comet-build

Comet 阶段 3：计划与构建（Build）

开始或恢复前必须先读取并执行 comet-classic/reference/classic-layout.md；本文件中的 OpenSpec CLI 调用必须使用 adapter，文件路径必须使用该协议绑定的 <classic-*> 逻辑根。

前置条件

• Design Doc 已创建（阶段 2 完成）
• 活跃 change 存在

步骤

0. 入口状态验证（Entry Check）

按 comet-classic/reference/scripts.md 使用稳定 comet CLI，然后执行入口验证；从任意入口恢复时先按 comet-classic/reference/context-recovery.md 运行恢复检查：

comet state select <change-name>
comet state check <name> build

验证通过后继续 Step 1。验证失败时脚本会输出具体失败原因。

若上述 select / check 输出 BLOCKED，且原因是 bound_branch 与当前分支不一致，立即按 comet-classic/reference/decision-point.md 暂停，让用户单选：切回绑定分支后重新运行入口验证，或在用户明确确认当前分支应接管该 change 后运行 comet state rebind <change-name> 并重新入口验证。不得自行切换分支，不得自行换绑。

幂等性：build 阶段所有操作可安全重复执行。读取 .comet.yaml 的 phase 字段确认仍在 build 阶段，读取 plan 文件头的 base-ref，再按文档顺序解析 tasks.md 的复选框，从第一个未勾选任务继续执行。已提交的任务不得重复提交。

1. 制定计划

使用 writing-plans Skill 创建实施计划。计划必须使用 comet state get <name> language 读取到的 Comet 配置产物语言，并保存至固定路径 docs/superpowers/plans/<YYYY-MM-DD>-<change-name>.md（如 docs/superpowers/plans/2026-08-21-rename-alert.md）。

调用 Skill 时提供以下输入：

1. 产物语言：comet state get <name> language 的解析结果
2. Design Doc（docs/superpowers/specs/ 下的技术设计文档）
3. <classic-change-dir>/tasks.md（任务边界）
4. 固定计划路径和 git rev-parse HEAD 的结果

只使用 writing-plans 的计划编写与自检流程；计划完成后返回 Comet Build，由 Comet 统一处理后续执行配置。若 Skill 加载或计划生成失败，停止 Build 并报告原因。

计划要求：

• 保存至指令中给定的计划路径，不更改文件名
• 只覆盖 tasks.md 列出的任务，不扩展范围
• 引用设计文档，拆分为可执行任务
• Plan 文件头必须包含关联元数据：

---
change: <openspec-change-name>
design-doc: docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md
base-ref: <git rev-parse HEAD before implementation>
---

base-ref 用于验证阶段跨提交统计改动规模。创建计划时先记录当前提交：

git rev-parse HEAD

计划写入后确认该路径存在，再运行 Step 2 的 comet state set <name> plan ... 记录计划路径。

2. 记录计划并联合确认工作方式

先记录 plan 路径：

comet state set <name> plan docs/superpowers/plans/YYYY-MM-DD-feature.md

无需手动更新 phase，阶段守卫（guard --apply）会在退出条件满足后推进 phase 字段。

展示联合决策时，只提供本工作流支持的执行方式、TDD 模式和代码审查模式。工作区已经在 Open 阶段准备并绑定；若当前 change 没有有效 isolation，返回 /comet-open 修复，不在 Build 创建或切换工作区。