Module replay 

keel replay <flow> — journal-driven replay inspection (architecture spec FR6; dx-spec §5–6).

A dry run: it opens .keel/journal.db read-only, walks the recorded step ledger, and renders exactly what re-entering the flow WOULD do — which steps substitute from the journal, which re-execute live, where the replay cursor stands, and what the nondeterminism defense will hold each step to. No effect fires and nothing is written; actual re-execution stays with keel run / a front-end resume.

The verdict mirrors the core’s semantics (keel-core/src/flow.rs, normative in conformance/README.md):

• completed → pure replay: every step substitutes, no effect fires; a step beyond the ledger is nondeterminism (KEEL-E031).
• running / failed → resume: terminal (ok/error) records substitute; a crashed-mid-step running record re-executes live; the flow continues live past the ledger. Each resume consumes one flow-level attempt, and a still-live lease refuses the resume (KEEL-E030).
• dead → refused: never auto-resumed (KEEL-E032); inspection only.

Internal marker rows never render as steps, but they are read: the reserved seq-0 counter reports how many resumes the flow has consumed, and flow:branch:* markers surface as recorded nondeterminism divergences with their expected/observed keys.

Determinism (dx-spec §5): the --json twin carries only values read from the DB — timestamps are the recorded ms integers, never wall-clock — so identical journals give byte-identical output.

Functions

replay

keel replay <flow> [--step N] for project. flow resolves like keel trace (exact flow_id, else a unique substring of id/entrypoint).