| Campo |
Valor |
| Story |
Envío del formulario de contacto |
| Módulo / Epic |
[CONTACTO] |
| ID |
CONT-001 |
| Estado |
Ready |
| Prioridad |
Alta |
| Jira |
EJEMPLO-101 |
Como visitante del sitio,
quiero enviar un mensaje desde el formulario de contacto,
para comunicarme con el negocio sin tener que buscar un correo o teléfono.
- El visitante puede enviar el formulario con nombre, correo y mensaje.
- El mensaje se entrega al correo configurado del equipo.
- Si falta un campo obligatorio o el correo es inválido, se muestra un error claro
sin recargar la página.
- Al enviar con éxito, el visitante ve una confirmación visible.
- Cada envío queda registrado para trazabilidad.
- Correo con formato inválido (
juan@, @dominio.com).
- Mensaje vacío o solo espacios.
- Envío doble por doble clic (evitar duplicados).
- El servicio de correo no está disponible al momento del envío.
- Intento de spam / bot (se cubre a fondo en CONT-002).
- CONT-002 (validación y antispam) — refuerza este envío.
- CONT-003 (notificación por correo) — es el canal de entrega.
| Story |
Jira Issue |
Tipo |
Estado |
| CONT-001 |
EJEMPLO-101 |
Story |
Ready |
Ver Story Refinement arriba — ahí ya están los criterios de
aceptación y casos límite. En una línea: que un visitante pueda enviar un mensaje
sin fallas silenciosas ni duplicados.
Formulario controlado en el cliente que valida en vivo y envía a un endpoint que
vuelve a validar en servidor, registra el envío y dispara el correo. Sin colas ni
servicios externos — el volumen no lo justifica todavía.
- Endpoint
POST /api/contacto que recibe nombre, correo y mensaje.
- Validación en servidor (no confiar solo en el cliente).
- Envío de correo al buzón configurado del equipo.
- Registro del envío (timestamp, origen, estado de entrega) para trazabilidad.
- Control de duplicados por idempotencia o ventana corta de tiempo.
- Componente
FormularioContacto con los tres campos + botón de envío.
- Validación en vivo y mensajes de error accesibles, sin recargar.
- Estado de carga en el botón y confirmación visible al enviar.
- Usa tokens y componentes del Design System del proyecto (DS-First).
- No aplica funcionalidad de IA en esta Story.
- La detección de spam asistida se evalúa en CONT-002.
- No almacenar datos sensibles más allá de lo necesario para el contacto.
- Cumplir con la política de retención de datos del proyecto.
- Respetar
prefers-reduced-motion en las transiciones del formulario.
- El control de duplicados (doble clic) es fácil de subestimar: debe cubrir tanto
el doble submit en el cliente como un reintento de red ya en servidor.
- Si el servicio de correo falla a media entrega, el envío debe quedar registrado
igual — no perder trazabilidad solo porque el correo no salió.
- No se construye cola de mensajería ni reintentos automáticos en esta Story.
- No se implementa aquí la detección de spam — eso es CONT-002.
- CONT-002 · Validación y antispam — refuerza este envío.
- CONT-003 · Notificación por correo — el canal de entrega.
| Descripción |
Jira Issue |
Tipo |
| Endpoint + validación de servidor |
EJEMPLO-201 |
Task |
| Componente de formulario (DS) |
EJEMPLO-202 |
Task |
| Registro y trazabilidad de envíos |
EJEMPLO-203 |
Task |