zeroz-lab Code Quality — 代码质量审查
入口/出口
- 入口: 已通过 Spec Compliance 审查的代码（功能完整）
- 出口: 代码质量审查报告（通过/不通过 + 五轴评分 + 改进建议）
- 指向: 通过 → ship 阶段；不通过 → 退回 build 修复质量问题
- 前置加载: CANON.md, verify-team-code-review-standards
- 输出路径:
docs/features/YYYYMMDD-<name>/04-review.md（质量审查部分） → ship-workflow-ship（通过时）或 build-workflow-execute（不通过时退回修复质量问题）
何时不使用
- 代码尚未通过 Spec Compliance 审查（功能不完整时不进入质量审查）
- 非软件产物（document/article/deck/visual 使用对应的 content-review 或 visual-review）
Iron Law
核心职责
评估已经功能完整的代码的实现质量。关心：逻辑正确性、可读性、架构合理性、安全措施、性能。不关心：spec 需求覆盖（Spec Compliance 职责）、功能完整性（Spec Compliance 职责）、scope creep（Spec Compliance 职责）。
审查流程
使用 verify-team-code-review-standards 技能执行五轴审查。
Step 1: 确认前置条件
确认代码已通过 Spec Compliance。接受以下证据：当前 /review 中刚完成的结果、04-review.md 中的 Stage 1 区块、或外部分派 auditor 的 PASS。不要要求 04-review.md 已存在（它通常是两阶段合并后的最终产物）。
无证据或不通过时，立即停止并告知用户先完成 Spec Compliance。
Step 2: 加载审查标准
加载 verify-team-code-review-standards，获取五轴标准：Correctness / Readability / Architecture / Security / Performance。
Step 3: 执行五轴审查
按 verify-team-code-review-standards 逐项检查。详细检查项见 rubric.md。要求：
- 每个轴必须有结论和证据引用
- Blocking / Important / Suggestion 必须分级
- 安全和正确性问题优先于可读性偏好
- 不能把测试通过当作代码质量通过
Step 4: 生成报告 + 判定
汇总五轴审查结果。完整报告模板见 report-template.md。
通过： 五轴全部覆盖 + 无 Blocking + Important ≤2 且有修复计划。 不通过： 有 Blocking 或 Important >2 无修复计划 → 退回 build 修复。 灰色地带： 代码风格遵循项目现有风格；性能只关注明显问题（N+1、无界循环）；架构只关注当前变更合理性，不要求重构整个项目。
验证证据
输出或记录必须包含：输入/来源、执行动作、验证结果、阻塞/回退。
验证失败处理
| 失败场景 | 处理方式 |
|---|---|
| Blocking 安全问题（XSS/注入/硬编码密钥） | 立即不通过，退回 build 修复 |
| Blocking 正确性问题（未处理错误/类型不安全） | 不通过，提供文件名+行号+问题描述 |
| Important >2 且无修复计划 | 不通过，要求制定修复计划 |
| 五轴未全部覆盖 | 审查不完整，补齐后再判定 |
| Spec Compliance 未通过但已进入质量审查 | 立即停止 |
| 发现问题属于 Spec Compliance 职责 | 转交 Spec Compliance Auditor |
常见说辞
| 说辞 | 现实 | 后果 |
|---|---|---|
| "这个安全问题不太可能被利用" | 安全问题没有"不太可能"，只有"已被利用"和"尚未被利用"。 | 在最糟糕时刻被利用。未修复 = 潜在安全事故 |
| "N+1 查询数据量不大" | 数据量会增长。今天 10 条，明天 1000 条。 | 等性能问题明显时修复成本远高于现在 |
| "这个函数虽然复杂，但我能看懂" | 代码是给整个团队看的。 | 6 个月后维护时忘记细节，复杂代码 = 维护困难 = 容易引入 bug |
| "架构问题只影响这一个功能" | 架构问题会传染。一个模块打破规则，其他会跟随。 | 最终导致架构混乱 |
违反字面规则就是违反精神。 没有灰色地带。
与 Spec Compliance 的边界
spec 明确要求的 = Spec Compliance；spec 未提及但应该有的 = Code Quality。例："函数没处理 null" → spec 要求 = Spec Compliance；spec 未提及 = Code Quality（Correctness 轴）。
红旗
- 代码中有明显的安全漏洞（XSS、SQL 注入、命令注入、硬编码密钥）
- 代码中有明显的正确性问题（未处理的错误、未验证的边界、类型不安全）
- 代码中有明显的性能问题（N+1 查询、无界循环、资源泄露）
- 审查者跳过某个轴，声称"不适用"
- 审查者在代码未通过 Spec Compliance 时进行质量审查
- 审查者将"功能缺失"标记为质量问题
验证清单
- 已确认代码通过 Spec Compliance 审查
- 已执行五轴审查（Correctness/Readability/Architecture/Security/Performance）
- 已标记所有 Blocking 问题
- 已标记所有 Important 问题
- 已提供清晰的修复建议
- 已生成质量审查报告
- 已判定通过/不通过
审查完成验证清单
- 五轴每个轴已给出评分（1-5）
- 每个扣分项有具体的文件名 + 行号 + 问题描述
- 所有发现已按 Blocking / Important / Suggestion 分级
- Blocking 问题有明确的修复建议
- 审查范围与 spec 需求清单一一对应
- 安全相关发现已转交 verify-quality-security（如有）
输出模板
完整报告模板见 verify-quality-code-quality/report-template.md。
### Code Quality Report — <feature-name>
**五轴评分**:
| 轴 | 评分 (1-5) | 关键发现 |
|----|-----------|---------|
| Correctness | [N] | [具体问题] |
| Readability | [N] | [具体问题] |
| Architecture | [N] | [具体问题] |
| Security | [N] | [具体问题] |
| Performance | [N] | [具体问题] |
**Findings Summary**:
| # | Severity | Category | Description | File:Line | Status |
|---|----------|----------|-------------|-----------|--------|
| 1 | Blocking | [轴] | [问题] | [位置] | Open |
**Verdict**: APPROVED / APPROVED_WITH_CONCERNS / REJECTED