Auditoria de Código Pré-Push

Como engenheiro sênior, você está fazendo a revisão final antes de enviar este código para o GitHub. Verifique tudo cuidadosamente e corrija os problemas conforme os encontrar.

Quando Usar Esta Habilidade

• O usuário solicita "auditar o código" ou "revisar antes de enviar"
• Antes de fazer o primeiro envio para o GitHub
• Antes de tornar um repositório público
• Revisão pré-implantação em produção
• O usuário pede para "limpar o código" ou "otimizar tudo"

Seu Trabalho

Revise todo o código, arquivo por arquivo. Leia o código cuidadosamente. Corrija os problemas imediatamente. Não apenas anote os problemas — faça as alterações necessárias.

Processo de Auditoria

1. Limpar Arquivos Desnecessários

Comece procurando por arquivos que não deveriam estar no GitHub:

Exclua estes imediatamente:

• Arquivos do sistema operacional: .DS_Store, Thumbs.db, desktop.ini
• Logs: *.log, npm-debug.log*, yarn-error.log*
• Arquivos temporários: *.tmp, *.temp, *.cache, *.swp
• Saída de compilação: dist/, build/, .next/, out/, .cache/
• Dependências: node_modules/, vendor/, __pycache__/, *.pyc
• Arquivos do IDE: .idea/, .vscode/ (pergunte ao usuário primeiro), *.iml, .project
• Arquivos de backup: *.bak, *_old.*, *_backup.*, *_copy.*
• Artefatos de teste: coverage/, .nyc_output/, test-results/
• Lixo pessoal: TODO.txt, NOTES.txt, scratch.*, test123.*

Crítico - Verifique se há segredos:

• Arquivos .env (nunca devem ser commitados)
• Arquivos contendo: password, api_key, token, secret, private_key
• *.pem, *.key, *.cert, credentials.json, serviceAccountKey.json

Se você encontrar segredos no código, marque como um BLOQUEADOR CRÍTICO.

2. Corrigir .gitignore

Verifique se o arquivo .gitignore existe e é completo. Se estiver faltando ou não estiver completo, atualize-o para incluir todos os padrões de arquivos desnecessários acima. Certifique-se de que .env.example exista com chaves, mas sem valores.

3. Auditar Cada Arquivo Fonte

Percorra cada arquivo de código e verifique:

Código Morto (remover imediatamente):

• Blocos de código comentados
• Importações/requisições não utilizadas
• Variáveis não utilizadas (declaradas, mas nunca usadas)
• Funções não utilizadas (definidas, mas nunca chamadas)
• Código inalcançável (após return, dentro de if (false))
• Lógica duplicada (mesmo código em vários lugares — combine)

Qualidade do Código (corrija os problemas conforme avança):

• Nomes vagos: data, info, temp, thing → renomeie para serem descritivos
• Números mágicos: if (status === 3) → extraia para uma constante nomeada
• Declarações de depuração: remova console.log, print(), debugger
• Comentários TODO/FIXME: resolva-os ou exclua-os
• TypeScript any: adicione tipos adequados ou explique por que any está sendo usado
• Use === em vez de == em JavaScript
• Funções com mais de 50 linhas: considere dividir
• Código aninhado com mais de 3 níveis: refatore com retornos antecipados

Problemas de Lógica (crítico):

• Verificações ausentes de nulo/indefinido
• Operações de array em arrays potencialmente vazios
• Funções assíncronas que não são aguardadas
• Promises sem .catch() ou try/catch
• Possibilidades de loops infinitos
• default ausente em instruções switch

4. Verificação de Segurança (Tolerância Zero)

Segredos: Procure por senhas, chaves de API e tokens codificados. Eles devem estar em variáveis de ambiente.

Vulnerabilidades de injeção:

• SQL: Sem concatenação de strings em consultas — use apenas consultas parametrizadas
• Injeção de comando: Sem exec() com entrada fornecida pelo usuário
• Travessia de diretório: Sem caminhos de arquivo de entrada do usuário sem validação
• XSS: Sem innerHTML ou dangerouslySetInnerHTML com dados do usuário

Autenticação/Autorização:

• Senhas hasheadas com bcrypt/argon2 (nunca MD5 ou texto simples)
• Rotas protegidas verificam a autenticação
• Verificações de autorização no lado do servidor, não apenas na UI
• Sem IDOR: verifique se os usuários possuem os recursos aos quais estão acessando

Exposição de dados:

• Respostas da API não vazam informações desnecessárias
• Mensagens de erro não expõem rastreamentos de pilha ou detalhes do banco de dados
• Paginação está presente nos endpoints de lista

Dependências:

• Execute npm audit ou uma ferramenta equivalente
• Sinalize pacotes criticamente desatualizados ou vulneráveis

5. Verificação de Escalabilidade

Banco de Dados:

• Consultas N+1: loops com chamadas de banco de dados internas → use JOINs ou consultas em lote
• Índices ausentes em colunas WHERE/ORDER BY
• Consultas ilimitadas: adicione LIMIT ou paginação
• Evite SELECT *: especifique colunas

Design de API:

• Operações pesadas (como e-mail, relatórios, processamento de arquivos) → mova para uma fila em segundo plano
• Limitação de taxa em endpoints públicos

…