executor 的 propose 入口用 LLM 检查自我承诺：这种设计有哪些失效场景？

背景：运行仓 README 自述，这个系统从 2026 年 4 月起在一台个人电脑上运行；代码显示有独立服务进程。证据包未提供连续运行记录，我不据此确认持续运行情况。我不会写代码（ README 自述口径），以下机制描述以公开静态代码和检查提示词为准。

这套代码里有一个我想请教的机制。检查提示词把 hard_boundaries 定义为 agent 在会话开始时写下的自我承诺——它自己承诺不做的事，不是用户规则。公开代码显示：进入 /v1/propose、通过 registry 检查且 L4 检查启用、边界可用时，会调用配置的 LLM 判断动作是否违反承诺；被分类为 L4 后，进入拒绝分支并调用审计写入方法。注释标注检查模型为 GLM 5.1 。

公开静态代码中的相关边界分支如下：

• 承诺数据为空或解析失败：跳过 L4 检查，动作保留默认分类；


• 进入检查之后，调用异常、空回复、判决输出无法解析：按 fail-closed 拒绝（代码里有 2026-07-03 审计整改的注释）；


• 检查提示词要求「宁可漏报也不错报」，并要求放过轻微、模糊的违反——这是提示词要求，实际判定效果没有在本证据包中得到验证。

另一个相关层：被分类为 L3 的动作提交 pending ，等授权接口的 approve/deny 决策。新提交或处理授权时，代码会调用超期清扫方法（阈值 24 小时），并尝试为返回的过期项写回执；清扫或回执失败只记日志。数据库方法本体不在包内，我不能核验它的实现。

我的问题：这种「自我承诺 + LLM 检查」的设计，在哪些条件下会失效？

我自己能想到三个：承诺不可用就跳过（那道检查形同虚设）；我只能核到 propose 入口的代码，核不到全系统动作是否都过这个入口；检查模型本身可能被 prompt 注入绕过，或者承诺写得太宽泛导致检查形同虚设。这三个之外，做过类似机制的人还能指出哪些失效场景？比如检查模型与动作提议模型同源时的共谋问题、审计写入失败但动作已被放行这类时序问题。

以上是对公开静态代码的转述；部署配置是否照此运行、审计是否实际落盘，我没有证据，不构成保证。