Design System Vutti

Vutti Presentes

Design System do SaaS

Referência viva da interface do produto

Revisão consolidada: 9 de outubro de 2026

Escopo: aplicação web Vutti Presentes, superfícies públicas e autenticadas

Este documento reúne os padrões visuais aprovados e as exceções próprias do Vutti Presentes. Deve orientar a criação e a revisão de interfaces do SaaS. Não autoriza alterações de produto, regras de negócio, produção ou outros produtos Vutti.

1. Princípios e aplicação

• A interface combina produto digital moderno, confiável e operacional com uma camada acolhedora e celebrativa moderada. A proporção conceitual de referência é 80% produto e 20% celebração; não é uma medida de pixels.
• Clareza, leitura, consistência e acesso às ações têm prioridade sobre decoração e ocupação artificial da tela.
• A altura dos componentes acompanha o conteúdo, exceto quando uma dimensão está definida neste sistema.
• Desktop, tablet e mobile são composições próprias. Reorganizar conteúdo e ações antes de comprimir controles.
• Superfícies com funções diferentes podem ter composição específica, mas compartilham tipografia, geometria, iconografia, hierarquia e responsividade.
• O padrão visual não altera ações, dados, permissões, autenticação, pagamentos, reservas, aceites ou validações existentes.

Hierarquia de decisão

1. Decisão visual explícita mais recente aprovada para o produto.
2. Este documento, atualizado para incorporar decisões aprovadas.
3. Implementação atual quando não houver regra normativa específica e sua origem não indicar regressão pendente.
4. Padrão global da família Vutti, como matriz de identidade.
5. Materiais históricos, protótipos e referências parciais.

Uma implementação isolada não substitui uma regra aprovada. Uma regra explícita não deve ser descartada apenas porque uma tela ainda não a aplica integralmente.

2. Identidade e tipografia

Famílias

As três famílias são carregadas no HTML da aplicação. A fonte efetiva deve corresponder ao papel acima; declarações antigas remanescentes no CSS não definem a família vigente quando regras posteriores a substituem.

Escala

Títulos escolhem o token pela função, não apenas pela tag HTML. Texto auxiliar comum usa 14/20 px; 12/16 px fica restrito a informação auxiliar não crítica e ações textuais terciárias, como Esqueci minha senha. Texto principal de apoio usa 16/22 px. Letter-spacing negativo aplica-se somente a títulos em Plus Jakarta Sans. Não há tamanho exclusivo para tablet.

3. Containers, espaçamento e densidade

Larguras e gutters

Os valores são limites, não larguras mínimas. O fundo pode ocupar toda a viewport; conteúdo centralizado respeita o limite e os gutters. O eixo do conteúdo, topbar e rodapé deve permanecer coerente. Superfície que exceda 1120 px é exceção específica, não novo container global.

Gutters estruturais: 24 px em desktop e tablet; 16 px em mobile. Algumas regiões operacionais têm paddings próprios por breakpoint, conforme a composição já consolidada, sem redefinir o container global. No shell operacional, a área principal usa 24 px no desktop, 16 px no tablet e mobile; painéis e grids podem possuir ajustes locais de densidade.

Escala de espaçamento

4, 8, 12, 16, 20, 24, 32, 40, 48 e 64 px.

Cards e painéis usam, em regra, padding de 20 px em desktop/tablet e 16 px em mobile. A escala não arredonda dimensões específicas de componentes: controles de 42 px, botões de 44/48 px, ícones de 18 px e radii de 10 px permanecem como definidos.

Cards de resumo em uma composição de três unidades têm máximo de 300 px cada, gap de 16 px e conjunto máximo de 932 px, centralizado no container. O limite de largura se mantém nas composições responsivas; não impor altura fixa nem alargar um card além de 300 px quando restar em coluna única. Esta regra se aplica a esse componente de resumo, não automaticamente às cinco métricas da tela Reservas.

O shell operacional mantém conteúdo compacto, sem altura mínima artificial para preencher a viewport. A área principal flexível leva o rodapé ao fim em páginas curtas; páginas longas seguem o fluxo normal. Páginas de acesso e estados centralizam-se no espaço disponível sem cortar conteúdo em viewports baixos ou com teclado aberto.

4. Superfícies, cores e geometria

O produto usa superfícies claras, fundo suave, texto escuro, acento verde-petróleo Vutti e cores complementares discretas. Verde, azul/ciano, pêssego, manteiga e rosa podem apoiar a camada celebrativa em doses pequenas. Cores semânticas comunicam sucesso, aviso e erro; cor nunca substitui rótulo ou instrução.

O CSS consolidado preserva os tokens de marca e superfícies existentes, incluindo --vutti-dark, --vutti-gradient, --accent, --accent-strong, --soft, --panel, --ink, --muted e --line. O gradiente principal de ação usa a composição verde para ciano já implementada. Não criar uma nova paleta ou copiar valores de mockups didáticos sem aprovação específica. Contraste deve ser avaliado sobre a combinação real de texto, controle e fundo.

Radius

As sombras são suaves e subordinadas à borda e à hierarquia. Não adicionar camadas de sombra ou gradientes para preencher espaço. Espessuras de borda, cores exatas de foco e todos os níveis de elevação não constituem uma escala independente além dos tokens já existentes.

5. Botões, campos e iconografia

Botões

Botões textuais usam Inter 14/20 px, peso 600, padding horizontal de 16 px e gap de 8 px entre ícone e texto. Largura acompanha o conteúdo, exceto quando a composição exige largura total. Ícones de botão com rótulo medem 18 px. Não somar padding textual à caixa de 44 × 44 px de um botão somente com ícone.

Normal, hover, focus, active, disabled e loading preservam a geometria do componente. O foco permanece visível. O CTA principal usa o gradiente oficial verde/cyan Vutti no estado normal, com texto escuro. O hover usa somente uma variação sutil do mesmo gradiente e mantém a hierarquia visual. Ação neutra e destrutiva mantêm hierarquias distintas. Cor não define sozinha se uma ação é primária: função e contexto definem a altura e a prioridade. Ações recorrentes usam ícones da biblioteca do produto, não emoji ou caracteres tipográficos.

Ações sobre mídia usam botão contextual de 44 px, padding horizontal 16 px, radius 10 px, ícone 18 px e gap 8 px. O rótulo é Adicionar sem imagem própria e Trocar quando ela existe. A ação não muda upload ou enquadramento.

Campos

Labels permanecem visíveis; placeholder não os substitui. Ajuda e erro ficam fora da caixa e não alteram sua altura. Campos obrigatórios usam *; campos opcionais ficam sem indicação salvo necessidade jurídica ou de negócio. Estados normal, foco, desabilitado e erro preservam a geometria.

Campos independentes com ícone de ação, como mostrar senha, conservam o alvo de toque de 44 × 44 px sem converter o campo de 42 px em botão nem aumentar sua altura. O encaixe específico deve respeitar o componente implementado. Controles nativos são preservados quando sua substituição criaria comportamento ou risco de acessibilidade.

Iconografia

Desenhos mantêm traço simples e coerente com a superfície. Alvo interativo não pode ser confundido com o tamanho do desenho; ações somente com ícone têm alvo mínimo de 44 × 44 px. Ícones apoiam a leitura e não substituem rótulos essenciais.

6. Topbar e navegação

A topbar ocupa 64 px em desktop, tablet e mobile, sem quebra de linha nem crescimento para acomodar conteúdo local. Usa o container global e seus gutters. Controles de navegação têm 44 px; em telas estreitas, a navegação se concentra em botão/menu de 44 × 44 px.

A navegação global autenticada contém Minhas listas e Conta, mais as ações contextuais cabíveis à superfície. No editor, Ver como convidado, Publicar lista ou Compartilhar, e Reservas ficam na área contextual da topbar, nessa ordem no desktop, separadas visualmente da navegação global. A ação de publicação/compartilhamento ocupa o mesmo lugar e acompanha o status da lista. Em tablet e mobile, ela é a primeira ação contextual destacada no menu hambúrguer. O cabeçalho da lista mantém status e ações administrativas menos frequentes no menu contextual, sem repetir Compartilhar.

A ação correspondente à superfície atual não se repete na navegação dessa tela: por exemplo, Minhas listas não aparece na tela de listas e Reservas não aparece na tela de reservas. Destinos úteis para outra superfície, como Ver como convidado no editor, permanecem acessíveis. Não criar destinos novos como solução visual.

No desktop, o selo Conta de teste ocupa espaço independente entre marca e ações. Em tablet e mobile, pode ser reorganizado dentro do menu global sem comprimir controles ou ultrapassar os 64 px da barra.

Prévia privada

A topbar mantém 64 px. O contexto de prévia fica em faixa própria abaixo: etiqueta Prévia privada à esquerda, explicação legível e Voltar à edição à direita. Em tablet/mobile, a faixa pode quebrar em linhas, mantendo alinhamento, alvo e ausência de sobreposição. A prévia usa a mesma apresentação pública, mas continua privada e identificada como prévia.

7. Menus, modais e feedback

Menus

Menus agrupam ações secundárias e preservam visíveis as ações frequentes. Ações destrutivas são separadas do grupo operacional. O menu cabe na viewport e não fica preso ao recorte de um card; abre abaixo do acionador e inverte quando faltar espaço. Divisores aparecem somente entre grupos distintos; menu de ação única não recebe divisor isolado. Os menus contextuais de lista e cards permanecem junto ao acionador também no mobile; os de categoria e presente seguem esse padrão no desktop, enquanto o editor mobile/tablet utiliza a exclusão direta descrita na seção do editor. Os menus permanecem ancorados, preferencialmente alinhados pela direita, com margem de 12 px da viewport e alvo de toque mínimo de 44 × 44 px. Reposicionam-se durante scroll e resize e fecham quando o acionador sai da viewport. O próprio acionador, clique externo e Escape permitem fechar o menu; ações destrutivas preservam o tratamento visual existente.

Modais

Modais têm finalidade e título claros, fechamento visível, largura adequada e conteúdo acessível com viewport baixo ou teclado aberto. Preservam foco, Escape e retorno de foco quando já suportados. Erros aparecem no próprio modal e próximos ao campo relacionado. Confirmações usam superfície Vutti, não alert, confirm ou prompt nativos; sucesso simples usa toast não bloqueante.

Confirmações usam título de referência 20 px, peso 600, line-height 1.3, sem divisor entre cabeçalho e conteúdo. A superfície branca usa sombra suave, contorno fino e raio de 20 px. A ação primária mantém o tratamento principal; cancelar é neutro; ação destrutiva é vermelha e separada, nunca entre cancelar e confirmar/salvar. Nomes longos quebram naturalmente. Não criar modal só para repetir informação já presente.

Estados e mensagens

Vazio, carregando, sucesso, erro, desabilitado e processamento devem ser distinguíveis sem inventar dados. Estado vazio explica a situação e destaca somente a ação existente pertinente. Erros ficam próximos da origem. Status operacional usa indicador circular semântico e texto Inter 14/20 px, peso 500, sem fundo, borda ou formato pill; badges de recomendação, conta de teste e qualificação seguem sua própria função.

Estados de página usam uma superfície central única, com título que nomeia a condição, explicação direta e próximo passo real. Vazio operacional e ausência de resultado de busca usam composições distintas. Lista pausada/encerrada usa faixa contextual, não aparência de erro de navegação.

Toasts não bloqueiam a continuação. Presente excluído. Desfazer permanece disponível por aproximadamente quatro segundos. Mensagens curtas, médias e longas usam duração proporcional à leitura; aviso que exige ação não depende de desaparecimento automático. Autosave mostra Salvando… com spinner compacto, Salvo temporariamente e mantém Falha ao salvar até resolução ou nova tentativa; a ação de nova tentativa fica junto ao erro, com alvo de 44 px, sem CTA permanente de atualização quando o editor já persiste as alterações automaticamente.

8. Superfícies do produto

Login, cadastro e recuperação

Acesso tem maior riqueza visual que as superfícies operacionais, sem virar landing page. A composição desktop pode combinar contexto visual de marca e formulário; tablet/mobile priorizam o formulário e reduzem decoração antes de comprimir fontes e campos. Não adicionar depoimentos, números, benefícios ou promessas. Login e recuperação mantêm a mesma família visual.

Cadastro preserva o aceite exigido e acesso aos documentos legais sem duplicação desnecessária. Continuar com Google segue disponível conforme o fluxo do produto; seu aviso legal compacto fica imediatamente abaixo da ação, com links sublinhados e foco visível. Não criar formulário, senha ou checkbox de aceite na continuação Google quando o fluxo vigente não os exige. Confirmação de e-mail, troca de endereço e recuperação mostram estados objetivos no mesmo sistema de acesso e não revelam existência de conta.

Suas listas

O título Suas listas e seu apoio formam um eixo central; a ação principal fica à direita no desktop e integrada ao eixo em mobile. Não restaurar hero, saudação longa, e-mail redundante ou CTA repetido.

Cards comunicam nome/ocasião, status e data existentes, progresso quando calculado e ações. Não adicionar métricas de convidados, presentes ou unidades, nem exibir progresso que sugira atividade sem reservas. Reservas é ação principal; editar e ver como convidado são secundárias. Compartilhamento reúne cópia de link e WhatsApp. Pausar, reativar e encerrar acompanham o estado real. Excluir usa lixeira acessível, separada das ações operacionais. O menu de três pontos só aparece se contiver ações úteis.

O card operacional usa container de até 1120 px, capa com corte 3:2 e conteúdo central flexível. No desktop, a mídia preenche a coluna esquerda disponível do card para aproveitar sua área útil; mantém-se o corte com object-fit: cover, sem distorcer a imagem, e o espaçamento de 24 px até o conteúdo. Ações ocupam o espaço necessário. Status usa ponto semântico e texto Inter 14/20 px, peso 500. Coluna de status/progresso mantém posição coerente entre cards, independentemente do comprimento do título. Tablet e mobile mantêm composição e dimensões próprias, sem herdar a largura da mídia desktop. A regra se aplica aos cards de lista e não redefine a largura da capa pública.

Em mobile, ações textuais ocupam a largura disponível e se empilham; menu permanece no canto superior do próprio card sem cobrir informação. Status e progresso mantêm posição coerente entre cards equivalentes. Altura segue o conteúdo, sem vazio artificial.

Criação, editor, categorias e presentes

Os seletores Tipo, Prioridade e Aceito mais do editor, incluindo inclusão de presente e categoria, usam combobox com opções em listbox. Texto fechado e opções abertas compartilham o centro horizontal da caixa, com padding simétrico e seta fora do eixo textual. O cabeçalho Aceito mais não quebra no desktop; labels contextuais permanecem visíveis em tablet/mobile. O campo conserva 42 px, Inter 16/22 px e radius de 10 px; opções têm alvo de 44 px. O menu acompanha o campo, evita recortes dos cards e inverte verticalmente quando necessário. Preservar nome acessível, foco visível, setas, Home/End, busca por letras, Enter/Espaço, Tab e Escape, além de mouse e toque.

Na cópia de recuperação de uma lista indisponível, seletores são apresentados como texto estático com nome acessível e o rótulo da escolha local mais recente: Item/Kit e Sim/Não, inclusive no conteúdo de categoria ainda aberto. A apresentação conserva Inter 16/22 px, radius de 10 px e altura mínima de 42 px, com quebra de texto quando necessária. Nomes e componentes ocupam a largura disponível; os demais valores têm labels próprios, sem colunas vazias para ações removidas. Esta superfície permite somente consulta e cópia, sem menus, edição ou salvamento; o editor disponível mantém os comboboxes normais.

Agrupar campos por assunto e ordem de preenchimento. Informações relacionadas podem compartilhar linha apenas com largura suficiente. Nome e texto recebem mais espaço que quantidade. Quantidade de novo item começa em branco conforme o fluxo vigente. Dados e controles não devem ser encapsulados em cards sem função.

No editor, cabeçalho de grade e linhas compartilham a mesma geometria. A grade de presentes dá espaço principal ao nome e usa trilhos próprios e consistentes para tipo, quantidade, prioridade, aceite de extra e ações conforme a superfície. Desktop/tablet apresentam cabeçalhos; mobile repõe labels junto aos campos. Nome e categoria permanecem alinhados à esquerda. Edição em linha, expansão, arraste, validação e autosave preservam a interação vigente. Em mobile e tablet, os puxadores de categoria e de todos os presentes compartilham o mesmo eixo visual e mantêm alvo de 44 × 44 px.

No cabeçalho Informações da lista em mobile e tablet, status e menu de ações ficam agrupados à direita acima do título. O título permanece em linha própria, alinhado à esquerda no eixo dos campos, sem quebra e com a hierarquia tipográfica vigente. Autosave permanece abaixo como informação secundária e não desloca o grupo principal. Publicação e compartilhamento ficam nas ações da topbar. O desktop mantém seu alinhamento vigente.

Prioridade, Meta atingida e Aceita extra são etiquetas informativas compactas, Inter 12/16 px, peso 500, junto ao nome ou metadados; não viram faixa de alerta nem usam a aparência do status operacional. A última só aparece quando a opção correspondente estiver ativa.

Kits permanecem em linhas estruturadas com os comportamentos de teclado, foco, remoção e colagem existentes, sem limite funcional de quantidade de componentes. Cada componente conserva o campo de até 120 caracteres. Abrir, colar, editar ou salvar não pode cortar componentes silenciosamente. Uma colagem com texto inválido deve ser rejeitada por inteiro, com explicação e preservação do conteúdo anterior. O kit permanece uma única unidade reservável. Não substituir por textarea livre. Divisor entre informações da lista e personalização conserva 24 px de cada lado. Capa pública e capa personalizada mantêm proporção 3:2; formatos enviados podem variar e o enquadramento não distorce a imagem.

No editor em mobile e tablet, arraste e expansão de categoria ficam agrupados em alvos adjacentes independentes de 44 × 44 px à esquerda; o título flexível ocupa o centro e pode quebrar linhas; a exclusão permanece à direita. Os estados de foco dos dois controles permanecem distinguíveis. O cabeçalho verde-claro da categoria ocupa toda a largura interna do card, com cantos superiores arredondados e ação Adicionar presente larga abaixo do título. O card externo continua delimitando os presentes. O arraste do presente permanece à esquerda do nome e sua exclusão à direita. No mobile, o rótulo Presente de cada linha fica alinhado à esquerda após o puxador, com respiro confortável; puxador e lixeira mantêm recuos laterais equivalentes de 4 px. No tablet, o rótulo Presente do cabeçalho de colunas fica alinhado ao início do trilho do nome e as linhas usam os mesmos trilhos, com puxador e lixeira em alvos de 44 × 44 px e recuos laterais equivalentes de 4 px. Cabeçalho e linhas de presentes persistidos compartilham o padding horizontal de 4 px para distribuir os trilhos na mesma largura. Na grade tablet, todos os trilhos permanecem dentro do card. O desktop conserva a composição aprovada.

No editor desktop, o cabeçalho verde-claro da categoria também ocupa toda a largura interna do card, encosta nas laterais internas e usa os cantos superiores do componente. Arraste, expandir/recolher e nome flexível ficam à esquerda; Adicionar presente e exclusão ficam à direita, dentro da faixa. Os controles mantêm alvos de aproximadamente 44 × 44 px. Categoria recolhida exibe somente o cabeçalho compacto; expandida inicia a tabela logo abaixo, preservando integralmente seus trilhos, campos e ações. Em mobile e tablet, permanece exatamente a composição aprovada acima, com Adicionar presente em linha própria abaixo do título.

No editor da lista, categoria, presente e item interno de kit usam a mesma lixeira neutra em todos os viewports, com ícone uniforme e alvo de 44 × 44 px; não há cor, fundo ou borda destrutiva permanente. Hover e foco permanecem visíveis. As exclusões de categoria e presente continuam exigindo confirmação, com os títulos “Deseja realmente excluir esta categoria?” e “Deseja realmente excluir este presente?” e aviso de que a exclusão pode ser desfeita por alguns segundos. As proteções de remoção permanecem ativas. Menus com múltiplas ações nas outras superfícies permanecem como estão. O editor de itens do kit conserva seus comportamentos de teclado, foco, remoção e colagem.

Exclusões reversíveis usam notificação não bloqueante com ação Desfazer. Exclusões sensíveis ou irreversíveis mantêm confirmação explícita. Categoria e presente restauráveis exibem mensagem contextual, como “Categoria excluída.” e “Presente excluído.”, com ação individual por quatro segundos; operações sucessivas conservam suas possibilidades de desfazer de forma independente. A restauração de categoria inclui a posição, os presentes, kits, componentes e seus demais atributos. Exclusão de lista inteira e de conta não oferece Desfazer.

Na seção Categorias e presentes do editor, o título e a ação Adicionar categoria ficam centralizados em mobile e tablet; desktop mantém o alinhamento aprovado.

Na lista pública, os componentes do kit aparecem em apresentação compacta somente leitura: rótulo Inclui: seguido pelos itens em linha, separados visualmente por |, em Inter 14/20 px. O texto pode quebrar dentro de nomes longos e não interfere nas colunas de quantidade ou reserva.

Publicação e reservas

Publicação usa a ação contextual Publicar lista na topbar do rascunho. O rodapé do editor não exibe um bloco permanente de publicação. Ao acionar, o editor conclui o autosave e mostra todas as pendências num modal Antes de publicar, com ação para focar a primeira correção. Sem pendências, a confirmação comercial vigente prossegue. Após a primeira publicação confirmada, a ação passa a Compartilhar e abre o compartilhamento uma única vez; o mesmo link público continua válido nas edições seguintes. Não indicar sucesso antes da confirmação. O fluxo externo do Checkout Asaas não é padronizado por este documento.

A publicação vale para um evento, sem vencimento pela data e sem mensalidade. A regra anterior de 30 dias após o evento e limite de 180 dias de adiamento foi superada pelo PROMPT 097; seu histórico está em P087-VALIDADE-LISTAS.md. O modal comercial mantém título, subtítulo, preço do servidor, pagamento único, ações e a informação curta Após o encerramento, sua lista fica disponível para consulta por 12 meses. Crédito, autorização existente, pagamento pendente e teste interno usam mensagens contextuais; teste interno não exibe preço. Não acrescentar checkbox nem transformar o modal em página de explicações.

O nome do evento permanece livremente editável pelo autosave, inclusive após a publicação. A ocasião fica bloqueada após o vínculo da publicação. Data e conteúdo continuam editáveis até o encerramento definitivo. Os três campos mantêm alinhamento e espaçamentos uniformes, sem avisos permanentes de vínculo ou validade. Pausar é reversível. Encerrar lista abre a confirmação destrutiva Encerrar lista definitivamente?, com Cancelar e Encerrar definitivamente. Na consulta do histórico encerrado, campos, mídia, presentes e status das reservas ficam desabilitados; a data prevista de exclusão aparece em texto auxiliar. Cards encerrados usam Consultar.

O lembrete Seu evento já aconteceu! é um aviso em fluxo normal no painel do organizador, com texto e ações Manter ativa / Encerrar lista. Não abre modal automaticamente, não bloqueia conteúdo nem aparece na lista pública. Usa card discreto, espaçamento da escala, título 20/26 px e texto 14/20 px; as ações reorganizam-se sem sobrepor o conteúdo. Encerrar lista aciona a confirmação, sem encerrar diretamente.

Na lista pública e na prévia privada, as etiquetas Prioridade e Aceito mais unidades são controles de explicação com a aparência compacta existente, sem ícone extra. A descrição associada é acessível por foco, mouse e toque; Escape ou toque fora fecham. Um único balão fica no plano superior, limitado à área visível com margem de 12 px e largura máxima de 320 px. Interagir com o balão mantém a leitura. A abertura não desloca a linha nem aciona reserva. O editor conserva os títulos Prioridade e Aceito mais, sem explicações.

Reservas tem título próprio, identificação da lista e cinco métricas distintas: Convidados, Unidades reservadas, Presentes com reserva, Pendentes e Preenchimento. Busca permanece compacta. Cada convidado pode expandir detalhes com presente, quantidade, status e data confiável; dado sem timestamp confiável é indicado como indisponível, não inventado. Status usa controle compacto alinhado ao cabeçalho. No tablet e mobile, o título alinha à esquerda no eixo interno do card e Voltar para a lista fica centralizado com largura ampliada; desktop mantém sua composição. Tablet/mobile reorganizam linhas sem overflow.

Lista pública e prévia

A lista pública orienta o convidado por identificação do evento, conteúdo personalizado, categorias/presentes, disponibilidade, ação de reserva e feedback. Não acrescentar cadastro obrigatório, compra do presente, checkout, ações administrativas ou dados privados. Reserva de presente não é compra; cobrança de publicação é outro fluxo.

A data aparece compacta logo abaixo da descrição, alinhada ao conteúdo: rótulo 12/16 px e data 16/22 px, peso 700. Não usa separador, fundo, borda ou largura artificial. Responsável e WhatsApp vêm abaixo em 14/20 px. Lista pública e prévia compartilham a composição.

A capa usa proporção 3:2, fica acima do conteúdo em tela estreita e não é distorcida. A ocasião pode determinar capa local de fallback quando não há imagem própria. A largura final da capa pública não está fixada neste sistema; não assumir uma medida dos mockups como obrigatória.

A coluna numérica Quantidade e seus rótulos responsivos e acessíveis compartilham a mesma nomenclatura. Falta, Reservado e Reservar preservam seus nomes e cálculos.

Cabeçalho da lista pública/prévia reutiliza a geometria e tipografia do cabeçalho do editor: mínimo de 44 px, padding 10 × 14 px, gap 10 px, Inter 14/20 px, peso 500. No desktop, os rótulos de quantidade, falta e reservado ficam no cabeçalho e não se repetem por linha. Em tablet/mobile, labels contextuais reaparecem. As três colunas numéricas têm largura igual; números são tabulares. Nome de categoria e conteúdo permanecem alinhados à esquerda.

Cada categoria pública é um card interno delimitado dentro do contêiner externo existente, com borda sutil, cantos arredondados e cabeçalho em faixa contínua até as laterais internas, respeitando os cantos superiores. Cabeçalhos de coluna, presentes, kits, indicadores, métricas de disponibilidade e ações permanecem dentro do contorno. A mesma composição se mantém responsiva em tablet e mobile, sem trazer controles de edição para a lista pública.

Após reserva concluída, a confirmação é página própria, não modal ou toast. Conforme o PROMPT 101, resultado e convite comercial usam dois cards empilhados e centralizados em desktop, tablet e mobile. O card branco apresenta ícone verde, Reserva confirmada!, resumo compacto com dados reais e retorno secundário Voltar para a lista. O convite reutilizável usa gradiente suave verde/ciano, símbolo oficial V à esquerda de Vutti Presentes e CTA Conhecer o Vutti Presentes, que abre https://vutti.com.br/listas-de-presentes em nova aba. O cabeçalho não repete o CTA nessa composição.

Lista pública sem novas reservas usa a mesma composição abaixo do cabeçalho e contexto preservados do evento, com ícone e mensagem específicos de pausa, encerramento, arquivamento ou disponibilidade esgotada. O estado real prevalece; a data passada não implica encerramento e itens que aceitam unidades extras continuam operacionais. Lista vazia não é apresentada como totalmente reservada. O convite comercial muda o conteúdo por contexto e não aparece em destaque na lista ativa com disponibilidade nem na prévia privada. Esta é uma composição específica dessas superfícies, sem criar tokens globais.

Rodapé do SaaS

No desktop, o rodapé compacto distribui links legais à esquerda e suporte à direita no mesmo container. O suporte apresenta “Precisa de ajuda com sua lista? Fale com a gente.”, e-mail funcional e número do WhatsApp com o ícone oficial da marca, formando um único link que abre em nova aba. Tablet e mobile reorganizam os grupos conforme o espaço disponível, sem comprimir textos ou produzir overflow.

9. Celebração, imagens e movimento

Login/cadastro e lista pública admitem presença celebrativa moderada; criação, personalização e listas usam acentos leves; edição de itens e estados de erro priorizam a operação. Usar um motivo visual por composição, manter decoração nas margens e reduzir sua presença quando competir com conteúdo em telas menores. Ilustrações não cobrem título, mídia, dados ou controles, não capturam foco e não exigem animação contínua. Evitar mascote infantil como identidade geral, stock genérico, excesso de tons pastel/neon e fundos carregados atrás de listas.

Imagem não é distorcida; preservar proporção ou usar enquadramento deliberado existente. Não inferir uma nova dimensão para capa além de 3:2 quando a largura não estiver definida. Transições são breves e funcionais, não atrasam leitura nem operação. Respeitar prefers-reduced-motion e manter conteúdo disponível quando animação não puder ocorrer.

10. Responsividade e acessibilidade

Breakpoints estruturais

Breakpoints adicionais só são usados quando um componente demonstrar necessidade. Viewports de referência para validações visuais: 390 × 844, 768 × 1024 e 1440 × 900. 375 px, 820 × 1180 e 1600 × 1000 são complementares. Nenhuma tela deve produzir overflow horizontal global.

Mobile prioriza título, informação principal, CTA, conteúdo secundário e decoração, nessa ordem. Campos, botões, alvos, menus, modais e ações não são encolhidos apenas para caber lado a lado. Cards, grades, imagens e tabelas reorganizam-se de acordo com conteúdo real. Em desktop, aproveitar largura sem alongar excessivamente texto ou adicionar sidebar sem função. Tablet não é uma versão comprimida do desktop.

Manter labels, foco visível, nomes acessíveis para ações com ícone, contraste funcional, ordem de leitura e navegação por teclado. Estados nunca dependem só de cor. Menus e modais preservam foco, fechamento e retorno conforme implementados. Validar nomes longos, listas vazias, erros, teclado móvel e conteúdo extenso nas superfícies afetadas.

11. Exceções e limites documentados

Acesso público: cadastro e login

As referências finais aprovadas no PROMPT 090 substituem a apresentação anterior de cadastro e login. O card central tem máximo de 548 px no cadastro e 542 px no login, raio de 20 px, padding lateral de 24 px no cadastro e 27 px no login e título 40/48 px em desktop/tablet. Campos usam 54 px e ações principais, Google e troca de modo usam 62 px; são exceções específicas destas duas telas. O CTA usa gradiente verde/ciano com texto branco conforme a referência. A marca aparece apenas no cabeçalho de 92 px (80 px no mobile), com faixa escura superior; o fundo é suave e o rodapé contém documentos e atendimento em ambos os modos.

No mobile, card com padding lateral de 20 px, título 28/34 px, campos 48 px e botões 52 px reorganizam a composição sem overflow. Labels permanecem visíveis, com os placeholders da referência. Cadastro usa “Crie sua conta” e “Organize e compartilhe suas listas de presentes.”; login usa “Entre na sua conta” e “Continue de onde parou.”. Google usa a marca colorida. Há um único aviso legal abaixo do Google por modo e não há checkbox de aceite no cadastro; a ação de criar conta manifesta o aceite, que continua registrado pelo servidor. Confirmação de e-mail legada e demais aceites específicos conservam seus controles próprios.

A orientação de senha é um popover compacto junto ao campo, oculto inicialmente. Ao digitar uma senha incompleta ou tentar enviá-la, mostra os critérios reais com estado textual de cumprido/falta; atualiza sem anúncios a cada caractere, desaparece ao cumprir a política ou sair do campo, e Escape o dispensa. Não exige maiúsculas: a política vigente é 10–128 caracteres Unicode, uma letra, um número ASCII e um caractere especial não branco. O backend permanece autoridade. Mensagens dinâmicas, foco, recuperação, confirmação, vinculação Google e segurança permanecem funcionais.

Painel Vutti administrativo

O acesso administrativo preserva o card aprovado, fundo suave, marca Painel Vutti, OPERAÇÃO VUTTI e acabamento. E-mail/senha próprios precedem Esqueci minha senha e Entrar, o CTA principal no gradiente Vutti. Depois vêm divisor ou, Google secundário com marca reconhecível, documentos jurídicos e Voltar às minhas listas. Recuperação e redefinição trocam o conteúdo do mesmo card, com foco no título após transição, erro persistente junto ao formulário e campos com mostrar/ocultar senha. O tema escuro pertence à área autenticada; o acesso mantém a composição clara aprovada.

A superfície administrativa em painel.vutti.com.br (frontend independente; presentes.vutti.com.br/painel histórico e desativado, 404 sem redirect) reutiliza identidade, fontes, gutters, campos e botões do SaaS. Seu app shell administrativo não tem topbar: sidebar e conteúdo começam no topo, com busca global na primeira linha útil alinhada à marca. No desktop, a sidebar fixa expande com nomes ou recolhe com ícones e nomes acessíveis. O controle junto à marca tem SVG de 20 px, alvo de 44 × 44 px, tooltip e foco visível. A preferência de recolhimento é local ao navegador. Em tablet/mobile, a navegação única aparece em um drawer sobre o conteúdo, acionado por controle de 44 × 44 px, com fechamento por Escape, seleção e toque fora. O perfil da conta autenticada ocupa o rodapé da sidebar; mostra imagem processada e persistida da própria conta ou iniciais como fallback. Seu menu mostra identidade, e-mail, perfil e as ações Minhas listas, Alternar tema e Sair. A imagem do perfil é alterada pelo avatar grande, um botão de 44 × 44 px com foco visível, nome acessível próprio e suporte a teclado; não há ação textual separada. A imagem aceita JPG, PNG ou WebP de até 5 MB e é armazenada como WebP quadrado. O tema escuro é exclusivo do painel, ativado pelo usuário e salvo no navegador; preferência ausente ou inválida retorna ao claro. Busca global e ações obedecem à hierarquia de cada perfil. Essa composição é própria da administração e não substitui os menus ou o cabeçalho do cliente.

A busca global reúne o campo, Buscar e Atualizar na mesma faixa. Em desktop e tablet com espaço suficiente, os botões ficam juntos imediatamente após o campo; em mobile, o campo pode ocupar a primeira linha e o grupo de ações permanece unido na seguinte. Buscar submete somente a busca; Atualizar é um botão independente que recarrega a rota e o contexto atuais. Ações específicas da área permanecem junto ao título local.

O conteúdo operacional do painel pode atingir 1440 px dentro do espaço restante à direita da sidebar, centralizado com gutters de 24 px no desktop e 16 px em tablet/mobile. A largura global de 1120 px das demais superfícies permanece vigente. Recolher a sidebar disponibiliza imediatamente a largura liberada.

Nos cabeçalhos ordenáveis, somente o texto do título pode ser truncado. O indicador ↑/↓ ocupa espaço próprio, permanece visível na largura padrão da coluna e fica fora do nome acessível; o estado sem ordenação não mostra glifo.

Consultas usam tabelas com cabeçalhos legíveis, ordenação em três estados e rolagem horizontal localizada. Fichas preservam filtros de origem, distinguem dados ausentes de zero e indicam consultas somente leitura. Decisões usam modais com labels, foco inicial e retorno ao controle acionador; feedback simples usa toast. Manter alvos de 44 px e estados em texto, sem depender só de cor. Validar essas superfícies nos viewports oficiais e os componentes críticos em 820×1180 e 360×800. Não transformar uma largura incidental de sidebar em token global.

As tabelas administrativas têm divisores verticais contínuos no cabeçalho e corpo, além das linhas horizontais. A coluna Ações mantém rótulo e conteúdo alinhados sem espaço reservado para divisor ausente; em grades ordenáveis, seu rótulo usa uma caixa interna de 44 px alinhada como os controles de título, sem aumentar a altura existente do cabeçalho. As demais colunas permitem redimensionar por divisor no cabeçalho em desktop e tablet com espaço suficiente. Cada tabela conserva suas larguras próprias no navegador; duplo clique no divisor restaura apenas a coluna correspondente. O divisor não aciona a ordenação. Tabelas largas rolam somente no próprio container, e a coluna Ações permanece no fluxo e alinhada ao cabeçalho. Em mobile estreito, a leitura e a rolagem local têm prioridade sobre o gesto de resize. Cards de métricas numéricas centralizam rótulo e valor; fichas e cards genéricos conservam sua composição. Resumos quantitativos, como reservas e conversão acumulada, usam mini-grade de duas colunas com faixa de título, cabeçalho Indicador/Quantidade ou Indicador/Valor conforme o dado e linhas separadoras. Títulos e textos de apoio de seções compartilham o alinhamento horizontal dos cards e grades abaixo. No resumo de origem da autorização da visão geral, o cabeçalho e os valores de Publicações ficam alinhados à direita.

No tablet (720–1099 px), o divisor de coluna conserva traço visual de 1–2 px, mas oferece alvo de toque transparente de 44 × 44 px dentro do cabeçalho. O espaço do rótulo e da ordenação fica reservado separadamente para não haver sobreposição entre os controles nem com a coluna seguinte.

As tabelas paginadas mostram 10 registros por página e informam a faixa exibida, o total e a página atual. Datas manuais aparecem somente no período personalizado; selecionar um período pronto limpa os valores manuais. A faixa selecionada é apresentada em formato brasileiro, sem expor o identificador de fuso. O cabeçalho da sidebar administrativa usa o símbolo oficial sem moldura e mantém acesso a Minhas listas no menu do perfil. A busca global mantém Buscar e Atualizar agrupados na faixa, conforme a composição responsiva definida nesta seção. As tabelas reduzem o espaço vertical das linhas sem reduzir a área acionável mínima de 44 px nem quebrar palavras comuns. O perfil técnico não é repetido abaixo do título da área.

As exceções abaixo são específicas do Vutti Presentes e não são regras genéricas para outros produtos Vutti:

• Prévia privada usa a experiência pública com sessão e contexto próprios, além de uma faixa de retorno ao editor.
• Conta de teste é identificador contextual da conta interna, com posicionamento próprio na topbar e reorganização no menu estreito.
• Status operacionais usam ponto semântico e texto simples, não badge preenchido/pill.
• Labels contextuais de métricas públicas reaparecem em tablet/mobile; no desktop ficam no cabeçalho compartilhado da grade.
• Confirmação pós-reserva é página de resultado dedicada; toast não a substitui.
• Publicação pode continuar para checkout externo, enquanto a reserva do convidado não é compra.
• Capa temática de fallback depende da ocasião quando não há upload próprio; capa própria usa recorte 3:2 sem distorção.
• Lixeira de exclusão, ações do card e menu de três pontos obedecem aos estados e opções reais da lista.
• Aceite legal, confirmação de e-mail e continuação Google seguem seus próprios estados de produto e não são simplificados por composição visual.

Pontos sem decisão visual universal fechada: paleta semântica completa além dos tokens já usados; escala de bordas/foco/sombras completa; dimensão final da capa pública; encaixe visual definitivo de ações independentes junto a controles de 42 px; dimensões de marca não consolidadas; e aparência de interações/componentes não especificados neste documento. Preserve o estado atual aprovado nesses pontos e não invente novos tokens.

12. Manutenção

Antes de alterar uma tela, identificar os tokens e componentes envolvidos e distinguir regra global de exceção específica. Quando uma alteração aprovada mudar um padrão reutilizável, atualizar este documento na mesma tarefa. Registrar exceção apenas quando houver necessidade ligada à superfície e decisão clara; resultado pontual ou aparência incidental não cria regra global.

A aplicação do sistema a uma superfície não autoriza redesenhar outra. Este documento não substitui especificações funcionais, legais, de segurança, comerciais ou de integração. Não usar exemplos como autorização para criar recurso, remover dado ou mudar fluxo.

Resumo dos tokens