inq-roi-simulador-web/sprints/sprint-1-5/ETAPA_10_PROMPT.md

Sprint 1.5 — Etapa 10: Validación E2E final + preparación Sprint 2

Objetivo: validar que el Sprint 1.5 (Etapas 1-9) produjo un sistema funcional, sin regresiones, con cobertura clara y baseline reproducible. Generar checklist de QA reutilizable y documento de estado de cobertura para que Sprint 2 arranque con confianza.

Pre-requisitos: Etapas 1-9 cerradas. Suite de tests existente con ~526 tests verdes. Sistema de design tokens InQ aplicado en web app + 3 PDFs.

Etapa siguiente: Etapa 11 — Polish final + documentación del Sprint 1.5 (refinamientos diferidos del KPI Hero, banner, grid 2x2, Top 3 + cierre formal del sprint).

---

1. Esta etapa es distinta a las anteriores

Las Etapas 1-9 produjeron código y artefactos visuales. Etapa 10 valida lo construido. No agrega features, no rediseña visuales. Su producto principal es confianza en el sistema.

Mentalidad correcta para esta etapa:

• Si todo funciona como debe → reporte limpio, baseline documentado
• Si hay regresiones o bugs no cazados antes → catalogarlos sin pánico, anotarlos para resolver con criterio (algunos en Etapa 11, otros en Sprint 2)
• NO arreglar cosas durante esta etapa sin consultar. La etapa es diagnóstica, no correctiva.

---

2. Alcance estricto

Sí entra

• ✅ Correr la suite E2E completa del proyecto
• ✅ Documentar resultado: cuántos tests, cuántos verdes, cuántos rojos, cuántos skip
• ✅ Generar los 3 PDFs finales del sprint (Actual, Automatizado, ROI) en tests/e2e/__output__/sprint-1-5-final/
• ✅ Generar reporte de estado de cobertura en docs/COVERAGE_STATE.md con:
  • Qué áreas tienen tests sólidos (unitarios + E2E)
  • Qué áreas tienen tests débiles o nulos (gaps identificados)
  • Recomendaciones de qué cubrir en Sprint 2
• ✅ Crear docs/QA_CHECKLIST.md reutilizable: lista de verificación para futuros cierres de sprint o pre-deploys
• ✅ Smoke test manual documentado del flujo end-to-end (qué hacer en el navegador para verificar el producto)
• ✅ Identificar regresiones o anomalías comparando con baseline previo de cada etapa

NO entra

• ❌ Agregar tests nuevos para cubrir gaps detectados (eso es Sprint 2)
• ❌ Arreglar bugs detectados durante la validación (a menos que sean bloqueantes — consultar antes)
• ❌ Cambios visuales en web app o PDFs
• ❌ Refinamientos del KPI Hero, banner, grid 2x2, Top 3 (Etapa 11)
• ❌ Cambios en la arquitectura, deps, o configuración

---

3. Lo que esta etapa debe producir

3.1 Reporte de ejecución de la suite

Formato esperado en el reporte final a director:

Suite de tests — estado actual:

Tests unitarios:
  - Total: N
  - Verdes: N
  - Rojos: N (listar archivos + razón)
  - Skip: N (listar archivos + razón si está documentada)

Tests E2E (Playwright):
  - Total: N
  - Verdes: N
  - Rojos: N
  - Skip: N

Build:
  - npm run build: ✓ o ✗ (con detalle si falla)
  - npm run typecheck: ✓ o ✗
  - npm run lint: ✓ o ✗

Tiempo total de ejecución de la suite:
  - Unit: N segundos
  - E2E: N segundos

3.2 PDFs finales del sprint

En la carpeta tests/e2e/__output__/sprint-1-5-final/, generar:

• final-actual.pdf — proceso medium-with-gateways, escenario actual
• final-automatizado.pdf — proceso medium-with-gateways, escenario automatizado
• final-roi.pdf — proceso medium-with-gateways, ROI con frecuencia 5000/año, 3 años, USD 80.000

Estos PDFs son el baseline final del sprint. Cualquier cambio futuro debe compararse contra ellos.

Validar al generar:

• PDF Actual: 4 páginas, orientaciones [portrait, landscape, portrait, portrait]
• PDF Automatizado: 4 páginas, mismas orientaciones
• PDF ROI: 5 páginas, todas portrait, KPI Hero gradiente en página 1, trayectoria del ahorro en página 5

3.3 docs/COVERAGE_STATE.md

Documento con esta estructura mínima:

# Estado de cobertura — fin de Sprint 1.5

## Áreas con cobertura sólida

[Lista de módulos/features con tests unitarios + E2E robustos]

Ejemplos esperados:
- Motor de simulación BPMN (lib/simulator)
- Cálculo de ROI (lib/roi)
- Exportación PDF (3 generadores)
- Formato de moneda y payback (helpers)
- Badge automatizable en BpmnCanvas

## Áreas con cobertura parcial

[Lista de módulos donde hay tests unitarios pero faltan E2E, o viceversa]

## Áreas sin cobertura

[Lista de módulos críticos sin tests, identificados durante revisión]

## Gaps identificados para Sprint 2

[Tests que vale la pena agregar en Sprint 2, priorizados por riesgo]

Ejemplos esperables:
- Tests E2E del flujo completo de importación BPMN
- Tests de regresión visual de PDFs (golden files)
- Tests de stress en simulador con procesos grandes (50+ actividades)
- Tests de edge cases en cálculo de ROI (inversión cero, payback infinito, etc.)

3.4 docs/QA_CHECKLIST.md

Checklist reutilizable para cierres de sprint o pre-deploys. Estructura:

# Checklist de QA — pre-cierre de sprint / pre-deploy

> Lista de verificación para validar el estado del producto antes de 
> cerrar un sprint o desplegar a producción.

## 1. Suite de tests
[ ] npm test pasa con 0 rojos
[ ] npm run test:e2e pasa con 0 rojos
[ ] npm run build sin errores ni warnings nuevos
[ ] npm run typecheck limpio
[ ] npm run lint limpio

## 2. Validación visual web app
[ ] Workspace carga correctamente con simple-linear
[ ] BPMN se renderiza sin errores en consola
[ ] Badge ⚡ aparece en actividades automatizables (después de Guardar)
[ ] Reporte muestra KPI cards con paleta InQ
[ ] Tab ROI muestra KPI Hero con gradiente naranja → magenta
[ ] Switch toggle activa/desactiva escenario automatizado
[ ] CumulativeSavingsChart se ve correctamente

## 3. Validación visual PDFs
[ ] PDF Actual tiene 4 páginas (incluye BPMN landscape)
[ ] PDF Automatizado tiene 4 páginas (incluye BPMN landscape)
[ ] PDF ROI tiene 5 páginas (con trayectoria del ahorro)
[ ] Header "InQ ROI" naranja en todas las páginas
[ ] Footer "Powered by InQuality" + paginación correcta
[ ] Sin caracteres rotos visibles
[ ] Sin texto truncado en márgenes

## 4. Regresiones
[ ] No aparece "Process Cost Platform" en ningún lugar
[ ] No aparece "v0.1.0" en PDFs (solo en web)
[ ] No aparece "INQ", "Inq", "inq" (verificar regla I-n-Q)

## 5. Documentación
[ ] CLAUDE.md actualizado con decisiones del sprint
[ ] methodology/ tiene cosechas aplicadas
[ ] OBSERVATIONS.md vacío o solo con [RESOLVED]
[ ] BACKLOG.md y TECH_DEBT.md actualizados
[ ] STRATEGIC_DIRECTION.md refleja decisiones del sprint

3.5 Smoke test manual

Documentar pasos exactos que el director (o un consultor de InQuality) puede ejecutar en el navegador para validar que el producto funciona. Esto va a la sección del QA_CHECKLIST.md o como archivo separado docs/SMOKE_TEST.md.

Pasos mínimos esperados:

1. npm run dev
2. Abrir http://localhost:5173/
3. Importar BPMN de ejemplo (medium-with-gateways)
4. Configurar costos en 3 actividades:
   - Recepcionar solicitud: USD 200 directo / USD 20 automatizado
   - Calcular score crediticio: USD 100 directo / USD 10 automatizado
   - Analizar riesgo crediticio: USD 200 directo / USD 20 automatizado
5. Marcar las 3 como automatizables y Guardar cada una
6. Verificar que aparecen 3 badges ⚡ en el canvas
7. Ir a tab Reporte → verificar KPI cards
8. Ir a tab ROI → verificar KPI Hero gradiente
9. Configurar parámetros ROI: 5000 ejecuciones/año, 3 años, USD 80.000 inversión
10. Exportar los 3 PDFs (Actual, Automatizado, ROI)
11. Verificar que los PDFs descargados tienen la cantidad de páginas correcta

Tiempo estimado: 5 minutos

---

4. Validaciones automatizadas mandatorias

Antes de present_files, ejecutá y confirmá:

1. Suite completa de tests pasa:
   - Unit tests: TODOS verdes (NO permitir rojos o skips sin justificación)
   - E2E tests: TODOS verdes
   - Si hay rojos: documentar exactamente cuáles y por qué

2. Los 3 PDFs finales se generan correctamente:
   - Tamaños razonables (Actual ~80KB, Automatizado ~80KB, ROI ~250KB con gradiente)
   - Cantidad de páginas correcta (4, 4, 5)
   - Orientaciones correctas

3. Build, typecheck, lint: TODOS limpios

4. Archivos creados en su lugar:
   - docs/COVERAGE_STATE.md
   - docs/QA_CHECKLIST.md (o sección dentro de COVERAGE_STATE.md)
   - tests/e2e/__output__/sprint-1-5-final/ con los 3 PDFs

5. NO hay archivos huérfanos:
   - No quedaron PDFs viejos de etapas anteriores en directorios productivos
   - tests/screenshots/ no creció más allá de lo esperado

---

5. Entregables (Definition of Done)

[ ] Suite completa de tests ejecutada y reportada
[ ] 3 PDFs finales del sprint generados en sprint-1-5-final/
[ ] docs/COVERAGE_STATE.md creado con áreas sólidas + parciales + gaps
[ ] docs/QA_CHECKLIST.md creado y reutilizable
[ ] Smoke test manual documentado
[ ] Reporte de regresiones (si las hay) catalogadas sin actuar
[ ] Build limpio, typecheck limpio, lint limpio
[ ] PDFs presentados con paths absolutos para validación visual del director
[ ] Sin código nuevo agregado al producto (solo docs + artefactos de QA)
[ ] Decisiones por iniciativa: esperado "Ninguna" (la etapa es diagnóstica)

---

6. Reporte final a entregar

1. Tabla de archivos creados (esperado: solo docs + PDFs en sprint-1-5-final/)
2. Resultado de la suite completa (verdes/rojos/skip por categoría)
3. 3 PDFs finales presentados con paths absolutos
4. Resumen de COVERAGE_STATE.md: áreas sólidas, parciales, gaps
5. Resumen de QA_CHECKLIST.md: cuántos items tiene, cómo está organizado
6. Regresiones detectadas: si hay, listadas SIN ACCIÓN CORRECTIVA (anotadas para Etapa 11 o Sprint 2)
7. Anomalías encontradas: cualquier comportamiento inesperado durante la validación
8. Recomendaciones para Sprint 2: cosas que vale la pena cubrir con tests adicionales

---

7. Reglas operativas

1. NO ARREGLAR bugs durante esta etapa. Si encontrás regresión o anomalía, anotala en el reporte y dejala así. Excepción única: si encontrás un bug que rompe el build completo o impide generar los PDFs finales, consultar antes de arreglar.

2. NO AGREGAR tests nuevos para cubrir gaps. Los gaps van a COVERAGE_STATE.md para Sprint 2.

3. NO CAMBIAR código de producción. Solo se permite agregar documentación.

4. NO TOCAR archivos visuales del producto (PDFs, web app). Solo generarlos para baseline.

5. Política de iniciativa proactiva refinada (post-Etapa 8):

   • Cualquier cambio en código de producción durante esta etapa: Nivel 3 (consultar previa)
   • Crear nuevos archivos en docs/: permitido si están en scope (ver §3)
   • Crear archivos fuera de docs/: Nivel 2 mínimo

6. Si la suite tiene rojos: documentarlos sin arreglarlos. La etapa puede cerrarse con rojos conocidos siempre que estén documentados y categorizados (bug nuevo vs bug heredado vs flaky).

7. Si encontrás contradicción entre prompt y código: PARÁ y consultá.

---

8. Mentalidad correcta para esta etapa

Etapa 10 es inventario, no construcción. Pensá como auditor externo:

• ¿Qué tengo construido?
• ¿Qué tan robusto está testeado?
• ¿Qué falta cubrir?
• ¿Hay sorpresas escondidas?

Si encontrás algo que no estaba en el radar (test que pasa pero el comportamiento real es raro, dependencia desactualizada, archivo huérfano de etapas pasadas), eso es valor de esta etapa. Reportarlo es lo correcto.

Si todo está limpio y predecible, eso también es valor — significa que las Etapas 1-9 dejaron un sistema en buen estado.

El éxito de esta etapa no se mide en cambios producidos. Se mide en confianza generada para arrancar Sprint 2.

---

9. Una nota sobre el cierre del Sprint 1.5

Después de Etapa 10, queda solo Etapa 11 (polish + documentación). Cuando esa cierre:

• El Sprint 1.5 se considera completo
• Se hace tag sprint-1-5-cerrado en git
• Se ejecuta el cierre de OBSERVATIONS.md (purgar items resueltos, archivar)
• Se actualiza STRATEGIC_DIRECTION.md con reflexiones del sprint
• Sprint 2 arranca con backlog claro, baseline de cobertura conocido, y método refinado

Etapa 10 es el último filtro antes de ese cierre.