评审与完成定义规范
前八类规范回答「代码该写成什么样」，这一页回答「什么时候算做完、谁来判」。小组作业最容易失分的地方不是功能没做，而是没有人能说清它做完了没有——完成定义（Definition of Done）就是把这个判断写下来。
1这一页管什么
管流程与判定；具体的技术判定分散在前面各页。
- 管完成的判定与流程。完成定义、单次变更的规模上限、评审清单、评审的责任人与时限、例外的处理方式、证据归档、合并策略。
- 不交由这一页。「场景是否满足」由规约判定，「代码是否符合规范」由各规范页判定；本页只规定这些判定在什么时候、由谁触发。
- 两种落法。完成定义与合并策略写进规则或根目录说明文件；「按规范评审一次变更」写成技能。
对应的课程知识点：软件过程与完成定义（Definition of Done）、同行评审（peer review）与评审检查表、变更管理与主干保护、质量门禁与证据留档、例外管理与架构决策记录（ADR）。协作节奏一页讲「怎么分工」，本页讲「什么时候算做完」。
2规范条目
八条，从完成定义排到例外处理。
| 条目 | 要写清什么，为什么这样规定 | 怎么检查 |
|---|---|---|
| 完成定义（Definition of Done） | 一条变更完成的全部判定：场景全部满足、用例通过、门禁通过、文档同步、验证记录归档。没有完成定义时，「做完了」是主观判断 | 逐条打勾；勾不上的那一条就是未完成的部分 |
| 变更规模上限 | 单次变更不超过一组任务或若干文件；超出即拆分。规模越大，评审越趋近于走过场 | 超过上限的变更应被拆回 |
| 评审检查表 | 人工评审看规约覆盖与业务判定（场景是否满足、授权判定是否正确、迁移是否可逆、提示词改动是否跑过评测）；Harness 审查看规范一致性；代码风格交由格式化工具 | 评审记录中应能看出三类分工各查了什么 |
| 责任人与时限 | 谁批准、多久内响应、超时如何处置。没有责任人的评审请求会一直挂着 | 抽查是否存在超期未处理的评审请求 |
| 门禁必跑 | 合并前必须执行门禁命令；不得跳过本地钩子，也不得放宽其中的检查项让结果变绿 | 抽查若干合并记录是否都能对应到一次门禁执行 |
| 例外书面化 | 确有理由保留旧写法时，把例外写进规范本身并记录理由；不允许留在会话里的口头豁免 | 检索规范文件中的例外条目；会话里的豁免一律无效 |
| 证据归档 | 变更说明、验证记录、评审结论归档到仓库的 docs/ 目录，按变更名可检索 | 按变更名检索，应能一次找到三份材料 |
| 复盘留痕 | 失败与返工的原因记入变更说明或决策记录，作为下一次的输入 | 抽查一次失败是否有可检索的记录 |
3本课先写到哪
下列四件完成，本课交付就有可判定的终点。
- 最小集合四件。写一条完成定义、定变更规模上限、定评审检查表、规定门禁必跑。
- 完成定义写在根目录说明文件里。每次会话都能读到，不是写在群里。
- 用一次变更走完整流程。提变更 → 实现 → 自检 → 评审 → 归档 → 打标签，缺哪一步就补哪一步。
- 写一次例外。挑一条确实难以遵守的规范，按流程写下例外与理由，验证这条路走得通。
这一页最难的不是写条目，而是执行时不放开：一旦允许「这次先过」，完成定义就退化成了一句口号。