# 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: ```sql UPDATE surveys SET status = 'live' WHERE id IN ( SELECT id FROM surveys WHERE status = 'draft' ); ``` Verificar que quedaron en `live`: ```sql SELECT id, name, status FROM surveys ORDER BY name; ``` Tag de release en el repo local y push: ```bash 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.