# ETAPA 1B — Corrección del seed + ejecución/validación real

> Prompt versionado (Patrón B.1). Cierra los huecos que la auditoría encontró en la Etapa 1: seed
> inventado/incompleto y nada ejecutado. Claude Code lo ejecuta tras leer `CLAUDE.md`, `DATA_MODEL.md`,
> `SEED_SPEC.md` y este prompt.

## 1. Objetivo
Reescribir `supabase/seed.sql` para que refleje el instrumento real (34 preguntas) según
`SEED_SPEC.md`, y ejecutar la base contra el proyecto **Supabase Cloud** ya vinculado (sin Docker)
para verificar de verdad lo que la Etapa 1 dejó sin correr.

## 2. Contexto previo
La Etapa 1 creó esquema, RLS, triggers, `agg_segment` y un seed **incorrecto** (9 de 34 preguntas;
B1/C1/D1 tipadas como `yes_no`; supuesto inválido C1→G4; D1 sin reglas; falta Sección A). El esquema
NO se ejecutó (no había Docker). Ahora hay un proyecto Supabase Cloud vinculado (`supabase link`).

## 3. Decisiones ya tomadas (no consultar de nuevo)
- Las 34 preguntas, tipos, opciones y condicionales están en `SEED_SPEC.md` — es el contrato.
- `conditional_rules` van en la pregunta **dependiente** (`{if_question, op:'eq', value:'Sí', action:'show'}`).
- B1/C1/D1 = `single_choice` de 3 opciones; solo "Sí" dispara el bloque.
- `is_sensitive=true` en las preguntas marcadas en `SEED_SPEC.md`. Encuesta = `sensible`, anónima, Modo A.
- `qi_age_bucket`←A2, `qi_sector`←A1, `qi_zone`=NULL (no se pregunta zona).
- `respondent_id` sigue NULL (encuesta anónima).

## 4. Tareas
1. Reescribir `supabase/seed.sql`: 1 organización demo, 1 `consent_version` v1 (scopes
   `["operativo","macro_n1"]`), 1 `survey` (anónima/sensible/confidencial/Modo A/k=5), y las **34
   preguntas** con sus tipos, opciones, `max_select` (H1=3), `is_sensitive`, y `conditional_rules`
   en las dependientes (B2-B5, C2-C5, D2-D5).
2. Aplicar a Cloud: `supabase db push` y luego cargar el seed contra el proyecto vinculado.
3. Ejecutar las validaciones de la sección 6 contra la base real.

## 5. Definition of Done
- [ ] `seed.sql` con 34 preguntas que coinciden 1:1 con `SEED_SPEC.md`.
- [ ] `supabase db push` aplica limpio en Cloud (reportar si algún GRANT/policy falla — la auditoría sospechaba de 003/006).
- [ ] Seed cargado y consultable en el proyecto Cloud.
- [ ] Validaciones de la sección 6 verdes.
- [ ] `git diff --name-only HEAD` solo con `supabase/seed.sql` (+ tests si los tocás).

## 6. Validaciones automatizadas mandatorias (contra la base Cloud)
- Conteo: `SELECT count(*) FROM questions` = **34**; condicionales = **12** (B2-B5, C2-C5, D2-D5),
  cada una con `if_question` correcto y `value='Sí'`.
- Tipos: B1/C1/D1 son `single_choice` (no `yes_no`); H1 `multiple_choice` con `max_select=3`;
  F3/G4 `rating`; H3 `text_long`.
- `is_sensitive=true` en exactamente las preguntas marcadas en `SEED_SPEC.md`.
- RLS: como rol de organización, `SELECT * FROM responses` y `FROM answers` → **0 filas**.
- Constraint: `INSERT` en `responses` con `respondent_id` no nulo en encuesta anónima → ERROR.
- k-anonimato: `agg_segment` sobre un segmento sembrado con 3 respuestas → "n insuficiente"; con ≥5 → valor.
- Inmutabilidad: `UPDATE`/`DELETE` sobre `consent_records` → ERROR.
- Si CUALQUIERA falla: **NO declarar lista la etapa.** Reportar el fallo y esperar instrucciones.

## 7. Qué reportar
- **Verificado:** salida concreta de cada validación (conteos, resultado de `agg_segment` n=3 y n=5,
  comportamiento de RLS, errores esperados que efectivamente saltaron).
- **Asumido:** cualquier supuesto (ej. textos exactos de opciones que hayas normalizado).
- **Hallazgos no esperados** y **Decisiones por iniciativa** (clasificadas por nivel).
- **`git diff --name-only HEAD`** pegado.

## 8. Qué NO hacer
- NO tocar el esquema (migraciones 001-006) salvo que una validación revele un bug — y si lo revela,
  **reportar antes de corregir** (cambiar esquema es Nivel 3 si toca RLS/privacidad).
- NO agregar columnas `qi_gender`/`qi_modality` (hay un hallazgo abierto en `SEED_SPEC.md` para el
  director — es decisión Nivel 3, no la tomes acá).
- NO exponer texto libre (H3) en ninguna vista/función analítica.
- NO usar `respondent_id`. NO usar `service_role` en nada de cara al cliente.