Dt dev code

编码阶段

前置检查

1. 项目根目录存在 .dt/，且 .dt/tasks/（done/ 之外）有任务目录。没有 → 提示用户先运行 dt-dev 走完方案确认。
2. 任务目录多于一个 → 列出让用户选。
3. 任务目录中必须有经用户确认的 design.md：头部有 状态：已确认 行、task.md 已存在、或同一会话里刚确认过，满足其一即视为已确认；都不满足时问用户一句，已确认则补上状态行再继续，未确认则回到 dt-dev 阶段二。

读取上下文

.dt/spec.md + 任务目录的 design.md（续做场景下还有 task.md）。

拆解执行清单（首次进入）

task.md 不存在时，把 design.md 拆解为有序执行清单写入 <任务目录>/task.md：

# <任务名>

状态：doing

## 执行清单

- [ ] 1. <步骤>（验证：<命令或检查方法>）
- [ ] 2. …

拆解原则：按模块或完整功能单元拆，不拆成大量微小步骤；每步附验证方法。

清单贴到对话里给用户看一眼，不等待批准，直接进入下一步「执行方式」的判断（用户随时可以叫停调整）。

执行方式

开干前先分析清单的依赖结构：

• 存在互相独立的部分 → 告诉用户结构（哪些项独立、哪些成链），问一句：顺序执行，还是派子代理并行？
  • 并行的定义：独立分支同时跑，依赖链内部永远顺序（分批放：批内同时、批间等待）。
  • 独立的判定标准：不改同一个文件；涉及共享文件的项归入同一条链，宁可少并行。
  • 每组子代理用什么模型，由 AI 按任务性质自行决定，不需要用户指定。
• 纯链条、没有并行空间 → 不问，主对话顺序执行，说明一句原因。

派子代理的铁律：给路径不给转述——子代理提示词里写明"先读 <任务目录>/design.md、task.md 和 .dt/spec.md 的相关节再开工"（派发时指明 spec.md 哪些节与该组任务相关，不让子代理吞整份规范），不由主对话转述内容。

执行规则

1. 逐项完整实现，不用示例代码或占位代码代替；每完成一项跑该项验证，勾掉 checkbox。
2. 严格遵守 design.md、项目架构、业务规则和开发规范；优先复用已有模式；不做无关重构。
3. 不强制 TDD，但关键逻辑、高风险模块和历史易回归位置必须补充必要测试。
4. 不漂移规则：执行中发现方案有误——
   • 小偏差：顺手更新 design.md，告知用户一声，继续；
   • 会改变技术方案、数据结构或业务行为的偏差：停下，改 design.md，重新经用户确认后继续。
   • 代码与 design.md 必须始终对得上。
5. 会话中断后续做：读 task.md 的状态和勾选进度接着干。

AI Review

清单全部完成后，调用 dt-dev-review。

提交提议

Review 完成后，提议用户提交本次改动（给出建议的提交拆分和提交信息），不自动执行：用户同意才执行 git 操作，不同意直接进入归档。

归档

提交提议处理完后，调用 dt-dev-archive。