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）
76 lines
4.2 KiB
Markdown
76 lines
4.2 KiB
Markdown
# 04-迭代记录（Iteration Logs）
|
||
|
||
> 执行过程的事实档案：每次迭代一个子目录，记录迭代目标、技术实现方案与验收标准。
|
||
|
||
## 角色
|
||
|
||
项目执行史的忠实记录。复盘、追溯、计划验收的事实依据。是"文档驱动"闭环里唯一记录"发生过的现实"的地方。
|
||
|
||
## 组织结构
|
||
|
||
每次迭代一个子目录。目录已位于迭代记录下，目录名不再重复"迭代"前缀，直接为 **`<编号>-<目标名称>`**（如 `01-建立神之一手框架`），编号放最前、后面直接跟本次迭代的目标名称，子目录内含三份文档：
|
||
|
||
```
|
||
04-迭代记录/
|
||
├── 说明.md
|
||
├── 01-建立神之一手框架/
|
||
│ ├── 迭代目标.md # 本次迭代的目标、目标描述、目标讨论过程、对老师的配合需求
|
||
│ ├── 技术实现方案.md # 实现该目标对应的技术实现方案
|
||
│ └── 验收标准.md # 本次迭代的验收标准线、验收方法、验收目标
|
||
├── 02-<目标名称>/
|
||
└── ...
|
||
```
|
||
|
||
### 迭代目标.md
|
||
|
||
记录本次迭代的：
|
||
|
||
1. **目标**：一句话说清本次迭代要达成什么。
|
||
2. **目标描述**：目标的详细描述（范围、边界、要解决的问题）。
|
||
3. **目标讨论过程**：本次迭代目标从提出到确定的讨论过程（关键论点、取舍、结论）。
|
||
4. **对老师（项目主理人）的配合需求**：执行本次迭代需要老师配合的事项（决策、素材、确认、评审等）。
|
||
|
||
> 迭代目标若引用需求池中的需求，需在目标描述中标注需求编号，并触发需求池索引记录联动（见需求池）。
|
||
|
||
### 技术实现方案.md
|
||
|
||
记录实现本次迭代目标对应的技术实现方案：技术选型、架构/设计要点、实现步骤、涉及的设计约束（引用 `03-设计约束/` 中对应条目编号）等。
|
||
|
||
### 验收标准.md
|
||
|
||
明确本次迭代的验收标准线 —— 如何判定本次迭代是否达成。记录：
|
||
|
||
1. **验收标准线**：本次迭代达成的标准在哪里（可验证的具体标准，作为"迭代完成"的判定线）。
|
||
2. **验收方法**：如何做验收（验证手段：测试、演示、评审、数据核对等）。
|
||
3. **验收目标**：验收要达到的目标（验收时逐项确认的最终结果）。
|
||
|
||
## 强约束（初始定义）
|
||
|
||
1. **只记事实**：记录"做了什么、结果如何"，不写感想、不写评价、不粉饰。
|
||
2. **追加式，不改写**：历史记录不可修改、不可删除；纠正用追加的更正记录。
|
||
3. **每次迭代一个子目录**：迭代必须有自己的编号子目录，文档归入对应子目录，不混放。
|
||
4. **与计划/需求池对应**：每条迭代记录应能对应到计划中的任务或需求池条目。
|
||
5. **入范围门槛**：只有确定的需求才可进入迭代工作范围；未确定的需求不得建立迭代子目录。
|
||
6. **成功失败都记**：失败是复盘的原料，必须如实记录。
|
||
7. **时间可溯**：记录带有时间信息，支持按时间回溯。
|
||
|
||
## 待讨论细节
|
||
|
||
- [ ] 迭代编号规则（编号是否需带日期 / 序号是否全局递增 / 目标名称的写法规范）
|
||
- [ ] 迭代的粒度（多大算一次迭代？一次讨论 / 一个功能 / 一个周期？）
|
||
- [ ] 迭代目标.md 的讨论过程如何记录（详细纪要 vs 结论摘要）
|
||
- [ ] 验收标准.md 的写法模板（标准线 / 验收方法 / 验收目标的具体写法与示例）
|
||
- [ ] 复盘模板（复盘时如何从记录中提炼结论）
|
||
|
||
## 实现经验沉淀（2026-09-01 起，随迭代复盘累积）
|
||
|
||
> 跨迭代复用的实现经验，从各次迭代复盘中提炼，作为后续实现的隐性约束。
|
||
|
||
### 语义迁移核对（迭代 06，2026-09-01）
|
||
|
||
改造/迁移方法时，若方法语义发生变化（如「新增量」变「绝对目标量」、存储整体读写变单条生命周期），必须：
|
||
|
||
1. **显式命名语义**：如 `_applySharesForStrategy(target)` 注释标明参数为绝对目标；
|
||
2. **逐调用点核对**：每个调用点确认传入参数含义一致（增量 vs 绝对量）；
|
||
3. **真实 API CRUD 回归**：不能只靠隔离单测 —— 隔离测试可能掩盖语义混淆（本次 add-shares 加仓 100 变 100 的 Bug 就是真实 API 验证才暴露）。
|