Extiende questions con instance_generator/instance_of/hint. Instrumento v3 completo (10 secciones, 50 preguntas) como datos declarativos. Operadores de flujo para multiple_choice: contains, eq_sole. Flujo del formulario en el esquema, no en presentación (ADR-005). Seed solo reemplaza catálogo; no toca evidencia de consentimiento (ADR-003).
104 lines
3.9 KiB
Markdown
104 lines
3.9 KiB
Markdown
# ETAPA 4A — Modelo de datos: instance_id en answers
|
|
|
|
## 1. Objetivo
|
|
Agregar la columna `instance_id` a la tabla `answers` y cambiar la constraint
|
|
única para soportar múltiples respuestas a la misma pregunta (una por instancia
|
|
de vínculo familiar). Es el cambio de base que habilita todo el wizard v3.
|
|
|
|
## 2. Contexto previo
|
|
- v3 se desarrolla en `main`. v2 está preservado en `v2.1.0-stable`.
|
|
- La tabla `answers` actual tiene constraint `UNIQUE (response_id, question_id)`.
|
|
- El wizard v3 genera múltiples respuestas para las preguntas 4.2 y 4.3 (una por
|
|
cada familiar declarado en 4.1). Sin `instance_id`, esas respuestas colisionan.
|
|
- Las preguntas no-vinculadas (la gran mayoría) usan `instance_id = 'default'`.
|
|
|
|
## 3. DECISIONES YA TOMADAS — no consultar de nuevo
|
|
- Nombre de la columna: `instance_id`, tipo `text`, `DEFAULT 'default'`, NOT NULL.
|
|
- Nueva constraint: `UNIQUE (response_id, question_id, instance_id)`.
|
|
- Para preguntas normales: `instance_id = 'default'`.
|
|
- Para instancias de vínculo: `instance_id = 'familiar_1'`, `'familiar_2'`, etc.
|
|
- Esto es una migración nueva, NO modifica migraciones existentes.
|
|
- NO se migran datos v2 — el seed v3 arranca limpio (etapa posterior).
|
|
|
|
## 4. Tareas
|
|
|
|
### 4.1 Nueva migración
|
|
Crear `supabase/migrations/20260620000001_add_instance_id.sql`:
|
|
|
|
```sql
|
|
-- Sprint 4 (v3.0.0) — instance_id para respuestas multi-instancia
|
|
-- Habilita el mini-wizard de vínculos familiares (una respuesta por familiar)
|
|
|
|
-- 1. Agregar la columna con default para filas existentes
|
|
ALTER TABLE public.answers
|
|
ADD COLUMN IF NOT EXISTS instance_id text NOT NULL DEFAULT 'default';
|
|
|
|
-- 2. Eliminar la constraint única vieja (nombre real verificado en DB)
|
|
ALTER TABLE public.answers
|
|
DROP CONSTRAINT IF EXISTS answers_response_id_question_id_key;
|
|
|
|
-- 3. Crear la nueva constraint que incluye instance_id
|
|
ALTER TABLE public.answers
|
|
ADD CONSTRAINT answers_response_question_instance_key
|
|
UNIQUE (response_id, question_id, instance_id);
|
|
|
|
-- 4. Índice para consultas por instancia (análisis de vínculos)
|
|
CREATE INDEX IF NOT EXISTS idx_answers_instance
|
|
ON public.answers (question_id, instance_id)
|
|
WHERE instance_id != 'default';
|
|
```
|
|
|
|
### 4.2 Verificar el nombre real de la constraint actual
|
|
ANTES de escribir el DROP, verificar el nombre exacto de la constraint única
|
|
actual de `answers`. El nombre asumido es `answers_response_id_question_id_key`
|
|
(convención Postgres), pero confirmar con:
|
|
|
|
```sql
|
|
SELECT conname FROM pg_constraint
|
|
WHERE conrelid = 'public.answers'::regclass AND contype = 'u';
|
|
```
|
|
|
|
Si el nombre difiere, ajustar el `DROP CONSTRAINT` en la migración.
|
|
NO ejecutar la migración en producción — solo crear el archivo.
|
|
|
|
### 4.3 Actualizar DATA_MODEL.md
|
|
Documentar el cambio en `DATA_MODEL.md`: la tabla `answers` ahora tiene
|
|
`instance_id` y la nueva constraint. Explicar el patrón 'default' vs 'familiar_N'.
|
|
|
|
## 5. Entregables (DoD)
|
|
- [ ] Migración `20260620000001_add_instance_id.sql` creada.
|
|
- [ ] Nombre real de la constraint actual verificado y usado en el DROP.
|
|
- [ ] `DATA_MODEL.md` actualizado con el nuevo esquema de `answers`.
|
|
- [ ] La migración es idempotente (`IF EXISTS` / `IF NOT EXISTS`).
|
|
- [ ] NO ejecutada en producción.
|
|
|
|
## 6. Qué reportar
|
|
```
|
|
Verificado:
|
|
- Migración creada ✓
|
|
- Nombre real de constraint actual: [nombre]
|
|
- DATA_MODEL.md actualizado ✓
|
|
- Idempotencia confirmada ✓
|
|
|
|
Asumido:
|
|
- [supuestos sobre el esquema]
|
|
|
|
NO ejecutado en producción (pendiente aprobación del director).
|
|
```
|
|
|
|
## 7. Qué NO hacer
|
|
- ❌ No ejecutar la migración en la DB de producción.
|
|
- ❌ No modificar migraciones existentes.
|
|
- ❌ No tocar el seed todavía (es la etapa 4B).
|
|
- ❌ No migrar datos de v2.
|
|
- ❌ No tocar la rama v2.1.0-stable.
|
|
|
|
## 8. Versionado
|
|
Commit sugerido al cerrar:
|
|
```
|
|
feat(data): agregar instance_id a answers para multi-instancia [4A]
|
|
|
|
Habilita respuestas múltiples por pregunta (mini-wizard de vínculos).
|
|
Nueva constraint UNIQUE(response_id, question_id, instance_id).
|
|
Parte del Sprint 4 hacia v3.0.0.
|
|
``` |