# SEED engenharia — Sistema de E-mail v0.12

> **Estado:** **FASE 4 COMPLETA — os 6 sub-blocos `estável`** (EM fundamento técnico ·
> EL sistema de layout · EC componentes · ET transacionais do ERP · EN newsletter/comercial ·
> EA assinatura corporativa), todos promovidos pelo gate visual do Rafael entre 2026-08-07
> e 2026-08-08, após validação na matriz de 3 clientes reais (§7.1).
> **Data:** 2026-08-08 · **Fase:** 4 do rebranding do Design System v2 (fechada no marco v1.5)
> **Escopo acumulado do arquivo:** decisões EM0–EM15 e EL1–EL10 (§§2–6) · régua de validação
> e ciclo de gate (§7) · sub-blocos EC (§8-B), ET (§8-C), EA (§8-D) e EN (§8-E) · supersedes
> formais (§9). Artefatos canônicos vigentes: `seed-email-base.html` v0.4 ·
> `seed-email-componentes.html` v0.3 · 3 transacionais v0.2 · newsletter v3.2 · comercial v2 ·
> assinatura EA v0.2. Réguas de guarda permanentes: **GV1–GV8**. Balanço da fase: 11 defeitos
> reais do gate visual, 11 corrigidos, zero visível à automação antes do olho humano.

---

## 0. Contexto para quem nunca viu a conversa que gerou este arquivo

A **SEED engenharia** é um HUB de engenharia elétrica que atua em Minas Gerais, Espírito
Santo e Bahia desde 2016. Cinco pilares: energia solar fotovoltaica, subestações de média
tensão, grupos geradores (GMG), projetos elétricos e consultorias. Ferramenta proprietária
da casa: o **Diagnóstico 360°**.

O **Design System v2 (DS v2)** é o sistema canônico permanente que serve todos os outputs
da empresa: o ERP SEED, o sistema de chat, sistemas digitais futuros, o site institucional,
e-mail, marketing, documentos técnicos de engenharia e colateral físico. Ele está
organizado em fases:

| Fase | Objeto | Estado |
|---|---|---|
| 1 | Tokens (`seed-tokens.md` v1.2) | ✅ concluída |
| 2 | Marca (`marca-seed.md` v5.0) | ✅ concluída |
| 3 | Componentes (`seed-componentes.md` v0.47 — 44 componentes em 7 blocos) | ✅ concluída |
| **4** | **Sistema de e-mail — este arquivo** | ✅ concluída (6/6 sub-blocos `estável`, marco v1.5) |

**Este arquivo é a fonte de verdade do e-mail SEED.** Ele nasce como arquivo canônico
próprio, e não como uma seção do `seed-componentes.md`, por uma razão estrutural
explicada em EM0 abaixo.

**Convenção de leitura.** Cada decisão tem um código de duas letras + número (`EM1`, `EL3`).
Toda decisão traz **racional** e **alternativas descartadas** — é regra do projeto: decisão
sem alternativa descartada registrada não é decisão, é preferência. Quando um conteúdo
substitui outro, há **supersede formal** (seção 9), nunca nota solta.

---

## 1. A tese: e-mail é outro runtime, não outra tela

A cadeia de três camadas do DS v2 é:

```
1. PRIMITIVOS   --seed-turquesa-600      valor bruto
       ↓
2. SEMÂNTICOS   --seed-action-primary    intenção de uso
       ↓
3. COMPONENTE   --seed-button-primary-bg exceção local
```

**Essa cadeia para antes do e-mail.** Não por escolha de estilo, mas por impossibilidade
técnica: CSS custom properties não são suportadas em Gmail, Outlook e Yahoo — e no Gmail o
caso é pior que ausência simples, porque ele aceita a função `var()` mas ignora a
*declaração* da variável, o que a torna inútil.

A consequência prática é que **nenhuma linha de CSS dos 44 componentes da Fase 3 é
reaproveitável em e-mail.** O que se herda é conceitual, e isso é bastante:

| Herda-se | Não se herda |
|---|---|
| Taxonomia de severidade (sucesso, atenção, erro, informação) | Qualquer regra CSS |
| Microcopy e tom de voz | Flexbox, grid, position |
| Hierarquia de ação (primária, secundária, terciária) | `var(--seed-*)` |
| Régua de acessibilidade e de contraste medido | Ícones em SVG |
| Lei 70/20/10 da marca | Dark mode nativo com par light/dark |

Registrar isso aqui evita a expectativa — razoável, mas errada — de que a Fase 4 seria
"portar os componentes para e-mail". Ela é **reimplementação** com herança conceitual.

---

## 2. EM0 — por que arquivo canônico próprio

**Decisão:** o sistema de e-mail vive em `seed-email.md`, arquivo canônico novo. O Project
Knowledge passa de 7 para 8 arquivos canônicos.

**Racional:** a regra-mãe do `seed-componentes.md` é "componente consome semântico, nunca
hex". O e-mail consome hex literal por impossibilidade técnica. Hospedar as duas coisas no
mesmo arquivo criaria uma exceção que contamina a leitura de todo o resto — qualquer leitor
futuro passaria a duvidar da regra. Além disso o arquivo já tem 2.372 linhas.

**Alternativas descartadas:**
- *Seção nova no `seed-componentes.md`* — rejeitada pelo conflito de regra acima.
- *Viver nas skills `seed-ds-*`* — rejeitada porque skill é **consumidora** do canônico,
  nunca a fonte. Inverter isso quebraria a cadeia de propagação do projeto.

**Precedente interno:** a decisão NM5 do §45 (iconografia) já estabeleceu esse padrão para
outro objeto — quando um domínio cresce a ponto de ter regra própria, nasce arquivo próprio
por supersede formal.

---

## 3. EM2 — matriz de suporte em três níveis

Prometer suporte universal é o que produz template inflado e impossível de auditar.
Declarar o nível torna a degradação uma **decisão**, não um acidente.

| Nível | Clientes | Compromisso |
|---|---|---|
| **T1 — paridade visual** | Gmail (web, Android, iOS), Outlook.com web, Apple Mail (iOS, macOS) | O e-mail aparece como desenhado |
| **T2 — funcional degradado** | Outlook desktop Windows (clássico, motor Word) e novo Outlook | Toda informação legível e toda ação clicável; espaçamento e refinamento podem cair |
| **T3 — legível** | Qualquer outro cliente | O conteúdo é compreensível, ainda que sem estilo |

**Alternativas descartadas:**
- *Suporte universal prometido* — impossível de verificar, portanto impossível de manter.
- *Só Gmail + Outlook* — ignoraria o Apple Mail, que é o único cliente que respeita CSS
  autoral e por isso serve de "controle" no diagnóstico: se quebra nele, o defeito é nosso.

**Fato apurado sobre o ambiente de teste da SEED (2026-08-07):** a empresa opera Google
Workspace, acessa e-mail por Gmail web, e os celulares da equipe são majoritariamente
Android. Existe **Outlook 2024 clássico** instalado e disponível para teste — o que garante
cobertura de T2 sem ferramenta paga. Ver seção 7.

---

## 4. EM1 — camada de tokens resolvidos

> ### ERRATA v0.12 — A TINTA DE TEXTO MIGRA PARA A FAMÍLIA DA MARCA (2026-08-14)
>
> **O que muda:** os dois hex de tinta resolvidos migram, em **185 declarações `color:`** nos **14
> artefatos** do sistema: `#242E34` → **`#0B3330`** (text-primary) e `#4D606C` → **`#2F5A54`**
> (text-secondary). Nenhuma borda, nenhum fundo, nenhum outro papel: **100% das ocorrências estavam
> em contexto `color:`**, verificado antes da edição.
>
> **Por que era obrigatório.** A camada de tokens foi a **v1.9** dos gêmeos em 2026-08-13, levando a
> tinta de texto para a família turquesa da marca — mas o e-mail **resolve token em hex literal na
> autoria** (é o EM1: cliente de e-mail não tem custom property). Resultado: o sistema passou a ter
> **duas tintas** — produto digital em `#0B3330` e e-mail em `#242E34`. O CHECKPOINT do marco v2.0
> registrou isso como **risco R2**, com o argumento: *backlog é o que espera a vez; risco é o que o
> cliente vê* — e o e-mail é justamente o artefato que **sai da empresa**.
>
> **Medição antes da edição, contra as três superfícies em uso no sistema:**
>
> | Sobre | `text-primary` | `text-secondary` |
> |---|---|---|
> | `#FFFFFF` | 13,86 → **13,72** | 6,55 → **7,75** (+18%) |
> | `#F2F6F9` | 12,75 → **12,63** | 6,03 → **7,13** (+18%) |
> | `#ECF4FC` | 12,48 → **12,36** | 5,90 → **6,98** (+18%) |
>
> O primário perde 0,14 e segue quase quatro vezes acima do piso; **o secundário ganha 18% em todas
> as superfícies**. Nenhum par se aproxima do limite.
>
> **Validação:** `contraste-email.py` **14 pares com piso · 0 reprovações** · `suite-email.mjs`
> **23/23 em cada um dos 14 artefatos**.
>
> **O que esta errata NÃO faz:** não toca `#617683` (cinza-600), usado em 23 pontos do sistema. Ele
> **não é** o `text-muted` do gêmeo (que era `#788F9D` e foi para `#40706A`), e migrá-lo por
> semelhança seria adivinhar papel. **Fica declarado como pendência**, não como omissão.
>
> **Limite que permanece, e ele não é resolvível aqui:** a inversão forçada de dark mode do Gmail
> app e do Outlook Windows altera essas cores **fora do nosso controle** (EM3). O par autoral está
> medido; o resultado invertido é do **gate visual humano** (§7.1).

## 4. EM1 — camada de tokens resolvidos

**Decisão:** o e-mail consome **hex literal**, resolvido a partir do `seed-tokens.md` v1.2
por script, publicado como `seed-tokens-email.json`. Nenhum `var()` no output. Token
consumido sem definição continua sendo bug de build, reprovado na suíte.

**Racional:** ver seção 1. É o padrão da indústria — provedores de e-mail mantêm
transformadores que substituem variáveis pelos valores justamente para ampliar a
compatibilidade.

**Alternativas descartadas:**
- *`var()` com valor de fallback* — o Gmail não declara a variável, então o resultado é
  imprevisível entre clientes; um fallback que funciona em teste pode falhar em produção.
- *Paleta duplicada e mantida à mão* — produz deriva garantida entre o e-mail e o resto do
  sistema, que é exatamente o problema que o DS existe para matar.

### 4.1 Paleta resolvida (subconjunto e-mail)

Todos os hex vêm das rampas do `seed-tokens.md` v1.2 §2.1. Nenhum foi inventado aqui.

| Papel no e-mail | Hex | Origem no token |
|---|---|---|
| Canvas (fundo externo da mensagem) | `#F2F6F9` | cinza-50 |
| Superfície (fundo do card) | `#FFFFFF` | branco |
| Marca profunda (cabeçalho/rodapé) | `#005048` | turquesa-800 |
| Marca alternativa | `#006C62` | turquesa-700 |
| Ação primária (fundo do botão) | `#098475` | turquesa-600 |
| Texto primário | `#242E34` | cinza-900 |
| Texto secundário | `#4D606C` | cinza-700 |
| Texto sutil (dentro do card) | `#617683` | cinza-600 |
| Link | `#006C62` | turquesa-700 |
| Divisor / borda | `#C8D6DF` | cinza-200 |
| Sucesso — texto / fundo | `#005048` / `#E8FBF7` | turquesa-800 / turquesa-50 |
| Erro — texto / fundo | `#A5272A` / `#FFF2F1` | vermelho-700 / vermelho-50 |
| Atenção — texto / fundo | `#5B3E00` / `#FFF4E4` | dourado-800 / dourado-50 |
| Informação — texto / fundo | `#004C61` / `#ECF4FC` | azul-800 / azul-50 |

### 4.2 Contraste medido (não herdado)

Medido por `contraste-email.py` em 2026-08-07. **14 pares com piso, 0 reprovações.**

| Papel | Razão | Veredicto |
|---|---|---|
| Texto primário sobre corpo branco | 13.86 | AAA |
| Texto secundário sobre corpo | 6.55 | AA |
| Texto sutil sobre corpo | 4.74 | AA |
| Link sobre corpo | 6.32 | AA |
| Texto primário sobre canvas | 12.75 | AAA |
| Texto de rodapé sobre canvas | 6.03 | AA |
| Botão primário (branco sobre turquesa-600) | 4.60 | AA |
| Texto inverso sobre marca-800 | 9.37 | AAA |
| Texto inverso sobre marca-700 | 6.32 | AA |
| Sucesso | 8.73 | AAA |
| Erro | 6.58 | AA |
| Atenção | 9.05 | AAA |
| Informação | 8.57 | AAA |

**Por que remedir em vez de herdar os números do `seed-tokens.md`:** os fundos do e-mail
não são os mesmos da interface. O caso que provou a necessidade está registrado como errata
abaixo.

> **ERRATA v0.1 — rodapé legal.** A primeira versão desta tabela usava **cinza-600** para o
> texto de rodapé sobre o canvas cinza. Medido: **4.37**, que **reprova** o piso AA de 4.5.
> O mesmo cinza-600 passa com folga sobre branco (4.74) — o fundo cinza consome a margem.
> **Correção aplicada:** rodapé sobre canvas usa **cinza-700**, medido em **6.03**. Se os
> números tivessem sido herdados da interface em vez de medidos, o erro teria entrado em
> todos os templates da fase.

### 4.3 Isenção declarada — elementos decorativos

Divisor e borda de card foram medidos e **isentados** do piso de 3:1:

| Elemento | Razão medida |
|---|---|
| Borda de card sobre canvas | 1.37 |
| Divisor sobre corpo | 1.49 |

**Racional:** o critério WCAG 1.4.11 se aplica a componentes de interface e a objetos
gráficos **necessários para entender o conteúdo**. Um divisor que apenas reforça uma
separação já sustentada por espaçamento e por troca de fundo não carrega informação: se
sumir por completo, o e-mail continua compreensível e navegável.

**Evidência de que escurecer não era a saída:** medimos os stops disponíveis — cinza-200 =
1.49, cinza-300 = 1.91, cinza-400 = 2.53 sobre branco. **Nenhum stop utilizável alcança
3:1.** Chegar lá exigiria cinza-600, transformando um detalhe em traço pesado e contrariando
o princípio "assinatura, não cobertura" (`marca-seed.md` v5.0 §2).

**Condição da isenção (gatilho de revisão):** se algum dia um divisor passar a ser o **único**
indicador de uma fronteira — sem espaçamento, sem troca de fundo — ele deixa de ser
decorativo e volta a exigir 3:1.

---

## 5. Decisões EM — fundamento técnico

### EM3 — dark mode: o DS não é portado

**Decisão:** o par light/dark nativo do DS **não é levado ao e-mail**. Em seu lugar, uma
estratégia de sobrevivência em três camadas:

1. Declarar intenção com as meta tags `color-scheme` e `supported-color-schemes`
2. Fornecer `prefers-color-scheme` para os clientes que o respeitam
3. **Desenhar para sobreviver à inversão forçada:** fundo `#ffffff` literal e nunca
   transparente; logo e ícone com placa opaca ou contorno; jamais quase-preto sobre
   quase-branco

**Racional:** existem três regimes de dark mode entre os clientes — nenhum, inversão
parcial, e inversão total. O terceiro é destrutivo e não tem contorno técnico: a inversão
total também atinge fundos escuros, de modo que um e-mail já desenhado em tema escuro é
ironicamente forçado a ficar claro. Outlook aplica algoritmo próprio independentemente do
CSS do remetente, chegando a injetar estilos inline com `!important`. O Gmail ignora
`prefers-color-scheme` e aplica lógica própria — e converte fundo branco em cinza-escuro de
forma previsível, o que torna `#ffffff` literal mais seguro que transparente.

**Alternativas descartadas:**
- *Replicar o par light/dark do DS* — produziria o oposto do pretendido nos clientes de
  inversão total.
- *Ignorar dark mode* — a maioria dos clientes força de qualquer maneira; ignorar é aceitar
  resultado aleatório.

**Consequência para a marca:** logo transparente corre risco documentado de sumir quando o
fundo muda; a mitigação é contorno grosso ou placa de fundo atrás da imagem. Isso vira
requisito do pipeline de assets (EM5).

### EM4 — tipografia: Montserrat é aprimoramento, não requisito

**Decisão:** pilha canônica para e-mail —

```
'Montserrat', 'Segoe UI', Roboto, Helvetica, Arial, sans-serif
```

Para dados de medição e identificadores (kWh, kWp, número de UC, ART, nº de proposta):

```
'JetBrains Mono', Consolas, 'Courier New', monospace
```

**Racional:** Outlook desktop e Gmail Android não carregam webfont. A régua real, portanto,
**é a pilha de fallback** — não a fonte de marca. Um sistema que só foi testado com a fonte
carregada nunca foi testado.

**Alternativas descartadas:**
- *Texto como imagem para garantir a fonte* — mata acessibilidade e desaparece com bloqueio
  de imagem.
- *Forçar webfont via `@import`* — silenciosamente ignorado, dando falsa sensação de
  cobertura.

**Pendência gerada:** o `marca-seed.md` v5.0 não declara o comportamento da marca quando
Montserrat não carrega. Emenda a fazer quando aquele arquivo for editado (seção 8).

### EM5 — ícones e logo: SVG proibido

**Decisão:** todo ícone e o logo entram como **PNG @2x** (48px de arquivo, exibido a 24px),
com a cor **assada no arquivo**, hospedados em URL pública estável. `alt` obrigatório:
descritivo quando informativo, `alt=""` quando decorativo — **nunca ausente**.

**Racional:** o Outlook para Windows renderiza com o motor do Word, que não suporta SVG nem
inline nem via `img src`. E `currentColor` não existe no e-mail, o que obriga a cor a ser
decidida no momento da geração do arquivo. O set de 28 glifos do §45 é favorável a essa
conversão: ícones simples de traço a 24px são os mais fáceis de rasterizar e os mais
legíveis em tamanho pequeno.

**Sobre `alt` ausente vs. vazio:** um `alt` ausente costuma fazer o leitor de tela ler em
voz alta o nome do arquivo ou a URL. `alt=""` é a marcação correta para decorativo.

**Alternativas descartadas:**
- *`<picture>` com SVG e fallback PNG* — dobra requisições e não resolve o Outlook.
- *Base64 embutido* — consome o orçamento de peso (EM6).
- *Ícone-fonte* — desaconselhado pelo canon de e-mail e frágil sob bloqueio de fonte.

### EM6 — peso: gate de 80 KB

**Decisão:** o HTML do artefato deve ficar **abaixo de 80 KB**, medido por script antes de
qualquer envio.

**Racional:** o Gmail corta a mensagem exatamente ao atingir 102 KB, o que pode impedir o
fechamento de tabelas e quebrar o layout — e o limite conta apenas o código, não as imagens.
Dois agravantes justificam a margem: no mobile o teto é menor (cerca de 20 KB no iOS,
cerca de 75 KB em outros), e o próprio provedor de envio **aumenta** o HTML ao injetar links
de rastreamento. A regra prática da indústria é ficar abaixo de 80 KB.

**Alternativa descartada:** adotar 102 KB — não deixa margem para a injeção do provedor,
e o estouro só apareceria em produção.

### EM7 — nenhuma informação existe só em imagem

**Decisão:** todo e-mail deve ser compreensível e acionável **com as imagens bloqueadas**.

**Racional:** bloqueio de imagem é estado padrão frequente, e a orientação de acessibilidade
é explícita: não faça conteúdo de e-mail só de imagem, porque parte dos usuários tem imagens
desabilitadas e nesse caso o texto alternativo não aparece.

**Alternativa descartada:** hero com a chamada dentro da arte — padrão comum de mercado,
reprovado aqui.

### EM8 — plain-text alternativo obrigatório

**Decisão:** toda peça sai em multipart, com versão em texto puro.

**Racional:** entrega, acessibilidade e leitura em relógio ou assistente. Bônus de método:
a versão texto é o teste que expõe conteúdo preso em imagem.

**Alternativa descartada:** HTML-only — penaliza entrega e quebra em cliente texto.

### EM9 — conformidade: o DS reserva o slot, não implementa

**Decisão:** o template **reserva os slots** (rodapé com endereço físico, gestão de
preferências, link de descadastro visível) e **declara os requisitos** de autenticação. A
implementação de infraestrutura é de produto/TI, fora do DS.

**Racional:** cabeçalho de descadastro e autenticação são infraestrutura, não design — mas
se o template não tiver o lugar reservado desde o início, vira remendo depois.

#### EM9-b — regime de volume (emenda de 2026-08-07)

**Fato apurado:** o volume de e-mail da SEED está **abaixo de 5.000/dia**, o que a coloca
fora da categoria de bulk sender do Google. Consequências:

| | Situação |
|---|---|
| Cabeçalhos `List-Unsubscribe` / `List-Unsubscribe-Post` (RFC 8058) | Passam de exigidos a **recomendados** — e são **mantidos assim mesmo** |
| SPF, DKIM, DMARC | **Continuam obrigatórios** — valem para todos os remetentes, não só bulk |

**Racional para manter a RFC 8058 mesmo sem obrigação:** custo zero, ganho de reputação
real, e o limiar de bulk sender é **permanente uma vez cruzado** — uma única campanha maior
mudaria o regime para sempre. Projetamos como bulk desde já.

### EM10 — formato-fonte canônico

**Decisão:** o canônico é **HTML puro comentado**, no padrão Cerberus. Um porte para React
Email fica registrado como **consumidor** do canônico, para o caminho Supabase Auth Hook +
Resend do ERP.

**Racional:** o canônico precisa servir quatro destinos incompatíveis entre si — o provedor
de envio, o template do Supabase Auth, a assinatura colada no cliente de e-mail do
colaborador, e o React do ERP. Só HTML puro serve os quatro.

**Alternativas descartadas:**
- *MJML como fonte* — adicionaria uma linguagem e uma etapa de build à casa, e o output
  ainda exigiria auditoria própria. É a auditoria que dá garantia, não o compilador.
- *React Email como fonte* — não serve a assinatura nem peça de marketing fora do React.

### EM11 — hospedagem dos assets

**Decisão:** origem em **Cloudflare R2**, servida por domínio próprio com caminho versionado
e imutável:

```
https://assets.seed.eng.br/email/v1/icones/<nome>@2x.png
https://assets.seed.eng.br/email/v1/marca/<nome>@2x.png
```

**Regras invioláveis:**
1. O segmento `/v1/` **nunca é sobrescrito**. Arte nova entra em `/v2/`.
2. Os PNGs são ancorados por MD5 no `MANIFESTO.md`, como qualquer artefato canônico.
3. Cache: `Cache-Control: public, max-age=31536000, immutable`.

**Racional:** um e-mail é **imutável depois de enviado** — ele busca a imagem ao vivo, anos
depois. Não existe editar a URL de uma peça que já está em 300 caixas. Portanto o host
precisa ser mais estável que qualquer produto. A regra de nunca sobrescrever é a mesma lição
que originou a REGRA DE PROPAGAÇÃO do marco v1.4 do projeto.

> **SUPERSEDE — EM11-b.** A decisão original (2026-08-07, manhã) colocava a origem no
> **Supabase Storage**. Substituída por Cloudflare R2 no mesmo dia, ao apurar o fato novo de
> que a SEED já opera Cloudflare. Motivos: (a) domínio próprio é nativo no R2, sem add-on
> pago nem proxy a manter; (b) egress sem custo e free tier recorrente de 10 GB, folga
> enorme para poucos megabytes de PNG; (c) **o argumento decisivo é de arquitetura** — o
> projeto Supabase pertence ao ERP, e asset de e-mail não pode depender do ciclo de vida de
> um produto. *Alternativa descartada:* Supabase Storage com Worker de proxy no Cloudflare —
> funciona, mas cria código a manter para um problema que o R2 resolve com um clique.

> **EM11-c — TLS mínimo 1.0, decisão consciente.** O domínio de assets ficou com TLS mínimo
> 1.0, que é o padrão da Cloudflare. *Racional:* o que trafega são PNGs públicos, sem
> credencial e sem dado pessoal — não há segredo em trânsito. Exigir TLS 1.2 traria ganho
> nulo e um risco real: cliente de e-mail corporativo antigo falharia ao buscar a imagem, e
> o sintoma seria logo quebrado sem explicação. *Alternativa descartada:* subir para 1.2 por
> higiene padrão — boa regra geral, errada nesta superfície. **Gatilho de revisão:** se o
> bucket passar a servir qualquer conteúdo não-público, esta decisão precisa ser refeita.

**Estado verificado em 2026-08-07:** bucket `seed-email-assets` criado; domínio
`assets.seed.eng.br` ativo com acesso habilitado; Public Development URL (`r2.dev`)
**desativado** de propósito, por ter limites de taxa estritos que causariam falha
intermitente de imagem em produção. Verificação por leitura de volta: requisição a um objeto
inexistente retorna o 404 do próprio R2, provando DNS, TLS e roteamento.

### EM12 — sem ferramenta paga de preview

**Decisão:** nenhuma assinatura de serviço de preview. O gate é a **matriz de caixas reais**
(seção 7).

**Racional:** a Fase 4 produz cerca de 6 templates que depois mudam pouco; assinatura mensal
é despesa recorrente para trabalho concentrado em janelas. O mercado encareceu — a Litmus
passou a ter mínimo de US$ 500/mês e virou enterprise-only; o Email on Acid começa em
US$ 74/mês e oferece trial de 7 dias.

**Uso previsto do trial:** opcional, apenas se aparecer defeito que a matriz local não
explique.

> **SUPERSEDE — EM12-b, criada e revogada no mesmo dia.** Foi criada uma emenda tornando o
> trial do Email on Acid **obrigatório**, sob a premissa de que a SEED, sendo 100% Google
> Workspace, não teria acesso ao motor Word do Outlook. **A premissa caiu:** apurou-se que há
> Outlook 2024 clássico instalado e disponível. Emenda **revogada**. Registro mantido para
> que a linha de raciocínio não se perca.

### EM13 — provedor de envio

**Decisão:** **Resend** como provedor transacional, com envio por **subdomínio próprio**.

| Trilha | Destino | Estado |
|---|---|---|
| Transacional (ERP) | Resend, via `envio.seed.eng.br` | **decidida** |
| Newsletter / comercial | a definir no sub-bloco EN | **adiada de propósito** — depende de a SEED ter lista e cadência, dado ainda inexistente |
| Assinatura corporativa | nenhum provedor; vive no cliente de e-mail do colaborador | **decidida** |

**Racional:** a integração nativa configura o SMTP customizado do Supabase Auth
automaticamente; casa com o porte React Email do EM10; e o plano gratuito (3.000/mês)
comporta o volume atual.

**Risco declarado:** o teto do plano gratuito é **diário** (100/dia), não só mensal — uma
rajada de avisos do ERP numa única manhã pode estourar mesmo com volume mensal baixo.

**Fronteira:** o Resend é focado em transacional; campanha de marketing exigiria ferramenta
distinta. Por isso a trilha de marketing está adiada, e não decidida por omissão.

> **EM13-b — envio por subdomínio.**
> **Decisão:** `envio.seed.eng.br`, com o domínio raiz `seed.eng.br` permanecendo exclusivo
> do Google Workspace e **intocado**.
>
> **Racional:** reputação isolada — se um disparo automático do ERP acumular marcações de
> spam, o dano fica contido no subdomínio e não contamina o e-mail humano da equipe, que é
> onde estão as propostas comerciais e o contato com concessionárias. A documentação do
> provedor recomenda o mesmo: preferir subdomínio ao domínio raiz, por ausência de conflito
> de MX com o e-mail existente e por isolamento de reputação. Subdomínios herdam a política
> DMARC do domínio pai quando não têm a sua.
>
> **Trade-off assumido:** o destinatário vê o remetente como `@envio.seed.eng.br`.
>
> **Alternativa descartada:** enviar pelo domínio raiz — sem risco técnico, mas
> compartilharia reputação com a comunicação humana da empresa.
>
> > **CORREÇÃO DE RACIONAL (registro de erro).** A primeira justificativa escrita para o
> > EM13-b alegava que incluir o provedor no domínio raiz arriscaria **quebrar o SPF do
> > Google Workspace**. **Isso não procede.** O Resend nunca pede edição do SPF do apex — ele
> > publica MX, SPF e DKIM sob um subdomínio de envio próprio. O raciocínio partiu do padrão
> > de outros provedores sem verificar o deste. A conclusão sobreviveu; o racional foi
> > substituído pelo argumento de reputação acima.

**Estado verificado em 2026-08-07:** domínio `envio.seed.eng.br` **verificado** no Resend
(região São Paulo, sa-east-1), com DKIM, SPF e MX confirmados. DMARC publicado em
`_dmarc.envio.seed.eng.br` com `v=DMARC1; p=none; rua=mailto:contato@seed.eng.br`, mais o
registro de autorização de relatório entre domínios
`envio.seed.eng.br._report._dmarc.seed.eng.br`. Verificação por terceiro: consulta DMARC em
todos os nameservers da zona retornou o registro idêntico e consistente.

### EM14 — identidade de remetente

| Campo | Valor |
|---|---|
| From name | `SEED engenharia` |
| From | `nao-responda@envio.seed.eng.br` |
| **Reply-To** | **`contato@seed.eng.br`** |

**Racional:** o From name é o que o destinatário lê **antes de abrir**, e por isso segue a
grafia canônica da marca. O endereço não leva acento nem ponto, que quebram em cliente
antigo. O **Reply-To é o campo que mais importa**: sem ele, o cliente que recebe um alerta
de geração e aperta "Responder" fala com o vazio.

**Alternativa descartada:** remetente por assunto (`propostas@`, `faturas@`) — fragmenta a
reputação em vários endereços e multiplica manutenção, sem ganho para o destinatário.

**Marcação de estado:** o Reply-To é **provisório por decisão do Rafael** ("por hora"). Se
surgir caixa dedicada a atendimento de sistema, é troca de uma linha.

> **SUPERSEDE — ET7 (2026-08-08).** O From `nao-responda@envio.seed.eng.br` foi substituído
> por **`notificacoes@envio.seed.eng.br`**. *Motivo:* a pesquisa do lote ET (Litmus) mostrou
> que endereço "no-reply" desencoraja resposta e desperdiça sinal positivo de entregabilidade
> — e contradizia o nosso próprio rodapé, que convida "Responda este e-mail". *Alternativas
> descartadas:* manter `nao-responda@` (contradição interna) · From `contato@seed.eng.br`
> (misturaria o domínio de envio com a caixa humana, quebrando o isolamento da EM13-b).
> Nenhuma caixa nova precisa existir: o domínio de envio está verificado e o Reply-To segue
> apontando para `contato@`.

### EM15 — fronteira do app Lovable

**Decisão:** os e-mails de autenticação do app `app.seed.eng.br` (recuperação de senha,
ativação de usuário) ficam **fora do escopo da Fase 4** nesta rodada. Revisão programada
para o fim do desenvolvimento do app, quando a SEED decide entre atualizar o envio do
Lovable ou unificar no Resend.

**Racional:** são e-mails de infraestrutura, vistos apenas por usuários internos, sem
contato com cliente. Refatorar sistema em desenvolvimento ativo é retrabalho garantido.

**Alternativa descartada:** unificar agora — o app ainda está mudando, e a padronização
seria refeita.

**Mitigação que torna a unificação barata depois:** o formato-fonte canônico é HTML puro
(EM10), que é exatamente o que o Supabase Auth aceita como template customizado. Quando a
decisão vier, é colar — não reescrever.

---

## 6. Decisões EL — sistema de layout

| # | Decisão | Racional | Alternativas descartadas |
|---|---|---|---|
| **EL1** | Grade de **600px**, coluna única como padrão; multi-coluna é exceção justificada | Largura canônica com melhor comportamento no painel de leitura do Outlook | 640/680px (risco de corte lateral) · fluido sem teto (o Outlook não colabora) |
| **EL2** | Técnica **híbrida**: `max-width`/`min-width` com largura fixa condicional para Outlook, empilhando **sem** media query; media query apenas como aprimoramento progressivo | Garante base legível onde a media query não existe (Outlook Windows) ou é parcial (Gmail). É a técnica do canon: o layout empilha sem media query, com largura fixa para o Outlook, que está preso ao desktop de qualquer forma | Media-query-only (quebra exatamente no cliente corporativo que o público da SEED usa) · mobile-first puro (perde controle do desktop no Outlook.com) |
| **EL3** | `role="presentation"` em **toda** tabela de layout, inclusive aninhadas. Tabela de **dados real** mantém semântica (`<table>`, `<caption>`, `<th scope>`) — herda o §40 | Layout de e-mail aninha tabelas; marcar só a externa deixa o leitor de tela anunciando linhas e colunas das internas | Marcar apenas a tabela raiz |
| **EL4** | **Botão bulletproof** por padding + VML para Outlook; alvo com altura ≥44px; texto real, nunca imagem | Herda o §1 e a régua de escada de mecanismos: cor nunca é o único portador de significado | Botão como imagem (morre com bloqueio) · `<button>` (não existe em e-mail) |
| **EL5** | **Preheader obrigatório** com espaçador, tratado como microcopy de primeira classe | Sem ele o cliente preenche sozinho com o começo do corpo — inclusive com texto alternativo de imagem | Deixar o cliente decidir |
| **EL6** | `lang="pt-BR"` no `<html>` · um único `<h1>` · hierarquia semântica real · ordem de leitura linear | Critério WCAG 3.1.1 e navegação por cabeçalho no leitor de tela | Marcação puramente visual |
| **EL7** | **Cabeçalho e rodapé canônicos** como módulos únicos: logo raster com placa, assinatura institucional, endereço da matriz, gestão de preferências | Rodapé compartilhado é o que impede a deriva peça a peça | Rodapé por template (garante versões divergentes em meses) |
| **EL8** | **Contraste medido por script** sobre os hex resolvidos, nos pisos da seção 4.2, com a isenção declarada de 4.3 | Régua permanente do projeto: nenhum número não-medido entra em arquivo canônico | Herdar os pares do DS sem remedir — foi o que a errata do rodapé provou ser perigoso |

| **EL9** | Corpo de texto em **16px**, não nos 14px da escala de interface | E-mail é lido em condições piores que uma interface — tela pequena, luz ruim, de relance, sem zoom fácil; 16px é o padrão da indústria para corpo de e-mail | Herdar os 14px por consistência numérica — consistência que produz texto difícil de ler é teimosia, não consistência |
| **EL10** | Espaçamento vertical entre blocos por **linha espaçadora com `height`**, nunca `margin` em tabela | O motor Word ignora margin em tabela; o bloco flui para o lado do vizinho (defeito 5 do gate, §7.2) | Margin na tabela (falha no Outlook) · padding no td do conteúdo anterior (acopla o espaço ao bloco errado) |

**Fronteira declarada — largura mínima de teste.** No e-mail o piso é **320px**, não os
360px usados no DS web. É divergência deliberada: o pior caso histórico do e-mail é mais
baixo que o do navegador. Registrada aqui para não ser lida no futuro como inconsistência.

---

## 7. Régua de validação executada

A camada de validação da Fase 3 (445 testes jsdom + 43 verificações de render em Chrome
headless) **não se aplica** a esta fase, e o motivo é estrutural: jsdom valida comportamento
de DOM interativo, que o e-mail não tem; e o Chrome headless é o cliente de e-mail mais
permissivo que existe — passar nele não prova nada sobre o Outlook.

| Camada | Artefato | O que mede |
|---|---|---|
| **Estática** | `suite-email.mjs` | Reprova `var(--`, `<svg>`, `flex/grid/position`, tabela de layout sem `role="presentation"`, `<img>` sem `alt` ou com `alt` ausente, `<img>` sem dimensão em px, `<html>` sem `lang`, ausência de preheader / `color-scheme` / `supported-color-schemes`, link sem `href` absoluto, fundo transparente em bloco de marca |
| **Peso** | mesma suíte | HTML < 80 KB (EM6) + inventário de imagens |
| **Contraste** | `contraste-email.py` | Todos os pares resolvidos, com as três categorias de piso |
| **Render** | extensão da suíte de render existente | 600px e 320px · **com e sem imagens** · dark emulado · prova grayscale |
| **Gate humano** | protocolo de envio real | A única camada que vê o motor Word |

### 7.1 Matriz do gate humano

| Cliente | Papel no diagnóstico |
|---|---|
| **Outlook 2024 clássico (Windows)** | Motor do Word. É onde tudo quebra — e é o cliente dos destinatários B2B da SEED (concessionária, indústria, órgão público, licitação) |
| **Gmail app Android** | Inversão forçada de dark mode |
| **Gmail web** | Proxy de imagem, tratamento de `<style>`, fallback de fonte |
| **Outlook.com web** | Regime intermediário: injeta estilos próprios com `!important` |
| **Apple Mail iOS** | Controle — o mais permissivo. Se quebra aqui, o defeito é nosso |

**Inversão de equilíbrio a assumir de frente:** esta é a primeira fase do projeto em que o
gate humano é **mais determinante** que a camada automatizada. Nenhuma ferramenta disponível
emula o motor Word.

**Cuidado de identificação:** existem dois programas chamados Outlook no Windows, e apenas o
**clássico** serve. O "novo Outlook" usa motor de navegador e renderiza bem demais para
servir de pior caso.

---

### 7.2 Ciclo de gate executado (2026-08-07 → 2026-08-08) — registro completo

O template-base atravessou três rodadas de gate visual humano. **Cinco defeitos reais
foram encontrados — nenhum deles visível pelas 19 verificações automatizadas.** Todos
corrigidos e convertidos em teste-guarda permanente, com crédito ao gate do Rafael,
conforme a regra do projeto.

| # | Cliente | Defeito encontrado | Causa | Correção | Guarda |
|---|---|---|---|---|---|
| 1 | Gmail app Android (dark forçado) | Emenda de dois tons ao redor do logo | O cliente inverte a cor CSS do `<td>` mas não inverte imagem; a placa do PNG divergiu do fundo | Faixa de marca virou **imagem única de borda a borda** (`cabecalho-seed-600@2x.png`) | **GV1** |
| 2 | Gmail app Android | Corpo inteiro centralizado | O `align="center"` do canvas externo vaza por herança (o web ignora; o app obedece) | `align` + `text-align` explícitos em todo `<td>` de conteúdo | **GV2** |
| 3 | Gmail app Android | Blocos escuros irregulares atrás do texto | Elemento sem `background-color` declarado recebe tratamento diferente do vizinho na inversão | `background-color` explícito em todo `h1`/`p` | **GV3** |
| 4 | Gmail app Android | Título transbordando a caixa | Auto-scaling de fonte do cliente. Registrado como hipótese na v0.2; **promovido a fato** quando o reenvio confirmou a correção | `-webkit-text-size-adjust:100%` no body | coberto pela revalidação |
| 5 | Outlook 2024 clássico (motor Word) | Divisor ao **lado** do botão VML, não abaixo | O motor Word **ignora `margin` em `<table>`** | Espaçamento vertical virou linha espaçadora com `height` | **GV4** |

**Regra unificada nascida dos defeitos 1–3:** os três tinham a mesma causa — o Gmail
inverte o que é CSS implícito e não toca em imagem nem no que é explícito. A régua
permanente é **NADA IMPLÍCITO**: toda cor, alinhamento e fundo declarados; faixa de
marca é imagem única; espaçamento entre blocos é linha espaçadora, nunca margin de tabela.

**Regra de protocolo nascida do processo:** print de e-mail **encaminhado não vale como
evidência de gate** — o encaminhamento do Gmail descarta o `<head>` (metas de tema, media
queries) e os comentários condicionais (VML), produzindo defeitos que não são do template.
O gate exige **recebimento direto** na caixa do cliente testado. Aconteceu duas vezes no
ciclo antes de virar regra.

**Matriz efetivamente coberta:** Gmail web ✅ · Gmail app Android com inversão forçada ✅ ·
Outlook 2024 clássico ✅ (VML do botão confirmado renderizando). Pendentes sem bloquear:
Outlook.com web e Apple Mail iOS — riscos residuais baixos, cobertos na primeira
oportunidade.

**Diferença v0.2 → v0.3:** apenas o divisor (defeito 5). Promovida sem reenvio aos
clientes já aprovados, por ser correção de padrão documentado do motor Word com risco
classificado como mínimo — decisão consciente, não omissão.

### 7.3 Promoção

**2026-08-08 — Rafael aprovou** ("aprovo") a promoção a `estável` de: o template-base
`seed-email-base.html` v0.3 (MD5 `4fed56e13ae5c90e43ab706be9e32eb6`), as réguas GV1–GV4
como teste-guarda permanente, e o protocolo de gate sem encaminhamento. A suíte
`suite-email.mjs` acompanha com 19 verificações (MD5 `a936c3f73ea7cf647386db5c0eed7b63`).

---

## 8. Fronteiras e pendências abertas

### Do escopo desta fase

- ~~**EC, ET, EN, EA** não escritos — são os lotes seguintes.~~ **RESOLVIDA (v0.11):**
  os quatro sub-blocos foram escritos e promovidos a `estável` em 2026-08-08 — EC (§8-B),
  ET (§8-C), EA (§8-D), EN (§8-E). Linha mantida riscada para rastreabilidade.
- **Trilha de marketing** (EM13) adiada de propósito até haver dado sobre lista e cadência.
- **Cache dos assets:** como o upload será manual pelo painel, o cabeçalho `Cache-Control`
  não vem sozinho. Solução prevista para o lote EC: uma Cache Rule na zona aplicada a
  `assets.seed.eng.br/*`, em vez de editar objeto a objeto.
- **API key do Resend:** política de chave descartável — criada no momento do envio de
  teste e revogada em seguida. A primeira chave do projeto foi revogada após exposição
  parcial em screenshot (2026-08-07); a prática de revogar pós-uso virou o padrão.
- **Rodapé do template-base:** dois placeholders aguardando dado real — o **endereço da
  matriz** (obrigatório por regra antispam) e a **URL de gestão de preferências**
  (`seed.eng.br/preferencias` ainda não existe). Preencher antes do primeiro envio a
  cliente real; irrelevante para os lotes de produção EC/ET.
- **Clientes pendentes de gate:** Outlook.com web e Apple Mail iOS (ver §7.2).

### Emendas devidas a outros arquivos canônicos

| Arquivo | Emenda | Quando |
|---|---|---|
| `marca-seed.md` v5.0 | Declarar o comportamento da marca quando Montserrat não carrega (EM4) e a exigência de placa/contorno para logo em fundo invertido (EM3) | Na próxima edição do arquivo |
| `seed-componentes.md` | Nenhuma — a Fase 4 não altera componentes web | — |
| `MANIFESTO.md` | Ancorar por MD5 os PNGs de e-mail quando existirem (EM11) | Lote EC |

### Fora do escopo do Design System — backlog de TI da SEED

Achados apurados durante a montagem da infraestrutura, registrados para não se perderem:

1. **DKIM do Google Workspace não está ativo.** Não existe registro `google._domainkey` na
   zona `seed.eng.br`. O Workspace não ativa DKIM sozinho — é ação manual no Admin Console.
   Consequência: os e-mails da SEED passam por SPF mas não vão assinados.
2. **DMARC ausente no domínio raiz.** Confirmado por ferramenta de terceiro. Ordem correta:
   ativar DKIM → aguardar 48h autenticando → publicar `_dmarc` com `p=none` → monitorar →
   endurecer.
3. **Resíduo no SPF do raiz.** O registro inclui `spf.whservidor.com`, de hospedagem
   anterior. **Medido:** o include resolve e retorna Pass, o SPF está íntegro (13/13 verde),
   e não há estouro de lookups — portanto **não é urgente**. Mas todo domínio incluído em um
   SPF ganha autorização para enviar como `@seed.eng.br`; convém remover depois de confirmar
   que não há conta ativa. **Procedimento seguro:** copiar o valor atual antes de editar.

---

## 8-B. Sub-bloco EC — componentes de e-mail (`estável` · promovido em 2026-08-08)

> Consolidado EC1–EC8 aprovado pelo Rafael em 2026-08-08 ("aprovo") após 3 rodadas
> encadeadas: R1 Cerberus components (espaçamento por padding/spacer, nunca margin em
> tabela — respaldo do canon à nossa EL10; tags semânticas seguras com CSS inline) →
> R2 recibo transacional da Stripe via Really Good Emails + inventário de recibo
> (papéis de tabela definidos; itemização, totais, forma de pagamento) → R3 norma da
> fronteira das duas tabelas (marcação portadora de significado — th/scope/caption —
> proibida em tabela de apresentação e obrigatória em tabela de dado real; scope
> simples preferido a headers/id por suporte). 4ª rodada não disparada.
> Preview canônico: `seed-email-componentes.html` v0.1, que **herda o template-base
> v0.3** — a região CONTEUDO trocada, cabeçalho/rodapé/mecânica intactos, provando o
> contrato do EL7 na prática.

### Decisões EC

| # | Decisão | Racional | Alternativas descartadas |
|---|---|---|---|
| **EC1** | Inventário do lote: caixa de severidade · card neutro · tabela de dados · lista · bloco de contato comercial · ícone raster. Botão, divisor e spacer não se reescrevem — vivem no template-base (EL4/EL10) | Uma fonte por componente | Duplicar botão/divisor no EC (drift entre cópias) |
| **EC2** | Caixa de severidade nos 4 níveis T1–T5: barra lateral 4px na cor de texto + fundo -50 + texto no par medido da §4.2. **Mecanismo além de cor = rótulo textual em negrito** ("Sucesso:", "Atenção:", "Erro:", "Informação:"); ícone é opcional, nunca o portador | Rótulo textual sobrevive a bloqueio de imagem, grayscale e inversão; elimina dependência de PNGs hospedados só para severidade | Ícone como portador (viola EM7) · só cor de fundo (viola a escada de mecanismos) |
| **EC3** | Tabela de dados real: `<caption>` + `<thead>` + `<th scope="col">`/`<th scope="row">`, atributo booleano `data-tabela-dados` (o opt-out que a suíte reconhece), números em mono alinhados à direita, sem células mescladas, bordas horizontais visíveis | A exceção semântica do EL3, pelo lado obrigatório: sem a marcação, o leitor anuncia o valor sem o contexto da coluna | role=presentation + visual de tabela (perde as relações) · headers/id (pior suporte, desnecessário) |
| **EC4** | Lista semântica `<ul>`/`<ol>` com CSS inline: margin controlada, padding-left explícito, cor declarada | Canon: semântica é segura em e-mail; o que quebra é default não zerado | Tabela imitando lista |
| **EC5** | Ícones raster **sob demanda**: nenhum PNG especulativo. Par glifo×cor rasterizado quando um template o pedir, do SVG normalizado do §45 (24×24, stroke 2), a 48px @2x, cor assada, nome `<glifo>-<cor>@2x.png`, âncora no MANIFESTO. **Fonte dos SVGs: `seed-icones-preview.html` (Drive `validacao/`)** | 28 glifos × 4+ cores ≈ 112 arquivos, quase todos sem uso; sob demanda mantém o bucket auditável | Rasterizar o set inteiro (manutenção sem consumo) |
| **EC6** | Card neutro: tabela aninhada, borda 1px cinza-200 (decorativa, isenção §4.3), `border-radius:8px` com **degradação assumida no Outlook (canto reto)**, padding 24, fundo branco explícito | Agrupamento de resumo sem cor nova | VML para cantos de card (complexidade que só o botão justifica) |
| **EC7** | Bloco de contato comercial (ET/EN): nome, cargo, canal — texto puro com filete turquesa-600 à esquerda, **sem foto** | Remetente humano sem asset por pessoa; foto some no bloqueio | Foto do responsável · cartão gráfico (viola EM7) |
| **EC8** | Entregável: preview único `seed-email-componentes.html`, validado pela suíte e enviado à matriz real no gate | Padrão dos blocos da F3: um preview canônico por lote | Um arquivo por componente |

### Gate visual do EC (2026-08-08) — 2 achados, corrigidos no preview v0.2

| # | Cliente | Achado | Correção | Guarda |
|---|---|---|---|---|
| 6 | Gmail app Android (dark) | Valores da tabela quebrando linha no meio do número ("R$" separado de "3.104,55") | `white-space:nowrap` nas células mono de valor; a coluna Descrição absorve o aperto | revalidação |
| 7 | Outlook 2024 (motor Word) | Barra lateral da severidade rendia como **dois tocos com vão** — o Word não estica célula vazia para a altura da linha | **Supersede da anatomia EC2:** a barra deixa de ser célula de 4px e vira **`border-left` no próprio td de conteúdo**, que o Word renderiza de forma confiável | **GV5** |

Fora os achados, o gate aprovou: as 4 severidades **distinguíveis após a inversão forçada**
do Android (o cenário-alvo do EC2), card, lista e contato limpos nos dois clientes, e a
herança do template-base intacta.

### Promoção do EC

**2026-08-08 — Rafael aprovou** ("aprovo") a promoção a `estável` do sub-bloco EC:
decisões EC1–EC8 (com o supersede da anatomia EC2 — barra lateral por `border-left`,
nunca por célula), o preview canônico `seed-email-componentes.html` v0.2
(MD5 `bc1312630cbd8ce2b3a4d11a4c2d976d`) e a régua GV5. Placar do lote: 20 verificações
automatizadas, 3 clientes reais no gate (Gmail web · Gmail app Android dark forçado ·
Outlook 2024 clássico), 2 defeitos reais encontrados pelo gate humano, ambos corrigidos
e convertidos em guarda. Confirmação da v0.2 nos três clientes: barra contínua no motor
Word, valores íntegros na inversão do Android, regressão limpa no Gmail web.

**Nota cosmética registrada, sem bloqueio:** no Android, "4.812 kWh" quebra entre número
e unidade (ponto de quebra legítimo — o nowrap protege o número). Se algum template
exigir número+unidade indivisíveis, a troca do espaço por `&nbsp;` resolve caso a caso.

### Errata de suíte (registro de transparência)

Na primeira auditoria do preview real, o detector do EL3 acusou a tabela de dados como
tabela de layout sem role — **falso FAIL**: o `data-tabela-dados` estava presente como
**atributo booleano sem valor** (HTML legítimo) e o detector exigia `=`. Corrigido no
detector, com regressão confirmada (template-base 19 PASS · fixture violador seguindo
reprovado). Mesmo padrão das lições da F3: falso-positivo de suíte se corrige na suíte,
nunca afrouxando a regra.

---

## 8-C. Sub-bloco ET — transacionais do ERP (`estável` · promovido em 2026-08-08)

> Consolidado ET1–ET7 aprovado pelo Rafael em 2026-08-08 ("aprovo"). Rodadas: heranças
> declaradas (recibo do R2/EC, régua GOV.UK do R1/EM, conformidade EM9) + arco novo —
> R1 canon transacional Postmark/Litmus (identificador no assunto, sem nome de produto,
> veto ao no-reply) → R2 mercado (resumo do acontecido primeiro, copy enxuta, sem adendo
> promocional) → R3 domínio de monitoramento solar (produção normal é faixa modelada,
> não alvo único; alerta exige esperado × medido × desvio; nem toda queda dispara alarme).

### Os três templates

| Template | Assunto canônico | Preheader | Composição |
|---|---|---|---|
| `et-proposta-enviada` | `Proposta {{proposta_numero}} enviada — {{titulo_projeto}}` | "A proposta {{proposta_numero}} foi gerada e esta disponivel no portal." | h1-fato + card da proposta + CTA "Ver proposta" + bloco de contato comercial. **Sem caixa de severidade** (ET2) |
| `et-fatura-processada` | `Fatura de {{mes_ref}} processada — UC {{uc_numero}}` | "A fatura de {{mes_ref}} da UC {{uc_numero}} foi processada e conferida." | h1-fato + card da UC + tabela EC3 itemizada com `{{#itens}}` + CTA "Ver fatura no portal" + nota "sem anexo" (ET6) |
| `et-alerta-geracao` | `Atenção: geração abaixo do esperado — {{usina_nome}}` | "Geracao de {{periodo}} ficou {{desvio_pct}}% abaixo da faixa esperada — {{usina_nome}}." | Caixa "Atenção" EC2 + card da usina + tabela esperado × medido × desvio com `{{#linhas}}` + CTA "Ver monitoramento" + nota sobre o gatilho ser do ERP (ET5) |

### Inventário de placeholders (o contrato com o ERP)

Convenção ET4: `{{snake_case}}` simples para valor; `{{#secao}}…{{/secao}}` para bloco
repetível (sintaxe mustache, entendida por Resend, React Email e template Go do Supabase).

| Placeholder | Templates | Tipo | Exemplo |
|---|---|---|---|
| `proposta_numero` · `proposta_id` | proposta | texto/id | `2026-0147` |
| `titulo_projeto` | proposta | texto | `UFV Fazenda Santa Clara` |
| `potencia_kwp` | proposta · alerta | número BR | `42,7` |
| `cliente_nome` · `cidade_uf` | todos | texto | `Fazenda Santa Clara` · `Governador Valadares/MG` |
| `responsavel_nome` · `responsavel_cargo` · `responsavel_fone` | proposta | texto | — |
| `mes_ref` | fatura | texto | `agosto/2026` |
| `uc_numero` · `fatura_id` | fatura | id | `000000000` · `784512` |
| `{{#itens}}` → `descricao` · `qtde` · `valor` | fatura | bloco repetível | linha da tabela |
| `total` | fatura | moeda BR | `R$ 3.169,05` |
| `periodo` · `desvio_pct` · `usina_nome` · `usina_id` | alerta | texto/número/id | `07/08/2026` · `18` |
| `{{#linhas}}` → `rotulo` · `esperado` · `medido` · `desvio` | alerta | bloco repetível | linha esperado×medido |

**Obrigação do consumidor:** todo placeholder é obrigatório salvo o bloco repetível, que
aceita N ≥ 1 linhas. Placeholder não preenchido em produção é bug de integração — o
literal `{{` chegando à caixa do cliente é o sintoma.

### Decisões ET1–ET7

(Resumo — a tabela completa com racionais e alternativas descartadas foi aprovada em
2026-08-08 e está no histórico da conversa de produção; as decisões estruturais: ET1
composição pura sobre o template-base · ET2 confirmação sem caixa de severidade · ET3
contrato de assunto+preheader com identificador e sem nome de produto · ET4 placeholders
mustache inventariados · ET5 alerta com esperado×medido×desvio, sem gráfico até a F5,
gatilho é do ERP · ET6 fatura sem anexo, acesso por link · ET7 supersede do From para
`notificacoes@`, registrado na EM14.)

### Entregáveis e validação

6 arquivos: 3 canônicos com placeholders + 3 amostras preenchidas (sufixo `-amostra`,
para gate e referência de integração). **Suíte: 120 PASS / 0 FAIL** (20 verificações × 6).
Amostras verificadas sem resíduo de `{{` por asserção no gerador.

### Gate visual e promoção do ET

**Gate executado em 2026-08-08:** 3 templates × 3 clientes (Outlook 2024 clássico ·
Gmail web · Gmail app Android com inversão forçada) = 9 evidências por recebimento
direto. **Zero defeito novo** — primeiro lote da fase a atravessar o gate limpo; as
réguas GV1–GV5 herdadas seguraram tudo (barra da caixa Atenção contínua no motor Word;
tabela de 4 colunas do alerta íntegra a ~360px invertido; valores com nowrap intactos).
Nota cosmética recorrente (quebra entre número e unidade no espaço) permanece registrada
sem bloqueio. Observação de auditoria: possíveis filetes no print do Outlook do alerta
classificados como artefato de compressão de screenshot, não reproduzidos ao vivo.

**2026-08-08 — Rafael aprovou** ("aprovo") a promoção a `estável`: os 3 templates
canônicos e suas amostras, o inventário de placeholders como contrato formal com o ERP,
e o ET7 (From `notificacoes@envio.seed.eng.br`) confirmado em envio real.

---

## 8-D. Sub-bloco EA — assinatura corporativa (`estável` · promovido em 2026-08-08)

> Consolidado EA1–EA4 aprovado em 2026-08-08 (aprovo conjunto EA+EN). Fatos da pesquisa
> que regem o desenho: teto de HTML — Gmail 10.000 caracteres, Outlook 8.000 (o Outlook
> é a restrição vinculante); largura 300–400px porque os clientes comprimem o que passa
> disso no painel móvel; imagem sempre hospedada por URL, nunca embutida (embutida pesa
> em cada resposta da thread); texto sempre HTML real, imagem só para o logo; SVG e WebP
> proibidos em assinatura.

**Anatomia (EA1–EA3):** tabela única ≤400px, 2 colunas — logo raster à esquerda com
filete turquesa-600 separando os dados.

> **SUPERSEDE — EA3-b (2026-08-08, decisão do Rafael no gate).** O logo da assinatura
> passa da versão horizontal para a **VERTICAL principal**
> (`logo-seed-assinatura-vertical@2x.png`, 192×202 @2x exibido a 96×101, placa branca,
> rasterizado do SVG oficial). *Motivo:* preferência estética do diretor — a vertical
> preenche melhor a coluna esquerda da assinatura, cuja proporção é quase quadrada.
> O PNG horizontal `logo-seed-assinatura@2x.png` fica **aposentado sem uso** (nunca
> chegou a produção; permanece no R2 pela regra do caminho imutável, sem consumidor). Conteúdo: nome · cargo · SEED engenharia ·
telefone (`tel:`) · e-mail (`mailto:`) · seed.eng.br. Sem ícones sociais, sem foto, sem
disclaimer. **Consumo real: ~1.7k caracteres — 21% do orçamento de 8k.**

**Distribuição (EA4):** `ea-assinatura.html` (canônico com 4 campos `{{nome}}`,
`{{cargo}}`, `{{fone}}`/`{{fone_link}}`, `{{email}}`) + `ea-guia-instalacao.md` com o
passo a passo Gmail web e a armadilha da "assinatura para dispositivos móveis" do app
(que sobrepõe a rica se ativada — deve ficar desativada).

## 8-E. Sub-bloco EN — newsletter e comercial (`estável` · promovido em 2026-08-08)

> Consolidado EN1–EN5 aprovado em 2026-08-08. Fatos-guia: corpus B2B converge com o
> nosso base (coluna única 600px, corpo ≥14px, botão 44px); o desenho certo para
> conteúdo que varia por envio é o layout MODULAR (pilha de blocos independentes
> rearranjáveis); e prospecção direta responde melhor a texto quase puro — HTML de
> marca funciona em newsletter, não em follow-up.

**Newsletter (EN1, EN4):** `en-newsletter.html` — 4 módulos delimitados por marcadores
`MODULO-*` no código (Destaque · Notas `{{#notas}}` · Case · Aviso); cada edição
escolhe e ORDENA módulos removendo blocos inteiros, nunca os esvaziando. Rodapé
estendido: "Gerenciar preferências" + **"Cancelar inscrição"** com `{{descadastro_url}}`
integral — a URL é gerada pela ferramenta de disparo por destinatário e não pode ter
domínio fixo no canônico.

**Comercial/follow-up (EN2, EN3):** `en-comercial.html` — texto quase puro por decisão:
sem faixa de marca, sem imagem, sem botão; saudação + 3 parágrafos + um link inline.
A marca entra pela assinatura EA colada no slot `{{assinatura_ea}}`. A copy é território
da skill `seed-ds-mensagem` (fronteira EN3). Rodapé de conformidade compacto com
endereço e descadastro.

**Trilha de disparo (EN5):** formalmente adiada, herdando a EM13 — ferramenta de
campanha e cadência são decisão do Rafael quando houver lista. Os templates são
agnósticos de ferramenta.

### Refinamentos de suíte do gate EA+EN (transparência)

A 1ª auditoria dos formatos novos produziu 8 FAILs — nenhum defeito de design, três
lacunas da suíte diante de formatos que ela nunca tinha visto:
1. **URL-placeholder:** `href="{{descadastro_url}}"` reprovava no canônico; regra
   refinada — URL contendo `{{` valida na AMOSTRA (o output real), não no template.
2. **Modo fragmento:** a assinatura foi auditada como e-mail completo e reprovou em 6
   testes de nível-documento (lang, h1, metas, preheader, grade) que não se aplicam a
   uma tabela colada nas configurações do Gmail. A suíte agora detecta fragmento
   (ausência de `<html>`) e pula esses testes com SKIP explícito.
3. **GV3 na assinatura:** este era real — os `<p>` dela não declaravam fundo, e
   assinatura também sofre inversão de dark mode. Corrigido no artefato: NADA IMPLÍCITO
   vale nela também.
Regressão pós-refinamento: base + componentes + ET = 60 PASS / 0 FAIL; fixture violador
segue reprovando (15 FAIL corretos).

---

### Gate visual do EN — defeitos 8 e 9 (2026-08-08) e correção retroativa

| # | Cliente | Defeito | Causa | Correção | Guarda |
|---|---|---|---|---|---|
| 8 | Todos (amostra da newsletter) | **Chaves órfãs vazando ao destinatário**: "{{SEED em agosto}}", "{nota}" | Erro de geração: placeholders dentro de expressões de f-string Python não sofrem a redução de chaves — o canônico saiu com 4 chaves e a substituição deixou par órfão em volta do valor. **Agravante:** a asserção anti-resíduo procurava só `{{palavra}}` e não viu valor com espaços — falsa confiança | Canônico normalizado por pós-processamento; **asserção reforçada: qualquer `{{`/`}}` residual reprova** | **GV6a** |
| 9 | Outlook 2024 | Divisores entre módulos rendendo como **faixas cinza** | `<td>` espaçador sem `background-color` — a regra NADA IMPLÍCITO cobria texto (GV3) mas não o vazio | Fundo explícito em todo spacer/divisor | **GV6b** |

> **REVISÃO DO DEFEITO 9 (mesma data, após reenvio).** A correção de fundo NÃO resolveu:
> inspeção do arquivo enviado provou o `background-color:#FFFFFF` presente em todos os
> spacers, e as faixas persistiram no Outlook — **a hipótese da causa estava errada.**
> Causa revisada, por eliminação com evidência dos gates anteriores: o construto de
> divisor em 3 linhas (spacer + border-top + spacer) é que o motor Word renderiza como
> faixas; spacers isolados e linha simples sempre renderizaram limpos. **Correção
> estrutural:** divisor vira td externo com padding vertical + linha de 1px via
> `bgcolor` (atributo nativo do Word) com `mso-line-height-rule:exactly`. O GV6b
> (fundo em spacer) permanece — é barato e coerente com NADA IMPLÍCITO — mas deixa de
> ser apontado como a correção do 9. No retrofit, o GV2 reprovou o td novo do divisor
> (padding sem align) na primeira auditoria — corrigido; os guardas policiando o
> próprio conserto é o sistema operando como desenhado.

**Latência retroativa medida e corrigida:** o GV6 varreu o acervo e reprovou os spacers
de TODOS os templates promovidos (base, componentes, os 3 ET + amostras) — o defeito
sempre existiu, só ficou visível nos divisores maiores da newsletter. Correção em lote
com versão nova: **base v0.4 · componentes v0.3 · ET v0.2 (todos)**. Diferença exclusiva:
fundo nos spacers. Regressão pós-correção: **284 PASS / 0 FAIL nos 14 arquivos do acervo.**

### Ciclo final do gate EA+EN — defeitos 10 e 11, veredito final do 9, e a promoção

**Veredito final do defeito 9 (terceira e última revisão, com crédito ao Rafael):** os
prints em três zooms diferentes do Outlook provaram que **qualquer linha-espaçadora com
`&nbsp;` fantasmagoriza como faixa cinza em zoom ≠100% no motor Word** — inclusive
spacers de 8px com fundo branco declarado. Regra canônica resultante: **espaçamento
vertical em e-mail é padding e margin; o divisor é td com padding + linha de 1px via
`bgcolor` + `mso-line-height-rule:exactly`.** A newsletter v3.1+ tem zero row-spacers.
Nota de transparência: houve uma reclassificação prematura minha ("artefato benigno de
zoom") entre a 2ª e a 3ª evidência — derrubada pelo print seguinte do Rafael e registrada.

| # | Defeito | Causa | Correção | Guarda |
|---|---|---|---|---|
| 10 | "@@" no texto e botão flutuando dentro do parágrafo (Outlook) | **Erro de ferramenta do produtor:** uma linha "no-op" num script de edição avaliava para `replace("</p>","@@")` e destruiu todos os fechamentos de parágrafo; a suíte passou 42/42 porque nada verificava balanceamento | 9 `</p>` restaurados pela inversa exata; balanceamento conferido | **GV7** (tags p/h1/h2/ul/table balanceadas + sentinela residual) |
| 11 | Logo da assinatura quebrado nos e-mails (anônima ok, Content-Type ok) | **Artefato composto desatualizado:** o EA3-b trocou o logo para o vertical, mas o comercial — que EMBUTE a assinatura — não foi regenerado e saiu pedindo o PNG aposentado, inexistente no bucket | Comercial regenerado com asserção dupla (URL vertical presente, aposentada ausente); regra: peça que embute outra regenera junto | **GV8** (lista viva de assets aposentados; referência reprova) |

**Decisão do Rafael — row-spacers do acervo (2026-08-08, "aprovo b"):** TOLERÂNCIA
MONITORADA. Os templates promovidos (base v0.4, componentes v0.3, ET v0.2) mantêm o
construto antigo — passaram nos gates reais, o fantasma é cosmético e dependente de
zoom, e a régua do projeto veta editar canônico promovido sem motivo funcional (mudaria
8 MD5 ancorados por estética condicional). A regra "espaçamento por padding" vale para
TODO template novo; o retrofit de um template existente acontece quando ele for editado
por outro motivo. *Alternativa descartada:* retrofit completo imediato (uniformidade
técnica ao custo de re-gate de 8 arquivos sem defeito funcional).

### Promoção final — EA + EN (fecha a produção da Fase 4)

**2026-08-08 — Rafael aprovou** ("aprovo b"). Evidências do gate combinado: newsletter
v3.2 limpa no Outlook em 100% e 120% (defeitos 9 e 10 mortos com prova) · comercial v2
aprovado na percepção ("e-mail de pessoa") com o logo vertical carregando · assinatura
**instalada no Gmail real do diretor**, renderizando na janela de composição com dados
reais e os três links ativos.

**Balanço da fase: 11 defeitos reais encontrados pelo gate humano, 11 corrigidos, 8
famílias de guarda permanentes (GV1–GV8). Nenhum dos 11 era visível às verificações
automatizadas antes do olho do Rafael.** Com EA e EN, os 6 sub-blocos da F4 (EM · EL ·
EC · ET · EN · EA) estão `estável`.

## 9. Supersedes formais

| O que morre | O que passa a valer | Motivo |
|---|---|---|
| EM11 original (origem em Supabase Storage) | **EM11-b** — Cloudflare R2 | Fato novo: a SEED já opera Cloudflare. Domínio próprio nativo, custo zero, e desacoplamento do ciclo de vida do ERP |
| EM12-b (trial de preview obrigatório) | **EM12** original — trial opcional | A premissa caiu: há Outlook 2024 clássico disponível para teste |
| Racional original do EM13-b (risco de quebrar o SPF do raiz) | Racional de **reputação isolada** | O racional original era factualmente incorreto; a conclusão sobreviveu |
| Piso de 3:1 aplicado a divisor e borda | **Isenção declarada** da seção 4.3 | Classificação inicial errada: são decorativos, não objetos gráficos essenciais |
| Rodapé sobre canvas em cinza-600 | **cinza-700** | Medição: 4.37 reprovava AA; 6.03 aprova |

---

## 10. Registro de versões

| Versão | Data | Conteúdo |
|---|---|---|
| **0.11** | 2026-08-09 | **Correção de estado congelado — nenhuma decisão, supersede ou artefato muda** (mesma classe da errata de cabeçalho corrigida no `seed-ds-roadmap.md` v1.8). Três pontos estavam parados no escopo da v0.2 enquanto o corpo já continha os 6 sub-blocos `estável`: (a) o **cabeçalho** declarava "EM+EL estáveis, base v0.3, GV1–GV4" e "EC/ET/EN/EA ainda não escritos" — reescrito para refletir a Fase 4 completa, com a lista de artefatos vigentes e GV1–GV8; (b) a **tabela de fases do §0** marcava a F4 como "🔄 em produção" — corrigida para ✅ concluída; (c) a **pendência "EC/ET/EN/EA não escritos" do §8** — marcada RESOLVIDA com referência às §§8-B–8-E, linha riscada mantida para rastreabilidade. As demais pendências do §8 permanecem intactas: ou seguem realmente abertas (rodapé com dado real, trilha EN5, clientes fora da matriz mínima), ou não têm comprovação de resolução dentro deste arquivo (Cache Rule) — não se corrige por memória. Divergência detectada na verificação de retomada pós-marco v1.5 (2026-08-09); correção imediata por decisão do Rafael de não deixar a pendência para trás. |
| **0.10** | 2026-08-08 | **PROMOÇÃO FINAL — EA e EN a `estável`; os 6 sub-blocos da F4 fechados.** Veredito final do defeito 9 (row-spacer × zoom; padding como técnica canônica), defeitos 10 (GV7) e 11 (GV8), decisão "aprovo b" da tolerância monitorada para o acervo. Newsletter consolidada em v3.2 (zero row-spacers, tags balanceadas), comercial v2 com assinatura vertical embutida, assinatura EA v0.2 instalada e provada em produção real. Balanço da fase: 11 defeitos do gate, 11 corrigidos, GV1–GV8. |
| **0.9** | 2026-08-08 | Gate EN: defeitos 8 (chaves órfãs — erro de geração com asserção fraca, GV6a) e 9 (spacer sem fundo no Outlook, GV6b). **Correção retroativa em todo o acervo** (base v0.4, componentes v0.3, ET v0.2). 284 PASS / 0 FAIL em 14 arquivos. |
| **0.8** | 2026-08-08 | Sub-blocos **EA** (assinatura: canônico + amostra + guia + PNG novo `logo-seed-assinatura@2x.png` MD5 `15f8f4821677cfddb81a868681ea9a1d`) e **EN** (newsletter modular de 4 módulos + comercial texto-puro, com amostras) em `rascunho`. 3 refinamentos de suíte documentados (URL-placeholder, modo fragmento, GV3 na assinatura). 110 PASS / 0 FAIL nos 6 arquivos novos; regressão 60/0. |
| **0.7** | 2026-08-08 | **Promoção do ET a `estável`** pelo gate do Rafael: 9 evidências em 3 motores, zero defeito novo. Fase com EM/EL/EC/ET fechados; restam EN e EA. |
| **0.6** | 2026-08-08 | Sub-bloco **ET** em `rascunho`: 3 transacionais (proposta · fatura · alerta) compostos sobre o base v0.3, inventário de placeholders mustache como contrato com o ERP, supersede ET7 do From (`notificacoes@`) registrado na EM14. 120 PASS / 0 FAIL nos 6 arquivos. |
| **0.5** | 2026-08-08 | **Promoção do EC a `estável`** pelo gate do Rafael: EC1–EC8, preview v0.2, GV5. Confirmação da correção dos achados 6 e 7 nos três clientes da matriz. Nota cosmética número/unidade registrada sem bloqueio. |
| **0.4** | 2026-08-08 | Gate visual do EC: achados 6 (nowrap em valores) e 7 (barra de severidade → border-left, supersede da anatomia EC2, guarda GV5). Preview v0.2, suíte com 20 verificações. |
| **0.3** | 2026-08-08 | Sub-bloco **EC** em `rascunho`: consolidado EC1–EC8 aprovado, seção 8-B com as 8 decisões, preview canônico `seed-email-componentes.html` v0.1 herdando o template-base v0.3 (19 PASS / 0 FAIL), errata de suíte do atributo booleano registrada. Aguardando gate visual da matriz real. |
| **0.2** | 2026-08-08 | **Promoção a `estável`** dos sub-blocos EM+EL e do template-base v0.3, pelo gate do Rafael. Nova §7.2 com o ciclo completo de gate (5 defeitos reais em 3 clientes, todos corrigidos e virados guarda GV1–GV4), §7.3 com o registro da promoção, decisões novas EL9 (corpo 16px) e EL10 (espaçador em vez de margin), regra unificada NADA IMPLÍCITO, protocolo de gate sem encaminhamento, e atualização das pendências (placeholders do rodapé, política de chave descartável, clientes pendentes). |
| **0.1** | 2026-08-07 | Primeira entrega da Fase 4. Sub-blocos EM (fundamento técnico, EM0–EM15) e EL (layout, EL1–EL8). Paleta resolvida com 14 pares medidos e 0 reprovações. Infraestrutura montada e verificada: Cloudflare R2 + `assets.seed.eng.br` ativo; Resend + `envio.seed.eng.br` verificado com DKIM/SPF/MX/DMARC. Cinco supersedes formais registrados, incluindo duas correções de erro do próprio autor (racional do EM13-b e classificação de contraste decorativo). Estado: `rascunho`, aguardando gate visual. |

---

*Arquivo canônico do Design System v2 da SEED engenharia. Produzido por Claude sob direção
de Rafael Sant'Ana. Nada aqui é promovido a `estável` sem aprovação explícita após gate
visual.*