---
fonte: 01-canonicos/marca-seed.md
versao_da_fonte: v5.35
secao: 17
titulo: "Pendências explícitas"
sequencia: 18 de 19
bytes_do_corpo: 50510
md5_do_corpo: f7aa67a613f9b58c55161eba9495193f
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/marca-seed.md
---
## 17. Pendências explícitas

1. **CMYK "U"** (superfície fosca) — a confirmar se surgir demanda de impressão fosca crítica.
2. **Curadoria do banco fotográfico real** — processo operacional a organizar (pasta no Drive, critérios da §8); sem ele, a diretriz de fotografia fica sem matéria-prima. **Desde 2026-09-04 existe a ESPECIFICAÇÃO DE COMPRA das fotos:** quatro listas geradas (`07-pecas/frota/fotos-necessarias-frota.md` · `one-pagers/fotos-necessarias-onepagers.md` · `rollup-totem/fotos-necessarias-rollup.md` · `portfolio/fotos-necessarias.md`) com enquadramento, orientação e resolução mínima calculada da MESMA constante que desenha cada área — uma sessão de fotos alimenta frota e portfólio. A pendência deixa de ser "sem matéria-prima" e vira "sessão de fotos a executar".
3. ✅ **Vetores do Grafismo v2 — RESOLVIDA em 2026-08-22 (v5.12).** O SERRA-CENA fechou na v5.4 (geradores, §7.7); os três usos internos — textura de fundo, marcador de seção e divisor editorial — fecharam na v5.12 com o gerador `06-validacao/geradores/gen-detalhe.py` (extração por AST do aprovado, nunca cópia) e os 5 assets de referência em `03-assets/grafismos/`. Especificação consolidada na tabela da §7.6.
4. ✅ **Redesenho executivo das peças físicas — FECHADA em 2026-09-04 (v5.32).** Papelaria (Onda 1, §12.1–§12.8), frota (§12.22) e uniforme/EPI (§12.23) entregues com gerador, gate e spec; a F8 fecha nas três ondas.
5. ✅ **SANGRIA E MARGEM DE SEGURANÇA — RESOLVIDA em 2026-08-22 (`MR-P10`).** Nasceu
   e fechou no mesmo dia: pesquisada em três fontes, medida na peça e decidida por
   veredito dele — **3 mm de sangria e 3 mm de margem**, com a composição definida
   para a área de corte e a sangria como crescimento para fora. **A regra é a §7.4-e**
   e a conferência é automática (cláusulas **MM1-d** e **MM1-e**).
   ✅ **O caso da DOBRA (`MR-P12`) DEIXA DE SER BLOQUEIO em 2026-08-25, por
   decisão dele — e o que a substitui é uma FRONTEIRA, não uma medida.**

   **A pergunta dele, verbatim:** *"aqui você está entrando muito no detalhe de
   produção do crachá, isso é mesmo necessário no design system? o DS não seria um
   template que depois onde fosse ser produzido seria visto as regras do local
   para poder seguir o template? eu estendo esse questionamento para tudo que
   estamos fazendo."*

   ⚠ **A pergunta estava certa, e o custo da `MR-P12` era real:** ela vinha
   bloqueando "arquivo de produção" em peça atrás de peça — pasta com aba, crachá,
   diário em bloco, lombada, etiqueta de bloqueio — e **o bloqueio não produzia
   nada**: ninguém estava esperando aquele arquivo, e a medida que faltava (margem
   de vinco em milímetro) é do **fornecedor**, varia de gráfica para gráfica e só
   se conhece na cotação.

   ⭐⭐ **A FRONTEIRA NÃO É "produção × design" — É "MUDA O DESENHO × NÃO MUDA".**
   Dizer que detalhe de produção sai do DS estaria errado, e o próprio acervo
   prova: a **sangria de 3 mm** existe porque o corte erra e o **piso de 0,25 mm**
   existe porque traço fino some na impressão. As duas são restrições de produção,
   e as duas **mudam o desenho** — tirá-las quebraria as peças.

   | | |
   |---|---|
   | **FICA no DS** | tudo que muda **onde a tinta vai**: formato, sangria, margem de segurança, piso de traço, altura de letra normalizada, altura de linha de escrita à mão, **zona livre de conteúdo** perto de furo ou dobra |
   | **SAI do DS** | o detalhe do **fornecedor**: tolerância de faca, posição exata do furo, gramatura, tipo de acabamento, **margem de vinco em milímetro** |
   | **O DS entrega** | o **TEMPLATE** e a **LISTA DECLARADA de restrições** que quem produz precisa respeitar — **nunca um "arquivo de produção"** |

   **O caso do crachá mostra a linha exata:** a **zona de 9 mm livre no topo FICA**
   (é desenho — nada de conteúdo ali, e isso vale em qualquer gráfica); a
   **posição e o tamanho do furo SAEM** (é produção, e o fornecedor tem a faca).

   ⭐ **Consequência imediata: nenhuma peça fica mais esperando "arquivo de
   produção".** Crachá, diário, lombada, pasta com aba e etiqueta de bloqueio saem
   **completos**, com a lista de restrições ao lado. Três pendências de peça viram
   linha de spec. ⚠ **E os dois tipos de arquivo da §7.4-e continuam existindo** —
   GATE e PRODUÇÃO —; o que muda é que **o arquivo de produção passa a ser feito
   sob demanda, com a medida do fornecedor na mão**, e não a ser esperado.
6. ✅ **AMARELO DE MARCA × AMARELO NORMATIVO — RESOLVIDA em 2026-08-22
   (`MR-P11`, v5.13), saída (a) aprovada pelo Rafael** (*"essa está aprovada,
   pode propagar"*). **A REGRA: o amarelo de marca `#FAD61D` NÃO ENTRA em peça
   instalada em ambiente com sinalização de segurança** (subestação, sala de
   painéis, canteiro — onde a NR-10 10.10.1 obriga as cores da NR-26 → ABNT
   NBR 7195, em que amarelo significa CUIDADO/ADVERTÊNCIA); **nessas peças a
   assinatura da SEED é turquesa e branco. Em papelaria, escritório e digital,
   o amarelo segue como acento único, sem restrição. Uma regra, uma
   fronteira.** Motivo: sinalização que confunde é sinalização que não
   protege, e a responsabilidade técnica da peça é da SEED. Desbloqueia
   sinalização (2.9) e uniforme/EPI (3.2) do `plano-producao-pecas.md`.
   Conformidade conferida na propagação: o marcador amarelo da v5.12 é
   elemento de papelaria/digital — fora do escopo, sem conflito.
   Levantamento e fontes em `inventario-pecas-ds.md` §3.2.

   ⭐⭐ **A FRONTEIRA DE 2026-08-25 — quando a peça NÃO compartilha o campo
   visual, mas É o campo visual.** Veredito dele, sobre a `SN-P6`:
   > *"normal de segurança deve seguir as cores da norma de segurança, nao
   > podemos impor nosso DS sobre isso."*

   **A REGRA: em peça de SEGURANÇA, quando a exigência normativa colide com a
   identidade visual, a NORMA GANHA — e isso é linha de spec, não escolha caso a
   caso.**

   ⚠ **E A REGRA TEM FRONTEIRA, delimitada por ele em 2026-08-25** (ao confirmar
   a regra): *"estou falando apenas sobre norma de segurança, as demais normas
   temos que ver caso a caso, mas acredito nao ter outro tipo de normal que va
   se sobressair sobre ao nosso normativo interno do DS."*
   **Só norma de SEGURANÇA supera o normativo interno automaticamente.** Qualquer
   outra colisão — ABNT de desenho técnico, norma de concessionária, regra dos
   Correios — vai a ele **caso a caso**, com o custo de cada saída medido.
   ⭐ *Regra sem fronteira é regra que cresce sozinha:* sem esta delimitação, a
   próxima sessão aplicaria "a norma ganha" a qualquer norma e apagaria
   identidade onde ele não mandou apagar.

   ⚠ **A distinção é mais fina que "a norma ganha", e é ela que importa:** esta
   §17.6 foi escrita para peça que **COMPARTILHA** campo visual com sinalização —
   etiqueta de equipamento, crachá, uniforme —, e nessas o turquesa e branco
   continua valendo. A **família de sinalização NR-10 É o campo visual**, e nela
   governa a **NR-26, item 26.1.4**: *"o uso de cores deve ser o mais reduzido
   possível, a fim de não ocasionar distração, confusão e fadiga ao
   trabalhador."* Uma terceira cor ao lado do vermelho de proibição é
   exatamente o que esse item proíbe.
   **Consequência:** na família de sinalização a assinatura é **monocromática**
   (`logo-horizontal-mono-positivo`, pela linha "Impressão P&B" da matriz §5.1),
   separada do conteúdo por um fio e não por um campo de cor.

   ⚠ **O QUE NÃO SAI, e está declarado para ninguém "consertar" depois:** o que
   a decisão tira é **cor de marca usada como acento ou sinal**. A **tinta de
   texto** da casa (§3.5-d — `text-primary`, `text-secondary`, `text-muted`)
   **fica**: ela não sinaliza nada, não compete com cor de segurança, não aparece
   como campo de cor, e não existe tinta canônica alternativa. ⭐ *Reduzir cor não
   é apagar tinta.*

   **O custo foi medido, e é honesto dizê-lo:** o contraste da assinatura
   **melhorou** (branco sobre `brand-deep` 9,37:1 → preto sobre branco 21,00:1).
   O que piorou é **reconhecimento a distância, e só na placa A3**: com o logo a
   60 mm a caixa alta mede 8,75 mm, legível a **1,75 m** numa peça projetada para
   **4,0 m**. Antes, a tarja turquesa era um campo de cor contínuo — dizia "é da
   SEED" sem ler nada. *É perda de marca, não de segurança, e numa peça de
   segurança é o lado certo de perder: uma placa de risco elétrico não existe
   para anunciar quem a fabricou.* Pendência `SN-P10`, com saída medida que não
   acrescenta cor (logo maior, ao custo de área).
   ⭐ **PRECISÃO DE ESCOPO — 2026-08-24, por ele.** A redação acima diz "peça
   instalada em ambiente com sinalização de segurança" e dá "canteiro" como
   exemplo. **É largo demais, e a largura pegou uma peça que não devia:** eu
   apliquei a regra à PLACA DE OBRA (§12.1) e ela não se aplica. O critério,
   nas palavras dele: *"objetivamente é onde existem placas de sinalização que
   tbm usa o amarelo (…) no caso de uma placa de obra nao é o caso, pois o local
   que ela fica instalada nao compartilha espaço com alguma sinalização de
   segurança. o exemplo que queremos abordar seria por exemplo, um quadro
   eletrico, uma porta de subestação, entre outros locais especificos que podem
   ter uma sinalização amarela de segurança."*
   
   **A REGRA PASSA A SER, com o critério explícito: o amarelo `#FAD61D` não
   entra em peça que COMPARTILHA CAMPO VISUAL com sinalização de segurança
   amarela** — quadro elétrico, porta de subestação, painel, e os pontos
   específicos onde a NR-26/NBR 7195 manda amarelo. **Não é o terreno que
   decide, é a vizinhança visual da peça.** Placa de obra na entrada da obra,
   totem, banner e papelaria seguem com o amarelo liberado.
   
   ⭐ **A lição de método, e ela é de escrita de norma:** a versão anterior
   nomeava LUGARES ("subestação, sala de painéis, canteiro") em vez de nomear a
   CONDIÇÃO. Lugar é fácil de escrever e fácil de aplicar errado; condição é
   mais difícil de escrever e não estica. *Regra que enumera exemplos vira
   regra que se aplica por semelhança — e semelhança não é critério.*
7. ✅ **Kit de favicon/app icons e avatares — FECHADA PARCIALMENTE em 2026-08-28/2026-09-04 (§12.26):** kit SVG (favicon + masters de apple-touch, maskable e avatar, nos dois fundos) com as 5 decisões dele. O que NÃO fechou ganhou entrada própria no item 9: capas de rede (`FV-P1`) e rasterização + espelho §5.4 (`FV-P2`).
8. **Pendências abertas pela Onda 1 da F8** (2026-08-24), todas nomeadas:

   - ✅ **`RD-P1` — MEDIDA e fechada em 2026-08-27, com veredito NÃO ESTENDER.**
     O experimento que a própria pendência pedia: a `auditoria-borda-campo` (80
     medições × 2 temas) rodada **2× sem e 2× com** as flags deterministas —
     via o interruptor `CHROMIUM_DETERMINISTA=1` que o `ambiente.mjs` ganhou
     para isto (uma condição, um interruptor, zero edição nos instrumentos).
     **Resultado: os QUATRO placares idênticos** (80 PASS · 0 FAIL · 88 [n/a]).
     ⭐ **Veredito: o placar de tela é INVARIANTE às flags — estender não compra
     nada** (instrumento de tela consome placar, não PNG bit-a-bit) e custaria
     os ~15% de lentidão medidos na calibração original. O escopo declarado
     fica como está: rasterização determinística é para instrumento de PEÇA. O
     interruptor fica no ambiente para quem quiser re-medir.
   - ✅ **`RD-P2` — fechada em 2026-08-27 como NÃO-REPRODUZÍVEL, com prova.** O
     ruído registrado (2 px em 8,7 M, Δ1 nível) aparecia ENTRE execuções — e a
     prova §14.10 do render (duas cargas no MESMO processo) não o vê. O
     experimento reproduziu a condição real: **6 capturas em 6 processos node
     SEPARADOS**, por peça, nas duas suspeitas de fundo escuro
     (`pasta-a4-brand-deep`, `F3-cartao-fundo`). **Resultado: 12 de 12 PNG
     byte-idênticos por MD5.** O fenômeno não existe no acervo atual — entre o
     registro e hoje mudaram as flags deterministas (55º defeito) e as próprias
     peças (fontes embutidas). ⚠ A suspeita original (névoa E1) não foi
     confirmada nem refutada: **o fenômeno sumiu antes do isolamento**, e
     encerrar assim é mais honesto que atribuir causa sem reprodução. Se
     voltar: o método é capturar N vezes em processos separados e comparar MD5.
   - ✅ **`PC-P1` — RESOLVIDA em 2026-08-25, com as duas saídas usadas.** As sete
     peças anteriores à convenção tiveram destinos diferentes, e a diferença é a
     que importa: as **três do cartão de produção** foram **REMOVIDAS** (eram
     arquivo de produção, e o vigente passou a ser a §12.9 — com o ponteiro da
     §7.4-d repontado ANTES de o arquivo sair); as **quatro evidências de gate**
     (peça larga e grafismo em razão A4) foram **preservadas**, porque reescrevê-las
     as faria deixar de provar o que provaram.
     Para elas nasceu o veredito **`[hist]`** na `guarda-peca-fresca.mjs`, com
     motivo escrito por arquivo e contagem separada do placar. ⭐ Não é cosmético:
     **FAIL recorrente que "todo mundo sabe que pode ignorar" treina o operador a
     ignorar FAIL** — e aí o próximo FAIL verdadeiro passa junto. A lista é
     explícita, por caminho: peça nova sem `.peca` cai em FAIL como deve.
     PF-01 no acervo passou de 25·7·16 para **25 PASS · 0 FAIL · 4 [hist] ·
     16 [n/a]**.
   - ✅ **`PP-P1` — RESOLVIDA em 2026-08-26.** A **JetBrains Mono v2.304** está
     versionada em `03-assets/fontes/jetbrains-mono/` — pesos **400, 500 e 700**
     (os três que as bancadas pediam ao Google Fonts), mais `LICENSE.txt` (SIL
     Open Font License 1.1) e `AUTHORS.txt`. Baixada do *release* oficial do
     projeto no GitHub; MD5 de cada arquivo registrado no MANIFESTO.
     **Cobertura de glifo MEDIDA antes de declarar resolvida**, com o leitor de
     `cmap` da `guarda-glifo.py`: **1363 glifos** em cada peso, e o repertório
     que uma peça técnica da SEED precisa — dígitos, alfabeto, acentuação
     portuguesa completa, e o técnico (`°` `º` `ª` `²` `³` `µ` `Ω` `·` `—` `–`) —
     **está todo presente**. ⚠ **Falta exatamente um:** `U+2011`, o hífen
     inquebrável. Medido: **zero ocorrências** em todo o acervo (89 peças, as
     bancadas, os canônicos e os gêmeos), e se alguém o usar amanhã **a GL1
     reprova** — foi para isso que ela nasceu. ⭐ *Declarar a lacuna que se mediu
     vale mais que declarar a cobertura que se supôs.*
     ⚠⚠ **E ISSO RESOLVE DISPONIBILIDADE, NÃO USO.** A pendência travava a fonte
     por ela não existir; agora ela existe. **Passar as peças impressas a
     consumir `--seed-font-mono` é decisão separada e dele** — a `PP-P1-b`
     abaixo, apresentada a ele com visual e número em 2026-08-26.
     ⭐ *Destravar um recurso não autoriza gastá-lo: quem aprovou a peça aprovou
     a peça que viu.*
     ⚠⚠⚠ **CORREÇÃO DA v5.23 — esta entrada afirmava, na v5.22, que "número em
     peça impressa continua em Montserrat com `tabular-nums`". É FALSO, e foi
     medido em 2026-08-26.** O `gen-comprovante-ponto.py:190` declara
     `.mono{font-family:var(--seed-font-mono);font-variant-numeric:tabular-nums}`
     e o Chrome rasteriza aquilo em **Consolas** — fonte da Microsoft, que a peça
     não embute. **A regra estava sendo desobedecida em silêncio**, e a frase
     errada não era descuido de redação: eu **deduzi** de "a regra manda
     Montserrat" que "as peças estão em Montserrat".
     ⭐⭐ **Régua: afirmação sobre o estado de uma peça tem de ser MEDIDA na peça,
     nunca deduzida da regra.** É a mesma classe do defeito da §12.19 — a placa
     que afirmava uma conferência que não aconteceu.
   - ✅ **`GM-P1` — RESOLVIDA no mesmo dia.** A `guarda-piso-mm.py` morria com
     `UnicodeEncodeError` **antes de medir qualquer coisa**, porque imprime `≥`
     no cabeçalho e o console do Windows abre em cp1252 — quem rodasse sem
     `PYTHONIOENCODING=utf-8` via um traceback e podia ler isso como reprovação
     da peça. **Instrumento que morre por codepage do console mente sobre o
     artefato.** O script passou a reconfigurar a própria saída para UTF-8 com
     `errors='replace'`: perder um símbolo no relatório é aceitável, perder a
     MEDIÇÃO não é. Conferido rodando sem a variável de ambiente.
   - ✅ **`SN-P10` — FECHADA em 2026-09-04 por CONFIRMAÇÃO do veredito de 25/08 (MANIFESTO §145, resposta P-SN, verbatim: *"A — confirmo o veredito de 25/08 (60 mm, como está)"*).** A placa A3 fica com o logo a 60 mm, legível a 1,75 m, de propósito — o critério é o de 25/08, *"nao podemos competir com mensagem de segurança"*, registrado no gerador e na §12.19 mas nunca nesta fila (por isso a v5.28 a reabriu como órfã). Desta vez a confirmação saiu COM os renders que faltavam: opções A (60 mm · 1,75 m), C (94,8 mm · 2,77 m, só o rodapé) e B (137,1 mm · 4,0 m) na mesma escala, em `preview/gate-apoio-sn-p10/`, geradas pelo modo `--logo-placa` do `gen-sinalizacao.py` (instrumento que só consome espaço em branco e aborta se tocar conteúdo normativo; a saída oficial não mudou um byte). O registro original da pendência fica abaixo como história:
     ~~PENDÊNCIA ÓRFÃ: existia em 2026-08-24 e nunca teve entrada nesta lista, só uma menção solta dentro do §17.6. Achada em 2026-08-27 ao responder "quanto falta".~~ O que ela é: ao tirar o amarelo e a tarja
     turquesa da família NR-10 (`MR-P11`), a placa A3 perdeu **reconhecimento a
     distância** — o logo a 60 mm dá caixa alta de 8,75 mm, legível a **1,75 m**
     numa peça projetada para **4,0 m**. Contraste do texto MELHOROU (9,37 →
     21,00); o que piorou é marca, não segurança. **Saída medida que não
     acrescenta cor:** logo maior, ao custo de área útil da placa.
     ⭐ **É DECISÃO DELE, com custo em mm** — e por isso a pergunta precisa sair
     com as duas opções renderizadas lado a lado (§14.13), não em prosa.
     ⭐⭐ **RÉGUA QUE FICA: pendência citada dentro do texto de outra seção não
     existe.** Só existe o que tem entrada na fila — três rodadas de
     "resolver tudo em aberto" passaram por cima desta sem vê-la, porque
     "em aberto" se lê NA LISTA. Toda pendência nomeada em prosa entra aqui
     no mesmo movimento em que é nomeada.
   - ⏳ **`PT-P2` — a tela de consulta do comprovante de ponto** (§12.3-a) ainda
     não existe como artefato: a norma admite disponibilizar em sistema em vez
     de emitir, e a tela compartilha a FONTE com o PDF, não o layout.
     ⭐ **RECLASSIFICADA em 2026-08-27: isto é PRODUÇÃO NOVA (arquétipo de tela
     do ERP), não ponta solta de conserto** — entra na fila da onda de
     aplicações junto com a `AD-P7`, não na fila de pendências de fechamento.
     *Chamar produção nova de pendência faria a lista de pendências nunca
     zerar, e uma lista que nunca zera deixa de informar.*
   - ✅ **`MR-P13` — FECHADA em 2026-08-25.** O nome correto é **Básico**, não
     "Basic" — veredito dele: *"sobre o nome, o correto é Basico, nao Basic"*. Os
     três planos são **Básico · Essencial · Premium**. E a lacuna maior fechou no
     mesmo ato: ele anexou um orçamento SEED Plus real e autorizou usar a
     estrutura, então o `sobreaseed.md` §6 passou a registrar **o que cada plano
     contempla** — uma escada de 2, 4 e 7 itens —, o que fica fora dos três, as
     observações operacionais e como o preço se estrutura (por USINA, não por
     cliente). Peça já pode descrever os planos.
   - ✅ **`MR-P14` — RESOLVIDA em 2026-08-25, e o canônico estava certo nas DUAS
     vezes em que foi questionado.** O orçamento SEED Plus (24/04/2026) e depois o
     **contrato-modelo de prestação de serviço** (rev. 00) traziam, os dois,
     *Rua Albânia, 81* para Governador Valadares. Veredito dele: *"O endereço
     correto em Governador Valadares é da Rua Duarte Coelho, vou solicitar pra
     corrigir onde estiver errado."*
     **Nenhuma peça do design system foi ou precisa ser alterada.** A ação virou
     duas correções fora dele, e a segunda é de outra natureza: o orçamento em
     circulação, e o **contrato que o cliente assina** — endereço errado da
     CONTRATADA afeta notificação, foro e correspondência formal.
     ⭐ **A régua:** decisão tomada com uma evidência merece ser reapresentada
     quando aparece outra — não para duvidar do decisor, e sim porque quem decidiu
     tinha menos informação. Nas duas vezes o canônico venceu, e foi por **não**
     ter sido alterado "para casar com o material" que ele seguiu servindo de
     referência.
   - ✅ **`MR-P15` — RESOLVIDA em 2026-08-25.** Ver §12.10: o contrato está
     correto, e **três** itens separam o Essencial do Premium.

   - ✅ **`PP-P1-b` — RESOLVIDA em 2026-08-26, e a autorização veio mais forte
     que um "vai".** Veredito dele, verbatim: *"podemos deixar o plano B, mas
     temos que forçar sempre a fonte canônica, nem que seja dando opção de
     instalá-la ou avisando que precisa instalar e dando o link para isso"*.
     **O QUE FOI FEITO, por camada — porque "forçar" tem um jeito para cada
     natureza de artefato:**
     **(a) PEÇA IMPRESSA viaja para fora do repo → fonte EMBUTIDA.** Os geradores
     do comprovante de ponto e da pasta A4 embutem a JetBrains Mono 400/500/700
     em base64, mesmo contrato TP1 da Montserrat (ABORTA se faltar). Custo:
     ~1,07 MB por peça, declarado. **A assinatura de e-mail fica FORA**, como
     apresentado: cliente de e-mail não carrega `@font-face`.
     **(b) BANCADA/TELA é lente interna → `@font-face` por URL RELATIVA** para os
     TTF versionados em `03-assets/fontes/` — **Montserrat E JetBrains**, porque o
     achado era maior que o enunciado: **zero dos 42 arquivos de
     `05-html-de-referencia/` tinha `@font-face`**, ou seja até a Montserrat
     deles dependia da fonte instalada no sistema (funcionava nesta máquina por
     sorte). ⭐ *Embutir base64 nas 42 custaria ~45 MB de repo para arquivos que
     nunca saem dele; URL relativa dá o mesmo resultado por ~1 KB cada.*
     Aplicação pela §14.4: `base-bancada.css` (cobre as 9 bancadas geradas) +
     os 11 templates de tela (regenerados) + artefato direto só nos sem gerador.
     ⚠ O `banco-dataviz-dm.html` recebeu direto COM nota: o `gen-dm.py` não
     regenera a bancada (pendência `GN-P1`).
     **(c) AVISO + LINK, como ele pediu:** nasce `03-assets/fontes/LEIA-ME.md` —
     quando instalar (só para uso FORA do DS: Office, Figma), como (clique
     direito → Instalar nos TTF daqui), e os links oficiais.
     **A PILHA DE RESERVA FICA** (ordem dele: *"podemos deixar o plano B"*) — com
     o `@font-face` presente ela só trabalha em arquivo aberto fora do repo ou
     mutilado, que é o papel de um plano B.
     **MEDIDO NO FIM, pelo `mede-fonte-efetiva.mjs` (132 arquivos):** 55 aplicam
     mono a texto → **53 RECEBEM a JetBrains** · 1 `[sem-pixel]` (nó oculto da
     tela-autenticacao) · **1 TROCOU: a assinatura de e-mail — a exceção
     declarada**. Antes do conserto eram 26 de 42 bancadas + as 5 peças vivas em
     Consolas.
     ⚠ **Dois defeitos de aplicação pegos no caminho, com régua:**
     (1) sete templates usam `str.format()` e as chaves `{}` do CSS viraram
     placeholder (`KeyError: font-family`) — ⭐ *bloco inserido em template herda
     o MECANISMO DE ESCAPE do template; não existe "CSS neutro" dentro de um
     molde*; (2) o medidor classificava nó que não pinta pixel como "recebeu
     outra" — nasce o veredito `[sem-pixel]`, ⭐ *"não mensurável" é veredito
     próprio, nunca FAIL nem PASS* (a mesma régua do `[n/a]` das guardas).
     *O texto da pendência original, para histórico:*
     ~~EMBUTIR ou não a JetBrains Mono nas peças impressas.
     APRESENTADA A ELE em 2026-08-26, com visual e número. Decisão dele.~~
     *Para quem lê sem contexto:* a `PP-P1` (acima) resolveu a **disponibilidade**
     da fonte; esta resolve o **uso**. Ele cobrou a falta do visual, verbatim:
     *"porque nao me apresentou as peças pra eu ver a diferença, vc disse que muda
     as peças, mas nao fez nenhum comentário sobre, e o que tenho que decidir"*.
     ⭐⭐ **A cobrança é justa e nomeia uma leitura errada da §14.13 que eu vinha
     fazendo:** "toda pergunta ao decisor sai com o custo medido de cada saída" —
     e eu lia **custo** como **preço**. *O custo de uma saída inclui o que ela
     muda no que já está aprovado, e isso não se enuncia: se olha.*
     **O ESTADO MEDIDO** (instrumento novo `ferramentas/mede-fonte-efetiva.mjs`):
     das 90 peças, **22 aplicam o token mono a texto**; **17 recebem** a JetBrains
     — e são **todas da era anterior**, que a embute — e **5 recebem outra**: são
     as peças **vivas** (mock da assinatura, os 2 comprovantes de ponto, as 2
     pastas A4), que rasterizam **Consolas**.
     ⚠ **Consolas é fonte da Microsoft, licenciada com o Windows:** peça que
     depende dela sai diferente em Mac, em Linux e na gráfica.
     **O CUSTO MEDIDO:** a JetBrains Mono é **+9,12% mais larga** que Consolas no
     mesmo corpo (56 nós de uma linha, de +9,01% a +9,13% — a uniformidade é a
     assinatura de uma medição correta), e **zero nós passam a transbordar** nas
     cinco peças. Cada peça fica **~357 KB** maior.
     **RECOMENDAÇÃO APRESENTADA:** embutir nas **4 peças impressas**; a
     **assinatura de e-mail fica de fora**, porque cliente de e-mail não carrega
     `@font-face` e os 357 KB não mudariam o que o destinatário vê.
     Medição completa em `09-pesquisa/medicao-fonte-mono-e-papel-do-drive.md`.
   - ✅ **`GT-P1` — FECHADA em 2026-08-27 (v5.27): medida e decidida por ele — o Drive não guarda mais o DS. O texto abaixo é o REGISTRO DO ACHADO, preservado na data em que foi escrito.**
     **`GT-P1` — o papel do Google Drive. APRESENTADA A ELE em 2026-08-26 com
     número. Decisão dele.** Herdada da fundação (`CLAUDE.md`), e ele a abriu
     supondo: *"acredito que hoje o google drive nao tenha papel nenhum, já que
     todos os arquivos foram migrados para github correto?"*
     ⚠⚠ **A premissa está invertida, e a inversão é grande: o Drive tem hoje o
     papel mais crítico da operação — ele é o DISCO onde o repositório mora.** A
     cópia de trabalho está em `G:\Meu Drive\Claude\code\assistente de email\`,
     e `G:` é **Google Drive File Stream 130.0.2.0**. Os **399 MB em 1.309
     arquivos** do `.git` são sincronizados para a nuvem a cada commit.
     ⭐ *O git já é a sincronização; o Drive sincronizando o `.git` por cima é uma
     segunda sincronização competindo com a primeira.*
     **E a pasta de ORIGEM da migração não foi removida:**
     `G:\Meu Drive\#nuvem\marca seed\Design System v2`, **945 arquivos /
     105 MB**, gravável. Conferida **por MD5** (nunca por tamanho — §14/D-62):
     **135 idênticos · 172 DIVERGENTES · 629 só lá · 9 de basename ambíguo**.
     ⚠⚠ **Os 172 divergentes são versões ANTIGAS dos canônicos, congeladas:**
     `marca-seed.md` **v5.11** contra a v5.22 do repositório; `seed-tokens.css`
     v1.20 contra v1.23; `seed-componentes.md` v1.29 contra v1.38. **Existem hoje
     onze versões de atraso do canônico de marca num arquivo com o nome certo** —
     e numa casa cuja regra fundadora é *"~50% das pesquisas são feitas por IA"*,
     um agente que varra o Drive lê a v5.11 sem nada indicar que está errado.
     ⭐ **A armadilha em forma literal:** a pasta antiga tem
     `temporaria/marca-seed-v5.4-PROPOSTA-aguardando-veredito.md`, cujo conteúdo
     — por decisão dele de 22/08 — começa com *"⚠ APAGUE ESTE ARQUIVO — ele é uma
     LÁPIDE"*. *O nome anuncia pendência dele em aberto; o conteúdo diz que já foi
     decidida.*
     **O risco não é teórico:** o `CLAUDE.md` registra que ele *"já custou um
     arquivo em 2026-08-06"*.
     **CUSTO DE OPERAR ALI, medido** (e a primeira medição foi refeita porque a
     ORDEM de execução era uma segunda condição variando, §14.5): `git status`
     **275 ms local × 522 ms Drive** · `git log --stat -20` **8.791 × 15.577 ms**
     · `git fsck` **8,2 × 21,2 s**. **Drive de 1,8× a 2,6× mais lento.**
     `git fsck` **passa nos dois** — não há dano instalado, há risco e lentidão.
     **RECOMENDAÇÃO APRESENTADA:** (a) mover o repositório para disco local, com
     o GitHub como única cópia remota; (b) aposentar a pasta antiga
     **renomeando, nunca apagando**, para `Design System v2 — CONGELADO
     22-08-2026 — NAO USAR`, com um `LEIA-ME.md` apontando a fonte de verdade.
     ⭐ *O nome faz o trabalho que o conteúdo não faz.* Não apagar porque 629
     daqueles arquivos são evidência de gate da era anterior, e **evidência não se
     descarta**. ⚠ Nada executado: mover o repositório muda o caminho de tudo, e
     renomear pasta no Drive dele é mexer nos arquivos dele.
     ⚠⚠ **TERCEIRA AÇÃO, achada no fechamento e ela é MINHA:** o eixo 1 do
     `audita-fechamento.py` lista **47 caminhos citados nos canônicos deste
     repositório que não estão aqui dentro**, e cruzando a lista com a pasta
     antiga, **44 dos 47 ESTÃO lá** (`render-audit/`, `validacao/`, `temporaria/`,
     `lixeira/`). ⭐⭐ **Logo a pasta antiga não é só cópia morta: ela é a ÚNICA
     cópia de 44 arquivos que os canônicos daqui referenciam.** Isso reforça
     renomear em vez de apagar, e exige um terceiro passo: **marcar essas 44
     citações como históricas, ou trazer os arquivos para o repositório.**
     *Aposentar a pasta sem tratar as citações deixaria 44 referências apontando
     para o nada, dentro dos canônicos.*
     ⚠⚠⚠ **CORREÇÃO DA v5.24 — o parágrafo acima EXAGERA, e a medição posterior o
     desqualifica.** Escrevi *"ela é a ÚNICA cópia de 44 arquivos que os canônicos
     referenciam"* com base numa contagem de **citações de caminho**. Medido depois
     **por execução** (33 instrumentos rodados): **nenhum código vivo depende
     daqueles 44 arquivos** — são citações em prosa, dentro de documentação
     histórica. ⭐⭐ *É a MESMA classe do erro que eu havia acabado de nomear na
     §131.14 — contar citação como dependência confunde escrita com leitura — e eu
     o repeti no parágrafo seguinte.* **O tratamento das 44 citações continua sendo
     trabalho meu, mas é conserto TEXTUAL: elas não bloqueiam a deleção.**
     ✅✅✅ **EXECUTADA em 2026-08-26, madrugada — o repositório MUDOU DE CASA:**
     de `G:\Meu Drive\Claude\codessistente de email\seed-design-system` para
     **`G:\Meu Drive\Claude\code\seed-design-system`**. A pasta antiga do Drive
     ele mesmo deletou (verificado depois: `guarda-grafismo` 21·0 e
     `audita-fechamento` com os mesmos 2 achados — **nada quebrou**). O movimento
     travou duas vezes em `Device or resource busy` e as causas valem registro:
     **cinco processos `python` de sessões anteriores** — três na porta 8820 e
     dois de 25/08 — todos servidores de preview empilhados com `cwd` dentro do
     repo, mais **o shell da própria sessão**. ⭐ *Pasta que "não quer" ser movida
     está sendo segurada por alguém — e o alguém costuma ser você mesmo, de outra
     sessão.* Verificado no caminho novo: `git status` limpo, `fsck` OK, guardas
     rodam (ES 90·0, GR1 21·0), `mede-fonte-efetiva` confirma `[ recebe ]` em
     bancada e peça, preview servindo. A memória de sessões foi copiada para o
     project-key novo. A pasta `assistente de email` ficou com apenas o `.claude/`
     do projeto antigo — **deletá-la é decisão dele**, não minha.
     ✅✅ **VEREDITO DELE, 2026-08-26:** *"a pasta G:\Meu Drive\#nuvem\marca
     seed\Design System v2 vou renomear e depois deletar, nao precisa dela mais
     la"* · *"a pasta seed-design-system vou deixar os arquivos disponiveis
     offline no pc para dar agilidade na leitura e gravacao"*.
     **A DELEÇÃO ESTÁ LIBERADA, e a liberação é MEDIDA — não opinião.** Antes de
     dizer "pode", conferi em duas vias:
     **(a) por MD5:** dos 945 arquivos, **135 são idênticos** ao que já está aqui;
     **172 são versões antigas dos canônicos** (o motivo de a pasta ir embora);
     **629 são evidência e ferramentas da era anterior**; e o
     `SEED-DS-EXPORT-2026-08-22.zip` de 11,6 MB é o pacote que originou o commit
     de fundação — **cujo conteúdo está no GitHub**.
     **(b) por EXECUÇÃO:** rodei os 33 instrumentos que citam aquelas pastas.
     **Seis morrem por falta de arquivo, e NENHUM pela pasta do Drive** — morrem
     por falta de `node_modules/@fontsource`, dependência de programação do
     ambiente do Cowork que nunca esteve lá.
     ⭐⭐ **E o caminho até essa resposta tem a lição:** minha PRIMEIRA análise
     disse **75 dependências** (contou menção a caminho, inclusive em comentário,
     como leitura de arquivo — *o erro que eu tinha acabado de nomear na §131.14*).
     A SEGUNDA, mais fina, disse **zero** — e também errou, porque o caminho da
     única dependência real é montado por `join()` em pedaços que nenhum regex de
     linha vê. **Foi a linha de conferência contra a prova empírica que salvou:**
     eu havia escrito que a análise só valeria se explicasse a morte observada da
     `guarda-grafismo`, e ela não explicou. ⭐⭐⭐ *Quando duas análises estáticas
     seguidas erram, o problema não é o regex — é o MÉTODO: dependência de arquivo
     em runtime se mede EXECUTANDO.* Sem aquela linha eu teria reportado
     "0 dependências — pode deletar" com o instrumento cego para o único caso
     provado.
     ⚠ **SOBRE DEIXAR OFFLINE, e é preciso ser claro sem insistir:** offline ataca
     a latência medida (1,8× a 2,6×) e é a metade do problema. O que **continua** é
     o Drive sincronizando o `.git` (399 MB, 1.309 arquivos) a cada commit — a
     origem do risco de conflito que já custou um arquivo em 2026-08-06. **A
     decisão é dele e é razoável** (backup na nuvem de graça, GitHub cobrindo o
     histórico); fica registrado que **o risco não virou zero**, e que erro
     estranho de git tem esta como primeira hipótese.
   - ✅ **`GT-P2` — por que a pasta do projeto se chama `assistente de email`.
     Pergunta dele, respondida com data em 2026-08-26.**
     *"porque essa pasta tem uma subpasta com o nome \assistente de email? o que
     isso tem haver com o projeto?"* — **Nada. É herança acidental.**
     | o que | quando nasceu |
     |---|---|
     | a pasta `assistente de email` | **2026-05-04, 23h52** |
     | o `.claude/` dentro dela | 2026-05-05, 00h51 |
     | **o design system** | **2026-08-22, 01h24** — três meses e meio depois |
     | o commit de fundação | 2026-08-22, 01h33 |
     Era pasta de projeto de um **assistente de e-mail**, de maio, do qual **não
     sobrou nada** além de um `settings.local.json` de permissões. O DS foi criado
     **dentro** dela, provavelmente porque já estava configurada.
     **Renomear é seguro do lado do repositório, e isso foi conferido:** nenhum
     arquivo versionado cita `assistente de email`; nenhum código depende do
     caminho (os únicos caminhos absolutos funcionais apontam para o Chrome e para
     a pasta de dependências, ambos em `C:`); os oito arquivos que mencionam
     `G:\Meu Drive` são **documentação**. O que muda é fora daqui: o histórico das
     sessões fica indexado pelo caminho antigo. **Decisão dele, sem pressa.**
   - ✅ **`FT-P1` — FECHADA em 2026-08-27 (v5.27): subsets woff2 da SEED, 4 peças de 3,1 MB → ~290 KB. O texto abaixo é o REGISTRO DO ACHADO, preservado na data em que foi escrito.**
     **`FT-P1` — REFORMULADA em 2026-08-26, e a reformulação inverte o pedido.**
     Ela dizia: *"o acervo tem só `.ttf`, enquanto as peças antigas embutem
     `.woff2` e pesam 113 KB — converter"*. **Medido, converter para o `.woff2`
     que existe seria plantar um defeito.**
     O `.woff2` da JetBrains **já estava no repositório**, escondido como data-URI
     dentro de `07-pecas/gate-7-formatos/F2-cartao.html`: **21.832 B contra
     273.860 B do `.ttf`, 12,6× menor**, assinatura `wOF2` conferida. Mas ele é o
     recorte **"latin"** do @fontsource, e a cobertura medida no Chrome dá:
     **86/86** no repertório que as peças vivas realmente imprimem (empate com o
     `.ttf`) e **39/50** no repertório técnico da disciplina. **Os 11 ausentes:**
     `≤ ≥ √ Ω Δ ≠ ■ ✓ ✗ ∅ ∞`.
     ⚠⚠ **`Ω` (ohm) e `Δ` (delta, ligação triângulo) são caracteres de TRABALHO
     numa empresa de engenharia elétrica**, e `✓`/`✗` é o glifo do defeito
     fundador da GL1 na Montserrat.
     ⭐⭐ **Régua: cobertura medida contra o acervo de HOJE responde "quebra
     agora?"; contra o repertório da DISCIPLINA responde "vai quebrar?".** São
     perguntas diferentes, e é a segunda que escolhe formato. O empate em 86/86
     me faria adotar o arquivo 12,6× menor e plantar um defeito silencioso na
     primeira peça que escrevesse um ohm.
     **O pedido certo agora:** gerar `woff2` **subsetado pelo repertório da
     SEED**, não adotar subset de terceiro. Exige `fontTools` + `brotli`, que o
     ambiente não tem. ⚠ **E é achado sobre a era anterior:** as **18 peças de
     gate embutem esse recorte incompleto** — funcionou porque nenhuma escreveu
     um `Ω`.

   - ✅ **`PV-P1` — RESOLVIDA em 2026-08-26, no gerador, e a paridade ZEROU:
     513 PASS · 0 FAIL pela primeira vez.** Os dois casos, consertados pela §14.4:
     **(a)** o `.selo` do `base-bancada.css` consome `--seed-feedback-info-bg/-text`,
     e o `gen-banco-dominio.py` era **o único dos 9 gerados** sem os dois na lista
     `NOMES` — os 8 irmãos já os tinham. ⭐ *Quem consome CSS COMPARTILHADO herda a
     lista de tokens do compartilhado — e lista escrita à mão é exatamente a classe
     que a G2 existe para pegar.*
     **(b)** o `banco-identidade` consumia `--seed-surface-default`, que **não
     existe** — e a intenção estava ESCRITA no próprio template (SI20: *"superfície
     neutra com fio de 1px"*). Passou a consumir `--seed-surface-raised`, que **já
     estava na lista NOMES** do gerador: alguém a listou e depois consumiu outro
     nome. §14.1 respeitada: nada foi criado.
     *O texto original da pendência:*
   - ~~⏳~~ **`PV-P1` — dois tokens FANTASMA em duas bancadas. Achado em
     2026-08-26, e o pior nao e o defeito: e que eu nao o tinha visto.**
     ⚠⚠ **Como ele apareceu:** rodando a `paridade-previews.py` no fechamento
     desta rodada. Placar: **511 PASS · 2 FAIL**. Os dois arquivos estão
     **intocados** por esta rodada (`git status` vazio; última alteração no commit
     `dd32811`), então **os FAIL são pré-existentes** — e eu **não rodei essa
     guarda no fechamento anterior**, tendo reportado o placar da rodada sem ela.
     ⭐⭐ *Régua: guarda que não roda não é guarda — é guarda em potencial. E
     placar de fechamento que omite uma guarda do conjunto não é placar
     incompleto: é placar **falso**, porque quem lê "tudo verde" lê "tudo medido".*
     **O QUE A G2 EXIGE, e ela está certa:** token consumido tem de estar definido
     **no PRÓPRIO arquivo** — bancada é autocontida, e por isso embute o bloco
     `:root`. Os dois casos são de naturezas diferentes:
     **(a) `banco-dominio.html`** consome `--seed-feedback-info-bg` e
     `--seed-feedback-info-text` em **um** elemento (`background` e `color`) sem
     defini-los no próprio bloco. ⚠ **Os valores EXISTEM no canônico**
     (`#ECF4FC`/`#006783` claro, `#003241`/`#96E0FD` escuro) — o conserto é
     mecânico e **não cria valor**. Mas ele **muda o que se vê**: hoje as duas
     propriedades não resolvem.
     **(b) `banco-identidade.html`** consome `--seed-surface-default` em um
     `background`, e esse token **não existe em lugar nenhum** — zero definições
     no `seed-tokens.css`. ⚠ **Bate na §14.1: valor que não existe no canônico NÃO
     SE CRIA.** Descobrir a intenção (provavelmente uma das superfícies existentes)
     é decisão de conteúdo, não conserto mecânico.
     ⚠ **NÃO consertado nesta rodada, e o motivo é a §14.4:** as duas bancadas
     **são geradas** (`gen-banco-dominio.py` + `banco-dominio-template.html`;
     idem identidade), então o conserto vai no gerador e se prova por **regeneração
     byte-idêntica** — trabalho próprio, com gate próprio. *E ele não pediu isso:
     ampliar o escopo em silêncio é o que a régua desta mesma rodada condena.*

   - ✅ **`CT-P8` — FECHADA em 2026-08-27 (v5.27): CT1 em **168 PASS · 0 FAIL** no acervo. O texto abaixo é o REGISTRO DO ACHADO, preservado na data em que foi escrito.**
     **`CT-P8` — 32 FAIL da CT1 em quatro artefatos, e são PRÉ-EXISTENTES.
     Achado em 2026-08-26 ao rodar o conjunto COMPLETO de guardas.**
     A `guarda-centro-alvo.mjs` (contrato **CT1** — *o centro do desenho tem de
     coincidir com o centro do alvo de toque*) fecha em **168 PASS · 32 FAIL ·
     232 [n/a]** sobre 54 arquivos, 1.514 medições efetivas, tolerância **1,00 px**.
     **Os quatro reprovados:** `banco-data.html`, `banco-navegacao.html`,
     `tela-shell.html`, `tela-tabela.html` — **8 FAIL cada**, uma por combinação
     tema × estado.
     ⭐ **A uniformidade é o que dá confiança no achado:** o mesmo número de
     controles fora do centro nas **oito** combinações (claro/escuro ×
     repouso/hover/ativo/foco) diz que o defeito é **geométrico**, não de tema nem
     de estado. *E como ele aparece também em `claro/repouso`, que a CT1 SEMPRE
     mediu, ele não é novidade da extensão da guarda (as `CT-P1`/`CT-P2`
     resolvidas): estava visível e ninguém reportou.*
     ⚠ **Nenhum dos quatro foi tocado nesta rodada** (`git show --name-only` do
     commit desta rodada não os contém), e o `banco-navegacao.html` **não muda
     desde o commit de fundação `fbba442`**, de 2026-08-22.
     ⚠ **Não consertado aqui:** são bancadas e telas, **geradas** por
     `gen-banco-*.py` + template (§14.4), e o conserto se prova por regeneração
     byte-idêntica com gate visual próprio. *E ele não pediu isso.*
   - ✅ **`GR-P10` — RESOLVIDA em 2026-08-26, e o conserto foi UMA LINHA porque os
     arquivos já estavam aqui.** O `DIR` padrão passa a ser
     `07-pecas/gate-7-formatos`. **Conferido por MD5 ANTES de copiar nada:** os 7
     HTML de `gate-z3/formatos` são **idênticos** aos de
     `07-pecas/gate-7-formatos/` e os 5 de `gate-z3/largos` aos de
     `07-pecas/gate-pecas-largas/` — **12 de 12**. Os PNG daquela pasta são
     **saída** de uma execução antiga (`SALVA_PNG`), não entrada: a guarda lê um
     diretório de HTML e renderiza. **Placar: GR1 21 PASS · 0 FAIL · 7 de 7 alvos
     medidos** — pela primeira vez neste repositório.
     ⭐⭐⭐ **RÉGUA: antes de resgatar um arquivo, conferir se ele já está salvo em
     outro lugar.** Eu ia copiar 14 arquivos para dentro do repositório e criar
     uma SEGUNDA cópia do que ele já versiona — *exatamente a doença que a
     `GT-P1` descreve no Drive.* **O resgate errado teria plantado aqui dentro o
     problema que estávamos tirando de lá.**
   - ✅ **`PF-P2` — FECHADA em 2026-08-27 (v5.27): nasceu a guarda **PF2**, 7 defeitos reais na estreia. O texto abaixo é o REGISTRO DO ACHADO, preservado na data em que foi escrito.**
     **`PF-P2` — a folha de `preview/` não tem guarda de contraste, e foi nessa
     isenção que um defeito de legibilidade morou. Achado POR ELE, olhando.**
     Ele apontou, verbatim: *"essa fonte onde está marcado no texto nao está dando
     para ler, veja se aplicou de maneira errada ou configuramos algo errado"*.
     **Medido no Chrome: contraste 1,01** em cinco trechos de `<code>` dentro do
     bloco escuro da folha — contra o **piso 3,00**. Praticamente branco sobre
     branco.
     **A CAUSA É DE CLASSE, não descuido:** o `code` declarava `background` e
     **não declarava `color`**. Dentro de um bloco de fundo escuro ele herdava a
     **tinta clara do bloco** e mantinha o **fundo claro próprio**. Qualquer bloco
     escuro com `code` dentro reproduziria.
     ⭐⭐ **RÉGUA: fundo e tinta se declaram JUNTOS, sempre.** Declarar só um deixa
     o outro à mercê da herança — e herança de bloco escuro com fundo próprio
     claro é a receita exata do invisível.
     ✅ **A folha foi consertada e medida:** 274 elementos de texto,
     **mínimo 5,87 nos `code` e 4,23 na página inteira, zero abaixo do piso**.
     ~~⏳~~ ✅ **A GUARDA NASCEU na v5.27 (contrato **PF2**, `guarda-preview-contraste.mjs`, piso 4,5 / 3,0) — o que segue é o registro do que estava aberto em 2026-08-26:**
     **O que ficava aberto era a GUARDA:** `preview/` é isento das auditorias de
     contraste porque é *lente de revisão, não peça* — e a isenção tem motivo bom.
     ⭐ *Mas rascunho que serve de base para o decisor decidir não é rascunho.*
     Estender a guarda ao `preview/` é trabalho meu, na fila.
   - ~~⏳ `GR-P10` — a `guarda-grafismo.mjs` NÃO RODA.~~ **Ver acima: RESOLVIDA.**
     O texto original da pendência, para quem precisa do diagnóstico: Ela morre com `ENOENT` procurando
     `06-validacao/render-audit/gate-z3/formatos`. **Essa pasta não existe no
     repositório — e EXISTE na pasta antiga do Drive**
     (`#nuvem\marca seed\Design System v2\render-audit\gate-z3\formatos`).
     ⭐⭐ **Logo uma guarda VIVA e versionada aqui depende de uma pasta que está
     só no Drive.** Não é mais uma questão de "citações históricas nos
     canônicos" (as 44 do eixo 1): é **código de validação que não executa**.
     **O tamanho medido:** **34 arquivos** de `06-validacao/` citam
     `render-audit/`, e **21 citam caminho ausente**. ⚠ Mas *"caminho ausente"
     não é o mesmo que "quebrado"*: para várias guardas (`guarda-piso-mm`,
     `paridade-previews`, `guarda-peca-fresca`, `guarda-escape`) aquela pasta é
     **saída** que elas mesmas criam, e as quatro **passam**. ⭐ *Contar citação de
     caminho como defeito confundiria escrita com leitura — e inflaria o número
     por um fator de 20.* **Medido de fato: 1 guarda morre.**
     `render-audit/` está no `.gitignore` desde 2026-08-26, então esses arquivos
     **nunca vão aparecer por commit**. O conserto é (a) trazer a fixture do
     `gate-z3` para dentro do repositório, ou (b) reapontar a guarda — e as duas
     saídas dependem do veredito da `GT-P1`.

9. **Pendências abertas pela Onda 3 da F8** (2026-09-04), todas nomeadas — códigos conferidos como não usados no `marca-seed.md`, no MANIFESTO e no `seed-componentes.md`:

   - ✅ **`PI-P1` — FECHADA em 2026-09-04 por veredito dele, sem leitura de norma (MANIFESTO §144, verbatim: *"PI-P1 nao precisa porque isso é fabricado conforme norma da concessionária"*).** A placa de advertência de geração própria é peça da distribuidora, fabricada no padrão dela em cada estado; o DS não precisa conhecê-la porque a placa SEED (§12.27) já declara que não a substitui. O registro abaixo é o que estava aberto: placas de EDP (ES) e Neoenergia Coelba (BA) não lidas (só a CEMIG ND-5.30 foi, §12.27). Nasceu citada em prosa como `ET-P5` em `gen-etiqueta.py` e `gen-placa-instalacao.py` — sem entrada na fila, e com código que **colidia** com o `ET-P5` do `seed-componentes.md` (consumidores do e-mail transacional). Repontada nos dois geradores em 2026-09-04. Efeito na peça: nenhum no desenho (a placa declara que não substitui a da distribuidora); o que muda é saber se ES/BA vedam publicidade como MG.
   - ✅ **`FV-P1` — capas de rede social — FECHADA em 2026-09-04 (§12.30).** Produzida em três direções por plataforma para gate comparativo com pesquisa de mercado; direção decidida por plataforma no MANIFESTO §145 (LinkedIn A · Facebook C · YouTube A+ · X A, não publicada). Os 48 arquivos de estudo saíram em 2026-09-05 por tabela de remoção aprovada (§147).
   - ✅ **`FV-P4` — capas de destaques do Instagram — FECHADA em 2026-09-05 (§12.31)**, por ordem dele (*"produzir agora as duas"*, §145): 8 destaques, ícone do set §45, composição C escuro decidida pela sessão por delegação (§146) e exposta a veto.
   - ✅ **`FV-P5` — FECHADA em 2026-09-05 por ordem dele (*"FV-P%: pode criar"*, §147):** nascem `hard-hat` (Obras) e `solar-panel-plus` (SEED Plus) no set §45 do `seed-componentes.md` (v1.39, 30 glifos), com alternativas (`crane`, `wrench-plus`) desenhadas, renderizadas e descartadas com o porquê (MANIFESTO §148, folha `preview/gate-apoio-fv-p5/`); os dois destaques regeneram com ícone (§12.31). Exposto a veto no relatório.
   - ✅ **`FV-P3` — capa do perfil comercial do WhatsApp Business — FECHADA em 2026-09-04 (§12.30)**, por ordem dele (*"produzir agora as duas"*, §145), na direção A. Medida secundária (1211 × 681) e recorte medido em captura de 2022: a conferência no app antes de publicar é etapa do gate humano.
   - ✅ **`FV-P2` — FECHADA: rasterização em 2026-09-04** (ordem dele: *"PV-P2 pode fazer pra adiantar"*, MANIFESTO §144; §12.26 traz a lista, as provas e o defeito de instrumento) **e upload para o espelho §5.4 em 2026-09-05**, pela sessão com autorização explícita dele (§147): subpasta `Logos/Símbolo/favicon/`, 10 arquivos com MD5 conferido, permissão pública herdada, FILE_IDs lidos pela API e dois deles baixados pela URL pública com MD5 igual ao do repositório.

---