Skip to main content
Recurso beta. A auditoria é disponibilizada como beta enquanto coletamos feedback inicial. O catálogo de detectores e o formato do relatório podem mudar antes da próxima versão estável. Abra uma issue se algo parecer errado.
A auditoria agora está disponível como a página de dashboard /audit, não como um subcomando de CLI. Acesse pelo navbar do dashboard (entre Policies e Projects) ou visite http://localhost:8020/audit diretamente ao executar o failproofai localmente.
failproofai          # abra o dashboard, depois clique em "Audit"
O dashboard escaneia transcrições anteriores do CLI do agente nesta máquina (Claude Code, Codex, Copilot, Cursor, OpenCode, Pi, Gemini) e reporta 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, entre outros. Para cada transcrição, todo evento de uso de ferramenta é reproduzido através das 39 políticas integradas e de 8 detectores exclusivos de auditoria que identificam padrões ainda não cobertos pelas políticas em tempo de execução. As contagens são agregadas por política/detector em todas as sessões.

O que você obtém

A página /audit é composta por seis seções:
  1. Identity — seu agente classificado em um dos 8 arquétipos (optimist, cowboy, explorer, goldfish, paranoid architect, precision builder, hammer, ghost) com base no sinal ponderado de todas as transcrições auditadas.
  2. Strengths — números reais derivados do escaneamento (% de chamadas limpas, “0 vazamentos de credenciais”, etc.) condicionados ao acionamento real das políticas de sanitização relevantes.
  3. Score — de 0 a 100 com faixas S/A/B/C/D/F e uma projeção de melhoria caso todas as políticas recomendadas fossem habilitadas.
  4. Findings — cards por política com o que aconteceu, custo, evidências capturadas e o comando exato failproofai policy add <slug> para ativar a política integrada em tempo real que teria detectado o problema.
  5. Prescribed policies — lista de instalação consolidada com um comando único failproofai policies --install.
  6. Re-audit reminder — “volte melhor”. Configure um lembrete por e-mail de 7 dias via api-server (requer login; veja failproofai auth).

Detectores exclusivos de auditoria

Estes detectam padrões de “comportamento ineficiente” que ainda não são aplicados em tempo real. Eles rodam apenas durante a auditoria e nunca bloqueiam uma chamada de ferramenta ao vivo.
DetectorO que conta
redundant-cd-cwdComandos Bash que começam com cd <cwd> && … mesmo que os comandos já rodem em cwd.
prefer-edit-over-read-catcat/head/tail/less/more em um único arquivo fonte — use a ferramenta Read.
prefer-edit-over-sed-awkEdições in-place com sed -i / awk … > file — use a ferramenta Edit.
prefer-write-over-heredocEscrita de arquivos com heredoc / echo > file multilinha — use a ferramenta Write.
sleep-polling-loopsleep N longo (≥ 30s) ou loops de polling while …; sleep …; done.
find-from-rootfind /, find /home, find /usr, etc. — limite ao cwd.
git-commit-no-verifygit commit … --no-verify / -n, ignorando hooks.
reread-after-editRead de um arquivo que foi recentemente modificado por Edit/Write na mesma sessão.

Caches

  • Cache por transcrição em ~/.failproofai/cache/audit/<sha1>.json, indexado por (mtime, size, engineVersion, detectorVersion) — invalidado 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 parte da chave de cache); entradas com mais de 7 dias são rejeitadas na leitura para que resultados antigos não sobrevivam à evoluçã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 executar novamente. Também rejeitado na leitura após o TTL de 7 dias — o /audit cai no estado vazio e solicita uma nova execução. Clique em [ re-audit now ] próximo ao final do relatório para atualizar — a re-auditoria envia noCache: true, ignorando o cache por transcrição e re-escaneando 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 concluir com sucesso (sem recarregar a página; uma re-auditoria com falha mantém o relatório anterior).

Observações

  • Sem mutação. A auditoria é reproduzida 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ó são acionadas em eventos Stop e executam execSync contra o estado git ao vivo — elas não têm uma interpretação significativa para “o que teria acontecido em 2025”, portanto não aparecem nas contagens de auditoria.
  • Políticas personalizadas ignoradas. Hooks personalizados fornecidos pelo usuário não são reproduzidos (eles podem ter mudado desde a sessão original).