65 lines
4.1 KiB
Markdown
65 lines
4.1 KiB
Markdown
# 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. |