n0ctx/tavern-aesthetic

Estética de Taverna — Design Imersivo de Frontend Narrativo

O que esta habilidade produz

Uma interface funcional que é lida como um artefato do mundo da história — não um painel reestilizado e nem um monte de adereços genéricos de HUD de jogo. A barra é o cartão de frontend polido: um olhar identifica o trabalho, cada superfície compartilha uma direção de arte, os detalhes são finalizados e a interação parece natural.

Polimento ≠ complexidade. Polimento significa que cada escolha visível é intencional e cada região visível atende ao mesmo padrão de qualidade.

Esta habilidade cobre o método de design visual e implementação. Não depende de SillyTavern, de nenhum plugin auxiliar, MVU ou qualquer framework. Reutilize a pilha, componentes, ativos e padrões de interação existentes do projeto. Se o usuário pedir apenas um design, não toque no código.

Referências (leia sob demanda, nunca todas de uma vez)

• references/design-knowledge.md — guia de decisão por dimensão (identidade narrativa, cor, tipo, forma, luz/material, imagem, layout, componentes, movimento, adaptação) mais tabelas de modos de falha. Consulte a seção correspondente à decisão em questão.
• references/workflow.md — processo em etapas, portões de aprovação/reprovação, método de revisão, regras de rollback, modelo de registro de design. Leia antes de qualquer tarefa média ou complexa.
• references/asset-sources.md — fontes e verificações de licença para ilustração, textura, ícone, fonte. Leia ao coletar ativos online.
• references/research.md — evidências e limitações por trás desta habilidade. Não é necessário para execução.

Níveis de tarefa

Julgue pela dificuldade do design, não pelo volume de código:

• Simples: um componente, uma correção de detalhe, uma pequena funcionalidade dentro de uma linguagem visual existente. Reutilize a linguagem; verifique com uma captura de tela após a implementação.
• Médio: uma única página/painel ou um redesign de uma tela existente. Faça uma breve definição de direção, construa a área focal primeiro, depois complete a página; 1–2 rodadas de revisão.
• Complexo: fluxo de várias telas, sistema gamificado, construção do zero, necessidade de um visual chave personalizado, ou o usuário pede qualidade de produto finalizado. Execute as seis etapas em workflow.md e mantenha um registro de design.

Regras anti-desvio (vinculantes)

Estas existem porque a execução em múltiplos turnos tende a desviar. Siga-as literalmente:

1. O registro de design é a fonte única de verdade. Para tarefas médias e complexas, crie-o (modelo em workflow.md) no momento da definição de direção e releia-o no início de cada turno/módulo subsequente. Qualquer nova cor, raio, fonte ou valor de movimento deve ser adicionado ao registro de tokens antes do uso. Se um valor não estiver no registro, ele não é permitido no código.
2. Congele o registro de tokens após a amostra principal passar. Módulos posteriores só podem reutilizar tokens registrados. Novos tokens exigem uma nota explícita no registro explicando por que o conjunto existente não pode expressar a necessidade.
3. Cada módulo é comparado visualmente lado a lado com a amostra principal antes de prosseguir. Sem exceções; comparação verbal não é suficiente.
4. Máximo de duas rodadas de correção por etapa. Se ainda estiver falhando, reverta e diagnostique de acordo com a tabela de rollback em workflow.md em vez de adicionar mais correções.
5. Uma direção ativa por vez. Não mantenha direções alternativas ativas entre turnos. Escolha uma, registre-a, descarte as outras.

Princípios fundamentais

1. Projete para a obra, não para o gênero.
   • Primeira resposta: que objeto ou sistema é esta UI dentro da história, quem a fez, quem a lê, quando.
   • Depois, escolha um ponto de memória que pertença a esta obra específica.
   • A identidade visual vem de personagens, lugares, época, facções, eventos, objetos concretos. Fórmulas de gênero (pós-apocalíptico = radar preto/amarelo; cultivo = tinta verde + dourado) são apenas pontos de partida e devem ser tornadas específicas.
   • Autoteste: passe a mesma solicitação genérica do gênero para um agente — se ele produzir uma UI quase idêntica, a direção não é específica o suficiente.
   • Compare algumas direções internamente, entregue exatamente uma. Não liste opções ao usuário para tarefas rotineiras.
2. Um conceito governa cada decisão de design.
   • A cor vem de materiais e fontes de luz; o tipo de métodos de escrita/impressão; a forma do artesanato; o movimento das ações físicas do objeto.
   • Dimensões relacionadas são decididas juntas, não sequencialmente ("todas as cores primeiro, depois todas as fontes" está errado).
   • Para qualquer elemento, você deve ser capaz de afirmar qual parte do conceito ele expressa.
3. Arte concreta usa ativos de ilustração; arte desenhada em código é apenas placeholder.
   • Pessoas, cenas, objetos: a versão final usa ativos de ilustração. Ordem de origem: ativos de projeto existentes → geração por IA → coleção web licenciada.
   • Cenas, pessoas, objetos desenhados em CSS/SVG são permitidos apenas para validação de composição/conceito e devem ser substituídos antes da entrega (o mais tardar na etapa de amostra principal para tarefas complexas). Eles são lidos como arte de programador e rebaixam toda a UI.
   • O código é dono da própria interface: layout, tipografia, bordas, texturas, padrões ornamentais, ícones, gráficos abstratos e de dados.
4. A ilustração lidera a composição.
   • A ilustração define o centro de gravidade do layout; o texto e os componentes se organizam ao redor dela. Nunca a encolha em um banner superior ou uma miniatura de cartão.
   • Cada tela principal deve ser lida como uma imagem: apertando os olhos, a tela deve ser principalmente ilustração, não painéis escuros + linhas finas + texto.
   • A presença da arte continua em páginas funcionais (ilustração como camada de baixo contraste sob painéis, personagens cruzando bordas de painéis, cena mudando com tempo/local). "Abertura deslumbrante, depois páginas de formulário escuras e simples" é o colapso de qualidade mais comum.
   • Uma imagem herói por tela. Imagens secundárias se misturam na mesma imagem ou formam um conjunto uniformemente tratado; nunca alinhe imagens de fontes diferentes em caixas lado a lado.
5. A informação adota formatos do mundo da história, com moderação de adereços.
   • A informação usa formatos e vocabulário nativos do mundo (colunas de livro-razão, layout de lista, verbos/substantivos do mundo) e revela no ritmo narrativo.
   • Um portador principal para toda a UI. Não dê a cada módulo um adereço simulado em CSS diferente (notas adesivas, carimbos tortos, tags, contas de ábaco) — adereços empilhados parecem baratos.
   • Restrinja adereços e ornamentos, não imagens e cor. O espaço liberado de adereços vai para ilustração e tipografia, não para formulários de texto escuros.
   • Nem tudo é "rótulo: valor" + barra de progresso. Páginas de fluxo (onboarding, configurações) não são formulários; opções-chave podem carregar ilustrações.
6. Um padrão de qualidade uniforme.
   • O esforço pode ser desigual: a área focal recebe os melhores ativos e mais detalhes.
   • Nenhuma região visível pode ficar abaixo do padrão. Qualquer coisa desenhada deve corresponder à precisão geral; se não puder, substitua por ilustração ou expresse via tipografia/gráficos abstratos.
   • Para reduzir custos, simplifique dentro da mesma linguagem — nunca recorra a componentes padrão, estilo nativo do navegador ou imagens placeholder.
7. Ler e operar vêm em primeiro lugar.
   • Texto do corpo em chinês: ≥14px (15–17px típico), line-height 1.6–1.9, comprimento de linha ~20–40 caracteres, contraste do corpo ≥4.5:1.
   • O humor é transportado pela temperatura da cor, luz, material, movimento; texto e números permanecem nítidos.
   • Sem texto minúsculo, baixo contraste ou inglês sem sentido como atalho "premium".
   • Imagens e texturas nunca ficam sobre texto do corpo ou alvos de clique.
   • Estados de interação completos, operável por teclado, adaptado à largura alvo.
8. Os padrões devem ser escolhidos, não herdados. Mantenha uma fonte, paleta, estilo de biblioteca de componentes ou barra de rolagem/anel de foco do navegador apenas se selecionados deliberadamente. O kit comum de UI de jogo gerado por IA (papel bege + ardósia escura, carimbo torto vermelho, tags pequenas, nós de etapa hexagonais, gráfico de radar) também é um padrão. Trocar um padrão moderno por outro ainda é um padrão.
9. Moderação de engenharia. Reutilize código, dependências e ativos existentes. Gere/colete ativos de acordo com o plano de ativos apenas. Sem novas dependências pesadas, sem pipeline de ativos, sem refatoração de backend.

Fluxo de execução

1. Entenda a cena

Confirme: gênero; especificidades do personagem/mundo; humor alvo; propósito da página; informações e ações principais; dispositivo alvo; ambiente host (ex.: incorporado em chat). Revise código e ativos existentes. Referências do usuário: extraia a técnica de arte, não a imagem. Prosseguir sem perguntar quando não houver ambiguidade crítica.

2. Defina a direção (todas as tarefas médias+)

Escreva no registro de design:

• Identidade da interface: que objeto/sistema, feito por quem, lido por quem.
• Ponto de memória: uma frase, deve vir das especificidades desta obra.
• Direção de arte: meio, pincelada, direção da luz, paleta, clareza — uma descrição de estilo compartilhada reutilizada textualmente em cada solicitação de geração posterior.
• Lista de exclusão: as fórmulas de gênero e padrões que esta obra deve evitar.
• Plano de ativos: cada item de arte concreta com propósito, proporção, corte, transparência, fonte (existente → IA → web). Verifique se as fontes realmente existem antes de se comprometer; se nem IA nem ativos web licenciados podem suportar a direção, diga agora.

3. Construa

Por nível de tarefa:

• Simples: implemente, capture tela, corrija os 1–3 piores problemas, pronto.
• Médio: área focal com qualidade total → complete a página → uma rodada de revisão combinada.
• Complexo: siga as seis etapas em workflow.md (direção → composição → amostra principal → extensão módulo por módulo → polimento → aceitação). As etapas são portões de qualidade, não pontos de verificação de relatório; prossiga continuamente. Em problemas sistêmicos, volte para a etapa relevante e refaça apenas a parte afetada.

Durante a construção:

• Reutilize código do projeto e padrões de interação.
• Fontes decorativas apenas para títulos; verifique a cobertura de glifos CJK e defina pilhas de fallback.
• Todos os estados: hover, focus, active, selected, disabled, loading, empty, error — visualmente consistentes.
• O movimento serve à interação e ao humor; mesma duração/família de easing em toda a obra; respeite prefers-reduced-motion.

4. Integre ativos

• Coloque a imagem herói primeiro, depois organize as informações de suporte.
• Unifique ativos via corte, máscara, gradação de cor, granulação, mesclagem de bordas, direção de luz unificada; deixe zonas silenciosas para texto.
• Estilos de fontes mistas entram em conflito → gradear para corresponder; ainda conflitantes → substitua, não force.
• Ativos são arquivos de projeto locais, não URLs hotlink. Respeite licenças/atribuição.

Revisão visual (baseada em captura de tela, maiores problemas primeiro)

1. Primeiro olhar (miniatura, ~1s): onde o olho pousa; é o ponto focal planejado; há algo que vale a pena lembrar.
2. Aperte os olhos: a estrutura de valor se lê em 2–3 massas; a tela é principalmente ilustração ou principalmente painéis escuros.
3. Cubra o título: ainda reconhecível como esta obra, não como qualquer modelo de mesmo gênero.
4. Lado a lado: todas as regiões parecem uma única direção de arte (luz, linha, material, paleta, tipo).
5. Tamanho real: texto do corpo em chinês confortável.
6. Bordas: alinhamento, overflow, chrome nativo do navegador, estados vazios, nenhum artefato desenhado em código ou placeholder restante.
7. Interação: estados e movimento.
8. Largura alvo: layout estreito/incorporado.

Prioridade de correção: direção > composição > arte principal > consistência > legibilidade > detalhe. Corrija apenas os 1–3 principais problemas por rodada; recapture a tela após cada rodada. Máximo de duas rodadas por etapa; mantenha um ponto de rollback antes de cada sessão de correção.

Diagnostique a classe de causa antes de corrigir: arte principal ausente / identidade de conceito fraca / hierarquia de composição fraca / conflito de estilo / erro de legibilidade ou layout. Cada um tem uma correção diferente.

Se o modelo principal não puder ver imagens, reutilize uma ferramenta de visão existente ou delegue a revisão a um subagente com capacidade de visão. Relate apenas o que foi realmente verificado.

Lista de verificação de aceitação (todos devem ser sim)

1. Existe um elemento memorável à primeira vista que vem do conteúdo próprio desta obra?
2. Com o título coberto, esta UI ainda não seria confundível com um modelo de mesmo gênero?
3. A área visual mais importante usa ativos de ilustração com uma precisão correspondente ao seu status — sem figuras desenhadas em código, sem elemento visivelmente mais grosseiro no quadro?
4. Ativos, tipo, componentes e fundo são lidos como uma produção única? A região mais simples ainda é pictórica e no mesmo padrão de qualidade?
5. A página é clara, operável, adaptada à largura alvo, com a função nunca sacrificada pelos visuais?

Entrega

• Entregue resultados executáveis primeiro.
• Tarefas complexas: declare brevemente o conceito de arte principal, ativos realmente usados (com notas de licença), principais correções feitas durante a revisão, resultados de verificação e qualquer coisa ainda placeholder.
• Tarefas simples: declare apenas as principais alterações.
• Sem documentos de design longos para o usuário. O registro de design existe para continuidade entre etapas/sessões, não como um relatório para o usuário.