# 实施计划: [FEATURE] **分支**:`[###-feature-name]` | **日期**: [DATE] | **规范**: [link] **输入**:`/specs/[###-feature-name]/spec.md` 中的功能规范 ## 执行流程(/plan 命令作用范围) ``` 1. 从 Input 路径加载功能规范 → 如果缺失:ERROR "No feature spec at {path}" 2. 填写技术背景(扫描 NEEDS CLARIFICATION) → 根据文件结构或上下文判断项目类型(web=前后端,mobile=App+API) → 根据项目类型给出结构决策 3. 根据宪章内容完成 Constitution Check 部分(原则 I–V、运营约束、流程质量门槛、治理要求) 4. 评估 Constitution Check → 若存在违例:记录在 Complexity Tracking → 若无法给出理由:ERROR "Simplify approach first" → 更新 Progress Tracking:Initial Constitution Check 5. 执行 Phase 0 → research.md(确保记录行情数据源、敞口目标与风险约束) → 若仍有 NEEDS CLARIFICATION:ERROR "Resolve unknowns" 6. 执行 Phase 1 → contracts、data-model.md、quickstart.md、agent 文件 7. 再次评估 Constitution Check → 若出现新违例:回到 Phase 1 调整 → 更新 Progress Tracking:Post-Design Constitution Check 8. 规划 Phase 2 → 描述任务生成策略(不要创建 tasks.md) 9. 停止 - 准备执行 /tasks 命令 ``` **重要提示**:/plan 命令到步骤 7 即结束。后续阶段由其他命令完成: - Phase 2:/tasks 生成 tasks.md - Phase 3-4:按计划实施 ## 总结 [摘自功能规范:关键需求 + 研究阶段确定的技术方案摘要] ## 技术背景 **语言/版本**: [如 Python 3.11,Swift 5.9,Rust 1.75,或 NEEDS CLARIFICATION] **主要依赖**: [如 FastAPI,UIKit,LLVM,或 NEEDS CLARIFICATION] **存储**: [如 PostgreSQL,CoreData,文件系统,或 N/A] **测试框架**: [如 pytest,XCTest,cargo test,或 NEEDS CLARIFICATION] **目标平台**: [如 Linux server,iOS 15+,WASM,或 NEEDS CLARIFICATION] **项目类型**: [单体/前后端/移动,多用于目录结构决策] **性能目标**: [如 1000 req/s,60 fps,或 NEEDS CLARIFICATION] **约束条件**: [如 p95 <200ms,内存 <100MB,支持离线等] **规模/范围**: [如 1 万用户、50 个界面、或 NEEDS CLARIFICATION] ## 宪章核对(Constitution Check) *关卡:必须在 Phase 0 前通过,并在 Phase 1 后再次确认。* [根据宪章写出核对项] ## 项目结构 ### 文档(本功能) ``` specs/[###-feature]/ ├── plan.md # 本文件(/plan 输出) ├── research.md # Phase 0 输出(/plan) ├── data-model.md # Phase 1 输出(/plan) ├── quickstart.md # Phase 1 输出(/plan) ├── contracts/ # Phase 1 输出(/plan) └── tasks.md # Phase 2 输出(/tasks,非 /plan 生成) ``` ### 源码目录(仓库根目录) ``` # [若未使用请删除] 方案 1:单体项目(默认) src/ ├── models/ ├── services/ ├── cli/ └── lib/ tests/ ├── contract/ ├── integration/ └── unit/ # [若未使用请删除] 方案 2:Web 应用(前后端) backend/ ├── src/ │ ├── models/ │ ├── services/ │ └── api/ └── tests/ frontend/ ├── src/ │ ├── components/ │ ├── pages/ │ └── services/ └── tests/ # [若未使用请删除] 方案 3:移动端 + API(iOS / Android) api/ └── [同后端结构] ios/ 或 android/ └── [平台特定目录] ``` **结构决策**:[记录实际采用的结构并引用上述目录] ## Phase 0:概述与调研 1. **从技术背景提取未知项**: - 每个 NEEDS CLARIFICATION → 研究任务 - 每个新依赖 → 最佳实践任务 - 每个外部集成 → 设计模式任务 2. **生成调研任务**: ``` 对每个未知项: 任务:调研 {未知点} 在 {功能背景} 的最佳做法 对每个技术选项: 任务:收集 {技术} 在 {领域} 的最佳实践 ``` 3. **整理输出**至 `research.md`: - 决策:选择方案 - 理由:为何选择 - 备选:评估过的其他方案 **产出**:research.md,所有未知项已解决 ## Phase 1:设计与契约 *前提:research.md 已完成* 1. **从功能规范提取实体** → `data-model.md` - 实体名称、字段、关系 - 验证规则 - 状态变化若有 2. **从需求生成 API 契约** - 每个用户行为 → 对应接口 - REST/GraphQL 等标准格式 - 输出到 `/contracts/` 3. **从契约生成契约测试** - 每个接口一个测试文件 - 校验请求/响应结构 - 测试必须先失败 4. **从用户故事提取测试场景** - 每个故事 → 集成测试场景 - Quickstart 测试 = 验收步骤 5. **增量更新 agent 文件**(O(1) 操作): - 运行 `.specify/scripts/bash/update-agent-context.sh claude` - 仅添加本轮新增技术信息 - 保留手工补充内容 - 记录最近 3 次变更 - 保持文件在 150 行以内 **产出**:data-model.md、/contracts/*、失败的契约测试、quickstart.md、更新后的 agent 文件 ## Phase 2:任务规划方法 *说明 /tasks 命令的工作方式(本阶段不执行)* **任务生成策略**: - 以 `.specify/templates/tasks-template.md` 为基线 - 根据 Phase 1 文档(契约、数据模型、quickstart)生成任务 - 每个契约 → 契约测试任务 [P] - 每个实体 → 模型创建任务 [P] - 每个用户故事 → 集成测试任务 - 实现任务遵循测试先行 **排序策略**: - TDD 顺序:先测试再实现 - 依赖顺序:模型 → 服务 → 接口 - [P] 用于描述可并行的工作 **预估输出**:tasks.md,约 25-30 个有序任务 **注意**:Phase 2 由 /tasks 完成,非 /plan 输出 ## Phase 3+:后续实施 *超出 /plan 命令范围* **Phase 3**:执行 /tasks 生成 tasks.md **Phase 4**:按 tasks.md 实施 **Phase 5**:验证(运行测试、执行 quickstart、性能验证) ## 复杂度追踪 *仅在 Constitution Check 有违例时填写* | 违例 | 原因 | 被否决的简单方案 | |------|------|------------------| | [示例:新增第 4 个项目] | [现实需求] | [为何前三个不足] | ## 进度追踪 *执行流程中的状态记录* **阶段状态**: - [ ] Phase 0:调研完成 (/plan) - [ ] Phase 1:设计完成 (/plan) - [ ] Phase 2:任务规划完成 (/plan,仅描述方法) - [ ] Phase 3:任务已生成 (/tasks) - [ ] Phase 4:实现完成 - [ ] Phase 5:验证通过 **关卡状态**: - [ ] 初次宪章核对:通过 - [ ] 设计后宪章核对:通过 - [ ] 所有 NEEDS CLARIFICATION 已解决 - [ ] 复杂度偏差已记录 --- *基于宪章 v1.3.0 - 详见 `/memory/constitution.md`*