33 lines
1.5 KiB
Markdown
33 lines
1.5 KiB
Markdown
# F-152 — Product Spec
|
|
|
|
## Problema
|
|
Los clientes no reciben confirmación por email ni al crear la cuenta ni cuando su
|
|
pedido se confirma tras el pago:
|
|
- `POST /auth/register` crea el usuario pero no envía email de bienvenida.
|
|
- El webhook de Stripe (`PaymentSucceeded`) pasa el pedido a `PAID` pero no
|
|
notifica al cliente (el `OrderEventPublisher` inyectado en payments es no-op y
|
|
`sendOrderStatusEmail` solo se llamaba desde transiciones admin).
|
|
|
|
## Objetivo
|
|
Que los clientes reciban los dos emails transaccionales esenciales:
|
|
1. **Welcome** al crear la cuenta (account_created).
|
|
2. **Order confirmation** cuando el pago se confirma (PaymentSucceeded → PAID),
|
|
reenviando el flujo ya existente de `sendOrderStatusEmail` (SMTP desde
|
|
*Ajustes → SMTP / Email*).
|
|
|
|
## Usuarios
|
|
- Usuario principal: cliente que se registra / compra en la tienda.
|
|
- Usuario secundario: operador (Ajustes SMTP) y admin (vee historial).
|
|
|
|
## Alcance v1
|
|
- In scope:
|
|
- Welcome email on `POST /auth/register` (best-effort, nunca bloquea el registro).
|
|
- Order confirmation email on `PaymentSucceeded` webhook (best-effort, nunca
|
|
rompe la reconciliación de pagos).
|
|
- Reusar el SMTP configurado en `store_settings` ya usado por admin transitions.
|
|
- Tests unitarios de cuerpo/email y de best-effort.
|
|
- Out of scope:
|
|
- Verificación por enlace (gating de cuenta por email) — queda como hardening.
|
|
- Reenvío de emails ya enviados (idempotencia garantizada por el webhook).
|
|
- Cambiar el email de transición admin existente.
|