# 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. --- ### 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).