kennedys0/taste-engine — Roteador de Estilo

Taste Engine — Roteador de Estilo

Um processo universal, muitos gostos independentes — com anti-slop, SEO público condicional e movimento alinhado ao estilo opcional. O Taste Engine controla quando perguntar, qual pacote de estilo selecionado carregar e como aplicá-lo. O motor em si não tem uma estética própria. Os pacotes de estilo em styles/*.md contêm as instruções reais de design.

Fidelidade do material (estilos selecionados) — contrato no nível da captura de tela

As estéticas visuais selecionadas devem ser reconhecíveis na interface renderizada, não apenas declaradas em cabeçalhos ou nomes de variáveis CSS. Quando glassmorphism for selecionado, carregue styles/glassmorphism.md e aplique seu portão de fidelidade material de Vidro obrigatório: painéis reais visivelmente foscos/tintos filtrando luz de fundo diferenciada, reflexos/ bordas legíveis e fallback acessível. Um hero azul marinho plano com um CTA azul não é Glassmorfismo. Use tests/glassmorphism-visual.md para verificações de aceitação e examples/glassmorphism/frosted-surfaces.css como receita inicial. Não aplique esta verificação específica de vidro a outros estilos; cada estética mantém seus próprios requisitos.

Exceção de gradiente específica do Glassmorfismo

Quando o Glassmorfismo for selecionado, gradientes CSS propositais de fundo, campos de luz ambiente e formas de cor suave controladas são explicitamente permitidos porque tornam o fosqueamento translúcido e a profundidade visíveis. Não os remova para satisfazer avisos gerais de gradiente anti-slop. Leia styles/glassmorphism.md ("Exceção explícita de gradiente de fundo") e valide que a primeira viewport mostra um painel real filtrando seu fundo diferenciado. Esta isenção se aplica apenas ao material selecionado e nunca substitui usabilidade, veracidade, acessibilidade ou restrições do usuário.

Invocação automática: o contrato de zero comando

• Esta é uma habilidade acionada por tarefa, não um fluxo de trabalho apenas de comando de barra. Agentes instalados que suportam Habilidades de Agente Autônomas devem descobrir os metadados acima em solicitações de portfólio, site, aplicativo, dashboard, landing page e redesign de UI — mesmo quando o usuário nunca diz "taste-engine".
• Uma vez invocado, aplique Contrato de Invocação Automática antes de qualquer código de UI. A plataforma real decide se a habilidade é invocada; este arquivo não pode criar um hook de nível de SO ou garantir conformidade em todos os hosts.
• Seleção de estilo implícita: "crie um site de portfólio" → faça UMA pergunta concisa de estilo, depois encerre a vez. Nunca pergunte ao usuário sobre detalhes não relacionados na mesma vez.
• Seleção de estilo explícita: "crie um site de portfólio no estilo esqueumorfismo" → normalize o erro de digitação para skeuomorphism, leia styles/skeuomorphism.md e construa. Não execute o menu de perguntas.
• Projeto estabelecido: uma configuração de projeto aprovada ou marca/estilo documentado prevalece sobre padrões genéricos para trabalho incremental; não interrompa com um menu.
• Nenhum trabalho de frontend: implementação de API, depuração de lógica de negócios, migração de banco de dados, infraestrutura, tarefas apenas de escrita → não inicie o seletor de estilo.

Acompanhante de engenharia — condicional e ciente do framework

Uma vez que a pergunta de estilo visual é resolvida (ou pulada para sistemas existentes/trabalho não visual), aplique Roteador de Engenharia. Cada UI web recebe o portão universal Qualidade de Interface Web; React/Next ganha Desempenho React e opcionalmente Composição React apenas quando a pilha e a tarefa os justificam. Trabalho React Native/Expo ganha Móvel Nativo, não SEO web. A navegação por movimento pode usar Transições de View após verificações de compatibilidade, ou Anime.js opcional quando realmente útil. Tarefas de escrita de documentação ganham Escrita de Documentação sem um seletor de estilo visual.

Estas são integrações originais locais, não plugins Vercel importados. Elas resumem práticas de engenharia aprendidas de pesquisas upstream. Nunca assuma habilidades upstream instaladas, nunca exija React, nunca implante sem intenção explícita de implantação, e não deixe que a orientação técnica sobrescreva a estética do usuário. O pré-voo principal, hero de tela cheia, SEO, anti-slop e movimento ciente de estilo permanecem inalterados. Veja testes de roteamento de engenharia.

Hero de tela cheia — obrigatório quando relevante

Após a seleção de estilo, para qualquer novo portfólio público, landing page ou homepage com um hero, carregue Contrato de Hero de Tela Cheia. Padrão para uma composição de cabeçalho + hero de uma tela visível: use min-height: 100svh seguro para dispositivos móveis (com fallback 100vh) e subtraia a altura real do cabeçalho em fluxo normal, ou use um hero de altura total quando o cabeçalho o sobrepõe. Não aplique 100vh cegamente: alturas fixas podem cortar texto e viewports móveis alteradas por barra de ferramentas. Mantenha o conteúdo e o CTA utilizáveis em telas estreitas/curtas; permita crescimento natural e rolagem com zoom/texto grande. Siga as orientações do estilo selecionado em ## Composição do Hero (primeira viewport completa) e as verificações anti-slop compartilhadas. Não invente imagens, emblemas, estatísticas falsas ou movimento em loop apenas para preencher a tela.

Esta regra não força um hero de marketing em dashboards privados, formulários, espaços de trabalho de aplicativos ou edições incrementais que não criam/redesenham o hero. Uma escolha explícita do usuário por um hero compacto ou sem hero prevalece. Nenhuma pergunta extra de seleção de estilo é necessária quando o estilo já está estabelecido.

Mecanismo de Movimento Anime.js v4 — opcional e ciente de estilo

Para solicitações explícitas de micro-interação de UI, ou ao construir um estilo selecionado que se beneficia genuinamente de movimento adicional, carregue Adaptador de Mecanismo de Movimento e as orientações de ## Movimento do estilo escolhido. O movimento nunca se torna um novo seletor estético, e nunca requer uma segunda entrevista. Uma solicitação como "Adicione micro-interação neste dashboard" preserva o estilo do projeto existente e funciona sem uma pergunta de estilo. Se o projeto não tiver linguagem de design selecionada e o usuário estiver construindo uma nova UI, o pré-voo original de uma pergunta permanece obrigatório.

Nenhuma instalação automática de dependências. Inspecione a pilha existente primeiro. Prefira CSS/capacidades nativas do navegador para transições simples; considere Anime.js v4 apenas quando simplificar significativamente o movimento coordenado ou for explicitamente solicitado. Para React/Next, use createScope() + limpeza de ciclo de vida; para usuários que preferem movimento reduzido, desabilite efeitos não essenciais mantendo as interações funcionais. Não force bounce, loops ou stagger gratuito. O mapeamento de estilo está em styles/motion-profiles.json; receita React em examples/react/anime-v4-press.jsx. Aplicativos não web/nativos devem usar suas APIs de movimento de plataforma.

SEO entre estilos: automático e condicional

SEO não é uma escolha de estilo. Para um site público novo ou substancialmente redesenhado (portfólio, landing page, blog, site empresarial público, documentação pública ou páginas de produto públicas), carregue Integração SEO e, quando necessário, receitas de implementação SEO após a seleção de estilo visual. Aplique SEO técnico + conteúdo anti-slop a cada estilo escolhido, sem perguntar "você quer SEO?" como uma segunda pergunta. SEO nunca altera a estética material selecionada.

• Estilo explícito: "Crie um portfólio Esqueumorfismo" → leia styles/skeuomorphism.md + references/seo.md, sem pergunta de estilo, depois implemente.
• Estilo ausente: "Crie um site de portfólio" → faça exatamente uma pergunta de estilo e pare. Após a resposta, carregue estilo + SEO e implemente. Não ignore o pré-voo apenas para escrever metadados.
• Apenas SEO: "Audite o SEO do meu site" / "corrija URLs canônicas e o sitemap" → leia o módulo de SEO imediatamente, nenhuma entrevista de estilo visual e nenhum redesign não solicitado.
• Aplicativo privado/interno: preserve a confidencialidade e indexabilidade existente; não gere sitemap público ou revele rotas privadas. Tarefas nativas móveis/somente backend estão fora do escopo normal de SEO web.
• Domínio desconhecido: não fabrique URLs reais, autoria, dados estruturados, avaliações ou conteúdo de página; implemente semântica/título com segurança e relate o que permanece pendente.

SEO e estilo compartilham portões FLOOR / REFLEX / FINISH; privacidade, conteúdo verdadeiro, acessibilidade e comportamento funcional superam preferências estéticas e de busca. Veja cenários de aceitação de SEO. A habilidade opcional independente taste-seo é para instalações apenas de SEO; usuários do roteador não precisam instalá-la separadamente.

Requisito rígido: pré-voo antes de nova implementação visual

Para tarefas que introduzem ou redesenham substancialmente a UI visual, não escreva código de UI, gere mockups de interface ou altere tokens de design até que a direção visual seja resolvida.

1. Examine a solicitação atual do usuário, a marca/sistema de design do produto existente e uma configuração de estilo de projeto explicitamente aprovada.
2. Se um estilo já estiver explicitamente selecionado (por exemplo, "dashboard brutalista"), não pergunte novamente. Confirme em uma linha curta se útil e carregue aquele pacote de estilo.
3. Se o projeto existente tiver um estilo claramente estabelecido e o usuário solicitar alterações incrementais, preserve-o; não interrompa com uma nova escolha. Uma solicitação de redesign pode substituir o estilo estabelecido.
4. Caso contrário, faça exatamente uma pergunta concisa de seleção de estilo e pare. Ofereça 6 opções contrastantes e "Mais estilos / Personalizado / Enviar referência". Não selecione um estilo silenciosamente, comece a codificar enquanto aguarda uma resposta ou faça uma entrevista de múltiplas perguntas.
5. Quando o usuário responder, resolva o ID do estilo via registro, leia apenas o(s) pacote(s) selecionado(s), derive tokens/decisões específicas do projeto e então execute. Um adjetivo ou referência fornecido pelo usuário pode exigir a interpretação das características do estilo em vez de forçar um preset.
6. Se um executor de ferramenta não puder pausar para entrada do usuário, relate a seleção não resolvida e não fabrique consentimento. Uma instrução explícita para usar um padrão autônomo de melhor esforço pode autorizar um estilo provisório; marque-o como provisório e reversível.

Pergunta obrigatória (exemplo em português)

Antes de começar a projetar, qual estilo visual você gostaria?

1. Claymorfismo — suave, tátil, profundidade sutil
2. Glassmorfismo — transparente, em camadas, moderno
3. Brutalismo — tipografia ousada, grade bruta, alto contraste
4. Neo-brutalismo — cores vibrantes, bordas e sombras duras
5. Minimalismo — limpo, simples, foco no conteúdo
6. Suíço / Editorial — grade de precisão, tipografia dominante Ou digite outros, personalizado, ou envie referência.

Adapte-se ao idioma do usuário. Mantenha uma única pergunta; descreva distinções sem declarar uma como "melhor". Para menus longos, primeiro apresente as seis mais uma forma de ver as opções restantes. Se o usuário quiser exemplos, mostre opções antes de selecionar. Se o usuário solicitar um seletor interativo e o agente suportar, apresente as mesmas escolhas como controles de UI.

Pacotes de estilo disponíveis

Leia styles/registry.json ao corresponder IDs, aliases, erros de ortografia comuns e descrições. Normalize pontuação, hífens e capitalização; respeite menções negadas de estilo ("não glassmorfismo") e contexto. Quando disponível, python3 scripts/style_probe.py --prompt "..." pode fornecer uma dica de estilo determinística; a interpretação semântica e o contexto do projeto ainda vencem. Não chame uma habilidade de estilo independente pelo nome: leia o arquivo local styles/<id>.md selecionado, que faz parte deste roteador instalado. Pacotes incorporados:

ID	Direção	Arquivo para carregar quando selecionado
claymorphism	Tátil esculpido	pacote de estilo
glassmorphism	Em camadas translúcidas	pacote de estilo
brutalism	Estruturado bruto	pacote de estilo
neo-brutalism	Ousado lúdico	pacote de estilo
minimalism	Clareza contida	pacote de estilo
swiss-editorial	Grade tipográfica	pacote de estilo
bento	Blocos modulares	pacote de estilo
skeuomorphism	Metáfora de controle físico	pacote de estilo
retro-terminal	Estética de console	pacote de estilo
enterprise	Fluxo de trabalho/dados primeiro	pacote de estilo

Personalizado é primeira classe: se a estética escolhida não estiver no registro, colete uma breve referência ou restrições, depois crie uma definição de estilo provisória específica do projeto usando as mesmas dimensões. Nunca rotule o estilo como um pacote não presente. Não exija acesso externo à internet para escolher.

Estados do roteador

• needs-selection: Novo trabalho visual; nenhuma direção escolhida/confirmada. Faça uma pergunta de estilo e pare.
• ready: Estilo ou marca existente explicitamente estabelecido; carregue o pacote relevante e implemente.
• refine: Pequena alteração na UI existente; preserve o estilo, modifique apenas tokens/componentes necessários.
• custom: Usuário escolhe uma mistura, fornece capturas de tela ou solicita um estilo não especificado; mapeie para as mesmas dimensões de design e confirme apenas ambiguidade consequencial.
• non-visual: Backend, testes, documentação, correções de bugs sem decisão visual; pule a seleção de design completamente.

Regras detalhadas de roteamento, misturas e conflitos: roteador de estilo. Para descoberta autônoma, aliases de estilo, limitações do host e transcrições de exemplo exatas, veja invocação automática.

Aplicando o estilo após a seleção

1. Extraia requisitos: produto, público, dispositivo, framework, marca existente, gostos/não gostos explícitos, acessibilidade, desempenho.
2. Carregue apenas o pacote selecionado (mais referências compartilhadas conforme necessário). Não misture regras aleatórias de pacotes não selecionados.
   • Estilo ≠ anatomia: derive o fluxo do produto e o conteúdo da página dos objetivos reais do usuário, enquanto o pacote selecionado determina o material visual. Antes de codificar, ...