本阶段如何触发
/comet-build 通常由 /comet-classic 自动衔接。
默认：用 /comet 自动衔接
design 阶段退出后（phase: build），/comet-classic 会自动衔接调用 /comet-build。下一次调用 /comet-classic 时，如果检测到 phase: build 或有 Design Doc 但执行未完成，也会路由到 build：hotfix 走 /comet-hotfix、tweak 走 /comet-tweak、full 走 /comet-build。详见自动推进机制。
手动：什么时候才需要直接 /comet-build
- 关闭了自动衔接（
auto_transition: false）：design 完成后/comet-classic会停下并打印 HINT。 - 只想单独跑 build（恢复一个
phase: build的 change 继续执行）。 - verify 失败后通过
comet-state transition verify-fail回滚，需要重新进入 build 修复。
/comet；只有手动控制阶段时才直接调用阶段命令。
你会经历什么
build 阶段有 2 个停顿点（全局编号 6-7，整个五阶段工作流共 10 个，见五阶段停顿点和用户选择点）。下面按发生顺序讲。
build 阶段把计划拆成任务卡片，逐张执行、排错、勾选并留下提交证据
Step 0：入口状态验证
base-ref，grep 找第一个未完成任务。幂等：已提交的任务不会重复提交。
Step 1：创建实施计划
Comet 派子代理加载writing-plans 写计划（这样不占主会话上下文），子代理失败时回退到主会话内联加载。计划 frontmatter 必须含：
停顿点 6：build 联合决策
计划写好后，Comet 暂停等你选：同一次决策里再选三种工作模式
选 A 继续后，Comet 在同一次联合决策里让你一次选定执行方式、TDD 模式和审查模式。工作区隔离不在这里。它已在 open 阶段的工作区决策（停顿点 3）确定：选择结果写入isolation，实际执行目录的当前分支记录为 bound_branch，build 阶段只验证目录与分支匹配，不会静默换目录。选择 branch 时的分支名在 open 阶段一并确认（hotfix/tweak 预设默认 hotfix/YYYYMMDD/<name>、tweak/YYYYMMDD/<name>）。
1. 执行方式（build_mode）
2. TDD 模式（tdd_mode）
3. 审查模式（review_mode）
详见代码审查机制。
Step 3：逐任务执行
选定后，按build_mode 执行。两种执行方式的体验不同：
子代理（implementer）不能自己勾选任务
，只有主会话在双阶段验收通过后才勾选。reviewer 拿到的是完整任务 + 实现
commit/diff + RED/GREEN 证据（TDD 时），
不能只看实现者摘要就下结论。
Step 3b：异常调试协议（强制）
执行中出现崩溃、测试失败、构建失败或异常行为时，Comet 强制加载systematic-debugging：
- 先定位根因：读完整错误、查最近改动、追数据流。根因调查完成前不得提任何修复。
- 根因是源码 bug 时，先加一个最小失败测试复现，再修源码。
- 修完跑失败测试、相关测试、项目构建/验证命令确认全过。
- 失败测试、源码修复和 tasks.md 勾选都保留在当前 change 内，不要另开“写测试用例”change 替代当前验证循环。
多失败的并行排查
进入四阶段流程前，先做一个失败独立性评估，决定串行还是并行：
满足并行条件时：
- 用 Skill 工具加载 Superpowers
dispatching-parallel-agents。 - 每个独立失败派一个后台排查 agent（按问题域分组，全部派发放在同一条响应里并发执行）。每个 prompt 都包含完整上下文（具体失败、错误信息、允许排查范围、禁止动其他问题域代码）。
- 所有 agent 仍受“根因定位前不得改源码”约束。它们只定位根因并返回发现，不直接提交修复。
- 所有排查返回后，主会话串行汇总发现并修复；修复仍走当前
review_mode的验证和审查循环。
Step 4：spec 增量更新
执行中发现需要改 spec 时，按规模处理：Step 5：勾选 + 提交
每个任务：按build_mode 执行 → 按 review_mode 审查（如适用）→ 主会话勾选 tasks.md → 提交。勾选用定向验证：
grep -c '\- \[ \]' tasks.md 查剩余未勾选数。
退出
phase: verify，设 verify_result: pending。
调用的 skill
产物
退出条件（阶段守卫检查）
- tasks.md 全部勾选
- 代码已提交
- 显式运行项目 build/test 命令并通过（不要只依赖 guard 自动猜测）
isolation是current、branch或worktree，且当前 Git 分支与bound_branch一致build_mode已选（subagent 模式需subagent_dispatch: confirmed）tdd_mode已选review_mode已选（thorough 已按每 3 个任务完成分段审查并修复 CRITICAL/IMPORTANT，或记录非 CRITICAL 接受原因；standard/off 已记录对应原因）
npm run build、Maven 或 Cargo）并把失败输出作为证据。.comet.yaml 和仓库根配置不再支持 build_command / verify_command；需要固定团队级验证流程时，请把它放进项目自己的构建脚本。
恢复
build 阶段幂等。恢复时grep -n '\- \[ \]' tasks.md | head -1 找第一个未完成任务继续。build_pause: plan-ready 的恢复见停顿点 6。上下文压缩后用 comet-state check <name> build --recover 拿恢复上下文；subagent 模式重读 .comet/subagent-progress.md 恢复当前任务和审查轮数，不能在主会话直接执行任务。full workflow 如果停在 plan-ready，恢复动作必须先确认已有的工作区绑定，再补齐或确认三个执行选择：build_mode、tdd_mode 和 review_mode。
推荐路径
下一步
- verify 阶段 — build 完成后进入验证
- 代码审查机制 — review_mode 详解
- 状态管理 — build_mode/isolation/tdd_mode 字段
- 五阶段停顿点和用户选择点 — build 的停顿点