failproofai 1.0.1-beta.1 → 1.0.1

package/.next/standalone/docs-old/fr/getting-started.mdx

@@ -0,0 +1,199 @@
+---
+title: Démarrage rapide
+description: "Installez failproofai, activez les politiques et laissez vos agents s'exécuter de manière fiable"
+icon: rocket
+---
+
+## Prérequis
+
+- **Node.js** >= 20.9.0
+- **Bun** >= 1.3.0 (optionnel - uniquement nécessaire pour compiler depuis les sources)
+
+---
+
+## Installation
+
+<CodeGroup>
+
+```bash npm
+npm install -g failproofai
+```
+
+```bash bun
+bun add -g failproofai
+```
+
+</CodeGroup>
+
+---
+
+## Démarrage rapide
+
+<Steps>
+  <Step title="Activer les politiques">
+    Les politiques sont des règles qui s'exécutent avant et après chaque appel d'outil d'un agent. Elles interceptent les commandes destructrices, les fuites de secrets et d'autres modes de défaillance avant qu'ils ne causent des dommages.
+
+    ```bash
+    failproofai policies --install
+    ```
+
+    Cette commande écrit des entrées de hook dans les CLIs d'agents installés (le `~/.claude/settings.json` de Claude Code, le `~/.codex/hooks.json` d'OpenAI Codex, le `~/.copilot/hooks/failproofai.json` de GitHub Copilot CLI, le `~/.cursor/hooks.json` de Cursor Agent, le shim de plugin généré par OpenCode dans `~/.config/opencode/plugins/failproofai.mjs` ainsi qu'une entrée d'enregistrement dans le tableau `plugin` de `~/.config/opencode/opencode.json`, le `~/.pi/agent/settings.json` de Pi, le `~/.hermes/config.yaml` de Hermes, le `~/.openclaw/openclaw.json` d'OpenClaw, le `~/.factory/hooks.json` de Factory Droid, le `~/.config/devin/config.json` de Devin CLI, le `~/.gemini/config/hooks.json` d'Antigravity CLI, ou le répertoire de plugins auto-découvert par Goose dans `~/.agents/plugins/failproofai/hooks/hooks.json`). Si plusieurs sont présents, vous serez invité à choisir ; passez `--cli claude codex copilot cursor opencode pi hermes openclaw factory devin antigravity goose` (n'importe quel sous-ensemble) pour ignorer cette invite.
+
+    La prise en charge de GitHub Copilot CLI, Cursor Agent, OpenCode et Pi est en **bêta** — installez avec `--cli copilot`, `--cli cursor`, `--cli opencode`, ou `--cli pi`. Hermes (hermes-agent, une passerelle Slack/Telegram) s'installe en portée utilisateur avec `--cli hermes` et est **également** une source d'audit hors ligne. OpenClaw (passerelle openclaw, un assistant multi-canaux auto-hébergé) s'installe en portée utilisateur avec `--cli openclaw` — l'application des règles passe par ses hooks de plugin en cours de processus (`before_agent_finalize` est une vraie barrière de fin de tour, ainsi les fonctions intégrées `require-*-before-stop` sont appliquées) — et est **également** une source d'audit hors ligne. Factory Droid (`droid`) s'installe avec `--cli factory` (portée utilisateur + projet) et est **également** une source d'audit hors ligne. Devin CLI (`devin`, Cognition) s'installe avec `--cli devin` (portée utilisateur + projet) et est **également** une source d'audit hors ligne. Antigravity CLI (`agy`) s'installe avec `--cli antigravity` (portée utilisateur + projet) et est **également** une source d'audit hors ligne. Goose (nom de code goose, Block) s'installe avec `--cli goose` (portée utilisateur + projet) — l'installateur dépose simplement un répertoire de plugin dans `~/.agents/plugins/failproofai/` que Goose auto-découvre, et il est **également** une source d'audit hors ligne.
+
+    ```bash
+    failproofai policies --install --scope project
+    failproofai policies --install --cli codex --scope project
+    failproofai policies --install --cli copilot --scope project
+    failproofai policies --install --cli cursor --scope project
+    failproofai policies --install --cli opencode --scope project
+    failproofai policies --install --cli pi --scope project
+    failproofai policies --install --cli hermes --scope user
+    failproofai policies --install --cli openclaw --scope user
+    failproofai policies --install --cli factory --scope project
+    failproofai policies --install --cli devin --scope project
+    failproofai policies --install --cli antigravity --scope project
+    failproofai policies --install --cli goose --scope project
+    failproofai policies --install block-sudo block-rm-rf sanitize-api-keys
+    ```
+  </Step>
+  <Step title="Vérifier">
+    ```bash
+    failproofai policies
+    ```
+
+    Affiche toutes les politiques, leur état d'activation et les paramètres configurés.
+  </Step>
+  <Step title="Lancer le tableau de bord">
+    ```bash
+    failproofai
+    ```
+
+    Ouvre un tableau de bord local à l'adresse `http://localhost:8020` où vous pouvez parcourir les sessions, inspecter les appels d'outils et gérer les politiques.
+  </Step>
+  <Step title="Lancer votre agent">
+    Démarrez Claude Code comme d'habitude. Si l'agent tente quelque chose de risqué, failproofai l'intercepte automatiquement. Laissez-le tourner sans surveillance et consultez ce qui s'est passé dans le tableau de bord.
+  </Step>
+</Steps>
+
+---
+
+## Fonctionnement des politiques
+
+Chaque fois qu'un agent exécute un outil, Claude Code appelle failproofai en tant que sous-processus :
+
+```text
+Claude Code  →  failproofai --hook PreToolUse  →  reads stdin JSON
+                                                 evaluates policies
+                                                 writes decision to stdout
+```
+
+Chaque politique retourne l'une des trois décisions suivantes :
+
+- **allow** - l'agent continue normalement
+- **deny** - l'action est bloquée, l'agent est informé de la raison
+- **instruct** - du contexte supplémentaire est ajouté à l'invite de l'agent
+
+<Note>
+Les politiques s'exécutent dans votre processus local. Rien n'est envoyé à un service distant.
+</Note>
+
+---
+
+## Configurer des politiques d'équipe avec les politiques basées sur les conventions
+
+La façon la plus rapide d'établir des standards de qualité au sein de votre équipe est la convention `.failproofai/policies/`. Déposez des fichiers de politique dans ce répertoire et ils sont chargés automatiquement — pas d'arguments, pas de modifications de configuration, pas de commandes d'installation.
+
+<Steps>
+  <Step title="Créer le répertoire des politiques">
+    ```bash
+    mkdir -p .failproofai/policies
+    ```
+  </Step>
+  <Step title="Ajouter des fichiers de politique">
+    Copiez les exemples de démarrage ou écrivez les vôtres :
+
+    ```bash
+    cp node_modules/failproofai/examples/convention-policies/*.mjs .failproofai/policies/
+    ```
+
+    Ou créez-en un nouveau :
+
+    ```js
+    // .failproofai/policies/team-policies.mjs
+    import { customPolicies, allow, deny, instruct } from "failproofai";
+
+    customPolicies.add({
+      name: "test-before-commit",
+      match: { events: ["PreToolUse"] },
+      fn: async (ctx) => {
+        if (ctx.toolName !== "Bash") return allow();
+        if (/git\s+commit/.test(ctx.toolInput?.command ?? "")) {
+          return instruct("Run tests before committing.");
+        }
+        return allow();
+      },
+    });
+    ```
+  </Step>
+  <Step title="Valider dans git">
+    ```bash
+    git add .failproofai/policies/
+    git commit -m "Add team quality policies"
+    ```
+
+    Chaque membre de l'équipe qui a failproofai installé récupère ces politiques automatiquement. Aucune configuration individuelle n'est nécessaire.
+  </Step>
+</Steps>
+
+<Tip>
+Validez `.failproofai/policies/` dans votre dépôt afin que toute l'équipe partage les mêmes standards. Au fur et à mesure que votre équipe découvre de nouveaux modes de défaillance, ajoutez des politiques et poussez-les — tout le monde reçoit la mise à jour au prochain `git pull`. Avec le temps, ces politiques deviennent un standard de qualité vivant qui ne cesse de s'améliorer.
+</Tip>
+
+---
+
+## Stockage des données
+
+Toute la configuration et les journaux restent sur votre machine :
+
+| Chemin | Contenu |
+|--------|---------|
+| `~/.failproofai/policies/local-policies/policies-config.json` | Configuration globale des politiques |
+| `~/.failproofai/hook-activity/` | Historique d'exécution des hooks (JSONL paginé) |
+| `~/.failproofai/logs/` | Journaux de débogage pour les erreurs de hooks personnalisés |
+| `.failproofai/policies-config.json` | Configuration par projet (validée) |
+| `.failproofai/policies-config.local.json` | Substitutions personnelles (ignorées par git) |
+
+---
+
+## Désinstallation
+
+```bash
+failproofai policies --uninstall
+```
+
+Supprime les entrées de hook de `~/.claude/settings.json`. Les fichiers de configuration dans `~/.failproofai/` sont conservés.
+
+---
+
+## Étapes suivantes
+
+<CardGroup cols={2}>
+
+<Card title="Configuration" icon="gear" href="/fr/configuration">
+  Portées et format des fichiers de configuration
+</Card>
+
+<Card title="Politiques intégrées" icon="shield" href="/fr/built-in-policies">
+  Les 26 politiques avec leurs paramètres
+</Card>
+
+<Card title="Politiques personnalisées" icon="code" href="/fr/custom-policies">
+  Écrivez vos propres politiques en JavaScript
+</Card>
+
+<Card title="Moniteur d'agents" icon="chart-line" href="/fr/dashboard">
+  Surveillez les sessions et examinez l'activité des politiques
+</Card>
+
+</CardGroup>

package/.next/standalone/docs-old/fr/introduction.mdx

@@ -0,0 +1,57 @@
+---
+title: "Failproof AI"
+description: "FailproofAI donne aux agents IA 39 politiques de défaillance intégrées qui détectent les boucles, les fuites de secrets, les appels d'outils destructeurs et bien plus encore, en une seule installation."
+---
+
+[![npm weekly downloads](https://img.shields.io/npm/dw/failproofai?style=flat-square&color=2ea44f)](https://www.npmjs.com/package/failproofai)
+
+Hooks et politiques pour la **gestion des défaillances IA**, la **récupération d'erreurs** et la **fiabilité des LLM**. Gardez vos agents IA fiables et en fonctionnement autonome avec **Claude Code**, **OpenAI Codex**, **GitHub Copilot**, **Cursor Agent**, **OpenCode**, **Pi**, **Hermes**, **OpenClaw**, **Factory Droid**, **Devin CLI**, **Antigravity CLI** et le **Agents SDK**.
+
+Les agents IA échouent de manière prévisible. Ils exécutent des commandes destructrices, laissent fuiter des secrets, dérivent hors de leur périmètre, se retrouvent coincés dans des boucles ou poussent directement sur la branche principale. Sans surveillance, de petites défaillances se transforment en pannes en cascade, en identifiants compromis et en travail perdu.
+
+FailproofAI résout ce problème grâce aux **politiques**. Ces règles s'accrochent à chaque appel d'outil de l'agent pour **détecter les défaillances**, **les atténuer** (bloquer, instruire, assainir) et **vous alerter** quand quelque chose nécessite votre attention. Un tableau de bord local vous permet de revoir chaque appel d'outil, chaque défaillance d'agent et chaque action de récupération après coup.
+
+Les transcriptions et l'évaluation des politiques restent sur votre machine. Les données ne sont envoyées que lorsque vous utilisez explicitement une fonctionnalité en ligne, comme les rappels d'audit authentifiés ou les invitations.
+
+## Démarrer
+
+<CardGroup cols={2}>
+
+<Card title="39 politiques intégrées" icon="shield" href="/fr/built-in-policies">
+  Bloquez les commandes destructrices, empêchez les fuites de secrets, maintenez les agents dans les limites du projet, et bien plus encore. Tout est disponible dès l'installation.
+</Card>
+
+<Card title="Politiques personnalisées" icon="code" href="/fr/custom-policies">
+  Rédigez vos propres règles en JavaScript avec une API simple allow / deny / instruct.
+</Card>
+
+<Card title="Moniteur d'agents" icon="chart-line" href="/fr/dashboard">
+  Voyez ce que vos agents ont fait pendant votre absence. Parcourez les sessions, inspectez les appels d'outils, examinez où les politiques se sont déclenchées.
+</Card>
+
+<Card title="Configuration simplifiée" icon="gear" href="/fr/configuration">
+  Ajustez n'importe quelle politique sans écrire de code. Définissez des listes autorisées, des branches protégées ou des seuils par projet ou globalement.
+</Card>
+
+</CardGroup>
+
+## Démarrage rapide
+
+<CodeGroup>
+
+```bash npm
+npm install -g failproofai
+```
+
+```bash bun
+bun add -g failproofai
+```
+
+</CodeGroup>
+
+```bash
+failproofai policies --install   # enable policies (or skip — `failproofai` will offer to set them up on first run)
+failproofai                      # launch the dashboard
+```
+
+Consultez le guide [Premiers pas](/fr/getting-started) pour le parcours complet.

package/.next/standalone/docs-old/fr/package-aliases.mdx

@@ -0,0 +1,82 @@
+---
+title: Alias de packages
+description: "Alias enregistrés pour prévenir le typosquatting et leur fonctionnement"
+icon: copy
+---
+
+## Package officiel
+
+Le package npm canonique est **`failproofai`** :
+
+```bash
+npm install -g failproofai
+# ou
+bun add -g failproofai
+```
+
+---
+
+## Pourquoi nous détenons les noms d'alias
+
+Le typosquatting est une attaque courante sur la chaîne d'approvisionnement logicielle : un acteur malveillant enregistre un nom de package à une touche de distance d'un package populaire. Les utilisateurs qui font une faute de frappe lors de la commande d'installation se retrouvent à exécuter du code contrôlé par l'attaquant avec un accès total au système — précisément le type de menace que Failproof AI est conçu pour contrer.
+
+Pour éliminer cette surface d'attaque, **nous détenons de manière préventive toutes les fautes d'orthographe courantes et variantes de mise en forme** de `failproofai` sur npm. Aucun de ces noms ne peut être enregistré par un tiers. Chacun est un proxy léger qui installe et délègue au vrai package `failproofai`.
+
+---
+
+## Alias enregistrés
+
+**Variantes de mise en forme** — différentes façons d'écrire « failproof ai » :
+
+| Package | Statut |
+|---------|--------|
+| `failproof` | ✅ Publié |
+| `failproof-ai` | ⏳ En attente de validation npm |
+| `fail-proof-ai` | ⏳ En attente de validation npm |
+| `failproof_ai` | ⏳ En attente de validation npm |
+| `fail_proof_ai` | ⏳ En attente de validation npm |
+| `fail-proofai` | ⏳ En attente de validation npm |
+
+**Fautes de frappe `failprof*`** — un `o` manquant dans « proof » :
+
+| Package | Statut |
+|---------|--------|
+| `failprof` | ✅ Publié |
+| `failprof-ai` | ✅ Publié |
+| `failprofai` | ⏳ En attente de validation npm |
+| `fail-prof-ai` | ⏳ En attente de validation npm |
+| `failprof_ai` | ⏳ En attente de validation npm |
+
+**Fautes de frappe `faliproof*`** — `a` et `i` inversés :
+
+| Package | Statut |
+|---------|--------|
+| `faliproof` | ✅ Publié |
+| `faliproof-ai` | ✅ Publié |
+| `faliproofai` | ⏳ En attente de validation npm |
+
+> **Pourquoi « en attente » ?** La politique anti-spam de npm bloque les noms qui, après suppression de la ponctuation et vérification de similarité, se normalisent vers la même chaîne qu'un package existant. Nous avons contacté le support npm pour réserver ces noms à des fins de protection contre le typosquatting. Ils seront activés une fois approuvés.
+
+Vous pouvez vérifier que tout alias publié nous appartient :
+
+```bash
+npm info failproof
+# Cherchez : "ExosphereHost Inc." dans le champ maintainers
+```
+
+---
+
+## Fonctionnement des alias
+
+Chaque package alias :
+
+1. Liste `failproofai` comme dépendance — ainsi le vrai package est installé et son binaire devient disponible
+2. Expose un binaire portant son propre nom (ex. `failprof-ai`) qui transmet tous les arguments au binaire `failproofai`
+
+Le proxy est un script Node de deux lignes ; il ne contient aucune logique, aucun appel réseau et ne collecte aucune donnée au-delà de ce que fait `failproofai` lui-même.
+
+---
+
+## Si vous trouvez un nom que nous avons manqué
+
+Ouvrez une issue sur [failproofai/failproofai](https://github.com/failproofai/failproofai/issues) et nous l'enregistrerons.

package/.next/standalone/docs-old/fr/testing.mdx

@@ -0,0 +1,260 @@
+---
+title: Tests
+description: "Tests unitaires, tests E2E et utilitaires de test"
+icon: flask-vial
+---
+
+failproofai dispose de deux suites de tests : les **tests unitaires** (rapides, avec mocks) et les **tests end-to-end** (invocations réelles de sous-processus).
+
+---
+
+## Exécution des tests
+
+```bash
+# Lancer tous les tests unitaires une fois
+bun run test:run
+
+# Lancer les tests unitaires en mode watch
+bun run test
+
+# Lancer les tests E2E (nécessite une configuration préalable - voir ci-dessous)
+bun run test:e2e
+
+# Vérification des types sans compilation
+bunx tsc --noEmit
+
+# Lint
+bun run lint
+```
+
+---
+
+## Tests unitaires
+
+Les tests unitaires se trouvent dans `__tests__/` et utilisent [Vitest](https://vitest.dev) avec `jsdom`.
+
+```text
+__tests__/
+  hooks/
+    builtin-policies.test.ts      # Logique des politiques pour chaque builtin
+    hooks-config.test.ts          # Chargement de la config et fusion des scopes
+    policy-evaluator.test.ts      # Injection de paramètres et ordre d'évaluation
+    custom-hooks-registry.test.ts # globalThis registry add/get/clear
+    custom-hooks-loader.test.ts   # Chargeur ESM, imports transitifs, gestion des erreurs
+    manager.test.ts               # Opérations install/remove/list
+  components/
+    sessions-list.test.tsx        # Composant liste des sessions
+    project-list.test.tsx         # Composant liste des projets
+    ...
+  lib/
+    logger.test.ts
+    paths.test.ts
+    date-filters.test.ts
+    telemetry.test.ts
+    ...
+  actions/
+    get-hooks-config.test.ts
+    get-hook-activity.test.ts
+    ...
+  contexts/
+    ThemeContext.test.tsx
+    AutoRefreshContext.test.tsx
+```
+
+### Écrire un test unitaire de politique
+
+```typescript
+import { describe, it, expect, beforeEach } from "vitest";
+import { getBuiltinPolicies } from "../../src/hooks/builtin-policies";
+import { allow, deny } from "../../src/hooks/policy-types";
+
+describe("block-sudo", () => {
+  const policy = getBuiltinPolicies().find((p) => p.name === "block-sudo")!;
+
+  it("denies sudo commands", () => {
+    const ctx = {
+      eventType: "PreToolUse" as const,
+      payload: {},
+      toolName: "Bash",
+      toolInput: { command: "sudo apt install nodejs" },
+      params: { allowPatterns: [] },
+    };
+    expect(policy.fn(ctx)).toEqual(deny("sudo command blocked by failproofai"));
+  });
+
+  it("allows non-sudo commands", () => {
+    const ctx = {
+      eventType: "PreToolUse" as const,
+      payload: {},
+      toolName: "Bash",
+      toolInput: { command: "ls -la" },
+      params: { allowPatterns: [] },
+    };
+    expect(policy.fn(ctx)).toEqual(allow());
+  });
+
+  it("allows patterns in allowPatterns", () => {
+    const ctx = {
+      eventType: "PreToolUse" as const,
+      payload: {},
+      toolName: "Bash",
+      toolInput: { command: "sudo systemctl status nginx" },
+      params: { allowPatterns: ["sudo systemctl status"] },
+    };
+    expect(policy.fn(ctx)).toEqual(allow());
+  });
+});
+```
+
+---
+
+## Tests end-to-end
+
+Les tests E2E invoquent le vrai binaire `failproofai` en tant que sous-processus, lui envoient un payload JSON via stdin et vérifient le résultat sur stdout ainsi que le code de sortie. Cela teste le chemin d'intégration complet utilisé par Claude Code.
+
+### Configuration
+
+Les tests E2E exécutent le binaire directement depuis les sources du dépôt. Avant la première exécution, compilez le bundle CJS utilisé par les fichiers de hooks personnalisés lorsqu'ils importent depuis `'failproofai'` :
+
+```bash
+bun build src/index.ts --outdir dist --target node --format cjs
+```
+
+Puis lancez les tests :
+
+```bash
+bun run test:e2e
+```
+
+Recompilez `dist/` à chaque fois que vous modifiez l'API publique des hooks (`src/hooks/custom-hooks-registry.ts`, `src/hooks/policy-helpers.ts` ou `src/hooks/policy-types.ts`).
+
+### Structure des tests E2E
+
+```text
+__tests__/e2e/
+  helpers/
+    hook-runner.ts      # Lance le binaire, envoie le payload JSON, capture le code de sortie + stdout + stderr
+    fixture-env.ts      # Répertoires temporaires isolés par test avec fichiers de config
+    payloads.ts         # Factories de payloads conformes à Claude pour chaque type d'événement
+  hooks/
+    builtin-policies.e2e.test.ts   # Chaque politique builtin avec un vrai sous-processus
+    custom-hooks.e2e.test.ts       # Chargement et évaluation des hooks personnalisés
+    config-scopes.e2e.test.ts      # Fusion de config entre les scopes project/local/global
+    policy-params.e2e.test.ts      # Injection de paramètres pour chaque politique paramétrée
+```
+
+### Utilisation des utilitaires E2E
+
+**`FixtureEnv`** - environnement isolé par test :
+
+```typescript
+import { createFixtureEnv } from "../helpers/fixture-env";
+
+const env = createFixtureEnv();
+// env.cwd    - répertoire temporaire ; à passer en payload.cwd pour charger .failproofai/policies-config.json
+// env.home   - home isolé ; évite toute fuite depuis le vrai ~/.failproofai
+
+env.writeConfig({
+  enabledPolicies: ["block-sudo"],
+  policyParams: {
+    "block-sudo": { allowPatterns: ["sudo systemctl status"] },
+  },
+});
+```
+
+`createFixtureEnv()` enregistre automatiquement le nettoyage via `afterEach`.
+
+**`runHook`** - invoquer le binaire :
+
+```typescript
+import { runHook } from "../helpers/hook-runner";
+import { Payloads } from "../helpers/payloads";
+
+const result = await runHook(
+  "PreToolUse",
+  Payloads.preToolUse.bash("sudo apt install nodejs", env.cwd),
+  { homeDir: env.home }
+);
+
+expect(result.exitCode).toBe(0);
+expect(result.parsed?.hookSpecificOutput?.permissionDecision).toBe("deny");
+```
+
+**`Payloads`** - factories de payloads prêts à l'emploi :
+
+```typescript
+Payloads.preToolUse.bash(command, cwd)
+Payloads.preToolUse.write(filePath, content, cwd)
+Payloads.preToolUse.read(filePath, cwd)
+Payloads.postToolUse.bash(command, output, cwd)
+Payloads.postToolUse.read(filePath, content, cwd)
+Payloads.notification(message, cwd)
+Payloads.stop(cwd)
+```
+
+### Écrire un test E2E
+
+```typescript
+import { describe, it, expect } from "vitest";
+import { createFixtureEnv } from "../helpers/fixture-env";
+import { runHook } from "../helpers/hook-runner";
+import { Payloads } from "../helpers/payloads";
+
+describe("block-rm-rf (E2E)", () => {
+  it("denies rm -rf", async () => {
+    const env = createFixtureEnv();
+    env.writeConfig({ enabledPolicies: ["block-rm-rf"] });
+
+    const result = await runHook(
+      "PreToolUse",
+      Payloads.preToolUse.bash("rm -rf /", env.cwd),
+      { homeDir: env.home }
+    );
+
+    expect(result.exitCode).toBe(0);
+    expect(result.parsed?.hookSpecificOutput?.permissionDecision).toBe("deny");
+  });
+
+  it("allows non-recursive rm", async () => {
+    const env = createFixtureEnv();
+    env.writeConfig({ enabledPolicies: ["block-rm-rf"] });
+
+    const result = await runHook(
+      "PreToolUse",
+      Payloads.preToolUse.bash("rm /tmp/file.txt", env.cwd),
+      { homeDir: env.home }
+    );
+
+    expect(result.exitCode).toBe(0);
+    expect(result.stdout).toBe("");  // allow → stdout vide
+  });
+});
+```
+
+### Formats de réponse E2E
+
+| Décision | Code de sortie | stdout |
+|----------|----------------|--------|
+| `PreToolUse` deny | `0` | `{"hookSpecificOutput":{"permissionDecision":"deny","permissionDecisionReason":"..."}}` |
+| `PostToolUse` deny | `0` | `{"hookSpecificOutput":{"additionalContext":"Blocked ... because: ..."}}` |
+| Instruct (hors Stop) | `0` | `{"hookSpecificOutput":{"additionalContext":"Instruction from failproofai: ..."}}` |
+| Stop instruct | `2` | stdout vide ; raison dans stderr |
+| Allow | `0` | chaîne vide |
+
+### Configuration Vitest
+
+Les tests E2E utilisent `vitest.config.e2e.mts` avec :
+
+- `environment: "node"` - pas de globals navigateur requis
+- `pool: "forks"` - isolation réelle des processus (les tests lancent des sous-processus)
+- `testTimeout: 20_000` - 20 s par test (démarrage du binaire + évaluation du hook)
+
+Le pool `forks` est important : les workers basés sur des threads partagent `globalThis`, ce qui peut interférer avec les tests qui lancent des sous-processus. Les forks basés sur des processus évitent ce problème.
+
+---
+
+## CI
+
+L'exécution complète de la CI (`bun run lint && bunx tsc --noEmit && bun run test:run && bun run build`) doit passer avant toute fusion. La suite E2E s'exécute en parallèle dans un job CI séparé.
+
+Consultez [Contributing](../CONTRIBUTING.md) pour la liste de vérification complète avant fusion.