O que Engenharia Frontend faz?
Leia anti-ai-writing antes de redigir textos, comentários ou relatórios. Leia as instruções do repositório, telas e componentes existentes, tokens de design, versões do framework/dependências, roteamento, contratos de dados e convenções de teste. Use a stack e utilitários existentes; verifique APIs desconhecidas contra a documentação oficial da versão em uso. Preserve trabalho não relacionado e comportamento estabelecido do produto.
Estabeleça a Função e o Design da Tela
Identifique o público, a tarefa do usuário, a ação principal, a hierarquia de conteúdo, os estados necessários e os critérios de aceitação. Use primeiro os designs fornecidos e os padrões existentes do produto. Para interfaces novas substanciais, esclareça requisitos ausentes importantes e use agent-planning quando um plano ajudar. Não exija uma cerimônia de design para uma alteração pequena e compreendida.
Quando uma nova direção visual for necessária, estude referências relevantes e traduza sua hierarquia, densidade, navegação e princípios de interação úteis para a linguagem do próprio produto. Não copie branding, texto, ativos ou layouts exatos proprietários. Registre decisões de design suficientes para orientar a implementação sem inventar um sistema de design completo para uma única tela.
Use tipografia, espaçamento, cores, raios e ênfase coerentes dos tokens do projeto. Priorize a ação e a informação do usuário em vez de recorrer a seções de herói genéricas, cartões uniformes, espaçamento excessivo ou gradientes decorativos. Esses padrões podem ser apropriados quando o produto os exige; não imponha proibições estéticas. Use conteúdo realista, incluindo rótulos longos e dados esparsos/densos. Remova detalhes de implementação irrelevantes do texto do produto. Mantenha todos os controles expostos funcionais ou claramente identificados como indisponíveis; nunca disfarce um placeholder como um recurso funcional.
Implemente Componentes e Estado Claros
Para contratos frontend/backend alterados, use api-design e preserve os consumidores suportados. Não infira um contrato de backend a partir de fixtures de UI.
Use writing-clean-simple-code para responsabilidades focadas e abstrações justificadas. Prefira composição e APIs de componentes estabelecidas em vez de uma matriz grande de flags não relacionadas. Divida por responsabilidade, não por contagem arbitrária de linhas. Mantenha a propriedade de dados e apresentação clara sem forçar um contêiner ou hook separado para cada componente.
Coloque o estado onde ele é pertencente: estado de interação local, estado compartilhado, estado de URL para visualizações navegáveis/compartilháveis e ferramentas de estado de servidor existentes para dados remotos. Evite estado derivado duplicado e booleanos contraditórios. Não introduza um store global apenas para evitar algumas props. Preserve a identidade estável do item, navegação pelo histórico, links profundos e contratos de renderização/hidratação do framework quando relevante.
Lide com estados de carregamento, vazio, sucesso, erro, desabilitado, pendente e permissão aplicáveis. Diferencie sem dados de resultados filtrados. Preserve dados inseridos após erros recuperáveis, explique como prosseguir e evite submissões duplicadas. Para atualizações otimistas, considere falha, alterações concorrentes, respostas obsoletas e reconciliação. Rastreie a propriedade de cancelamento antes de cancelar solicitações compartilhadas. Não use controles ocultos como autorização; a imposição do lado do servidor permanece necessária.
Torne o Layout e a Interação Inclusivos
Leia acessibilidade e verificações responsivas. Prefira HTML semântico nativo e primitivos acessíveis testados. A interação personalizada deve implementar seu contrato completo de teclado, foco e estado. Rótulos, erros e feedback de status devem ser compreensíveis sem depender de cor ou animação.
Escolha pontos de interrupção onde o conteúdo precisar deles e respeite os tokens de layout existentes. Use layouts flexíveis, limites de largura apropriados e ativos responsivos. Verifique visualizações estreitas e largas, zoom, texto longo, estados vazios e estouro. Preserve conteúdo e ações significativos em telas pequenas em vez de ocultá-los para caber em uma captura de tela.
Preserve Segurança e Desempenho
Trate conteúdo remoto e URLs como não confiáveis. Use renderização segura do framework; sanitize apenas por meio de mecanismos testados quando HTML rico for necessário. Não exponha segredos ou registros privados em bundles do cliente, telemetria ou mensagens de erro. Escopem dados em cache para identidade/tenant e limpe ou invalide-os em alterações de contexto relevantes.
Evite waterfalls de fetch desnecessários, trabalho repetido caro, dependências excessivamente grandes e mudanças de layout. Use as convenções de ativos, renderização e carregamento do framework. Otimize com base em evidências medidas e orçamentos do produto; não adicione memoização, virtualização ou divisão de código mecanicamente. Resultados de laboratório e desempenho de campo são evidências diferentes e devem ser relatados separadamente.
Verifique o Resultado Renderizado
Use test-authoring para cobertura comportamental. Execute verificações relevantes do repositório e inspecione a aplicação em um navegador disponível com dados realistas. Exercite ações e transições de estado afetadas, navegação por teclado, foco, validação, layout responsivo e alvos de navegador aplicáveis. Inspecione falhas de console e de rede relevantes para a alteração. Capturas de tela estabelecem a aparência, não a correção da interação; varreduras automatizadas de acessibilidade não estabelecem conformidade.
Compare a saída renderizada com os designs aceitos ou as telas estabelecidas do projeto. Corrija problemas descobertos de clipping, espaçamento, contraste ou interação e reexamine os estados afetados. Não execute ações destrutivas ao vivo apenas para verificar uma UI; use fixtures seguras ou um ambiente de teste autorizado. Se o acesso ao navegador não estiver disponível, declare exatamente o que permanece não verificado em vez de considerar a interface visualmente validada.
Relate alterações reais, fluxos/viewports testados e limitações materiais. Use code-review quando uma revisão independente for justificada, disponível e autorizada. Commit, push e publicação usam git-delivery autorizado.