motor-de-encuestas/BACKLOG.md

BACKLOG.md

Ítems pendientes que no entran en el sprint actual. El agente NO los ejecuta sin aprobación del director (Nivel 3 salvo indicación contraria).

---

Seguridad

[SEC-004] RPC de submit es bypasseable vía REST directo (coherencia de flujo)

• Estado: Riesgo residual documentado — no resuelto en Etapa 4G
• Contexto: rpc_submit_response (migración 20260624000001_submit_rpc.sql) es el único camino de escritura para consent_records/responses/answers (las policies WITH CHECK(true) que permitían INSERT directo a anon se eliminaron). La RPC valida lo ESTRUCTURAL en SQL (el question_id pertenece a la encuesta, la encuesta está viva, el consentimiento llegó). La validación de COHERENCIA DE FLUJO (visibilidad según conditional_rules, instancias legítimas de 4.1) vive en TypeScript (lib/submit-validation.ts, reusa lib/form-engine.ts) porque reimplementarla en SQL violaría la regla de "no duplicar la lógica de flujo" (BRIEF 4G).
• Riesgo: quien llame a rpc_submit_response directo por la REST API de Supabase (sin pasar por el Server Action de Next.js) puede mandar un payload con instancias/visibilidad incoherentes que igual pase las validaciones estructurales de la RPC.
• Por qué no es un incidente de privacidad: el dato resultante sigue siendo anónimo (respondent_id=NULL), is_sensitive se sigue respetando, y queda sujeto al umbral k-anonimato en agg_segment/RPCs de dashboard igual que cualquier otra respuesta. Es un problema de calidad de datos de investigación (una respuesta lógicamente imposible podría colarse), no de exposición de datos.
• Cierre posible (no implementado): firmar el payload en el Server Action (HMAC con un secreto server-only) y verificar la firma dentro de la RPC antes de insertar — así un caller directo sin el secreto no puede producir un payload válido. Evaluar costo/beneficio antes de priorizar.
• Dependencia: no bloquea Sprint 4; evaluar junto con SEC-002 (sprint de compliance).

[SEC-002] Sprint de compliance & seguridad

• Estado: Diferido — pendiente de priorizar tras Sprint 4
• Contexto: COMPLIANCE.md documenta el estado actual de seguridad (v2.1.0) y el roadmap de hardening. Antes de escalar a más empresas o datos reales, se requiere un sprint dedicado.
• Ítems principales (ver COMPLIANCE.md secciones 5 y 6):
  • Registro de auditoría append-only (log inmutable de operaciones sensibles)
  • Hashing SHA-256 de integridad de respuestas (detección de tampering sin blockchain)
  • Cifrado en reposo a nivel de volumen/disco de la base de datos
  • Roadmap de hardening por capas: aplicación, autenticación, datos, infraestructura, observabilidad y proceso (revisión periódica de CVEs, pen testing)
• Dependencia: no bloquea Sprint 4; sí bloquea escalar a producción masiva.
• Ver: COMPLIANCE.md secciones 5 y 6.

[SEC-001] Actualizar Next.js — CVE pendiente en 15.3.3

• Estado: Pendiente
• Prioridad: Alta
• Contexto: Next.js 15.3.3 tiene un CVE conocido. La versión no se actualizó en la tarea del 2026-06-02 para no mezclar cambios con el fix de producción de chromedriver. Actualizar en el próximo ciclo de mantenimiento.
• Acción: npm install next@latest + verificar que el build y la app sigan funcionando antes de deployar.
• Nota: revisar changelog de Next.js por breaking changes antes de actualizar.

---

Técnico / Deuda

[TECH-001] npm audit reporta 2 vulnerabilidades en deps de producción

• Estado: Pendiente de revisión
• Contexto: npm audit señala 1 moderate + 1 critical. Evaluar con npm audit --json si afectan el runtime de la app o solo herramientas de build.
• Acción: npm audit fix (o fix manual) y re-verificar build.

[TECH-002] Mockup formulario_mapeo.html no encontrado en el árbol de trabajo

• Estado: Pendiente
• Contexto: El BRIEF Sprint 2 lo cita como "contrato visual". El agente diseñó la UI basándose en SEED_SPEC.md. Requiere validación visual del director contra el mockup original.

[TECH-003] Auditoría a11y interactiva pendiente (foco, aria-expanded, widgets)

• Estado: Pendiente
• Contexto: La auditoría de Etapa 2A se corrió sobre el HTML SSR estático (jsdom). La verificación de componentes interactivos (foco al abrir bloque condicional, aria-expanded en triggers, operación solo con teclado) requiere auditoría en browser real.
• Acción: Correr axe-cli con Chrome 149+ (o actualizar Chrome a 149) y hacer test manual de navegación por teclado.

---

Features

(Sprint 3 y posteriores — ver ARCHITECTURE.md y BRIEF por sprint)

[BACKLOG-001] Consentimiento inicial editable desde admin

• Estado: hoy el texto del consentimiento está hardcoded en consent-screen.tsx.
• Necesidad: cuando se construya el motor de formularios (builder), el texto del consentimiento debe ser editable por encuesta desde la administración, para reflejar cambios en política de privacidad o ajustes específicos por tipo de relevamiento.
• Bloquea: implementación del builder visual.
• Decisión cerrada: la edición es desde admin, no desde el código.

---

[BACKLOG-002] Fase 2 — Motor genérico de formularios

• Estado: Diferido post-deadline

• Contexto: En Sprint 4 se construye un intérprete del esquema declarativo específico para el formulario de cuidadores (ADR-005, Fase 1). Una vez entregado ese caso, el intérprete se extrae a un motor universal que interprete cualquier esquema definido en questions.conditional_rules + campos de instanciación, sin hardcodear ningún formulario. El formulario de cuidadores se vuelve el primer caso de prueba del motor sin reescribir el contrato de datos.

• Dependencia: Fase 1 completada (Sprint 4 — wizard funcional).

• Ver: ADR-005 (docs/adr/ADR-005-esquema-declarativo-formularios.md).

• Dashboard / reportes (Sprint 3)

• Formulario de consentimiento + persistencia de respuestas (Etapa 2B)

• Builder visual de encuestas (post-validación del caso fijo)

• Integración LLM para análisis de texto libre (diferenciador)

• Modo B / controller_role dual (reservado en esquema)

• Columnas qi_gender / qi_modality en responses — decisión Nivel 3 abierta (ver hallazgo en SEED_SPEC.md)