项目规划与评估规范
1. 规划约束
1.1 硬性约束
- 阶段性聚焦: 单个迭代核心任务控制在 5-6 项以内，超出时遵循"进一出一"原则。
- 功能解耦: 新功能不破坏现有核心逻辑。涉及核心架构变动必须先技术预研并更新设计文档。
- 测试先行: 规划任务时同步制定测试方案。不包含测试补全计划的功能不具备准入资格。
- 验收标准具体化: 待办条目必须写清：执行范围、非目标、可验证验收标准、最小验证矩阵/证据落点，以及必要时的回滚边界。禁止"优化一下""先做最小版本"等模糊口径。
- 设计先行闸门: 涉及新模块、跨模块边界调整、数据/接口契约重写时，先完成设计文档再进入实现。
- 阶段切换闸门: 当前阶段归档未完成前，禁止在 roadmap 中开启下一阶段的正式规划。
1.2 迭代内新增事项闸门
开发/测试/审计过程中发现的额外事项默认不自动并入当前阶段：
- 先核对该事项是否已在
todo.md、roadmap.md当前阶段或todo-archive.md中 - 若不在当前规划内，先完成快速分流（阻塞/高风险 → 插队；其他 → 延期）
- 未完成判定前，严禁直接进入开发
2. 路线图与待办管理
2.1 路线图
docs/plan/roadmap.md维护阶段概览，每阶段包含：目标、优先级、状态- 已完成阶段标注状态为"已审计归档"或等价完成状态
- 下一阶段在上一阶段归档完成后才开启正式规划
- 详细任务不在 roadmap 中重复展开，以
todo.md/backlog.md为准
2.2 待办事项
docs/plan/todo.md仅包含当前阶段的具体实施任务- 任务状态：
[ ]待办 /[x]已完成 /[-]已取消 - 任务描述至少包含：优先级、依赖、交付物、验收标准
- 任务按里程碑分组
2.3 待办积压
docs/plan/backlog.md存放后续阶段的详细任务- 应区分两类条目：
- 长期主线任务: 可跨阶段保留（覆盖率治理、ESLint/类型债等）。记录最近一次上收阶段、当前状态与下一切片方向。
- 短期/一次性候选: 上收后去重，不得同时出现在当前规划与 backlog 中。
2.4 归档管理
- 阶段完成后，详细内容从
todo.md移入docs/plan/todo-archive.md - 归档保留原始层级结构、状态与验收标准，确保历史可追溯
3. 迭代中途新增事项分流
- 范围核对: 先检查是否已在
todo.md、roadmap.md当前阶段或todo-archive.md中。 - 分类决策:
- A 类（当前范围内）: 只是补足当前验收标准的配套工作 → 继续执行，补充说明
- B 类（允许插队）: 阻塞交付、功能回归、高风险安全/合规、当前依赖链高危漏洞 → 写入
todo.md，标注插队原因 - C 类（延期）: 体验优化、非阻塞重构、探索性想法 → 写入
backlog.md
- 容量控制: B 类事项进入后若超出 5-6 项，须挪出一项低优先级内容至
backlog.md。 - 禁止静默膨胀: 不得在未告知用户的情况下把原子任务扩展成新的功能包。
4. 阶段归档流程
4.1 归档准入
- 确认当前阶段核心条目全部完成
- "进行中""待继续观察"类描述先判断是否阻塞归档还是仅属运行期观察
- 若缺少
todo.md清理、回归记录、阶段总结或todo-archive.md归档块 → 视仍在收口中
4.2 文件更新顺序
- 先清理
todo.md：移除已完成阶段正文 - 再追加
todo-archive.md：完整归档块（审计结论、验收摘要） - 最后同步
roadmap.md：阶段状态改为"已完成"或"已审计归档"
4.3 最低验证
todo.md已清理、todo-archive.md已追加roadmap.md已同步阶段状态- 质量门结论可查（lint + typecheck + 定向测试）
- Review Gate 有
Pass/Reject结论
5. 需求采访与意图抽离
针对模糊需求，必须先通过"采访"方式反问用户：
- 先结构后细节，一步步递进
- 一次一个问题，待用户回答后再追问
- 目标是抽离出最核心、最真实的业务需求
- 在核心需求未对齐前严禁进入开发阶段
6. 相关文档
本文档在 1.0.0 前参考 momei 项目的成熟做法完成继承与适配；1.0.0 后按项目自身实践持续演进，形成自有规范。