docs: documentar decisiones MVP de cola persistente en README y STATUS

Co-authored-by: aider (openrouter/openai/gpt-5) <aider@aider.chat>

README.md

@@ -41,6 +41,48 @@ graph TD
 ```
 *(Diagram updated for planned flow)*
 
+## Decisiones de diseño de la cola de respuestas (MVP)
+1) Persistencia: 100% persistente (tabla única).
+2) Worker: continuo en background.
+3) Locking: status=processing (sin lease).
+4) Orden: sin orden estricto por chat.
+5) Reintentos: sin reintentos en MVP.
+6) Errores: 4xx = fallo definitivo; 5xx/red = fallo (sin reintentos).
+7) Idempotencia: no.
+8) Esquema DB: tabla única response_queue.
+9) Transporte: envío desde ResponseQueue (fetch directo a Evolution API).
+10) Concurrencia: N workers globales.
+11) Integración: encolar y worker continuo (arranca con el servidor).
+12) Configuración: defaults fijos (sin nuevas env vars por ahora).
+13) Limpieza: sin limpieza/retención de historiales (por ahora).
+14) Seguridad: no enviar al número del bot (CHATBOT_PHONE_NUMBER).
+15) Pruebas: unitarias de cola con mocks de fetch.
+
+## Arquitectura de la cola persistente (MVP)
+- Estados: queued | processing | sent | failed.
+- Campos mínimos por mensaje: id (PK), recipient, type (text), payload_text, status, attempts (0), last_error (nullable), created_at, updated_at.
+- Índices recomendados: (status, created_at) para seleccionar pendientes rápidamente.
+- Sin orden estricto por chat; el envío puede intercalarse entre destinatarios.
+- Concurrencia: N workers globales operando en bucle, cada uno toma mensajes en estado queued y los marca processing.
+
+## Flujo del worker continuo (MVP)
+- Se inicia al arrancar el servidor (desactivado en tests).
+- Ciclo: seleccionar hasta un pequeño batch de mensajes queued, marcar processing, enviar a Evolution API, marcar sent o failed según respuesta.
+- Sin reintentos; logs mínimos y no sensibles.
+
+## Limitaciones explícitas del MVP
+- Sin backoff ni reintentos.
+- Sin orden garantizado por chat.
+- Sin idempotencia ni limpieza automática.
+- Sin lease; en caso de crash podrían quedar mensajes en processing que requerirán recuperación manual en una iteración futura.
+
+## Plan incremental posterior
+- Añadir reintentos con backoff exponencial y jitter.
+- Garantizar orden por chat (serialización por recipient).
+- Introducir lease (lease_until) para tolerancia a fallos y recuperación.
+- Limpieza/retención y métricas/observabilidad.
+- Opcional: idempotencia e índices adicionales.
+
 ## ✅ Current Status (as of latest commit, all tests passing)
 ### Implemented
 - Webhook server setup (`src/server.ts`) receiving Evolution API events.

STATUS.md

@@ -34,7 +34,7 @@
 - **Cola de Respuestas**
   - Sin integración con Evolution API
   - No envía mensajes realmente
-  - **Persistencia en DB pendiente** (importante para evitar pérdida de mensajes en reinicios)
+  - **Persistencia en DB en progreso** (importante para evitar pérdida de mensajes en reinicios)
 - **Validaciones**
   - Permisos de usuario no implementados
   - Sin verificación de pertenencia a grupos
@@ -42,12 +42,14 @@
   - Acciones de tareas no implementadas (crear/listar)
 
 ## ➡️ Próximos Pasos Prioritarios
-1. Implementar procesamiento de cola de respuestas
+1. Documentar decisiones del MVP de cola persistente (este cambio)
-2. Conectar comandos con servicio de tareas
+2. Definir esquema de DB (tabla única response_queue) e incluirlo en initializeDatabase
-3. Añadir validaciones de seguridad
+3. Actualizar tests de DB para la nueva tabla
-4. Completar CRUD de tareas
+4. Adaptar ResponseQueue.add a persistente (insert en DB)
-5. Manejar eventos de actualización de grupos
+5. Implementar worker continuo básico (N workers, sin reintentos, sin orden estricto)
-6. **Persistir cola de respuestas en DB** (para fiabilidad)
+6. Integrar el worker en server.start (desactivado en entorno de test)
+7. Añadir tests unitarios de la cola con mocks de fetch
+8. Iteración siguiente: reintentos con backoff exponencial y mejoras de observabilidad
 
 ## 🔧 Archivos Clave a Modificar
 - `src/services/response-queue.ts`