Pubblica un pack - Failproof AI

Un pack è costituito da tre file allegati a un rilascio GitHub. failproofai pack build scrive tutti e tre partendo da un file di policy che hai già.

1. Scrivi le policy

Un file, utilizzando la stessa API di qualsiasi custom policy. Due campi extra sono importanti per un pack:

import { customPolicies, deny, allow } from "failproofai";

customPolicies.add({
  name: "block-refunds",
  description: "Refunds above the approved limit need a human",
  category: "Billing",        // groups it, and is what --category selects on
  defaultEnabled: true,       // switched on by a plain `pack add`
  match: { events: ["PreToolUse"], tools: ["Bash"] },
  fn: async (ctx) =>
    String(ctx.toolInput?.command ?? "").includes("refund")
      ? deny("Refunds need a human. Ask before running this.")
      : allow(),
});

defaultEnabled di default è false quando lo ometti. Un semplice failproofai pack add attiva solo quello che hai contrassegnato — installare senza controllo ogni policy di uno sconosciuto non è una decisione che l’installer dovrebbe prendere per l’utente.

La voce deve essere un singolo file autocontenuto. Solo la voce è fissata con digest, quindi un pack che importa file locali non potrebbe onestamente affermare che il digest copre ciò che viene eseguito. Raggruppa prima (esbuild, bun build, rollup) e costruisci il pack dal bundle — pack build rifiuta un import locale piuttosto che distribuire una promessa che non può mantenere.

2. Costruisci gli asset del rilascio

failproofai pack build ./policies.mjs \
  --id acme/support-agent \
  --version 1.0.0 \
  --out ./dist-pack

Scrive tre file e convalida ogni policy con le proprie regole del loader prima — quindi un pack che non potrebbe mai essere installato fallisce qui, dove puoi correggerlo:

File	Cos’è
`failproofai-pack.json`	Il manifest: id, version, effect e una voce per ogni policy
`failproofai-pack.mjs`	La tua voce, testualmente
`SHA256SUMS`	`<sha256> <filename>` per gli altri due

Rifiutati al momento della costruzione: un id che non è publisher/name, un nome di policy contenente /, una policy che dichiara alwaysOn, una description, category o match mancante, una voce che non registra nulla e una voce che importa file locali.

3. Allegali a un rilascio

Etichetta il rilascio con la stessa versione che hai costruito e allega tutti e tre i file come asset di rilascio:

gh release create 1.0.0 \
  ./dist-pack/failproofai-pack.json \
  ./dist-pack/failproofai-pack.mjs \
  ./dist-pack/SHA256SUMS

Chiunque può ora installarlo:

failproofai pack add acme/support-agent

I nomi degli asset sono fissi — sono quelli da cui la CLI di un consumer costruisce i suoi URL, senza chiamata API e senza discovery.

Distribuire una nuova versione

Costruisci con il nuovo --version, etichetta un nuovo rilascio, allega di nuovo i tre asset. I consumer eseguono lo stesso pack add e mantengono qualsiasi sottoinsieme avevano scelto; una policy che hanno disattivato rimane disattivata durante l’aggiornamento. Cambiare il name di una policy è una breaking change: una macchina che l’aveva disattivata sta disattivando un nome che non esiste più e il nuovo nome arriva con quello che defaultEnabled dice.

Cosa i tuoi utenti stanno affidandoti

SHA256SUMS risiede nello stesso rilascio dell’artefatto, quindi prova che i byte sono quelli che hai pubblicato — non chi sei tu. Chiunque possa scrivere nel repository può scrivere entrambi i file. La protezione dei tuoi utenti è che il digest è fissato quando installano, quindi quello che hai distribuito non può cambiare sotto di loro dopo. Pubblica da un repository il cui accesso in scrittura controlli e tratta un rilascio di pack come se stessi pubblicando un package.

Osserva prima di applicare

Un manifest può dichiarare "effect": "observe". Quelle policy vengono eseguite e i loro verdetti sono registrati e scartati — nulla è bloccato. È il modo per misurare una nuova regola rispetto al traffico reale prima che possa interrompere il lavoro di chiunque.

{ "id": "acme/support-agent", "version": "1.1.0", "effect": "observe", "policies": [ ... ] }

​1. Scrivi le policy

​2. Costruisci gli asset del rilascio

​3. Allegali a un rilascio

​Distribuire una nuova versione

​Cosa i tuoi utenti stanno affidandoti

​Osserva prima di applicare

1. Scrivi le policy

2. Costruisci gli asset del rilascio

3. Allegali a un rilascio

Distribuire una nuova versione

Cosa i tuoi utenti stanno affidandoti

Osserva prima di applicare