Arquitectura
Ironloom enruta trabajo mediante un process graph tipado. El supervisor valida políticas, selecciona un worker, registra artefactos inmutables bajo .ironloom y reporta resultados a la superficie de control de origen.
Los adaptadores de Discord, GitHub y SonarCloud permanecen en los bordes. Las reglas de negocio viven en crates core, policy, process graph, workers y supervisor.
Límites del runtime
Reglas de límite
ironloom-runtimees el servicio desplegable y el límite de composición.ironloom-supervisorposee las decisiones de enrutamiento de procesos y despacho mediante el registro de workers.ironloom-discordes el adaptador del plano de control del operador y verifica interacciones HTTP firmadas de Discord antes de procesarlas.ironloom-githublee el estado fuente de verdad de GitHub mediante solicitudes API auditables antes de las decisiones del supervisor.ironloom-sonarcloudposee la validación de bootstrap de SonarCloud, el polling de quality gates y la normalización de issues.ironloom-storageposee el acceso directo al sistema de archivos.ironloom/.
Primer corte vertical
- Una interacción firmada de comando de Discord se acepta en el puerto HTTP del runtime.
- El runtime resuelve el hilo de Discord a exactamente un work item persistido y falla cerrado ante vínculos faltantes o ambiguos.
- El supervisor selecciona el worker de control mediante el process graph y lo despacha por el registro de workers.
- La política permite solo una acción de control no destructiva vinculada a hilo.
- El worker de control ejecuta un comando permitido con entorno controlado, timeout y streams capturados, y devuelve un resultado estructurado.
- Storage escribe un artefacto inmutable bajo
.ironloomy lo indexa por hilo y work item. - El runtime devuelve una respuesta de mensaje de canal de Discord a la interacción de origen.
Contributors
Vanna DiCatania