Architecture
Ironloom routes work through a typed process graph. The supervisor validates policy, selects a worker, records immutable artifacts under .ironloom, and reports outcomes back to the originating control surface.
Adapters for Discord, GitHub, and SonarCloud stay at the edges. Business rules live in core crates, policy, the process graph, workers, and the supervisor.
Runtime Boundaries
Boundary Rules
ironloom-runtimeis the deployable service and composition boundary.ironloom-supervisorowns process routing and worker registry dispatch decisions.ironloom-discordis the operator control-plane adapter and verifies signed Discord HTTP interactions before handling them.ironloom-githubreads GitHub source-of-truth state through auditable API requests before supervisor decisions.ironloom-sonarcloudowns SonarCloud bootstrap validation, quality gate polling, and issue normalization.ironloom-storageowns direct.ironloom/filesystem access.
First Vertical Slice
- A signed Discord command interaction is accepted on the runtime HTTP port.
- The runtime resolves the Discord thread to exactly one persisted work item and fails closed for missing or ambiguous bindings.
- The supervisor selects the gate worker through the process graph and dispatches it through the worker registry.
- Policy permits only a thread-bound non-destructive gate action.
- The gate worker runs an allow-listed command with controlled environment, timeout, and captured streams, then returns a structured result.
- Storage writes an immutable artifact under
.ironloomand indexes it by thread and work item. - The runtime returns a Discord channel message response to the originating interaction.
Contributors
Vanna DiCatania