我审计了自己的智能体，寻找'存在但不覆盖默认路径的防护措施'。我在一个代码库中发现了九个这样的问题。

两周前，我在这里发帖讨论了一个默认行为，它让我的智能体在未更改任何文件的情况下报告成功。你们中的一些人对此进行了拆解，其方式比修复本身更有用——最尖锐的观点是，一旦运行持有在检出之外产生效果的工具，空的差异并不能证明没有发生任何事情。那个讨论串促使我去寻找这种错误的形态，而不仅仅是具体实例。 这种形态是：规则写在一个地方，却没有应用于旁边的东西。我找到了九个。一个例子，全部来自同一个代码库：一个工具允许列表被文档描述为'在每个表面都应用'，但有三个调用点，其中没有一个是cron守护进程使用的那个。配置选项被接受、验证并忽略。治理围栏根本无法开启：开启它会在导入时杀死CLI。从未有人在启用它的情况下运行，所以没人发现。五个JSON存储执行读-修改-写操作而没有锁。两个进程，第二个静默地擦除了第一个的工作。其中一个是技能存储，所以一个学习到东西的运行可能被同一个学习运行擦除。一个环境变量被读取为两种不同的含义，这破坏了它所有六个合法值。 它们共同之处在于，没有一个会失败。每一个都通过测试、通过审查，并产生绿色的运行。有三个调用点的允许列表不会抛出异常，它只是不进行防护。未加锁的存储不会损坏，它只是丢失数据。这个通用的修复，也是本文中唯一值得借鉴的部分：构建门禁必须列出豁免项，而不是义务项。一个枚举应覆盖内容的检查在有人添加第十项时就会失败开放。一个枚举允许不覆盖内容的检查则会失败关闭：新项不在豁免列表上，因此构建会中断，添加它的人必须将其连接起来或写下原因，在差异中供人审查。 我现在有四个这样的检查。一个拒绝任何使用未通过受管配置文件注册表构建的智能体。一个拒绝写入声明区域之外的内容。一个拒绝没有类别的技能卡。每个大约十五行，它们是我相信下一个实例会被捕获的唯一原因。 我仍然不确定的事情，并真心希望得到意见：豁免列表是一个可以写下'尚未'然后忘记的地方。我的豁免在注释中有记录，但没有过期时间。有没有人让过时的豁免产生一些成本，而不发明一个没人遵守的流程？