Skip to main content

Module fold

Module fold 

Source
Expand description

Deterministic RunLog → CheckpointView folding.

Checkpoint = deterministic fold of the RunLog (spine §6.1); this module is that fold, exposed as the pure function fold_checkpoint so the rebuild channel (pointlock inspect --rebuild-checkpoint, 07 §3.3) and the write-path materialization share one implementation and can be equality-checked against each other.

§Fold inputs

The 17-event union does not carry the root flow id or the provider binding, so the fold takes a RunMeta (the run table row written by crate::Store::begin_run) alongside the ordered events. Both inputs are immutable after begin_run, keeping the fold a pure function of durable state.

§Coverage rules (iron rule: explicit, never silent)

Every one of the 17 event types is matched explicitly below. Events that do not change the view are handled as documented no-ops, not wildcard arms. Every StepRecord field has an event carrier (spine §6.1 M1 note — no placeholders remain):

  • StepRecord.effectHash / judgeHash / resolvedInputs: harvested from the stepEntered payload.
  • StepRecord.output: harvested from the stepExited payload; a call step whose exit carries no output keeps the callee outputs harvested from callFramePopped.
  • CallFrame.nextIndex: a body cursor — advanced only when the exited step is a direct body child of the innermost frame (nested container children and iteration instances do not move it; M2).
  • CallFrame.iterStack: reconstructed from the open container spans — an in-flight span whose successor extends it with an iteration path frame is a live foreach; the as name comes from the container’s stepEntered snapshot ({ items, as }, the runner’s foreach carrier). No carrier ⇒ no IterState (never fabricated).
  • CallFrame.vars stays empty in the fold: let products have no dedicated event carrier (the stepEntered snapshot of a let step is the bindings object, but the fold is kind-agnostic); the runner re-seeds scope from the records on resume (documented divergence, pending the handler wave).
  • binding.sessionLineage / binding.eventCursor: copied verbatim from RunMeta; no event advances the cursor or appends a session generation yet (M1 scope).
  • runResumed.alignmentReport stays log-resident; the fold does not re-base completed records.

Structs§

FoldedRun
Result of a fold: the materializable view plus the run status the same event sequence implies (kept together so the write path and the rebuild self-check share one transition function).
RunMeta
Immutable per-run metadata (the run table row): the fold input the 17-event union does not carry — root flow id, provider binding seed, and the identity fields also present in runStarted.

Enums§

RunStatus
Run lifecycle status — the run.status column’s closed four-value set (07 §3.3 DDL CHECK constraint).

Functions§

fold_checkpoint
Folds an ordered event sequence into a CheckpointView + run status.