122 lines
5.5 KiB
Markdown
122 lines
5.5 KiB
Markdown
# ESTADO DEL PROYECTO — Datos País sobre el Cuidado
|
|
## Documento de continuidad — 24 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
|
|
- **Producción:** 2.1.0 (formulario lineal) — pero los 3 surveys están en `draft`
|
|
- **Desarrollo:** 3.0.0 (wizard) en `main`, NO desplegado aún
|
|
- **Preservación:** `v2.1.0-stable` + tag `v2.1.0`
|
|
- SemVer + CHANGELOG.md + tags. ADRs en `docs/adr/`.
|
|
|
|
⚠️ **Importante:** los 3 surveys están en `draft` a propósito (el frontend v2 desplegado
|
|
no entiende el seed v3). Se reactivan a `live` cuando se despliegue v3 completo (tras 4I).
|
|
|
|
---
|
|
|
|
## 2. Sprint 4 — Wizard v3 — EN CURSO (7 de 10 etapas completas)
|
|
|
|
Arquitectura (ADR-005): formulario = esquema declarativo (datos); frontend = renderer
|
|
sin reglas; motor interpreta el esquema. Fase 1 = formulario-como-esquema (este sprint);
|
|
Fase 2 = motor genérico (BACKLOG-002).
|
|
|
|
| Etapa | Nombre | Estado |
|
|
|---|---|---|
|
|
| 4.0 | Preservación v2 | ✅ |
|
|
| 4A | instance_id en answers | ✅ prod |
|
|
| 4B | Esquema declarativo + seed v3 (150 questions) | ✅ prod |
|
|
| 4C | Motor de flujo (lib/form-engine.ts, puro) | ✅ |
|
|
| 4D | Frontend renderer wizard (layout estable) | ✅ |
|
|
| 4E | Instancias de vínculo (emergente del motor; refactor + tests) | ✅ |
|
|
| 4G | Submit + validación server-side (RPC transaccional) | ✅ verificado vs Postgres real |
|
|
| 4F | Autocomplete barrios (UX) | ⏳ pendiente |
|
|
| 4H | RPCs de vínculo (dashboard agrega por instancia) | ⏳ pendiente |
|
|
| 4I | Validación e2e + tag v3.0.0 + despliegue + reactivar surveys | ⏳ pendiente |
|
|
|
|
Orden restante: 4F → 4H → 4I (4F y 4H son independientes; 4I cierra)
|
|
|
|
### Lo construido y verificado
|
|
- **Motor (4C):** `lib/form-engine.ts` puro, 20+ tests. Operadores escalares
|
|
(eq/eq_any/not_in) y de array (contains/eq_sole), acciones show/hide (hide=veto).
|
|
Instancias con ID estable `familiar_${posición de opción}`. Secciones=pantallas.
|
|
`applyAnswer`/`isRequiredAndUnanswered` (limpieza de instancias y required) en el motor.
|
|
- **Wizard (4D):** renderer una-preg-por-pantalla. Layout estable: header/footer fijos,
|
|
enunciado anclado, scroll interno con fade condicional (has-overflow). Reusa widgets.
|
|
- **Submit (4G):** RPC `rpc_submit_response` SECURITY DEFINER, transaccional, ÚNICO camino
|
|
de escritura (se dropearon las policies WITH CHECK(true)). Validación server-side
|
|
(7 checks) en `lib/submit-validation.ts` reusando el motor. Verificado vs Postgres real:
|
|
instancias separadas (familiar_1/familiar_2), atomicidad (fallo→0 huérfanos), anon
|
|
bloqueado de insertar directo.
|
|
|
|
### Recorridos del formulario (validados)
|
|
- Completo / Solo niño (eq_sole→5.3,8.4,9.1,9.4) / Ninguna (contains→S10) / 3.1=No oculta 3.2-3.5
|
|
|
|
---
|
|
|
|
## 3. Decisiones arquitectónicas (no reabrir)
|
|
1. Lógica de flujo en datos, no en frontend (ADR-005)
|
|
2. Motor puro en cliente; reusado server-side para validar (4G)
|
|
3. Validación de integridad server-side = no negociable (cumplido en 4G)
|
|
4. Secciones como pantallas (reversible)
|
|
5. Se extiende questions, no tabla separada (ADR-005)
|
|
6. Migraciones vía CLI del VPS
|
|
7. consent_records inmutable (ADR-003); RPC es único camino de escritura
|
|
8. qi_sector→2.6 (nivel jerárquico) confirmado con equipo
|
|
9. SemVer + CHANGELOG + tags
|
|
|
|
---
|
|
|
|
## 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 compliance (audit log, hashing, cifrado en reposo) | Sprint dedicado |
|
|
| SEC-003 | Agujero TRUNCATE evade ADR-003 | Antes de datos reales |
|
|
| SEC-004 | RPC validable por bypass REST (coherencia de flujo en Server Action, no SQL). Calidad de datos, no privacidad. Cerrar con firma de payload | Sprint futuro |
|
|
| BACKLOG-002 | Fase 2: motor genérico | Post-deadline |
|
|
|
|
---
|
|
|
|
## 5. Infraestructura
|
|
- 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
|
|
|
|
---
|
|
|
|
## 6. Próximo paso
|
|
**Etapa 4F (autocomplete barrios)** o **4H (RPCs de vínculo)** — son independientes.
|
|
- 4F necesita subir `geo_paraguay_full.json` (8152 barrios, generado, está en outputs de Claude
|
|
arquitecto) a `public/data/geo_paraguay.json` del repo.
|
|
- 4H: las RPCs del dashboard deben agregar datos de vínculo por instancia (4.2/4.3 con instance_id).
|
|
- 4I: validación e2e completa, tag v3.0.0, desplegar a producción, reactivar surveys a live.
|
|
|
|
---
|
|
|
|
## 7. Contexto comercial
|
|
- 2 clientes inminentes en ~10-20 días (deadline de v3)
|
|
- InQuality y Fundación Solidaridad en joint venture
|
|
- Datos de prueba descartables (dump en v2.1.0-stable)
|
|
|
|
---
|
|
|
|
## 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. Sprint 4: wizard v3
|
|
con esquema declarativo (ADR-005).
|
|
|
|
Estado completo: docs/estado/ESTADO_PROYECTO_JUNIO_2026.md.
|
|
Sprint: sprints/sprint-4/. Completadas: 4.0/4A/4B/4C/4D/4E/4G.
|
|
Pendientes: 4F (barrios), 4H (RPCs vínculo), 4I (release).
|
|
|
|
El motor (lib/form-engine.ts) y el submit (RPC + validación server-side) están
|
|
hechos y verificados contra Postgres real. La lógica vive en datos; frontend renderiza.
|
|
Los 3 surveys están en draft (v3 no desplegado aún).
|
|
|
|
Próximo paso: [COMPLETAR]
|
|
``` |