Module engine 

The driving loop, as a value.

update(State, Msg) -> (State, Vec<Cmd>) is the product; driving it is five lines that were written out longhand in six places, each with its own spelling of the surrounding loop. Engine owns the reducer state and the effect sink and exposes those five lines once:

  inbox ── Msg ──► observer ──► update(State, Msg) ──► (State, Vec<Cmd>) ──► sink

Three seams, one per axis the callers actually differ on: EffectSink (where a Cmd goes), StepObserver (what watches each message before the reducer consumes it), and DrivePolicy (when the loop stops).

Engine::drive is an actor loop, and EngineHandle names its two ends so something outside it — a daemon socket, a second view of one session, an SDK client — can send messages in and watch what comes out.

Engine::reduce — the kernel — is synchronous and observer-free on purpose: --replay folds a recorded log with no tokio runtime in sight, and keeping the kernel callable from a plain for loop is what proves this abstraction did not smuggle a runtime into the fold.

See docs/design/engine-extraction.md.

Structs

DrivePolicy

Everything that ends a drive, in one value.

DropEffects

Discards every command. --replay’s sink: the recorded log already holds each effect’s real-world result as a later Msg, so re-running the effect would both duplicate it and make the fold impure.

Engine

The reducer, its state, and where its commands go.

EngineGone

The drive that owned this handle’s inbox has ended.

EngineHandle

A running engine, reachable from outside its drive.

Inbox

The messages a drive pumps.

Observation

One message, as seen before update consumes it.

StepOutcome

What one reduction did that a driver has to act on.

Enums

DriveExit

When Engine::drive returns.

OnCancel

What a fired cancel token does to the drive.

StopWhen

How far Engine::drive runs.

Traits

EffectSink

Where a reducer-emitted Cmd goes.

StepObserver

A hook on every message an Engine pumps.