Guias de branding abrangentes cobrem razoavelmente pesquisa, posicionamento, identidade, voz e aplicação. O handoff para o desenvolvedor começa depois. Seu trabalho é traduzir a direção de marca aprovada em decisões de website, sem pedir que o implementador invente políticas ou regras de design ausentes.

Mantenha seis tipos de materiais separados. Assets de identidade tradicionais incluem logos, marcas, cores da marca, tipografias, fotografia, ilustração e orientações verbais. Decisões de design de website atribuem esses materiais a papéis semânticos, escalas, layouts, modos e regras de uso. Requisitos de produto definem comportamento, permissões, validação, conteúdo e recuperação. Artefatos de entrega transportam decisões de design aprovadas para um repositório ou ferramenta. Consumidores implementados são os componentes e superfícies que leem esses artefatos. Evidências de aceitação registram o que foi verificado e o que permanece não resolvido.

Registre cada decisão como uma cadeia da autoridade até a evidência. Isso expõe dois erros comuns: tratar a exportação mais recente como a fonte da verdade e tratar um valor de token correto como prova de que a interface o utiliza corretamente.

• Artefato: o asset, regra, grupo de tokens, arquivo ou referência sob revisão.
• Fonte da verdade: o local e a versão aprovados que têm autoridade sobre a decisão.
• Propósito semântico: o que a decisão significa na interface, e não apenas seu valor visual.
• Formato de entrega: como a decisão chega ao projeto, como orientações escritas, tokens DTCG, variáveis CSS, um tema Tailwind ou um item de registro.
• Consumidor pretendido: o componente, template, agente, ferramenta de build ou camada de estilo de runtime que deve utilizá-lo.
• Responsável: a pessoa ou equipe autorizada a resolver ambiguidades ou aprovar uma alteração.
• Alterações permitidas: transformações que o implementador pode fazer sem precisar de nova aprovação.
• Omissões conhecidas: papéis, modos, estados, breakpoints, assets ou regras necessários que a fonte não define.
• Evidência de aceitação: a superfície, estado, viewport, modo e resultado observável usados para verificar a implementação.

artifact: ""
status: ready-to-implement | requires-decision | reference-only | outside-handoff
source_of_truth:
  location: ""
  version_or_date: ""
  approved_by: ""
semantic_purpose: ""
delivery:
  format: ""
  path_or_identifier: ""
intended_consumers:
  - ""
owner: ""
permitted_changes:
  - ""
known_omissions:
  - ""
acceptance_evidence:
  surfaces:
    - ""
  states:
    - ""
  viewports_or_containers:
    - ""
  color_modes:
    - ""
  expected_observation: ""
notes: ""

O campo de status controla o que acontece a seguir. Ele evita que uma imagem de referência ganhe autoridade acidental e mantém requisitos indefinidos fora da fila de implementação.

• Pronto para implementar: a autoridade, o propósito semântico, o consumidor, as alterações permitidas e as condições de aceitação relevantes são explícitos.
• Requer uma decisão: o input é relevante, mas pelo menos uma regra material está ausente ou é contraditória. Atribua um responsável e bloqueie apenas o trabalho afetado.
• Apenas referência: o item comunica direção ou contexto, mas não é preciso o suficiente para governar a implementação. Mood boards e mockups de campanha geralmente pertencem a esta categoria.
• Fora do handoff do site: o item pertence a outra disciplina ou entrega, como revisão de marca registrada, planejamento de campanha, permissões de produto ou redação editorial final. Registre esse limite para que a ausência do item não seja confundida com uma tarefa do desenvolvedor.

A classificação é granular. Um pacote de logos pode estar pronto para implementação, enquanto seu tamanho mínimo em larguras reduzidas ainda exija uma decisão. Um sistema de cores pode estar pronto para o modo claro, enquanto o modo escuro permaneça indefinido. Dividir o registro dessa forma permite que o trabalho continue sem ocultar a parte não resolvida.

Cores brutas são ingredientes. O código do site precisa de papéis (roles), como fundo de página, primeiro plano, card, superfície suavizada, borda, ação primária, ação destrutiva, anel de foco e cores de status. Cada combinação de primeiro plano e superfície precisa de um uso pretendido. Se os modos claro e escuro forem suportados, registre ambos os mapeamentos e indique se um modo pode recorrer a outro valor (fallback).

Não derive cores de erro, aviso, sucesso, seleção ou foco de uma cor de destaque da marca, a menos que a autoridade atribua esses significados. O mesmo valor hex pode ser válido como cor de campanha e incorreto como um papel de interface.

Registre a família para cada papel, os pesos aprovados, a escala tipográfica, regras de altura de linha (line-height), espaçamento entre letras, fallbacks e onde fontes mono ou display são permitidas. Apenas o nome de uma família de fontes deixa que o navegador e o desenvolvedor escolham pesos e métricas. Além disso, não define nada sobre cabeçalhos, corpo de texto, rótulos, botões, tabelas ou dados numéricos.

A entrega da fonte é uma decisão de implementação separada. O brand kit pode aprovar famílias e papéis enquanto o projeto ainda precisa de uma estratégia de carregamento, arquivos disponíveis, fallbacks e verificações de performance. Essas escolhas técnicas devem preservar os papéis aprovados, sem fingir que o handoff visual resolveu cada trade-off de entrega.

Especifique a escala de espaçamento, margens da página (gutters), larguras de conteúdo, ritmo de seção, comportamento da grade, raios de canto, bordas, sombras e motivos recorrentes que tornam o sistema reconhecível. Nomeie as exceções. Se um motivo for decorativo, indique onde ele pode aparecer e como se comporta em containers limitados.

Para logos, registre as variantes aprovadas, área de respiro, tamanho mínimo útil, restrições de fundo e se o corte ou a recolorização são permitidos. Para fotografia e ilustração, inclua regras de seleção e tratamento em vez de apenas uma pasta de exemplos. O texto alternativo e o significado do conteúdo ainda dependem do contexto real da página; uma biblioteca de ativos de marca não pode fornecê-los universalmente.

Breakpoints, comportamento de container, reflow, truncamento, mudanças de navegação, densidade e alvos de toque são decisões do site. Estados de hover, foco, pressionado, selecionado, desativado, carregando, sucesso, vazio e erro precisam de requisitos onde o produto possa alcançá-los. Um brand board estático não define esses comportamentos.

O handoff pode definir o tratamento visual para botões, inputs, cards, navegação, tabelas, gráficos e diálogos. Ele não define automaticamente o que esses componentes fazem. Permissões, validação, confirmação, cancelamento, manipulação de dados e recuperação pertencem aos requisitos de produto. Mantenha essa autoridade separada, mesmo quando ambos os tipos de regra aparecem na mesma interface.

O kit público Ambient Sage mostra como várias camadas de handoff podem se conectar. Ele atribui Plus Jakarta Sans aos papéis de cabeçalho e corpo, com pesos 400, 500, 600 e 700. JetBrains Mono preenche o papel mono nos pesos 400, 500 e 700. A escala publicada é compact-product. Seu sistema de cores inclui papéis semânticos para modos claro e escuro, enquanto a orientação escrita descreve uma tela warm-sage, tratamento de card tonal, destaque amarelo contido e valores numéricos superdimensionados.

Isso é mais útil do que uma lista de fontes porque vincula famílias a papéis e pesos, e mais útil do que uma paleta porque fornece mapeamentos semânticos e orientação de uso. O mesmo kit está disponível via DESIGN.md, JSON de tokens DTCG, variáveis CSS, outputs do Tailwind, JSON do registro shadcn, um caminho de instalação de registro, a CLI do Identity Forge e acesso MCP.

O exemplo tem limites firmes. Ele não prova que Plus Jakarta Sans e JetBrains Mono são a melhor combinação para outro produto. Não estabelece o comportamento de componentes, regras responsivas, requisitos de conteúdo, conformidade de acessibilidade ou prontidão para produção de outro produto. Essas decisões ainda precisam de proprietários locais e evidências.

Um artefato de entrega deve carregar uma decisão aprovada sem se tornar silenciosamente a autoridade que a criou. Registre qual fonte produziu o artefato, quando ele foi gerado e qual consumidor o lê. Se um export e sua fonte divergirem, resolva a fonte ou o caminho de regeneração antes de corrigir o componente visível.

• O DESIGN.md carrega a intenção, regras de uso, orientação de layout, motivos, tratamentos de componentes e restrições que são difíceis de expressar como valores de token.
• Tokens DTCG fornecem uma representação estruturada que pode alimentar ferramentas ou transformações, mantendo nomes e valores de tokens.
• Variáveis CSS expõem valores de tema diretamente aos estilos e componentes. A presença delas não prova que cada componente referencia o papel correto.
• O output do Tailwind mapeia decisões para as convenções de utilitários e temas do projeto. Utilitários locais ainda podem sobrescrever ou ignorar esse mapeamento.
• Um item de registro shadcn empacota valores para um caminho de instalação compatível. Ele continua sendo um mecanismo de entrega, não uma evidência de que os componentes instalados satisfaçam todas as regras da marca.
• O acesso via CLI aplica ou escreve artefatos em um projeto. O acesso MCP permite que um agente compatível descubra, leia ou aplique informações do kit. Em ambos os casos, o projeto receptor ainda precisa de uma autoridade declarada e de um registro de aceitação.

Escolha superfícies que exercitem diferentes papéis em vez de verificar cada rota superficialmente. Inclua os modos, estados e larguras de container que o produto realmente suporta.

• Navegação: tratamento do logo, estado ativo, hierarquia, foco e comportamento em larguras reduzidas.
• Cabeçalhos e corpo de texto: mapeamento de papéis, pesos permitidos, comprimento de linha, quebra de texto e ritmo vertical.
• Formulários: rótulos, inputs, texto de ajuda, validação, controles desativados, foco e estados de recuperação que estejam no escopo.
• Botões e links: tratamentos primário, secundário, destrutivo, pressionado, desativado e de foco, onde for necessário.
• Cards e overlays: papéis de superfície, combinações de primeiro plano, bordas ou separação tonal, raio, espaçamento e empilhamento.
• Tabelas ou métricas: hierarquia de cabeçalhos, tratamento numérico, alinhamento, densidade, valores longos e estados vazios.
• Estados de status: funções de sucesso, aviso, erro, seleção e carregamento, sem inventar significados a partir de cores decorativas.
• Modos claro e escuro: paridade semântica, legibilidade, overrides locais e componentes que mantêm um valor bruto de modo claro.
• Containers estreitos: quebra de linha, reflow, clipping, mudanças de navegação e motivos que competem com o conteúdo.

Um screenshot pode revelar uma divergência, mas raramente identifica o responsável. Rastreie uma decisão aprovada através de toda a cadeia. Uma mudança controlada torna visíveis as camadas obsoletas ou ignoradas.

1. 1

   Escolha uma decisão aprovada de baixo risco

   Use um token reversível ou um mapeamento de tipografia que tenha uma fonte clara e um consumidor representativo. Registre a versão atual da fonte e as superfícies esperadas.

2. 2

   Confirme o registro autoritativo

   Verifique o propósito semântico, os modos permitidos, o responsável e o valor ou regra esperada. Se a autoridade for ambígua, interrompa o teste e resolva essa ambiguidade primeiro.

3. 3

   Regere ou atualize o artefato de entrega selecionado

   Use o fluxo de entrega normal. Registre a versão do artefato ou a mudança resultante para que um export desatualizado possa ser distinguido de uma implementação incorreta.

4. 4

   Inspecione o consumidor pretendido

   Confirme se o componente ou camada de estilo relevante lê a função semântica. Procure por valores brutos, aliases, constantes copiadas, padrões do framework e overrides locais.

5. 5

   Verifique superfícies representativas

   Inspecione o estado, viewport, container e modo de cor aplicáveis. Registre tanto a mudança esperada quanto qualquer superfície que não tenha mudado.

6. 6

   Classifique cada divergência por camada

   Uma decisão de fonte errada retorna ao responsável pelo design. Um export obsoleto retorna ao processo de entrega. Um mapeamento incorreto pertence à integração do consumidor. Um override local pertence à implementação. Uma mudança em outro lugar pode ser um desvio não relacionado e não deve ser incluída na correção da marca sem evidências.

7. 7

   Restaure ou aprove o valor controlado

   Retorne ao valor aprovado, a menos que o próprio teste tenha sido uma atualização autorizada. Preserve o registro de evidências de qualquer maneira.

Finalize a entrada com uma decisão explícita. A aprovação deve ser limitada às decisões e superfícies suportadas pelas evidências, e não redigida como uma afirmação geral de que a marca ou o site estão concluídos.

decision: approve | revise | block
scope:
  decisions: []
  consumers: []
  surfaces: []
  modes: []
  viewports_or_containers: []
resolved_evidence:
  - decision: ""
    source_of_truth: ""
    delivery_artifact: ""
    observed_result: ""
unresolved:
  - issue: ""
    classification: missing-decision | stale-artifact | consumer-mapping | local-override | unrelated-drift
    owner: ""
    required_evidence: ""
    next_action: ""
    blocks: ""
permitted_implementation_step: ""
reviewed_by: ""
reviewed_on: ""

A próxima etapa de implementação deve decorrer diretamente deste registro. Aplique o artefato aprovado quando a cadeia estiver completa. Solicite uma decisão nominal quando a autoridade estiver ausente. Corrija a camada de entrega ou do consumidor identificada quando a fonte já estiver correta. Isso evita que o desenvolvedor transforme uma questão de marca não resolvida em uma convenção local permanente.

• Como construir uma marca do zero (2026): A Shopify apresenta o brand kit e o guia de estilo dentro de um processo mais amplo que também abrange pesquisa de público, voz, naming, história, criação de logo, aplicação e medição.
• O que é uma marca? Definição e exemplos: A Ramotion descreve os componentes de marca através da identidade visual, identidade verbal, experiências de interação, valores e posicionamento, mostrando que uma marca vai além de um logo.
• O que é Branding? Entendendo sua importância: A HubSpot aborda a estratégia de marca, assets visuais, voz e aplicação em sites e outros canais como partes de um processo de branding mais amplo.
• Kit de Design Ambient Sage: O kit público Ambient Sage documenta a Plus Jakarta Sans para títulos e corpo de texto, JetBrains Mono para a função mono, design tokens semânticos para temas claro e escuro, orientações escritas e diversos formatos de entrega para desenvolvedores.
• Como gerar um DESIGN.md (e o que ele é): O Identity Forge descreve o DESIGN.md como um brief de design escrito que contém a intenção, sistemas de cores e tipografia, regras de layout e espaçamento, tratamentos de componentes, motivos e restrições explícitas de uso.
• Explicação sobre design tokens de cores semânticas: O Identity Forge explica que tokens semânticos nomeiam as cores por finalidade — como background, foreground, primary, border e ring — em vez de usar a matiz bruta.
• Checklist de revisão de UI por IA: teste interfaces geradas antes do deploy: O guia de revisão separa requisitos de produto, autoridade de design, artefatos de entrega, evidências de implementação e evidências de acessibilidade, recomendando o rastreamento de alterações controladas até a camada responsável por qualquer divergência.
• Geradores de design system shadcn/ui: você precisa de um tema, de um sistema ou de um handoff para agente?: O Identity Forge diferencia um tema visual de um design system mais amplo e de um handoff para agente, recomendando a inspeção do significado dos tokens, paridade de modos, tipografia, orientações de layout, rotas de instalação e lacunas conhecidas.

• How To Build a Brand From Scratch (2026): A Shopify apresenta o kit de marca e o guia de estilo dentro de um processo mais amplo que também abrange pesquisa de público, voz, naming, storytelling, criação de logo, aplicação e mensuração.
• What is a Brand? Definition and Examples: A Ramotion descreve componentes de marca abrangendo identidade visual, identidade verbal, experiências de interação, valores e posicionamento, demonstrando que uma marca vai além de um logo.
• What is Branding? Understanding Its Importance: A HubSpot cobre estratégia de marca, assets visuais, voz e aplicação em websites e outros canais como parte de um processo de branding mais amplo.
• Ambient Sage Design Kit: O kit público Ambient Sage documenta a Plus Jakarta Sans para títulos e corpo de texto, JetBrains Mono para a função mono, design tokens semânticos para temas claro e escuro, orientações escritas e diversos formatos de entrega para desenvolvedores.
• How to generate a DESIGN.md (and what it is): A Identity Forge descreve o DESIGN.md como um briefing de design escrito que contém a intenção, sistemas de cores e tipografia, regras de layout e espaçamento, tratamentos de componentes, motivos e restrições explícitas de uso.
• Semantic color tokens explained: O Identity Forge explica que tokens semânticos nomeiam as cores por finalidade — como background, foreground, primary, border e ring — em vez de usar a matiz bruta.
• AI UI review checklist: test generated interfaces before you ship: O guia de revisão separa requisitos de produto, autoridade de design, artefatos de entrega, evidências de implementação e evidências de acessibilidade, recomendando o rastreamento de alterações controladas até a camada responsável por qualquer divergência.
• Shadcn design system generators: do you need a theme, a system, or an agent handoff?: O Identity Forge diferencia um tema visual de um design system mais amplo e de um handoff para agente, recomendando a inspeção do significado dos tokens, paridade de modos, tipografia, orientações de layout, rotas de instalação e lacunas conhecidas.