用途
disciplined-design 是 disciplined development 流程的第二阶段（Phase 2），角色定位为设计专家。它的任务不是编写实现代码，而是根据“已批准的研究文档”制定详细的实现计划（Implementation Plan），为后续实现阶段提供可直接遵循的规范。
核心原则
- Plan Before Code（先计划后编码）：任何改动在编写前都已计划。
- Explicit Steps（显式步骤）：把工作拆分为可评审的小块。
- Test Strategy First（测试策略先行）：在实现前定义如何验证。
- Human Approval（人工批准）：没有签署确认就不进入实现。
- Eliminate Before Adding（先删除后新增）：设计主要是关于移除。
Essentialism：ELIMINATE 阶段
该阶段体现 McKeown 的 ELIMINATE 原则，设计即选择“不做什么”。添加任何东西前需自问：我们能移除什么？能工作的最简单架构是什么？如果这件事可以很简单会怎样？
功能的 5/25 规则
将巴菲特规则应用于范围：列出所有考虑的功能/能力（最多 25 项）；圈出前 5 项作为 IN scope；其余 20 项成为 AVOID AT ALL COST 清单——它们不是“锦上添花”或“未来工作”，而是威胁核心要务的危险干扰。
前置条件
Phase 2 需要：Phase 1 已批准的研究文档、已解决的开放问题、清晰的范围与成功标准。
阶段目标
产出实现计划，做到：明确哪些文件变更、在实现前定义函数签名、建立测试策略、把工作排成可评审的步骤。
实现计划模板包含的部分
- 头部：状态（Draft/Review/Approved）、研究文档链接、作者、日期、预估工作量。
- 概述：摘要、方法（从研究选项中选择的高层方案）、范围（In Scope / Out of Scope / Avoid At All Cost）。
- 架构：组件图、数据流、关键设计决策表（决策、理由、被否决的替代方案）、被消除的选项表（被拒选项、拒绝原因、纳入风险）、简洁性检查（回答“如果这件事可以很简单会怎样？”）。
- 文件变更：新增文件、修改文件、删除文件三张表。
- API 设计：公开类型（附文档注释）、公开函数（含参数、返回值、错误说明）、错误类型（示例使用 thiserror）。
- 测试策略：单元测试表（测试名、位置、目的）、集成测试表、属性测试（示例为 proptest 中 process_never_panics）。
- 实现步骤：每步含文件、描述、测试、依赖、预估工时；示例分为 Step 1 类型与错误、Step 2 核心逻辑、Step 3 集成、Step 4 文档。
- 回滚计划：回滚步骤、功能开关（如 FEATURE_ENABLED=false）。
- 迁移（如适用）：数据库变更（SQL 示例）、数据迁移步骤。
- 依赖：新增依赖表（crate、版本、理由）、依赖更新表。
- 性能考量：预期性能表（指标、目标、测量方式）、要添加的基准测试示例。
- 开放事项表、审批清单（技术评审、测试策略、性能目标、人工批准）。
设计技法
- Interface-First Design：先定义接口（如 trait FeatureService），实现留到 Phase 3。
- Test-Driven Design：先写测试签名，函数体用 todo!() 占位。
门槛条件
进入 Phase 3（实现）前需满足：
标准门槛：列出所有文件变更、定义所有公开 API、测试策略完整、步骤按依赖排序、设定性能目标、获得人工批准。
Essentialism 门槛：范围内主要组件/功能不超过 5 个、填写“被消除的选项”部分、记录“Avoid At All Cost”清单、回答简洁性检查（设计应显得轻松而非费力）、对功能应用 5/25 规则。
质量评估与后续
完成设计后，在进入 Phase 3 前使用 disciplined-quality-evaluation 技能请求评估。Phase 2 批准后：用 disciplined-specification 技能进行规范访谈（Phase 2.5），深入边界情况、失败模式与取舍，在实现前暴露隐藏需求，结论追加到设计文档；随后使用 disciplined-implementation 技能进入 Phase 3。
约束与成功指标
约束：不做实现、只做设计；签名必须显式；设计可测试（每步都有测试）；步骤足够小以便评审。
成功指标：实现者无需猜测即可遵循计划；测试在代码之前定义；Phase 3 不出现架构意外；步骤可独立评审。
适用场景与限制
适用于需要严格设计先行、范围克制、测试先行与人工审批的软件开发流程，尤其是遵循 disciplined development 工作流的项目。其限制在于：它本身不产出实现代码，依赖 Phase 1 已批准的研究文档；文档中未提供具体安装命令、收费方式或平台要求等信息。