暗黑裁决庭

要解决的问题

把多角色评审做成角色扮演，是这类流程最常见的失败模式：角色越多，越容易用流程仪式替代实际证据。典型表现包括：把任务描述或提交说明当作实现事实，不读真实 diff、源码和配置；跨文件、跨端或批量改动只凭“搜过了”“测试通过”宣称完成，拿不出覆盖账本；前后端契约同变却只签一端；敏感数据链路看到界面打码就关闭安全审查；修完一个问题就宣布完成，其余审查单元被静默重置。

核心能力与关键步骤

先核事实，不采信二手描述。 审查前读取任务要求、真实 diff、源码、配置与测试，描述和提交说明不算实现事实。

按风险投入，不搞一刀切。 Lite / Standard / Strict 三档模式，默认取能覆盖风险的最低档；命中鉴权、隐私、敏感数据外发、LLM/RAG/Agent 链路、资金、生产发布等场景强制 Strict，且不得自行降级。

两个账本兜底完整性。 Standard/Strict 动手前先建项目属性账本，先确认 i18n、无障碍、鉴权、多租户、SSR 等横切属性是否存在并留证据；再建变更覆盖账本，把 source、transform、sink、consumer、test、docs 逐项登记。

全局队列防止半途而废。 受影响表面各自登记为审查单元，前端、后端、共享契约分开销账，互不代签；敏感数据链路另设 security/data-egress 单元，功能测试通过但它未审完就不能关闭它。

双轮对抗而非走过场。 同一任务内至少完成两轮方法不同的审查：第一轮覆盖审查找全影响面，第二轮更换搜索方向与反证手段，专查遗漏、修复副作用和错误假设。第二轮若改动了产物，还要追加关闭轮验证最终状态。

发现即修。 显式调用本技能意味着直接修复已确认问题，Blocker/High 立即修；这样修复成为默认语义：

Standard / Strict 流程为：事实基线 → 成功标准 → 选模式并完整加载参考 → 建两个账本 → 冻结初始队列 → 最小方案 → 实施留证 → 第一轮全单元发现 → 自动修复扩面 → 轮次闸门对账 → 第二轮差异化复审 → 验证交付。中断或上下文压缩后从队列恢复，不凭记忆宣布完成。

适用边界

• 未显式调用本技能、只说普通“审查”时默认只读；用户明确“只读”时永远优先于默认修复。
• 同一 Agent 的多视角检查只能叫“差异化复审”，宣称独立 Agent 需环境支持并获得授权。
• “未发现问题”是合法输出，但必须说明检查范围和证据；不得为满足流程编造缺陷。