binance-api/.specify/templates/plan-template.md

实施计划： [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 cursor
   • 仅添加本轮新增技术信息
   • 保留手工补充内容
   • 记录最近 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.0.0 - 详见 /memory/constitution.md