/* Ponte entre o Bootstrap 5.2.2 compilado e os tokens do design system
   (Identidade Visual §6.4). Escrita à mão, versionada.

   Carrega DEPOIS do `bootstrap.min.css`, nos dois shells — `templates/base.html`
   e `templates/base_error.html`. Isso não é preferência de organização: todo
   nome aqui empata em especificidade com a declaração do Bootstrap, e quem
   vence é quem vem depois. Declarada antes, esta folha não faz absolutamente
   nada — sem erro, sem warning, sem 404. A cor simplesmente continua azul.
   É por isso que cada item deste arquivo termina numa asserção de VALOR
   COMPUTADO em `tests/e2e/test_visual_identity.py`: a ordem dos `<link>` é
   evidência, o valor computado é o fato.

   Separada do `tokens.css` porque as duas fazem coisas diferentes: lá moram os
   TOKENS, aqui mora a tradução deles para o vocabulário de outra biblioteca.
   Nenhum valor nasce neste arquivo — cor nova nasce no design system.

   O Bootstrap deste projeto não lê a maioria das variáveis globais: as cores dos
   componentes foram fixadas na compilação. Medido no `.min.css`, `--bs-primary`,
   `--bs-danger` e `--bs-warning` têm ZERO leituras em tempo de execução, e por
   isso não aparecem aqui — declará-las prometeria uma troca de cor que nunca
   acontece. Daí as três camadas abaixo:

     1. variáveis globais que o Bootstrap realmente lê;
     2. variáveis próprias de cada componente, sobrescritas por seletor;
     3. propriedade direta, onde o Bootstrap escreveu valor literal.

   Escopo: só os componentes que o sistema usa de fato. Não vale recompilar o
   Bootstrap a partir do Sass para um legado com data para sair. */

/* ─── Camada 1 — as variáveis globais que o Bootstrap lê ──────────────────────
   Todas declaradas pelo Bootstrap no próprio `:root`, com a mesma
   especificidade deste bloco. */
:root {
  --bs-font-sans-serif: var(--font-sans);
  --bs-font-monospace: var(--font-mono);
  --bs-body-bg: var(--surface-app);
  --bs-body-color: var(--text-primary);
  --bs-border-color: var(--border-default);
  --bs-border-radius: var(--radius-md);
  --bs-link-color: var(--text-link);
  /* O hover sai do verde e vai para o preto, de propósito. `--text-link` é
     `--color-primary-800` e o hover era `--color-primary-900`: os dois verdes
     se separam por apenas 1,77:1, ou seja, o estado existia e não se via.
     Contra `--text-primary` a separação vai a 2,68:1 e a cor de chegada sobe de
     8,05:1 para 12,21:1 sobre a página.

     Vale para TODO link, e não só para o `.btn-link`: um link e um botão com
     cara de link reagindo de formas diferentes seria a inconsistência que esta
     folha existe para não criar. */
  --bs-link-hover-color: var(--text-primary);

  /* Os gêmeos `-rgb`. Várias cores do Bootstrap vêm em par, e é o SEGUNDO nome
     que alimenta os utilitários `.bg-*`, `.text-*` e `.border-*`
     (`rgba(var(--bs-primary-rgb), var(--bs-bg-opacity))`). Sobrescrever só o de
     cima deixa os dois discordando: `.bg-success` continua pintando o
     verde-garrafa do Bootstrap ao lado de um botão verde da marca, e o sintoma
     não aponta para este arquivo.

     O CSS não extrai os componentes de um hex, então o valor vai LITERAL — a
     primeira das duas exceções à regra de "nenhuma cor literal" deste arquivo.
     Cada linha diz de que token deriva, e há teste guardando cada par
     (`tests/integration/test_design_tokens.py`). */
  --bs-body-bg-rgb: 246, 246, 246; /* --color-neutral-50 */
  --bs-primary-rgb: 157, 193, 27; /* --color-primary-500 */
  /* Sucesso É o verde da marca (§3.2): não existe cor de sucesso separada. Sem
     este gêmeo, `.bg-success` e `.text-success` seguem no `#198754`, uma cor que
     não está em nenhuma escala do projeto. */
  --bs-success-rgb: 157, 193, 27; /* --color-primary-500 */
  --bs-danger-rgb: 180, 35, 24; /* --color-danger-600 */
  --bs-warning-rgb: 255, 193, 7; /* --color-warning-500 */
  /* O gêmeo de `--bs-body-color`, acima. Só o `.text-body` o lê, e nenhum
     template usa essa classe hoje — é exatamente a armadilha descrita acima,
     esperando: o primeiro `.text-body` escrito depois disto cairia no `#212529`
     do Bootstrap ao lado de um `body` em `#303030`. */
  --bs-body-color-rgb: 48, 48, 48; /* --color-neutral-900 */
  /* Os três cinzas que sobraram do tema do Bootstrap. `.bg-light` é o fundo
     INTEIRO das quatro páginas de erro, e ficava em `#f8f9fa` ao lado de um
     `--surface-app` de `#f6f6f6`; `.text-secondary` é o "404" gigante; e
     `.text-dark` aparece em duas telas de pedido.

     Fora de escopo, e nomeados aqui para não serem redescobertos: o
     `.text-muted` (12 arquivos) não tem gêmeo — o Bootstrap fixou `#6c757d`
     literal na regra —, e cabe num ticket próprio. */
  --bs-light-rgb: 246, 246, 246; /* --color-neutral-50 */
  --bs-secondary-rgb: 117, 117, 117; /* --color-neutral-500 */
  --bs-dark-rgb: 48, 48, 48; /* --color-neutral-900 */
}

/* ─── Camada 2 — botões (Componentes §1) ──────────────────────────────────────
   Nove classes legadas em uso, seis variantes no design system. O mapeamento
   está registrado na subseção `Decisões` da §1; o resumo é que o legado não tem
   critério de qual botão é a ação primária da tela (inconsistência C1), e a
   ponte não pode inventar um. Ela reproduz o papel que cada classe já exerce.

   Cada variante sobrescreve TODAS as suas variáveis, não só as três de repouso.
   Uma esquecida deixa o azul aparecer só naquele estado, e nenhuma tela
   reporta isso. */

/* Desabilitado e foco valem para toda variante, então ficam numa regra só. */
.btn {
  /* §1: `opacity: 0.5`, sem troca de cor de fundo. O Bootstrap usa `.65` E
     troca as cores, o que num botão vazado dava um desabilitado de outra matiz
     ao lado do habilitado. */
  --bs-btn-disabled-opacity: 0.5;
  /* Desfaz o halo de foco do Bootstrap na origem. Ele é derivado de
     `--bs-btn-focus-shadow-rgb`, literal por variante, e reaparece em regras de
     especificidade maior que a deste arquivo (`.btn:first-child:active:focus-visible`).
     Neutralizar a variável atinge todas elas de uma vez. */
  --bs-btn-focus-box-shadow: none;
}

.btn:focus-visible {
  /* §1: anel de 2px com afastamento de 2px, nunca `outline: none` sem
     substituto. O afastamento não é enfeite: `--focus-ring` sobre o botão
     vermelho mede 2,01:1, e é o vão que põe o anel contra o fundo da página,
     onde mede 12,21:1. */
  outline: var(--focus-ring-width) solid var(--focus-ring);
  outline-offset: var(--focus-ring-offset);
  box-shadow: none;
}

/* PREENCHIDO VERDE — a ação que a tela existe para fazer, e o sucesso, que é
   o mesmo verde (§3.2: não existe cor de sucesso separada).

   A borda é o MESMO verde do preenchimento, e acompanha o estado. A aresta um
   degrau mais escura, que esta ponte usava antes, ficava cada vez mais
   aparente conforme o botão clareava — no active ela chegava a 3,12:1 contra o
   próprio preenchimento e lia como anel, não como aresta.

   Consequência assumida: a fronteira do botão contra a página cai para
   1,93:1. Quem identifica o controle passa a ser o rótulo, em 6,33:1, e não a
   forma — leitura que a WCAG admite para um controle sem contorno próprio.

   Hover e active CLAREIAM: o verde é claro e leva texto escuro, então o estado
   se move na direção que preserva o contraste. Descendo a escala dava 4,45:1 e
   3,19:1; subindo dá 8,93:1 e 9,94:1. */
.btn-primary,
.btn-success {
  --bs-btn-color: var(--text-on-primary);
  --bs-btn-bg: var(--action-primary);
  --bs-btn-border-color: var(--action-primary);
  --bs-btn-hover-color: var(--text-on-primary);
  --bs-btn-hover-bg: var(--action-primary-hover);
  --bs-btn-hover-border-color: var(--action-primary-hover);
  --bs-btn-active-color: var(--text-on-primary);
  --bs-btn-active-bg: var(--action-primary-active);
  --bs-btn-active-border-color: var(--action-primary-active);
  --bs-btn-disabled-color: var(--text-on-primary);
  --bs-btn-disabled-bg: var(--action-primary);
  --bs-btn-disabled-border-color: var(--action-primary);
}

/* VAZADO VERDE — o mesmo verde do preenchido, na forma vazada.

   O texto é PRETO, e não verde, porque o verde da marca não sobrevive como
   texto: `#9DC11B` sobre branco mede 2,08:1. Nem o degrau 700 passa (4,14:1).
   Com a cor no contorno e o preto no rótulo, o texto lê em 13,20:1.

   A BORDA É UM DEGRAU MAIS ESCURA que o preenchido, ao contrário do
   `.btn-primary` — e a diferença é de função, não descuido. Num botão
   preenchido a fronteira é o preenchimento, e o rótulo dentro identifica o
   controle; num vazado não há preenchimento, então **a borda é a forma** e
   cumpre sozinha os 3:1 da WCAG 1.4.11. O verde da marca dava 2,08:1 contra o
   branco — menos que os 4,50:1 do azul do Bootstrap que ele substituiu, e 21
   destes botões são só-ícone, sem rótulo nenhum para compensar. O degrau 700 dá
   4,14:1; o 600 não serve, para por 2,97:1. Decisão de 27/09/2026 (§3.2).

   O vazado VERMELHO é a exceção das duas regras: o vermelho é escuro o bastante
   para ser o próprio texto (6,08:1) e a própria borda (6,57:1), então ele segue
   o `destructive-outline` da §1 e carrega a cor nas duas pontas.

   Hover e active tingem o fundo com a própria matiz, lendo a escala direto. A
   escada semântica não serve aqui: `--status-success-surface` e
   `--status-success-muted` são AMBOS `--color-primary-100`, então o par não
   oferece dois degraus. Ler a escala também evita amarrar o estado de interação
   de um botão à família de STATUS — se um dia sucesso deixar de ser o verde da
   marca, este botão não se move junto. A borda continua acima de 3:1 sobre os
   dois fundos: 3,98:1 no hover e 3,78:1 no active. */
.btn-outline-primary,
.btn-outline-success {
  --bs-btn-color: var(--text-primary);
  --bs-btn-bg: transparent;
  --bs-btn-border-color: var(--border-on-primary);
  --bs-btn-hover-color: var(--text-primary);
  --bs-btn-hover-bg: var(--color-primary-50);
  --bs-btn-hover-border-color: var(--border-on-primary);
  --bs-btn-active-color: var(--text-primary);
  --bs-btn-active-bg: var(--color-primary-100);
  --bs-btn-active-border-color: var(--border-on-primary);
  --bs-btn-disabled-color: var(--text-primary);
  --bs-btn-disabled-bg: transparent;
  --bs-btn-disabled-border-color: var(--border-on-primary);
}

/* AMARELO — preenchido e vazado, com o amarelo da marca e fonte preta.

   O design system não tinha variante de aviso: ela nasce aqui, para as 6 telas
   legadas que a pedem, e morre quando elas migrarem. O amarelo `#FFC107` é
   ainda mais impossível como texto que o verde — 1,63:1 sobre branco —, então
   o preto carrega a leitura nos dois: 8,10:1 sobre o preenchido e 13,20:1 no
   vazado.

   Pela mesma razão do verde, o VAZADO leva a borda um degrau mais escura
   (`--border-on-warning`, 3,93:1 sobre branco): sem preenchimento, a borda é a
   forma. O amarelo da marca dava 1,51:1 e já reprovava antes deste ticket. O
   preenchido mantém a borda da própria cor — nele a fronteira é o
   preenchimento.

   `btn-warning` não tem nenhum uso nos templates hoje. Entra para o par ficar
   completo e para a tela que precisar dele não inventar uma sétima cor. */
.btn-warning {
  --bs-btn-color: var(--text-on-warning);
  --bs-btn-bg: var(--status-warning-solid);
  --bs-btn-border-color: var(--status-warning-solid);
  --bs-btn-hover-color: var(--text-on-warning);
  --bs-btn-hover-bg: var(--color-warning-300);
  --bs-btn-hover-border-color: var(--color-warning-300);
  /* A escada do preenchido é 500 → 300 → 100, clareando, espelhando o verde.
     Os dois degraus são lidos da escala direto, e não de `--status-warning-muted`:
     desde 3/10/2026 esse token é o 100, o mesmo degrau que as outras quatro
     famílias usam, e apontar o hover para ele colapsaria hover e active na
     mesma cor. Ler a escala é o que a camada de tradução faz quando não há
     token de papel — não existe `--action-warning-*` —, como a ponte do shadcn
     já faz. */
  --bs-btn-active-color: var(--text-on-warning);
  --bs-btn-active-bg: var(--color-warning-100);
  --bs-btn-active-border-color: var(--color-warning-100);
  --bs-btn-disabled-color: var(--text-on-warning);
  --bs-btn-disabled-bg: var(--status-warning-solid);
  --bs-btn-disabled-border-color: var(--status-warning-solid);
}

.btn-outline-warning {
  --bs-btn-color: var(--text-primary);
  --bs-btn-bg: transparent;
  --bs-btn-border-color: var(--border-on-warning);
  --bs-btn-hover-color: var(--text-primary);
  --bs-btn-hover-bg: var(--status-warning-surface);
  --bs-btn-hover-border-color: var(--border-on-warning);
  --bs-btn-active-color: var(--text-primary);
  --bs-btn-active-bg: var(--status-warning-muted);
  --bs-btn-active-border-color: var(--border-on-warning);
  --bs-btn-disabled-color: var(--text-primary);
  --bs-btn-disabled-bg: transparent;
  --bs-btn-disabled-border-color: var(--border-on-warning);
}

/* NEUTRO — a ação de apoio, que não tem cor própria. As duas classes do legado
   deixam de ser idênticas e passam a se distinguir pela forma, como todos os
   outros pares: uma preenchida, a outra vazada.

   O design system não tem token de AÇÃO neutra — só de borda e de superfície —,
   então o preenchido lê a escala direto, como o active do amarelo acima. O
   degrau 500 é quase exatamente o cinza que o `btn-secondary` do Bootstrap já
   tinha (`#6c757d`), então o "Fechar" de modal continua com o peso visual de
   sempre, só que na escala do projeto.

   Preenchido escuro leva texto branco, então o estado ESCURECE — a direção
   oposta à do verde e do amarelo, pela mesma razão: preservar o contraste com
   o texto da própria variante. */
.btn-secondary {
  --bs-btn-color: var(--text-on-inverse);
  --bs-btn-bg: var(--color-neutral-500);
  --bs-btn-border-color: var(--color-neutral-500);
  --bs-btn-hover-color: var(--text-on-inverse);
  --bs-btn-hover-bg: var(--color-neutral-600);
  --bs-btn-hover-border-color: var(--color-neutral-600);
  --bs-btn-active-color: var(--text-on-inverse);
  --bs-btn-active-bg: var(--color-neutral-900);
  --bs-btn-active-border-color: var(--color-neutral-900);
  --bs-btn-disabled-color: var(--text-on-inverse);
  --bs-btn-disabled-bg: var(--color-neutral-500);
  --bs-btn-disabled-border-color: var(--color-neutral-500);
}

/* Vazado neutro. `--border-strong` (4,26:1) é a única neutra acima do mínimo de
   3:1 da WCAG 1.4.11 — a decorativa `--border-default` mede 1,24:1 contra a
   página e não é aresta.

   Desde 27/09/2026 TODOS os vazados cumprem os 3:1 sozinhos: este em 4,26:1, o
   verde em 4,14:1, o amarelo em 3,93:1 e o vermelho em 6,57:1. Num vazado a
   borda é a forma. */
.btn-outline-secondary {
  --bs-btn-color: var(--text-primary);
  --bs-btn-bg: transparent;
  --bs-btn-border-color: var(--border-strong);
  --bs-btn-hover-color: var(--text-primary);
  --bs-btn-hover-bg: var(--surface-hover);
  --bs-btn-hover-border-color: var(--border-hover);
  --bs-btn-active-color: var(--text-primary);
  --bs-btn-active-bg: var(--surface-sunken);
  --bs-btn-active-border-color: var(--border-hover);
  --bs-btn-disabled-color: var(--text-primary);
  --bs-btn-disabled-bg: transparent;
  --bs-btn-disabled-border-color: var(--border-strong);
}

/* destructive — confirma perda de dado. O vermelho é escuro e leva texto
   branco, então o estado ESCURECE, que é a direção que o token já tinha.

   A aresta continua sendo `--border-on-danger`, um degrau mais escura, e NÃO
   acompanhou a mudança do verde: contra a página ela mede 10,65:1 e nunca foi
   o anel que incomodava. Alinhar os dois é decisão em aberto. */
.btn-danger {
  --bs-btn-color: var(--text-on-danger);
  --bs-btn-bg: var(--action-danger);
  --bs-btn-border-color: var(--border-on-danger);
  --bs-btn-hover-color: var(--text-on-danger);
  --bs-btn-hover-bg: var(--action-danger-hover);
  --bs-btn-hover-border-color: var(--border-on-danger);
  --bs-btn-active-color: var(--text-on-danger);
  --bs-btn-active-bg: var(--action-danger-active);
  --bs-btn-active-border-color: var(--border-on-danger);
  --bs-btn-disabled-color: var(--text-on-danger);
  --bs-btn-disabled-bg: var(--action-danger);
  --bs-btn-disabled-border-color: var(--border-on-danger);
}

/* destructive-outline — descarta trabalho sem destruir registro. Contorno
   vermelho, sem preenchimento: é a única das nove cuja forma legada já era a
   que o design system pede, e a única vazada que carrega a cor no texto,
   porque o vermelho lê (6,08:1). */
.btn-outline-danger {
  --bs-btn-color: var(--action-danger);
  --bs-btn-bg: transparent;
  --bs-btn-border-color: var(--action-danger);
  --bs-btn-hover-color: var(--action-danger);
  --bs-btn-hover-bg: var(--status-danger-surface);
  --bs-btn-hover-border-color: var(--action-danger);
  --bs-btn-active-color: var(--action-danger);
  --bs-btn-active-bg: var(--status-danger-muted);
  --bs-btn-active-border-color: var(--action-danger);
  --bs-btn-disabled-color: var(--action-danger);
  --bs-btn-disabled-bg: transparent;
  --bs-btn-disabled-border-color: var(--action-danger);
}

/* link — ação que parece navegação. A cor de repouso vem de graça da camada 1;
   só o desabilitado precisa de ajuste, porque lá o Bootstrap fixou um cinza
   literal, contra a regra de "opacidade sem troca de cor" da §1.

   O hover mora na camada 1, em `--bs-link-hover-color`: ele saiu de
   `--color-primary-900` para `--text-primary`. Os dois verdes se separavam por
   apenas 1,77:1 — o hover existia e não se via. Contra o preto a separação
   dobra, para 2,68:1, e a cor de chegada sobe de 8,05:1 para 12,21:1. */
.btn-link {
  --bs-btn-disabled-color: var(--text-link);
}

/* ─── Camada 2 — paginação ────────────────────────────────────────────────────
   `--bs-pagination-color` e `-hover-color` já vêm da camada 1, pelos nomes de
   link. O que sobra é a página atual, azul literal, e o halo de foco — um
   segundo literal, fácil de esquecer porque só aparece no foco de teclado, que
   é exatamente quem depende dele. */
.pagination {
  --bs-pagination-active-color: var(--text-on-primary);
  --bs-pagination-active-bg: var(--action-primary);
  /* A mesma regra do botão preenchido: a borda é a própria cor. A página atual
     é uma pílula verde com o número dentro, e é o número que a identifica. */
  --bs-pagination-active-border-color: var(--action-primary);
  --bs-pagination-focus-box-shadow: none;
}

.pagination .page-link:focus-visible {
  outline: var(--focus-ring-width) solid var(--focus-ring);
  outline-offset: var(--focus-ring-offset);
  box-shadow: none;
}

/* ─── Camada 2 — alertas (Componentes §20) ────────────────────────────────────
   Superfície, borda e texto saem das variáveis próprias do componente; a BARRA
   DE 4px À ESQUERDA vai por propriedade direta, porque o Bootstrap não tem esse
   conceito.

   A ordem dentro de cada regra importa: `.alert` monta a borda com o shorthand
   `border: var(--bs-alert-border)`, e a longhand `border-left` tem de vir DEPOIS
   na folha, senão o shorthand a apaga. Como este arquivo carrega depois do
   Bootstrap, a longhand ganha — e o teste que mede as outras três bordas em 1px
   é o que prova que a ordem se manteve.

   Sem ícone, por decisão de 24/09/2026: numa flash message o texto já é a
   própria mensagem, e transformar o `.alert` em flex para mascarar um SVG por
   variante é estrutura que a migração React descarta. Quem carrega a severidade
   além da cor é a barra (forma e posição) e o próprio texto.

   As classes vêm de três origens: o nível da mensagem do Django, marcação fixa
   em template, e o `alert-' + type` montado em JS na tela de permissões.

   Limite conhecido: num alerta que também carrega o utilitário `.border`, a
   barra some. O utilitário é `!important` nos quatro lados e vence a longhand
   daqui. Subir a barra para `!important` seria a ponte passar por cima de um
   utilitário que o template aplicou de propósito, por causa de uma regra que o
   design system chama de reforço, não de significado — então ela perde, e é o
   certo. Acontece hoje em um único lugar, o painel de ajuda do dashboard. */
.alert-success {
  --bs-alert-color: var(--status-success-fg);
  --bs-alert-bg: var(--status-success-surface);
  --bs-alert-border-color: var(--status-success-border);

  border-left: 4px solid var(--status-success-solid);
}

.alert-warning {
  --bs-alert-color: var(--status-warning-fg);
  --bs-alert-bg: var(--status-warning-surface);
  --bs-alert-border-color: var(--status-warning-border);

  border-left: 4px solid var(--status-warning-solid);
}

/* Onde `messages.error()` passa a cair, pelo `MESSAGE_TAGS` do settings. Antes
   ele produzia `alert-error`, classe que não existe no Bootstrap: as 40
   mensagens de erro do sistema renderizavam sem fundo, sem borda e sem cor
   nenhuma. */
.alert-danger {
  --bs-alert-color: var(--status-danger-fg);
  --bs-alert-bg: var(--status-danger-surface);
  --bs-alert-border-color: var(--status-danger-border);

  border-left: 4px solid var(--status-danger-solid);
}

/* Onde `messages.debug()` cai. `alert-debug` também não existe no Bootstrap, e o
   informativo do design system é neutro/cinza — que é exatamente o que uma
   mensagem de depuração deve parecer. */
.alert-info {
  --bs-alert-color: var(--status-info-fg);
  --bs-alert-bg: var(--status-info-surface);
  --bs-alert-border-color: var(--status-info-border);

  border-left: 4px solid var(--status-info-solid);
}

/* O único endereço plausível, no vocabulário do Bootstrap, para a variante
   `progress` do design system — é o que evita que ela fique sem porta no
   legado. */
.alert-primary {
  --bs-alert-color: var(--status-progress-fg);
  --bs-alert-bg: var(--status-progress-surface);
  --bs-alert-border-color: var(--status-progress-border);

  border-left: 4px solid var(--status-progress-solid);
}

/* `secondary` e `light` são marcação, não nível de mensagem. As duas caem no
   informativo, que o design system define como neutro. */
.alert-secondary,
.alert-light {
  --bs-alert-color: var(--status-info-fg);
  --bs-alert-bg: var(--status-info-surface);
  --bs-alert-border-color: var(--status-info-border);

  border-left: 4px solid var(--status-info-solid);
}

/* ─── Camada 3 — badges (Componentes §15) ─────────────────────────────────────
   Esta é a armadilha: `.text-bg-*` NÃO lê os gêmeos `-rgb`. Em 5.2.2 a regra é
   `background-color: RGBA(13,110,253,var(--bs-bg-opacity,1))!important` com
   `color:#fff!important` — valor literal E `!important`. Sobrescrever por
   variável não faz nada; sobrescrever sem `!important` também não. Só empata
   quem escreve propriedade direta com `!important` e carrega depois.

   Estes são status de PAGAMENTO e de ativo/inativo. Os cinco literais de status
   de ENTREGA vivem em `extra/base.css` e são outra coisa. */
/* O raio. O Bootstrap fixa `--bs-badge-border-radius: 0.375rem` no `.badge`, e
   a §15 pede `--radius-full` — pílula. É variável própria do componente, então
   uma linha basta: não havia razão técnica para o legado continuar quadrado. */
.badge {
  --bs-badge-border-radius: var(--radius-full);
}

.text-bg-success {
  background-color: var(--status-success-solid) !important;
  color: var(--status-success-on-solid) !important;
}

.text-bg-danger {
  background-color: var(--status-danger-solid) !important;
  color: var(--status-danger-on-solid) !important;
}

.text-bg-warning {
  background-color: var(--status-warning-solid) !important;
  color: var(--status-warning-on-solid) !important;
}

/* "Aberto" — um pagamento em curso, que é a variante `progress`. */
.text-bg-primary {
  background-color: var(--status-progress-solid) !important;
  color: var(--status-progress-on-solid) !important;
}

/* "Sem definição", "Inativa", "Renegociada" — ausência de estado, que é o
   informativo neutro. */
.text-bg-secondary {
  background-color: var(--status-info-solid) !important;
  color: var(--status-info-on-solid) !important;
}

.text-bg-dark {
  background-color: var(--surface-inverse) !important;
  color: var(--text-on-inverse) !important;
}

/* `.badge` combinada com o utilitário `.bg-*` é outro caso: ali o fundo já vem
   certo pelo gêmeo `-rgb` da camada 1. O que sobra errado é o texto, que o
   `.badge` fixa em branco — sobre o verde da marca isso mede 2,08:1. */
.badge.bg-success {
  --bs-badge-color: var(--status-success-on-solid);
}

.badge.bg-danger {
  --bs-badge-color: var(--status-danger-on-solid);
}

/* ─── Camada 3 — controles de formulário ──────────────────────────────────────
   Aqui o Bootstrap não deixou variável nenhuma: `border-color:#86b7fe` e
   `box-shadow:0 0 0 .25rem rgba(13,110,253,.25)` estão literais na folha. O
   `box-shadow` precisa ser desfeito explicitamente, senão o halo azul aparece
   junto com o anel novo.

   `.form-check-input:focus` entra junto de propósito: é o mesmo literal azul, e
   deixá-lo de fora produziria um checkbox verde com foco azul. */
.form-control:focus,
.form-select:focus,
.form-check-input:focus {
  border-color: var(--border-focus);
  outline: var(--focus-ring-width) solid var(--focus-ring);
  outline-offset: var(--focus-ring-offset);
  box-shadow: none;
}

/* Aqui a borda É um degrau mais escura, e a diferença para o botão não é
   inconsistência: um botão tem o rótulo DENTRO, e é o rótulo que identifica o
   controle quando a aresta é fraca. Um checkbox não tem nada dentro — a caixa é
   o controle inteiro, então o limite dela precisa cumprir os 3:1 da WCAG 1.4.11
   sozinho. O verde da marca contra o branco mede 2,08:1; o degrau 700, 4,14:1. */
.form-check-input:checked {
  background-color: var(--action-primary);
  border-color: var(--border-on-primary);
}

/* A marca dentro do controle marcado — tique do checkbox, ponto do radio e
   botão do switch — é um SVG em data URI, e `var()` NÃO resolve dentro de
   `url("data:…")`. Então o hex vai literal e percent-encoded: a segunda e última
   exceção deste arquivo à regra de "nenhuma cor literal", pela mesma razão dos
   gêmeos `-rgb` — a sintaxe não aceita variável.

   `%23303030` é `--color-neutral-900`, que é o valor tanto de `--text-on-primary`
   quanto de `--focus-ring`; um único valor serve aos dois papéis. O Bootstrap
   desenha essas marcas em branco, o que sobre o verde da marca mede 2,08:1 —
   PIOR que os 4,50:1 que tinha sobre o azul. Em `--text-on-primary` dá 6,33:1.

   Há teste conferindo que este hex continua igual ao token
   (`tests/integration/test_design_tokens.py`). */
.form-check-input:checked[type="checkbox"] {
  background-image: url("data:image/svg+xml,%3csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 20 20'%3e%3cpath fill='none' stroke='%23303030' stroke-linecap='round' stroke-linejoin='round' stroke-width='3' d='m6 10 3 3 6-6'/%3e%3c/svg%3e");
}

.form-check-input:checked[type="radio"] {
  background-image: url("data:image/svg+xml,%3csvg xmlns='http://www.w3.org/2000/svg' viewBox='-4 -4 8 8'%3e%3ccircle r='2' fill='%23303030'/%3e%3c/svg%3e");
}

/* O botão do switch, nos dois estados que o desenham. O azul só aparecia em
   FOCADO E DESMARCADO — a regra `:checked` do Bootstrap vem depois, com a mesma
   especificidade, e vence. Daí o `:not(:checked)`: sem ele esta regra roubaria o
   botão do switch marcado. */
.form-switch .form-check-input:focus:not(:checked) {
  background-image: url("data:image/svg+xml,%3csvg xmlns='http://www.w3.org/2000/svg' viewBox='-4 -4 8 8'%3e%3ccircle r='3' fill='%23303030'/%3e%3c/svg%3e");
}

.form-switch .form-check-input:checked {
  background-image: url("data:image/svg+xml,%3csvg xmlns='http://www.w3.org/2000/svg' viewBox='-4 -4 8 8'%3e%3ccircle r='3' fill='%23303030'/%3e%3c/svg%3e");
}

/* ─── A quebra de linha do tooltip (sem token) ────────────────────────────────
   Sem número de camada de propósito: as três camadas do cabeçalho são
   MECANISMOS de tradução de token, e este bloco não traduz token nenhum — é
   propriedade direta, como a Camada 3, mas desfazendo uma decisão de layout do
   Bootstrap em vez de uma cor literal. Chamá-lo de "Camada 4" prometeria um
   quarto mecanismo que o cabeçalho não descreve.

   Os quatro tooltips de auditoria do sistema (cancelamento e medidor de uma
   venda, troca de cliente de um orçamento, pagamento de uma fatura de
   comissão) mostram um campo por linha. Separavam os campos com
   `<br>---<br>` no próprio título, e por isso pediam `data-bs-html="true"` —
   que fazia o Bootstrap reinterpretar como marcação também o nome e o motivo
   DIGITADOS POR USUÁRIO. Sem o flag, o Bootstrap escreve o título em
   `textContent`, e aí o `\n` que o `{% audit_tooltip_text %}` coloca entre os
   campos só vira quebra visível se o CSS pedir. É esta declaração que permite
   proibir marcação no texto; sem ela, as quatro telas viram uma linha corrida.

   O `text-align` entra junto porque o padrão do Bootstrap é `center`, e três ou
   quatro linhas centralizadas ficam irregulares — cada uma começando num ponto
   diferente, num bloco que se lê como lista de campos.

   A aparência de tooltip do design system (§22 de Componentes — fundo
   `--surface-inverse`, `--font-size-xs`, `--radius-md`) NÃO está aqui: a ponte
   não tem camada de tooltip, e criá-la é redesenho, não conserto de escape. */
.tooltip-inner {
  white-space: pre-line;
  text-align: left;
}