Revisar um pull request
- Obtenha o diff. Para um número de PR use
gh pr diff <number>; caso contrário,git diff origin/main...HEAD. Leia também a descrição do PR, se houver (gh pr view <number>). - Leia os arquivos alterados por completo quando o diff isolado não for claro. Não revise código que você não leu.
- Verifique, nesta ordem:
- Correção: condições erradas, off-by-one, erros não tratados, condições de corrida, entradas nulas/vazias.
- Testes: cada mudança de comportamento está coberta? Os testes falhariam sem a alteração?
- Segurança: entrada não confiável chegando a shell, SQL, caminhos de arquivo ou HTML; segredos no diff.
- Compatibilidade: interfaces públicas alteradas, migrações, configuração ou variáveis de ambiente.
- Legibilidade: apenas problemas que atrasariam o próximo mantenedor. Pule preferências de estilo que o linter já cobre.
- Execute
npm testse existirem testes e reporte o resultado honestamente.
Formato de saída
## Resumo
Uma ou duas frases sobre o que o PR faz e seu veredito geral (aprovar / solicitar alterações / comentar).
## Correções obrigatórias
- `caminho/arquivo.js:42` O que está errado, por que importa, sugestão de correção.
## Considerações importantes
- `caminho/arquivo.js:90` ...
## Sugestões adicionais
- ...
Deixe uma seção de fora se estiver vazia. Cite arquivo:linha para cada achado. Não invente problemas: se a alteração está correta, diga isso no resumo. Não publique comentários no GitHub a menos que o usuário solicite.