ETAPA 1D — Actualización del instrumento a v2 (44 preguntas)

Implementa la revisión del instrumento hecha por la colega del equipo. Leé: CLAUDE.md, DATA_MODEL.md, SEED_SPEC.md (v2) y este prompt.

1. Objetivo

Actualizar el seed y la app para que reflejen el instrumento v2 de 44 preguntas según SEED_SPEC.md. Dos partes: (A) base de datos en Supabase Cloud, (B) widget text_short en el formulario Next.js.

2. Contexto previo

La Etapa 1C cerró la fundación de datos con 34 preguntas. Esta etapa la actualiza a 44 por decisión del equipo. El esquema de tablas NO cambia — solo cambia el contenido del seed. Las columnas qi_city y qi_country se agregan en un sprint futuro (no en esta etapa).

3. Decisiones ya tomadas

44 preguntas con códigos únicos según SEED_SPEC.md. Códigos corregidos: 6.4 y 6.5 (las que en el HTML original eran 6.2 y 6.3 duplicados).
A1/A2/A3 son tipo text_short (texto libre corto), sin opciones. Se guardan en answers.
Pregunta 6.2 = multiple_choice max_select=3 (NO ranking todavía).
Pregunta 3.4 (salary) = is_sensitive=true. Ninguna vista de org_admin la expone.
Condicionales: cond-disc-propia (1.1=Sí → 1.2–1.5), cond-familiar (1.6=Sí → 1.7–1.12), cond-adulto-mayor (1.13=Sí → 1.14–1.16). Reglas en la pregunta dependiente.
Secciones A, 2, 3, 4, 5, 6, 7 son top-level (siempre visibles).
RE-INDEX es solo una nota en los textos de SEED_SPEC.md; NO agrega columna al esquema.

4. Tareas

4A — Base de datos

Reescribir supabase/seed.sql con las 44 preguntas de SEED_SPEC.md: tipos, opciones, max_select (6.2=3), is_sensitive (marcar las indicadas ✅), conditional_rules en dependientes, required=false para todas (el equipo decidió capturar todas las respuestas para validar el concepto, la obligatoriedad real se define luego).
Aplicar a Cloud: supabase db push --include-seed o equivalente.
Verificar: SELECT count(*) FROM questions = 44; códigos únicos sin duplicados; pregunta 3.4 con is_sensitive=true; los 3 bloques condicionales tienen las reglas correctas.

4B — App (formulario Next.js)

En components/widgets/, crear text-short-field.tsx: un <input type="text"> accesible (label asociado, aria-required, aria-invalid) con el mismo estilo visual que los otros widgets.
En components/question-renderer.tsx: registrar text_short y renderizarlo con el nuevo widget.
Verificar que A1/A2/A3 se renderizan como campos de texto, y que el formulario sigue funcionando end-to-end (cargar las 44 preguntas desde Supabase, condicionales B/C/D, envío al resumen).

5. Definition of Done

SELECT count(*) FROM questions = 44 contra Cloud.
Códigos únicos: SELECT code, count(*) FROM questions GROUP BY code HAVING count(*) > 1 = vacío.
3.4 tiene is_sensitive=true.
Pregunta A1 con type='text_short' y options=null.
npm run build limpio.
El formulario en http://localhost:3000 muestra A1/A2/A3 como campos de texto.
B1=Sí despliega 1.2–1.5; C1=Sí despliega 1.7–1.12; D1=Sí despliega 1.14–1.16.
git diff --name-only HEAD solo con supabase/seed.sql + archivos de la app.

6. Validaciones automatizadas mandatorias

Conteo de preguntas: 44 ✓
Sin códigos duplicados (query arriba) ✓
is_sensitive en exactamente las preguntas marcadas en SEED_SPEC.md ✓
Al menos una conditional_rule en cada una de las 16 preguntas dependientes ✓
npm run build sin errores ✓
Si CUALQUIERA falla: NO declarar lista. Reportar y esperar.

7. Qué reportar

Conteo de preguntas y confirmación de código únicos.
Confirmación de que A1/A2 se renderizan correctamente en el formulario.
Salida de git diff --name-only HEAD.
Hallazgos, asumidos, decisiones por iniciativa (con nivel).

8. Qué NO hacer

NO agregar columnas qi_city/qi_country al esquema (es Sprint 3).
NO implementar widget de ranking (está en backlog).
NO tocar migraciones 001–007.
NO cambiar la lógica de RLS ni los policies.
NO exponer 3.4 en ninguna vista o función que sea accesible a org_admin.
Ante conflicto restricción vs build limpio: detenerse y reportar.

4.2 KiB Raw Permalink Blame History Unescape Escape