Revisão de PR

O que Revisão de PR faz?

Procedimento para revisar um PR. As regras de revisão (tom, categorias de comentários, fluxo de decisão, o que não fazer) estão no Playbook em "Revisões de PR"; esta skill é o como. Não reescreva as regras aqui, aplique-as. Os "Padrões Compartilhados" do Playbook se aplicam em toda parte (seja conciso, sem enrolação de IA, verifique não afirme, nunca invente).

Antes de revisar

1. Peça o ticket primeiro. De acordo com a primeira etapa obrigatória do Playbook, não busque o diff nem analise nada até ter o ticket. O ticket define o tipo de trabalho (feature vs follow-up vs investigação) e os critérios de aceitação, que alteram a forma como você revisa.
2. Identifique o PR: peça o número/URL do PR se não for fornecido.

Colete contexto

• Busque o diff e os metadados com a CLI do GitHub: gh pr view <pr> e gh pr diff <pr>.
• Para um PR de investigação, verifique também docs/investigations/ para o formato esperado.
• Leia os arquivos alterados por completo, não apenas os trechos do diff, quando o comportamento depender do código ao redor.

Revisão

Percorra o diff arquivo por arquivo. Aplique a seção "Revisões de PR" do Playbook:

• Execute a checklist do Playbook (critérios de aceitação, falhas de compilação/teste, chamadores atualizados, cobertura de testes, evidências para investigações).
• Classifique cada achado como bloqueante, nit ou pergunta, de acordo com o Playbook.
• Use o fluxo de decisão do Playbook para decidir se cada observação merece um comentário.
• As regras de escopo diferem por tipo de ticket (follow-up: resolva tudo aqui; feature: refatorações válidas). Confirme o tipo a partir do ticket.
• De acordo com o "Verifique, não afirme" do Playbook: verifique as alegações você mesmo antes de repeti-las. Execute gh pr checks <pr> para CI, faça grep no repositório por símbolos removidos. A descrição do PR é a alegação do autor, não uma evidência.
• De acordo com o "Não descarte silenciosamente o comportamento existente" do Playbook: uma regressão comportamental não confirmada é um achado bloqueante, mesmo que o autor a tenha sinalizado na descrição.

Saída

Siga o "Revisões de PR > Formato" do Playbook. Produza a revisão diretamente no chat (não em um arquivo, a menos que o usuário peça um), como um veredito em uma linha seguido pelos achados. NÃO é uma redação em prosa, um registro de conversa ou seções como "Contexto Coletado"/"Revisão Inicial". Cada achado é exatamente: uma linha de referência de localização+código, o comentário em um bloco de código copiável, e o porquê. Concretamente, um achado tem esta aparência:

### Bloqueante

`internal/adapters/users/adapter.go:281`
```go
_, err := u.providersClient.Update(ctx, request)
```

Comentário (cole no PR):

Isso elimina a repetição de consistência eventual na qual essas gravações dependem. A latência entre Core e Usuários aparece como NotFound, que a nova política apenas transitória não repetirá, fazendo com que a gravação falhe imediatamente.

Porquê: O AC #3 pede para confirmar que nenhum caminho depende da repetição de erros em nível de aplicação; este caminho dependia, e o diff o remove sem confirmar que a janela desapareceu.
````

Repita um bloco desses para cada achado, agrupado sob `### Bloqueante` / `### Nits` / `### Perguntas` (omitir grupos vazios). O bloco de código após "Comentário" é a única coisa que o usuário copia para o GitHub; todo o resto é para navegação. Se estiver tudo certo, apenas a linha do veredito.

## Postagem (apenas se solicitado)

Se o usuário quiser que os comentários sejam postados em vez de redigidos no chat, confirme primeiro, depois use `gh pr review` / `gh pr comment`. O padrão é redigir no chat.