coding-design-plan

编码设计计划

将范围明确的任务转化为最精简且完整的方案，让实现者无需做出新的产品或架构决策即可据此构建。下一个使用者是 implement-and-review 或负责变更的工程师。计划只有在说明变更的行为、责任方、边界、验证方式以及任何未解决的阻碍后，才算完成。

将 PRD 或任务中已确定的选择视为已作出的决定。不要通过新的访谈或选项列表重新讨论这些决定。

工作流

1. 阅读已批准的任务、验收约定和当前生效的项目规范。在提出方案前，检查相关代码、测试和当前行为。

2. 用一句话说明设计问题。指出将发生变化的行为及其责任方。

3. 只梳理受影响的边界：本地代码、模块、组件、服务、数据存储、公共约定或部署行为。运用变更归属，将每项职责放在后续变更理应归属的位置。

4. 选择适配现有代码的最精简且完整的方案。存在真正的替代方案时，说明一个决定性的权衡。如果代码和任务已明确指出一种局部改动，就不要比较选项。

5. 仅在触发条件适用时执行针对性的工程检查：

   1. 如果任务会改变非本地边界，且任务约定尚未选定适用的审查视角，则以当前角色应用 design-gate。
   2. 如果任务中已有指定审查视角的结论，则应用这些结论。不要重新运行审查视角来重述相同结论。
   3. 对于只能通过运行代码解答的单项不确定性，使用 to-prototype。原型代码绝不能晋升为正式代码。

   在当前角色中应用选定的方法。独立专家只有在存在实质性风险或未解决问题时才需要参与。派发前，使用 shared/references/model-preview.md 复用或获取一份具体且已批准的路由快照。独立的最终代码审查仍是单独的工作流要求。

6. 将计划转化为可观察的验证方式。对每项变更行为，指出能证明其正确的测试或直接检查。对于不涉及行为的变更，说明自动化测试为何无用，并指出替代检查。

7. 将发现的相关后续工作保留在 deferred 中。扩展范围需要新任务或明确的用户指示。

复用任务提供或继承的选择。对于不重要的细节，采用安全且范围明确的默认值。只有当无法检查的事实会改变所选方案、公共行为、风险边界、范围、成本、允许产生的影响或尚未解决的决定时，才询问用户。沉默不代表批准。其他情况下，说明假设并继续。

输出约定

返回：

1. design_problem：一句话。
2. chosen_shape：最精简且完整的实现方案。
3. boundaries：受影响的责任方、模块、约定或运行路径。
4. constraints：适用的任务决策和审查视角结论。
5. verification：针对每项变更行为的命令、测试或直接检查。
6. test_scenarios：针对每项变更行为，列出输入、操作和预期结果；若无测试预期，则写明 Test expectation: none，并说明原因和替代检查。
7. deferred：不纳入本任务的相关后续工作。
8. blocker_or_assumption：仅填写可能改变计划的未解决事实。

仅当以下三项条件全部满足，或均不适用时才编写 ADR：决策难以撤销、没有背景时会令人意外，并且确实存在权衡。决定确定时就记录，不要等到实现结束。

注意事项

1. 不要把常规修复变成架构审查。
2. 不要让设计审查视角扩大已接受任务的范围。
3. 需要通过一次性原型学习时，不要规划示踪弹式实现。
4. 缺少验收约定和证据路径时，不要声称计划已完成。