Ixe1/ui-from-image

Missão

Trate a(s) imagem(ns) de referência fornecida(s) como a fonte de verdade visual.

Precisão supera velocidade. Não pare no "quase lá". A tarefa não está concluída quando a página meramente funciona; está concluída quando o resultado renderizado é uma correspondência visual próxima e não há mais discrepâncias óbvias.

Tenda a mais passes de verificação em vez de menos. Se houver uma chance realista de que o texto esteja errado, um controle esteja apertado, o espaçamento esteja frágil ou um bug de layout esteja escondido por uma viewport, continue iterando.

Não descreva o resultado como "bom o suficiente", "pronto para enviar" ou equivalente, a menos que todas as etapas obrigatórias de verificação e relatório nesta habilidade estejam completas e nenhuma discrepância visível conhecida permaneça além de uma incerteza menor claramente declarada.

Saída padrão

A menos que o repositório já determine outra estrutura, use:

• index.html
• styles.css
• script.js

Se estiver adaptando um frontend/framework existente, siga a estrutura de arquivos do repositório, mantendo a marcação, o estilo e o comportamento tão limpos e separados quanto o framework permitir.

Modo de operação

• Para trabalho independente, use HTML/CSS/JS simples, a menos que o ambiente já inclua um sistema de estilo que o usuário queira manter.
• Reutilize a configuração existente de Tailwind/DaisyUI do repositório, quando presente.
• Se o repositório já tiver um sistema de estilo estabelecido diferente, não introduza Tailwind/DaisyUI como um segundo sistema concorrente, a menos que o usuário peça explicitamente.
• Se Tailwind/DaisyUI já estiverem disponíveis ou forem explicitamente solicitados, trate-os como ferramentas de implementação, não como autoridade de design. Substitua os padrões sempre que a captura de tela diferir.
• Primeiro, alcance fidelidade nas dimensões exatas de referência da captura de tela primária.
• Para trabalho de página web desktop, não trate um mockup estreito ou uma captura de tela de prova de conceito como a largura final real da página desktop. Após a passagem de tamanho de referência, prefira adaptar o layout para uma viewport desktop real com cerca de 1900px de largura, permitindo aproximadamente 1900px em vez de 1920px para considerar uma barra de rolagem e o chrome normal do navegador.
• Somente após a versão do tamanho de referência estar visualmente próxima, você deve derivar o comportamento para tablet/mobile.
• Quando o usuário fornecer uma captura de tela nova ou revisada, a captura de tela mais recente se torna a fonte da verdade.

Regras de alta fidelidade

• Combine layout, espaçamento, tipografia, altura da linha, espaçamento entre letras, cores, bordas, opacidade da borda, sombras, gradientes, raio da borda, corte/proporção da imagem e hierarquia visual o mais próximo possível.
• Use valores explícitos para larguras, alturas, larguras máximas, preenchimento, margem, gap, raio da borda, tamanho da fonte, altura da linha, rastreamento e sombra quando os padrões não forem próximos o suficiente.
• Trate a fidelidade do texto tanto como um problema de layout quanto de conteúdo. Se o texto estiver cortado, apertado, truncado, quebrado incorretamente ou empurrar controles próximos para fora do alinhamento, a página não está pronta.
• Trate cada detalhe visível como obrigatório, incluindo microdetalhes:
  • logotipos pequenos e ícones de botões
  • ícones de pesquisa
  • caret de dropdown
  • chevrons de paginação
  • sublinhados / brilhos de navegação ativa
  • pontos de status
  • cores de marcadores
  • ícones de cartão
  • ícones de estrela/favorito
  • linhas divisórias
  • diferenças sutis de raio de canto
  • alterações de opacidade de texto
• Perder um pequeno ícone ou logotipo dentro de um controle é uma falha de fidelidade, não uma omissão menor.
• Não redesenhe, simplifique, embeleze ou "melhore" a interface do usuário, a menos que seja necessário para responsividade ou porque a referência é genuinamente ambígua.
• Não confie silenciosamente na tipografia, estilos de botão, estilos de entrada ou escala de espaçamento do DaisyUI se eles não corresponderem à referência.

Modo de adaptação de frontend existente

Ao trabalhar dentro de um frontend ou sistema de design existente:

• Inspecione a base de código atual antes de criar novas estruturas.
• Reutilize shells de layout existentes, componentes compartilhados, padrões de utilitários, tokens de tipografia, escalas de espaçamento, breakpoints, convenções de ícones e variáveis de tema sempre que puderem expressar fielmente a referência.
• Prefira adaptar uma página ou seção existente próxima a criar uma implementação paralela do zero.
• Não introduza componentes duplicados, tokens de design conflitantes ou um segundo sistema de estilo, a menos que o usuário peça explicitamente.
• Se a captura de tela conflitar com o sistema de design estabelecido, preserve a composição em nível de página da captura de tela, mantendo-se o mais consistente possível com os tokens/componentes atuais, a menos que o usuário diga explicitamente que a captura de tela deve substituir a linguagem de design atual.

Recebimento de referência e tratamento de breakpoint

• Registre as dimensões exatas de cada imagem de referência antes de codificar.
• Para a passagem de fidelidade primária, renderize a página no tamanho de viewport de referência exato em pixels CSS, sempre que possível.
• Se a imagem de referência desktop for substancialmente mais estreita do que uma viewport desktop moderna, trate essa largura como uma referência de composição/estilo, em vez da largura final real da página desktop. Preserve a estrutura, hierarquia, intenção de espaçamento e linguagem visual da captura de tela, depois expanda e valide a implementação desktop real em cerca de 1900px de largura de viewport.
• Se várias imagens de referência forem fornecidas para desktop/tablet/mobile, trate cada uma como autoritativa para seu breakpoint.
• Se houver apenas uma referência desktop, deduza layouts para tablet/mobile preservando hierarquia, ordenação e equilíbrio visual, sem inventar novas seções ou interações.
• Se o texto for legível, reproduza-o exatamente, incluindo pontuação e pequenos rótulos auxiliares.
• Se o texto não estiver claro, use a aproximação razoável mais próxima e relate a incerteza.
• Se a captura de tela mostrar uma região cortada de uma página em vez de uma página completa, combine a região visível primeiro.

Honestidade de viewport e segurança de dimensionamento

• Trate o zoom do navegador, o dimensionamento DPI do SO e a proporção de pixels do dispositivo como fatores ambientais que a implementação deve tolerar, não como desculpas para distorcer o layout.
• Quando Playwright ou automação de navegador semelhante estiver disponível, trate as capturas de tela controladas por automação feitas em um tamanho de viewport explícito como a referência de fidelidade primária para comparação.
• Não trate uma janela de navegador com cabeçalho como fonte da verdade para fidelidade de pixel quando o dimensionamento DPI do SO, o zoom do navegador, o chrome da janela ou o comportamento do compositor da área de trabalho podem afetar o que o humano vê na tela.
• No Windows em particular, assuma que o dimensionamento da área de trabalho não padrão ou o zoom do navegador podem tornar um navegador com cabeçalho visualmente enganoso, mesmo quando o layout da página subjacente está correto em pixels CSS.
• Se o Playwright relatar que abriu um navegador/canal chrome ou msedge, ainda é uma verificação orientada pelo Playwright. Não descreva isso como "mudar do Playwright" a menos que a automação do navegador tenha sido realmente abandonada.
• Não use CSS zoom, transform: scale(...) no nível raiz, dimensionamento de wrapper sintético ou hacks de viewport semelhantes para fazer a captura de tela de implementação parecer mais próxima da referência.
• Não "corrija" largura, superlotação ou incompatibilidades de posição de dobra encolhendo a página inteira ou inflando a tela.
• Resolva incompatibilidades de captura de tela com mudanças reais de layout:
  • larguras corretas do contêiner
  • dimensionamento correto de grid e flex
  • gaps e paddings corretos
  • tamanhos de fonte e alturas de linha corretos
  • alturas de controle e larguras intrínsecas corretas
  • breakpoints responsivos corretos
• Se aparecer uma incompatibilidade específica do navegador, primeiro suspeite de suposições de layout inválidas, overflow ou hacks de dimensionamento na implementação antes de culpar o ambiente do usuário.
• Se houver uma incompatibilidade entre uma janela de navegador com cabeçalho e uma captura de tela do Playwright feita na viewport calibrada, confie primeiro na captura de tela para trabalho de fidelidade e investigue a implementação com passes de captura de tela adicionais antes de atribuir a diferença à máquina do usuário.
• Ao relatar o status de fidelidade, distinga entre:
  • diferenças esperadas de refluxo causadas por preferências de zoom do usuário/navegador, e
  • bugs genuínos de layout, como overflow horizontal, cálculos de largura incorretos, quebra incorreta ou comportamento frágil de breakpoint.

Lista de verificação pré-voo

Antes de implementar, inspecione e faça um inventário explícito de:

1. Seções da página e sua ordem
2. Estrutura de grid / coluna e proporções de largura aproximadas
3. Principais contêineres e limites de cartão
4. Todos os blocos de texto e rótulos
5. Todos os controles visíveis e estados interativos
6. Todos os ícones, logotipos, emblemas, chips, pontos de status, separadores e marcas decorativas
7. Todos os ativos de imagem e gráficos de fundo
8. Agrupamentos de tipografia (título hero, corpo do texto, pílulas, botões, cabeçalhos de tabela, linhas de tabela, cartões laterais, avisos, etc.)
9. Cores primárias, secundárias, silenciadas, sucesso, aviso, perigo e destaque
10. Intenção responsiva provável
11. Quaisquer regiões onde o comprimento da cópia, a contagem de chips ou a densidade de controle tornem provável a superlotação
12. Quaisquer linhas ou painéis que devem permanecer em uma linha no breakpoint de referência

Não comece a codificar até que você tenha um mapa mental funcional de cada elemento visualmente significativo.

Auditoria de tipografia

Tipografia é um alvo de fidelidade de primeira classe.

• Inspecione as fontes de fonte existentes no repositório primeiro:
  • CSS global
  • configuração Tailwind
  • configuração de tema DaisyUI
  • tokens de design
  • componentes de página existentes
  • arquivos de fonte locais
• Se uma fonte de projeto existente corresponder à referência, use-a.
• Se a referência parecer usar uma fonte personalizada ou não padrão e a fonte exata não estiver disponível, escolha a opção disponível mais próxima e relate essa limitação explicitamente.
• Não use a tipografia genérica do DaisyUI/corpo sem verificar.
• Defina a tipografia explicitamente para cada grupo visual:
  • texto do logotipo
  • links de navegação
  • pílulas / emblemas
  • título hero
  • parágrafo principal
  • rótulos de estatísticas
  • valores de estatísticas
  • texto auxiliar
  • chips de filtro
  • rótulos de formulário
  • cabeçalhos de tabela
  • linhas de tabela
  • cabeçalhos de barra lateral
  • notificações / timestamps
  • botões primários e secundários
• Verifique não apenas a família da fonte, mas também:
  • tamanho
  • peso
  • altura da linha
  • espaçamento entre letras
  • caixa
  • cor / opacidade
• Valide a quebra de texto e as quebras de linha na largura de referência. Se um título ou parágrafo quebrar de forma diferente da captura de tela, corrija-o.
• Valide a integridade do texto para controles e UI densa:
  • sem truncamento não intencional
  • sem subidas/descidas cortadas
  • sem compressão vertical devido a altura de linha ou altura de controle incorretas
  • sem colisões entre rótulo/texto auxiliar
  • sem texto de espaço reservado transbordando seu campo

Auditoria de iconografia e integridade

Antes de declarar a página concluída, verifique se cada ícone ou marca visualmente significativa da referência está representado no DOM.

Isso inclui:

• marcas de logotipo
• ícones de marca dentro de botões
• ícones de pesquisa
• caret de dropdown
• ícones de cartão de estatísticas
• indicadores de status
• marcadores de mapa / notificação
• ícones de favorito de tabela
• setas de paginação
• ícones de fechar / redefinir / filtrar
• quaisquer símbolos embutidos sutis

Regras:

• Ícones de UI pequenos contam como ativos e não devem ser omitidos.
• Prefira ícones existentes do repositório ou SVGs embutidos simples para ícones de UI pequenos.
• Não adicione uma nova biblioteca de ícones, a menos que o repositório já use uma ou o usuário peça explicitamente.
• Para marcas comuns usadas em controles de UI (por exemplo, Discord), use um SVG embutido limpo ou componente de ícone existente, a menos que o repositório já tenha um ativo apropriado.

Regras de ajuste de layout e superlotação

Para o breakpoint de referência:

• Recrie a composição da captura de tela antes de fazer adaptações responsivas.
• Não resolva a superlotação redesignando, excluindo, encolhendo ou refluindo grupos importantes prematuramente.
• Não resolva a superlotação dimensionando toda a página com CSS ou confiando em suposições de zoom do navegador.
• Primeiro, esgote as opções de preservação de fidelidade:
  • corresponder ao tamanho da viewport de referência
  • corrigir larguras de contêiner e larguras de coluna lateral
  • apertar ou afrouxar gaps para os valores medidos
  • usar o tamanho de fonte e altura de linha corretos
  • usar larguras de controle e larguras mínimas corretas
  • usar o dimensionamento de faixa correto para cada coluna de grade em vez de distribuir tudo uniformemente
  • dar aos controles densos a largura que eles realmente precisam antes de encolher elementos vizinhos
  • usar quebra apenas onde a captura de tela já implica quebra
  • inspecionar se a referência realmente usa várias linhas
• Mova os controles para linhas adicionais no breakpoint de referência apenas se:
  • a captura de tela mostrar explicitamente várias linhas, ou
  • o usuário fornecer uma captura de tela revisada mostrando a estrutura atualizada.
• Se os controles ainda parecerem apertados após uma passagem, assuma que as proporções ainda estão erradas e continue iterando. Não normalize a superlotação como "bom o suficiente".
• Para breakpoints mais estreitos, refluir limpa e suavemente, preservando a hierarquia e o equilíbrio visual.

Auditoria de cor, superfície e efeitos

• Combine superfícies primárias, superfícies secundárias, superfícies silenciadas, bordas, brilhos, sombras, gradientes e opacidades de texto o mais próximo possível.
• Quando possível, amostre ou estime cores da referência em vez de inventar novos valores.
• Preste atenção a:
  • gradientes de fundo
  • alpha de borda sutil
  • transparência de painel
  • ênfase de hover/ativo que é visível na referência
  • diferenças de contraste entre conteúdo principal e cartões de barra lateral
  • consistência da cor de destaque em emblemas, indicadores ao vivo, botões e destaques

Fluxo de trabalho de manipulação de ativos

Primeiro, faça um inventário de cada ativo visível exigido pela página:

• logotipos
• imagens hero
• miniaturas / cartões
• mapas
• avatares
• ícones
• ilustrações
• gráficos de fundo
• quaisquer outros elementos visuais não textuais

Para cada ativo, escolha exatamente um caminho.

1) Usuário forneceu o ativo

• Inspecione visualmente antes de usar.
• Use-o onde for apropriado.
• Corte, redimensione, preencha, apare ou mascare conforme necessário para corresponder à composição de referência.
• Preserve a proporção; nunca distorça.
• Use object-fit: cover ou contain conforme apropriado.
• Se o ativo for de baixa resolução ou de outra forma imperfeito, chegue o mais próximo possível e observe a limitação.

2) Ativo está faltando e o usuário não pediu para gerá-lo

• Use um espaço reservado claramente rotulado com as dimensões aproximadas corretas, proporção, raio de borda, posicionamento e peso visual.
• Se você mesmo criar ou sintetizar um ativo temporário substituto, em vez disso...