55 lines
3.5 KiB
Markdown
55 lines
3.5 KiB
Markdown
# LineUp App 迭代文档
|
||
|
||
每个迭代使用一个独立目录，目录名固定为“迭代编号.简短名称”。目录内至少保留该迭代的主定义文档；
|
||
每进行一次设计、架构或实现评审，都必须新增一份独立评审记录，不覆盖之前的记录。
|
||
|
||
```text
|
||
迭代/
|
||
├── plan.md # 当前阶段之后的总体路线和排期原则
|
||
├── 00.base/
|
||
│ └── 00.base.md
|
||
├── 01.kernel/
|
||
│ └── 01.kernel.md
|
||
└── 03.sdk_and_coreapp/
|
||
├── 03.sdk_and_coreapp.md # 本迭代的权威目标、范围、契约、步骤和验收
|
||
├── 01.design_review.md # 第 1 次评审记录
|
||
├── 02.design_review.md # 第 2 次评审记录
|
||
└── 03.design_review.md # 第 3 次评审记录
|
||
```
|
||
|
||
约定如下：
|
||
|
||
1. 主定义文档命名为 `<迭代目录名>.md`，是当前实施依据；
|
||
2. 评审记录按发生顺序编号，命名为 `<两位序号>.design_review.md`；
|
||
3. 每份评审记录必须在元信息之后、评审正文之前维护“问题清单（Outline）”，格式参考
|
||
[`01.design_review.md`](03.sdk_and_coreapp/01.design_review.md)：列出状态、编号、问题和当前结论/下一步；
|
||
4. 评审记录必须写明评审日期、编号、对象、方式和总体结论。新问题先在 Outline 中登记；问题确认后先
|
||
更新 Outline 状态，再回填主定义文档、验收项和评审正文；
|
||
5. 已确认的结论需要回填主定义文档和验收项；评审记录保留原始意见，用于追溯，不能替代主定义文档；
|
||
6. 迭代完成后的实现验收、发布复盘等文档也保留在对应目录内，并使用清晰的递增编号。
|
||
|
||
## 后续总计划
|
||
|
||
当前阶段之后的路线、迭代拆分、范围边界和完成标准见 [plan.md](plan.md)。该文件记录已确认的整体方向；
|
||
每个具体迭代开始后，仍需在自己的目录中创建主定义文档和独立评审记录。
|
||
|
||
## 评审优先级与遗留问题
|
||
|
||
评审问题使用 `P0`～`P5` 标示处理优先级。优先级表达的是“最晚何时必须解决”，而不是问题描述的
|
||
修辞强弱。
|
||
|
||
| 级别 | 含义 | 当前迭代的处理规则 |
|
||
|---|---|---|
|
||
| P0 | 根本性阻塞：安全边界、数据正确性或总体架构不能成立。 | 立即处理；在解决前不得进入相关实现。 |
|
||
| P1 | 关键规则未定：不解决会让不同实现互相冲突或明显返工。 | 在开始相关模块实现前处理。 |
|
||
| P2 | 交付或验收缺口：核心方向正确，但缺失会使恢复、安全验证或验收不完整。 | 必须在本迭代验收前处理。 |
|
||
| P3 | 局部行为、一致性或质量问题：存在安全默认行为，但相关模块完成前仍需收敛。 | 必须在本迭代结束前处理。 |
|
||
| P4 | 优化、可读性或维护性建议。 | 可以登记为遗留问题，不阻塞当前迭代。 |
|
||
| P5 | 观察记录或未来机会，当前没有足够的产品需求或证据进入排期。 | 可以登记为遗留问题，不纳入当前迭代。 |
|
||
|
||
因此，**P0～P3 必须在当前迭代处理完毕，P4～P5 可以作为遗留问题延期处理。**
|
||
|
||
延期不是删除：评审中出现 P4/P5 时，必须在该评审文件的 Outline 或“遗留问题”段落中保留编号、问题、
|
||
延期原因和建议重新评估的阶段/条件。只有在对应迭代主定义文档或新的评审记录中明确重新纳入后，才将
|
||
其提升为当前迭代的 P0～P3 问题。
|