Figma para Frontend

Figma para Página Frontend

Resultado e Escopo

Implemente o design selecionado no projeto existente e verifique o resultado em um navegador. Uma URL do Figma normalmente é suficiente para começar; infira as convenções do projeto a partir do repositório. Aceite capturas de tela ou exportações fornecidas como evidência alternativa quando o design não puder ser acessado.

As instruções do usuário têm precedência sobre estas diretrizes. Preserve as alterações existentes e mantenha as edições dentro do escopo solicitado. Identifique se a tarefa é uma nova página, uma atualização de página existente, uma seção ou um componente reutilizável antes de escolher arquivos ou rotas. Não transforme um componente ou correção local em uma nova página.

Restrições Principais

• Leia o código relevante do repositório antes de editar. Reutilize seu framework, roteador, estilos, tokens, componentes, assets e convenções de dados quando apropriado.
• Traduza a geometria do design em regras de layout. Prefira fluxo normal, flex e grid; use posicionamento absoluto apenas para sobreposição real, decoração ou overlays. Grupos do Figma são evidência, não limites obrigatórios de componentes.
• Reutilize assets idênticos e componentes mapeados adequados. Preserve imagens e ícones distintivos em vez de substituir por símbolos aproximados. Não renderize uma seção interativa inteira como uma captura de tela.
• Implemente comportamentos suportados por requisitos, protótipos ou comportamento existente do produto. Não infira posicionamento fixo, semântica de filtro, contratos de API ou destinos de navegação apenas pela aparência.
• Preserve controles semânticos, nomes acessíveis, operação por teclado e comportamento de foco adequado. Exclua elementos de chrome do dispositivo, como uma barra de status do sistema operacional, a menos que solicitado.
• Não reivindique paridade visual sem comparar o alvo implementado com o design. Relate requisitos bloqueados ou não verificados explicitamente.

Compatibilidade CSS

• Use margin para espaçamento entre itens flex, grid e itens repetidos. Não use gap, row-gap ou column-gap. Coloque o espaçamento em uma classe de item nomeada; dê ao primeiro ou último item uma classe modificadora explícita quando sua margem for diferente. Não substitua gap por seletores como > * + *, :first-child ou :last-child.
• Escreva seletores contra classes de componentes explícitas. Evite seletores universais e combinadores irmãos (+, ~) em estilos que possam compilar para WXSS. Verifique o suporte de seletores da plataforma alvo antes de usar outras pseudo-classes ou combinadores; não assuma que o suporte CSS do navegador implica suporte WXSS.
• Para máscaras e painéis fixos, use declarações explícitas top, right, bottom e left em vez de inset. Ao usar env(safe-area-inset-*), coloque um valor de fallback simples imediatamente antes da declaração que usa env(). Defina box-sizing: border-box onde larguras fixas e preenchimento devem se encaixar.
• No Taro H5, o estilo integrado taro-button-core:active pode tornar um botão pressionado cinza mesmo quando sua classe de hover está desabilitada. Se o design não tiver alteração de cor ao pressionar, substitua as cores de fundo e texto ativas para as classes de botão específicas, preservando as cores normais de cada botão. Não redefina botões globalmente ou altere a estilização desabilitada.

Evidência e Decisões

Leia design-evidence.md ao coletar ou atualizar evidências de design. Mantenha um resumo de trabalho conciso do alvo, convenções do projeto, mapeamento de assets, capacidades aplicáveis e incertezas. Notas de contexto são suficientes para tarefas pequenas; não gere um arquivo de especificação a menos que seja útil ou solicitado.

Classifique as decisões:

• Confirmado: requisitos explícitos do usuário, propriedades de design selecionadas, comportamento de protótipo ou contratos de produto existentes relevantes.
• Inferido: adaptação de layout comum, quebra de linha e limites de componentes locais consistentes com o projeto. Escolha a implementação razoável mais pequena e divulgue suposições relevantes.
• Desconhecido: contratos de envio ausentes, destinos ambíguos, quadros alvo conflitantes ou comportamento de negócios consequente. Inspecione as evidências disponíveis primeiro; faça uma pergunta focada se ainda for necessário. Continue o trabalho independente enquanto aguarda uma resposta.

Um controle visível por si só não estabelece seu comportamento de negócios. Não finja envios bem-sucedidos, invente endpoints ou substitua silenciosamente o comportamento simulado. Use fixtures apenas quando a tarefa ou a convenção de visualização existente as suportar e identifique essa limitação.

Execução

Siga dependências em vez de repetir uma sequência fixa. Para uma correção local, reutilize evidências ainda válidas e inspecione a região alterada mais o comportamento compartilhado afetado. Leituras independentes de repositório e design podem ser agrupadas.

1. Identificar Alvo e Projeto

Analise a chave do arquivo e o ID do nó. Inspecione o tipo, dimensões e contexto circundante do nó selecionado. Se o ID do nó estiver ausente, inspecione candidatos de nível superior; selecione apenas quando o alvo estiver claro.

Use buscas e leituras direcionadas para estabelecer:

• instruções aplicáveis do repositório e alterações atuais;
• gerenciador de pacotes, comandos de desenvolvimento e verificação;
• arquivos de destino prováveis e a implementação existente mais próxima;
• roteador, estilos, tokens, fontes, viewport/unidade e convenções de componentes;
• mapeamentos design-para-código e assets existentes, quando disponíveis.

Para trabalho em página ou componente existente, preserve seu ponto de entrada. Para uma nova página, siga a família de rotas e convenções de parâmetros existentes, verificando conflitos. Use o nome do quadro apenas como uma dica de nomenclatura de fallback; não imponha uma rota de detalhe genérica.

2. Adquirir Evidências de Design Suficientes

Prefira ferramentas Figma disponíveis para metadados, capturas de tela, variáveis, mapeamentos de componentes e assets. Siga quaisquer pré-requisitos de skill específicos da ferramenta antes de chamar essas ferramentas. Se o acesso falhar, tente um navegador autenticado disponível, depois capturas de tela ou exportações fornecidas. Não use pesquisa na web como substituto do design real.

Comece com a captura de tela do alvo e visão geral estrutural, depois busque detalhes para subárvores relevantes. Inspecione o conteúdo abaixo da dobra. Não recupere repetidamente o arquivo inteiro ou quadros não relacionados. Registre medições ou estados indisponíveis como incerteza, em vez de fatos exatos.

3. Mapear e Implementar

Mapeie o design em módulos significativos, escolhendo componentes existentes onde seu comportamento e aparência se encaixam. Extraia um componente quando a reutilização, comportamento independente ou complexidade justificá-lo; não divida cada wrapper ou crie um sistema de design para uma única página.

Resolva fontes e assets principais no início. Preserve a proporção de aspecto, transparência e resolução apropriada dos assets; use convenções de armazenamento do repositório e nomes de arquivo semânticos. Verifique se os assets em tempo de execução carregam de um local durável suportado pelo projeto.

Derive dimensionamento fluido, larguras máximas, quebra de linha e breakpoints a partir de variantes fornecidas e comportamento existente do projeto. Com um único tamanho de design, implemente uma adaptação conservadora e distinga-a de um layout responsivo especificado pelo designer. Teste a plataforma solicitada; não crie um redesign de desktop ou mobile não solicitado.

Para projetos Taro que compartilham estilos entre builds H5 e mini-programa, inspecione o WXSS gerado, bem como a folha de estilo fonte. Verifique o espaçamento e estados pressionados em cada runtime solicitado quando disponível.

Ative apenas ramos de comportamento relevantes:

• Navegação: use destinos estabelecidos e comportamento de roteamento.
• Formulários e coleções: use contratos de dados existentes; implemente estados de validação, carregamento, vazio, erro e sucesso necessários.
• Abas e filtros: estabeleça propriedade do estado e semântica de seleção a partir de evidências. O comportamento de rascunho/commit se aplica apenas quando suportado.
• Tabelas: preserve alinhamento e bordas mostradas; forneça overflow apropriado para a viewport alvo.
• Overlays ou UI fixa: leia overlays-and-sticky.md.
• Movimento ou mídia: reproduza comportamento confirmado e lide com carregamento e movimento reduzido quando aplicável.

4. Verificar e Iterar

Reutilize um servidor em execução adequado, ou inicie o comando de desenvolvimento documentado em uma porta disponível. Use uma superfície de automação de navegador disponível, preferindo o navegador no aplicativo quando adequado, depois um navegador externo autenticado ou as ferramentas de navegador do projeto. Inspecione a rota relevante ou a visualização de componente existente.

Leia acceptance-checklist.md para comparação visual, verificações de interação aplicáveis e critérios de conclusão. Corrija grandes diferenças estruturais antes do polimento local. Após cada alteração, verifique a região afetada; realize uma verificação final de todo o alvo.

Execute verificações de repositório relevantes, inspecione o diff final e distinga falhas pré-existentes das introduzidas. Evite adicionar dependências ou refatorações amplas apenas para realizar a verificação. Preserve sessões de servidor pré-existentes e torne o estado de qualquer servidor iniciado para esta tarefa intencional.

Recuperação e Conclusão

Se o acesso ou a verificação em tempo de execução falhar, inspecione o erro concreto e tente uma alternativa relevante disponível. Pare de repetir uma falha inalterada sem novas evidências. Continue o trabalho que pode ser concluído independentemente, depois relate o bloqueador exato, o que foi implementado e o que permanece não verificado. Ferramentas ou credenciais ausentes não são evidência de verificação bem-sucedida.

Conclua quando o alvo solicitado estiver implementado, as verificações aplicáveis passarem e nenhum defeito necessário conhecido permanecer. Pequenas diferenças de renderização podem ser documentadas; erros de layout não resolvidos, comportamento necessário ausente ou verificações de navegador bloqueadas não devem ser apresentados como conclusão completa.

Relate de forma concisa:

• alvo implementado e ponto de entrada, incluindo uma rota apenas quando aplicável;
• mudanças significativas de comportamento e componente;
• localização da pré-visualização e verificações realmente realizadas;
• suposições relevantes, diferenças não resolvidas ou bloqueadores.