kyugao
dd98b4d45b
- 新增 02-计划/计划-数据存储SQLite.md（PLAN-007） - 新增 04-迭代记录/06-数据存储SQLite/ 五份文档（迭代目标/技术实现方案/验收标准/UI交互调用分析/迭代复盘） - 归档 R-008 至 已完成/（含归档头 + 讨论记录索引），索引更新为已实现（已归档） - 设计约束更新：技术方案约束-012 标注 SQLite 变更、数据存储设计.md 第 9 节变更预告 - 需求池说明.md 新增「归档与转正规范」；迭代记录说明.md 新增「实现经验沉淀」 - 验收标准修正 db 文件名笔误（one-divine-lot.db → store.db）
81 lines
4.8 KiB
Markdown
81 lines
4.8 KiB
Markdown
# 05-需求池（Backlog）
|
||
|
||
> 所有待办需求的统一入口：想法先进池，讨论后排优先级，再进计划。
|
||
|
||
## 角色
|
||
|
||
项目的"收件箱"。任何新想法、新需求、待解决的问题，第一步都是登记入池，而不是直接动手。保证"想清楚再动"。
|
||
|
||
## 强约束（初始定义）
|
||
|
||
1. **统一格式登记**：每条需求按约定格式登记，信息完整方可入池。
|
||
2. **有优先级**：需求必须标注优先级（或待讨论确定优先级）。
|
||
3. **状态流转明确**：需求有清晰的状态流转：**起草 → 讨论中 → 已定稿**（单向推进，回退需讨论说明）；已定稿后可进入计划/迭代，实现后联动「实现迭代 / 实现状态」。
|
||
4. **实现追溯联动**：需求被某次迭代实现时，需求索引记录需补充「实现该需求的迭代」（如 `01-建立神之一手框架`）与「需求实现状态」（实现中 / 已实现 / 部分实现），与迭代记录双向可追溯。
|
||
5. **讨论中的想法先入池**：任何讨论中冒出的新想法，先记入池，不直接进代码或计划。
|
||
6. **入范围门槛**：**只有确定的需求才可进入计划范围或迭代工作范围**；讨论中、未确定的需求停留在需求池，不得进入计划与迭代。
|
||
7. **池子可清理**：定期复盘，拒绝/搁置的需求要明确标记，不让池子无限膨胀。
|
||
|
||
## 待讨论细节
|
||
|
||
- [x] 登记格式（字段：标题 / 描述 / 来源 / 优先级 / 状态（起草/讨论中/已定稿）/ 更新日期 / 实现迭代 / 实现状态）—— 2026-08-27 已按 skill v2 对齐
|
||
- [ ] 优先级规则（P0-P2？MoSCoW？如何定）
|
||
- [x] 状态流转的具体定义（AI 提议 + 老师确认，2026-08-28 定；详见下方「状态流转与定稿」）
|
||
- [x] 需求定稿判定标准（三要素：边界清楚 / 核心逻辑明确 / 老师确认，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）；
|
||
> - **草稿/ = 需求收集**：临时的想法、未成形的需求先放这里，成熟后转正到根目录形成正式需求；
|
||
> - **已完成/ = 归档**：需求实现后移入（每个需求一个文件）；
|
||
> - **丢弃/ = 归档**：拒绝/搁置的需求移入（记录原因）。
|