O desvio visual de um painel raramente vem de uma grande mudança, e sim de valores de cor, espaçamentos e componentes avulsos espalhados pelo código: o mesmo “sucesso” aparece em três tons de verde, e trocar o tema exige mexer em dezenas de arquivos.
O admin-design começa pelos tokens e pelas estruturas, e só depois fala de páginas.
A cor descreve o propósito, não o valor
A cor passa apenas por classes utilitárias semânticas: bg-card, text-muted-foreground, text-success, border-destructive. Trocar o tema altera tokens, não o código de negócio.
As paletas funcionam em duas camadas: seis predefinições (teal, blue, forest, violet, amber, graphite e personalizada) definem o tom geral, enquanto cores base (neutral, stone, zinc e outras) e cores de tema em dezoito matizes ajustam o restante. Os modos claro e escuro guardam escolhas separadas.
A acessibilidade não é um acréscimo: tamanho e peso da fonte, alto contraste, suporte à visão de cores, redução de movimento e links sublinhados ficam nas configurações. As preferências permanecem no navegador e nunca entram nos dados de negócio.
Todos os gráficos são SVG desenhado à mão
Linhas, barras, anéis, mini barras, barras horizontais, mapas de calor, radar, funil e Gantt compartilham o mesmo conjunto de cores semânticas, seguem os modos claro e escuro e trazem role="img" com um aria-label que diz o que o gráfico mostra.
O preço de zero dependências é manter coordenadas e escalas. O retorno é o controle sobre tamanho do pacote, auditorias e consistência de tema: não existe um segundo sistema de cores para sincronizar.
A galeria é a superfície de aceite
Nove categorias de componentes ocupam nove páginas, e cada controle tem um lugar real. Alterar um componente exige atualizar antes o exemplo na galeria; um recurso novo chega como exemplo, lugar real e teste. A documentação não se separa da implementação e a revisão tem um único ponto de comparação.