# ESTADO DEL PROYECTO — Datos País sobre el Cuidado
## Documento de continuidad — 20 junio 2026

> Director (Product Owner): Marcos · Claude (Projects) = arquitecto/copiloto · Claude Code = implementación
> Metodología: Maria Mersan · Contacto Fundación: Valeria Arce

---

## 1. Versionado y ramas

- **Versión en producción:** 2.1.0 (formulario lineal, dashboard multitenante)
- **Versión en desarrollo:** 3.0.0 (wizard, en `main`)
- **Rama de preservación:** `v2.1.0-stable` (código + dump DB) + tag `v2.1.0`
- Convención: SemVer + CHANGELOG.md (raíz) + tags en cada versión estable
- ADRs en `docs/adr/`. ADR-005 = esquema declarativo + estrategia dos fases.

---

## 2. Sprint 4 — Wizard v3 — EN CURSO

Arquitectura (ADR-005): el formulario es un **esquema declarativo** (datos); el frontend
es un **renderer** sin reglas de negocio; el motor interpreta el esquema.
Estrategia dos fases: Fase 1 (este sprint) formulario-como-esquema; Fase 2 (BACKLOG-002)
motor genérico universal.

### Etapas
| Etapa | Nombre | Estado |
|---|---|---|
| 4.0 | Preservación v2 (tag, rama, dump, CHANGELOG) | ✅ |
| 4A | Persistencia `instance_id` en answers | ✅ aplicada en prod |
| 4B | Esquema declarativo + seed v3 (10 secciones, 150 questions) | ✅ aplicada en prod |
| 4C | Motor de resolución de flujo (puro, lib/, 16 tests) | ✅ commiteada |
| 4D | Frontend renderer (consume el motor, una preg/pantalla) | ⏳ siguiente |
| 4E | Instancias de vínculo (mini-wizard familiares) | pendiente |
| 4F | Autocomplete barrios (requiere geo_paraguay_full.json) | pendiente |
| 4G | Submit con instance_id + **validación server-side (no negociable)** | pendiente |
| 4H | RPCs de vínculo (agregados por instancia) | pendiente |
| 4I | Validación e2e + tag v3.0.0 + ADR + BACKLOG Fase 2 | pendiente |

Orden: 4D → (4E ∥ 4F) → 4G → 4H → 4I

### Estado técnico v3 en la DB (ya aplicado en prod)
- `answers.instance_id text DEFAULT 'default'`, constraint `(response_id, question_id, instance_id)`
- `questions` extendida: `instance_generator`, `instance_of`, `hint`
- 150 questions (50 × 3 surveys), instrumento v3 de 10 secciones
- 4.1 = `instance_generator`; 4.2/4.3 = `instance_of='4.1'`
- Datos de prueba v2 borrados (TRUNCATE); v3 arranca limpio

### Motor de flujo (4C) — lib/form-engine.ts
- Módulo puro, sin React/DOM. Tests en `lib/form-engine.test.mts` (16/16).
- Operadores: `eq`, `eq_any`, `not_in` (escalares); `contains`, `eq_sole` (array multiple_choice)
- Acciones: `show`, `hide` (hide = veto absoluto sobre show del mismo array)
- Reglas múltiples en un array = OR
- ID de instancia: `familiar_${posición fija de opción}` (determinista, estable)
- Secciones = pantallas propias; se ocultan solo si su fila type='section' tiene regla

### Recorridos del formulario (validados en mockup y tests)
- Completo: todos los vínculos → todas las secciones
- Solo niño sin discapacidad (`eq_sole` op 1): liviano → 5.3, 8.4, 9.1, 9.4
- Ninguna (`contains` op 8): salta a Sección 10
- 3.1='No': oculta 3.2-3.5

---

## 3. Decisiones arquitectónicas clave (no reabrir)

1. Lógica de flujo en datos (esquema), no en frontend (ADR-005)
2. Frontend = renderer sin reglas de negocio
3. Motor de flujo (4C) corre en cliente, módulo puro testeable
4. **Validación de integridad del submit = server-side, NO negociable (4G)**
   La validación de cliente es UX, no seguridad. Datos de salud sensibles.
5. Secciones como pantallas propias (reversible — es comportamiento del motor)
6. Se extiende `questions`, no se crea tabla de definición (ADR-005)
7. Migraciones vía CLI del VPS (`docker exec -i supabase-db psql`)
8. consent_records inmutable (ADR-003); el seed nunca toca datos de respuesta

---

## 4. Deuda técnica y seguridad

| ID | Descripción | Prioridad |
|---|---|---|
| TECH-DEBT-006 | Backup remoto S3 | Antes de datos reales |
| TECH-DEBT-009 | Rotar secrets post-CVE | Antes de datos reales |
| SEC-002 | Sprint de compliance (audit log, hashing, cifrado en reposo) | Sprint dedicado |
| SEC-003 | **Agujero TRUNCATE evade inmutabilidad ADR-003** — cerrar antes de datos reales | Antes de datos reales |
| BACKLOG-002 | Fase 2: motor genérico de formularios | Post-deadline |

COMPLIANCE.md documenta estado de seguridad, roadmap de auditabilidad, y la decisión
fundamentada de NO usar blockchain.

---

## 5. Infraestructura (sin cambios)
- Next.js 15.3.8 · Supabase self-hosted · Dokploy v0.29.4 · VPS inq-mart-2 (172.20.5.11)
- App: `economia-cuidado.inqualityhq.com` · API: `db.inqualityhq.com`
- Repos Gitea: `git.inquality.com.py/marcos/motor-de-encuestas`
- Backups GFS locales 3AM

---

## 6. Contexto comercial
- 2 clientes inminentes en 10-20 días (motivan el deadline de v3)
- InQuality y Fundación Solidaridad ya en joint venture del producto
- Datos de prueba descartables (existe dump en v2.1.0-stable)

---

## 7. Próximo paso inmediato
**Etapa 4D — Frontend renderer.** El componente consume el motor (4C) y renderiza
una pregunta por pantalla. Incluye la tarea 4.5 pospuesta de 4C (query de app/page.tsx
con hint/instance_generator/instance_of). Reemplaza lib/conditional.ts y la lógica
de secciones hardcodeada de survey-form.tsx v2.

---

## 8. Prompt para nueva sesión
```
Sos el arquitecto/copiloto técnico de "Datos País sobre el Cuidado", motor de
formularios soberano (Paraguay). Yo soy el product owner. Estamos en Sprint 4
construyendo el formulario wizard v3 (esquema declarativo, ADR-005).

Estado completo: docs/estado/ESTADO_PROYECTO_JUNIO_2026.md en el repo.
Sprint: sprints/sprint-4/ (BRIEF + prompts de etapa + reportes).
Completadas: 4.0, 4A, 4B, 4C. Siguiente: 4D (frontend renderer).

El motor de flujo ya existe y está testeado (lib/form-engine.ts, 16 tests).
La lógica vive en datos; el frontend es renderer sin reglas.

Próximo paso: [COMPLETAR]
```