Execução de Code Review

Contexto

• Stack: .NET 8 / C# — arquitetura em camadas (Api → Aplicacao → Dominio → Repositorio → Infra)
• Banco: PostgreSQL via EF Core (Npgsql)
• Mensageria: RabbitMQ (Publisher/Consumer)
• Testes: xUnit + AutoDomainData + FakeItEasy
• Branch principal: liberada
• Documentação de tasks: ./docs/tasks/[tipo]-[nome]/

Procedimentos

Etapa 1: Análise de Documentação (Obrigatória)

1. Identificar a feature sendo revisada e localizar os documentos em ./docs/tasks/prd-[feature-slug]/:
   • techspec.md — para entender as decisões arquiteturais esperadas.
   • tasks.md — para verificar o escopo implementado.
   • prd.md, investigacao.md ou spike.md — para entender a motivação.
2. Ler as regras do projeto em .claude/rules/:
   • code-style.md — estilo de código (chaves, construtores, expression body).
   • naming-conventions.md — prefixos e sufixos obrigatórios.
   • service-patterns.md — padrões de Service (nunca injetar Service em Service).
   • repository-patterns.md — padrões de Repository e EF Core.
   • application-patterns.md — padrões de orquestração na camada Aplicação.
   • controller-patterns.md — padrões de Controller.
   • entity-patterns.md — padrões de entidade e validação.
   • testing-patterns.md — padrões de testes unitários.
   • rabbitmq-patterns.md — padrões de Publisher/Consumer.
   • infrastructure-patterns.md — padrões de infraestrutura.
3. NÃO pule esta etapa — entender o contexto é fundamental para a revisão.

Etapa 2: Análise das Alterações de Código (Obrigatória)

1. Executar comandos git para entender o que mudou:
   • git status para ver arquivos modificados.
   • git diff e git diff --staged para ver todas as alterações.
   • git log liberada..HEAD --oneline para ver os commits da branch.
   • git diff liberada...HEAD para o diff completo da branch.
2. Para cada arquivo modificado: a. Analisar alterações linha por linha. b. Verificar aderência aos padrões do projeto. c. Identificar problemas potenciais.
3. Ler o contexto completo dos arquivos modificados, não apenas o diff.

Etapa 3: Verificação de Conformidade com Regras (Obrigatória)

1. Para cada alteração de código, verificar:
   • Convenções de nomenclatura (IServ, Serv, IRep, Rep, IAplic, Aplic, *DTO, *Validator, *Config, etc.).
   • Aderência à estrutura de pastas Modulo[Nome] espelhada entre camadas.
   • Estilo de código: sempre {} em if, sem primary constructor, sem expression body em métodos.
   • Padrão de erros: AppException com EnumErro específico por validação — nunca código genérico.
   • Service nunca injeta outro Service — usa IRep para dependências entre domínios.
   • Tabelas novas usam IdentificadorLong (nunca Identificador int).
   • AsNoTracking() em consultas de leitura.
   • TransactionScope.CriarAsyncFlow() em métodos async com scope.Complete() ao final.
   • Nenhuma dependência não autorizada introduzida.

Etapa 4: Verificação de Aderência à Tech Spec (Obrigatória)

1. Comparar a implementação com a Tech Spec:
   • Arquitetura implementada conforme especificado.
   • Componentes criados conforme definido.
   • Interfaces e contratos seguem a especificação.
   • Modelos de dados conforme documentado.
   • Endpoints/APIs conforme especificado.
   • Integrações implementadas corretamente.

Etapa 5: Verificação de Completude das Tasks (Obrigatória)

1. Para cada task marcada como concluída:
   • Código correspondente foi implementado.
   • Critérios de aceite foram atendidos.
   • Subtarefas foram todas concluídas.
   • Testes da task foram implementados.

Etapa 6: Execução de Testes (Obrigatória)

1. Compilar a solução: dotnet build.
2. Executar a suíte de testes: dotnet test.
3. Verificar:
   • Compilação sem erros.
   • Todos os testes passam.
   • Novos testes adicionados para código novo (xUnit + AutoDomainData + FakeItEasy).
   • Nomenclatura de testes segue o padrão MetodoNome_Condicao_ResultadoEsperado.
   • Testes são significativos (não apenas para cobertura).
4. O review NÃO PODE ser aprovado se build ou testes falharem.

Etapa 7: Análise de Qualidade de Código (Obrigatória)

1. Ler references/code-quality-checklist.md para o checklist completo.
2. Avaliar as seguintes dimensões:
   • Corretude: lógica correta, edge cases tratados.
   • Complexidade: funções não muito longas, baixa complexidade ciclomática.
   • DRY: sem código duplicado.
   • SOLID: princípios SOLID respeitados, especialmente inversão de dependência.
   • Nomenclatura: nomes claros, descritivos e seguindo convenções do projeto.
   • Tratamento de erros: AppException + EnumErro específico, sem try/catch genérico.
   • Segurança: sem vulnerabilidades óbvias (SQL injection, XSS, dados sensíveis expostos).
   • Performance: sem N+1 queries, uso correto de AsNoTracking(), projeções adequadas.
   • Banco de dados: migrations corretas, configs de EF Core adequadas.
   • Mensageria: Publishers/Consumers seguindo padrões (login no Consumer antes de acessar DadosAmbiente).

Etapa 8: Gerar Relatório de Review (Obrigatória)

1. Ler o template de relatório em assets/review-report-template.md.
2. Preencher todas as seções com os achados reais.
3. Classificar cada achado por severidade:
   • Crítico: testes falhando, bugs de produção, vulnerabilidades de segurança, perda de dados.
   • Major: violação de padrões arquiteturais, Tech Spec não seguida, problemas de performance.
   • Minor: estilo de código, nomenclatura, melhorias de legibilidade.
   • Positivo: boas práticas identificadas, decisões acertadas.
4. Aplicar critérios de aprovação:
   • APROVADO: Todos os critérios atendidos, build e testes passando, código conforme regras e Tech Spec.
   • APROVADO COM RESSALVAS: Critérios principais atendidos, apenas issues minor ou poucos major não bloqueantes.
   • REPROVADO: Build ou testes falhando, issues críticos, violações graves de regras, não aderência à Tech Spec ou problemas de segurança.

Tratamento de Erros

• Se nenhuma alteração git for encontrada, reportar que não há nada para revisar.
• Se build ou testes falharem, o status do review DEVE ser REPROVADO independente dos demais achados.
• Se documentação (Tech Spec, tasks.md) não for encontrada em ./docs/tasks/, perguntar ao usuário qual feature está sendo revisada.
• Verificar se há arquivos que DEVERIAM ter sido modificados mas não foram.
• Ser construtivo nas críticas — sempre sugerir alternativas.