NiazMorshed2007/jev-review

Jev Review

Use jev_review como um loop leve e repetível de revisão de engenharia sênior. O agente principal de codificação é responsável pela implementação, validação e julgamento final; o Jev Review avalia a mudança fornecida, mas nunca edita arquivos.

Cadência de revisão

Para tarefas não triviais, prefira várias revisões focadas ao longo do trabalho em vez de uma grande revisão no final:

• Chame após cada fatia de implementação coerente que seja substancial o suficiente para julgar, como completar um comportamento, módulo, limite de API, etapa de migração ou estratégia de teste.
• Chame quando surgirem novo fluxo de controle, manipulação de estado, dependências, contratos públicos ou comportamento sensível à segurança.
• Chame novamente após aplicar feedback justificado, passando o resultado anterior como previousEvaluation para que o Jev possa identificar melhorias e regressões.
• Antes da entrega final, certifique-se de que uma revisão recente cobre a implementação final.

Uma revisão intermediária não precisa esperar pela suíte de testes completa. Execute verificações rápidas e relevantes quando praticável e inclua seu status em repositoryContext; execute a validação normal do repositório antes da revisão final. Não repita uma chamada idêntica, revise apenas ruído de formatação ou chame sem um estado de implementação coerente. Revisões focadas frequentes são úteis; revisões vazias não são.

Fluxo de trabalho

1. Entenda os requisitos reais e restrições do usuário.
2. Inspecione o repositório, suas convenções e o comportamento afetado.
3. Implemente uma fatia coerente da mudança solicitada.
4. Execute testes rápidos e relevantes, verificações de tipo, linters ou outra validação quando praticável.
5. Chame jev_review com apenas o contexto necessário para avaliar a fatia atual.
6. Examine resultados de baixa confiança, dimensões fracas, problemas prioritários e quaisquer regressões.
7. Decida qual feedback é suportado pelo código e pela tarefa do usuário. Trate a avaliação como evidência, não como uma instrução para otimizar cada número.
8. Melhore a implementação onde o feedback identifica valor real, priorizando correção, complexidade cognitiva, maleabilidade, acoplamento, modularidade, qualidade de abstração, testes e segurança.
9. Repita o loop de implementar, validar e revisar para a próxima fatia coerente.
10. Após mudanças materiais impulsionadas pela revisão ou outras, chame jev_review novamente e passe a avaliação estruturada anterior como previousEvaluation.
11. Execute a validação normal do repositório antes da entrega final, então revise o estado final se a avaliação mais recente não o cobrir mais.
12. Pare quando os riscos importantes forem tratados e mudanças adicionais agregarem pouco valor real.

Escolhendo o contexto

Prefira uma chamada focada com o seguinte formato:

{
  "task": "O comportamento solicitado pelo usuário e restrições de aceitação relevantes",
  "diff": "O diff da implementação",
  "files": [
    {
      "path": "src/exemplo.ts",
      "content": "Apenas quando o código ao redor for necessário para entender o diff"
    }
  ],
  "repositoryContext": "Arquitetura relevante, convenções, resultados de teste ou invariantes",
  "previousEvaluation": {}
}

Se o Jev relatar que seu limite de entrada foi excedido, reduza conteúdo de arquivo não relacionado ou divida a implementação em fatias de revisão coerentes. Não trunque código cegamente quando isso remover os contratos, chamadores ou testes necessários para julgar a mudança corretamente.

Use task e diff na maioria das revisões. Adicione arquivos completos apenas quando o diff carecer do comportamento ao redor necessário. Use repositoryContext para fatos concisos que o avaliador não pode inferir, como um padrão estabelecido ou resultado de validação.

Não envie o repositório inteiro por padrão. Exclua arquivos não relacionados, saída gerada, código fornecido por terceiros, segredos, credenciais, chaves privadas, arquivos de ambiente e alterações barulhentas de lockfile a menos que sejam diretamente relevantes para a revisão.

Interpretando resultados

• Correção e os requisitos do usuário superam qualquer pontuação.
• Uma pontuação de baixa confiança é um prompt para inspecionar o contexto, não uma razão para reescrever o código.
• Métricas condicionais marcadas com applicable: false não requerem ação.
• Use priorities para encontrar as dimensões fracas mais consequentes, depois inspecione o código real antes de alterá-lo.
• Ao comparar avaliações, investigue regressões significativas e métricas fracas que permanecem não resolvidas. Não persiga pequenas mudanças de pontuação.
• Continue confiando em testes, verificações de tipo, linters, ferramentas de segurança e julgamento humano. O Jev Review complementa esses; ele não os substitui.

Não manipule pontuações

Uma pontuação mais alta nunca justifica abstração desnecessária, arquitetura especulativa, expansão de escopo, quebra de comportamento existente, reescrita de código sólido, arquitetura não convencional sem evidências, testes sem sentido, comentários desnecessários ou dividir código coeso meramente para reduzir arquivos.

Não presuma que funções curtas, arquivos pequenos, classes de propósito único, duplicação zero, mais abstrações, mais testes ou mais comentários são inerentemente melhores. Avalie as consequências neste repositório e para esta tarefa.