Escrever uma política

Há duas formas de escrever uma política: deixar o Failproof AI redigir a partir de uma descoberta de auditoria, ou escrever o código-fonte você mesmo. Nada é publicado ou implantado até que você decida.

Escrever uma política a partir de uma auditoria

Uma auditoria encontra uma falha; uma política impede que ela aconteça novamente. O Failproof AI redige a política a partir das evidências da própria descoberta.

1. Execute uma auditoria

Execute uma auditoria sobre as sessões onde a falha ocorre. Cada descoberta carrega suas sessões de evidência, uma causa raiz e um caminho de prevenção sugerido. Trabalhe a partir de uma descoberta com um padrão de ação repetível — uma política só pode bloquear o que consegue reconhecer em um evento de hook.

2. Gere o rascunho

Dashboard
CLI

Abra o problema da descoberta em Analyze → issues e verifique as sessões citadas, a causa raiz e a recomendação.
Selecione generate policy. O Failproof AI primeiro informa se uma política consegue expressar o problema. Um resultado no policy significa que a solução é um alerta, uma mudança de processo ou uma pessoa — e não uma política.
Selecione write this policy. O título do problema, a descoberta, a causa raiz, a recomendação e a intenção de aplicação proposta se tornam um rascunho em Admin → policy editor. Use open the editor anyway quando você discordar da verificação de candidatura.

Leia as evidências e depois redija com o assistente. compose imprime o código-fonte para você revisar e não publica nada:

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

compose requer uma sessão autenticada (fp login) cuja função tenha policies:write; ele rejeita chaves de API.

3. Revise o rascunho

Um rascunho é um ponto de partida, não um veredicto. Antes de publicar, verifique se ele:

Nomeia o modo de falha em linguagem operacional.
Corresponde apenas aos eventos de hook e ferramentas que carregam evidências suficientes para decidir.
Usa a condição mais restrita possível que captura a ação insegura.
Retorna um motivo que diz ao agente o que fazer em vez disso.
Usa instruct onde o agente pode corrigir o curso com segurança, e deny apenas onde permitir a ação é inaceitável ou irreversível.

Valide o código-fonte no editor e corrija todos os erros reportados.

4. Teste e depois publique

Execute o backtest na aba de código-fonte antes de publicar: ele repete o rascunho contra chamadas que sua frota já realizou e conta as chamadas funcionais que teriam sido interrompidas. Testar uma política cobre isso e as outras verificações. Quando o comportamento estiver correto, insira a identidade da política e selecione publish version. Publicar cria uma versão imutável e não implanta nada: ela fica sem uso até que você a implante. Em um terminal:

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

publish verifica a sintaxe do código-fonte antes de enviá-lo, então um erro de sintaxe aparece aqui em vez de aparecer em uma máquina no momento de aplicação.

Escreva você mesmo

Uma política é JavaScript ou TypeScript usando a 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();
  },
});

Isso corresponde a production/config.yml, /srv/production/config.yml, /srv/production e C:\\production\\config.yml tanto para Write quanto para Edit, mas não para production-backup: production precisa ser um segmento de caminho completo. O contexto também carrega o tipo de evento, payload normalizado, metadados de sessão, parâmetros e CLI de origem quando disponível — veja o SDK de políticas. Para publicá-la como uma versão, cole o código-fonte em compose em Admin → policy editor e siga os passos 3 e 4 acima, ou publique o arquivo a partir de um terminal com fp policies publish. Para executá-la em uma máquina sem Cloud, salve-a em .failproofai/policies/ com um nome terminando em policies.js, policies.mjs ou policies.ts — esses arquivos são carregados automaticamente nos escopos de projeto e usuário — ou instale por caminho:

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

Dê a cada política um nome único entre políticas de convenção, personalizadas, de pacote e gerenciadas pela Cloud.

Prevent repeat failures

Get a policy

Ship a policy