taskbot/STATUS.md

Estado del Proyecto — Task Manager para WhatsApp

Estado general: listo para piloto con la junta directiva; 170 tests pasando. Riesgos operativos principales: CI/CD básico, red interna entre Evolution API y el bot, y backups/persistencia.

Hecho (por áreas)

• Servidor webhook
  • Endpoint /health, validación de entorno, extracción robusta de texto (conversation/extended/captions).
  • Detección DM vs grupo y política “solo DM”.
  • Registro/verificación de webhooks y sincronización de grupos activos con caché.
  • Rate limiting por usuario (15/min por defecto; desactivado en tests; aviso con cooldown).
• Base de datos y migraciones
  • Inicialización con PRAGMA FK y timestamps de alta precisión.
  • Esquema: users, tasks, task_assignments, user_preferences, response_queue (con metadata).
  • Migrador up-only con tabla schema_migrations; backup automático con VACUUM INTO; baseline si existe esquema previo.
• Cola de respuestas
  • Persistente con workers en background, reintentos con backoff exponencial + jitter, recuperación de items processing tras reinicios, y limpieza/retención.
  • 2xx=sent, 4xx=failed definitivo, 5xx/red=reintento; evita enviar al propio bot.
• Comandos
  • Crear, listar (grupo/mis/sin/todos), completar, tomar, soltar; ayuda por DM.
  • Fechas “hoy/mañana” con TZ configurable; formato dd/MM; vencidas con ⚠️.
  • Menciones reales y tokens @…; reglas por defecto: grupo→sin responsable, DM→creador.
• Recordatorios por DM
  • Preferencias por usuario (daily|weekly|off; hora con soporte en modelo/servicio), evita duplicados por día, weekly en lunes, respeta TZ, no envía si no hay tareas.
• Contactos y nombres
  • Caché en memoria, actualización por webhooks, fallback a Evolution API (saltado en tests); nombres amigables en textos.
• Testing
  • ~170 tests unitarios con SQLite en memoria; ResponseQueue (reintentos/cleanup), comandos (alias/fechas/listados/x/tomar/soltar), recordatorios, utilidades.

Pendiente (priorizado)

• MVP operativo (bloqueantes/casi bloqueantes)
  1. CI/CD: pipeline mínimo (build + bun test + build/push imagen + despliegue CapRover).
  2. Persistencia/backup: volumen /app/data y backup diario del fichero SQLite.
  3. Seguridad/red: ejecutar en red interna con Evolution API; si no, proteger el webhook (IP allowlist/reverse proxy).
  4. Ensayo E2E en staging: registro de webhook, recepción de MESSAGES_UPSERT reales y envío de DMs.
• Post-MVP (mejoras)
  • Observabilidad: /metrics con contadores de cola, errores y latencias.
  • Orden por destinatario en ResponseQueue; idempotency_key opcional.
  • Permisos/roles y pertenencia a grupos (si se requiere).
  • Edición/eliminación de tareas.
  • Política de caché de contactos (TTL configurable, invalidación más fina).
  • Sincronización mínima de miembros (cacheada; no bloqueante).

Roadmap y próximas iteraciones

• Iteración A — Operativa lista para piloto
  • Entregables: pipeline CI (GitHub Actions), build de imagen, despliegue CapRover con volumen /app/data, backup diario configurado, checklist de red interna verificada.
• Iteración B — Observabilidad mínima
  • Entregables: logs con contexto en puntos clave, plan de /metrics (pospuesto si no es crítico), guía de troubleshooting.
• Iteración C — Calidad de datos/UX
  • Entregables: mejoras de caché de contactos, afinado de recordatorios (hora por usuario), pruebas adicionales de ResponseQueue y comandos.

Checklist de readiness para piloto

• Infra
  • App en CapRover con volumen /app/data.
  • Variables de entorno configuradas; TZ correcta.
  • Evol. API y bot en la misma red; /health OK.
• Operación
  • Backups diarios de data/tasks.db y procedimiento de restauración.
  • Logs accesibles; worker de cola activo.
• Funcional
  • Bot añadido a los grupos; grupos activos sincronizados.
  • Comandos base verificados en un grupo real (crear/ver/x/tomar/soltar/configurar).
• Comunicación/privacidad
  • Aviso a la junta: cómo usar, qué se guarda, cómo desactivar recordatorios.

Riesgos y mitigaciones

• Webhook expuesto públicamente
  • Mitigación: red interna; si no es posible, IP allowlist/reverse proxy y rotación de claves.
• Pérdida de datos en SQLite
  • Mitigación: volumen persistente + backups diarios + prueba de restore.
• TZ incorrecta y mensajes con fecha errónea
  • Mitigación: fijar TZ en entorno, tests de humo con “hoy/mañana”.
• Fallos o latencia de Evolution API
  • Mitigación: reintentos con backoff; logs de error; visibilidad en ResponseQueue.

Testing y cobertura

• Cubre: comandos, ResponseQueue (reintentos/cleanup), recordatorios (daily/weekly/TZ), utilidades, normalización de IDs, validaciones básicas en servidor.
• Falta: pruebas E2E reales contra Evolution API (recomendado antes del piloto).

Notas de despliegue/operación

• Migraciones up-only al arranque; backup con VACUUM INTO previo.
• Persistencia en data/; mapear a volumen y monitorizar tamaño; ejecutar VACUUM periódicamente si procede.
• Rotación de logs vía orquestador; considerar niveles/etiquetas para búsquedas.

Changelog breve

• Reintentos/backoff y recuperación de ResponseQueue: completado.
• Recordatorios por DM (daily/weekly) con preferencias: completado.
• Rate limiting por usuario: completado.
• Ayuda por DM y formato de mensajes unificado: completado.
• Limpieza/retención de historiales de cola: completado.