Claw Code 2.0 标准执行看板解析：.omx/cc2/board.md 的数据模型、双维状态体系与生成校验管线

.omx/cc2/board.md 是 claw-code 仓库中 Claw Code 2.0（下称 CC2）的"标准执行看板"：它把 8000 余行的 ROADMAP.md（127 个标题 + 542 条有序动作）、issue 收件箱与 opencode/codex 对标元数据，统一收敛成 732 条结构一致、可被机器逐条解析的看板条目。读完本文，你将掌握看板的 schema 与证据冻结机制、lifecycle × release bucket 双维坐标系、lane 归属与验证方法语义，以及从 generate_cc2_board.py 到 render_board_md.py --check 的完整生成、校验与同步保证管线——这套机制正是该项目"clawable（可被 Agent 驱动）"工程理念在任务管理层面的直接落地。

看板定位：一份机器可读的 732 条工作契约

看板文件头声明了三个关键元信息：

• 生成时间：2026-05-25T04:30:33+00:00，即该文件是某一时刻的快照而非实时视图；
• Schema 版本：cc2.board.v1，与 board.json 顶层 schema_version 字段一致；
• Ultragoal 变更策略：.omx/ultragoal 由 leader（主 Agent）独占维护，渲染任务不得修改它。对应 board.json 中 generation_policy.ultragoal_mutation = "forbidden"，表明看板生成被明确禁止触碰目标状态文件。

看板总规模为 732 条 canonical board items。项目背景见 ROADMAP.md 开篇：claw-code 的首要用户不是盯着终端的人，而是"通过 hooks、plugins、sessions 和 channel events 接入的 claws"，因此路线图本身就要求状态与失败模式"machine-readable"。看板正是这一要求在执行层的物化——每条工作项都是带来源锚点、生命周期、发布桶和验证方法的独立记录，而不是散落在长文叙述中的段落。

证据冻结（Evidence Freeze）：快照的可追溯性

看板开篇的 Evidence Freeze 表记录了三类证据源的冻结指纹，这是整套机制里最值得注意的设计——看板不是凭空整理出来的，而是从哈希锚定的源文件推导出来的：

Source	Frozen evidence
Roadmap	ROADMAP.md sha256 前缀 2aba3315e52f3079；127 个标题；542 条有序动作
Approved plan	.omx/plans/claw-code-2-0-adaptive-plan.md sha256 前缀 e7ef6faf23bfc16b
Research bundle	根目录 .omx/research；最新 open issues 30 条；issue 语料 1000 条；含 codex/opencode clone 元数据

这些字段并非手写，而是 generate_cc2_board.py 在 build_board() 中计算并写入 sources 节点的：sha256_prefix() 对 ROADMAP.md 与计划文件取字节级 SHA-256 并截取前 16 位（generate_cc2_board.py#L87-L88）。这意味着：

1. 任何人拿到 board.json 后，都能用哈希前缀核对"看板是从哪个版本的 ROADMAP 推导的"；
2. ROADMAP 一旦变化（哪怕改一个字符），下次重新生成时指纹必然不同，快照与源文件的对应关系不可伪造；
3. 冻结元数据同时记录 heading_count: 127 与 ordered_action_count: 542，与正文的覆盖门禁互相印证。

值得留意的一个细节：sources.research.root 记录的是构建机的绝对路径（/Users/bellman/.../.omx/research），说明该看板是维护者机器上生成后提交入库的快照；当前仓库内保留的是生成产物与工具链本身。

覆盖门禁：127/127 与 542/542 的完整性证明

Roadmap Coverage Summary 给出三条门禁，全部 PASS：

Coverage gate	Mapped	Total	Status
ROADMAP headings	127	127	PASS
ROADMAP ordered actions	542	542	PASS
Duplicate heading lines	0	0	PASS

"覆盖"的含义在 generation_policy.roadmap_coverage 中被定义为 "all markdown headings plus top-level ordered roadmap actions"——即 ROADMAP 里每一行 markdown 标题和每一条缩进 ≤4 空格的有序列表动作，都必须映射到至少一条看板条目，且不允许同一行被映射两次。生成端在 generate_cc2_board.py#L443-L446 计算 unmapped_heading_lines 与 duplicate_heading_lines；独立校验器 validate_cc2_board.py 则用正则 ^#{1,6}\s+ 重新扫一遍 ROADMAP.md 的全部标题行，与看板中 source_type == "roadmap_heading" 条目的 source_line 做集合差（validate_cc2_board.py#L71-L78），任何未映射行都会让校验直接 FAIL。渲染器 render_board_md.py 的 validate_board() 同样内建了这三条覆盖断言（render_board_md.py#L75-L84），形成"生成时、渲染时、独立校验时"三处一致的完整性证明。

条目数据模型：9 个必填字段与 ID 命名法

每条 board item 必须携带 9 个必填字段（render_board_md.py#L44-L54 与 validate_cc2_board.py#L10-L20 双处硬编码）：

字段	语义
id	全局唯一 ID，渲染为看板表第一列
title	条目标题（继承自 ROADMAP 标题/动作原文或 issue 标题）
source_anchor	来源锚点，如 ROADMAP.md:L1188 或 .omx/research/claw-issues.json#issue-3037
source_type	来源类型：roadmap_heading / roadmap_action / issue_theme / latest_open_issue / parity_repo_context
release_bucket	发布桶，见下文 7 桶枚举
lifecycle_status	生命周期状态，见下文 8 状态枚举
dependencies	依赖 lane/契约列表，可为空
verification_required	该条目要求的验证方法
deferral_rationale	延期/拒绝理由；deferred_with_rationale 状态为强制非空（render_board_md.py#L102-L103）

ID 命名法由 generate_cc2_board.py#L273 规定，分三个族：

• CC2-RM-H0001-<slug> / CC2-RM-A0051-<slug>：ROADMAP 标题（H）/有序动作（A），序号为全局递增，slug 由 slugify() 取标题前 40 字符；
• CC2-ISSUE-CLAW-OPEN-LATEST-3037 / CC2-ISSUE-CLAW-ISSUES-3012：issue 收件箱条目，后缀即 issue 编号；
• CC2-PARITY-OPENCODE-REPO-CONTEXT：opencode/codex 对标仓库元数据条目。

看板的明细表（Board Items by Stream）每行即按 ID | Title | Source | Bucket | Lifecycle | Verification | Dependencies | Deferral 八列展开，渲染器对 title 中的 | 做 \| 转义以保证表格不错位（render_board_md.py#L211-L223）。

双维坐标系：Lifecycle × Release Bucket

看板为每条条目同时标注生命周期（"现在处于什么阶段"）与发布桶（"属于哪个发布梯队"），两维正交。

生命周期枚举（8 态）

Lifecycle	Count	Meaning
active	73	当前 CC2 实现面上应保持可见的工作项
context	15	仅上下文/证据锚点，不是实现工作项
deferred_with_rationale	9	有意延期；条目内必须携带延期理由
done_verify	316	上游已标记完成，但保留下来以对照当前 CC2 行为做验证
open	285	可执行、未解决，需要实现或验收证据
rejected_not_claw	2	非 Claw Code 产品工作，明确排除
stale_done	31	历史上完成/已合并，但可能过时，作为发布证据前需重新核实新鲜度
superseded	1	已被更新条目取代，仅作追溯上下文保留

这 8 个状态不是自由文本，而是受控枚举：generation_policy.status_values 列出全部取值，渲染器会对任何枚举外的 lifecycle_status 报错（render_board_md.py#L98-L99）。状态如何从 ROADMAP 原文推断出来，由 status_for() 的启发式决定（generate_cc2_board.py#L192-L213）：标题含 done/fixed/verified/landed/green 等词判为 done_verify；再叠加 stale/no longer reproduces 则降级为 stale_done；含 deferred/post-2.0 判为 deferred_with_rationale；H1/H2 级的散文标题（如 Goal、Product Principles）默认判为 context，但以 Phase 开头的标题判为 active 工作容器。

发布桶枚举（7 桶）

Bucket	Count	Meaning
2.x_intake	30	Post-2.0 收件箱或后续候选，保留用于排序
alpha_blocker	243	在 alpha 级自主编码 lane 可信之前必须解决
beta_adoption	417	alpha 阻塞受控后，对更广 dogfood/采用重要
context	15	不可执行的路线图上下文
ga_ecosystem	22	成熟插件/MCP/Provider 生态所必需
post_2_0_research	3	研究导向条目，CC2 看板切片不要求
rejected_not_claw	2	显式非 Claw 拒绝桶

分桶逻辑在 release_bucket_for()（generate_cc2_board.py#L172-L189）：先按 category_for() 的关键词表把条目归入 security/windows_install/provider/sessions/plugin_mcp 等 13 个类别，再映射到桶——Phase 1–4、安全、worker、事件类全部压入 alpha_blocker，Windows/安装/provider/文档/会话类进 beta_adoption，插件 MCP 与 IDE/ACP 类进 ga_ecosystem。从分布看（417 条 beta_adoption、243 条 alpha_blocker），CC2 的当前重心清晰：alpha 阻塞项尚未清零，大量采用面打磨仍在队列中。

Lane 结构与来源构成

Stream 汇总

Stream / lane	Items	Active+open+verify	Lifecycle mix
Adoption overlay — user-visible parity and release polish	357	329	deferred_with_rationale 3, done_verify 237, open 92, rejected_not_claw 2, stale_done 23
Parity overlay — opencode/codex comparison context	20	16	context 2, deferred_with_rationale 1, done_verify 5, open 11, stale_done 1
Stream 0 — Governance, intake, and cross-cutting roadmap triage	221	198	active 6, context 13, deferred_with_rationale 4, done_verify 45, open 147, stale_done 5, superseded 1
Stream 1 — Worker boot and session control	17	16	active 8, deferred_with_rationale 1, done_verify 2, open 6
Stream 2 — Event/reporting contracts	73	73	active 45, done_verify 20, open 8
Stream 3 — Branch/test recovery	17	15	active 6, done_verify 2, open 7, stale_done 2
Stream 4 — Claws-first task execution	5	5	active 4, done_verify 1
Stream 5 — Plugin/MCP lifecycle	22	22	active 4, done_verify 4, open 14

lane 划分与 ROADMAP 的 Phase 1–5 一一对应（stream_1_worker_boot_session_control 对应 Phase 1 Reliable Worker Boot，依此类推），外加两个横切 overlay：adoption overlay 收纳 Windows 安装、provider 路由、文档采用类条目，parity overlay 收纳对标上下文。stream_for()（generate_cc2_board.py#L151-L169）按 "Phase N" 字面量 + 类别关键词双通道指派 lane，无法命中任何规则时落回 stream_0_governance 兜底。

Source-Type Mix

Source type	Items
roadmap_action	542
roadmap_heading	127
issue_theme	31
latest_open_issue	30
parity_repo_context	2

542 + 127 = 669 正好等于覆盖门禁的 mapped 数，另 63 条来自 issue 收件箱（30 条最新 open issue 全量入 2.x_intake 桶 + 31 条从 1000 条 issue 语料中按关键词抽样入 beta_adoption 桶，见 generate_cc2_board.py#L431-L441）和 2 条对标仓库元数据。

验证方法与依赖语义

每条条目还带两个机器可判定字段，它们决定了"这条工作怎么算完成"以及"谁先做"。

Verification（验证方法） 是与类别绑定的受控词汇，在 verification_for()（generate_cc2_board.py#L228-L248）中定义，例如：

验证方法	适用类别
worker_boot_state_machine_or_cli_json_contract_test	boot（Phase 1：worker 状态机 / CLI JSON 契约测试）
schema_golden_fixture_or_consumer_contract_test	event_report（Phase 2：事件 schema golden fixture）
git_fixture_or_recovery_recipe_test	branch_recovery（Phase 3：git fixture / 恢复配方测试）
plugin_mcp_lifecycle_contract_test	plugin_mcp（Phase 5：插件/MCP 生命周期契约）
provider_routing_contract_test	provider（provider 路由契约）
install_matrix_or_cross_platform_smoke	windows_install（跨平台安装矩阵冒烟）
docs_snapshot_or_help_output_check	docs_license（文档快照 / help 输出检查）
verify_existing_evidence_and_regression_guard	所有 done_verify / stale_done 条目
none_context_only	context 条目

值得注意的是 done_verify 与 stale_done 共享同一验证方法：已完成的工作不作为免检项，而是要求"保留现有证据 + 回归防护"来重新对照当前行为——这与 lifecycle 语义表中"retained for verification against current CC2 behavior"的定义一致，也是 done_verify 数量高达 316 的原因。

Dependencies（依赖） 表达的是 lane 级先决关系而非文件级依赖，例如 Phase 2 的全部条目依赖 stream_1_worker_boot_session_control，Windows/文档类条目依赖 adoption_overlay_triage 分诊，stable_alpha_contracts 是 Zed/ACP/桌面类条目的共同前置。issue 收件箱条目则统一依赖 roadmap_board_triage，其 deferral 理由统一写明 "admitted only when it matches freeze/admission rules; otherwise remains 2.x_intake"——最新 issue 不是自动开工，而是排队候审。

读一条真实看板条目：以 CC2-RM-A0051 为例

看板中体量最大的 adoption overlay lane 收纳了大量来自真实 dogfood 的"pinpoint"条目。以 CC2-RM-A0051-dev-rust-cargo-test-p-rusty-claude-cli-r（锚点 ROADMAP.md:L1110）为例，其标题即完整问题陈述：

dev/rust cargo test -p rusty-claude-cli reads host ~/.claude/plugins/installed/ from real $HOME and fails parse-time on any half-installed user plugin

条目正文记录了完整的证据链：11 个确定性失败的测试名、根因的两层结构（parse_args 急切遍历宿主插件目录 + 测试 harness 未做 $HOME 隔离）、以及"backport env_lock 隔离模式 + 解耦 argv 解析与文件系统校验"的双部分修复动作。它的 bucket 是 beta_adoption、lifecycle 是 done_verify、verification 是 verify_existing_evidence_and_regression_guard——即该问题已在 main 分支修复，但要求后续以回归测试持续锁住。再看收件箱侧的 CC2-ISSUE-CLAW-OPEN-LATEST-3037（"docs: clarify Claw Code positioning as multi-provider Claude-Code-shaped runtime"），其 source anchor 是 .omx/research/claw-open-latest.json#issue-3037，lifecycle 为 open、verification 为 issue_acceptance_repro_or_triage_decision，deferral 列注明"Latest issue intake is admitted only when it matches freeze/admission rules; otherwise remains 2.x_intake"。两类条目并置在同一张表里，正是看板"单一表格承载全部工作形态"的设计意图：ROADMAP 叙事、issue 流量、对标上下文共用同一 schema、同一门禁、同一验证词汇。

生成管线：generate → render → validate 三段式

1. 生成：scripts/generate_cc2_board.py

parse_roadmap() 用两条正则分别捕获 #{1,6} 标题与缩进 ≤4 空格的有序列表动作（标题保留层级栈路径，动作额外记录序号），随后对每条记录执行 category_for → stream_for → release_bucket_for → status_for → verification_for → dependencies_for 的纯函数派生，构造带 source_anchor（ROADMAP.md:L<行号>）、source_context（层级路径）的完整条目（generate_cc2_board.py#L114-L140）。issue 与 parity 条目由 issue_item() / repo_context_item() 以同样字段集构造。build_board() 收尾时组装 schema_version、generated_at、generation_policy、sources、coverage、summary、items 七个顶层节点，并在写出前就内联执行一次 validate_board()，失败即拒绝产出（generate_cc2_board.py#L448-L496）。

2. 渲染：.omx/cc2/render_board_md.py

渲染器从 board.json 重新生成 board.md，结构与前文各表一一对应：Evidence Freeze → Coverage → Lifecycle → Bucket → Stream Summaries → Source-Type Mix → 按 lane 排序的明细表。所有计数（by_lane / by_status / by_bucket / by_source）都是现场用 Counter 从 items 重算的，不存在"正文数字与数据不符"的可能。它还提供 --check 模式：重渲染后与磁盘上的 board.md 做全量文本比对，不一致即返回 1（render_board_md.py#L247-L257），使 board.md 成为"必须与 board.json 同步"的受管产物而非手工文档。

3. 校验：scripts/validate_cc2_board.py

独立校验器从磁盘上的 board.json 出发，逐条检查必填字段、ID 唯一性、status 枚举、dependencies 类型，然后独立重扫 ROADMAP.md 做标题行集合差与重复检测，并把 coverage 节点与实测值交叉核对，任一不符输出 FAIL cc2 board validation 及明细（validate_cc2_board.py#L58-L89）。

4. 统一入口：scripts/cc2_board.py

该 wrapper 把三个工具收拢为两个子命令，确保所有入口执行同一套 schema（其 docstring 明确说明 "This script intentionally delegates to the richer G001 board generator, validator, and Markdown renderer so all entrypoints enforce the same schema"）：

• python3 scripts/cc2_board.py generate：先跑生成器，再用渲染器产出 board.md；
• python3 scripts/cc2_board.py validate：串行执行 validate_cc2_board.py 与 render_board_md.py --check，两者都通过才打印 CC2 board validation PASS: ... canonical and in sync（cc2_board.py#L53-L61）。

从源码结构看，这套三段式把"内容正确性（validator）"与"产物同步性（renderer --check）"分离成两类独立断言，任何一类被绕过都会让 validate 失败——看板因此同时是一份数据（board.json，机器消费）和一份视图（board.md，人读），且二者被工具强制锁在同一状态。

与项目其余部分的衔接

• 上游证据：ROADMAP.md 开篇定义了 "clawable" 的七项判据（deterministic to start / machine-readable state / recoverable without a human / branch-aware / plugin-MCP-aware / event-first / autonomous next-step）与七个痛点，Phase 1–5 的阶段划分正是看板 stream 1–5 的来源；ROADMAP 的 127 个标题与 542 条有序动作是看板 669 条 roadmap 系条目的唯一上游。
• 目标状态隔离：看板头部与 generation_policy 双重复述 .omx/ultragoal 不可被渲染任务修改；该目录在仓库中确实独立存在（goals.json、ledger.jsonl 等），形成"目标账本"与"工作看板"的权限边界。
• 消费方：仓库文档中的 g002–g013 系列验证地图（如 g012-final-release-readiness-report.md）描述的是围绕这批 alpha/beta 桶条目做验收验证的流程，看板则提供了它们逐条引用的稳定 ID 与来源锚点。

小结

.omx/cc2/board.md 的价值不在某一具体工作项，而在于它示范了"Agent 自维护项目"的任务管理形态：证据用哈希冻结、覆盖用门禁证明、状态用受控枚举、分桶用显式策略、同步用工具强制——ROADMAP 的 669 个源行、30 条最新 issue、2 条对标元数据全部可溯源到带行号/编号的锚点，任何缺失映射或重复映射都会让生成与校验双重失败。对需要在多人/多 Agent 协作中管理长路线图的项目而言，这套 ROADMAP.md → board.json → board.md 的三段管线（外加 --check 同步断言）是一个可直接参考的工程范本。