4c. Sub-bloco DI — impresso/PDF + integração da stack

Estado: o sub-bloco DI está COMPLETO — estável em 2026-08-11. Foi produzido em duas partes, por decisão de método: DI-a (DI1–DI2, DI4–DI19) fechou pelo "aprovo" do Rafael sobre o consolidado, e DI-b (DI3 — o veredito do gatilho da textura no papel) ficou deliberadamente aberto até haver prova impressa física, porque não se responde por análise. A prova foi executada e o DI-b fechou no mesmo dia (§4c.3): o impresso não entra no gatilho, e a medição produziu um supersede da própria regra do piso de claridade, que passa a ser calibrada por forma e não por meio.

Base: 4 rodadas encadeadas (R1 canon interno: §5 e §4.4 deste arquivo, §3c do seed-tokens.md, §44/GI1–GI5 do seed-componentes.md · R2 mercado/stack: fornecedor gráfico real da SEED, doc oficial do shadcn Chart sobre Recharts v3, print-color-adjust no MDN e no comportamento real dos navegadores · R3 normas: Lei 6.496/77 e Resolução CONFEA 1.137/2023, Resoluções e Orientação Técnica 4 do CONARQ, políticas PAdES da ICP-Brasil sob a IN 34/2025, ISO 12647-2:2013 · R4, disparada porque impresso é domínio novo para este projeto: comportamento de meio-tom e linha mínima em impressora laser).

Siglas usadas aqui, explicadas na primeira ocorrência. CTP = computer-to-plate, o processo pelo qual a gráfica grava a chapa de impressão direto do arquivo digital. TVI = tone value increase, o nome normativo do "ganho de ponto" (a mancha de tinta que engorda o ponto impresso em relação ao arquivo). PAdES = PDF Advanced Electronic Signatures, o padrão de assinatura digital embutida em PDF adotado pela ICP-Brasil. ART = Anotação de Responsabilidade Técnica, o documento que vincula legalmente o engenheiro ao serviço.

4c.0 O achado que reabriu o DG13 — remedição de 2026-08-11#

A pendência que este sub-bloco herdou do §5 dizia que o modo claro tinha 7 pontos de espalhamento de claridade, acima do piso de 6, e que a dúvida era apenas se o papel justificaria baixar esse piso. A remedição mostrou que a premissa estava velha: os 7 pontos foram medidos na categórica v1.0, com três séries. A categórica ESTENDIDA v1.5 tem seis, e as seis nunca foram medidas juntas neste instrumento.

Medição com a mesma função do contraste-dg.py (claridade = luminância relativa em codificação gama, em pontos percentuais), modo claro, que é o modo que vai ao papel:

Piores pares, em qualquer adjacência: cat-1 × cat-4 = 1 ponto · cat-3 × cat-5 = 1 ponto · cat-4 × cat-5 = 5 pontos. Com três séries (cat-1/2/3) o pior par é 7, e a medição antiga estava correta na data em que foi feita.

Conclusão que o número obriga: o modo claro não é seguro em escala de cinza. Ele é seguro até três séries. A partir da quarta, o claro colapsa como o escuro sempre colapsou — e isso é um fato de tela, anterior a qualquer discussão sobre papel.

Por que ninguém tinha visto. O contraste-dg.py percorre apenas cat1, cat2 e cat3 — exatamente o trio que passa. O detector estava recortado no lugar onde o defeito não mora. Isso reclassifica a pendência P8 do MANIFESTO.md: atualizar aquele script não é higiene de manutenção, é restaurar a única guarda automatizada capaz de flagrar esta classe de erro. A correção está no DI18.

4c.1 DI1 — Dois destinos de impressão; só um é escopo do DI#

Fato apurado sobre o fornecedor real (Zap Gráfica, o parceiro da SEED): o fluxo dela é CTP e exige PDF/X-1a, com todos os elementos convertidos em CMYK — arquivos entregues em RGB podem ter a cor alterada ou simplesmente não impressa. A gráfica também declara variação de ±10% na cor, para mais ou para menos, dentro do mesmo lote de produção.

Consequência declarada: essa tolerância é incompatível com qualquer informação codificada por diferença fina de cor — mas é irrelevante para o laudo, que nunca passa pelo CTP da gráfica. É por isso que o DI trata os dois destinos como problemas diferentes em vez de buscar um pipeline único.

Alternativa descartada: adotar CMYK como saída única de todo impresso da empresa. Obrigaria conversão de cor em todo laudo gerado pelo ERP, com perda de gama e sem nenhum ganho, já que o destino real daqueles PDFs é uma impressora de escritório.

4c.2 DI2 — SUPERSEDE do gatilho do DG13: o gatilho é função do número de séries#

Regra antiga (DG13, §4.4): textura por série apenas na interseção escuro ∩ grayscale.

Regra vigente: textura por série quando grayscale ∩ (escuro OU ≥4 séries).

Racional medido: §4c.0. O DG13 nasceu correto sobre a evidência que tinha — três séries, 7 pontos de folga no claro. A categórica v1.5 dobrou o número de posições sem que o gatilho fosse remedido, e nos pares cat-1 × cat-4 e cat-3 × cat-5 a folga caiu para 1 ponto. O que muda não é o meio (tela × papel): é a densidade da paleta em uso.

O que permanece intocado: o vocabulário de textura do DG13 (série 1 sólida · 2 pontilhada · 3 quadriculada · 4 linhas horizontais), a exclusividade da diagonal a 45° para o chart-no-data, a obrigação de a legenda repetir a textura sob o mesmo gatilho, e a isenção do gráfico de série única.

Alternativas descartadas:

• Manter o DG13 como está e apenas somar o modo de impressão. Fecharia a pergunta do papel deixando aberto um colapso de tela já medido — a definição de verde enganoso.
• Texturizar sempre, em todo modo. O gate visual de 2026-08-09 já reprovou esse desenho ("ligar textura onde a cor já resolve" é ruído), e a regra de 3 séries continua verdadeira.
• Baixar o piso de 6 para 1 ponto. Trocaria um limiar calibrado por gate humano por um número escolhido para caber na paleta — inverteria a ordem entre instrumento e evidência.

4c.3 DI3 — O impresso NÃO entra no gatilho da textura, porque não precisa (DI-b FECHADO)#

Estado: FECHADO em 2026-08-11, por prova impressa física executada pelo Rafael. Esta seção substitui integralmente a redação anterior, que declarava o veredito ABERTO e previa que o papel exigiria piso próprio de claridade. A previsão estava errada, e o modo pelo qual ela errou é o achado mais valioso do sub-bloco — ver a correção da regra do piso no fim desta seção.

Veredito. O modo de impressão não é acrescentado ao gatilho do DI2. O gatilho permanece grayscale ∩ (escuro OU ≥4 séries), exatamente como o DI2 o escreveu, e cobre o impresso sem uma palavra nova.

Como a medição chegou a isso, por eliminação:

Alternativa descartada: acrescentar "impresso" como terceira condição do gatilho. Seria redundante e pior: criaria duas regras dizendo a mesma coisa, e regra duplicada é precisamente o que deriva quando uma das duas é editada e a outra não — a classe de defeito das erratas E12/E14/E16 desta mesma fase.

O item 1 da folha era um CONTROLE, não um caso de uso. Ele mostra 6 séries sem textura em cinza, situação que a regra vigente já proíbe. Ele falhou como previsto. A prova não pediu regra nova: validou a regra existente no meio em que ela nunca havia sido testada.

Os dois pares que colapsaram são exatamente os dois pares previstos#

Nenhum falso positivo, nenhum falso negativo. Os outros 13 pares tinham folga na medição e foram todos distinguidos. O instrumento — espalhamento de claridade em pontos percentuais, calibrado em tela — previu o comportamento do papel com precisão de par a par.

SUPERSEDE da regra do piso: ele é calibrado por FORMA, não por MEIO#

A regra vigente até aqui, nascida da emenda da v0.5 e do DM11, dizia: "o piso de 6 pontos decide apenas no contexto em que foi calibrado — barras altas adjacentes, modo claro, em tela; fora dali quem decide é o gate". Ela foi escrita depois que as bandas do medidor mediram 9, 8 e 17 pontos, todas acima do piso, e ainda assim eram indistinguíveis. A leitura natural foi que meio novo exige calibração nova, e foi por isso que o DI3 nasceu prevendo piso próprio para o papel.

A prova impressa mostra que a variável nunca foi o meio — foi a FORMA. Compare os dois episódios:

Forma diferente, mesmo meio → erra. Mesma forma, meio diferente → acerta.

Regra vigente, mais precisa e mais útil que a anterior: o piso de claridade é calibrado por forma de apresentação e vale para aquela forma em qualquer meio. Mudar de tela para papel não invalida o número; mudar de barra alta adjacente para banda fina de medidor invalida. Ao encontrar uma forma nova — banda, fatia fina, célula de heatmap, faixa de sparkline — o piso tem de ser recalibrado por gate mesmo que o meio seja o de sempre.

Por que isso importa mais que o veredito: a regra anterior mandava recalibrar a cada meio novo, o que é caro e, como se vê, desnecessário. A nova manda recalibrar a cada forma nova, que é onde o risco realmente mora — e explica os dois episódios em vez de um só.

Fronteira: a folha de prova mede sobrevivência, não adequação#

Crítica do Rafael no gate, registrada porque é correta e limita o instrumento: a régua do item 6 mostra as espessuras isoladas, com rótulos que só significam algo para quem já conhece a hierarquia. Uma régua abstrata responde "a impressora consegue depositar esta linha?" — e não responde "esta espessura é adequada aqui?". A segunda pergunta exige as espessuras aplicadas no gráfico (linha de série, linha de meta, eixo, grade). A folha v0.1 responde a primeira, que era o que o DI6 precisava; se a segunda pergunta for feita algum dia, a folha precisa ser refeita.

Achado colateral: o piso de 0,5px não tem consumidor hoje — a grade do preview do DG está toda em 1px. É um valor que existe na lei e não é exercido, e valor não exercido deriva. A verificar quando a Fase 6 montar painéis, onde grade fina em gráfico pequeno é o caso natural para ele.

4c.4 DI4 — Nenhuma informação de gráfico pode viver em background-color de CSS#

Fato apurado, não inferência: a propriedade print-color-adjust: exact é uma dica ao navegador, e a preferência do usuário no diálogo de impressão ("Gráficos de plano de fundo", "Background graphics") tem precedência — nenhuma folha de estilo a sobrepõe. Um laudo impresso por alguém que nunca abriu "Mais configurações" sai com todo background ausente.

Regra dura que sai daí: toda superfície que carrega dado é elemento de conteúdo do SVG — <rect>, <path>, <circle> com atributo fill —, nunca um <div> pintado por background-color. Vale para barra, área, fatia, banda de medidor, célula de heatmap e o chart-no-data. O print-color-adjust: exact continua declarado na folha de impressão, como reforço, e nunca como garantia.

A inferência foi MEDIDA e virou fato — gate de impressão de 2026-08-11. A v0.1 do preview do DI trazia esta regra como inferência não medida. A v0.2 montou uma matriz de quatro células — background-color × fill de SVG, cruzados com print-color-adjust: exact × economy — e o Rafael a imprimiu no Chrome, destino "Salvar como PDF", A4, nas duas posições da opção "Gráficos de segundo plano".

Célula	O que é	Opção MARCADA	Opção DESMARCADA
A	CSS background · exact	sobreviveu	sobreviveu
B	SVG fill · exact	sobreviveu	sobreviveu
C	CSS background · economy	sobreviveu	SUMIU
D	SVG fill · economy	sobreviveu	sobreviveu

C sumiu e D sobreviveu sob condição idêntica — mesma cor, mesma área, mesma célula da matriz, única diferença sendo como a superfície é pintada. O DI4 está provado como escrito.

Segundo achado, não previsto: a célula A sobreviveu, isto é, o Chrome honrou print-color-adjust: exact mesmo contra a preferência desmarcada. Existem portanto duas camadas de proteção, e elas não valem o mesmo: a dica de CSS, que funcionou aqui, e a natureza estrutural do SVG, que não depende de navegador. A regra dura do DS continua sendo a segunda, porque a primeira é documentadamente uma dica.

Fronteira da medição, declarada: um navegador (Chrome), um destino ("Salvar como PDF"). Não medido em Firefox nem em driver de impressora física, e o Firefox tem histórico de divergir neste ponto. Vale como fato para o Chrome e forte indício para o resto.

Erro de método registrado, porque é instrutivo: a v0.1 do preview tinha só duas células e não isolava a variável — a folha de impressão declara exact num seletor universal, que protegia os dois braços do próprio teste. A primeira rodada devolveu "os dois sobreviveram", resultado verdadeiro que respondia outra pergunta. Só a matriz de quatro, com o controle sobrescrevendo para economy por especificidade de classe, isolou o que interessava.

4c.5 DI5 — O <figure> do gráfico nunca se parte entre páginas#

break-inside: avoid aplicado ao <figure> inteiro, não a partes dele. Motivo: o DG1 define o gráfico como um conjunto de cinco partes (título em figcaption, descrição curta, fallback textual, legenda e a área de dado com role="img"). Se a paginação separa a legenda da área de dado, o leitor perde a chave de leitura na virada da folha — e o fallback textual, que existe para ser a alternativa acessível, vira um parágrafo órfão sem referente visível.

4c.6 DI6 — Traço no papel: o piso é do papel, não da tela#

A escala já está resolvida: vector-effect: non-scaling-stroke é obrigatório em todo SVG de gráfico (lei transversal do §4.6), e sem ele o mesmo stroke-width=1 renderizaria entre meio pixel e doze, porque os viewBox do sistema escalam de 0,66× a 12,4×.

O que não está resolvido é o piso físico. A hierarquia canônica é dado 2px · estrutura 1px · apoio 0,5px · marca de meta 1,5px. O candidato a falhar no papel é o apoio de 0,5px: a referência de ordem de grandeza levantada na R4 é que uma impressora laser não deposita linha abaixo de aproximadamente três a quatro vezes o seu ponto nominal, o que aproxima o apoio do limite mesmo em equipamentos de resolução alta. Número declarado como referência de literatura, não como medição da SEED — a régua de traço da folha do DI3 é que produz o número nosso.

4c.7 DI7 — O Design System não converte para CMYK#

Os hex canônicos permanecem RGB. A conversão para CMYK é responsabilidade do fluxo da gráfica, na Fase 7, com prova de cor contratada.

Racional: criar uma tabela CMYK aqui criaria um segundo lugar onde a cor mora, contra o DF7 ("tokens de dado têm UMA fonte"), e o consumidor real desse valor não existe hoje — o laudo, que é o impresso que a empresa de fato produz, sai por impressora de escritório, que recebe RGB e converte sozinha.

Alternativa descartada: gêmeo CMYK dos tokens. Levaria a unidade seed-tokens.md + .json + .css a quatro arquivos que precisam mudar juntos, quadruplicando a superfície que o paridade-tokens.py precisa guardar, para servir um consumidor hipotético.

Duas regras do fornecedor ficam registradas desde já, para a F7 não redescobri-las: o preto de texto deve ser K 100% puro (a gráfica não se responsabiliza por material enviado com preto composto, que causa decalque e variação); e o preto de área grande, quando se quer um preto profundo, é C 50% M 50% Y 40% K 100%.

4c.8 DI8 — PDF/A não é adotado; o laudo sai em PDF comum, assinável em PAdES#

Pesquisa normativa fechada, com o resultado negativo declarado: não existe exigência de formato de arquivo para laudo técnico de engenharia no arcabouço CONFEA/CREA. A Lei 6.496/77 e a Resolução CONFEA 1.137/2023 tratam da ART, do acervo técnico e da validade da assinatura eletrônica — nunca do formato do documento. O PDF/A (ISO 19005) é recomendação do CONARQ para preservação de longo prazo, dirigida aos órgãos e entidades do Sistema Nacional de Arquivos, isto é, ao setor público; a SEED não integra o SINAR.

E há um conflito técnico real, que é o argumento decisivo: a Orientação Técnica 4 da Câmara Técnica de Documentos Eletrônicos do CONARQ registra que o PDF/A-1 admite apenas assinatura digital simples. Isso colide frontalmente com o padrão PAdES da ICP-Brasil — cujas políticas foram republicadas pela Instrução Normativa 34/2025 do ITI, nas variantes AD-RB, AD-RT, AD-RC e AD-RA —, que é justamente o que confere validade jurídica plena a um laudo assinado. Adotar PDF/A-1 seria trocar validade jurídica por conformidade de arquivamento que ninguém exige.

Decisão: PDF comum, com assinatura PAdES quando o laudo exigir responsabilidade técnica formal.

Gatilho de revisão declarado: se um contrato, cliente ou órgão exigir PDF/A por escrito, reavaliar com PDF/A-2 ou PDF/A-3, que admitem assinatura avançada — nunca PDF/A-1.

4c.9 DI9 — Fotocópia e fax: sem regra própria, com gatilho declarado#

Evidência de campo do Rafael: fotocópia de laudo é rara a ponto de ele não lembrar da última vez. A rede de proteção para esse caso já existe e é herdada, sem custo novo: o fallback textual obrigatório do DG1, o rótulo textual de estado sempre visível do DM7 e a hachura diagonal exclusiva do chart-no-data. Nenhuma regra nova é criada.

Gatilho: se a fotocópia passar a ocorrer com regularidade em algum fluxo (concessionária, cartório, cliente), o caso entra com medição própria — e a fotocópia em preto e branco é, por construção, um caso de grayscale, portanto já coberto pelo gatilho do DI2 a partir de quatro séries.

4c.10 DI10 — Fronteira com a Fase 7 (colateral físico)#

O DI entrega o comportamento da dataviz no papel: gatilho de textura, folha de estilo de impressão, paginação do <figure>, piso de traço e a decisão de formato do arquivo. A Fase 7 entrega tudo o mais que o papel exige da marca: formato, gramatura, acabamento, capa, papelaria e a conversão de cor para o fluxo da gráfica (DI7). Linha declarada para não ser invadida em nenhuma direção.

4c.11 Guia de integração da stack — DI11–DI17#

Consumidor real e imediato: o ERP em Lovable (Vite + React + TypeScript + Tailwind + shadcn/ui + Supabase). O guia é o documento colável lá; este arquivo permanece agnóstico de biblioteca (DF2), e o guia é a ponte, nunca a lei.

DI11 — A cadeia tem quatro saltos, não três. O padrão GI1 do §44 do seed-componentes.md formalizou a cadeia de três camadas para componentes de UI (primitivos → semânticos --seed-* → aliases shadcn). Para gráfico existe um salto a mais, e ele é fácil de errar:

--seed-chart-cat-N   (token SEED, dono do valor)
      ↓
--chart-N            (alias que o shadcn Chart espera encontrar no CSS)
      ↓
chartConfig[chave].color = "var(--chart-N)"
      ↓
fill="var(--color-chave)"   ← o que o componente Recharts realmente consome

Fato da documentação oficial: o fill não referencia --chart-N. Ele referencia var(--color-CHAVE), uma variável que o ChartContainer gera em tempo de execução a partir do chartConfig. Pular o terceiro salto produz gráfico sem cor, sem erro no console.

DI12 — Sintaxe do Recharts v3. var(--chart-1), nunca hsl(var(--chart-1)). A forma com hsl() era o padrão do Recharts v2 e pressupunha tokens gravados como triplas de canal; os tokens SEED são hex, e o embrulho em hsl() produziria valor inválido — que em CSS significa cor ausente, e não erro.

DI13 — O tema vem do [data-theme], não do chartConfig. O chartConfig aceita um objeto theme: { light, dark } como alternativa às variáveis CSS. Descartado: duplicaria a cor dentro do TypeScript, criando uma segunda fonte de verdade dentro do produto e furando o DF7 e o GI1. Trocar o data-theme continua resolvendo o tema inteiro de uma vez.

DI14 — accessibilityLayer é obrigatório e insuficiente. A prop existe e entrega acesso por teclado e suporte a leitor de tela; deve ser ligada em todo gráfico. Ela não entrega alternativa textual (WCAG 1.1.1) nem relação codificada entre legenda e dado (1.3.1) — que são exatamente as duas reprovações da auditoria pública do shadcn Charts. O invólucro <figure> de cinco partes do DG1 permanece obrigatório por cima da prop. Sem ele, o produto herda a falha da biblioteca, e o guia de integração deixa de ser guia para virar veículo do defeito.

DI15 — ChartContainer sempre com altura. Ou height, ou min-h-*, ou aspect-*. Sem uma delas o ResponsiveContainer não consegue medir no primeiro render e o gráfico não aparece. Item de verificação do guia, não recomendação.

DI16 — Aliases de --chart-1 a --chart-6. O shadcn distribui cinco por padrão; o teto SEED é seis (DG). Acima disso o gráfico se reestrutura — agregação em "Outros", facetas, ou o par destaque × contexto do DG17 — e nunca ganha uma sétima cor.

DI17 — Contrato Lovable. O guia entrega: um bloco único colável em globals.css (Tailwind v4, via @theme) com os seis aliases apontando para os tokens SEED nos dois temas; um chartConfig de exemplo; e o wrapper <figure> do DG1 como componente em src/components/seed/, conforme o GI5 do §44.

4c.12 DI18 — Reescrita do contraste-dg.py (fecha a pendência P8 do MANIFESTO)#

O script vigente mede duas coisas mortas — o DG11 (contorno em cinza-900, supersedido pelo DG14) e a paleta categórica anterior à v1.5 — e, pior, percorre apenas três séries. A reescrita mede:

1. Ausência de contorno e o vão de 2px do DG14.
2. As seis séries da categórica v1.5, contra os fundos de referência declarados.
3. O gatilho do DI2, por varredura de todos os pares em cada número de séries de 2 a 6, nos dois modos — reprovando quando um par cai abaixo do piso sem que a textura esteja prevista.

O placar vai mudar, e é para mudar. O verde atual é produto do recorte, não da saúde da paleta. Isso reafirma a régua do §7 do MANIFESTO: verde só é bom sinal quando não há errata aberta; havendo, a suíte parou de medir.

4c.13 DI19 — O gráfico do alerta de geração (ET5) entra em /email/v1/#

O DM8 especificou o gráfico do e-mail de alerta de geração e declarou que o slot fecha quando o PNG em resolução dobrada existir no bucket R2, sob assets.seed.eng.br/email/v1/. O caminho /email/v1/ é imutável por decisão — arte nova vai para /v2/.

Decisão: o PNG do ET5 nasce em /email/v1/, com nome novo.

Racional: a imutabilidade do /v1/ existe para impedir que um arquivo seja substituído no mesmo caminho sem ninguém perceber — a classe de defeito da §1 do MANIFESTO.md, em que uma propagação afirmada e nunca lida de volta sobrescreveu um artefato. Acrescentar um arquivo com nome inédito não expõe nenhum consumidor existente a troca silenciosa. Além disso, o slot do ET5 está declarado desde a Fase 4 e nunca foi preenchido: ele já pertence ao /v1/ conceitualmente.

Alternativa descartada: abrir /email/v2/ só para este asset. Faria o seed-email.md passar a citar dois caminhos-base para a mesma geração de arte, dobrando a superfície de confusão para economizar uma regra que não estava sendo violada.

Consequência: a produção deste PNG fecha, no mesmo movimento, a pendência P4-b do MANIFESTO.md — os seis PNGs do bucket que seguem sem âncora passam a ser medidos e ancorados junto com o novo.

---