Correção Visual
Transforme um problema visível de UI em uma mudança de código localizada, aprovada e verificada.
Evidências Suportadas
Aceite qualquer combinação útil de:
- Uma captura de tela da UI atual
- Uma captura de tela com uma região anotada ou descrita
- Uma captura de tela atual e uma alvo com seus papéis identificados
- Uma rota, viewport, nome de componente, string visível, seletor ou ID de teste
- Um sintoma em linguagem natural, como "este card está cortado" ou "estes controles não estão alinhados"
Peça apenas por evidências que impeçam a localização confiável. Uma rota mais uma string visível única podem ser suficientes sem uma captura de tela. Uma captura de tela com componentes repetidos ainda pode precisar de uma rota, rótulo ou estado.
Lide com um problema visual de cada vez. Divida sintomas não relacionados em correções separadas.
Fluxo de Trabalho
1. Estabeleça o alvo
Reafirme o resultado delimitado em termos concretos:
- O que parece errado agora
- O que o usuário espera ver
- Qual rota, componente, estado e viewport são relevantes, quando conhecidos
- Qual âncora visível identifica o alvo
Se o resultado solicitado for subjetivo ou puder afetar diferentes elementos, faça a menor pergunta que os distinga.
2. Estabeleça uma linha de base somente leitura
Antes de editar:
- Encontre as instruções do repositório e a fonte da verdade.
- Inspecione o status da árvore de trabalho e preserve as alterações existentes do usuário.
- Identifique o framework, a entrada da rota, a árvore de componentes, o sistema de estilo e os comandos disponíveis de execução ou teste.
- Reproduza a rota alvo e o viewport quando o ambiente permitir.
- Capture ou registre o estado atual antes de alterá-lo.
Não edite a saída gerada quando existir um arquivo de origem mantido. Não limpe ou sobrescreva alterações não relacionadas na árvore de trabalho.
Relate a linha de base brevemente:
Contexto
- Rota/estado: /catalog, filtros abertos
- Viewport: 390 x 844
- Fonte da verdade: src/routes/catalog.tsx + src/styles/catalog.css
- Alterações existentes do usuário: nenhuma
- Reprodução: disponível
3. Localize a fonte renderizada
Rastreie evidências do elemento renderizado de volta ao código mantido. Use a rota, nome acessível, texto visível, seletor DOM, nome do componente, ID de teste, classe, token de estilo ou geometria da captura de tela. Leia references/locating.md quando vários arquivos ou camadas de estilo estiverem envolvidos.
Identifique um local de origem principal e no máximo dois locais relacionados necessários. As evidências de arquivo e linha devem vir da árvore de trabalho atual.
Localizado
- Principal: src/components/ProductGrid.tsx:42, ProductGrid
- Relacionado: src/styles/products.css:18
- Evidência: `.grid` controla o espaçamento horizontal repetido visível entre os cards
- Confiança: alta
Se dois elementos semelhantes permanecerem plausíveis, explique a evidência distintiva e pare para esclarecimento.
4. Diagnostique a partir das evidências
Conecte o sintoma visível ao código real. Prefira uma causa suportada. Ofereça duas ou três hipóteses apenas quando as evidências permanecerem ambíguas.
Para cada hipótese, inclua:
- A propriedade, seletor, token ou componente envolvido
- O código ou evidência renderizada que a suporta
- A direção da correção pretendida
- Uma observação que a refutaria
Não invente valores CSS a partir da captura de tela. Inspecione o valor atual e o sistema de design ao redor primeiro.
5. Apresente o plano de alteração exato
Mostre o patch proposto antes de editar:
Plano de alteração
- Arquivos: src/components/ProductGrid.tsx:42
- Atual: gap: 8px
- Proposto: usar o token space-4 existente (16px)
- Escopo: ProductGrid em /catalog e /search
- Preservando: padding do card, contagem de colunas móveis, rotas não relacionadas
- Verificação: teste direcionado, lint, capturas de tela em 390 x 844 e 1280 x 800
- Risco: médio; o componente é compartilhado por duas rotas
Aguarde aprovação explícita deste plano. Escolher um diagnóstico não aprova uma alteração de código. Se o plano depois se expandir para outro arquivo, dependência, arquivo de bloqueio, artefato gerado ou rota, apresente o plano revisado e obtenha aprovação novamente.
6. Aplique o patch aprovado
Faça a menor alteração que implemente o plano. Mantenha as edições dentro dos arquivos e escopo aprovados. Em seguida, inspecione o diff imediatamente:
- Execute
git diff --checkquando o projeto usar Git. - Confirme que o diff contém apenas a alteração planejada.
- Preserve alterações pré-existentes e evite reformatação não relacionada.
- Não faça commit, push, instale dependências ou modifique serviços externos, a menos que autorizado separadamente.
7. Verifique o resultado
Leia references/verification.md antes de afirmar sucesso.
Use a evidência mais forte disponível:
- Execute testes direcionados, formatação, verificações de tipo ou uma compilação relevante para o código alterado.
- Renderize a mesma rota, estado e viewport usados para a linha de base.
- Compare visualmente antes e depois.
- Verifique um viewport próximo ou rota compartilhada quando a fonte alterada tiver escopo mais amplo.
Relate exatamente um estado de verificação:
Verificado visualmentequando existirem evidências de renderização comparáveis antes e depoisVerificado estaticamentequando as verificações de código passarem, mas a UI não puder ser renderizadaNão foi possível verificar visualmentequando o ambiente não tiver a rota, navegador, fixture ou caminho de inicializaçãoFalha na verificaçãocom o comando com falha ou regressão observada
Se a verificação falhar, retorne ao diagnóstico. Não empilhe uma segunda correção não aprovada em cima da primeira.
Relatório de conclusão
Mantenha a transferência compacta e baseada em evidências:
Corrigido
- Alvo: espaçamento do card do catálogo em largura móvel
- Fonte: src/components/ProductGrid.tsx:42
- Alteração: gap agora usa space-4
- Verificação: Verificado visualmente em 390 x 844; teste unitário e lint passaram
- Verificações mais amplas: /search em 390 x 844 e /catalog em 1280 x 800
Mencione qualquer incerteza visual restante. Nunca descreva um diff de código como prova visual.