企业官网建设流程全解析

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

【免费下载链接】claw-codeAn agent-managed museum exhibit, built in Rust with Gajae-Code / LazyCodex — developed and maintained with no human intervention.项目地址: https://gitcode.com/gh_mirrors/claudeco/claw-code

.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 表记录了三类证据源的冻结指纹，这是整套机制里最值得注意的设计——看板不是凭空整理出来的，而是从哈希锚定的源文件推导出来的：

这些字段并非手写，而是 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：

"覆盖"的含义在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 命名法由 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 态）

这 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 桶）

分桶逻辑在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 汇总

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

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）中定义，例如：

值得注意的是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/rustcargo test -p rusty-claude-clireads host~/.claude/plugins/installed/from real$HOMEand fails parse-time on any half-installed user plugin

条目正文记录了完整的证据链：11 个确定性失败的测试名、根因的两层结构（parse_args急切遍历宿主插件目录 + 测试 harness 未做$HOME隔离）、以及"backportenv_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同步断言）是一个可直接参考的工程范本。

【免费下载链接】claw-codeAn agent-managed museum exhibit, built in Rust with Gajae-Code / LazyCodex — developed and maintained with no human intervention.项目地址: https://gitcode.com/gh_mirrors/claudeco/claw-code