Dataviz

7. Registro de versões

seed-dataviz.md v0.22 · §07seção 12 de 1207-registro-de-versoes.md · MD5 58ec837d

Versão	Data	Conteúdo
0.22	2026-08-24	A DP-P7 FECHA no mesmo dia em que nasceu, por veredito ("opção B é melhor"): o coropleto passa a desenhar a fronteira que o DP4 obriga. O `gen-dp.py` deixou de tratar a variante `coropleto` no ramo dos municípios com obra (que no coropleto é vazio) e passou a desenhar em todos, como a `completa`. Medido depois: 1.348 fronteiras em `#788F9D` a 0,5 de espessura. A E19-b é o que permitiu o conserto sem FAIL. Nenhum hex muda, nenhuma decisão de cor muda — muda o que É DESENHADO.
0.21	2026-08-24	Nasce a E19-b — exceção declarada por veredito na fronteira geográfica sobre o sem-medição. O porte da camada de validação (F7.7-P1) mediu o que a E19 não tinha medido: no claro a tinta adotada rende 2,80 sobre `chart-no-data`/`surface-sunken` (o par canonizado, sobre o contexto, segue 3,11 PASS). Veredito do Rafael, saída (a): aceitar como exceção declarada — a hachura é o segundo separador (1.4.11 cobra o par só quando ele é o ÚNICO identificador); mesmo veredito para cat-2-stroke × sunken (2,89), cujo segundo portador é a FORMA (E20). Candidatas medidas e descartadas: ci-600 (colide em valor com a hachura — estrutura E3) e ci-700 (dobra o peso do traço). NENHUM hex muda; a exceção vira categoria própria `[exceção]` no `contraste-dp.py`, com número impresso. Placar: 27 PASS · 0 FAIL · 3 exceções. A prova visual da decisão (mapa real, lupa 12× por captura) achou de carona a pendência DP-P7: a demo do coropleto não desenha fronteira nenhuma, contra o DP4 — e a E19-b é o que permite consertá-la sem criar FAIL.
0.20	2026-08-11	GATE VISUAL DO PREVIEW v0.4 APROVADO — o sub-bloco DP fica SEM NENHUMA PENDÊNCIA ABERTA, e com isso a Fase 5 fecha sem ponta solta. Nenhuma decisão de conteúdo muda: é mudança de estado mais o registro que a aprovação obriga. As seis pendências nominais do DP, todas fechadas no mesmo dia em que o sub-bloco nasceu: DP-P1 (token do território e da fronteira — fechou com dois tokens novos e as erratas E19/E20) · DP-P2 (largura mínima da variante malha completa — medida agora: ≥ 640px) · DP-P3 (piso de claridade do polígono — fecha como decisão, com o piso declarado NÃO herdável e transferido ao DP14) · DP-P4 (paralelos da projeção) · DP-P5 (tolerância de simplificação, que superseiu o DP9) · DP-P6 (edição da Malha Municipal Digital). Placar final das quatro camadas com a geografia real: jsdom 82 PASS · 0 FAIL · render em Chrome real 22 PASS · 0 FAIL · contraste 27 PASS com 23 candidatas reprovadas de propósito · gate visual aprovado. Nota de fronteira sobre a DP-P3, para que ninguém a leia como resolvida por decreto: o piso de claridade para polígono de município não foi calibrado — foi declarado como não herdável e adiado até existir um coropleto com dado real, porque calibrar contra exemplo inventado produz o verde que impede a procura. A pendência fecha como decisão, não como medição, e isso está escrito no §4d.6.
0.19	2026-08-11	A MALHA REAL DO IBGE ENTRA E FECHA TRÊS PENDÊNCIAS (DP-P4, DP-P5, DP-P6). O preview deixa de usar malha sintética. Fonte: Malha Municipal Digital do IBGE, edição 2025, baixada do portal oficial pelo Rafael em três pacotes Shapefile (MG, ES, BA), SIRGAS 2000, UTF-8 — 1.348 municípios, 4.251.625 vértices, 135,9 MB de GeoJSON bruto. Registro de fonte descartada: antes disso a malha veio do espelho `tbrugz/geodata-br` (GitHub, CC0), porque o domínio do IBGE não é acessível da máquina de execução; as contagens batiam, mas os vértices não — 143.319 contra 4.251.625. O espelho já era ~30× simplificado e não declarava. DP15 (novo, §4d.14b): as ilhas oceânicas de Vitória saem do desenho, não do dado — a extensão de longitude cai de 22,20° para 13,70°, evitando 40% de figura em oceano vazio. DP-P4 fechada: paralelos -20,52° / -10,93° calculados da extensão real. DP-P5 fechada, e o resultado SUPERSEDIU o DP9: um único asset a 2%, no lugar de dois níveis — a diferença medida entre os níveis era de 192 KB, e duas fontes da mesma geometria por isso viola o DF7. Piso declarado: erro de área p99 ≤ 2% (medido 1,78%). DP-P6 fechada: edição 2025, no nome do asset. Instrumento novo: erro de área por município medido na projeção real, contra a malha bruta — é a métrica certa porque num coropleto a área desenhada é o que compara os dados. Caso-limite achado sozinho: Santa Cruz de Minas (MG), 3,565 km², erra 4,2% a 2% e 20,5% a 1%. Preview a v0.4, com a malha oficial renderizada pela cadeia REAL do DP2 (`d3-geo` + `topojson-client`). Suíte a 82 PASS · 0 FAIL (era 77) e render 22 PASS · 0 FAIL. Três defeitos achados na inspeção das capturas, nenhum visto pela automação: (1) a tabela do fallback transbordava 8px a 360px — corrigida com o contêiner rolável nomeado e focável do Bloco 6; (2) a descrição do DP1 ainda dizia "malha sintética" depois da troca — artefato mentindo sobre si mesmo, a classe da errata E6; (3) dois códigos IBGE digitados de memória apontavam para municípios errados (Vitória virou Cariacica, Cachoeiro virou São Mateus): o preview ficava correto e dizendo outra coisa. Regra que sai daqui: identificador digitado de cabeça é a mesma classe de defeito que a regra "geometria é calculada, nunca digitada" já cobria — a seleção passou a ser resolvida por nome contra a própria malha, com asserção.
0.18	2026-08-11	PROMOÇÃO: o sub-bloco DP passa a `estável` e A FASE 5 ESTÁ FECHADA. Os seis sub-blocos — DF, DT, DG, DM, DI e DP — são todos `estável`, e o marco v1.6 é disparado. Nenhuma decisão de conteúdo muda nesta versão: é mudança de ESTADO mais o registro que a promoção obriga. Placar final das quatro camadas de validação do DP: jsdom 77 PASS · 0 FAIL · render em Chrome real 22 PASS · 0 FAIL · contraste 27 PASS com 23 candidatas reprovadas de propósito (é a evidência que fundamenta os dois tokens novos) · gate visual aprovado. Fronteira do que o gate cobriu: o Rafael inspecionou o preview v0.2 e respondeu os cinco pontos do protocolo; a v0.3 difere em um único ponto (a tinta da contagem, corrigida pelo DG12) e foi aprovada sobre relato de medição e de inspeção de captura. Registrado porque fato e inferência se declaram separados. Pendências que o DP leva consigo para a Fase 6, todas declaradas: DP-P2 (largura mínima da variante malha completa) · DP-P3 (piso de claridade do polígono de município, que só fecha com coropleto de dado real) · DP-P4 (paralelos da projeção para o recorte MG-ES-BA) · DP-P5 (tolerância de simplificação) · DP-P6 (ano da Malha Municipal Digital do IBGE). O preview usa malha SINTÉTICA declarada enquanto a DP-P6 não fecha. Item obrigatório do marco, executado: a AUDITORIA DE IMPACTO DAS LACUNAS do §6 do `estudo-viver-de-ia.md`, agora na §6b daquele arquivo (v1.3). Veredito: nenhuma lacuna exige supersede em algo `estável`; e uma das cinco lacunas vermelhas não existia — a "camada de movimento" está nos gêmeos desde a camada de primitivos (errata E-EST1).
0.17	2026-08-11	A camada de RENDER do sub-bloco DP foi executada — e ela havia sido PULADA em silêncio nos lotes anteriores. Cobrança do Rafael, correta: "você precisa rodar o teste e enxergar essas coisas antes de eu testar". Fato registrado sem atenuante: nos lotes das v0.14–v0.16 eu verifiquei que não havia navegador headless na máquina, não avisei, e segui — de modo que a régua de quatro camadas (jsdom · render · contraste · gate humano) rodou com três. O defeito das 360px morava exatamente na camada ausente. Ambiente resolvido com o binário de Chromium empacotado em npm (`@sparticuz/chromium` + `puppeteer-core`), já que o download normal do Chrome não passa pela rede desta máquina. Nasce a `render-dp.mjs`: 22 PASS · 0 FAIL, medindo o que jsdom não vê — colapso real da grade em cada largura (R1), equivalência entre o controle de largura e o redimensionamento real da janela (R2, a regra do §4d.15), estouro de viewBox por `getBBox()` em navegador real (R3), espessura RENDERIZADA das fronteiras com o viewBox escalando 0,82× (R4, prova do `non-scaling-stroke`) e ausência de transbordo horizontal (R5). O defeito que só a inspeção das capturas achou, e que é violação de regra existente: a contagem de agrupamento do DP11 estava pintada em branco fixo. O DG12 determina há dois sub-blocos que tinta sobre dado não segue o tema e consome `cinza-900` nos dois modos, porque o fill categórico é claro nos dois modos. Medido: branco contra os fills do tema escuro dá 1,83 · 2,04 · 2,05; `cinza-900` dá 7,57 · 6,80 · 6,77 no escuro e 4,30 · 3,40 · 4,17 no claro. Preview a v0.3, guardas `DP11-02b/c/d` na suíte (77 PASS · 0 FAIL, era 74); prova de que são reais: contra o preview v0.2, reprovam em 2. Classe do defeito: regra do sistema não aplicada em consumidor novo — o DG12 nasceu para rótulo interno de barra e fatia, e o marcador de mapa é rótulo interno também; ninguém fez a ligação. Parente direto da E19, que herdou de outro consumidor sem remedir. Lição de método, e é a mais cara deste sub-bloco: camada de validação indisponível não é camada dispensável — é pendência a declarar. Pular em silêncio produz o mesmo verde de quando tudo passou. Nenhuma decisão de spec mudou nesta versão.
0.16	2026-08-11	O gate visual do Rafael achou um defeito que 68 verificações automatizadas não viam — e o defeito era no INSTRUMENTO, não no desenho. Ele testou os cinco pontos do gate no preview v0.1 e mandou uma captura da tela a 360px: as duas figuras do DP5 apareciam lado a lado, com cerca de 170px cada, em vez de empilhadas. Causa medida: o controle de largura da barra mudava o `max-width` do contêiner, enquanto a regra que empilha a grade era uma `@media` ancorada na largura da janela — que continuava larga. Consequência dura: a dimensão "largura" da matriz de render nunca foi exercida de verdade; o que aparecia na tela ao escolher "360" era uma célula que não existe na matriz. Regra nova, registrada no §4d.15 e mais geral que o sub-bloco: simular uma dimensão da matriz só vale se a simulação dirigir as MESMAS regras que a realidade dirige. Correção: preview a v0.2, com o contêiner virando container de consulta (`container-type: inline-size`) e as regras de layout passando a `@container` — assim o controle e a janela real disparam o mesmo conjunto de regras. Guardas novas `LARG-01`…`LARG-05` na suíte; prova de que são reais: contra o preview v0.1, reprovam em 3. Segunda correção de âncora no mesmo lote: a verificação `HIG-03` procurava a string literal `preview v0.1` no título — guarda que quebra a cada revisão e que, pior, convida a mentir de volta, que é exatamente a errata E6. Passou a exigir que o título declare alguma versão e que ela seja a mesma do `<h1>`. Placar da suíte: 74 PASS · 0 FAIL (era 68). O que o episódio prova, e é o motivo de o gate visual ser estruturalmente não-opcional: nenhuma das verificações automatizadas via o defeito, porque jsdom não resolve layout e a suíte conferia a presença da regra, não quem a dispara. Nenhuma decisão de spec do DP mudou nesta versão.
0.15	2026-08-11	A medição do DP mudou DUAS decisões que já haviam sido aprovadas no gate — e fechou a pendência DP-P1 no mesmo dia em que ela nasceu. Nasce o `contraste-dp.py` v1, instrumento do sub-bloco DP, que extrai os hex do `seed-tokens.css` em vez de digitá-los (lição das erratas E4/E16) e mede seis famílias de pares nos dois temas: colisões de valor entre papéis, território × fronteira, território × sem-medição, hachura, marcador × território e marcadores entre si em escala de cinza. Achado 1, que é um fato do sistema e não do mapa: `chart-grid` e `chart-no-data` têm o mesmo hex nos dois temas (`#E3EBF0` light, `#38464F` dark) — o que torna a condição (b) da §3c ("fronteira sustentada por `chart-grid`") impossível de cumprir sobre uma célula sem medição, com razão 1,00. O defeito é antigo e nunca apareceu porque no heatmap a célula no-data é hachurada e as vizinhas são sequenciais saturadas: a fronteira nunca precisava separar dois cinzas. Num mapa, separar dois cinzas é o caso normal. Errata E19 e supersede no §6. Achado 2: no tema escuro `chart-axis` é o mesmo hex do `chart-no-data-hatch` (`#90A6B3`) — logo emprestar `chart-axis` para a fronteira repetiria a estrutura da E3. Daí dois tokens novos na v1.8 dos três gêmeos: `chart-geo-base` (território de contexto) e `chart-geo-boundary` (fronteira), ambos com valor idêntico a tokens existentes de propósito — o que muda não é a cor, é a responsabilidade de mantê-la. Achado 3, o mais incômodo: o DP10 dizia "cor até 3 categorias, forma acima disso", e descartava por raciocínio a redundância cor+forma desde a primeira. A medição inverte: no dark os três pares de marcador medem 3,6 · 3,7 · 0,2 pontos de claridade e no light o par `cat-1 × cat-4` mede 0,9, todos abaixo do piso de 6. A forma passa a ser o portador permanente da categoria e a cor vira redundância (errata E20). O dourado sai da paleta de marcador por aplicação da regra do dourado que já existia (fill pequeno e solitário), e o marcador ganha contorno em `cat-N-stroke`, cuja própria descrição nos gêmeos nomeia o caso: "marcador pequeno — o pior caso do 1.4.11". Lição de método, terceira ocorrência registrada: não diagnostique por raciocínio, meça — aqui o raciocínio não errou um diagnóstico, errou uma decisão de design aprovada, e o que a pegou foi a pendência ter sido declarada em vez de resolvida por escolha. Gêmeos a v1.8 (adição pura: nenhum valor anterior muda) e a guarda `paridade-tokens.py` estendida para os dois tokens novos — 52 PASS · 0 FAIL, e prova de que a guarda nova é real: rodada contra o CSS v1.7, reprova em 4. Errata E8 CORRIGIDA de passagem na mesma edição, pela regra GI2: a §3c citava o fundo dark `#1C252B`, e o token é `#1D272D`. Pendente deste lote: preview do DP construído sobre a spec corrigida, suíte, gate visual e a edição do `MANIFESTO.md`.
0.14	2026-08-11	Spec do sub-bloco DP — mapas de atuação MG-ES-BA — em §4d, DP1–DP14. Com ela, os SEIS sub-blocos da Fase 5 existem; falta o gate visual do DP para fechar a fase. Consolidado aprovado pelo Rafael após 3 rodadas encadeadas de pesquisa (R1 canon interno · R2 mercado/stack de mapa em React · R3 normas: IBGE, projeção cartográfica, acessibilidade de mapa). Escopo decidido em briefing ANTES da pesquisa — pontos e não coropleto, três destinos (impresso, ERP, site), figura fixa, três níveis geográficos, sem identificação de cliente em peça externa, sem fonte de malha preexistente na empresa. Registro de método: a primeira formulação da pergunta (d) foi respondida com uma correção do Rafael — a proposta de dois níveis (estado + ponto) foi recusada com "eu tenho que ter todos os municípios", e a redação da proposta induzia a leitura errada de que municípios sem obra sumiriam do mapa; a decisão final (DP5) mantém o território sempre inteiro e torna seletiva apenas a linha de fronteira. Três achados da R1 mudaram o desenho: (1) a §3c do `seed-tokens.md` já nomeia "mapa coroplético" como consumidor da escala sequencial e já traz as três condições obrigatórias da isenção do WCAG 1.4.11 — entre elas fronteira por `chart-grid`, o que dispensa o supersede do DG14 que eu previa e o reduz a precisão de escopo (DP4); (2) o traço de 0,5px seguia sem consumidor e a fronteira municipal da variante malha completa é o primeiro (DP5); (3) o DF2 tem uma lacuna: declara shadcn Chart sobre Recharts como consumidor canônico web, e Recharts não desenha mapa — emenda formal no §6. Achado da R2/R3: projeção equivalente (Albers) é obrigatória e Mercator é vetado, porque nosso recorte vai de ~-8° a ~-22° de latitude e a deformação de área seria sistemática e direcional, inflando a Bahia contra Minas — mentira visual da empresa sobre si mesma. Achado que inventa vocabulário, o único do sub-bloco: o DI2 manda texturizar, mas textura não cabe num marcador de 8–12px; em mapa a distinção em escala de cinza passa a ser por forma (círculo/quadrado/triângulo), com teto de 3 categorias — menor que o teto de 6 da categórica, e portanto um mapa da SEED não consegue mostrar os cinco pilares como cinco marcadores legíveis em mono. Advertências do IBGE que entram no canônico (DP8): os limites da Malha Municipal Digital são aproximados, o IBGE não tem atribuição legal de demarcação, e a malha é republicada anualmente — logo o mapa da SEED não serve como peça de definição de limite territorial, e o asset declara o ano. Matriz de render ganha dimensão nova: largura de renderização (360 · 768 · 1200), cruzada com tema × grayscale × impressão. Seis pendências nominais nascem declaradas (DP-P1…DP-P6, §4d.16), nenhuma bloqueando a spec e todas bloqueando a promoção a `estável`. Pendente deste lote: preview do DP, suíte, gate visual do Rafael e a edição do `MANIFESTO.md` que ancora este arquivo e os artefatos do DP.
0.13	2026-08-11	SUPERSEDE do DM8: o e-mail de alerta de geração não leva gráfico. Decisão do Rafael no gate de produção do asset, contra o desenho que eu havia especificado e produzido. Racional, que é mais forte que o original: o PNG hospedado no R2 é arquivo único servido a todos os disparos, logo os números nele são ilustrativos — o cliente cujo desvio real é de 6% receberia um e-mail com imagem mostrando 18%, contradizendo o texto ao lado. Quem vê isso não conclui "a imagem é genérica", conclui que o sistema erra; e um alerta existe precisamente para ser confiável. Regra vigente: o e-mail avisa, o sistema mostra — dado real vive onde o cliente entra para ver. O slot ET5 sai da dataviz e volta ao `seed-email.md` SEM REGRA NOVA: o EC5 já determina ícone raster sob demanda, rasterizado do SVG normalizado quando um template o pede, em `/email/v1/icones/`; um template de alerta pedindo glifo de alerta é o caso previsto, e o DM8 havia contornado essa lei ao especificar um PNG de conteúdo. Descartado: gráfico gerado por usina no envio — não por mérito, mas por domínio, já que o DM10 pôs comportamento dependente de dado vivo no produto. Registro material: o PNG `seed-email-et5-grafico@2x.png` (1120×520 @2x, 28.441 B, MD5 `f2ad29b3a8075da85c67f157399711fd`) chegou a ser produzido, com fonte SVG e gerador, e foi descartado sem subir ao R2 — fica anotado que existiu para que ninguém o ache num diretório de trabalho e o suba supondo propagação pendente. O DI19 permanece válido quanto ao caminho e muda de objeto. Lição de método: a spec do DM8 foi escrita sem perguntar de quem é o dado que a peça mostra — a pergunta que o gate fez em dez segundos e que teria evitado a produção inteira.
0.12	2026-08-11	DI-b FECHADO por prova impressa física. O sub-bloco DI está completo e a Fase 5 fica a um sub-bloco do marco. (1) Produzida a folha de prova de 7 itens (`seed-dataviz-di-prova-impressa.pdf`, A4 retrato com orientação declarada em CSS, 3 páginas, questionário de 6 perguntas na última) e impressa pelo Rafael duas vezes na mesma impressora física, em cor e em escala de cinza pelo driver. (2) Veredito do DI3: o modo de impressão NÃO entra no gatilho da textura, porque não precisa. Em cor as 6 séries se distinguem — textura ali seria o ruído que derrubou o DG11. Em mono, que é grayscale por definição, o gatilho do DI2 já dispara com 6 séries. Descartado: acrescentar "impresso" como terceira condição — redundante e pior, porque regra duplicada é o que deriva quando uma das duas é editada e a outra não, a classe de defeito das erratas E12/E14/E16. O item 1 da folha era controle, não caso de uso: 6 séries sem textura em cinza é situação que a regra vigente já proíbe, e falhou como previsto. A prova validou a regra existente no meio em que ela nunca havia sido testada, em vez de pedir regra nova. (3) Os dois pares que colapsaram a olho são exatamente os dois previstos: "Fora de ponta" ≈ "Bombeamento" (`cat-1 × cat-4`, 56% × 55%) e "Reservado" ≈ "Iluminação" (`cat-3 × cat-5`, 49% × 50%), ambos a 1 ponto — zero falso positivo e zero falso negativo em 15 pares. (4) SUPERSEDE da regra do piso, e é o achado mais valioso do sub-bloco: ela dizia que o piso decide só no contexto em que foi calibrado, e foi lida como meio novo exige calibração nova — foi por isso que o DI3 nasceu prevendo piso próprio para papel. A variável nunca foi o meio, foi a FORMA. No DM11 eram bandas finas de medidor a 9/8/17 pontos, indistinguíveis na tela; aqui são barras altas adjacentes, a forma em que o piso foi calibrado, e o instrumento acertou no papel. Forma diferente + mesmo meio → erra; mesma forma + meio diferente → acerta. Regra vigente: o piso é calibrado por forma e vale para aquela forma em qualquer meio; forma nova (banda, fatia fina, célula de heatmap) exige recalibração por gate mesmo no meio de sempre. (5) As 6 texturas se distinguem no papel em escala de cinza — o vocabulário estendido a 6 posições da v0.10 sobrevive ao impresso. (6) DI6 fechado sem piso próprio: as quatro espessuras (2 · 1,5 · 1 · 0,5px) saíram distintas na impressão física, nenhuma sumiu nem engordou; a hierarquia de traço vale igual no papel. (7) Fronteira do instrumento, por crítica do Rafael: a régua mede sobrevivência, não adequação — espessura isolada com rótulo abstrato responde "a impressora deposita?" e não "é adequada aqui?"; a segunda pergunta exigiria as espessuras aplicadas no gráfico. Achado colateral: o piso de 0,5px não tem consumidor — a grade do preview do DG está toda em 1px, e valor que existe na lei sem ser exercido deriva; a verificar na Fase 6. Pendente do lote: PNG @2x do ET5 e a edição do MANIFESTO que ancora a folha de prova, o preview do DI v0.3, a suíte do DI e este arquivo.
0.11	2026-08-11	O DI4 sai de inferência para fato medido, e nasce a suíte do sub-bloco DI. (1) Gate de impressão do Rafael (Chrome, "Salvar como PDF", A4): a matriz de quatro células do preview do DI devolveu C sumiu · D sobreviveu com "Gráficos de segundo plano" desmarcado — `background-color` de CSS desaparece quando nada o protege, `fill` de SVG sobrevive por ser conteúdo desenhado. Regra do DI4 provada como escrita (§4c.4). Segundo achado não previsto: a célula A sobreviveu, ou seja, o Chrome honra `print-color-adjust: exact` mesmo contra a preferência desmarcada — há duas camadas de proteção e elas não valem o mesmo; a regra dura do DS continua sendo a estrutural, porque a de CSS é documentadamente uma dica. Fronteira declarada: um navegador, um destino; Firefox e driver físico não medidos. (2) Erro de método registrado: a v0.1 do preview tinha duas células e não isolava a variável, porque a folha de impressão declara `exact` num seletor universal e protegia os dois braços do próprio teste — a primeira rodada devolveu um resultado verdadeiro que respondia outra pergunta. (3) Preview do DI chega à v0.3 e a `suite-dataviz-di.mjs` nasce com 32 verificações, cobrindo DI4, DI5, DI6, o modo de impressão forçado ao claro, as cinco partes do DG1 no exemplo, o guia de integração e a higiene de tokens; rodada contra a v0.1, reprova em 4 — as guardas são reais. (4) Errata E17: `vector-effect` não é herdada (SVG 2 a define como Inherited: no), então declará-la num `<g>` é inócuo; o preview do DG sempre aplicou por seletor universal e o do DI copiou o conceito da lei do §4.6 sem copiar a implementação que a torna verdadeira. (5) Dois defeitos de papel achados pelo gate e que nenhuma automação veria: uma `.nota` partindo entre páginas (o `break-inside: avoid` cobria só os blocos longos) e as células do teste com áreas diferentes (o SVG preservava a proporção do viewBox). Padrão que se repetiu três vezes neste lote e vale como regra: quando um teste e o comportamento discordam, quase sempre é o teste que está olhando para o lugar errado — aconteceu no `DG7-03`, no `contraste-dg.py` e no `DI6-02`. Pendente: PNG @2x do ET5 e a folha de prova do DI-b (o gatilho da textura no papel, que segue ABERTO — o gate de impressão desta versão mediu o DI4, não o DI3).
0.10	2026-08-11	Lote de produção do DI-a. Nenhum gráfico novo e nenhum tipo novo: o DI não cria gráfico, cria comportamento. (1) Vocabulário de textura do DG13 ESTENDIDO de 4 para 6 posições (linhas verticais na 5, diagonal a 135° na 6 — nunca 45°, que é exclusiva do `chart-no-data`), aprovado no gate de 2026-08-11. A lacuna existia desde sempre e era invisível porque o gatilho antigo nunca foi exercido contra um gráfico de 5 ou 6 séries. (2) `seed-tokens.md` vai a v1.7 com o token novo `chart-no-data-hatch` (cinza-600 / cinza-400), fechando a errata E13; os três gêmeos foram editados na mesma edição e o `paridade-tokens.py` fecha em 50 PASS · 0 FAIL. (3) `contraste-dg.py` reescrito (v2, DI18): mede o DG14 em vez do DG11 morto, as seis séries da v1.5 em vez de três, e opera o portão do DI2 varrendo todos os pares para 2…6 séries nos dois modos — 38 PASS · 0 FAIL · 20 MITIGADO · 4 ISENTO. Fecha a pendência P8. (4) Preview do DG a v1.4 com a E11 corrigida (a pizza de 5 séries passa a texturizar), o gatilho DI2 implementado por atributo `data-series` no `<figure>` — para a condição ficar auditável no DOM e não escondida em JS —, os patterns `tex-s5`/`tex-s6` e a hachura no token novo. (5) A suíte ganha a seção que o §6 dizia existir e não existia (errata E12): 11 verificações `TEX-` + 2 `NEU-`, levando o placar de 163 a 176 PASS · 0 FAIL. Prova de que a guarda é real: rodada contra o preview v1.3 antigo, ela reprova em 4. Oito erratas E9–E16 (§5), três delas de uma classe nova — correção declarada que não foi inteiramente aplicada: a E14 mostra que a E3 trocou a tinta da hachura só no swatch da legenda, deixando os dois `<pattern>` SVG em violeta desde a v1.5; a E15 acha a terceira ocorrência da mesma armadilha na série "Esperada"; a E16 mede 19 tokens semânticos derivados no bloco embutido do preview e os corrige por script a partir do canônico — a guarda que a E4 havia pedido — e de quebra explica a E8, porque a §3c copiou o fundo de referência dark do preview em vez de copiar do token. Regra de método que sai do lote: correção de errata se verifica pela medição do que ela prometia consertar, não pelo fato de o arquivo ter mudado. Percalço de produção registrado: a primeira edição do CSS dos tokens usou `replace` de texto e a linha indentada a 2 espaços casou dentro da indentada a 4, dentro do `@media (prefers-color-scheme: dark)`, duplicando uma declaração fora de qualquer seletor; pego na leitura de volta e refeito por regex de linha inteira. Guarda que fica: edição cirúrgica de CSS por `replace` de texto é insegura quando o mesmo token existe em blocos de indentação diferente — o casamento tem de ser ancorado na linha. Pendente: gate visual do preview v1.4, preview do DI, PNG do ET5 e a edição do MANIFESTO (que fecha E9, E10, P8 e P4-b).
0.9	2026-08-11	Sub-bloco DI escrito — §4c, DI1–DI19 — em duas partes: DI-a `estável` e DI-b aberto. Consolidado aprovado pelo Rafael após 4 rodadas encadeadas (a 4ª disparada por regra: impresso é domínio novo para o projeto). O achado central não estava no roteiro: ao remedir a premissa represada no §5 ("o claro tem 7 pontos de espalhamento"), descobriu-se que o número era da categórica v1.0 com três séries; com as seis posições da v1.5 o pior par no modo claro mede 1 ponto (`cat-1 × cat-4` e `cat-3 × cat-5`; claridades 56/75/49/55/50/27). O modo claro é seguro até três séries e colapsa a partir da quarta — fato de tela, anterior a qualquer discussão sobre papel. Daí o DI2, supersede formal do gatilho do DG13, que passa de "escuro ∩ grayscale" para `grayscale ∩ (escuro OU ≥4 séries)`, e a errata E7 contra a redação anterior do §5. Por que o defeito sobreviveu dois sub-blocos: o `contraste-dg.py` percorre apenas `cat1/cat2/cat3` — o detector estava recortado no lugar onde o defeito não mora; a pendência P8 do `MANIFESTO.md` deixa de ser higiene e passa a ser guarda ausente (reescrita especificada no DI18). Decisões de impresso: DI1 separa os dois destinos (laser de escritório = escopo; offset da gráfica, que exige PDF/X-1a em CMYK e declara variação de ±10% na cor dentro do mesmo lote = Fase 7) · DI4 proíbe informação de gráfico em `background-color` de CSS, porque `print-color-adjust: exact` é dica e a preferência do usuário no diálogo de impressão vence — com a inferência complementar (o `fill` de SVG sobrevive por ser conteúdo) declarada como não medida e transformada em teste da folha de prova · DI5 `break-inside: avoid` no `<figure>` inteiro · DI6 piso de traço a calibrar no papel · DI7 o DS não converte para CMYK (evita um segundo lugar onde a cor mora, contra o DF7) · DI8 PDF/A não adotado: nada no arcabouço CONFEA/CREA exige formato, o PDF/A é recomendação do CONARQ para o setor público, e o PDF/A-1 admite apenas assinatura simples — colidiria com o PAdES da ICP-Brasil, que é o que dá validade jurídica ao laudo assinado · DI9 fotocópia sem regra própria, com gatilho · DI10 fronteira com a F7. Guia da stack (DI11–DI17): a cadeia tem quatro saltos, não três — o `fill` do Recharts consome `var(--color-CHAVE)` gerado pelo `ChartContainer`, nunca `--chart-N` direto; sintaxe v3 sem `hsl()`; tema por `[data-theme]` e não pelo objeto `theme` do `chartConfig`; `accessibilityLayer` obrigatório e insuficiente (não cobre 1.1.1 nem 1.3.1 — o invólucro DG1 permanece por cima). DI19 decide o caminho do PNG do ET5: `/email/v1/`, porque a imutabilidade daquele caminho proíbe substituir arte, não acrescentar — e fecha a P4-b junto. DI-b (DI3) fica ABERTO por método: o veredito do gatilho da textura no papel só sai de prova impressa real, com protocolo de 7 itens fechado no §4c.3. Erratas novas: E7 (acima) e E8 (a §3c do `seed-tokens.md` cita o fundo dark `#1C252B`; o token real é `#1D272D` — remedido, deltas ≤0,24, nenhum veredito muda). Pendente deste lote: preview do DI, suíte, `contraste-dg.py` reescrito, PNG do ET5 e a folha de prova impressa.
0.8	2026-08-11	Gate visual aprovado nos previews corrigidos — as v1.3/v0.8 passam a artefatos VIGENTES do DG e do DM. Mudança de estado apenas; nenhuma decisão de conteúdo. Fecha a janela de 2026-08-11, na qual a Fase 5 ganhou: a categórica ESTENDIDA `estável` (tokens v1.6), o redesenho DG14–DG17 formalizado, o sub-bloco DM escrito e promovido, a P6 aberta e fechada no mesmo dia, e as seis erratas achadas e corrigidas. Próximo sub-bloco: DI (impresso/PDF + integração da stack), com o `contraste-dg.py` a atualizar antes ou durante — ele ainda mede o DG11 e a paleta anterior à v1.5.
0.7	2026-08-11	As seis erratas E1–E6 corrigidas nos previews, que passam a `seed-dataviz-graficos-preview.html` v1.3 e `seed-dataviz-monitoramento-preview.html` v0.8 — na entrega, ambos `aguardando gate visual` (aprovado no mesmo dia, v0.8), porque correção de artefato aprovado não se auto-aprova e três das mudanças são visíveis (E1 medidores com `role="meter"`, E3 troca de cor do "esperado" e da hachura, E5 rótulo da pizza sai da fatia). Nenhuma decisão de spec muda nesta versão: as erratas eram divergências do PREVIEW em relação à spec, e a correção fez o artefato alcançar a regra que já existia. Sétimo ponto achado durante a correção, tratado dentro da E3: a hachura do `chart-no-data` desenhava as linhas em `cat-5-stroke` — mesma armadilha do ET5, no lugar mais sensível possível, já que "sem medição" é exatamente o que não pode parecer categoria; passou a `chart-axis`. Regra nova, generalizada a partir daí: posição categórica nunca serve de neutro — referência, contexto e ausência consomem token com papel declarado (`chart-no-data`, `chart-grid`, `chart-axis`, cinza de contexto do DG17), porque `cat-N` pode trocar de cor em qualquer supersede de paleta, como trocou na v1.5. Validação: DG 163 PASS · 0 FAIL; DM 105 PASS · 0 FAIL · 0 FAIL DOCUMENTADO (a suite ganhou v2.1 com dois falsos negativos corrigidos: exigia `aria-valuenow` do medidor SEM leitura, que legitimamente não o tem, e não resolvia o alias novo do "esperado").
0.6	2026-08-11	PROMOÇÃO: o sub-bloco DM passa de spec escrita a `estável`, por "aprovo" explícito do Rafael sobre o lote de formalização. A Fase 5 fica com DF, DT, DG e DM concluídos; restam DP e DI. Nenhuma decisão de conteúdo mudou nesta versão — é mudança de ESTADO mais os registros que a promoção obriga. Pendência P6 FECHADA no mesmo dia em que nasceu: os dois previews aprovados foram reanexados e conferidos por MD5 2/2 (gráficos v1.2 `8d1930…0fbf` · monitoramento v0.7 `f146c8…334c`), e as suites passaram de placar reproduzido a placar executado contra os artefatos reais — `suite-dataviz-dg.mjs` 163 PASS · 0 FAIL e `suite-dataviz-dm.mjs` v2: 85 PASS · 0 FAIL · 6 FAIL DOCUMENTADO. Seis erratas E1–E6 medidas (§5), todas nascidas de rodar a automação contra o artefato depois do gate humano: `role="meter"` ausente no preview do DM (E1 — o DM4 não chegou a ser exercido no gate), sparkline a 1,6px contra os 2px que o próprio arquivo declara (E2), ET5 "esperado" em `cat-5` que a v1.5 transformou em violeta (E3 — primeira consequência colateral medida de um supersede de paleta), deriva de 4 primitivos nos dois previews (E4 — nenhum veredito muda, deltas ≤1 ponto, mas prova que o bloco de tokens foi digitado e não copiado), rótulo interno da pizza a 4,30 (E5) e os dois arquivos declarando "v0.1" no próprio título (E6 — a identificação positiva por leitura do MANIFESTO §3.1 não funciona neles). Lição de método registrada na suite: a v1 da `suite-dataviz-dm.mjs`, escrita contra uma reconstrução enquanto o artefato estava ausente, produziu 26 FAIL no artefato real — 23 eram premissa da suite (ela codificava os NOMES da reconstrução como se fossem spec) e só 3 eram desvio genuíno. Suite escrita contra reconstrução testa a reconstrução; a v2 testa a mesma spec pelo COMPORTAMENTO (o alias resolve para cinza? o gatilho exige as duas condições?), não pelo seletor.
0.5	2026-08-11	Lote de formalização da F5 — o material aprovado nos gates de 2026-08-10 sai da conversa e entra no canônico. (1) Redesenho DG14–DG17 (§4.6, "gráfico de produto"): DG14 supersede o DG11 (zero contorno; vão de 2px como espaço negativo; possível porque a categórica v1.5 passa 3:1 sozinha); DG15 geometria orgânica (rx=3 universal, pílula em ranking, curva monótona Fritsch–Carlson 2px, gradiente 22%→0) + guarda DG15b (raio consistente — defeito achado pelo olho do Rafael, não pela regex); DG16 palco mínimo (≤3 gridlines, sem linha de eixo, número protagonista, badge-pílula, ponto de status com rótulo); DG17 destaque×contexto. Duas leis transversais: hierarquia de traço (2/1/0,5px + meta 1,5px como exceção + `vector-effect: non-scaling-stroke` obrigatório — viewBox escalam 0,66×–12,4× medidos) e consumo da categórica estendida (5 famílias distintas até 5 séries; 6ª posição única exceção; teto 6; regra do dourado; ordem 2↔3 decidida no gate pelo peso do dourado). (2) Sub-bloco DM escrito por extenso (§4b, DM1–DM11): bullet graph canônico (Few/Cleveland–McGill), anatomia de 6 partes, DM3 papéis invertidos (supersede na §3c), `role="meter"`+`aria-valuetext` via useMeter (descartados `<meter>` nativo e progressbar), sparkline de Tufte com contrato decorativo DM6, DM7 rótulo de estado sempre visível, DM8 fecha o slot ET5 (PNG @2x 560px no R2), DM9 no-data nunca vira zero, DM11 textura de banda no gatilho do DG13 — com o registro de que o piso de 6 pontos não transfere de contexto (bandas a 9/8/17 seguiam indistintas; emenda no DG13). 4 defeitos de produção viraram guarda (variáveis órfãs, DM7 ausente, overflow de viewBox detectável só por `getBBox` em navegador real, acentos). Estado do DM: `aguardando aprovo do lote`. (3) Emendas: DG5-b remedido para a paleta v1.5 (interno só em cat-2/cat-6; errata do "45%" latente no preview), DG10-b com racional supersedido e teto mantido, DG12 restrito ao rótulo + exceção do DM. (4) Achados da formalização: previews aprovados AUSENTES do Drive (alvos MD5 registrados; pendência P6) · deriva de 5 hex nos previews vs canônico (ancoragem nos stops reais, veredito idêntico) · GI2 do colapso dark CUMPRIDA na §3c v1.5. Suite do DG na versão final: 163 verificações.
0.4	2026-08-09	Sub-bloco DG (gráficos core) `estável` — 13 decisões, §4 nova. Sete tipos (barra, empilhada, agrupada, linha, área, pizza, dispersão) mais os três estados herdados do Bloco 3. Consolidado aprovado após 3 rodadas encadeadas de pesquisa, com duas emendas durante a produção: a barra empilhada foi puxada para dentro do escopo a pedido do Rafael (caso real: consumo por posto tarifário), trazendo junto a agrupada como saída obrigatória; e o DG13 (textura) nasceu do gate. Três regras nasceram da medição, não do consolidado: DG11 (contorno `cinza-900` — o fill categórico reprova sozinho contra o fundo claro), DG12 (tinta sobre dado não segue o tema — o fill é claro nos dois modos) e DG13 (textura na interseção escuro+grayscale). O gate levou o preview da v0.1 à v0.5, e os dois achados decisivos foram do olho do Rafael: o colapso das séries em cinza no modo escuro, e o escopo exato do gatilho da textura. Correção de instrumento registrada: o portão de grayscale media razão de contraste WCAG e reprovava o modo claro, onde o gate humano lia bem — foi trocado por espalhamento de claridade, com piso declarado como calibrado pelo gate e não derivado de norma. Validação: jsdom 147/0 · contraste 32 PASS · 0 FAIL · 14 MITIGADO · 4 ISENTO · render puppeteer 6 cenários (matriz tema × grayscale × largura, agora cruzada e não amostrada — a versão anterior não gerava escuro+grayscale, que era exatamente onde o defeito morava).
0.3	2026-08-09	PROMOÇÃO: DF e DT passam de `rascunho` a `estável`, após "aprovo" explícito do Rafael no gate visual do preview `seed-dataviz-tokens-preview.html` v0.2 completo (2ª rodada do gate; a 1ª aprovara só a escala A sobre o preview comparativo). Nenhuma decisão de conteúdo mudou nesta versão — a v0.3 é mudança de ESTADO mais os registros que a promoção obriga. Junto: validação reproduzida na janela (29 PASS · 3 FAIL, os 3 documentados do fill em traço fino) e cruzamento §3c×gêmeos (26/26 hex batem). Débito dos gêmeos ENCERRADO — `seed-tokens.json`/`.css` regenerados para v1.4, e a execução revelou que a defasagem era de duas versões (faltava todo o pacote mobile v1.2), não uma; nasceu daí a guarda `paridade-tokens.py`. `MANIFESTO.md` v1.2 ancora os artefatos da F5.
0.2	2026-08-09	Achado do gate visual do Rafael na escala sequencial: os stops 50/100 da proposta original liam como cinza — ambíguos com "sem dado". Correção aprovada (opção A sobre preview comparativo): escala desloca para 100→900 (light) / 800→100 (dark), e nasce o token `chart-no-data` (cinza exclusivo de "sem medição", sempre hachurado). Alternativa B descartada (manter 50→800 e resolver só por regra — a leitura-cinza permaneceria). Valores e supersede na §3c do `seed-tokens.md` v1.3. Bug de regressão corrigido no `contraste-dataviz.py` (seção do gauge media os stops rejeitados, não os canônicos).
0.1	2026-08-09	Primeira entrega da Fase 5. Nasce o 9º canônico com o fundamento DF1–DF7 (consolidado aprovado pelo Rafael em 2026-08-09 após 3 rodadas: R1 canon interno · R2 mercado/stack shadcn Chart+Recharts v3 · R3 normas WCAG 1.4.1/1.4.11/1.4.3) e o registro do sub-bloco DT, cujos valores vivem no `seed-tokens.md` v1.3 §3c (DF7: uma fonte). Medição prévia corrigiu 2 propostas de gauge e originou a variante `cat-N-stroke`. Estado: `rascunho`, aguardando gate visual do preview de tokens.

Arquivo canônico do Design System v2 da SEED engenharia. Produzido por Claude sob direção de Rafael Sant'Ana. Nada aqui é promovido a estável sem aprovação explícita após gate visual.