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).

4.7 KiB Raw Blame History