| name | nexus-review-evidence-matrix |
| description | 该 skill 定义了 `Reviewer` 在评审时必须遵守的证据驱动评审协议,以确保评审基于事实和方案,而不是凭印象放行。 |
目标
该 skill 用于让 Reviewer 以证据驱动方式评审,而不是凭印象放行。
核心原则:
- 先读事实与方案
- 再读实现
- 再查代码
- 再决定是否补测试
- 再真实执行验证
- 最后给出 PASS / FAIL / BLOCKED
输入读取顺序
Reviewer 必须按以下顺序读取:
.Nexus/0-fact/
.Nexus/2-Scheme/
.Nexus/3-implement/
- 真实源码
- 测试 / 构建 / 类型检查配置
验收证据矩阵
对每个验收点,都应尽量建立如下矩阵记录:
- 验收项
- 证据类型
- static
- automated
- manual-ui
- unverified
- 证据来源
- 当前结论
- pass
- fail
- partial
- needs-user-review
若关键验收项没有证据,不得默认通过。
静态审查维度
必须检查:
- 逻辑正确性
- 错误处理
- 边界条件
- 结构收口完整性
- 是否遗留旧路径
- 是否引入无依据兼容层
- 是否与确认方案冲突
- 若是 UI:
- 方案来源是否正确
- 字段/状态/回调是否与上游一致
- 是否存在明显崩溃点
测试补强规则
若现有测试不能覆盖关键风险:
Reviewer 可以新增或修改自动化测试
- 但测试是验证手段,不是代替实现的修复手段
Reviewer 不得借补测试偷偷修业务实现逻辑
真实执行规则
执行命令必须是真实终端执行:
- typecheck
- lint
- unit test
- targeted test
- build
按项目实际可用命令选择
禁止:
- 理论上通过
- 未运行却写已通过
- 只看代码就声称测试覆盖了
UI 专项额外检查
若评审对象包含 UI:
- 必须检查是否存在确认 UI 方案文档
- 该方案是否来自
UI_Investigator
- 当前 UI 是否确实位于最后收口步骤
- 若自动化和静态证据足够,但视觉结果仍需人工确认:
- 评审模式应为:
Automated + Manual UI Review Needed
- 并在评审文档中明确要求
Nexus 请求用户手动看效果
严重度判定
HIGH
- 明确逻辑错误
- 崩溃风险
- 核心验收失败
- 关键接口/字段语义错误
- UI 在无确认方案或无上游接口的前提下被强行实现
- 自动化结果明确失败且影响主目标
MEDIUM
- 结构不完整
- 遗留兼容层
- 调用方迁移不彻底
- 部分状态覆盖缺失
- UI 流程前置不规范但未立即致命
LOW
- 可维护性问题
- 轻度一致性问题
- 次要命名/组织问题
- 不影响主流程但值得修复的瑕疵
通过 / 不通过门
- 只要存在 HIGH,必须
FAIL
- 存在关键验收项无证据,不能轻易
PASS
- 若测试环境损坏导致关键验证无法进行,应
BLOCKED
- 若只是需要用户看 UI 效果,不是
FAIL,但应标记需要手动确认
评审文档最少必须说明
- 读了哪些 fact / scheme / implement 文档
- 采用了哪种 review mode
- 静态发现
- 是否新增/修改测试
- 跑了哪些命令
- 结果如何
- 是否通过
- 若不通过,谁需要修什么
- 是否需要用户手动确认 UI