Claw Code 2.0 G012 最终发布门禁：release readiness 报告、校验脚本与 PR 审计快照全解

Claw Code 2.0 采用「Ultragoal 流式交付 + 最终发布门禁（G012）」的收尾模式：G001–G011 各流各自产出可验证证据，G012 则把这些证据汇聚成一份仓库本地、非破坏性的最终发布就绪报告。本文以 docs/g012-final-release-readiness-report.md 为主体，完整拆解报告中的 7 项门禁结论、G001–G012 流证据索引、17 个 roadmap PR 的逐条处置决定，并深入到 scripts/validate_cc2_board.py、.github/scripts/check_release_readiness.py 等校验脚本源码，说明每个「PASS」背后实际检查了什么，以及如何在当前仓库中复跑这套校验链。

1. G012 最终门禁是什么，这份报告在其中的位置

Claw Code 2.0 的交付计划被组织为 .omx/ultragoal 中一组「stream goal」（G001–G012），其中 G012 是最后的质量闸门：它要求 roadmap board 无未映射的可操作项、fmt/clippy/测试与聚焦契约套件通过、AI-slop 清理与代码审查留证，并产出最终的 alpha/beta/GA 就绪报告。.omx/ultragoal/goals.json 中 G012 的目标描述明确写着：最终完成被 docs/pr-issue-resolution-gate.md 的新鲜证据阻塞，直到所有 open PR 和 issue 都被分诊（triage）、正确的 PR 被合并、可解决的正确 issue 被修复或关闭。

G012 由多个 worker 分工执行：worker-2 负责质量门禁分类（W2），worker-3 负责 PR 对账（W3），worker-4 负责 issue 对账（W4），而本报告是 worker-1 的 roadmap/board 审计与发布就绪证据图（evidence map）。报告开头强调两点设计约束：

1. repo-local 且非破坏性：报告只引用 .omx/ultragoal 的证据，不修改 leader 拥有的 ultragoal 状态（goals.json、ledger.jsonl 为 leader-owned，worker 禁止变更）；
2. 不做远程写操作：不合并 PR、不关闭 W3/W4 负责的 issue，只提供这些 lane 可以参考的新鲜 roadmap/board/readiness 审计。

报告基线快照为 2026-05-15T02:59:29Z 的 origin/main / HEAD 2e93264919f38835410668ff6ca588606bc629f0。这一点很重要：报告中所有数字（729 条 board 项、51 个 open PR、1000 条 issue 等）都是该快照时刻的观测值，不是仓库当前状态（见第 5 节快照口径说明）。

2. 发布就绪总览：7 项门禁及其证据

报告的核心是一张 release readiness summary 表，共 7 项检查，全部 PASS（其中 PR/issue 快照项带限定条件）。下表完整继承报告原文，并把每项的检查命令落到可执行的仓库路径：

门禁	证据	结果
Ultragoal 流完成度	.omx/ultragoal/goals.json 显示该快照下 G001–G011 全部 complete、G012 仍 pending。	发布前流完成度 PASS；G012 本身仍为活动门禁。
Roadmap board 覆盖度	python3 scripts/validate_cc2_board.py → PASS cc2 board validation；729 条 board 项；124/124 个 ROADMAP 标题映射；542/542 个 ROADMAP 动作映射。	PASS
Issue/parity 接收覆盖度	python3 .omx/cc2/validate_issue_parity_intake.py → PASS issue/parity intake: 19 issue rows, 9 parity rows。	PASS
发布文档/就绪脚本	python3 .github/scripts/check_release_readiness.py → release-readiness check passed。	PASS
文档单一事实源	python3 .github/scripts/check_doc_source_of_truth.py → doc source-of-truth check passed。	PASS
新鲜 open PR 快照	gh pr list --state open --limit 1000 --json number,title,state,updatedAt,url,isDraft,mergeable → 51 条 open PR 记录；最新为 #3040。	快照捕获 PASS；对账/行动归 W3。
新鲜 open issue 快照	gh issue list --state open --limit 1000 --json number,title,state,updatedAt,url,labels → 1000 条 open issue 记录；最新返回 #3036。	快照捕获 PASS（带 limit 限定）；对账/行动归 W4。

逐项展开说明各门禁的验证逻辑：

2.1 Roadmap board 校验：validate_cc2_board.py 到底查了什么

board 覆盖度是 G012 的第一道硬门禁，其实现是 scripts/validate_cc2_board.py。从源码看，它执行四类检查：

1. 条目 schema 完整性：.omx/cc2/board.json 的每个 item 必须包含 9 个必填字段——id、title、source_anchor、source_type、release_bucket、status、dependencies、verification_required、deferral_rationale；id 不允许重复；dependencies 必须是列表。
2. 状态机合法性：status 必须落在固定的 8 值集合内：context、active、open、done_verify、stale_done、superseded、deferred_with_rationale、rejected_not_claw。
3. ROADMAP.md 标题全覆盖：脚本用正则 ^#{1,6}\s+ 扫出 ROADMAP.md 的全部 Markdown 标题行号，再与 board 中 source_type == "roadmap_heading" 条目的 source_line 对账——既不允许有未映射标题（unmapped），也不允许一个标题被映射到多个条目（duplicate）。
4. coverage 计数一致性：board 内嵌的 coverage.roadmap_headings_total/mapped 必须与实时扫描结果一致，防止「改板不刷 coverage」。

全部通过后输出报告里引用的那行 PASS cc2 board validation，并打印 items 数与 ROADMAP headings mapped、ROADMAP actions mapped 两个比例。快照时刻的实测结果为 729 项、124/124 标题、542/542 动作。当前仓库的 .omx/cc2/board.json 已随 ROADMAP 演进更新为 732 项、127/127 标题（新增的 3 个 Pinpoint 标题对应 G013 目标），脚本逻辑不变。

2.2 Issue/parity 接收校验：19 行 issue 是怎么被锁定的

.omx/cc2/validate_issue_parity_intake.py 校验 .omx/cc2/issue-parity-intake.json（schema 为 cc2.issue_parity_intake.v1，owner 为 worker-2，服务于 G001 stream-0 board 集成）。其规则从源码可直接读出：

• 必须恰好覆盖一组固定编号的 issue：3028–3038 共 11 个，加上 {3007, 3006, 3005, 3003, 2997, 3023, 3004} 8 个，合计 19 个必填 issue 行——这就是报告里 19 issue rows 的由来；缺少或多出一行都会 FAIL；
• 所有行（issue 行 + parity 行）的 source_anchor、source_type、release_bucket、lifecycle_status、dependencies、verification_required 不得为空；
• release_bucket 只能取 alpha_blocker / beta_adoption / ga_ecosystem / post_2_0_research；lifecycle_status 复用与 board 相同的 8 值状态集合；
• 状态为 deferred_with_rationale 的行必须携带非空的 deferral_rationale（防「无理由延期」）；
• parity_rows 数量不得低于 coverage 中声明的最小值，报告中该值为 9。

2.3 发布文档就绪检查：check_release_readiness.py

.github/scripts/check_release_readiness.py 被刻意设计为零依赖（仅标准库），以便在开发机、Windows CI 与最小化 release job 上都能跑。它覆盖三类回归高发点：

1. 必备策略文件存在性：LICENSE、CONTRIBUTING.md、SECURITY.md、SUPPORT.md、CODE_OF_CONDUCT.md 缺一不可；
2. 本地 Markdown 链接与图片锚点解析：对 README/USAGE/PARITY/PHILOSOPHY/ROADMAP/CONTRIBUTING/SECURITY/SUPPORT/CODE_OF_CONDUCT、docs/ 目录以及 rust/README.md、rust/USAGE.md、rust/MOCK_PARITY_HARNESS.md 逐文件提取 Markdown 与 HTML 链接，检查目标文件存在、未逃逸仓库根目录，且 .md 目标中的 #anchor 能按 GitHub 锚点规则（小写化、去符号、空格转连字符）在目标文件标题中找到对应锚点；
3. 废弃安装命令拦截：扫描所有 bash/sh/shell/zsh/powershell 代码块，若出现 cargo install claw-code 即报错，强制文档改用从源码构建的安装说明。

2.4 文档单一事实源检查：check_doc_source_of_truth.py

.github/scripts/check_doc_source_of_truth.py 针对的是「项目迁移/更名后的过期引用」这类回归。它对根目录 6 个核心文档（README、USAGE、PARITY、PHILOSOPHY、ROADMAP、.github/FUNDING.yml）加上 docs/ 全量 Markdown，逐条匹配一组 FORBIDDEN 正则，例如：旧 GitHub 仓库路径 github.com/Yeachan-Heo/claw-code（需替换为 ultraworkers 新仓库）、另一个过期仓库路径、过期 Discord 邀请链接、旧 star-history 嵌入、旧 hero 图片 assets/clawd-hero.jpeg（应指向当前的 assets/claw-hero.jpeg）、已废弃的 assets/instructkr.png 引用。任何命中都带文件与行号报 FAIL。

2.5 PR/issue 新鲜快照：命令、口径与归属

报告用 GitHub CLI 拉取两个新鲜快照作为门禁输入：

gh pr list --state open --limit 1000 --json number,title,state,updatedAt,url,isDraft,mergeable
gh issue list --state open --limit 1000 --json number,title,state,updatedAt,url,labels

结果：51 条 open PR 记录（最新 #3040）、1000 条 open issue 记录（最新返回 #3036）。两项都标注「PASS for snapshot capture」，但带明确限定：

• PR 快照的对账与行动归 W3（worker-3）；
• issue 快照命中了 --limit 1000 上限，因此结论只能写成「open issue 至少 1000 条」，除非拿到更高 limit 或分页导出——这个 caveat 同样写在 docs/pr-issue-resolution-gate.md 中；
• 这些命令输出只是证据输入而非最终证明，最终门禁必须刷新快照并比对 delta 后才允许完成声明（gate 文档原话："The final gate must refresh them and compare deltas before any completion claim"）。

3. 流证据索引：G001–G012 各自的完成证据落点

报告第二张表把每个 stream goal 映射到其主证据文件，这也是 G012 汇聚「证据图」的骨架：

Goal	快照内 ultragoal 状态	主跟踪证据
G001 Stream 0 board	complete	.omx/cc2/board.json、.omx/cc2/board.md、scripts/validate_cc2_board.py
G002 security	complete	docs/g002-security-verification-map.md
G003 boot/session	complete	docs/g003-boot-session-verification-map.md
G004 events/reports	complete	docs/g004-events-reports-verification-map.md、docs/g004-events-reports-contract.md
G005 branch/recovery	complete	docs/g005-branch-recovery-verification-map.md
G006 task/policy/board	complete	docs/g006-task-policy-board-verification-map.md
G007 plugin/MCP	complete	docs/g007-plugin-mcp-verification-map.md、docs/g007-mcp-lifecycle-mapping.md
G008 provider compatibility	complete	docs/local-openai-compatible-providers.md + ultragoal 质量门禁产物
G009 Windows/docs/release	complete	docs/g009-windows-docs-release-verification-map.md、docs/windows-install-release.md
G010 session hygiene	complete	docs/g010-session-hygiene-verification-map.md、docs/g010-clone-disambiguation-metadata.md
G011 ecosystem/ops/UX	complete	docs/g011-ecosystem-ops-ux-verification-map.md、docs/g011-acp-json-rpc-status-contract.md、docs/pr-issue-resolution-gate.md
G012 final gate	pending（快照内）	本报告 + W2/W3/W4 的最终门禁报告

这套索引的可信度来自 ultragoal 的持久化审计链：每个 goal 在 goals.json 里有 status、completedAt 与一段叙述式 evidence（记录了团队 ID、任务完成比、leader 验证过的命令清单），.omx/ultragoal/ledger.jsonl 则以 JSONL 追加日志记录 goal_started / goal_completed / steering_accepted 等事件。例如 G002 的 evidence 字段完整列出了 leader 复验通过的命令链（cargo fmt --all -- --check、cargo test -p tools path_scope、python3 -m pytest tests/test_security_scope.py 等），G012 的 evidence 则指向最终门禁日志、commit 04c2abb 与三份产出文档（docs/pr-triage-g012-final-gate.json、docs/pr-issue-resolution-gate.md 和本报告）。

4. Roadmap PR 审计快照：17 个 PR 的逐条处置

docs/roadmap-pr-goals.md 列出了 17 个 roadmap/product-fit PR，原则是「只在其正确、可解决、安全时才合并」。G012 的新鲜快照显示这 17 个 PR 全部仍处于 open 状态；其中 16 个 roadmap 文档 PR 为 CONFLICTING，因此不构成该 worker lane 的直接合并候选；#2824 为 MERGEABLE，但它属于显式的 product-fit 评审而非 roadmap 直接合并候选。

以下为报告原文的完整处置表（Worker-1 final-gate disposition）：

PR	标题	Mergeable	Draft	更新时间	Worker-1 最终门禁处置
#2824	docs: personal assistant roadmap	MERGEABLE	false	2026-04-28T13:05:03Z	交给 product-fit/leader 决策；不作为 CC2 发布门禁证据自动合并。
#2839	docs(roadmap): add #330 — resume mode stats/cost always zero	CONFLICTING	false	2026-04-29T12:36:19Z	未解决冲突不可合并；已映射进已完成的 session/status 流。
#2841	docs(roadmap): add #332 — doctor json missing top-level status field	CONFLICTING	false	2026-04-29T13:04:12Z	未解决冲突不可合并；已映射进已完成的 boot/doctor 流。
#2842	docs(roadmap): add #334 — version json omits build_date and uses short sha only	CONFLICTING	false	2026-04-29T13:35:01Z	未解决冲突不可合并；发布就绪文档/脚本在 HEAD 上通过。
#2844	docs(roadmap): add #336 — session subcommand resume inconsistency and type/kind error mismatch	CONFLICTING	false	2026-04-29T14:03:19Z	未解决冲突不可合并；已映射进已完成的 session hygiene 流。
#2846	docs(roadmap): add #331 — export silently overwrites on repeated invocations	CONFLICTING	false	2026-04-29T13:02:02Z	未解决冲突不可合并；若仍有必要则留给 W3/leader 分诊。
#2848	docs(roadmap): add #333 — no in-session settings inspect command	CONFLICTING	false	2026-04-29T13:32:01Z	未解决冲突不可合并；若仍有必要则留给 W3/leader 分诊。
#2850	docs(roadmap): add #335 — session list omits created_at_ms field	CONFLICTING	false	2026-04-29T14:01:29Z	未解决冲突不可合并；已映射进已完成的 session metadata 流。
#2858	docs(roadmap): add #343 — session subcommand resume-safety inconsistently enforced	CONFLICTING	false	2026-04-29T16:02:45Z	未解决冲突不可合并；已映射进已完成的 session/recovery 流。
#2862	docs(roadmap): add #342 — status json omits active session ID, workspace counters ambiguous	CONFLICTING	false	2026-04-29T19:04:31Z	未解决冲突不可合并；已映射进已完成的 status/session 流。
#2864	docs(roadmap): add #364 — /cost returns no cost_usd; identical to /stats	CONFLICTING	false	2026-04-29T22:32:52Z	未解决冲突不可合并；已映射进已完成的 UX/status 契约评审。
#2865	docs(roadmap): add #362 — doctor auth false-positive: misses CLI session tokens	CONFLICTING	false	2026-04-29T22:06:28Z	未解决冲突不可合并；已映射进已完成的 doctor/auth 流工作。
#2867	docs(roadmap): add #368 — export always appends .txt; response.file reflects mangled path	CONFLICTING	false	2026-04-29T23:35:35Z	未解决冲突不可合并；若仍有必要则留给 W3/leader 分诊。
#2868	docs(roadmap): add #356 — session list title always null; no rename command	CONFLICTING	false	2026-04-29T20:36:43Z	未解决冲突不可合并；已映射进已完成的 session identity 流。
#2869	docs(roadmap): add #358 — history entries missing role field, no pagination	CONFLICTING	false	2026-04-29T21:02:55Z	未解决冲突不可合并；已映射进已完成的 session/history 评审。
#2872	docs(roadmap): add #360 — /tokens, /stats, /cost identical output; no context-window or cost_usd	CONFLICTING	false	2026-04-29T21:32:57Z	未解决冲突不可合并；已映射进已完成的 UX/status 契约评审。
#2876	docs(roadmap): add #354 — /cwd suggests itself in did-you-mean; self-referential loop	CONFLICTING	false	2026-04-29T20:01:22Z	未解决冲突不可合并；已映射进已完成的命令 UX 评审。

这份处置表与 W3 的机器可读 PR 账本 docs/pr-triage-g012-final-gate.json 相互印证：后者由 gh pr list --state open --limit 100 --json ... 加逐 PR gh pr view 捕获（2026-05-15T02:58:00Z），summary 记录 51 个 open PR、worker-3 合并 0 个、延迟 51 个，其中 32 个处于 CONFLICTING/DIRTY 状态、19 个 MERGEABLE 但被 GitHub 报为 UNSTABLE 且无新鲜 check-rollup 证据，docs-only 候选评审 PR #3021 与 #2824 被推迟到内容/事实源评审完成为止。这正体现了 docs/pr-issue-resolution-gate.md 中的策略：只合并正确、安全、无冲突、有证据的 PR；不安全/错误/冲突/未验证的高风险 PR 一律延迟，自动化 lane 可以建议标签、评论、延期/关闭理由或合并候选，但未经 maintainer 授权不得在远端合并或关闭。

与这些 PR 配套的是 gate 文档定义的 anti-slop 分诊分类（actionable-bug、actionable-docs、actionable-feature、duplicate、spam-or-promotion、generated-slop-or-hallucinated、unsafe-or-security-sensitive、not-reproducible-yet、externally-blocked），模板落在 .github/ISSUE_TEMPLATE/ 与 .github/PULL_REQUEST_TEMPLATE.md，方法论在 docs/anti-slop-triage.md。

5. Worker-1 停止条件与 G012 的整体完成判定

报告最后一节给出了明确的停止条件（stop condition）：

• Worker-1 层面：当本报告被提交且其检查通过时，worker-1 的 release-readiness lane 即告完成；
• G012 整体层面：仍需 leader 整合 W2 的质量门禁分类与 W3/W4 的 PR/issue 对账证据，才能宣布完成；
• 证据边界：该报告不声称远端 PR/issue 积压已解决，它提供的是这些 lane 可引用的新鲜 roadmap/board/readiness 审计。

这个「各 lane 只交证据、leader 统一收口」的判定模型，与 docs/pr-issue-resolution-gate.md 中「最终完成审计必须使用新鲜 GitHub 快照而非规划快照」「最终报告必须含逐 PR 的 merge/reject/defer 行、理由与验证引用」的要求是一致的。

需要说明的快照口径：本报告定格于 2026-05-15 的 HEAD 2e9326...。仓库此后继续演进——从 ledger.jsonl 可见 2026-05-25 有一条 steering_accepted 记录：reset 到 origin/main 后 validate_cc2_board.py 报出 3 个未映射 ROADMAP 标题（7528/7538/7548 行，对应新追加的 Pinpoints #693–#695），由此启动了 G013 目标；当前 .omx/cc2/board.json 的 coverage 也已更新为 127/127 标题、542/542 动作、732 条 board 项。这恰好展示了该校验链的价值：roadmap 一旦新增条目，board 校验会立即失败，强制证据图与 ROADMAP 保持同步，门禁结论永远附着于具体快照而非「一次通过永久有效」。

6. 复跑这套发布就绪校验链

在具备 Python 3 与（可选）已登录 gh CLI 的环境里，可以在本仓库中依次复跑报告引用的全部本地检查（gh 相关命令需要可访问 GitHub 的凭据，且属于只读查询）：

# 1. Board 覆盖度（默认读取 .omx/cc2/board.json，也可用 --board 指定）
python3 scripts/validate_cc2_board.py
# 预期输出：PASS cc2 board validation
#   - items: <条目数>
#   - ROADMAP headings mapped: <mapped>/<total>
#   - ROADMAP actions mapped: <mapped>/<total>

# 2. Issue/parity 接收完整性
python3 .omx/cc2/validate_issue_parity_intake.py
# 预期输出：PASS issue/parity intake: 19 issue rows, 9 parity rows

# 3. 发布文档就绪（策略文件 + 本地链接/锚点 + 废弃安装命令）
python3 .github/scripts/check_release_readiness.py
# 预期输出：release-readiness check passed

# 4. 文档单一事实源（过期仓库路径/资源引用）
python3 .github/scripts/check_doc_source_of_truth.py
# 预期输出：doc source-of-truth check passed

# 5. 新鲜 PR/issue 快照（只读；需要 gh auth login）
gh pr list --state open --limit 1000 --json number,title,state,updatedAt,url,isDraft,mergeable
gh issue list --state open --limit 1000 --json number,title,state,updatedAt,url,labels

前 4 项是纯本地、确定性检查，失败时都会以非零退出码和逐条错误行号定位问题（如 item N missing required fields、missing local link target、deprecated "cargo install claw-code" appears in an executable command block），这正是报告能把每项门禁写成可复核证据的前提。

7. 小结：从「流完成」到「发布就绪」的证据链

G012 报告展示了 Claw Code 2.0 收尾阶段的完整证据链结构：

1. 流级证据：G001–G011 各自沉淀 verification map 文档、质量门禁 JSON 与 ultragoal 状态记录；
2. 汇聚级证据：G012 报告以快照 HEAD 为基准，把 board 覆盖度、intake 完整性、文档就绪、文档事实源、PR/issue 快照 7 项检查压成一张可逐行复核的门禁表；
3. 处置级证据：17 个 roadmap PR 逐条给出 mergeable 状态与 worker-1 处置决定，并与 W3 的 PR 账本 JSON 对齐；
4. 判定级规则：worker-1 的停止条件、leader 收口条件、以及「新鲜快照 + delta 比对」才允许完成声明的硬要求。

对读者而言，这份报告的参考价值不在于某一个 PASS 结果，而在于它示范了如何用「仓库本地脚本 + 机器可读账本 + 明确 lane 归属」把一次大型版本的发布门禁变成可审计、可复跑、可增量更新的工程实践——每一个结论都能顺着文件路径追到源码与原始命令输出。