chukaofili/agent-plugins

Verificar UI

Construir as telas é a primeira metade. Uma mudança na UI não está concluída até que tenha sido dirigida em um navegador real e suas capturas de tela estejam no PR. Uma verificação de tipo limpa, uma execução de lint e uma suíte de testes unitários dizem que o código compila e sua lógica se sustenta. Nenhum deles diz se o painel renderiza, ou se o rodapé fica onde o design o coloca. Revisores que nunca executam o branch julgam o trabalho pelas capturas de tela, ou não julgam.

1. Dirija em um navegador real, com dados reais

Use um aplicativo em execução com um banco de dados real (semeados), não mocks, e não apenas uma captura de tela do caminho feliz. Percorra cada estado que o design nomeia, mais aqueles que ele não nomeia:

• Ambos os temas. Cores escritas à mão são onde as variantes de modo escuro são esquecidas.
• Mobile e desktop. Os layouts se reorganizam em breakpoints, e rodapés e barras de ferramentas podem órfão metade do seu conteúdo.
• Estados vazio, carregando, no limite e de falha, não apenas o preenchido.
• Cada transição onde um diálogo ou visão fecha e outro abre.
• Abra todos os menus, popovers e dropdowns que você adicionou. Um menu que você nunca abre parece idêntico a um que crasha a página ao abrir.
• Verifique o console do navegador e o painel de rede em busca de erros enquanto você navega.

2. Execute uma varredura de revisão

Revise a mudança contra as diretrizes de design e framework que o repositório usa (sistema de design, acessibilidade, melhores práticas do framework). Se seu agente pode criar subagentes, execute um revisor por diretriz em paralelo em um modelo mais barato. É um trabalho de correspondência de padrões, não de julgamento.

• Forneça aos revisores as regras do próprio repositório. Um revisor que não as leu irá relatar decisões documentadas como violações.
• Diga a eles para apenas relatar. Em seguida, julgue cada descoberta você mesmo pela probabilidade do mundo real. Rejeite descobertas que seriam verdadeiras para um produto diferente, como conselhos de virtualização para uma lista limitada a uma dúzia de linhas.

3. Capture capturas de tela para o PR

Não uma descrição das telas: as telas. Capturá-las é também a maneira mais barata de pegar um estado que você não olhou de fato.

• Dirija o aplicativo real. Um script de navegador descartável que atinge cada estado é suficiente. Use os helpers de semeadura da estrutura E2E para alcançar estados que nenhum fluxo de UI produz, em seguida, exclua o script assim que as imagens existirem. Ele não afirma nada e não é cobertura.
• Reconstrua antes de capturar. Caso contrário, você pode capturar a tela do bug que acabou de corrigir.
• Aguarde as animações antes do obturador. "Visível" resolve quando um elemento está disposto, não quando sua transição de entrada termina, então uma captura ingênua mostra diálogos meio esmaecidos sem fundo. Aguarde a conclusão de animações finitas (filtrando as infinitas, como pulsos de esqueleto), com um timeout.
• Alcance cada estado da forma que um usuário faria onde puder. Forçar uma bandeira pula a corrida que pode expor um bug.
• Faça commit delas em docs/screenshots/<topico>/, ao lado do design que implementam, se houver um.
• Referencie-as pelo SHA do commit, não pelo branch, por exemplo, https://github.com/<org>/<repo>/blob/<sha>/<caminho>?raw=true. Uma URL de branch morre quando o branch é excluído na mesclagem e deixa o PR cheio de imagens quebradas.

Nenhum navegador disponível

Se o ambiente realmente não puder executar a UI (sem ferramentas de navegador, credenciais faltando, infraestrutura que você não controla), mencione isso na seção de Testing do PR. Nomeie o que bloqueou e o que você verificou em vez disso. Silêncio lê-se como "verificado".

Envie correções da revisão como um estágio sobreposto

Correções encontradas nesta passagem vão em um novo PR empilhado sobre a funcionalidade, para que a construção e a passagem de revisão permaneçam separadamente revisáveis (veja stacked-prs).

O que esta passagem pega

Nenhum deles veio de um verificador de tipo, linter ou suíte de testes unitários:

• Um esqueleto de carregamento que não correspondia à sua página. Ele esqueletoava uma barra de ferramentas que a página não tem, então cada navegação pulava entre dois layouts. Espelhe o layout real linha por linha, ou não envie um esqueleto.
• Dois diálogos pintados ao mesmo tempo em uma transição, porque cada diálogo estava montado e apenas sua bandeira open alternava. Oculto não é desmontado.
• Um flash de identidade errada: a própria linha do usuário oferecia para removê-lo por uma pintura, porque o cliente leu a sessão após a primeira renderização. Identidade que o servidor já conhece deve vir junto com a página.
• Um estado vazio falso: "Nenhum resultado encontrado" renderizado por um quadro antes da consulta resolver, porque zero linhas significava tanto "carregando" quanto "vazio".
• Um token de design trocado por um de aparência semelhante, visivelmente diferente em um dos temas.
• Um rótulo codificado ao lado de quatro outros locais de chamada que liam o mesmo rótulo de um catálogo compartilhado.
• Um menu que crashou a página ao abrir, porque um subcomponente exigia um pai que não tinha. Um clique manual perdeu duas vezes, porque ninguém abriu o menu.
• Um item de especificação silenciosamente ignorado, e outro descartado por uma boa razão, mas deixado sem documentação. Qualquer desvio do design precisa de uma nota explicando porquê.
• Um diálogo contradizendo a si mesmo, encontrado ao olhar a captura de tela: um aviso dizia "todos os assentos estão em uso" enquanto o rodapé ao lado ainda oferecia "2 assentos restantes".