# Case Study: InQ ROI — Sprint 2

**Proyecto:** InQ ROI — herramienta interna de consultoría de procesos BPMN  
**Sprint:** 2 (mayo 2026)  
**Duración:** 6 etapas  
**Tests al cierre:** 548 (eran 541 al inicio)  
**Deploy:** https://process-cost-platform.pages.dev

---

## Objetivo del sprint

Completar y elevar el modelo de recursos con costo por hora: migrar de `utilizationPercent` a `utilizationMinutes + units`, construir la experiencia "wow" encima, y hacer visible el desglose de recursos en el reporte web y en el PDF. Complementado con mejoras de UX para uso en talleres.

---

## Etapas y entregables

| Etapa | Contenido | Resultado |
|---|---|---|
| 1 | Migración modelo + Dexie v3 | `utilizationPercent → utilizationMinutes + units`, migración datos preservada, tests verdes |
| 2 | ActivityPanel "wow" | Inputs numéricos, cálculo en tiempo real, helper contextual, resumen de costos naranja |
| 3 | Reporte web: desglose + TECH_DEBT | Filas expandibles en tabla, payback label fix, badge 20px, CumulativeSavingsChart verificado |
| 4 | UX rápidos | Edición inline de nombre de proceso y cliente en header del workspace |
| 5 | PDF: tabla de recursos | Sección condicional en página 4/5, chips de tipo por recurso, fix truncamiento |
| 6 | Fixes + tests | Acentos corregidos, columna Esp. (USD), 7 tests nuevos (541→548) |

---

## Decisiones de método documentadas en este sprint

### AP.9 — Resolución unilateral de restricciones contradictorias

**Origen:** Etapa 1. El prompt tenía dos requisitos que colisionaban: `❌ no tocar ActivityPanel.tsx` y `build sin errores TypeScript`. Cambiar `ActivityResourceAssignment` en `types.ts` inevitablemente generaba errores TypeScript en `ActivityPanel.tsx`. El agente resolvió la contradicción actuando mínimamente en el archivo restringido en lugar de detenerse.

**Daño:** slider roto (stuck en 1 min), requirió toda la Etapa 2 para corregir.

**Aprendizaje:** cuando haya restricción `❌` absoluta sobre un archivo, el prompt debe incluir explícitamente la instrucción de detenerse ante conflictos, no resolverlos unilateralmente. Si el conflicto es inevitable por dependencias de tipos, resolverlo en el prompt antes de dárselo al agente.

**Documentado en:** `methodology/ANTI_PATTERNS.md` como AP.9.

---

### C.7 — Control preventivo de scope con `git diff`

**Origen:** Etapa 1 (como respuesta a AP.9). Los controles detectivos existentes (grep, build, tests) verifican que el código funciona pero no detectan archivos modificados fuera del scope.

**Solución:** incluir en todo prompt:
```bash
git diff --name-only HEAD
```
Con instrucción explícita: si aparece un archivo no autorizado → revertirlo y reportarlo como conflicto de scope, no incluirlo en el entregable.

**Resultado:** aplicado desde Etapa 2. Ningún conflicto de scope no declarado en Etapas 3-6.

**Documentado en:** `methodology/PATTERNS.md` como C.7.

---

## Hallazgos técnicos reutilizables

### rowSpan en jsPDF-autotable no está soportado en body cells

Intentado en `drawResourcesSection` para agrupar filas por actividad. No funciona en body rows. Solución: repetir el nombre de actividad en cada fila. El prompt lo anticipó correctamente con salida de emergencia — pero el tiempo de investigación fue real.

**Para futuros prompts de PDF con tablas agrupadas:** especificar desde el inicio que se use repetición en lugar de rowSpan, o usar `didParseCell` hook si se necesita estilización diferencial.

### `void resources` como placeholder de deuda técnica

En `exportScenarioPdf`, el parámetro `resources` estaba silenciado con `void resources` desde Sprint 1.5. Al agregar la tabla de recursos en Etapa 5, se eliminó ese placeholder. Patrón a evitar: silenciar parámetros con `void` en lugar de documentar la deuda explícitamente en `TECH_DEBT.md`.

### Modelo `utilizationMinutes + units` más natural para talleres

La pregunta "¿cuántos minutos dedica el analista a esta actividad?" es verificable en una entrevista con el cliente. La pregunta anterior "¿qué porcentaje de utilización tiene?" generaba confusión. El cambio de modelo mejoró la calidad de la elicitación de datos de costos en contexto real.

---

## Proporción web/PDF al cierre

| Componente | Etapas | % real | % comprometido |
|---|---|---|---|
| Web app | 1, 2, 3, 4 | ~65% | 60-70% |
| PDF | 5, 6 | ~30% | 15-25% |
| Tests/fixes | 6 | ~5% | 10-15% |

PDF ligeramente por encima del rango comprometido (tabla de recursos + fixes visuales). Justificado por el valor del entregable para pre-venta.

---

## Estado al cierre del sprint

**TECH_DEBT cerrados en Sprint 2:**
- CumulativeSavingsChart -inversión: verificado (ya estaba correcto)
- Payback label superpuesto: corregido
- Badge ⚡ tamaño: 20×20px, validado visualmente
- Truncamiento notas metodológicas: auditado, 2 líneas corregidas

**Pendientes para Sprint 3:**
- Modelo B (AS-IS/TO-BE con dos BPMNs)
- Catálogo global de recursos compartido
- Recursos en escenario automatizado
- Indicador de simulación desactualizada (alta prioridad, bajo esfuerzo)
- Posicionamiento: primera conversación sobre herramienta interna vs. venta externa
