Crate areev_run 

areev-run — the areev run driver

A host over Areev (governed-agents §4), peer of areev-mcp: executes OMS Workflow grains through the pure scheduler (areev-run-core), journaling every effect as content-addressed grains — intent before dispatch, result as a supersession re-stating identity and links — with checkpoints per superstep, resume from the file alone, HITL respond with separation of duties, budgets, cancel, and journal-consistent verify.

The replay contract (§5, stated honestly): the journal is exactly-once — a result-journaled effect is never re-executed or double-counted, across interrupts and across crashes. The external effect is at-most-once per attempt in normal operation and at-least-once across the dispatch-to-result crash window: a dangling intent re-delivers under the same idempotency key and the redelivery is journaled as an Observation — recorded, never silent.

Re-exports

pub use clock::Clock;

pub use clock::ScriptedClock;

pub use clock::SystemClock;

pub use executor::CommandExecutor;

pub use executor::ExecResult;

pub use executor::ExecutorRegistry;

pub use executor::HostToolExecutor;

pub use manifest::BudgetsSpec;

pub use manifest::ForkBase;

pub use manifest::PinnedTool;

pub use manifest::RunManifest;

pub use runner::CrashPoint;

pub use runner::OnDangling;

pub use runner::RunOptions;

pub use runner::Runner;

pub use otel::OtelObserver;

pub use stream::RunEvent;

pub use stream::RunObserver;

Modules

clock

The ONE place the runtime reads the wall clock. Every reading flows into the scheduler as EventIn::ClockReading and is journaled in decision records — the scheduler core cannot tell the time (its clippy.toml and the CI dep-tree check enforce it), so this seam is the whole clock surface, and replay/verify substitute journaled readings here.

executor

Host tool execution (§4’s concurrency rule): a bounded thread pool runs effects in parallel; ALL store writes stay on the driver thread. The executor is a host-supplied trait — Areev never executes anything itself (Tool grains are data; execution is the host’s job), it hands the host a name, a pinned definition hash, the input, and the deterministic idempotency key the crash-redelivery contract depends on (§5.3).

journal

The journal writer/reader (governed-agents §5.1) — the driver half of the replay contract. Uses ONLY existing vocabulary: an intent is a Tool grain stamped Pending before dispatch; its result supersedes it, re-stating run_id, the mg:step_action link, and every key field — supersession flips the intent’s link rows off the current set, so a result that forgot to re-state would erase the node’s execution record (the store-level trap pinned by superseding_an_execution_record_needs_the_link_restated).

manifest

The run manifest (§5.3/§6.1 V7): everything a resume must know, written ONCE at run start — the plan hash, the frozen tool resolutions, the budgets, the principal, the redaction posture. Persisted through the facade’s record_run_manifest shape (a value-level State at epoch 0 + a run:<id> mg:harness <hash> Fact), so the manifest replicates with the file and runs_touching can join runs to their configuration.

otel

OpenTelemetry export (Wave 5): a §6.10 observer that turns run events into OTLP/HTTP JSON spans — hand-rolled over std::net::TcpStream (dependency-light policy: no HTTP client crate, no OTel SDK). One POST per run, flushed at RunFinished, so a collector outage costs one buffered batch, never scheduler time — the bus already guarantees the run never waits on an observer.

reducers

Typed reducers (§6.5): per-key merge functions, declared on the Workflow grain (reducers: {state_key: name}), FROZEN into the manifest at resolve — a resume must merge exactly as the original run did, so the choice can never live in host configuration.

runner

The driver loop (§5.3): start, resume, respond, cancel, verify. All store writes happen HERE, on the driver thread, in the order the pure core commands them — intents before dispatches, results before their bookkeeping, checkpoints as commanded. Parallelism lives exclusively in the executor pool.

stream

Streaming (§6.10) — observational only. Events describe what the driver journaled; they never carry authority and never backpressure the scheduler: emit is non-blocking by construction (bounded buffer, drop-oldest + counter), and the subscriber runs on its own thread. The §6.10 check is that journals are IDENTICAL with no subscriber, a subscriber, and a deliberately slow subscriber.

Structs

ShadowReport

A shadow evaluation over N journaled runs — the §7.4 pre-apply check for Tier-B code (“shadow replay of N recent journaled runs, zero effect dispatches, before Apply”).

ShadowRun

One run’s row in a shadow evaluation (§8 Wave 4): replayed entirely from its journal — zero effect dispatches by construction (the shadow path holds no executor, no pool, and no LLM; there is nothing to dispatch TO).

VerifyReport

The verify report: journal-consistency per checkpoint, honest about what was NOT verifiable (missing results, parks).

VerifyStep

One verify finding (§5.5 tiers, labeled output).

Enums

CoreRunError

A runtime failure with a stable RUN-Ennn code.

CoreRunOutcome

Terminal run outcomes.

FailCause

The §6.3 retryability table’s input — mirrors areev_core::types::FailureCause without depending on how the driver spells it on the grain.

RunSession

What a drive returned to its caller.

Functions

err_run

Map a store failure into the RUN domain (the underlying DOMAIN-Ennn message survives in the detail).