one_divine_lot/docs/05-需求池/说明.md

05-需求池（Backlog）

所有待办需求的统一入口：想法先进池，讨论后排优先级，再进计划。

角色

项目的"收件箱"。任何新想法、新需求、待解决的问题，第一步都是登记入池，而不是直接动手。保证"想清楚再动"。

强约束（初始定义）

1. 统一格式登记：每条需求按约定格式登记，信息完整方可入池。
2. 有优先级：需求必须标注优先级（或待讨论确定优先级）。
3. 状态流转明确：需求有清晰的状态流转：起草 → 讨论中 → 已定稿（单向推进，回退需讨论说明）；已定稿后可进入计划/迭代，实现后联动「实现迭代 / 实现状态」。
4. 实现追溯联动：需求被某次迭代实现时，需求索引记录需补充「实现该需求的迭代」（如 01-建立神之一手框架）与「需求实现状态」（实现中 / 已实现 / 部分实现），与迭代记录双向可追溯。
5. 讨论中的想法先入池：任何讨论中冒出的新想法，先记入池，不直接进代码或计划。
6. 入范围门槛：只有确定的需求才可进入计划范围或迭代工作范围；讨论中、未确定的需求停留在需求池，不得进入计划与迭代。
7. 池子可清理：定期复盘，拒绝/搁置的需求要明确标记，不让池子无限膨胀。

待讨论细节

• 登记格式（字段：标题 / 描述 / 来源 / 优先级 / 状态（起草/讨论中/已定稿）/ 更新日期 / 实现迭代 / 实现状态）—— 2026-08-27 已按 skill v2 对齐
• 优先级规则（P0-P2？MoSCoW？如何定）
• 状态流转的具体定义（AI 提议 + 老师确认，2026-08-28 定；详见下方「状态流转与定稿」）
• 需求定稿判定标准（三要素：边界清楚 / 核心逻辑明确 / 老师确认，2026-08-28 定）

状态流转与定稿（2026-08-28 老师确认）

状态流转责任

• 状态流转由 AI 提议 + 老师确认 驱动：AI 负责整理需求、提出状态变更建议（起草 → 讨论中 → 已定稿），老师拍板确认后 AI 更新状态；
• 回退（如 已定稿 → 讨论中）同样需老师确认，并记录回退理由。

需求定稿标准（三要素）

需求进入「已定稿」需同时满足以下三条，全部满足才可进入计划 / 迭代范围：

1. 边界清楚：做什么 / 不做什么（本期范围）明确收敛；
2. 核心逻辑明确：关键决策点（数据模型 / 交互 / 技术方案）都有讨论结论；
3. 老师确认：老师明确表示需求可定稿。

实践样本：R-002 从提出到定稿经历 7+ 轮讨论，完整走完三要素后进入迭代 01。

归档与转正规范（2026-09-01 老师确认，源自 R-005/R-008 实践）

需求归档检查清单

需求实现完成后归档，按序执行：

1. 核实完成：对应迭代复盘存在且标记「验收通过」，索引中实现状态为「已实现」；
2. 补归档头：归档文件加「归档日期 / 需求状态：已完成 / 实现迭代 / 讨论记录索引」头部；
3. 移入归档：需求文件从根目录移入 已完成/；
4. 更新索引：主索引保留条目，实现状态改为「已实现（已归档）」，描述标注归档路径；
5. 双向追溯：迭代记录与需求池互相引用（迭代复盘关联需求编号，需求归档引用迭代复盘路径）。

归档只追加不改写历史。

草稿转正清理

草稿转正为正式需求（T→R）时：

• 必须清理草稿残留的头部/模板内容（如「状态：起草」「登记日期」旧头部），确保正式文件只有一套头部；
• 转正后删除草稿文件；
• 索引同步更新（草稿行状态 → 已转需求 R-xxx）。

目录结构（2026-08-28 老师确认）

docs/05-需求池/
├── 说明.md            # 本文件（目录说明与约定）
├── 需求池索引.md       # 当前工作需求总览（状态流转记录）
├── 草稿/              # 需求收集：临时的想法、未成形的需求（先进草稿，成熟后转正到根目录）
├── 已完成/            # 已完成需求的归档（每个需求一个文件，含需求摘要+讨论记录）
└── 丢弃/              # 被拒绝/搁置需求的归档（记录需求+丢弃原因）

约定（2026-08-28 老师明确）：

• 根目录 = 当前需求工作目录：正在讨论、已定稿、待实现的需求以文件形式放在根目录（如 R-002）；
• 草稿/ = 需求收集：临时的想法、未成形的需求先放这里，成熟后转正到根目录形成正式需求；
• 已完成/ = 归档：需求实现后移入（每个需求一个文件）；
• 丢弃/ = 归档：拒绝/搁置的需求移入（记录原因）。