[Snowson]

任务

• 任务书：无（设计评审方直接实现，目标态设计阶段二 P8）

• 目标终态：质量棘轮覆盖 Swift（native/ 下超过 500 行的文件数、函数体超过 60 行的函数数、嵌套超过 6 层的函数数，只降不升）；新增 harness/docs_check.py，已跟踪 Markdown 的相对链接断链即失败，未完成状态且超过 30 天未提交的文档只报告；两者进 bin/verify 默认档与完整档。

• 对应验收编号（docs/specs，新增条目写进规格验收表）：不挂规格编号；证据登记在 docs/specs/delivery-harness.md §6「熵治理（P8）」。

• 非目标：不引入新依赖；Swift 解析不处理 #if 分支与正则字面量；不核对锚点是否存在；不改 quality workflow。

• 待办（docs/plans/backlog.md）：关闭 B29

阈值取自 2026-09-28 native/ 的分布（332 个函数：函数体行数中位 6、P95 48、P99 88；嵌套 1–4 层占 92%），基线 swift_files_over_500 2、swift_long_functions 9、swift_deep_functions 13。largest_file_lines（只报告）随 --update 从 1693 写为当前的 1696。

首跑修正 4 处断链（文档修正，规则未放宽）：

• README.md、README.zh-CN.md 的 ../../releases 只在 GitHub 网页上可解析，改为完整的 Releases 链接；
• docs/plans/session-inbox.md 把本机 /opt/homebrew/... 路径写成了链接，改为文字说明；
• docs/review/2026-09-27-harness-audit.md 的计划模板已归档，链接改到 docs/templates/archive/plan.md。

陈旧状态：无（仓库内文档最近提交都在 30 天内）。

改动 harness/，按 R3 由用户批准。

证据

• CI 运行（当前 head）：见本 PR 的 build / harness 检查
• 风险等级与修复证据：见 harness job summary（机器生成）
• 单测：tests/test_harness_entropy.py（含 test_lengthened_swift_function_fails_ratchet、test_broken_relative_link_fails、test_anchors_external_links_and_code_are_not_reported、test_stale_unfinished_status_is_reported_without_failing）

需要人工验收的部分

• 阈值（60 行、6 层、500 行）是否合适，由用户在评审时判断；上调基线须改 harness/quality-baseline.json（R3）。

🤖 Generated with Claude Code

[Snowson]

独立评审（试行）：不通过

• 评审方：opencode（zai-coding-plan/glm-5.3）；设计方：未能判定；评审的提交：017d661f1980；用时 4.0 分钟
• 只读评审：只看任务书、PR 描述、diff 与证据包，不看执行过程；结论供用户参考，不替代用户审批。

结论：改动实质核验为绿（测试真实、基线一致、接线正确），但证据包以 head 为 base 生成、diff 为空、R3 被误判 R0，材料不可用且会导致护栏改动绕过用户批准，退回重生成证据后再审，且属 R3 仍需用户批准

严重度	位置	问题	修复要求
阻断	build/review/pack.md:1-5；build/review/diff.patch	证据包以 head 自身为 base（017d661 → 017d661，0 提交），diff.patch 为空，逐文件风险表为空，风险等级误判为 R0「门禁全绿即可自动合并」；实际改动 8e7f233..017d661 共 12 文件、5 个命中 harness/**，risk.py 判 R3 须用户批准。按此包路由会让护栏改动绕过用户批准自动合并	显式以合并基点 8e7f233 重新生成 diff.patch 与 pack.md 后重审；并修正流程：PR 已合入 origin/main 后不得再用 --base origin/main 生成评审材料，review_pack 需回退到 head 的合并基点
严重	build/review/pr.md:25-27	PR「证据」声称 CI 运行与 harness job summary，材料中无任何对应输出，pack.md 自述「本地没有 verify 汇总」；改动含 bin/verify 与 verify.py 本身，按清单 X2/F7（看 run 链接不看描述）这些「通过」按未验证处理	补充当前 head 的 CI run 链接（build/harness job 输出）或本地 bin/verify --strict --full 完整输出到证据包后重审

[Snowson]

独立评审（试行）：需用户验收

• 评审方：opencode（zai-coding-plan/glm-5.3）；设计方：claude-code；评审的提交：017d661f1980；用时 5.7 分钟
• 只读评审：只看任务书、PR 描述、diff 与证据包，不看执行过程；结论供用户参考，不替代用户审批。

结论：改动与自述一致、接线完整、CI 与本地实测全部通过，无阻断缺陷；但 harness 改动属 R3 且已先于本评审合入 main，需用户确认批准记录与阈值后方可视为通过。

严重度	位置	问题	修复要求
一般	harness/quality.py:52	规范 §6 P8 行（docs/specs/delivery-harness.md:162）称「协议要求不算函数」，但协议中的计算属性要求 var name: String { get } 被 swift_functions 实际计为函数（实测返回 ('name', 2, 1, 1)），测试只断言了 func 要求不计；对三项棘轮指标无实际影响（此类函数体恒为 1 行）。	二选一：把 delivery-harness.md §6 P8 的表述改为「协议的 func 要求不算函数」，或让 var 声明同样排除协议上下文并在测试中补断言。
一般	harness/quality.py:14	strip_swift 对字符串插值内嵌字符串字面量（如 "("x")"）会提前终止字符串并把同行剩余内容当作字符串吞掉，导致同行大括号丢失；该限制未与 #if 分支、正则字面量一起列入声明的非目标。native/ 现有代码无此模式，当前基线稳定，属未来代码的潜在坑。	在 quality.py 文档字符串与 delivery-harness.md §6 P8 的限制清单中补上该已知限制，或让普通字符串内的 ( 跳过一层嵌套引号，并补一个对应用例。
一般	origin/main（合并提交 e163a96）	origin/main 已通过「Merge pull request #62」包含本 PR（其后 #63 又合并 main 解决冲突），而 harness/** 按 R3 须用户批准后合并，材料中没有批准记录可确认批准先于合并。	由用户确认 PR #62 的合并发生在其批准之后；若未经批准，评估回滚或补记批准。
一般	harness/quality-baseline.json	阈值（Swift 函数 60 行、嵌套 6 层、文件 500 行、文档 30 天）是否合适属机器判不了的判断，PR 已声明留给用户；上调基线须直接改 quality-baseline.json（R3）。	用户在验收时确认各阈值；如需调整，修改 quality-baseline.json 后按 R3 重新批准。

[Snowson]

上一条独立评审（结论「不通过」）作废：它基于空的评审材料。原因是评审工具在 PR 已合并时按 main 的合并基点比较，得到空 diff（工具缺陷，已在 #63 修复）。以下一条评审为准。

关于该评审的第 3 条发现：本 PR 于 2026-09-28 14:59:10 UTC 由 SnowsonZ 批准，15:00:33 合并，批准先于合并。

[Snowson]

更正：上面第二条评论中「已在 #63 修复」不准确。#63 合并时漏掉了包含该修复的提交，修复实际随 #64 合并（2026-09-29）。