sdc-review

name	sdc-review
description	Use when implemented code or a complete SDC change needs an independent engineering review.

Skill: SDC 代码审查 sdc-review

触发条件

当用户输入以下任一内容时，自动触发本技能：

• sdc-review
• "帮我审查代码"
• "代码质量检查"
• "看看有没有问题"

核心使命

像资深工程师一样审查实际 diff 和相关上下文，优先发现具体缺陷、架构风险、安全风险、兼容性问题和维护成本。

Brownfield/Legacy 项目还必须复核实际改动是否符合当前 change 的 impact.md。

Reference Loading

Load only what is needed:

• Role contract: ../../sdc-references/role-contracts.md, section sdc-review.
• Review gate: ../../sdc-references/delivery-gates.md.
• Shared evidence and stop-line rules: ../../sdc-references/workflow-standards.md.
• Expert routing: ../../sdc-references/expert-routing.md.
• Legacy impact review: ../../sdc-references/legacy-impact-gate.md.
• Artifact output contracts: ../../sdc-references/artifact-output-contracts.md.
• Execution orchestration and reviewer independence: ../../sdc-references/execution-orchestration.md.

审查范围

必须覆盖：

• Correctness：行为是否满足 REQ/AC，是否有边界遗漏。
• Architecture：模块边界、依赖方向、职责拆分、过度设计。
• Security：输入校验、权限、敏感信息、注入、危险 API。
• Data and contracts：数据迁移、公共接口、兼容性。
• Knowledge drift：实际 diff 是否改变产品/技术事实但未记录到 knowledge-candidates.md 或 archive 建议。
• Common Ground drift：实际 diff 是否改变共享假设，或是否把 OPEN/WORKING 当作事实。
• Expert routing coverage：实际 diff 是否触发了 data/security/api/test/legacy 等专家视角但未覆盖。
• Artifact output coverage：实际 diff 是否触发流程、集成、API、数据、UX、测试、部署或 AI 参与说明，但 design/context-pack/check 中没有对应产物或 N/A 证据。
• Performance：明显低效、N+1、内存或并发风险。
• Maintainability：命名、重复、复杂度、错误处理、注释质量。
• Legacy impact：实际 diff 是否超出 impact.md。

Findings 规则

• Findings 先行，按严重程度排序。
• 每个 finding 必须有文件/行号、影响、修复建议。
• 审查必须只读，不得修改 working tree、index、HEAD、branch、plan 或 review package。
• Task review 必须分别给出 Spec Compliance 和 Code Quality 结论；diff 无法证明的要求列为 Cannot verify from diff。
• 不接受 controller/implementer 对 finding 的忽略、压制或预先降级；plan-mandated defect 交给用户裁决。
• 不要编造问题；没有问题就明确说没有发现阻塞问题。
• 将 confirmed defects、risks、optional improvements 分开。
• 测试缺口和上下文限制要明确写出。

输出格式

🔍 SDC 代码审查报告
==================================================

## 严重问题
| 文件 | 位置 | 问题 | 影响 | 修复建议 |

## 警告问题
| 文件 | 位置 | 问题 | 影响 | 修复建议 |

## 可选改进
- ...

## 老系统改造点与影响点分析
- 适用：
- impact.md 来源：
- 实际改造点：
- 与 impact.md 不一致或新增的影响：
- 残余风险：

## 知识库影响
- 产品知识是否变化：
- 技术知识是否变化：
- Common Ground 是否变化：
- Expert Routing 是否变化：
- 是否需要补 `knowledge-candidates.md`：

## 测试/上下文缺口
- ...

## 结论
👉 ...

质量红线

• 问题必须具体到文件和行号。
• 严重问题必须说明后果和修复建议。
• 无问题时不得为了凑数编造 finding。
• 遗留项目实际 diff 超出 impact.md 必须标记为严重风险。
• 高风险 diff 缺少对应专家视角或标准覆盖时必须标记为风险。
• Critical/Important finding 或影响验收的 Cannot verify 未解决时不能 Approved。