Cada BPL se compila, prueba y distribuye de forma independiente, con dependencias rigurosamente monodireccionales. Varias bases de datos orquestadas por la sincronización, con PostgreSQL como hub de plataforma. Junto a ello, MemoryLens, seguridad e integración.
Las dependencias son monodireccionales. Actualizar un módulo significa sustituir un archivo .bpl, sin recompilar el ejecutable.
La plataforma sigue siendo multi-base de datos — Firebird para el MES, SQL Server/COBOL para el ERP — pero los servicios
transversales (identidad, permisos, telemetría, documentación, IA) convergen en PostgreSQL. El salto está
aislado tras interfaces (IAuthProvider,
IAuthRepository): cambiar la fuente
de datos significa cambiar una implementación y una línea de bootstrap, sin tocar los módulos.
Tablas AUTH_* (recursos, acciones, roles, matriz de permisos, roles de usuario) y proveedor de identidad en PostgreSQL. FK reales, permisos e identidad co-ubicados.
Eventos aplicativos y de seguridad consolidados en ml_app_events en PostgreSQL, con patrón outbox desde el SyncEventHub.
Con pgvector, los embeddings viven junto a los datos: ninguna segunda base de datos, búsqueda semántica donde ya está la información.
// La identidad es abstracta: Firebird hoy, PostgreSQL mañana if HasAuthProvider then Result := CurrentAuthProvider.Authenticate(AUser, APwd) else Result := LegacyLogin2(AUser, APwd); // fallback // Cutover a PG = una línea de bootstrap: SetAuthProvider(TAuthPgProvider.Create(connPG));
Dashboard, telemetría, auditoría, documentación, log y sincronización no son opciones por módulo: son servicios del framework. Un scaffolding conforme a las reglas del servidor MCP (scaffold_module) los engancha automáticamente — un módulo generado nace ya observable, trazado y documentado.
Un sistema transversal que sirve a tres públicos con una única arquitectura. Cada módulo accede vía TMLHelper: un uses, cero dependencias adicionales.
Captura errores, mide rendimiento, documenta decisiones de arquitectura. Browser ML para navegación cross-módulo.
Ayuda contextual con botón ? en cada frame. Tips, avisos, guías. Late-binding: si ML no está cargada, fallback graceful.
Panel de diagnóstico con badge de eventos. Creación de tickets con contexto automático. Visor de eventos con detalle.
Autenticación y autorización bien hechas: modelo de permisos centralizado, enforcement declarativo, auditoría en PostgreSQL. Checklist interna OWASP ASVS L1, cimientos listos para verificaciones futuras.
Recursos, acciones y roles en tabla. Un permiso es el par (recurso, acción); un rol es un conjunto de permisos; el usuario recibe uno o más roles. Complementario al modelo de niveles/entidades existente.
Guardias configuradas en JSON sobre formularios, menús y acciones. Rollout incremental "uno a la vez", con fail-open mientras el enforcement no esté activo en el módulo.
Quien crea no aprueba. Base APPROVE ya separada, control dinámico sobre acciones sensibles con override trazado.
Eventos de seguridad (login, acceso denegado, override) en PostgreSQL. Cadena hash append-only: la propiedad "no manipulado" sin blockchain.
Es el punto central de la arquitectura: SyncFramework mantiene alineadas bases de datos heterogéneas (SQL Server/COBOL del ERP, Firebird del MES, PostgreSQL de la plataforma) con un engine bidireccional basado en hash que no requiere triggers ni timestamps en las tablas de origen. Cada sistema queda en su lugar; los datos permanecen coherentes.
ERP / COBOL
Engine basado en hash
MES local
Plataforma · IA
Deletion tracking sin modificar las tablas de origen. Garbage collector para la limpieza automática de las entradas obsoletas.
Ejecución multi-perfil en paralelo. Cada perfil tiene source, target y transform configurables.
Registros fallidos trazados con retry. Conflictos gestionados con política configurable por perfil.
Consola y servicio. Heartbeat en la BD para la monitorización. Graceful shutdown.
PostgreSQL debajo, Ollama al lado, MCP como puente hacia los modelos.