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)