marcos/motor-de-encuestas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
eaf71567a7375fab439ff5abdf18f8e312e40918
motor-de-encuestas/docs/estado/ESTADO_PROYECTO_JUNIO_2026.md
markosbenitez 424071b97c estado de proyecto updated
2026-06-23 15:01:08 -03:00

5.7 KiB
Raw Blame History

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