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