Começar
Aparência

Vale na hora e fica lembrada neste navegador.

Decisões

ORG-0023 — Design system da Hibex

Contexto

As aplicações da Hibex precisam parecer da mesma família, nos dois temas, com os mesmos componentes e estados. Uma biblioteca copiada e editada localmente diverge em semanas.

Decisão

  1. O design system chega como cópia em vendor/hibex/, trazida por script do mantenedor e nunca editada à mão (hook + manifesto).
  2. Cada aplicação tem uma família de cor exclusiva dentro do produto; o build entrega só a folha, o script, as fontes, os ícones, a marca-mãe e a família dela.
  3. O verificador roda na CI e quebra o build com erro.
  4. O que falta na biblioteca vira hibex-pendente: NNNN <assunto> no código e um pedido em docs/design-system/pedidos.md; nunca uma peça local que imita a biblioteca.
  5. Atualizar a cópia é change, lendo o CHANGELOG.md entre as versões.
  6. Um mapa de estados por produto; aviso de ambiente em toda publicação fora da produção, nunca nas capturas.
  7. As famílias de cor de cada aplicação ficam numa ADR da stack (a ADR-0005 pré-escrita).

Alternativas consideradas

AlternativaPor que não
Pacote de dependência (npm) com a bibliotecaPor que não: a stack pode não usar Node no runtime; a cópia versionada serve qualquer tecnologia
Liberdade visual por aplicaçãoPor que não: as aplicações deixam de parecer da mesma família

Consequências

  • A interface nasce no padrão já na fundação (change de aparência), antes da primeira tela de produto.
  • O que a biblioteca não tem demora uma versão dela para chegar.

Mais

O detalhe está na documentação da arquitetura.