Files
inq-roi-simulador-web/TODO.md
Marcos Benítez 2f4633a33c feat(sprint-1.5): rediseño visual PDF ROI + identidad InQ (Etapas 4-7)
- Header/footer compartidos con paleta InQ naranja en los 3 PDFs (Etapa 4)
- Layout híbrido portrait+landscape en PDFs Actual/Automatizado:
  página 2 landscape para diagrama BPMN heatmap (Etapa 5)
- Página 1 PDF ROI rediseñada: header denso, banner narrativo, KPI Hero
  con gradiente naranja→magenta, grid 2×2 de KPIs secundarios, Top 3
  actividades por ahorro (Etapa 6)
- Páginas 2-5 PDF ROI con identidad InQ: tabla con paleta naranja,
  análisis del ahorro, nota metodológica, trayectoria del ahorro
  acumulado con gráfico SVG nativo (Etapa 7)
- 500 tests verdes (+ 34 tests nuevos del Sprint 1.5)
- BACKLOG.md, TECH_DEBT.md, OBSERVATIONS.md: sistema de planificación
  reemplaza TODO.md

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-05-17 20:45:01 -03:00

195 lines
11 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# TODO — Process Cost Platform · Fase 1
> Features descartadas del MVP (scope defendido) para no arriesgar la fecha.
> Ordenadas por impacto estimado.
## Alta prioridad
- [ ] **Múltiples simulaciones**: historial de simulaciones por proceso con comparación de escenarios
- [ ] **Recursos con costo por hora**: link actividad ↔ recurso (rol, persona, sistema) con cálculo automático
- [ ] **Edición del nombre del proceso y cliente** desde el workspace (sin ir a configuración global)
- [ ] **Gateway OR inclusivo nativo**: actualmente se simula como XOR; implementar propagación OR real
- [ ] **Distribuciones de probabilidad**: gamma/triangular por actividad en lugar de valores fijos
## Media prioridad
- [ ] **Export a Excel** (.xlsx) con múltiples hojas (resumen + por actividad + metodología)
- [ ] **Modo oscuro** (Dark mode)
- [ ] **i18n**: inglés + español configurable
- [ ] **PWA installable**: manifest + service worker para uso offline
- [ ] **Zoom/pan del heatmap** desde el reporte (ahora es solo visualización estática)
- [ ] **Detalle de recursos por actividad** en el PDF (tabla de costos por recurso asignado)
- [ ] **Importación por URL**: cargar BPMN desde enlace directo (GitHub, Confluence, etc.)
## Refinamientos UX
- [ ] **Mejorar animación de expansión de la sección "Automatización" en ActivityPanel.** Actualmente usa max-h trick (funciona pero la aceleración no es lineal en los últimos píxeles porque el contenedor crece hasta un max fijo de 320px). Solución sofisticada: `useRef + scrollHeight` para animar a la altura real del contenido. Costo: medio. Beneficio: micro-pulido visual.
## Deuda técnica / Decisiones arquitectónicas pendientes
- [ ] **Dexie live queries (Modelo B de sincronización store↔db)**: Hoy la invalidación del resultado de simulación se garantiza via ESLint rule (`no-restricted-imports`) + convención: todas las mutaciones pasan por `useProcessStore`. Si en Sprint 2 la grilla de edición masiva requiere escrituras de alta frecuencia directas a IndexedDB (por performance), evaluar migración a live queries de Dexie que invaliden el store automáticamente. Documentado en la auditoría de Mayo 2026.
- [ ] **Indicador visual en el reporte de actividades automatable** (borde punteado o ícono diferenciador): en Sprint 1 se usa solo leyenda de texto. Evaluar si el cliente necesita más claridad visual al comparar Actual vs Automatizado.
- [ ] **Sprint 3-4: revisar paleta del heatmap** (verde/ámbar/rojo saturados vs. pasteles). Los colores saturados actuales (`#10B981`, `#F59E0B`, `#EF4444`) funcionan bien en pantallas grandes de talleres. El brief de Sprint 1.5 propone pasteles más "consultivos" (`#BBF7D0`, `#FED7AA`, `#FECACA`), pero el cambio requiere recalibrar los tests E2E de análisis de píxeles (umbrales de verde/ámbar/rojo). Hacer con feedback real de uso en talleres InQuality.
- [ ] **Columna "Eficiencia de automatización" en ComparisonTable**: métrica = `(ahorro$ × probabilidad) / inversión-prorrateada`. Permite rankear actividades por "qué tan valiosa es automatizar cada una" en lugar de solo "cuánto cuestan". Útil en conversaciones de pre-venta donde el cliente quiere priorizar qué automatizar primero.
- [ ] **ComparisonTable — actividades no automatizables muestran "USD 0,00" y "0,0%"**: semánticamente incorrecto. El ahorro de una actividad no automatizable no es "cero", es "no aplica". Cambiar por "—" (em dash) en columnas Ahorro y % Ahorro para filas donde `isAutomatable === false`. Implementar en Etapa 3 al rediseñar ComparisonTable con paleta InQ. (detectado en Sprint 1.5 Etapa 2)
## Baja prioridad / Fase 2
- [ ] **Login y multi-tenant**: persistencia en la nube, colaboración
- [ ] **Versionado de procesos**: historial de cambios con diff visual
- [ ] **Gobernanza/RACI**: asignación de responsables por actividad
- [ ] **Jerarquía organizacional**: integración con orgchart para asignar costos por área
- [ ] **IA / asistente**: sugerencias de optimización, benchmarking automático
- [ ] **Marketplace de procesos**: biblioteca de BPMNs precostos por industria
- [ ] **Elementos RPA y agentes**: soporte para costos de bots y workflows automatizados
- [ ] **Tutoriales interactivos**: onboarding guiado para usuarios nuevos
## Observaciones de Etapa 3 (Sprint 1.5) — pendientes de Sprint 3-4 o posterior
### 1. Footer "Hecho desde Paraguay 🇵🇾" — evaluar destino
**Estado:** mantenido en web app por decisión del director.
**Decisión pendiente:** ¿se mantiene en producción cuando InQuality eventualmente venda a clientes internacionales no-LATAM?
**Argumentos a favor:** identidad regional, toque humano, diferenciador respecto a herramientas anónimas, alineado con tendencia LATAM de productos open source ("Made in Argentina/Brasil/etc.").
**Argumentos en contra:** sesgo gringo en clientes corporativos puede leer la firma regional como debilidad de credibilidad.
**Acción:** evaluar en Sprint 3-4 con feedback de uso real en talleres y demos. Decisión depende del posicionamiento de mercado.
---
### 2. Versión "v0.1.0" en footer — eliminar de PDFs
**Estado:** aparece en footer web. Decisión: **mantener en web, sacar de PDF**.
**Justificación:** en web la versión es útil para el usuario interno (saber qué features tiene). En PDFs entregados al cliente, la versión puede generar dudas de estabilidad ("¿v0.1.0 es producción?").
**Acción:** en Etapa 4 (PDF: header y footer compartidos), no incluir versión en el footer del PDF. Documentar como decisión de diseño en CLAUDE.md o ARCHITECTURE.md.
---
### 3. CumulativeSavingsChart — empezar en `-inversión`, no en 0
**Estado:** actualmente el gráfico parte de `(Año 0, 0)`. Decisión: cambiar a `(Año 0, -inversión)` para ser financieramente honesto.
**Justificación:** el modelo actual muestra ahorro bruto acumulado, no neto. Mostrar el punto inicial como `-USD 80.000` (la inversión) hace visible el "valle de retorno": la línea cruza el cero exactamente en el mes de payback. Es la representación estándar en análisis financiero.
**Impacto:**
- Cambio en `src/features/report/CumulativeSavingsChart.tsx` (web)
- Cambio en `src/lib/export/pdf-sections-roi.ts` cuando se rediseñe el chart en Etapa 6 (PDF)
- Aplicar consistente en ambas vistas
**Acción:** incorporar en roadmap de Etapa siguiente del Sprint 1.5 (probablemente Etapa 6 cuando se rediseñe la página 1 del PDF ROI). Si Etapa 6 ya tiene scope cerrado, mover a Sprint 2.
---
### 4. Label "Payback" superpuesto con eje Y en CumulativeSavingsChart
**Estado:** bug visual menor. El texto del marker vertical "Payback · X meses" se superpone con los labels del eje Y (`0.0M`, `2.0M`, etc.).
**Acción:** ajustar offset del label del marker payback en `CumulativeSavingsChart.tsx`. Trabajo de 10 min en próxima etapa que toque el componente.
**Prioridad:** baja. No afecta funcionalidad, solo polish visual.
---
## Observaciones de Etapa 4 (Sprint 1.5)
### 1. Subtítulo "Análisis de retorno de inversión" solo en página 1 ROI
**Estado:** decisión visual aprobada. Página 1 tiene subtítulo descriptivo,
páginas 2-4 no.
**Acción:** evaluar en Etapa 6 si el subtítulo se refina o se mantiene.
### 2. Punto de partida del KPI card en página 1 de PDFs Actual/Automatizado
**Estado:** color del KPI "Costo total" migrado a naranja en Etapa 4
(decisión retroactiva del audit).
**Acción:** en Etapa 6, el rediseño del KPI card debe asumir punto de
partida naranja, no azul.
### 3. Unicode roto en notas metodológicas — investigar fuente
**Estado:** caracteres Σ (sumatoria), (menos matemático) renderizan
como £ (libra) y " (comilla) respectivamente. Pre-existente.
**Causa probable:** jsPDF con fuente WinAnsi no soporta esos puntos
Unicode.
**Solución estándar:** embeber fuente Unicode (Roboto o similar) con
doc.addFileToVFS() + doc.addFont().
**Acción:** Sprint 2 — etapa dedicada a font embedding en PDFs. NO
abordar en Sprint 1.5 (riesgo de regresión en este punto del sprint).
---
### Notas operativas
- Las 4 observaciones se descubrieron en validación visual del director (no en tests ni reporte automático).
- Refuerzan el valor del **Patrón C.1** (validación visual mandatoria del artefacto final).
- Punto 1 dio origen al **Patrón C.6** documentado en `methodology/` (iniciativa agéntica con consulta).
### Sprint 2 — Nota metodológica de PDFs: fórmulas truncadas + Unicode roto
**Severidad:** afecta calidad del entregable al cliente. Mantenido como
deuda consciente, no como descuido.
**Síntomas observados en Sprint 1.5 Etapa 5:**
1. Fórmulas matemáticas largas se cortan en el margen derecho.
Ejemplo en PDFs Actual y Automatizado, página 4:
"Costo directo por actividad = (costo_fijo + £(recurso × costo_hora
× tiempo × utilización / 60)"
→ faltan "))" y "× probabilidad_de_ejecución."
Ejemplo en PDF ROI, página 4:
"...Probabilidades calculada" → falta "del grafo BPMN."
2. Caracteres Unicode renderizan mal:
Σ (sumatoria) → £ (libra)
(menos matemático) → "
**Causa raíz hipotetizada:**
- jsPDF con fuente WinAnsi no soporta esos puntos Unicode (caracteres rotos)
- Falta de wrapping automático de líneas largas en notas metodológicas
**Resolución propuesta para Sprint 2:**
- Etapa dedicada a "PDF: font embedding y text wrapping"
- Embeber Roboto Unicode completo (doc.addFileToVFS + doc.addFont)
- Usar doc.splitTextToSize() para todas las notas metodológicas
- Validar con tests que ninguna línea supera el ancho disponible
**Workaround temporal (si surge demo o entrega antes de Sprint 2):**
- Reformular fórmulas como multi-línea en el texto fuente
- 10-15 min de trabajo, soluciona el síntoma sin embeber fuente
**Archivos afectados:**
- src/lib/export/pdf-sections.ts (notas metodológicas Actual/Automatizado)
- src/lib/export/pdf-sections-roi.ts (nota metodológica ROI)
## Refinamientos visuales para Etapa 11 (polish final) — derivados de Etapa 6
### Página 1 del PDF ROI
1. **KPI Hero**:
- Spacing entre label "AHORRO PROYECTADO A 3 AÑOS" y la cifra
- Tamaño de la cifra (evaluar reducir ligeramente)
- Esquinas redondeadas (si se logra técnicamente)
2. **Banner narrativo**:
- Destacar tipográficamente cifras y palabras clave (negrita en USD, %, meses)
- Considerar bullets o estructura más visual
3. **Grid 2x2 KPIs secundarios**:
- Inconsistencia tipográfica detectada — investigar y armonizar
- Verificar que los 4 cards sigan el mismo patrón visual
4. **Top 3 actividades**:
- Aumentar tamaño del título "TOP 3 ACTIVIDADES POR AHORRO"
- Agregar fondo claro a las barras para mejor contraste
- Reconsiderar diseño completo del bloque
### Decisiones diferidas a Sprint 3-4
- Ícono de InQuality en header (requiere assets de marca)
- Esquinas redondeadas del KPI Hero (técnicamente complejo en jsPDF)