> ## Documentation Index
> Fetch the complete documentation index at: https://docs.befailproof.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Benutzerdefinierte Richtlinien

> Schreibe eine Richtlinie für einen Fehlerfall, der spezifisch für deinen Agent-Workflow ist.

Erstelle eine Datei mit der Endung `policies.js`, `policies.mjs` oder `policies.ts` unter `.failproofai/policies/`. Konventionsdateien werden automatisch auf Projekt- und Benutzerebene geladen.

## Richtlinie vor der Cloud-Veröffentlichung testen

<Tabs>
  <Tab title="Dashboard">
    1. Installiere die benutzerdefinierte Richtlinie auf einer Testmaschine und löse sowohl eine passende Aktion als auch eine legitime Nicht-Übereinstimmung aus.
    2. Gehe zu **Observe → policy** und vergleiche die beiden Entscheidungen.
    3. Öffne jede verlinkte Sitzung und überprüfe, ob das Ereignis-Payload ausreichend Belege für die Regel enthält.
    4. Wenn das Verhalten korrekt ist, verschiebe den geprüften Quellcode in **Admin → policy editor** und veröffentliche eine Version.
  </Tab>

  <Tab title="CLI">
    ```bash theme={null}
    failproofai policies --install --custom ./security.policies.ts \
      --cli claude --scope project
    failproofai policies
    ```

    Konventionsdateien unter `.failproofai/policies/` werden ohne `--custom` geladen. Behalte einen expliziten Installationsbefehl in CI, wenn die Validierung bei einem fehlerhaften Modul scheitern soll.
  </Tab>
</Tabs>

```ts theme={null}
import { customPolicies, allow, deny } from "failproofai";

customPolicies.add({
  name: "protect-production-paths",
  description: "Block writes to production configuration",
  match: { events: ["PreToolUse"] },
  fn: async (ctx) => {
    if (ctx.toolName !== "Write" && ctx.toolName !== "Edit") return allow();
    const path = String(ctx.toolInput?.file_path ?? "").replaceAll("\\", "/");
    if (path.split("/").includes("production")) {
      return deny("Writes to production configuration require approval.");
    }
    return allow();
  },
});
```

Dies trifft auf `production/config.yml`, `/srv/production/config.yml`, `/srv/production` und `C:\\production\\config.yml` sowohl für `Write` als auch für `Edit` zu. Namen wie `production-backup` werden nicht erfasst, da `production` ein vollständiges Pfadsegment sein muss.

Explizite Datei validieren und installieren:

```bash theme={null}
failproofai policies --install --custom ./security.policies.ts
```

Der Richtlinienkontext umfasst den Ereignistyp, den normalisierten Payload, den Tool-Namen und -Input, Sitzungsmetadaten, Parameter sowie die Quell-CLI, sofern verfügbar.

## Fehlerpfade testen

Führe die Validierung nach dem Ändern der Einstiegsdatei oder eines lokalen Moduls durch, das sie importiert:

```bash theme={null}
failproofai policies --install --custom ./security.policies.ts --scope project
```

Der strikte CLI-Pfad schlägt bei fehlenden Dateien, Syntaxfehlern, unaufgelösten Importen, Ausnahmen auf oberster Ebene und Modul-Lade-Timeouts fehl. Zum Zeitpunkt der Durchsetzung wird eine fehlerhafte benutzerdefinierte Datei protokolliert und übersprungen, sodass die eingebauten Richtlinien weiter ausgeführt werden können. Behandle jede Ladewarnung als Verlust der erwarteten Durchsetzung und erstelle dafür Alarme in den Produktionsprotokollen.

Verwende global eindeutige Namen für explizite, konventionsbasierte und Cloud-verwaltete Richtlinien. Halte Richtlinienfunktionen deterministisch, begrenze externe Aufrufe mit kurzen Timeouts, und gib auf jedem Pfad ein beabsichtigtes `allow`, `instruct` oder `deny` zurück.

<Warning>
  Eine benutzerdefinierte Richtlinie ist Durchsetzungscode. Teste fehlende Felder, alternative Tool-Namen und fehlerhafte Eingaben – nicht nur die erwartete Übereinstimmung.
</Warning>