38 lines
1.7 KiB
Markdown
38 lines
1.7 KiB
Markdown
# 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` 后，功能才允许进入发布状态。
|