docs: actualizar estado — Mirada Empresa verificada

sprints/sprint-4/ETAPA_4H_PROMPT.md

@@ -0,0 +1,98 @@
+# ETAPA 4H — Migrar las RPCs del dashboard de códigos v2 a v3
+
+## 1. Objetivo
+Las 9 RPCs del dashboard referencian códigos de pregunta de v2 (`1.6`, `1.13`, `A6`,
+`A7`, `3.4`, `6.2`, etc.) que NO existen en el instrumento v3. Corriendo contra el seed
+v3 devuelven 0 en casi todo. Esta etapa migra los códigos v2→v3 para que el dashboard
+vuelva a funcionar con el instrumento nuevo. Es REPARACIÓN, no funcionalidad nueva.
+
+## 2. Contexto previo
+- Las RPCs viven en `supabase/migrations/20260605140001_012_dashboard_rpc_v2.sql`
+  + parche `20260611000001_dash_responses_all.sql` (flag p_all).
+- 9 RPCs públicas + 2 helpers (`_dash_responses`, `_dash_parse_filters`).
+- k-anonimato k≥5 en dos niveles (total y por-segmento) — NO tocar la lógica de k,
+  solo los códigos de pregunta.
+- Flag p_all = UUID sentinela `00000000-...` en `_dash_responses` — NO tocar.
+- El instrumento v3 está en el seed (códigos 2.1-10.1, 10 secciones). El mapeo de
+  códigos v2→v3 hay que derivarlo del seed v3 y del mockup validado.
+- Esta etapa NO incluye los datos de vínculo por instancia (4.2/4.3) — eso es la etapa
+  siguiente (vínculo). Acá solo se migran los códigos de las preguntas NO instanciadas.
+
+## 3. DECISIONES YA TOMADAS — no consultar de nuevo
+- Solo se migran CÓDIGOS de pregunta v2→v3 y los VALORES esperados si cambiaron
+  (ej. opciones de respuesta que se reescribieron en v3).
+- NO se cambia la lógica de k-anonimato, ni el flag p_all, ni la estructura de las RPCs.
+- NO se agregan las RPCs de vínculo (es la etapa siguiente).
+- Si una métrica de v2 ya no tiene pregunta equivalente en v3, se REPORTA (no se inventa
+  un mapeo) — decisión del director/metodología.
+- Migración nueva, no se editan las migraciones viejas de RPCs.
+
+## 4. Tareas
+
+### 4.1 Construir la tabla de mapeo v2→v3
+Antes de tocar SQL, derivar del seed v3 y documentar el mapeo de cada código v2 usado
+en las RPCs a su equivalente v3. Ejemplos a resolver (verificar contra el seed real):
+- `1.6`/`1.13` (triggers de cuidado v2) → ¿qué los representa en v3? (probablemente 4.1
+  con sus opciones de vínculo, o las preguntas de cuidado de S5-S7)
+- `A6`/`A7` (demográficas v2) → 2.x en v3
+- `3.4` (salario v2) → 8.4 en v3
+- `6.2` (apoyos v2) → 9.2 en v3
+- etc. — mapear TODOS los códigos que aparezcan en las 9 RPCs.
+Reportar esta tabla ANTES de escribir el SQL, porque algunos mapeos requieren confirmación
+(las métricas de "cuidador activo" cambian: v2 usaba 3 triggers, v3 usa 4.1 multi-opción).
+
+### 4.2 Migración nueva con las RPCs actualizadas
+Crear `supabase/migrations/2026XXXXXXXXXX_dashboard_rpc_v3.sql` que recree las 9 RPCs
+con los códigos v3. Mantener idéntica: estructura, lógica de k≥5, manejo de p_all,
+shape del JSON de retorno (para no romper los widgets).
+
+### 4.3 Verificar valores de respuesta esperados
+Algunas RPCs comparan contra valores literales (`a.value #>> '{}' = 'Sí'`). Si las opciones
+de respuesta cambiaron en v3 (wording), actualizar esos literales. Verificar contra el seed.
+
+### 4.4 Reportar métricas sin equivalente
+Si alguna métrica v2 no tiene pregunta v3 equivalente, listarla para decisión — no inventar.
+
+## 5. Entregables (DoD)
+- [ ] Tabla de mapeo v2→v3 documentada y reportada ANTES del SQL.
+- [ ] Migración que recrea las 9 RPCs con códigos v3.
+- [ ] Lógica de k≥5, p_all y shape de retorno SIN cambios.
+- [ ] Literales de valores de respuesta actualizados donde el wording cambió.
+- [ ] Métricas sin equivalente v3 reportadas (no inventadas).
+- [ ] NO incluye RPCs de vínculo (etapa siguiente).
+- [ ] NO aplicada a producción (solo archivo) hasta validación del director.
+
+## 6. Qué reportar
+```
+Verificado:
+- Tabla de mapeo v2→v3: [código v2 → código v3, por cada uno]
+- 9 RPCs migradas ✓
+- k≥5 sin cambios ✓ / p_all sin cambios ✓ / shape de retorno sin cambios ✓
+- Literales de valores actualizados: [cuáles]
+
+Métricas sin equivalente v3 (requieren decisión):
+- [lista o "ninguna"]
+
+Asumido:
+- [mapeos que asumió y conviene confirmar]
+
+NO aplicado a producción.
+```
+
+## 7. Qué NO hacer
+- ❌ No cambiar la lógica de k-anonimato, p_all, ni el shape del JSON de retorno.
+- ❌ No agregar las RPCs de vínculo por instancia (es la etapa siguiente).
+- ❌ No inventar mapeos para métricas sin equivalente — reportar.
+- ❌ No editar las migraciones viejas de RPCs.
+- ❌ No aplicar a producción sin validación.
+- ❌ No tocar v2.1.0-stable ni el motor.
+
+## 8. Versionado
+```
+fix(dashboard): migrar RPCs de códigos v2 a v3 [4H]
+
+Las 9 RPCs del dashboard referenciaban códigos v2 inexistentes en v3
+(devolvían 0 con el seed nuevo). Migrados a códigos v3. k-anonimato,
+flag p_all y shape de retorno sin cambios. No incluye datos de vínculo
+por instancia (etapa siguiente).
+```