Writing Structured Feedback

Passo 1 — Coletar e normalizar todos os achados

Reunir todos os achados das quatro revisões técnicas em um único pool. Para cada achado, garantir que os campos mínimos estejam presentes:

- Localização: arquivo e linha.

- Descrição: o que está errado e por quê. - Impacto: consequência se não for corrigido. - Severidade: como cada skill de revisão classificou.

Achados sem localização ou sem descrição clara devem ser reformulados antes de continuar.

Passo 2 — Classificar cada achado em uma das três camadas

Aplicar os critérios de classificação abaixo para cada achado:

**Camada 1 — Bloqueante (deve ser corrigido antes do merge):**

- Bugs que produzem comportamento incorreto em cenários cobertos pelos requisitos. - Qualquer vulnerabilidade de segurança de severidade crítica ou alta. - Ausência de teste para comportamento novo crítico de negócio. - Problemas de performance que degradam SLA em carga previsível de produção. - Breaking changes em contratos externos não documentados ou não versionados.

**Camada 2 — Importante (deve ser endereçado, cria risco se ignorado):** - Problemas de lógica em edge cases de baixa frequência. - Vulnerabilidades de segurança de severidade média. - Problemas de performance em cold paths ou com impacto moderado. - Testes frágeis que podem produzir falsos positivos ou falsos negativos. - Gaps de cobertura em cenários de erro não críticos.

**Camada 3 — Opcional (melhoria desejável, não urgente):** - Sugestões de legibilidade que não afetam comportamento. - Refatorações que reduzem complexidade sem risco de regressão. - Nomenclatura de testes que poderia ser mais descritiva. - Melhorias de performance que não impactam SLA.

Quando houver dúvida entre Camada 1 e 2, classificar como Camada 1.

Passo 3 — Ordenar achados dentro de cada camada

Dentro de cada camada, ordenar por:

1. Severidade declarada pelas skills de revisão (crítica → alta → média → baixa). 2. Impacto em produção (maior impacto primeiro). 3. Facilidade de correção (mais fácil primeiro, para reduzir atrito do autor).

Passo 4 — Redigir sugestão de resolução para cada item

Para cada achado que ainda não tem sugestão de resolução, redigir uma:

- Sugestão deve ser específica e acionável — não "refatore este código" mas "extraia a lógica de validação para um método separado e trate o caso nulo na linha 42".

- Quando houver múltiplas abordagens válidas, apresentar a principal e mencionar a alternativa. - Quando a correção exigir decisão de design além do escopo do PR, indicar que deve ser tratado em tarefa separada.

Passo 5 — Redigir sumário executivo

Escrever um sumário de 2–4 frases sobre o estado geral do PR:

- O PR está pronto para merge, condicionado a correções ou não pronto?

- Qual é a área de maior preocupação (se houver)? - Há algo que merece reconhecimento positivo — boa estrutura, testes bem escritos, solução elegante?

O sumário deve ser honesto. Pressão de prazo não justifica sumário diplomático que oculta problemas bloqueantes.

Passo 6 — Montar o documento final de feedback

Estrutura obrigatória do documento de saída:

```

## Code Review — [Nome do PR ou ID]

Sumário

[2–4 frases do Passo 5]

---

Bloqueante (deve corrigir antes de merge)

[Lista numerada de achados da Camada 1]

---

### Importante (deve endereçar, cria risco se ignorado)

[Lista numerada de achados da Camada 2]

---

### Opcional (melhoria desejável)

[Lista numerada de achados da Camada 3]

---

### Perguntas para o autor

[Lista de perguntas de clarificação pendentes, se houver]

```

---