Tokens

9. Versionamento

seed-tokens.md v1.23 · §09seção 17 de 1709-versionamento.md · MD5 c76265cd

Versão	Data	Mudança
1.23	2026-08-26	A CAMADA 3 FECHA (SG1 a ZERO FAIL) e a COLISÃO DE ALTURA, aberta em 2026-08-15, é RECONCILIADA. Para quem lê sem ter visto a conversa: a entrada v1.22 desta mesma tabela terminava com uma lista chamada "o que fica para a sessão principal" — decidir o par dark do `divider-strong`, marcar `switch-off-bg`/`slider-track` como medição pendente, fixar a curva do `ease-out`, isentar o `input-affix` e abrir a pendência do estado OFF no tema claro. Esta versão fecha a lista inteira, e vale dizer por quê: lista de pendência que ninguém fecha vira lista de desculpa, e a única prova de que ela servia é ela acabar. Todas as seis decisões vieram do Rafael em 2026-08-26, no gate das nove peças da Onda 2. ① O SWITCH — e a medição achou três coisas, não uma. Ele decidiu: "acredito que tem que conseguir um tom que atenda o piso. analise e decida". (a) O tom é cinza-500 `#788F9D` = 3,38:1, primeiro degrau da escala acima do piso — o cinza-400 ainda reprova, com 2,53. Zero cor nova (§14.1). (b) ⭐ Medir "3:1 sobre a página" era medir METADE do componente: o thumb é BRANCO, e branco sobre cinza-300 dá os mesmos 1,91 — o thumb sumia dentro do trilho, e a posição do thumb é o único canal que separa ON de OFF (K3: nunca "ON/OFF" escrito no trilho). Cinza-500 conserta os dois pares de uma vez. (c) ⭐⭐ No tema ESCURO quem reprovava era o estado LIGADO, não o desligado — thumb cinza-100 sobre o trilho ligado dá 2,25 — e ninguém tinha visto porque a cláusula só mandava medir o OFF. A saída não precisou de cor nova: "o que vai sobre a superfície de ação" já é par medido e canonizado (`--seed-text-on-action-primary`), e o thumb de um switch ligado é exatamente isso — 7,39:1. Nasce `--seed-switch-thumb-on`; no claro ele coincide com o thumb desligado, e isso é a regra colapsando, não duplicação. (d) Dois erros de NOME na mesma linha da spec, consertados junto: ela apontava para `--seed-action-primary-bg`, o token fantasma da FF-P2/FF-P3, e dizia "turquesa-400 sobre dark" quando `action-primary` escuro é `#66D1C2` = turquesa-300. ⭐ Spec que aponta para nome morto passa em toda guarda de valor, porque não há valor nenhum para conferir. ② O SLIDER tinha a mesma doença, e ela só apareceu porque o switch foi medido — cinza-300, os mesmos 1,91. Passa a cinza-500. ⚠ Mas aqui a saída é diferente, e a diferença importa: nenhum degrau atende os dois pares, porque o vazio precisa ficar longe do branco da página e longe do turquesa do preenchido, e o turquesa-600 mora no meio da escala (cinza-300 dá 2,40 contra o preenchido, cinza-500 dá 1,36). A decisão não foi escolher o menos pior; foi ver o que cada par carrega: o valor tem canal textual garantido pela própria spec ("valor corrente visível SEMPRE") e canal de forma no thumb de 24px com borda, então a divisão preenchido/vazio é o terceiro canal e fica decorativa declarada, com o número escrito (1,36 claro / 2,59 escuro) — mesmo tratamento de `card-border` e `divider-color`. Exigir 3:1 ali seria criar cláusula que o canon nunca teve, e cláusula nova é decisão dele. ③ E OS DOIS TINHAM O MESMO DEFEITO ESTRUTURAL, que era o que ele já havia apontado: `--seed-switch-off-bg` e `--seed-slider-track` eram declarados só no tema escuro e com escopo de elemento (`[data-theme="dark"] .seed-switch{…}`) — e como não existiam no gêmeo, no tema CLARO o `var()` não resolvia e o controle ficava sem fundo nenhum. Com o token no gêmeo, as duas regras de escopo somem e o defeito morre pela raiz. ⭐ Token declarado só num tema não é "tema faltando" — é um estado que não existe na metade do sistema. ④ A CURVA: ele mandou "teste os 2 e decida", e o teste devolveu uma resposta melhor que "escolha um". Resolvendo o bézier em 21 instantes de um movimento de 120 ms e convertendo para tempo — porque milissegundo é o que o olho pode ou não perceber, e "parecem diferentes no papel" não é medida de nada: `.2,.8,.4,1` e `.2,.7,.3,1` diferem no máximo 1,5% do percurso e 0,3 ms. A 60 Hz um quadro dura 16,7 ms, então a diferença é 1/56 de quadro e não existe em nenhum monitor — eram dois nomes para a mesma curva. Escolhida a de maior uso (3 artefatos contra 2), que também faz o conserto ser de 2 arquivos e não 3. ⭐⭐ E o mesmo teste respondeu a pergunta que ninguém tinha feito: `--seed-ease-out` deve existir, ou era apelido de `--seed-ease-productive`? Contra o productive a diferença é 36,8% e 24,9 ms — 83 vezes maior que a diferença entre as candidatas. São curvas diferentes de verdade, então o token merece existir. Sem o número, isso se responderia por gosto. ⑤ O DIVISOR FORTE: a v1.22 recusou emiti-lo, com um argumento bom — e o que mudou não foi a opinião, foi a medição. A recusa se apoiava no "1,91 light" da spec. ⚠⚠ Esse número não existe: medidas as cinco superfícies do tema claro contra o `border-default`, nenhuma dá 1,91 (page/raised/overlay = 1,49; subtle 1,37; sunken 1,23). O número foi transplantado — 1,91 é o que o `border-subtle` escuro dá sobre a página escura. ⭐ O número estava certo em algum lugar do arquivo; só estava grudado no token errado. E o irmão só batia porque foi medido contra outro fundo: o "1,75 dark" do `divider-color` não sai da `surface-page` (1,91) — sai da `surface-subtle`. ⭐⭐ Régua: contraste sem fundo declarado não é um número, é uma família de números — e foi variando o fundo, uma condição por vez (§14.5), que os três valores se explicaram. Sem o 1,91, o cinza-600 do consumidor vivo se revela dialeto local e vale a regra simétrica do irmão: border-default nos dois temas (1,49 / 2,84, decorativo declarado). ⑥ O `--seed-input-w-md` NÃO foi emitido, e a saída certa não era nenhuma das duas que a SG1 oferece. O nome aparecia uma vez, num exemplo de HTML da §2.5: `style="max-width:var(--seed-input-w-md,320px)"` — um `var()` apontando para um token que nunca existiu, que é o mesmo defeito do switch. ⭐ Exemplo de código num canônico é código que alguém copia; citar nele um `var()` que não resolve não é citação, é ensinar o defeito. O exemplo passou a escrever `320px` direto e o nome saiu do canônico. ⚠ E aí nasceu a 6ª classe de falso positivo da SG1: o comentário que EXPLICA a remoção cita o nome, e a guarda reprovou de novo — com razão, porque para ela nome no arquivo é nome no arquivo. Reescrever o comentário sem o nome faria a guarda passar e apagaria a lição, trapaça que a isenção do `--seed-tq-300` já proíbe. Isentado com o motivo escrito. As seis classes hoje: curinga · placeholder maiúsculo · classe BEM · contraexemplo documentado · nome de exemplo em diagrama · nome citado no registro da própria remoção. Todas dizem citar não é pedir. ⑦ A ALTURA DE CONTROLE — ele mandou "reconcilie para todos seguirem o padrão". De 2026-08-15 a 2026-08-26 o DS teve três réguas com dois números: 32/40/48 em `--seed-control-` (v1.14, genérica, herdada do Fluent) contra 32/44/52 em `--seed-button-height-` e `--seed-field-height-` (fixados por escrito na §1.6 e na §2.5, com a decisão explícita "md = 44px (não 40px)"). O `sm` já coincidia. ⚠ O desempate não foi por gosto: medido, NENHUM artefato do acervo consome `--seed-control-`** — os três consumidores são a spec, a guarda de paridade e o gêmeo. A régua genérica era a de papel; vence quem tem spec. ⚠ E o argumento certo para o 44 não é o SC 2.5.8, que pede 24×24 (AA) e que 40 também cumpriria: o 44 é fundamento próprio do DS, mais generoso que a norma — e é por ser decisão nossa que ele precisava ser reconciliado em vez de deduzido de fora. O preset compacto (28/32/40) não muda: é densidade para tela de dado com mouse, e fica abaixo do alvo de toque de propósito. PLACARES. `SG1`: 140 PASS · 7 FAIL · 6 [isento] → 147 PASS · 0 FAIL · 7 [isento] — a camada 3 não tem mais nenhum nome que o canon cite e o gêmeo não defina. `paridade-tokens.py`: 103 → 110 PASS · 0 FAIL. ⚠ E esta é a primeira leva que NÃO é adição pura — as v1.21 e v1.22 podiam se gabar disso; esta muda dois valores, e o G1 acusou, exigindo supersede declarado (`SUPERSEDES_V123_ROOT`). Declarar é o preço de mudar valor, e o preço é barato. `:root` 323 → 330 (+7), dark 129 → 135 (+6). ⭐ E a linha `info:` do G6, que desde a v1.22 imprimia "COLISÃO DECLARADA de altura" a cada execução, passa a imprimir "RÉGUA ÚNICA desde a v1.23: md=44px · lg=52px nos três grupos" — e continua imprimindo os três pares, de modo que, se algum dia um deles derivar, a divergência aparece na mesma linha que hoje diz que não há nenhuma. O oposto de declarar um problema não é silêncio: é declarar que ele fechou. CONSUMIDORES. As duas bancadas que carregavam a curva divergente (`banco-feedback`, `banco-superficies`) foram atualizadas pelo `reinjeta-tokens.py` — ⭐ o build de quem não tem gerador fez sozinho o trabalho, e sem chance de errar um hex —, e o mesmo build apagou o dialeto do divisor (cinza-600 → `#4D606C`). ⚠ O que ele NÃO faz, por regra declarada, quase me custou as duas bancadas: ele não acrescenta token que o preview não consumia. Ao apagar as regras de escopo local do switch e do slider eu deixei `banco-formfield.html` consumindo `var()` de tokens que não estavam escritos nele — e o arquivo carrega cópia embutida, não lê o gêmeo. Os dez tokens foram acrescentados aos blocos `:root` e dark, e o reinjetor, rodado em seguida, confirmou 0 divergências contra o gêmeo. ⭐ Apagar dialeto local só é seguro depois de o canônico chegar ao arquivo — e num preview de cópia embutida, "chegar" quer dizer estar escrito nele.
1.22	2026-08-25	SEGUNDA LEVA DA CAMADA 3 — 19 tokens em seis grupos, e a classe da AD-P6 passa a ter INSTRUMENTO. Para quem lê sem ter visto a conversa: a v1.21 (mesmo dia) emitiu o primeiro grupo de componente dos gêmeos, o form-field, porque o `seed-componentes.md` descrevia 21 tokens `--seed-field-` que nenhum artefato podia consumir* — a spec citava, o gêmeo não definia. Esta entrada fecha a mesma classe para os grupos seguintes. O que mudou no método, e é o mais importante desta versão: a pergunta "quais grupos ainda faltam?" era respondida por `grep` e memória, e errou por quatro caminhos diferentes numa única tentativa — família escrita com `` (`--seed-field-` não é um token), família com posição genérica (`-N`), classe CSS em BEM lida como token (o `--` duplo de `.seed-btn--primary`) e contraexemplo documentado lido como pedido. Nasce então a guarda `06-validacao/guardas/guarda-spec-gemeo.py` (contrato SG1), que varre os `01-canonicos/.md` e reprova todo custom property que o canon nomeia* e o gêmeo `seed-tokens.css` não define, imprimindo nome, quem cita, quantas vezes e a linha de contexto. Placar SG1: 121 PASS · 29 FAIL · 3 `[isento]` antes desta edição → 140 PASS · 10 FAIL · 3 `[isento]` depois (cobertura: 153 nomes distintos em 10 canônicos, conferidos contra 323 definidos no gêmeo). OS 19 EMITIDOS, cada um com valor e origem. Botão (12), `seed-componentes.md` §1.6 l.126-148 — a spec escreve o bloco CSS inteiro, com o par dark explícito e a regra que o gerou verbatim ("token de componente que referencia primitivo DEVE declarar o par dark — primitivo não troca de modo sozinho", correção v0.5): `button-radius` 8px (= radius-md) · `button-font-weight` 600 (= fw-semibold) · `button-height-sm/md/lg` 32/44/52px (fixados) · `button-gap` 8px (= sp-2) · `button-secondary-border` turquesa-600 `#098475` / turquesa-300 `#66D1C2` · `button-secondary-text` turquesa-800 `#005048` / turquesa-100 `#CDF3EC` · `button-outline-border` cinza-600 `#617683` / cinza-400 `#90A6B3` · `button-ghost-text` turquesa-700 `#006C62` / turquesa-300 `#66D1C2` · `button-toggle-on-bg` turquesa-800 `#005048` / turquesa-300 `#66D1C2` · `button-toggle-on-fg` `#FFFFFF` (único valor de cor da leva que a spec fixa em hex, não em alias) / turquesa-900 `#00352F`. Cartão (3), §26 l.1954: `card-bg` = surface-raised · `card-border` = border-subtle (borda decorativa declarada: 1,21 claro / 1,75 escuro, abaixo do piso 3,00 da SC 1.4.11 de propósito, porque a separação é carregada por espaço + raio + superfície + tipografia) · `card-radius` 12px (= radius-lg → radius-6). Divisor (1), §26-F l.1976: `divider-color` = border-subtle. Lista (1), §26-F l.2000: `list-hover` = surface-subtle no claro e o hex `#273137` no escuro — a assimetria é da spec e foi preservada, porque `#273137` é o `surface-overlay` do escuro, não o `surface-subtle` (`#141D23`), e é o que os quatro consumidores vivos renderizam. Item destrutivo de menu (1), §27 l.2181: `danger-item` = vermelho-700 `#A5272A` / vermelho-200 `#FFC2BD`. Espera (1), §17 R3-c l.1687: `wait-delay` 1000ms, número que a própria linha fixa por escrito ("default 1000ms"), fundamentado no limite de 1s de Nielsen, com revisão por telemetria real do ERP na F4 declarada ali como "pendência declarada, não decisão aberta". OS 10 QUE NÃO SE EMITE, com o motivo — e eles são a lição desta versão, porque nem todo nome citado é um pedido. ⓐ Três contraexemplos documentados (documentação de um defeito CITA o defeito, e citar não é pedir): `--seed-button-primary-bg` aparece só no diagrama de arquitetura do §1 deste arquivo e do `seed-email.md` ("3. COMPONENTE — exceção local"), como ilustração do conceito de camada 3 — e a §1.6, que é a spec real do botão, deliberadamente não o cria, porque o botão primário consome `--seed-action-primary` sem divergir (a regra do §1 daqui: "a camada 3 só nasce quando um componente precisa divergir do semântico"); `--seed-input-affix` está na coluna Descartado da tabela de decisões do §3.10 ("duplicaria help-text sem caso de uso divergente"), com a §3.6 dizendo em texto "Tokens novos: nenhum de cor"; `--seed-danger-solid` é nomeado no `mapa-cobertura-ds.md` §21 dentro da tabela da "cegueira de nome" — a mesma superfície vermelha sólida vive no acervo sob três nomes, e este é justamente o que carrega o valor divergente (`#D94545` contra `#C6393B`), já registrado como pendência AC-P5 e MR-P3; emiti-lo canonizaria o defeito. ⓑ Quatro lacunas reais da spec (nome sem origem de valor declarada — §14.1: valor que não existe no canônico não se cria): `--seed-input-w-md` aparece uma vez, dentro de um exemplo HTML de `style` embutido, como `var(--seed-input-w-md,320px)`; o `320px` é fallback de CSS, não declaração, não existe escala de largura (`-w-sm`/`-w-lg`) e não há medição nem racional — emitir inventaria uma escala de um membro só. `--seed-divider-strong`: a §26-F fixa o alias (border-default) e mede 1,91 apenas no claro, sem declarar o par dark, e o único consumidor vivo (`banco-superficies.html`) usa cinza-600 `#617683` no escuro, que não é o border-default dark (`#4D606C`) — emitir qualquer um dos dois lados criaria contradição com o consumidor ou invenção de valor. `--seed-switch-thumb`: a spec diz "branco / cinza-100", mas a bancada `banco-formfield.html` fixa `#fff` nos dois temas e não consome o token; divergência sem decisão registrada. `--seed-ease-out`: a spec o usa quatro vezes e nunca fixa a curva, e o acervo tem dois valores diferentes rodando — `cubic-bezier(.2,.8,.4,1)` em três artefatos e `cubic-bezier(.2,.7,.3,1)` em dois (medido por varredura nas bancadas); o gêmeo não tem `ease-out`, só `ease-productive`/`ease-expressive`. ⓒ Três de dependência circular com o fantasma: `--seed-switch-off-bg` e `--seed-slider-track` têm o alias condicionado a uma medição que nunca foi feita (a própria spec escreve "3:1 sobre a página: medir na produção do preview") — e o valor que ela propõe não passaria: cinza-300 `#ACBECA` sobre a página clara mede 1,91, medido aqui, contra o piso de 3,00 que a linha exige; o único consumidor declara só a metade escura, e com escopo de elemento (`[data-theme="dark"] .seed-switch{…}`), o que deixa o estado OFF do tema claro com `background` inválido — defeito real, medível, e que merece pendência própria. `--seed-switch-on-bg` tem como origem declarada o `--seed-action-primary-bg`, que é token fantasma isento na SG1 (FF-P2/FF-P3), e o valor dark que a spec lhe dá (turquesa-400) contradiz o `--seed-action-primary` vivo do tema escuro (turquesa-300 `#66D1C2`), que é o que a bancada de fato renderiza — além de o componente não divergir do semântico, o que pela regra do §1 proíbe criar a camada 3. VERIFICAÇÃO DE SUPERSEDE, feita antes de emitir cada valor (a régua que a v1.21 pagou caro: spec desatualizada que ninguém anota vira token errado). Três decisões posteriores foram achadas e nenhuma muda valor dos 19: CD-P7 (2026-08-17, fechada) decidiu que os 93 botões com borda abaixo de 3:1 não são defeito de SC 1.4.11, porque rótulo legível já identifica o controle — é veredito sobre conformidade, não sobre valor; MR-P1/MR-P2 (2026-08-17) reescreveram a tinta sobre fundo de marca, mas na família `text-on-`, e o registro diz explicitamente que "o botão primário não muda de aparência"; CP-P4* (2026-08-15) supersedeu a forma de aplicar a borda do cartão (de `border` para o par anel-de-1px + sombra), sem tocar no valor do token. Os consumidores vivos foram conferidos um a um e concordam com a spec em todos os 19 — `banco-componentes.html` (l.406-411) já declarava os seis tokens de cor do botão com os mesmos aliases, `banco-superficies.html` os três do cartão e o divisor, quatro bancadas o `list-hover` e duas o `danger-item`. PLACARES, antes e depois. `paridade-tokens.py`: 85 → 104 PASS · 0 FAIL, com o gate novo G6 (irmão do G5: presença nos dois gêmeos, fidelidade alias→valor e espelho `prefers-color-scheme` idêntico ao `[data-theme="dark"]`); o G6 imprime a cada execução uma linha de INFORMAÇÃO com a colisão de altura, para que ninguém a descubra por acidente. G1 estrito contra o CSS v1.21 real: 0 sumidos, 0 alterados, `:root` 304 → 323 (+19), dark 118 → 129 (+11) — adição pura provada, não afirmada. `paridade-previews.py`: 505 PASS · 0 FAIL, inalterado. `guarda-valor-gemeo.mjs` (contrato AC5, artefato × gêmeo no Chrome real): 40 PASS · 0 FAIL nos dois lados, com a medição feita duas vezes variando UMA condição (o gêmeo) — contra o v1.21: 11 `[achado]`, 5.556 valores comparados, 76 declarações de dialeto local; contra o v1.22: 10 `[achado]`, 5.588 valores comparados (+32), 60 declarações de dialeto local (−16). Ou seja: 16 redeclarações que eram "dialeto local, ninguém confere" viraram valor conferido contra o gêmeo, nos dois temas, e todas passaram. PROVA DE CONSUMO (cobaia mínima no scratchpad, fora do repositório, ligada ao gêmeo real por `file://` e sem repetir nenhum valor literal; Chrome real pelo contrato `ambiente.mjs`, medição por `getComputedStyle`): 38 PASS · 0 FAIL — 19 tokens × 2 temas. E a contraprova, que é o que dá sentido ao número: a mesma cobaia apontada para o gêmeo v1.21 devolve 0 PASS · 38 FAIL, com as cores caindo em `rgba(0,0,0,0)` e o delay em `0s` — a camada é medida de verdade, e reprova quando não existe. COLISÃO DECLARADA E NÃO RESOLVIDA, com os três números lado a lado, para decisão do Rafael: `--seed-button-height-md/lg` = 44/52px (§1.6) e `--seed-field-height-md/lg` = 44/52px (§2.5, decisão explícita "md = 44px (não 40px)", alvo de toque WCAG) contra `--seed-control-md/lg` = 40/48px (v1.14, régua genérica de altura de controle). Dois números para o mesmo degrau da escala, agora em três grupos. Emitido como cada spec fixa; reconciliar é decisão de canônico, não dos gêmeos. O QUE FICA PARA A SESSÃO PRINCIPAL, porque é promoção de texto canônico e não emissão de token: anotar no `seed-componentes.md` que a §3.6/§3.10 já resolveram o `input-affix` (para a SG1 poder isentá-lo em vez de reprová-lo), decidir o par dark do `divider-strong`, marcar o `switch-off-bg`/`slider-track` como medição pendente, fixar a curva do `ease-out` num dos dois valores que já rodam, e abrir a pendência do estado OFF do switch no tema claro.
1.21	2026-08-25	A CAMADA 3 (componente) COMEÇA A EXISTIR NOS GÊMEOS — form-field, fecha a AD-P6. O defeito, medido: `seed-componentes.md` §2.5 (validada pelo Rafael em 2026-08-02, v0.6/v0.7) especifica 21 tokens `--seed-field-` com contraste medido par a par; `seed-field-` aparecia 116 vezes* na spec e ZERO nos gêmeos — a camada era perfeitamente descrita e inconsumível, e o ERP (resultado nº 1 do projeto) consome exatamente ela. A emissão: adição pura (nenhum valor anterior muda), cada token gravado como o hex RESOLVIDO do alias que a §2.5 declara (ex.: `field-label` = cinza-900 `#242E34`), nos três blocos do CSS (`:root`, `[data-theme="dark"]` e o espelho `prefers-color-scheme`) e no grupo `semantic.field` do JSON — com UMA exceção obrigatória, achada pela verificação de colisão com decisão posterior: `field-border` NÃO segue a §2.5 l.400 (cinza-600), porque a CD-P2 (2026-08-17, fechada) a supersedeu — o alias vigente é `--seed-border-interactive` (cinza-500 `#788F9D` nos dois temas; medido 3,13 claro / 5,05 escuro, o local degradava na inversão 4,74→3,21), e a bancada `banco-formfield.html` já renderiza assim desde CD-P2; as variantes de estado (`-hover/-error/-success/-warning`) não migraram, por decisão da própria CD-P2. A colisão foi flagrada pela `guarda-valor-gemeo.mjs`, que comparou a emissão com o consumidor vivo — a primeira emissão seguia a §2.5 verbatim e reprovou. Estrutura fixada pela spec: alturas 32/44/52px — o md=44 é decisão explícita do canônico ("md = 44px (não 40px)", alvo de toque WCAG) e coexiste declaradamente com a régua genérica `--seed-control-md` 40px da v1.14; reconciliar é decisão de canônico, apontada ao decisor. Guarda nova: gate G5 na `paridade-tokens.py` — presença nos dois gêmeos, fidelidade alias→valor (se o token-base mudar e o field não seguir, reprova — mata a fossilização da classe "defasado e invisível" do reinjeta-tokens) e, pela primeira vez, o espelho `prefers-color-scheme` é lido por um gate (antes um token esquecido lá era invisível). Placar: 85 PASS · 0 FAIL (64 anteriores + 21 do G5); G1 estrito contra o CSS v1.20 real: 0 sumidos, 0 alterados, +21 `:root` / +15 dark. Prova de consumo no Chrome real (contrato `ambiente.mjs`): 6 tokens consumidos por uma cobaia de scratchpad (altura, raio, fundo, borda, ajuda, erro) e medidos no render por `getComputedStyle` — 9 medições · 9 PASS nos dois temas. Divergências INTERNAS da §2.5 achadas na emissão (spec escrita antes da implementação, registradas para o gate, não corrigidas aqui): (a) o comentário do `readonly-bg` claro diz "sobre cinza-50" e o `surface-sunken` vigente é cinza-100 `#E3EBF0` (o alias vence, o número 12,75:1 está defasado); (b) as medições dark citam "dark-default `#141D23`", que hoje é o `surface-subtle` (a página dark é `#0B1419`) — e a bancada `banco-formfield.html` carrega `--seed-field-readonly-bg: #141D23` LITERAL no bloco dark (resolução da era da spec), divergindo do alias vigente `surface-sunken` = `#0B1419`; (c) a §2.5 l.400 (`field-border` = cinza-600) está SUPERSEDIDA pela CD-P2 e a tabela da §2.5 nunca recebeu a anotação — promover a nota no `seed-componentes.md` é da sessão principal. Nota de lacuna desta tabela: as linhas v1.13–v1.20 nunca foram escritas aqui (mesma classe da errata que a v1.11 registrou e restaurou para v1.7–v1.10); lacuna apontada ao decisor em 2026-08-25 — não restaurada nesta edição porque reconstrução histórica não é emissão de token.
1.12	2026-08-14	`border-interactive` — FECHA A SH-P1/PN-P5 (aberta desde o bloco 6A, 2026-08-11). Fronteira de componente interativo (SC 1.4.11): promoção do empréstimo declarado do `cinza-500` `#788F9D` a semântico, mesmo hex nos dois temas por medição (seis superfícies, 3,11–5,51, todas ≥3,0), slot dark declarado de propósito (coincidência medida, não invariância). Alternativa `cinza-600` descartada com número (passa, mas mudaria cor renderizada aprovada em gate sem motivo). Gatilho: regra GI2 — a camada 2 foi editada pela CP-P3 (v1.11) e o Rafael mandou fechar na mesma janela. Gêmeos na MESMA edição; `paridade-tokens.py` 52 · 0. O campo de busca do shell passa a consumir o semântico (preview v0.3). Racional completo na nota do §3.
1.11	2026-08-14	Semânticos de COMPOSIÇÃO E CHROME (CP-P3 · SUP-6 em escopo mínimo) — nova subseção no §3. Entram, todos INVARIANTES de tema (sem redeclaração no bloco dark, de propósito): `rail-background` (gradiente `turquesa-700 → turquesa-800` do CP20, adotado no gate G2; extremos medidos 6,32/9,37) · `chrome-overlay-hover`/`-active` (véu branco .12/.14 sobre a rampa da marca — alphas fixados depois de medição em COMPOSIÇÃO: rótulo branco sobre overlay composto em cada extremo = 4,88/6,82 e 4,68/6,50, todos ≥4,5) · `entity-1…6` com tinta por posição `entity-N-ink` (paleta fechada do CP23, gate G3; admissão CP22 medida: 5,11/5,30/5,63/9,37/6,43/6,68) · `marker-now` (`turquesa-600` fixo, CP24/G4, ≥3,0 contra as cinco superfícies canônicas). Gêmeos JSON+CSS na MESMA edição (v1.11), `paridade-tokens.py` 52 PASS · 0 FAIL (G1 sem regressão: nenhum valor anterior muda — é ADIÇÃO). Motivação: pendência CP-P3 do `seed-composicao.md` (regeneração do shell, que também fecha a errata E-CP-01 — o C1 deixava de consumir a categórica). Errata desta edição, fechada pela regra GI2: a tabela deste §9 estava parada na v1.6 — as entradas v1.7–v1.10 nunca foram escritas aqui (mesma classe da E-6C-01 do `seed-componentes.md`: quem bumpa o título escreve a entrada na mesma edição); restauradas abaixo a partir das notas inline deste arquivo e do MANIFESTO, marcadas como retroativas.
1.10	2026-08-14	(entrada retroativa, escrita na v1.11) Normalização do `focus-ring` — o tema claro deixa de consumir o primitivo `--seed-branco` e passa ao semântico `--seed-surface-page` (o que o escuro já fazia); cor renderizada idêntica, muda a EXPRESSÃO. Achado veio de fora: `paridade-previews.py` acusou os previews, e eles estavam mais corretos que o canônico. Racional completo na nota do §3.
1.9	2026-08-13	(entrada retroativa, escrita na v1.11) SUPERSEDE DA TINTA DE TEXTO — `text-primary/secondary/muted` migram da família cinza para a família turquesa da marca nos dois temas (`#0B3330`/`#2F5A54`/`#40706A` no claro), com supersede formal da restrição "nenhum hex novo" (valores entram como SEMÂNTICOS). Fecha na mesma edição a errata do `text-muted`, que REPROVAVA (2,80–3,38 no claro). Racional, tabela e alternativas descartadas na nota do §3. Fecha o PN-P1.
1.8	2026-08-14	(entrada retroativa, escrita na v1.11) Sub-bloco DP (mapas): adição de `chart-geo-base` (território de contexto) e `chart-geo-boundary` (fronteira de município, piso 3:1). Nenhum valor anterior muda. Nota na §3c; errata E19 relacionada (chart-grid tem o mesmo hex de no-data).
1.7	2026-08-11	(entrada retroativa, escrita na v1.11) `chart-no-data-hatch`: a tinta das linhas da hachura ganha token próprio (a E3 provou que papel de desenho sem token toma emprestado o de outro papel — era cat-5-stroke e virou violeta na v1.5). Medido contra o preenchimento: 3,93/3,84.
1.6	2026-08-11	Promoção da categórica ESTENDIDA da §3c a `estável`, por "aprovo" explícito do Rafael sobre o lote de formalização da Fase 5 (o gate visual havia acontecido em 2026-08-10; o lote formalizou o que estava só nos previews). Nenhum valor de token muda nesta versão — é mudança de estado. Os gêmeos `seed-tokens.json` e `seed-tokens.css` acompanham para v1.6 para preservar a unidade md+json+css declarada no cabeçalho, seguindo o precedente da v1.4 (que também foi uma promoção de estado). Alternativa descartada: declarar o estado sem bump de versão, deixando os três em v1.5 — economizaria uma edição, mas criaria um arquivo cujo rótulo de versão não distingue "proposto" de "aprovado", que é exatamente a informação que o gate produz. Achado colateral registrado no `seed-dataviz.md` v0.6 §5 (errata E3): o supersede da categórica teve uma consequência não intencional — o `cat-5`, que na v1.0 era cinza-400 e servia de referência neutra no gráfico do alerta ET5, virou violeta na v1.5; referência de comparação não pode carregar cor de categoria viva, e o ET5 passa a consumir tinta neutra. É a classe de risco que qualquer troca de paleta cria: quem usava uma posição categórica como "neutro" perde o neutro em silêncio.
1.5	2026-08-11	Categórica ESTENDIDA (§3c) — supersede formal da categórica v1.0 e da restrição "nenhum hex novo" do DT. Racional medido: a marca tem só 3 matizes livres para dado (turquesa ~170°, dourado/amarelo ~36–50° — mesma família —, azul ~192–197°; vermelho e cinza são reservados), então nascem 2 matizes exclusivos de dataviz que nunca aparecem em UI (padrão IBM Carbon/GitLab): magenta 332° (`#CD518B`/`#E8A1C2`) e violeta 268° (`#966AC8`/`#BD9CE2`), 6 hex novos no total, sem rampa no §2.1 de propósito. Sequência: turquesa → dourado → magenta → azul → violeta → azul-800 — 5 famílias, nenhuma repete antes da 6ª posição; ordem 2↔3 decidida no gate (dourado separa por peso os dois tons médios saturados). `cat-1` light muda de turquesa-400 para turquesa-500 `#00A192` (3.22 vs branco — o DG14 removeu o contorno e o fill passou a ter de passar 3:1 sozinho). Regra do dourado: permitido em área grande com rótulo direto; vetado como fill solitário sem rótulo (1.85 é insolúvel sem matar a cor da marca). O cinza sai da categórica (conflitava com a reserva de "sem dado"). Supersede DM3 no gauge: bandas viram intensidades de cinza (medido: as faixas coloridas distavam 1 ponto de claridade no light e 0 no dark); a barra de valor carrega a severidade; nenhum hex muda. Emenda GI2 cumprida: registrado que a rampa categórica ESCURA colapsa em claridade (75/75/71/71/67) por construção — é o que obriga o DG13. Achado da formalização: os previews aprovados embutiam 5 hex com deriva do canônico; a seção ancora nos stops reais do §2.1, com remedição provando veredito idêntico. Aprovação: gate visual do Rafael em 2026-08-10 ("tudo ok" sobre os previews v1.2/v0.7); leis de consumo no `seed-dataviz.md` v0.5. Gêmeos atualizados NA MESMA edição (v1.5), `paridade-tokens.py` com allowlist de supersede declarada.
1.4	2026-08-09	Promoção da §3c a `estável` (gate visual do DT aprovado pelo Rafael sobre o preview v0.2 completo) e fechamento do débito do §7.0: os gêmeos `seed-tokens.json` e `seed-tokens.css` foram regenerados e passam a v1.4. Nenhum valor de token foi alterado nesta versão — é mudança de estado + restabelecimento da unidade md+json+css. Achado da execução: o débito era de DUAS versões, não uma — os gêmeos declaravam `v1.1` e não continham nenhum token do pacote mobile v1.2 (breakpoints, tipografia fluida `clamp()`, `--seed-fs-field-touch`, safe-area); a redação anterior da pendência 7.0 é superada com racional completo. Guarda nova: `validacao/paridade-tokens.py` (G1 não-regressão · G2 paridade json↔css · G3 cobertura nominal), 43 PASS · 0 FAIL — ela reprovou a primeira tentativa de regeneração (renome de `--seed-sp-*`, perda de `--seed-focus-ring`, sombras serializadas como DTCG), o que levou a entrega a ser feita por edição cirúrgica. Cruzamento §3c × gêmeos: 26/26 hex batem. `contraste-dataviz.py` reproduzido na janela: 29 PASS · 3 FAIL (os 3 documentados do fill em traço fino).
1.3	2026-08-09	Escalas de dado da Fase 5 (sub-bloco DT), nova §3c — a entrega prometida desde a v1.0. Sequencial `chart-seq-1…7` (rampa turquesa; escala final 100→900 light / 800→100 dark, decidida no gate visual: o Rafael reprovou a proposta original 50→800 porque os dois primeiros stops liam como cinza — ambíguos com "sem dado" — e aprovou a opção A sobre preview comparativo; nasce junto o token `chart-no-data`, cinza exclusivo de "sem medição", SEMPRE hachurado; isenção 1.4.11 declarada com condições de acompanhamento e gatilho de revisão) · divergente `chart-div-neg-3…pos-3` (vermelho↔cinza↔turquesa, alinhada por construção ao par positive/negative da v1.0; posições plenas passam 3:1 medido nos dois modos; regra da zona-zero declarada) · gauge `gauge-track/value/range-` (faixas referenciam a taxonomia de feedback — nenhuma severidade paralela) · variante `cat-N-stroke` light+dark* para traço fino, nascida de remedição que reprovou cat-1/2/5 a ≤3px (fill intocado; os pares dark vieram do achado V2 do render). Dois achados do script corrigiram a proposta antes da spec: warning light dourado-500→600 (2.35→3.25 vs trilha) e critical dark vermelho-400→300 (2.38→3.26). Nenhum hex novo — tudo stop existente do §2.1. Errata §5 fechada nesta edição (regra GI2 — aberta desde o roadmap v1.3, 2026-08-04): a linha do par info dizia "azul-700 · 5.79 · AA"; medição de 2026-08-09 provou que 5.79 é de fato o azul-700, mas o par semântico usado pelo sistema (feedback-info-text, consumido inclusive pelo e-mail §4.2) é o azul-800, que mede 8.57 · AAA — a linha passa a documentar o par real, e a errata original (que previa só troca de rótulo) é superada pela correção completa rótulo+número+veredicto. Consumidor primário desta seção: `seed-dataviz.md` (9º canônico, DF7: uma fonte, referência sem duplicação).
1.2	2026-08-02	Camada mobile/app (pacote M1–M3 aprovado pelo Rafael). Breakpoints oficiais = escala Tailwind (sm 640…2xl 1536), canônicos no JSON + theme do Tailwind, com supersede do corte 960 do HTML v1; escala tipográfica fluida com `clamp()` rem+vw nos 4 topos (regra WCAG 1.4.4 embutida); `--seed-fs-field-touch` 16px via `pointer: coarse` (anti-zoom iOS); tokens de safe-area para PWA/app. Nenhum valor de cor alterado. Contexto: diretriz de paridade mobile/app declarada pelo Rafael em 2026-08-02 — apps serão produzidos e o uso mobile supera o desktop.
1.1	2026-07-30	Hierarquia de uso da paleta (§3b): proporção 70/20/10 (supersede os 45% de 2018), amarelo=acento oficial vs dourado=trabalho, papel formal do azul (livre na UI/info, contido na marca, nunca ação primária). Novo grupo semântico `accent` (highlight/highlight-subtle/on-highlight). Nenhum valor de cor alterado.
1.0	2026-07-30	Entrega inicial da Fase 1 do rebranding do DS. Rampas tonais das 6 famílias (8 cores de marca + vermelho funcional), semânticos light/dark, elevação, motion, tipografia (Montserrat+JetBrains Mono; Indie Flower e Neo Tech aposentadas), spacing/radius, dataviz. Supersedes declarados: #0d8f82 → surface-brand-deep; #2a3942 → cinza-900; hex dark ad-hoc → superfícies dark oficiais; #c63838 → vermelho-600; regra de contraste do turquesa reformulada com medição.