Struct Runner 

pub struct Runner {
    pub facade: Arc<AreevFacade>,
    pub clock: Arc<dyn Clock>,
    pub executor: Arc<dyn HostToolExecutor>,
    pub llm: Option<Arc<dyn ToolCallLlm>>,
    pub observer: Option<Arc<dyn RunObserver>>,
    pub ns: String,
    pub principal: String,
}

The runtime driver: a host over one facade.

Fields

facade: Arc<AreevFacade>

clock: Arc<dyn Clock>

executor: Arc<dyn HostToolExecutor>

llm: Option<Arc<dyn ToolCallLlm>>

The tool-calling model for abstract nodes; None = abstract nodes refuse at load (RUN-E006).

observer: Option<Arc<dyn RunObserver>>

§6.10 streaming subscriber; None = no events. Observational only — a slow observer delays (and eventually loses) events, never the run.

ns: String

principal: String

Implementations

impl Runner

pub fn start( &self, plan_hash: &Hash, run_id: &str, input: Value, opts: &RunOptions, ) -> Result<RunSession, RunError>

Start a new run of the Workflow at plan_hash and drive it until it finishes or parks on a Client ask.

pub fn resume( &self, run_id: &str, opts: &RunOptions, ) -> Result<RunSession, RunError>

Resume a run from its latest checkpoint: settle expired asks, adopt journaled responses, re-deliver dangling intents (§5.3).

pub fn fork( &self, base_run_id: &str, at_superstep: Option<u64>, new_run_id: &str, new_plan: Option<&Hash>, opts: &RunOptions, ) -> Result<Hash, RunError>

§5.4 time-travel fork: a NEW run descending from one of base’s checkpoints. The fork’s manifest records (base_run, base_checkpoint), an mg:fork_of Fact indexes the relationship, and the SEED checkpoint derived_froms the base checkpoint — the verifiability chain. The base run is never touched.

• Same plan (new_plan = None): the base checkpoint’s scheduler state carries over under the new run id; the fork re-executes everything past the checkpoint under its own journal keys. A BudgetExhausted terminal re-opens (that is how a run continues under raised budgets — budgets are the fork’s own knobs).
• New plan (in-flight migration): full §6.1 validation re-runs; the graph restarts at its entry with the base checkpoint’s CONTEXT as the input.

v1 refuses forking a checkpoint that parked mid-superstep (pending asks address journal keys of the parent) — pick a closed superstep.

Returns the seed checkpoint hash; resume continues the fork.

pub fn respond( &self, run_id: &str, tool_call_id: &str, result: Value, is_error: bool, responder: &str, ) -> Result<(), RunError>

Answer a Client ask (§6.6’s validation order). Responding and resuming are separate acts: this writes the journaled result and returns; resume spends the compute.

pub fn cancel( &self, run_id: &str, principal: &str, reason: &str, ) -> Result<(), RunError>

Write the cancel marker (the kill-switch primitive). The drive loop polls it every iteration; resume after cancel drains.

pub fn shadow_eval(&self, run_ids: &[String]) -> ShadowReport

Shadow evaluation (§8 Wave 4): journal-consistent replay of the given runs, writing nothing and dispatching nothing — the verify path holds no executor, no pool, and no model, so “zero effect dispatches” is a property of the code shape, and the report states it explicitly for the §7.4 pre-apply gate. A run that fails to load is reported inconsistent, never skipped silently.

pub fn recent_runs(&self, limit: usize) -> Result<Vec<String>, RunError>

The run_ids of the most recent runs in this namespace, newest first — manifest link Facts in agent:harness are the census.

pub fn verify(&self, run_id: &str) -> Result<VerifyReport, RunError>

§5.5 gate 1 / verify tier 1: journal-consistent replay. Re-drives the run from the manifest’s input with the clock scripted from journaled readings and every effect answered from the journal — writing NOTHING — and byte-compares every checkpoint the replay commands against the stored chain. A missing journaled result stops verification at that step (reported, not asserted); a divergent checkpoint is the RUN-E009 condition, reported with both hashes.