Revisão de Task

Procedimentos

Etapa 1: Identificar a Task

1. Procure arquivos de task no diretório ./docs/tasks/. As tasks ficam em subdiretórios organizados por tipo de documento-fonte:
   • ./docs/tasks/prd-[nome]/[num]_task.md — tasks de PRD
   • ./docs/tasks/investigacao-[nome]/[num]_task.md — tasks de Investigação
   • ./docs/tasks/spike-[nome]/[num]_task.md — tasks de Spike
2. Se um número de task e nome do documento-fonte forem fornecidos, encontre o arquivo específico [num]_task.md no subdiretório correspondente.
3. Se apenas o nome do documento-fonte for fornecido, liste todas as tasks do subdiretório.
4. Se nenhum contexto for fornecido, liste os subdiretórios disponíveis em ./docs/tasks/ e peça ao usuário para especificar.
5. Leia o tasks.md do subdiretório para entender o contexto geral e dependências entre tasks.
6. Leia e compreenda completamente os requisitos da task individual ([num]_task.md).

Etapa 2: Identificar Arquivos Alterados

1. Use git diff e git log para identificar arquivos alterados como parte desta task.
2. Revise cada arquivo alterado cuidadosamente.
3. Leia o contexto completo dos arquivos modificados, não apenas os diffs.

Etapa 3: Carregar Padrões do Projeto

1. Leia references/code-standards.md para o checklist completo de padrões .NET/C#.
2. Leia CLAUDE.md na raiz do projeto para regras adicionais e armadilhas comuns.
3. Leia .claude/rules/code-style.md e .claude/rules/naming-conventions.md para referência detalhada.

Etapa 4: Conduzir a Revisão

1. Revise o código contra TODOS os critérios do projeto:

   Nomenclatura:

   • Prefixos/sufixos corretos: IServ, Serv, IRep, Rep, Aplic, IAplic, DTO, View, Validator, Config, Controller, Publisher, Consumer
   • Conversão DTO segue padrões ToClass/FromClass

   Code Style:

   • Sempre {} em blocos if, mesmo com uma única instrução
   • Sem primary constructor — sempre construtor tradicional com {}
   • Sem expression body (=>) em métodos — sempre corpo com {}
   • EnumErro específico por validação de negócio — nunca códigos genéricos

   Arquitetura:

   • Service nunca injeta outro Service — orquestração fica no Aplic
   • Camadas respeitadas: Api → Aplicacao → Dominio → Repositorio
   • DI Registration via Scrutor auto-scanning

   EF Core / Repositório:

   • AsNoTracking() em consultas de existência
   • IgnoreUnidadeFilters() quando consultar cross-unit
   • scope.Complete() chamado ao final de TransactionScope
   • CriarAsyncFlow() para TransactionScope em métodos async
   • Tabelas novas com IdentificadorLong (nunca Identificador int)
   • Usar IdentificadorLongTenant<Tenant> ou IdentificadorLongUnidade<Tenant, Unidade>

   RabbitMQ:

   • Login no Consumer antes de acessar serviços que dependem de DadosAmbiente
   • Publisher/Consumer seguem nomenclatura com sufixos corretos

   Geral:

   • Sem vulnerabilidades de segurança (injeção SQL, XSS, etc.)
   • Tratamento de erros com AppException e EnumErro específico
   • FluentValidation para validações de entrada

2. Verifique conformidade com CLAUDE.md e skills aplicáveis.

Etapa 5: Classificar Problemas

1. Para cada problema encontrado, classifique como:
   • CRÍTICO: Bugs, problemas de segurança, funcionalidade quebrada, Service injetando Service, TransactionScope sem Complete() ou sem CriarAsyncFlow(), tabela nova com Identificador (int).
   • MAJOR: Violações de padrões de código do projeto (primary constructor, expression body, if sem {}), EnumErro genérico, testes ausentes, nomenclatura fora do padrão.
   • MINOR: Sugestões de estilo, melhorias menores, otimizações opcionais.
   • POSITIVO: Coisas bem feitas que devem ser reconhecidas.

Etapa 6: Validar Build e Testes

1. Execute dotnet build para verificar a compilação do projeto.
2. Execute dotnet test para verificar se todos os testes passam.
3. Se houver migrations novas, valide a convenção de nome: DDMMAAAA-acao-descricao.

Etapa 7: Gerar Artefato de Revisão

1. Leia o template em assets/review-artifact-template.md.
2. Crie o arquivo [num]_task_review.md no MESMO subdiretório do arquivo [num]_task.md (ex: ./docs/tasks/prd-[nome]/1_task_review.md).
3. Aplique os critérios de status:
   • APROVADO: Sem problemas críticos ou major. Pronto para produção.
   • APROVADO COM OBSERVAÇÕES: Sem problemas críticos, apenas minor ou poucos problemas major não bloqueantes.
   • MUDANÇAS SOLICITADAS: Problemas críticos encontrados OU múltiplos problemas major que precisam ser resolvidos.

Diretrizes

• Seja minucioso mas justo: revise cada arquivo alterado, mas reconheça o bom trabalho.
• Seja específico: sempre referencie o arquivo exato e o número da linha para problemas.
• Forneça soluções: sugira correções com exemplos de código C#, não apenas problemas.
• Escreva o artefato de revisão em português brasileiro. Exemplos de código permanecem em C#.

Tratamento de Erros

• Se ./docs/tasks/ não existir ou estiver vazio, informe ao usuário que não há tasks geradas.
• Se nenhum arquivo [num]_task.md for encontrado no subdiretório, liste os subdiretórios disponíveis e peça ao usuário para especificar.
• Se o git diff não mostrar alterações, informe que não há nada para revisar.
• Se build ou testes falharem, inclua as falhas no artefato de revisão como problemas críticos.