UAT de Design (Design UAT)
Revise a implementação visual de um site em relação às suas referências de design. Padrão: relatório HTML em inglês, focado em problemas; respeite um idioma ou formato de relatório solicitado. O skill é reutilizável entre projetos. URLs de projeto, mapeamentos de frames, desvios aceitos, credenciais e evidências de execução não pertencem a esta pasta de skill.
Comece com o escopo do usuário
Use os links do site e do Figma fornecidos como escopo inicial. Reutilize um perfil de projeto adequado, se presente; caso contrário, inicie a descoberta sem exigir uma lista de rotas pré-preparada ou configuração. Quando uma Página do Figma representa uma entrega de versão, faça um inventário de toda a Página e descubra o caminho de teste de cada módulo. A URL do site fornecida é um ponto de entrada, não uma restrição de rota. Respeite um escopo explícito de Página inteira; registre exclusões e estados bloqueados em vez de substituir silenciosamente por uma amostra. Para um escopo grande não especificado, declare um limite de revisão útil. Amostrar uma tela não aceita um módulo inteiro.
Mantenha os dados do projeto no espaço de trabalho gravável do projeto atual, respeitando as instruções do repositório. Um padrão útil é design-uat/<projeto>/project.json e runs/<run-id>/, mas preserve um local estabelecido. Consulte project-data.md ao criar mapeamentos, construir entrada de relatório ou registrar uma nova execução.
Descubra as ferramentas realmente disponíveis. Prefira um conector Figma para estrutura e medidas de design, e controle de navegador para UI ao vivo. Use as instruções de ferramenta relevantes e skills de pré-requisito quando necessário; este skill não fornece essas ferramentas. Reutilize um login autorizado existente, se possível. Se o acesso estiver bloqueado, continue o trabalho independente útil e relate precisamente quais estados não puderam ser revisados.
Descubra o mapeamento de design para página
Inspecione a hierarquia de design e a navegação ao vivo antes de comparar imagens. Uma tela pode conter contêineres de módulo, frames de tela, exemplos de estado local, notas, anotações e propostas alternativas. Identifique o alvo visual dentro dessa estrutura, em vez de exportar todo o quadro de documentação como uma tela.
Leia as notas associadas e exemplos de estado local. Eles podem especificar comportamento responsivo, dimensões de entrada, truncamento ou detalhes de componente que o frame principal não mostra. Use o conteúdo visível/efetivo do nó; texto de erro/ajuda de componente oculto não é um requisito ativo apenas por existir na árvore.
Distinga uma especificação de página real de uma ilustração de interações gerais. Um exemplo genérico de gaveta pode revelar uma discrepância em um módulo existente, mas não estabelece os campos obrigatórios de cada categoria. Retenha uma descoberta útil entre módulos com sua rota real, contexto de navegação e limitação de linha de base; rotule o status legado suspeito como não confirmado, a menos que seu histórico seja conhecido.
Corresponda usando a evidência combinada de contexto do módulo, rota, título da página visível, rótulos de campo, estrutura da UI e aparência renderizada. Registre IDs de frame, página/estado, região de comparação, confiança e status de mapeamento nos dados do projeto. Uma URL pode ter muitos estados visuais. Não confunda uma lista, uma gaveta aberta, um campo focado e um estado vazio.
Proceda com correspondências bem fundamentadas marcadas como inferidas quando não confirmadas por humanos. Agrupe escolhas genuinamente ambíguas para o usuário enquanto continua com casos desbloqueados. Registre designs alternativos/de backup como fora do escopo selecionado com um motivo; o nome por si só não estabelece a versão aceita. Verifique os mapeamentos salvos anteriormente em relação ao design atual e à página ao vivo antes de reutilizar.
Para arquivos Figma grandes, mantenha metadados brutos localmente e retorne resumos superficiais e compactos para o contexto. Restrinja por ancestrais conhecidos antes de extrair subárvores detalhadas ou screenshots. Evite carregar o arquivo inteiro repetidamente.
Capture evidências comparáveis
Leia evidence-workflow.md antes da primeira captura ou ao diagnosticar um problema de comparação. Ele cobre estouro de prancheta, correspondência de estado, exclusão de anotação, conteúdo dinâmico, recortes locais e aceitação de screenshot.
Exponha os estados visuais necessários através de navegação, foco e alterações reversíveis de entrada. Não envie alterações de negócio apenas para obter um screenshot sem autorização para essas alterações. Se um estado precisar de dados indisponíveis ou uma ação de gravação, registre essa limitação em vez de fabricá-la.
Capture a região exata do design e o estado do navegador em viewport, escala e tema compatíveis. Verifique se as fontes/conteúdo foram carregados e o alvo está estável. Rejeite capturas de carregamento transitório, a menos que o carregamento seja o próprio estado revisado. Inspecione os screenshots salvos antes de usá-los em um relatório. Preserve as capturas originais juntamente com quaisquer recortes, sobreposições e anotações.
Fundamente as diferenças em ambas as imagens juntas e, onde for útil, na geometria do Figma e nos limites dos elementos do navegador. Atribua os valores medidos à sua fonte. Use scripts/compare_regions.py para recortes emparelhados opcionais em escala real e marcas quando o Pillow estiver disponível. O renderizador de relatório requer apenas a biblioteca padrão do Python.
Inspecione relacionamentos em uma linha de controle, bem como dimensões individuais: espaços adjacentes, alinhamento, espaço de ação restante e alterações quando os controles de filtro ativo aparecem. Agrupe uma correção de layout compartilhada e suas consequências visuais sob um problema estável, quando suportado por evidências ou feedback explícito do revisor. Distinga esse agrupamento de um diagnóstico de causa raiz no nível do código.
Distinga contexto de defeitos: dados de amostra, identidade da conta, navegação expandida, anúncios globais e versões posteriores de componentes podem alterar um screenshot. Registre-os; não descarte silenciosamente seus efeitos de layout. Valores de texto podem ser excluídos da correspondência de cópia, enquanto seu wrapping, estouro e alinhamento permanecem revisáveis. Nunca estique screenshots para esconder diferenças ou invente uma pontuação de similaridade de página inteira.
Faça descobertas acionáveis
Classifique cada descoberta pelo que sua evidência suporta:
visual-defect(defeito visual): uma falha visual reproduzível, como corte, sobreposição ou uma violação de implementação confirmada. Declare as condições e a fonte da expectativa.baseline-mismatch(incompatibilidade de linha de base): uma diferença demonstrada da referência fornecida cujo design/versão atualmente aceito pode precisar de confirmação.design-clarification(esclarecimento de design): uma condição observada com orientação de design insuficiente ou conflitante para decidir a aceitação.
Mantenha a confiança da observação, a prioridade sugerida e o status de acompanhamento separados. Não chame uma diferença de screenshot de alta confiança de um defeito aceito apenas porque a diferença é óbvia. Use o esquema de prioridade do projeto; rotule sugestões e deixe a prioridade não definida onde a decisão não foi resolvida. Não invente proprietários, versões alvo, desvios aprovados, conclusão de implementação ou novos testes bem-sucedidos.
Cada descoberta precisa de um ID estável, página/estado, título conciso, resultado real, resultado esperado ou incerteza explícita, base de evidência, ação recomendada e etapas de reprodução. Anexe evidências de comparação direcionadas e a captura completa do estado atual. Inclua referências Figma relevantes. Descobertas sem evidência visual são limitações ou perguntas, não defeitos visuais confirmados.
Registre verificações observadas e estados bloqueados/não revisados separadamente. Mantenha os mesmos IDs de problema em uma nova execução. Feche ou marque uma descoberta como resolvida apenas a partir de novas evidências correspondentes; retenha a observação anterior e explique os critérios de aceitação alterados.
Incorpore a revisão de design
Padrão: rascunho de revisão, depois incorpore as decisões do designer antes de produzir uma entrega para o desenvolvedor. Leia review-workflow.md ao receber feedback, revisar uma linha de base de design ou preparar o relatório formal. Revisão e aprovação explícitas já dadas na conversa são suficientes; não peça a mesma confirmação novamente.
Registre decisões de reter, excluir, aceitar, mesclar, adiar e atualizar design nos dados do projeto com sua fonte e escopo. Uma correção de referência de design não é uma correção de implementação. O feedback do revisor sobre uma mudança de design não autoriza, por si só, a edição do Figma. Mantenha o rascunho e o histórico de decisões; a entrega para o desenvolvedor contém apenas itens de ação retidos, incluindo qualquer esclarecimento retido explicitamente ou acompanhamento de módulo existente. Não transforme campos de prioridade, propriedade, versão ou novo teste não atribuídos em valores confirmados.
Entregue o relatório
Leia report-format.md ao escrever o relatório. Preserve a ordem de leitura comprovada: contexto de escopo → registro conciso de problemas → evidência visual real/esperada do problema selecionado → notas de cobertura e revisão. Torne a evidência visual o conteúdo principal do relatório, não um apêndice separado. Evite repetir screenshots grandes para cada problema e para cada verificação bem-sucedida.
Escreva os dados de execução estruturados descritos em project-data.md, depois renderize:
python3 <diretório-do-skill>/scripts/render_report.py <diretório-da-execucao>/report.json
Isso produz report.html auto-contido, issue-register.csv e um acceptance-checklist.csv quando os critérios são fornecidos. Em uma entrega para o desenvolvedor, cada item retido precisa de uma URL de teste direta, navegação/contexto, ação do desenvolvedor e critérios de aceitação observáveis. O renderizador suporta esses campos diretamente; não modifique o HTML gerado para adicioná-los. O renderizador precisa de Python 3.9+ e nenhum pacote de terceiros. Ele valida entrada/evidência, mas não infere decisões de revisão, acessa sistemas externos ou envia o relatório para desenvolvedores.
Inspecione o relatório renderizado, suas funcionalidades de alternância/filtragem de problemas, expansão de imagem e quaisquer controles de comparação. Abra o resultado usando as ferramentas de pré-visualização local disponíveis, seguindo suas regras de navegador. Use uma pré-visualização local não conflitante, se necessário, vinculada ao loopback; não publique ou escreva em sistemas externos, a menos que solicitado. Restaure as sobreposições temporárias de viewport do navegador e entradas de teste quando prático, e relate qualquer estado que permaneça alterado.
Entregue o link do relatório, cobertura concisa e resultados principais no idioma da conversa. Explique limitações materiais. Não exija aprovação apenas para produzir o relatório já solicitado. Uma solicitação para discutir a abordagem não é uma solicitação para executar uma execução de UAT.