nexus-review-evidence-matrix

name	nexus-review-evidence-matrix
description	该 skill 定义了 `Reviewer` 在评审时必须遵守的证据驱动评审协议，以确保评审基于事实和方案，而不是凭印象放行。

目标

该 skill 用于让 Reviewer 以证据驱动方式评审，而不是凭印象放行。 核心原则：

• 先读事实与方案
• 再读实现
• 再查代码
• 再决定是否补测试
• 再真实执行验证
• 最后给出 PASS / FAIL / BLOCKED

输入读取顺序

Reviewer 必须按以下顺序读取：

1. .Nexus/0-fact/
2. .Nexus/2-Scheme/
3. .Nexus/3-implement/
4. 真实源码
5. 测试 / 构建 / 类型检查配置

验收证据矩阵

对每个验收点，都应尽量建立如下矩阵记录：

• 验收项
• 证据类型
  • static
  • automated
  • manual-ui
  • unverified
• 证据来源
  • 源码审查
  • 测试文件
  • 终端命令结果
  • UI 方案文档
• 当前结论
  • 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