Três produtos, três marcas, um design system: a conta fecha com design tokens organizados em camadas. O token separa decisão de valor; qual cor representa ação primária é decisão, o hex exato é valor. Sem essa separação, cada marca nova copia componentes e o conjunto diverge em semanas. Com ela, a marca sobrescreve valores e o sistema troca de pele sem fork de componente.

Quais são as camadas de tokens?

  1. Tokens primitivos: valores brutos como color-blue-500, compartilhados por todas as marcas
  2. Tokens semânticos: action-primary, surface-raised, text-danger, referenciam primitivos
  3. Component tokens: button-bg, consomem semânticos e isolam variações

Disciplina de naming sustenta o conjunto: nomes descrevem papel, então a marca B renderiza danger em laranja e text-danger continua de pé. Primitivos mudam pouco; semânticos acompanham o produto; component tokens absorvem exceções sem contaminar o resto. Renomear token depois da adoção custa mais que qualquer debate de naming na criação.

Como compilar tokens para várias plataformas?

Fonte única em JSON, compilação via Style Dictionary para CSS custom properties, Swift, Kotlin e config do Tailwind. Referência quebrada entre camadas falha o build no CI, antes de chegar ao design review. Tema sincronizado à mão drifta em semanas; o pipeline publica pacotes versionados por plataforma.

Como trocar de marca em runtime?

Custom properties cascatam por escopo. Um atributo data-theme="marca-b" no wrapper redefine os tokens semânticos, e a página muda sem rebuild. O mesmo mecanismo atende white-label: o host redefine dois tokens e o widget embutido veste a identidade do parceiro. Tokens inline custam poucos KB e dispensam requisição extra; em SSR, eles entram antes do paint para evitar flash do tema errado no primeiro render.

Como manter coerência entre marcas diferentes?

Escala tipográfica modular em razão 1,25 com grid de espaçamento de 4/8px sustenta três personalidades distintas. As marcas variam cor, raio de borda e peso do display; ritmo vertical e hierarquia permanecem iguais em todas.

Como governar mudanças de token?

PR de token passa por review com snapshots de regressão visual no Chromatic e screenshots do Playwright comparando componentes nas três marcas. O pipeline publica changelog por release, e os times consumidores enxergam o diff no PR antes de atualizar. Rename breaking segue ciclo de deprecação como qualquer API pública: versão nova convive com alias da antiga por um release.

Dark mode sai de graça?

Sai. O dark theme vira mais um arquivo de marca sobrescrevendo apenas tokens de surface e text. Nenhum seletor novo, nenhum fork de componente; a camada semântica absorve a variação inteira.