Changelog

Unreleased

Corregido

Avance de la recolección APM programada (#262): el panel de tareas en segundo plano lista las recolecciones habilitadas por aplicación antes de su primera ejecución y conserva visible la próxima. La barra de tareas y el tooltip de la bandeja ahora muestran el avance activo; no se añaden llamadas a servicios cloud.
Próximas sigue el horario real (#278): las recolecciones por aplicación muestran cuándo dispara el siguiente intervalo de 30 minutos en vez de "30 minutos después del último cambio", y salen de Próximas mientras la recolección programada está en pausa.
Los perfiles GCP locales se recuperan de un token rechazado: un perfil local: (una configuración de gcloud) seguía usando un token de acceso en caché durante 30 minutos aunque Google ya lo rechazara, así que las lecturas de GCP fallaban con 401 hasta reiniciar KUA. Ahora KUA guarda el token solo hasta poco antes del vencimiento que informa gcloud y lo descarta en cuanto Google lo rechaza, de modo que la siguiente lectura le pide uno nuevo a gcloud.
Los recursos asociados se pueden recolectar (#280): asociar un recurso a una KUA Application sin proveedor ahora añade el scope donde vive (cuenta y región de AWS, proyecto de GCP, team de Vercel), visible en la vista previa, así que su recolección ya no falla con scope_unbound. Los PersistentVolumes de Kubernetes tienen su propio tipo, ConfigMaps, Secrets y volúmenes ya no dicen tener métricas que KUA no recolecta, y el inventario regional de AWS reparte su tope entre servicios, de modo que muchas Lambdas ya no ocultan topics de SNS, reglas de EventBridge ni load balancers; la estimación nombra los servicios que tenían más de lo que cupo.

Añadido

Agregar recursos de GCP como los stacks de AWS (#283): el descubrimiento de GCP del mapa pasa a ser un asistente como el de AWS. Elige deployments de Infrastructure Manager (los recursos que administra su última revisión, con los recursos de Terraform que KUA no mapea listados aparte) o labels (app=orders; Terraform marca sus recursos con goog-terraform-provisioned), o el proyecto completo, o busca un recurso por su nombre completo como Find ARN. Los recursos se agrupan por tipo con búsqueda, y se dibujan las relaciones disco → VM y suscripción → topic. Ahora se puede dibujar y sumar a la aplicación cualquier tipo del catálogo de GCP (VMs, discos, GKE, Cloud SQL, buckets, Pub/Sub, jobs de Cloud Run, Firestore, Memorystore, Workflows, Scheduler, Tasks, BigQuery), no solo Cloud Run y Functions. Solo llamadas List, sin costo; sin Infrastructure Manager el panel lo avisa y sigue con las labels.
Señales del APM para colas, tablas, flujos, bases de datos, APIs, volúmenes, Glue, GCP y jobs y volúmenes de Kubernetes (#286): los recursos asociados dejan de mostrarse como no soportados. CloudWatch: SQS (mensajes visibles, antigüedad del más viejo, enviados), SNS (publicados, fallidos), DynamoDB (capacidad consumida, throttles de lectura y escritura), Step Functions (iniciadas, fallidas, duración), RDS (CPU, conexiones, almacenamiento libre), API Gateway REST y HTTP (requests, 5xx, latencia), SES (tasas de rebote y queja de la cuenta) y EBS (cola, burst balance), una llamada GetMetricData por recolección. Jobs de Glue: ejecuciones, fallas y duración desde GetJobRuns (sin costo). GCP desde Cloud Monitoring: requests, 5xx y latencia p95 de Cloud Run, CPU, disco y conexiones de Cloud SQL y CPU de VMs, una serie temporal por métrica. Kubernetes: tiempo desde el último éxito de un CronJob, jobs activos y fallidos; estado enlazado de un PVC y, con Prometheus, bytes y porcentaje usados. La vista previa del costo de recolección los incluye: CloudWatch USD 0,01 por cada 1.000 métricas; Cloud Monitoring USD 0,50 por millón de series después del primer millón gratis por cuenta de facturación al mes.
Recomendados y Buscar en la cuenta al agregar recursos (#284): el panel Agregar recursos de KUApps abre en Recomendados: recursos relacionados con lo que la aplicación tiene, cada uno con su evidencia ("usado por orders (Extract)", "volumen del reclamo db/data") y confianza, los volúmenes liberados marcados y un botón Descartar. Buscar en la cuenta lista lo que tiene un perfil AWS, un proyecto GCP o un contexto Kubernetes, por tipo y texto, o resuelve un ARN o nombre completo pegado, con paginación. Los recursos elegidos se agregan en un paso, con los scopes que necesitan; el panel sigue abierto para seguir agregando. El descubrimiento por Mapa es la tercera pestaña, y abrir el panel desde el Mapa empieza ahí. Solo llamadas List/Describe, sin costo.
Volúmenes EBS en la vista de AWS: una nueva pestaña EBS en Almacenamiento lista los volúmenes de la región con tamaño, tipo, estado, la instancia a la que están adjuntos, el reclamo de Kubernetes para el que los creó el driver EBS CSI y su costo mensual a precio de lista. Los volúmenes sin adjuntar se destacan y se suman (cantidad, GiB y USD al mes), con un filtro para ver solo esos. Solo DescribeVolumes, sin costo.
Los agentes arman y ajustan el APM de una aplicación (#285): dos herramientas MCP, search_resources (los catálogos de AWS, GCP y Kubernetes, con la entrada exacta para asociar) y recommend_application_resources (recursos relacionados con evidencia), y siete operaciones con vista previa: scopes.add, scopes.remove, resource.update, thresholds.update, collection.update, collection.run y recommendations.dismiss. Encender la recolección, ejecutarla y activar un recurso muestran en la vista previa las llamadas a CloudWatch y los USD estimados por ejecución y por mes, de modo que el usuario aprueba el costo antes de que se recolecte nada; todo cambio sigue requiriendo la aprobación del usuario y "Permitir que agentes cambien KUApps".
Recomendaciones de recursos (#283): GET /api/kua-apps/applications/:id/recommendations sugiere qué más pertenece a una aplicación a partir de lo que ya tiene, cada sugerencia con su evidencia y confianza: las Lambdas, jobs de Glue, tablas DynamoDB, colas y topics que usa una definición de Step Functions, los ARN y URLs de colas en el entorno de una Lambda (solo el nombre de la variable, nunca el valor), los target groups y EC2 detrás de un load balancer, los volúmenes EBS de una instancia y, para workloads de Kubernetes, el clúster EKS, las EC2 de sus nodos y workload → PVC → PV → volumen EBS o disco de GCP. Los volúmenes liberados del mismo reclamo se marcan para revisar. Se excluyen miembros, recursos desasociados y sugerencias descartadas (POST .../recommendations/dismiss); nada se asocia hasta que el usuario o un cambio aprobado de un agente lo haga. Step Functions ahora también reconoce tareas de Glue, DynamoDB y SNS en el mapa de arquitectura. Solo llamadas Describe/Get/List, sin costo.
Catálogos de recursos de GCP y Kubernetes (#282): GET /api/kua-apps/catalog/gcp lista VMs y discos persistentes de Compute Engine, GKE, Cloud SQL, buckets, topics y suscripciones de Pub/Sub, servicios y jobs de Cloud Run, Functions, Firestore, Memorystore, Workflows, Cloud Scheduler, Cloud Tasks y datasets de BigQuery de un proyecto con su nombre completo y location, y resuelve un nombre completo; una API deshabilitada se informa sin ocultar el resto. GET /api/kua-apps/catalog/kubernetes lista Deployments, StatefulSets, DaemonSets, CronJobs, Jobs, Services, Ingresses, PVCs, PVs y nodos de un contexto; cada PV nombra el volumen EBS o disco de GCP que lo respalda y cada nodo su instancia EC2. Todos estos tipos de GCP y los CronJobs y Jobs de Kubernetes se pueden asociar a una KUA Application. Solo llamadas List, sin costo.
Catálogo de recursos de AWS (#281): GET /api/kua-apps/catalog/aws lista lo que tiene una cuenta AWS para asociarlo a una KUA Application: instancias EC2, volúmenes EBS, S3, DynamoDB, SQS, SNS, identidades SES, jobs, crawlers y workflows de Glue, Step Functions, load balancers y target groups, zonas de Route 53, CloudFront, RDS, API Gateway, EKS, ECS, EventBridge y Lambda. Filtra por tipo o texto, o pega un ARN para resolver un recurso; cada item trae el ARN, la cuenta y la región que necesita el registro. Un tipo que el perfil no puede leer se informa sin ocultar los demás, y las páginas continúan una misma foto de cinco minutos. Solo llamadas List/Describe, sin costo. Ahora se pueden asociar volúmenes EBS, Glue, Route 53, SES y target groups.
Panel de estado en la bandeja (#278): al hacer clic en el icono de la bandeja se abre un panel con el estado de KUA (versión, plan, si el backend responde, con Reiniciar backend), las tareas en segundo plano en ejecución con su avance, las próximas programadas, las pausadas o con error con pausar, reanudar y cancelar, y la actualización de la app que se descarga en segundo plano (Reiniciar y actualizar cuando está lista). El clic derecho mantiene el menú; en Linux el panel es su primer elemento. Solo lee la API local: sin llamadas a la nube.
Interruptor de acceso de agentes de IA (MCP) (#278): enciende o apaga los agentes en este equipo desde el panel de la bandeja o Conectar un agente IA. Apagado, KUA rechaza toda petición del servidor MCP con AGENTS_DISABLED y el agente le dice al usuario dónde volver a encenderlo. Encendido por defecto; un agente no puede cambiar su propio acceso.
Herramientas de inventario de solo lectura para agentes: el servidor MCP añade check_profile (conexión y permisos de lectura de un perfil AWS, GCP o Vercel o un contexto Kubernetes, sin credenciales ni errores crudos del proveedor), list_kubernetes_contexts, kubernetes_architecture (workloads, Pods, Services, Ingresses, PVCs/PVs y nodos con sus relaciones; sin valores de Secrets) y cloud_resource_inventory (recursos de AWS, GCP o Vercel filtrados por texto y tipo, paginados sobre una misma foto de cinco minutos). gcp_advisor acepta refresh e indica si sus datos son recientes, de caché o desactualizados. Solo usan lecturas list/describe del plano de control, sin costo, y nunca cambian recursos.

Actualizar desde 1.x

Cambios visibles y cambios que rompen comportamiento al actualizar desde 1.17:

Los límites del plan Free aplican desde el 2026-11-10. Hasta entonces Free conserva agentes por MCP, trabajo programado en segundo plano y KUA Applications sin tope, y KUA muestra un aviso en la app. Desde esa fecha Free se limita a 3 KUA Applications y esas dos funciones requieren Pro o Team. Ayuda y opciones → Cuenta lista qué cambia y cuándo.
El Advisor requiere Pro o Team. En Free, los resúmenes y KUApps muestran solo los conteos tras un candado con "Ver planes", y las herramientas de Advisor del MCP explican el plan en vez de devolver hallazgos. El refresco automático de logs en caché, las cachés de logs superiores a 256 MB, los webhooks de alertas y los filtros de ruta guardados en el mapa también siguen el plan.
La API local escucha solo en 127.0.0.1. Antes escuchaba en todas las interfaces de red sin autenticación. Si accedías a KUA desde otro dispositivo a propósito, define KUA_HOST (por ejemplo 0.0.0.0 en una red de confianza); KUA avisa al iniciar.
Cerrar la ventana ya no cierra KUA. Sigue corriendo en la bandeja del sistema; usa el menú de la bandeja y Salir para un cierre ordenado.
Iniciar sesión es opcional. Sin cuenta KUA funciona como Free. KUA_PLAN (free, pro o team) solo reemplaza el plan en desarrollo y la app de escritorio empaquetada lo ignora. El plan se guarda 7 días sin conexión y se renueva cada 6 horas.
El registro del gasto viene activado. Desactívalo en Ayuda y opciones → Cuenta; mientras está apagado no se registra nada y los paneles de gasto se ocultan.
Los agentes no pueden cambiar KUApps salvo que lo permitas. Conectar un agente IA → Permitir que los agentes cambien KUApps viene desactivado, y cada cambio aplicado queda auditado.
Respaldos y sync siguen funcionando. El formato KUAAppBundle sigue en la versión 1, así que los respaldos en la nube, el sync, el uso compartido con el equipo y las versiones anteriores de KUA lo siguen leyendo. Los respaldos y copias de equipo hechos antes de esta versión conservan su valor de perfil hasta que la aplicación se suba de nuevo.
Los enlaces y las URL llevan más estado. Las vistas de AWS, GCP y Kubernetes guardan servicio, perfil, búsqueda, filtros y selección en la URL, así que los marcadores viejos abren la vista pero no esos detalles.

Kubernetes

Ergonomía de Kubernetes (K06, K09-K11, K13, K14): la URL guarda la vista de Kubernetes (?view=kubernetes&context=…&ns=…&resource=…&name=…), así recargar, atrás/adelante o un enlace abren el mismo clúster, namespace, lista o Resumen y recurso seleccionado; un contexto que no está en el kubeconfig se avisa en vez de reemplazarse, y un ?app= antiguo de KUApps ya no reabre esa aplicación. Las tablas muestran "N de M", los filtros activos (los rápidos deben cumplirse todos, las severidades se suman) y un botón Limpiar filtros, y una tabla vacía por filtros lo dice. Las columnas están traducidas, las edades usan unidades de kubectl (7d 5h), CPU y memoria de nodos se leen como capacidad en cores y GiB, y Events distingue la severidad KUA del tipo de Kubernetes, con repeticiones, primera y última vez y la regla de severidad como ayuda. Las filas se abren con Enter o Espacio, las cabeceras de orden son botones con aria-sort, el filtro tiene etiqueta y las pestañas del inspector siguen el patrón tablist. Por debajo de 1180px la cabecera pasa a dos líneas en vez de recortar contexto y namespace; por debajo de 900px el menú de recursos es un panel desplegable y el inspector ocupa todo el ancho; las acciones de fila quedan fijas a la derecha. Los logs de workloads dicen si muestran la caché local o Kubernetes en vivo, indican dónde ver los logs de la instancia anterior de un pod, marcan como históricos los workloads en caché que ya no están en el clúster y advierten que 0 eventos en caché no prueba que no hubiera logs.
Recorrido de diagnóstico en Kubernetes (K05, K07, K08, K12): desde el bloque de Salud de un pod se abren sus logs actuales o los de la instancia anterior del contenedor que terminó (la casilla Anterior de la terminal sigue a la pestaña). Una sección de Relaciones enlaza el ReplicaSet, el Deployment, el nodo y los Services que seleccionan el pod, e indica si es endpoint listo de cada uno. El detalle de un Service explica sus backends: ningún pod coincide con el selector, pods que coinciden pero no están listos, sin selector o ExternalName, con pods que coinciden, pods listos, endpoints y el pod cuya label comparte el nombre de la app pero ya no coincide (un selector anclado a una release anterior). El Resumen muestra los incidentes activos antes del asesor, que ahora empieza plegado; la tarjeta de pods con problemas separa los reiniciados en los últimos 60 minutos del histórico, y los pods tienen el filtro rápido "Reinicio en la última hora". La regla de crash loop cuenta los pods en crash loop ahora y los que tienen 10+ reinicios con el último en las últimas 24 horas, y lo explica.
Métricas de nodo por Prometheus en Kubernetes: sin Metrics API, las métricas de un nodo fallaban ("Unexpected token '<'") tras unos dos minutos. La consulta escapaba el nombre del nodo como \. dentro de una cadena PromQL, que Prometheus rechaza, y buscaba node-exporter por instance, que lleva IP:puerto y no el nombre del nodo. KUA probaba entonces cada servicio y puerto de Prometheus hasta que uno respondía HTML. Ahora el nodo se busca por node_uname_info{nodename}, con el uso de contenedores de cAdvisor como alternativa indicada; los nombres se escapan para PromQL también en las consultas de pods, y una consulta rechazada por Prometheus se detiene enseguida.
Reevaluación de Kubernetes (R01-R04): un workload con CPU y memoria muestreadas en pods distintos mezclaba ambas poblaciones; ahora cada señal tiene su propia referencia y cobertura, y el inspector dice "Muestras de CPU de X de N pods y de memoria de Y de N" cuando difieren. Los movimientos dentro de la vista de Kubernetes (lista, selección, namespace, contexto, Resumen y Logs de workloads) crean una entrada en el historial y Atrás/Adelante los vuelven a aplicar; el arranque ya no registra estados transitorios. Incidentes, nodos, workloads no listos y avisos del Resumen tienen botones reales, el menú de Kubernetes usa enlaces con aria-current y, en ventanas estrechas, el panel desplegable lleva el foco al elemento activo, se cierra con Escape devolviendo el foco al botón y queda inerte mientras está cerrado. La regla de crash loop dice lo que mide: reinicios acumulados con la última terminación en 24 h o sin hora registrada, no reinicios contados en 24 h.
Salud y consumo en Kubernetes (K02-K04): el detalle del pod llamaba "Estado" a la fase, así que un pod en CrashLoopBackOff aparecía como Running; ahora empieza por un bloque de Salud (fallando, no listo, pendiente, listo) con el estado de cada contenedor con problemas, contenedores listos, reinicios y última terminación, y muestra la fase como "Fase del pod". El gráfico del Resumen es "Pods por fase" y enlaza los pods en Running que no están listos. Una respuesta vacía de Prometheus o un pod que Metrics API aún no midió aparecían como consumo 0; ahora dicen "Sin muestra reciente", los workloads indican cuántos pods tienen muestra y Prometheus da valores por pod. Las barras se medían contra 1 core / 512 MiB inventados por pod, con piso del 2 % y tope del 100 %; ahora usan limits, si no requests, de los contenedores o allocatable del nodo, muestran valores por encima de la referencia y no dan porcentaje si no hay referencia. El colector APM ya no guarda ceros cuando falta la muestra.
Confirmaciones de escritura en Kubernetes (K01): restart, cordon, uncordon, drain, borrado, escalado y edición YAML muestran entorno, clúster, contexto completo, namespace y recurso antes de actuar. El contexto se fija al abrir la acción y el servidor responde 409 sin cambiar nada si el contexto activo cambió entretanto. La cabecera muestra el nombre corto del clúster (no el ARN de EKS) con etiqueta de entorno en texto, y sus selectores tienen nombre accesible. Reiniciar un DaemonSet ya no devuelve 404.
Logs de workloads de Kubernetes con inteligencia: Logs → Logs de workloads lista los deployments, statefulsets, daemonsets y pods sueltos del namespace y les trae la experiencia de CloudWatch Logs: cachear los logs de los pods de un workload (cifrados, misma caché y presupuesto), consultarlos en vivo o desde la caché con sintaxis de Logs Insights, escanear hasta 5 días en segundo plano y abrir el mismo panel Intelligence con anomalías, ML local, recomendaciones y briefs para agentes. Los logs se leen por la API de Kubernetes (todos los contenedores, más la instancia anterior de los que se reiniciaron) detrás de un adaptador compatible con FilterLogEvents, así que la sincronización, el relleno de historia y los escaneos son los mismos que en CloudWatch; un único ejecutor de escaneos atiende a ambos proveedores. Los consejos exclusivos de CloudWatch (retención por CLI, políticas de protección de datos) se omiten en Kubernetes. Nuevas herramientas MCP: list_kube_log_workloads, kube_log_intelligence y search_logs con provider: "kubernetes". Los errores de base de datos de TypeORM, MongoDB, Sequelize, Prisma y pg ("Unable to connect to the database", ServerSelectionTimeout, "Connection terminated unexpectedly"…) ahora se categorizan como errores de base de datos.

AWS

Escrituras AWS y datos honestos (auditoría UX de AWS A01-A06): iniciar y detener EC2 y ECS piden confirmación con el recurso, su estado, la cuenta, el perfil y la región, el impacto y el propietario EKS o Auto Scaling; Iniciar en ECS se deshabilita mientras el servicio corre (fija las tareas deseadas en 1). El diálogo de invocación Lambda tiene título y botón Invocar, avisa que ejecuta de verdad y puede costar, y valida el JSON junto al campo. Los diálogos de escritura pertenecen al perfil con el que se abrieron: un cambio de perfil los cierra y no se envía nada. Los contadores de Step Functions distinguen cero confirmado, "1000+", lectura parcial, sin acceso y flujos Express, y nunca convierten una lectura fallida en cero. Las etiquetas Lambda se leen en bloque (Tagging API) y dicen "No leídas" cuando no se pudo; la columna Estado, que ListFunctions nunca devuelve, ya no está. La caché de CloudWatch Logs separa el presupuesto compartido de esta máquina de este perfil y región. Los balanceadores cuentan como cubiertos por KUA y su tasa de error solo divide los 5xx de targets por RequestCount. Las respuestas AWS y GCP en caché conservan sus fechas (se guardaban como {} y mostraban "Invalid Date").
Ergonomía de AWS (auditoría UX de AWS A07-A15): cada pestaña de servicio muestra el perfil, la cuenta y la región, y los servicios globales dicen que la región no los filtra. El Resumen empieza por lo que requiere atención en las últimas 24 h y abre las funciones Lambda o máquinas de estado afectadas, las peores primero (los balanceadores abren su salud actual, que no atribuye los 5xx, y lo dicen). Las tablas muestran dos etiquetas relevantes y "+N", dejan las acciones secundarias y de escritura en un menú "Más" y filtran por estado, runtime, actividad, tipo o región con "N de M" y Limpiar filtros. Cada bloque dice su ventana y cuándo se leyó. El Asesor muestra primero los tres hallazgos más graves y dice cuántas fuentes no se revisaron. Las acciones dicen si leen, configuran o comprueban. La barra lateral, las cabeceras ordenables, los menús y los diálogos funcionan con teclado (Escape cierra, el foco queda dentro y vuelve). La URL describe la vista (?view=aws&service=…&profile=…&q=…&f.…), Atrás y Adelante se mueven entre proveedores y servicios, y el perfil de un enlace solo se usa si existe en esta máquina.
Load Balancers de AWS: AWS → Networking → Load Balancers lista todos los load balancers Application, Network, Gateway y Classic de la región: público o interno, nombre DNS, listeners y targets sanos. Su salud marca load balancers fallidos, target groups sin targets sanos, targets no sanos, load balancers sin targets, listeners HTTP públicos que no redirigen a HTTPS y políticas TLS que todavía aceptan TLS 1.0/1.1. Los detalles muestran las reglas de cada listener, la política TLS y los certificados, los target groups con el motivo de cada target no sano, la protección contra borrado, los access logs y los tags. Solo usa llamadas Describe* de Elastic Load Balancing, que no tienen costo; si falta un permiso solo se oculta esa parte y se ofrece una solicitud de acceso.
Recursos AWS descubiertos desde CloudFormation perdían su cuenta y región: los recursos agregados desde un stack de CloudFormation no tienen ARN, y su cuenta y región se perdían al entrar a Observabilidad. Una aplicación sin provider no podía recolectarlos ("Application profile and region are required"), y el registry listaba cada uno dos veces (uno con su cuenta y otro sin ella), marcándolos como divergentes. Ahora los recursos conservan la cuenta y región de su nodo de Arquitectura; los existentes se corrigen con una reconciliación al arrancar. Si aun así falta la región, la recolección indica qué scope la necesita.
AWS CloudFormation (solo lectura): nueva pestaña Management → CloudFormation con todos los stacks agrupados por estado (completos, en curso, fallidos, revertidos, en revisión), estado de drift, protección contra borrado y stacks anidados. Cada stack muestra parámetros, outputs y tags, sus recursos vinculados a la pestaña de KUA que los gestiona, sus eventos con la causa raíz de la última falla resaltada, la plantilla original y la detección de drift bajo demanda con las diferencias de propiedades. Las lecturas de CloudFormation no tienen costo; los stacks se vinculan a KUA Applications (agregando sus recursos una sola vez), los exports muestran qué stacks los importan, los change sets se revisan con su riesgo (eliminaciones, reemplazos, recursos con datos), los parámetros se actualizan con un change set previsualizado, la protección contra borrado se activa o desactiva y los stacks se eliminan después de una previsualización del borrado. Las operaciones destructivas piden escribir el nombre del stack (y un motivo para borrar), el servidor las vuelve a verificar y quedan en el audit log, con un historial de operaciones por stack.
Cobertura del resumen: CloudWatch Logs y CloudFormation ya no aparecen como cubiertos a medias; CloudWatch sigue parcial hasta que existan alarmas y un explorador de métricas.

GCP

Etiquetas de GCP que dicen lo que KUA sabe (auditoría UX de GCP G01-G09): "Iniciar/Detener" de Cloud Run pasan a "Mantener caliente" y "Permitir escalar a cero": solo cambian las instancias mínimas, el diálogo muestra el cambio (0 → 1) y aclara que el endpoint sigue atendiendo. Storage muestra la prevención de acceso público (Forzada, Heredada, No determinada) y la exposición pública como "No verificada" en vez de una etiqueta "Pública" sin evidencia IAM. Functions lee su región del nombre del recurso, así el detalle, los logs y la invocación llegan a la función listada (daba 403). Los errores de lectura nombran su causa (API deshabilitada, permiso, credenciales, petición rechazada, no encontrado, cuota, temporal) con el cuerpo original en detalles técnicos; el enlace para habilitar la API solo aparece si está deshabilitada y una lista no leída dice "Sin leer", no 0. Artifact Registry, Cloud Scheduler, Cloud Run Jobs y Cloud Tasks recorren cada ubicación en vez de "locations/-", que Google rechaza; se omiten las ubicaciones bloqueadas por política. El Resumen separa los incidentes de los recursos observados de la cobertura de lectura, lista las lecturas pendientes con su causa y permite marcar servicios sin uso; el historial de builds se cuenta aparte de los recursos desplegados y las listas paginadas dicen cuándo son parciales. Cada gráfico de métricas tiene su propio estado y Reintentar; los totales se suman, el p99 usa la distribución combinada, los filtros incluyen la región y la CPU es un porcentaje.
Ergonomía de GCP (auditoría UX de GCP G10-G15): los diálogos de escritura muestran proyecto, perfil, región y recurso, y se cierran sin enviar nada si cambia el perfil; una estimación que no se puede calcular dice que el costo es desconocido. Filas, listas laterales, pestañas de detalle y los 20 diálogos de GCP funcionan con teclado. Las señales del Resumen abren su servicio filtrado al recurso afectado (y su detalle), las áreas filtran la tabla de servicios y Conectar GKE explica antes la importación del kubeconfig. La tarjeta de costos es una base ociosa de los recursos modelados, con su cobertura y lo que deja fuera. Pestañas, avisos y advertencias de la estimación están traducidos, y el pie del Asesor ya no afirma que no hay llamadas facturadas junto a una programación que sí se factura. Las listas filtran por estado y región, ordenan, dicen "N de M" y se apilan en pantallas estrechas. La URL guarda la vista GCP (?view=gcp&service=…&profile=…&q=…&f.…&selected=…), Atrás y Adelante recorren los servicios y la búsqueda se guarda por servicio.
Correcciones de la reevaluación de GCP (R01-R06): una respuesta tardía de detalle, logs o métricas para una selección, rango o reintento anterior se descarta en vez de dibujar los datos de otro recurso. Las listas conservan su alcance desde la API hasta la tabla: una región que falló o un límite de páginas se muestra como "Lista parcial" con las regiones y "n+", y todas las listas leen todas sus páginas. El detalle, los avisos y el historial de Cloud Run hablan del mínimo de instancias y usan las mismas unidades que la tabla. Las pestañas de detalle admiten flechas, Inicio/Fin, tabindex rotatorio y un tabpanel etiquetado. Los enlaces también restauran el filtro de evidencia del Resumen, la pestaña del detalle y el repositorio de Artifact Registry. La estimación de lecturas de GCP del Asesor sigue la frecuencia elegida y explica sus supuestos, y se tradujeron las etiquetas fijas restantes.

Vercel

Resumen y Advisor de Vercel: Vercel abre en un nuevo Resumen de la cuenta o el team: salud, proyectos, el estado de producción de cada proyecto, la tasa reciente de deploys fallidos, dominios (y cuántos no están verificados), variables de entorno contadas por tipo y una tabla de proyectos por último deployment. Dentro de él, el Advisor revisa cada proyecto de la cuenta o el team del perfil contra 13 buenas prácticas: credenciales en variables de entorno de tipo Plain, secretos de producción compartidos con todas las previews o que no son Sensitive, previews sin Deployment Protection, pull requests de forks construidos con las variables del proyecto, un último deploy a producción fallido, dominios sin verificar, proyectos pausados, proyectos sin producción o que despliegan directo a producción, Node.js fuera de soporte, una tasa alta de deploys fallidos y proyectos sin Git. Lee los nombres y tipos de las variables, nunca sus valores, con lecturas gratuitas de la API de Vercel (unas 3 por proyecto, en caché 15 minutos). Los hallazgos se pueden aceptar o silenciar, guardan su historial, se pueden analizar de forma programada y generan alertas de postura igual que los Advisors de AWS y GCP. Los agentes los obtienen con la nueva herramienta MCP vercel_advisor. Un perfil agregado solo con un token se guarda con un hash del token, nunca con el token, y no se puede programar.
Los runtime logs de Vercel podían quedar colgados: el endpoint de runtime logs es un stream que puede quedar abierto; ahora una lectura se corta a los 20 segundos y conserva las líneas completas leídas como muestra, así que una sincronización o el refresco automático de logs nunca espera indefinidamente. Los runtime logs se leen del último deployment de producción listo, no de uno que falló.

KUApps y Arquitectura

Fiabilidad de KUApps (#239): el picker de Kubernetes mantiene sus propios contextos (otras vistas de la aplicación los compartían y vaciaban, por eso decía que el kubeconfig no tenía ninguno) y, cuando la vista del mapa no está lista, lo dice con un reintento en vez de culpar a la conexión. Refrescar el Resumen renueva umbrales e incidencias juntos; si las incidencias no se pueden leer, la salud dice "Evaluación parcial", nunca cero incidencias, y se ignora una respuesta de un rango anterior. Las ventanas estrechas pliegan la lista de aplicaciones al achicarse y usan filas de dos líneas y pestañas con ícono. Abrir un recurso en la vista de AWS dice su cuenta, región y perfil, y avisa si está en otra región o la cuenta es ambigua. Un Node del clúster ya no abre una crítica falsa de "0 % de pods listos", los objetos de EKS ya no muestran el clúster como namespace, "No soportado" pasa a "Sin métricas de KUA" y los hallazgos de logs nombran sus recursos y el siguiente paso.
Abrir un recurso donde vive (#239): cada recurso de AWS de un mapa o de una KUA Application se puede abrir desde el canvas, desde cada fila de Recursos (lista de KUApps y tabla del registro) y desde el inspector de KUApps: en su pestaña de la vista de AWS de KUA (SQS, SNS, DynamoDB, S3, ECS, EKS, ECR, RDS, API Gateway, CloudFront, Cognito, Secrets Manager, load balancers y target groups, CloudWatch Logs, Glue, Step Functions, Lambda, EC2…), buscado por el nombre con que AWS lo lista y con el perfil vinculado a su cuenta, o, para lo que KUA no tiene pestaña (security groups y sus reglas, launch templates, grupos de Auto Scaling, access entries de EKS, roles y políticas IAM, llaves KMS), en su página de la consola de AWS en su región. Los recursos de Kubernetes se abren en la vista de Kubernetes: su detalle, los pods de un workload y sus logs, en su propio contexto y namespace.
Revisión de KUApps (#239): las lecturas de logs en vivo (logs de recursos de Lambda, ECS, EventBridge, GCP y Vercel, CloudWatch en vivo e Insights, y los streams de pods, GCP y Vercel) ahora ocultan secretos como ya hacía la caché, también claves compuestas (DB_PASSWORD, aws_secret_access_key) y llaves privadas PEM, y el visor de logs dice cuántos ocultó y que deben rotarse en el origen. La salud del Resumen cuenta también las incidencias abiertas (una crítica nunca es "Sana"), dice cuándo y sobre qué se evaluó y espera a ambas antes de poder pulsarse. El inspector sabe si está en Recursos o en el Mapa, el Asesor ya no consulta una aplicación nueva con el perfil de la anterior y explica un fallo en vez de mostrarlo crudo, cada aplicación se reconcilia al iniciar, Recursos mantiene una sola lista operativa con la tabla técnica del registro plegada aparte, los denominadores tienen nombre (inventariados, seguidos por Observabilidad) y Revisión muestra las decisiones antes de los posibles duplicados plegados.
El diagrama primero (#239): las herramientas del mapa caben en una fila (búsqueda, orden, Filtros, Capas, Ocultos, Componente) y cada una abre su panel debajo, de a una; el asesor queda plegado con su conteo visible y una validación al día ocupa una línea. Los nombres largos de recursos parten dentro de su nodo con el nombre completo como tooltip, el texto del mapa es de al menos 12 px, los encabezados de sección se ajustan en ventanas estrechas y los tablists restantes (métricas y logs de un recurso, recursos de los logs de la aplicación) responden a las flechas.
Un nodo por recurso en el mapa (#239): los nodos que son el mismo recurso se unen en uno: mismo ARN (un nodo worker de EKS y su instancia EC2, un recurso descubierto y también proyectado desde Observabilidad) o el mismo objeto de Kubernetes. Se conserva el nodo descubierto, que toma las relaciones (incluidas las decisiones hechas a mano), la posición y la evidencia. Ocurre en cada reconcile e importación de descubrimiento; un nombre compartido por sí solo nunca une dos nodos. Los Nodes de Kubernetes tienen ahora su propio tipo, así que su proyección coincide con el nodo descubierto.
El mapa valida sus recursos donde viven (#239): al abrir un mapa, KUA lee la API de Kubernetes de sus contextos y namespaces y consulta AWS Cloud Control por sus recursos de AWS con el perfil vinculado a su cuenta (lecturas sin costo propio; nada cambia en el clúster ni en la cuenta). Se valida cada recurso dibujado, también los que Observabilidad proyectó al mapa, y la membresía de la aplicación sigue el cambio. Un recurso de AWS que KUA no puede leer (sin conexión, sin permiso, un tipo o identificador que no verifica) aparece como no verificado, nunca como eliminado; y marca los pods reemplazados por un nuevo despliegue, los workloads recreados con otro uid y los recursos que ya no existen. Propone el cambio (los sucesores toman el lugar y las relaciones, incluso las dibujadas a mano; lo que ya no existe sale del mapa) y aplica solo lo que el usuario confirma, en una revisión con su motivo en Cambios. Un contexto que no se puede leer no marca nada como eliminado. Rutas recorre los mismos recursos una sola vez y lista todos los tipos de relación de cada paso.
KUApps encuentra un recurso entre muchos (#239): Recursos tiene búsqueda, filtros (proveedor, tipo, conexión, namespace, estado de señales), encabezados de columna y conexiones legibles (el clúster en vez del ARN del contexto). Un nodo del diagrama sin cuenta se une al recurso de su única cuenta conocida en vez de aparecer dos veces; lo que KUA no puede unir aparece como posibles duplicados en Revisión, que se divide en decisiones pendientes, hallazgos de estructura e historial plegado. Agregar recursos abre el proveedor y el contexto de la conexión elegida, ya no se cierra solo mientras carga el perfil ("no hay contextos para este perfil" hasta un segundo clic), nombra un contexto que este equipo no tiene y ofrece Reparar conexión. "¿Por qué?" solo sugiere cachear logs de un recurso que los escribe, las conexiones verificadas nombran el perfil de este equipo, y "N recursos solo en un lado" los lista con el siguiente paso. "Conexión" reemplaza scope, registry y discovery en los textos, nada queda bajo 12 px, la lista de aplicaciones se pliega en ventanas estrechas, las pestañas responden a las flechas, y la confirmación de recolección del Resumen separa lo que se lee ahora, la caché y el costo. El mapa abre a un tamaño legible (agrupado por dominio si es grande), mantiene la búsqueda a la vista (Enter va a la coincidencia y sus vecinos), y Rutas muestra cada ruta desde donde se ramifica, 5 por entrada.
KUApps guía del problema a la acción (#239): el Resumen lista lo que requiere atención bajo sus indicadores (recurso, evidencia, desde cuándo y una acción: ver métricas, revisar, asociar un perfil, recolectar de nuevo), y la tarjeta de salud abre Señales en los recursos afectados con el mismo rango. Señales tiene un solo rango de tiempo, empieza por esas incidencias, pliega las métricas agregadas y los gráficos sin datos, e indica qué recursos fallaron en su última recolección y por qué (guardado por recurso). Recursos y el Mapa comparten un inspector (detalle, métricas y logs del propio recurso, relaciones en palabras, pestañas con flechas). Recolectar desde Señales pregunta antes y separa qué se consulta ahora, qué viene de la caché local y qué tiene costo.
Recursos que ya no existen (#236): cuando un release reemplaza workloads de Kubernetes con nombres nuevos (attencion-3.9.1 → attencion-3.9.2), la recolección ya no queda parcial con "HTTP request failed": el recurso aparece como "Ya no existe" desde ese momento, y KUApps → Revisión sugiere su sucesor del mismo namespace (mismo label app, o el mismo nombre sin versión) para reemplazarlo, desvincularlo o ignorarlo. No se reemplaza nada automáticamente y no cambia nada en el clúster. Los Pods se observan a través de su Deployment en vez de como miembros propios.
Señales de KUApps por recurso: Señales lista toda la aplicación y luego cada recurso agrupado por tipo, con métricas y logs leídos con el perfil y la región de la cuenta de cada recurso (antes, una aplicación sin provider leía todos los logs con un perfil inexistente: "Credential profile not found"). Los tipos que KUA no recolecta (API Gateway, SQS, DynamoDB…) aparecen como no soportados en vez de "sin datos". Los secretos de CloudFormation que una versión anterior guardó como workloads de Kubernetes se eliminan al arrancar (hacían parcial cada recolección), y las recolecciones cortadas por un reinicio se cierran en vez de quedar en ejecución.
Sincronización y Quitar del diagrama en KUApps (#146, #153): las aplicaciones sin provider se sincronizan entre computadores igual que las demás; el vínculo de sincronización pertenece a la aplicación y su membresía viaja: un recurso desvinculado en un computador se desvincula en el otro, y los miembros agregados en cualquier lado llegan al otro. Quitar del diagrama ahora solo oculta un recurso real en esa vista: sigue en la aplicación con sus relaciones, señales e historial, y Ocultos en esta vista lo vuelve a mostrar. Antes, un recurso que venía solo del diagrama salía de la aplicación y perdía su historial de métricas, y el nodo de un miembro volvía a aparecer en el siguiente refresco.
Los recursos de KUApps muestran el estado de sus señales (#151, #152): cada recurso en Recursos y en el inspector indica si sus señales están al día, desactualizadas, parciales, sin datos, apagadas, con error, sin conexión desde este computador o no soportadas, en vez de verse vacío. La pestaña del workspace viaja en la URL junto a ?app=. Agregar recursos marca lo que ya está en la aplicación y muestra la identidad nativa, se recupera si la vista cambió mientras tanto sin perder la selección, y Quitar del diagrama pide confirmación. Vincular un stack de CloudFormation ahora pasa por el servicio común de membresía (#150). Los scopes de providers de plugins aparecen como no soportados.
KUA Applications portables (#153): un respaldo ahora lleva los scopes de la aplicación, todas sus vistas de arquitectura, la membresía de recursos, las relaciones que dibujó el usuario y los recursos que desvinculó, y las aplicaciones sin provider se pueden exportar. Importar muestra primero una vista previa: el nombre que recibe, los scopes por asociar, las vistas, qué recursos vuelven y cuáles no (y por qué), los recursos que este computador ya tiene y lo que quedó fuera del archivo. Importar crea una aplicación nueva, restaura la membresía con el servicio común del registry sin iniciar ninguna recolección y se deshace si algo falla. El formato sigue siendo KUAAppBundle versión 1 (con contentVersion: 2), así que los respaldos en la nube, la sincronización, el equipo y las versiones anteriores de KUA lo siguen leyendo.
Load balancers de AWS en Arquitectura (#210): el discovery regional agrega los load balancers y sus target groups al grafo de KUApps, y luego sugiere la ruta declarada desde el target group hasta el servicio ECS con evidencia de configuración. Las relaciones se pueden revisar antes de importarlas y no requieren stacks de CloudFormation.
Overlays de despliegues y seguridad en Architecture Canvas: los nodos Deployment de Kubernetes pueden mostrar la última revisión de ReplicaSet retenida, su fecha de creación y réplicas listas/deseadas. Un overlay optativo proyecta en los nodos los hallazgos de los Advisors de AWS y GCP, además de los chequeos de seguridad de Kubernetes, solo cuando coinciden exactamente proveedor, tipo de recurso, proyecto/región/contexto, namespace e identidad; respeta las decisiones de acceso de los Advisors y no persiste los datos del scan en el grafo. Los rollouts y hallazgos se cargan bajo demanda.
¿Por qué? en cada relación y sugerencia de KUApps: en Revisión, en el inspector del Mapa y en la lista de relaciones, ¿Por qué? explica una relación con palabras simples: una frase por cada evidencia, clasificada como declarada (un template, manifiesto o configuración), observada (tráfico o logs) o inferida (nombres o scope), la confianza separada por esas clases, lo que vio Observabilidad en el par (tasa de error de cada lado en los logs en caché, y los errores recurrentes de quien llama que hablan del destino, encontrados por nombre y, con el ML local activo, por significado), consejos (verificar antes de aceptar, declararla en el código, agregar timeouts y reintentos cuando el destino falla, rotar secretos con cuidado) y qué hace aceptar o rechazar. Copiar para agente IA lo convierte en una tarea. Todo es local: no hay llamadas a la nube, y el modelo local solo compara embeddings; no escribe el texto. El Advisor de producto suma un hallazgo para dependencias confirmadas cuyo destino muestra en sus logs errores por sobre el objetivo de la aplicación.
Ajustes de KUApps por secciones, y syncs que dicen lo que hacen: Ajustes tiene navegación propia: detalles de la aplicación, cuentas y scopes, fuentes y sincronización, respaldos y colaboración, y eliminar. "Unir Observabilidad y Arquitectura" explica que compara ambos lados por identidad en local, sin llamar a la nube, muestra su última ejecución y lo que queda en un solo lado, y puede ejecutarse ahora o abrir Revisión. "Actualizar desde CloudFormation" explica que lee el stack sin costo y no aplica nada hasta que confirmes. Eliminar una aplicación pide su nombre y aclara que los proyectos de Arquitectura y la infraestructura en la nube se mantienen. En el Mapa, el inspector de recursos tiene pestañas Detalle, Señales y Relaciones.
Resumen compacto en KUApps: el Resumen de una aplicación ahora son cuatro tarjetas en vez de la vista completa de Observabilidad: salud en el rango elegido (con su peor señal y umbral), score y hallazgos de estructura, lo que espera revisión y cobertura de señales (recursos con colector y los tipos sin él). Cada tarjeta abre la pestaña con el detalle. Una aplicación sin datos dice "Sin datos", nunca sana. El rango y Recolectar ahora siguen arriba; Recolectar ahora abre Señales con su confirmación habitual de qué lee y cuánto cuesta. El Advisor de producto se muestra abierto debajo de las tarjetas.
Agregar recursos en un panel lateral: en KUApps, Agregar recursos abre un panel a la derecha desde el encabezado de la aplicación, Recursos o el Mapa, sin salir de la pestaña. Primero pide la cuenta (cuando la aplicación tiene varias verificadas), después qué discovery usar (AWS, Kubernetes, GCP, Vercel o un recurso manual), y explica qué hace agregar: los recursos entran a la aplicación y a su mapa, no cambia nada en la nube y la recolección de métricas queda apagada. Ajustes ya no tiene una sección para agregar recursos al final de la página.
Workspace de KUApps por aplicación: cada aplicación abre en Resumen y tiene Recursos, Mapa (Canvas y Rutas), Señales (métricas, logs y trazas), Revisión y Ajustes. Revisión recupera lo que el diseño anterior escondía: el score y los hallazgos de estructura, "Analizar topología en la nube", las relaciones sugeridas con su evidencia y confianza (confirmar una o todas), las referencias a recursos fuera de la aplicación, aceptar o rechazar relaciones y las cuentas sin un perfil usable de este computador. La pestaña Revisión muestra cuántos elementos esperan una decisión. Las entradas de Arquitectura y Observabilidad de la barra lateral de KUApps ya no están: todo se abre dentro de la aplicación.
Una sola forma de asociar, actualizar y desvincular recursos de una aplicación: Observabilidad, Arquitectura y KUApps ahora pasan por el mismo servicio. Agregar un recurso que ya está en la aplicación responde con el existente en vez de duplicarlo, las escrituras revisan la revisión de la aplicación para no pisar un cambio más reciente, y una proyección fallida a una vista de Arquitectura la termina la siguiente reconciliación. Desvincular un recurso lo quita de la aplicación pero deja su nodo en el diagrama, y la aplicación ya no lo vuelve a tomar desde ese nodo; no se elimina nada en la nube. Las relaciones que confirmaste o rechazaste conservan su estado.
KUA Applications sin provider: KUApps → Crear aplicación ahora crea una aplicación solo con nombre, ambiente y equipo, sin pasar por la configuración de Observabilidad. Sus cuentas se agregan como scopes (cuenta y región AWS, proyecto GCP, contexto de Kubernetes, team de Vercel u otro id de proveedor), y cada computador asocia uno de sus propios perfiles a cada scope: el panel lista los perfiles de este computador para ese proveedor, avisa mientras un scope no tiene perfil o tiene uno que no calza, y muestra si está verificado. La verificación solo usa lecturas sin costo (AWS STS GetCallerIdentity, el proyecto GCP y el team de Vercel del perfil, los contextos de kube), y un scope cuya cuenta no se conocía se completa con la cuenta a la que llega el perfil. Los perfiles nunca se exportan. Las aplicaciones existentes se migran al arrancar sin perder datos: reciben los scopes donde viven sus recursos y un binding al perfil que usaban, y el registry de recursos pasa a identidades sin perfil (un recurso visto con dos perfiles pasa a ser uno). Los nombres de aplicación ya no son únicos, un enlace con ?app=<id> abre esa aplicación y elegir una aplicación ya no cae al perfil AWS de la barra superior. GET /api/kua-apps/migration-report lista lo que necesita una decisión. La arquitectura y la observabilidad de una aplicación sin provider se abren cuando se puedan agregar recursos a sus scopes (#151), y estas aplicaciones no se publican al equipo hasta que el bundle lleve scopes (#153).
Correcciones de claridad en KUApps (#239): el inspector del Mapa mostraba solo el nombre del recurso (su contenido estaba dentro de un template que no se renderizaba); tras recargar, una aplicación con varias cuentas pedía agregar cuentas que ya tenía (un 404 del provider elegido en otra parte de KUA ocultaba el detalle de la aplicación, y el Mapa dependía de un scope elegido en Agregar recursos), así que ahora el Mapa abre con el perfil dueño de su vista; la tasa 5xx del balanceador podía superar el 100 % porque los errores que genera el propio balanceador no forman parte de RequestCount, así que la tasa ahora cuenta solo los errores de los targets y los 5xx del balanceador son una señal aparte, contada; "Cobertura de señales" pasa a "Recursos con datos recientes", con compatibles, habilitados y con datos, y verde solo para cobertura efectiva; {targetGroup} y "No data in this range" se traducen.
Aplicaciones sin provider sin señales: una aplicación creada en KUApps con cuentas de varios proveedores (por ejemplo un clúster EKS) no podía abrir Señales, Revisión ni Recolectar ahora, y Fuentes y sincronización decía que no estaba disponible, porque Observabilidad solo atendía aplicaciones con un perfil propio. Ahora se atienden por las rutas genéricas de Observabilidad: los workloads de Kubernetes se recolectan con su contexto de kube, los recursos de AWS con el perfil verificado asociado a su cuenta (un recurso de una cuenta sin perfil verificado se informa como tal, nunca se lee con el perfil de otra cuenta), y la recolección programada las incluye cuando el sondeo está activo. El inspector del Mapa también muestra las señales de los workloads de Kubernetes dentro de una aplicación AWS.
Aplicaciones que desaparecían de la barra de KUApps: abrir Mapa, Recursos o Ajustes de una aplicación cargaba en la lista compartida las aplicaciones de Arquitectura del perfil de esa aplicación, así que las de otros perfiles desaparecían de la barra lateral de KUApps hasta refrescar. KUApps ahora mantiene su propia lista.
Aplicaciones legacy después de la migración de scopes: una aplicación creada con un perfil perdía el Mapa y Agregar recursos cuando la migración le daba scopes cuyo perfil aún no estaba verificado. Vuelve a usar su propio perfil.
Perfil local en KUApps exportadas: un KUAAppBundle (export, respaldo en la nube, sincronización y equipo) omitía los ids de perfil, pero los conservaba dentro de las identidades del registry de recursos (identityKey), y los cambios automáticos de arquitectura se exportaban con el perfil como autor. Ahora los recursos viajan con una identidad portable (provider, cuenta/proyecto/contexto, ubicación, tipo e id nativo), las relaciones apuntan a esos ids y los autores que eran perfiles se exportan como local; los bundles antiguos se limpian al leerse otra vez. Los respaldos y copias de equipo hechos antes de esta versión conservan el valor antiguo hasta que la aplicación se vuelva a subir. El contrato de KUA Application que lo sustenta, sin provider ni perfil propios, está en Arquitectura → Contrato de KUA Application.

Advisor

Advisor de producto v2 (#96): muestra el consumo y burn rate del presupuesto de error de APM/logs, reutiliza inspecciones técnicas recientes de scopes verificados y filtra hallazgos por membresía del registry antes de recomendar sobre riesgos coincidentes. DORA queda explícitamente no disponible hasta poder correlacionar historial de releases y commits; no agrega scans ni lecturas facturadas.
Cobertura del Advisor por proveedor (#95): AWS suma chequeos de policies wildcard, roles sin uso y política de contraseñas IAM, además de SQS, SNS, DynamoDB y CloudFront, al scan cacheado por 15 minutos. S3 se analiza por separado y solo a pedido: el overview muestra cantidad de buckets y una estimación conservadora de solicitudes/costo a USD 0,0004 cada 1.000, pide confirmación antes de las lecturas detalladas y cachea los resultados por 15 minutos. Kubernetes suma bindings cluster-admin, namespaces sin labels de Pod Security Admission y Secrets montados por muchos pods. Vercel revisa la protección de deployments Preview y solo los nombres de variables de Preview que parecen credenciales; nunca devuelve sus valores. Los catálogos de runtimes deprecados incluyen fecha de revisión y un test de vigencia de seis meses. Los límites de los colectores se muestran como resultados parciales, no como scans completos.
Análisis de logs por recurso en KUApps: el Advisor de producto lee agregados locales sanitizados para cada recurso AWS y Kubernetes usando el scope verificado de cuenta/región o clúster/namespace correspondiente. Marca tasas de error por encima del objetivo, señales recurrentes o graves, grupos aún no cacheados y scopes sin acceso verificado como hallazgos distintos; no usa mensajes crudos ni hace nuevas llamadas a la nube. Topology puede abrir directamente los logs del workload Kubernetes correspondiente.
Falsos positivos del Advisor: la regla de AWS de roles IAM sin uso leía el último uso de ListRoles, que nunca lo devuelve, así que marcaba todos los roles como nunca usados; ahora lo lee con GetRole (sin costo, hasta 200 roles, de a pocos), marca los roles nunca usados solo si tienen más de 90 días, y los roles y políticas de IAM se paginan con Marker en vez de quedarse en los primeros 100. La regla de cluster-admin de Kubernetes ya no reporta el binding cluster-admin de fábrica hacia system:masters, los bindings administrados eks: ni las service accounts de namespaces kube-*, que tiene todo clúster. La regla de Secrets muy usados cuenta workloads en vez de réplicas. En Vercel, las credenciales de previews se reportan solo cuando las previews no están protegidas, ya no duplican el hallazgo de secretos compartidos con producción, y Vercel Authentication en previews cuenta como protección aunque una contraseña proteja solo producción.
Advisor en cada resumen: los resúmenes de Kubernetes, AWS y GCP suman un panel de recomendaciones de buenas prácticas agrupadas en seguridad, infraestructura, arquitectura y desarrollo, cada una con su severidad, los recursos afectados y un link a la documentación del proveedor. Los chequeos son deterministas (sin IA) y solo usan datos que KUA ya lee o APIs de control gratuitas: Kubernetes suma NetworkPolicies, PodDisruptionBudgets y HPAs al resumen (contenedores privilegiados o como root, credenciales en texto plano en variables de entorno, faltan requests/limits/probes, una sola réplica, tags de imagen flotantes, namespaces sin NetworkPolicy…; se omiten los namespaces kube-*); AWS lee el credential report de IAM, CloudTrail, EC2, RDS, Lambda y EKS (MFA y keys de root, keys viejas o sin uso, puertos abiertos a internet, IMDSv1, bases públicas o sin cifrar, backups, Multi-AZ, runtimes deprecados, volúmenes e IPs huérfanos…; con caché de 15 minutos, sin llamadas a Cost Explorer ni CloudWatch); GCP reutiliza las filas del resumen (service accounts default, IPs públicas, backups y HA de Cloud SQL, acceso a buckets, hardening de GKE, runtimes deprecados…). Las fuentes que no se pueden leer se listan con las acciones IAM que necesitan.
Advisor de producto en KUApps: cada aplicación tiene la mirada de producto: objetivos incumplidos, objetivos que quedaron en los defaults de KUA, sin equipo dueño o sin entorno, producción sin una etapa previa, sin arquitectura de los journeys de usuario y telemetría faltante o desactualizada. Se calcula desde el registro de KUApps sin llamadas a la nube.

Logs y observabilidad

Inteligencia de logs multicloud (#92): KUA Applications permite activar por recurso Cloud Run/Cloud Function de GCP o un proyecto Vercel. Cloud Logging se limita a cinco páginas entries.list por sync y muestra una estimación antes de la primera lectura; Vercel lee solo runtime logs del último deployment de producción, limita cada respuesta a 2 MiB/5.000 eventos y respeta Retry-After. Ambas fuentes usan la caché compartida cifrada, el sanitizador, la ventana de retención y el mapeo de evidencia.
Tasas históricas de logs y objetivos compartidos (#90): Observability grafica las tasas de errores y warnings cacheadas desde los buckets locales de 30 días, con frescura de sincronización y cobertura faltante de caché o scopes explícita. El objetivo existente de tasa de error ahora evalúa métricas APM y eventos de logs; las firmas sanitizadas recurrentes se comparan con las 24 horas anteriores usando un umbral configurable de crecimiento. El Advisor de producto informa objetivos de logs incumplidos mediante el motor compartido, sin logs crudos ni lecturas a la nube.
Cobertura compacta de logs en KUApps: Señales y Mapa muestran primero el conteo de recursos y conservan la lista completa de elementos sin caché o sin scope disponible en un desplegable acotado, evitando que aplicaciones grandes desborden la vista.
Firmas de logs de contenedores: las líneas envueltas por el runtime de contenedores ({"time","stream","log"} de Docker, containerd y Container Insights) y los logs con colores (NestJS, Winston) generaban una firma por pod y muestras llenas de códigos de escape. Las firmas y muestras ahora salen del mensaje de la aplicación sin colores, así que el mismo error en varios pods es un solo error recurrente. Los grupos en caché se vuelven a analizar automáticamente en la siguiente lectura (en local, sin llamadas a AWS).
Búsqueda en CloudWatch Logs: las búsquedas en vivo devolvían los eventos más antiguos del rango (FilterLogEvents lee hacia adelante) mientras que la caché devolvía los más nuevos, y la caché buscaba los filter patterns como texto plano. Ahora ambas devuelven los eventos más nuevos y aplican la misma sintaxis de filter patterns.
Refresco automático de logs en caché y tamaño de caché configurable (planes Pro y Team): cada log group de CloudWatch o workload de Kubernetes en caché puede refrescar sus eventos más nuevos cada 1, 5, 15, 30 o 60 minutos mientras KUA está abierto (sin rellenar historia, nunca con Logs Insights, se detiene al llegar al presupuesto de la caché), configurado desde su fila o apenas termina un escaneo, mostrando las solicitudes por día que genera y el próximo refresco. El tamaño de la caché de logs se elige en las vistas de logs (de 256 MB hasta 20 GB). Límites por plan: Free mantiene 256 MB y sincronización manual, Pro hasta 2 GB y refresco cada 15 minutos o más, Team hasta 20 GB y cada minuto o más. La app de escritorio suma una capa de planes con los mismos planes que el control plane; hasta vincularse a una cuenta KUA, el plan sale de KUA_PLAN (free por defecto). KUA_LOG_CACHE_MB sigue reemplazando el tamaño.
Secciones plegables en el panel Intelligence de logs: anomalías, ML local, recomendaciones, categorías, errores y advertencias recurrentes, recursos mencionados y observabilidad se pliegan desde su título, mantienen un contador al lado (rojo o amarillo según severidad) y siguen cerradas entre log groups y sesiones. El panel ya no se recarga solo cuando una sincronización o un escaneo en segundo plano guarda eventos nuevos: avisa que hay un escaneo del grupo en curso y, cuando hay eventos nuevos en caché, ofrece "Actualizar análisis", así se conservan los filtros y las secciones abiertas mientras leés.
ML local para logs: un modelo de embeddings local y opcional (paraphrase-multilingual-MiniLM-L12-v2, unos 130 MB, que se descarga una vez desde Hugging Face, gratis, al activarlo en Intelligence → ML local, y se puede borrar desde ahí) suma búsqueda por significado en los errores recurrentes de todos los log groups en caché, también en español sobre logs en inglés; agrupa errores que dicen lo mismo con otras palabras; y sugiere una categoría para los errores que las reglas dejan sin categoría. Corre en esta computadora con ONNX Runtime (ningún texto sale de ella, sin llamadas a AWS), sobre las firmas sanitizadas, y los vectores quedan en caché para calcular cada error una sola vez. Los agentes reciben los errores parecidos en el brief y una herramienta MCP nueva, search_logs. El instalador solo lleva los binarios de ONNX Runtime de su plataforma.
Anomalías en los logs: el panel Intelligence de cada log group en caché señala qué cambió frente a sus 7 días anteriores: picos de errores en la última hora (y si solo acompañan a más tráfico), caídas del volumen de logs frente a la misma hora del día, una categoría de fallo o de cliente a 3× o más su ritmo habitual, y errores recurrentes que aparecieron en las últimas 24 h. Cada anomalía explica el valor esperado, abre su tramo de tiempo o sus eventos, y forma parte del brief para agentes y de la respuesta log_intelligence del MCP. Solo se evalúa el tiempo sincronizado, así que una caché desactualizada o nueva se informa en vez de adivinarse. Estadística simple sobre los agregados locales: sin IA y sin llamadas a AWS.
Escaneos de logs en segundo plano: leé hasta 5 días de un log group de CloudWatch en la caché local mientras seguís trabajando. Los escaneos corren en segundo plano (dos a la vez, el resto en cola), leen primero la hora más reciente, muestran progreso y tiempo restante, y se pueden pausar, reanudar o cancelar; el avance se guarda después de cada página, así que un escaneo interrumpido al cerrar KUA vuelve pausado y continúa donde quedó. El rango escaneado se mantiene más allá de la ventana habitual del grupo (hasta el límite de 7 días de la caché), y el escaneo se detiene en lugar de borrar datos cuando la caché llega a su presupuesto. Antes de empezar, KUA estima el volumen contra el espacio libre de la caché; FilterLogEvents no se cobra por request y la descarga cuenta como transferencia de salida de AWS (primeros 100 GB/mes gratis). "Ver en caché" abre el rango escaneado en los eventos cacheados.
Gráfico de actividad de logs: eventos por nivel en el tiempo con una resolución que se adapta al rango (segundos, minutos, horas o días), zoom con clic o arrastrando, tooltip y vista de tabla; los resultados de Logs Insights agrupados con bin() también se grafican. El gráfico conserva su historia: un índice por minuto de eventos por nivel se guarda 30 días aunque los eventos ya hayan salido de la caché (un grupo con mucho volumen puede guardar solo una hora de eventos), y la vista "Volumen total" lee la métrica IncomingLogEvents de CloudWatch para cualquier grupo y rango (~USD 0,00001 por lectura, reutilizada desde el historial local de métricas).
AWS CloudWatch Logs: nueva pestaña con todos los log groups clasificados como servicio de AWS, máquina (agente de CloudWatch, instancias EC2 detectadas por sus streams) o propios; streams y eventos recientes.
Caché local de logs: guardá los log groups que elijas hasta 7 días, menos si el volumen del grupo no entra en su parte del presupuesto (KUA_LOG_CACHE_MB, 256 MB por defecto). Los eventos se sanitizan, se comprimen (~19x en logs reales de Lambda) y se cifran con AES-256-GCM usando una clave guardada en el llavero del usuario del sistema operativo; nunca salen de la máquina. Las sincronizaciones leen primero las horas más recientes y después completan las anteriores. Una caché anterior en texto plano se migra automáticamente. Cada grupo tiene una configuración de historial (solo eventos nuevos, última hora, 6 h, 24 h, 3 días o toda la ventana) y una acción "completar ahora".
Consultas de logs: sintaxis de Logs Insights (fields, filter, parse, stats, sort, limit, display, dedup) con autocompletado, validación en vivo con sugerencias, plantillas por tipo de log y un armador de filtros. Corre gratis sobre la caché o una muestra en vivo, o en Logs Insights después de mostrar el volumen y el costo estimados.
Vista de respaldo en S3: por log group, si sus logs se copian a S3 (suscripción o tareas de exportación) y cuáles vencen sin copia; tareas de exportación, CloudTrail y VPC flow logs escritos en S3, y un explorador del archivo que lee exportaciones gzip.
Inteligencia de logs: cada log group cacheado se analiza con reglas deterministas compartidas con la evidencia de logs de Kubernetes: tasas de errores y warnings, firmas de error recurrentes, palabras clave de fallas (timeouts, throttling, memoria, accesos, conexión) y referencias a otros recursos. Solo se guardan agregados (30 días). En Observability, la topología inteligente muestra estas señales para los recursos de la aplicación, marca tasas de error por encima del umbral de la aplicación, lista los recursos sin logs cacheados y sugiere relaciones vistas en los logs para revisarlas; nada se conecta automáticamente. Las líneas REPORT de Lambda de los grupos cacheados también alimentan las métricas de APM. Los eventos se categorizan (timeouts, memoria, throttling, permisos, conexión, código, configuración, base de datos, errores del cliente, cold starts…) y se pueden filtrar por categoría, nivel o error recurrente; los valores sensibles que llegan a los logs se cuentan por tipo (incluidos números de tarjeta y RUT). Cada grupo recibe recomendaciones con evidencia y confianza: correcciones por categoría (con las acciones IAM exactas cuando un mensaje de acceso denegado las menciona), enmascarado en el origen y políticas de protección de datos de CloudWatch, logging estructurado, nivel de log y retención.

Agentes IA y MCP

Cambios en KUApps desde agentes IA (#155): los agentes pueden crear y editar KUA Applications, asociar o desvincular recursos y vincular o desvincular vistas mediante el servidor MCP, en dos pasos: preview_application_change devuelve un plan y apply_application_change lo ejecuta solo después de que el usuario lo aprueba y solo mientras Conectar un agente IA → Permitir que agentes cambien KUApps está encendido (apagado por defecto). Un plan hecho sobre una revisión anterior se rechaza con la revisión actual, aplicar un plan dos veces devuelve su resultado registrado, get_application_change lo lee si se perdió la respuesta, los recursos necesitan su identidad nativa y scope, y cada aplicación queda auditada. No se crea ni se borra nada en la nube.
KUA Applications para agentes IA (#154): el servidor MCP suma tres herramientas de solo lectura: get_application, list_application_resources y get_architecture_graph. Leen una aplicación con el mismo servicio de KUApps que la UI (los scopes salen de la aplicación, nunca del perfil AWS elegido en KUA), informan el estado de señales de cada recurso y la hora de sus últimos datos, entregan una vista solo a través de su aplicación e indican qué scopes puede leer este computador sin nombrar el perfil. Solo datos locales.
Briefs para agentes IA: el Advisor de cada overview (AWS, GCP, Kubernetes y la lente de producto de KUApps) y las recomendaciones de la inteligencia de logs suman "Copiar para agente IA" y "Descargar brief (.md)". El brief es una tarea autocontenida en Markdown para Claude Code, Codex, ChatGPT o cualquier otro agente: contexto (proveedor, cuenta, región, namespace o log group), reglas de trabajo (verificar primero el estado actual, corregir por severidad y causa raíz, cambiar la infraestructura como código en vez de la consola, pedir confirmación antes de operaciones destructivas o con costo, nunca exponer secretos), cada hallazgo con sus recursos afectados y documentación, y para logs la actividad, las firmas sanitizadas, consultas de Logs Insights, ejemplos de código y los recursos con los que habla la carga, más cómo verificar la corrección. Se arma localmente con datos que KUA ya tiene, en el idioma de la app: sin IA y sin llamadas a la nube.
Servidor MCP para agentes IA: mcp/server.mjs permite que Claude Code, Codex CLI y otros clientes MCP lean KUA directamente: perfiles, hallazgos del Advisor de AWS, GCP, Kubernetes y producto, log groups en caché y su inteligencia de logs, como los mismos briefs en Markdown o como JSON, en inglés o español. Corre por stdio en tu equipo, lee la API de KUA (KuaDashboard debe estar abierto; KUA_URL reemplaza http://localhost:7190), no tiene dependencias y todas las herramientas son de solo lectura: sin llamadas con costo y sin devolver credenciales. También corre desde la app instalada con el ejecutable de KuaDashboard en modo Node, así que no requiere Node.js; el ícono de enchufe junto a los botones del brief abre Conectar agentes IA con la configuración exacta para Claude Code, Codex CLI, clientes JSON y el config.toml de Codex. Configuración en Funcionalidades → Agentes IA.

Planes y cuenta

Webhooks de alertas en Cuenta, para Pro y Team: los webhooks de Slack y Microsoft Teams para las alertas de postura del Advisor pasan de Ayuda y opciones a su propia sección en Cuenta, y también están disponibles en el plan Pro (siguen los planes del Advisor). La comparación de planes los incluye.
Registro del gasto opcional: Ayuda y opciones → Cuenta desactiva el registro de lo que KUA gasta en APIs cloud (y, si quieres, borra su historial) y lo vuelve a activar. Mientras está desactivado no se registra nada y se ocultan los paneles de gasto del overview de AWS y de la caché de logs. Por defecto sigue activado.
Iniciar sesión en una cuenta KUA y contratar desde KUA: Ayuda y Opciones → Cuenta inicia sesión con Google a través del navegador del sistema (redirección a la propia computadora con un código de un solo uso y PKCE; el token de sesión queda en el llavero del sistema operativo y nunca llega a la interfaz) y toma el plan de la cuenta, guardado 7 días para usarlo sin conexión y actualizado cada 6 horas. Con la cuenta vinculada se puede pasar a Pro o Team, mensual o anual, en el checkout de Polar (KUA espera la confirmación del pago y actualiza el plan) y gestionar la suscripción en el portal de facturación. KUA_PLAN sigue reemplazando el plan en una computadora, para desarrollo. El control plane suma /auth/desktop/start, /auth/desktop/token, cierre de sesión con token y una página para volver a KUA después del checkout.
Cuenta en Ayuda y Opciones, y el Advisor como función Pro: una nueva pestaña Cuenta reúne todo lo que dependerá de la cuenta KUA: el plan y de dónde viene, una comparación Free / Pro / Team, el tamaño de la caché de logs, el ML local y lo que gastó KUA este mes; el inicio de sesión llega con la vinculación de cuentas. El Advisor ahora es parte del plan Pro: en Free, los overviews y KUApps muestran solo los conteos (chequeos que pasan, hallazgos por categoría y severidad) detrás de un candado con "Ver planes", y las herramientas MCP del Advisor explican el plan en vez de devolver hallazgos. Lo aplica el servidor, así que los recursos y las correcciones nunca llegan a un cliente Free. Mientras la app no se vincule a una cuenta, usa KUA_PLAN=pro o team.
Lo que gasta KUA: cada llamada al AWS SDK que hace KUA se mide en un solo lugar, se valoriza con los precios públicos de AWS (us-east-1) y, cuando tiene precio por uso, queda en un registro local con su cálculo: GetMetricData por métrica, Logs Insights por GB escaneado, Cost Explorer por solicitud, Athena por TB escaneado (mínimo 10 MB), Lex por solicitud de texto, y las descargas de logs (FilterLogEvents: sin cargo por solicitud, transferencia dentro de los primeros 100 GB al mes gratis, mostrada como el costo fuera de la capa gratuita). Cada llamada se atribuye al perfil y a la funcionalidad que la hizo, incluidos los escaneos en segundo plano y las recolecciones de Observabilidad. Un panel "Gasto de KUA" en el overview de AWS y en la vista de caché de logs muestra hoy, este mes y los últimos 7, 30 o 90 días, cada operación como cantidad × precio unitario = USD, el desglose por funcionalidad y las últimas llamadas facturables. Es una estimación de las llamadas de KUA, no la factura de AWS.
Cobro con Polar (merchant of record): Stripe no acepta cuentas de Chile, así que el control plane pasa a tener un proveedor de cobro intercambiable, con Polar como principal: checkout y portal de cliente con la API REST de Polar, clientes vinculados por id externo, verificación Standard Webhooks y eventos de suscripción que activan o quitan Pro/Team. Mismos planes y precios; Stripe queda disponible para una futura empresa en el extranjero.
Planes de Stripe (modo prueba): KUA Pro (USD 9/mes, 90/año) y KUA Team (USD 29/mes, 290/año, hasta 10 miembros), un portal de cliente para cambiar de plan, tarjeta o cancelar, y checkout anual. El plan sale del precio de la suscripción, así que los cambios de plan desde el portal se aplican.

Escritorio y sistema

Panel de tareas en segundo plano: el header compartido abre una vista actualizada de tareas activas, programadas y recientes, con progreso, tiempo transcurrido en vivo, proveedor, controles anunciados por la API y métricas globales de CPU/memoria claramente separadas del consumo por tarea. Cuando el ledger AWS tiene datos de esa actividad, muestra el costo estimado de los últimos 30 días (incluido el potencial fuera del nivel gratuito), nunca como costo de una ejecución individual; los costos de otros proveedores quedan explícitamente sin medir. El drawer y los cambios de tareas usan transiciones sutiles y respetan la preferencia de movimiento reducido. Consulta solo mientras está abierto, se actualiza cuando KUA vuelve a primer plano y muestra estados de carga, lista vacía y errores recuperables en inglés y español.
Controles de tareas en segundo plano: POST /api/system/tasks/:id/:action expone solo las acciones que soporta cada tarea. Los escaneos de logs se pueden pausar, reanudar o cancelar de forma independiente; una request en curso termina su página antes de aplicar el control y el avance sobrevive al reinicio como pausado. Los schedulers periódicos pausan solo su propio timer y dejan que el trabajo activo termine en un punto seguro.
API de estado de tareas en segundo plano: GET /api/system/tasks informa si la recolección APM, el refresco automático de logs, la sincronización de aplicaciones/equipo y Advisor están programados, en ejecución, completados o fallaron, junto con uptime, contadores de tiempo de CPU y memoria del proceso. Es de solo lectura; los errores se reducen a códigos validados y CPU/memoria no se atribuyen a tareas individuales.
Modo de escritorio en segundo plano: al cerrar la ventana, KUA y su backend siguen activos en la bandeja del sistema; se puede recuperar desde allí o elegir Salir para apagar ordenadamente. La preferencia de cerrar a la bandeja es local y, si Linux no ofrece una bandeja compatible, iniciar KUA otra vez recupera la instancia existente.
Paneles transparentes: una docena de pantallas (AWS, GCP, Observabilidad, KUApps) pintaba paneles con un color que nunca se había definido, así que se veían transparentes. El color ahora existe en los dos temas.
API local accesible desde la red: el servidor de KUA escuchaba en todas las interfaces de red, y su API no tiene autenticación, así que otro equipo de la misma red podía leer perfiles, clústeres y logs o abrir shells a través de él. Ahora escucha solo en 127.0.0.1; KUA_HOST lo expone a propósito (por ejemplo 0.0.0.0 en una red de confianza), con un aviso al arrancar.
Idioma de las pantallas de detalle: los detalles de EC2, Lambda, EKS y VPC, los paneles Info de Cloud Run, VM y Cloud SQL de GCP, el modal de creación de recursos de GCP, la terminal y las pantallas de conexión RDP/SSH de EC2, las vistas de AWS y GCP (cada pestaña de servicio, modal, aviso y lista vacía), el detalle de Step Functions, las vistas de Arquitectura (lienzo, rutas, recursos y paneles de discovery), Helm, el modal de perfiles, EventBridge, la observabilidad y los logs de aplicaciones, KUApps, los exploradores de S3 y GCS, el panel de observabilidad de EKS y el visor de archivos tenían texto fijo, así que varias quedaban en un solo idioma sin importar el de la app. Ahora siguen el idioma de la app, fechas incluidas, y un test evita que las pantallas migradas vuelvan a tener texto fijo.
Historial de versiones y textos restantes en los dos idiomas: las versiones 1.16 y anteriores del modal de Ayuda, el sondeo, el historial de estados, las etiquetas y las confirmaciones de iniciar, detener y eliminar de GCP, el editor YAML, los avisos de actualización y de sesión de AWS, el port forwarding y la ventana de donación ahora están en inglés y español. Los scopes de GCP, el día de mantenimiento de Cloud SQL y los presets de creación llegan del servidor como códigos, así que también siguen el idioma de la app.
Despliegue del control plane: El control plane en Cloud Run (cloud/control-plane) ya se construye y despliega. Cloud Build corre con la cuenta de despliegue en vez de la de Compute por defecto (sobre la que el deployer no podía actuar), sube el código a su propio bucket y ya no sube node_modules; el servicio corre como kua-control-plane-run. La configuración pasa a variables y secretos de GitHub, y los valores sensibles se sincronizan con Secret Manager. Los webhooks de Stripe fallaban con PERMISSION_DENIED porque la base (default) de Datastore del proyecto rechaza toda escritura; el servicio ahora usa su propia base kua-control-plane. /health reemplaza a /healthz (reservada por Cloud Run) y los errores 500 quedan registrados.

v1.17.0 (2026-09-28)

Cloud Insights suma resúmenes, costos, actividad y salud para AWS y Kubernetes, agrega SQS, SNS y SES, dibuja los dashboards de CloudWatch dentro de KUA y hace que cada lectura automática indique cuánto cuesta.

Arreglado

Costos del auto-refresco de AWS: El auto-refresco global (cada 5 s por defecto) volvía a leer la actividad de 24 h de Lambda y Step Functions y los KPIs del Resumen en cada ciclo. Esas lecturas usan GetMetricData de CloudWatch, que se cobra (USD 0.01 por cada 1.000 métricas, fuera de la capa gratuita): unos USD 0.006 por carga de la tabla de Lambda con ~600 métricas, o cerca de USD 4 por hora con la pestaña abierta. Ahora la actividad y los insights del Resumen se reutilizan durante 15 minutos y el resumen de recursos (gratis) durante 5; el botón de actualizar sigue forzando una lectura nueva.
Dashboards de AWS: Los widgets de logs cuyo SOURCE es el ARN de un log group (por ejemplo SOURCE "arn:aws:logs:…:log-group:/aws/lambda/…") fallaban con Value at 'logGroupNamePrefix' failed to satisfy constraint. La estimación de tamaño ahora usa el nombre del log group y la consulta usa logGroupIdentifiers, que acepta nombres y ARNs; los grupos cuyo tamaño no se puede conocer (por ejemplo, de otra cuenta) nunca corren solos. También se respetan los widgets con rango propio (start/end) y la leyenda oculta.
Vista Vercel: Arreglado bug donde datos obsoletos de proyectos anteriores persistían tras cambios rápidos de proyecto. Se implementó protección contra condiciones de carrera con IDs de solicitud y limpieza explícita de contexto al cambiar de proyecto o perfil.
Modal AWS Lambda: Arreglado que las celdas de la tabla de variables de entorno no envolvían valores largos (ARNs, strings largos). Se hizo responsive el layout de la pestaña Código en dispositivos móviles y tablets: el árbol de archivos y el visor de código ahora se apilan verticalmente en pantallas ≤768px.

Cambiado

Idioma: El inglés pasa a ser el idioma base. Las instalaciones nuevas arrancan en inglés (se respeta el idioma ya elegido) y un texto que falte en el idioma activo usa el inglés en vez de mostrar la clave. Las tablas de recursos de Kubernetes, los chips de filtros rápidos, el historial de filtros, el Resumen y el panel de detalle (pestañas Resumen, YAML, Env, Data, Métricas y Eventos) quedan traducidos completamente a inglés y español; un test mantiene ambos diccionarios con las mismas claves.
Navegación de Kubernetes: Cambiar entre secciones del menú lateral (Workloads, Red, Configuración, Almacenamiento, Cluster) ya no vacía la tabla. Los recursos ya visitados en el mismo contexto y namespace aparecen al instante desde un caché local y se revalidan en segundo plano; solo un recurso nunca visitado muestra el estado de carga. Un delete, scale, restart o edición ahora invalida en el servidor solo las listas afectadas (por ejemplo, escalar un deployment refresca deployments, replicasets, pods y eventos) en vez de todo el caché, y los refrescos sin cambios no vuelven a renderizar la tabla.
AWS VPC: La acción "Details" de VPC ahora se llama "Info" y abre un modal dedicado alineado al patrón Info de EC2/Lambda (tabs subrayados, listas de definición, botones de copiar, badges en el header). Mismos datos y endpoint que antes.
AWS Route 53 (correcciones): Las pruebas DNS ahora llegan al backend (la UI llamaba a una URL inexistente), las pruebas A/AAAA incluyen la verificación TCP 443/80, las pruebas SPF y DKIM se ofrecen en los registros TXT que las contienen y solo se muestran pruebas que tienen sentido para cada tipo de registro. La selección de registros ya no se desplaza al cambiar la búsqueda o el filtro, los registros con política de routing (mismo nombre y tipo) se exportan por separado con su Set ID y las zonas con más de 300 registros se cargan completas. Se agregó una guía de diagnóstico DNS a la documentación de AWS.

Añadido

Mensajería AWS: detalles, logs, salud e historial de métricas: El detalle de SQS muestra consumidores Lambda, productores SNS, política de acceso, tags, espera de recepción (avisa el short polling) y más métricas. El de SNS muestra la filter policy, raw delivery y dead-letter queue de cada suscripción, y un visor de logs de estado de entrega (grupos de éxito y fallo, bajo demanda); la tabla suma tasa de éxito y mensajes filtrados. SES suma la lista de supresión, fallas de render, tasa de entrega, gráficos de tasas de reputación y métricas de eventos por configuration set (primero se cuentan, se leen a pedido). Colas, tópicos y la cuenta de SES tienen un estado de salud con motivos, con los umbrales de revisión de AWS SES. Las métricas por hora ya leídas se guardan en un historial local (base de APM), así los detalles solo piden lo que las tablas no leyeron y los gráficos de 24 h / 7 d / 30 d lo reutilizan; la retención se configura en Opciones (30 días por defecto). Los recursos usan las identidades del registro de KUA, y GET /api/cloud/aws/metrics/history lee el historial guardado sin llamar a AWS, listo para KUA Applications.
SQS, SNS y SES en AWS (#85, #86, #87): Nuevas pestañas en Integration. SQS: colas con mensajes visibles y en vuelo, enviados/recibidos/borrados en 24 h, dead-letter queue y redrive, cifrado y retención. SNS: tópicos con suscripciones confirmadas y pendientes, protocolos, publicados/entregados/fallidos en 24 h y estado del delivery status logging. SES: estado de envío, sandbox, cuota de 24 h, tasa de envío, métricas de enviados/entregados/rebotes/quejas/rechazados, identidades con verificación, DKIM y MAIL FROM (SPF), y configuration sets con sus destinos de eventos. Cada recurso tiene un detalle con gráficos por hora de 24 h de CloudWatch, avisos cuando faltan métricas o logs (con Solicitar acceso), y cada pestaña indica su costo; listar SQS se cobra por solicitud, así que una nueva opción Auto-actualización de tablas para AWS (30 s por defecto) limita las recargas en segundo plano. Los tres servicios se cuentan en el Resumen en vez de fuera de KUA, y los costos guardados en caché antes de que un servicio tuviera pestaña ya no lo marcan como fuera de KUA.
Caché y actualización para Kubernetes, GCP y Vercel: Opciones ahora agrupa la caché y la actualización por proveedor. Kubernetes: ventana de la caché de listas de recursos (se aplica a la caché del backend con PUT /api/system/cache-settings), intervalo de auto-actualización del Resumen y tendencias de Prometheus y reutilización del descubrimiento de Prometheus. Google Cloud y Vercel: tiempo mínimo entre recargas de tablas en segundo plano. Ninguna de estas lecturas se cobra por llamada; los nuevos valores de 30 s para el Resumen de Kubernetes y las tablas de GCP y Vercel reemplazan la recarga en cada ciclo de 5 s, y los botones de actualizar siguen cargando al instante.
Opciones de plataforma: caché y almacenamiento: Ayuda → Opciones tiene un grupo Caché y actualización para elegir cuánto tiempo se reutilizan la actividad de AWS, los KPIs del Resumen, el conteo de recursos y los costos de Cost Explorer, el intervalo de auto-actualización de los dashboards de CloudWatch y el límite de ejecución automática de Logs Insights. Cada opción muestra su costo con el valor elegido. Un panel Almacenamiento local muestra el espacio que usa la carpeta de datos de KUA: cada base SQLite con espacio usado, páginas libres, journal WAL y filas y tamaño por tabla, cada archivo, el almacenamiento del navegador, los perfiles con costos de AWS en caché y el espacio libre en disco (GET /api/system/storage, solo lectura). La pestaña Opciones ahora se adapta al ancho de un teléfono, Restaurar valores por defecto conserva el idioma y los botones de idioma vuelven a mostrar sus banderas.
Conexiones guardadas en la Consola: Guarda cualquier sesión de la consola con un nombre reconocible y vuelve a abrirla con un clic desde el workspace de Consola (logs/exec de Kubernetes, shell local, SSH a EC2, AWS SSM con su confirmación, logs/SSH de GCP, logs de Vercel); renombra o borra las conexiones guardadas y renombra las sesiones activas (doble clic en el nombre de la pestaña). Solo se guarda lo necesario para reabrir, nunca credenciales. Las sesiones y pestañas muestran iconos y colores por proveedor, y los nombres largos se acortan por el medio.
Actividad y estado de logs en AWS: La tabla de Lambda muestra las invocaciones y errores de las últimas 24 h de cada función y el estado de su log group de CloudWatch Logs (activo, vacío, inexistente o desconocido, usando los grupos propios de LoggingConfig), y la tabla de Step Functions muestra las ejecuciones de 24 h (incluidas las Express) y el nivel de logging, marcando las máquinas con el logging apagado. El endpoint de logs de Lambda responde un log group inexistente con un estado tipado en vez de un error, y la pestaña de logs de Lambda ahora está traducida. SQS, SNS y SES quedan en sus propios issues.
Dashboards de AWS dibujados en KUA: Los dashboards de CloudWatch ahora se pueden ver dentro de KUA con su disposición original: widgets de métricas (series de tiempo, barras, valor único, expresiones, SEARCH, SQL de Metrics Insights, anotaciones y umbrales de alarma), widgets de Logs Insights como tablas o barras, y widgets de texto y alarmas, con selector de rango y auto-actualización solo de métricas. Las consultas de logs muestran primero una estimación de los datos a leer y solo corren solas bajo ~1 GB; cada widget muestra los bytes leídos. El catálogo IAM ahora lee los comandos del SDK que importa cada ruta, lo que también completa las rutas de etiquetas.
Dashboards de CloudWatch en AWS: Nueva vista Monitoreo → CloudWatch Dashboards que lista los dashboards de la cuenta con un enlace para abrir cada uno en la consola de AWS y un panel de detalle que resume sus widgets (métricas y namespaces, log groups de Logs Insights, alarmas, vista y región) y muestra la definición JSON. Las fechas de las tablas de AWS ahora siguen el idioma de la app en vez del sistema operativo.
Costos y cobertura en el Resumen de AWS: El Resumen de AWS ahora muestra el costo del mes, la proyección a fin de mes, el mes anterior y los servicios más caros desde Cost Explorer (en caché 12 h por perfil en disco, porque AWS cobra cada consulta, con actualización manual), con la métrica de facturación de CloudWatch como respaldo; tarjetas de actividad de las últimas 24 h para Lambda, EC2 (CPU), load balancers (requests, 5xx, latencia), EKS (con Container Insights), RDS, DynamoDB, Step Functions, EventBridge, ejecuciones de Glue, CloudFront y almacenamiento de S3; y los servicios fuera de KUA que tienen costo, recursos etiquetados o cambios recientes en CloudTrail. Cada fuente se degrada por separado y ofrece solicitar acceso si falta un permiso.
Solicitudes de acceso en AWS: Los errores de permisos de AWS ahora son tipados: la API responde 403 con la acción IAM rechazada, las demás acciones que necesita la pantalla y una policy IAM sugerida. El aviso de error de AWS y las tarjetas Sin permiso del Resumen ofrecen Solicitar acceso, con un mensaje copiable para el administrador de AWS (en inglés o español) y el JSON de la policy. Las acciones salen de un catálogo generado desde los comandos del SDK de cada ruta (npm run aws:iam-catalog), limitado a los servicios que soporta KUA.
Resumen de AWS: Nueva primera vista del módulo AWS con la cuenta activa (y su alias), el tipo de identidad y su ARN (con advertencia si son credenciales root), la región del perfil y las regiones habilitadas de la cuenta, y una tarjeta por servicio con su cantidad de recursos para 16 servicios. Los servicios se leen en paralelo, cada uno con su tiempo máximo, así que un permiso faltante solo marca su tarjeta (mostrando la acción IAM cuando AWS la informa). Al hacer clic en una tarjeta se abre la pestaña del servicio. Lambda usa el total de la cuenta en vez de paginar todas las funciones.
Resumen de Kubernetes: Nuevo Resumen arriba en el menú lateral de Kubernetes con pods por estado, pods con problemas (CrashLoopBackOff, ImagePullBackOff, OOMKilled, NotReady…), salud y presión de nodos, workloads por debajo de sus réplicas deseadas, eventos Warning recientes y uso de CPU/memoria del clúster desde metrics-server. Pods, workloads y eventos siguen el selector de namespace; nodos y uso cubren el clúster. Cada tarjeta y fila abre la tabla correspondiente ya filtrada, y cada sección se degrada por separado si falta un permiso o la Metrics API. La columna Status de Pods ahora muestra el motivo del problema y un nuevo filtro rápido Con problemas lista los pods no sanos. El descubrimiento de Prometheus ahora se cachea por contexto en vez de listar todos los Services en cada consulta.
Tendencias en el Resumen de Kubernetes: Con Prometheus en el clúster, el Resumen agrega gráficas de CPU, memoria, reinicios y pods no listos para 1 h, 6 h, 24 h o 7 d, del clúster completo o del namespace seleccionado. Los clústeres sin metrics-server ahora obtienen el uso actual del clúster y por nodo desde Prometheus node-exporter. Las consultas a Prometheus reutilizan el servicio y puerto que respondió la última vez en vez de reintentar todos los candidatos.
Vistas de tablas de Kubernetes: Cada tabla de recursos recuerda su filtro de texto, columna de orden y chips de filtro al salir y volver, y también tras recargar. Nuevos chips de filtro rápido con conteos en la mayoría de los recursos (por ejemplo, Pods: No Running, No listos, Con reinicios; Deployments: No listos, En 0 réplicas; ReplicaSets: Inactivas; Services/Endpoints: Sin backends; Secrets: TLS, Registry, Opaque; HPAs: En el máximo/mínimo; PDBs: Bloquean desalojos; NetworkPolicies: Bloquea ingress/egress; Nodes: No Ready, Cordoned; PVCs/PVs: No Bound). La caja de filtro guarda un historial de filtros recientes por recurso y permite marcarlos con estrella para dejarlos guardados.
AWS Route 53: Se agregó funcionalidad de búsqueda y filtrado para registros DNS. Los usuarios ahora pueden buscar registros por nombre o valor, filtrar por tipo de registro (A, TXT, MX, CNAME, etc.), seleccionar múltiples registros con checkboxes, y exportar los registros seleccionados como CSV para respaldo o análisis.
AWS Route 53 Validación DNS: Se agregó validación y diagnóstico de registros DNS. Los usuarios pueden probar registros directamente desde la vista de Route 53 para verificar que se resuelven correctamente y están publicados en Internet. Soporta registros A (con verificación de conectividad TCP), TXT, MX, CNAME, NS además de validación de SPF y DKIM. El backend usa el módulo dns nativo de Node para resolución DNS pública.
Services de Kubernetes: La tabla de Services ahora muestra la app asociada (desde el selector del Service) y las IPs internas de los pods que respaldan cada Service, leídas de EndpointSlices con una sola llamada por namespace. Se marcan los pods no listos, y las columnas Type y Cluster IP no cambian.
Info de AWS EKS: Nuevo panel Info para clusters EKS, con el diseño de EC2/Lambda, enfocado en la infraestructura AWS del cluster: VPC, subnets y security groups (con qué usa cada uno), managed node groups, instancias EC2 nodo (managed, Karpenter y self-managed) y add-ons de EKS. Cada sección se degrada por separado con un aviso cuando falta un permiso. La tabla de EKS agrega las columnas Node groups y cantidad de instancias EC2, y muestra el endpoint de la API bajo el nombre de cada cluster.
Severidad de eventos de Kubernetes: Los eventos se colorean como Critical, Warning o Normal (columna con badge y borde de fila) según su tipo y motivo, y chips con conteos en la barra filtran la tabla por severidad, combinados con el filtro de texto.
Selector Perfil → Proyecto de Vercel: Un selector de Proyecto junto al perfil de Vercel en el header, como Cluster → Namespace en Kubernetes. Cambiar de perfil recarga sus proyectos; cambiar de proyecto recarga la vista activa que depende del proyecto. Se recuerda el último proyecto por perfil y la tabla Projects queda sincronizada como atajo. Elegir un proyecto ya no recarga las vistas que no dependen de él, y las listas de proyectos de un perfil anterior se ignoran si llegan tarde.
GCP Cloud Run, VMs de Compute y Cloud SQL: Tablas con columnas de detalle (imagen, CPU/memoria, escalado y revisión en Cloud Run; red, discos, Spot y protección en VMs; estado claro RUNNING/STOPPED, HA, almacenamiento, backups e IPs en Cloud SQL) y Start/Stop/Eliminar en cada fila. Nuevos formularios de creación con costo estimado en vivo. Iniciar muestra el costo estimado y exige aceptar el costo; eliminar exige escribir el nombre y se bloquea si el recurso tiene protección contra eliminación; crear exige el nombre, aceptar el costo y, desde $100/mes, una segunda confirmación de costo alto. El backend aplica las mismas validaciones y audita cada creación y eliminación.
SSH a VMs de GCP: Abre una shell SSH en una VM de Compute Engine desde la tabla de VMs, dentro de la consola de KUA, igual que el SSH de EC2 y sin llaves guardadas: una llave cifrada por cuenta de Google, autorizada vía OS Login o metadata con vencimiento de 24 horas y reutilizada al reconectar sin modificar la VM.
Detalle, etiquetas e historial de estados en GCP: El detalle de Cloud Run, VMs y Cloud SQL se reorganiza en tarjetas con mucha más configuración y observaciones de seguridad (acceso público, secretos en texto plano, backups desactivados, conexiones SQL sin cifrar…), sin exponer nunca valores secretos. Las etiquetas se pueden editar con las reglas de GCP validadas. Una nueva pestaña Historial muestra los cambios de estado y las acciones; el sondeo de estados en segundo plano se puede activar por perfil con intervalo, tipos de recurso y retención a elección (desactivado por defecto, con las lecturas de API por día visibles).

v1.16.0 (2026-09-16)

Console Sessions unifica toda conexión remota — Kubernetes, Terminal local, SSH de EC2, AWS SSM, GCP y Vercel — detrás de un único registro compartido de sesiones y un workspace global.

Las sesiones de Consola ahora tienen acciones contextuales "Open in Console" de un clic donde realmente existe la capacidad: una fila de instancia EC2 obtiene una nueva acción "⚡ SSM" junto a SSH/RDP, la pestaña Logs de un servicio de GCP Cloud Run obtiene una acción "Open in Console", y una fila de deployment de Vercel obtiene otra. Toda sesión abierta desde Architecture, Observability o estas nuevas acciones ahora encadena correctamente su environment y application id reales hacia la sesión (antes, toda entrada de auditoría de una sesión mostraba environment: default sin importar desde dónde se abriera). El lanzador de Console de GCP Cloud Run ya no requiere escribir un project id — siempre se resolvía desde el perfil de credenciales del lado del servidor, pero una validación más estricta del lado del cliente bloqueaba que ese fallback se usara. Esto cierra el épico de Consola (#36-43). Ver sesiones de consola.
GCP y Vercel se suman a la Consola con capacidades honestas: ahora se pueden seguir logs de Cloud Run (GCP) y de deployments (Vercel) como sesiones (sin shell — ambas son streams de logs de una sola vía), mientras que Cloud Shell de GCP queda marcado explícitamente como no disponible, con el motivo visible en el lanzador, ya que no hay forma de iniciarlo desde una credencial de service account almacenada. Ver sesiones de consola.
Ahora se pueden iniciar sesiones AWS SSM Session Manager desde la Consola — sin necesidad de claves SSH, solo un perfil de AWS confirmado y un ID de instancia. Requiere tener instalado session-manager-plugin de AWS (el lanzador muestra una ayuda de instalación y deshabilita Conectar si no está); iniciar una sesión siempre requiere confirmación explícita primero. Un permiso denegado nunca deja una sesión huérfana. Ver sesiones de consola.
Las pestañas de Consola, su orden, la pestaña activa y las preferencias de ajuste de línea/altura ahora sobreviven a una recarga — las pestañas restauradas siempre vuelven desconectadas, nunca reanudando una sesión remota en silencio, y requieren un Reconectar explícito (ahora disponible también desde el panel rápido, no solo desde el workspace de Consola). El historial de comandos ahora es compartido y se persiste por destino exacto (namespace/pod/container, ambiente, o host/usuario/ perfil) en lugar de dos historiales separados, no persistidos y sin alcance, acotado a 200 comandos por destino y 50 destinos en total, con una acción explícita de "Borrar historial" por pestaña y "Borrar todo el historial" en el workspace de Consola. Nunca se escribe nada sensible en el almacenamiento — solo el descriptor de sesión, nunca output crudo ni credenciales. Ver sesiones de consola.
Las sesiones SSH de EC2 ahora se unen al mismo registro compartido de Consola que Terminal local y logs/exec de Kubernetes: conectarse al mismo host/usuario/ perfil de credenciales desde la vista de AWS y desde el lanzador del workspace de Consola converge en una sola sesión en lugar de abrir una segunda conexión en paralelo, y el estado de la sesión ahora es uno de connected, error, done, reconnecting o stopped en lugar de un genérico "closed" único. RDP de EC2 no cambia. Se eliminó la vista de Terminal local independiente, que ya no se usaba. Ver sesiones de consola.
La Consola ahora es accesible desde un botón global en el header, disponible en cualquier módulo, además del panel rápido existente. Abre un workspace dedicado que lista todas las sesiones activas (proveedor, ambiente, región/proyecto, destino, estado) con acciones de cerrar/reconectar, más un lanzador para iniciar nuevas sesiones de Terminal local o logs/exec de Kubernetes. Ambas superficies leen el mismo store de sesiones, así que nada abierto en una queda invisible en la otra. SSH/RDP de EC2 siguen siendo accesibles solo desde la vista de AWS por ahora. Ver sesiones de consola.
El Canvas de Architecture agrega un overlay opt-in de "Events" que muestra los Kubernetes Warning Events sobre el nodo correspondiente (ahora se captura kind/name/namespace de cada evento), y acciones de nodo inline "Ver métricas aquí" / "Ver logs aquí" que abren en un modal en lugar de navegar siempre fuera del Canvas.
Las conexiones de consola validan su contexto antes de abrirse. SSH/RDP de EC2 usan el ID de un perfil de credenciales de Env Manager, en lugar de introducir contraseñas o rutas de claves en la consola. Local y Kubernetes siguen disponibles; SSM, shell GCP y logs Vercel quedan explícitamente planificados, no habilitados. Ver sesiones de consola.

v1.15.0 (2026-09-05)

Architecture Foundation integra arquitectura y observabilidad centradas en aplicaciones dentro de KUApps.

Continúa el plan de convergencia de KUA Application (Fases 9-16): contexto Architecture persistente, navegación a nivel de recurso, overlays de salud en el Canvas, una vista canónica de Resources compartida, menos revisiones sorpresa del grafo, diagnóstico de sincronización visible, filtros compartidos entre Canvas y Routes, y sugerencias deterministas de relaciones basadas en logs. También corrige un bug real de duplicación encontrado al validar este trabajo.

Observability: inteligencia de logs Kubernetes en Intelligent

El panel de topología Intelligent ahora mide las líneas retenidas actualmente por las pestañas de logs Kubernetes abiertas explícitamente para workloads/Pods: cantidad de líneas, tasa de error, advertencias, firmas de error recurrentes normalizadas y conteos de palabras habituales de fallo.
La medición es determinista y está acotada a la sesión. No ejecuta otra lectura a Kubernetes, no persiste logs crudos ni participa en el scheduler de 30 minutos. Las tasas históricas y alertas quedan para una futura fase de agregación persistida.
La evidencia de relaciones derivada de logs redacta credenciales comunes, tokens bearer, credenciales en URLs, query strings de URLs y valores con forma de correo antes de mostrar una muestra corta. El flujo explícito de revisión sigue siendo obligatorio antes de confirmar una dependencia calls.

Architecture Canvas y Routes: filtros de relaciones y carriles por proveedor

Canvas y Routes ahora comparten filtros persistidos por tipo y estado de relación, para enfocar diagramas grandes en routes_to, uses, relaciones sugeridas/manuales u otros cortes de dependencias sin cambiar el grafo.
Canvas agrega una organización por carriles de proveedor que agrupa recursos por nube/plataforma y los ordena por etapa lógica: entradas, routing/buffers, compute, runtime, datos/configuración y gobierno.
Canvas también agrega una organización por proveedor + secciones de recurso para diagramas que deben mantener cada proveedor separado primero y luego dividir sus recursos por tipo dentro de ese proveedor.
Los carriles por proveedor usan conectores escalonados y encabezados de sección para que los diagramas multiproveedor queden más estructurados y fáciles de recorrer.
Los layouts por secciones ahora amplían el espacio entre nodos cuando hay overlays activos como labels, métricas, estado de collection o trazas, y ordenan recursos del mismo tipo usando primero el contexto de relaciones antes que el nombre.
Se mejoró el toolbar del Canvas en pantallas estrechas para que los filtros y botones de overlays sigan disponibles dentro de una franja desplazable horizontal.
Refrescar un proyecto Architecture ahora recarga el grafo en la vista actual en vez de limpiar y remontar Canvas/Routes/Resources mientras la petición está en curso.
Cuando Architecture se abre dentro de KUApps, los proyectos ahora aparecen como subnivel de la Application seleccionada en vez de consumir una segunda barra lateral junto al canvas.
KUApps ahora usa su barra lateral global como único cambio entre Architecture y Observability, y Observability ya no renderiza una segunda lista interna de aplicaciones cuando está embebido allí.

Architecture Canvas: exportación a PDF y Mermaid

Se agregó un botón "Export PDF" que renderiza el diagrama completo (todos los nodos y relaciones, no solo lo visible en pantalla) en un PDF listo para imprimir, dimensionado al tamaño total del grafo, para que diagramas grandes puedan imprimirse o compartirse sin que nada quede recortado.
Se agregó un botón "Export Mermaid" que descarga el diagrama actualmente visible (respetando los filtros activos de proveedor/contexto/namespace) como un archivo .mmd de Mermaid.
Se corrigió que "Export PDF" generaba una página en blanco: el zoom del diagrama se calculaba con la unidad de margen incorrecta, lo que encogía todo el diagrama hasta casi desaparecer dentro de la imagen exportada. También se agregó un límite de tamaño y un timeout con aviso de error para que exportar un diagrama muy grande falle de forma controlada en vez de quedarse colgado indefinidamente.

Architecture: descubrimiento de referencias por variables de entorno de Lambda

El escaneo de inventario regional de AWS ahora infiere con qué habla una función Lambda (colas SQS, tablas DynamoDB, buckets S3, tópicos SNS) leyendo su configuración de variables de entorno — la misma metadata que ListFunctions ya devuelve — sin descargar ni ejecutar el código de la función.
Solo los valores que resuelven a un ARN completo o a una URL de cola SQS se convierten en sugerencia de recurso/relación; strings arbitrarios y secretos nunca se copian al grafo ni a su evidencia.
Estas nuevas relaciones references fluyen por la misma revisión de sugerencias y detección de aplicaciones candidatas ya existente, así que una Lambda de arquitectura basada en eventos (por ejemplo un dispatcher de colas) ahora puede mostrar su cola/tabla/bucket relacionado como sugerencia de importación incluso cuando nada apunta a ella desde CloudFormation o EventBridge.

Architecture: descubrimiento de capacidades por rol IAM y referencias estáticas de código

El escaneo de inventario regional ahora también lee las políticas del rol de ejecución de cada Lambda (solo metadata) y muestra colas, tablas, buckets o tópicos que está autorizada a usar como sugerencia más débil de "puede acceder", incluso cuando nada en su configuración las referencia todavía.
Un nuevo lector de código estático, estrictamente opt-in, puede descargar el paquete de despliegue de una Lambda específica y buscar patrones de ARNs/URLs literales y uso de clientes SDK de AWS en su texto fuente — nunca ejecuta ni evalúa el código, y solo corre para funciones seleccionadas explícitamente para el análisis.
Ambas señales reutilizan el mismo flujo de revisión de sugerencias de relación que cualquier otra fuente de discovery.

Cualquier ARN de AWS reconocible ahora se convierte en un recurso sugerido, incluso para servicios sin soporte dedicado todavía (Kinesis, destinos de API, etc.) — antes se descartaban en silencio, lo que también hacía que algunos targets de EventBridge nunca aparecieran.
Los tópicos SNS y sus suscripciones SQS/Lambda ahora se descubren como parte del escaneo regular de AWS, completando patrones comunes de fan-out pub/sub.
Cuando un recurso CloudFormation importa un valor de otro stack (Fn::ImportValue) que no se puede resolver solo con los stacks seleccionados, el panel de discovery ahora muestra un aviso recomendando agregar también ese stack, en vez de descartar esa dependencia en silencio.

Corregido: "Retry sync" nunca lograba limpiar algunos recursos divergentes

Los tipos de recurso que Architecture puede descubrir pero que Observability todavía no soporta en su esquema (S3, SNS, DynamoDB y cualquier servicio AWS detectado genéricamente) se contaban como "divergentes" aunque nunca pueden observarse desde ambos lados — reintentar la sincronización nunca los podía corregir, ya que eso requeriría correlacionar con una fuente que no existe para esos tipos.
El diagnóstico de recursos divergentes ahora solo cuenta tipos de recurso que realmente pueden confirmarse desde Observability y Architecture a la vez. Las relaciones divergentes (pendientes de revisión) no cambian, ya que esas sí son accionables desde el Canvas.

El registro compartido de recursos de Observability ahora soporta buckets S3, tópicos SNS y tablas DynamoDB, igualando lo que el discovery de Architecture ya podía encontrar. Estos recursos ahora correlacionan automáticamente en una sola entrada compartida en vez de aparecer solo del lado de Architecture.
Se corrigió un bug de identidad relacionado: los nombres de bucket S3 son únicos globalmente y nunca llevan cuenta/región en su ARN, así que depender de la cuenta/región del momento de discovery del nodo de Architecture para calcular la identidad podía crear una entrada de registro duplicada en vez de coincidir con la que produce Observability.

Corregido: los workloads Kubernetes podían descubrirse dos veces con una identidad rota

El discovery de Kubernetes derivaba el Kind de un workload (Deployment, StatefulSet, ...) de un campo que la API de Kubernetes no siempre devuelve en resultados de listado, lo que podía convertirse en silencio en un valor vacío o genérico. Cuando eso pasaba, la identidad del workload descubierto ya no coincidía con la de un alta manual o una sincronización previa, creando un recurso duplicado en Observability y un nodo duplicado en Architecture.
El Kind del workload ahora se conoce de antemano según qué endpoint de Kubernetes lo produjo, nunca se infiere de ese campo poco confiable, así que los workloads recién descubiertos siempre resuelven a la misma identidad que su contraparte agregada manualmente o sincronizada antes.

Architecture: los paneles de discovery muestran los recursos ya agregados al proyecto

Tanto el panel de discovery de AWS como el de Kubernetes ahora marcan los recursos del preview que ya existen en el grafo del proyecto actual, en vez de listarlos igual que los nuevos. Los recursos ya agregados muestran una insignia distintiva y ya no se pueden volver a seleccionar por accidente.
Las aplicaciones identificadas también muestran cuántos de sus recursos ya forman parte del proyecto.

Observability: los recursos Kubernetes muestran su tipo específico, y la divergencia se marca por elemento

Los recursos Kubernetes en la tabla de Resources y la vista de Topology de Observability antes se mostraban todos como "Kubernetes" genérico con el mismo ícono. Ahora muestran su tipo real (Deployment, Pod, Service, ConfigMap...) con un ícono acorde, para distinguirlos de un vistazo.
Los recursos divergentes y las relaciones divergentes (pendientes de revisión) ahora se marcan individualmente, no solo como conteo agregado, usando la misma regla que ya excluye tipos de recurso que Observability nunca puede correlacionar — lista para extenderse a futuros tipos de recurso de GCP/Vercel sin cambios de UI.

Architecture: los Deployments de Kubernetes ahora se relacionan entre sí desde metadata, igual que ya pasa con AWS

El discovery de Kubernetes solo relacionaba recursos por selectores de labels y referencias a ConfigMap/Secret/PVC; un Deployment cuyas variables de entorno apuntaban a otro Service por nombre (la forma más común en que las apps Kubernetes realmente se llaman entre sí) no generaba ninguna relación.
El discovery ahora lee los valores planos de variables de entorno — sin descargar ni ejecutar nada — y reconoce tanto una referencia DNS interna completa (service.namespace.svc.cluster.local) como un nombre de servicio simple cuando la propia clave de la variable lo sugiere (..._HOST, ..._URL, ..._SERVICE, ...), sugiriendo una relación calls hacia el Service o Deployment coincidente.
Estas sugerencias pasan por el mismo flujo de revisión que cualquier otra relación descubierta, y ahora aparecen de forma consistente tanto en Architecture como en Observability.

Observability: EC2 y S3 reportan métricas de CloudWatch, y más recursos AWS llegan al inventario

Los recursos EC2, EKS, RDS, API Gateway, CloudFront, Auto Scaling y ElastiCache descubiertos por Architecture eran rechazados de plano por la restricción de tipo de recurso, así que nunca aparecían en Observability ni siquiera como inventario. Ahora se almacenan y correlacionan como cualquier otro recurso.
Las instancias EC2 ahora reportan CPU, red entrante y saliente, y chequeos de estado fallidos. Los buckets S3 reportan almacenamiento usado y cantidad de objetos, pedidos al ritmo diario al que esas métricas realmente se publican.
Estas lecturas vienen de CloudWatch, que cobra por solicitud, así que cada recurso es una sola llamada que lleva todas sus métricas, el presupuesto mensual de solicitudes AWS se reserva antes de gastarlo, y una llamada fallida igual reporta lo que gastó. La confirmación de recolección indica explícitamente que estas lecturas son facturables.
Los recursos de un tipo sin objetivo medible — un security group también es un recurso "EC2" — se reportan como inventario sin contactar nunca a CloudWatch.

Corregido: importar recursos descubiertos descartaba silenciosamente sus relaciones

Desde que los recursos ya presentes en un proyecto dejaron de ser seleccionables, cualquier relación que conectara un recurso recién seleccionado con uno de ellos se descartaba al importar: una relación solo se importa cuando ambos extremos viajan con ella. Por eso los Deployments no aparecían enlazados a sus Pods en el canvas aunque el discovery sí encontraba esos vínculos.
Los recursos que ya están en el proyecto ahora se envían como contexto, de modo que esas relaciones sobreviven. Reenviarlos es idempotente: el servidor los fusiona con los nodos existentes por identidad en vez de duplicarlos.
Lo mismo ocurría con las importaciones de AWS y se corrige igual. AWS ahora además recalcula qué recursos ya están presentes en el momento de importar, en lugar de confiar en un preview que pudo cachearse antes de que se agregaran.

Architecture: los nodos del clúster ahora se identifican como las instancias en la nube donde corren

Los recursos EC2 que CloudFormation descubre para un clúster EKS son security groups, reglas y launch templates — nunca las instancias en ejecución, porque las instancias de un node group las crea su Auto Scaling group en tiempo de ejecución. Las instancias reales son los nodos del clúster.
Los nodos descubiertos ahora llevan su id de instancia, zona de disponibilidad, tipo de instancia y, cuando el contexto nombra la cuenta explícitamente (un ARN de contexto EKS), su ARN de EC2. Ese ARN es lo que permite que un nodo en ejecución se correlacione con la misma instancia vista desde AWS.
Cuando la cuenta no se puede determinar, la identidad de la instancia igual se registra pero no se inventa ningún ARN.

Observability: una vista de Relaciones para revisar las conexiones descubiertas

Las relaciones descubiertas que esperaban una decisión solo se contaban, nunca se mostraban: no aparecían en Topology y la única forma de actuar sobre ellas era abrir el canvas de Architecture. Observability ahora tiene una pestaña Relaciones que lista cada una con sus dos extremos, su tipo, la evidencia que la respalda y su estado, con acciones Aceptar y Rechazar. Funciona igual para AWS y Kubernetes, porque lee del registro compartido.
Aceptar o rechazar desde Observability registra exactamente la misma decisión que el canvas de Architecture, así que las dos vistas nunca pueden contradecirse.
Las relaciones cuya evidencia declara el propio recurso — un Ingress que nombra su Service, una coincidencia de selector, el nodo donde está agendado un Pod — ahora se confirman automáticamente en vez de pedir una decisión que solo tiene una respuesta sensata. Todo lo inferido por nombres sigue esperando revisión, y una decisión ya tomada por una persona nunca se sobrescribe.
Las relaciones existentes se reevalúan en la siguiente reconciliación, así que activar esto no obliga a reimportar todo.
"Relaciones divergentes" ahora es "relaciones por revisar", que es lo que siempre significó: a diferencia de los recursos divergentes, no son un problema a corregir sino una decisión a tomar. El contador ahora es un acceso directo a la nueva vista.

Observability: la confirmación de recolección ahora también describe Kubernetes

Confirmar una recolección solo describía Lambda: a una aplicación compuesta íntegramente por recursos Kubernetes se le pedía confirmar "Funciones Lambda: 0" y un presupuesto de lecturas AWS que esa recolección ni siquiera consume.
La confirmación ahora lista lo que realmente se va a leer, desglosado por tipo de recurso (Deployments, Pods, Services, Ingresses, nodos), y aclara que una recolección de Kubernetes solo lee del clúster y nunca toca el presupuesto de lecturas de AWS. Los detalles de Lambda se muestran solo cuando la aplicación realmente tiene funciones Lambda.
Su descripción también estaba desactualizada: el uso de Kubernetes ahora puede venir de Prometheus, y el inventario de los Ingress de la API de Kubernetes.

Corregido: los Secrets y ConfigMaps generaban un error de recolección en cada ejecución

El colector se invoca para cada recurso Kubernetes de una aplicación, pero solo los workloads, Pods, Services, Ingresses y nodos tienen algo que medir. Un Secret o ConfigMap generaba un error de "kind no soportado" por cada uno, en cada ciclo de recolección.
Esos kinds ahora se reportan como solo topología, igual que los tipos de recurso de otros proveedores que ningún colector soporta.

Observability: volumen de logs por workload, y menos espacio desperdiciado en recursos sin métricas

Los Deployments, StatefulSets, DaemonSets y Pods ahora reportan cuánto log están escribiendo en disco, leído desde Prometheus. Esto responde una pregunta que la API de métricas de Kubernetes nunca pudo, y se recolecta incluso cuando el uso vino de un Metrics Server.
Si el clúster no tiene Prometheus, el volumen de logs simplemente se omite: una recolección nunca falla por eso, y el clúster se sondea una sola vez en lugar de una vez por recurso en cada ejecución.
Los tipos de recurso sin colector de métricas (Secrets, ConfigMaps y cualquier tipo futuro) ya no ocupan una sección completa cada uno. Ahora se resumen en una sola línea compacta, dejando el espacio a los recursos que sí reportan algo.
Se evaluó agregar métricas de requests de los Ingress y deliberadamente no se hizo: este clúster no tiene ningún ingress controller instrumentado en Prometheus, y los conteos de requests de los balanceadores viven en CloudWatch, que es facturable. Los Ingress siguen reportando su inventario de ruteo en vez de números que habría que inventar.

Observability: los nodos del clúster, los Ingress y los Pods ahora reportan sus propias métricas

Los nodos del clúster ahora se descubren como recursos y reportan CPU en uso, memoria en uso, Pods alojados y su capacidad de CPU/memoria, leídos del Prometheus que ya corre en el clúster. Los Pods quedan enlazados en el diagrama al nodo que los ejecuta.
Los Ingress ahora reportan su inventario de ruteo (reglas, rutas, hosts y hosts con TLS) leído desde la API de Kubernetes. El tráfico del ingress controller deliberadamente no se reporta, porque no hay garantía de que algún controller esté siendo recolectado por Prometheus e inventar esos números sería engañoso.
Los Pods ahora se recolectan directamente en vez de fallar: antes cada Pod de una aplicación generaba un error de tipo no soportado en cada recolección.
Listar los nodos del clúster requiere un permiso a nivel de clúster que muchos roles no tienen. Cuando se deniega, el discovery ahora degrada esa capacidad y conserva todo lo demás, en vez de hacer fallar todo el escaneo de Kubernetes.
Cada sección de recursos ahora comienza con cuántos recursos de ese tipo tiene la aplicación, y ya no repite contadores que no le corresponden: los Pods muestran uso y reinicios en vez de un par listos/total que solo repetía la propia sección, y los Services muestran los Pods a los que enrutan en vez de duplicar la CPU y memoria de su workload.

Observability: los KPI y gráficos ahora se organizan por tipo de recurso

El Overview mostraba una única fila plana de KPI y una sola grilla de gráficos, fijada a Lambda y Kubernetes. Ahora las métricas se agrupan en una sección por tipo de recurso — y por kind de Kubernetes (Deployments, Pods, Services, Ingresses...) — cada una con sus propios KPI, gráficos y conteo de recursos.
Las series de métricas ahora se pueden pedir filtradas por tipo de recurso y kind de Kubernetes, para que un gráfico muestre solo los recursos a los que corresponde en vez de un único total del clúster.
Los tipos de recurso que Architecture ya descubre pero para los que aún ningún colector reporta métricas (S3, SQS, SNS, DynamoDB, Ingresses, ConfigMaps, recursos de GCP y Vercel) ahora se listan explícitamente con una nota que aclara que solo se correlacionan para la topología, en vez de omitirse en silencio.
Qué métricas corresponden a cada tipo de recurso ahora vive en un único catálogo independiente del proveedor, así que agregar métricas de EC2, Cloud SQL o cualquier proveedor futuro es una entrada en ese catálogo en vez de cambios repartidos por las vistas de Observability.
Los KPI de uso de Kubernetes ya no afirman que su fuente siempre es metrics.k8s.io, dado que el uso ahora puede provenir de Prometheus.

Corregido: el uso de CPU/memoria de Kubernetes nunca llegaba realmente a Prometheus

Cuando un clúster no tiene Metrics Server, el uso de CPU/memoria de Kubernetes en Observability recurre a consultar un Service de Prometheus descubierto — pero ese respaldo siempre fallaba en un clúster real (reportado silenciosamente como "Métricas no disponibles"), aunque ese mismo Prometheus ya era alcanzable desde el panel de detalle del recurso.
El colector armaba la solicitud proxy a Prometheus a través de un helper del cliente de Kubernetes que codifica toda la ruta de la consulta PromQL como un único segmento de URL, corrompiéndola antes de que llegara al clúster. Ahora arma la solicitud proxy directamente, de la misma forma comprobada que ya usa el panel de detalle del recurso.
Las gráficas de CPU y memoria de Kubernetes y el resumen "CPU promedio"/"Memoria promedio" ahora se completan correctamente para clústeres que dependen de Prometheus en lugar de Metrics Server.

Corregido: recursos Kubernetes duplicados entre Architecture y Observabilidad

Una aplicación Kubernetes alojada en AWS (por ejemplo EKS) guarda aws como proveedor del recurso para sus workloads, mientras que el adaptador Kubernetes de Architecture siempre usaba kubernetes. El registro compartido trataba esto como dos recursos distintos, por lo que el mismo Deployment podía aparecer dos veces — una vez desde APM y otra desde Architecture — en la tabla de recursos de Observabilidad y en el registro.
Los nodos de discovery Kubernetes ahora llevan una clave estable contexto/namespace/kind/nombre (la misma que APM ya usa para workloads agregados manualmente o descubiertos por EKS), y cada lugar que convierte un recurso APM en nodo del grafo (o viceversa) ahora normaliza el proveedor a kubernetes en lugar de confiar en la nube donde corre la aplicación.
Los duplicados existentes se autocorrigen en la próxima reconciliación del registro compartido (colección automática, reconciliación manual o cualquier cambio de recurso en APM/Architecture) — no se requiere migración manual de datos.
Se generalizó la corrección como regla reutilizable: el proveedor de un recurso ahora siempre se deriva de lo que el recurso realmente es (resourceOwnProvider en applicationRegistryService.js), nunca se hereda de la nube donde corre su aplicación, tanto para la proyección APM→Architecture como Architecture→APM.

Architecture Fase 9: persistencia del contexto de aplicación

El contexto activo de la KUA Application (aplicación, proyecto, proveedor y perfil) ahora persiste en almacenamiento local y se restaura al recargar, por lo que recargar la ventana ya no pierde la aplicación Architecture seleccionada.
El perfil de Architecture ya no fuerza el selector global de perfil AWS cuando la aplicación ya tiene su propio perfil (por ejemplo, una aplicación solo Kubernetes); solo recurre a él cuando no hay ninguna aplicación activa.

Architecture Fase 10: navegación a nivel de recurso

El inspector de nodos del Canvas ahora expone acciones de navegación contextuales: los workloads/Pods de Kubernetes pueden abrir sus logs, el detalle YAML/métricas (reutilizando el panel de detalle Kubernetes existente) y la lista de Pods propios; los nodos Lambda, EC2, EventBridge y Step Functions de AWS pueden abrir los logs de Lambda o saltar directamente a la pestaña de AWS correspondiente filtrada por nombre.
Los tipos de recurso no soportados no muestran sección de navegación en lugar de una acción rota o vacía.

Architecture Fase 11: overlay de salud en el Canvas

El Canvas suma un toggle opcional "Health" que muestra una insignia en cada nodo: degradado/saludable para workloads y Services Kubernetes usando la salud ya capturada durante el discovery, y una insignia de obsoleto para recursos ausentes en la última sincronización.
La preferencia del overlay persiste junto con el resto de la vista del canvas y no altera el layout del diagrama, manteniendo legibles los diagramas densos cuando está desactivado.

Architecture Fase 12: vista canónica de Resources

Architecture suma una pestaña "Resources" que lista el registro compartido de la KUA Application enlazada: proveedor, tipo de recurso, scope/ubicación, fuentes que lo confirman (APM, Architecture o ambas) y cantidad de relaciones.
Los recursos confirmados desde un solo lado (APM o Architecture) se marcan como divergencia de fuente única en vez de fusionarse silenciosamente.
El estado operativo reutiliza la señal de salud/obsolescencia de la Fase 11 ya disponible en el nodo del grafo Architecture, sin una nueva canalización de telemetría.
El endpoint del registro compartido (GET /apm/applications/:id/registry) ahora informa qué fuentes confirmaron cada recurso.

Architecture Fase 13: menos revisiones sorpresa por la reconciliación del registro compartido

Reconciliar el registro compartido tras una operación de Architecture podía generar hasta dos revisiones adicionales del grafo sobre el guardado propio del usuario (una por proyectar recursos APM faltantes al grafo, otra por sellar los ids de correlación del registro). Ambas mutaciones ahora se fusionan en un solo documento de trabajo y se guardan como máximo una vez, por lo que una acción del usuario produce como máximo una revisión derivada en vez de hasta dos.

Architecture Fase 14: diagnóstico visible de sincronización del registro compartido

Cada reconciliación del registro compartido (manual o automática) ahora persiste un diagnóstico: hora y duración de la última sincronización exitosa, último error, y cuántos recursos/relaciones están confirmados desde un solo lado (APM o Architecture).
La vista de aplicación de Observability ahora muestra este diagnóstico como una franja de estado persistente en vez de un aviso puntual, con una acción "Retry sync" que reutiliza el endpoint de reconciliación existente.
Una sincronización fallida ya no borra la última sincronización exitosa conocida ni sus conteos de divergencia.

Architecture Fase 15: Routes con sus propios filtros de proveedor/contexto/namespace

Routes ya respetaba los filtros persistidos de proveedor/contexto/namespace del Canvas, pero solo el Canvas podía cambiarlos. Routes ahora tiene los mismos controles de filtro en su propia barra de herramientas, escribiendo al mismo estado de vista compartido, sin necesidad de cambiar a Canvas para acotar las rutas.

Architecture Fase 16: sugerencias de relaciones deterministas basadas en logs

Los nodos de workload/Pod Kubernetes suman una acción "Suggest relationships from logs" que analiza el stream de logs ya abierto en busca de referencias DNS internas (servicio.namespace.svc.cluster.local) y propone relaciones calls hacia los nodos Kubernetes coincidentes del mismo diagrama.
La extracción es completamente determinista (sin IA/ML) y se sanitiza antes de guardarse como evidencia: primero se redactan patrones comunes de secretos (encabezados Authorization, tokens, API keys, contraseñas), y solo se conserva una muestra corta más un conteo de ocurrencias, nunca el log crudo completo.
Cada sugerencia se agrega con status: suggested y confianza menor a 1, pasando por el mismo flujo de revisión de aceptar/rechazar que ya se usa para el discovery automático — nada se agrega al grafo sin confirmación humana explícita.
La librería de extracción también agrupa firmas de errores recurrentes y recolecta ids de correlación/request/trace distintos para fases futuras, sin persistir ni mostrar el contenido crudo del log más allá de la vista de terminal existente.

v1.14.1 (2026-08-26)

Reconciliación de recursos AWS heredados

La reconciliación de Architecture ya no falla cuando un nodo AWS legado no incluye provider; usa el provider de la KUA Application enlazada.
Los nodos AWS con ARN recuperan automáticamente cuenta y región para compartir una identidad única con el recurso APM, evitando duplicados en el registro.
Los nodos incompletos no proyectables se omiten de forma segura y se agregó una prueba de regresión para aplicaciones serverless como syn agent-call.

v1.14.0 (2026-08-26)

Recursos compartidos y análisis de topología AWS

El análisis de topología AWS ahora separa recursos y relaciones AWS de las membresías Kubernetes mixtas, conservando la topología completa de la aplicación en la respuesta.
La resolución de referencias AWS es segura ante datos incompletos y las funciones y state machines serverless de CloudFormation/SAM conservan su semántica Lambda/Step Functions.
El discovery Architecture deriva la cuenta AWS desde los recursos del preview cuando el scope seleccionado no la entrega.
Las aplicaciones enlazadas ahora reconcilian recursos observables en ambos sentidos: los recursos agregados en APM aparecen en una vista Architecture existente y los nodos compatibles AWS/Kubernetes/GCP/Vercel de Architecture se proyectan en APM sin duplicarse.
Los proveedores Kubernetes se persisten explícitamente cuando es necesario, y las membresías proyectadas desde Architecture se eliminan al retirar su nodo de origen.
Se agregó cobertura de regresión para análisis mixto AWS/Kubernetes, proyección bidireccional, normalización serverless y migración de esquema a v1.14.

v1.13.0 (2026-08-26)

Workspace Architecture centrado en la aplicacion

Architecture ahora carga y muestra primero el catalogo de KUA Applications, selecciona la aplicacion activa y limita sus vistas Architecture a esa aplicacion.
El workspace Architecture ahora expone juntos identidad, proveedor, entorno, equipo, scopes activos y estado del enlace junto con la revision del diagrama.
Crear o refrescar una vista Architecture conserva el applicationId seleccionado; los proyectos heredados sin enlace siguen disponibles como ruta de compatibilidad.

v1.12.0 (2026-08-26)

Endurecimiento del shell de KUA Application

Architecture ahora acepta un contexto de aplicacion, acota la carga de proyectos a la KUA Application enlazada y vincula los proyectos nuevos con esa aplicacion.
Architecture y Observability exponen navegacion reversible para aplicaciones Kubernetes genericas y proveedores cloud, con un contexto compartido que muestra identidad, entorno y equipo.
La conciliacion del registro ahora se ejecuta despues de eliminar proyectos, desenlazar, restaurar snapshots y otras mutaciones del grafo, eliminando membresias y relaciones Architecture obsoletas.
Los nodos Kubernetes heredados se normalizan desde su kind nativo, evitando que Deployments, Services, Pods y otros recursos existentes se rendericen como clusters genericos.
Los filtros persistidos de proveedor, contexto y namespace ahora se aplican tanto en Canvas como en Routes, y el control GitHub usa el SVG incluido sin avisos de Lucide.

Architecture Fase 8: Base del Adaptador Kubernetes (2026-08-26)

La vista Routes ahora es neutral al proveedor: conserva los caminos APL de eventos/workflows y agrega caminos de Microservicios para flujos Kubernetes Ingress -> Service -> Pod y sus dependencias declaradas de configuracion o almacenamiento.
La evidencia de rutas Kubernetes sigue siendo declarada y explicable. El futuro analisis frecuente de logs producira sugerencias observadas, acotadas por privacidad y sujetas a revision, nunca relaciones automaticas desde texto de logs crudo.
El preview Kubernetes de Architecture ahora acepta uno o varios filtros de namespace y agrupa los recursos seleccionables por tipo, con seleccion por grupo para workloads, Pods, Services, Ingress, ConfigMaps, Secrets y persistent volumes.
Los diagramas Kubernetes ahora usan un tratamiento visual dedicado para el cluster e iconos distintos para workloads, Pods, Services, Ingress, ConfigMaps, Secrets y persistent volume claims.
El discovery Kubernetes incluye el enrutamiento de Services e Ingress, mas solo los ConfigMaps, Secrets y PVCs referenciados explicitamente por entorno o volumen del workload; estas dependencias se dibujan con relaciones uses basadas en evidencia.
Architecture ahora admite recursos manuales explicitos junto al discovery: se pueden agregar instancias EC2 o cualquier componente AWS, ademas de recursos Kubernetes, GCP o Vercel, registrando proveedor, identidad nativa estable, ambito y ubicacion en el grafo.
Architecture ahora usa un unico menu Add resources en lugar de una accion solo AWS: los previews e imports AWS y Kubernetes estan disponibles hoy, mientras GCP y Vercel aparecen como adaptadores de proveedor planificados.
El discovery Kubernetes de Architecture lista contextos, previsualiza un contexto seleccionado explicitamente con salud y evidencia de relaciones, e importa solo los recursos confirmados y sus relaciones internas en una revision del grafo.
Las aplicaciones con recursos Kubernetes confirmados ahora actualizan automaticamente su preview de topologia acotado despues de cargar, consultando solo sus contextos configurados; al abrir el preview se reutiliza ese resultado.
Al crear una vista Architecture desde Observability, el nuevo diagrama ahora incluye los recursos y dependencias confirmados de la aplicacion en lugar de abrir un grafo vacio.
Observability Kubernetes ahora usa como fallback un Service Prometheus detectado dentro del cluster para el uso agregado de CPU y memoria de Pods cuando metrics.k8s.io no esta disponible, conservando cursores de reinicios estables entre fuentes.
Las senales de disponibilidad, total y reinicios de Pods ahora permanecen completas cuando metrics.k8s.io no esta disponible; Observability identifica explicitamente que solo faltan los datos de uso de CPU y memoria.
Observability ahora deriva KPIs, graficas, analisis cloud y controles de trazas desde las capacidades de recursos confirmados, por lo que las aplicaciones solo Kubernetes no muestran senales Lambda ni analisis exclusivos de AWS.
Los Pods, Deployments, StatefulSets y DaemonSets Kubernetes configurados ahora exponen su streaming de logs existente directamente desde Observability, cambiando al contexto Kubernetes asociado antes de resolver los Pods del workload.
La configuracion de Observability ahora carga los clusters Kubernetes compatibles antes de detectar workloads y consulta solo el cluster EKS elegido explicitamente, con estados separados para carga de clusters y workloads.
El flujo de configuracion trata Kubernetes como un ambito explicito de la aplicacion y reutiliza una seleccion de contexto segun proveedor preparada para GKE y conexiones Kubernetes generales, sin cambiar las reglas de membresia confirmada.
El preview de topologia Kubernetes ahora lista primero los clusters compatibles y exige seleccionar uno antes de consultar workloads, Services, Ingress y eventos, evitando escaneos innecesarios de varios clusters.
Nuevo feedback visible de carga mientras KUA lista clusters y mientras lee los recursos Kubernetes del cluster elegido.
Nuevo adaptador Kubernetes de topologia solo lectura con identidades estables de contexto, namespace y UID para workloads, pods, Services e Ingress.
Los previews Kubernetes ahora aportan evidencia declarada de selectores e Ingress, senales de salud de workload/pod, resumenes de eventos Warning y capacidades por contexto que se degradan de forma segura si una API no esta disponible.

Base de Architecture Fase 6 (2026-08-26)

Nuevo registro compartido neutral al proveedor para recursos, membresias y relaciones de KUA Application, basado en identidades estables y conservando el linaje de cada fuente por separado.
Nueva conciliacion explicita de datos APM y Architecture enlazados, que proyecta identificadores de correlacion a nodos y relaciones sin mover buckets metricos, cursores ni trazas de sus almacenes locales actuales.

Base de Architecture Fase 5 (2026-08-26)

Nuevo enlace reversible y aislado por perfil entre una aplicacion de Observability y un proyecto Architecture existente o nuevo, sin mover recursos, metricas, trazas ni datos del grafo.
Observability ahora muestra la cobertura del enlace Architecture, recursos sin correspondencia y advertencias de identidad duplicada, y abre el diagrama enlazado exacto en una accion.

Inicio de Architecture Fase 4 (2026-08-26)

Nueva aplicacion autoritativa de sync CloudFormation con una revision atomica del grafo, proteccion optimista expectedRevision, metadata de stacks seleccionados e identidades estables conservadas.
La revision de sync ahora muestra recursos concretos por categoria, conserva decisiones manuales y relaciones rechazadas, marca como stale los recursos ausentes y permite restaurarlos o eliminarlos explicitamente.
Nuevo plan de Gestion Unificada de KUA: define KUA Application como limite compartido entre APM y Architecture y ordena la migracion hacia un workspace de aplicaciones neutral al proveedor.
Nuevo contrato de fase 4 para sincronizacion autoritativa CloudFormation, ciclo de vida stale, metadata de sync y revision de relaciones.
Primer hito documentado como una revision segura de sync CloudFormation que compara fuentes de stacks seleccionados antes de aplicar una sola revision del grafo.
Primer endpoint read-only de sync preview AWS, clasificando recursos y relaciones CloudFormation seleccionados como nuevos, modificados, sin cambios, ausentes, stale, manuales, reforzados o rechazados sin mutar el grafo.
Nuevo panel de sync preview en el workspace Architecture para revisar fuentes CloudFormation existentes y resumir cambios de recursos y relaciones antes de implementar el flujo de apply.

Cierre de Architecture Fase 3 (2026-08-25)

El redescubrimiento ahora reconcilia identidades AWS actuales e historicas sin duplicar nodos y remapea relaciones, grupos y posiciones al ID conservado.
Las decisiones manuales y relaciones rechazadas siguen prevaleciendo al importar de nuevo los mismos recursos y evidencias.
El modo de orden del Canvas, su direccion y la preferencia de etiquetas ahora se guardan en el grafo versionado, se restauran al recargar y aparecen en comparaciones de snapshots.
El discovery AWS ahora indica si se cargan stacks CloudFormation o se analizan recursos y evidencias, con una espera visible durante lecturas demoradas.
Los proyectos Architecture ahora se pueden eliminar explícitamente, incluyendo su grafo local, snapshots e historial de revisiones.
Un redescubrimiento real de los tres stacks AFEX conservó 119 nodos sin duplicados y registró nueva evidencia de relaciones disponible.
Las versiones de capas Lambda ahora se modelan como capas con el nombre de la capa, en lugar de funciones cuyo nombre era una versión numérica.
Los permisos Lambda de API Gateway se consolidan como evidencia de ruta a Lambda, en vez de nodos policy repetidos; al seleccionar una Lambda se muestran sus rutas API, permisos y la identidad CloudFormation.
Nuevo contrato bilingue de fase con criterios de aceptacion explicitos; la sincronizacion autoritativa queda diferida a fase 4.
Validacion de cierre aprobada: 118 pruebas backend, 374 pruebas frontend, build de produccion y build de documentacion VitePress.

Base del espacio Architecture

Nuevo espacio Architecture aislado por perfil para diagramas de aplicaciones, inicialmente orientado a AWS.
Nuevo modelo de grafo independiente del proveedor para ámbitos, fuentes, nodos, relaciones, grupos, evidencia y layout persistente.
Nuevo almacenamiento privado architecture.sqlite3 con WAL, revisiones optimistas del grafo, snapshots inmutables y cierre seguro del servidor.
Nuevas APIs aisladas por perfil para crear proyectos, leer y actualizar borradores del grafo, y crear o consultar snapshots.
Primer workspace Vue para crear proyectos, consultar el resumen del grafo y mantener historial local de snapshots.
Nuevas operaciones tipadas del grafo con limpieza en cascada, control optimista de revisiones e historial semántico de cambios.
Comparación y restauración transaccional de snapshots, creando siempre una nueva revisión y un snapshot inmutable sin reescribir el historial.
Nuevos controles del workspace para comparar snapshots, restaurar estados anteriores y consultar el historial reciente de revisiones.
Nuevo canvas interactivo con Vue Flow para crear, conectar, mover, editar y eliminar componentes de arquitectura manualmente.
Las interacciones del canvas persisten mediante operaciones tipadas, incluyendo cambios de layout registrados sólo al terminar cada movimiento.
Nuevo discovery AWS de sólo lectura para deployments CloudFormation activos y servicios ECS, aislado por perfil/región y con estimación de requests.
Nuevo flujo de preview y confirmación en dos pasos: KUA nunca preselecciona recursos y los recursos confirmados se importan atómicamente con sus relaciones inferidas.
Nuevas sugerencias de relaciones con evidencia desde referencias CloudFormation DependsOn, Ref, GetAtt y Sub, incluyendo sintaxis YAML abreviada.
Las relaciones inferidas se clasifican como automáticas o sugeridas según el umbral de confianza del proyecto, conservando su confianza y evidencia de origen.
Nuevas acciones explícitas para aceptar o rechazar relaciones; las decisiones revisadas se conservan al redescubrir y las relaciones rechazadas permanecen en el historial canónico aunque se oculten del canvas.
Nueva semántica AWS para targets de EventBridge, definiciones Step Functions y ubicación de servicios ECS, además de relaciones directas SQS a Lambda inferidas desde event source mappings de CloudFormation.
Nuevo inventario regional directo para Lambda, EventBridge y Step Functions, usando los stacks CloudFormation como enriquecimiento opcional en lugar de exigirlos para el discovery.
Los recursos AWS conectados ahora se identifican como aplicaciones candidatas mediante evidencia de targets EventBridge y ASL, listas para selección explícita; los previews truncados al límite de 500 recursos se informan claramente.
Las aplicaciones identificadas ahora se dibujan directamente con una acción: el preview validado se reutiliza durante cinco minutos, el panel de discovery se cierra después de importar y los diagramas grandes reciben un layout adaptativo más ancho.
Nuevo discovery regional directo de event source mappings de Lambda para completar rutas SQS a Lambda sin depender de CloudFormation.
Nuevo diagrama APL con modos Secuencia de eventos, Nombre A-Z, Event bus, Flujo de servicios y Ruta más larga; el orden se aplica a entradas y ramas preservando caminos con relaciones distintas.
Los nuevos proyectos Architecture ahora abren una configuración guiada CloudFormation-first: elegir deployments, confirmar recursos inferidos y revisar el diagrama, con inventario regional como alternativa explícita.
Los recursos Step Functions ahora abren su diagrama ASL interno configurable desde Routes o Canvas, mientras la composición del candidato indica qué aplicaciones contienen workflows y otros tipos de recursos AWS.
Architecture ahora puede mapear todos los recursos de los stacks CloudFormation seleccionados explícitamente, incluyendo recursos aislados y servicios AWS antes no soportados, sin ampliar el contrato de recursos de APM.
La evidencia CloudFormation ahora identifica notificaciones S3, asociaciones de roles y policies IAM, roles usados por workloads, permisos Lambda y recursos gobernados mediante relaciones semánticas específicas.
El Canvas puede ordenar el curso de solicitudes horizontal o verticalmente mediante niveles causales persistidos y reducción de cruces; los diagramas densos parten de un zoom legible, con etiquetas opcionales e iconos AWS reconocibles.
Los métodos API Gateway y rutas HTTP API ahora muestran su método y path resueltos, conservan evidencia directa de ruta a Lambda y exponen referencias navegables en el inspector del Canvas.
Al seleccionar un componente, el Canvas ahora lo centra con zoom legible y atenúa nodos y relaciones no vinculados, manteniendo visibles las dependencias directas en topologías densas.
Al limpiar la selección del Canvas ahora se restaura explícitamente la visibilidad completa de todos los nodos y relaciones, incluso cuando Vue Flow haya mutado sus estilos internos.
Nuevo modo de orden por tipo de recurso con secciones etiquetadas y contador, rejillas deterministas, posiciones persistidas y conectores rectos tenues para diagramas grandes.
El discovery Architecture consume el presupuesto AWS existente por perfil; las plantillas se analizan localmente y nunca se persisten ni se devuelven al frontend.
Cobertura backend y frontend para validación del grafo, inmutabilidad de snapshots, conflictos de revisión, aislamiento por perfil y comportamiento del store.

v1.11.3 (2026-08-11)

Hotfix de empaquetado macOS

Se corrigió el paquete de macOS Intel que incluía el binario nativo ARM64 de better-sqlite3, lo que impedía iniciar el backend después de instalar la aplicación.
Los artefactos macOS x64 y ARM64 ahora se generan en procesos aislados y secuenciales para impedir que una dependencia nativa sea reemplazada mientras se archiva otra arquitectura.
Se agregaron validaciones de arquitectura para el ejecutable Electron y el módulo nativo SQLite dentro de ambos ZIP finales antes de publicar un release.
Se conserva un manifiesto de actualización macOS combinado con los artefactos ZIP/DMG para x64 y ARM64.

v1.11.2 (2026-08-11)

APM multicloud y sin proveedor

Se extendió la observabilidad de aplicaciones desde AWS a ámbitos aislados para AWS, GCP y Vercel, más un ámbito General sin proveedor para aplicaciones Kubernetes.
Observabilidad ahora forma parte de la navegación principal e incluye edición, eliminación, gestión de recursos y configuración según el proveedor.
Se agregaron migraciones SQLite por columnas explícitas para aplicaciones y recursos por proveedor, conservando de forma segura los datos APM existentes.
Nuevas guías bilingües de credenciales para AWS, GCP, Vercel y Kubernetes, con persistencia de perfiles corregida y carga diferida por proveedor.

Inteligencia de topología explicable

Nuevo evaluador estructural local con puntuación, cobertura conectada, detección de recursos aislados, hallazgos y sugerencias de dependencia explicables.
Las relaciones genéricas related_to se informan por separado y no cuentan como causalidad operacional.
Nuevo análisis AWS explícito y de solo lectura para las definiciones de Step Functions asociadas.
El análisis ASL reconoce invocaciones Lambda directas y optimizadas, subflujos Step Functions, envíos SQS, tareas ECS y operaciones SDK de S3.
Las referencias ASL externas siguen siendo sugerencias: el usuario debe agregar el recurso, analizar nuevamente y confirmar la dependencia. KUA nunca crea relaciones causales automáticamente.

Requests de procesos y trazas de ejecución

Nueva pestaña AWS Trazas que acepta request/correlation ID, ARN de ejecución o ARN de una Step Function asociada.
Al pegar el ARN de una Step Function se muestran hasta 10 ejecuciones recientes y se traza la última; luego se puede seleccionar directamente cualquier ejecución de la lista.
El historial de Step Functions genera un timeline ordenado con Lambda, ECS, S3, subflujos, estados, duración y evidencia de fallos.
Nueva opción explícita Mostrar request/response sanitizados para entradas, parámetros, salidas, errores y causas de la ejecución y de cada paso.
Los campos habituales de credenciales y datos personales se ocultan, strings y arrays grandes se limitan, los payloads se solicitan sólo bajo demanda y las trazas nunca se persisten.
Todas las lecturas de trazas y topología permanecen limitadas a recursos asociados y consumen el presupuesto AWS por perfil. KUA no invoca workloads productivos ni habilita logging automáticamente.

Correcciones Vercel y estabilidad

Se actualizaron rutas y versiones API de Vercel, se conservaron errores upstream y se soportan las respuestas Cron actuales y antiguas.
Se corrigieron textos por proveedor, manejo de perfiles, comportamiento de Env Manager y presentación de recursos en las vistas multicloud.
Se agregó cobertura backend y frontend para migraciones, scoping, extracción ASL, evaluación de topología, trazas, sanitización, compatibilidad Vercel y perfiles.

v1.11.0 (2026-08-06)

Observabilidad local de aplicaciones

Nuevo espacio de aplicaciones por perfil para recursos Lambda, Kubernetes, SQS, EventBridge, Step Functions y ECS confirmados explícitamente.
Discovery read-only de despliegues CloudFormation y ECS con preview antes de importar. KUA nunca selecciona candidatos ni crea dependencias automáticamente.
Almacén privado SQLite con agregados UTC de 30 minutos, umbrales locales, cursores de recolección, historial de ejecuciones, retención y health checks.
Colectores Lambda y Kubernetes con paginación reanudable, deduplicación, estados parciales y captura oportunista de métricas ya cargadas en la interfaz.
Topología manual por aplicación, umbrales de salud configurables, tendencias locales e historial de métricas aislado por perfil.

EKS Container Insights

Nuevo dashboard de observabilidad EKS basado en consultas read-only a CloudWatch Container Insights.
Las métricas se pueden agrupar por namespace, workload, pod o nodo, mostrando contexto del clúster y sus node groups junto a las series.
La recolección informa cuando Container Insights no está disponible o devuelve datos parciales, sin provisionar agentes, dashboards, alarmas ni otros recursos AWS.

Controles de coste y privacidad

El polling automático APM permanece desactivado por defecto y la recolección se habilita explícitamente por aplicación.
Límite local estricto de 100.000 lecturas AWS por perfil y mes calendario.
KUA almacena sólo identificadores confirmados, configuración, cursores, contadores, estado de recolección y agregados. No persiste líneas de CloudWatch Logs, payloads, credenciales, secretos, variables de entorno ni tags arbitrarios.
Los buckets, cursores y ejecuciones expiran a los 90 días; los registros de presupuesto expiran a los 15 meses.

Estabilidad de refresco y terminal

Refresco silencioso y estable cada 5 segundos para Kubernetes, AWS, GCP y Vercel, pausado cuando la ventana está oculta.
Cachés en memoria stale-while-revalidate para listados cloud y Kubernetes, invalidadas después de mutaciones y cambios de contexto.
El refresco en segundo plano conserva la identidad de datos sin cambios e ignora respuestas obsoletas después de navegar entre recursos.
Terminal Logs conserva hasta 5.000 líneas, renderiza ventanas de 1.000, permite pausar/reanudar el seguimiento y seleccionar un pod individual para logs de workloads.

Compatibilidad runtime y Kubernetes

Reparación idempotente de módulos nativos para better-sqlite3, soporte de unpack/rebuild en Electron, permisos privados para la base y puerto Vite estricto.
Actualización de patches Kubernetes para las firmas actuales del cliente y eliminación de campos administrados por el servidor antes de aplicar YAML editado.
Cierre limpio del scheduler/base APM y health reporting en el backend local.

v1.10.5 (2026-07-07)

Estabilidad de desarrollo y release

Separación de puertos para backend estable (7190), backend de desarrollo/Electron (7192) y frontend Vite (7193).
Workaround en el workflow de release para módulos nativos opcionales que podían fallar durante electron-rebuild multiplataforma.

v1.10.4 (2026-06-22)

OAuth de Vercel Marketplace

Soporte completo para el flujo de integración de Vercel Marketplace: la página de callback ahora maneja configurationId, teamId, next y source además del flujo estándar OAuth con code+state.
Corregido el error "Missing OAuth parameters" que aparecía cuando Vercel Marketplace redirigía al callback sin parámetro state.
Al completar la autorización de Marketplace, la app abre la URL next de Vercel en el navegador para que la integración quede marcada como instalada.
VERCEL_CONFIGURATION_ID y VERCEL_TEAM_ID del flujo Marketplace se persisten en el perfil de credenciales.

v1.10.3 (2026-06-22)

Callback OAuth de Vercel

Se cambió el redirect OAuth de Vercel a la página HTTPS https://lnavarrocarter.github.io/kuadashboard/vercel-callback para completar la autorización sin depender del redirect con protocolo custom.
Se agregó una página de callback con auto-forward que devuelve code y state a la app de escritorio usando el flujo existente de Vercel.
Se agregó soporte para VERCEL_OAUTH_REDIRECT_URI en la configuración runtime para que los builds locales y empaquetados queden alineados con el callback HTTPS.

v1.10.2 (2026-06-22)

AWS — Credenciales temporales + SSO en navegador

Soporte completo para AWS_SESSION_TOKEN en perfiles guardados y resolución de credenciales AWS, habilitando sesiones temporales de STS de extremo a extremo.
Nuevo flujo de autorización por dispositivo de IAM Identity Center (SSO) desde navegador, con selección de cuenta/rol y captura automática de credenciales temporales.
Seguimiento de expiración de sesión SSO y renovación con un clic mediante metadata persistida (meta.__sso).

Seguridad, estabilidad y UX

Restricción a localhost para endpoints de perfiles locales de AWS y bootstrap SSO, evitando exposición remota de configuración local de la estación de trabajo.
Ajuste de sanitización en Env Manager para conservar metadata estructurada reservada en meta.__sso (start URL, región, cuenta/rol y expiración), manteniendo el comportamiento previo de tags para claves normales.
Endurecimiento de apertura de ventana SSO usando noopener,noreferrer.
Normalización de finales de línea en public/index.html para eliminar CR residuales y reducir diffs ruidosos.

Fixes AWS adicionales

Corregido el congelamiento del render de diagramas de Step Functions en máquinas de estado con ciclos, agregando una protección de ciclo en la asignación BFS de niveles (StepFnDiagram.vue).
Corregidos los fallos de ejecución en Athena cuando el workgroup no tiene output location configurado, permitiendo definir un override S3 explícito en el Query Editor y en el modal de consulta por workgroup.

v1.10.0 (2026-06-09)

GCP — Paneles master-detail

Los cuatro servicios principales de GCP estrenan un layout completo de panel dividido: lista de recursos a la izquierda y panel de detalle con tabs a la derecha, coherente con el patrón ya establecido en Cognito, Athena y Lex.

Cloud Run — tabs: Overview (configuración, imagen, escalado), Revisions (con % de tráfico), Variables (vars de entorno), Logs, Metrics.
Compute VMs — tabs: Overview (tags, labels, protección de borrado), Discos, Red (interfaces e IPs), Logs, Metrics.
Cloud SQL — tabs: Overview (backup y disponibilidad), Config (tipo de almacenamiento, flags), Connection (direcciones IP, connection name), Logs, Metrics.
Cloud Functions — tabs: Overview (runtime, recursos, trigger), Variables, Logs, Invoke (inline, reemplaza el modal flotante anterior), Metrics.

GCP — Métricas Cloud Monitoring embebidas

El tab Metrics se incluye ahora en los cuatro paneles de servicio. Muestra tres gráficas de línea (Chart.js) obtenidas desde la API Cloud Monitoring v3, con selector de rango (1h / 3h / 6h / 24h) y botón de actualización.

Servicio	Gráficas
Cloud Run	Request Rate (req/s) · Latency p99 (ms) · Instance Count
Compute VMs	CPU Utilization (%) · Network In (B/s) · Disk Read (B/s)
Cloud SQL	CPU Utilization (%) · Connections · Disk Used (bytes)
Cloud Functions	Execution Count (req/s) · Duration p99 (ns) · Active Instances

GCP — GCS Upload y Delete

Upload: nuevo botón "⬆ Upload" en la barra del GCS Browser. Permite seleccionar múltiples archivos, los sube como binario raw a la carpeta actual y muestra un log de resultado por archivo (✓ / ✗).
Delete: botón "🗑 Delete" en el panel de preview del archivo. Pide confirmación antes de llamar a la nueva ruta DELETE /storage/:bucket/object.

GCP — Artifact Registry Deploy-to-K8s

Artifact Registry se rediseña como panel master-detail con dos tabs:

Packages & Tags — vista en dos columnas: lista de packages a la izquierda y tabla de tags a la derecha. Cada fila de tag Docker tiene un botón 🚀 Deploy.
Deploy to K8s — al pulsar Deploy se rellena automáticamente la referencia completa de imagen (location-docker.pkg.dev/project/repo/pkg:tag). El panel permite seleccionar el Namespace, el Deployment y el Container del cluster Kubernetes activo, muestra un resumen del despliegue y aplica el cambio con un clic.

Integración con Kubernetes

Nuevo endpoint POST /api/:namespace/deployments/:name/set-image: aplica un strategic-merge-patch sobre la imagen de un container específico y escribe una entrada en el audit log.

GCP — Visor de logs mejorado

Las entradas de log en todos los paneles de detalle usan colores según severidad: ERROR/CRITICAL → rojo, WARNING → ámbar, INFO/NOTICE → verde, DEBUG/DEFAULT → tenue.

v1.9.3 (2026-06-09)

AWS Amazon Lex

Rediseño del módulo Lex con un layout master-detail de panel dividido (igual al de Cognito y Athena). El panel izquierdo lista todos los bots con estado, versión y fecha de actualización. Al hacer clic en un bot se abre el panel de detalle a la derecha.
Se eliminaron los 8 botones de acción de colores de cada fila. Toda la funcionalidad (Intents, Aliases, Slot Types, Chat, Logs, Missed, Metrics, Test Set) ahora está accesible mediante la barra de tabs del panel derecho.
Los datos se cargan bajo demanda por tab y se cachean mientras el bot esté seleccionado — cambiar de tab para el mismo bot no provoca una nueva llamada a la API.
Las acciones Chat y Build en el tab de Aliases ahora navegan a sus tabs correspondientes en lugar de abrir modales anidados.

v1.9.2 (2026-06-09)

AWS DynamoDB

Edición de ítems en el modal Browse: cada fila tiene un botón ✏️ que abre un editor JSON pre-llenado con los datos actuales del ítem. Al guardar se ejecuta un PutItem (reemplazo completo) y se refresca la página actual.
Eliminación de ítems por fila: el botón 🗑 extrae automáticamente los campos de la clave primaria desde el key schema de la tabla y pide confirmación antes de llamar a DeleteItem.
Botón New Item en la barra del modal Browse: abre el editor JSON pre-llenado solo con los campos de clave para crear un nuevo registro desde cero.
El editor JSON valida sintaxis en tiempo real y bloquea el guardado si hay errores de parseo.

v1.9.1 (2026-05-28)

AWS Cognito

Búsqueda libre de texto en User Pools sin errores de filtro de AWS.
Edición de atributos de usuario desde el modal de detalle.
Gestión de membresía de grupos desde el detalle de usuario: asignar y quitar grupos.
Controles de MFA por usuario: habilitar, deshabilitar y cambiar método preferido (SMS/TOTP).
Flujo de creación de grupos con soporte de descripción en el tab Groups.
Corrección de error en tiempo de ejecución en el flujo de creación de grupos con HMR.
Corrección del estado MFA en la lista de usuarios alineando el cálculo con los settings de Cognito.

v1.9.0 (Mayo 2026)

Vercel

Integración completa con Vercel mediante autenticación OAuth — conecta tu cuenta directamente desde el modal de perfil.
Vista de proyectos con estado de deployment, framework, región y acceso directo a la URL en vivo.
Detalle de deployments con pestañas de Actividad, DNS Records, Aliases, Cron Jobs, Webhooks, Edge Config y Checks.

AWS Step Functions

Nueva columna Executions en la tabla de Step Functions con conteos en vivo de ejecuciones activas (▶), fallidas (✗) y con timeout (⏱).
Nueva pestaña Versiones en el panel Info — lista todas las versiones publicadas del workflow con fecha, descripción y visor de definición ASL con botón de copia.
Modal Info refactorizado con cinco pestañas: Detalles, Diagrama, Ejecuciones, Eventos y Versiones.

v1.8.0 (2026-05-10)

Kubernetes

Las tablas de recursos ahora soportan seleccion multiple, eliminacion masiva y acciones por fila mas completas.
El menu de Kubernetes cubre mas recursos de workloads, networking, storage, config, policy, RBAC, scheduling, admission y administracion del cluster.
La columna Age muestra duraciones legibles como 1day 3hrs 10min, 23hrs 10min, 2min y 30sec, pero ordena por duracion real transcurrida.
ConfigMaps y Secrets tienen una vista clave/valor mas simple para mapear y editar datos.
Los workloads muestran variables de entorno en el panel de detalle, incluyendo edicion de entradas por contenedor.
El modal de kubeconfig permite importar YAML pegado, cargar un archivo desde el selector desktop o registrar una ruta existente.

Helm

Los charts se pueden buscar desde repositorios configurados e instalar directamente en el cluster activo.
Los releases instalados se pueden listar y desinstalar desde la vista Helm.
Las instalaciones muestran progreso, salida y estado final del release en lugar de dejar la UI esperando sin contexto.
La instalacion de metrics-server incluye un preset de compatibilidad para clusters locales o self-signed, con flags de TLS de kubelet y tipos de direccion preferidos.

Observabilidad

Las metricas estan disponibles para Pods, workloads y Nodes usando metrics.k8s.io.
Cuando Metrics Server no esta disponible, KuaDashboard puede detectar servicios Prometheus y consultar metricas mediante el proxy del API server de Kubernetes.
Los paneles de detalle de recursos y Nodes incluyen eventos relacionados y resumen de notificaciones para diagnosticar scheduling, image pull, salud y ciclo de vida.

Port Forwarding

Los tuneles para Services y Pods son mas confiables, con mejor resolucion del pod objetivo, estado persistente y reconexion.
Las acciones de port-forward estan disponibles desde tablas y detalles cuando el recurso seleccionado soporta tunel.

v1.7.0 (2026-05-05)

Auto-refresh para vistas Kubernetes, AWS, GCP y Helm sin resetear el contexto de navegacion.
Panel lateral Kubernetes ajustable con resumen especializado y YAML estructurado.
Metricas de Pods usando metrics.k8s.io, deteccion de Prometheus y acceso a Helm cuando falta monitoreo.
Streaming de logs en tiempo real para Pods, Deployments, StatefulSets y DaemonSets.
Busqueda en Terminal Logs, filtros por fecha serializada, descarga y conteo de lineas.
Editor YAML con busqueda, lint, guardado, estado linea/columna, ruta de seccion y autocompletado.
Sesiones EC2 SSH/RDP persistentes que se pueden ocultar y reabrir sin cerrar la conexion.

Changelog ​

Unreleased ​

Corregido ​

Añadido ​

Lo más destacado de la 2.0 ​

Actualizar desde 1.x ​

Kubernetes ​

AWS ​

GCP ​

Vercel ​

KUApps y Arquitectura ​

Advisor ​

Logs y observabilidad ​

Agentes IA y MCP ​

Planes y cuenta ​

Escritorio y sistema ​

v1.17.0 (2026-09-28) ​

Arreglado ​

Cambiado ​

Añadido ​

v1.16.0 (2026-09-16) ​

v1.15.0 (2026-09-05) ​

Observability: inteligencia de logs Kubernetes en Intelligent ​

Architecture Canvas y Routes: filtros de relaciones y carriles por proveedor ​

Architecture Canvas: exportación a PDF y Mermaid ​

Architecture: descubrimiento de referencias por variables de entorno de Lambda ​

Architecture: descubrimiento de capacidades por rol IAM y referencias estáticas de código ​

Architecture: discovery de recursos generalizado (fan-out SNS, servicios desconocidos, cross-stack) ​

Corregido: "Retry sync" nunca lograba limpiar algunos recursos divergentes ​

Architecture + Observability: S3, SNS y DynamoDB ahora correlacionan como recursos compartidos ​

Corregido: los workloads Kubernetes podían descubrirse dos veces con una identidad rota ​

Architecture: los paneles de discovery muestran los recursos ya agregados al proyecto ​

Observability: los recursos Kubernetes muestran su tipo específico, y la divergencia se marca por elemento ​

Architecture: los Deployments de Kubernetes ahora se relacionan entre sí desde metadata, igual que ya pasa con AWS ​

Observability: EC2 y S3 reportan métricas de CloudWatch, y más recursos AWS llegan al inventario ​

Corregido: importar recursos descubiertos descartaba silenciosamente sus relaciones ​

Architecture: los nodos del clúster ahora se identifican como las instancias en la nube donde corren ​

Observability: una vista de Relaciones para revisar las conexiones descubiertas ​

Observability: la confirmación de recolección ahora también describe Kubernetes ​

Corregido: los Secrets y ConfigMaps generaban un error de recolección en cada ejecución ​

Observability: volumen de logs por workload, y menos espacio desperdiciado en recursos sin métricas ​

Observability: los nodos del clúster, los Ingress y los Pods ahora reportan sus propias métricas ​

Observability: los KPI y gráficos ahora se organizan por tipo de recurso ​

Corregido: el uso de CPU/memoria de Kubernetes nunca llegaba realmente a Prometheus ​

Corregido: recursos Kubernetes duplicados entre Architecture y Observabilidad ​

Architecture Fase 9: persistencia del contexto de aplicación ​

Architecture Fase 10: navegación a nivel de recurso ​

Architecture Fase 11: overlay de salud en el Canvas ​

Architecture Fase 12: vista canónica de Resources ​

Architecture Fase 13: menos revisiones sorpresa por la reconciliación del registro compartido ​

Architecture Fase 14: diagnóstico visible de sincronización del registro compartido ​

Architecture Fase 15: Routes con sus propios filtros de proveedor/contexto/namespace ​

Architecture Fase 16: sugerencias de relaciones deterministas basadas en logs ​

v1.14.1 (2026-08-26) ​

Reconciliación de recursos AWS heredados ​

v1.14.0 (2026-08-26) ​

Recursos compartidos y análisis de topología AWS ​

v1.13.0 (2026-08-26) ​

Workspace Architecture centrado en la aplicacion ​

v1.12.0 (2026-08-26) ​

Endurecimiento del shell de KUA Application ​

Architecture Fase 8: Base del Adaptador Kubernetes (2026-08-26) ​

Base de Architecture Fase 6 (2026-08-26) ​

Base de Architecture Fase 5 (2026-08-26) ​

Inicio de Architecture Fase 4 (2026-08-26) ​

Cierre de Architecture Fase 3 (2026-08-25) ​

Base del espacio Architecture ​

v1.11.3 (2026-08-11) ​

Hotfix de empaquetado macOS ​

v1.11.2 (2026-08-11) ​

APM multicloud y sin proveedor ​

Inteligencia de topología explicable ​

Requests de procesos y trazas de ejecución ​

Correcciones Vercel y estabilidad ​

v1.11.0 (2026-08-06) ​

Observabilidad local de aplicaciones ​

EKS Container Insights ​

Controles de coste y privacidad ​

Estabilidad de refresco y terminal ​

Compatibilidad runtime y Kubernetes ​

Changelog

Unreleased

Corregido

Añadido

Lo más destacado de la 2.0

Actualizar desde 1.x

Kubernetes

AWS

GCP

Vercel

KUApps y Arquitectura

Advisor

Logs y observabilidad

Agentes IA y MCP

Planes y cuenta

Escritorio y sistema

v1.17.0 (2026-09-28)

Arreglado

Cambiado

Añadido

v1.16.0 (2026-09-16)

v1.15.0 (2026-09-05)

Observability: inteligencia de logs Kubernetes en Intelligent

Architecture Canvas y Routes: filtros de relaciones y carriles por proveedor

Architecture Canvas: exportación a PDF y Mermaid

Architecture: descubrimiento de referencias por variables de entorno de Lambda

Architecture: descubrimiento de capacidades por rol IAM y referencias estáticas de código

Architecture: discovery de recursos generalizado (fan-out SNS, servicios desconocidos, cross-stack)

Corregido: "Retry sync" nunca lograba limpiar algunos recursos divergentes

Architecture + Observability: S3, SNS y DynamoDB ahora correlacionan como recursos compartidos

Corregido: los workloads Kubernetes podían descubrirse dos veces con una identidad rota

Architecture: los paneles de discovery muestran los recursos ya agregados al proyecto

Observability: los recursos Kubernetes muestran su tipo específico, y la divergencia se marca por elemento

Architecture: los Deployments de Kubernetes ahora se relacionan entre sí desde metadata, igual que ya pasa con AWS

Observability: EC2 y S3 reportan métricas de CloudWatch, y más recursos AWS llegan al inventario

Corregido: importar recursos descubiertos descartaba silenciosamente sus relaciones

Architecture: los nodos del clúster ahora se identifican como las instancias en la nube donde corren

Observability: una vista de Relaciones para revisar las conexiones descubiertas

Observability: la confirmación de recolección ahora también describe Kubernetes

Corregido: los Secrets y ConfigMaps generaban un error de recolección en cada ejecución

Observability: volumen de logs por workload, y menos espacio desperdiciado en recursos sin métricas

Observability: los nodos del clúster, los Ingress y los Pods ahora reportan sus propias métricas

Observability: los KPI y gráficos ahora se organizan por tipo de recurso

Corregido: el uso de CPU/memoria de Kubernetes nunca llegaba realmente a Prometheus

Corregido: recursos Kubernetes duplicados entre Architecture y Observabilidad

Architecture Fase 9: persistencia del contexto de aplicación

Architecture Fase 10: navegación a nivel de recurso

Architecture Fase 11: overlay de salud en el Canvas

Architecture Fase 12: vista canónica de Resources

Architecture Fase 13: menos revisiones sorpresa por la reconciliación del registro compartido

Architecture Fase 14: diagnóstico visible de sincronización del registro compartido

Architecture Fase 15: Routes con sus propios filtros de proveedor/contexto/namespace

Architecture Fase 16: sugerencias de relaciones deterministas basadas en logs

v1.14.1 (2026-08-26)

Reconciliación de recursos AWS heredados

v1.14.0 (2026-08-26)

Recursos compartidos y análisis de topología AWS

v1.13.0 (2026-08-26)

Workspace Architecture centrado en la aplicacion

v1.12.0 (2026-08-26)

Endurecimiento del shell de KUA Application

Architecture Fase 8: Base del Adaptador Kubernetes (2026-08-26)

Base de Architecture Fase 6 (2026-08-26)

Base de Architecture Fase 5 (2026-08-26)

Inicio de Architecture Fase 4 (2026-08-26)

Cierre de Architecture Fase 3 (2026-08-25)

Base del espacio Architecture

v1.11.3 (2026-08-11)

Hotfix de empaquetado macOS

v1.11.2 (2026-08-11)

APM multicloud y sin proveedor

Inteligencia de topología explicable

Requests de procesos y trazas de ejecución

Correcciones Vercel y estabilidad

v1.11.0 (2026-08-06)

Observabilidad local de aplicaciones

EKS Container Insights

Controles de coste y privacidad

Estabilidad de refresco y terminal

Compatibilidad runtime y Kubernetes