Failproof AI 的设计原则是：强制执行失败时应清晰可见，而非静默放行存在风险的操作。
诊断失败关闭（failure-closed）阻断
- 前往 Admin → enforcement，打开对应机器。
- 检查其最后签到时间、已分配的部署及上报的部署信息。
- 前往 Observe → policy，打开被拒绝决策所在的会话。
- 确认原因是守护进程可达性问题、版本不匹配，还是策略本身的问题。
升级软件包后，重新运行 failproofai config 可更新并重启守护进程。 failproofaid 的机器上，守护进程是唯一的评估器。若其不可达，或其协议版本与 CLI 不匹配，hook 评估将失败关闭。该操作将被拒绝，并附带原因，引导操作员检查或更新守护进程。
在守护进程配置之前，hook 会在进程内评估策略。一旦记录了守护进程配置，当守护进程出现故障时，Failproof AI 不会静默回退到其他评估器。
应对失败关闭决策
- 运行
failproofai config --status。
- 若版本不一致，更新软件包后重新运行
failproofai config。
- 若守护进程不可达，检查其服务状态和本地日志。
- 仅在确认策略评估路径正常后，再恢复智能体工作。
请勿反复重试被阻断的操作。失败关闭响应意味着系统无法确认该操作是安全的。
包无法加载
若一台机器被要求强制执行某个包，但该包无法运行，系统将拒绝操作而非静默继续。触发条件是已记录的预期，而非空预期：未安装任何包的机器保持静默；而已声明但无法解析的包——或注册项少于其清单声明的包——将触发拒绝。
与守护进程不可达不同，此拒绝的范围较窄。守护进程无法到达意味着根本未发生任何评估，因此无法确认任何操作的安全性。而无法加载的包具有可枚举的缺失守卫集合，因为每条已声明的策略都带有自己的 match——因此它只拒绝这些策略所覆盖的事件和工具，其余操作照常进行。
以下情况不会触发拒绝：
observe 包——其设计本身就是评估后丢弃- 从未启用或已明确关闭的策略
- 加载器从未收到的包——此时「无注册项」与刻意跳过无法区分
- 活跃会话暂停期间
- 加载超时——这是暂时性问题，一次磁盘响应缓慢不应触发拒绝直至人工介入
UserPromptSubmit 会使用 instruct 而非拒绝，无论缺失的策略声明了什么。全面拒绝会将其一并阻断，使你无法使用本可修复问题的智能体。
处理方法
该命令会列出所有已安装但无法加载的包，说明原因，并以非零状态码退出。随后，你可以重新安装（failproofai pack add <source>）或移除该包（failproofai pack remove <publisher/name>）——移除包会撤销预期，拒绝行为也将随之停止。 
