Failproof AI は、強制適用の失敗が無音でリスクのある操作を許可するのではなく、明示的に可視化されるよう設計されています。
失敗クローズ（failure-closed）ブロックの診断
- Admin → enforcement に移動してマシンを開きます。
- 最後のチェックイン、割り当てられたデプロイメント、および報告されたデプロイメントを確認します。
- Observe → policy に移動して、拒否された決定のセッションを開きます。
- 理由がデーモンの到達可能性、バージョンの不一致、またはポリシー自体を示しているかを確認します。
failproofai config を再実行すると、パッケージのアップグレード後にデーモンが更新・再起動されます。failproofaid を使用するよう設定されたマシンでは、デーモンが唯一の評価者です。デーモンに到達できない場合、またはそのプロトコルバージョンが CLI と一致しない場合、フック評価は失敗クローズとなります。アクションは拒否され、その理由にはオペレーターにデーモンの確認または更新を促すメッセージが含まれます。
デーモン設定の前は、フックはプロセス内でポリシーを評価します。デーモン設定が記録されると、Failproof AI はデーモンが失敗した際に第二の評価者へ無音でフォールバックすることはありません。
失敗クローズ（failure-closed）の決定への対応
failproofai config --status を実行します。- バージョンが異なる場合は、パッケージを更新してから
failproofai config を再実行します。
- デーモンに到達できない場合は、サービスの状態とローカルログを確認します。
- ポリシー評価のパスが正常であることを確認してからエージェントの作業を再開します。
ブロックされたアクションを繰り返し再試行しないでください。失敗クローズの応答は、システムがそのアクションの安全性を確立できなかったことを意味します。
パックが読み込まれない場合
パックを強制適用するよう指示されたマシンがそれを実行できない場合、静かに継続するのではなく拒否します。トリガーとなるのは記録された期待値であり、空の期待値ではありません。パックがインストールされていないマシンは無音のままですが、宣言されているにもかかわらず解決できないパック、またはマニフェストで宣言された数より少ないガードしか登録しないパックは拒否されます。
この拒否は、到達できないデーモンとは異なり限定的です。デーモンに到達できない場合は評価そのものが行われておらず、何も安全であるとはわかりません。読み込めないパックには、宣言されたポリシーごとに独自の match があるため、欠けているガードのセットが列挙可能です。つまり、それらのポリシーが対象とするイベントとツールのみ拒否され、それ以外はすべて続行されます。
以下の場合には発動しません：
observe パック（構造上、評価して破棄します）- 採用していないポリシー、または明示的に無効にしたポリシー
- ローダーが受け取れなかったパック（「登録なし」は意図的なスキップと区別できません）
- アクティブなセッションの一時停止
- 読み込みタイムアウト（これは一時的なもので、ディスクの一瞬の遅延のために人が介入するまで拒否を続けるべきではありません）
UserPromptSubmit は、欠けているポリシーが何を宣言していたかにかかわらず、拒否の代わりに instruct を行います。一括拒否では問題を修正できるエージェントへのアクセスも遮断してしまうためです。
対処方法
このリストは、インストール記録またはダイジェストが照合できなくなったインストール済みパックにフラグを立て、その理由を表示します。パックのインポートは行わないため、読み込んだ後にのみ失敗するパック（マニフェストが宣言した数より少ないガードしか登録しないもの）は通常どおりリストされます。その場合は以下の拒否によって特定されます。いずれの場合も、パックを再インストール（failproofai policies add <source>）するか、削除（failproofai policies remove <publisher/name>）してください。削除すると期待値が取り下げられ、拒否も停止します。
拒否自体は pack/failproofai-pack-unavailable に帰属し、これは読み込まれたポリシーよりも優先されます。そのため、ブロックされたツール呼び出しは、最初に発動した既存のガードではなく、欠けているパックを示します。 
