# 单次交付评审评分表

> 任务实现完成、正式接受前使用。它评估一轮交付；长期代码库质量见 [`quality-document.md`](quality-document.md)。

## 评分

每项 0-2 分：`0` 不满足，`1` 部分满足，`2` 完全满足。

| 维度 | 2 分标准 | 分数 | 证据 |
| --- | --- | --- | --- |
| 需求正确性 | 当前任务对应需求 ID 和全部验收均满足 |  |  |
| 验证真实性 | 自动命令和手工 smoke 均实际运行，结果写入 progress |  |  |
| 范围纪律 | 只修改当前任务需要内容，无 Backlog 和无关重构 |  |  |
| 架构边界 | UI/application/domain/infrastructure/platform 依赖符合文档 |  |  |
| 数据与副作用安全 | 数据库、文件、profile、进程和恢复失败路径均受控 |  |  |
| 安全与合规 | 无秘密泄露、无绕过平台边界、无未经确认自动化 |  |  |
| 交接准备度 | 文档、任务、current state 和下一步足够新会话继续 |  |  |

总分：`/14`

## 强制门槛

结论为 **Accept** 必须同时满足：

- 总分至少 12。
- “需求正确性”和“验证真实性”均为 2。
- 不存在任何 0 分。
- 安全硬边界没有违反。
- 任务状态、progress 和 current state 已同步。

任一安全硬边界违反，直接 **Block**，不能用总分抵消。

## 结论

- **Accept**：达到门槛，可以将任务保持为 `DONE`。
- **Revise**：实现方向可用，但有明确缺口；任务回到 `DOING`，列出修复。
- **Block**：存在根本风险、技术闸门失败或需要用户决策；任务标 `BLOCKED`。

## 评审记录

- 任务 ID：
- 评审日期：
- 结论：
- 缺失证据：
- 必须修复：
- 残余风险：
- 下次复审条件：

评审不能靠 agent 自己概括“看起来没问题”。每个 2 分都要引用测试命令、手工步骤、代码位置或文档条目。