自指悖论：修好之后，就再也测不到修好的那条路

一个修复一旦真的生效，那条被修复的路径就再也不会被触发，于是你永久失去了证明它修好的机会。应对办法是把验证搬离线，固定历史产物做回放基线，并强制每个检查器自己说出验证了什么。

一、第一类自指：修复让触发条件消失

守卫子系统末段把它写成了纪律，这类修复一旦生效，真实场次永远不会再触发被修路径，只能靠离线回放覆盖，改动前后必跑，不是可省的仪式。

推论有点吓人：在这类代码上，「先跑再说」和「根本不跑」在结果上无法区分。所以必须先跑改动前的那一次，那是你唯一能证明这条路曾经存在过的证据。

另一条：两条被打断的路径此前从未被真跑覆盖过。零不一定是好事，零也可能意味着这条路径从来没被测过。

二、第二类自指：检查器说自己没问题

verify_all.js 存在的理由写在开头注释里，一次性脚本靠人记住，于是一个什么都测不出来的重音检测器存活了好几个会话，报零被读成「没有发现重音」，真相是「这个检查从未触发」。

防线：子脚本退出码 0 但输出里没有 VERDICT 行时不得报 PASS，而是回显末行输出并标记「光有退出码零不算证据」。

本质一句话，退出码零只说明进程正常结束，不说明它验证了什么。

三、硬闸门与软闸门

判据不是「重不重要」，而是它依赖什么。

注释给的理由很硬：把依赖在线服务的检查做成硬门，意味着语音合成服务打个嗝就一场都跑不了，等于把观测手段变成一条新的运行时依赖。

四、把时间冻住：离线回放基线

需求文档 v4 必读第 2 条，改任何指标相关代码前先跑 replay_check.js，当前无岗位，这是唯一的验证路径。

起因是岗位池耗尽后，一大批需求的验收都写着「跑一场看看」，于是改完无法验证，只能靠注释自证。

固定三场基线不得随意增删。三者申请编号相同，所以必须按目录名锚定，不能按申请编号。

取舍最值得学：三指标以子进程调用 echo_check.js，而不在这里重算——判据只写一份。比对九个字段，差异时打印旧值到新值。临时产物写系统临时目录即时删除，绝不写回基线产物。

五、已知与未知

已知：自指类修复是常态不是例外；检查器必须输出自己的结论；硬软分层依据是依赖强度；离线回放基线是当前唯一验证路径。

未知其一：快照冻结的是过去的自己与过去的平台行为。平台若改了脾气，快照告诉你的是「相对三个月前有没有变」，不是「这些变化在生产里是对的」。

未知其二：判据与阈值本身也是人写的。完美的覆盖仍可能给出百分之百的自信与零的信息量，那个测不出东西的重音检测器就是前科。

六、带走的判断

• 修复会把自己的触发条件删掉。 先记录当前风貌，再动手改，改完再对一次。改动前那一次不是走过场。
• 检查器的结论必须能被看见。 让它输出一行人类能读的结论，让没有结论的情况被标记而不是被忽略。
• 「零次」有两种读法，没发生，或者没测到。 一个从来没被覆盖过的分支，在文档里永远是好的。
• 依赖越少，越有资格当硬门槛。 别为了观察系统而给系统增加新的依赖。
• 判据只写一份，观测不许修改被观测对象，把阈值跟结果一起存档。 这三件事决定了几个月后你还能不能回答，这个结论到底证明了什么。

AGENTS.md 守卫子系统末段（自指悖论纪律）· 常用命令节；autobot/verify_all.js（硬软分层与 noVerdict 判定）；autobot/replay_check.js（三固定基线、判据唯一实现、九字段比对）；autobot/docs/REQUIREMENTS-DEV.md v4 必读第 2 条。