Revisar Convenções

O que Revisar Convenções faz?

Revise se o código alterado se encaixa neste repositório, não apenas se funciona. Favoreça revocação sobre precisão: identifique inconsistências plausíveis e baseadas em evidências para um humano fazer a triagem, incluindo pequenos desvios de estilo e padrão que uma revisão focada em defeitos omitiria.

Esta é uma revisão somente leitura. Não modifique arquivos, execute formatadores que escrevam arquivos ou poste comentários.

Procedimento

1. Estabeleça o diff. Use o destino solicitado. Caso contrário, inspecione as alterações staged e unstaged; se não houver nenhuma, compare a branch atual com sua base de merge em relação à branch base estabelecida. Declare qualquer incerteza sobre o destino da comparação.
2. Leia as orientações locais. Verifique os AGENTS.md, CONTRIBUTING.md, documentos de estilo/arquitetura e configuração de lint/teste aplicáveis. Não presuma que os documentos cobrem convenções não documentadas.
3. Busque ativamente por precedentes fora do diff. Para cada escolha de implementação nova ou alterada, inspecione:
   • Mesmo contexto primeiro: código adjacente, arquivos irmãos, a área de UI que contém (ex: barra de ferramentas, cabeçalho, diálogo), o mesmo pacote/módulo, ou testes vizinhos — mesmo que implementem uma funcionalidade diferente.
   • Mesmo comportamento em seguida: outras implementações de controles de UI, operações, auxiliares ou testes equivalentes.
   • Direção mais ampla por último: padrões de todo o repositório e migrações documentadas quando a prática local não estiver clara. Compare múltiplos exemplos representativos quando prático. Priorize precedentes da mesma região de UI, módulo ou fronteira arquitetural em vez de implementações funcionalmente similares em outros lugares. Trate uma implementação em um contexto diferente como um contraexemplo apenas quando a mesma convenção se aplica a ambos os contextos.
4. Procure deliberadamente por incompatibilidades de convenção:
   • UI: misturar sistemas de componentes dentro de uma área estabelecida; escolher um controle, composição, estilo, prop ou padrão de evento diferente da UI vizinha.
   • Código: ignorar um auxiliar/wrapper existente, usar um idioma diferente de gerenciamento de estado ou tratamento de erros, convenções de nomenclatura/tipo/importação ou posicionamento inconsistente de arquivos.
   • Testes: fixture/setup, nomenclatura, estrutura, localizador ou estilo de asserção inconsistentes; alterações em seletores ou asserções E2E existentes que ampliem seu alvo sem uma necessidade explicada.
   • Escopo da alteração: introduzir uma segunda maneira de fazer a mesma coisa, ou reescritas de estilo não relacionadas dentro do diff.
5. Desafie incompatibilidades aparentes. Antes de relatar uma incompatibilidade, estabeleça a responsabilidade e intenção reais do código alterado a partir de sua implementação, chamadores e testes. Não aplique uma convenção apenas porque terminologia ou APIs relacionadas aparecem. Determine se a convenção citada rege o comportamento sendo testado, o mecanismo de implementação ou a localização do teste, e explique por que ela se aplica a esta alteração. Verifique se uma migração documentada, exceção deliberada ou requisito genuinamente diferente explica a escolha. Quando os exemplos entrarem em conflito, relate a incerteza em vez de inventar uma regra uniforme.

Limite de relato

Seja agressivo para encontrar candidatos, não para declarar regras. Relate desvios menores e potencialmente discutíveis quando houver um precedente específico ou política documentada para comparar. Não exija prova de um defeito em tempo de execução, alta gravidade ou múltiplos exemplos idênticos.

Relate convenções inferidas com forte suporte mesmo quando não estiverem explicitamente documentadas; rotule-as como inferidas e cite a evidência de suporte.

• Incompatibilidade clara: orientação diretamente aplicável ou precedente local forte.
• Possível incompatibilidade: precedente concreto, mas limitado/conflitante; vale a pena revisão humana. Identifique explicitamente a incerteza.

Não invente convenções, cite código não relacionado como evidência ou transforme um exemplo incidental em uma regra universal. Pule trivia de formatador/linter puro, preferências sem evidência de repositório, problemas pré-existentes fora da alteração e bugs genéricos de correção/segurança/desempenho tratados por $review-agent. Não exija refatorações amplas para impor uniformidade.

Exemplo: Quando uma alternância é adicionada a uma barra de ferramentas, inspecione outros controles naquela barra de ferramentas, bem como alternâncias em outros lugares. Em uma barra de ferramentas baseada em Quasar, usar um sistema de componentes diferente pode merecer um achado, mesmo que funcione corretamente. Este é um método para encontrar convenções locais, não uma regra geral exigindo Quasar.

Saída

Relate todos os candidatos distintos e baseados em evidências, incluindo os de baixo impacto; mescle instâncias duplicadas do mesmo problema. Ordene por relevância provável para os mantenedores, não apenas por gravidade.

Para cada achado, forneça:

• Localização: arquivo e linha(s) alterados.
• Evidência da convenção: arquivo(s)/localizações exatas existentes ou regra documentada; rotule documentada ou inferida.
• Incompatibilidade: o que difere e por que isso importa para a consistência.
• Sugestão: menor ajuste razoável, expresso como sugestão para casos incertos.
• Confiança: alta, média ou baixa; explique a incerteza para média/baixa.

Separe Incompatibilidades claras de Possíveis incompatibilidades. Se nenhum dos dois tiver candidatos baseados em evidências, diga Nenhum achado de convenção. Não descarte silenciosamente casos plausíveis apenas porque são estilísticos ou podem ser rejeitados durante a revisão manual.