已有 SPEC.md 时用单线程计划—执行—验证循环逐任务实…

适用于已有 SPEC.md、需要按 §T 任务逐项实现、用外部验证命令判定完成，并在测试/构建失败时先判断是代码 bug 还是规范缺陷的工作流。

适用场景

解决思路

1. 当用户要求 build、实现、执行规范，或处理特定 §T 任务（如 `build §T.3`、`build --next`、`implement next task`、`run the build`）时启动本流程。
2. 先读取 `SPEC.md`；若不存在，告诉用户先调用 spec 技能，然后停止。
3. 若 `FORMAT.md` 尚未加载，读取一次。
4. 若存在 §R，必须读取；构建必须遵守其中的外部事实，不得重新推导或与之矛盾。
5. 解析调用参数：`§T.n` 表示只做该任务。
6. 解析调用参数：`--next` 表示选择 §T 中状态为 `.` 或 `~` 的最小编号行。
7. 解析调用参数：`--all` 或空参数表示按 §T 顺序执行所有 `.` 行。
8. 若是高爆炸半径变更（共享模块、认证、数据、金钱、公共 §I），先运行 `/review`。
9. 若是琐碎且可逆的变更，跳过计划仪式，直接进入 EXECUTE。
10. 在原生 plan 模式中为选定任务制定计划，不要重新发明任务拆解方式。
11. 计划中引用所有适用的 §V 不变式，并确保计划尊重全部 §V。
12. 计划中引用所有触及的 §I 接口，并确保计划保持其形状。
13. 列出要创建或编辑的文件。
14. 建立验证契约：为每个触及的 §V 指定确切测试或验收标准，必须写明哪个测试，而不是“加测试”。
15. 注意仅写“做 TDD”会反效果；规范要说明检查什么；每个触及的 §V 都要有一个先失败的具体命名测试。
16. 指定验证命令（test、build、lint），它是外部 oracle；绿色即完成，不能以“看起来完成”为准。
17. 展示计划；除非处于 auto 模式，等待用户确认。
18. 按顺序逐任务执行：先将 §T.n 状态单元格从 `.` 改为 `~`，只写入 `SPEC.md`。
19. 按计划编辑代码。
20. 运行验证命令。
21. 若通过：将 `~` 改为 `x`，然后继续下一个任务。
22. 若失败：调用 backprop 技能，不要盲目重试。
23. 失败时读取失败输出。
24. 判断失败原因是：(a) 我的代码 bug，(b) 规范错误，还是 (c) 未指定的边缘情况。
25. 若是 (a)：修复代码并重新运行，不修改规范。
26. 若是 (b) 或 (c)：先以 `bug: <cause>` 调用 spec 技能，让其更新 §V 和 §B，然后基于更新后的规范恢复构建。
27. 绝不在未考虑 backprop 的情况下静默修复根因；§B 是防止复发的记忆。
28. 写入策略：build 只能翻转 §T 状态，不能对 `SPEC.md` 做其他编辑。
29. 其他规范编辑：调用 spec 技能。
30. 每个 §T 完成后提交。提交信息：`T<n>: <goal line>` 加 §V 引用。
31. 只有满足以下条件才将任务标记为 `x`：验证命令（oracle）退出码为 0。
32. 只有满足以下条件才将任务标记为 `x`：每个触及的 §V 都有验证契约中命名的测试，并且该测试通过。
33. 只有满足以下条件才将任务标记为 `x`：没有 §V 不变式回归（结束时运行完整测试套件）。
34. 非目标：不使用 sub-agents，不使用并行 worker，只使用主线程。
35. 非目标：不做进度面板；`cat SPEC.md | grep §T` 就是仪表盘。
36. 非目标：不做所选任务范围之外的投机性工作。

适用边界 · 注意事项

• 没有 `SPEC.md` 时不要使用；应先调用 spec 技能。
• 高爆炸半径变更（共享模块、认证、数据、金钱、公共 §I）未先运行 `/review` 时不要直接实现。
• 需要子代理、并行 worker、进度面板或超出选定任务范围的投机性工作时不要使用本流程。