Runtime architecture

Roder separates the stable harness from installable behavior. The core owns turn lifecycle, cancellation, policy, event ordering, tool routing, and provider loops. Extensions provide inference engines, tools, stores, policy contributors, event sinks, subagent dispatchers, and UI services.

The dependency rule

extensions  -> roder-api
core        -> roder-api
apps        -> roder-protocol
roder-cli   -> core + selected extensions

Extensions do not depend on roder-core. The core does not depend on provider crates. Distribution binaries compose the registry they want.

Turn flow

1. A client starts a turn through the TUI or roder-app-server.
2. roder-core assembles context and selects the configured inference engine.
3. The provider streams canonical inference events back into the runtime.
4. Tool calls are filtered by policy, routed through the registry, and emitted as events.
5. Tool results are appended to the turn until the provider reaches end-of-turn.
6. The final transcript and typed events are available to stores, sinks, clients, and replay tooling.

Eval deadline path

Eval-profile turns can carry an internal deadline. Near the reserve window, the runtime asks the model to checkpoint scoreable outputs, update the task ledger when required, then finalize without starting more tools. Command tools see the remaining deadline and clamp long process timeouts so failures become tool results instead of opaque external interrupts.

Core crates

• roder-api defines the contracts.
• roder-core executes turns against those contracts.
• roder-extension-host builds the default registry for the CLI distribution.
• roder-protocol keeps the app-server wire shapes separate from runtime internals.