Eine Richtlinie schreiben

Es gibt zwei Möglichkeiten, eine Richtlinie zu schreiben: Failproof AI entwirft sie aus einem Audit-Befund, oder du schreibst die Quelle selbst. Nichts wird veröffentlicht oder bereitgestellt, bis du es entscheidest.

Eine Richtlinie aus einem Audit schreiben

Ein Audit findet einen Fehler; eine Richtlinie verhindert, dass er sich wiederholt. Failproof AI entwirft die Richtlinie anhand der Belege des Befunds.

1. Audit durchführen

Führe einen Audit über die Sitzungen durch, in denen der Fehler auftritt. Jeder Befund enthält seine Belege, eine Grundursache und einen vorgeschlagenen Präventionspfad. Arbeite mit einem Befund, der ein wiederholbares Aktionsmuster aufweist – eine Richtlinie kann nur das stoppen, was sie in einem Hook-Ereignis erkennen kann.

2. Den Entwurf generieren

Dashboard
CLI

Öffne das Problem des Befunds unter Analyze → issues und überprüfe die zitierten Sitzungen, die Grundursache und die Empfehlung.
Wähle generate policy. Failproof AI beurteilt zunächst, ob eine Richtlinie das Problem überhaupt ausdrücken kann. Ein no policy-Ergebnis bedeutet, dass die Lösung eine Benachrichtigung, eine Workflow-Änderung oder eine Person erfordert – keine Richtlinie.
Wähle write this policy. Der Titel des Problems, der Befund, die Grundursache, die Empfehlung und die vorgeschlagene Durchsetzungsabsicht werden als Entwurf in Admin → policy editor übernommen. Verwende open the editor anyway, wenn du mit der Eignungsprüfung nicht einverstanden bist.

Lies die Belege und erstelle dann einen Entwurf mit dem Assistenten. compose gibt die Quelle zur Überprüfung aus und veröffentlicht nichts:

fp issues show <issue-id>
fp audits finding <finding-id>
fp policies compose "Block git push --force on release branches"

compose benötigt eine angemeldete Sitzung (fp login), deren Rolle policies:write besitzt; API-Keys werden abgelehnt.

3. Den Entwurf überprüfen

Ein Entwurf ist ein Ausgangspunkt, kein Urteil. Überprüfe vor der Veröffentlichung, ob er:

Den Fehlermodus in operativer Sprache benennt.
Nur die Hook-Ereignisse und Tools abgleicht, die genug Belege für eine Entscheidung liefern.
Die engste Bedingung verwendet, die die unsichere Aktion erfasst.
Eine Begründung zurückgibt, die dem Agenten mitteilt, was er stattdessen tun soll.
instruct verwendet, wenn der Agent den Kurs sicher korrigieren kann, und deny nur dann, wenn das Zulassen der Aktion inakzeptabel oder irreversibel ist.

Validiere die Quelle im Editor und behebe jeden gemeldeten Fehler.

4. Testen und dann veröffentlichen

Führe backtest unter der Quelle durch, bevor du veröffentlichst: Es spielt den Entwurf gegen Aufrufe ab, die deine Agenten bereits gemacht haben, und zählt die funktionierenden Aufrufe, die unterbrochen worden wären. Eine Richtlinie testen behandelt das sowie die anderen Prüfungen. Wenn sie sich korrekt verhält, gib die Richtlinienidentität ein und wähle publish version. Das Veröffentlichen erstellt eine unveränderliche Version und stellt nichts bereit: Sie liegt ungenutzt, bis du sie bereitstellst. Über ein Terminal:

fp policies publish checkout-guard ./checkout.policy.mjs --description "Block force-push"

publish prüft die Quelle syntaktisch, bevor sie gesendet wird – ein Syntaxfehler wird also hier aufgedeckt und nicht zur Laufzeit auf einem Gerät.

Selbst schreiben

Eine Richtlinie ist JavaScript oder TypeScript gegen die failproofai-API:

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 für sowohl Write als auch Edit zu, jedoch nicht auf production-backup: production muss ein vollständiges Pfadsegment sein. Der Kontext enthält außerdem den Ereignistyp, normalisierte Nutzdaten, Sitzungsmetadaten, Parameter und die Quell-CLI, sofern verfügbar – siehe das Policy SDK. Um es als Version zu veröffentlichen, füge die Quelle in compose unter Admin → policy editor ein und folge den Schritten 3 und 4 oben, oder veröffentliche die Datei über ein Terminal mit fp policies publish. Um sie ohne Cloud auf einem Gerät auszuführen, speichere sie unter .failproofai/policies/ mit einem Namen, der auf policies.js, policies.mjs oder policies.ts endet – diese werden automatisch im Projekt- und Benutzerbereich geladen – oder installiere sie über den Pfad:

failproofai policies --install --custom ./security.policies.ts --scope project

Gib jeder Richtlinie einen Namen, der über Konventions-, benutzerdefinierte, Paket- und Cloud-verwaltete Richtlinien hinweg eindeutig ist.

Prevent repeat failures

Get a policy

Ship a policy

Eine Richtlinie schreiben

Eine Richtlinie aus einem Audit schreiben

1. Audit durchführen

2. Den Entwurf generieren

3. Den Entwurf überprüfen

4. Testen und dann veröffentlichen

Selbst schreiben

​Eine Richtlinie aus einem Audit schreiben

​1. Audit durchführen

​2. Den Entwurf generieren

​3. Den Entwurf überprüfen

​4. Testen und dann veröffentlichen

​Selbst schreiben

Eine Richtlinie aus einem Audit schreiben

1. Audit durchführen

2. Den Entwurf generieren

3. Den Entwurf überprüfen

4. Testen und dann veröffentlichen

Selbst schreiben