智能体补丁门禁也需要组合自测

给自动补丁加上属性检查、测试冻结和夹具锁定，仍可能漏掉缺陷。dev.to 的一篇文章指出，单项保护都合理，组合后却可能因执行顺序和匹配键设计，把必须拒绝的问题降成暂缓处理。作者提出：将合成补丁送进完整门禁，逐项断言预期裁决，给门禁本身做测试。

目前能确认什么

属性检查用于验证程序应满足的约束；夹具是测试依赖的数据或样本；测试冻结则记录已知的不稳定失败，避免反复阻塞流程。

问题出在它们如何共同决策。节选中的旧门禁先查冻结记录，只要失败测试的名称命中，就返回 hold:freeze。此时，即使补丁违反属性或改动了受锁定的夹具，后续拒绝逻辑也没有机会执行。

已有豁免不能覆盖新缺陷。

作者给出的参考规则是：夹具漂移直接拒绝；属性违规优先于冻结；冻结必须同时匹配测试名和冻结时的断言签名。签名变化，应按新失败处理。

文中的八种案例是预期行为规范，不是真实流水线的测量结果。自测既要验证新门禁符合预期，也要确认旧逻辑无法通过整套案例。文章另披露了 MonkeyCode 产品推广背景，示例逻辑本身不依赖该产品。

我的判断

对接入 Agent 自动补丁的团队，检查重点应从「有没有这些检查」推进到「多个检查同时触发时，谁决定结果」。尤其要检查：冻结测试同时出现属性违规、冻结测试同时修改夹具时，最终裁决是否仍是拒绝。

这里还要区分 hold 和放行：节选证明旧逻辑会错误降级，不能据此认定所有流水线都会自动合并。

门禁自测通过，也不等于真实流水线安全。

节选末尾已指出，PatchCase 若偏离流水线实际输出，自测可能只验证了一个虚构模型。真实失败如何映射到这些字段、断言签名如何保持有效，现有信息还没交代完整；落地时，这两处连接比扩充案例数量更需要先查清。