Fix shared Web Fetch scoring and bind ten-method report evidence

[Maisiqi]

同步 main，并保留 PR51 的共享评分修复、原生答案来源检查和十方法报告。解决合并后的解析、运行参数、历史证据与报告规则差异；沿用原始调用，只对受影响结果离线重评分。

已合入 main 158f3555（#54）的代码拆分：评分器和任务定义现在由独立的 LexBench Web Fetch 包维护。配套评分修复 PR保留本次共享评分修复；本 PR 固定引用其 c75efb36 提交。抓取适配器、运行与重试、证据保护和报告继续由 Browser Eval 维护，不保留第二套评分器。

• 共 430 个任务、10 种方法、4300 条结果。重新评分 1320 条，保留其余 2980 条；通过数由 1966 变为 1972，失败 2328，没有新增 provider 调用。变化来自正文/列表/统计字段的解析修复和显式验收范围，未放宽原有页面身份要求。
• 共享入口继续验证正文、资源、文件、标题和最终网址的原生来源；调用参数由同一个生成函数供执行和事前冻结使用。保留 main 的运行、重试、任务合同和报告能力，并补上合并后的正反控制。
• 保留原始答案及原始校验值。敏感内容只在公开副本和诊断文字中脱敏，分别绑定原件与公开副本；评分、耗时、调用次数不因此改变。
• 2980 条旧复核经输入核对后沿用；1320 条重评分结果明确标为尚未重新人工复核。本次没有新增独立盲审。历史来源未完成调用前后全量核验，19 条超时缺少完整事前收据的限制仍保留；本轮排序只描述所列任务通过率，不代表完成仓库认证或通用能力排名。

本轮代码审查另修复三处共享边界：原生重试按每次实际调用保留并核验收据；Moli 普通与固定原生调用共用题类等待条件；冻结报告绑定当前维护的模板并拒绝缺失或伪造绑定。保留离线预览的既有使用方式。上述修复没有新增调用或重评分，样本内排名保持显示。

公开证据按顺序恢复，旧附件保持不变：

1. 原始公开输入包
2. 原标题与网址修正包 v2
3. 本次 main 同步修正包，将其中 evidence/ 内容覆盖到前两步恢复的证据目录；完整文件校验清单绑定全部 33373 个输入文件。

使用仓库现有生成器重建中英文报告：

uv run --frozen python scripts/build_report.py --local-audit \
  --evidence /path/to/restored-evidence --output /path/to/report \
  --presentation-binding research/native-430-local-report.json \
  --language zh --include-english
uv run --frozen python scripts/check_report.py /path/to/report \
  --presentation-binding research/native-430-local-report.json

验证：最新提交 29a4163a 包含当前 main，代码冲突已消除。本地 5746 项测试、2555 个子测试通过（138 项按环境跳过），界面、原生适配器、离线示例与四种安装包组合检查通过；PR51 完整 CI通过。评分库 1559 项测试、81 个子测试通过，Python 3.11–3.14 CI全部通过，其固定提交已通过无凭据、全新 Git 目录下载验证。

从恢复输入构建的中英文报告通过完整内容、证据和数字一致性检查，25760 个页面路径无断链；实际操作覆盖 120 项宽窄屏、明暗主题检查及 16 次成功/失败详情证据交互。完整输入包与清单均经匿名下载及哈希核对。详见交付验证记录。

当前 GitHub 显示代码可合并、机器检查通过；此前的人工审查状态仍为 CHANGES_REQUESTED，需要审查者复核后更新。本次未合并任何 PR。

[lanyue-llk]

Closing as superseded by #42. The current deliverable is the six-method, seven-family native Web Fetch comparison; #42 owns the shared execution, scoring, evidence and report changes. This ten-method local snapshot is stale and its report-specific binding is not part of the current release.

[lanyue-llk]

结果审计：当前报告不能作为正式排名发布

我下载并展开了 Artifact Site v2 的完整报告包，核对了 430 个案例、4,300 条结果、任务契约、复核记录和触发异常的原始输出。当前包可以保留为本地诊断快照，但不应按现状发布总榜或合并为正式报告。下面的问题会实质改变判分或排名。

1. 题目与验收契约互相冲突，影响 16 题、160 个结果

有 16 个动态任务明文要求排除导航或页脚，acceptance_contract.stable_text_anchors 却把 nav/footer 内的文字列为必需项。当前 160 个方法×任务结果中有 49 个被判通过。完整受影响任务为：

dynamic-013、014、015、016、018、024、025、029、034、035、039、041、046、058、096、107。

dynamic-029-029-primevue-basic-treetable 是最清楚的反例：题目要求“排除导航”，契约却要求大量 nav > span 项。Cloudflare 返回 144,955 字符的整站内容，132/132 检查项通过，但正文词精确率只有 0.0009、F1 只有 0.0017。这个结果主要靠题目明确要求排除的导航文字过关。

需要修正共享契约生成/校验逻辑，加入“排除区域不能提供正向命中”的成对回归用例，并重新判定这 160 条结果。只改报告文字不够。

2. 已确认一条当前误判通过

firecrawl__global-homepage-002-youtube-com__r001 应为失败。

题目明确规定按钮控件文字不能代替普通网页文字；输出开头是 Error 401 (Bad Request)，必需项 Live 只出现在播放器控件 0:00 / Live · Watch full video。首轮独立复核据此判失败，后续却用“所有文字都出现”改成通过，而且裁定记录只有通用模板，没有解释为什么可以违反位置限制。

按现有任务定义修正这一条后，Firecrawl 至少应从 359/430 降为 358/430；总通过数至少减少 1。

3. 已知 DNS 污染仍计入总榜，比较不公平

lexmount-doc 在本机被解析到私网 10.2.0.11，公网地址是 43.162.217.19。因此 Moli、OpenClaw、DeepSeek 的原生安全保护拒绝访问，另外 7 个托管/远端方法通过。报告和运行契约已经承认这个环境差异，却仍把该题计入各方法分数。

这不是产品能力差异。应把该题从全部 10 种方法中统一隔离，不能只保留三条失败；修复后重算所有分榜和总榜。

4. 来源没有在调用前后复核，却隐藏了本地非认证状态

local-run-contract.json 明确写着 source_reverified: false、reference_policy: frozen_existing。430 题中，129 题没有 checked_at；其余 301 题的核验时间在 9 月 2 日至 23 日，本轮调用是 10 月 10 日。与此同时：

• report-manifest.json 标记 evidence_state: local_measurement、certified: false；
• presentation.show_local_status_banners 却是 false；
• 首页仍显示“综合通过率总榜”“独立核验 4,300/4,300；未决 0”和 1—10 名。

这种展示会让读者把诊断快照当成正式排名。若不做调用前后来源冻结和认证执行，首页及每个结果页必须持续显示“本地、未认证、不可用于排名”，并移除名次表达。

5. “通过”没有约束输出纯度，异常输出被算作正常交付

在有正文参考的任务里，共有 182 条通过结果（55 个案例）的词精确率低于 30%。这不等于 182 条都应直接改成失败，但足以证明当前二元通过率不能代表“干净正文”。极端例子就是上面的 PrimeVue：召回率 1.0，精确率 0.0009。

另外两条 Firecrawl 结果在第 3 轮被从失败改为通过：

• firecrawl__live-027-sponsors__r001
• firecrawl__live-032-api-reference__r001

两份输出都包含完整 hCaptcha 挑战组件文字，指标里也保留了 forbidden_hits: ["CAPTCHA"]。它们可能满足“目标文字出现”的覆盖条件，但不能无条件称为正常、干净的正文交付。报告至少要把“目标覆盖”和“页面/挑战污染”拆成两个结论；若题目要求正文净化，后者应进入任务判定。

6. 变更记录与最终总数对不上

公开核验记录写的是：

• 第 2 轮：1904 → 1960；
• 第 3 轮：再增加 2 条。

按此最终应为 1962，首页各方法通过数相加却是 1967。final-audit/audit-summary.json 又写 original_passes: 1904、false_negatives_corrected: 60、false_positives_corrected: 3、corrected_passes: 1967，这组数本身只能算到 1961。另一个评分修正收据则记录 62 条假阴性、3 条假阳性，并另有 4 条 page-identity admission。

需要由一个结构化来源生成变更记录、审计摘要和首页数字，并让 release check 校验每轮增减与最终值守恒。现在无法从公开记录重建 1967 是怎么来的。

7. “全量独立核验、未决 0”的证据链不够完整

初始复核有 148 条 insufficient。后续确实补了判断或裁定，但最终结论仍有 117 条与 effective_agent_verdict 不同，其中 69 条只留下同一句模板裁定：“核对已有原始返回、冻结要求和相应修正证据；当前结论见评分明细。”上面的 YouTube 误判就在其中。

“未决 0”可以表示系统给每条记录都填了最终值，但不能代替可复查的逐案裁定。所有覆盖人工复核结论的记录都应保存具体规则、证据片段和裁定理由；release check 应拒绝通用模板。

合并前最低要求

1. 修复 16 个排除区域与正向锚点冲突的任务，加入正反回归，并重新判定 160 条结果。
2. 将 YouTube 结果改为失败，补位置/角色敏感的稳定文字测试。
3. 跨全部方法隔离 lexmount-doc，重算分数。
4. 统一并校验 1904→最终值的变更账目。
5. 明确区分目标覆盖、正文纯度和挑战页污染；不要把 182 条低精确率通过统一描述成正常正文。
6. 若继续保留这轮调用，整份报告只能标为本地未认证诊断快照并取消排名。要发布正式排名，应在调用前后重新核验全部来源，再按认证流程完成全量执行。

基于以上问题，我建议本 PR 保持阻塞状态；它也不应替代当前正式报告链路。

[lanyue-llk]

审查结论

Request changes。这个 PR 目前不应合并。

PR 实际解决什么问题

PR 的目标是保留并重建一份历史快照：430 个任务、10 种方法，复用已有调用，不发起新的正式评测。但实现范围远超“维护旧报告”。它改了共享评分器、任务通过谓词、回归用例库、本地复核门禁、运行器、报告渲染和国际化。这些修改会影响以后所有 Web Fetch cohort，不只影响这份历史报告。

当前正式重跑已经由 #42 负责。#51 保存的是过期、未认证的十方法本地快照。里面可复用的修复可以拆出来，但不能用维护旧报告的名义一起进入共享链路。

阻塞问题

[P0] 未认证报告可以隐藏身份，同时继续展示排名

scripts/build_report.py:31-32 新增了 --hide-local-status-banners。harness/web_fetch/report.py:1840-1843 在调用完整时清空可靠性警告和本地审核提示，即使 manifest 仍是 certified: false，publication_state 仍是 local_audit_only_not_for_release。report_check.py 会检查证据，却不要求页面保留未认证标记。

当前报告正是这样生成的：presentation.show_local_status_banners 为 false，首页却仍显示总榜和第 1—10 名。读者很容易把诊断快照当成正式结果。

本地、未认证证据不能关闭这个标记。若横幅太占位置，可以改成每个页面都有的紧凑标记；release check 还应拒绝这类报告使用排名措辞，并增加“缺少标记必须失败”的反例测试。

[P0] PR 改了全局验收规则，却把它记成“没有规则修订”

harness/web_fetch/metrics.py:26-28、325-340、569-571 把 forbidden_hits、blocked_page 和 stable_blocked_page 降成纯诊断项。只要命中足够多的正向锚点，包含挑战页或拒绝访问内容的结果也可能通过。这是共享评分策略变更，不是展示修复，也不是单纯的解析器修正。

与此同时，harness/web_fetch/local_audit.py:417-427 强制这些复评分结果填写 scoring.rule_revision is False。报告因此把新规则伪装成没有规则变化的离线修正。报告里的两条 Firecrawl 输出包含 hCaptcha 文字，也通过这条路径由失败改成通过。

回归用例本身也可被改写：harness/web_fetch/scoring_regressions.py:33-40 允许 control_revisions.overrides 替换旧 ID 的输入和期望结果。本 PR 改写了 15 条控制用例。例如 html-doctype-visible-challenge-still-blocks 这个名字还说“应该阻断”，期望值却被改成了 True。测试会通过，但旧用例已经不再保护原来的行为。

不要靠放宽全局谓词来挽救这份报告。如果产品合同确实要变，应走真实的 scoring-rule revision：提升合同版本，保留旧控制用例，用新 ID 增加成对反例，并对全部受影响结果重新评分、重新复核。

[P1] “全量独立复核、未决 0”没有被门禁真正约束

harness/web_fetch/local_audit.py:545-582 只检查当前评分、agent_verdict 的取值范围，以及 final_verdict 是否等于评分器结果。它不检查 effective_agent_verdict、分歧与裁定证据，也不要求逐案理由。

我构造了一条记录：机器和当前结论为 pass，人工及 effective 结论为 fail，最终结论改回 pass，裁定理由为空，未决数为 0。_require_local_review 接受了它。报告中有 69 条覆盖人工结论的记录只保留同一句模板，已确认误判的 YouTube 案例也在其中。

人工/effective 结论与最终结论不同时，必须保存并校验具体规则、证据和逐案裁定；同时校验状态流转和分歧总数。应增加“空裁定不能通过”的反例测试。

[P1] 回溯页面身份可以用归一化后的空字符串通过

harness/web_fetch/local_audit.py:491-497 检查的是原始样本文本长度和原始值去重，之后才用归一化结果做子串匹配。两个分别由 20 个和 21 个空格组成的不同字符串都会归一化成 ""，而空字符串存在于任何正文中。

我用这两个样本和完全无关的保存输出、浏览器捕获做了实测，score_reviewed_page_identity 返回了 page_identity_status: verified，basis 为 retrospective_content_correspondence。

样本应先统一归一化，再检查非空、最小有效长度和归一化后的唯一性。更稳妥的做法是程序提取双方共有的确定性片段，不接受复核者任意填写字符串。空白、标记差异和纯标点样本都要有反例测试。

[P1] 哈希绑定的历史文章仍会把活动 HTML 注入报告

harness/web_fetch/report_reading.py:26-48 从外部 HTML 中抽取 <style> 和 <main>，随后原样塞进报告。哈希只能证明使用的是哪份字节，不能证明这些字节安全。我放入 <script> 和 onerror 属性后，二者都原样出现在渲染结果中。

同一外部包还可以提供翻译。harness/web_fetch/report_i18n.py:4100-4101 把它并入全局翻译表，因此历史文章数据可以覆盖报告其他页面的界面文字。

这里应使用结构化 Markdown，或对 HTML 做严格的标签、属性、URL 白名单清洗。文章翻译只能作用于文章路由。测试至少覆盖 script、事件属性、iframe/form、危险 URL 和覆盖全局翻译键。

[P1] 评分器登记了锚点来源位置，却完全不按位置匹配

harness/web_fetch/stable_tasks.py:780-803 接受 source_location，但 evaluate_stable_task 在 1032-1035 始终对整份可见文本匹配锚点，没有使用位置约束。

这正是报告中 16 个冲突任务的代码根因：题目要求排除导航或页脚，验收锚点却来自 nav/footer；受影响的 160 条结果中有 49 条利用被排除区域的文字通过。

不要从自然语言题目里猜区域。应在共享合同里加入机器可读的允许/排除区域，或明确的 match_location；校验器要拒绝来自排除区域的正向锚点，评分器只能在所属区域匹配。还要加入一组成对用例：同一文本出现在错误区域时失败，出现在允许区域时通过，然后重判这 160 条结果。

[P1] 作为历史快照，PR 范围过大，描述也没有覆盖真实风险

实际 diff 是 57 个文件、约 1.3 万行新增，涉及共享 provider、runner、评分器、解析器和报告渲染。PR 描述只说维护旧报告、没有新调用，没有交代全局判分变化、15 条回归用例改写、人工结论覆盖、页面身份补录、隐藏状态、外部 HTML、已知 DNS 不对称、测试命令，也没有说明与 #42 的关系。

最小可维护方案是：

1. #51 保持关闭/被替代，只作为历史诊断快照保留。
2. 有通用价值的解析器和渲染修复拆成小 PR，各自提供独立测试。
3. 评分策略变化走现有的版本化规则修订流程，不放进本地报告的特殊分支。
4. 当前公平重跑及正式报告继续由 #42 负责。

实测范围

• 下载并检查了 Artifact Site v2 完整包：430 个案例、4,300 条结果。报告结果审计见 #51 (comment)
• 运行了本地审核、lineage、admission、评分、报告语言和正文范围的定向测试：171 passed, 1 skipped, 107 subtests passed。
• 分别给复核门禁、页面身份匹配和历史 HTML 渲染写了反例；三个不安全输入都被接受或保留。
• GitHub CI 全绿，但现有测试没有覆盖上述对抗样例，也没有发现报告层面的任务冲突。

[Maisiqi]

历史版本说明：以下内容对应此前的 1968/4300 版本，保留供追溯；其中 SQLite 9/1、复核覆盖和旧附件依赖不再代表当前修订。最新处理见本轮回应和 PR 正文。

针对最新审查及后续更正，本次采用单一当前规则，不再保留运行时 v1/v2 分支。

• 接受：不能混用旧指标与新判定，也不能无痕修改规则。 已删除 EvalCase、score_attempt、task_passed 中的策略选择器和回归库的历史版本注入。旧源码及原控制集按哈希冻结保存；当前库只验证当前行为，被替代的控制逐项记录 ID、原定义哈希和原因。全部 4300 条保存输出重新评分，无新增产品调用，修订凭证保留旧/新哈希和逐条判定变化。
• 禁止要求与诊断提示分开。 框架继续支持真正明确的禁止输出要求，不能在不修订合同的情况下把它降为提示。但这批抓网页任务的目的，是检查要求的内容是否取得：完整正文可能正常讨论 CAPTCHA、403 或 Access denied，仅凭词语出现不能证明抓取失败。因此明确修订这批案例，将这些检查项迁移为 diagnostic_any，不再单独否决结果；正文、事实、记录数和结构要求仍然有效。正反测试覆盖“正文完整且出现提示词仍通过”“只有提示词、缺少目标内容仍失败”，并另保留真正禁止要求的测试。这项调整记为规则修订，不称为原合同没有变化。
• 接受：SQLite 十次新调用必须有完整且可访问的证据。 已将替换案例接入完整本地测量使用的共同执行校验，核对冻结题目、方法配置及版本、Python/运行环境、45 秒预算、并发和重试设置、系统默认 DNS、前后来源材料、每次输出与完整调用日志。缺少这些材料、只拼十条结果行不能通过。执行合同是根据保留的真实输入和物理调用清单整理的，不伪称补出了事前签发的认证。新增十条现已逐条复核，九通过、一失败与程序一致；此前已知机器汇总，不称为盲审。
• 接受：可见状态不能靠隐藏 DOM 标记代替。 已改为页面可见的简短普通文字，检查会拒绝隐藏、空白或嵌在隐藏父元素中的状态说明；没有恢复此前黄色提示框。

仍有两处方法判断上的分歧，明确保留：

1. 保留这批样本的通过率排序。 该排序只是所列任务与配置下的计数和通过率，不据此宣称工具在所有网页上的能力顺序。缺少历史前后核验会限制结论，但单凭这一缺口，不能推出这些已保存返回和通过率全部失去比较价值。报告保留 certified: false、测试日期及核验范围；耗时不参与名次，也不将日期混合或时间重叠产生的耗时差异全部归因于工具本身。因此没有接受“取消全部名次”。这是保留意见，未冒充 reviewer 已认可。
2. 不把每次全量前后核验视为所有稳定内容题的唯一可用流程。 制定本批要求时，选择了尽量稳定的内容，避开价格、名次、人数等易变内容；判断短时间内变化风险较低。逐轮全量核验会增加请求和检查时间；对于这类稳定内容题，我认为全量前后核验过于严格，时间投入与预期收益不相称，更倾向于对异常、争议和易变页面重点核验。不过，这只是当时的取舍与未来流程建议，不能证明历史页面都没变化，也没有追认历史调用符合现行认证流程。

16 道动态题的范围调整同样作为当前规则修订保留，不追认历史认证。允许已独立观察到、与题目目标相关的稳定导航或页脚，并不等于只返回导航即可通过；目标内容与记录要求仍需满足。纯 Markdown 无法普遍证明每段文字的 DOM 来源，因此不声称拥有通用的页面位置判定能力；YouTube 的播放器排除只按该题已有证据与明确范围处理。

当前提交为 1e5e4768，430 个案例、4300 条结果，通过 1968/4300。当前案例中没有仅凭禁止词就否决结果的要求；305 道题保留相关诊断提示。SQLite 的十次调用为 9 通过、1 未通过。保留历史 4290 条复核及 652 条补充裁定；新增十条完成本次逐条复核，当前覆盖 4300/4300，未复核通过数为 0。

本地完整测试 5290 通过、54 跳过；后续修改的针对性检查通过（本次复核、结果汇总和原失败场景共 57 条通过、13 子测试通过），CLI 检查通过。最终报告检查通过：430 题、4300 条结果、10 种方法、25798 个页面路由。当前提交的 GitHub 测试 已完成：主测试和 Python 3.12/3.13/3.14 三组 CLI 测试均通过；Claude 自动审查跳过。

最新证据附件：PR-51-current-rule-and-sqlite-evidence.zip，14,815,846 字节，SHA-256：3218b22ad388ebb2ae3e084e9378d323ddd9950e75783ae33f75339a4812bdc0。已从 GitHub 下载并核对哈希，实际完成独立目录还原，未重新调用产品。它需要同一草稿内的旧补丁和固定 Artifact Site v2 原始证据；旧补丁中的 1959/4290 是上一阶段，不是当前成绩。草稿限有权限的仓库 reviewer 查看，固定附件 API 地址及哈希已写入 research/native-430-local-report.json。线上 Artifact Site v2 未替换。

此前 YouTube 控件误判、空白身份样本、历史 HTML 清洗、文章翻译范围、逐条裁定和分数账目修复均保留。本 PR 不替代 #42 的认证链路，不表示已获得审核批准。

**本次新增的十条复核：**已完整阅读 SQLite 十份返回，并核对冻结正文、四个必需事实、五段正文覆盖和原始响应。OpenClaw 的返回从 C 示例开始，缺 sqlite3 test.db、命令行建库章节和 TCL 示例，保留失败。其余九条满足当前内容门槛。Tavily 的代码缺字与单行化直接存在于 API 的 raw_content，不是适配器丢失；其覆盖率仍达现行门槛，保留通过，同时记录代码不能保证直接运行。Crawl4AI 代码块内的加粗标记、CowAgent 的实体编码也已记录，不能把内容通过说成代码原样无损。未新增调用、未改分、未改原时间与耗时。

新增证据附件为 PR-51-sqlite-ten-result-review.zip，2,218,013 字节，SHA-256：0fd186daed24ea8495e14f0ee2e52e769a65aa44688b2cbea6f4561d6b61894b。在前述 14.8 MB 附件之后应用；历史 4290 条意见不变，十条初步判断、精确片段及原生响应调查均有绑定。

[Maisiqi]

历史版本说明：以下内容对应此前的 1968/4300 版本，保留供追溯；其中 SQLite 9/1、复核覆盖和旧附件依赖不再代表当前修订。最新处理见本轮回应和 PR 正文。

最新修正证据已上传到同一草稿附件页，供有仓库权限的 reviewer 核对；这不是正式报告发布。

当前为 1968/4300 通过，包含 SQLite 的十次真实调用；此前 DNS 题排除后的 1959/4290 属于历史阶段。

• 最新附件：PR-51-current-rule-and-sqlite-evidence.zip，14,815,846 字节。SHA-256：3218b22ad388ebb2ae3e084e9378d323ddd9950e75783ae33f75339a4812bdc0。
• 必需的先前补丁仍保留：PR-51-diagnostic-correction-patch.zip，7,580,469 字节。SHA-256：90d51b8bed3c8c480a45160a3cd8d624753451ee08f04ba816b7e6bb708d1c24。

按 FOLLOWUP-README.txt 使用固定 Artifact Site v2 原始证据及先前补丁，再应用最新附件。已验证独立目录还原、4300 条输出与评分哈希一致，并从 GitHub 下载核对附件；还原过程不会调用产品。固定附件 API 地址见 research/native-430-local-report.json。

当前提交 · 修复及保留意见。线上 Artifact Site v2 仍未替换。

最新复核补充附件：PR-51-sqlite-ten-result-review.zip，2,218,013 字节，SHA-256：0fd186daed24ea8495e14f0ee2e52e769a65aa44688b2cbea6f4561d6b61894b。在以上附件之后应用，当前复核覆盖补齐至 4300/4300，分数仍为 1968/4300。十条新增复核不是盲审；原文片段及 Tavily 代码缺字等异常调查保留，输出、调用与耗时均未修改。

[lanyue-llk]

最新提交审查：仍需修改

我按当前 head 12250db8 重新检查了代码、增量提交、测试和已上传证据。前一轮指出的多数实现缺陷已经修正：旧评分控制没有再被覆盖；YouTube 播放器文字已改判；页面身份空白绕过、历史 HTML 注入、全局翻译覆盖、模板裁定和结果账目也都有对应门禁。这些修改可以保留。

不过当前版本还不能合并，下面的问题会让历史结果被静默改判，或把未认证快照包装成正式排名。

[P0] 缺少策略版本的旧结果会自动套用 v2

harness/web_fetch/metrics.py:329 使用 metrics.get('acceptance_policy_version', 2)。历史记录没有这个字段时，会被当成 v2；而 v2 已把 blocked_page、stable_blocked_page、forbidden_hits 从硬失败改为诊断项。

我直接调用当前 task_passed 验证了同一份指标：缺少版本时返回 True，显式 v1 返回 False，显式 v2 返回 True。这意味着旧证据即使没有进入本次 411 条重评分范围，也可能在汇总或重建报告时悄悄从失败变成通过。

缺失版本应按历史 v1 解释，或者直接拒绝读取；只有新评分产生的记录才能显式写 v2。请补一组成对测试：无版本的 legacy blocked 记录仍失败，显式 v2 才按新规则判断。

[P0] 未认证状态被隐藏，报告却恢复了排名

harness/web_fetch/report.py:1860-1867 在 presentation.ranking == saved_task_pass_rate 时只输出一个隐藏的 data-evidence-state，页面上没有任何未认证提示。随后 generate() 把这份本地快照当成非诊断报告，恢复“综合通过率总榜”、排序和 1—10 名；report_check.py:191-203 也专门允许这条例外。

这不是展示取舍。PR 正文写的是“仅供诊断，不用于排名”，manifest 仍是 certified: false，历史调用又没有完成来源前后全量核验。隐藏 DOM 属性无法告知读者证据边界。测试 test_explicit_sample_ranking_reuses_existing_ranked_table_and_keeps_scope 还明确要求横幅文本为空，说明这个绕过是有意固化的。

请删除 saved_task_pass_rate 例外：未认证快照每页保留可见、简短的状态说明，并使用非排名表格。正式排名留给完成认证流程的 #42。

[P1] SQLite 替换题的十次新调用没有绑定完整执行契约，最新证据也未交付

当前草稿附件仍是上一版的 1959/4290 修正包，不含 SQLite 新题的十次调用。最新版 1968/4300 只在 research/native-430-local-report.json 中绑定了本机 data-home 路径；该路径不是 PR 内容，也不在附件中，因此 reviewer 无法复现或核对这十条输出。

代码门禁也不够。require_local_task_replacement() 只确认每个方法各有一条记录、没有 retry、旧行没变；require_replacement_execution() 只核对 attempt ID 计数。测试中的最小 receipt 没有调用前任务契约、provider 配置、运行参数、超时/并发策略、来源核验或执行证书，仍能通过。

替换题既然用于恢复 430 题排名，就必须沿用现有 shared local-measurement gate：在调用前绑定题目和参考、十种方法配置、运行环境、超时/并发/retry/DNS 策略，调用后绑定完整执行和来源证据。请同时上传或固定一个包含最新版十次调用的可访问证据包。单独再造一个较弱的 replacement gate 没有必要。

[P1] 16 道动态题的修改可以作为新规则，但不能倒推成旧排名

新增 content_scope 和正文最低要求的方向是合理的：允许登记过的导航/页脚稳定文字参与覆盖，同时阻止“只有导航/页脚”通过，32 个反例也覆盖了这一点。它比为 16 道题逐题打补丁更通用。

但这仍是题目合同变化。旧题明确要求排除导航/页脚，现在改成允许它们参与正向命中；160 条历史结果因此按新合同重判。可以把它作为版本化的诊断分析，不能据此恢复这批历史调用的正式排名。另一个边界仍未解决：HTML 可以按区域检查，Markdown/纯文本通常无法证明某段文字来自导航还是正文，目前只能靠个别文本模式补洞，不应宣称已有通用的位置敏感判分。

[P1] 没有调用前后来源核验时，风险分层可以讨论，但当前报告不能排名

作者提出“稳定文字不必每轮全量核验”可以作为后续协议设计讨论，但它不能追认已经发生的调用。129 道题没有 checked_at，其他参考也早于本轮调用；现在补查无法证明调用当时页面未变。

对本地诊断快照，重点复核异常案例是可接受的成本取舍。若要发布十方法排名，仍应按仓库现行合同做调用前后完整来源冻结和认证执行。应先改协议、加入风险分层的可执行门禁，再用于未来 cohort，不能给这批历史数据开例外。

[P2] PR 正文和范围仍没有交代真实变更

当前 diff 为 76 个文件、约 1.48 万行新增，除了报告修复，还包括共享 runner/provider、评分策略 v2、871 条回归控制、411 条重评分、16 个任务合同修订、任务替换和十次新调用。PR 正文只有两句话，也没有列出最新证据包、4290/4300 的复核范围、来源核验缺口及与 #42 的边界。

建议把通用修复和历史报告处理拆开：评分版本、HTML 清洗、裁定证据、账目校验、角色/区域匹配可以独立合并；十方法历史快照保持未认证、非排名，正式重跑继续由 #42 负责。如果暂时不拆，至少要把以上范围和证据限制写进 PR 正文，不能只放在评论里。

结论

合理且已修好的部分不算过度设计：评分策略版本化、不可变回归控制、HTML 白名单、逐案裁定证据、结果账目、通用 content_scope/text_exclusions 都解决了真实的共因问题。

真正多出来且有害的复杂度，是为一份 certified: false 的历史快照增加 saved_task_pass_rate 排名逃生口，以及另建一个弱于现有执行契约的任务替换门禁。这两处应删除并回到共享认证边界，而不是继续加例外。

定向测试共 67 条通过；GitHub CI 也全绿。上述结论来自现有测试之外的反向样例和证据可达性检查，测试通过不能覆盖这些合同问题。

[lanyue-llk]

补充更正上一条审查中“缺少策略版本”的处理建议。

重新按仓库的单一当前实现规则核对后，这里不应把缺失版本默认成 v1，也不应在当前运行时同时保留 v1/v2。这个 PR 已经用 scorer 哈希、冻结 scorer 快照和修订收据保存历史规则；复现旧报告时应使用其绑定的旧 scorer 字节，不需要让最新版 score_attempt、task_passed 和 EvalCase 继续切换旧逻辑。

因此该问题的最小修复应改为：

1. 当前评分器只保留一套最新、正确的验收逻辑，删除 acceptance_policy_version 选择器、v1 分支和 historical_policy_versions 运行时注入。
2. 对本次规则修正影响到的完整方法×任务范围统一重评分，用 revision receipt、旧/新 scorer 哈希和逐条 verdict transition 记录变化。
3. 当前回归库只验证当前正确行为；旧行为由 Git 历史和已绑定的 frozen scorer 保存，不作为现行测试继续执行。旧控制如被新规则取代，应在修订收据中列出 superseded ID 和原因，不能无痕改写。
4. 旧报告若要原样复现，走已有 scoring-snapshots/<sha256>/；若用当前代码重建，则必须完成整组重评分，不能混用旧指标和新谓词。

当前所谓 v2 还混在一起处理了两类不同信号，也需要在单一现行规则里拆清：自动识别出的挑战页/错误页提示可以作为诊断信号，避免正文讨论“CAPTCHA”时被误杀；但案例显式声明的 forbidden_any 是任务合同，不能一律降成诊断项。现在 evaluate_content() 即使命中 forbidden_any 仍把 content_pass 设为真，测试也把这种行为写死了。最小修复是保留一个当前谓词，把启发式 blocked_page 与合同级 forbidden requirement 分开命名和判定，而不是靠 v1/v2 切换两套含义。

我上一条中“缺失版本按历史 v1 解释”会继续扩大兼容层，不符合仓库要求，请以上述更正为准。

其他阻塞结论不变：未认证快照不能靠隐藏 DOM 标记恢复排名；SQLite 十次新调用仍需完整、可访问的执行与来源证据；16 道任务合同变化可以作为当前规则修正，但不能追认历史排名。

[lanyue-llk]

最新 head 审查结论：仍需修改

本次按 1e5e4768 重新核对了代码、三份最新证据附件、SQLite 十条原始输出和当前复核记录。前面指出的双版本评分、显式禁止项与诊断提示混用、SQLite 执行契约缺失等问题，最新版已经按正确方向修复。当前评分器只保留一套规则，旧指标会被拒绝；forbidden_any 继续影响任务结果，diagnostic_any 只做提示；十次替换调用也已绑定运行参数及调用前后来源证据。这些修改可以保留。

但下面五项仍会造成错误结论或无法审计的结论，暂时不能合并。

[P0] 未认证快照仍可通过专用开关恢复排名

harness/web_fetch/report.py:1858-1876 用 presentation.ranking == saved_task_pass_rate 把 local_audit_only_not_for_release 从诊断模式切回排名模式；report_check.py:224-238 也显式接受这条例外。页面虽然增加了“未完成认证流程”的一句话，仍然显示排序、名次和榜单。

这批历史调用没有完成仓库要求的调用前后全量来源核验。当前数据中 430 题只有 304 题带有效来源核验，126 题没有。提示语不能补回缺失证据，也不能让排名成立。请删除 saved_task_pass_rate 分支：未认证快照统一走非排名诊断表；正式排名仍由完成认证流程的 cohort 产生。这个分支是目前最明显的报告专用例外，也是有害的额外复杂度。

[P0] 3050 条受规则变化影响的旧人工判断被改写绑定，却没有按当前合同复核

本次把 305 个案例的旧 forbidden_any 从硬失败条件迁到 diagnostic_any，影响 3050 条方法×任务结果。4300 条机器结果确实全部重评分了，但旧人工意见没有重新做。

adjudication_evidence._require_review_binding_revision() 把这件事登记为 unchanged_target_and_verdict_evidence_carryforward：先在内存里把旧案例的 forbidden_any 改名为 diagnostic_any，然后据此断言“目标要求未变”，再替换旧证据的 case hash 和 rule ID。硬失败条件改成诊断项是验收语义变化，不能靠改字段名把旧复核变成当前复核。证据本身也写明 new_independent_review: false。

因此当前报告不能宣称“4300/4300 当前合同独立复核”。请保留旧复核为历史记录，并在当前覆盖率中排除这 3050 条；或者按当前合同重新复核完整受影响范围。不要继续扩展这套 review-binding migration。当前复核材料里还有 47 条读者可见摘要写着“规则版本 2”，也说明迁移只改了绑定，没有把当前语义和展示清理干净。

[P0] 裁定门禁只验证文字存在，不验证文字是否为真

require_adjudication_evidence() 只检查理由非空、case/content hash、rule_ids 非空和摘录位置。它不确认 rule ID 存在，也不确认理由里声称的命中项与当前 metrics 一致。我用不存在的 rule ID，并写入“CAPTCHA 已命中”，而实际答案没有 CAPTCHA，当前校验仍返回成功。

最新 result-review.json 已经出现同类问题：38 条裁定写着“命中词：。”，却继续声称先前意见是由验证/错误词触发，其中一些 rule_ids 还包含 diagnostic_any。例如 moli-webfetch__stable-browser-use-readme__r001 的旧人工证据明确引用了两处 CAPTCHA 文本，迁移后的中文理由却变成空命中；英文摘要仍写 Policy version 2。

请让门禁校验语义，而不只是格式：rule ID 必须属于当前案例/指标；引用 diagnostic_any 时，理由中的命中词必须与 metrics.diagnostic_hits 精确对应；引用某条通过或失败规则时，该规则的计算结果必须支持裁定。给“不存在的规则”“空命中”“理由与 metrics 相反”各加一个失败用例，并重新生成、复核受影响裁定。

[P1] SQLite 题目合理，但验收漏掉了题目明说的代码保真，已经产生误判通过

题目要求保留正文、标题、列表和代码示例。当前合同只检查四个关键词，加五段正文词覆盖，没有任何代码完整性规则。我用当前评分器重算附件中的原始输出：Tavily 和 Crawl4AI 都通过。

但 Tavily 的 C 示例已经损坏：两个 #include 的内容为空，for(i=0; i<argc; i++) 后半段被截断并直接粘到 sqlite3 *db。复核文字也承认“代码不可直接运行”。Crawl4AI 则把 ** 加粗标记写进代码块，改变了代码文本。这与“保留代码示例”冲突，不能一边承认代码损坏，一边判任务通过。

建议保留这道题，因为它能测出正文抓取之外的代码保真；补上最小、任务级的代码完整性要求，例如对 TCL 和 C 示例各登记若干归一化后的完整代码行/连续片段，并加入“只有四个 API 名称但代码残缺应失败”“完整代码仅空白或链接格式变化应通过”的成对控制。然后统一重评分十条结果。不要为 SQLite 单独写 provider 分支，也不要为了保住当前 9/1 结论弱化题目文字。

[P1] 当前结果账本从 1968 重新起算，丢掉了可机器校验的完整变更链

前置证据里的账本完整记录了 1904 → 1959 的各轮增减；最新 local-evidence/result-ledger.json 只剩两个从 1968 开始、变化数均为 0 的状态。旧账本虽然另存为 task-replacement/baseline-result-ledger.json，任务替换收据没有把“移除 10 条旧结果、加入 10 条新结果、9 通过/1 失败”建模成同一条可校验的转换，当前账本也没有引用前置账本。

这会让报告中的完整历史再次依赖人工写的 review_rounds 文本。请让顶层账本引用并校验前置账本、任务替换收据和当前结果，明确记录旧任务十条退出、新任务十条进入，以及 1959 pass + 9 pass = 1968 pass 的口径。账本可以增加一种“原子任务替换”事件，不要把新结果直接当成无历史的 baseline。

证据交付仍不完整

当前 profile 指向两个 GitHub draft release asset，文件自己写明需要仓库写权限；还要求先取得 Artifact Site v2 的原始导出。公开 share 页面目前仍是旧报告，不能从公开入口拿到完整重建输入。普通 reviewer 无法从 PR 提供的公开材料独立还原最新版。

证据仍应放在 Git 之外，但请提供一个固定、只读、reviewer 可访问的完整包或 Artifact Site 版本，绑定同一组哈希。不要要求仓库写权限，也不要依赖未公开的本机 data-home。

对修改方案的判断

以下部分不是过度设计，应保留：单一当前评分规则；合同级禁止项和诊断提示分离；拒绝旧指标混入当前汇总；共享执行契约；HTML 白名单清洗；页面身份样本归一化；成对评分回归。

需要删除或收缩的是三套为历史快照开例外的机制：saved_task_pass_rate、把语义变化包装成“要求未变”的 review-binding migration、以及从当前数值重新起算的结果账本。最小方案不是再增加一个策略版本，而是让当前代码只有一套规则，让历史证据保持历史身份，未认证数据只做诊断。

验证记录：最新定向测试为 104 passed、870 subtests passed；评分/复核反向用例另行实测。GitHub CI 目前全绿，但现有测试会主动接受上述排名例外和复核迁移，因此 CI 通过不能排除这些问题。

[Maisiqi]

本轮任务通过率排名继续保留。作者制定检查要求时选择的是预期稳定存在的正文、文字和结构，没有把容易变化的内容作为检查项。作者因此判断：这些要求短时间内变化风险较低，逐次增加调用前后核验的时间成本较高，没有这项检查不足以成为删除本轮排名的理由。

排名只回答“各方法在这 430 个任务和当前要求下，保存的结果通过了多少”，按本轮实际通过率排列，耗时单独展示。稳定检查项降低了网页变化风险，但不能证明历史网页绝未变化。因此报告保留实际检查缺口，不补称历史调用已经核验，不宣称完成仓库认证，也不推广为所有网页上的能力顺序。

这是作者对比较用途和检查成本的取舍，与 reviewer 的分歧仍保留，不声称已经获得认可。其他成立的问题继续修复；最新修复、72 条受影响结果复查、4228 条旧意见复用及公开证据交付见本轮逐项回应。

[lanyue-llk]

Reviewing the current head 7a8731f.

I re-ran the relevant tests (315 passed, 1 skipped, 160 subtests passed) and checked the published 282 MiB evidence archive against its declared SHA-256. The earlier candidate-extraction problem, CowAgent/Cloudflare answer cleanup, stale PR description, and missing public evidence package are fixed. I also checked the suspicious-looking historical Moli resource_page_runtime rows. The retained call log shows fetch --dump html, with no --eval, so those rows are not evidence of case-specific cheating.

The PR still should not merge in its current form:

1. [P0] The native-answer proof is optional and incomplete for fields that directly affect the score. require_native_answer_projection() returns immediately when the declaration is absent and compares only fields listed by the declaration. SubprocessJsonlProvider copies the worker's entire metadata into the result but declares only content; images, links, videos, media, extras, and files can therefore affect scoring without being checked against the retained native response. Firecrawl, Tavily, Exa, and the ordinary Cloudflare routes retain raw responses but do not declare an answer projection at all. I reproduced this with a native response containing native.png and adapter metadata containing forged.png: the projection check accepted it, and evaluate_resources() awarded a pass from forged.png. The published supplemental review shows the same coverage gap. Of the 72 freshly checked rows, 16 say native_projection_verified=true, 45 say false, and 11 leave it unset. The minimum fix is one provider-neutral allowlist of score-bearing outputs and a fail-closed rule: every score-bearing value must be projected from the retained native envelope, or byte-bound for files; undeclared score-bearing metadata must be rejected. native_route_cell.answer_fields should drive that check instead of serving as descriptive metadata.

2. [P1] Failed calls can pass the new route verifier without any invocation signature. In verify_native_route_contract(), line 317 requires a request only when row['ok'] is true. I built a two-row failed cohort with empty requests; the verifier accepted it. That leaves the exact blind spot the historical audit already exposes for 19 timeouts. Every executed result must have exactly one bound request signature. If failure before transport is a supported outcome, record a separate, explicit pre_transport_failure receipt and keep it out of claims about an observed provider route.

3. [P1] The report still publishes an ordering from an uncertified cohort. The public archive README says it “does not certify historical pre/post source checks”; the verification record says historical source certification is incomplete; the route audit is retrospective, was not frozen before calls, and has 19 unconfirmed timeouts. local_pass_rate_ranking() still grants uniform_native_local_measurement a special ranking path. That leaves a second, weaker publication policy. The retrospective audit is useful archive evidence, but it cannot satisfy the repository's certified pre-call contract. Remove ranking, winner, and order claims and present per-method descriptive counts only, or rerun the complete cohort through the current certified pipeline. The historical path must not satisfy the release gate.

4. [P2] native_routes.py duplicates each adapter's request-construction logic. _request_parameters() independently rebuilds the Tavily, Exa, Firecrawl, Cloudflare, Moli, and JSONL requests that the adapters build again when executing. This is a second implementation owner and will drift as soon as an adapter changes. The smaller durable design is for each provider to expose one pure canonical request builder; pre-call freezing and execution must consume the same object. The ledger should serialize and compare that object, not maintain a parallel request implementation.

Items 1–3 close correctness gaps. Item 4 removes duplicated machinery. The historical evidence can remain available after these changes, under the current publication rule.

[lanyue-llk]

Correction to my review of 7a8731f: I set the bar too high on two points and am narrowing the requested changes.

A single measured cohort can support a scoped ordering of the saved pass counts. Missing historical pre/post source certification limits reproducibility and any claim that the order generalizes beyond these 430 observed tasks, but it does not by itself make the arithmetic or the within-cohort description false. I therefore withdraw item 3 as a correctness blocker. Keep the wording tied to this run, avoid a general product winner claim, and treat any stricter certified-release requirement as a publication-policy gate rather than evidence that these results are wrong. I am not asking for a full rerun or removal of the scoped ordering solely on that basis.

I am also narrowing item 2. A failed result may legitimately have no provider request when it failed before transport. The real defect is that the receipt does not distinguish that case from a timeout or failure after transport whose request signature was lost. Add an explicit failure stage or pre_transport_failure state and require a signature only after transport begins. This is an auditability issue, not proof that the current pass counts are wrong.

Item 4 is a maintainability recommendation. The duplicated request builders are likely to drift, but they should block this PR only if the frozen and executed requests already differ.

Item 1 remains the substantive blocker. I reproduced a score-changing path in which undeclared metadata.images differs from the retained native response, passes the projection check, and supplies the URL that makes the resource score pass. This is a concrete false-pass mechanism, not a demand for perfect evidence. The minimum fix is to reject undeclared score-bearing fields and bind every field the shared scorer reads to the native response or file bytes.

[Maisiqi]

@lanyue-llk

针对 7a8731f 的审查及后续更正，本轮按以下范围处理，没有新增网页或 provider 调用。

1. **接受计分字段缺少完整来源检查的问题，已修复。**正文、链接、图片、视频、media/extras 和返回文件分别声明原生来源；未声明的非空计分字段不能进入评分。固定原生调用还按冻结路线的 answer_fields 限制可读取的来源。API/worker 字段与保留的响应比对，文件与原始字节比对，文件通过与否从字节检查计算。持久化、保存证据的聚合检查及显式传入原生响应的离线评分共用检查。已补“额外塞入正确链接”“替换图片”“删去错误候选”“伪造文件/文件通过标记”等反例，以及正常返回的正例；原来能误判通过的小例子现在会在评分前被拒绝。

   对当前 4300 条保存结果做了事后字段核对：3847 条核对保留的原生响应，430 条 CLI 结果核对输出/文件绑定，23 条没有可计分的返回；没有发现答案字段不一致。另核对 37 份文件评分记录，未发现与字节检查不一致。没有改写旧结果来冒充当时已经声明字段，没有新增盲审；总成绩仍是 1966/4300 通过。详见字段核对记录。

2. **接受更正后的失败阶段要求，已补新调用的检查，并重新查历史日志。**以后收据区分进入对外调用步骤之前和之后的失败；进入后必须保留对应调用签名，不能再让失败结果一律跳过检查。超时后丢弃迟到文件，但仍把该任务记为超时未通过，避免从统计中漏掉。这里的“开始调用”指进入 HTTP/进程/worker 发送步骤，不声称服务器已经收到请求。

   历史 19 条超时的原始诊断日志均按保存的 SHA-256 找回。其中 12 条有 http_request_started，可确认已进入 HTTP 请求步骤；7 条有 worker_request_sent，可确认任务已发送给 worker，但不能仅据此确认 worker 已向网页发起网络请求。因此修正此前笼统的“19 条均无法确认调用阶段”的说法。完整的事前冻结参数收据仍不能补造；保留原来的超时未通过结果，不重跑、不写成已补齐全部历史证据。详见历史超时阶段核对，公开记录只保留阶段与校验值，不公开本机目录和原始私有日志。

3. **按更正保留本轮排序。**排名描述这 430 道任务保存结果的通过率顺序，耗时另列；不推广为产品在所有网站上的普遍强弱，也不称为完成缺失的来源前后认证。规则选取预期稳定的文字、正文和结构，作者判断短期变化风险较低，而逐次前后核验的时间成本较高，因此保留本轮排序，同时如实保留核验缺口；这不能证明所有页面当时都没有变化。此次没有为保留排名重跑。

4. **采纳参数重复编写的维护建议，做了现有实现内的整理。**固定原生请求由 provider 自己的纯参数生成函数供事前冻结和实际调用共同使用，路线检查只负责标准化、记录和比较；HTTP、CLI 和 JSONL 均覆盖。对实际传输参数保留一致性检查。未借此更换历史接口、参数或方法版本；模拟传输测试覆盖各 HTTP 方法及网页、PDF、图片、视频和文件输入。

验证：核心修改提交 c2490db3 的本地整套 make ci 通过，Python 为 5522 项通过、54 项跳过及 2059 个子测试通过，界面、原生适配器和四组安装包试装也通过。最终超时文件补充修复的相关 178 项测试及 998 个子测试通过。最终提交 9eb9d968 的 GitHub 主测试和 Python 3.12/3.13/3.14 CLI 全部通过。两份新增核对记录均已匿名下载，HTTP 200，大小和 SHA-256 与 Git 中绑定一致。

仍保留的限制：历史来源前后全量核验缺失；19 条超时没有完整的事前冻结调用收据，其中 7 条 worker 任务的网页网络阶段仍不能确认。这些限制不以新日志检查冒充已消除，也不改变原有分数。报告成绩和保存输入保持原样，当前排行榜通过率标绿加粗的展示修改一并提交。

[lanyue-llk]

最新版还剩一个会实质改判的缺口：原生来源校验没有覆盖 title 和 final_url。

当前 SCORE_ANSWER_FIELDS 只包含 links/images/videos/media/extras，require_native_answer_projection() 的参数也只有正文、元数据、原生响应和文件。可是 score_attempt() 随后会：

• 把 title 拼入可评分文字，参与必需事实、禁止项等正文判定；
• 用 final_url 作为相对链接和资源的解析基址。

我在当前提交上做了两个最小反例，二者都通过现有原生投影检查并造成假通过：

1. 保留的原生响应是 {"content":""}，评分正文也是空串，只额外传入 title="SECRET"。任务要求事实 SECRET，结果 content_pass=True。
2. 原生正文只有 ![asset](/asset.png)，任务请求地址属于 wrong.example.test，只额外传入 final_url="https://good.example.test/page"。预期资源是 https://good.example.test/asset.png，结果 resource_pass=True。

这两个值都没有经过 require_native_answer_projection()，因此适配器仍可在解析后改写会参与评分的输入。新上传的字段审计写的是“全部可计分字段”，但其范围实际没有包含这两项，所以 mismatch_count: 0 还不能证明评分输入全部来自保留的原生结果。

最小修复不需要再加一套框架：把 title 和 final_url 纳入现有的统一来源合同。title 应由保留响应中的声明字段或可重放转换得到；final_url 应由原生响应或传输收据中的实际响应地址证明，确实没有返回地址时才使用已声明的请求地址回退。评分前统一比对，不能按 provider 或 case 加例外。

请补上面两条反例及对应正例，并把当前 4300 条保存结果的离线字段审计扩到 title/final_url。若全部一致，不需要新增产品调用，也不需要重评分；若发现不一致，只重评分受影响的完整范围。

这轮其余几项我已复核：元数据/文件答案字段、失败阶段记录、超时文件计数、请求参数共用生成器都已按前一轮意见落地；相关定向测试通过。当前我只保留这一项阻塞意见。

[Maisiqi]

已按这条评论修复，问题成立：之前对正文和资源做了原生来源检查，却漏掉了参与评分的标题和最终网址。

这次把两项补进同一套检查：标题必须能从原始返回的相应字段取得；最终网址使用产品返回值、原调用日志或真实 HTTP 响应地址，只有缺少这些来源时才使用请求网址。相对图片和视频链接也必须按这个经过核对的网址解析。新调用保存时、读取保存结果时，以及离线纠正旧记录时，都会检查，避免只在某一个入口补漏。已增加“伪造标题/地址应拒绝”和“真实标题/跳转应保留”的成对测试。

实际检查了全部 4300 条保存结果：没有发现凭空添加的标题；发现两条 Cloudflare 资源结果保留了请求网址，而原始响应已经返回跳转后的网址，分别是 Unsplash 图片页和 VideoJS 页面。已按原始响应纠正这一调用路线的全部 16 条结果，并重新评分；原有 4 条 Moli 页面身份裁定随既有流程一同保留，因此本次记录了 20 条离线重评分。通过/失败没有变化，仍为 1966/4300，本轮排名也不变；没有新增真实调用。

公开交付保留原输入包，新增修正包，不覆盖原证据：

• 4300 条标题与网址来源核对记录
• 修正包：叠加在原输入包上恢复
• 原输入包及其他核对材料

两份新增文件均已用匿名下载核对完整文件大小和 SHA-256；原包加修正包恢复后，33352 个输入文件的校验值、修正链、复查记录和分数总账均通过。公开日志只保留这次判断实际使用的事件行，并与原日志分别绑定校验值；本机目录和敏感值不公开。

本轮没有把历史检查说成事前已经完成：72 条已知机器结论的证据复查、4228 条经依赖核对沿用意见，及 19 条超时缺少完整事前调用收据、历史来源未完成前后全量核验的限制，继续保留。

验证已完成：本地完整代码检查 5534 项通过、54 项跳过；最终提交 4384167a 的 GitHub 主测试及 Python 3.12/3.13/3.14 CLI 全部通过。新版中英文报告已重建，完整报告检查通过。此前已实际检查 136 个页面/语言/宽度/主题组合，以及成功与失败详情中的日志、键盘关闭和返回导航；此次重建后又核对了改动页的中英文说明。新增轮次英文说明漏写数字的问题已对齐，原始结果和评分未变。

[lanyue-llk]

复核当前 head 4384167a 后，上轮 title/final_url 的评分漏洞已经修好。我重新跑了相关测试，并用原来的两个反例验证：伪造标题和最终网址现在都会在评分前被拒绝。新审计也找到了两条历史地址差异，作者按完整 Cloudflare 资源路线重评分了 16 条结果，另保留 4 条既有身份复核；当前 4300 条上下文字段均可验证，判定仍是 1966/4300。

我没有再发现会改分或制造假通过的阻塞问题。还剩两处非阻塞收尾，建议在合并前顺手清掉：

1. 当前 Release 同时公开了 PR-51-native-context-correction-20261016.tar.xz 和 PR-51-native-context-correction-20261016-v2.tar.xz，但 profile 只绑定 v2。旧包没有任何当前引用，而且不带版本号的文件名反而更像默认下载项。请从当前交付页移除这份未绑定的中间包，只保留 profile 指向的正确包。历史调用和修订链已经由基线、前置结果及 receipt 保存，不需要用两个并列的“当前修正包”表达历史。
2. 文档规定 result_fields 属于投影 schema 2，但 project_native_answer() 仍同时接受 schema 1/2，tests/test_scoring.py 还构造了 schema_version: 1 加 result_fields 的混合声明。请让当前写入端拒绝这种混搭，并把该测试夹具改为 schema 2；历史 schema 1 继续只按原正文、资源和文件范围读取即可。不需要再增加 schema 3 或兼容别名。

验证记录：相关测试 236 项通过；唯一需要本机回环端口的测试在解除沙箱限制后单独通过。审计 JSON 的远端哈希与 profile 一致；44 MB v2 修正包完整下载后通过 SHA-256 和 xz 校验。430 份公开诊断视图中，330 份参与最终网址评分的视图全部重放一致，其余 100 份未参与该字段评分的日志地址也与审计记录一致。

除上述两个清理项外，我没有新的修改要求，也不建议再扩大实现或重跑 provider。

[Maisiqi]

这两项收尾建议都接受，已在 fa7d93a2 和当前交付页处理。

1. 已从 Release 移除未被当前 profile 引用的 PR-51-native-context-correction-20261016.tar.xz。先核对原 SHA-256 并保存了私有备份；当前公开页保留原始基线包和 profile 绑定的 v2 修正包，原调用、前置结果及修订收据均未删除。

2. 现有统一校验现在明确拒绝 schema 1 中出现 result_fields，空对象也拒绝。检查覆盖新结果保存、丢弃超时答案的保存路径、原生响应评分和保存记录读取；测试里的混合声明已改为 schema 2。合法 schema 1 继续只核对原正文、资源和文件，不把历史标题或网址当成经过该旧版本验证；合法 schema 2 仍检查标题及最终网址。没有增加新版本或兼容别名。

检查当前 4300 条记录，混合声明为 0；其中带声明的 27 条（11 条 schema 1、16 条 schema 2）已通过新代码的保存证据检查。本次只收紧无效声明，不改变有效输入的判分、调用参数或报告内容，不新增 provider 调用，不需要重新评分或重建报告。通过数仍为 1966/4300，历史核验和超时收据限制保持原样。

验证：相关测试 131 项、79 个子测试通过；本地完整 make ci 通过，其中 Python 测试 5539 项通过、54 项跳过、2063 个子测试通过，安装包验证也通过。最终提交 fa7d93a2 的 GitHub 主测试及 Python 3.12/3.13/3.14 CLI 全部通过。此次两个清理项均已完成，没有增加报告实现或重跑 provider。