Auditer les sessions passées (bêta)

​

Lancer l’audit

npx -y failproofai audit

failproofai audit

failproofai

​

Ce que vous obtenez

1. Affiche — l’identité de votre agent en un coup d’œil : son archétype (l’un des 8 — optimist, cowboy, explorer, goldfish, paranoid architect, precision builder, hammer, ghost), ses mots-clés de persona, la rareté de cet archétype, et un score de 0 à 100 avec un niveau (S jusqu’à bottom tier). Conçue pour être partagée — postez sur X ou LinkedIn, ou téléchargez en PNG.
2. // strengths — ce que votre agent fait déjà bien, exprimé en chiffres réels issus du scan (ex. : taux de tool-call propres, 0 tentative de push vers main), affiché uniquement lorsque la politique concernée n’a aucune infraction.
3. // quirks — ce qui s’est glissé : un tableau classé des comportements que failproofai aurait interceptés — quand cela s’est produit pour la dernière fois, ce qui a glissé (et la règle intégrée qui l’aurait bloqué), sa sévérité, et la fréquence d’apparition (new / recurring / N× seen).
4. // how to improve — la liste des correctifs recommandés : une ligne par politique avec un failproofai policy add <slug> à copier-coller, plus un bouton install all qui active toutes les recommandations d’un coup et affiche votre score projeté si vous le faites.
5. // come back better — adoptez la bonne habitude : configurez un rappel par e-mail (3d / 7d / 14d / 30d) ou relancez l’audit maintenant, et invitez un ami à effectuer son propre audit (envoyé depuis failproof.ai, avec vous en Cc). Les rappels et invitations nécessitent une connexion.

​

Audits planifiés

[audit]
auto = true
interval_days = 7

• Le calendrier est basé sur l’horloge murale, ce qui lui permet de survivre aux suspensions et redémarrages : un ordinateur portable qui était en veille au-delà de son heure prévue s’exécute une seule fois au réveil, sans rattrapage en file.
• Chaque exécution est un processus distinct à faible priorité (nice 19) — jamais sur le chemin des hooks du démon, qui reste libre pour répondre aux appels d’outils.
• Un scan est ignoré si failproofai audit ou la relance depuis le tableau de bord est déjà en cours ; il est retenté peu après plutôt que traité comme un échec.
• La progression est écrite dans ~/.failproofai/state/audit-schedule.json (dernière exécution, prochaine échéance). Ce fichier appartient au démon — modifiez la cadence dans config.toml.

​

Détecteurs propres à l’audit

​

Caches

• Cache par transcription dans ~/.failproofai/cache/audit/<sha1>.json indexé par (mtime, size, engineVersion, detectorVersion) — invalidé automatiquement lorsque la transcription ou le code de politique/détecteur change. Chaque entrée stocke également un horodatage cachedAt comme métadonnées TTL (non incluses dans la clé de cache) ; les entrées de plus de 7 jours sont rejetées à la lecture afin que des résultats anciens ne survivent pas à l’évolution des détecteurs.
• Cache du résultat global dans ~/.failproofai/audit-dashboard.json (mode 0600). Permet au tableau de bord de s’afficher instantanément lors de la navigation sans relancer le scan. Également rejeté à la lecture au-delà du TTL de 7 jours — /audit revient alors à son état vide et invite à relancer une analyse fraîche. Cliquez sur [ re-audit now ] en bas du rapport pour actualiser — la relance envoie noCache: true, ce qui contourne le cache par transcription et rescanne toutes les transcriptions au lieu de retourner le résultat mis en cache ; l’exécution diffuse sa progression via une bannière persistante en haut et remplace le résultat en place en cas de succès (sans rechargement de page ; un échec de la relance conserve le rapport précédent).

​

Remarques

• Aucune mutation. L’audit se rejoue en mode lecture seule. warn-repeated-tool-calls est ignoré car son fichier annexe par session serait sinon modifié.
• Politiques de workflow ignorées. Les politiques require-*-before-stop ne se déclenchent que sur les événements Stop et s’exécutent via execSync contre l’état git en direct — elles n’ont pas d’interprétation significative du type « qu’aurait-il pu se passer en 2025 », et n’apparaissent donc pas dans les comptages d’audit.
• Politiques personnalisées ignorées. Les hooks personnalisés fournis par l’utilisateur ne sont pas rejoués (ils peuvent avoir changé depuis la session d’origine).