From b0cf273bc87a3baab9cf4711fd5a6f6614fac35e Mon Sep 17 00:00:00 2001 From: markosbenitez Date: Wed, 24 Jun 2026 21:31:56 -0300 Subject: [PATCH] =?UTF-8?q?docs:=20actualizar=20estado=20=E2=80=94=20cierr?= =?UTF-8?q?e=20Etapa=204G.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/estado/ESTADO_PROYECTO_JUNIO_2026.md | 151 ++++++++++------------ 1 file changed, 71 insertions(+), 80 deletions(-) diff --git a/docs/estado/ESTADO_PROYECTO_JUNIO_2026.md b/docs/estado/ESTADO_PROYECTO_JUNIO_2026.md index 3a39526..218e6d0 100644 --- a/docs/estado/ESTADO_PROYECTO_JUNIO_2026.md +++ b/docs/estado/ESTADO_PROYECTO_JUNIO_2026.md @@ -1,5 +1,5 @@ # ESTADO DEL PROYECTO — Datos País sobre el Cuidado -## Documento de continuidad — 20 junio 2026 +## 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 @@ -7,125 +7,116 @@ --- ## 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/`. -- **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. +⚠️ **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 +## 2. Sprint 4 — Wizard v3 — EN CURSO (7 de 10 etapas completas) -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. +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). -### 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 | +| 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: 4D → (4E ∥ 4F) → 4G → 4H → 4I +Orden restante: 4F → 4H → 4I (4F y 4H son independientes; 4I cierra) -### 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 +### 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. -### 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 +### 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 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 +## 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 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. +| 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 (sin cambios) +## 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` -- Backups GFS locales 3AM +- App: economia-cuidado.inqualityhq.com · API: db.inqualityhq.com +- Repos Gitea: git.inquality.com.py/marcos/motor-de-encuestas --- -## 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) +## 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. 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. +## 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. Estamos en Sprint 4 -construyendo el formulario wizard v3 (esquema declarativo, ADR-005). +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 en el repo. -Sprint: sprints/sprint-4/ (BRIEF + prompts de etapa + reportes). -Completadas: 4.0, 4A, 4B, 4C. Siguiente: 4D (frontend renderer). +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 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. +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] ``` \ No newline at end of file