one_divine_lot/docs/04-迭代记录/说明.md

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 的写法模板（标准线 / 验收方法 / 验收目标的具体写法与示例）
• 复盘模板（复盘时如何从记录中提炼结论）