keykovar/skill-fe-code-review

Revisão de Código Frontend

Regras Padrão

• Corresponda ao idioma do usuário. Se o usuário escrever em português, responda em português.
• Traduza títulos de seções, rótulos de status e recomendações para o idioma do usuário. Mantenha rótulos em inglês estáveis quando útil, por exemplo Blocking: Deve Modificar.
• Para solicitações em português, use o modelo em português para o modo selecionado. Não use títulos de seção apenas em inglês, como Conclusão Geral, Escopo da Revisão, Lacunas de Teste ou Recomendação Final.
• Padrão: revisão somente leitura.
• Não modifique arquivos, formate arquivos, faça commit, push, reset, instale pacotes, mude de branch ou execute comandos destrutivos, a menos que o usuário peça explicitamente.
• Uma solicitação para revisar, avaliar a qualidade da revisão ou gerar um relatório de revisão autoriza apenas saída de chat. Não crie ou atualize relatórios, planos, listas de tarefas, arquivos Markdown ou arquivos de origem, a menos que o usuário peça explicitamente por esse artefato de arquivo ou por alterações de código. Modos de cliente nomeados como Agente, Construir, Escrever ou similares não substituem este limite.
• Baseie as descobertas em código real, diffs, caminhos de chamada, fluxo de dados, versões de pacotes e contratos de tempo de execução.
• Não infira semântica apenas a partir de nomes.
• Não apresente inspeção estática como verificação de tempo de execução.
• Não relate problemas vagos. Explique a condição de gatilho, impacto, causa raiz, correção sugerida e método de verificação.
• Se nenhum problema claro for encontrado, diga isso diretamente e liste os riscos residuais ou áreas não verificadas.

Descoberta de Escopo

Inspecione o escopo solicitado. Se o usuário não especificar um, revise todas as alterações não commitadas. Colete o inventário uma vez.

Quando o escopo solicitado for todas as alterações não commitadas, scripts/collect-review-context.mjs está disponível dentro do limite autorizado do Skill/workspace, e o Node.js estiver disponível, execute-o em vez de emitir comandos de inventário Git separados:

node <skill-directory>/scripts/collect-review-context.mjs --workspace "$PWD"

O script é somente leitura e retorna a raiz do repositório, HEAD, status, diff e patch unstaged, patch staged, arquivos não rastreados, git diff --check e a presença do CodeGraph. Ele sempre coleta a árvore de trabalho não commitada completa. Não o execute para revisões apenas staged, commit, merge commit, branch, PR, intervalo ou caminho específico, pois isso leria alterações fora do escopo solicitado. Use os comandos Git limitados correspondentes para esses escopos. Para uma revisão de todas as alterações não commitadas, reutilize a saída do coletor e não reexecute comandos equivalentes. Se o script não puder ser executado dentro do limite autorizado, colete as mesmas evidências manualmente em um lote somente leitura quando o cliente suportar:

git status --short
git diff --stat
git diff --find-renames
git diff --cached --find-renames
git ls-files --others --exclude-standard

Estabeleça e relate a linha de base de comparação antes de revisar:

• Alterações não commitadas: HEAD versus a árvore de trabalho, incluindo arquivos staged, unstaged e não rastreados relevantes.
• Alterações staged: HEAD versus o índice.
• Commit: seu pai versus o commit.
• Branch ou PR: base de merge versus cabeça do alvo, a menos que o usuário especifique outro intervalo.
• Commit de merge: primeiro pai versus o commit de merge, a menos que o usuário especifique outro pai ou linha de base.

Se arquivos de pacote ou configuração foram alterados, inspecione o impacto de dependência e construção. Sempre resuma o escopo solicitado, linha de base de comparação, arquivos modificados, arquivos staged, arquivos unstaged, arquivos não rastreados e comandos de validação que foram executados ou ignorados.

Para Revisão de Correção, identifique também o relatório de revisão ou descobertas anteriores e o diff de correção. Mantenha o intervalo de funcionalidade original separado do intervalo de correção posterior.

Se .codegraph/ existir na raiz do repositório e o CodeGraph estiver disponível, use-o antes de buscas amplas de grep/find para entender símbolos, caminhos de chamada e raio de explosão.

Use evidências nesta ordem:

1. Código fonte do repositório, diffs, caminhos de chamada, testes, configuração, arquivos lock e documentação do projeto.
2. Tipos de dependência instalada e código-fonte para a versão local resolvida.
3. Documentação oficial por meio de um canal cujo contrato de ferramenta permita revisão de código, somente quando o comportamento de framework ou biblioteca sensível à versão ainda não puder ser estabelecido localmente.

O contrato atual da ferramenta oficial Context7 MCP exclui revisão de código. Não use o Context7 ao executar esta habilidade, direta ou indiretamente. Isso inclui pedir a um subagente, delegado, proxy, wrapper ou outra ferramenta ou sessão para chamá-la em nome da revisão. Não ignore a restrição reformulando, decompondo, sanitizando ou renomeando o trabalho de revisão como uma pergunta de documentação. Se uma conclusão depender de semântica externa e nenhuma fonte autorizada e permitida estiver disponível, marque-a como Não é Possível Verificar e identifique a evidência ausente.

Ao usar qualquer serviço de documentação externa, envie apenas a biblioteca pública, versão, API ou pergunta de comportamento sanitizada necessária para verificação. Nunca envie código-fonte privado, diffs, caminhos de repositório, dados de API interna, credenciais, tokens, dados de usuário ou identificadores proprietários.

Evidência Condicional de Tempo de Execução do Navegador

Use o Playwright ou outra ferramenta de automação de navegador disponível somente quando todas estas condições forem atendidas:

• O comportamento alterado for observável no navegador e as evidências de tempo de execução puderem confirmar ou refutar materialmente uma descoberta, como roteamento, formulários, estado de UI assíncrono, comportamento de armazenamento ou cookies, hidratação, foco, rolagem, transbordamento responsivo ou ordenação de requisições.
• Existir um ponto de entrada concreto, como uma rota local, URL, interação ou harness de teste, e o resultado observável esperado for explícito a partir do requisito, comportamento de linha de base ou um contrato de teste existente.
• Um ambiente de teste local ou isolado adequado já estiver executável sem instalar dependências, alterar a configuração do projeto ou escrever artefatos gerados no repositório.
• O estado inicial for controlado e repetível, ou puder ser reconstruído antes de cada execução sem depender de dados de produção ou de uma conta real.
• O caminho for isolado e puder ser exercitado sem acesso de produção, pagamentos reais, dados reais de usuário, ações destrutivas ou efeitos colaterais externos irreversíveis.

Mantenha a verificação do navegador somente leitura em relação ao repositório, sistemas de produção e contas reais. O estado isolado do navegador local pode mudar quando exigido pelo cenário, mas redefina-o quando prático e não trate essa mudança de estado como verificação de dados do produto.

Registre o ambiente e o tipo de URL, ponto de entrada, navegador e viewport, estado inicial e como ele é reproduzido, resultado esperado, ações, resultado observado e resumo relevante do console ou da rede. Masque credenciais, tokens, dados pessoais, corpos de requisição e conteúdo de resposta sensível. Se as evidências de tempo de execução forem necessárias, mas a condição não for satisfeita, use Não é Possível Verificar e indique o ambiente, estado, expectativa ou capacidade indisponível.

A automação do navegador prova apenas o caminho exercitado no ambiente registrado. Uma verificação de navegador bem-sucedida não prova o comportamento em todos os navegadores ou viewports e não substitui a verificação de WebView real, bridge nativa, dispositivo, backend, implantação, monitoramento ou produção.

Seleção de Modo

• Use Revisão Rápida por padrão para mudanças diárias, PRs pequenos, correções de bugs e refatorações locais.
• Use Revisão Profunda para pagamento, autenticação, roteamento/navegação, bridge WebView, RTC/áudio/vídeo, SSR/hidratação, i18n, estado global/store, cache/persistência, configuração de build/deploy, atualizações de dependência, módulos compartilhados, código sensível a desempenho, branches de release, comportamento entre módulos ou refatorações grandes.
• Use Revisão de Correção quando o usuário pedir para revisar novamente correções, verificar descobertas anteriores, verificar se os comentários da revisão foram resolvidos ou detectar regressões introduzidas pelas correções.

Carregue exatamente uma referência de modo antes de revisar:

• Revisão Rápida: references/quick-review.md
• Revisão Profunda: references/deep-review.md
• Revisão de Correção: references/fix-review.md

Para Revisão de Correção, use as descobertas anteriores da conversa atual quando disponíveis. Caso contrário, exija que o usuário forneça o relatório de revisão anterior, a lista de problemas ou um caminho legível para ele. Não invente descobertas anteriores nem afirme que um problema foi resolvido sem uma linha de base utilizável.

Detecção de Tecnologia

Inspecione os arquivos do projeto e carregue apenas as referências correspondentes:

• React: carregue references/react.md para React, React DOM, Next.js, Remix, JSX/TSX ou hooks.
• Vue: carregue references/vue.md para Vue, Nuxt, Pinia, arquivos .vue ou Composition API.
• TypeScript: carregue references/typescript.md para projetos TypeScript ou contratos TypeScript alterados.
• JavaScript: carregue references/javascript.md para projetos JavaScript ou código com muita manipulação de forma de execução.
• Híbrido/WebView: carregue references/hybrid-webview.md para bridges, contratos nativos, WebView, shell de aplicativo, armazenamento, teclado, área segura, áudio ou vídeo.
• Risco de release: carregue references/release-risk.md para Revisão Profunda, branches de release, feature flags, rollout, monitoramento, rollback ou fluxos de alto risco.

Disciplina de Evidência Rápida/Correção

Aplique estas regras de execução obrigatórias para Revisão Rápida e Revisão de Correção. Elas reduzem a exploração repetida sem reduzir a cobertura necessária:

• Use uma viagem de ida e volta somente leitura por grupo de evidências quando o cliente suportar lotes: arquivos de Skill/referência selecionados; coletor de contexto inicial ou sua alternativa manual; fonte alterada e de linha de base mais pesquisas de consumidor direto; e validação aplicável restante. Divida um grupo apenas para evitar um resultado excessivamente grande ou quando o primeiro resultado expor um novo contrato não resolvido. Não concatene arquivos grandes não relacionados apenas para reduzir o número de comandos.
• Congele e reutilize o inventário Git inicial. Em uma revisão somente leitura, não repita consultas de status, name-status, stat, diff staged, arquivo não rastreado ou diff inalterado no final. Um avaliador host, não o modelo de revisão, realiza qualquer comparação de integridade pós-execução independente.
• Leia cada instrução selecionada, diff, arquivo de linha de base e intervalo de código-fonte sobreposto uma vez. Prefira uma leitura com números de linha que cubra o intervalo necessário. Antes de qualquer leitura ou pesquisa repetida, identifique a pergunta de evidência específica não resolvida; pule o comando quando a saída existente já a responder.
• Após conhecer os arquivos alterados e os caminhos diretamente afetados, não execute buscas amplas de rg a partir de . ou um inventário de arquivos de repositório rg --files sem filtro. Escopo das buscas para o proprietário alterado, símbolos nomeados e caminhos diretamente afetados; expanda apenas quando uma correspondência concreta expuser outro consumidor ou contrato.
• Detecte tecnologia a partir de tipos de arquivo alterados, imports e no máximo uma leitura de manifesto relevante. Inspecione a configuração de pacote, lock, build ou TypeScript com mais profundidade apenas quando ela for alterada ou quando uma descoberta depender de sua versão resolvida ou contrato de compilador/build. Não investigue configuração ausente ou arquivos lock apenas para completar uma lista de verificação genérica.
• Pesquise uma vez por testes diretamente relevantes usando caminhos que se sabe existirem ou uma consulta de glob de nome de arquivo limitada. Se essa pesquisa não estabelecer nenhum teste aplicável, registre a lacuna; não tente novamente com nomes de diretório de teste adivinhados ou padrões alternativos em todo o repositório sem novas evidências.
• Combine verificações independentes de expressão ou determinísticas que exercitem o mesmo contrato de comportamento em uma viagem de ida e volta de validação. Não reexecute o diff apenas para preparar a explicação final.
• Quando o usuário ou avaliador declarar explicitamente que um HEAD sintético representa a linha de base do problema original, verifique o HEAD atual e o diff de correção e, em seguida, use essa linha de base declarada. Registre objetos de commit originais indisponíveis como um limite de evidência em vez de investigar cada objeto quando o fechamento não depender deles.
• Continue além desses grupos sempre que as evidências entrarem em conflito, uma condição alterada permanecer não classificada, um contrato diretamente afetado não for resolvido ou uma descoberta ainda não tiver seu gatilho e impacto. Estas são regras de completude, não um limite rígido de comando ou token.
• Pare de explorar quando a linha de base solicitada e o diff forem estabelecidos, cada entrada de razão de condição alterada no escopo for contabilizada, cada descoberta relatada tiver evidências suficientes, a validação necessária for concluída ou explicitamente limitada, e o contrato de saída selecionado puder ser preenchido de forma consistente. Não amplie as buscas meramente para aumentar a confiança subjetiva.

Análise de Comportamento Antes/Depois

Realize esta análise em todos os modos. Compare o comportamento, não apenas as linhas alteradas:

1. Identifique o comportamento antes da alteração e o comportamento pretendido após ela.
2. Detecte comportamento removido, enfraquecido ou preservado não intencionalmente.
3. Verifique branches, guards, fallbacks, limpeza, cancelamento, tentativas e tratamento de erro ausentes.
4. Antes de priorizar descobertas, construa um razão compacto interno de condições alteradas para cada condição, guard, fallback, padrão e retorno antecipado que foi adicionado, alterado, movido, dividido ou retido dentro de um bloco de decisão modificado no diff solicitado. Um guard textualmente inalterado permanece no escopo quando seu fluxo de controle, comportamento de retorno ou escritas de estado ao redor foram alterados. Compare quais valores de tempo de execução tomam cada branch antes e depois; não produza o razão por padrão.
5. Nesse razão, distinga ausência (null ou undefined) de valores falsy válidos como 0, false ou uma string vazia. Para escritas de estado atrás desses branches, rastreie as transições de um valor truthy ou não vazio anterior para cada valor falsy válido por meio de consumidores diretamente afetados; não inspecione apenas o valor atual isoladamente.
6. Considere cada entrada do razão antes de finalizar: classifique-a como preservação de comportamento, lacuna de evidência ou descoberta. Use preservação de comportamento somente após verificar se o comportamento preservado em si permanece correto para o contrato de tempo de execução visível e as transições de estado. Se um bloco de decisão modificado reter um defeito material, relate-o e identifique-o como um defeito retido, em vez de uma regressão introduzida pelo diff. Não omita uma condição alterada afetada apenas porque outra descoberta tem maior gravidade.
7. Rastreie chamadores, consumidores, eventos, contratos de API, armazenamento, cache e formas de dados de tempo de execução afetados.
8. Confirme o comportamento