Failproof AI 的设计原则是：执行失败时应显式可见，而非悄无声息地放行有风险的操作。
诊断失败关闭阻断
- 前往 管理员 → 执行，打开对应机器。
- 检查其最后一次签入时间、已分配的部署及上报的部署。
- 前往 观察 → 策略，打开被拒绝决策的会话。
- 确认原因是否报告了守护进程可达性问题、版本偏差，或策略本身的问题。
重新运行 failproofai config 会在软件包升级后更新并重启守护进程。 failproofaid 的机器上，守护进程是唯一的评估器。如果它不可达，或其协议版本与 CLI 不匹配，Hook 评估将失败关闭。操作会被拒绝，并附带原因，指引操作员检查或更新守护进程。
在守护进程配置之前，Hook 会在进程内评估策略。一旦记录了守护进程配置，当守护进程发生故障时，Failproof AI 不会悄悄回退到备用评估器。
响应失败关闭决策
- 运行
failproofai config --status。
- 如果版本不一致，更新软件包后重新运行
failproofai config。
- 如果守护进程不可达，检查其服务状态和本地日志。
- 仅在确认策略评估路径正常后，才继续进行 Agent 工作。
不要反复重试被阻断的操作。失败关闭响应意味着系统无法确认该操作是安全的。
策略包无法加载
如果一台机器被要求执行某个策略包，但无法运行它，系统会拒绝操作而非悄然继续。触发条件是已记录的预期，而非空预期：未安装任何策略包的机器保持静默，而已声明但无法解析的策略包——或注册数量少于其清单声明数量的策略包——则会触发拒绝。
这种拒绝是范围限定的，与守护进程不可达的情况不同。守护进程无法到达意味着根本没有进行任何评估，因此无从知晓任何操作是否安全。无法加载的策略包有可枚举的缺失守卫集合，因为每个声明的策略都携带自己的 match——所以它只拒绝这些策略所覆盖的事件和工具，其余操作正常进行。
以下情况不会触发拒绝：
observe 包，其设计本身就是评估后丢弃- 你从未采用或已明确关闭的策略
- 加载器从未收到的策略包，因为”无注册”与故意跳过无法区分
- 活跃会话暂停
- 加载超时（属于瞬态情况）——单次磁盘缓慢不应触发拒绝，直到人工介入
UserPromptSubmit 会使用 instruct 而非拒绝，无论缺失的策略声明了什么。全量拒绝会将其一并阻断，使你无法访问本可修复问题的 Agent。
处理方法
该列表会标记安装记录或摘要校验不通过的已安装策略包，并说明原因。它不会导入策略包，因此仅在加载时失败的包（注册数量少于清单声明）会正常显示在列表中；下方的拒绝信息才会指出该包。无论哪种情况，重新安装（failproofai policies add <source>）或移除（failproofai policies remove <publisher/name>）均可解决——移除操作会撤销预期，拒绝也随之停止。
拒绝本身归因于 pack/failproofai-pack-unavailable，其优先级高于已加载的策略，因此被阻断的工具调用会指向缺失的策略包，而非碰巧首先触发的某个存活守卫。 
