ETAPA 4I — Validación e2e + Release v3.0.0

1. Objetivo

Validar el wizard v3 end-to-end y hacer el release a producción. Los 3 surveys pasan de draft a live. Esta etapa es irreversible en varios pasos — seguir el orden estricto de fases y detenerse si algo falla.

2. Estado de entrada

Último commit: 3e7109a0 (4F ciudad-select)
Commits no desplegados desde último deploy: 8dea04c fix cnt RPCs · dbcc60a tema claro · 3ec5da0 autocomplete barrios · 3e7109a0 ciudad-select
VPS: seed de 50 respuestas activo (Demo en live) — NO limpiar, el director quiere mostrar el dashboard al equipo con esos datos
Los 3 surveys están en draft

3. DECISIONES YA TOMADAS — no consultar

Deploy vía Dokploy (rebuild + clean cache)
Migraciones SIEMPRE vía CLI del VPS — ninguna migración pendiente en esta etapa
Los 3 surveys se reactivan a live solo DESPUÉS de verificar producción
Tag v3.0.0 solo DESPUÉS de reactivar surveys
No hay migración de datos v2 → v3 (arranque limpio)

4. Fases — orden estricto, detenerse si algo falla

FASE 1 — Validación e2e local (antes de tocar producción)

Correr el wizard completo localmente y verificar:

Consentimiento → flujo completo → submit exitoso
Una respuesta con al menos 1 familiar (instancia) persiste con instance_id
El motor no muestra preguntas que el flujo oculta
El autocomplete de barrio funciona (dropdown visible, no tapado)
El filtro ciudad-departamento funciona (2.1 → 2.2 filtra, cambiar 2.1 limpia 2.2)
Submit devuelve confirmación, no error

Si CUALQUIER item falla: DETENER. Reportar el fallo y esperar instrucción.

FASE 2 — Deploy en Dokploy

Trigger rebuild en Dokploy con "Clean cache"
Verificar que el BUILD_ID nuevo aparece en los logs
Verificar que la app responde en economia-cuidado.inqualityhq.com
Verificar que el dashboard sigue mostrando los 50 datos sembrados
Verificar que el wizard abre y llega a la pregunta 2.3 sin errores de consola

Si CUALQUIER item falla: DETENER. Reportar el fallo y esperar instrucción.

FASE 3 — Reactivar surveys + Tag

Solo ejecutar si Fase 1 y Fase 2 están completas y verificadas.

Reactivar los 3 surveys en el VPS:

UPDATE surveys SET status = 'live'
WHERE id IN (
  SELECT id FROM surveys WHERE status = 'draft'
);

Verificar que quedaron en live:

SELECT id, name, status FROM surveys ORDER BY name;

Tag de release en el repo local y push:

git tag -a v3.0.0 -m "Release v3.0.0 — wizard declarativo + dashboard tres miradas"
git push origin v3.0.0

Actualizar CHANGELOG.md con las etapas 4C→4I completadas.

5. DoD completo

git log --name-only -1 antes de empezar — confirmar commit de entrada
Fase 1 completa sin fallos
Fase 2 completa — app en producción respondiendo
Surveys en live — verificado con SELECT
Tag v3.0.0 pusheado a Gitea
CHANGELOG.md actualizado
git log --name-only -1 del commit de CHANGELOG

6. Qué reportar

Por fase, en orden: FASE 1 — e2e local:

Submit con familiar: [response_id y instance_id del registro insertado] Items del checklist: ✓/✗ cada uno

FASE 2 — Deploy:

BUILD_ID nuevo: [valor] App responde: ✓/✗ Dashboard con datos: ✓/✗ Wizard sin errores de consola: ✓/✗

FASE 3 — Release:

Surveys en live: [output del SELECT] Tag v3.0.0: [output de git tag] CHANGELOG: [secciones agregadas]

7. Qué NO hacer

❌ No reactivar surveys antes de verificar producción (Fase 2 primero)
❌ No taggear antes de reactivar surveys (Fase 3 es la última)
❌ No limpiar el seed de 50 respuestas — el director los necesita para mostrar al equipo
❌ No aplicar migraciones — no hay ninguna pendiente en esta etapa
❌ No tocar v2.1.0-stable
❌ No continuar si algo falla — detenerse y reportar

8. Versionado

chore(release): CHANGELOG v3.0.0 — wizard declarativo + dashboard tres miradas Etapas 4C→4I completadas. Motor de flujo puro, wizard renderer,

instancias familiares, submit con validación server-side, dashboard

tres miradas (Mirada Empresa funcional), autocomplete barrios/ciudad.

4.1 KiB Raw Blame History