7. Pendências explícitas

(v1.3) Gêmeos seed-tokens.json/seed-tokens.css a regenerar com os tokens novos da §3c — ENCERRADA na v1.4 (2026-08-09), no prazo declarado (o gate do DT). Os dois gêmeos foram regenerados e passam a v1.4, restabelecendo a unidade md+json+css do cabeçalho.

SUPERSEDE FORMAL da redação anterior desta pendência. A redação da v1.3 dizia que o débito era regenerar os gêmeos "com os tokens novos da §3c" — isto é, um atraso de uma versão. Isso estava errado, e o erro só apareceu quando os arquivos foram abertos. Medição de 2026-08-09 sobre as cópias reais do Drive: seed-tokens.json e seed-tokens.css declaravam v1.1 no próprio cabeçalho e não continham nenhum token do pacote mobile v1.2 — zero ocorrências de breakpoint, safe-area, fs-field-touch e clamp nos dois arquivos. A defasagem real era de duas versões (v1.2 + v1.3). A v1.4 dos gêmeos fecha as duas de uma vez.

Causa raiz declarada: a regra "os três arquivos formam uma unidade" existia desde a v1.0 sem detector. Ler o .md não revela nada sobre o conteúdo dos gêmeos, e o .md é justamente onde a versão dos três é declarada — a fonte da afirmação e o objeto da afirmação nunca se encontravam. Mesma classe do defeito que originou a regra de leitura de volta no marco v1.4 (propagação afirmada, nunca lida).

Correção estrutural: nasce a guarda permanente validacao/paridade-tokens.py, que mede 3 portões — G1 não-regressão (nenhum token do CSS anterior some ou muda de valor), G2 paridade (todo token do JSON tem contraparte no CSS, salvo isentos declarados: hoje só breakpoint, que media query não lê), G3 cobertura (o inventário nominal da §3c e do pacote v1.2 está nos dois gêmeos, em light e dark). Placar da regeneração: 43 PASS · 0 FAIL.

Achado do próprio G1, registrado por transparência: a primeira tentativa de regeneração reescrevia o CSS inteiro a partir do JSON e foi reprovada — renomeou --seed-sp-* para --seed-space-* (renomear token quebra todo consumidor), perdeu --seed-focus-ring (composto que só existe no CSS, sem contraparte no JSON) e serializou sombras, famílias tipográficas e curvas de bezier como estrutura DTCG em vez de valor CSS. A entrega final foi por edição cirúrgica sobre o arquivo anterior: zero regressão por construção, não por conferência. Alternativa descartada: aceitar a regeneração total e corrigir os 3 achados — descartada porque o método que produz 3 perdas detectadas produz as não detectadas também.

Verificação cruzada da entrega: os 26 tokens da §3c foram conferidos linha a linha entre esta seção e os hex efetivamente gravados nos gêmeos — 26/26 batem, 0 divergências. Contagem do CSS: :root 156 → 191 tokens (+35 = 26 dataviz + 4 fluidos + 1 field-touch + 4 safe-area); bloco dark 61 → 87 (+26). Chaves balanceadas, zero declarações duplicadas, prefers-color-scheme com os 26 espelhados.

Validação visual pelo Rafael do preview (seed-tokens-preview.html) — rampas e semânticos em light/dark. Qualquer ajuste de gosto (ex.: dark mais quente/frio) é feito na fonte e regenerado.

CMYK "U" (superfície fosca) das cores: o Manual 2018 previa e não preencheu. Segue "(a confirmar)" — só relevante se houver impressão em papel fosco com fidelidade crítica.

Teste em tela real dos produtos: os valores dark foram derivados por método e auditados por contraste, mas merecem uma passada de olho no ERP real antes de virarem lei.