docs: cierre formal de Sprint 1.5
- OBSERVATIONS.md reseteado para Sprint 2 - STRATEGIC_DIRECTION.md con reflexiones del sprint - TECH_DEBT.md curado: items resueltos archivados - methodology/CASE_STUDIES/inq-roi-sprint-1-5.md generado Sprint 1.5 cerrado: - 11 etapas + 1 fix pre-Etapa 11 - 526 unit tests + 38 E2E al cierre - Producto con identidad InQ aplicada en web + 3 PDFs - Metodología documentada con casos reales (2 de mala clasificación de iniciativa, originaron AP.8 + refinamiento C.6) - Material para transmisión al equipo de 5 técnicos
This commit is contained in:
312
sprints/sprint-1-5/ETAPA_10_PROMPT.md
Normal file
312
sprints/sprint-1-5/ETAPA_10_PROMPT.md
Normal file
@@ -0,0 +1,312 @@
|
||||
# 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.
|
||||
471
sprints/sprint-1-5/ETAPA_11_PROMPT.md
Normal file
471
sprints/sprint-1-5/ETAPA_11_PROMPT.md
Normal file
@@ -0,0 +1,471 @@
|
||||
# Sprint 1.5 — Etapa 11: Polish final + cierre formal del sprint
|
||||
|
||||
> **Objetivo:** completar los refinamientos visuales diferidos de Etapa 6 sobre la página 1 del PDF ROI (KPI Hero, banner narrativo, grid 2x2, Top 3). Ejecutar el cierre formal del Sprint 1.5: curaduría de OBSERVATIONS.md, migración de items DEFERRED, actualización de STRATEGIC_DIRECTION.md, generación de case study en methodology/, y tag del sprint.
|
||||
>
|
||||
> **Pre-requisitos:** Etapas 1-10 cerradas. CI 100% verde. 3 PDFs baseline en `tests/e2e/__output__/sprint-1-5-final/`. Docs `COVERAGE_STATE.md` y `QA_CHECKLIST.md` creados.
|
||||
>
|
||||
> **Etapa siguiente:** apertura de Sprint 2 (etapa por planificar, no parte de este sprint).
|
||||
|
||||
---
|
||||
|
||||
## 1. Esta etapa tiene dos partes diferenciadas
|
||||
|
||||
**Parte A — Polish visual** (mitad de la etapa): refinamientos del PDF ROI página 1.
|
||||
**Parte B — Cierre formal** (otra mitad): curaduría de archivos del sprint.
|
||||
|
||||
Hacé las dos partes EN ORDEN. La parte A primero. Cuando esté validada por el director, ejecutar parte B.
|
||||
|
||||
---
|
||||
|
||||
## 2. Parte A — Polish visual de página 1 PDF ROI
|
||||
|
||||
### 2.1 Alcance estricto de Parte A
|
||||
|
||||
Recoger los 4 refinamientos diferidos documentados en `TECH_DEBT.md` sección "Refinamientos visuales del PDF":
|
||||
|
||||
#### Refinamiento 1 — KPI Hero (gradiente naranja → magenta)
|
||||
|
||||
**Hallazgos del director en Etapa 6:**
|
||||
- Cifra demasiado pegada al label "AHORRO PROYECTADO A 3 AÑOS"
|
||||
- Tamaño de la cifra (USD 8.020.000,00) podría reducirse ligeramente
|
||||
- Esquinas cuadradas — pasa, pero si se logra redondear, mejor
|
||||
|
||||
**Cambios propuestos:**
|
||||
```
|
||||
Label "AHORRO PROYECTADO A N AÑOS":
|
||||
- Tamaño: 10pt (sin cambios)
|
||||
- Margin-bottom: aumentar de 6mm a 9mm (más respiro hacia la cifra)
|
||||
- Letter-spacing: 1.2pt (sin cambios)
|
||||
|
||||
Cifra principal (USD N.NNN.NNN):
|
||||
- Tamaño: bajar de 30pt a 26pt (más balanceada)
|
||||
- Tracking: -0.8pt (un poco menos cerrado)
|
||||
- Margin-bottom: 5mm (sin cambios significativos)
|
||||
|
||||
Esquinas redondeadas (intento opcional):
|
||||
- Si jsPDF permite recortar la imagen del gradiente con border-radius,
|
||||
aplicar 6mm de radius
|
||||
- Si requiere implementación compleja (cuatro triángulos blancos en
|
||||
esquinas, máscara SVG, etc.), DEJAR esquinas cuadradas y reportar
|
||||
- Tiempo máximo invertido: 30 minutos. Si no sale, pasar.
|
||||
```
|
||||
|
||||
#### Refinamiento 2 — Banner narrativo
|
||||
|
||||
**Hallazgo del director:**
|
||||
- "Texto corrido", no destaca cifras ni palabras clave
|
||||
- Podría tener tratamiento más visual
|
||||
|
||||
**Cambios propuestos:**
|
||||
```
|
||||
Estructura del banner:
|
||||
- Mantener fondo #FFF8ED + border-left 3px #F59845
|
||||
- Mantener tamaño general del texto (11pt)
|
||||
|
||||
Tratamiento tipográfico del contenido:
|
||||
- Las CIFRAS dentro del texto en peso 600 + color #B45309 (naranja oscuro):
|
||||
- "5.000 ejecuciones"
|
||||
- "3 años"
|
||||
- "USD 80.000,00"
|
||||
- "USD 540,00"
|
||||
- "90,0%"
|
||||
- "0.4 meses" (o equivalente del payback)
|
||||
|
||||
- El RESULTADO ("Resultado: ahorro de...") en peso 500
|
||||
|
||||
- El resto del texto en peso 400 (sin cambios)
|
||||
|
||||
Implementación técnica:
|
||||
- jsPDF requiere usar doc.text() con setFont() para cada segmento
|
||||
- Construir el banner como secuencia de fragmentos en lugar de párrafo
|
||||
monolítico
|
||||
- Alternativa: usar doc.text() con array de strings y posicionar
|
||||
manualmente
|
||||
```
|
||||
|
||||
#### Refinamiento 3 — Grid 2x2 KPIs secundarios
|
||||
|
||||
**Hallazgo del director:**
|
||||
- "No tienen consistencia en el uso de tipografía"
|
||||
- Verificar que los 4 cards sigan el mismo patrón visual
|
||||
|
||||
**Cambios propuestos:**
|
||||
|
||||
Auditar visualmente los 4 cards y unificar:
|
||||
```
|
||||
Card label superior (las 4 cards):
|
||||
- Tamaño: 9pt (fijo, no variar)
|
||||
- Peso: 500
|
||||
- Color: #92400E
|
||||
- Letter-spacing: 1pt
|
||||
- Uppercase
|
||||
- Margin-bottom: 5mm (fijo)
|
||||
|
||||
Card cifra principal (las 4 cards):
|
||||
- Tamaño: 18pt (fijo, no variar entre cards)
|
||||
- Peso: 700 (bold)
|
||||
- Color: #0F172A
|
||||
- Font-family: mono (alineación de números consistente)
|
||||
- Margin-bottom: 3mm
|
||||
|
||||
Card delta/contexto (las 4 cards):
|
||||
- Tamaño: 9pt (fijo)
|
||||
- Peso: 500
|
||||
- Color: #B45309
|
||||
- Margin-top: 0 (después del 3mm de margin-bottom de la cifra)
|
||||
```
|
||||
|
||||
**Específicamente verificar:**
|
||||
- Card "AHORRO POR EJECUCIÓN": la línea "-90,0% vs. actual" debe tener mismo tamaño/peso/color que las deltas de los otros cards
|
||||
- Card "PAYBACK": la línea "Dentro del horizonte" debe tener mismo tratamiento
|
||||
- Card "AHORRO ANUAL": "× 3 años" debe tener mismo tratamiento
|
||||
- Card "ROI ANUAL": "retorno anual" debe tener mismo tratamiento
|
||||
|
||||
#### Refinamiento 4 — Top 3 actividades
|
||||
|
||||
**Hallazgos del director:**
|
||||
- Título "TOP 3 ACTIVIDADES POR AHORRO" se ve pequeño
|
||||
- Las barras no tienen fondo para contraste
|
||||
|
||||
**Cambios propuestos:**
|
||||
```
|
||||
Título de la sección:
|
||||
- Texto: "TOP 3 ACTIVIDADES POR AHORRO"
|
||||
- Tamaño: aumentar de 9pt a 11pt
|
||||
- Peso: 600 (más bold)
|
||||
- Color: #92400E (naranja oscuro, en vez de gris)
|
||||
- Letter-spacing: 1.2pt
|
||||
- Margin-bottom: 8mm (más respiro hacia las barras)
|
||||
|
||||
Barras horizontales:
|
||||
- Track (fondo): mantener #FED7AA (inq-orange-100)
|
||||
- Fill: mantener #F59845 (inq-orange)
|
||||
- Aumentar visibilidad del track: agregar border 0.3pt #F59845 en track
|
||||
para definir el área completa
|
||||
- Border-radius: 1mm en track y fill
|
||||
|
||||
Layout fila:
|
||||
- Mantener grid 3 columnas (nombre 40% / barra 40% / cifra 20%)
|
||||
- Gap entre filas: 5mm (un poco más que antes)
|
||||
```
|
||||
|
||||
### 2.2 Validación visual obligatoria de Parte A
|
||||
|
||||
Cuando Claude Code termine los 4 refinamientos, **NO HACER PARTE B AÚN**. Generar el PDF ROI actualizado:
|
||||
|
||||
```
|
||||
tests/e2e/__output__/etapa-11-roi.pdf
|
||||
```
|
||||
|
||||
Y presentarlo para validación del director. El director va a:
|
||||
|
||||
1. Comparar la página 1 con el PDF de Etapa 6 (donde se identificaron los problemas)
|
||||
2. Decidir si los 4 refinamientos resuelven sus observaciones
|
||||
3. O pedir ajustes específicos
|
||||
|
||||
**Solo después del OK explícito del director sobre Parte A, ejecutar Parte B.**
|
||||
|
||||
### 2.3 Iteración esperada
|
||||
|
||||
Es probable que la primera pasada no satisfaga al 100%. El director va a dar feedback específico tipo:
|
||||
|
||||
- "La cifra del KPI Hero todavía está muy grande, bajá a 24pt"
|
||||
- "El banner no destaca lo suficiente, los números deberían ser color naranja oscuro más fuerte"
|
||||
- "Las barras del Top 3 ahora tienen border, pero el border es muy delgado"
|
||||
|
||||
**Mentalidad correcta:** la primera pasada es punto de partida. La conversación visual con el director afina hasta llegar al resultado. Esperá 1-3 iteraciones.
|
||||
|
||||
---
|
||||
|
||||
## 3. Parte B — Cierre formal del sprint
|
||||
|
||||
**Ejecutar SOLO después del OK explícito del director sobre Parte A.**
|
||||
|
||||
### 3.1 Curaduría de OBSERVATIONS.md
|
||||
|
||||
Acciones específicas:
|
||||
|
||||
1. **Items con etiqueta `[RESOLVED]`**:
|
||||
- Verificar que todos están realmente resueltos
|
||||
- Trasladar a una sección final del archivo "Historial de Sprint 1.5" o eliminarlos según preferencia del director
|
||||
|
||||
2. **Items con etiqueta `[DEFERRED-TECH-DEBT]`**:
|
||||
- Verificar que ya están migrados a `TECH_DEBT.md`
|
||||
- Si NO están migrados, migrarlos ahora
|
||||
- Eliminar de `OBSERVATIONS.md`
|
||||
|
||||
3. **Items con etiqueta `[DEFERRED-BACKLOG]`**:
|
||||
- Verificar que ya están migrados a `BACKLOG.md`
|
||||
- Si NO están migrados, migrarlos ahora
|
||||
- Eliminar de `OBSERVATIONS.md`
|
||||
|
||||
4. **Items con etiqueta `[CURRENT-SPRINT]`**:
|
||||
- Si están resueltos por Parte A (polish final), marcarlos `[RESOLVED]`
|
||||
- Si NO están resueltos, **PARAR Y CONSULTAR**: ¿se difieren a Sprint 2 o se cierran como deuda asumida?
|
||||
|
||||
5. **Vaciar el archivo dejando estructura para Sprint 2**:
|
||||
```markdown
|
||||
# OBSERVATIONS — Sprint 2
|
||||
|
||||
> Hallazgos descubiertos durante validación visual del sprint actual.
|
||||
> Este archivo se vacía al cerrar el sprint.
|
||||
|
||||
(Sin hallazgos activos. Sprint 2 inicia.)
|
||||
|
||||
## Convención de etiquetas
|
||||
|
||||
[mantener la convención de etiquetas como referencia]
|
||||
```
|
||||
|
||||
### 3.2 Actualización de STRATEGIC_DIRECTION.md
|
||||
|
||||
Agregar al final del archivo una nueva sección con reflexiones del Sprint 1.5:
|
||||
|
||||
```markdown
|
||||
## Reflexiones del cierre de Sprint 1.5
|
||||
|
||||
### Lo que funcionó
|
||||
|
||||
- [Capturar 3-5 cosas que el director identificó como aprendizajes positivos]
|
||||
- Ejemplo esperable: "Política de iniciativa proactiva con consulta clasificada
|
||||
redujo errores de scope después de Etapa 8"
|
||||
|
||||
### Lo que costó más de lo esperado
|
||||
|
||||
- [Capturar 2-3 dificultades específicas]
|
||||
- Ejemplo esperable: "El gradiente del KPI Hero requirió varias iteraciones"
|
||||
|
||||
### Decisiones arquitectónicas tomadas durante el sprint
|
||||
|
||||
- ASCII puro en fórmulas matemáticas (en lugar de Σ Unicode)
|
||||
- Layout híbrido portrait/landscape para PDFs
|
||||
- Jerarquía visual: KPI Hero exclusivo del PDF ROI
|
||||
- Badge ⚡ con posición basada en `left` (no `right`)
|
||||
- Permisos de Claude Code versionados en .claude/
|
||||
|
||||
### Estado de las definiciones del producto
|
||||
|
||||
- Identidad visual: estable hasta Sprint 4+
|
||||
- Posicionamiento de mercado: pendiente de consolidar con feedback real
|
||||
- Métricas de éxito: pendientes de definir con datos de uso
|
||||
|
||||
### Anticipación para Sprint 2
|
||||
|
||||
[Espacio para que el director complete cuando arranque Sprint 2]
|
||||
```
|
||||
|
||||
### 3.3 Generación de case study
|
||||
|
||||
Crear `methodology/CASE_STUDIES/inq-roi-sprint-1-5.md` con resumen del sprint para uso futuro del director con su equipo.
|
||||
|
||||
Estructura:
|
||||
|
||||
```markdown
|
||||
# Case Study — InQ ROI Sprint 1.5: Rediseño visual con identidad InQ
|
||||
|
||||
## Contexto inicial
|
||||
|
||||
- Producto: InQ ROI, herramienta interna de InQuality
|
||||
- Director: Marcos (CEO/fundador InQuality)
|
||||
- Equipo de ejecución: Claude Code (un solo agente) + Claude Sonnet (asesor)
|
||||
- Duración planeada: 11 etapas
|
||||
- Duración real: 11 etapas + 1 fix puntual entre Etapas 10 y 11
|
||||
|
||||
## Alcance del sprint
|
||||
|
||||
[Lista de qué se construyó: identidad visual, sistema de design,
|
||||
3 PDFs rediseñados, badge en web, metodología documentada]
|
||||
|
||||
## Aplicación del método
|
||||
|
||||
### Patrones aplicados con casos concretos
|
||||
|
||||
[Mencionar cada patrón usado durante el sprint con el caso específico
|
||||
donde se aplicó:]
|
||||
|
||||
- A.1 Brief versionado: BRIEF.md de 852 líneas, base del sprint completo
|
||||
- A.2 Mockup como contrato: mockups iterados pre-implementación
|
||||
- B.4 Reglas no negociables en CLAUDE.md: marca "InQ", política de
|
||||
iniciativa proactiva
|
||||
- C.1 Validación visual mandatoria: cazó truncamiento de notas en Etapa 5
|
||||
- C.3 Auditoría adversarial: detectó decisión proactiva no autorizada
|
||||
en Etapa 3
|
||||
- C.6 Iniciativa agéntica con consulta clasificada: refinada en Etapas 5 y 8
|
||||
- D.4 Permisos versionados en .claude/: aplicado mid-sprint
|
||||
|
||||
### Anti-patrones detectados con casos concretos
|
||||
|
||||
- AP.3 Racionalización de output anómalo: detectado en validación
|
||||
visual de Etapa 5 (compactación de páginas)
|
||||
- AP.8 Adelanto silencioso de deuda técnica: detectado en Etapa 7-8
|
||||
(reescritura de fórmulas Σ → ASCII)
|
||||
|
||||
### Cosechas del método originadas en este sprint
|
||||
|
||||
- Refinamiento del Patrón C.6 con criterios explícitos de clasificación
|
||||
- Nuevo Anti-Patrón AP.7: Bypass total de permisos en desarrollo local
|
||||
- Nuevo Anti-Patrón AP.8: Adelanto silencioso de deuda técnica
|
||||
- Nuevo Patrón D.4: Permisos del agente versionados en .claude/
|
||||
- Extensión del Principio 3: "El auditor también debe ser auditado"
|
||||
|
||||
## Lecciones aprendidas
|
||||
|
||||
[3-5 lecciones operativas que el director identificó como transferibles
|
||||
al equipo]
|
||||
|
||||
## Métricas
|
||||
|
||||
- Etapas: 11 (+ 1 fix puntual)
|
||||
- Tests: 526 unit + 38 E2E al cierre
|
||||
- Archivos modificados/creados: [contar de los commits]
|
||||
- Decisiones de iniciativa: total y desglose por nivel
|
||||
- Casos de mala clasificación de iniciativa: 2 (Etapas 5 y 7-8)
|
||||
|
||||
## Material para transmisión al equipo
|
||||
|
||||
[Sugerencias de qué partes de este case study usar en las 4 sesiones
|
||||
× 1h de transmisión del método al equipo de 5 técnicos de InQuality]
|
||||
```
|
||||
|
||||
### 3.4 Tag final del sprint
|
||||
|
||||
```bash
|
||||
git tag sprint-1-5-cerrado
|
||||
git push --tags
|
||||
```
|
||||
|
||||
### 3.5 Validación final del cierre
|
||||
|
||||
Antes de declarar Etapa 11 (y Sprint 1.5) cerrados:
|
||||
|
||||
- [ ] OBSERVATIONS.md vaciado o resetado para Sprint 2
|
||||
- [ ] STRATEGIC_DIRECTION.md actualizado con reflexiones del sprint
|
||||
- [ ] CASE_STUDIES/inq-roi-sprint-1-5.md creado
|
||||
- [ ] Tag git `sprint-1-5-cerrado` creado
|
||||
- [ ] Suite completa de tests sigue 100% verde
|
||||
- [ ] CI limpio
|
||||
|
||||
---
|
||||
|
||||
## 4. Validaciones automatizadas
|
||||
|
||||
```
|
||||
Parte A — Polish visual:
|
||||
1. PDF ROI etapa-11-roi.pdf generado, 5 páginas
|
||||
2. Página 1: cifra del KPI Hero ≤ 26pt
|
||||
3. Página 1: banner narrativo con cifras destacadas (verificar fragmentos
|
||||
de texto con setFont en peso 600)
|
||||
4. Página 1: grid 2x2 con tamaños consistentes en los 4 cards
|
||||
5. Página 1: título "TOP 3 ACTIVIDADES POR AHORRO" en color naranja
|
||||
oscuro (#92400E)
|
||||
6. PDFs Actual y Automatizado: SIN CAMBIOS respecto a Etapa 8
|
||||
7. Tests previos siguen verdes (526 unit + 38 E2E)
|
||||
|
||||
Parte B — Cierre formal:
|
||||
8. OBSERVATIONS.md tiene estructura limpia para Sprint 2
|
||||
9. STRATEGIC_DIRECTION.md tiene nueva sección de reflexiones
|
||||
10. methodology/CASE_STUDIES/inq-roi-sprint-1-5.md existe y tiene
|
||||
estructura mínima esperada
|
||||
11. Tag git sprint-1-5-cerrado existe en local (push pendiente del director)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. Entregables (Definition of Done)
|
||||
|
||||
```
|
||||
PARTE A:
|
||||
[ ] 4 refinamientos del PDF ROI página 1 aplicados según especificación
|
||||
[ ] PDF ROI etapa-11-roi.pdf generado para validación visual
|
||||
[ ] PDFs Actual y Automatizado NO modificados
|
||||
[ ] Tests previos verdes
|
||||
[ ] OK explícito del director sobre Parte A antes de avanzar
|
||||
|
||||
PARTE B:
|
||||
[ ] OBSERVATIONS.md curado y reseteado para Sprint 2
|
||||
[ ] STRATEGIC_DIRECTION.md actualizado con reflexiones
|
||||
[ ] methodology/CASE_STUDIES/inq-roi-sprint-1-5.md creado
|
||||
[ ] Tag git sprint-1-5-cerrado local
|
||||
[ ] CI 100% verde
|
||||
[ ] Reporte final entregado
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. Reporte final a entregar
|
||||
|
||||
1. **Tabla de archivos modificados/creados** (parte A + parte B separadas)
|
||||
2. **PDF ROI etapa-11-roi.pdf presentado** con path absoluto
|
||||
3. **Validaciones automatizadas confirmadas** (11 puntos)
|
||||
4. **Resumen de cambios en cada refinamiento**: qué se modificó exactamente
|
||||
5. **Decisiones tomadas durante refinamientos** (especialmente sobre
|
||||
esquinas redondeadas del KPI Hero — sí/no se logró)
|
||||
6. **Resumen de curaduría**: cuántos items procesados de cada estado
|
||||
([RESOLVED], [DEFERRED-*], [CURRENT-SPRINT])
|
||||
7. **Confirmación de tag git** y estado final del sprint
|
||||
8. **Decisiones de iniciativa proactiva** según política CLAUDE.md
|
||||
|
||||
---
|
||||
|
||||
## 7. Reglas operativas
|
||||
|
||||
1. **PARTE A ANTES DE PARTE B.** No mezclar. Cuando Parte A está validada
|
||||
por el director, recién entonces ejecutar Parte B.
|
||||
|
||||
2. **ITERACIÓN EN PARTE A.** Los refinamientos visuales pueden requerir
|
||||
2-3 pasadas. Eso es normal. Mantener iteraciones acotadas a feedback
|
||||
específico del director, sin re-rediseñar de cero.
|
||||
|
||||
3. **NO TOCAR PDFs Actual y Automatizado.** Cerrados en Etapa 8.
|
||||
|
||||
4. **NO MODIFICAR código no relacionado con los 4 refinamientos** durante
|
||||
Parte A. Es polish, no refactor.
|
||||
|
||||
5. **EN PARTE B, las decisiones de curaduría son del director.** Si un
|
||||
item DEFERRED no está claro a dónde migrar, consultar. Si un item
|
||||
CURRENT-SPRINT no se resolvió en el sprint, consultar antes de
|
||||
diferirlo automáticamente.
|
||||
|
||||
6. **Política de iniciativa refinada (post-Etapa 8):**
|
||||
- Cambios en código fuera de los 4 refinamientos: Nivel 3 — consultar
|
||||
- Cambios en archivos de documentación dentro del scope de Parte B:
|
||||
Nivel 2 — reportar
|
||||
- Eliminar items de OBSERVATIONS.md: SIEMPRE Nivel 2 (reportar lo
|
||||
que se eliminó/movió)
|
||||
|
||||
7. **Si encontrás contradicción** entre prompt y código: PARÁ y consultá.
|
||||
|
||||
8. **Si la iteración de Parte A se extiende mucho**, evaluar con el
|
||||
director si vale la pena cerrar Etapa 11 con el polish "razonable"
|
||||
y diferir refinamientos finos a una etapa de mantenimiento en Sprint 2.
|
||||
|
||||
---
|
||||
|
||||
## 8. Por qué esta etapa importa
|
||||
|
||||
Etapa 11 es **el cierre del primer sprint donde se construyó el método mientras se construía el producto**. Lo que decidas acá determina:
|
||||
|
||||
1. La calidad final del entregable visual que va a clientes
|
||||
2. La calidad del registro del sprint (case study + reflexiones)
|
||||
3. La capacidad de transmitir el método a tu equipo con material concreto
|
||||
|
||||
**No te apures con esta etapa.** Si Parte A requiere 3 iteraciones, está bien. Si Parte B requiere 1 hora de curaduría con decisiones por item, está bien.
|
||||
|
||||
El éxito de Etapa 11 NO se mide en velocidad. Se mide en:
|
||||
- Página 1 del PDF ROI alcanza el nivel que vos pretendías al inicio del sprint
|
||||
- Sprint 1.5 cierra con artefactos transferibles (case study + docs actualizados)
|
||||
- Tu equipo puede ver Sprint 1.5 como ejemplo concreto del método en acción
|
||||
|
||||
---
|
||||
|
||||
## 9. Después de Etapa 11
|
||||
|
||||
Cuando esta etapa cierre:
|
||||
|
||||
- Sprint 1.5 queda completamente cerrado
|
||||
- Tu siguiente trabajo es planificar Sprint 2 con la dirección estratégica documentada (rebalanceo web/PDF, criterio de wow obligatorio)
|
||||
- Las 4 sesiones × 1h de transmisión metodológica al equipo pueden arrancar usando el case study como material
|
||||
|
||||
Es el momento de inflexión. Sprint 1.5 fue donde construiste vocabulario, patrones y método. Sprint 2 va a ser donde vos aplicás eso para producir features de valor, y donde tu equipo eventualmente toma el método y lo usa.
|
||||
|
||||
Esta es la última etapa donde estamos todos enfocados solo en InQ ROI. Después, el método cobra vida propia.
|
||||
Reference in New Issue
Block a user