反例驱动的只读方案审查

适用

用户给来一份方案 / 任务卡 / 判据清单，要求“先审再实施”。目标：在不写文件的前提下，证明每条判据真的能失败、命令真的适用、验收层级没有被偷换。

1. 先核对授权与入口

• 本轮是只读审阅还是已授权实施？只读时零写入（含备份、队列、记忆、checkpoint）。
• 找到方案声称改动的真实代码入口/配置项；关键词存在不等于逻辑存在。
• 记录方案的验收判据，逐条编号。

2. 零写入探针

用纯函数 / 内存夹具验证，不落文件：

• Node stdin 或 node -e，避免 heredoc 反斜杠在传输中被改写；若 heredoc 失败，先区分传输失败与产品失败，不要把它算成方案缺陷。
• 直接调用真实导出的 API 或带锚点校验的源码函数；不手写桩冒充真实实现。
• 同一份内存夹具分别喂给“当前版”与“HEAD 基线版”，用独立期望值比对。
• 探针自身要有负对照：喂一个必然失败的输入，确认断言会红。
• 结束时核对内容未变（文件哈希/git status），证明零写入。

3. 逐条反证判据

对每条判据问：

1. 它读的是被测系统，还是探针自己刚写进去的夹具？
2. 去掉目标实现后它还会绿吗？会绿 ⇒ 假判据。
3. 关键词/字段存在是否被当成行为通过？改成行为断言或显式 UNVERIFIED。
4. 证据是否同源？同一份脚本既产生又核验，不能算独立复核。
5. 验收层级是否被偷换？静态 / 模拟 / 运行时 / 产物 / 原生宿主要分别标注。

4. 命令适用性

• 在真实 shell 里裸跑关键命令，记录退出码；管道会吞退出码，用 ${PIPESTATUS[0]} 或不用管道。
• Windows / Git Bash 的参数改写、路径转换、编码与行尾问题先排除。
• 命令依赖是否闭合：脚本引用的 client-root、测试导出、索引前置是否在隔离环境里存在；缺失会产生“未复现”的假结果。

5. 收敛判据：按覆盖，不按轮数

• 固定轮数（如“三轮无发现即收敛”）不是收敛判据；按覆盖矩阵收敛：每条判据都有正例、反例、负对照与证据层级。
• 新发现要回填到覆盖表；没有新覆盖就停，不要为凑轮数重复跑同一手段。
• 报告“审计通过”不等于“验收完整”；原始验收要求要逐项对账（源码、安装副本、真实调用、授权来源、产物证据）。

6. 输出：收敛后的任务卡

• 保留的判据、删除的假判据、新增的反例；
• 每条判据的命令与退出码；
• 未验证项与原因；
• 明确“这是审阅结论，不是实施授权”；实施需另行批准。

边界

• 只读审阅不修改方案文件、不更新状态、不调用 checkpoint。
• 不把本轮内存探针结果当成宿主端验证或已落地改进。
• 反例本身也要能失败；不能用一个恒真的反例证明判据有问题。

相关

• 通用证据纪律：verify-before-claim。
• 规则/技能冲突审计：rules-conflict-audit。
• 方案文档成文：vibecoding-doc。