Auditoria de Código
O valor de uma auditoria está no ranqueamento e nas evidências, não no tamanho. Um achado sem caminho de arquivo, resultado de consulta, número de PR ou contagem de linhas é uma hipótese — rotule-o como tal.
Fundamente a auditoria no código e na produção, não em documentos
Notas de projeto, planos e documentos de status são pontos de verificação, não autoridades. Comece por eles para saber o que foi alegado, depois verifique contra a realidade: o commit atual, o estado do banco de dados, as verificações de PR, as pontas dos branches.
Quando os documentos e o código discordam, essa discordância é, por si só, um achado — frequentemente o mais valioso da auditoria.
Uma alegação sobre produção exige uma consulta contra a produção. Combine isso com uma skill de porta de verificação para a mecânica.
Estrutura
# Auditoria de <Escopo> (AAAA-MM-DD)
## Resumo
<As três coisas que importam e o que você faria primeiro.>
## Parte 1 — O que você não está vendo (pontos cegos, ranqueados)
## Parte 2 — Capacidades faltantes (ranqueadas, cada uma com uma estimativa aproximada de esforço)
## Parte 3 — Capacidades existentes que precisam de melhoria (ranqueadas)
## Parte 4 — Mudanças arquiteturais (ranqueadas, em português claro)
## Parte 5 — Se eu comandasse os próximos 30 dias
## Lista de verificação (discrepâncias encontradas durante a auditoria)
Ranqueie tudo. Uma lista não ranqueada de 40 achados é uma lista inacionável de 40 achados.
Verifique por scaffolds dormentes antes de estimar
Anexe uma estimativa aproximada de esforço a cada lacuna e diga o que a torna barata ou cara.
O achado de auditoria mais valioso costuma ser este: a maioria das "lacunas" de alto valor são dias de trabalho, não semanas, porque os scaffolds já existem no repositório sem chamadores. Uma funcionalidade que já está 80% pronta é uma decisão completamente diferente de uma que não está.
Faça grep pela coisa antes de declarar que está faltando. Uma função com zero chamadores é o caso canônico — o código existe, nada a invoca, e todo documento de status descreve a funcionalidade como ausente.
A lista de verificação
Toda auditoria termina com as discrepâncias que não conseguiu resolver. Cada entrada nomeia:
- o que foi alegado
- o que foi observado
- qual consulta ou verificação resolveria a questão
Esta é a seção que a próxima sessão realmente usa. Escreva-a mesmo quando for curta.
A seção do explicitamente não vale a pena fazer
Nomeie o que você examinou e deliberadamente rejeitou, com o motivo.
Auditorias que apenas adicionam ao backlog tornam o backlog inútil. Um achado que você examinou e descartou vale mais do que um que você nunca menciona, porque impede que a próxima auditoria o levante novamente.
Itens retidos não são lacunas
Qualquer coisa já marcada como deliberadamente adiada, ou retida para uma decisão humana explícita, está retida de propósito. Não a liste como lacuna.
Ressurgir uma retenção deliberada como achado é como decisões retidas são executadas acidentalmente.
Saída
Escreva a auditoria onde o projeto as mantém. Se ela substituir uma auditoria anterior, diga qual e o que mudou — uma pasta de auditorias deve permanecer legível como uma sequência, não como uma pilha.