131 lines
5.7 KiB
Markdown
131 lines
5.7 KiB
Markdown
# 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]
|
||
``` |