# 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**.