build

build — 实现规范

单线程原生计划→执行。你是主 Claude。无群组。

加载

1. 读取 SPEC.md。如果缺失 → 告诉用户先调用 spec 技能。停止。
2. 如果尚未加载，读取一次 FORMAT.md。
3. 如果存在 §R，读取它——构建必须遵守的外部事实，⊥ 重新推导或反驳。
4. 解析调用参数：
   • §T.n → 仅该任务
   • --next → 状态为 . 或 ~ 的最小行号
   • --all 或空 → 按 §T 顺序处理所有 . 行

高影响范围（共享模块、认证、数据、金钱、公共 §I）？先运行 /review。琐碎且可逆？跳过规划仪式，直接执行 EXECUTE 步骤。

计划

原生计划模式——你委托给它，不要重新发明任务分解。对于选定的任务：

1. 引用所有适用的 §V 不变量。计划必须遵守所有。
2. 引用所有涉及的 §I 接口。计划必须保持形状。
3. 列出要创建/编辑的文件。
4. 验证契约——命名确切的测试/验收标准，证明每个涉及的 §V。哪个测试，而不是“添加测试”。“做 TDD” 单独会适得其反；规范说明要检查什么。每个涉及的 §V → 一个先失败的命名测试。
5. 命名验证命令（测试、构建、lint）——这是外部预言机。绿色 = 完成；⊥ “看起来完成”。

显示计划。除非自动模式，否则等待用户确认。

执行

按顺序处理每个任务：

1. 将 §T.n 状态单元格 . → ~。直接写入 SPEC.md。
2. 按计划编辑代码。
3. 运行验证命令。
4. 通过 → 将 ~ → x。下一个任务。
5. 失败 → 调用 backprop 技能。不要盲目重试。

失败 → 反向传播

测试/构建失败时：

1. 读取失败输出。
2. 询问：失败是 (a) 我的代码错误，(b) 规范错误，还是 (c) 未指定的边缘情况？
3. 如果是 (a) → 修复代码，重新运行。不更改规范。
4. 如果是 (b) 或 (c) → 首先使用 bug: <cause> 调用 spec 技能，让它更新 §V 和 §B，然后根据更新后的规范继续构建。

规则：永远不要在不考虑反向传播的情况下静默修复根本原因。§B 是阻止再次发生的记忆。

写入策略

• 仅翻转 §T 状态。构建不进行其他 SPEC.md 编辑。
• 其他规范编辑 → 调用 spec 技能。
• 每个 §T 完成后提交。消息：T<n>: <goal line> + §V 引用。

验证

任务 x 仅当：

• 验证命令（预言机）退出码为 0。
• 每个涉及的 §V 都有其验证契约中的命名测试，并且通过。
• 没有 §V 不变量回归（最后运行完整测试套件）。

非目标

• 无子代理。无并行工作线程。仅主线程。
• 无进度仪表板。cat SPEC.md | grep §T 就是仪表板。
• 不做超出所选任务范围的推测性工作。