Skip to main content
Recurso beta. O audit é disponibilizado em beta enquanto coletamos feedback inicial. O catálogo de detectores e o formato do relatório podem mudar antes do próximo corte estável. Abra uma issue se algo parecer errado.
O audit reproduz suas transcrições anteriores do agente-CLI pelo motor de políticas do failproofai e gera um relatório visual e compartilhável na página /audit do dashboard — o arquétipo do seu agente, uma pontuação de 0 a 100, e exatamente quais políticas teriam capturado o quê.

Executar

Três formas de iniciar — todas levam ao mesmo relatório /audit.

Sem instalação

npx -y failproofai audit baixa o failproofai, executa a varredura e abre o dashboard automaticamente — sem necessidade de instalação prévia.

Pelo CLI

failproofai audit executa a varredura no seu terminal e abre localhost:8020/audit automaticamente ao terminar.

Pelo dashboard

Execute failproofai e clique em Audit na barra de navegação (entre Policies e Projects), ou acesse /audit diretamente.
Execute failproofai audit -h (ou --help) para ver o uso. O audit roda completamente offline — sem conta ou conexão à internet necessária — e o dashboard continua servindo até você encerrá-lo com Ctrl+C.
O dashboard varre transcrições anteriores do agente CLI nesta máquina (Claude Code, Codex, Copilot, Cursor, OpenCode, Pi) e relata com que frequência o agente fez coisas que o failproofai foi criado para impedir — verificações de variáveis de ambiente, force pushes, prefixos redundantes cd <cwd>, loops de polling com sleep, releitura de arquivos recém-editados, e mais. Para cada transcrição, cada evento de uso de ferramenta é reproduzido pelas 39 políticas integradas e pelos 8 detectores exclusivos do audit que capturam padrões ainda não cobertos pelas políticas em tempo real. As contagens são agregadas por política/detector em todas as sessões.

O que você recebe

A página /audit é um pôster de tela única e compartilhável seguido por quatro seções abaixo da dobra:
  1. Pôster — a identidade do seu agente em um relance: seu arquétipo (um dos 8 — optimist, cowboy, explorer, goldfish, paranoid architect, precision builder, hammer, ghost), suas palavras-chave de persona, o quão raro é esse arquétipo, e uma pontuação de 0 a 100 com uma faixa de classificação (S até bottom tier). Criado para compartilhar — poste no X ou no LinkedIn, ou baixe como PNG.
  2. // strengths — o que seu agente já faz bem, com números reais da varredura (ex.: % de chamadas de ferramenta limpas, 0 tentativas de push para main), exibido apenas onde a política relevante tem um histórico limpo.
  3. // quirks — o que escapou: uma tabela classificada de comportamentos que o failproofai teria capturado — quando aconteceu pela última vez, o que escapou (e o integrado que teria bloqueado), sua severidade, e com que frequência foi visto (new / recurring / N× seen).
  4. // how to improve — a lista de correções prescrita: uma linha por política com um failproofai policy add <slug> para copiar e colar, mais um botão install all que habilita todas as recomendações de uma vez e mostra sua pontuação projetada se você fizesse isso.
  5. // come back better — crie o hábito: defina um lembrete de reauditoria por e-mail (3d / 7d / 14d / 30d) ou reaudite agora, e convide um amigo para rodar a própria auditoria (enviado de failproof.ai, com Cc para você). Lembretes e convites exigem login — veja failproofai auth.

Detectores exclusivos do audit

Esses detectores capturam padrões de “comportamento ineficiente” ainda não aplicados em tempo real. Rodam apenas durante o audit e nunca bloqueiam uma chamada de ferramenta ao vivo.

Caches

  • Cache por transcrição em ~/.failproofai/cache/audit/<sha1>.json, indexado por (mtime, size, engineVersion, detectorVersion) — invalida automaticamente quando a transcrição ou o código de política/detector muda. Cada entrada também armazena um timestamp cachedAt como metadado de TTL (não faz parte da chave do cache); entradas com mais de 7 dias são rejeitadas na leitura para que resultados de longa duração não sobrevivam à evolução da intenção dos detectores.
  • Cache do resultado completo em ~/.failproofai/audit-dashboard.json (modo 0600). Permite que o dashboard renderize instantaneamente na navegação sem precisar rodar novamente. Também rejeitado na leitura após o TTL de 7 dias/audit então cai em seu estado vazio e solicita uma nova execução. Clique em [ re-audit now ] perto do final do relatório para atualizar — o re-audit envia noCache: true, então ignora o cache por transcrição e reavarre todas as transcrições em vez de retornar o resultado em cache; a execução transmite o progresso via uma faixa fixa no topo e substitui o resultado no lugar ao ser concluída com sucesso (sem recarregamento de página; um re-audit com falha mantém o relatório anterior).

Observações

  • Sem mutação. O audit é reproduzido em modo somente leitura. warn-repeated-tool-calls é ignorado porque seu sidecar por sessão seria modificado de outra forma.
  • Políticas de fluxo de trabalho ignoradas. As políticas require-*-before-stop são acionadas apenas em eventos Stop e execSync contra o estado git atual — elas não têm uma interpretação significativa de “o que teria acontecido em 2025”, portanto não aparecem nas contagens do audit.
  • Políticas personalizadas ignoradas. Hooks customizados fornecidos pelo usuário não são reproduzidos (eles podem ter mudado desde a sessão original).