---
fonte: 01-canonicos/seed-dataviz.md
versao_da_fonte: v0.22
secao: 04c
titulo: "Sub-bloco DI — impresso/PDF + integração da stack (DI1–DI19)"
sequencia: 8 de 12
bytes_do_corpo: 26225
md5_do_corpo: bc9b87f993f4cdb190e43428758c7ee2
gerado_por: 06-validacao/geradores/gen-camada-ia.py
nota: fatia GERADA — o corpo abaixo é byte a byte o trecho do canônico; edite o canônico, nunca esta fatia. Canônico inteiro em https://ds.seed.eng.br/01-canonicos/seed-dataviz.md
---
## 4c. Sub-bloco DI — impresso/PDF + integração da stack (DI1–DI19)

> **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:

| Série | Token | Hex light | Claridade |
|---|---|---|---:|
| cat-1 | turquesa-500 | `#00A192` | 56% |
| cat-2 | dourado-300 | `#F9B11C` | 75% |
| cat-3 | magenta (exclusivo de dado) | `#CD518B` | 49% |
| cat-4 | azul-500 | `#0099C1` | 55% |
| cat-5 | violeta (exclusivo de dado) | `#966AC8` | 50% |
| cat-6 | azul-800 | `#004C61` | 27% |

**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

| Destino | O que sai por ele | Escopo |
|---|---|---|
| **(a) Laser colorida de escritório** | Laudo, relatório de O&M, proposta impressa, qualquer PDF gerado pelo ERP e mandado para a impressora | **DI** |
| **(b) Offset da gráfica** | Colateral físico da marca | **Fase 7** |

*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:**

| Condição de impressão | O que a prova mostrou | Consequência |
|---|---|---|
| **Em cor** | As 6 séries se distinguem bem, sem textura | A cor basta. Textura aqui seria ruído — o mesmo argumento que derrubou o DG11 |
| **Em escala de cinza (driver mono)** | Sem textura, 4 das 6 séries se distinguem; **2 pares colapsam** | Impressão mono **é grayscale por definição**, e o gatilho do DI2 já dispara ali com 6 séries |
| **Em escala de cinza, com textura** | As **6 texturas se distinguem bem** | O vocabulário estendido a 6 posições (§4.4) sobrevive ao papel |
| **Régua de traço** | As quatro espessuras (2 · 1,5 · 1 · 0,5px) saíram distintas, nenhuma sumiu nem engordou | **Não há piso de traço próprio para papel.** A hierarquia vale igual no impresso — ver DI6 |

*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

| Par identificado a olho, na folha impressa em cinza | Séries | Claridade medida em TELA | Espalhamento |
|---|---|---|---:|
| "Fora de ponta" ≈ "Bombeamento" | `cat-1` × `cat-4` | 56% × 55% | **1 ponto** |
| "Reservado" ≈ "Iluminação" | `cat-3` × `cat-5` | 49% × 50% | **1 ponto** |

**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:

| Episódio | Forma | Meio | O instrumento… |
|---|---|---|---|
| DM11 | bandas finas dentro de um medidor, com barra de valor por cima | tela | **errou** (9/8/17 pontos e ainda assim indistintas) |
| DI3 | **barras altas adjacentes** — a forma em que o piso foi calibrado | **papel** | **acertou par a par** |

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.

---