# Review 审查规范

## 1. 两类 Review

### 代码 Review

以 PRD、设计、实施计划、Git diff和测试证据为输入，审查正确性、安全性、性能、数据一致性、契约兼容性和测试充分性。

### 开发规范符合性 Review

逐条检查代码开发规范和流程规范，包括中文注释、命名、文件拆分尺度、日志、错误处理、GitNexus前后门禁、中文提交、文档和回退材料。

## 2. 审查角色

- 优先由非实现者进行独立 Review。
- 个人项目没有独立审查者时，可以执行结构化自审，但必须在报告中标明 `reviewer_type: self`，不得伪称独立审查。
- 使用代理审查时，必须提供功能说明、PRD、设计、基线 SHA 和当前 SHA；只有用户明确授权多代理时才调用独立审查代理。

## 3. 严重程度

- Critical：可能导致数据错误、安全事故、核心功能不可用或不可恢复，必须修复。
- Important：会造成明显错误、回归、规范失效或重要测试缺口，必须修复。
- Minor：不阻塞当前功能，但应记录后续处理或接受理由。

## 4. 结论

Review 只能使用：

- `passed`：没有未解决的 Critical 或 Important，证据齐全。
- `changes_required`：存在必须修改的问题。
- `blocked`：缺少 PRD、代码、测试、环境或其他必要证据。

修复 Review 问题后必须记录修复提交和复审结论。代码变化会使旧的 GitNexus开发后报告失效时，必须重新更新图谱和影响报告。

## 5. 发布门禁

`review/code-review.md` 和 `review/standards-review.md` 均存在、非空且最终结论为 `passed` 后，功能才允许进入发布状态。