Nuevas funcionalidades
n-735 Board conciliaciones enhancement
Repos: front · Tipo: Feature · PRs: front #493 · sha: 7890029
En el listado de conciliaciones, al hacer clic en una fila ya no se expande hacia abajo: ahora se abre un panel lateral de detalle que muestra las métricas de la conciliación y sus archivos, y podés cambiar de fila sin cerrarlo. Además, en la vista y edición de una conciliación aparecen tarjetas de resumen con los totales, y se mejoró la apariencia (estado 'cerrada' en naranja y mejor legibilidad en modo oscuro).
En la lista de conciliaciones, clic en una fila abre el panel lateral (no modal) con las tarjetas de resumen y la tabla de archivos; verificar que se cierra con clic afuera, la X o Escape, y que al cambiar rápido de fila no queden datos viejos por respuestas tardías. Confirmar que la fila 'Diferencia' se excluye del resumen y que el porcentaje solo llega a 100% cuando no quedan registros sin conciliar. Comprobar el chip naranja en estado cerrado, la sección de resumen entre datos y archivos en editar/ver (recarga al cargar y al guardar), colores de hover/selección en modo oscuro, y que las acciones de la fila sigan funcionando (sin abrir el panel).
Reemplazar el expand de fila por un panel de detalle no modal mejora la lectura de conciliaciones al mantener la lista visible y permitir saltar entre filas, y unifica la presentación de métricas (tarjetas de resumen reutilizables) entre el panel y la vista/edición. Es un cambio aditivo de frontend (row-click opcional en la tabla) que no afecta otras pantallas y suma pulido visual (estado cerrado, modo oscuro).
n-736 Dashboard enhancement
Repos: api + front · Tipo: Feature · PRs: api #584, front #492 · sha: 870f341 / eed4be7
En el dashboard de Conciliaciones ahora podés ver el detalle por empresa: las 4 empresas con mayor monto conciliado y el resto agrupado como 'Otros', con la cantidad y montos de conciliaciones abiertas y cerradas. Además, los gráficos se renovaron (barras radiales, barra apilada por empresa y un gráfico de evolución más claro) para leer mejor la información.
Llamar GET /api/v1/conciliation/report/?group_by=status y verificar que la respuesta incluye grouped_by_status (sin cambios), y ahora también grouped_by_company (hasta 4 empresas ordenadas por monto conciliado), others (null cuando hay 4 empresas o menos) y meta. Confirmar los conteos y montos open/closed por empresa y en el bucket 'Otros'. Validar que los filtros existentes (fecha, empresa, categoría, estado, moneda) siguen aplicando igual. En el front: confirmar que se renderizan los nuevos gráficos ApexCharts y que el porcentaje se calcula con valor absoluto cuando el monto conciliado es negativo.
Se enriqueció el dashboard de Conciliaciones con visibilidad de montos por empresa y visualizaciones renovadas, dando una lectura de negocio más accionable sobre dónde se concentra la conciliación. El cambio mantiene compatibilidad con el payload y los filtros existentes, por lo que no rompe integraciones actuales.
n-746 Redisenar prime table lazy fecha compuesta columnas responsive estilo driv
Repos: front · Tipo: Feature · PRs: front #508 · sha: 924e72a
Las tablas de administración ahora se ven mejor en pantallas angostas: ocultan automáticamente las columnas menos importantes según prioridad, muestran las fechas en un formato claro con la fecha completa al pasar el mouse, y ordenan las acciones de cada fila mostrando las principales al pasar el cursor y el resto en un menú de tres puntos. En celular las acciones se agrupan en ese menú para no saturar la fila.
Verificar en las ~18 pantallas migradas (agentes, alertas, calendario, categorías, empresas, conciliaciones, data manager, integraciones, procesos, scripts, ejecuciones, estado, usuarios, event-logs y dashboard): 1) achicar el viewport y confirmar que las columnas se ocultan progresivamente por prioridad; 2) que las fechas muestren formato corto con tooltip de fecha completa; 3) acciones primarias visibles al hover en desktop y solo el menú kebab en touch; 4) que no aparezca el error NG02100 en event-logs (pasar timestamp crudo); 5) el expand de scripts y las acciones custom de calendario/scripts (play/stop, logs) funcionando; 6) la acción Renombrar en el panel de detalle de conciliaciones; y que sigan funcionando notas, row-click en conciliaciones y el opt-in de notas.
Unifica la UX de todos los listados de administración con un patrón moderno tipo Google Drive, resolviendo columnas que desbordaban en viewports estrechos, formatos de fecha inconsistentes (y el bug NG02100), filas saturadas por acciones siempre visibles y tablas anidadas rotas en móvil, sin romper los flujos existentes.
n-757 Gestion de kpis en unimate
Repos: api + front · Tipo: Feature · PRs: api #589, front #505 · sha: f0a26fb / 7b12c90
Ahora podés definir tus propios indicadores (KPIs) sobre las columnas de tus datos, tanto en Data Manager como en Conciliaciones. Elegís un nombre, la columna y la operación (suma, promedio, conteo, mínimo, máximo, conteo de valores distintos o no vacíos) y Unimate calcula el resultado automáticamente al procesar el lote o la conciliación, con soporte para montos en la moneda correspondiente.
Con el feature flag dynamic_kpi_indicators activo: crear un lote de Data Manager enviando el array 'indicators' y verificar que al terminar el procesamiento se calculan los resultados; hacer PATCH con nuevas definiciones y confirmar que se reemplazan y se recalculan en background (respuesta inmediata con result null y luego valor). Repetir en Conciliaciones vía PATCH {file_id, indicators} y comprobar el cálculo en el mismo pase del job de Excel. Validar cada operación (SUM/COUNT/COUNT_NON_NULL/COUNT_DISTINCT/AVG/MIN/MAX), que SUM/AVG/MIN/MAX sobre columna no numérica arrojen el error non_numeric_column y que is_monetary=true incluya la moneda. Verificar recálculo tras alta/edición/borrado y movimiento/importación de registros, y con el flag apagado que la funcionalidad quede inactiva.
Elimina el desarrollo ad hoc por cada métrica nueva: permite que clientes e integraciones definan KPIs personalizados y persistidos sobre datos arbitrarios, habilitando reporting configurable (SLA, financiero, analítica) y dejando la base para que el Dashboard consuma estos resultados a futuro.
n-762 Addpipelinecache
Repos: front · Tipo: Feature · PRs: front #499 · sha: d2da242
No hay cambios visibles en la aplicación. Es una mejora interna del proceso de construcción y publicación de la plataforma.
Ejecutar el workflow 'Build & Push cloud-front' en GitHub Actions y verificar: (1) que el Job Summary muestre los 3 últimos tags git al iniciar; (2) que el build de Docker use caché de capas (--cache-from/--cache-to type=gha) y que una segunda corrida sea más rápida al reutilizar node_modules; (3) que la imagen se publique correctamente en GHCR con el tag {version}_{environment}.
Optimiza el pipeline de despliegue de cloud-front cacheando las capas de Docker (node_modules) entre builds, reduciendo tiempos de construcción y publicación. Además mejora la usabilidad al listar los últimos tags disponibles en el resumen del job. No impacta funcionalidad del producto; acelera el ciclo de entrega.
n-765 Cross batch search multi category currency
Repos: api + front · Tipo: Feature · PRs: api #590, front #506 · sha: d86ed73 / 06b3550
Ahora podés buscar registros en varias categorías a la vez en una sola búsqueda (antes había que repetirla categoría por categoría) y, si querés, acotar los resultados a una única moneda. Cada fila del resultado muestra a qué categoría pertenece. Al filtrar por moneda, los lotes que no tienen moneda asignada quedan fuera de los resultados (la interfaz te avisa de esto).
1) Ejecutar una búsqueda con una sola categoría y verificar que sigue funcionando igual que antes (backward compatible). 2) Seleccionar dos o más categorías y confirmar que los resultados combinan registros de todas. 3) Aplicar un filtro de moneda (código ISO de 3 letras) y verificar que solo aparecen registros de lotes con esa moneda y que los lotes sin moneda quedan excluidos. 4) Verificar que cada fila muestra category_id/category_name. 5) Pedir una categoría fuera del provider del usuario y confirmar que la búsqueda se rechaza por completo (400, fail-closed) con mensaje claro. 6) Confirmar que el código de moneda se normaliza a mayúsculas.
Reduce fricción y errores en operaciones multi-categoría y multi-moneda del Data Manager: antes los usuarios debían repetir la búsqueda una vez por categoría y separar a mano los resultados de distintas monedas. Con un solo request que abarca varias categorías y filtra por moneda, se agiliza la comparación y búsqueda de registros equivalentes, manteniendo el comportamiento previo intacto y con validación de alcance por provider.
Correcciones
n-745 Campos obligatorios y borrado de responsable en bots
Repos: api + front · Tipo: Fix · PRs: api #586, front #495 · sha: 9e32e04 / c490ec5
Al cargar o editar un bot ya podés dejar vacío o borrar el responsable y los demás datos operativos (bots previos/siguientes, documentación) y el cambio se guarda correctamente. Además, el selector de responsable ahora muestra solo personas reales, sin duplicados.
Editar un bot con responsable asignado, borrarlo (dejar el campo vacío) y guardar: debe quedar sin responsable y sin error. Verificar que el desplegable de responsables liste solo personas humanas (sin filas legales/proveedor duplicadas) y que asigne la persona correcta cuando el usuario tiene registro legal + humano. Limpiar 'bots previos' y 'bots siguientes' y guardar: deben quedar vacíos ([]), sin reenviar IDs anteriores. Dejar en blanco documentación, contingencia y archivos usados y confirmar que se guardan vacíos.
Los campos operativos de bots (responsable, dependencias, documentación), pensados para trazabilidad y gobierno, ya podían cargarse pero no borrarse de forma confiable, y el responsable se resolvía mal cuando existían registros Person duplicados (legal + humano). Este fix asegura edición y borrado consistentes y un mapeo correcto del responsable alineado con la lista de personas, mejorando la calidad de la metadata operativa.
n-758 Angular budget
Repos: front · Tipo: Fix · PRs: front #491 · sha: da37dba
No hay cambios visibles en la aplicación. Es un ajuste interno de la configuración de compilación del frontend para que estilos algo más grandes no interrumpan la generación de la app.
Verificar que la compilación del frontend termina sin errores ni warnings de budget de estilos: correr el build de producción y confirmar que ya no falla por 'anyComponentStyle' que antes superaba 7kb (ahora el error se dispara recién a 12kb y el warning a 8kb). Confirmar que la app sigue cargando y renderizando igual que antes.
Se subieron los umbrales de tamaño de estilos por componente (warning 2kb→8kb, error 7kb→12kb) para desbloquear el build del frontend, que fallaba cuando algún componente excedía el límite anterior. Es deuda técnica/mantenimiento: destraba despliegues sin impacto funcional para el usuario.
n-771 Errores runtime conciliate data manager
Repos: front · Tipo: Fix · PRs: front #496 · sha: 6be3b86
Se corrigieron fallos al abrir las pantallas de conciliación y de data manager: ya no aparecen errores que degradaban la experiencia y el indicador 'Total verificado' vuelve a mostrarse correctamente. El selector de empresa en el formulario de conciliación también vuelve a responder bien al cambiar de empresa.
Abrir /admin/conciliate/edit y /admin/data-manager/view y edit; verificar que la consola del navegador no muestre NG0203 ni TypeError. Cambiar la empresa en el formulario de conciliación y confirmar que se dispara el cambio (companyChange) y se actualizan las suscripciones. Confirmar que el KPI 'Total verificado' renderica desde el primer render y muestra el estado de carga del monto sin romper.
Eran dos bugs de estabilidad en frontend (uso incorrecto de APIs de Angular 17) que ensuciaban la consola y podían romper el render del KPI y las suscripciones del formulario. Es un fix solo de frontend, sin cambios de API, permisos ni rutas, que mejora la robustez de conciliación y data manager alineándose con los patrones ya existentes del repo.
n-772 Login invalid credentials toast message
Repos: front · Tipo: Fix · PRs: front #507 · sha: c9cb6d1
Cuando iniciás sesión y algo falla (por ejemplo, usuario o contraseña incorrectos, o un error al entrar con Google/Microsoft/Entra ID), el aviso ahora aparece como una notificación flotante arriba a la derecha, igual que en el resto de la plataforma. Antes el mensaje se mostraba abajo de la página y podía pasar desapercibido. Los avisos de éxito también usan este mismo formato.
En la pantalla de login, ingresar credenciales inválidas y verificar que el error aparezca como toast flotante arriba a la derecha (no como banner al pie de la página). Repetir con errores de proveedores externos (Google, Microsoft, Entra ID) y con errores de API/validación, confirmando severidad 'error'. Validar que un login exitoso muestre toast de severidad 'success'. Confirmar que el toast se cierra solo (~5s errores, ~8s listas de validación) y que no queden acumulados mensajes previos.
Unifica la experiencia de notificaciones del login con el patrón de toast del resto de la app, mejorando la visibilidad del feedback (antes quedaba debajo del fold y podía no verse). Es un cambio acotado al componente de login, sin impacto en backend ni en ErrorService/MessageService.
n-784 Dark mode execution log preview
Repos: front · Tipo: Fix · PRs: front #509 · sha: 0e4fba7
Se corrige la vista previa de los logs de ejecución en modo oscuro: antes el texto aparecía casi ilegible (blanco sobre fondo claro/blanco) y ahora se ve con el contraste correcto y un borde sutil pero visible.
Activar el modo oscuro (tema Lara dark blue), abrir una ejecución y desplegar la vista previa de logs en el overlay: verificar que el texto del log sea legible, que el fondo y el borde del panel tengan contraste adecuado y que no haya texto blanco sobre fondo blanco. Revisar también que el resto del modo oscuro no se vea afectado.
Fix de UI/accesibilidad en frontend que resuelve un problema de legibilidad en dark mode causado por la escala invertida de superficies de PrimeNG Lara (tokens surface más altos eran más claros). Mejora la experiencia de quienes usan modo oscuro sin impacto funcional en backend.
n-801 Falta showtime true en columnas de fecha en script execution
Repos: front · Tipo: Fix · PRs: front #510 · sha: 13469c9
En la tabla de ejecuciones de scripts, las columnas Inicio y Fin ahora muestran la fecha junto con la hora (formato H:mm), en lugar de solo la fecha.
Abrir la pantalla de ejecuciones de scripts y verificar que las columnas 'Inicio' (start_time) y 'Fin' (end_time) muestren fecha y hora, no solo la fecha.
Mejora la trazabilidad operativa de las ejecuciones al permitir ver la hora exacta de inicio y fin, facilitando el seguimiento cuando hay varias corridas en un mismo día.
Mejoras técnicas
n-719 Separacion redis layers
Repos: api · Tipo: Improvement · PRs: api #585 · sha: d0304e0
No hay cambios visibles en la interfaz ni en cómo se usan los bots. Es una mejora interna de infraestructura: la plataforma queda más estable y con menor riesgo de que un problema en un área (por ejemplo colas de trabajos o WebSockets) afecte a las demás.
Verificar que la plataforma funcione con configuración legacy (solo REDIS_HOST) sin errores. Probar que sigan funcionando: caché general, conciliaciones (records, locks, progreso), notificaciones/estado en tiempo real por WebSocket, y la ejecución de bots programados (schedules y cron). En entorno local, levantar los contenedores redis-ephemeral y redis-durable y confirmar que app, scheduler y workers arrancan correctamente. Validar que los schedules huérfanos se reconcilian al iniciar el rqscheduler.
Antes toda la plataforma compartía una sola instancia de Redis para usos muy distintos (caché, conciliación, WebSockets y colas de trabajos), lo que generaba contención de memoria y acoplaba fallas entre dominios. Al separar Redis en capas dedicadas se logra escalar, ajustar políticas de memoria y persistencia de forma independiente por carga, reduciendo el riesgo operativo, manteniendo compatibilidad total con despliegues existentes.
n-759 Reducir tamano de scss del dashboard commercial performance
Repos: front · Tipo: Improvement · PRs: front #498 · sha: 406b1eb
El tablero comercial (rendimiento comercial) se ve igual que antes, sin cambios visibles para el usuario. Por dentro se ordenaron y unificaron sus estilos para que la sección cargue de forma más liviana y ordenada.
Abrir /admin/comercial y sus pestañas (métricas de interacción, salud del producto, salud de suscripciones) y verificar que se ven idénticas a antes, sin errores de maquetado en escritorio y móvil. Confirmar que el build de producción compila sin superar el presupuesto de estilos por componente (error a 7 kB) y que no hay regresiones visuales en tablas, filtros y calendario.
Los componentes del dashboard comercial superaban el presupuesto de estilos de producción de Angular porque los mismos estilos compartidos se duplicaban en cada componente. Se hizo la corrección estructural (deduplicar y cargar los estilos compartidos una sola vez) para eliminar la duplicación, reducir el peso de estilos y volver a un presupuesto estricto, mejorando el mantenimiento sin afectar la funcionalidad ni la apariencia.
n-760 Footer
Repos: api + front · Tipo: Improvement · PRs: api #588, front #500 · sha: bd54810 / 24a2435
El pie de página (footer) de la aplicación ahora muestra, junto al copyright, la versión desplegada de la interfaz (UI) y la del backend (API) como etiquetas de color. Así podés ver de un vistazo qué versión está corriendo en cada ambiente.
1) Iniciar sesión y confirmar que el footer aparece en todas las pantallas del layout privado, con copyright y dos chips: API (tono info) y UI (tono success). 2) Verificar que la versión de UI coincide con la de package.json y la de API con conciliation_api.__version__. 3) Llamar a GET /api/v1/core/version/ SIN autenticación y confirmar respuesta 200 con {"version":"<x.y.z>"}. 4) Revisar el fondo con gradiente celeste en tema claro y el fondo definido en tema oscuro.
Mejora la visibilidad operativa: soporte e ingeniería pueden verificar de forma inmediata qué versiones de UI y API están desplegadas en cada ambiente, alineadas con los tags de release de Docker, facilitando el triage de incidentes y la verificación de despliegues. Antes la versión solo vivía en package.json/index.html sin visibilidad in-app.
n-773 Success por exito en toast message sin openspec
Repos: front · Tipo: Improvement · PRs: front #501 · sha: 5b5195c
Cuando una acción se completa correctamente, el aviso de confirmación ahora aparece en español: el título dice 'Éxito' en lugar de 'Success'.
Ingresar al área privada y realizar cualquier acción que dispare una notificación de éxito (por ejemplo guardar o actualizar un registro). Verificar que el toast muestre 'Éxito' como título y el mensaje de detalle correspondiente, sin que aparezca 'Success'.
Mejora de consistencia idiomática: se traduce al español el título de las notificaciones de éxito que aún estaba en inglés, alineando la interfaz con el resto de la plataforma. Impacto visual menor, sin cambios funcionales.
n-776 Openspec proposal tracking convention
Repos: api + front · Tipo: Improvement · PRs: api #587, front #497 · sha: 56e5b32 / a7da83d
No hay cambios visibles para el usuario final de la plataforma. Es una mejora interna de proceso de desarrollo que no altera funcionalidades, pantallas ni comportamiento de los bots.
Verificar en ambos repos (cloud-api y cloud-front) que existe el archivo de skill openspec-continue-change/SKILL.md, que openspec/config.yaml incorpora los cambios de configuración y que openspec/unimate-openspec-sdd-workflow.md incluye la sección que enfatiza el bloque de Tracking en los proposals. No requiere pruebas funcionales sobre la aplicación.
Estandariza la trazabilidad de los proposals de OpenSpec (tickets, branches, repos, PRs, release) y documenta cómo continuar un change paso a paso. Mejora la consistencia y el seguimiento del trabajo entre backend y frontend, sin impacto en el producto de cara al cliente.