75 lines
4.2 KiB
Markdown
75 lines
4.2 KiB
Markdown
# 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
|
||
1. 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).
|
||
2. Aplicar a Cloud: `supabase db push --include-seed` o equivalente.
|
||
3. 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)
|
||
4. 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.
|
||
5. En `components/question-renderer.tsx`: registrar `text_short` y renderizarlo con el nuevo widget.
|
||
6. 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**. |