Failproof AI est conçu de sorte qu’un échec d’application soit visible plutôt que de permettre silencieusement des opérations risquées.
Diagnostiquer un blocage en mode échec-fermé
- Accédez à Admin → enforcement et ouvrez la machine.
- Vérifiez sa dernière connexion, le déploiement attribué et le déploiement signalé.
- Accédez à Observe → policy et ouvrez la session de la décision refusée.
- Confirmez si la raison indique une inaccessibilité du daemon, un écart de version, ou la politique elle-même.
Relancer failproofai config met à jour et redémarre le daemon après une mise à jour du package. failproofaid, le daemon est le seul évaluateur. S’il est inaccessible ou si sa version de protocole ne correspond pas à celle du CLI, l’évaluation des hooks échoue en mode fermé. L’action est refusée avec une raison qui invite l’opérateur à vérifier ou mettre à jour le daemon.
Avant la configuration du daemon, les hooks évaluent les politiques en cours de processus. Une fois la configuration du daemon enregistrée, Failproof AI ne bascule pas silencieusement vers un second évaluateur en cas de défaillance du daemon.
Réagir à une décision en mode échec-fermé
- Exécutez
failproofai config --status.
- Si les versions diffèrent, relancez
failproofai config après avoir mis à jour le package.
- Si le daemon est inaccessible, inspectez l’état de son service et les journaux locaux.
- Ne reprenez le travail de l’agent qu’après avoir vérifié qu’un chemin d’évaluation des politiques connu est opérationnel.
Ne réessayez pas l’action bloquée de manière répétée. Une réponse en mode échec-fermé signifie que le système n’a pas pu établir que l’action était sûre.
Un pack ne se charge pas
Une machine à qui l’on a demandé d’appliquer un pack, et qui ne peut pas l’exécuter, refuse plutôt que de continuer silencieusement. Le déclencheur est une attente enregistrée, jamais une attente vide : une machine sans pack installé reste silencieuse, tandis qu’un pack déclaré qui ne peut pas se résoudre — ou qui enregistre moins que ce que son manifeste déclare — entraîne un refus.
Le refus est ciblé, contrairement à un daemon inaccessible. Un daemon inaccessible signifie qu’aucune évaluation n’a eu lieu, et donc que rien ne peut être considéré comme sûr. Un pack qui ne se charge pas dispose d’un ensemble énumérable de guards manquants, car chaque politique déclarée porte son propre match — il refuse donc uniquement les événements et outils couverts par ces politiques, et tout le reste continue normalement.
Il ne se déclenche pas pour :
- un pack
observe, qui évalue et écarte par construction
- des politiques que vous n’avez jamais adoptées, ou explicitement désactivées
- un pack que le chargeur n’a jamais reçu, où « aucun enregistrement » ne peut être distingué d’un saut délibéré
- une pause de session active
- un délai d’expiration de chargement, qui est transitoire — un moment de disque lent ne doit pas entraîner un refus jusqu’à ce qu’un humain intervienne
UserPromptSubmit instruis plutôt que de refuser, quelle que soit la politique manquante déclarée. Un refus général l’inclurait et vous bloquerait hors de l’agent qui pourrait résoudre le problème.
Que faire
La liste signale un pack installé dont l’enregistrement d’installation ou le condensé ne correspond plus, et en indique la raison. Elle n’importe pas le pack, donc un pack qui échoue uniquement au chargement — en enregistrant moins que ce que son manifeste déclare — apparaît normalement dans la liste ; le refus ci-dessous est ce qui identifie ce cas. Dans tous les cas, réinstallez-le (failproofai policies add <source>) ou supprimez-le (failproofai policies remove <publisher/name>) — le supprimer retire l’attente, et le refus s’arrête avec elle.
Le refus lui-même est attribué à pack/failproofai-pack-unavailable, ce qui prend le dessus sur les politiques qui ont bien chargé, de sorte qu’un appel d’outil bloqué nomme le pack manquant plutôt que le guard survivant qui se serait déclenché en premier. 
