# 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:

```markdown
# 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:

```markdown
# 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.