---
fonte: 01-canonicos/seed-email.md
versao_da_fonte: v0.13
secao: 05
titulo: "Decisões EM — fundamento técnico"
sequencia: 8 de 17
bytes_do_corpo: 16538
md5_do_corpo: c024bfc34e499bd4e2b587b83a154213
gerado_por: 06-validacao/geradores/gen-camada-ia.py
nota: fatia GERADA — o corpo abaixo é byte a byte o trecho do canônico; edite o canônico, nunca esta fatia. Canônico inteiro em https://ds.seed.eng.br/01-canonicos/seed-email.md
---
## 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.

---