Eslopes
18 de julio de 2026, 16:55
Estado actual de la actualización de egui
A continuación, un informe detallado de todo lo que se hizo en esta sesión sobre la rama egui-035 de PowerRustCOBOL. Se completaron dos funcionalidades grandes (specs 030 y 031), ambas siguiendo el flujo de desarrollo dirigido por especificaciones del proyecto (/specify → /plan → /tasks → /implement), y se confirmó y subió todo al repositorio remoto.
El trabajo de actualización de egui todavía no ha finalizado.
Antes de considerar esta etapa terminada, es necesario:
Probar individualmente cada control.
Corregir algunos problemas que todavía persisten en las esquinas y bordes redondeados.
Incorporar nuevos controles, previstos para la próxima revisión.
Renovar la apariencia visual de varios controles.
Entre los controles que recibirán una nueva presentación visual se encuentran especialmente:
Slider
Calendar
Otros controles que todavía están siendo revisados.
El objetivo inmediato es estabilizar la plataforma lo suficiente como para poder habilitar nuevamente la descarga.
La previsión actual es publicar una versión descargable probablemente hacia finales de la próxima semana.
[Resumen del trabajo realizado — Rama egui-035
A continuación se presenta un informe detallado del trabajo realizado en la rama egui-035 de PowerRustCOBOL.
Durante esta etapa se completaron dos funcionalidades principales:
Spec 030 — Capa de ejecución de herramientas.
Spec 031 — Perfiles de modelo y Gestor de modelos.
Ambas se desarrollaron siguiendo el flujo dirigido por especificaciones del proyecto:
/specify → /plan → /tasks → /implement
Todo el trabajo fue validado, confirmado mediante commit y publicado en el repositorio remoto.
Panorama general
La rama egui-035 es una rama dedicada y de larga duración con dos objetivos principales:
Modernizar la plataforma de interfaz gráfica del IDE.
Construir, sobre esa nueva base, un sistema de agentes de IA capaz de percibir y operar el propio entorno de desarrollo.
Todo el trabajo sigue el flujo de desarrollo dirigido por especificaciones:
/specify → /plan → /tasks → /implement
Las cinco capas de la arquitectura
Cada capa se apoya en la anterior:
Spec 027 — Actualización de la plataforma a egui 0.35 y acceso MCP para agentes. Es la base de toda la arquitectura.
Spec 028 — Base de datos de agentes y Gestor de agentes.
Spec 029 — Grace, la agente orquestadora del sistema multiagente.
Spec 030 — Capa de ejecución de herramientas, que permite que los especialistas actúen realmente.
Spec 031 — Perfiles de modelo reutilizables y Gestor de modelos.
Una regla se aplica a toda la rama:
El número de versión no se modifica con cada spec.
La entrada del CHANGELOG tampoco se actualiza individualmente.
Ambos cambios quedan reservados para la compuerta final de integración, correspondiente a la Spec 027, tarea T16.
El objetivo es producir un único incremento de versión reconciliado cuando la rama se integre en main.
1. Spec 027 — Actualización de la plataforma a egui 0.35
Motivación
Esta especificación es la razón de existir de la rama y la base que hizo posible todo el soporte de agentes.
La pila completa de interfaz fue actualizada de egui/eframe 0.29 a egui/eframe 0.35.
La actualización tuvo dos motivaciones principales:
Estabilidad de la plataforma: la versión 0.29 se estaba quedando atrás, mientras que la rama 0.35 recibe mantenimiento activo y ofrece una base más estable.
Soporte nativo para agentes: egui 0.35 incorpora el protocolo de inspección y egui_mcp, un servidor MCP que permite que agentes de IA observen y operen aplicaciones egui.
Esta capacidad convierte al propio IDE en un entorno operable por agentes. Los agentes pueden:
Inspeccionar la interfaz gráfica.
Observar el estado de widgets y controles.
Generar formularios.
Escribir manejadores de eventos COBOL.
Conducir flujos del IDE de forma programática.
Trabajar sobre el estado real de la aplicación, en lugar de emitir bloques JSON a ciegas.
Sobre esta base se apoyan:
Las herramientas de observación egui.* de la Spec 030.
La ejecución gobernada de herramientas.
La integración de Grace con el IDE.
El modelo multiagente completo.
La migración fue tratada como un cambio de “todo o nada”:
Cero pérdida de funcionalidad.
Cero stubs.
Cero errores de compilación.
Cero advertencias de deprecación.
Proceso de migración
La migración se realizó versión por versión, con una compuerta de calidad en cada etapa:
Toolchain: MSRV elevado a Rust 1.92, requisito mínimo de egui 0.34 o superior.
0.30 → 0.31: migración a CornerRadius, con impacto directo sobre el sistema de esquinas redondeadas.
0.32: actualización de paneles, menús e id_salt.
0.33: adopción del nuevo trait Plugin y retirada de screen_rect. Se reclasificaron 18 usos como content_rect.
0.34: incorporación del rediseño “More Ui, less Context”, incluyendo App::ui, viewports basados en Ui, global_style, fonts_mut y el nuevo motor de fuentes skrifa.
0.35: salto final de toda la familia egui a la versión 0.35.0, incluyendo una protección contra el pánico real de epaint cuando units_per_em = 0.
Funcionalidad protegida y verificada
Se confirmó que no hubo pérdida de funcionalidad en:
Paneles del IDE.
Form Designer.
Ventanas multi-viewport.
Editor COBOL.
Editor de eventos.
Panel de salida y logs.
Depurador.
Árbol del proyecto.
Diálogos de archivos.
Runtime de formularios.
Temas y estilos glass.
Asistente de IA.
Modales de error.
Inspección y acceso MCP
El endpoint de inspección y MCP permanece activo en:
127.0.0.1:5719
Sus características incluyen:
Puerto configurable.
Acceso limitado exclusivamente a loopback.
Internacionalización en seis idiomas.
Ciclo completo validado: información → árbol de aproximadamente 340 nodos → ejecución de clic → captura.
Aislamiento de seguridad
Las aplicaciones COBOL compiladas o empaquetadas y rcrun no exponen ninguna superficie MCP o de inspección.
La verificación incluyó:
Cero coincidencias de dependencias MCP en los cuatro crates involucrados.
Cero sockets TCP expuestos por rcrun.
Separación estricta entre las capacidades de inspección del IDE y los binarios generados.
Fuentes y compatibilidad internacional
Se validaron:
177 tipografías con el motor skrifa.
Compatibilidad GB18030 de extremo a extremo.
Protección contra valores inválidos de units_per_em.
Ejecución sin pánicos asociados al nuevo motor de fuentes.
Estado actual
Tareas completadas:
T1 a T13.
T15.
Tareas pendientes:
T14 — Recorrido del operador: ejecutar la rama junto a una compilación de main y confirmar la compuerta de cero pérdida de funcionalidad.
T16 — Finalización e integración: actualizar la versión, modificar el CHANGELOG, ejecutar la auditoría de sincronización, completar las pruebas y realizar la integración --no-ff en main.
Definir la ventana de publicación.
Publicar el aviso correspondiente en el foro.
También permanece un artefacto visual menor relacionado con las esquinas en Vista previa y Ejecutar formulario, que debe verificarse utilizando:
COBOL_FRAME_DIAGNOSTICS=1
2. Spec 028 — Base de datos de agentes y Gestor de agentes
Sobre la nueva plataforma se creó una base de datos de agentes capaz de almacenar cualquier cantidad de agentes.
Cada agente puede disponer de:
Su propio modelo.
Su propio prompt.
Capacidades declaradas.
Herramientas.
Skills.
Políticas.
Conocimiento especializado.
Un agente compañero de revisión.
Cada agente se almacena dentro del proyecto en:
agentic_ai/<nombre-del-agente>/
La estructura incluye:
<nombre>_prompt.md — prompt multilínea del agente.
steering/ — instrucciones de orientación.
policies.md — políticas aplicables.
skills/ — capacidades especializadas.
mcp.json — configuración de herramientas MCP.
knowledge/ — conocimiento adicional.
agent.json — identidad y configuración de ejecución.
La clave de API:
Nunca se almacena dentro del proyecto.
Nunca viaja con el repositorio.
Permanece en el almacén local de secretos de la máquina.
Los nombres de los agentes son:
Únicos.
Fijos desde su creación.
Utilizados como nombre de la carpeta correspondiente.
Cada agente primario puede declarar un compañero pedante encargado de revisar sus respuestas.
Las reglas de modelos son:
El agente primario y su propio revisor deben utilizar modelos diferentes.
Agentes no relacionados pueden compartir el mismo modelo.
El Gestor de agentes permite:
Crear agentes.
Editar agentes.
Asignar modelos.
Definir especializaciones.
Configurar capacidades.
Asignar revisores pedantes.
Administrar prompts, tools, skills y conocimiento.
La primera vez que se abre, el Gestor de agentes se inicializa automáticamente a partir de la configuración de IA existente.
3. Spec 029 — Grace, la orquestadora del sistema multiagente
Grace es la autoridad única de coordinación:
Siempre se llama Grace.
Está identificada con una corona.
No puede eliminarse.
Existe una única instancia por proyecto.
Cuando Grace está activada, el flujo de una solicitud es el siguiente:
Grace analiza la solicitud.
Genera un plan estructurado.
Divide el trabajo en tareas.
Selecciona agentes por tipo, especialización y capacidades declaradas.
Delega cada tarea mediante contratos estructurados.
Activa las revisiones pedantes obligatorias.
Ejecuta ciclos de corrección limitados.
Integra los resultados aprobados.
Ensambla la respuesta final.
Los agentes nunca se seleccionan por semejanza de nombre.
Únicamente el trabajo aprobado puede llegar al resultado final.
Estados de las tareas
El motor implementa once estados:
Pending
Ready
Running
AwaitingDependency
AwaitingReview
CorrectionRequired
Revalidating
Approved
Blocked
Failed
Completed
La delegación utiliza contratos estructurados:
TaskSpec → TaskResult
Una afirmación como “terminado”, sin evidencia verificable, se rechaza.
La revisión es obligatoria:
Ningún agente puede aprobar su propio trabajo.
Cada corrección vuelve a pasar por el proceso completo de revisión.
Los ciclos de corrección son limitados.
Los resultados y veredictos quedan registrados.
Cada workflow se almacena como un registro auditable en:
agentic_ai/Grace/runs/
En el Form Designer, un conmutador con la corona de Grace permite enrutar la solicitud a través de ella y observar el progreso:
planificar → delegar → revisión pedante → integrar
Agentes especializados iniciales
Se crearon los siguientes especialistas:
Form Designer Agent
COBOL Event Handler Agent
Version Control Agent
Cada especialista dispone de su correspondiente compañero pedante.
4. Spec 030 — Capa de ejecución de herramientas
El problema
Los especialistas ya disponían de:
Definiciones.
Prompts.
Modelos.
Revisores.
Orquestación.
Sin embargo, todavía no podían actuar sobre el proyecto.
Cada resultado era únicamente texto:
No se modificaban formularios.
No se operaba sobre el repositorio.
No se ejecutaban herramientas.
No existía evidencia real de ejecución.
La solución
La implementación se apoyó en una única extensión del diseño existente:
AgentInvoker
Esto permitió mantener sin modificaciones el crate de lógica pura:
cobolt-agents
tool_exec.rs
ToolExecutingInvoker envuelve al invocador base y ejecuta el siguiente ciclo:
Llama al modelo.
Detecta un bloque JSON final con tool_calls.
Comprueba que las herramientas solicitadas estén declaradas.
Ejecuta las herramientas autorizadas.
Captura los resultados reales.
Reinyecta esos resultados como un nuevo turno.
Repite el proceso hasta que el agente responda sin solicitar más herramientas.
El formato esperado es:
{"tool_calls":[...]}
La gobernanza es estricta:
Una herramienta no declarada provoca el fallo de la tarea.
Una herramienta inventada se considera un defecto crítico.
Cada llamada queda registrada como ToolEvidence.
El ciclo de ejecución está limitado.
No se acepta una declaración de éxito sin evidencia.
git_exec.rs
El ejecutor Git está limitado al repositorio del proyecto abierto por el usuario.
Nunca puede actuar sobre el repositorio del propio IDE.
Se rechazan argumentos capaces de escapar del repositorio:
-C
--git-dir
--work-tree
Las operaciones de lectura y mutación local pueden ejecutarse de forma autónoma:
status
diff
log
add
commit
branch
checkout
stash
Las operaciones de red o reescritura de historial están restringidas:
push
fetch
pull
rebase
reset --hard
Operaciones de force-push.
Estas operaciones requieren confirmación explícita.
Para cada ejecución se registra:
El comando exacto.
El directorio de trabajo.
El código de salida.
La salida estándar.
La salida de error.
La evidencia correspondiente.
Un código de salida diferente de cero se considera un fallo.
Herramientas egui.*
Las herramientas egui.* implementadas en esta fase son exclusivamente de observación.
Permiten que el especialista:
Observe el árbol de widgets.
Consulte la instantánea de inspección almacenada en caché.
Verifique el estado real de la interfaz.
Compruebe el resultado de su propio trabajo.
No existe una vía directa de mutación de la interfaz mediante estas herramientas.
Aplicación de diseños aprobados
Cuando el compañero pedante aprueba una tarea de diseño:
El resultado se envía al flujo existente de previsualización y aplicación.
El change-set vuelve a validarse.
El cambio se aplica como una única acción.
La acción puede revisarse.
La acción puede deshacerse.
Un change-set inválido nunca se aplica.
Confirmación de operaciones restringidas
El panel de Grace muestra una confirmación en línea para operaciones Git restringidas.
El usuario puede:
Aprobar la operación.
Denegarla.
Revisar el comando exacto antes de decidir.
Cerrar la sesión o denegar la solicitud se registra como una denegación con evidencia.
El archivo de ejecución pasó a utilizar la siguiente estructura:
{record, tool_calls}
El formato permanece compatible con registros anteriores.
5. Spec 031 — Perfiles de modelo y Gestor de modelos
El problema
Anteriormente, cada agente incorporaba toda su configuración de modelo.
Esto producía:
Configuración repetida.
Duplicación de endpoints.
Duplicación de parámetros.
Duplicación de modelos.
Repetición de los mismos datos en el Gestor de agentes.
La solución
El modelo fue desacoplado del agente.
Ahora:
La conexión se define una sola vez.
La configuración se almacena como un perfil reutilizable.
Cada agente referencia el perfil correspondiente.
ModelProfile
Un ModelProfile es un perfil global y reutilizable que contiene:
Nombre.
Proveedor.
Endpoint.
Modelo.
Parámetros de generación.
Un perfil puede reutilizarse:
En varios proyectos.
Por varios agentes.
Por agentes primarios y revisores, siempre que se respeten las reglas de independencia.
La clave de API no forma parte del perfil.
Permanece almacenada mediante la combinación:
(proveedor, modelo)
Por motivos de seguridad, la clave:
Nunca se copia en un perfil.
Nunca se almacena en un archivo del proyecto.
Nunca se inserta en el COBOL generado.
Nunca se incorpora al binario compilado.
Resolución del modelo
La resolución utiliza el perfil como primera opción.
Para agentes todavía no migrados:
Se mantiene como respaldo la configuración incrustada anterior.
Una referencia a un perfil eliminado se resuelve como “sin modelo configurado”.
Una referencia colgante nunca provoca un fallo inesperado.
Migración automática
La primera vez que se abre el Gestor de agentes:
Se inspeccionan las configuraciones incrustadas existentes.
Se crea el conjunto mínimo de perfiles necesarios.
Las configuraciones idénticas se consolidan en un único perfil.
Cada agente se asocia con el perfil correspondiente.
Se conserva exactamente la misma configuración efectiva que existía antes.
La migración es:
Automática.
Idempotente.
Compatible con agentes existentes.
Realizada sin intervención manual.
Gestor de modelos
Se añadió el botón:
Gestor de modelos…
Este se encuentra junto a:
Gestionar agentes…
El nuevo modal permite:
Crear perfiles.
Renombrar perfiles.
Duplicar perfiles.
Eliminar perfiles con advertencia.
Configurar el proveedor.
Configurar el endpoint.
Introducir la clave.
Seleccionar el modelo.
Obtener la lista de modelos disponibles.
Probar la conexión.
Verificar la competencia COBOL.
Gestor de agentes simplificado
El antiguo bloque completo de conexión fue reemplazado por un selector de perfil.
Como resultado:
La configuración ya no se repite por agente.
La obtención de modelos se centraliza.
La administración de claves se retira del formulario de cada agente.
El Gestor de agentes queda más limpio y enfocado.
Verificación de competencia
El botón Verificar competencia:
Se encuentra junto al selector del agente pedante.
Solo aparece cuando se selecciona un compañero.
Se oculta cuando la opción elegida es “ninguno”.
Ejecuta la verificación como un tándem compuesto por el agente primario y su revisor.
6. Calidad, confirmación y publicación
Pruebas
Resultados obtenidos:
cobolt-ide: 193 pruebas aprobadas, 0 fallos.
cobolt-agents: 13 pruebas aprobadas, 0 fallos.
Todo el workspace compila correctamente.
Todo el workspace supera las pruebas.
Las nuevas suites cubren:
tool_exec
git_exec
Perfiles de modelo.
Migración automática.
Internacionalización
Todas las nuevas cadenas de la interfaz fueron traducidas a seis idiomas:
Inglés.
Español.
Portugués.
Japonés.
Chino.
Francés.
Documentación
Se actualizó únicamente:
developers-guide-en.md
Las traducciones existentes no fueron modificadas.
Commit y publicación
Commit realizado:
79d95a1 — Agents execute tools + reusable model profiles (specs 030, 031)
Contenido:
21 archivos modificados.
3.589 líneas añadidas.
295 líneas eliminadas.
Las Specs 030 y 031 se incluyeron en un único commit porque:
Comparten archivos estrechamente relacionados.
Ambas son funcionalidades.
No se mezclaron correcciones independientes.
La rama fue publicada en:
origin/egui-035
Rango publicado:
317e74f..79d95a1
El archivo siguiente fue excluido deliberadamente:
assets/images/bg2.jpg
Este archivo apareció modificado durante la sesión sin formar parte del trabajo realizado. Permanece pendiente de revisión para decidir si debe conservarse o descartarse.
7. Tareas pendientes y decisiones necesarias
Verificaciones manuales en la aplicación
Es necesario probar:
El flujo completo de Grace ejecutando herramientas.
La adición de un control como cambio deshacible.
La creación autónoma de un commit.
La solicitud de confirmación antes de un push restringido.
La creación y persistencia de un perfil en el Gestor de modelos.
La verificación de competencia junto al compañero pedante.
La ausencia de claves en el COBOL generado.
La ausencia de claves en el binario compilado.
Para las verificaciones de seguridad se recomienda:
Compilar el proyecto.
Inspeccionar el COBOL generado.
Ejecutar una búsqueda de texto sobre el binario.
bg2.jpg
Es necesario decidir si el cambio en:
assets/images/bg2.jpg
debe:
Confirmarse.
Descartarse.
Spec 027 — T14 y T16
Quedan pendientes:
El recorrido manual del operador.
La validación final de cero pérdida de funcionalidad.
La compuerta de integración en main.
La actualización de versión.
La actualización del CHANGELOG.
La auditoría de sincronización.
La ejecución completa de pruebas.
La integración mediante --no-ff.
La definición de la ventana de publicación.
La publicación del aviso en el foro.
La versión y el CHANGELOG permanecen reservados para la tarea T16.
A continuación, un informe detallado de todo lo que se hizo en esta sesión sobre la rama egui-035 de PowerRustCOBOL. Se completaron dos funcionalidades grandes (specs 030 y 031), ambas siguiendo el flujo de desarrollo dirigido por especificaciones del proyecto (/specify → /plan → /tasks → /implement), y se confirmó y subió todo al repositorio remoto.
El trabajo de actualización de egui todavía no ha finalizado.
Antes de considerar esta etapa terminada, es necesario:
Probar individualmente cada control.
Corregir algunos problemas que todavía persisten en las esquinas y bordes redondeados.
Incorporar nuevos controles, previstos para la próxima revisión.
Renovar la apariencia visual de varios controles.
Entre los controles que recibirán una nueva presentación visual se encuentran especialmente:
Slider
Calendar
Otros controles que todavía están siendo revisados.
El objetivo inmediato es estabilizar la plataforma lo suficiente como para poder habilitar nuevamente la descarga.
La previsión actual es publicar una versión descargable probablemente hacia finales de la próxima semana.
[Resumen del trabajo realizado — Rama egui-035
A continuación se presenta un informe detallado del trabajo realizado en la rama egui-035 de PowerRustCOBOL.
Durante esta etapa se completaron dos funcionalidades principales:
Spec 030 — Capa de ejecución de herramientas.
Spec 031 — Perfiles de modelo y Gestor de modelos.
Ambas se desarrollaron siguiendo el flujo dirigido por especificaciones del proyecto:
/specify → /plan → /tasks → /implement
Todo el trabajo fue validado, confirmado mediante commit y publicado en el repositorio remoto.
Panorama general
La rama egui-035 es una rama dedicada y de larga duración con dos objetivos principales:
Modernizar la plataforma de interfaz gráfica del IDE.
Construir, sobre esa nueva base, un sistema de agentes de IA capaz de percibir y operar el propio entorno de desarrollo.
Todo el trabajo sigue el flujo de desarrollo dirigido por especificaciones:
/specify → /plan → /tasks → /implement
Las cinco capas de la arquitectura
Cada capa se apoya en la anterior:
Spec 027 — Actualización de la plataforma a egui 0.35 y acceso MCP para agentes. Es la base de toda la arquitectura.
Spec 028 — Base de datos de agentes y Gestor de agentes.
Spec 029 — Grace, la agente orquestadora del sistema multiagente.
Spec 030 — Capa de ejecución de herramientas, que permite que los especialistas actúen realmente.
Spec 031 — Perfiles de modelo reutilizables y Gestor de modelos.
Una regla se aplica a toda la rama:
El número de versión no se modifica con cada spec.
La entrada del CHANGELOG tampoco se actualiza individualmente.
Ambos cambios quedan reservados para la compuerta final de integración, correspondiente a la Spec 027, tarea T16.
El objetivo es producir un único incremento de versión reconciliado cuando la rama se integre en main.
1. Spec 027 — Actualización de la plataforma a egui 0.35
Motivación
Esta especificación es la razón de existir de la rama y la base que hizo posible todo el soporte de agentes.
La pila completa de interfaz fue actualizada de egui/eframe 0.29 a egui/eframe 0.35.
La actualización tuvo dos motivaciones principales:
Estabilidad de la plataforma: la versión 0.29 se estaba quedando atrás, mientras que la rama 0.35 recibe mantenimiento activo y ofrece una base más estable.
Soporte nativo para agentes: egui 0.35 incorpora el protocolo de inspección y egui_mcp, un servidor MCP que permite que agentes de IA observen y operen aplicaciones egui.
Esta capacidad convierte al propio IDE en un entorno operable por agentes. Los agentes pueden:
Inspeccionar la interfaz gráfica.
Observar el estado de widgets y controles.
Generar formularios.
Escribir manejadores de eventos COBOL.
Conducir flujos del IDE de forma programática.
Trabajar sobre el estado real de la aplicación, en lugar de emitir bloques JSON a ciegas.
Sobre esta base se apoyan:
Las herramientas de observación egui.* de la Spec 030.
La ejecución gobernada de herramientas.
La integración de Grace con el IDE.
El modelo multiagente completo.
La migración fue tratada como un cambio de “todo o nada”:
Cero pérdida de funcionalidad.
Cero stubs.
Cero errores de compilación.
Cero advertencias de deprecación.
Proceso de migración
La migración se realizó versión por versión, con una compuerta de calidad en cada etapa:
Toolchain: MSRV elevado a Rust 1.92, requisito mínimo de egui 0.34 o superior.
0.30 → 0.31: migración a CornerRadius, con impacto directo sobre el sistema de esquinas redondeadas.
0.32: actualización de paneles, menús e id_salt.
0.33: adopción del nuevo trait Plugin y retirada de screen_rect. Se reclasificaron 18 usos como content_rect.
0.34: incorporación del rediseño “More Ui, less Context”, incluyendo App::ui, viewports basados en Ui, global_style, fonts_mut y el nuevo motor de fuentes skrifa.
0.35: salto final de toda la familia egui a la versión 0.35.0, incluyendo una protección contra el pánico real de epaint cuando units_per_em = 0.
Funcionalidad protegida y verificada
Se confirmó que no hubo pérdida de funcionalidad en:
Paneles del IDE.
Form Designer.
Ventanas multi-viewport.
Editor COBOL.
Editor de eventos.
Panel de salida y logs.
Depurador.
Árbol del proyecto.
Diálogos de archivos.
Runtime de formularios.
Temas y estilos glass.
Asistente de IA.
Modales de error.
Inspección y acceso MCP
El endpoint de inspección y MCP permanece activo en:
127.0.0.1:5719
Sus características incluyen:
Puerto configurable.
Acceso limitado exclusivamente a loopback.
Internacionalización en seis idiomas.
Ciclo completo validado: información → árbol de aproximadamente 340 nodos → ejecución de clic → captura.
Aislamiento de seguridad
Las aplicaciones COBOL compiladas o empaquetadas y rcrun no exponen ninguna superficie MCP o de inspección.
La verificación incluyó:
Cero coincidencias de dependencias MCP en los cuatro crates involucrados.
Cero sockets TCP expuestos por rcrun.
Separación estricta entre las capacidades de inspección del IDE y los binarios generados.
Fuentes y compatibilidad internacional
Se validaron:
177 tipografías con el motor skrifa.
Compatibilidad GB18030 de extremo a extremo.
Protección contra valores inválidos de units_per_em.
Ejecución sin pánicos asociados al nuevo motor de fuentes.
Estado actual
Tareas completadas:
T1 a T13.
T15.
Tareas pendientes:
T14 — Recorrido del operador: ejecutar la rama junto a una compilación de main y confirmar la compuerta de cero pérdida de funcionalidad.
T16 — Finalización e integración: actualizar la versión, modificar el CHANGELOG, ejecutar la auditoría de sincronización, completar las pruebas y realizar la integración --no-ff en main.
Definir la ventana de publicación.
Publicar el aviso correspondiente en el foro.
También permanece un artefacto visual menor relacionado con las esquinas en Vista previa y Ejecutar formulario, que debe verificarse utilizando:
COBOL_FRAME_DIAGNOSTICS=1
2. Spec 028 — Base de datos de agentes y Gestor de agentes
Sobre la nueva plataforma se creó una base de datos de agentes capaz de almacenar cualquier cantidad de agentes.
Cada agente puede disponer de:
Su propio modelo.
Su propio prompt.
Capacidades declaradas.
Herramientas.
Skills.
Políticas.
Conocimiento especializado.
Un agente compañero de revisión.
Cada agente se almacena dentro del proyecto en:
agentic_ai/<nombre-del-agente>/
La estructura incluye:
<nombre>_prompt.md — prompt multilínea del agente.
steering/ — instrucciones de orientación.
policies.md — políticas aplicables.
skills/ — capacidades especializadas.
mcp.json — configuración de herramientas MCP.
knowledge/ — conocimiento adicional.
agent.json — identidad y configuración de ejecución.
La clave de API:
Nunca se almacena dentro del proyecto.
Nunca viaja con el repositorio.
Permanece en el almacén local de secretos de la máquina.
Los nombres de los agentes son:
Únicos.
Fijos desde su creación.
Utilizados como nombre de la carpeta correspondiente.
Cada agente primario puede declarar un compañero pedante encargado de revisar sus respuestas.
Las reglas de modelos son:
El agente primario y su propio revisor deben utilizar modelos diferentes.
Agentes no relacionados pueden compartir el mismo modelo.
El Gestor de agentes permite:
Crear agentes.
Editar agentes.
Asignar modelos.
Definir especializaciones.
Configurar capacidades.
Asignar revisores pedantes.
Administrar prompts, tools, skills y conocimiento.
La primera vez que se abre, el Gestor de agentes se inicializa automáticamente a partir de la configuración de IA existente.
3. Spec 029 — Grace, la orquestadora del sistema multiagente
Grace es la autoridad única de coordinación:
Siempre se llama Grace.
Está identificada con una corona.
No puede eliminarse.
Existe una única instancia por proyecto.
Cuando Grace está activada, el flujo de una solicitud es el siguiente:
Grace analiza la solicitud.
Genera un plan estructurado.
Divide el trabajo en tareas.
Selecciona agentes por tipo, especialización y capacidades declaradas.
Delega cada tarea mediante contratos estructurados.
Activa las revisiones pedantes obligatorias.
Ejecuta ciclos de corrección limitados.
Integra los resultados aprobados.
Ensambla la respuesta final.
Los agentes nunca se seleccionan por semejanza de nombre.
Únicamente el trabajo aprobado puede llegar al resultado final.
Estados de las tareas
El motor implementa once estados:
Pending
Ready
Running
AwaitingDependency
AwaitingReview
CorrectionRequired
Revalidating
Approved
Blocked
Failed
Completed
La delegación utiliza contratos estructurados:
TaskSpec → TaskResult
Una afirmación como “terminado”, sin evidencia verificable, se rechaza.
La revisión es obligatoria:
Ningún agente puede aprobar su propio trabajo.
Cada corrección vuelve a pasar por el proceso completo de revisión.
Los ciclos de corrección son limitados.
Los resultados y veredictos quedan registrados.
Cada workflow se almacena como un registro auditable en:
agentic_ai/Grace/runs/
En el Form Designer, un conmutador con la corona de Grace permite enrutar la solicitud a través de ella y observar el progreso:
planificar → delegar → revisión pedante → integrar
Agentes especializados iniciales
Se crearon los siguientes especialistas:
Form Designer Agent
COBOL Event Handler Agent
Version Control Agent
Cada especialista dispone de su correspondiente compañero pedante.
4. Spec 030 — Capa de ejecución de herramientas
El problema
Los especialistas ya disponían de:
Definiciones.
Prompts.
Modelos.
Revisores.
Orquestación.
Sin embargo, todavía no podían actuar sobre el proyecto.
Cada resultado era únicamente texto:
No se modificaban formularios.
No se operaba sobre el repositorio.
No se ejecutaban herramientas.
No existía evidencia real de ejecución.
La solución
La implementación se apoyó en una única extensión del diseño existente:
AgentInvoker
Esto permitió mantener sin modificaciones el crate de lógica pura:
cobolt-agents
tool_exec.rs
ToolExecutingInvoker envuelve al invocador base y ejecuta el siguiente ciclo:
Llama al modelo.
Detecta un bloque JSON final con tool_calls.
Comprueba que las herramientas solicitadas estén declaradas.
Ejecuta las herramientas autorizadas.
Captura los resultados reales.
Reinyecta esos resultados como un nuevo turno.
Repite el proceso hasta que el agente responda sin solicitar más herramientas.
El formato esperado es:
{"tool_calls":[...]}
La gobernanza es estricta:
Una herramienta no declarada provoca el fallo de la tarea.
Una herramienta inventada se considera un defecto crítico.
Cada llamada queda registrada como ToolEvidence.
El ciclo de ejecución está limitado.
No se acepta una declaración de éxito sin evidencia.
git_exec.rs
El ejecutor Git está limitado al repositorio del proyecto abierto por el usuario.
Nunca puede actuar sobre el repositorio del propio IDE.
Se rechazan argumentos capaces de escapar del repositorio:
-C
--git-dir
--work-tree
Las operaciones de lectura y mutación local pueden ejecutarse de forma autónoma:
status
diff
log
add
commit
branch
checkout
stash
Las operaciones de red o reescritura de historial están restringidas:
push
fetch
pull
rebase
reset --hard
Operaciones de force-push.
Estas operaciones requieren confirmación explícita.
Para cada ejecución se registra:
El comando exacto.
El directorio de trabajo.
El código de salida.
La salida estándar.
La salida de error.
La evidencia correspondiente.
Un código de salida diferente de cero se considera un fallo.
Herramientas egui.*
Las herramientas egui.* implementadas en esta fase son exclusivamente de observación.
Permiten que el especialista:
Observe el árbol de widgets.
Consulte la instantánea de inspección almacenada en caché.
Verifique el estado real de la interfaz.
Compruebe el resultado de su propio trabajo.
No existe una vía directa de mutación de la interfaz mediante estas herramientas.
Aplicación de diseños aprobados
Cuando el compañero pedante aprueba una tarea de diseño:
El resultado se envía al flujo existente de previsualización y aplicación.
El change-set vuelve a validarse.
El cambio se aplica como una única acción.
La acción puede revisarse.
La acción puede deshacerse.
Un change-set inválido nunca se aplica.
Confirmación de operaciones restringidas
El panel de Grace muestra una confirmación en línea para operaciones Git restringidas.
El usuario puede:
Aprobar la operación.
Denegarla.
Revisar el comando exacto antes de decidir.
Cerrar la sesión o denegar la solicitud se registra como una denegación con evidencia.
El archivo de ejecución pasó a utilizar la siguiente estructura:
{record, tool_calls}
El formato permanece compatible con registros anteriores.
5. Spec 031 — Perfiles de modelo y Gestor de modelos
El problema
Anteriormente, cada agente incorporaba toda su configuración de modelo.
Esto producía:
Configuración repetida.
Duplicación de endpoints.
Duplicación de parámetros.
Duplicación de modelos.
Repetición de los mismos datos en el Gestor de agentes.
La solución
El modelo fue desacoplado del agente.
Ahora:
La conexión se define una sola vez.
La configuración se almacena como un perfil reutilizable.
Cada agente referencia el perfil correspondiente.
ModelProfile
Un ModelProfile es un perfil global y reutilizable que contiene:
Nombre.
Proveedor.
Endpoint.
Modelo.
Parámetros de generación.
Un perfil puede reutilizarse:
En varios proyectos.
Por varios agentes.
Por agentes primarios y revisores, siempre que se respeten las reglas de independencia.
La clave de API no forma parte del perfil.
Permanece almacenada mediante la combinación:
(proveedor, modelo)
Por motivos de seguridad, la clave:
Nunca se copia en un perfil.
Nunca se almacena en un archivo del proyecto.
Nunca se inserta en el COBOL generado.
Nunca se incorpora al binario compilado.
Resolución del modelo
La resolución utiliza el perfil como primera opción.
Para agentes todavía no migrados:
Se mantiene como respaldo la configuración incrustada anterior.
Una referencia a un perfil eliminado se resuelve como “sin modelo configurado”.
Una referencia colgante nunca provoca un fallo inesperado.
Migración automática
La primera vez que se abre el Gestor de agentes:
Se inspeccionan las configuraciones incrustadas existentes.
Se crea el conjunto mínimo de perfiles necesarios.
Las configuraciones idénticas se consolidan en un único perfil.
Cada agente se asocia con el perfil correspondiente.
Se conserva exactamente la misma configuración efectiva que existía antes.
La migración es:
Automática.
Idempotente.
Compatible con agentes existentes.
Realizada sin intervención manual.
Gestor de modelos
Se añadió el botón:
Gestor de modelos…
Este se encuentra junto a:
Gestionar agentes…
El nuevo modal permite:
Crear perfiles.
Renombrar perfiles.
Duplicar perfiles.
Eliminar perfiles con advertencia.
Configurar el proveedor.
Configurar el endpoint.
Introducir la clave.
Seleccionar el modelo.
Obtener la lista de modelos disponibles.
Probar la conexión.
Verificar la competencia COBOL.
Gestor de agentes simplificado
El antiguo bloque completo de conexión fue reemplazado por un selector de perfil.
Como resultado:
La configuración ya no se repite por agente.
La obtención de modelos se centraliza.
La administración de claves se retira del formulario de cada agente.
El Gestor de agentes queda más limpio y enfocado.
Verificación de competencia
El botón Verificar competencia:
Se encuentra junto al selector del agente pedante.
Solo aparece cuando se selecciona un compañero.
Se oculta cuando la opción elegida es “ninguno”.
Ejecuta la verificación como un tándem compuesto por el agente primario y su revisor.
6. Calidad, confirmación y publicación
Pruebas
Resultados obtenidos:
cobolt-ide: 193 pruebas aprobadas, 0 fallos.
cobolt-agents: 13 pruebas aprobadas, 0 fallos.
Todo el workspace compila correctamente.
Todo el workspace supera las pruebas.
Las nuevas suites cubren:
tool_exec
git_exec
Perfiles de modelo.
Migración automática.
Internacionalización
Todas las nuevas cadenas de la interfaz fueron traducidas a seis idiomas:
Inglés.
Español.
Portugués.
Japonés.
Chino.
Francés.
Documentación
Se actualizó únicamente:
developers-guide-en.md
Las traducciones existentes no fueron modificadas.
Commit y publicación
Commit realizado:
79d95a1 — Agents execute tools + reusable model profiles (specs 030, 031)
Contenido:
21 archivos modificados.
3.589 líneas añadidas.
295 líneas eliminadas.
Las Specs 030 y 031 se incluyeron en un único commit porque:
Comparten archivos estrechamente relacionados.
Ambas son funcionalidades.
No se mezclaron correcciones independientes.
La rama fue publicada en:
origin/egui-035
Rango publicado:
317e74f..79d95a1
El archivo siguiente fue excluido deliberadamente:
assets/images/bg2.jpg
Este archivo apareció modificado durante la sesión sin formar parte del trabajo realizado. Permanece pendiente de revisión para decidir si debe conservarse o descartarse.
7. Tareas pendientes y decisiones necesarias
Verificaciones manuales en la aplicación
Es necesario probar:
El flujo completo de Grace ejecutando herramientas.
La adición de un control como cambio deshacible.
La creación autónoma de un commit.
La solicitud de confirmación antes de un push restringido.
La creación y persistencia de un perfil en el Gestor de modelos.
La verificación de competencia junto al compañero pedante.
La ausencia de claves en el COBOL generado.
La ausencia de claves en el binario compilado.
Para las verificaciones de seguridad se recomienda:
Compilar el proyecto.
Inspeccionar el COBOL generado.
Ejecutar una búsqueda de texto sobre el binario.
bg2.jpg
Es necesario decidir si el cambio en:
assets/images/bg2.jpg
debe:
Confirmarse.
Descartarse.
Spec 027 — T14 y T16
Quedan pendientes:
El recorrido manual del operador.
La validación final de cero pérdida de funcionalidad.
La compuerta de integración en main.
La actualización de versión.
La actualización del CHANGELOG.
La auditoría de sincronización.
La ejecución completa de pruebas.
La integración mediante --no-ff.
La definición de la ventana de publicación.
La publicación del aviso en el foro.
La versión y el CHANGELOG permanecen reservados para la tarea T16.