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:

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.

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#

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.

---