四、审查体系：双轴 × 双轨审查模型（Dual-Axis & Dual-Track Review）
4.1 审查两轴定义（What to Review）
代码与文档变更均按风险开展双轴独立审查，审查前必须固定比较基线、变更差异、权威规范与需求来源。
| 审查对象 | Standards 轴：是否符合规范 (Compliance) | Spec 轴：是否满足需求 (Fulfillment) |
|---|---|---|
| 代码实现 | 架构分层、并发竞态、协程泄漏、错误通道、向后兼容性、假测试排查 | 业务意图吻合度、领域不变量、权限判定、异常恢复、验收映射、显式界定 OPEN 范围 |
| 技术文档 | 权威冲突、术语统一性、版本有效性、引用真实性、门禁执行主体、盲区声明 | 需求遗漏、逻辑歧义、状态机完备性、可判定验收口径、失败语义、未决假设、跨服务责任 |
| 交付记录 | 制品 Digest、验证证据范围、迁移校验和、配置引用安全、审批机制是否实际生效 | 本次实际交付范围、端到端业务验收证据、回滚/恢复前置条件、未覆盖场景声明 |
| Agent 治理事实 | 授权依据、身份归因、工具版本、权限拦截点、审计完整性与例外期限 | 工具动作是否落在本任务边界内；停止后副作用、未知结果及人工接管预案是否就绪 |
失败语义与“结果未知”处理规范
编写规格和开展审查时，至少区分以下状态，并说明各自可观察的证据：
- 确定拒绝（Definite Rejection）：系统明确拒绝业务受理；不得发生契约禁止的业务副作用，但可能写入审计或幂等记录，不能笼统称为“零持久化”。
- 确定未提交（Definite Not Submitted）：有可靠证据证明请求未进入受理路径，例如在本地发送前被拦截；仅凭超时或一次查询未找到，不能作此判断。
- 已受理在途（Accepted & Processing）：服务端已确认受理，处理尚未完成。
- 已确认终态（Confirmed Terminal Result）：已确认成功或失败；失败时仍须按契约核对部分副作用、资源清理与补偿状态。
- 结果未知（Result Unknown）：调用方因超时、断连或崩溃而无法确认实际结果；这是调用方的认知状态，不能覆盖服务端的业务状态。
注意
不得将“结果未知”直接判定为失败，也不得由客户端自动换键重发或盲目执行反向补偿：
- 必须保留原操作作用域（Tenant ID + Actor ID）、原请求幂等键及请求参数摘要；
- 优先通过只读查询核验原请求；查询不可用、未找到或超出保留期时继续标注不确定性。只有契约明确允许且幂等前提仍成立时，才可按规定使用原键同参重试；不得自行改键；
- 明确声明超时重试策略、同键同参/异参处理、数据保留期与跨重启恢复机制；
- 涉及资金场景时，必须核验不可变原凭证、唯一副作用、账务守恒、重启恢复屏障及权限漂移后的安全边界。
4.2 两条审查轨道与自动化支撑（Who Reviews）
自动化检查为两条审查轨道提供基础证据：执行确定性规则工具，产出结构化原始数据。
- Reviewer Agent 轨：使用独立上下文开展审查，减少实现过程中的既有判断影响；独立上下文不是准确性保证，结论仍须依据证据与反例校准；对照规范与需求分别产出两轴审查报告，逐项列出违规依据、具体代码/文档位置、触发条件与修改建议；
- 人类决策轨：负责重大业务目标的确认、架构权衡、风险接受及 OPEN 范围签署；凡命中 L3 级高风险红线，必须由对应的领域责任人独立签字审批（Sign-off）。
- 发现项定级：使用
BLOCKER（阻断）、WARNING（警告）、NIT（建议），写明位置、触发条件、依据与影响。 - 处置与复核：“接受、部分接受、拒绝、延期”表示处置决定；另记“待处理、已修待复核、已关闭”等解决状态。拒绝发现须提供反证并由审查者复核；非阻断项延期须有负责人和期限。所有有效且未解决的
BLOCKER均阻止合入，不能仅凭“接受风险”或调整标签关闭。修复后补充验证，变更审查结论时保留理由与记录。