code-detailed-design

name	code-detailed-design
description	把业务设计转成模块、接口、数据和实现方案。Invoke after business design is accepted and before coding starts.

Code Detailed Design

目标

在整体架构、业务设计和技术选型确定后，输出可直接指导编码的详细设计。

状态规则

• 当前状态固定输出为：详细设计中
• 本阶段属于中高参与阶段，遇到明显不同的技术方案时必须向用户说明取舍并请用户拍板
• 所有选型、接口风格、库表方案、事务策略、并发策略、测试策略，都必须尽量以选择题形式呈现

选择式决策协议

技术方案存在明显分歧时，必须使用以下格式：

当前状态：详细设计中
当前目标：确认本轮技术设计选择
我的推荐：方案 A
推荐理由：...

请你做选择：
1. 方案 A（推荐） - 成本...，收益...，风险...
2. 方案 B - 成本...，收益...，风险...
3. 方案 C - 成本...，收益...，风险...

你确认后，我会：...

必须覆盖的设计内容

1. 模块划分与职责边界
2. 类、函数、服务、任务拆分
3. 接口设计
4. 请求响应结构
5. 数据模型与字段设计
6. 库表设计与 SQL 草案
7. 关键流程时序
8. 数据流向（技术层）
9. 事务边界
10. 并发、锁、幂等、重试策略
11. 权限控制与安全落点
12. 异常处理实现计划
13. 日志、监控、审计、埋点计划
14. 测试策略与测试点
15. 详细编码计划
16. 变更影响范围
17. 回滚或降级思路

输出契约

必须在 业务设计 目录输出详细设计文档，或在其中明确区分“业务设计”和“详细设计”两个部分。

文档中至少要有一个“关键技术决策清单”章节，并采用选择题形式记录推荐项、备选项和最终选择。

回退规则

• 若发现业务规则不成立或缺失，应回退到 business-design
• 若发现对项目现状理解错误，应回退到 repo-investigation

禁止事项

• 禁止没有职责边界就开始编码
• 禁止没有失败路径和异常处理就开始编码
• 禁止只写 happy path