- Mantener compatibilidad hacia atrás: en creación de tareas, si el group_id no está allowed, persistir sin group_id (null).
- No bloquear DMs por diseño (gating aplica solo a grupos).
- Reutilizar ResponseQueue para todas las notificaciones (incluyendo admins).
Plan detallado etapa por etapa (con impacto en tests y archivos a tocar)
Convenciones transversales para no romper la suite:
- Nueva variable GROUP_GATING_MODE = 'off' | 'discover' | 'enforce'. Valor por defecto: 'off' (especialmente en tests). Solo se activará en tests específicos.
- Si prueba mensajes de grupo, usar seedAllowed(db, ['<group_id>']).
- Resto de suites: sin cambios esperados.
Etapa 3 — Gating mínimo en superficies críticas
Objetivo
- Bloquear comandos y sync en grupos no allowed cuando GROUP_GATING_MODE='enforce'.
Cambios de código
- src/services/command.ts:
- Al inicio, si message viene de grupo y GROUP_GATING_MODE='enforce', llamar AllowedGroups.isAllowed(groupId). Si no allowed: política por defecto “silencio” o respuesta breve configurable.
- src/services/group-sync.ts:
- Filtrar operaciones a solo grupos AllowedGroups.isAllowed.
- src/server.ts:
- Antes de encolar/ejecutar comandos, si es grupo y 'enforce', exigir allowed.
- src/services/metrics.ts:
- commands_blocked_total
- sync_skipped_group_total (opcional)
Tests nuevos a añadir
- tests/unit/services/command.gating.test.ts
- tests/unit/services/group-sync.gating.test.ts
Tests existentes a actualizar
- tests/unit/services/command.claim-unassign.test.ts: sembrar grupo allowed en beforeAll/beforeEach o fijar GROUP_GATING_MODE='off'.
- tests/unit/services/command.reminders-config.test.ts: idem si el test ejecuta comandos en contexto de grupo.
- tests/unit/services/command.date-parsing.test.ts: normalmente DM; no tocar salvo que simule grupo.
- tests/unit/services/group-sync.members.test.ts: sembrar grupo allowed para '123@g.us'.
- tests/unit/services/group-sync.scheduler.test.ts: sembrar grupos allowed en el scheduler o setear mode='off'.
- tests/unit/tasks/claim-unassign.test.ts: si hay contexto de grupo, seedAllowed; si es DM, sin cambios.
- tests/unit/services/cleanup-inactive.test.ts, tests/unit/services/metrics-health.test.ts, tests/unit/services/response-queue*.test.ts, tests/unit/services/reminders.test.ts: no deberían requerir cambios; si alguno falla por simulación de grupo, aplicar seedAllowed o mode='off'.
Etapa 4 — Flujo de aprobación administrativa y notificaciones
Objetivo
- Permitir a ADMIN_USERS aprobar/bloquear grupos y consultar pendientes; notificar a admins al descubrir pending.
- src/services/response-queue.ts (o webhook-manager): enviar DM a ADMIN_USERS en descubrimiento pending (best-effort y detrás de flag para no romper tests existentes).
- docs/operations.md: documentar variables y comportamiento.
- docs/architecture.md: sección de control de acceso por grupos.
- Confirmar /metrics en src/server.ts.
Tests nuevos a añadir
- Opcional: tests/unit/services/metrics-health.test.ts puede ampliar cobertura para nuevos contadores (no estricta; tolerar ausencia si METRICS_ENABLED='false').
Tests existentes a actualizar
- tests/unit/services/metrics-health.test.ts: si asume conjunto exacto de métricas, flexibilizar aserciones o aislar nuevas métricas tras METRICS_ENABLED.
Etapa 7 — Hardening, regresión y rollout
Objetivo
- Validar que no hay rutas sin gating y que la activación progresiva no rompe nada.
Cambios de código
- Ninguno obligatorio más allá de ajustes menores.