marcos/motor-de-encuestas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
b0cf273bc87a3baab9cf4711fd5a6f6614fac35e
motor-de-encuestas/docs/estado/ESTADO_PROYECTO_JUNIO_2026.md
markosbenitez b0cf273bc8 docs: actualizar estado — cierre Etapa 4G.
2026-06-24 21:31:56 -03:00

5.5 KiB
Raw Blame History

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]
Reference in New Issue View Git Blame Copy Permalink