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

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).
Aplicar a Cloud: supabase db push y luego cargar el seed contra el proyecto vinculado.
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.

4.1 KiB Raw Blame History