# Marca SEED engenharia — Identidade Visual v5.35

> **Arquivo canônico de identidade visual.** Carregar antes de produzir qualquer output visível (post, carrossel, slide, proposta, mensagem, UI institucional, mockup, peça física). Diretrizes inegociáveis — não improvisar elementos de marca.
>
> **Contexto desta versão:** a v5.0 é a entrega da Fase 2 do rebranding do design system SEED (julho/2026). Não é mudança de paleta nem de logo — os 8 hex canônicos e os vetores de 2018 permanecem intactos. É mudança de **aplicação e profundidade**: linguagem editorial contida no lugar da decoração, grafismo de linhas no lugar das massas, tipografia enxuta (2 famílias), hierarquia de cor com números, regras digitais que 2018 não previa, e acessibilidade medida. Substituição integral da v4.1 — a tabela de supersedes (§16) lista tudo que morre, com o porquê.
>
> **Fronteiras com os outros arquivos canônicos:**
> - **Institucional** (missão/visão/valores, cultura, portfólio, slogans, tom de voz, textos prontos, números) → `sobreaseed.md`. Este arquivo não repete.
> - **Tokens** (rampas tonais, semânticos light/dark, motion, elevação, dataviz — valores executáveis) → `seed-tokens.md` + `seed-tokens.json` + `seed-tokens.css` (v1.1, Drive: `marca seed/Design System v2/`). Este arquivo referencia, não duplica.
> - **Componentes UI vivos e ~50 ícones SVG** → `seed-design-system.html` v1.0, fonte de código até o site DS no Lovable substituí-lo (Fases 3–7).
> - **`erp-seed-design.md` está MORTO** (decisão 2026-07-30): o design system v2 serve todos os produtos — ERP, chat e futuros. Qualquer referência a ele em outros documentos deve ser ignorada.
>
> **Data:** 2026-07-30 · **Aprovação:** Rafael Sant'Ana · **Produção:** Claude (conversa de projeto do rebranding)

---

## 1. Grafia da marca (regra visual e verbal)

**"SEED engenharia"** — SEED em caixa alta, "engenharia" em minúsculo. Inegociável em qualquer peça. Nunca "SEED Engenharia", "Seed Engenharia" ou "SEEDENGENHARIA".

*(Regra duplicada intencionalmente aqui e no `sobreaseed.md` por ser crítica nos dois contextos.)*

---

## 2. Fundamento da identidade

**O conceito de 2018 permanece** (auditado e aprovado em 2026): o símbolo orgânico — formas fluidas evocando energia limpa e renovável — em contraponto deliberado à tipografia reta e sóbria. Essa tensão é a marca.

**O que muda é a postura de aplicação**, resumida em três princípios novos:

1. **Assinatura, não cobertura.** A cor da marca pontua e assina; não forra. Uma peça SEED moderna é majoritariamente branca e respirada, com o turquesa aparecendo com precisão (ver §3.3, proporção 70/20/10).
2. **Precisão de engenharia como estética.** Labels micro em monoespaçada, números tabulares, dados com fonte nomeada, grids limpos. A SEED é uma empresa de engenharia — o material deve parecer feito por engenheiros meticulosos, não por um gerador de posts.
3. **Calor nos momentos certos.** O lado quente da marca (amarelo, EEny, tom acolhedor) não sumiu — foi concentrado. Aparece pontualmente, onde tem função (boas-vindas, sucesso, comunicação interna), e por isso volta a significar algo.

---

## 3. Cores

### 3.1 As 8 cores canônicas (hex intactos desde 2018) + referências de impressão

| Cor | HEX | Pantone | CMYK (C — sup. brilhante) | Papel na v5.0 |
|---|---|---|---|---|
| Turquesa | `#11B0A0` | 3275C | 75 0 45 0 | Cor principal; assinatura da marca |
| Branco | `#FFFFFF` | — | 0 0 0 0 | Cor dominante das peças (~70%) |
| Amarelo | `#FAD61D` | 115C | 4 13 90 0 | **Acento oficial** (grifos, EEny, símbolo) |
| Verde | `#098475` | 327C | 83 25 58 9 | Ação primária digital; profundidade |
| Cinza | `#617683` | 5487C | 63 41 35 19 | Texto e neutros |
| Amarelo Dourado | `#F9B11C` | 7409C | 0 35 91 0 | **Cor de trabalho** (warning, dataviz) |
| Azul | `#53C2E9` | 2985C | 62 0 5 0 | Família de info na UI; contido na marca |
| Azul Claro | `#ECF4FC` | 656C | 12 0 1 0 | Fundos suaves (= azul-50 da rampa) |

Pantone/CMYK resgatados do Manual de Identidade Visual 2018 (v1.0, DSDG). CMYK "U" (superfície fosca): o manual previa e não preencheu — **(a confirmar)** se houver impressão fosca com fidelidade crítica.

**Errata registrada (2026-07-30):** o manual 2018 lista para o Azul Claro RGB 230 244 252 (= `#E6F4FC`) e HEX `#ECF4FC` — valores inconsistentes entre si. Decisão do Rafael: **`#ECF4FC` é o canônico** (é o que todo o material digital usa); o RGB do manual fica registrado como errata.

**Vermelho funcional `#D94545`:** não é cor de marca. Existe para estados de erro/perigo em interface e dataviz negativa (rampa completa nos tokens). **Proibido em material de marca** (posts, capas, propostas).

### 3.2 Rampas tonais — onde vivem os tons

Cada cor virou uma rampa de 10 tons (50→900) gerada em OKLCH com os canônicos ancorados exatos — fundos sutis, hovers, escuros premium, tudo derivado sem tocar nos hex de 2018. **Valores e método: `seed-tokens.md` §2 (v1.1).** Três fatos úteis no dia a dia:

- O verde `#098475` é o turquesa-600 da rampa — e é o tom de **ação acessível** (4.60:1 com branco).
- O azul-claro `#ECF4FC` é o azul-50 — o "fundo suave" oficial.
- O escuro premium da marca é o `turquesa-800 #005048` / `turquesa-900 #00352F` — para capas profundas, use `surface-brand-deep` (turquesa-700/800). **Supersede: a variante não-oficial `#0d8f82` está aposentada.**

### 3.3 Hierarquia de uso — a lei 70/20/10

**Supersede a regra de 2018 de "45% de turquesa na identidade"** — causa raiz das peças cobertas de onda (o "efeito infantil" que este rebranding mata).

- **~70% branco e neutros claros** (branco, cinza-50, azul-50). O respiro é o fundo padrão.
- **~20% família turquesa** — majoritariamente em tons da rampa (fundos 50/100, textos 600/700, escuros 800/900); o `#11B0A0` chapado é assinatura, não forração.
- **~10% acentos** — amarelo, dourado, azul e escuros, cada um no seu papel.

Quatro esclarecimentos de aplicação (para a regra não virar burocracia nem ser burlada):

1. **É hierarquia visual, não régua de pixels.** Ninguém mede área; o teste é de olho: um campo calmo dominante, a cor da marca estruturando, o acento escasso. Se o acento aparece em tudo, nada destaca.
2. **Fotografia conta como campo dominante.** Numa peça fotográfica (capa com foto de usina, post de obra), a foto pode ocupar 80% — a ordem se mantém: foto/neutro > turquesa > acento.
3. **O erro clássico que a regra existe pra impedir:** tratar a cor da marca como o campo dominante. O dominante é o neutro; a marca é a camada estrutural.
4. **A regra é contrato de engenharia via tokens:** nos produtos, componentes não introduzem uma quarta família saturada sem revisão de design — os semânticos já codificam a hierarquia.

### 3.4 Hierarquia dos amarelos (decisão 2026-07-30)

Os dois amarelos distam ~25° de matiz; usados de forma intercambiável, liam como inconsistência. Agora:

- **Amarelo `#FAD61D` = acento oficial de marca.** Grifos, marcadores de ênfase, o amarelo do EEny e do símbolo. Token: `accent-highlight`.
- **Dourado `#F9B11C` = cor de trabalho.** Warning na interface, cat-2 do dataviz, detalhe fotográfico. Fora de destaque de marca.
- **Nunca os dois na mesma peça.**

### 3.5 Papel do azul (decisão 2026-07-30, mal-entendido resolvido em registro)

- **No produto digital: livre e empregado.** É a família de `info` (banners, badges, estados informativos), cat-3 do dataviz, tags, céu/água em ilustração.
- **Em material de marca: contido.** Fora de títulos, fundos de peça e CTAs, onde compete com o turquesa.
- **Ação primária é sempre família turquesa/verde — nunca azul.** Botão azul é a convenção de quem não tem cor própria de ação; a SEED tem (`#098475`, AA). Registro: a contenção do azul nunca se aplicou a sistemas — só a peças de marca.

### 3.5-b Registro de 2026-08-13 — a régua de ação foi CONFIRMADA, e a âncora de ênfase nasce

**Contexto, porque sem ele este registro parece redundante.** Em 2026-08-13, durante a produção do
§48 (Painel) do design system, uma régua de ação alternativa foi proposta e chegou a viver num
preview: *a ação deixaria de ter cor própria e passaria a usar o "escuro estrutural" da tela*, que
naquele momento era `azul-800 #004C61`. A proposta **conflitava frontalmente com o §3.5 acima** e
foi registrada como conflito declarado, pendente de decisão de marca — jamais aplicada ao canônico.

**A proposta foi RETIRADA no mesmo dia, e o §3.5 permanece vigente e intocado.** O motivo não foi
preferência: a caixa de ênfase do painel passou a ser **turquesa vivo** em vez de escura, e com
isso a ação voltou naturalmente à família da marca. Conferido nos gêmeos de token: o
`action-primary` **sempre foi** `#098475` no tema claro e `#66D1C2` no escuro. **A camada de tokens
nunca saiu desta regra** — apenas um preview havia desviado.

*Fica registrado para quem encontrar o rastro:* se você achar num artefato antigo um botão primário
em `azul-800`, é resíduo daquela proposta retirada, não decisão de marca. O hex de ação é o
`#098475` que o §3.5 nomeia.

### 3.5-c ÂNCORA DE ÊNFASE — uma por página, cromática (nova em 2026-08-13)

**Regra:** toda página de produto tem **UMA** caixa de ênfase, e ela é **cromática, não escura**.
Base `turquesa-400 #11B0A0` (L 33,71%, croma 0,624), **tinta única** `turquesa-900 #00352F`
(4,99 — piso 4,5), **anel** `turquesa-600` (4,60 contra a página, obrigatório porque a base contra
o branco mede 2,71 e reprova o piso de fronteira de 3,0) e **véu de luz** `turquesa-300` a 35% no
canto onde o texto vive (ΔL 5,84 pontos, dentro da faixa de 4–6 do mecanismo P1 medido no
`estudo-viver-de-ia.md`).

**Três reprovações que fecham as alternativas, todas medidas:** descer a base um degrau para
`turquesa-500` derruba a tinta a **4,20** · a ação em pílula **branca** dentro da âncora mede
**2,71** de fronteira e reprova · o **itálico do sujeito não pode ser marcado por cor** (branco
2,71 · `amarelo-200` 1,90 · `turquesa-100` 3,36), e passa a ser marcado por **forma e peso** —
mecanismo que, ao contrário da cor, sobrevive ao grayscale.

**Dentro da âncora a hierarquia inverte:** ação primária é pílula `turquesa-800` + branco
(texto 9,37 · fronteira 3,45); secundária é ghost da própria tinta. **O amarelo não entra na
âncora** (1,90).

**Por que a âncora deixou de ser escura, em uma frase:** o diagnóstico foi **luminância, não
matiz** — a versão escura media L 6,03% contra 33,71% da atual, e nenhuma quantidade de croma
corrige uma caixa quase preta.

### 3.5-d TINTA DE TEXTO na família da marca (nova em 2026-08-13)

`text-primary`, `text-secondary` e `text-muted` passam da família cinza para a família turquesa —
**apenas o texto**. **Bordas e superfícies permanecem NEUTRAS e a página permanece BRANCA**,
porque é o que a referência medida faz (`estudo-viver-de-ia.md` §2.1: tinta em croma 0,192, bordas
em 0,027/0,031, página em branco puro) e porque a âncora do §3.5-c é cromática — esverdear a
superfície roubaria dela o contraste de saturação que a faz existir.

Valores e medições completas vivem no `seed-tokens.md` **v1.9**, com o supersede formal da
restrição de hex novo. **Os 8 hex canônicos da paleta 2018 seguem intocados:** a tinta entra como
valor **semântico**, nunca como primitivo.

### 3.6 Regras de contraste (reformuladas com medição — supersede as regras sem número da v4.1)

- Branco sobre turquesa `#11B0A0` = **3.22:1** → permitido APENAS ≥24px ou ≥19px bold (AA-large). Texto funcional/normal sobre fundo turquesa: usar `surface-brand-deep` ou o par de ação (turquesa-600+).
- Branco sobre verde `#098475` = **4.60:1** → AA para qualquer tamanho. É o fundo de botão primário.
- Amarelo `#FAD61D` → **SEMPRE texto escuro** (cinza-900 `#242E34`, 9.70:1). Nunca branco. Idem dourado (7.48:1 com cinza-900).
- Corpo de texto em fundo claro: mínimo cinza-600 `#617683` (4.74:1); preferencial cinza-700 (6.55:1). Cinza-500 só para metadados/placeholder.
- Auditoria completa (14 pares): `seed-tokens.md` §5.

### 3.6-b Admissão de cor de entidade — **`estável`** · gate visual do Rafael aprovado em 2026-08-14 (G3 do preview de composição) *(SUP-5 de 2026-08-14; dispositivo C21 do confronto de referências)*

**É lei de marca, não de token, porque decide o que pode ser cor da SEED.** Cor de entidade
(área do ERP, cliente, categoria) sai de **paleta FECHADA** (decisão Q1 do gate de 2026-08-14) e
só é admitida se passar **4,5:1** com uma das duas tintas declaradas: **`entity-ink-dark` =
cinza-900 `#242E34`** · **`entity-ink-light` = branco**. A verificação acontece **na definição
da paleta** — teste estático, custo zero em render. Precedente interno: a regra do amarelo do
§3.6 (*"SEMPRE texto escuro"*) já era uma declaração de tinta-por-cor; esta seção a generaliza.

**Medição de 2026-08-14 (6 famílias × 10 stops × 2 tintas, fórmula WCAG 2.1 sobre o
`seed-tokens.css` v1.9) — a lei é limpa e vale para TODAS as famílias:**

| Faixa de stop | Tinta admitida | Pior par |
|---|---|---|
| 50–400 | `entity-ink-dark` (cinza-900) | 5,03 ✓ |
| **500** | **NENHUMA — inadmissível** (zona de cruzamento de luminância) | 4,30 ✗ |
| 600–900 | `entity-ink-light` (branco) | 4,60 ✓ |

**A paleta de seis posições proposta, os porquês das exclusões e a regra "acima de 6, repete
cor e distingue por glifo" estão no `seed-composicao.md` §7 (CP22/CP23)** — este arquivo é dono
da LEI de admissão; aquele, do consumo em composição. *Alternativa descartada: hex livre com
cálculo de luminância em render — instável na zona de cruzamento, custo em render e texto
mudando entre chips vizinhos; com paleta fechada, a tabela estática é estritamente melhor.*

---

## 4. Tipografia — 2 famílias de sistema + 1 celebratória de fronteira estreita

### 4.1 Montserrat — marca e interface

Do display ao corpo. Pesos carregados: 300 (Light), 400 (Regular), 600 (SemiBold), 700 (Bold) — preferir versão variável.

| Uso | Especificação |
|---|---|
| Título principal | Bold (700), tracking -0.5 a -2px |
| Subtítulo | SemiBold (600) |
| Corpo | Light (300) ou Regular (400) |
| Texto corrido longo | **Light/Regular com line-height 1.65** — pesos médios em massa ficam monótonos nesta fonte (regra de legibilidade, obrigatória em blog/relatório) |

### 4.2 JetBrains Mono — dados e técnica

Pesos: 400, 500, 700. Papel exclusivo: **dados de medição** (kWh, kWp, demanda), **identificadores** (UC, ART, nº de proposta), **código**, **timestamps**, e **acento técnico em labels micro** (o caption pode ser mono — ver escala). Algarismos tabulares nativos: colunas de números alinham. **Nunca em títulos ou parágrafos.**

### 4.3 Camada expressiva e fonte celebratória (decisões de 2026-07-31)

**Camada expressiva da Montserrat — pesos 800/900 liberados para display de marketing.** A família tem 9 pesos; o sistema usa 4 no dia a dia, e o marketing ganha ExtraBold (800) e Black (900) para títulos de impacto em social e campanhas. Repertório oficial de tratamento (usar antes de pensar em fonte nova): Black gigante com tracking apertado · grifo amarelo (`accent-highlight`) atrás da palavra-chave · contraste Light+Black na mesma frase · contorno/outline do Black · caixa alta empilhada · número gigante em JetBrains Mono como quebra técnica. Fundamento (pesquisa 2026): o erro mais comum é buscar fonte nova quando o sistema só precisa ser usado com mais criatividade.

**Fonte celebratória: Caveat** (Google Fonts, SIL OFL, pesos 400–700 variável, PT-BR completo). Escolhida pelo Rafael em comparativo real de 3 candidatas (vs. Shantell Sans e Kalam, mockup "Feliz 2026!" na linguagem v5.0). É a resposta oficial à necessidade que a Indie Flower atendia de forma errada — o registro manuscrito para momentos humanos, agora com fonte contemporânea e fronteiras duras:

- **Onde:** display de peças celebratórias e de emoção — datas comemorativas, celebrações, conquistas, campanhas humanas. **1 a 3 palavras por peça** (ex.: "Feliz 2026!"), sempre em Bold (700) para presença.
- **Nunca:** corpo de texto, propostas, documentos, material técnico, licitação, UI/produtos, e-mail. Por decisão deliberada, a Caveat **não entra nos tokens** (`seed-tokens.*`) — mantê-la fora do sistema de produto é o que garante a fronteira.
- **Sempre** pareada com layout limpo: Montserrat no restante da peça, lei 70/20/10 valendo.
- Fundamento (pesquisa 2026): tipografia manuscrita é tendência central ("imperfect by design" — reação à perfeição gerada por IA), com a ressalva de mercado que adotamos como regra: funciona para o caloroso/humano, nunca para o corporativo/técnico.

### 4.4 Aposentadorias (supersede formal)

- **Indie Flower — aposentada** (2026-07-30). A tagline manuscrita "Soluções Sustentáveis" **sai de cena** como elemento visual; o texto segue existindo como texto normal quando fizer sentido. Motivo: a fonte (marker fina, genérica, de 2010) envelhecia o visual — mas a *categoria* manuscrita provou-se válida e ganhou sucessora oficial com fronteiras: a Caveat (§4.3).
- **Neo Tech — aposentada** (2026-07-30). Não tinha papel definido, não está no Google Fonts, nenhuma peça recente a usava.

### 4.5 Pilhas de fallback (tokens) — e desde 2026-08-26 elas são PLANO B de verdade

⚠⚠ **A pilha não é mais o mecanismo de entrega da fonte — é reserva.** Decisão
dele em 2026-08-26 (*"podemos deixar o plano B, mas temos que forçar sempre a
fonte canônica"*): **peça impressa EMBUTE** a família (contrato TP1, aborta se
faltar) e **bancada/tela referencia por URL relativa** os TTF de
`03-assets/fontes/`. A pilha abaixo só trabalha em arquivo aberto fora do
repositório ou mutilado. Instalação no sistema é opcional e documentada em
`03-assets/fontes/LEIA-ME.md`. ⭐ *Antes disso, "fallback" era eufemismo: sem
`@font-face` em lugar nenhum, a pilha era o mecanismo primário — e o mono
rasterizava Consolas em tudo que estava vivo.*

```
--seed-font-sans: 'Montserrat', -apple-system, 'Segoe UI', Roboto, Arial, sans-serif;
--seed-font-mono: 'JetBrains Mono', 'SF Mono', Consolas, 'Courier New', monospace;
```

### 4.6 Regras absolutas (herdadas de 2018, auditadas e mantidas)

Sem sombras em texto · sem layouts diagonais · sem texto em curva · line-height títulos 1.1–1.2, corpo 1.5–1.7.

### 4.7 Escala tipográfica

| Nível | Tamanho / lh | Peso e tracking | Uso |
|---|---|---|---|
| DISPLAY | 64/72 | Bold · -2px | Hero, capa |
| H1 | 42/48 | Bold · -0.5px | Título de página |
| H2 | 32/38 | Bold | Título de seção |
| H3 | 24/30 | SemiBold · `text-brand` | Subtítulo principal |
| H4 | 18/24 | SemiBold | Subtítulo secundário |
| BODY LARGE | 17/26 | Light | Lead |
| BODY | 14/22 | Regular | Corpo padrão |
| SMALL | 12/18 | Regular · `text-muted` | Notas, metadados |
| CAPTION | 11/14 | SemiBold **ou JetBrains Mono Medium** · 2px tracking · UPPERCASE | Labels, eyebrows, micro-headers |

Nota da v5.0: o CAPTION em mono é o acento de "precisão de engenharia" da linguagem editorial (§10). A escala vale para peças, sites e documentos; a nota da v4.1 sobre escala própria do ERP morre junto com o `erp-seed-design.md` — **produtos usam esta escala** (densidades específicas serão tokens de componente na Fase 3).

---

## 5. Logo — regras críticas

**NUNCA redesenhar a logo manualmente.** Usar sempre os vetores oficiais, em duas fontes equivalentes:

1. **Local (Cowork SEED):** `02_assets/logos/` e `02_assets/simbolos/`.
2. **Espelho público (Google Drive):** pasta "identidade seed" — FILE_IDs na §5.4.

### 5.1 Variantes (14)

**Horizontais (uso padrão):** `logo-horizontal-principal.svg` (fundo branco) · `logo-horizontal-fundo-turquesa.svg` · `logo-horizontal-mono-negativo.svg` (branca, fundos escuros) · `logo-horizontal-mono-positivo.svg` (preta, impressão) · `logo-horizontal-cor-azul.svg` · `logo-horizontal-cor-cinza.svg`

**Verticais (compactos/quadrados/stories):** `logo-vertical-principal.svg` · `logo-vertical-fundo-turquesa.svg` · `logo-vertical-fundo-turquesa-2.svg` · `logo-vertical-mono-negativo.svg` · `logo-vertical-mono-positivo.svg`

**Símbolos (só o ícone):** `simbolo-principal.svg` · `simbolo-mono-negativo.svg` · `simbolo-mono-positivo.svg`

| Fundo | Variante |
|---|---|
| Branco | logo-horizontal-principal |
| Turquesa | logo-horizontal-fundo-turquesa ou mono-negativo |
| Escuro (incl. dark mode e `brand-deep`) | mono-negativo (branca) |
| Impressão P&B | mono-positivo (preta) |

### 5.2 Logo responsivo — mínimos por contexto (NOVO na v5.0)

O manual 2018 definia só o mínimo impresso (20mm — mantido). Regra digital nova:

| Contexto | Regra |
|---|---|
| Impresso | Logo completa, mínimo **20mm** de largura |
| Digital, largura ≥ 120px | Logo completa (horizontal ou vertical) |
| Digital, largura < 120px | **Só o símbolo** — o texto "engenharia" fica ilegível |
| Favicon / app icon / avatar (16–64px) | Símbolo, com margem interna generosa |
| Avatar circular (WhatsApp/Instagram) | Símbolo centrado; nunca a logo horizontal cortada |

**Kit de favicon — padrão 2026 (4 arquivos, para qualquer site/produto SEED):** `favicon.svg` (navegadores modernos, escala infinita, pode embutir media query de dark mode) · `favicon.ico` multi-size 16/32/48 (fallback legado) · `apple-touch-icon.png` 180×180 (iOS) · `icon-512.png` (PWA/Android). Fonte master do símbolo em ≥512×512. Regra de qualidade: validar o símbolo **no tamanho real** de 16 e 32px antes de publicar — legível ali ou simplificar. *(Assets executáveis: pendência §17.)*

### 5.3 Posição — matriz por contexto (supersede "preferencialmente ao centro" de 2018)

| Contexto | Posição |
|---|---|
| Navegação de site/produto | Topo-esquerda |
| Capa, momento editorial, slide de abertura | Centro |
| Documento, proposta, relatório | Topo (cabeçalho) + rodapé discreto |
| Post/story | Assinatura discreta (rodapé ou canto), nunca dominando |
| Peça física (fachada, frota) | Conforme §12 |

### 5.4 Espelho público dos assets (Google Drive)

> Espelho oficial dos vetores, pasta **"identidade seed"** (leitura pública), mantido pelo Rafael. A fonte segue sendo `02_assets/`; substituição de arquivo mantém o FILE_ID, upload novo gera ID novo (atualizar esta tabela). IDs verificados em 2026-07-17.
> **Pasta raiz:** `https://drive.google.com/drive/folders/1lkaQZsUWwPMtQPgOvd_UWHmh5tC9n7fd`

**Embed em HTML (padrão validado):**

```html
<img src="https://lh3.googleusercontent.com/d/{FILE_ID}" data-gdid="{FILE_ID}" alt="...">
<script>document.addEventListener("error",function(e){var i=e.target;
if(i.tagName==="IMG"&&i.dataset.gdid&&!i.dataset.fbk){i.dataset.fbk="1";
i.src="https://drive.google.com/thumbnail?id="+i.dataset.gdid+"&sz=w1200";}},true);</script>
```

**Logos horizontais — `Logos/Logo horizontal/SVG/`**

| Asset canônico | FILE_ID |
|---|---|
| logo-horizontal-principal.svg | `1nAlR9lzijfinjSXQP7a2mAlCCK4pOBfg` |
| logo-horizontal-fundo-turquesa.svg | `1PnQ9P27-2AHc8HkVKLkUH7AsVFn-mXVI` |
| logo-horizontal-mono-negativo.svg | `1mdKAuVa5DBT6byNbFDVZUzG7NNLa7rSy` |
| logo-horizontal-mono-positivo.svg | `1WuxV0lH9v5vS0HrgwMvIEmipmHHtAgDM` |
| logo-horizontal-cor-azul.svg | `1HyDD_P7-3Vr224RBLIi3GECzI_lPNvsE` |
| logo-horizontal-cor-cinza.svg | `1paa61LBbBuq9-N__boaSdcqbvn8qIXQl` |

**Logos verticais — `Logos/Logo vertical/SVG/`**

| Asset canônico | FILE_ID |
|---|---|
| logo-vertical-principal.svg | `1Orxj_QN_Te7qE0nw25wegImUIqM8BRDW` |
| logo-vertical-fundo-turquesa.svg | `1mwHRVBppWDwwV8xfcZhPoz5bHBsORglf` |
| logo-vertical-fundo-turquesa-2.svg | `1m98Yq24-xAQRDHCr2E4uqadjxbQif00H` |
| logo-vertical-mono-negativo.svg | `10ZeHkaJR0h86n904fWLvKy-Q2JIbMi07` |
| logo-vertical-mono-positivo.svg | `1sljnSSkFGPkqGn3xrnAvXUVzq5xA80iQ` |

**Símbolos — `Logos/Símbolo/SVG/`**

| Asset canônico | FILE_ID |
|---|---|
| simbolo-principal.svg | `1kUgeY6901yV6yuJ5IzMEuSoOavg9Qm_G` |
| simbolo-mono-negativo.svg | `15PNEI8bVDmLhXtB9LfyCMY5z7-E7Q5R3` |
| simbolo-mono-positivo.svg | `1bNf7rchqI9SzuZOdzwG5BJ_FH4PqQgDt` |

**Mascote EEny — `Mascote/SVG/`**

| Asset canônico | FILE_ID |
|---|---|
| eeny-pose-01.svg | `18JTeO30_Dv4gMlll8qOw1VuJu_NEEVYI` |
| eeny-pose-02.svg | `1_HkCLKxqmHxXf4PAyMqd4hiSYtkE8Fro` |
| eeny-pose-03.svg | `1S29NNfmmHcKYD0mS4Aq-S_dIhcXEK6lF` |
| eeny-pose-04.svg | `1fnS1_DJ5m96ya-SYYfWAhkqQccPo28q5` |
| eeny-pose-05.svg | `17zPz_aGoi6Azla5h6jOcVg90o3DiggFZ` |
| eeny-pose-06.svg | `1k9SZOlv5gs200GiRnDHvBxBuTve-09FR` |
| eeny-pose-07.svg | `1lrwcmS-htwcXuZfJ3pa4GGrGNt3eNcv5` |
| eeny-pose-08.svg | `1qWKwFO5A_PWGSVpIs_dEvg4fGssU_XYO` |

**Kit de favicon / ícones de app / avatar — `Logos/Símbolo/favicon/`** (fonte: `07-pecas/favicon-avatares/`, gerados por `gen-favicon.py`; rasterizados em 2026-09-04, FV-P2). **Upload feito em 2026-09-05 pela sessão, com autorização explícita dele no chat** (*"sim autorizo"*, MANIFESTO §147): subpasta `favicon` criada em `Logos/Símbolo/` (ID `1l3uGhWZ_Khvlhuf7U2ciDMWQpjVxGw5r`), os 10 arquivos copiados de `07-pecas/favicon-avatares/` com MD5 conferido 10 de 10 depois da cópia, permissão herdada da pasta-mãe (`anyone: reader`, lida pela API do Drive), FILE_IDs lidos pela API — nunca de memória. IDs verificados em 2026-09-05.

| Asset canônico | FILE_ID |
|---|---|
| favicon.svg | `1f0TOAYbqXv97L4NhA_6hnERUds3RiAEi` |
| favicon.ico | `1mcxscaz2CXwwxd2YG4YfP9tZeat7SfbD` |
| apple-touch-icon-claro.png | `14Tgif1pMNBpVxF5pWeYY7Uu2PIwWB8yi` |
| apple-touch-icon-escuro.png | `1wn3KJs3hXJuR3igVjaJJBdUDXiDf_TFu` |
| icon-512-claro.png | `1a2zkp5-Gkd7YONIPq3GhUo68cR-wuo4I` |
| icon-512-escuro.png | `1oz1BNKk_TzjYFkzC2Fe-CBT1rC0GQ3p3` |
| icon-192-claro.png | `1E96QGRsFDa-_GkVtBswwoDCujFeRJb0J` |
| icon-192-escuro.png | `1wAbbWeZiDJFc6aI7P7nV9I-UR8wR7lqc` |
| avatar-rede-claro.png | `1aG835CE6_mroTPByQKDuR7C26Z6UGQHO` |
| avatar-rede-escuro.png | `1V8mb42omCeP9Iz41_S6vTPDB9TsO-tvN` |

### 5.5 Área de proteção e proibições

Área de proteção: espaço mínimo **X** ao redor (X = altura da letra "S" de SEED); nada invade. X é uma **razão**, nunca valor fixo em px/mm — escala junto com a logo (padrão de mercado: 1× a altura da letra de referência, exatamente o nosso caso). Proibido (2018 + v4.1, mantidos): distorcer/esticar/comprimir · alterar cores dos elementos · sombra/outline/efeito · rotacionar · fundo de baixo contraste · recriar com texto ou formas · desmembrar os elementos.

---

## 6. Mascote EEny

EEny é uma criatura tipo gota/chama amarela com o símbolo da SEED na cabeça, forma orgânica com detalhes turquesa. **NÃO é um robô. NÃO é uma bolinha.** *(Supersede formal: o Manual 2018 §6.1 o descrevia como "robozinho" — conceito morto; a definição orgânica é a canônica.)*

**8 poses canônicas** (`eeny-pose-01…08.svg`, local em `02_assets/mascote-eeny/`, espelho na §5.4): 01 cauda longa/transição · 02 frontal padrão (na dúvida, use esta) · 03 atenta · 04 perfil 3/4 · 05 costas/contemplativa · 06 concentrada · 07 acenando/boas-vindas · 08 voltada/cauda fluida.

### Regras da v5.0 — parcimônia e desacoplamento

- **EEny vive desacoplado do logo.** *(Supersede: a regra 2018 de "manter sempre à direita do logotipo" morre.)* Quando excepcionalmente aparecerem juntos, proporção 3:1 (logo:EEny) mantida.
- **Momentos permitidos (produto e comunicação):** onboarding, estados de sucesso/celebração, empty states amigáveis, comunicação interna, conteúdo educativo leve.
- **Papel social — o EEny é ativo estratégico, não enfeite.** Nas redes, o EEny é o **protagonista permitido da camada de personalidade** da marca: pode estrelar conteúdo leve, educativo e de engajamento (dicas de energia, bastidores, datas, trends adaptadas) como a "voz simpática" da SEED. A evidência de mercado é forte — mascotes bem operados são dos maiores ativos de reconhecimento e engajamento que uma marca pode ter. A calibragem SEED: humor leve e didático no tom do `sobreaseed.md` — **não** o caos absurdista de mascotes B2C de app; somos uma empresa de engenharia falando com empresários e famílias. Regra prática: no feed, EEny protagonista em conteúdo de personalidade; coadjuvante pontual no restante; ausente do conteúdo técnico-comercial.
- **Proibido:** propostas comerciais, material técnico (laudos, relatórios, diagramas), peças de licitação, e como decoração recorrente/preenchimento de peças que não são sobre ele.
- Nunca distorcer proporções · nunca recriar manualmente · sempre os SVGs oficiais.

---

## 7. Grafismo v2 — linguagem de linhas

**A mudança visual mais importante da v5.0.** Direção aprovada: "menos infantil, mais profissional".

### O que morre (supersede formal)

- **Ondas como massas chapadas** cobrindo porções da peça (inclusive empilhadas turquesa+verde) — era a assinatura visual de 2018 e a principal fonte do efeito datado.
- **Grafismo secundário de padrões** (ícones repetidos sobre fundo turquesa, Manual 2018 §3.7–3.8) — textura decorativa aposentada sem sucessor direto.

### O que nasce

A onda não some — **emagrece**. Vira linha: curvas finas de **1.5–2px**, `stroke-linecap: round` (o mesmo traço da ilustração), sempre horizontais, em turquesa.

### 7.1 A ORIGEM DO DESENHO — o significado, e ele não pode se perder (novo na v5.4)

> **Rafael Sant'Ana, 2026-08-20, verbatim:** *"as ondas sao representacao de montanhas, pois remete ao verde, a natureza, logo as ondas devem se cruzar para formar um efeito de uma imagem na qual tem montanhas na frente e atras."*

A curva **não é uma onda decorativa: é uma cordilheira em planos que se cruzam.** Verde, natureza, profundidade. Perder essa leitura é perder o significado, não só a estética.

**Três coisas fazem uma linha ler como PLANO, e sem elas o desenho vira ritmo em vez de serra:**

| # | o que é | por que é indispensável |
|---|---|---|
| **① CRUZAMENTO** | as cristas se sobrepõem em x, não correm juntas | **paralelismo é RITMO; serra é PROFUNDIDADE.** Duas linhas paralelas nunca leem como planos |
| **② OCLUSÃO** | na travessia, a crista da frente **interrompe** a de trás | é o que informa a **ORDEM** dos planos. Sem ela o olho vê um X, não um vale. ⚠ Feita por `<mask>`, **nunca** por forma preenchida — assim funciona sobre qualquer fundo e não viola "linha, nunca massa" |
| **③ HIERARQUIA DE PESO E TOM** | a de trás mais fina e mais clara; a da frente mais grossa e mais firme | **perspectiva atmosférica**: o que está longe perde contraste |

*O corte de oclusão é também o idioma do desenho técnico — linha interrompida para indicar o que passa por cima. Conversa com o princípio §2 ("precisão de engenharia como estética") em vez de brigar com ele.*

**④ O CRITÉRIO DO MOVIMENTO** (veredito de 2026-08-20): *"nao pode perder o sentido de movimento apesar de serem montanhas"*. **O movimento é parte do significado** — a onda originou o desenho, a montanha é a leitura. **Composição que congele a serra viola o aprovado**, mesmo com cada linha correta.

### 7.2 DOIS REGIMES — `SERRA-CENA` e `DETALHE DE LINHA` (novo na v5.4; supersede a leitura de que o teto de ~8% governa todo grafismo)

O teto de **~8% da altura** da tabela abaixo foi escrito para **detalhe de rodapé de 1–2 linhas**. A partir da v5.4 o canon reconhece **dois regimes diferentes**, e o teto de 8% governa **apenas o primeiro**:

| regime | o que é | teto de altura | área total |
|---|---|---|---|
| **DETALHE DE LINHA** | 1–2 linhas discretas na base, sem cruzamento nem oclusão — o uso original desta seção | **≤ ~8%** da altura | ≤10% |
| **SERRA-CENA** | composição de **3 ou 4 planos** com cruzamento, oclusão e hierarquia de peso (a §7.1) | **por formato, tabela da §7.4** | ≤10% |

**POR QUE O REGIME NOVO EXISTE, com número.** Medido em 2026-08-20/21: **a serra precisa de ~15% da altura da peça para LER como serra.** Abaixo disso ela não fica "discreta" — ela **desaparece**: numa faixa de 32px (7,62% de uma peça de 420) o traço do plano de trás cai a 1,50px e a cena vira uma linha. *Não é preferência estética: é o limite abaixo do qual o desenho deixa de comunicar o que a §7.1 diz que ele significa.*

**As duas saídas do conflito, e o canon aceita AS DUAS** — é isto que a v5.4 registra para que ninguém leia uma como contradição da outra:
- **(a) ir para o TOPO** — o teto de ~8% é escrito para *rodapé*; uma faixa de topo é outro uso. Foi a saída aprovada para o modelo **MONTANHA** (§7.3).
- **(b) mudar o teto NO RODAPÉ** — aprovado por veredito, formato a formato, na tabela da §7.4. Foi a saída aprovada para o modelo **SERRA EM ARCOS**.

### 7.3 OS DOIS MODELOS DE SERRA-CENA — regras INDEPENDENTES (novo na v5.4)

> **Rafael Sant'Ana, 2026-08-21, verbatim:** *"o uso das montanhas/ondas no topo nao é o padrao, o padrao em em baixo, mas aprovei esse modelo de montanha para usar no topo caso o criador queira coloca-las no topo."*
>
> E, sobre estender ao topo uma regra do rodapé: *"para as montanhas do topo, eu aprovei dessa forma porque o desenho ficou muito bom, entao nao tem problema nao seguir a regra das ondas do rodape. **considere que o topo segue uma regra e o rodapé outra regra**."*

| | modelo **SERRA EM ARCOS** | modelo **MONTANHA** |
|---|---|---|
| **onde** | **RODAPÉ** | **TOPO** |
| **status** | **PADRÃO** | **OPÇÃO** de quem monta a peça, quando a composição pedir — e sem precisar justificar |
| **planos** | **4** (fundo · longe · perto · frente) | **3** (fundo · meio · frente) |
| **traçado** | **arcos** que nascem e morrem abaixo da moldura | crista **bezier** de curvatura distribuída |
| **encontro das linhas** | **TOQUE EXATO** — recorte na própria crista, folga zero | oclusão **COM FOLGA** (traço de máscara 7px) |
| **altura da faixa** | tabela da §7.4, **por formato** | **pela LARGURA, não pela altura** — §7.4-b |

**⚠ REGRA DE ESCOPO, e ela vale para todo este documento: regra derivada de UM modelo fica ESCOPADA a ele até haver veredito que a estenda.** O **toque exato** é regra do **RODAPÉ**, não lei geral do grafismo. *Generalizar por conta própria mudaria em silêncio uma peça já aprovada.*

**Anatomia da SERRA EM ARCOS (4 planos, de trás para a frente):** **FUNDO** — única linha *contínua* atravessando a peça; a mais alta e a mais clara; **sem ombros**. **LONGE** e **PERTO** — morros **PARCIAIS** em duas profundidades: arcos que **nascem e morrem abaixo da moldura** ou atrás de outro morro; cume **fora de centro**, flancos **assimétricos**, ápice **ARREDONDADO** — nunca ponta (*"o nosso nao é pontudo e sim uma ondulaçao"*). **FRENTE** — baixa e suave; atravessa a peça **mergulhando abaixo do limite inferior** entre um cume e outro (*"nao pode ser tao alta, ela tampa os cumes do fundo"*).

**Duas regras de construção da serra em arcos:**
- **TOQUE EXATO** (*"as linhas devem se tocar, se uma linha acaba antes de tocar a outra nao da sensacao de profundidade"*): a oclusão é recortada na **própria crista**, folga **zero** — a ponta redonda da linha de trás **encosta** no traço da frente. **É construção, não retoque.**
- **REGRA DO FRAGMENTO** (*"em linhas nao fica bonito e profissional, clean"*): trecho visível de linha com comprimento **< 80px** (calibrado na cena de 1080; escala com a janela) **ou** folga máxima **< 9px** sobre a linha que o oclui é **SUPRIMIDO**. **Ou o morro aparece de verdade, ou não aparece.** *A regra roda POR FORMATO.*

### 7.4 A LEI DA ESCALA e os TETOS POR FORMATO da serra-cena (novo na v5.4)

**LEI: a forma do morro é constante em UNIDADES DE F (altura da faixa); o que muda com a largura da peça é a COMPOSIÇÃO, nunca a forma.** Peça larga **não** ganha morro esticado.
**Razão natural da cena aprovada: `w/F = 12,7`.** *Medido: no post (w/F = 12,7) o morro massivo sai 432×62px — a proporção aprovada; no banner com a mesma fração de largura (w/F = 38,5) o MESMO morro sai 450×28px, razão 16:1 — o "esmagado" que foi reprovado.*

**ÂNCORA em peça larga-baixa:** a cena vai **ancorada** numa janela de proporção natural (largura da janela = `12,7 × F`), no **lado oposto ao texto**; a linha da FRENTE continua atravessando a peça inteira, mergulhada abaixo do limite fora da janela.

**Tetos aprovados por veredito** (2026-08-21) — **supersede o ~8% para o regime serra-cena**, formato a formato:

| formato | faixa | % da altura | veredito |
|---|---|---|---|
| post 1:1 · cartão dentro do detalhe · pasta A4 · story | conforme `floor(h × 0,0795)` | **7,8–7,9%** | cabe no regime de detalhe |
| **cartão de visita 90×50 mm** (frente e verso) — **VIGENTE** | 84px de 590 | **14,2%** | *"escolho B"* (medida brasileira, 2026-08-22 — §7.4-d) |
| ~~cartão de visita 89×51 mm~~ | ~~83px de 600~~ | ~~13,8%~~ | **HERDADO** — *"L2 e L3 estão ok"* na razão americana; **supersedido em 2026-08-22**, mantido só porque o acervo dos 7 formatos ainda está nessa razão |
| **banner 3:1** | 59px de 500 | **11,8%** | *"está aprovado"* |
| **capa 4:1** | 62px de 396 | **15,7%** | *"está aprovado"* — é o **mínimo** que satisfaz "a partir do centro" + proporção natural |
| **montanha no TOPO** | 64px de 420 | **regida pela LARGURA — ver §7.4-b** | aprovada em 2026-08-20 (P3 branco · P4 brand-deep) |

### 7.4-b O TETO DO TOPO É DE LARGURA, NÃO DE ALTURA (novo na v5.5)

> **Rafael Sant'Ana, 2026-08-21, verbatim:** *"acho que deixar 1:1 nao seria o
> ideial, o ponto é medir a aplicação na largura se atende ao desenho selecionado
> para o topo, a altura nao importa."*

**Regra:** no regime **SERRA-CENA no TOPO** (o modelo MONTANHA), o que se verifica
é a **proporção entre a LARGURA da peça e a altura da faixa** — `w/F` —, e **não**
a porcentagem da altura da peça. **A altura da peça é irrelevante para este
teto**, e a razão de aspecto da peça **não entra** na decisão.

**O número, e de onde ele vem:** a peça aprovada em 2026-08-20 (P3 branco e P4
brand-deep) tem **w = 420** e **F = 64**, logo a proporção do desenho aprovado é

> **`w/F = 6,5625`** — e o teto é **`F ≤ w / 6,5625`**.

*Nada foi inventado aqui: o número é a razão da própria peça que ele aprovou.
Faixa mais alta que isso, para a largura que a peça tem, deixa de ser o desenho
aprovado — engorda a cena verticalmente. Faixa mais baixa não é reprovada por esta
regra: a perda de leitura pelo excesso de finura é julgamento de FORMA, que
continua sendo gate visual humano (§7.2).*

**O que isto SUPERSEDE:** a leitura anterior, de que o topo respondia a um teto de
**15,24% da altura** válido só na razão 1:1. Aquele número continua correto como
*descrição* da peça aprovada (64 de 420 é 15,24%), mas **não é o teto** — é
consequência dele naquele formato. **Peça larga não fica sem teto e não precisa de
veredito novo:** ela responde à mesma proporção de largura.

⚠ **ESCOPO:** esta regra é do **TOPO**. O **RODAPÉ** continua com os tetos por
formato da tabela acima — regra derivada de um modelo fica escopada a ele até
haver veredito que a estenda (§7.3).

### 7.4-c PISO DE TRAÇO EM MILÍMETROS PARA PEÇA IMPRESSA (novo na v5.6)

> **Rafael Sant'Ana, 2026-08-22, verbatim:** *"saída B — piso de 0,25 mm por
> ESCALA, e só para peça IMPRESSA"*

**REGRA:** em **peça impressa**, nenhum traço do grafismo fica abaixo de
**0,25 mm**. Quando o mais fino ficaria abaixo, **todos os planos são multiplicados
pelo mesmo fator** até o mais fino tocar 0,25 mm.

| | |
|---|---|
| **piso** | **0,25 mm** (≈ 0,71 pt) |
| **método** | **ESCALA** — fator único aplicado a todos os planos |
| **escopo** | **só peça impressa** (peça de tela continua na lei em px, §7.4) |

**POR QUE ESCALA E NÃO GRAMPO, e é medido:** grampear por baixo (elevar só quem
está abaixo do piso) **achata planos no mesmo peso** — no cartão, 4 pesos distintos
caem para **2**. E a **hierarquia de peso e tom** é uma das **três condições que
fazem a linha ler como PLANO** (§7.1 ③). *Grampo salva o traço destruindo o
mecanismo do desenho; escala paga o custo em presença e mantém a leitura.*

**POR QUE 0,25 mm, com os números que sustentam:** os pisos de reprodução do
mercado são **0,088 mm** (digital, linha positiva), **0,176 mm** (digital, linha
**reversa** — clara sobre escuro) e 0,053/0,088 mm em offset. O verso do cartão é
**linha reversa** por definição (serra clara sobre `#005048`), e antes desta regra
media **0,180 mm** — passava o piso digital reverso por **0,004 mm**, 2% de margem.
**0,25 mm dá 42% de folga.** *Serigrafia (0,353 mm positiva / 0,706 mm reversa)
segue fora do alcance de cartão, e isso é declarado: peça serigrafada exige
decisão própria.*

⚠ **E o motivo pelo qual esta regra tinha de existir:** a lei do traço da §7.4 é em
**pixel**, inclusive o grampo. **Logo o traço FÍSICO de uma peça impressa é função
da resolução de exportação** — o mesmo arquivo exportado a 600 DPI em vez de 300
imprime com metade da espessura. **Piso em pixel não garante nada no papel.**

**ESCOPO EXATO, e ele é estreito de propósito:**
- **vale** para o **cartão de visita** (**90×50 mm** desde 2026-08-22 — §7.4-d) e
  para qualquer peça com alvo físico declarado;
  ⚠ **e o piso sobrevive à troca de formato — isto foi MEDIDO, não presumido:** nos
  três formatos testados (89×51 · 90×50 · 90×48 mm) o traço mais fino sai em
  **0,250 mm**, porque o piso é aplicado por ESCALA a partir do px/mm da peça.
  *É exatamente por isso que o piso foi escrito em milímetro e não em pixel.*
- **não vale** para post, story, banner e capa — **peça de tela não tem
  milímetro**, e inventar alvo físico para ela seria pior que não ter;
- **aplica-se à SERRA**. O **marcador de seção** (o risco amarelo de 56px, §7.6)
  tem traço fixo de 2px = **0,170 mm** no cartão: **passa** em offset e em digital
  positivo, **reprova** em serigrafia. **Fica intocado até haver veredito próprio**
  — ele não é linha de serra e não responde à lei da faixa.

**⚠ O PISO NÃO PODE SER VIOLADO PELO ARREDONDAMENTO (esclarecimento normativo da
v5.8).** O traço vive em px com 2 casas decimais. Ao aplicar o fator de escala, o
**menor** peso é arredondado **para CIMA**; os outros, para o mais próximo.
*Motivo medido: na pasta A4 (11,80952 px/mm) o piso vale 2,95238 px e o
arredondamento normal devolvia 2,95 px = **0,24980 mm** — 0,0002 mm abaixo do canon.
Piso violado por arredondamento é piso que não existe. Arredondar o menor para cima
só ENGROSSA, nunca afina, logo não pode criar defeito novo.*

**INSTRUMENTOS desta regra — dois, com papéis diferentes:**

| instrumento | papel |
|---|---|
| `validacao/guarda-piso-mm.py` | **a GUARDA (contrato MM1), de ALVO DE PASTA.** Julga contra **este** piso e devolve placar `PASS/FAIL/[n/a]` com exit code. É o que impede uma peça nova de nascer abaixo do piso sem ninguém ver |
| `validacao/mede-traco-mm.py` | **o DIAGNÓSTICO.** Mede o traço em mm/pt contra os pisos de **mercado** (offset · digital · serigrafia, positiva e reversa), que não são canon |

**⚠ COMO SE DECLARA QUE UMA PEÇA É IMPRESSA:** o **próprio artefato** carrega o alvo
físico — `<meta name="alvo-fisico" content="90x50mm">`, escrito pelo gerador.
**Peça sem essa declaração sai `[n/a]` NOMEADO**, nunca PASS: *peça de tela não tem
milímetro, e inventar alvo físico para ela seria pior que não ter.* Nenhum
instrumento desta casa decide isso por **nome de arquivo** — filtro por nome tem a
aparência de cobertura e já deixou 17 de 51 arquivos deste projeto nunca medidos.

**Traço:** escala com a FAIXA (`3,5 × F/86`), com **grampo de 1,5 a 4,5px** — o piso e o teto do canon nunca são violados. Peça com largura **< 700px** recebe **SUBCONJUNTO** da cena.
⚠ **Todos estes números são px de TELA.** Para **peça impressa** o traço em px desta seção é o **ponto de partida, não o resultado**: o piso físico de **0,25 mm** da **§7.4-c** (novo na v5.6) multiplica todos os planos por um fator único quando o mais fino ficaria abaixo dele. *A pendência que esta linha declarava aberta — "o traço em mm para impressão (cartão 89×51 mm, pasta A4)" — foi MEDIDA e DECIDIDA em 2026-08-22 (pendência de projeto `MR-P6`); ver §7.4-c e `Design System v2/validacao/MANIFESTO.md` §108.*

### 7.4-d A MEDIDA FÍSICA DO CARTÃO É 90×50 mm — PADRÃO BRASILEIRO (novo na v5.7)

> **Rafael Sant'Ana, 2026-08-22, verbatim:** *"escolho B / qualquer ajuste é minimo
> se precisar fazer, e o desenho se ajusta hoje proporcionalmente"*

**REGRA: o cartão de visita da SEED engenharia é `90 × 50 mm`** (9×5 cm), o padrão
dominante nas gráficas brasileiras. A **peça de referência** é
**`07-pecas/cartao-90x50/`** (§12.9), em 1063×591 px = 11,811 px/mm = 300 DPI.

> ⚠ **A peça de referência MUDOU em 2026-08-25, e o ponteiro antigo foi
> repontado antes de o arquivo sair.** Até aqui esta cláusula apontava para
> `L2-cartao-rodape-natural.html` e `L3-cartao-verso.html`, da era Cowork, que
> foram removidos por decisão dele — eram **arquivo de produção**, e o arquivo de
> produção vigente passou a ser outro. Os números que aquelas peças mediram e
> que fixaram o formato ficam registrados aqui, porque a decisão do formato se
> apoiou neles: **1062×590 px, 299,7 DPI, traço mínimo de 0,250 mm**.
> A peça nova mede 300 DPI exatos e traço de 0,261 mm — e a diferença tem
> explicação na §7.4-f: o grafismo dela SANGRA, porque em 90 mm de span o traço
> não alcançaria o piso.

**SUPERSEDE os `89×51 mm`** em que o cartão vinha sendo desenhado. ⚠ **E a razão do
supersede é o achado desta rodada:** 89×51 mm é `3,5 × 2 polegadas`, a medida de
**EUA e Canadá** — ela entrou no projeto como **default de ferramenta, não como
decisão de marca**. Não existe registro de ninguém tê-la escolhido. *A empresa
imprime no Brasil (MG, ES e BA), onde 90×50 mm é o que a gráfica corta sem pedir
arquivo especial e o que porta-cartão e carteira acomodam.*

**O que a troca custou, medido peça por peça — e é uma coisa só:**

| | 89×51 (antes) | **90×50 (vigente)** | leitura |
|---|---|---|---|
| traço mais fino | 0,250 mm | **0,250 mm** | o piso da §7.4-c **atravessa a troca de formato** |
| piso digital REVERSO (0,176 mm) | PASS | **PASS** | o verso escuro — o caso caro — segue coberto |
| área do grafismo (teto 10%) | 1,51% | **1,54%** | sobe porque a peça encolheu de área; segue a um sexto do teto |
| faixa da serra | 83px de 600 = 13,83% | **84px de 590 = 14,24%** | ⚠ **o desenho NÃO mudou** — a serra tem quase o mesmo tamanho físico (7,0 → 7,1 mm); a peça ficou **1 mm mais baixa**, então mudou o DENOMINADOR |
| GR1 na pasta das peças largas | 15·0·0 | **15·0·0** | nenhuma regressão |
| acervo dos 7 formatos | 21·0·0 | **21·0·0** | intacto — nenhuma outra peça foi tocada |

**O ÚNICO custo real: uma linha nova no teto da §7.4.** A tabela de tetos é indexada
pela **razão da peça** (tolerância 0,01), e a razão mudou de `1,745` para `1,800`.
⚠ *Antes de esta seção existir, a guarda GR1-c devolvia `[n/a]` para o cartão de
90×50 com o motivo escrito — **"razão da peça 1,800 não casa com nenhum formato da
tabela §7.4; teto de canon não se interpola nem se herda por analogia (§0-b)"**.
Isso é a guarda funcionando: ela se recusou a aprovar por analogia e mandou a lacuna
ao decisor.*

**Nenhum vetor mudou, nenhum hex mudou.** A peça vigente é **byte-idêntica** à opção
B que ele leu na folha de decisão (`render-audit/gate-mr9/decisao.html`) — conferido
por md5, 5 de 5.

⚠ **O QUE ESTA SEÇÃO NÃO RESOLVE, e a gráfica vai perguntar: SANGRIA.** O verso do
cartão é **fundo cheio** `#005048`, logo o arquivo de impressão precisa de área
**além da linha de corte** (mais margem de segurança para o conteúdo). **Nenhuma
peça deste projeto tem sangria hoje**, e nenhum número de sangria foi medido ou
autorizado. **Pendência `MR-P10`** — independe desta decisão e não se resolve por
analogia com o que "as gráficas costumam pedir" (§0-b).

⚠ **E se a compra for ONLINE, confirme o formato no pedido.** A maior gráfica online
do país (Printi) vende **90×48 mm** como o formato dela. Esses 2 mm viram corte no
desenho se o arquivo foi fechado para 90×50. *A variante 90×48 está medida e
guardada em `render-audit/gate-mr9/br-90x48/` — ela não é escolha de marca, é
restrição de fornecedor, e por isso não entrou no canon.*

### 7.4-f O GRAFISMO DE LINHA TEM UM SPAN MÍNIMO: 125 mm (novo em 2026-08-25)

**REGRA: o divisor de grafismo, na proporção natural, exige `span ≥ 125 mm` para
cumprir o piso de 0,25 mm do §7.4-c.** Abaixo disso ele não pode ser usado como
está — a peça sangra o grafismo ou não o usa.

**Por que existe um mínimo, e por que ele não se contorna desenhando mais fino:**
a altura do divisor e a espessura do traço são **a mesma grandeza** — a escala do
mapeamento `viewBox → width`. Encolher o grafismo encolhe o traço na mesma
proporção, e não há atributo que separe os dois. Isto já estava escrito no
`gen-timbrado.py` para o caso do rodapé (*"o que NÃO dá para encolher é o
grafismo"*); a §7.4-f generaliza com o número.

**Medido em nove spans, gerando o divisor e lendo o traço mais fino de cada um:**

| span | traço mais fino | |
|---|---|---|
| 78 mm | 0,157 mm | ⚠ abaixo |
| 90 mm | 0,181 mm | ⚠ abaixo |
| 100 mm | 0,201 mm | ⚠ abaixo |
| 110 mm | 0,221 mm | ⚠ abaixo |
| 120 mm | 0,241 mm | ⚠ abaixo |
| 124 mm | 0,249 mm | ⚠ abaixo — falta 0,001 mm |
| **125 mm** | **0,251 mm** | ✅ o mínimo |
| 130 mm | 0,261 mm | ✅ |
| 170 mm | 0,342 mm | ✅ a proporção do timbrado e da pasta |

**A SAÍDA PARA PEÇA MENOR QUE 125 mm É SANGRAR**, e o cartão 90×50 é o caso
fundador: o divisor entra com **130 mm centralizado** e a peça mostra um recorte
de 90 mm. *Arte maior que o corte é a definição de sangria* — não é gambiarra, é
o uso correto do recurso. Traço final 0,261 mm, folga de 4,5%.

⚠ **A alternativa legítima é NÃO usar grafismo.** Numa face que carrega
informação (a frente do cartão), a MM1-a sai `[n/a]` com o motivo declarado, e
esse é o veredito correto — não uma lacuna. O §3.5-c limita a UMA âncora
cromática por página; ele não exige nenhuma.

---

### 7.4-e SANGRIA E MARGEM DE SEGURANÇA EM PEÇA IMPRESSA (novo na v5.10)

> **Rafael Sant'Ana, 2026-08-22, verbatim:** *"a sangria vc tem que usar o que o
> mercado indica nas suas pesquisas. acredito que 3+3"*
> e, sobre o **método**, na mesma mensagem: *"vc tem que deixar o desenho dentro da
> area real, e a parte da sangria vc cresce o desenho."*

| | |
|---|---|
| **sangria** | **3 mm** por lado, além da linha de corte |
| **margem de segurança** | **3 mm** — nenhum conteúdo (texto, logo, marcador) mais perto do corte que isso |
| **método** | a composição é definida para a **ÁREA DE CORTE** e **não se mexe**; a sangria é **crescimento para fora** |

**O MÉTODO É REGRA, não detalhe de execução.** Há duas formas de produzir sangria e
elas dão resultados diferentes: (a) **encolher** a arte para caber numa tela maior —
*muda a composição e desalinha tudo que foi aprovado*; (b) **crescer** para fora,
mantendo a arte onde está. **O canon manda (b)**, por veredito dele.

⚠⚠ **O ARQUIVO DE PRODUÇÃO NASCE SOB DEMANDA (regra dele, v5.11).** Verbatim:
*"sobre a producao, apenas o mock, quando for ter a producao de alguma peça
especifica, ai sim trabalhamos o arquivo de producao para aquela demanda"*.

**Logo o entregável PADRÃO de toda peça é o MOCK** — a peça no tamanho do corte,
gerada por script, para decidir se o desenho está certo. **O arquivo com sangria (e,
quando houver dobra, a faca) só é feito quando existe a COMPRA daquela peça.**
*Por que isso é regra e não preferência: arquivo de produção feito antes da demanda
envelhece — a gráfica escolhida pode pedir 5 mm em vez de 3, ou uma faca diferente, e
aí o arquivo pronto vira arquivo errado com aparência de pronto.* O único arquivo de
produção que existe hoje é o do **cartão de visita** (`producao/cartao-90x50/`),
feito porque a demanda apareceu junto com a decisão.

⚠ **CONSEQUÊNCIA: existem DOIS tipos de arquivo, e confundi-los é defeito.**

| tipo | tamanho | para que serve |
|---|---|---|
| **arquivo de GATE** | exatamente a **área de corte** | é o que a guarda **GR1** mede (área, véu do glifo, faixa) e o que o decisor aprova olhando |
| **arquivo de PRODUÇÃO** | corte **+ 3 mm** de cada lado | é o que vai para a gráfica |

*Misturar os dois numa pasta faz a GR1 medir a tela com sangria e devolver `[n/a]` por
razão fora da tabela de tetos — um defeito que não é defeito.* Cada arquivo **declara
o próprio papel**: `<meta name="papel" content="gate">` ou `"producao"`, e o de
produção declara também `<meta name="corte-px">` e `<meta name="sangria">`.

**POR QUE SANGRIA NÃO É OPCIONAL NESTA FAMÍLIA, medido:** a serra do rodapé é
`width:100%` com `bottom:0` — ela **toca três bordas da peça**. Arquivo do tamanho do
corte + desvio normal de guilhotina = **fio branco na borda**. *No verso do cartão,
que é fundo cheio `#005048`, isso é o defeito de acabamento mais visível que existe.*

**POR QUE 3 mm e não 5, com os números da pesquisa:** as três fontes consultadas
convergem numa estrutura — **3 mm é o mínimo que a indústria aceita** (é o que a
Printi, maior gráfica online do país, publica como padrão dela) e **5 mm é o mais
comum no Brasil**. O veredito escolheu 3 mm, e o efeito medido é que **o layout
aprovado cabe sem mexer**: o conteúdo do cartão está a **4,24 mm** do corte — folga de
**1,24 mm** contra a margem de 3 mm (contra 5 mm faltariam 0,76 mm, e mover conteúdo
mudaria a composição aprovada).
⚠ **A gráfica escolhida manda:** as três fontes dizem para confirmar no pedido. Se a
gráfica exigir 5 mm, a conta já está pronta — e o conteúdo precisará ir de `50px` para
`59px`.

⚠ **ARREDONDAMENTO, mesma regra do piso de traço (§7.4-c / v5.8):** a sangria em px
arredonda **para CIMA**. *Sangria curta é sangria que não existe.* No cartão a
11,8 px/mm: 3 mm = 35,4 px → **36 px = 3,05 mm**.

**INSTRUMENTOS:** a guarda **MM1** (`validacao/guarda-piso-mm.py`) ganhou duas
cláusulas — **MM1-d** (arquivo de produção declara sangria ≥ 3 mm; arquivo de gate sai
`[n/a]`, porque não leva sangria por definição) e **MM1-e** (conteúdo a ≥ 3 mm do
corte). O diagnóstico detalhado sai em `validacao/mede-sangria.py`.

**ESCOPO E FRONTEIRAS:**
- vale para **peça com alvo físico declarado**. Peça de tela não tem corte;
- ⚠ **peça com DOBRA, VINCO ou FURO tem margem própria e NÃO está coberta aqui.** A
  pasta A4 com aba é o primeiro caso e **não existe como arquivo de produção** — a
  fonte pesquisada dá, como exemplo do problema, **15 mm** no lado da espiral em
  encadernação wire-o. *Medir isso é frente nova (`MR-P12`);*
- **marcas de corte** no arquivo final dependem do que a gráfica pedir no pedido.

### 7.5 COR DO GRAFISMO — só stops da rampa canônica (novo na v5.4)

Princípio: **perspectiva atmosférica.** O que está longe é mais claro e mais fino; a frente é sempre a mais firme. No tema escuro o plano de trás quase se dissolve no fundo — é a "névoa".

| modelo · tema | fundo da peça | frente | perto | longe | plano de fundo |
|---|---|---|---|---|---|
| arcos · claro | `#FFFFFF` | `#098475` | `#11B0A0` | `#66D1C2` | `#9CE4D8` |
| arcos · escuro | `#005048` | `#66D1C2` | `#11B0A0` | `#098475` | `#006C62` |
| montanha · claro | `#FFFFFF` | `#098475` | `#66D1C2` | — | `#9CE4D8` |
| montanha · escuro | `#005048` | `#66D1C2` | `#11B0A0` | — | `#006C62` |

**REGRA: o grafismo usa EXCLUSIVAMENTE stops da rampa canônica turquesa (§3.2). Nenhum hex fora do sistema, em nenhuma circunstância.**
> ⚠ **Precedente registrado, e é a origem da regra §0-b do projeto:** entre 2026-08-20 e 21 um hex inventado (`#0A6B60`) viveu quatro rodadas no plano de trás das peças escuras e chegou a **peça aprovada**. Ele havia entrado "por precedente", e o arquivo do precedente **não existia**. Retirado por ordem do decisor: *"eu nao autorizei e vc nao deveria ter criado sem autorizacao algo canonico e ja decidio."* Substituído por `#006C62` (turquesa-700) — **ΔE76 = 1,03**, abaixo do limiar de percepção humana (~2,3), logo **sem custo de aparência**.
> **REGRA §0-b: valor de marca que não existe neste documento nem nos gêmeos de token NÃO SE CRIA** — nem "por precedente", nem "provisoriamente até o gate", nem porque a diferença é invisível. Faltando valor: use o stop canônico mais próximo medindo o custo, **ou** leve a lacuna ao decisor. **Nunca invente e avise depois.**

**O AMARELO NÃO ENTRA NAS LINHAS DO GRAFISMO.** O §3.4 dá ao amarelo o papel de **acento único** e esta seção manda o grafismo ser o elemento mais silencioso da peça — amarelo na serra criaria **dois acentos competindo**. *Alternativa descartada, não esquecida.*

### 7.6 Os usos permitidos — tabela consolidada

| Uso permitido | Regime | Especificação |
|---|---|---|
| Textura de fundo | **serra-cena (uso interno)** | **A cena Z3 do rodapé, INTEIRA** (5 camadas, 4 tons, oclusão por máscara), turquesa a **≤10% de opacidade**, atrás de conteúdo. Gerador: `gen-detalhe.py`. *Supersede (v5.12) as "2–4 linhas curvas paralelas": paralelismo é ritmo; serra é profundidade (§7.1). Veredito verbatim: "vc tem que criar essas linhas igual as do rodapé que já estão aprovadas".* |
| Marcador de seção | detalhe | **O risco aprovado, intocado**: bezier única 56×8px, **amarelo `#FAD61D`**, traço 2px, ponta redonda — o `class="risco"` de `gen-zero-formatos.py`, em produção nas 3 famílias. Amarelo mantido por veredito (§78.3-6 do `seed-componentes.md` o reconcilia de propósito; §7.4-c já lhe dera veredito próprio). Asset: `03-assets/grafismos/grafismo-marcador.svg` |
| Detalhe de rodapé | detalhe | 1–2 linhas na base da peça, discretas, **nunca mais de ~8% da altura** |
| Divisor editorial | **serra-cena (uso interno)** | **A imagem do rodapé (1080×85) repetida emendada e CORTADA no limite direito** (verbatim: *"a quantidade de cópias que precisar em sequência emendadas, e o que passar do limite do lado direito vc corta"*). Altura natural = largura/12,7 (§7.4); **piso de leitura = §7.2** (~15% da altura da peça — abaixo disso a serra desaparece); **sem teto** — a aplicação avalia o objeto (§78.3-3); ao crescer, cresce **proporcionalmente**. Emenda pela §7.3: toque exato natural (máscara de oclusão) + FUNDO das cópias internas mergulha abaixo da faixa. Gerador: `gen-detalhe.py` |
| **Serra-cena no RODAPÉ** | **serra-cena** | **PADRÃO.** Modelo de arcos, 4 planos, toque exato. Tetos por formato na §7.4 |
| **Montanha no TOPO** | **serra-cena** | **OPÇÃO.** 3 planos, crista bezier, oclusão com folga. Faixa regida pela **LARGURA**: `F ≤ w / 6,5625` (§7.4-b) |

**Regras (todas mantidas da v5.0):** nunca rotacionar (sempre horizontal) · nunca voltar à massa preenchida (exceção única: capas físicas legadas até o redesenho da **Fase 8**) · nunca competir com foto ou dado — **grafismo é o elemento mais silencioso da peça** · **área total de grafismo ≤10% da peça** *(supersede o limite de 50% de 2018)*. *Medido nas 12 peças produzidas: **0,67% a 2,17%** — o teto de área nunca esteve em risco; o conflito sempre foi de ALTURA, não de área.*

### 7.7 ONDE VIVEM OS VETORES — a pendência §17.3 muda de estado (novo na v5.4)

A pendência 3 da §17 dizia: *"as linhas-padrão (textura, marcador, rodapé) serão desenhadas como assets SVG oficiais na Fase 8; até lá, gerar conforme especificação da §7"*. **Para o regime SERRA-CENA isso já aconteceu, e não como SVG solto: como GERADOR.**

| o que | onde |
|---|---|
| serra em arcos · 7 formatos | `Design System v2/validacao/gen-zero-formatos.py` |
| serra em arcos · peças largas (cartão, banner, capa) | `Design System v2/validacao/gen-z3-largos.py` |
| montanha · topo | `Design System v2/validacao/gen-variantes-montanha.py` |
| os 5 estudos que produziram o modelo | `validacao/gen-estudo-{crista,vale,seed,frente,zero}.py` |
| **textura · divisor · marcador (v5.12)** | **`06-validacao/geradores/gen-detalhe.py`** — extrai o traçado do `gen-zero-formatos.py` por AST, nunca por cópia. Assets de referência: `03-assets/grafismos/` |
| especificação completa, com todos os números | `seed-componentes.md` **§76** |

**⚠ NÃO RECRIE O TRAÇADO À MÃO.** Traçado redigitado é a classe de defeito mais perigosa deste projeto, porque não chama atenção e por isso não é conferida. *A pendência §17.3 fechou na v5.12: os três usos internos (textura, marcador, divisor) ganharam gerador e assets oficiais.*

---

## 8. Fotografia — real, da operação (diretriz nova)

**O banco de imagens genérico de 2018 está morto** (família no campo dourado, aperto de mãos, pessoa apontando pro alto — comunicava o oposto do atributo "sincero, autêntico" que a própria marca declara).

### Prioridade (nesta ordem)

1. **Operação real da SEED:** obra, usina em drone, subestação, equipe de verdade em campo com EPI, painel sendo instalado, bancada técnica. Com +1.000 obras entregues, matéria-prima existe — o processo de captação/curadoria é operacional (fora deste doc).
2. **Detalhe técnico:** close de conexões, instrumentos de medição, materiais — a estética da precisão.
3. **Stock — exceção documentada:** apenas para conceitos impossíveis de fotografar internamente; **nunca pessoas encenadas**; preferir paisagem/textura/aérea.

### Tratamento

- Luz natural, preferência pela golden hour em externas (herança boa de 2018).
- Tratamento de cor consistente: temperatura levemente quente, contraste moderado, **sem filtros de saturação artificial**; os tons da paleta podem ser puxados na correção (turquesa em céus/sombras, dourado na luz), com sutileza.
- Pessoas: espontâneas, em ação real — nunca pose de catálogo. Atributos-guia mantidos de 2018: integração, inovação, benefícios.

---

## 9. Ilustração

- **Traço primeiro:** linha fina 1.5–2px, cantos e pontas arredondados (`stroke-linecap: round`), na cor do contexto (cinza-700 ou turquesa-600).
- **Preenchimento chapado com moderação** — o flat "puro" de 2018 (tudo preenchido) lê como clip-art; a v5.0 inverte: linha domina, preenchimento pontua (1–2 áreas por ilustração, cores da paleta).
- Sem degradês, sem sombras, sem efeitos de luz (mantido de 2018).
- Paleta restrita ao sistema. Céu/água podem usar azul/azul-50 (papel formal do azul em ilustração).

---

## 10. Linguagem editorial (novo na v5.0)

O rigor que diferencia o material SEED de template:

- **Eyebrow/label micro** abre seções: CAPTION 11px, UPPERCASE, tracking 2px, cinza-500 — em Montserrat SemiBold ou JetBrains Mono Medium (acento técnico).
- **Displays falam frases completas, com ponto final.** "Tudo o que evoluiu, em um só lugar." — não "NOVIDADES!!!". Título é afirmação, não grito.
- **Hierarquia por peso e espaço, não por cor.** Cor em título é exceção com função (H3 brand), não regra.
- **Respiro generoso:** margens de seção ≥ `sp-12` (48px) em documentos, ≥ `sp-16` (64px) em landing pages. Na dúvida, mais branco.
- **Números são protagonistas:** dados da SEED (+1.000 obras, +50.000 painéis) em destaque tipográfico com fonte/contexto — e valores de medição sempre em mono.
- Sem emojis em material de marca. Ícones: a biblioteca SVG do DS.

---

## 11. Sistema digital

**Fonte executável: tokens v1.1** (`seed-tokens.css`/`.json`/`.md`). *(Supersede: o bloco CSS resumido da v4.1 — que ainda listava `--font-deco: Indie Flower` — está morto; nunca copiar tokens deste arquivo, sempre dos arquivos de token.)*

- **Cores em código:** componentes consomem tokens **semânticos** (`--seed-action-primary`, `--seed-text-secondary`), nunca hex, nunca primitivos.
- **Dark mode é cidadão de primeira classe:** todos os semânticos têm par light/dark; superfícies escuras oficiais tintadas no hue do cinza (`#0B1419`→`#273137`). Logo em dark: mono-negativo.
- **Motion:** dois registros (produtivo 100–150ms / expressivo 300–400ms) com easings tokenizados e `prefers-reduced-motion` embutido.
- **Elevação:** par superfície+sombra (`raised`/`overlay`/`modal`), sombras tintadas no cinza-900.
- **Acessibilidade:** WCAG 2.2 AA é piso — contraste conforme §3.6, foco visível (`--seed-focus-ring`), touch targets ≥44×44px.
- **Spacing** base 4px (`sp-0…sp-24`) · **radius** sm 4 / md 8 / lg 12 / xl 16 / full · **grid** 12 colunas gap 24px · **breakpoints** mobile 0–639 / tablet 640–959 / desktop 960+.
- **Dataviz:** sequência categórica fixa cat-1…6 + positivo/negativo (tokens §chart); poucas cores, diferenciar também por forma/espessura.

---

## 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).

---

## 13. Padrões de aplicação — slides e documentos

*(Atualiza §7 da v4.1; especificação completa por peça nas skills `seed-ds-*` e nas aplicações da **Fase 8**.)*

- **Capa/abertura:** fundo `surface-brand-deep` (turquesa-700/800) **ou branco editorial** (título grande escuro + linha de acento) — as duas vias oficiais. Logo conforme fundo. *(Supersede: capa em `#0d8f82` e "onda decorativa na base" obrigatória.)*
- **Slides de conteúdo:** fundo branco, título Bold em `text-primary` **ou** turquesa-600 (não mais `#11B0A0` em título — contraste), subtítulo SemiBold (dourado sai do subtítulo padrão — é cor de trabalho; usar `text-brand` ou cinza), corpo Light/Regular cinza-700, logo discreto no rodapé.
- **Slides de seção:** fundo turquesa-400 ou brand-deep, texto branco ≥24px, grafismo de linha (nunca massa).
- **Rodapé padrão:** `SEED engenharia · seed.eng.br` — caption, mono opcional.

---

## 14. Componentes digitais — referência rápida

Inventário vivo no `seed-design-system.html` v1.0 (botões, forms, cards, alerts, badges, chips, navegação, accordion, progress/skeleton, data-table, tooltip/modal, ~50 ícones SVG inline — **sempre SVG inline, nunca emoji ou biblioteca terceira**). Copiar de lá, não recriar. **Este inventário será auditado e substituído pelo site DS no Lovable (Fases 3–7)** — até lá, o HTML segue sendo a fonte de código.

---

## 15. Instruções operacionais para o agente

1. **NUNCA inventar dados institucionais** — fonte exclusiva: `sobreaseed.md`.
2. **NUNCA recriar logo ou EEny** — sempre os SVGs (§5.4 para web).
3. **Cores exatas, sempre via token semântico em código**; em peças, hex canônicos da §3.1 e tons da rampa.
4. **Montserrat + JetBrains Mono nos papéis da §4; Caveat SÓ em display celebratório (§4.3)** — Indie Flower e Neo Tech não existem mais.
5. **Lei 70/20/10** em toda peça; grafismo = linhas (§7); EEny = parcimônia (§6).
6. **Tom** do `sobreaseed.md`: acolhedor, direto, autêntico; linguagem editorial da §10.
7. **Dúvida de aplicação → perguntar ao Rafael** antes de prosseguir.

---

## 16. Supersedes consolidados da v5.0

| Item morto | Substituído por | Motivo |
|---|---|---|
| Regra "45% de turquesa" (2018) | Lei 70/20/10 (§3.3) | Causa raiz do efeito infantil |
| Ondas como massas chapadas | Grafismo v2 — linhas (§7) | Profissionalizar; era o elemento mais datado |
| Grafismo de padrões (ícones repetidos) | — (aposentado sem sucessor) | Textura decorativa 2018 |
| Limite de grafismo 50% da área (2018) | ≤10% da peça (§7) | Contenção editorial |
| Indie Flower + tagline manuscrita | Caveat como celebratória de fronteira estreita (§4.3) | A fonte envelhecia; a categoria manuscrita é válida (tendência 2026) e ganhou sucessora com regras |
| Neo Tech | JetBrains Mono (papel técnico real) | Sem papel definido nem uso |
| Variante não-oficial `#0d8f82` | `surface-brand-deep` (turquesa-700/800) | Necessidade agora tem resposta oficial na rampa |
| Regras de contraste sem número (v4.1) | §3.6 com medições WCAG | Branco/turquesa era afirmado, agora é medido (3.22:1) |
| "Logo preferencialmente ao centro" (2018) | Matriz por contexto (§5.3) | Regra de era impressa |
| Tamanho mínimo só impresso 20mm (2018) | + mínimos digitais (§5.2) | 2018 não previa favicon/avatar/navbar |
| EEny "sempre à direita do logo" (2018) | Desacoplamento + parcimônia (§6) | Mascote-apêndice era pensamento 2018 |
| EEny como "robozinho" (2018 §6.1) | Definição orgânica (§6) | Já negado na v4.x; formalizado |
| Banco de fotos stock genérico (2018) | Fotografia real da operação (§8) | Contradiz o atributo "autêntico" da própria marca |
| Ilustração flat "tudo preenchido" (2018) | Linha primeiro, preenchimento pontual (§9) | Flat puro lê como clip-art |
| Dourado como subtítulo padrão (v4.1 §3) | Dourado = cor de trabalho (§3.4) | Hierarquia dos amarelos |
| Bloco CSS resumido da v4.1 (§8) | Tokens v1.1 (arquivos próprios) | Fonte única; o bloco ainda citava Indie Flower |
| `erp-seed-design.md` | Este DS v2 serve todos os produtos | Decisão 2026-07-30 |
| CMYK/Pantone ausentes do digital | Tabela §3.1 (resgate do manual 2018) | Camada física precisava |
| Errata Azul Claro (RGB≠HEX no manual 2018) | `#ECF4FC` canônico | Decisão Rafael 2026-07-30 |

**Nota de rastreabilidade:** nada foi apagado do acervo — o Manual 2018 (PDF) e a v4.1 permanecem como registro histórico no Drive; este documento é que governa.

---

## 17. Pendências explícitas

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

## 18. Versionamento

| Versão | Data | Mudança |
|---|---|---|
| **5.35** | 2026-09-05 | **O veto dele sobre os glifos ("muito grosseiros"; "subestação pode ser uma torre de alta tensão") virou medição e três decisões (MANIFESTO §149–§151):** traço óptico 1,25 nos destaques (o traço 2 do set ampliado 15× dava 4,2 % do diâmetro contra 1,3–2,0 % no segmento — medido em 9 perfis) · `transmission-tower` NOVO no set, desenhado a partir do modelo em imagem que ele mandou, na densidade máxima que lê a 24 px reais · `generator` REDESENHADO a partir da foto dele · set a 31 glifos e o seletor §65 com a régua da última linha incompleta (decisão dele). §12.31 atualizada. IC-P2 corrigida no inventário e na bancada. |
| **5.34** | 2026-09-05 | **O fechamento das pendências (MANIFESTO §147–§148):** ele aprovou a remoção dos 48 estudos das capas (saíram), não vetou nada, autorizou o upload do kit de favicon para o espelho público — **`FV-P2` fecha de vez** (subpasta `Logos/Símbolo/favicon/`, 10 FILE_IDs na §5.4 lidos pela API, prova de download por MD5) — e mandou criar os glifos: **`FV-P5` fechada** com `hard-hat` e `solar-panel-plus` no set §45 (v1.39, 30 glifos); §12.31 atualizada (os oito destaques com ícone). A fila do item 9 do §17 zera. Achado registrado para a fila do `seed-componentes.md`: `IC-P2` (o inventário §45.3 diz que o Lucide não tem `solar-panel`; tem). |
| **5.33** | 2026-09-05 | **AS PENDÊNCIAS ANTES DA F9 — ele mandou resolver a fila antes de abrir a fase (MANIFESTO §144–§146).** `PI-P1` fechada por veredito (a placa da distribuidora é fabricada pela norma dela) · `SN-P10` fechada por CONFIRMAÇÃO do veredito de 25/08, agora com os renders que faltavam (opções A/C/B na mesma escala) · `FV-P2` executada (kit rasterizado pelo próprio gerador, 17/17 determinístico; §12.26, tabela nova no espelho §5.4 aguardando o upload dele) · **§12.30 capas de rede social** nasce (`FV-P1` + `FV-P3`: LinkedIn A · Facebook C · YouTube A+ · X A não publicada · WhatsApp A; formatos com fonte, avatar medido em captura, pesquisa de mercado) · **§12.31 destaques do Instagram** nasce (`FV-P4`: 8 destaques com o set de ícones §45, composição C escuro por delegação, medida no tamanho real) · nasce `FV-P5` (glifos para Obras e SEED Plus). Instrumento: `render-peca.mjs` e `guarda-peca-fresca.mjs` aceitam `alvo-tela` para peça de tela com tamanho fixo em px. Resíduo para o gate seguinte: tabela de remoção dos 48 estudos das capas. |
| **5.32** | 2026-09-04 | **A ONDA 3 FECHA E ENTRA NO CANÔNICO — nove specs novas (§12.22–§12.29 + §12.2-b), e com ela a F8 inteira.** Última decisão aberta respondida em 2026-09-04 (MANIFESTO §142: R6-U1 *"Linha 2 — cor da marca"* · R6-U3 *"20 mm"* · R6-REM *"aprovo a remoção (…) deve ficar salvo e registrado o desenho aprovado de todos os lados do carro"* · R6-VETO *"todos ficam"*). ⭐⭐⭐ **§12.22 FROTA** — a peça que ele apontou como faltante nasceu do zero, foi REPROVADA por erro de categoria (*"pensar na adesivagem dos carros como peças de papelaria é errado"*) e voltou como arte final DITADA por ele: 4 veículos × 3 vistas, cordilheira em escala de lataria (F 353–419 mm, traço ≥ 9 mm), traseira pelo modelo da FOTO REAL da Strada e sem ondas, EEny pose 07, 5 áreas de foto a 150 DPI, contato a 45/45 mm; nasce a **tipografia do contato (§138.1)** — o bicromatismo da logomarca espelhado em 0800/site, com ícones e a segunda fonte na lista; a **regra do formato veículo** (9 itens) decidida e promovida. **§12.23 UNIFORME/EPI** — a E1 refina a MR-P11 (*"podemos usar o amarelo, mas atendendo essas condições do padrao da propria logo"*); 4 cores de escritório; a **regra geral do bolso** (com bolso → vertical no bolso; sem → horizontal); campo cinza com logo branca direto; boné = símbolo, chapéu/capacete = vertical; **gola interna turquesa nas 4** decidida com estudo de mercado; **colete refeito com prova de interseção no DOM** (0 de 10) depois de o gate ver o número sobre a faixa — *guarda que mede com a constante do gerador confirma o gerador*. **§12.24 ONE-PAGERS** — dor→solução, coluna de foto, radar com fonte, **2 números** (*"+10 anos de mercado"*), estatística redundante não se cria. **§12.25 ROLL-UP + TOTEM** — institucional clean + comercial A/B (*"a da BV financeira…"*), ondas canto a canto SÓ nas comerciais (*"mas nao é regra"*), zona de sacrifício 250 mm, toque de 0,00 mm no amarelo consertado. **§12.26 FAVICON/AVATARES** — as 5 decisões (® sempre · margem 0% · escuro colorido · 2 fundos oficiais · maskable 40% W3C); raster e capas de rede fora, por decisão. **§12.27 PLACA DE INSTALAÇÃO CONCLUÍDA** — voluntária pelo texto da lei, 2 tamanhos sub-múltiplos da chapa, sem amarelo (*"nesse caso da placa sim"*), **QR real** wa.me em 4-Q com segno 1.6.6 (leitura por celular é etapa do gate). **§12.28 PORTFÓLIO** — template com fotos em branco, sem RT (*"a empresa é o foco"*), rol de fotos. **§12.29 AGENDA** — o brinde mudou de veredito (*"não precisa ter"* → *"gere um layout para agenda"*): 3 capas, 2 contracapas, sem ano, Cidade/UF. **§12.2-b MARCA D'ÁGUA** — E1 explodida aplicada nas 12 peças, **P3 cantos opostos** oficial, símbolo medido pelo CORPO (a caixa do viewBox fazia 58 mm virarem 40), ® fora por recorte, tinta 700 nos números (o furo dos 4,60:1 contra o branco puro). §17: fecham os itens 4 (redesenho executivo — F8) e 7 (kit de favicon; capas de rede ficam como `FV-P1`); o item 2 ganha matéria (quatro listas de fotos); nascem `PI-P1`, `FV-P1/P2` (as demais divergências da auditoria de fechamento — gola no gerador, capôs de Saveiro/Strada, rename da folha da regra, PNG das institucionais, docstrings defasadas — foram resolvidas ANTES desta promoção, não nomeadas). Roadmap v2.3: **F8 FECHADA, três ondas; próximo = F9.** Nenhum hex muda, nenhum vetor muda. |
| **5.31** | 2026-09-03 | **O diário de obra perde o furo (R5-M3, §140)** — *"nao se usa mais furo"*: corpo a 7 mm como o rodapé, colunas proporcionais em 196 mm; §12.15 anotado. Na mesma rodada, sem mudança de canon: a repetitiva oficial da marca d'água é a P3 (cantos opostos), a E1 segue aplicada; o colete foi refeito com prova de interseção contra as faixas refletivas (a folga declarada antes media uma constante errada do gerador — §141.1); a gola interna ganhou estudo de mercado antes da decisão (§141.2). |
| **5.30** | 2026-08-31 | **A MOLDURA AMPLA promovida ao §12.2 (R4-M2, MANIFESTO §139)** — margem 7 mm (o limite é a zona de exclusão X da logo, 6,72 mm medidos no asset), cabeçalho 29, rodapés 33/22/8, área útil 196×227/241/256 a partir de (7,29); **+24,6% de área no orçamento**. Propagada à família inteira (~45 peças regeneradas, colisão medida no DOM em todas: laudo e checklist tinham tabelas presas em 170 mm e foram realargadas com conta declarada). Nasce junto: a marca d'água de contorno do símbolo EXPLODIDO (360 mm, sangrando as 4 bordas, ® fora por conta) na família orçamento/proposta/portfólio, e a tinta dos números de seção sobe de turquesa-600 para 700 — o furo achado na re-medição: 600 mede 4,60:1 sobre o branco PURO, e qualquer véu o derruba (régua nova: contraste se confere contra o pior fundo que a peça admite). |
| **5.29** | 2026-08-27 | **A ONDA 3 ABRE, por ordem dele (*"Vamos abrir a 3 onda, tudo em paralelo"*) — e três vereditos moldam o escopo ANTES da produção.** ⭐ **(a)** o conteúdo dos **one-pagers é produzido por mim** (*"vc deve produzilos, nao eu"*), com fonte única no `sobreaseed.md` — nada fora dele entra na peça (§14.1); ⭐⭐ **(b)** o **item 3.4 (material próprio do Diagnóstico 360°) SAI da onda e do DS** — veredito dele: é **serviço que a SEED vende**, não marca com identidade própria (*"diagnostico 360 nao consigo ver ele tendo material de DS (...) é um serviço que vendemos"*); ele vive como conteúdo dentro do one-pager de Consultorias; ⭐ **(c)** o **portfólio nasce como TEMPLATE com área de foto em branco** (*"deixe em branco o local da foto"*) + **lista das fotos necessárias** entregue no fechamento — foto real é insumo de produção, não de DS. Escopo final da onda: **7 itens ≈ 15 peças** (3.1 frota · 3.2 uniforme/EPI · 3.3 one-pagers ×5 · 3.5 banner/roll-up + totem · 3.6 kit favicon + avatares · 3.7 placa de instalação concluída · 3.8 portfólio + brinde). Registro operacional no `plano-producao-pecas.md` §6. |
| **5.28** | 2026-08-27 | **OS MARCADORES DE ESTADO MENTIAM, E UMA PENDÊNCIA ESTAVA ÓRFÃ HÁ TRÊS DIAS — achado ao responder *"quanto falta pra finalizarmos o DS?"*.** ⭐⭐⭐ **A pergunta dele é respondida LENDO ESTA LISTA e o `seed-ds-roadmap.md`, e os dois estavam defasados:** **(a)** `CT-P8`, `PF-P2`, `FT-P1` e `GT-P1` foram fechadas na v5.27 e o fechamento foi escrito **só no changelog** — as quatro entradas continuaram marcadas ⏳, ou seja, quem lesse a fila veria como aberto o que fechou ontem (*mesma classe da defasagem que o roadmap pagou em 2026-08-22, quando uma sessão quase reabriu trabalho concluído 11 dias antes*); marcador corrigido para ✅ **sem reescrever o texto do achado**, que é registro datado (regra CP31). **(b)** ⭐ **A `SN-P10` nunca existiu como entrada:** nasceu em 2026-08-24 dentro do PARÁGRAFO do §17.6 (perda de reconhecimento a distância da placa A3 NR-10 ao sair a tarja turquesa: logo 60 mm → legível a 1,75 m numa peça de 4,0 m) e **três rodadas de "resolver tudo em aberto" passaram por cima dela**, porque "em aberto" se lê NA LISTA. Agora tem entrada própria, classificada como **decisão dele com custo em mm** — sai com as duas opções renderizadas (§14.13). **RÉGUA: pendência citada em prosa não existe; só existe o que tem entrada na fila, e ela entra no mesmo movimento em que é nomeada.** |
| **5.27** | 2026-08-27 | **A FILA ZERADA — dez pendências fechadas numa rodada, a mando dele (*"resolva as pendencias em aberto, assim que acabar eu autorizo a onda 3"*).** ✅ **`CT-P8`** — CT1 no acervo: **168 PASS · 0 FAIL** (era 32 FAIL). Dois consertos: a peneira aprendeu que **texto alfanumérico é rótulo** (botões "1"/"2" da paginação saíam como ícone e tinta de dígito nunca centra na caixa — é tipografia, não desalinhamento), e os três glifos tipográficos usados como ícone (⋯ ‹ ›) viraram **SVG de viewBox simétrico** — ⭐ *glifo de texto como ícone mede a tinta fora do centro porque a em-box posiciona pela linha de base*. ✅ **`PF-P2`** — nasce a `guarda-preview-contraste.mjs` (contrato **PF2**): piso **4,5** texto normal / 3,0 grande — mais duro que o 3,0 das bancadas, porque *folha de decisão é texto de leitura*. Cobaia dupla provada, e na estreia achou **7 defeitos reais** na folha (os `.ok` verdes a 4,23 sobre fundos tingidos); consertados com os pares DO SISTEMA (`feedback-success-text`, `text-muted`): **122 medidos · 0 FAIL**. ✅ **`IC-P1`** — encerrada como **FALSO REGISTRO**: o par real mede 5,62 nos dois temas, a gi2 dá 22·0 em duas rodadas, o arquivo não muda desde a fundação — e a rodada que a registrou usava a gi2 pré-conserto do contrato de alvo, com a sonda de placar do §130.10. ⭐ *Pendência nascida de rodada com instrumento depois consertado se re-mede antes de se trabalhar.* ✅ **`GN-P1`** — cinco instrumentos ancorados (o remendo sai do `.gitignore` junto com o defeito), e os 4 `captura-*.mjs` tinham defeito MAIOR escondido: apontavam para o **Chrome do container do Cowork** — instrumentos mortos com aparência de vivos. Leitura na fixture viva de `07-pecas/`, escrita na área ignorada — ⭐ *evidência não se regenera, se preserva*. ✅ **`SN-P14`** — a MM1-e ganhou **alcance declarado** (%/calc/transform saem nomeados — 7 blocos no acervo que eram silêncio) e o regex de px aprendeu decimal (o antigo lia **"5px" de "10.5px"**: número errado com cara de medido). ⚠ E o conserto quebrou a guarda no caminho — âncora de edição sem a indentação completa des-indentou um `try` e a MM1 passou a medir NADA (0·0·0, exit 0); a §14.9 pegou. ⭐⭐ *Âncora de edição em python COMEÇA no início da linha, com a indentação inteira.* Placar final: 185·0, idêntico, mais a cobaia reprovando como deve. ✅ **`FT-P1`** — nascem os **subsets woff2 da SEED** (`subset-seed/`, fontTools instalado): 25–34 KB/peso, cobertura provada por cmap (JetBrains **50/50 técnico + 86/86 vivos**; Montserrat sem ✓✗ porque **o original não os tem**). A GL1 aprendeu **woff2 via fontTools OPCIONAL** (sem a lib, volta ao [n/a] honesto) — e de brinde passou a MEDIR as 18 históricas. As 4 peças migraram: **~3,1 MB → ~290 KB (10×)**, GL1/MM1/render/fonte-efetiva todos verdes. ✅ **`RL-P1`** — a §5–§6 da ISO 3864-2 lida por inteiro (texto extraído do PDF dele): **só a etiqueta de impedimento está no escopo, e CONFERE** (combination label §6.5: texto abaixo do sinal, painel retangular, severidade opcional ausente). As outras três eram **classificação errada da rodada anterior** — ⭐ *"é etiqueta" não faz de uma peça um safety label: a norma agrupa por FUNÇÃO (comunicar perigo), não por formato*. ✅ **`RD-P1`** — medida com o interruptor `CHROMIUM_DETERMINISTA=1`: quatro placares idênticos → **não estender** (placar de tela é invariante; instrumento de tela consome placar, não PNG). ✅ **`RD-P2`** — **não reproduz**: 12 capturas em 12 processos separados, 12 MD5 idênticos. *O fenômeno sumiu antes do isolamento, e encerrar assim é mais honesto que atribuir causa sem reprodução.* ✅ **`AD-P5`** — a convenção de MOCK DE TELA em `07-pecas/` vira texto (§12.15): `superficie=tela` + `alvo-tela` + `estatuto` + `papel-irmao` — a solução já existia de fato no exemplar. ⏳ **`PT-P2` e `AD-P7` RECLASSIFICADAS**: produção nova e decisão de escopo — fila da onda de aplicações, não de conserto. *Chamar produção nova de pendência faria a lista nunca zerar, e lista que nunca zera deixa de informar.* |
| **5.26** | 2026-08-26 | **`PV-P1` RESOLVIDA — a paridade das bancadas ZERA pela primeira vez (513 PASS · 0 FAIL) — e a fonte canônica consertou metade da `CT-P8` de brinde.** **(a)** o `.selo` do `base-bancada.css` consome os dois `feedback-info` e o `gen-banco-dominio` era **o único dos 9 gerados** sem eles na lista `NOMES` — ⭐ *quem consome CSS compartilhado herda a lista de tokens do compartilhado*. **(b)** o `banco-identidade` consumia `--seed-surface-default`, que não existe; a intenção estava escrita no próprio template (*"superfície neutra com fio de 1px"*) e o consumo passou ao `--seed-surface-raised`, **que já estava na lista** — nada criado (§14.1). ⭐⭐ **E um efeito colateral medido que ninguém previu: a CT1 caiu de 32 para 16 FAIL.** `banco-data` e `tela-shell` passaram a centrar os ícones depois de receber a fonte canônica — **metade da `CT-P8` era a métrica da fonte errada**, não geometria. Restam `banco-navegacao` e `tela-tabela` (8 FAIL cada), que continuam na fila. |
| **5.25** | 2026-08-26 | **A FONTE CANÔNICA PASSA A SER FORÇADA NO ACERVO INTEIRO — `PP-P1-b` resolvida, e o achado era maior que o enunciado.** Veredito dele: *"podemos deixar o plano B, mas temos que forçar sempre a fonte canônica, nem que seja dando opção de instalá-la ou avisando que precisa instalar e dando o link"*. ⭐⭐ **O achado que mudou o escopo:** ZERO dos 42 arquivos de `05-html-de-referencia/` tinha `@font-face` — **até a Montserrat dependia da fonte instalada no sistema**, e funcionava nesta máquina por sorte. O mono rasterizava **Consolas em 26 de 42**. **A solução por camada:** peça impressa **EMBUTE** (comprovante e pasta A4, TP1, ~1,07 MB/peça declarado; assinatura de e-mail fora — cliente de e-mail não carrega @font-face) · bancada/tela ganha **`@font-face` por URL RELATIVA** para os TTF versionados (⭐ *base64 nas 42 custaria ~45 MB para arquivos que nunca saem do repo; URL relativa dá o mesmo por ~1 KB*) · nasce `03-assets/fontes/LEIA-ME.md` com o aviso e o link que ele pediu. **Aplicação pela §14.4:** `base-bancada.css` cobre as 9 bancadas geradas; os 11 templates de tela regenerados; artefato direto só nos sem gerador (o `banco-dataviz-dm` com a nota da `GN-P1`). ⚠ **Dois defeitos pegos no caminho:** sete templates usam `str.format()` e as chaves `{}` do CSS viraram placeholder — ⭐ *bloco inserido em template herda o mecanismo de escape do template*; e o `mede-fonte-efetiva.mjs` chamava nó sem pixel de "recebeu outra" — nasce o veredito `[sem-pixel]`, ⭐ *não-mensurável é veredito próprio, nunca FAIL nem PASS*. **MEDIDO NO FIM (132 arquivos):** 55 aplicam mono → **53 RECEBEM** · 1 `[sem-pixel]` · **1 TROCOU: a assinatura de e-mail, a exceção declarada**. Guardas nas 4 peças regeneradas: MM1 **12·0** · GL1 **4·0** · render **4·0** · PT 0 FAIL; paridade-previews mantém os MESMOS 2 FAIL pré-existentes da `PV-P1` (não aumentou). A §4.5 ganha a nota: **a pilha de reserva deixa de ser o mecanismo primário e vira plano B de verdade**. |
| **5.24** | 2026-08-26 | **AS CINCO COISAS QUE ELE LEVANTOU — quatro resolvidas, e o defeito que ele achou OLHANDO era meu.** ⭐⭐⭐ **`SN-P8` CONSERTADA SEM COMPRAR, e a chave estava nos números da véspera.** Ele decidiu *"nao vamos comprar, use a melhor opcao conforme sua recomendacao"*. A medição já havia separado **dois erros que eu tratava como um**: a razão da caixa batia em ~1,7% — *a silhueta estava certa* — e só a **espessura** errava, em −12,1%. ⭐ *Se o defeito é só espessura, o conserto não é redesenhar: é ENGROSSAR.* Um `stroke` da própria cor **não move nenhum dos 11 vértices** — e é por isso que passou onde reconstruir vértices havia sido reprovado. Medido: espessura **−12,1% → −2,3%**, tinta −16,2% → −5,2%, forma **29,51% → 27,17%** (W012) e **16,39% → 16,16%** (W042). ⚠ **A razão da caixa PIOROU (1,7% → 3,8%) e fica na tabela** — *conserto que melhora quatro colunas e piora uma não é gratuito, e omitir a quinta seria escolher a régua depois de ver o resultado.* ⚠⚠ **E eu quase publiquei duas réguas na mesma tabela:** o instrumento do teste normaliza pelo preto (26,45%) e o do canônico pelo amarelo (29,51%). ⭐⭐ *Comparação só vale DENTRO do mesmo instrumento — número de régua diferente na mesma coluna é comparação falsa, porque quem lê supõe a mesma unidade.* ⚠ **O resíduo está declarado NA PEÇA:** 27,17% segue acima do piso de ruído de ~10%; os dois textos públicos foram reescritos no MESMO commit que mudou o número. ⭐⭐ **A PERGUNTA DELE SOBRE A FONTE EXPÔS O DEFEITO MELHOR QUE EU:** *"porque estamos olhando Consolas x JetBrains Mono, isso é outra fonte sem ser as canônicas?"*. **A JetBrains Mono é canônica desde 2026-07-30 (§4.2), com papel escrito — dados de medição, identificadores, código.** Quem não é do sistema é a **Consolas**, que é o **terceiro item da pilha de reserva** da §4.5. ⭐ *Não estamos escolhendo entre duas fontes: estamos vendo a fonte que o canônico manda perder para o plano B de emergência.* Isso reduz a `PP-P1-b` de "decisão de gosto" a **"quando eu conserto"**. ⚠⚠⚠ **`PF-P2` — ELE ACHOU UM DEFEITO DE LEGIBILIDADE OLHANDO, e o número dá 1,01 de contraste** contra o piso 3,00: cinco `<code>` **brancos sobre branco** na folha que pedia decisão dele. **Causa de classe:** o `code` declarava `background` e **não** `color`, então dentro do bloco escuro herdava tinta clara e mantinha fundo claro. ⭐⭐ *Régua: fundo e tinta se declaram JUNTOS, sempre.* Consertado e medido: **274 elementos, mínimo 4,23, zero abaixo do piso**. ⚠ E a lacuna estrutural fica aberta: **`preview/` é isento das guardas de contraste** — ⭐ *rascunho que serve de base para o decisor decidir não é rascunho*. ✅ **`GR-P10` RESOLVIDA com UMA LINHA, e o quase-erro vale mais que o conserto.** Eu ia copiar 14 arquivos da pasta do Drive antes de ele deletar — até conferir por MD5 e descobrir que **12 de 12 já estavam no repositório**. ⭐⭐⭐ *Antes de resgatar um arquivo, conferir se ele já está salvo em outro lugar: o resgate errado teria plantado aqui dentro a doença que estávamos tirando de lá — duas cópias graváveis do mesmo material.* Placar GR1 **21 · 0 · 7 de 7 alvos** — a guarda roda pela primeira vez neste repositório. ✅ **`GT-P1` — DELEÇÃO LIBERADA, e por MEDIÇÃO.** Conferido por MD5 (135 idênticos · 172 canônicos antigos · 629 de evidência) **e por EXECUÇÃO** (33 instrumentos rodados; 6 morrem por falta de arquivo e **nenhum pela pasta do Drive**). ⭐⭐⭐ **E o caminho ensina: minha primeira análise disse 75 dependências e a segunda disse zero — as duas erradas.** Foi a linha de conferência contra a prova empírica que salvou. *Quando duas análises estáticas seguidas erram, o problema não é o regex — é o método: dependência em runtime se mede EXECUTANDO.* ✅ **`GT-P2` — a subpasta `assistente de email` não tem relação com o projeto:** é pasta de 2026-05-04 de outro projeto, e o DS nasceu dentro dela em 2026-08-22. Renomear é seguro — nenhum arquivo versionado cita o nome e nenhum código depende do caminho. |
| **5.23** | 2026-08-26 | **AS TRÊS DECISÕES DELE, APRESENTADAS COM O VISUAL E O NÚMERO — e uma correção de afirmação falsa que eu escrevi ontem neste arquivo.** ⭐⭐⭐ **A cobrança que gerou esta versão nomeia um erro de leitura da §14.13 que eu vinha repetindo.** Ele disse: *"porque nao me apresentou as peças pra eu ver a diferença, vc disse que muda as peças, mas nao fez nenhum comentário sobre"* e *"eu pedi para ser mais claro no contexto da pergunta, vc precisa me explicar o que precisa e até recomendar algo para eu decidir"*. A §14.13 manda que toda pergunta ao decisor saia com **o custo medido de cada saída** — e eu lia **custo** como **preço**. ⭐ *O custo de uma saída inclui o que ela muda no que já está aprovado, e isso não se enuncia: se olha.* É a terceira vez que ele cobra a mesma classe de falha (antes na `GD-P1`, *"eu nao entendi se aqui é pra eu resolver algo ou só vc"*). ⚠⚠⚠ **A CORREÇÃO: a `PP-P1` da v5.22 afirmava que "número em peça impressa continua em Montserrat com `tabular-nums`", e é FALSO.** O `gen-comprovante-ponto.py:190` pede `var(--seed-font-mono)` e o Chrome rasteriza **Consolas** — fonte da Microsoft que a peça não embute. A regra estava sendo desobedecida em silêncio, e o erro não foi de redação: eu **deduzi** de "a regra manda Montserrat" que "as peças estão em Montserrat". ⭐⭐ *Régua: afirmação sobre o estado de uma peça tem de ser MEDIDA na peça, nunca deduzida da regra* — mesma classe do defeito da §12.19, a placa que afirmava uma conferência que não aconteceu. ⏳ **`PP-P1-b` apresentada com visual:** nasce `ferramentas/mede-fonte-efetiva.mjs`, que mede pelo CDP a família que o navegador **de fato rasterizou** — não a que o CSS pediu. Das 90 peças, **22 aplicam mono a texto: 17 recebem** a JetBrains (todas da era anterior, que a embute) e **5 recebem Consolas** (as vivas). Custo medido: **+9,12% de largura**, **zero transbordos**, ~357 KB por peça. ⭐ *Medir o CSS mede a intenção; medir o pixel mede o resultado* — `getComputedStyle` devolveria 'JetBrains Mono' nas 22, inclusive nas 5 que desenham Consolas. ⚠ **E um erro meu de instrumento pego antes de virar número:** a medição acusou um nó **88,94% mais estreito**, impossível numa monoespaçada; era o `getBoundingClientRect` de Range **colapsando na última linha** em texto que quebra. ⭐ *Número fora do padrão dos irmãos acusa o instrumento antes do objeto* — 56 nós entre +9,01% e +9,13% denunciaram o outlier. ⏳ **`GT-P1` apresentada, e a premissa dele estava invertida:** o Drive não perdeu papel — **ele é o disco onde o repositório mora** (`G:` é File Stream; 399 MB e 1.309 arquivos de `.git` sincronizando). E a pasta de origem da migração **continua gravável** com **172 canônicos DIVERGENTES**, entre eles `marca-seed.md` **v5.11** — *onze versões de atraso num arquivo com o nome certo*, numa casa cuja regra fundadora é que metade das pesquisas é feita por IA. Medido: Drive de **1,8× a 2,6× mais lento**; `fsck` passa nos dois. ⏳ **`FT-P1` REFORMULADA, e a reformulação inverte o pedido:** o `.woff2` leve **já estava no repositório**, escondido num data-URI de peça de gate — 12,6× menor — mas é recorte *latin* e **não tem `≤ ≥ √ Ω Δ ≠ ■ ✓ ✗ ∅ ∞`**. ⭐⭐ *Cobertura contra o acervo de hoje responde "quebra agora?"; contra o repertório da DISCIPLINA responde "vai quebrar?"* — o empate em 86/86 me faria adotar o arquivo leve e plantar um defeito na primeira peça com um ohm. **Ω e Δ são caracteres de trabalho em engenharia elétrica.** E é o segundo achado da revisão da era Cowork: **as 18 peças de gate dela embutem esse recorte incompleto**. ⭐⭐ **`SN-P8` ganha a leitura que muda a conta:** o W042 e o W012 compartilham **o MESMO objeto** de raio (`RAIO_5036`, constante única), então o "+0,5%" do W042 **mede o conjunto e mascara o raio fino**, e **comprar só o W012 conserta os dois**. Recomendação: **CHF 60** (W012 + W042), não CHF 90 — os CHF 30 do P031 pagariam para confirmar o que já bate em +0,6%. O que justifica os CHF 60 é a **linha de picos** do W042, que está numa placa de **arco elétrico** e vem de desenho que a própria fonte não afirma ser oficial. |
| **5.22** | 2026-08-26 | **AS CINCO PONTAS SOLTAS, e a maior delas inverteu uma pendência de meses.** Ele mandou fechar antes da Onda 3: *"é melhor voltarmos corrigindo pontas soltas do que ficar costurando coisas erradas o tempo todo"*. ⭐⭐⭐ **`SN-P8` — o pictograma que o projeto tratava como sólido é o que está 12% errado.** A `SN-P12` perguntava se a linha de picos do W042 (fonte única) estava certa; medido contra a **arte oficial da ISO**, o W042 confere (espessura **+0,5%**, discordância de forma 16,4%), o **P031** confere (anel **+0,6%**, 9,65%) e o **W012 DIVERGE: 12,1% mais fino**, com 29,51% de discordância — **três vezes** o piso de ruído que o P031 estabelece. ⭐ **A causa é erro de raciocínio, não de execução:** o raio foi desenhado da **IEC 60417-5036**, e *reaproveitado não é idêntico* — a ficha do W042 diz "Relâmpago (da ISO 7010-W012)" e o W012, adotado da IEC, não preservou a proporção de traço. A razão da caixa bate em 1,4%: a silhueta é a mesma família, o que difere é a espessura dos membros. ⭐⭐ **E o caminho que destravou isso era gratuito o tempo todo:** a **ISO 3864-3:2024**, na NOTE 2 da Introdução, diz que todos os sinais estão no **OBP da própria ISO**. Uma tentativa anterior tomou **HTTP 403** e o projeto registrou "o catálogo responde 403 a acesso automatizado" — frase certa, conclusão falsa: **não era paywall, era user-agent**. ⭐ *403 não é "não tenho acesso": é "não me identifiquei como quem tem".* ⚠ **O conserto do W012 NÃO foi feito, e o motivo é medido:** reconstruir os vértices do PNG de 200 px foi **tentado e reprovado** — melhora a espessura (9,7% contra 12,1%) e **destrói a forma** (Jaccard cai de 0,74 para 0,56), porque o Douglas-Peucker só fecha em 11 vértices com 5,7% de tolerância. *Trocar erro conhecido de espessura por erro maior de forma é piorar com aparência de conserto.* **Fecha com o vetor oficial: CHF 30,00 por símbolo no OBP** — decisão de gasto dele, e a peça imprime o número. ⭐ **Achado de brinde, e é `shall`:** as fichas oficiais do **W042 e do P031** exigem **sinal de texto suplementar** por falta de dado de teste ISO 9186-1. As duas peças **já cumprem** — mas cumpriam *por acidente de composição*. Agora o requisito tem nome, e **regra com nome sobrevive ao próximo redesenho que "limpa" o texto**. ✅ **`PQ-P2` FEITA:** nasce a **§12.21**, a cartela de identificação de dispositivo DENTRO do quadro (IEC 61439-1 §6.3), 120+40 tiras por A4 no passo de 17,5 mm do trilho DIN. **Três defeitos nela pegos pelo gate visual**, e o primeiro vale régua: `display:flex` num container de **texto corrido** quebra o parágrafo em cada tag inline — o rodapé saiu com "deve", "devem", "devem" em linhas sozinhas e **transbordando a margem**. ✅ **`PP-P1` RESOLVIDA:** JetBrains Mono v2.304 versionada (400/500/700, OFL), com **cobertura de glifo medida antes de declarar** — 1363 glifos, todo o repertório técnico presente, e **exatamente um ausente** (`U+2011`, com zero ocorrências no acervo). ⚠ Isso resolve **disponibilidade, não uso**: passar as peças a consumir `--seed-font-mono` muda a aparência de dez peças aprovadas e **é decisão dele**. ⭐ *Destravar um recurso não autoriza gastá-lo.* ✅ **`GD-P1` RESOLVIDA, e ela era 100% minha** — ele teve de pedir clareza: *"seja mais claro no que disser, eu nao entendi se aqui é pra eu resolver algo ou só vc"*. Nasce `alvosHtml()` no `ambiente.mjs` e **12 instrumentos** passam a usá-lo. O defeito tinha classe própria: **onze guardas descartavam em silêncio** todo argumento que não terminasse em `.html` e caíam na varredura do acervo. ⭐ *Não é quebrar nem dar veredito falso: é **medir outra coisa e não avisar** — o placar sai verdadeiro e a leitura de quem pediu sai falsa.* ✅ **A REVISÃO DA ERA ANTERIOR, que ele pediu antes da Onda 3, tem número — e é boa notícia.** Nasce o `censo-era-cowork.py`: **18 de 88 peças físicas (20%)** são invisíveis para a guarda de token e para o render, e **todas as 18 são evidência de gate histórica** — *nenhuma peça viva está na lista*. ⚠ E o censo **reprovou em bloco duas vezes antes de acertar**: primeiro cobrando de bancada o que só peça deve ter (43 falsos positivos em 54), depois acusando a assinatura de e-mail, cuja isenção **já estava escrita na §12.8**. ⭐⭐ *Caminho não é classificador de tipo: `07-pecas/` guarda peça física, fragmento de e-mail e evidência histórica — três naturezas na mesma pasta.* E o `render-peca.mjs` deixa de reportar **4 FAIL crônicos** e passa a dar-lhes veredito `[hist]`, como a PF-01 já fazia. |
| **5.21** | 2026-08-26 | **O GATE DA ONDA 2: as dez peças entram no canônico (§12.11–§12.20), e a décima não estava no plano.** O veredito dele, verbatim: **"1. todos aprovados"**. *Para quem lê sem ter visto a conversa:* a Onda 2 produziu nove peças em 2026-08-25 — laudo, memorial, checklist, selo de prancha, ART/diário, as-built, crachá, etiqueta e sinalização —, e elas ficaram em `07-pecas/` **sem seção canônica**, porque a regra §0-b não deixa regra de marca nascer sem veredito dele. Esta versão promove as dez. ⭐⭐ **A DÉCIMA nasceu de uma pendência que ele REFORMULOU em vez de responder.** A `SN-P13` perguntava se quadro elétrico isolado precisa de placa de **advertência** própria (medido: exigiria A2 — em A4 paisagem estoura 138 mm, em A3, 59 mm). Ele respondeu outra coisa: *"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."* Nasce a **§12.20 — placa de identificação do quadro**, 100 × 70 mm, com a SEED na condição de **fabricante do conjunto**. *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?".* ⭐ 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"* — **a peça que ela dizia não substituir simplesmente não existia**. ⚠⚠ **E o achado normativo da §12.20 contraria o que o mercado repete.** Lida a **IEC 61439-1 Ed. 2.0 (2011-08), cláusula 6.1**, a etiqueta do conjunto exige **quatro** informações e só quatro: nome/marca do fabricante · designação de tipo ou nº · meio de identificar a data de fabricação · IEC 61439-X. **Tensão, corrente, frequência, Icc e IP não estão nela** — a cláusula 6.2.1 manda esses dados para a **documentação técnica**. Três páginas brasileiras afirmam o contrário e nenhuma cita cláusula. *A norma foi lida; as páginas, não.* A peça traz os dados elétricos assim mesmo, por decisão dele e pela NBR 14039 4.2.5.3, e **imprime na própria placa qual metade é obrigação e qual é escolha** — *peça que mistura o obrigatório com o escolhido, sem dizer qual é qual, transforma decisão nossa em norma alheia.* ⚠⚠⚠ **A CORREÇÃO MAIS SÉRIA DESTA VERSÃO, e ela é na §12.19: a placa de sinalização 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 independentes desmentem: (a) o extrato da leitura da norma tem a seção *"O que foi conferido"* com **duas** entradas, W012 e P031, e cita o W042 na seção de **ações**; (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"** (o texto impresso, o metadado e o `stdout`) 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.* Custo máximo aqui, porque isso sai impresso numa placa de segurança que alguém pode mostrar a um órgão. **`SN-P12` fechada com decisão, não com fonte:** a busca por uma segunda digitalização da linha de picos achou algo pior — a única fonte que existe **se declara** *"similar to recommendation issued in ISO 7010:2019"*, obra própria de terceiro. ⭐ *"Fonte única" quer dizer que ninguém confirmou; isto quer dizer que a própria fonte não afirma ser a oficial.* O W042 **fica**, porque sem ele a placa cita o item 10.7.7.1 b) da NR-10 (choque **e** arco) e cumpre metade — *pictograma aproximado que comunica "arco elétrico" protege mais que a ausência de pictograma*. Fecha com ~5 min de leitura da p. 405, numa assinatura paga **por tempo**, e não foi feito porque ele perguntou em 2026-08-25 se ainda precisava dela e a resposta foi não. |
| **5.20** | 2026-08-25 | **AS DECISÕES DELE SOBRE A ONDA 2, e três delas mudam REGRA e não peça.** ⭐ **NASCE A TERCEIRA VARIANTE DE RODAPÉ, `compacto`** (8 mm, uma linha de contato, **sem grafismo**, área útil de **241 mm**), e com ela a **regra de uso das três** como [LEI]: ofício só para carta e correspondência formal; orçamento para documento técnico e comercial; compacto onde área útil é o recurso escasso. Verbatim dele: *"o foco é otimizar a area útil para caber mais informação com o foco em diminuir o numero de paginas **sempre**"*. Quatro peças da Onda 2 estavam na variante errada, todas com o mesmo argumento plausível — **argumento plausível não vence prioridade declarada**. ⭐ E a variante **nasceu de uma PEÇA, não de uma proposta**: o rodapé de uma linha existia local no diário de obra e ele o reconheceu como padrão (*"é um modelo de rodapé"*). Ganho medido numa pasta real: **1 folha em 6, 16,7% menos papel**. ⭐⭐ **A `MR-P12` DEIXA DE SER BLOQUEIO**, e o que a substitui é uma FRONTEIRA que ele pediu: *"o DS nao seria um template que depois onde fosse ser produzido seria visto as regras do local?"*. **A fronteira NÃO é "produção × design" — é "MUDA O DESENHO × NÃO MUDA"**: a sangria de 3 mm e o piso de 0,25 mm são restrições de produção e **mudam o desenho**, então ficam; tolerância de faca, posição de furo e margem de vinco saem. O DS entrega **o template e a lista declarada de restrições**, nunca um "arquivo de produção". Cinco peças deixam de esperar. ⭐⭐ **A §17.6 ganha a fronteira da peça que NÃO compartilha o campo visual, mas É o campo visual** (veredito dele: *"normal de segurança deve seguir as cores da norma de segurança, nao podemos impor nosso DS sobre isso"*): **em peça de segurança, quando a norma colide com a identidade, a NORMA GANHA**. Na família NR-10 a assinatura é monocromática, pela NR-26 26.1.4. ⚠ E o que NÃO sai está declarado: **tinta de texto fica — reduzir cor não é apagar tinta**. Custo medido: contraste MELHORA (9,37:1 → 21,00:1) e o reconhecimento a distância piora só na placa A3 (1,75 m contra 4,0 m de premissa). |
| **5.19** | 2026-08-25 | **AS DUAS PENDÊNCIAS DE DADO FECHARAM, e as duas confirmaram o canônico.** ✅ **MR-P15: "o contrato está correto"** — três itens separam o Essencial do Premium, não um; a peça já estava assim, então o veredito não mudou artefato, mudou o ESTADO da regra, de divergente para confirmada (*divergência aberta convida a próxima sessão a "consertar" o que está certo*). Fica registrado o que o Essencial NÃO tem — nem suporte por WhatsApp/telefone, nem apoio junto à concessionária —, porque é contraintuitivo: **não se pode presumir que "todo plano tem um canal de suporte"**. ✅ **MR-P14: o endereço de Governador Valadares é Rua Duarte Coelho, 205**, e o canônico estava certo nas DUAS vezes em que foi questionado — primeiro contra o orçamento, depois contra o CONTRATO. Nenhuma peça alterada; a ação virou correção do material em circulação e do contrato que o cliente assina. ⭐ **Régua: decisão tomada com uma evidência merece ser reapresentada quando aparece outra** — e foi por NÃO ter sido alterado "para casar com o material" que o canônico seguiu servindo de referência. |
| **5.18** | 2026-08-25 | **O CONTRATO-MODELO FECHA AS CINCO LACUNAS DO SEED PLUS** e a §12.10 passa a poder afirmar o que antes era proibido: **o escopo da manutenção preventiva** (reaperto de conexões e estruturas · medição de grandezas · limpeza de inversores, disjuntores e DPS · limpeza dos painéis), os prazos de execução (90 dias para a primeira, 30 para data fora da programação, 15 para verificar corretiva), renovação automática, reajuste, e que **é VENDA ANUAL parcelada em 12×, não mensalidade**. As obrigações do contratante entram nas observações — *proposta que esconde a obrigação do cliente cria surpresa na execução, e surpresa chega como reclamação, não como aditivo*. ⭐ **A VALIDADE É POR TIPO DE SERVIÇO**, não constante da empresa: função da volatilidade do custo — SEED Plus 10 dias, energia solar 5, porque o preço do material muda. Pesa mais na §12.7, que serve material E serviço. ⚠ **MR-P15 aberta**: ele afirmou que só a preventiva separa Essencial de Premium, mas o orçamento E o contrato trazem matriz idêntica com **três** itens de diferença — a peça segue os documentos, porque é o contrato que obriga. **§12.9: as três peças antigas do cartão foram removidas** com o ponteiro da §7.4-d repontado ANTES, e as evidências de gate ganharam veredito próprio `[hist]` na PF-01. |
| **5.17** | 2026-08-25 | **§12.10 A PROPOSTA DO SEED PLUS — a peça em que o cliente ESCOLHE.** Três folhas, itens 1 a 10 contínuos, matriz comparativa dos três planos (2 · 4 · 7 itens, do `sobreaseed.md` §6) e 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. Preço **por USINA**, não por cliente. ⚠ A marca de "inclui" é **Unicode explícito com `aria-label`, nunca fonte simbólica**: o orçamento de origem usava Webdings (`a` = ✔, `x` = 🚫), e lidos como letras os dois não dizem nada — marca em fonte simbólica morre em extração de texto e em leitor de tela. ⚠ `table-layout:fixed` é obrigatório na matriz: no layout automático o `width` de célula é SUGESTÃO, e o navegador deu à coluna de descrição menos espaço que às de marca (48/41/41/41 mm), levando cada linha a 29 mm. **§12.4 ganha a trava 7: nenhuma marcação aparece como texto na peça** (`guarda-escape.py`, ES-01/ES-02) — três ocorrências num dia, todas por o contrato de escape não estar declarado, e uma delas estourou uma folha em 167,7 mm; ⭐ `isinstance(str)` NÃO é teste de "precisa escapar". |
| **5.16** | 2026-08-25 | **A RODADA DE CORREÇÕES DELE SOBRE A ONDA 1 — e ela rendeu uma LEI NOVA.** ⭐ **§7.4-f: o grafismo de linha exige span ≥ 125 mm** para cumprir o piso de 0,25 mm, medido em nove spans (78 mm → 0,157 · 124 mm → 0,249 · **125 mm → 0,251** · 170 mm → 0,342). Altura do divisor e espessura do traço são a MESMA grandeza, então não há como encolher um sem o outro — peça menor que 125 mm SANGRA o grafismo ou não o usa. **§12.9 CARTÃO 90×50 refeito do zero** por veredito dele (*"nada é definitivo. se podemos melhorar, vamos melhorar"*), e o erro que o fundou vale a lei: medi 0,250 mm nos arquivos antigos e concluí escala 1:1, mas eles usam OUTRA cena do grafismo — ⭐ **medir o artefato antigo não substitui medir o INSTRUMENTO que vai gerar o novo**. **§12.7 a proposta virou UM documento numerado de ponta a ponta** (itens 1 a 15 atravessando as duas partes, folhas 1 a 4 "de [N]", total como placeholder porque depende do preenchimento), **sem duplicação** entre as capas, com o RESUMO DO INVESTIMENTO e os OPCIONAIS subindo para a capa comercial e o PRAZO vindo da técnica para lá (art. 40 do CDC exige datas no ORÇAMENTO), e **sem campo de assinatura na técnica** — assinar duas vezes o mesmo negócio cria a dúvida de qual das duas obriga. **§12.5 a grade de soluções da pasta refeita**: cinco filetes curtos liam como cabeçalho de tabela; entram rótulo, UM fio contínuo e numeração 01–05. ⚠ E a régua do `<br>` pegou o próprio autor — o comentário que eu escrevi ao lado dela afirmava uma largura que eu NÃO tinha medido. |
| **5.15** | 2026-08-24 | **A ONDA 1 DA F8 FECHA COM SETE PEÇAS — §12.5 a §12.8, todas `estável`.** **§12.5 PASTA A4**: capa de uma face, duas variantes que exercitam a matriz §5.1 (branco → logo principal; `brand-deep` → mono-negativo), logo ao centro pela §5.3; ⚠ NÃO é o arquivo de produção, porque a MR-P12 (margem de vinco) está aberta, e ⚠ NÃO é o `F6-pasta-A4.html`, que é evidência do gate do GRAFISMO em razão A4. **§12.6 ENVELOPE** (ofício 229×114 pela ABNT NBR 13314, saco A4 240×340 de mercado e declarado `[não conferido]`): ⭐ a regra que manda na peça não é da marca, é dos CORREIOS — **20 mm na base da frente são da máquina de triagem** (guia CEPNet, ÁREA 4), e a serra para a 23 mm; três faces por formato, porque guia impressa em envelope é defeito de produção. **§12.7 PROPOSTA**: modelo PADRÃO e FLEXÍVEL fixado por ele (só material · só serviço · ambos; fotovoltaico e SEED Plus fora), DOIS documentos (técnica sem preço, comercial que não vale isolada), PRAZO como bloco próprio pelo **art. 40 do CDC**, e a moldura IMPORTADA do `gen-timbrado.py` em vez de copiada — o que se provou no mesmo dia, quando a correção PP-P2 propagou sozinha. **§12.8 ASSINATURA DE E-MAIL**, que NÃO é peça física e por isso não declara `alvo-fisico`: ela DERIVA do `ea-assinatura.html` com prova de derivação byte a byte, e a folha de gate mostra os quatro estados reais (com Montserrat, na pilha de reserva, com imagem bloqueada, a 320 px). ⚠ **§12.4 ganha a regra 7: a evidência tem de ser FRESCA e isso se prova** — quatro peças ficaram com o PNG de um commit anterior ao do próprio HTML, e nenhum instrumento olhava para essa relação. |
| **5.14** | 2026-08-24 | **A CAMADA FÍSICA GANHA AS TRÊS PRIMEIRAS PEÇAS DA F8 — §12.1, §12.2 e §12.3, todas `estável`, com gerador, mock renderizado e regeneração byte-idêntica.** **§12.1 PLACA DE OBRA [LEI]** (Lei 5.194/66 art. 16 + Res. CONFEA 407/1996 — a lei fixa o CONTEÚDO e não a FORMA, e é isso que faz dela peça do DS): dois tamanhos, campos como placeholder, e ⚠ **a MR-P11 morde aqui de um jeito não óbvio — o `simbolo-principal.svg` CARREGA o amarelo, então placa de canteiro usa o MONO-NEGATIVO**; a violação estaria dentro do asset oficial. **§12.2 TIMBRADO A4**, cujo entregável é a **ÁREA ÚTIL: 170 × 205 mm a partir de (20, 44)**, impressa no próprio arquivo para a proposta e o laudo LEREM em vez de redescobrir — o plano fixa que os três nascem dele. **§12.3 COMPROVANTE DE PONTO** (fecha a PT-P1): Portaria MTP 671/2021, REP-P, NSR, PAdES; a peça mais sensível do acervo em LGPD, porque a norma exige nome e PIS. **§12.4** fixa o que passa a valer para toda peça física — incluindo a régua nova: ⭐ **peça prova que consome token MEDINDO no navegador, nunca conferindo que a string está no arquivo** (a `guarda-peca-token.mjs` nasce de um `:root` aninhado que fez uma peça inteira renderizar SEM NENHUM token, parecendo certa). |
| **5.13** | 2026-08-22 | **A MR-P11 RESOLVE — saída (a) aprovada por veredito** (*"essa está aprovada, pode propagar"*): **o amarelo de marca não entra em peça instalada em ambiente com sinalização de segurança; nessas peças a assinatura é turquesa e branco**; papelaria, escritório e digital mantêm o acento único sem restrição. Uma regra, uma fronteira. Propagação feita com verificação de conformidade contra o que foi construído depois da recomendação (ordem dele na mesma data): único amarelo novo desde então é o marcador da v5.12, elemento de papelaria/digital, fora do escopo — sem conflito. Desbloqueia as peças 2.9 (sinalização) e 3.2 (uniforme/EPI) do `plano-producao-pecas.md`; a placa de obra (1.1) já era desenhada sem amarelo e fica correta. Nenhum hex muda. |
| **5.12** | 2026-08-22 | **Os três usos INTERNOS do grafismo ganham geometria canônica e a pendência §17.3 FECHA.** Nasce `06-validacao/geradores/gen-detalhe.py` (traçado extraído do `gen-zero-formatos.py` **por AST**, nunca redigitado) e os 5 assets de referência em `03-assets/grafismos/`. **TEXTURA** = a cena Z3 inteira a ≤10% — **supersede** as "2–4 linhas paralelas" da §7.6, por veredito: *"vc tem que criar essas linhas igual as do rodapé que já estão aprovadas"* (paralelismo é ritmo; serra é profundidade, §7.1); reclassificada como uso interno do SERRA-CENA. **DIVISOR** = a imagem do rodapé repetida emendada com **corte no limite direito** (verbatim: *"a quantidade de cópias que precisar em sequência emendadas, e o que passar do limite do lado direito vc corta"*); altura natural = largura/12,7; piso de leitura = **§7.2** (regra já feita, escolhida por ele sobre um piso novo em px); sem teto; escala proporcional (§7.4). A **EMENDA** é a §7.3 aplicada: toque exato **natural** (a máscara de oclusão aprovada corta a ponta do FUNDO na crista da cópia seguinte) + mergulho da ponta esquerda abaixo da faixa, na zona que a moldura já cortava. **MARCADOR** = o risco aprovado fica **intocado, inclusive o amarelo**: quando o "apenas o turquesa" da Fase 2 colidiu com o §78.3-6, o veredito foi *"prevalece o veredito que vc achou já estabelecido"*. **Sangria por tipo de arquivo** (§7.4-e): o transbordo natural de 6% cobre os 36px em todo formato impresso (cartão 63,78px · A4 148,80px) — nenhum desenho novo. **Alternativas descartadas, cada uma com o número que a matou**: 4 políticas paramétricas de amplitude (todas trocavam n=7 por 3 — redesenhavam a curva; a lei do §76.4 já respondia), duas linhas contínuas defasadas (só 17,5% de oclusão real — fita trançada), cadeia de arcos (fatiava o desenho), cena reduzida (o piso de traço da serra exige F≥58,64 — "profundidade custa altura"), cópias com profundidade alternada (linha listrada; §7.2 exclui oclusão do regime), descida-A construída (a natural já existia; construída abria talho ou nó). **Lição de instrumento**: a composição roda PURA sobre o desenho intocado — modificar `fundo_v` antes de `compoe()` desloca os retângulos de supressão de fragmento e o corte cai no meio do ar. Nenhum hex muda; nenhum traçado aprovado muda. |
| **5.11** | 2026-08-22 | **A §7.4-e ganha a regra do ARQUIVO SOB DEMANDA**, por veredito dele: *"sobre a producao, apenas o mock, quando for ter a producao de alguma peça especifica, ai sim trabalhamos o arquivo de producao para aquela demanda"*. O entregável **padrão** de toda peça passa a ser o **MOCK**; o arquivo com sangria (e a faca, quando houver dobra) só é feito **quando existe a compra**. Motivo: arquivo de produção feito antes da demanda **envelhece** — a gráfica escolhida pode pedir 5 mm em vez de 3, ou faca diferente, e o arquivo pronto vira arquivo errado com aparência de pronto. Nenhum valor muda; o que muda é **quando** o arquivo nasce. |
| **5.10** | 2026-08-22 | **Nasce a §7.4-e: SANGRIA de 3 mm e MARGEM DE SEGURANÇA de 3 mm em peça impressa**, por veredito dele: *"a sangria vc tem que usar o que o mercado indica nas suas pesquisas. acredito que 3+3"*. E o **MÉTODO entra como regra**, também dele: *"vc tem que deixar o desenho dentro da area real, e a parte da sangria vc cresce o desenho"* — a composição é definida para a área de corte e **não se mexe**; a sangria é **crescimento para fora**. Consequência formal: passam a existir **dois tipos de arquivo** — **GATE** (tamanho do corte, é o que a GR1 mede e o que ele aprova) e **PRODUÇÃO** (corte + 3 mm) —, cada um declarando o próprio papel no artefato (`<meta name="papel">`, `corte-px`, `sangria`). Medido: a serra **toca 3 bordas**, logo sangria é obrigatória; e o conteúdo do cartão está a **4,24 mm** do corte, folga de 1,24 mm contra a margem de 3 mm — **o layout aprovado cabe sem mexer**. Sangria em px arredonda **para cima** (36 px = 3,05 mm), mesma regra do piso de traço. A guarda MM1 ganha as cláusulas **MM1-d** e **MM1-e**. Fica aberta a **`MR-P12`**: peça com dobra/vinco tem margem própria e a pasta A4 com aba não existe como arquivo de produção. Nenhum hex muda, nenhum vetor muda, nenhuma composição muda. |
| **5.9** | 2026-08-22 | **A §12 ganha o INVENTÁRIO AMPLIADO e a §17 ganha a pendência `MR-P11`.** O inventário de peças físicas da §12 era o do Manual 2018 e **não continha uma única peça específica de engenharia elétrica** — faltava a classe **regulada por lei e por norma**. O levantamento completo (36 peças em 5 famílias, com fonte por peça regulada) passa a viver em `inventario-pecas-ds.md` v1.0, estado `proposta`. Peças reguladas identificadas: **placa de obra** (`Lei nº 5.194/1966, Art. 16` + `Resolução CONFEA nº 407/1996` — conteúdo obrigatório, **forma livre**, logo é peça legítima de DS) e **sinalização de segurança elétrica** (**NR-10 item 10.10.1**, sete situações; cores pela **NR-26 → ABNT NBR 7195**). Nasce a pendência **MR-P11**: o amarelo de marca `#FAD61D` colide em SIGNIFICADO com o amarelo normativo de advertência da NBR 7195 em ambiente industrial. Nenhum hex muda, nenhuma regra é revogada — o que entra é o registro do conflito e o apontamento do inventário. |
| **5.8** | 2026-08-22 | **Esclarecimento normativo na §7.4-c: o piso de 0,25 mm não pode ser violado pelo ARREDONDAMENTO.** Ao aplicar o fator de escala, o menor peso arredonda para CIMA. Motivo medido: na pasta A4 (11,80952 px/mm) o arredondamento normal devolvia 0,24980 mm — 0,0002 mm abaixo do canon, e a guarda nova pegou. A §7.4-c passa a nomear **DOIS** instrumentos com papéis distintos: a **guarda `guarda-piso-mm.py` (contrato MM1, alvo de pasta)**, que julga contra o piso do canon, e o **diagnóstico `mede-traco-mm.py`**, que compara com pisos de mercado. E fica escrito **como uma peça declara que é impressa**: `<meta name="alvo-fisico">` no próprio artefato — nunca por nome de arquivo; peça sem a declaração sai `[n/a]` nomeado. Nenhum hex muda, nenhum vetor muda, nenhum teto muda. |
| **5.7** | 2026-08-22 | **Nasce a §7.4-d: a medida física do cartão é `90×50 mm`, o padrão BRASILEIRO.** Veredito do Rafael, verbatim: *"escolho B / qualquer ajuste é minimo se precisar fazer, e o desenho se ajusta hoje proporcionalmente"*. **SUPERSEDE os 89×51 mm**, que eram `3,5×2 polegadas` — medida de EUA/Canadá que entrou como **default de ferramenta, nunca como decisão de marca** (não há registro de escolha). A §7.4 ganha o teto do novo formato (**84px de 590 = 14,2%**) e a linha antiga fica marcada como **HERDADA**, mantida só porque o acervo dos 7 formatos ainda está na razão 1,745. Medido: o piso de 0,25 mm da §7.4-c **atravessa a troca de formato** (0,250 mm nos três formatos testados), o verso reverso segue PASS, GR1 nas peças largas **15·0·0** e o acervo dos 7 formatos **21·0·0** — nenhuma regressão. Nenhum hex muda, nenhum vetor muda. Pendência nova **MR-P10: SANGRIA** — o verso é fundo cheio e nenhuma peça do projeto tem área além do corte. |
| **5.6** | 2026-08-22 | **Nasce a §7.4-c: PISO DE TRAÇO EM MILÍMETROS para peça impressa.** Veredito do Rafael, verbatim: *"saída B — piso de 0,25 mm por ESCALA, e só para peça IMPRESSA"*. Piso **0,25 mm**, aplicado por **ESCALA** (fator único em todos os planos), **só em peça com alvo físico declarado**. Motivo medido: a lei do traço da §7.4 é em px, logo o traço físico dependia da resolução de exportação; o verso do cartão passava o piso digital reverso por 0,004 mm (2% de margem) e agora tem 42%. Escala e não grampo porque grampo achata 4 pesos em 2 e a hierarquia de peso é uma das três condições do §7.1. Escopo declarado: peça de TELA fica de fora, e o marcador de seção (risco amarelo, 0,170 mm) fica intocado até veredito próprio. Nenhum hex muda; nenhuma regra da v5.0 é revogada. |
| **5.5** | 2026-08-21 | **Nasce a §7.4-b: o teto do grafismo no TOPO é de LARGURA, não de altura.** Veredito do Rafael, verbatim: *"o ponto é medir a aplicação na largura se atende ao desenho selecionado para o topo, a altura nao importa"*. Teto: **`F ≤ w / 6,5625`**, razão derivada da própria peça aprovada (w=420, F=64). **SUPERSEDE** a leitura de que o topo respondia a 15,24% da altura e só na razão 1:1 — aquele número passa a ser descrição da peça, não o teto, e peça larga deixa de precisar de veredito novo. Escopo declarado: **só o topo**; o rodapé segue com os tetos por formato da §7.4. Nenhum hex muda, nenhum vetor muda, nenhuma regra da v5.0 é revogada. |
| **5.4** | 2026-08-21 | **A §7 (Grafismo v2) é reescrita: nascem os DOIS REGIMES — `DETALHE DE LINHA` (o uso original, teto de ~8%) e `SERRA-CENA` (3–4 planos com cruzamento, oclusão e hierarquia de peso, com tetos POR FORMATO).** Nenhum hex muda, nenhum vetor muda, nenhuma regra da v5.0 é revogada — o teto de ~8% continua valendo para o regime de detalhe e o teto de área ≤10% continua valendo para os dois. Novidades: **§7.1** a ORIGEM do desenho (as ondas são montanhas — dita pelo Rafael em 2026-08-20 e que não estava escrita em documento nenhum) mais as três condições de leitura de plano e o critério do MOVIMENTO · **§7.2** os dois regimes, com o número que os separa (a serra precisa de ~15% da altura para LER como serra; abaixo disso ela não fica discreta, desaparece) · **§7.3** os DOIS MODELOS de serra-cena com **regras INDEPENDENTES** — arcos no RODAPÉ (PADRÃO, toque exato) e montanha no TOPO (OPÇÃO, oclusão com folga), por veredito dele: *"considere que o topo segue uma regra e o rodapé outra regra"* · **§7.4** a LEI DA ESCALA (forma constante em unidades de faixa, razão natural w/F = 12,7) e os tetos aprovados por formato (cartão 13,8% · banner 11,8% · capa 15,7% · topo 15,24%) · **§7.5** a cor do grafismo só em stops da rampa canônica, com o precedente registrado do hex inventado que foi retirado por ordem dele (`#0A6B60` → `#006C62`, ΔE76 = 1,03) e a **REGRA §0-b** · **§7.6** tabela consolidada de usos · **§7.7** os vetores da serra-cena existem como GERADORES, o que muda o estado da pendência §17.3. Especificação completa e medições em `seed-componentes.md` §76; registro da rodada em `validacao/MANIFESTO.md` §103. |
| **5.3** | 2026-08-14 | **A §3.6-b é promovida a `estável`** pelo gate visual do Rafael sobre o `seed-composicao-preview.html` v0.1 (veredito G3: as seis posições da paleta de entidade aprovadas; veredito G4, na mesma sessão: marcador de "agora" em `turquesa-600` fixo nos dois temas — registrado no CP24 do `seed-composicao.md` v1.1, terceiro membro da classe invariante de tema). Nenhum hex muda. |
| **5.2** | 2026-08-14 | **Nasce a §3.6-b — REGRA DE ADMISSÃO DE COR DE ENTIDADE (`rascunho`, gate visual pendente; SUP-5 do confronto de referências).** Nenhum hex muda, nenhum vetor muda. Cor de entidade sai de paleta FECHADA (decisão Q1) e só é admitida passando 4,5:1 com uma de duas tintas declaradas (`entity-ink-dark` = cinza-900 · `entity-ink-light` = branco) — verificação estática na definição da paleta, nunca em render. Medição de 120 pares (6 famílias × 10 stops × 2 tintas): stops 50–400 admitem a tinta escura (pior 5,03) · **stop 500 de QUALQUER família é inadmissível** (zona de cruzamento, pior 4,30) · stops 600–900 admitem branco (pior 4,60). A paleta de 6 posições proposta e o consumo em composição vivem no `seed-composicao.md` §7 (novo 12º canônico da Fase 2). Precedente interno: a regra do amarelo do §3.6 já era tinta-por-cor. |
| **5.1** | 2026-08-13 | **Registro da rodada do §48 Painel, sem mudança de paleta nem de logo — os 8 hex canônicos e os vetores seguem intocados.** Três seções novas: **§3.5-b** — a régua de ação foi **CONFIRMADA**; uma proposta de ação em `azul-800` viveu num preview, conflitava com o §3.5 e foi **retirada no mesmo dia**, sem nunca chegar ao canônico (a camada de tokens sempre teve `action-primary = #098475`). **§3.5-c** — nasce a **ÂNCORA DE ÊNFASE**: uma por página, **cromática e não escura**, base `turquesa-400` com tinta única `turquesa-900`, anel `turquesa-600` e véu de luz a 35%; com as três alternativas reprovadas e seus números. **§3.5-d** — a **TINTA DE TEXTO** passa à família da marca, **só o texto**: bordas e superfícies ficam neutras e a página branca, como faz a referência medida, e porque esverdear a superfície roubaria o contraste de saturação da âncora (medido: 2,71 → 2,21). Valores e medições no `seed-tokens.md` v1.9. |
| **5.0** | 2026-07-30 | **Rebranding de aplicação (Fase 2 do DS v2).** Hex e vetores intactos. Novidades: fundamento com 3 princípios (§2), Pantone/CMYK resgatados + errata azul-claro (§3.1), integração com tokens v1.1 (§3.2, §11), lei 70/20/10 (§3.3), hierarquia dos amarelos (§3.4), papel do azul (§3.5), contraste medido (§3.6), tipografia 2 famílias com JetBrains Mono e aposentadoria de Indie Flower/Neo Tech (§4), logo responsivo + matriz de posição (§5.2–5.3), EEny desacoplado com parcimônia (§6), Grafismo v2 de linhas (§7), fotografia real (§8), ilustração linha-primeiro (§9), linguagem editorial (§10), camada física (§12), aplicações atualizadas (§13), supersedes consolidados (§16). Morte do `erp-seed-design.md`. Base: auditoria do Manual 2018 + pesquisa de referência (Carbon, Polaris, Atlassian, WGSN) + decisões aprovadas pelo Rafael na conversa do rebranding. **Revisão por pesquisa aplicada pré-publicação (2026-07-30):** kit de favicon padrão 2026 (§5.2), esclarecimentos de aplicação da lei 70/20/10 (§3.3), papel social do EEny recalibrado — de restritivo demais para ativo estratégico com regras (§6), legibilidade quantitativa de frota (§12), clear space como razão (§5.5), pendências 5 (§17). **Decisões de 2026-07-31:** camada expressiva Montserrat 800/900 para display de marketing e Caveat como fonte celebratória oficial (§4.3), escolhida em comparativo real vs. Shantell Sans e Kalam — fora dos tokens por decisão (garante a fronteira de UI). |
| 4.1 | 2026-07-17 | Espelho público dos assets no Drive (22 FILE_IDs) com padrão de embed e fallback. |
| 4.0 | 2026-07-17 | Reescopagem: arquivo exclusivamente visual; institucional movido ao `sobreaseed.md`; correção de endereço; fronteiras formais; regra das 8 cores; registro do `#0d8f82`. |
| 3.2 | 2026-05-09 | Assets reais de `02_assets/` formalizados; variantes 9→14. |
| 3.1 | 2026-05-09 | Expansão digital: tokens, escala, spacing, grid, foto/ilustração, componentes. |
| 3.0 | 2026 | Migração para Cowork, conversão para markdown estruturado. |