终态 Diff 代码审查

要解决什么问题

对一段 commit 范围（例如 main..feature 或 ..HEAD）做代码审查时，如果按「每个 commit 单独看 diff」，很容易报出一堆中间态问题：早期 commit 引入的临时破坏、会在后面 commit 里被修掉；审查结论会和「合并后实际长什么样」不一致，浪费讨论成本，也可能漏掉终态里仍存在的真实风险。

本技能要求：只审查范围应用完毕后的最终代码树，把同一段 range 内已被后续 commit 修复的问题从 findings 里排除；除非用户明确要求，否则不在 review 过程中改代码。

技能如何工作

1. 确认审查范围：用户给出精确 range 就用原样；只给分支时，相对合理的目标分支算 merge base，目标分支不明确再追问。说明工作区是否有未提交改动——未纳入 range 时通常不在「纯 commit-range review」内。
2. 先建终态图景再下判断：跑 git diff --stat、git diff --name-only，并在 HEAD 上读相关文件的完整内容，而不只看 patch hunk；沿调用链、测试、配置、迁移与对外契约跟读。
3. 按最终行为审查：优先 P0～P3 级别的 bugs、回归、数据丢失、安全、兼容性破坏、并发与资源泄漏、以及高价值测试缺失；不纠结 commit 顺序、临时 breakage、中间实现细节——除非它们仍体现在最终树里。
4. 能验则验：对变更面跑有针对性的测试、编译或静态检查；若无法执行，明确写出没跑什么、为什么。

输出以 findings 为先、按严重度排序；每条含严重度、终态文件路径与行号、可观察风险、具体修复方向。若无阻塞项，应明确说明，并交代验证边界或残余风险。

适用边界与常见误用

• 用户要的是 final state，不是「逐 commit 考古」；勿把 range 内已修复的问题再报一遍。
• 勿只引用 diff 上下文——若 HEAD 上完整文件或调用方上下文会改变行为，必须以终态为准。
• 勿在未做验证或未说明验证范围的情况下宣称「范围干净」。