Scrivi una policy

Ci sono due modi per scrivere una policy: lasciare che Failproof AI la rediga da un risultato di audit, oppure scrivere il codice sorgente tu stesso. Nulla viene pubblicato o distribuito finché non scegli di farlo.

Scrivi una policy da un audit

Un audit trova un errore; una policy lo impedisce che accada di nuovo. Failproof AI redige la policy dalla stessa evidenza del risultato.

1. Esegui un audit

Esegui un audit sulle sessioni in cui si verifica l’errore. Ogni risultato contiene le sessioni di evidenza, una causa radice e un percorso di prevenzione suggerito. Lavora da un risultato con un pattern di azione ripetibile — una policy può solo bloccare ciò che riesce a riconoscere in un evento hook.

2. Genera la bozza

Dashboard
CLI

Apri il problema del risultato in Analyze → issues e controlla le sessioni citate, la causa radice e la raccomandazione.
Seleziona generate policy. Failproof AI innanzitutto indica se una policy può esprimere il problema. Un risultato no policy significa che la soluzione è un avviso, un cambiamento di flusso di lavoro, o una persona — non una policy.
Seleziona write this policy. Il titolo del problema, il risultato, la causa radice, la raccomandazione e l’intento di enforcement proposto diventano una bozza in Admin → policy editor. Usa open the editor anyway quando non sei d’accordo con il controllo di candidatura.

Leggi l’evidenza, quindi redigi con l’assistente. compose stampa il sorgente per la revisione e non pubblica nulla:

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

compose richiede una sessione autenticata (fp login) il cui ruolo ha policies:write; rifiuta le chiavi API.

3. Rivedi la bozza

Una bozza è un punto di partenza, non un verdetto. Prima di pubblicare, verifica che:

Nomini la modalità di errore in linguaggio operativo.
Corrisponda solo agli eventi hook e agli strumenti che portano sufficienti evidenze per decidere.
Utilizzi la condizione più ristretta che catturi l’azione non sicura.
Restituisca un motivo che dica all’agente cosa fare invece.
Utilizzi instruct dove l’agente può correggere il corso in modo sicuro, e deny solo dove consentire l’azione è inaccettabile o irreversibile.

Valida il sorgente nell’editor e correggi ogni errore segnalato.

4. Testalo, quindi pubblicalo

Esegui backtest sotto il sorgente prima di pubblicare: riproduce la bozza rispetto alle chiamate già effettuate dalla tua flotta e conta le chiamate funzionanti che avrebbe interrotto. Test a policy copre questo e gli altri controlli. Quando si comporta correttamente, inserisci l’identità della policy e seleziona publish version. La pubblicazione crea una versione immutabile e non distribuisce nulla: rimane inutilizzata finché non la distribuisci. Da un terminale:

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

publish effettua controlli di parse sul sorgente prima di inviarlo, così un errore di sintassi emerge qui invece che su una macchina al momento dell’enforcement.

Scrivila tu stesso

Una policy è JavaScript o TypeScript contro l’API failproofai:

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();
  },
});

Questo corrisponde a production/config.yml, /srv/production/config.yml, /srv/production e C:\\production\\config.yml per sia Write che Edit, ma non a production-backup: production deve essere un segmento di percorso intero. Il contesto contiene anche il tipo di evento, il payload normalizzato, i metadati della sessione, i parametri e la CLI sorgente quando disponibile — vedi l’SDK per policy. Per pubblicarla come versione, incolla il sorgente in compose in Admin → policy editor e segui i passaggi 3 e 4 sopra, oppure pubblica il file da un terminale con fp policies publish. Per eseguirla su una macchina senza Cloud, salvala in .failproofai/policies/ con un nome che termina in policies.js, policies.mjs o policies.ts — questi si caricano automaticamente in ambito progetto e utente — o installala per percorso:

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

Assegna a ogni policy un nome univoco tra le policy di convenzione, personalizzate, di pack e gestite da Cloud.

Prevent repeat failures

Get a policy

Ship a policy