---
fonte: 01-canonicos/marca-seed.md
versao_da_fonte: v5.35
secao: 12
titulo: "Camada física da marca"
sequencia: 13 de 19
bytes_do_corpo: 130586
md5_do_corpo: bc483bf0ce8b4468483ab0c010a7b7e5
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
---
## 12. Camada física da marca

Princípios herdados do Manual 2018 (o inventário: cartão, envelope, pasta A4, timbrado A4/A5, uniforme, frota, totem/banner, arquitetura de interiores) — **atualizados à linguagem v5.0**: nas peças novas, a onda-massa dá lugar à linha (§7) e o branco domina (§3.3). Regras por peça:

- **Papelaria** (cartão, timbrado, envelope, pasta): fundo branco dominante, logo conforme matriz §5.3, detalhe em linha no rodapé; dados em Montserrat, identificadores em mono quando técnico. Cores em Pantone (tabela §3.1) para offset, CMYK para digital.
- **Uniforme/EPI:** logo bordada/aplicada no peito (símbolo ou horizontal conforme espaço ≥/< 120px equivalente), turquesa como cor de peça OU detalhe — não ambos saturados; amarelo apenas em detalhes (vivos, botões) ou onde norma de segurança pedir alta visibilidade.
- **Frota:** branco dominante, faixa de linha turquesa (não massa), logo horizontal na lateral + símbolo na traseira. Regras de legibilidade em movimento: **teste dos 3 segundos** (nome + o que fazemos + um contato, capturáveis num relance — nada além disso; sem lista de serviços, sem múltiplos telefones); **altura mínima de letra ≈1cm para cada 2m de distância de leitura** (lateral lida a 20m → letras ≥10cm); alto contraste sempre (texto escuro em área branca / branco em área turquesa profunda); **nunca posicionar texto ou logo sobre frisos, vincos, maçanetas e recortes de painel**; layout idêntico em todos os veículos — a frota é reconhecida como conjunto.
- **Fachada/sinalização de obra:** logo sobre fundo branco ou turquesa profundo (`brand-deep`); placas de obra seguem exigências legais (ART, responsável) com a tipografia do sistema.
- **Interiores:** parede de destaque em turquesa `#11B0A0` é permitida (é ambiente, não peça — a lei 70/20/10 governa *peças de comunicação*).

Redesenho executivo das peças físicas: **Fase 8 (aplicações)** — esta seção dá as regras, não os arquivos finais.

> ⭐ **INVENTÁRIO AMPLIADO (novo na v5.9).** O inventário acima é o do **Manual 2018**
> e ele descreve a papelaria de um escritório genérico: **não contém uma única peça
> específica de engenharia elétrica**, que é o que a SEED entrega. O levantamento
> completo — **36 peças em 5 famílias**, incluindo a classe **REGULADA POR LEI E POR
> NORMA** que faltava — está em `Design System v2/inventario-pecas-ds.md` (v1.0,
> estado `proposta`). ⚠ **Aquele documento não é canon**: é o levantamento pedido
> pelo decisor, e cada peça entra pelo fluxo normal.
>
> ⚠⚠ **E ele traz UM CONFLITO DE MARCA que esta seção precisa registrar:** a
> **placa de obra é obrigatória por lei** (`Lei nº 5.194/1966, Art. 16` +
> `Resolução CONFEA nº 407/1996`) e a **sinalização de segurança elétrica** é
> obrigatória pela **NR-10 (item 10.10.1)**, cujas **cores** vêm da **NR-26 →
> ABNT NBR 7195**. Nessa norma o **amarelo significa CUIDADO / ADVERTÊNCIA** — e o
> amarelo da SEED (`#FAD61D`) é, pelo §3.4, o **acento único da marca**. Em
> subestação, sala de painéis e canteiro, **o mesmo amarelo passa a carregar dois
> significados**. *Ver a pendência 7 da §17: nada foi decidido, e decidir é dele.*

> **Supersede formal (2026-08-15, F7.2 — errata fechada pela regra GI2).** Estas quatro
> menções diziam "Fase 6". O `seed-ds-roadmap.md` v1.8 já registrava a errata mandando ler
> como **Fase 7** — mas a leitura ficou obsoleta antes de ser aplicada: em 2026-08-15 a
> **Fase 7 passou a ser COBERTURA** (F7.1 a F7.7, nascida do `mapa-cobertura-ds.md`), e
> aplicações desceu para a **Fase 8**. O número correto é 8, e a errata do roadmap fica
> superada por esta.


### 12.1 PLACA DE OBRA — **[LEI]** · `estável` (2026-08-24, F8 Onda 1, item 1.1)

**Gerador:** `06-validacao/geradores/gen-placa-obra.py` · **peça:**
`07-pecas/placa-obra/` em **1000 × 500 mm** e **2000 × 1000 mm**.

**O que a lei fixa — e o que ela NÃO fixa.** A `Lei nº 5.194/1966, art. 16`
obriga placa visível e legível ao público enquanto durar a obra, e a
`Resolução CONFEA nº 407/1996` detalha o conteúdo mínimo. **A lei fixa o
CONTEÚDO e não fixa a FORMA** — é por isso que a placa é peça legítima do
design system, e não um formulário.

Conteúdo obrigatório, que a peça carrega como **placeholder** (ordem dele:
*"isso aqui é template, vc nao precisa ter informação especifica"*):

| Campo | Fonte |
|---|---|
| descrição da obra ou serviço | art. 16 |
| **responsável técnico**: nome · título profissional · nº CREA | Res. 407/1996 |
| atividades pelas quais responde tecnicamente | Res. 407/1996 |
| autor do projeto (e coautores) | art. 16 |
| **executora** com nº de registro ou visto no CREA | Res. 407/1996 |
| nº da ART | prática decorrente (a placa fica até a **baixa** da ART) |

**A cor da assinatura — e a correção de um erro meu, registrada porque ela
ensina mais que o acerto.** A faixa de topo é `turquesa-800` (`brand-deep`), e
sobre ela vai o **`simbolo-mono-negativo.svg`** (branco). O asset está certo — mas
**o motivo que eu escrevi na primeira versão estava errado.**

Eu justifiquei a escolha pela **MR-P11** (o amarelo fora de peça instalada onde há
sinalização de segurança), tratando "canteiro" como o gatilho. Ele corrigiu o
escopo em 2026-08-24 (ver §17.6): **o critério é COMPARTILHAR CAMPO VISUAL com
sinalização amarela** — quadro elétrico, porta de subestação, painel —, e a placa
de obra, na entrada da obra, não está nessa condição. **A MR-P11 não se aplica
aqui.**

O motivo verdadeiro é mais simples e já estava no canon: a **matriz da §5.1** manda
mono-negativo sobre fundo **escuro, incluindo `brand-deep`**. Ou seja: cheguei ao
asset certo por uma regra errada.

⭐ **Consequência prática: a placa está LIVRE para usar o amarelo de marca** — o
desenho atual simplesmente não precisa dele, e isso é escolha de composição, não
restrição. Registrado para que ninguém "conserte" a placa amanhã achando que ela
está sob a MR-P11.

⭐⭐ **E a lição de método vale para todo o acervo: acertar o resultado por uma
razão errada é pior do que errar, porque não deixa rastro.** A régua nova é ler
a regra ANTES de invocá-la, e não a partir da lembrança do que ela dizia.

**Medida:** as fontes indicam **1,00 × 0,50 m como mínimo sugerido**, não como
imposição legal; os dois tamanhos saem de chapa cortada sem sobra.
**Resolução:** grande formato é montado a **2 px/mm** (≈ 51 DPI no tamanho
final), declarado no próprio arquivo — placa é lida a metros, não a palmos, e
renderizá-la a 300 DPI produziria 23.622 px de largura sem ganho nenhum.

**Fronteira `[não conferido]`:** se algum CREA de MG, ES ou BA publica exigência
regional adicional (medida, cor, ordem dos campos). Antes do primeiro uso real,
confirmar com o engenheiro responsável na circunscrição.

---

### 12.2 TIMBRADO A4 — `estável` (2026-08-24, F8 Onda 1, item 1.2)

**Gerador:** `06-validacao/geradores/gen-timbrado.py` · **peça:**
`07-pecas/timbrado-a4/` em duas variantes do MESMO código — `mock` (mostra a
área útil, para gate) e `limpo` (o template, sem uma linha de conteúdo).

⭐ **A ÁREA ÚTIL É O ENTREGÁVEL, e ela é herdada.** O plano fixa que
*"o timbrado vem antes de proposta, laudo e memorial porque os três nascem
dele"*.

**DUAS VARIANTES DE RODAPÉ, por decisão dele em 2026-08-24:** *"Em um ofício,
carta, etc, o rodapé pode ter uma altura maior, mas se tratando de um orçamento,
precisamos ter mais área útil para os dados propriamente ditos."*

**⭐ MOLDURA AMPLA desde 2026-08-31 (Onda 3, rodadas 3–4; MANIFESTO §138.4/§139).**
Ordem dele, verbatim: *"Quero que reveja a margem superior, precisamos ganhar
area, mantenha a logo mais alta possível para aumentar a area útil. o mesmo nas
margens da direita e esquerda"* + *"preciso do rodapé menor (...) pode diminuir
a altura das onads e crescer a quantiade de ondas"* — e na rodada 4: *"sim,
propaga"* (à família inteira) e *"promove"* (a este parágrafo). Os limites que
governam os números: a margem de 7 mm é a **zona de exclusão X da própria logo**
contra a borda (6,72 mm medidos no bbox do asset, arredondados para CIMA — 79 px
seria 6,69, abaixo de X); as ondas do rodapé a 10 mm são o piso conjunto das leis
§7.4-c (traço ≥ 0,25 mm → 0,255) e §7.4-f (span ≥ 125 mm/cópia → 126,9), com
1,54 cópias cobrindo a largura.

| Grandeza | `ofício` | `orçamento` | `compacto` |
|---|---|---|---|
| Formato | **210 × 297 mm** (A4), 300 DPI | idem | idem |
| Margem lateral | **7 mm** | idem | idem |
| Faixa de cabeçalho | **29 mm** (logo horizontal a 46 mm, topo a 7 mm) | idem | idem |
| Faixa de rodapé | **33 mm** — três colunas de sede (faixa medida no render: bloco a 30,72 mm do corte + 2,28 de folga) | **22 mm** — ondas 10 mm + texto base 14 mm | **8 mm** — uma linha de contato |
| Grafismo no rodapé | sim (ondas 10 mm) | sim (ondas 10 mm) | **NÃO** |
| **ÁREA ÚTIL** | **196 × 227 mm** a partir de (7, 29) | **196 × 241 mm** a partir de (7, 29) | **196 × 256 mm** a partir de (7, 29) |

**Ganho da moldura ampla sobre a original (20/44): +24,6% de área útil no
orçamento** (37.910 → 47.236 mm²). Histórico: a moldura original (margem 20,
cabeçalho 38, rodapés 40/25/8, útil 170×205/223/241) valeu de 2026-08-24 a
2026-08-31 e vive no histórico git; a marca d'água de contorno do símbolo
(explodida, §138.4) é da família orçamento/proposta/portfólio.

### ⭐ A REGRA DE USO DAS TRÊS, decidida por ele em 2026-08-25 — **[LEI]**

> *"o rodapé maior deve ser usado apenas para aplicações como carta, oficio, etc.
> criações como laudos, relatorios, orçamento, proposta, etc, o foco é otimizar a
> area útil para caber mais informação com o foco em diminuir o numero de paginas
> **sempre**."*

| variante | quando |
|---|---|
| `ofício` | **carta, ofício e correspondência formal** — onde o destinatário precisa do endereço completo das três sedes para responder |
| `orçamento` | **documento técnico e comercial** — proposta, orçamento, laudo, relatório, memorial, as-built |
| `compacto` | peça em que **área útil é o recurso escasso**, ou que se imprime em volume |

⚠ **A regra é de PRIORIDADE, não de conveniência**, e por isso quatro peças da
Onda 2 estavam erradas: as quatro nasceram em `ofício` com o mesmo argumento
plausível — *"o destinatário é um terceiro que precisa do endereço completo"*. Em
documento técnico o recurso escasso é a **área útil**; o endereço vive no corpo do
documento e na linha de contato. *Argumento plausível não vence prioridade
declarada.*

⭐ **A VARIANTE `compacto` NASCEU DE UMA PEÇA, não de uma proposta.** O diário de
obra tinha um rodapé **local** de uma linha, escrito para o caso dele — *"bloco de
50 vias não paga rodapé de 40 mm"* —, e ele o reconheceu como padrão:
> *"Gostei que em um dos materiais nao utilizou as ondas (morros) deixou apenas
> uma linha com o site, contato, telefone, etc no rodapé, isso mostra que nem todo
> material precisa das ondas, podendo otimizar o espaço. **é um modelo de
> rodapé**."*

É a terceira vez nesta fase que uma regra da casa nasce assim — as outras duas
foram a compressão do rodapé de orçamento e a serra que sangra no cartão. *Peça
resolvida com cuidado vira regra; regra inventada sem peça vira nota que ninguém
lê.* E promovê-la ao `gen-timbrado.py` paga parte da dívida de duplicação que o
paralelismo da Onda 2 deixou.

⚠⚠ **POR QUE O `compacto` NÃO LEVA GRAFISMO, e isto é conta e não gosto.** A
altura do divisor e a espessura do traço são a **MESMA grandeza** — a escala
(§7.4-f). Um grafismo espremido para caber num rodapé de 8 mm teria traço abaixo
do piso de 0,25 mm do §7.4-c. **Não existe "grafismo pequeno": existe grafismo ou
não existe.** Tirar as ondas é o que torna os 8 mm possíveis — a ausência do
grafismo não é o preço da variante, é o mecanismo dela.
⭐ E a consequência de instrumento é declarada: nesta variante a **MM1-a sai
`[n/a]`** com motivo, que é o veredito correto pelo §7.4-f e não uma lacuna.

⭐ **Os últimos 5 mm vieram de uma sugestão dele, e ela nasceu de olhar o
render:** *"a matriz e filial podem entrar abaixo da linha ficando acima do site
e abaixo da linha, comprimindo de forma que nao tocaria nas montanhas (ondas) e
otimizaria mais a area util?"* No `orçamento` o separador sobe e vira o **teto**
do rodapé; sede e contato se empilham abaixo dele.

E o bloco pôde **descer** porque a medição mostrou folga sobrando: a
`ferramentas/mede-faixas-tinta.mjs` achou que **a tinta da onda começa a
14,99 mm do corte**, enquanto a **caixa** do SVG começa a 17,4 mm — havia
**4,23 mm sem uso** que nenhuma medida de layout mostrava. ⭐ **Régua: caixa não
é tinta.** Espaço entre elementos se mede no pixel pintado, não no retângulo que
os contém — aqui a diferença foi 2,4 mm num rodapé de 27, quase 9%.

Depois da mudança, medido de novo: separador a 26,50 mm · sede 24,38→21,93 ·
contato 19,39→17,02 · onda 14,99→4,06 — **folga de 2,03 mm** entre a base do
texto e a tinta da onda.

⚠ **O que NÃO dá para encolher, e o motivo é físico.** O rodapé encolhe pelo
TEXTO, nunca pelo grafismo: a altura do divisor e a espessura do traço são a
**mesma grandeza** (a escala). Na proporção natural — 13,4 mm para 170 mm de
span — o traço mais fino mede **0,342 mm**, com 36,7% de folga sobre o piso de
0,25 mm do §7.4-c. Reduzir a 75% levaria o traço a 0,257 mm, folga de 3%:
apertado demais para impressão. *Querer rodapé mais baixo com traço mais grosso
é querer que a escala seja duas coisas.*

⚠ **A COLISÃO que o render pegou:** a primeira versão pôs o bloco de texto a
14 mm (ofício) e 8 mm (orçamento) do corte, e o topo da onda está a **17,4 mm** —
a onda passou **por cima da linha de contato nos dois**. É a classe SH1 do §72,
e não apareceu em nenhuma suíte, só no PNG. O texto agora fica a 19 mm, com
1,6 mm de folga sobre o topo da onda.

Ela sai impressa no próprio arquivo (`<meta name="area-util">`), para que a
proposta e o laudo a **leiam** em vez de a redescobrirem.

**Rodapé:** sede(s) + linha de contato + o **detalhe de linha** do grafismo na
base, que é o que a §12 manda para papelaria. Os dados vêm do `sobreaseed.md` §1
e **só de lá**.

⚠ **CORREÇÃO DE 2026-08-24: a MATRIZ é GOVERNADOR VALADARES.** O
`sobreaseed.md` registrava Baixo Guandu como matriz e Governador Valadares como
"sede administrativa em construção" — **errado desde a transferência**. Baixo
Guandu segue sendo a **cidade de fundação** (2016), que é outra coisa, e as duas
precisam estar no registro. **Toda peça que lista as sedes põe a MATRIZ primeiro
e rotula as outras como FILIAL.** (A reconciliação de 2026-07-17 sobre o endereço
— Rua Duarte Coelho, 205, nunca "Rua Albânia" — continua valendo.) Veredito dele sobre a forma: *"nao quer dizer que precisamos
construir um rodapé igual, quero algo com a nova identidade da empresa"* — o
rodapé antigo é referência de **conteúdo**, não de forma.

---

### 12.2-b MARCA D'ÁGUA DE CONTORNO DO SÍMBOLO — complemento do timbrado (`estável`, Onda 3, rodadas 2–5)

Gerador: `gen-timbrado.py`, função `marca_dagua(composicao)`, consumida por
opt-in pelos geradores da família. **Escopo declarado, 12 peças e só elas:**
timbrado-a4-orcamento (mock + limpo) · proposta (técnica capa/escopo,
comercial capa/condições) · proposta-plus (capa · planos · investimento) ·
portfólio (capa · case-modelo · contracapa). A moldura é compartilhada por dez
outros consumidores (laudo, memorial, as-built, checklist, one-pagers…) e o
veredito **não os inclui**; a folha do brinde técnico também fica fora. Quem não
chama `marca_dagua()` sai byte-idêntico.

**Nasceu de um pedido dele no gate da rodada 2** (2026-08-31, MANIFESTO §137.3):
*"Nos orçamentos e Portfolios (paginas), gera uma imagem da logo da seed com
apenas os contornos da logo, e utilize como marca d`agua bem clarinha de fundo."*
A primeira aplicação pôs a logo horizontal completa, 150 mm, central — e ele
mandou refazer ANTES do gate, com a foto do símbolo em contorno anexada
(§137.5): *"a proposta nao é ela aparecer pequena na folha, é pra ela aparecer
explodida, bem grande, pode até ser de forma repetitiva, formando linhas
interessantes de fundo."*

**Duas composições oficiais, as duas por veredito dele:**

| composição | estado | veredito | geometria |
|---|---|---|---|
| **E1 — explodida** | **APLICADA nas 12 peças** | R3-M1 (§138.4) e reconfirmada na R5-M1 (§140): *"fica a E1"* | símbolo em contorno a **360 mm de largura de viewBox (≈1,71× o A4; 248,5 mm de corpo)**, borda esquerda a −73 mm e superior a −30 mm — sangra pelas quatro bordas, recortado pelo `overflow:hidden` da peça. O recorte foi escolhido OLHANDO entre 4 composições renderizadas: o miolo da espiral fica fora do centro óptico (baixo-direita) para que cruzem a área de texto as CURVAS LONGAS, não o nó denso |
| **P3 — repetitiva, cantos opostos** | **OFICIAL, disponível** (disponível ≠ aplicada: trocar uma peça para cá é decisão de gate) | R5-M1b (§140): *"P3 — cantos opostos"*, depois de a repetitiva inclinada de 2026-08-31 ser reprovada na R4-M7 (*"nao está bom da forma que a logo está sendo aplicada nas repetitiva, talvez usar nao só 2 logos, mas mais logos menores, de maneira ordenada, nao muitas"*) | dois símbolos em pé, **180 mm de CORPO** cada, centros em (15, 238) e (195, 55) mm da página A4 — duas parênteses em diagonal que se encontram em x = 105 mm sem se cruzar; nenhum toca a logo do cabeçalho. Densidade de tinta da página medida no PNG limpo: **1,79%** (0,88% dentro da área útil) |

**As regras que valem para qualquer composição (do bloco do gerador e de §139.2):**
- O **asset é o SÍMBOLO** (`simbolo-principal.svg`), não a logo completa: explodido, o wordmark viraria letras cortadas. O contorno é **transformação mecânica** do asset oficial (§14.11) — os mesmos paths, cada `fill` do `<style>` reescrito para `fill:none` + stroke; nenhum path é removido.
- **UPRIGHT, 0° sempre** (§5.5: o símbolo não se rotaciona nem espelha). A repetitiva inclinada saiu do código.
- **Tamanho declarado pelo CORPO visível, nunca pela caixa do viewBox.** ⭐ Foi a origem do "pequeno" das composições reprovadas: `simbolo_contorno(px(58))` dá 58 mm de viewBox, mas o corpo desenhado ocupa 650,2 das 942 unidades (69%) — o símbolo tinha 40 mm. Medido (Chrome `getBBox`, 2026-09-02): corpo em (100,5; 119,0)–(750,7; 815,5) do viewBox 942 × 935.
- **O ® satélite fica FORA, por recorte, nunca por edição do asset:** na E1 cai além dos 210 mm da página por conta declarada (212,9 mm); na P3 sai por `clip-path` no canto (x > 745 e y < 230 do viewBox), e o recorte é estrutural — sem ele o símbolo de baixo poria um ® de 26 mm no meio da área útil. Conferido no PNG de prova (zoom na janela do anel: nenhum traço).
- **Cor `turquesa-100` (#CDF3EC)** — visibilidade 1,19:1 sobre o branco (cor.py, 2026-08-31). Sobre o traço, as tintas da casa medem: text-muted 4,71 · text-secondary 6,50 · text-primary 11,52 · turquesa-700 5,31 — todas ≥ 4,50. O consumidor **tem de declarar `seed-turquesa-100`** no bloco de tokens, senão o `var()` não resolve e o contorno some em silêncio (classe da PT-02).
- **Traço 0,35 mm** impressos — 40% de folga sobre o piso de 0,25 mm (§7.4-c); espessura física, independente da escala do símbolo.

⭐⭐ **O FURO ANTIGO QUE A RE-MEDIÇÃO ACHOU, e que virou régua (R3-M2, §137.5 e §138.4):**
a tinta **turquesa-600** dos números de seção media **4,60:1 sobre o BRANCO PURO** —
folga de 0,10 sobre o piso — e **3,86 sobre o traço da marca d'água**. Nenhum
clareamento do véu resolve (turquesa-50 como traço daria 1,07:1 e ainda não
salvaria), porque o furo é da TINTA. Saída medida e decidida: **turquesa-700
(5,31:1)** nos números de seção das peças com marca d'água (já registrado no
changelog v5.30). **Régua: o piso de contraste se confere contra o PIOR fundo que
a peça admite, nunca contra o branco.**

**Histórico que fica como história, não como opção:** os protótipos E2, P1, P1b,
P2, P2b e P4 (rodada 5, §139.2 — densidades 1,90 · descartado · 1,37 · 2,17 ·
2,72 · 1,93%) saíram do código e vivem em `preview/gate-r3-apoio/wm-*.png` e no
commit `db91fbd`. *Protótipo reprovado que fica no código vira "opção" para quem
lê depois.*

### 12.3 COMPROVANTE DE REGISTRO DE PONTO DO TRABALHADOR — `estável` (2026-08-24) · fecha a **PT-P1**

**Gerador:** `06-validacao/geradores/gen-comprovante-ponto.py` · **peça:**
`07-pecas/comprovante-ponto/` em duas vias — **bobina 80 mm** (impressa) e
**A4** (a via em PDF).

**Por que existe:** ele informou em 2026-08-24 que a SEED terá app de campo com
registro de ponto offline e sincronização, e pediu *"pode formalizar o layout do
recibo do ponto, é bom ter no template"*. A pesquisa mostrou que **o comprovante
é obrigatório por norma**, não cortesia.

**A norma — Portaria MTP nº 671/2021**, que criou o **REP-P** e **admite
expressamente a marcação offline com sincronização posterior**. Campos exigidos,
todos como placeholder: título · empregador (nome, CNPJ/CPF, CEI se houver) ·
**local da prestação** · identificação do REP · trabalhador (nome e **PIS**) ·
data e hora · **NSR** (numeração sequencial que começa em 1 por
estabelecimento). Em formato eletrônico: **PDF com assinatura PAdES**, e o
empregador possibilita extrair os comprovantes das últimas **48 horas** no
mínimo.

**O que é NOSSO, e não da norma** — a norma fixa quais campos existem, não a
ordem nem a hierarquia: NSR e horário sobem ao topo em corpo maior, porque são
os dois que alguém confere depois · números que se comparam vão em mono ·
a via de **bobina usa o símbolo mono-positivo**, porque impressora térmica marca
em uma cor e o símbolo principal sairia como cinza sujo · a via A4 reserva uma
**faixa de verificação** para o carimbo PAdES, e ela existe no template
justamente para que nenhum carimbo caia sobre o conteúdo obrigatório.

⚠ **É a peça mais sensível do acervo em LGPD:** ela carrega, por exigência da
própria norma, **nome e PIS do trabalhador**. Todo valor é placeholder em
maiúsculas entre colchetes. **Nenhum dado real entra aqui — nem em exemplo, nem
em captura de gate.**

#### 12.3-a Como o comprovante CIRCULA — três superfícies, e só uma é o documento

Pergunta dele em 2026-08-24: *"o A4 — via em PDF também é usado se for um envio
por email? ou o envio por email é enviado o pdf e nao no corpo do email? tem a
situação de deixar disponivel em sistema para cosulta e nao enviar (nao tenho
certeza) nesse caso, o modelo disponivel dentro do sistema seria o mesmo?"*

**A dúvida dele sobre a disponibilização em sistema está certa, e a norma
responde.** A orientação oficial do Ministério do Trabalho sobre a Portaria
671/2021 diz que *"a emissão do comprovante no momento do registro de ponto não
é obrigatória caso seja disponibilizado ao trabalhador, por meio de sistema
eletrônico, acesso a esse comprovante após cada marcação, independentemente de
prévia solicitação e autorização"* — e que o empregador deve possibilitar a
extração dos comprovantes das marcações das **últimas 48 horas, no mínimo**.

| Superfície | O que é | Governada por |
|---|---|---|
| **Bobina 80 mm** | a via impressa entregue na hora | esta seção |
| **PDF A4** | **O DOCUMENTO** — é ele que leva a assinatura PAdES | esta seção |
| **Tela de consulta** | onde o trabalhador acha e baixa o seu comprovante | `seed-componentes.md` (arquétipo de TELA), pendência **PT-P2** |

**As três regras que decorrem:**

1. **O e-mail é TRANSPORTE, não documento.** Se houver envio, ele leva o **PDF
   anexo** e o corpo **não repete os dados**. Dois motivos, e o segundo é o mais
   forte: (i) o corpo do e-mail não é assinado em PAdES, então repetir o
   conteúdo cria uma **segunda fonte sem valor probatório** — e segunda fonte é a
   classe de defeito mais perigosa desta casa; (ii) **LGPD** — nome e PIS
   trafegariam e ficariam parados em caixa de entrada, fora do controle da
   empresa, para ganhar zero.
2. **A tela de consulta NÃO é a peça A4.** São superfícies diferentes com
   trabalhos diferentes: a tela é **consulta** (buscar, filtrar por dia, baixar)
   e vive no celular; o PDF é **documento** e vive no papel ou no arquivo. Repetir
   o layout A4 dentro de uma tela de celular produziria um PDF ruim numa tela
   ruim. **O que elas compartilham é a FONTE, não o layout** — o botão "baixar"
   da tela gera exatamente este PDF.
3. **Disponibilizar em sistema basta**, pela orientação acima; imprimir na hora
   passa a ser escolha de operação, não obrigação. A bobina continua existindo
   para quem marca ponto em relógio de parede no canteiro, onde não há celular
   com o app.

**Pendência nova `PT-P2`:** a tela de consulta do comprovante — arquétipo de
tela, não peça física, logo ela nasce no `seed-componentes.md` e não aqui.
Ela herda os quatro estados de sincronização da **OF10** (§90), porque um
comprovante de marcação feita offline só existe depois que subiu.

⚠ **[não conferido no texto oficial]:** a lista de campos foi montada a partir
de fontes secundárias e da linhagem da Portaria 1.510/2009; o Anexo da 671/2021
não foi lido na íntegra. **A conformidade tem de ser confirmada por quem
responde por folha de pagamento e pelo jurídico antes de qualquer uso real.** O
design system desenha a peça; não atesta conformidade trabalhista — a mesma
fronteira que vale para a ART.

---

> **Correção PP-P2 (2026-08-24) — o rótulo colado na sede.** No rodapé, as
> palavras "Matriz" e "Filiais" saíam quase encostadas na sede seguinte. Causa:
> o espaço literal entre duas tags `<span>` é renderizado com a métrica do
> elemento **PAI**, e o `<div>` das colunas não declarava `font-size` — o espaço
> saía com ~16 px numa peça de 2480 px cujos textos têm 28 e 30 px. Conserto:
> `margin-right` **explícito** de 0,6 mm (7 px) no span do rótulo, em vez do
> espaço entre tags. Preferiu-se a margem a declarar `font-size` no pai porque a
> regra da casa é "nada implícito": medida declarada não depende de herança e
> não volta a quebrar se alguém mexer no pai.
> Achado pelo agente da §12.7, que **importa** este rodapé em vez de copiá-lo —
> e por isso herdou o defeito e o viu.

### 12.4 O que passa a valer para TODA peça física (nasce com a Onda 1)

1. **Regeneração byte-idêntica.** Todo gerador de peça aceita `--checar` e prova
   que regenera o que está em disco, byte a byte. É a régua de porte da F7.7-P1,
   agora aplicada a peça.
2. **A tipografia embutida ABORTA se faltar.** Nenhuma peça é gerada com
   tipografia de reserva (contrato TP1). A primeira versão do gerador do
   comprovante apontava para um caminho de fonte inexistente e um `if exists()`
   fazia o conjunto sair vazio, em silêncio — a peça saía com fonte de sistema.
3. **O grafismo vem do GERADOR**, nunca do SVG de referência escalado à mão
   (`03-assets/grafismos/LEIA-ME.md`).
4. **O logo vem do asset**, jamais redesenhado (§14.11) — **e o asset precisa
   ser escolhido pela regra da peça**: o símbolo principal carrega amarelo e não
   serve a peça de canteiro (§12.1).
5. ⭐ **A peça prova que consome token MEDINDO no navegador**, nunca conferindo
   que a string está no arquivo. Instrumento: `guardas/guarda-peca-token.mjs`
   (PT-01/02/03), com pasta de prova que reproduz o defeito fundador.
6. **A prova visual é do INSTRUMENTO**, não de captura manual:
   `ferramentas/render-peca.mjs` lê o `alvo-fisico` declarado, captura o
   elemento (não a janela) e exige **duas cargas byte a byte iguais**.
7. ⭐ **NENHUMA MARCAÇÃO APARECE COMO TEXTO NA PEÇA.** Instrumento:
   `guardas/guarda-escape.py` (**ES-01** tag HTML escapada visível · **ES-02**
   entidade escapada duas vezes), que lê o arquivo — é defeito de texto, e texto
   se mede no texto. `<pre>` e `<code>` são isentados, com a contagem impressa:
   ali exibir marcação é o uso CORRETO do escape.
   **Origem:** três ocorrências num só dia, todas por o **contrato de escape não
   estar declarado** — entidade escrita à mão na constante, HTML pronto passando
   por função que escapa, e tag dentro de constante de lista. Nenhuma foi pega
   por guarda alguma: o arquivo estava perfeitamente consistente, só dizia a
   coisa errada. A pior delas chegou a **estourar uma folha em 167,7 mm**,
   porque o `<span>` virado texto quebrou em dezenas de linhas dentro de uma
   coluna de 20 mm. E uma quarta, já na folha de gate da assinatura de e-mail,
   passou pelo gate HUMANO sem ser vista — `&middot;` no meio de um endereço em
   corpo de 2 mm não chama atenção.
   ⭐ **Regra derivada: `isinstance(str)` não é um teste de "precisa ser
   escapado".** Quem sabe se um valor é texto ou marcação é quem o PRODUZIU, e
   essa informação tem de viajar com o valor — nos geradores, pelo tipo `Cru`.
   E texto que vai para helper que escapa **não leva tag**.
8. ⭐ **A evidência tem de ser FRESCA, e isso se prova.** O PNG ao lado do HTML
   é conferido pela `guardas/guarda-peca-fresca.mjs` (**PF-01**), que
   re-renderiza em memória e compara PIXEL A PIXEL — nada é escrito. A régua é
   pixel e não byte porque o render do Chromium tem ruído medido: o mesmo HTML
   pode sair com 2 pixels de diferença em 8,7 milhões, com **Δ de 1 nível em
   255**, enquanto qualquer mudança real de conteúdo mede **Δ 244–246**. As
   duas populações não se tocam.
   **Origem:** em 2026-08-24 quatro peças ficaram com o PNG de um commit
   anterior ao do próprio HTML — o repositório guardou, como evidência de gate,
   imagem de outra versão do arquivo. Nenhum instrumento olhava para essa
   relação. Toda regeneração de HTML de peça obriga a re-renderizar o PNG e a
   **olhar** o resultado: o que mudou no HTML pode ter mudado o desenho.

### 12.5 Pasta A4 — capa institucional (`estável`)

Capa da pasta de apresentação, **uma face, 210 × 297 mm a 300 DPI**. Gerador:
`06-validacao/geradores/gen-pasta-a4.py`. Peças: `07-pecas/pasta-a4/`.

**Duas variantes obrigatórias**, e elas não são gosto: exercitam a matriz §5.1
nos dois fundos que a marca admite.

| variante | fundo | logo, pela matriz §5.1 |
|---|---|---|
| `claro` | branco | `logo-horizontal-principal.svg` |
| `brand-deep` | `#005048` | `logo-horizontal-mono-negativo.svg` |

- **Logo ao CENTRO**, porque a §5.3 manda centro em capa.
- Conteúdo: assinatura, marcador de detalhe, tagline, título de três linhas,
  slogan, grade dos **cinco pilares** e rodapé com as três sedes. Copy e dados
  vêm verbatim de `01-canonicos/sobreaseed.md` — §1 (sedes, matriz primeiro),
  §6 (pilares), §7 (slogan e tagline). Nenhum dado pessoal.
- **Na variante escura os dois planos de trás do grafismo quase somem.** Isso é
  a **E1-névoa**, aprovada pelo decisor em 2026-08-21 (*"pergunta 2, E1 nevoa
  fica melhor"*) exatamente para fundo escuro. **Não é defeito e não se
  "conserta".**

⚠ **Esta peça NÃO é o arquivo de produção da pasta.** É a capa plana, no
tamanho do corte. Pasta tem dobra, e peça com dobra precisa de margem de vinco
— a **MR-P12 está aberta**. Fazer a aba antes dela seria inventar medida.

⚠ **`07-pecas/gate-7-formatos/F6-pasta-A4.html` NÃO é esta peça.** Aquele
arquivo é **evidência do gate do grafismo** — uma das sete proporções em que a
cena Z3 foi promovida — e carrega a copy do `F1-post-1080`. O que ele prova é o
grafismo numa razão de A4, não uma pasta. Evidência reescrita deixa de provar o
que provou; por isso ele fica intocado.

**Régua de composição que nasceu aqui:** `<br>` não substitui a quebra
automática, **ele se soma a ela**. A primeira versão quebrava o título depois de
"conte com a", mas a linha não cabia na largura do bloco; o navegador quebrou
antes, as duas quebras se somaram e saiu um "com a" órfão no meio de quatro
linhas — com todos os placares verdes. **Quebra manual só é quebra se a linha
couber.**

⚠ **E a régua pegou o SEU AUTOR no dia seguinte.** A grade de soluções levava
`<br>` nos nomes longos, e "Consultorias em Eficiência Energética" saiu em TRÊS
linhas onde o `<br>` pedia duas: o resto ("Eficiência Energética", ~32 mm) não
cabia nos 29,97 mm da coluna e quebrou outra vez. Pior: o comentário que eu
mesmo escrevi ao lado do código afirmava que *"o nome mais longo por linha
caberia em 27 mm"* — **e eu não tinha medido**. Conserto estrutural: os nomes
não levam `<br>` nenhum. Medido depois de tirar: as quebras caem exatamente onde
o `<br>` tentava forçar (1, 2, 2, 1 e 3 linhas), e o texto mais largo de uma
linha é "Projetos Elétricos" com 25,80 mm.

**A GRADE DE SOLUÇÕES, refeita em 2026-08-25 — veredito dele:** *"a forma que
apresentou a lista de serviços da empresa com essa linha acima de cada nome ficou
muito infantil e pouco criativo. faça algo a nível da proposta."*
Estavam ali cinco filetes curtos, um por coluna, que liam como **cabeçalho de
tabela** — cada nome parecia o título de uma coluna vazia. Cinco réguas
paralelas de 30 mm não organizam nada; só repetem.
No lugar entra a gramática que a proposta usa para "lista de coisas importantes":
**um rótulo em caixa alta ("Soluções"), UM fio contínuo atravessando os 170 mm, e
cada solução numerada 01 a 05** em turquesa. Um fio que atravessa amarra o
conjunto; cinco fios paralelos o picam. E número ordinal é hierarquia — diz "há
cinco e esta é a primeira" —, enquanto filete repetido diz apenas "abaixo de mim
há texto", cinco vezes.

---

### 12.6 Envelope — ofício e saco A4 (`estável`)

Gerador: `06-validacao/geradores/gen-envelope.py`. Peças: `07-pecas/envelope/`.
**Seis arquivos**: dois formatos × três faces.

| formato | medida | fonte da medida |
|---|---|---|
| ofício | **229 × 114 mm** | **ABNT NBR 13314** (C6/C5), via Tabela 1 do *Guia Técnico CEPNet* dos Correios, 27/04/2021 |
| saco A4 | **240 × 340 mm** | medida de **mercado** (Scrity SKO 034 / Foroni) — `[não conferido]` em norma |

O saco A4 não está na tabela porque o **formato normal** dos Correios é
140–230 × 90–162 mm: ele é objeto **não mecanizável**. Declarar isso é a
diferença entre citar norma e alegar norma.

⭐ **A REGRA QUE MANDA NA PEÇA: os 20 mm da base da frente são dos Correios.**
*Guia CEPNet*, item 3.2 — "ÁREA 4", área branca e fosca reservada à impressão do
código de barras da máquina de triagem. No timbrado a serra chega a 4 mm do
corte; **aqui ela para a 23 mm** (20 de zona postal + 3 mm de folga, o mesmo
número da margem de segurança do §7.4-e). Medido no pixel: a tinta da onda
termina a **23,11 mm** do corte nas duas frentes.

Isto está escrito no gerador porque **nenhuma guarda desta casa pega**: é regra
postal, não regra de marca.

**Três faces por formato, do mesmo código:** `frente-mock` (com as guias de
gate), `frente-limpo` (o que vai para a gráfica) e `verso`. Guia impressa em
envelope é defeito de produção; se mock e limpo divergissem, o que o gate aprova
não seria o que se imprime.

**As três sedes vivem no VERSO.** O *Guia Técnico de Endereçamento* v1.4, §4.1,
diz que o remetente vai **preferencialmente no verso**, e que na frente deve
aparecer em corpo menor que o do destinatário — por isso a frente leva uma linha
condensada da matriz em **2,4 mm** contra o destinatário em **3,0/4,0 mm**.
Destinatário 100% placeholder, na ordem que a triagem espera ler (LGPD).

**O ofício engole o timbrado:** A4 dobrado em três dá 210 × 99 mm; o interior de
229 × 114 deixa **19 mm de folga no comprimento e 15 mm na altura**.

`[não conferido]`: o texto integral das ABNT NBR 12699 / 12972 / 13314 (normas
pagas — o que se conferiu foi a tabela do guia que as cita) · a medida da **aba**
do saco, que varia por fornecedor · e uma **contradição interna do próprio guia**,
que escreve "contado da borda direita" na frase da ÁREA 4 enquanto a figura 3
mostra a faixa na base (cotas 40/80/21/21/20 mm) — adotada a leitura da figura,
a confirmar na agência antes de tiragem grande.

⚠ **Manter 20 mm de zona limpa no SACO é decisão nossa de família, não norma** —
o saco não é mecanizável. Está declarado como tal no gerador e no
`<meta name="formato-postal">`.

⚠ **O design system desenha a peça; não atesta conformidade postal.** Quem
aceita a postagem é a agência — mesma fronteira da ART (§14.15).

Envelope **com janela** não foi desenhado: mudaria a posição do destinatário e é
variante nova, não ajuste desta.

---

### 12.7 Proposta comercial — modelo padrão e flexível (`estável`)

Gerador: `06-validacao/geradores/gen-proposta.py`. Peças: `07-pecas/proposta/`.

**Escopo, fixado pelo decisor em 2026-08-24:** este é o modelo **PADRÃO e
FLEXÍVEL** — orça **só material, só serviço, ou material com serviço**.
Fotovoltaico tem modelo próprio e o **SEED Plus** terá o seu; os dois são
customizações e estão **fora** deste escopo. Verbatim dele: *"nao estamos
criando o sistema aqui, aqui estamos definindo regras de design system, a
produção disso será no desenvolvimento do software."*

**DOIS DOCUMENTOS, não um.** Parte 1 de 2 **técnica** (escopo, sem uma única
coluna de preço — é a razão de existir dela) e parte 2 de 2 **comercial**
(valores, frete, pagamento, aceite). A capa comercial declara, em caixa de
ênfase, que **não vale isolada**; a faixa de identificação (número · parte ·
revisão · emissão · página X de Y) repete nas quatro páginas. É a contramedida
contra mandar meia proposta.

⭐ **A moldura é IMPORTADA, não copiada.** O gerador faz `import` do
`gen-timbrado.py` e usa o `cabecalho()` e o `rodape('orcamento')` dele, com uma
asserção que **aborta** se a área útil deixar de ser **(20, 44) 170 × 223 mm**.
Duas implementações da mesma medida divergem em silêncio — e a prova de que
isto funciona veio no mesmo dia: a correção da **PP-P2** no `gen-timbrado.py`
fez a proposta divergir no `--checar` e propagou sozinha ao ser regerada.

**PRAZO é bloco próprio na capa das duas partes** — início dos serviços, término
dos serviços, entrega dos materiais. Vem do **art. 40 do CDC**, que exige
orçamento prévio com mão de obra, materiais, condições de pagamento **e datas de
início e término**; §1º validade de 10 dias; §3º o consumidor não responde pelo
não previsto. As três cláusulas estão escritas na página de condições, com o
artigo citado.

**Todo número em Montserrat com `tabular-nums`, nunca em `--seed-font-mono`.**
JetBrains Mono não está versionada em `03-assets/fontes/`, e usar o token mono
numa peça impressa geraria com tipografia de reserva, o que o §12.4-2 proíbe.
Pendência **PP-P1**.

⭐ **A PROPOSTA É UMA, NUMERADA DE PONTA A PONTA** (decisão dele em 2026-08-25:
*"se é a mesma proposta, apesar de serem folhas distintas, ela é sequencial, e o
número de folhas vai depender do conteúdo após preenchido."*). Antes, cada folha
reiniciava os itens em 1 — a capa comercial ia de 1 a 4 e a folha de condições
voltava a 1 e ia até 6, como se fossem dois documentos.

| | folha | itens |
|---|---|---|
| **técnica** | 1 · capa | 1 Cliente · 2 Objeto · 3 Responsável técnico |
| | 2 · escopo | 4 Serviços · 5 Materiais · 6 Exclusos · 7 Responsabilidades do cliente · 8 Observações |
| **comercial** | 3 · capa | 9 Resumo do investimento · 10 Itens opcionais · 11 Prazo |
| | 4 · condições | 12 Frete · 13 Pagamento · 14 Condições · 15 Aceite |

⚠ **O total de folhas é `[N]`, placeholder, não número.** Escrever "de 4" no
template ensinaria que a proposta tem sempre quatro folhas — e a folha de escopo
é justamente a que cresce com o tamanho do fornecimento. `[N]` entra na mesma
linguagem de `[0000/2026]`: quem preenche, calcula.

⚠ **A numeração sai de UMA lista ordenada no gerador, nunca de número escrito à
mão, e o SUMÁRIO de cada parte é derivado da mesma lista.** Se o número morasse
em dois lugares (o corpo e o sumário), a primeira edição desalinharia os dois — e
o desalinhamento passaria em TODAS as guardas, porque nenhuma delas lê semântica
de sumário.

**TRÊS DECISÕES DE ORDEM, cada uma com motivo:**
1. **Sem duplicação.** Cliente, objeto, prazo e responsável técnico apareciam nas
   DUAS capas. Com numeração contínua isso fica insustentável — seria o mesmo
   dado com dois números. Cada informação vive numa folha só. A capa comercial
   não fica anônima: leva uma **linha de referência** (cliente e o item do
   objeto), sem número de item, porque é nela que se assina.
2. **O resumo do investimento subiu para a capa comercial.** É o número que o
   cliente abre a proposta para ver; esconder na folha 2 é escolher que ele
   procure. E os **itens opcionais vêm logo abaixo do total**, porque a nota deles
   diz que "NÃO estão somados ao total acima" — e uma nota que aponta para acima
   precisa que o acima esteja na mesma folha.
3. **O prazo saiu da técnica para a comercial.** O art. 40 do CDC exige as datas
   no ORÇAMENTO, e o orçamento é a parte comercial. Prazo sem preço não obriga
   ninguém a nada.

⚠ **A PARTE TÉCNICA NÃO TEM CAMPO DE ASSINATURA**, e o item "Aprovação técnica"
foi removido. Veredito dele: *"a proposta técnica nao tem necessidade do item 6,
é redundante. a assinatura já é feita na proposta comercial."* Assinar duas vezes
o mesmo negócio cria a dúvida de qual das duas obriga. O responsável técnico
continua **identificado** na capa, com nome, título e CREA — identificação não é
assinatura, e a ART exige a identificação.

**Placeholder deliberado:** exclusos típicos por pilar e responsabilidades do
cliente. Conteúdo de exclusão é risco comercial e técnico — precisa de veredito
do engenheiro responsável, não de preenchimento por design system.

**Achado de instrumento que esta peça pagou:** declarar `width`/`height` **na
classe** `.util` fez a `guarda-piso-mm.py` achar o tamanho da peça na primeira
dupla `width:…px;height:…px` do arquivo — que estava no `<style>`, antes do
`<body>`. A guarda passou a medir 2008 × 2634 px em vez de 2480 × 3508:
**MM1-b FAIL nas quatro**, e MM1-a e MM1-e reportando números errados **em
verde**. Regra: **largura e altura de peça vão inline no elemento**, depois do
`.peca`; a classe guarda só posicionamento.

---

### 12.8 Assinatura de e-mail (`estável`) — e por que ela NÃO é peça física

Gerador: `06-validacao/geradores/gen-assinatura-email.py`. Peças:
`07-pecas/assinatura-email/`. Governada pelo `04-email/seed-email.md`.

**Ela não declara `alvo-fisico`, `sangria` nem `papel`, e isso é correto:** não
existe corte, não existe milímetro, e o meio é o cliente de e-mail. Por isso sai
`[n/a]` na `guarda-piso-mm.py` e na `guarda-peca-fresca.mjs` — e `[n/a]` aqui é
o veredito certo, não uma lacuna.

⭐ **A assinatura NÃO foi reescrita.** `04-email/ea-assinatura.html` é `estável`
desde 2026-08-08 e continua sendo a fonte de verdade; o gerador **lê** aquele
arquivo e **deriva** a peça, com uma asserção que desfaz as substituições de
sentinela e exige o canônico **byte a byte de volta**. Motivo: EC1 manda "uma
fonte por componente", e o defeito 11 da F4 nasceu de uma peça que embutia a
assinatura e não foi regenerada.

**A limitação declarada, que é o ponto da folha de gate: e-mail não embute
fonte** (EM4 §5). O mock mostra **quatro estados**: (A) com Montserrat, (B) na
pilha de reserva, (C) com imagens bloqueadas, (D) a 320 px. Medido: A = 400×143
px, B = 393×125 px — a reserva é 7 px mais estreita e 18 px mais baixa, e **o
layout não quebra**; a diferença é tipográfica, não estrutural.

Pilha: `'Montserrat','Segoe UI',Roboto,Helvetica,Arial,sans-serif`. Outlook (todas
as versões) → Segoe UI · Gmail Android → Roboto · Apple Mail → Helvetica · resto
→ Arial. **Não se perde** a estrutura (tabela fixa em px) nem a palavra "SEED",
que é imagem.

Outras restrições que decidiram a peça: Gmail aceita `var()` e **ignora a
declaração** (EM1 §4) → hex literal, com asserção que aborta se divergir do
gêmeo · motor Word não renderiza SVG (EM5) → logo raster por **URL hospedada**,
não data URI, para não pesar em cada resposta da thread · Outlook corta em
**8.000 caracteres** (§8-D) → medido **1.893, 23,7% do teto**.

⚠ **O gate humano continua devendo e é a camada determinante:** Outlook 2024
clássico (motor Word), Gmail app Android com inversão forçada, Gmail web. Nada
local emula o Word — o mock é Chromium, o cliente mais permissivo que existe. E
**dark mode não é simulado de propósito**: simulação inventada viraria evidência
falsa.

⚠ **O PNG do logo vive só no bucket R2**, não no repositório, e não está
ancorado por MD5 no `MANIFESTO.md` — a regra 2 da EM11 pede isso. Pendência
anterior a esta peça.

---

### 12.9 Cartão de visita 90 × 50 mm (`estável`) — refeito do zero

Gerador: `06-validacao/geradores/gen-cartao.py`. Peças:
`07-pecas/cartao-90x50/`, duas faces.

**Formato 90 × 50 mm**, decisão dele em 2026-08-22 (§7.4-d): o padrão brasileiro,
contra os 89×51 mm que eram *default de ferramenta* — 3,5×2 polegadas, medida de
EUA e Canadá — e que ninguém havia escolhido.

**Por que foi refeito, e não corrigido.** Os três arquivos antigos em
`07-pecas/producao-cartao-90x50/` são da era Cowork: sem elemento `.peca`, sem
um único token do sistema, sem `<meta name="alvo-fisico">` nem `papel`, e com
PNG produzido em outro ambiente — invisíveis à `guarda-peca-token.mjs` e
irreprodutíveis pela `guarda-peca-fresca.mjs` (pendência `PC-P1`). **Veredito
dele em 2026-08-25:** *"mudamos muita coisa, logo, podemos refazer essas peças
do zero agora, nao tem problema, e ignora o que foi feito no passado. nada é
definitivo. se podemos melhorar, vamos melhorar."*

✅ **As três peças antigas foram REMOVIDAS em 2026-08-25**, com a tabela de
remoção apresentada e o veredito dele (*"sigo sua recomendação"*). Eram **arquivo
de produção**, não evidência de gate, e o arquivo de produção vigente passou a
ser este. ⚠ **O ponteiro da §7.4-d foi repontado ANTES de o arquivo sair**, e os
números que aquelas peças mediram — 1062×590 px, 299,7 DPI, traço de 0,250 mm —
ficaram registrados lá, porque foi neles que a decisão do formato se apoiou.
*Antes de remover, a pergunta é o que MORRE com o arquivo, não quem o menciona:
aqui o que morria era o ponteiro de uma norma.*
As evidências de gate de **peça larga** e de **grafismo em razão A4** seguem
intocadas, por decisão dele — e a `guarda-peca-fresca.mjs` passou a dar-lhes
veredito próprio, **`[hist]`**, em vez de reprová-las: *FAIL recorrente que todo
mundo sabe que pode ignorar treina o operador a ignorar FAIL.*

⚠ **"Ignorar o passado" valeu para o DESENHO, não para as medidas já aprovadas.**
O formato veio de lá. E a tentativa de trazer também a escala do grafismo
produziu o erro que virou a §7.4-f: medi 0,250 mm nos arquivos antigos, conclui
que escala 1:1 resolvia, e a guarda reprovou com 0,181 mm — porque aqueles
arquivos usam **outra cena** do grafismo (a Z3 "largos", ancorada por altura),
não o `svg_divisor`. ⭐ **Medir o artefato antigo não substitui medir o
INSTRUMENTO que vai gerar o novo.**

| face | fundo | logo, pela matriz §5.1 | grafismo |
|---|---|---|---|
| frente | branco | `logo-horizontal-principal` | não usa — MM1-a `[n/a]` declarado |
| verso | `brand-deep` | `simbolo-mono-negativo` | span 130 mm SANGRANDO (§7.4-f) |

- **Frente = informação:** logo, nome, cargo, fio e três contatos (telefone,
  e-mail, site). **Sem endereço** — três sedes em 90 mm fica ilegível, e o
  endereço está no site.
- **Verso = marca:** símbolo ao centro, tagline, grafismo na base. É a face que
  fica virada para cima no porta-cartão.
- **Margem de 6 mm**, o dobro da margem de segurança do §7.4-e. Num cartão a mão
  do leitor cobre a borda: conteúdo a 3 mm do corte fica sob o dedo.
- **Todo dado de pessoa é placeholder.** O cartão antigo trazia nome e cargo do
  CEO gravados no arquivo; este não. É template, e dado pessoal em artefato
  versionado é o que a §14.14 proíbe.

---

### 12.10 Proposta do SEED Plus (`estável`) — a peça em que o cliente ESCOLHE

Gerador: `06-validacao/geradores/gen-proposta-plus.py`. Peças:
`07-pecas/proposta-plus/`, três folhas.

**Por que não é a §12.7.** A proposta padrão orça um escopo **definido** — o
cliente aceita ou não. Aqui ele **escolhe entre três níveis de serviço**, e a
decisão depende de comparar o que cada um cobre. Logo o coração da peça é uma
**matriz comparativa**, não uma lista de itens, e existe um campo que a §12.7 não
tem: **PLANO CONTRATADO**, destacado, na folha que se assina. Sem ele, o que foi
contratado depende de memória.

| folha | itens |
|---|---|
| 1 · capa | 1 Cliente · 2 O que é o SEED Plus · 3 Usinas atendidas |
| 2 · planos | 4 Escopo dos planos (a matriz) · 5 Fora do escopo · 6 Observações |
| 3 · investimento | 7 Investimento por plano · 8 Formas de pagamento · 9 Condições · 10 Plano contratado e aceite |

Numeração contínua e `Folha X de [N]`, pela mesma decisão dele que governa a
§12.7. Moldura importada do timbrado (área útil 170 × 223 mm) e **helpers de
composição importados do `gen-proposta.py`** — duas implementações da mesma
medida divergem em silêncio.

**A matriz vem do `sobreaseed.md` §6** (2 · 4 · 7 itens, escada crescente), e a
peça imprime o **total de itens por plano** para a escada ficar visível de uma
vez. **O preço é por USINA**, não por cliente: um contratante pode ter várias, e
cada uma tem linha na tabela de usinas e na de investimento.

⚠ **A marca de "inclui" é Unicode explícito (`✓`), nunca caractere de fonte
simbólica.** O orçamento de origem usava **Webdings** — `a` para ✔ e `x` para
🚫 — e é exatamente isso que quase inverteu a leitura: lidos como letras, os dois
não dizem nada. Marca em fonte simbólica morre em qualquer extração de texto,
não é lida por leitor de tela e depende de a fonte existir na máquina. Cada marca
leva `aria-label`.

⚠ **`table-layout:fixed` é obrigatório na matriz.** Medido: no layout automático
o `width` de uma célula é apenas SUGESTÃO, e o navegador redistribuiu as quatro
colunas em 48/41/41/41 mm — deu à coluna de descrição **menos** espaço que às de
marca, e cada item passou a ocupar 29 mm de altura. Com `fixed`, as três colunas
de plano ficam nos 20 mm declarados e a descrição recebe os 110 mm restantes:
7,3 mm por linha.

⭐ **A VALIDADE É POR TIPO DE SERVIÇO — regra dele, 2026-08-25.** Não é constante
da empresa: é **função da volatilidade do custo daquele serviço**. SEED Plus são
**10 dias** (serviço, custo estável); **energia solar são 5**, porque o preço do
material muda e o risco é da SEED. O art. 40 §1º do CDC fixa 10 *"salvo
estipulação em contrário"*, então 5 é lícito — mas é **estipulação, e estipulação
tem de estar escrita na peça**. A tabela vive no `sobreaseed.md` §6.
⚠ Isto pesa mais na **§12.7** que aqui: a proposta padrão serve material,
serviço ou os dois, logo é o modelo em que a validade NÃO pode ser fixa. O campo
lá fica `[10]` de propósito, com a regra escrita ao lado — *placeholder sem
regra vira "todo mundo preenche 10"*.

✅ **AS CINCO LACUNAS FECHARAM em 2026-08-25**, com o contrato-modelo (rev. 00)
que ele anexou e os vereditos dele. A peça passou a poder afirmar:

- **uma preventiva por ano**, e o **escopo dela**, que era o item mais valioso do
  Premium e estava sem descrição: reaperto das conexões elétricas · verificação e
  reaperto das estruturas de fixação · medição de grandezas elétricas para
  análise de performance · limpeza de inversores, disjuntores e dispositivos de
  surto · limpeza dos painéis. Mais de uma preventiva por ano é **informada no
  orçamento**;
- **prazos de execução:** a primeira preventiva pode ser após **90 dias** da
  assinatura; data pedida fora da programação tem **prazo mínimo de 30 dias**; a
  corretiva tem **até 15 dias para verificação da demanda**, e esse prazo **não
  inclui** a correção;
- **tempo de resposta igual nos três planos** *(veredito dele)*;
- **vigência de 12 meses com renovação automática**, salvo aviso por e-mail com
  30 dias; **reajuste** a cada 12 meses comunicado com 30 dias, e sem acordo o
  contrato se rescinde sem penalidade;
- **é VENDA ANUAL parcelada em 12×**, não mensalidade — a diferença importa
  juridicamente e no fluxo de caixa, e a peça passou a dizer "valor anual";
- **as obrigações do contratante** entram nas observações (água, internet e
  energia no local · acesso ao monitoramento, à concessionária e à fatura ·
  projeto com 3 dias úteis de antecedência). *Proposta que esconde a obrigação
  do cliente cria surpresa na execução — e surpresa chega como reclamação, não
  como aditivo.*
- **o SEED Plus é só para energia solar** *(veredito dele)*.

✅ **`MR-P15` RESOLVIDA em 2026-08-25 — veredito dele: "o contrato está
correto".** A divergência era esta: ele havia dito que só a preventiva separava
Essencial de Premium, e o orçamento **e** o contrato-modelo traziam matriz
idêntica entre si com **três** itens de diferença. Levada com a matriz na tela, a
decisão confirmou os documentos.

⚠ **Fica registrado o que o Essencial NÃO tem, porque é contraintuitivo e vai ser
perguntado de novo:** nem **suporte por WhatsApp/telefone**, nem **apoio junto à
concessionária**. O Essencial é plano de *monitoramento e relatório, com suporte
para entender o relatório*; o canal de atendimento técnico da usina é do Premium.
**Quem escrever peça sobre isso não pode presumir que "todo plano tem um canal de
suporte".**

A peça já seguia a matriz, então o veredito não mudou artefato nenhum — mudou o
estado da regra, de divergente para **confirmada**. E isso vale o registro:
*divergência que fica aberta convida a próxima sessão a "consertar" o que está
certo.*

---

### 12.11 Laudo / relatório técnico (`estável`) — item 2.1 da Onda 2

Gerador: `06-validacao/geradores/gen-laudo.py`. Peças:
`07-pecas/laudo-tecnico/`, **três folhas A4** que formam UM documento —
**capa** (quem pediu, o que foi inspecionado, quem responde tecnicamente),
**medição** (valor medido × limite normativo, com o instrumento que produziu
cada número) e **conclusão**.

**Não havia modelo a seguir, e isso foi decisão dele.** Verbatim, 2026-08-25:
*"2.1 nao temos modelo para seguir, quero que voce construa do zero seguindo
padroes como voce fez, e depois podemos adpitar, voce fez corretamente. pois
quero refazer o que usamos, nao temos padrao."*

⚠ **A coluna do INSTRUMENTO é obrigatória na tabela de medição, e não é
enfeite:** número sem instrumento não é medição, é opinião com casa decimal.
A folha imprime modelo, número de série e validade da calibração.
⚠ **Nenhum laudo sai sem engenheiro responsável** (§14.15). A peça não
substitui a ART.

### 12.12 Memorial descritivo de instalações elétricas (`estável`) — item 2.2

Gerador: `gen-memorial.py`. Peças: `07-pecas/memorial-descritivo/`,
**sete folhas A4**: rosto · objeto · normas · dimensionamento · proteção ·
instalação · fecho.

**A folha de NORMAS é a que dá valor jurídico à peça**, e é a mais frágil: norma
citada com número errado ou revogada transforma o memorial num documento que
afirma conformidade com algo que não existe. Foi exatamente essa classe que
produziu o 58º defeito do projeto (uma peça `estável` citando Resolução CONFEA
1.025/2009, revogada em 2023 pela 1.137). **Toda citação normativa desta família
sai datada.**

### 12.13 Checklist de comissionamento e entrega (`estável`) — item 2.3

Gerador: `gen-checklist.py`. Peças: `07-pecas/checklist-comissionamento/`,
**oito folhas A4**: identificação · escopo da inspeção · inspeção visual ·
segurança · ensaios BT · ensaios MT · ensaios FV · encerramento.

⭐ **A função desta peça é JURÍDICA antes de ser gráfica.** A SEED entrega a obra
e vai embora; meses depois pode vir a pergunta *"isso foi testado?"* — em
reclamação, em sinistro de seguradora, em fiscalização. O checklist preenchido e
assinado é a resposta. Por isso ele tem campo de **assinatura e data por bloco**,
e não uma assinatura só no fim.

**Decisão dele sobre o escopo dos campos**, 2026-08-25, e ela vale para a família
inteira: *"pode seguir sua sugestao, pois quando formos realmente usar o template
para fazer, nesse momento que vamos editar adicionando ou tirando algum campo
mediante a necessidade."*

### 12.14 Selo (legenda) de prancha técnica (`estável`) — item 2.4

Gerador: `gen-selo-prancha.py`. Peças: `07-pecas/selo-prancha/`, com o selo em
**três alturas** (180 × 80 · 180 × 134 · 180 × 218 mm), a aplicação em A3 e A4,
as variantes mono e cor, e cinco folhas de medida.

**A largura de 180 mm não é escolha: é norma.** A **ABNT NBR 16752:2020** fixa a
legenda em 180 mm em TODOS os formatos de folha. ⚠ E ela **cancelou a NBR
10068:1987 e a NBR 10582:1998** — as duas que o briefing desta sessão citava como
vigentes.

**A altura varia com o tipo de projeto, por decisão dele**, 2026-08-25:
*"o selo de prancha vai depender do tipo de projeto, anexo segue um de subestação
da cemig e EDP para comparar, a cemig é mais completa."* As duas concessionárias
que ele anexou viraram as duas peças de comparação, e a variante alta (218 mm)
existe para o caso CEMIG, que pede mais campos.

**Altura de letra pela ABNT NBR 8402:** série 2,5 · 3,5 · 5 · 7 · 10 · 14 · 20 mm,
com `font-size = h ÷ 0,700` (capHeight da Montserrat, medido no arquivo TTF).
⚠ O 1,8 mm **não é** dessa série — é da ISO 3098, e o briefing o citava por engano.

### 12.15 Folha de rosto da ART, via de contingência do diário e a TELA do relatório diário (`estável`) — item 2.5

Gerador: `gen-art-diario.py`. Peças: `07-pecas/art-diario-obra/` —
`art-folha-rosto.html`, `diario-obra.html` e `diario-os-tela.html`.

⭐⭐ **Metade deste item mudou de natureza por uma frase dele**, 2026-08-25:
*"o diario de obra no nosso caso vai ser o relatorio diário que será preenchido
dentro da OS da obra."* O diário deixa de ser papel e vira **tela do ERP**, dentro
da Ordem de Serviço. A folha de papel **continua existindo**, como *via de
contingência* — obra sem sinal, fiscal que pede assinatura no local —, mas deixa
de ser a peça principal.

✅ **`AD-P5` — FECHADA em 2026-08-27, e a solução já existia DE FATO no próprio
exemplar:** o `diario-os-tela.html` se declara por completo e as guardas já o
tratam pela declaração (MM1 dá `[n/a]` com motivo). O que faltava era a
convenção estar ESCRITA como regra, e ela é esta: **mock de tela em `07-pecas/`
declara** `<meta name="superficie" content="tela">` + `alvo-tela` (px em vez de
`alvo-fisico` mm) + `estatuto` (dizendo que é mock estático de gate e onde vive
a tela operável) + `papel-irmao` quando houver via física. ⭐ *A natureza da
peça é o que ela DECLARA, nunca a pasta onde está — é a mesma régua do censo
("caminho não é classificador de tipo").* **`AD-P7`** (promover a tela a
arquétipo do ERP) segue aberta: é decisão de escopo do produto, dele, na onda
de aplicações.

⚠ **A citação da Resolução CONFEA na folha de rosto é datada**, pela lição da
§12.12: vale a **1.137/2023** (o art. 77 revogou a 1.025/2009).

⭐ **O bloco do diário NÃO é furado (veredito dele, 2026-09-02, MANIFESTO §140):**
*"alargar o corpo para 7 também — nao se usa mais furo"*. A margem de 20 mm que o
desenho reservava ao furo cai; corpo e rodapé seguem a moldura ampla (§12.2, 7 mm),
colunas alargadas proporcionalmente (170 → 196 mm). Picote e gramatura seguem
decisão da gráfica; a `MR-P12` (zona livre de furo/dobra) deixa de alcançar esta
peça.

### 12.16 Caderno as-built (`estável`) — item 2.6

Gerador: `gen-asbuilt.py`. Peças: `07-pecas/as-built/` — capa A4, folha de
controle de revisão e **lombada de 25 × 297 mm**.

"As-built" é o **conforme construído**: o registro do que foi EFETIVAMENTE
executado, **incluindo tudo em que a execução divergiu do projeto**. É o volume
que fecha a obra e vai para o arquivo do cliente, onde pode ficar dez anos sem
ser aberto — e é por isso que a **lombada** é peça própria: o caderno é achado na
prateleira ou não é achado.

⭐ **A folha de controle de revisão é o que separa as-built de "cópia do
projeto":** ela registra revisão, data, o que mudou e quem aprovou. Caderno
as-built sem histórico de revisão é projeto com outro nome.

### 12.17 Crachá de acesso, ID-1/CR80 vertical (`estável`) — item 2.7

Gerador: `gen-cracha.py`. Peças: `07-pecas/cracha/`, frente e verso,
**53,98 × 85,6 mm** (ID-1 da ISO/IEC 7810, na orientação vertical).

⭐ **A hierarquia é NOME primeiro, foto depois — decisão dele**, 2026-08-25:
*"acho que o nome é prioridade, quem olha o cracha olha pra ler o nome mais do
que conferir a foto."* Isso inverte o default de mercado e a peça segue a ordem
dele.

⭐⭐ **E este item encolheu de escopo por uma pergunta dele que virou regra da
casa.** Sobre a `MR-P12`, que tratava de detalhe de produção do crachá:
*"aqui voce está entrando muito no detalhe de produção do cracha, isso é mesmo
necessário no design system? o DS nao seria um template que depois onde fosse ser
produzido seria visto as regras do local para poder seguir o template? eu extendo
esse questionamento para tudo que estamos fazendo."*
**A resposta é sim, e vale para TODA peça física:** o DS fixa o **desenho**, e o
material, o acabamento e a tolerância de produção são do fornecedor, no momento
da produção. A `MR-P12` deixou de bloquear. ⚠ O que o DS **continua** fixando é o
que muda o desenho: dimensão de corte, margem de segurança, piso de traço e
legibilidade.

⚠ **LGPD (§14.14):** o crachá sai com placeholder. Nome, foto e documento de
pessoa real não entram em arquivo de repositório.

### 12.18 Etiqueta de equipamento instalado e selo de próxima revisão (`estável`) — item 2.8

Gerador: `gen-etiqueta.py`. Peças: `07-pecas/etiqueta-equipamento/` —
**etiqueta 110 × 80 mm** e **selo de revisão 60 × 45 mm**.

As duas têm funções **comerciais** diferentes, e a diferença governa o desenho:
a etiqueta é **pós-venda passivo** (anos depois, quem abre o quadro sabe quem
chamar); o selo é **receita recorrente** — carrega a data da próxima revisão,
escrita à mão em campo, e por isso a data é o maior elemento da peça, com 5,60 mm
de maiúscula.

**Premissa declarada: pior caso.** Ambiente externo, sol direto, chuva, por anos,
sobre carcaça que esquenta. Peça especificada para exterior serve ao caso fácil;
o inverso não vale. ⭐ E a premissa deixou de ser prudência e virou exigência
quando a pesquisa achou o **Projeto ABNT NBR 16690 (2018), item 10.2**, que pede
sinalização *"indelével"*, *"legível a partir de no mínimo 0,8 m"* e que
permaneça legível *"inclusive a sinalização exposta ao tempo"*.
⚠ `[não conferido]`: a norma publicada é a **NBR 16690:2019**; o que foi lido é o
projeto de 2018, que estampa *"NÃO TEM VALOR NORMATIVO"* em cada página.

⚠ **O amarelo `#FAD61D` não entra** (§17.6 / `MR-P11`): estas etiquetas são
coladas em quadro elétrico, inversor e porta de subestação — os três lugares que
ele nomeou ao aprovar a regra. Logo `mono-negativo`, nunca o `principal`, porque
o amarelo está DENTRO do arquivo oficial do logo principal.

### 12.19 Família de sinalização NR-10 (`estável`) — item 2.9

Gerador: `gen-sinalizacao.py`. Peças: `07-pecas/sinalizacao-nr10/` —
**placa de restrição de acesso A3** (297 × 420 mm), **etiqueta de impedimento de
energização** (120 × 200 mm) e **identificação de circuito** (105 × 74 mm).

⭐⭐ **A cor de segurança NÃO é do DS, e isso é decisão dele**, 2026-08-25:
*"normal de segurança deve seguir as cores da norma de segurança, nao podemos
impor nosso DS sobre isso."* E, no mesmo dia, o critério de conflito:
*"nao podemos competir com mensagem de segurança."*
⚠ **Cor de segurança não entra em `02-tokens/`** e se especifica contra **padrão
físico** (carta Munsell), nunca contra o hex desta página — duas fontes
secundárias da mesma notação Munsell divergiam em **ΔE76 = 5,44**. ⭐ E a leitura
da norma **confirmou por texto** o que já se havia decidido por medição: a própria
ABNT NBR ISO 7010 avisa que *"as cores representadas no arquivo eletrônico deste
documento não podem ser vistas na tela, nem impressas como representações
verdadeiras"* e manda buscar cor na **ABNT NBR ISO 3864-4**.

**Não se comprou a norma para desenhar, por decisão dele** (*"nao vamos adquirir
a norma, vamos montar o padrao"*): os pictogramas foram reconstruídos de desenho
público, com a fonte declarada símbolo a símbolo.

**Três pictogramas, e os três com estatuto declarado na própria peça:**
· **W012** (*Atenção: Eletricidade*) — conferido visualmente contra a arte oficial
  da p. 375, e **confere**;
· **P031** (*Proibido alterar o estado da chave interruptora*, referente oficial,
  citável) — conferido contra a p. 325 e a p. 148, e **confere**. A orla branca é
  **dispositivo nosso**, declarado: a arte oficial não a tem, e ela existe para o
  anel vermelho não se dissolver no campo vermelho da etiqueta;
· **W042** (*Atenção: Arco elétrico*) — ⚠ **conferência PARCIAL**. Ver adiante.

⭐⭐ **O W042 fecha uma LACUNA NORMATIVA, não é melhoria de desenho.** A NR-10 na
redação da **Portaria MTE 737/2026** (vigência 01/06/2027), item **10.7.7.1 b)**,
exige advertência de choque **e arco elétrico** — e a placa A3 **citava esse item**
cobrindo só choque. *A peça reivindicava um item que exige quatro coisas e
entregava três.* O raio é o **mesmo objeto** do W012, o que a ficha oficial manda
(*"Relâmpago (da ISO 7010-W012)"*) e a medição confirmou: 11 vértices alinhados
ciclicamente, erro médio 2,44%. Custo vertical de acrescentar o segundo
triângulo: **zero** — dois triângulos lado a lado têm a altura de um.

⚠⚠ **CORRIGIDO EM 2026-08-26, e é a correção mais séria desta família: a peça
AFIRMAVA uma conferência que não aconteceu.** O SVG do W042 saía com
`data-conferido-visualmente="sim, contra a arte oficial (…) p.405, em
2026-08-25"`. Duas vias desmentem: (a) o extrato da leitura
(`09-pesquisa/leitura-abnt-nbr-iso-7010.md`) tem a seção *"O que foi conferido"*
com **duas** entradas — W012 e P031 — e cita o W042 na seção de **ações**, como
"acrescentar à família"; (b) **a data é anterior ao desenho** — o W042 nasceu no
commit de 2026-08-26. ⭐ *Não se confere visualmente um desenho que ainda não
existe, e a data que estava ali para dar credibilidade é o que derruba a
afirmação.* ⭐⭐ **A classe importa mais que o caso:** o W042 foi acrescentado a
**três listas que já diziam "FEITA e CONFERE"** e herdou o verbo de graça —
*acrescentar item a uma lista de coisas verificadas propaga o veredito sem
propagar a verificação, e o custo de conferir some no meio da vírgula.*

**`SN-P12` — a linha de picos do W042 tem fonte única, e pior do que se sabia.**
Busca de 2026-08-26: a página do arquivo no Wikimedia Commons o declara *"similar
to recommendation issued in ISO 7010:2019"*, **obra própria** de um usuário (2019,
CC0) — não é a arte oficial nem traçado dela. ⭐ *"Fonte única" quer dizer que
ninguém confirmou; isto quer dizer que a própria fonte não afirma ser a oficial.*
O catálogo gratuito da ISO (OBP) responde 403 a acesso automatizado, e as demais
fontes são bancos de imagem comerciais — concordar com elas provaria que dois
terceiros concordam, não que o símbolo está certo.
**Fecha com conferência visual contra a p. 405 da ABNT NBR ISO 7010**, ~5 minutos
de leitura numa assinatura paga **por tempo**. Não foi feito porque ele perguntou
em 2026-08-25 se ainda precisava da assinatura e a resposta foi não; reabrir sem
ele pedir seria gastar dinheiro dele por conta própria.
**E o W042 fica assim mesmo:** sem ele a placa cita o item e cumpre metade;
*pictograma aproximado que comunica "arco elétrico" protege mais que a ausência
de pictograma.*

✅ **`SN-P8` — CONSERTADA EM 2026-08-26 SEM COMPRAR, e o resíduo está declarado
na peça.** Ordem dele: *"nao vamos comprar, use a melhor opcao conforme sua
recomendacao"*.

⭐⭐⭐ **A LEITURA QUE ABRIU O CAMINHO estava nos números da véspera e eu não a
tinha visto:** a medição contra a arte oficial separou **dois erros que eu
tratava como um**. A **razão da caixa** batia em ~1,7% — *a silhueta está certa*
— e o que errava era a **espessura dos membros**, em −12,1%.

**Se o defeito é só espessura, o conserto não é redesenhar: é ENGROSSAR.** Um
`stroke` da própria cor, com junta arredondada, cresce ao longo da normal de cada
aresta e **não move nenhum dos 11 vértices da IEC**. ⭐ *É por isso que esta
tentativa passou e a anterior — reconstruir os vértices do PNG de 200 px — havia
sido reprovada: aquela mexia na silhueta, esta não toca nela.*

**MEDIDO, com placar escrito ANTES e em DUAS réguas independentes:**

| medida | antes | depois |
|---|---|---|
| espessura do raio × oficial | **−12,1%** | **−2,3%** |
| tinta × oficial | −16,2% | **−5,2%** |
| discordância de forma, **W012** | 29,51% | **27,17%** |
| discordância de forma, **W042** | 16,39% | **16,16%** |
| razão da caixa do raio | ~1,7% | **3,8%** ⚠ |

⚠ **A quinta linha PIORA e ela fica na tabela.** O contorno cresce em todas as
direções e a caixa do raio é mais alta que larga — logo engorda
proporcionalmente mais na largura. ⭐ *O balanço é positivo porque a discordância
de forma, que é a medida integral, melhorou nos DOIS símbolos; mas conserto que
melhora quatro colunas e piora uma não é conserto gratuito, e omitir a quinta
seria escolher a régua depois de ver o resultado.*

**A ESPESSURA ESCOLHIDA — 0,902% da altura da caixa do raio — saiu de VARREDURA
MEDIDA, não de conta.** Dez valores testados; o escolhido empata com o vizinho na
espessura (a mediana é discreta em pixel nesta resolução) e ganha no **conjunto
dos dois símbolos**.

⚠⚠ **E EU QUASE PUBLIQUEI DUAS RÉGUAS NA MESMA TABELA.** O instrumento do teste
normaliza pela caixa do **preto** e dá 26,45%/22,87% para o estado atual; os
números do canônico vêm do `mede-w012.mjs`/`mede-w042b.mjs`, que normalizam pela
caixa do **amarelo** e dão 29,51%/16,39%. ⭐⭐ **Régua: comparação só vale DENTRO
do mesmo instrumento — número de régua diferente na mesma coluna não é
imprecisão, é comparação falsa, porque quem lê supõe a mesma unidade.** A escolha
foi conferida pelas duas.

⭐ **De brinde, e é medido pela MM1:** engrossar o raio **aumentou o pescoço mais
estreito** dele — o piso de traço que a `guarda-piso-mm.py` afere em milímetro
para a gráfica.

⚠⚠ **O QUE NÃO FICOU RESOLVIDO, e a peça imprime isso:** os **27,17%** seguem
**acima do piso de ruído de ~10%** do método. O conserto **reduziu** o desvio, não
o eliminou; fechar em definitivo continua dependendo do vetor oficial (CHF 30/
símbolo no OBP), que ele optou por não comprar. Os dois textos públicos da peça —
o impresso e o `<meta>` — foram reescritos **no mesmo commit** com os números
novos, o custo na razão da caixa e o resíduo. ⭐ *Afirmação numérica impressa tem
de ser reescrita no commit que muda o número — deixar para depois é como o
defeito da §12.19 nasceu.*

⭐⭐ **ADENDO DA v5.23 (2026-08-26) — o W042 e o W012 compartilham o MESMO objeto
de raio, e isso muda a conta da compra.** O `gen-sinalizacao.py` define
`RAIO_5036` como **uma constante única**, e a §12 registra por escrito *"é o MESMO
objeto, sem uma cópia"* — o que a ficha oficial da ISO manda (*"Lightning bolt
(from ISO 7010-W012)"*). Duas consequências:
**(a)** o **"+0,5% de espessura" do W042 NÃO afirma que o raio dele confere.**
Aquela medida é a mediana das extensões de preto do conjunto **raio + linha de
picos**, e a linha de picos, sendo larga, **domina a mediana e mascara o raio
fino**. Por identidade de código, o raio dentro do W042 está os mesmos **12,1%
mais fino**. ⭐ *Métrica agregada não herda o veredito para as partes — e "o
conjunto confere" não é "cada peça confere".*
**(b)** **comprar só o W012 conserta os dois símbolos**, porque basta trocar a
constante. Logo as saídas são: **CHF 30** (só o W012 — fecha o raio nas duas
peças, deixa a linha de picos do W042 em desenho de terceiro) · **CHF 60**
(W012 + W042 — fecha o raio **e** a linha de picos) · **CHF 90** (os três —
**paga CHF 30 para confirmar um P031 que já bate em +0,6%**).
**RECOMENDAÇÃO APRESENTADA A ELE: CHF 60.** Não pelo raio, que os CHF 30
resolveriam — **pela linha de picos do W042**, hoje vinda de arquivo publicado
por usuário no Wikimedia Commons cuja própria página diz ser *"similar a"* a
recomendação da ISO, sem afirmar ser a arte oficial. **Essa geometria está na
placa que adverte arco elétrico**, que é risco de morte.
⚠ **A compra é ação dele** — envolve dado de pagamento, que nunca passa por mim.
E não comprar segue defensável: as placas imprimem, e **a peça declara o desvio
em texto visível** desde 2026-08-26.

**`SN-P8`** (dúvida de até 4,71 mm na espessura dos membros do raio) **não se
fecha com a 7010** — é a **ISO 3864-3** que traz construção. Decidido, não reabrir.

### 12.20 Placa de identificação do quadro (`estável`) — nasce da `SN-P13`

Gerador: `gen-placa-quadro.py`. Peça: `07-pecas/placa-quadro/`,
**100 × 70 mm**. A placa que a SEED afixa no quadro que ela monta, na condição de
**fabricante do conjunto**.

⭐ **Esta peça não estava no plano — a `SN-P13` fechou por REFORMULAÇÃO.** A
pendência perguntava se quadro isolado precisa de placa de **advertência** própria
(medido: exigiria A2). A resposta dele, 2026-08-26, redirecionou a pergunta:
*"os quadros eletricos possuem placas de fabricação e identificação, que pode ser
um placa da seed, ela motra a tensao do quadro e pode ter mais alguma
informação."* **O quadro isolado não ganha placa de advertência; ganha a placa que
qualquer quadro já deveria ter e que a SEED, como montadora, é obrigada a
fornecer.** *A pergunta certa não era "que sinalização falta?", era "que placa a
norma já exige de nós e nós não estávamos fazendo?".*

⚠⚠ **O ACHADO NORMATIVO CONTRARIA O QUE O MERCADO REPETE.** Lida a
**IEC 61439-1 Ed. 2.0 (2011-08), cláusula 6.1**, a etiqueta de designação do
conjunto exige **quatro** informações e só quatro: (a) nome ou marca do fabricante
do conjunto · (b) designação de tipo ou número de identificação · (c) meio de
identificar a data de fabricação · (d) IEC 61439-X. **Tensão, corrente,
frequência, Icc e IP NÃO estão nessa lista** — a cláusula **6.2.1** manda as
características da Seção 5 para a **documentação técnica**. Três páginas
brasileiras consultadas afirmam o contrário e nenhuma cita cláusula. *A norma foi
lida; as páginas, não.*

**A peça tem DOIS BLOCOS com estatutos diferentes, e IMPRIME a diferença:** o
normativo (os quatro campos da §6.1) e o elétrico (tensão em destaque, corrente,
frequência, Icc, IP), este por decisão dele e pela **ABNT NBR 14039 4.2.5.3**, que
manda indicar claramente a tensão nominal. ⭐ *Peça que mistura o obrigatório com
o escolhido, sem dizer qual é qual, transforma decisão nossa em norma alheia — e
aí ninguém consegue mudar a nossa própria decisão sem parecer que está violando a
norma.*

**Material:** alumínio anodizado gravado ou inox a laser. ⚠ **Adesivo não atende**
a intenção do ensaio **10.2.7** (legibilidade após esfregamento) em quadro externo.

⚠ `[não conferido]`: a **IEC 61439-2** não foi lida, e a NOTA da §6.1 admite que a
parte aplicável exija campo adicional na etiqueta. Se exigir, esta peça já os traz
**por decisão** — o que muda é o estatuto deles, não o desenho.
⚠ **Esta placa não substitui a etiqueta de equipamento** (§12.18): aquela diz
*quem instalou e quando chamar*; esta diz *o que este conjunto é*. ⭐ E a lacuna
estava anotada no acervo desde a Onda 2 — o `gen-etiqueta.py` já dizia por escrito
que *"esta etiqueta não substitui a placa de dados do fabricante"*, e **a peça que
ela dizia não substituir simplesmente não existia**.
⚠ **`PQ-P2`:** a etiqueta de circuito disjuntor a disjuntor (§6.3 da mesma norma,
com IEC 81346-1/-2) **não foi feita**.


### 12.21 Cartela de identificação de dispositivo do quadro (`estável`) — fecha a `PQ-P2`

Gerador: `gen-etiqueta-circuito.py`. Peça: `07-pecas/etiqueta-circuito/`,
**cartela A4** com tiras destacáveis de **17,5 × 9 mm** (1 módulo DIN) e
**35 × 9 mm** (2 módulos). Rendimento: **120 + 40 tiras por folha**.

Ordem dele, 2026-08-26: *"PQ-P2: faça"*.

⚠⚠ **NÃO É a `identificacao-circuito` da §12.19, e a confusão é fácil** — as duas
falam de "circuito" e as duas são etiquetas:

| | §12.19 `identificacao-circuito` | **§12.21, esta peça** |
|---|---|---|
| onde | **FORA**, na porta do quadro | **DENTRO**, em cada dispositivo |
| quantas | uma por quadro | **uma por disjuntor** |
| o que diz | que circuito é e **onde se desliga** | a **designação** do dispositivo |
| norma | NR-10, situação "a" | **IEC 61439-1 §6.3** |
| quem lê | quem está diante do quadro fechado | quem abriu o quadro para intervir |

⭐ *Peça nova cujo nome colide com peça existente merece a tabela da diferença
escrita no próprio gerador — senão a terceira pessoa que passar por ali
"consolida" as duas e o quadro perde metade da identificação.*

**A norma, verbatim (IEC 61439-1 §6.3):** *"Inside the ASSEMBLY, it shall be
possible to identify individual circuits and their protective devices.
Identification tags shall be legible, permanent and appropriate for the physical
environment. Any designations used shall be in compliance with IEC 81346-1 and
IEC 81346-2 and identical with those used in the wiring diagrams."*

⭐⭐ **A cláusula mais fácil de esquecer é a que mais importa: *"identical with
those used in the wiring diagrams"*.** A etiqueta não pode carregar designação
que o unifilar não tenha — por isso a cartela imprime o campo **DIAGRAMA DE
REFERÊNCIA** no cabeçalho. *Etiqueta que não casa com o diagrama é pior que
etiqueta ausente: ela dá confiança falsa a quem vai intervir.*

**Designação pela IEC 81346:** `=` função · `+` local · `−` produto. Classes
usadas nos exemplos: **Q** (chaveamento controlado — disjuntor) · **F**
(proteção) · **X** (borne) · **T** (transformador) · **K** (relé) · **P**
(instrumento). Exemplo: **`=N-A1Q1`**.
⚠ `[não conferido]`: a **IEC 81346-2:2019 não foi lida** — a tabela de classes e
a estrutura de prefixos vêm de fonte secundária. A **IEC 60715** (trilho DIN)
também não: o passo de **17,5 mm é prática de mercado**, não norma lida.
**Confrontar as duas antes do primeiro uso real.**

⚠ **Um nível de distância só, e com motivo:** 300 mm, piso 13,75′. As peças
irmãs têm também o nível `longe` (0,8 m) porque ficam na carcaça do
equipamento; esta fica a um palmo do olho de quem abriu o painel.
⭐ *Nível de distância herdado sem pensar é premissa herdada sem pensar.*

### 12.22 ADESIVAGEM DA FROTA — 4 veículos × 3 vistas (`estável`) — item 3.1 da Onda 3

Gerador: `gen-frota.py` (v7, 2026-09-04). Peças: `07-pecas/frota/` — **lateral, traseira e capô de cada
um dos 4 modelos da frota real** (12 mocks, sufixo `-a-saia` = direção A) + a
folha da regra do formato + `fotos-necessarias-frota.md`. Resolução do mock:
0,5 px/mm (~12,7 DPI; a Hilux lateral sai com 2663 × 908 px) — arquivo de
produção nasce por veículo, medido no veículo real (§7.4-e).

⭐⭐⭐ **É a peça que ele apontou como faltante, e a única do inventário que nasceu
do zero — e a primeira versão foi REPROVADA por erro de categoria** (gate de
2026-08-28, MANIFESTO §136.2), no veredito mais importante da onda:
*"as ondas quando ficam pequenas e em quantidade perdem o sentido da forma que
foi desenhada, paracendo rabiscos, no caso de um material para carro, elas devem
ser aplicadas dando forma a lataria do carro, gosto de algo clean, só logo e os
efeitos que representem a marca, os carros já são todos brancos de proposito,
para poder adesivarmos de maneira marcante usando o fundo branco, então pensar
na adesivagem dos carros como peças de papelaria é errado, estamos falando de
uma peça criativa que tem capô, trazeira e laterais."*
Dois fatos de projeto que nenhum canônico registrava e passam a valer: **a frota é
branca DE PROPÓSITO — o branco do veículo é o fundo da peça**; e **peça de formato
novo ganha regra própria, não herda teto de outro formato** (G5: *"é formato novo,
tem que ter regra propria"*).

**A frota real (G1):** 1 Toyota Corolla 2019 · 1 VW Saveiro 2014/15 **cabine
estendida** (R2-F3) · 1 Toyota Hilux 2015/16 · 3 Fiat Strada 2022. Medidas externas
de ficha técnica com fonte no gerador; silhueta esquemática e proporcional;
balanços, cintura, maçanetas e placa `[inferência]`/`[não conferido]` declarados.
Placa do veículo: sempre retângulo vazio (LGPD, §14.14).

**O desenho final foi DITADO por ele** (rodada 2, 2026-08-31, §137.1 — direção A
"saia" escolhida entre três): *"A. portas da frente mantem a logo, portas de tras
com o 0800 mas com o site abaixo do 0800. Falta o layout do capo e da tampa
trazeira, o capo mantem apenas o símbolo da logo, e a tampa trazeira seriam fotos
dos tipos dos nossos serviços, para o cliente bater o olho e ver com o que
trabalhamos. Na lateral na parta atras da porta de trás, onde no desenha A voce
colocou o 0800, vamos colocar a lista de serviços principais para quem olhar
poder ler o que fazemos."*

**Painel a painel:**

| vista | o que leva | números (arte final) |
|---|---|---|
| **LATERAL — saia** | a cordilheira aprovada (cena Z3, via `gen_detalhe.svg_divisor`, §7.7) em proporção natural w/F = 12,7, correndo a saia inteira e contornando a traseira | faixa F: Corolla 364 mm (24,7% da altura) · Saveiro 354 (23,6%) · Hilux 419 (23,1%) · Strada 353 (22,1%); traço mais fino 9,0–17,1 mm (piso 2,5 mm de vinil, folga ≥ 2×) |
| porta da frente | logo horizontal oficial | — |
| porta de trás | telefone + site abaixo, tipografia do contato §138.1 | 0800 corpo 95–100 mm (13,3–14,0 m) · site 50–55 mm (7,0–7,7 m); piso da lateral 63 mm de caixa alta = 12,6 m (R4-F4) |
| zona atrás da porta de trás | lista dos 5 pilares (`sobreaseed.md` §6) em **JetBrains Mono 400**, caixa alta | corpo 25–45 mm (3,6–6,6 m); **piso aprovado: caixa alta ≥ 15 mm = 3 m** (R3-F2). Saveiro (sem porta de trás): 0800+site e lista dividem a caçamba — adaptação declarada |
| **CAPÔ** | **apenas o símbolo oficial**, base voltada para a frente; vincos = zona proibida | símbolo a 26–27% do comprimento do capô (regra escrita como guarda na v7): Corolla 320 mm (capô ~1230 `[inferência]`) · Saveiro 280 (~1050) · Hilux 400 (~1500) · Strada 300 (~1150); folga ao vinco ≥ 231 mm, à borda ≥ 356 mm — a ficha técnica não publica comprimento de capô; produção mede o veículo real (§7.4-e) |
| **TRASEIRA** (modelo = a **foto real da Strada** que ele anexou, R3-F4: *"analise pela foto e podemos usar como modelo para todos"*) | **SEM ondas** (R4-F1: *"na trazeira, por se tratar de pouco espaço, nao quero usar as ondas"*); zona de contato de **100 mm** na base com logo (esquerda) · site (centro) · telefone (direita) SOLTOS sobre o branco; acima, **5 áreas de FOTO em branco** (uma por pilar); **EEny pose 07** (`03-assets/mascote-eeny/eeny-pose-07.svg`, nunca redesenhada) no canto direito da fileira, altura das fotos, apoiada no chão da fileira (R4-F2: *"como está"*); badges de fábrica (modelo, emblema da montadora, concessionária, adesivo regulatório) = **zonas proibidas desenhadas** — a arte ocupa os espaços vagos, nunca os cobre. Corolla: porta-malas (R4-F3) | logo **70 mm** de altura (215 mm de largura), uniforme nos 4 (R5-F1: a alternativa "+10 mm de logo = −10 mm de foto" foi descartada); **telefone e site no MESMO corpo, 45 mm** (caixa alta 31,5 = 6,3 m; R5-F2: *"sobe (sem custo de foto) — site pode ter mesma altura do telefone"*); piso declarado da traseira: nenhum texto abaixo de 3 m; sobra horizontal útil−logo−site−telefone: Corolla 579 · Saveiro 532 · Hilux 679 · Strada 556 mm (guarda aborta abaixo de 80); áreas de foto: Corolla 5 × 245 × 205 mm · Saveiro 143 × 179 · Hilux 148 × 201 · Strada 147 × 181 |

⭐ **A TIPOGRAFIA DO CONTATO virou spec de referência geral (R3-F1, §138.1)**,
verbatim: *"na logomarca da SEED o nome SEED está em azul turquesa e o nome
engenharia está em outra cor. no telefone, deixe apenas os numeros '0800' na cor
atual, e coloque os demais numeros na cor da palavra endenharia. no caso do site,
a palavra 'SEED' fica com a mesma cor do 0800, também o SEED do site é maiusculo
e o .eng.br minusculo. no telefone coloque o simbolo do whatsapp no inicio, e no
site coloque o simbolo de site. a palavra SEED e o '0800' fica em negrito, o
restante não. Na lista de serviços nao precisa estar em negrito. seria
interessante usarmos a segunda fonte nessa lista ao inves da principal."*
Execução: o contato espelha o bicromatismo do asset `logo-horizontal-principal.svg`
("SEED" #00acac · "engenharia" #617683 = cinza-600, 4,74:1 sobre branco) —
ícone WhatsApp + **`0800`** negrito turquesa-600 + ` 591 5374` sem negrito
cinza-600; ícone globo + **`SEED`** negrito + `.eng.br` minúsculo sem negrito.
⚠ **`SEED.eng.br` é exceção decidida à caixa alta G3.** Os ícones são
**pictogramas utilitários desenhados no gerador**, não assets de marca. Larguras
de linha medidas no hmtx dos subsets oficiais (fontTools 4.63.0): '0800' 2,697 em
· ' 591 5374' 4,440 em · 'SEED' 2,806 em · '.eng.br' 3,468 em; JetBrains Mono
0,600 em/glifo. Esta spec foi reaproveitada nas costas da camisa de campo e do
colete (§12.23).

**Os vereditos do gate de 2026-08-28 que continuam valendo:** G2 contato único
**0800 591 5374** · G3 caixa alta em toda letra viva (exceção: o site) · G4
**amarelo SÓ dentro do logo**; fora dele, a escada turquesa do §7.5 sobre o branco.

**A REGRA DO FORMATO VEÍCULO — DECIDIDA (R2-F2: *"aparentemente as proporções
estão ok"*) e promovida (R4-F5), em 9 itens** (folha `frota-regra-do-formato.html`, renomeada de `-proposta` em 2026-09-04 — o nome dizia "proposta" e o conteúdo estava decidido; precedente R4-U2):
1 escala de lataria — faixa F entre L/12,7 e (cintura−saia)/0,94; piso absoluto
15% da altura do veículo; **nunca miniaturizada nem repetida em padrão** ·
2 traço ≥ 2,5 mm no veículo (10× o piso da §7.4-c — recorte de vinil) ·
3 letra viva pela régua do §12 (~1 cm de caixa alta por 2 m; teto lateral 150 mm) ·
4 zonas proibidas: friso, vinco, maçaneta, vidros, grade/faróis/lanternas, zona
da placa, **50 mm de toda borda de painel e emenda de vinil** ·
5 cor: amarelo só no logo; linha, nunca massa · 6 o branco do veículo é o fundo ·
7 conjunto: o mesmo desenho em toda a frota; o lado do motorista espelha
POSIÇÕES, a serra não se espelha nem rotaciona · 8 produção sob demanda ·
9 conteúdo por painel (o quadro acima), com o piso da lista e o emblema de
fábrica como zona proibida.

**Fotos:** as 5 áreas da traseira são **as mesmas capturas principais do
portfólio** (uma sessão alimenta as duas peças); resolução mínima calculada da
MESMA constante que desenha a área, a **150 DPI** `[proposta — folga ≥ 1,7× sobre a
leitura mais próxima]`: envelope **1447 × 1211 px** (o Corolla manda); captura
recomendada ≥ 3.000 px no lado maior.

**O que ficou fora, e por quê:** as direções B (gesto) e C (cintura) da rodada 2
— 32 arquivos removidos por `git rm` nominal no gate da rodada 6 (R6-REM:
*"aprovo a remoção — Lembrando que no final estavamos avaliando a traseira e o
capo, mas deve ficar salvo e registrado o desenho aprovado de todos os lados do
carro"*; commit `50fd92a`); a "van", classe que a v1 inventou e não existe na
frota; a serra na traseira; a EEny dentro da faixa de contato (sem largura
sobrando em nenhum veículo).

**Registro do conjunto aprovado (R6-REM):** a folha da regra traz a tabela das 12 vistas — veículo × lado × o que cada painel carrega — gerada do MESMO estudo que desenha cada arquivo.

---

### 12.23 UNIFORME E EPI — folhas de especificação de aplicação da marca (`estável`) — item 3.2

Gerador: `gen-uniforme.py`. Peças: `07-pecas/uniforme-epi/`, **oito folhas A4 a
300 DPI** + um anexo de estudo: 1 escritório — camisa social branca (masculina,
COM bolso) · 2 escritório — polo branca + camisa feminina turquesa · 3 escritório
— **as 4 cores oficiais + gola interna** · 4 campo — camisa (cinza) · 5 campo —
calça (cinza) · 6 campo — boné + chapéu árabe · 7 colete de alta visibilidade
(uso eventual) · 8 capacete · anexo à folha 3 — *"gola interna: o que o mercado
pratica"* (estudo para a R5-U1). Cada folha é **especificação de aplicação** —
posição, tamanho em mm, cor por regime de fundo, técnica, zona de proteção,
proibições — sobre desenhos técnicos planificados; **a modelagem é da confecção;
o dado da spec são as COTAS** (*"está muito quadrado, busque moldes reais"* →
flats redesenhados sobre anatomia de desenho técnico de vestuário).

⭐⭐ **O amarelo volta pela porta da própria logo — a E1 REFINOU a MR-P11 (§17.6)**,
verbatim (2026-08-28, §136.3): *"o uniforme branco possui a logo com amarelo,
pois é condizente com a aplicação da marca onde fundo branco ou azul turquesa
pode ser aplicada. logo, podemos usar o amarelo, mas atendendo essas condições do
padrao da propria logo."* Regra operacional: sobre BRANCO ou TURQUESA a logo entra
COLORIDA pelo padrão §5.1; a proibição de amarelo da MR-P11 **não alcança o amarelo
interno da logo aplicada conforme seu padrão**; sobre fundo que o padrão não
autoriza (o cinza do campo) a aplicação é MONO.

**A composição real, declarada por ele (nenhum agente tinha como saber):**
- **ESCRITÓRIO** — camisa social branca de botão (masculina COM bolso), polo branca, camisa feminina turquesa (SEM bolso), **sempre bordado**. E, desde a R3-U1, **4 CORES OFICIAIS** (*"vamos adicionar a A e B. ficamos com 4 opcoes para o escritorio, duas com logo colorida e duas com logo monocromatica"*): **branca** e **turquesa-400 #11B0A0** (logo colorida) · **cinza-600 #617683** e **petróleo turquesa-800 #005048** (mono-negativo, 4,70:1 e 9,29:1). A terceira cor nasceu de encomenda dele (R2-U4: *"O azul turquesa é uma cor difícil de encontrar com o ton correto, por isso quero que faça a sugestão de uma terceira cor de camisa que seja de tecido de cor fácil de encontrar e esteja na nossa paleta de cores"*); a candidata C (azul-900, marinho) não foi escolhida.
- **CAMPO** — camisa, calça, boné e **chapéu árabe** (tipo legionário), SEM colete, em **CINZA** (*"cor de uniforme padrao, produzir cor da empresa seria inviável"*). Regime decidido (R2-U1): *"campo cinza = logo branca direto no tecido"* — mono-negativo #FEFEFE sobre cinza-600, **4,70:1**; a saída "campo turquesa-800" saiu.
- **Técnica (Q2):** bordado prioritário (dura mais); escritório sempre bordado; campo depende do fornecedor. **Capacete: adesivo** (Q5), validar com o fabricante do CA.

⭐ **A REGRA GERAL DO BOLSO (R3-U1), para todas as camisas:** *"regra, quando tiver
bolso, a logo é no bolso e no formato vertical, quando nao tiver bolso, a logo é
horizontal."* E a regra das aplicações compactas (R2-U2/§137.2): *"em capacetes,
bones árabe também é a logo vertical, no bone deve usar apenas o símbolo da
logo"* → capacete e chapéu árabe = logo VERTICAL · boné = APENAS o símbolo. Os
assets verticais já existiam (`03-assets/logos/logo-vertical-*.svg`, viewBox
1262 × 1324) — nada se redesenhou.

**Pisos medidos no vetor:** logo completo impresso ≥ 20 mm (§5.2); **piso do
BORDADO: 90 mm na horizontal e 60 mm na vertical** (menor letra "engenharia" =
4,7 mm — o piso prático do bordado é ~4 mm); abaixo disso, só o símbolo. Zona de
proteção X = altura do "S" ≈ 0,146 × L.

**Peça a peça (cotas das folhas):**

| peça | aplicação | números |
|---|---|---|
| social branca (masc., com bolso) | **vertical COLORIDA 60 mm no bolso** esquerdo (128 × 140 mm, fundo reto); botões e casa brancos | X = 13 mm (folgas 34/38/39) |
| polo branca · feminina turquesa (sem bolso) | **horizontal 90 mm** no peito, topo a 180 mm do ponto alto do ombro; feminina não cavalga pence | — |
| **gola interna das 4 cores — R6-U1 "Linha 2 — cor da marca" (2026-09-04, §142)** | a face INTERNA do pé de gola é TURQUESA da marca; **a externa é sempre da cor da camisa** (correção dele, R4-U1 + foto da própria camisa, §139.1: *"o cinza é por dentro, a gola externa é da cor da camisa"*) | **branca → turquesa-400 (2,71:1) · turquesa → turquesa-800 (3,45:1) · cinza → turquesa-400 (1,75:1) · petróleo → turquesa-400 (3,45:1)**. ⚠ O 1,75:1 da cinza foi decidido COM o número na frente — *a interna "some" com a gola fechada e se insinua aberta* — escolha consciente, não furo. Decisão tomada com o estudo de mercado (R5-U1: *"nao quero decidir nada sem uma pesquisa"*): camisaria branca leva interna neutra escura; vivas/escuras levam interna branca; uniforme corporativo vende gola "na cor da identidade visual" — não existe estatística publicada, síntese por contagem declarada |
| campo — camisa cinza | vertical mono-negativa **60 mm no bolso** (topo a 13 mm da lapela); **costas: logo 240 mm + 0800 + site + frase** *"Projetos, Instalações e Manutenções elétricas"* | corpos **26 · 25 · 17 mm** (0800 3,6 m · frase em **2 linhas** a 17 mm, JetBrains Mono, caixa 12,4 mm = 2,5 m — R4-U4); contato mono branco com só o PESO diferenciando (sobre cinza o bicromatismo fura: turquesa 1,69:1, cinza 1,00:1); nenhuma linha mais larga que o logo de 240 mm — **medida no DOM**, não na constante |
| campo — calça cinza | **símbolo 40 mm** na coxa esquerda, no eixo do vinco, centro a 400 mm do cós | Q3: *"ao menos o simbolo"* — 2× o mínimo de 20 mm, sem texto |
| campo — boné | **apenas o símbolo, 50 mm**, gomos frontais | — |
| campo — chapéu árabe | **logo vertical 60 mm** na frente da copa | piso do bordado da vertical |
| **colete alta visibilidade** (uso eventual; mono-positivo #000001, NR-26 26.1.4) | frente: logo **70 mm** no peito esquerdo (20 mm à faixa); **costas (R5-U3 refeito): logo 150 mm + contato §138.1 com ícones (R4-U5: *"aplicar ícones no colete também"*)** | corpos **20 mm (0800, 2,8 m — R6-U3: "20 mm") · 16 mm (site, 2,2 m)**; **faixas 50 mm, vão 50, barra 50**; **REGRA: nenhum elemento de marca a menos de X = 21,9 mm de qualquer faixa refletiva** — provado por **interseção geométrica no DOM, 0 interseções em 10 de 10 elementos**; técnica transfer/serigrafia `[inferência de prática]` |
| capacete (adesivo) | **A** vertical COLORIDA 50 mm direto no casco branco · **B** campo turquesa-800 60 × 62 mm com vertical mono-negativa 45 mm — **convivem no casco branco** (R3-U5); em casco não branco, só o B | menor letra 3,9 / 3,5 mm — abaixo do bordado, legível em adesivo |

⭐⭐ **O colete voltou inteiro à prancheta por um número sobre a faixa (R5-U3:
*"na imagem o numero está sobre a faixa refletiva, isso nao pode ocorrer, reavalie
toda a aplicacao"*) — e a causa é lição de instrumento (§141.1):** as constantes
de largura do texto no gerador estavam erradas desde a rodada 3 (' 591 5374'
declarado 4,440 em, medido 5,422 — +22%); a linha do 0800 a 25 mm media 230,0 mm =
o painel inteiro; e **a guarda "nunca pegou" porque calculava com a mesma
constante errada**. *Guarda que mede com a constante do gerador confirma o
gerador, não a peça — largura de texto se prova no DOM.* Efeito colateral medido:
a camisa de campo usava as mesmas constantes (0800 desceu de 29 para 26 mm).
As faixas do flat também não obedeciam à própria norma (vão 45 mm; EN ISO 20471,
base da NBR 15292, pede ≥ 50 — `[não conferido na fonte primária — norma paga]`).

⭐ **Régua de método que a gola ensinou (§139.1):** *exemplo de peça de vestuário
se desenha a partir da PEÇA REAL (foto), não da descrição* — duas rodadas de
"gola interna" em texto produziram dois desenhos errados; uma foto produziu o
certo.

**Cotas sobre tecido escuro em tinta CLARA (R4-U3), com a exceção medida (R5-U2
"confirmado"):** #FEFEFE mede 4,70:1 sobre cinza-600 e 9,29:1 sobre petróleo; sobre
turquesa-400 a clara perde (2,69:1) → cota ESCURA cinza-900 (5,11:1). Cor de tecido
é do FORNECEDOR: os hex são referência de token, a aproximar na compra.

**Fontes normativas, com alcance declarado:** NR-10 10.2.9.2 (nova redação pela
Portaria MTE 737/2026 vigora em 2027-06-01 — `[não conferido o texto novo]`) ·
NR-6 (CA) `[leitura integral não conferida]` · ABNT NBR 16213/16623 (ATPV) e NBR
15292:2013 — pagas, `[não conferido]`. O DS dá a forma; CA, ATPV e classe são da
compra.

**O que ficou fora:** grafismo no vestuário (serra sobre tecido curvo perde a
hierarquia de planos, §7.1 ③) · a candidata azul-900 · o regime "campo
turquesa-800" no campo · a 3ª linha da frase (19 mm) · a Linha 1 (camisaria) e a
Linha 3 (grafite único) da gola.

(R6-U1 aplicada no gerador em 2026-09-04 antes desta promoção: folha 1 e folha 3 mostram a interna turquesa; a folha de estudo permanece como registro da pesquisa, com o selo da decisão.)

---

### 12.24 ONE-PAGERS DE PILAR — cinco folhas A4 (`estável`) — item 3.3

Gerador: `gen-onepager.py` (UM gerador parametrizado — cinco scripts seriam cinco
implementações da mesma folha). Peças: `07-pecas/one-pagers/` — Energia Solar ·
Subestações de Média Tensão · GMG · Projetos Elétricos · Consultorias em Eficiência
Energética, + `fotos-necessarias-onepagers.md`. Moldura: **importa o
`gen-timbrado.py`**, cabeçalho + `rodape('orcamento')`, **área útil (7, 29)
196 × 241 mm** (moldura ampla, R4-M1).

⭐ **O conteúdo é produzido pelo agente, não por ele** (2026-08-27: *"vc deve
produzilos, nao eu"*), com **fonte única `sobreaseed.md`** para todo fato
institucional; **conhecimento de DOMÍNIO** (norma, prazo, regra de tarifa) pode
vir de pesquisa com fonte citada e datada (rol de 2026-08-31 no gerador: Lei
14.300/2022, REN ANEEL 1.000/2021 e 1.059/2023, NR-10 10.2.3/10.2.4 `[ago/2026]`,
NBR 14039:2021, NBR ISO 8528-1, NBR 13534, Res. CONFEA 1.137/2023, NBR 5419:2015,
PRODIST Módulo 8). O que não confirmou em fonte primária ficou fora
(`[não conferido: prazos em dias da conexão GD]`).

⭐⭐ **A rodada 1 foi reprovada com cinco vereditos (§136.1), e nenhum era errata
de canon** — ESG, "+400 obras na Bahia" e "3 sedes" vêm todos do `sobreaseed.md`;
o veredito é curadoria de peça: *"nao temos selo ESG"* · *"ja está falando +1000
obras entregues, pra que falar +400 na bahia? se nao tem o que escrever, nao crie
redundancia"* · *"no rodapé ja fala as 3 sedes"* · escopo de Projetos = *"Projetos
Elétricos de modo geral, com foco em Subestações de média tensão, Grupo motor
gerador (GMG), Energia Solar Fotovoltaica, SPDA, entre outros"* · e a ordem maior:
*"acrecentando mais conteúdo onde demonstra a dor do cliente para ele quando ler
ele se identificar com o que resolvemos para ele que ele precisa. revise
profundamente."* **Régua nova, dele: estatística redundante não se cria.**

**O esqueleto (rodada 2, R2-OP0: *"deixe um campo para colocarmos uma foto do
serviço, esse campo pode ser uma coluna"*):** faixa "Portfólio de soluções" +
pílula "Pilar N de 5" · marcador amarelo (acento único, §3.4 — peça de mesa, fora
da MR-P11) · título · **A DOR do cliente** (abre a folha) · a resposta da SEED ·
coluna de conteúdo (112 mm: o que entregamos · caixa de ênfase única §3.5-c · para
quem · por que a SEED) + **coluna de foto 52 × 78 mm em branco** com o bloco **"No
seu radar"** (fatos de norma/prazo com fonte) · números ao pé · rodapé do
timbrado. Escala tipográfica desceu um degrau na rodada 2 (título 9,5 → 8,6 mm;
corpo 2,9 → 2,75) — medido no DOM; piso 2,2 mm.

**Os números (R2-OP1 + R3-OP1):** *"so tem relação com solar"* → os +50.000 painéis
só na folha Solar; *"coloque '+10 anos de mercado', e tire o intervalo de data"* →
**"+10 anos de mercado · +1.000 obras entregues"** nas quatro não-solares (DOIS
números; a sugestão "16 colaboradores" não entrou); a Solar com três. OP2–OP6
aprovados (radar · coluna 52 × 78 · densidade · 5º bullet removido · NBR 13534
no GMG). R2-OP2: o tom das dores aprovado.

**Regra do Diagnóstico 360°:** é SERVIÇO, não marca — entra como conteúdo só na
folha de Consultorias (veredito de 2026-08-27; item 3.4 saiu do DS).

**Fotos:** retrato 2:3, **mínimo 614 × 921 px** (300 DPI), recomendado 2×; uma por
folha, especificada no rol. LGPD: "para quem" fala por perfil e setor, nunca por
nome; pessoa identificável exige autorização de uso de imagem.

⚠ Lacuna declarada no gerador: **Subestações de Média Tensão não tem descrição de
serviço no canônico** (§6 só nomeia o pilar) — a folha compõe com o diferencial
HUB (§8) e as soluções operacionais do §6.
O bullet "10 anos de mercado regional — operação desde 2016" foi mantido por veredito dele (R4-S2, §139: *"está ok da forma apresentada, se futuramente formos atualizar o material, eu digo qual dado acrescentar nesse bloco"*).

---

### 12.25 ROLL-UP 800 × 2000 mm E TOTEM 600 × 1600 mm — institucional e comercial (`estável`) — item 3.5

Gerador: `gen-rollup.py`. Peças: `07-pecas/rollup-totem/` — **institucionais**
`rollup-800x2000mm` (arte + `-mock` com a zona de sacrifício anotada) e
`totem-recepcao-600x1600mm`; **comerciais** `rollup-comercial-a` e `-b` (arte +
mock cada) e `totem-comercial` (A) e `totem-comercial-b`; + `fotos-necessarias-rollup.md`.
Mock a 2 px/mm (≈ 51 DPI — grande formato, mesma decisão da placa de obra).

**Medidas:** roll-up **0,80 × 2,00 m de ÁREA VISUAL** — padrão de facto do mercado
gráfico brasileiro (cinco fornecedores consultados em 2026-08-27; `[não conferido]`
em fonte primária — não há norma). A lona de produção é maior (um fornecedor
publica 80 × 208) e pertence ao arquivo de produção (§7.4-e). Totem **0,60 × 1,60 m
— PROPOSTA a validar na compra** `[não conferido]`: 1,60 m põe o bloco de marca na
altura dos olhos; 0,60 passa em qualquer porta.

⭐ **Zona de sacrifício do roll-up: os 250 mm inferiores sem conteúdo essencial**
(o cassete engole a base da lona; valor conservador — `[não conferido]`, fornecedores
não publicam). No institucional o rodapé termina a 316 mm e o grafismo a 254 mm
do corte. O mock de gate desenha a linha; a arte, não. Totem não tem cassete.

**Legibilidade:** régua do §12 (alcance = caixa alta ÷ 5; sCapHeight 0,700 em;
`[inferência]` ao extrapolar de 20 m para 1,5–6 m). Roll-up: título 5 m ·
eyebrow/assinatura/pilares 3 m · contato 2 m · sedes 1,5 m. Totem: 4 · 2,5 · 2 ·
1,5 · 1,2 m. O gerador imprime a conta por bloco.

**Institucional (aprovado na rodada 1; o "aprova os 2" era sobre DUAS peças,
§136.5):** logo vertical principal ao centro (§5.3 capa/momento editorial; §5.1
fundo branco); slogan partido como a pasta A4 já o parte; 5 pilares verbatim do
§6; sedes MATRIZ primeiro; eyebrow em Montserrat SemiBold (não mono — voz de
marca lida a metros); divisor do gerador em proporção natural, spans 680/510 mm
(≥ 125 mm, §7.4-f — sem sangrar), traço mais fino ≈ 1,37 / 1,03 mm, altura ≈ 53,5
mm = 2,7% da altura. **O amarelo está na peça, e é deliberado**: o §17.6 nomeia
*"totem, banner e papelaria seguem com o amarelo liberado"*.

⭐⭐ **A COMERCIAL nasceu de encomenda dele (R2-3.5A):** *"muito clean, podemos ter
um material mais institucional como esse mas precisamos de algo mais comercial,
que faça a pessoa olhar para ele e ter interesse em ler, exemplo: a da BV
financeira tem uma imagem de uma família feliz com uma casa ao fundo, e é
colorido, usa bem as cores. monte essa opção também."* Sem foto de banco (§8 mata
pessoa encenada): **área de foto EM BRANCO especificada** (RA-1 800 × 880 · RB-1
800 × 990 · TA-1 600 × 760 · TB-1 600 × 790 mm; **150 DPI** = 4725 × 5197 ·
4725 × 5847 · 3544 × 4489 · 3544 × 4666 px — especificação de compra, não lei de
marca). Cor com força: campo **turquesa-800 #005048** com tinta branca (9,37:1) e
turquesa-200 (6,47:1); **amarelo como CTA** (pílula #FAD61D + cinza-900, 9,70:1) e,
na direção B, faixa de chamada. Grafismo GRANDE (a lição da frota): serra ~104 mm
no roll-up e 88 mm no totem, dentro dos tetos (§7.4-b topo: 121,9 / 91,4 mm;
rodapé 5,2% / 5,5%), tema escuro.

**Vereditos da rodada 3 (§138.4):** R3-R1 — **as duas direções do roll-up
coexistem** (A foto no topo → recepção · B cor no topo → feira), e o ajuste:
*"as ondas devem começar e terminar nos cantos nesse caso, mas nao é regra."* →
**nas TRÊS peças comerciais** a serra sangra 10 mm por lado (span L + 20 mm, o
mecanismo do verso do cartão); **"não é regra" = exceção só das comerciais; as
institucionais seguem dentro das margens.** R3-R2 headline *"Produza a sua
própria energia."* aprovada · R3-R3 faixa amarela aprovada · R3-R4 *"temos as duas
opçoes"* → nasce o **totem B** (mensagem nos olhos, foto abaixo) · R3-R5 +50.000
painéis confirmados (peça solar-adiante).

**Rodada 4 (R4-S1):** *"as ondas tocam o campo em amarelo no meio, pode deixar as
ondas mais altas, nao precisa tocar."* Toque medido no PNG: **0,00 mm nas duas
direções B**. Conserto: nasce `CAMPO_BASE`; a serra sobe 12 mm (folga ≥ 2,8× o
traço mais grosso), tetos inalterados. R4-S2: *"se futuramente formos atualizar o
material, eu digo qual dado acrescentar"* — os dados desta família só mudam por
ordem dele, nomeando o dado.

**O que ficou fora:** JetBrains Mono (não embutida — sem uso na peça) · variante
sem amarelo para roll-up armado em sala de painéis (linha de decisão dele, não
pedida).
(As 3 institucionais ganharam PNG de gate no fechamento de 2026-09-04 — `render-peca.mjs`, duas cargas idênticas — junto das 6 comerciais.)

---

### 12.26 KIT DE FAVICON, ÍCONES DE APP E AVATAR DE REDE (`estável`) — item 3.6 · fecha a §17.7 (parcial)

Gerador: `gen-favicon.py`. Peças: `07-pecas/favicon-avatares/` — `favicon.svg` ·
`apple-touch-icon-claro/-escuro.svg` (masters de 180 × 180) ·
`icon-maskable-claro/-escuro.svg` (masters de 512, servem 192) ·
`avatar-rede-claro/-escuro.svg` (400 × 400) · `gate-favicon-avatares.html` (folha
de espécime: o kit em contexto real simulado). **Peça de TELA** (`alvo-fisico`
vazio).

**Regra de ouro:** todo derivado nasce do `03-assets/simbolos/` por **extração +
transformação** (os `<path d>` copiados verbatim em tempo de geração; a única
reescrita é `class="a"` → `fill="#…"` com o valor lido do `<style>` do próprio
asset). As cores internas (#00acac, #fad61d, #fff) são do asset. Geometria MEDIDA
(Chrome `getBBox`, 2026-08-27): viewBox 942 × 935; organismo (100,5; 119,0) w 650,2
h 696,5; ® satélite (747,9; 124,2) 93,5 × 92,4 — "vive quase inteiro à direita do
organismo; a 16 px mede ~2 px". Os paths do ® são identificados por estrutura
(`fill-rule="evenodd"`) e o extrator aborta se a contagem mudar.

⭐ **As cinco decisões do gate de 2026-08-28 (§136.4), verbatim: *"® acompanha
SEMPRE · margem 0% · tema escuro colorido · fundo de app/avatar: as 2 opções valem
· maskable 40%"*:**
- **P1** o ® acompanha em todos os tamanhos (§5.5 proíbe desmembrar) — as variantes "sem ®" saíram do código;
- **P2** margem interna do favicon = **0%** (a §5.2 pedia "generosa" sem número; o "8% provisório" morreu);
- **P3** tema escuro = símbolo **COLORIDO** (a matriz §5.1 "escuro → mono-negativo" é regra de peça anterior ao favicon; a 16 px a cor identifica mais que a forma) → o `favicon.svg` é UM desenho para os dois temas, sem media query;
- **P4** fundo do ícone de app e do avatar: **as duas opções são oficiais** — branco + principal E brand-deep + mono-negativo, nomeadas `-claro/-escuro` pelo fundo;
- **P5** enquadramento dos ícones opacos: **regra única de 40%** — W3C Web Application Manifest (WD de 13/08/2026, §icon-masks): *"a circle (…) with a radius of 2/5 (40%) of the icon size"*; aplicada também ao apple-touch (squircle corta menos `[não conferido — a Apple não publica número]`) e ao avatar (círculo do símbolo a 160 de 200 = 80% do recorte).
A validação "legível a 16 e 32 px ou simplificar" (§5.2) foi exercida no gate — ele decidiu P1/P2 olhando renders reais e não pediu simplificação.

**Arquivos de produção — RASTERIZADOS em 2026-09-04 (`FV-P2` executada por ordem dele, *"PV-P2 pode fazer pra adiantar"*, MANIFESTO §144):** a decisão E ("sob demanda") foi antecipada. O próprio `gen-favicon.py` rasteriza como etapa padrão (Chrome headless real com flags determinísticas, Pillow para PNG e para o `.ico`), e o `--checar` cobre os rasters: `favicon.ico` (16 + 32 + 48, quadros lidos de volta e conferidos pixel a pixel) · `apple-touch-icon-claro/-escuro.png` 180 · `icon-512-claro/-escuro.png` · `icon-192-claro/-escuro.png` · `avatar-rede-claro/-escuro.png` 400 (o avatar não estava na lista da §5.2: nenhuma rede aceita SVG no upload — aplicado sem pergunta, sem veto no §145). Provas: duas gerações com MD5 igual em 17 de 17 arquivos; margem 0 % medida na caixa alfa do 16 px (0, 0, 16, 16); ® presente por diferença contra render-sonda. Defeito de instrumento registrado na docstring: o Chrome impõe janela mínima de 500 px e recortava os rasters menores — a forma final usa página-wrapper de 800 px e recorte exato. O comando literal está na folha, seção E. **Capas de rede
social** (a §17.7 as cita) ficam fora: capa é peça editorial por plataforma, não
derivado geométrico do símbolo — outra peça, outro gate. Os três nomes da 1ª
versão saíram na R2-REM (§137.4).

Pendências: `FV-P1` (capas de rede) — produzida em 2026-09-04, ver §12.30 · `FV-P2` — FECHADA: rasterização (acima) e upload para o espelho §5.4 feito em 2026-09-05 (FILE_IDs na tabela da §5.4).

---

### 12.27 PLACA DE INSTALAÇÃO CONCLUÍDA (`estável`) — item 3.7

Gerador: `gen-placa-instalacao.py`. Peças: `07-pecas/placa-instalacao/` — **500 × 250
mm** (portão/alambrado da usina, leitura de aproximação a ~3 m) e **400 × 200 mm**
(fachada/porta de acesso da subestação, ~2,4 m), cada uma **com QR (padrão) e sem
QR**. Sub-múltiplos exatos da chapa 2000 × 1000 da placa de obra (16 e 25 peças,
zero sobra; `[não conferido]` como chapa de linha — vem da decisão da §12.1).
Template com placeholders `[ASSIM]`; 300 DPI (leitura de aproximação, regime da
§12.18/§12.20).

⭐ **Estatuto: VOLUNTÁRIA — e a prova é o texto da lei.** A obrigação da Lei
5.194/1966 art. 16 vale *"enquanto durar a execução"*; a prática (Res. CONFEA
407/1996, CREAs) encerra na baixa da ART. `[não conferido]` como prova de negativa
("nenhuma norma obriga placa permanente" é afirmação sobre o que não existe).
Peça de presença e prova social — o pós-venda passivo da etiqueta §12.18 em escala
de portão. `[não conferido]`: enquadramento municipal como engenho publicitário.
**Três fronteiras impressas na própria peça:** não é a placa de obra (§12.1) · não
substitui a placa de advertência da distribuidora (CEMIG ND-5.30 jun/2025 item 5.4:
*"CUIDADO – RISCO DE CHOQUE ELÉTRICO – GERAÇÃO PRÓPRIA"*, veda publicidade; EDP e
Coelba não lidas por decisão dele — a placa da distribuidora é fabricada pela norma da própria distribuidora, `PI-P1` fechada em 2026-09-04) · não substitui a sinalização NR-10 (§12.19).

⭐ **MR-P11 se aplica de forma DIRETA, e ele confirmou: *"nesse caso da placa sim"*
(Q3).** Assinatura turquesa e branco: faixa `turquesa-800` de 55 × 500 mm (na maior)
+ `simbolo-mono-negativo` — o principal carrega o amarelo dentro do asset. A tarja
contínua É o dispositivo de reconhecimento a distância (a lição da SN-P10, aqui do
lado certo: peça de marca, não de segurança).

**Conteúdo, na ordem de quem se aproxima:** quem é (faixa + tag) → o que é
(`[TIPO E NOME DA INSTALAÇÃO]`) → números (`[POTÊNCIA]` com unidade em aberto —
serve kWp e kVA · conclusão `[MÊS/AAAA]` · ART) → quem fez (executora SEED · CREA ·
RT como CAMPO, §14.15) → **quem chamar** (seed.eng.br · contato@seed.eng.br · 0800
591 5374) → linha de estatuto. Marca e nome legíveis a 3,0/2,5 m (maior) e 2,4/2,0 m
(menor); campos a 0,65–1,2 m — a 1ª versão tentou 1,5 m e **estourou a chapa em
~80 mm** (scrollHeight 3903 px numa peça de 2953): *alvo de distância que não cabe
na chapa é alvo errado, não letra pequena.*

⭐⭐ **QR REAL, por veredito (Q1: *"as duas variantes valem, com QR é a primeira
opção, destino = WhatsApp do 0800"*)** — URL institucional
`https://wa.me/message/WGBZYBBPUF6PO1`. Gerado com **segno 1.6.6** (Python puro,
determinístico — ⚠ a prova byte-idêntica depende desta versão; o gerador aborta
sem ela). **ECC Q (25%)** — M descartado por margem em chapa exposta; H descartado
porque sobe a 37 × 37 módulos sem ganho. URL de 36 bytes fecha em **versão 4-Q,
33 × 33 módulos**; quiet zone 4 módulos dentro do quadro de 60/48 mm →
**1,463 mm/módulo (500 × 250) · 1,171 mm/módulo (400 × 200)**; ≥ 13,8 dots/módulo a
300 DPI (Denso Wave recomenda ≥ 4). Distância de leitura ~10:1 → ~0,48 / 0,39 m
(NN/g, regra de usabilidade, não norma). Contraste **13,72:1** (text-primary sobre
surface-page, cor.py). O gerador reconstrói o QR da URL a cada execução e aborta
se a matriz divergir. ⚠ **Decodificação por leitor independente NÃO MEDIDA** —
nenhum leitor nesta máquina (cv2, pyzbar, BarcodeDetector ausentes); a primeira
leitura com celular é etapa do gate humano.

**Decisões dele que fecharam sem retrabalho:** Q2 os dois tamanhos, "por tipo de
instalação" · Q4 **material é decisão de compra** (a recomendação — chapa rígida
ACM/alumínio/aço com UV ou gravação; adesivo não atende peça permanente — fica
como recomendação, não spec).

**O que ficou fora:** grafismo de serra (peça de informação, e serra em campo com
sinalização é ruído) · a linha "placa obrigatória — Lei 5.194" (aqui a lei faz o
papel inverso) · JetBrains Mono (a peça não a usa).

---

### 12.28 PORTFÓLIO DE OBRAS — template com fotos em branco (`estável`) — item 3.8-a

Gerador: `gen-portfolio.py`. Peças: `07-pecas/portfolio/` — `portfolio-capa` (logo ao
CENTRO, §5.3, mesmo asset e rodapé do timbrado) · `portfolio-case-modelo` (uma
página por obra, repetível) · `portfolio-contracapa` (soluções + diferenciais) ·
`brinde-tecnico-comparativo` (evidência de decisão — ver §12.29) ·
`fotos-necessarias.md`. Moldura ampla do timbrado, `rodape('orcamento')`, área útil
(7, 29) 196 × 241 mm; **marca d'água E1 (§12.2-b) nas três páginas de portfólio;
a folha do brinde está na mesma moldura (R5-M4) e SEM marca d'água**.

⭐⭐ **A decisão que governa a peça (2026-08-27):** *"nao tenho foto, deixe em branco o
local da foto (…) basta vc montar o template e quando isso entrar para producao
real, as fotos reais irao alimentar o app ou site ou qualquer criação."* → template
com área de foto em branco e especificação escrita dentro dela; nenhuma foto de
banco, nenhuma desenhada, nenhum dado real; entregável adicional: a lista das fotos
necessárias, gerada pelo próprio gerador da MESMA constante que desenha a área.
*(Isto desbloqueia, para efeito de DS, a pendência histórica das "fotos reais" da
F2: o sistema entrega o template; a foto é insumo de produção.)*

**Case:** campos obra · cliente/segmento · local · pilar · potência/porte · período ·
escopo · **resultado como campo**. **O campo "responsável técnico · ART" foi
REMOVIDO por veredito (§136.4):** *"estamos mostrando obras da empresa, ficar
repetindo responsavel nao faz sentido, e o responsável nao tem merito, a empresa é
o foco."* A grade caiu de 6 para 5 campos; a conferência do §14.15 permanece como
PROCESSO (nota discreta junto ao resultado, sem citar cargo nem pessoa). LGPD:
nome de cliente e de obra é SEMPRE campo.

**Fotos (R5-M5 "fotos 72/42" confirmado):** principal **196 × 72 mm → mínimo
2315 × 850 px**; 2 detalhes **95 × 42 mm → 1122 × 496 px** (300 DPI); captura
recomendada 2×, paisagem, corte panorâmico na diagramação. Três fotos por case,
especificadas por pilar no rol (a principal é a mesma da traseira da frota, §12.22).

O amarelo pode estar aqui (peça de mesa): marcador do `gen_detalhe.svg_marcador()`.

---

### 12.29 AGENDA — o brinde da SEED, capa 145 × 205 mm (`estável`) — item 3.8-b

Gerador: `gen-agenda.py`. Peças: `07-pecas/agenda/` — `capa-1-logo` (apenas a logo
colorida) · `capa-2-ondas` (logo colorida + ondas na base) · `capa-3-comercial` ·
`contracapa` (branca) · `contracapa-escura`. 300 DPI (papelaria lida na mão).

⭐ **O brinde mudou de veredito entre rodadas, e a mudança é o registro:** na
rodada 1 (§136.4) *"não precisa ter"* — a folha `brinde-tecnico-comparativo.html`
(três opções com custo medido em fornecedores consultados em 2026-08-27, logo
mono-positivo aplicado) ficou como **evidência de decisão**, não foi deletada. Na
rodada 2 (§137.3): *"quero que gere um layout para agenda, com duas opções, uma com
apenas a logo colorida e outra com a logo colorida com as ondas na parte de baixo.
faça uma versão mais comercial utilizando melhor as paletas de cores da SEED."*
**O brinde da SEED é a agenda.**

**Formato 145 × 205 mm** — prática dos fornecedores brasileiros de brindes
(14,5 × 20 e 14,5 × 20,9 consultados em 2026-08-31); `[inferência]` 205 = ponto médio
da faixa; a medida final é de quem corta (§7.4-e).

**As três capas, cada decisão com a regra:** logo VERTICAL principal ao centro
(§5.1 formato vertical, razão 0,71; §5.3 capa → centro). **Capa 1**: logo a **72 mm**
(A1 aprovado), centro óptico a 99,8 mm, nada mais. **Capa 2**: logo sobe para 54 mm;
serra em arcos do gerador na base, **span 165 mm SANGRANDO** 10 mm por lado (dentro
das margens seria 125 mm = exatamente o piso §7.4-f, traço 0,251 mm; a 165 o traço
mais fino sai em **0,332 mm, folga 33%**), faixa **13,0 mm = 6,3% da altura** (A2
aprovado). **Capa 3 — a comercial é uma TERCEIRA capa, não tratamento sobre as
duas**: campo branco em cima (68%, lei 70/20/10), **faixa turquesa-800 de 65 mm na
base** (32%) com a serra em tema escuro, tagline oficial em branco (≈ 9,3:1), marcador
amarelo como acento pontual (A3 aprovado). **SEM ANO na capa** (A4 decidido).

**Contracapas (A5: *"gerar versão escura também — Nos dados referente a endereço,
use apenass Cidade e UF."*):** branca (preserva a 70/20/10 do conjunto) e escura
(campo turquesa-800 inteiro, símbolo mono-negativo, **branco 9,37:1** e **turquesa-200
6,47:1** medidos pelo gerador, fio em turquesa-600). Conteúdo: 0800 + site + sedes
**só Cidade/UF**, MATRIZ primeiro (`sobreaseed.md` §1, §9). Zona X ≈ 8 mm
`[inferência da proporção]`; folgas 36,5 mm laterais e ≥ 14,9 mm verticais.

**O que ficou fora:** o ano · o brinde físico da folha comparativa · qualquer
variante de logo inventada.

### 12.30 CAPAS DE REDE SOCIAL — uma peça oficial por plataforma (`estável`) — fecha a `FV-P1` e a `FV-P3`

Gerador: `gen-capas-rede.py`. Peças: `07-pecas/capas-rede/` — `capa-linkedin` ·
`capa-facebook` · `capa-youtube` · `capa-x` · `capa-whatsapp` (cada uma `.html/.png` +
variante `-guia` com área segura, caixa de conteúdo e zona do avatar desenhadas por cima
da MESMA arte), `gate-capas-rede.html` (cada peça em contexto simulado com o avatar
§12.26 na posição medida; traz a tabela de formatos e a pesquisa de mercado) e
`fotos-necessarias-capas.md`. **Peça de TELA:** `alvo-fisico` vazio e
`<meta name="alvo-tela" content="LxApx">` — o opt-in que o `render-peca.mjs` e a
`guarda-peca-fresca.mjs` aceitam desde 2026-09-04 para peça com tamanho fixo em px
(sem fingir tamanho físico; peça de tela sem a meta segue `[n/a]`). Tipografia
embutida (woff2 subsetado, aborta se faltar), grafismo do gerador, logo do asset, tokens
medidos no navegador.

**Formatos, com fonte (consulta 2026-09-04):** LinkedIn **1512 × 256** (LinkedIn Help
a563309 — supersede a "capa 4:1" 1584 × 396 da §7.4, que era a medida ANTIGA da mesma
plataforma; a capa aprovada continua válida como prova do grafismo e a proporção da
serra herda dela) · Facebook **1702 × 630** = 2× o ótimo oficial 851 × 315 (Central
125379114252045; 2× por decisão declarada, mesma razão) · YouTube **2560 × 1440** com
área segura 1544 × 423 (oficial 1235 × 338 em 2048 × 1152, escalada ×1,25) · X **1500 ×
500** (help.x.com) · **WhatsApp Business 1211 × 681** `[secundária: WABetaInfo
2022-04-16, atualizado 2025-10-23 — a Meta confirma a existência da capa na Central de
Ajuda, mas não publica medida]`. **Zona do avatar MEDIDA em captura**, por plataforma
(LinkedIn, Facebook e X em 2026-09-04; WhatsApp na captura publicada pelo WABetaInfo em
2022: faixa exibida de 2,47:1 — 72 % da altura — com o círculo centrado, 27 % da largura,
cobrindo os 58 % inferiores). `[layout de plataforma muda sem aviso — conferir antes de
publicar]`.

⭐ **Direção por plataforma — vereditos dele (MANIFESTO §145, verbatim):** *"P-CAP-DIR:
A — institucional (grafismo + frase)"* → **LinkedIn A** · *"P-CAP-FB: C"* → **Facebook
C** (serviços, campo claro: logo principal, eyebrow, os 5 pilares com ordinal, divisor
claro no pé) · *"P-CAP-YT: A mas com os serviços"* → **YouTube A+** (composição nascida
desta resposta: o campo escuro de A E os 5 pilares em duas linhas explícitas 01–03 ·
04–05, tudo dentro da área segura; escala um degrau abaixo de A; pilares 29 px = 10,2 px
de caixa alta a 1284 px de banner na tela, ilegíveis no recorte do celular como toda a
tipografia do banner) · *"P-CAP-X: mesma direção"* → **X A** · *"P-CAP-EXTRA: produzir
agora as duas"* → **WhatsApp A** (`FV-P3`). Pesquisa de mercado (10 páginas do segmento:
3 só grafismo + frase, 6 foto + frase curta, 1 serviços nomeados, nenhuma com telefone)
registrada na folha e no gerador.

**Redes que publicam capa (P-CAP-REDES, verbatim: *"facebook, youtube, instagram,
linkedin, tiktok"*).** O X ficou fora da lista: a capa sai gerada e marcada **NÃO
PUBLICADA** (`<meta name="publicacao">`) — sai do gerador se ele mandar. **Instagram e
TikTok não têm capa de perfil:** ali a peça é o avatar (§12.26, já em PNG 400 × 400) e,
no Instagram, as capas de destaques (§12.31).

**Conteúdo verbatim (`sobreaseed.md`):** eyebrow "PROVEMOS EFICIÊNCIA ENERGÉTICA" (§9) ·
título "Onde quer que esteja." (a partição do slogan da capa L5 aprovada) · assinatura
"Especialistas em energia há mais de uma década" (§9) · os 5 pilares do §6 na ordem.
Amarelo só no marcador (§3.4 — capa não divide campo visual com sinalização, MR-P11 não
incide); serra = divisor do gerador com F = 15,7 % da altura visível (a proporção da
capa 4:1 aprovada, §7.4); tinta branco 9,37:1 e turquesa-200 6,47:1 sobre turquesa-800;
turquesa-600 4,60:1 sobre branco.

**O que ficou fora:** a direção **B** (foto de campo) não foi escolhida para nenhuma
plataforma; o código vive (`--estudo PASTA`, que recusa gravar em `07-pecas/`) e volta a
ser opção quando houver sessão de fotos — o rol `fotos-necessarias-capas.md` fica para
isso. Os 48 arquivos de estudo A/B/C do gate de 2026-09-04 (`capa-<plataforma>-[abc]*`)
saíram da pasta em 2026-09-05 por tabela de remoção aprovada por ele (MANIFESTO §147);
vivem no histórico do git.

⚠ **WhatsApp: medida secundária e recorte medido numa captura de 2022 (iOS beta).**
Mitigação de projeto: texto e logo na caixa de 1139 × 206 px ACIMA do avatar e dentro da
faixa exibida; a serra fica atrás do avatar. Conferir no app antes de publicar é etapa do
gate humano — o mesmo estatuto da leitura do QR na §12.27. Sem pendência nova.

---

### 12.31 CAPAS DE DESTAQUES DO INSTAGRAM (`estável`) — fecha a `FV-P4`

Gerador: `gen-destaques-instagram.py`. Peças: `07-pecas/destaques-instagram/` —
`destaque-solar` · `-subestacoes` · `-gmg` · `-projetos` · `-consultorias` ·
`-quem-somos` · `-obras` · `-seed-plus` (cada um `.html/.png` + variante `-guia` com o
círculo exibido e a zona segura do story desenhados) e `gate-destaques-instagram.html`
(a faixa do perfil simulada nos tamanhos reais, a comparação que decidiu, a pesquisa e
as medições). **Peça de TELA** (`alvo-fisico` vazio, `alvo-tela` 1080 × 1920 px).
Prova em duas passadas (gerar → `render-peca.mjs` → gerar de novo, porque a folha mede
os PNG); `--checar` byte-idêntico em 17 de 17.

**Formato:** arquivo 1080 × 1920 (9:16 — Instagram Help Center, trecho indexado; a Meta
publica 1440 × 2560 como 2× do mesmo 9:16). O Instagram exibe só o **círculo central de
~720 px `[secundária: moda.app, 2026-03-15]`**, a **56 px na web (MEDIDO em 2026-09-04 no
perfil @seedengenharia: `<img>` 56 × 56 dentro do anel de 67; nome do destaque em 12 px)**
e ~77–80 px no app `[secundária]`. **O nome do destaque NÃO vai na capa** — o Instagram o
escreve embaixo. Toda a tinta vive no círculo de 720 (guarda aborta se sair); fora dele o
campo é chapado, porque nunca aparece.

**Conjunto (8):** os 5 pilares do `sobreaseed.md` §6 (nome do destaque = Energia Solar ·
Subestações · GMG · Projetos · Consultorias) + 3 institucionais sustentados pelo canon E
vivos no perfil (Quem somos · Obras · SEED Plus). Depoimentos, Parceiros e Dúvidas
(vivos) ficam fora por falta de dado no `sobreaseed.md` — custo de entrar: uma linha em
`DESTAQUES`.

**Ícone = o set oficial §45 do `seed-componentes.md`** (árvore NM4 ①: existe no set SEED
→ usa SEED; a §45.4 mapeia os pilares — `sun`, `document`, `lightbulb` — e a §45.3 traz
`substation` e `generator`), **extraído da bancada `banco-icones.html` em tempo de
geração**, nunca redesenhado; "Quem somos" leva o símbolo oficial (§5.2, extração do
`gen-favicon.py`). *Isto supersede a leitura do MANIFESTO §145 de que "o canon não tem
pictogramas de serviço" — tinha; ver §146.*

⭐ **Composição oficial: C — só o ícone (360 px = 50 % do círculo) + marcador amarelo, tema
escuro (turquesa-800 + branco, 9,37:1), com TRAÇO ÓPTICO 1,25** (veredito T-TRACO, MANIFESTO
§150: o set segue traço 2 a 24 px; no destaque o glifo é ampliado 15× e o traço 2 dava 4,2 %
do diâmetro contra 1,3–2,0 % nos perfis de linha do segmento; com 1,25 fica em 2,6 %, 2,1 px a
77 px e 1,6 px a 56 px — parâmetro `TRACO_DESTAQUE` do gerador, medido no §149). Decisão delegada por ele (§145, *"pode decidir
pegando como base as decisoes acima"*) e tomada pela sessão em 2026-09-05 (§146), exposta
a veto: (1) direção-base A = campo escuro; (2) régua §5.2 medida — rótulo com caixa alta
de 3–4 px a 56/77 px não lê, ícone com traço de 2,3–3,2 px lê; (3) 9 de 10 perfis do
segmento fazem assim; (4) é a linguagem que o perfil vivo já usa. Descartadas: A (ícone +
rótulo — o rótulo não lê e rouba 40 % do círculo) · B (só rótulo — a leitura literal do
§145, reprovada pela medição) · tema claro (válido, fica no código via `--estudo`, não é
oficial: a faixa ganha unidade com um só campo). Amarelo só no marcador (§3.4). **Sem
serra/textura:** em span de 720 px o divisor exibido teria 0,12–0,48 px — ruído, medido.

**Obras e SEED Plus** nasceram sem glifo no set (saíam só com o rótulo) e ganharam os seus em
2026-09-05 (`FV-P5`, por ordem dele): `hard-hat` e `solar-panel-plus`, §45 v1.39 — os oito
destaques levam ícone. **No mesmo dia, pelo veto dele (§149–§151): Subestações passa a usar
`transmission-tower`** (glifo NOVO desenhado a partir do modelo dele — três travessas, X e
chão, o que ainda lê a 24 px reais; a cabine `substation` continua no set para a interface)
**e GMG usa o `generator` REDESENHADO** a partir da foto dele (contêiner com chaminé, porta do
painel com indicadores, raio, pés; o desenho anterior lia como filmadora — supersede em
§45.4). Set a 31 glifos (`seed-componentes.md` v1.42–v1.43); o seletor de identidade §65
aceita a última linha incompleta.

⚠ Os 192 arquivos de estudo (A/B/C × temas) do gate de 2026-09-04 nunca foram
versionados: saíram da pasta para o scratchpad da sessão em 2026-09-05, porque são
regeneráveis byte a byte por `--estudo PASTA` + `render-peca.mjs` e a folha guarda os
recortes reduzidos que decidiram. Exposto a veto (voltam com um comando).

---