revisao-de-prlisted

# Revisão de pull request ## Ordem da revisão Revise nesta ordem e **pare no primeiro nível que reprovar**. Apontar nomes de variável num PR que tem race condition desperdiça o tempo de todo mundo. 1. **Faz o que promete?** Compare o diff com a descrição do PR. Código a mais que ninguém pediu é tão problema quanto código a menos. 2. **Está correto?** Casos de borda, nulos, listas vazias, erro de rede, concorrência. 3. **Quebra alguém?** Contrato de API, schema, formato de dados persistidos, comportamento que outro time consome. 4. **Dá pra manter?** Duplicação, acoplamento, nomes. 5. **Estilo.** Só se o linter não pega. Se pega, o comentário é no linter, não no PR. ## O que buscar ativamente Estas são as classes de defeito que passam por revisão humana com mais frequência: - **Erro engolido** — `catch` que loga e segue, `?.` mascarando estado inválido. - **Concorrência** — leitura e escrita sem transação, `await` dentro de laço mutando estado compartilhado. - **Fronteira de confiança** — entrada de usuário chegando em query, path ou shell sem validação. - **Vazamento** — credencial, token ou PII em log, mensagem de erro ou resposta. - **Migração destrutiva** — `DROP`/`ALTER` sem plano de rollback, ou incompatível com a versão anterior rodando em paralelo durante o deploy. - **Teste que não testa** — asserção sobre mock, `expect(true)`, teste que passa com a implementação removida. ## Ao revisar código gerado por agente Peso extra em: dependência que não