一条规则已经写进代码，不等于它真的会执行。
现有即时检查逻辑里，用于识别弱 Kill 条件的分支可能被前面的控制流直接绕过。把代码压缩成等价结构，大致是：
如果一行包含 "Kill:"：
continue
如果 Kill 的内容是 "待定"、"unknown" 或过短：
报告 weak_kill
第二个判断依赖这一行包含 Kill:，第一步却已经把这类行全部跳过。函数仍能正常返回，规则编号也确实存在，最需要被识别的弱值却到不了对应分支。
这把问题收得很窄：讨论规则应该多早失败之前，先证明检查分支真的可达。
一条存在于代码里、却可能永远不执行的规则
这个缺口不是规则理念问题，而是普通的控制流问题。设计目标可以正确，返回结构也可以完整，实际执行路径仍可能没有完成承诺。
更值得注意的是，现有历史黑盒案例中确实包含一项“弱 Kill 条件应失败”的检查，但它覆盖的是另一条完整验证路径。当前三份测试文件共 40 项，通过数量不能自动证明新增的即时规则入口也被覆盖。
这正好说明两种测试不能互相替代：
- 历史案例回归保护已有入口的退出契约；
- 针对即时规则的表驱动测试，才负责证明
continue前后的具体分支。
40 项测试的证据范围在《四十项测试的证据账本》中单独展开。本文只处理规则入口、控制流和反馈时机。
同一条约束有三个生效时机
| 时机 | 能取得的材料 | 适合处理的问题 | 不应承担的判断 |
|---|---|---|---|
| 保存或即时检查 | 当前文本与局部结构 | 缺少字段、弱值、数量上限、明确格式错误 | 业务结果是否真实 |
| 提交或收敛 | 完整任务结构与引用关系 | outcome、直接证据、状态转换是否合法 | 外部命令是否成功 |
| 任务结束后 | test、lint、typecheck、人工验收 | 代码或业务结果是否通过外部检查 | 文本是否表达完整 |
即时反馈的价值不在于“越早越强”，而在于局部信息已经足够时尽早指出确定性问题。需要仓库、进程、数据库或人工观察的判断，仍然要留给后面的验证阶段。
这也是《把架构规则写进 AI 真正会经过的地方》与本文的分工：前者解释规则为什么要进入工程入口，本文检查进入代码后的规则是否真的执行。
五条现有规则分别属于哪一层
当前入口包含五项检查：
- 收敛阶段必须有 outcome；
- 收敛阶段必须出现直接证据；
- 观察或干预阶段的假设需要可证伪条件；
- 活跃假设超过五条时给出 warning；
- 互斥假设的概率总和不能超过容差。
前两项更接近结构门禁。第四项是认知负担的经验阈值，不应默认升级成业务硬约束。第五项只有在“互斥”关系定义正确时才有意义。
阶段识别本身也有两种来源：优先读取显式 phase，缺失时再根据 outcome、intervention、prediction 或 hypothesis 等字段启发式推断。后者能够兼容不完整输入，也会带来误分类可能。讨论文字里偶然出现这些词，不应被悄悄升级成正式阶段事实。
因此，一条即时结果至少要保留规则编号、严重级别、命中行和阶段来源。只返回 pass / fail，会把规则本身的不确定性藏起来。
先验证控制流，再讨论规则价值
第一批补测不需要继续增加规则数量，直接覆盖现有分支即可：
| 输入 | 预期 |
|---|---|
Kill: unknown | 报告弱 Kill 条件 |
Kill: 待定 | 报告弱 Kill 条件 |
Kill: | 报告缺失或过短 |
| 一个可明确证伪的完整条件 | 不报告弱值 |
讨论文字中偶然出现 Kill | 不误判为正式字段 |
这些是根据控制流缺口提出的测试设计，不是当前套件已经通过的结果。
接入编辑器时，还可以先使用影子模式记录命中，不立即阻断。每次命中至少关联规则、脱敏片段、是否修改，以及后续任务级验证结果。只有这条信息路径存在，才能继续判断提前提示是否减少了后续失败。
这篇文章停在可达性
目前可以确认三件事：五条规则拥有独立 CLI 入口；弱 Kill 条件检查存在不可达风险；任务结束后另有 test、lint 和 typecheck 记录外部结果。
当前材料不能回答保存时调用延迟、真实误报率、命中后是否改变 outcome，也不能证明上表中的即时规则用例已经补齐。
所以本轮最先要修的不是阈值，也不是第六条规则，而是控制流与回归用例。一个从未执行的分支，不需要先争论它应该返回 warning 还是 error。