# ADR-003 — Provider de e-mail

- Status: Proposed
- Data: 2026-10-02
- Pendência: P-011
- Relacionada: P-001
- Decisão: nenhuma

## Contexto

Download e e-mail usam o PDF da versão formal exibida. O envio não muda o status `Gerada`. A documentação de ecossistema cita Resend em outros contextos. Isso não formaliza o provider deste módulo.

P-001 também segue aberto: o que fazer quando o workspace não tem e-mail comercial para Reply-To.

## Alternativas

1. Resend. Citado fora deste módulo. Não adotado aqui.
2. Outro provider HTTP transacional.
3. SMTP operado por este produto.
4. Não enviar até haver provider e regra de Reply-To. É o comportamento do port hoje, não uma escolha de produto para o MVP.

## Critérios para sair de Proposed

- Provider nomeado, conta e ambiente definidos.
- O anexo é o `pdfRef` da versão exibida, não uma nova renderização.
- Falha de envio não altera status, número nem versão.
- Reply-To: ou o e-mail comercial do workspace, ou a regra explícita de P-001. O provider não inventa remetente.
- Evento em `proposal_email_events` com resultado e id do provider quando houver.
- Corpo, assunto e destinatário não vão para o Sentry.

## Impacto no código desta fase

`ProposalEmailProvider` devolve `blocked / P-001` sem Reply-To resolvido e `blocked / P-011` quando o Reply-To existe mas não há provider. Não há cliente HTTP.

## Impacto no prompt 02

A tabela `proposal_email_events` pode ser criada com `provider_message_id` anulável e `result` textual. Não gravar um check constraint com o nome de um provider.

## O que aprovar o provider não decide

P-001 continua uma pendência separada. Aprovar Resend, ou outro nome, não define o fallback de Reply-To.