Module resume 

keel flows resume <FLOW> [-- ARGS…] / keel flows resume --all — re-invoke a resumable flow’s recorded entrypoint through keel run semantics (architecture spec §4.3 “Recovery … re-execute”; §6 laptop model “a crashed script resumes when re-invoked”).

What the journal actually lets the CLI know

The frozen schema (contracts/journal.sql) records a flow’s identity — entrypoint ("py:<module>:<function>") and args_hash (a one-way digest) — never the script path the user originally typed at keel run <script>, nor the literal CLI arguments. That is enough to recognize a flow’s provenance but never enough to reconstruct the exact command that created it. This command is the honest middle ground between pure re-invocation (dx-spec/§6, which asks the operator to remember the command) and a fully automatic background scan (§4.3, which would face the identical gap with nobody present to fill it in) — it does the lookup and the eligibility checks, and is explicit about what it cannot know:

• The script. A py:<module>:<function> entrypoint’s module maps to a candidate file the same way the Python front end’s match_flow (python/keel/src/keel/_flow.py) matches one on the way in: a dotted module (jobs.nightly) names an exact path (jobs/nightly.py); a single-component module (pipeline) matches any pipeline.py under the project, so this command searches the tree for one. Zero matches, or more than one for a single-component module, and it stops rather than guess.
• The arguments. args_hash cannot be inverted. Passing none reproduces the original flow_id only when the original invocation also had none; otherwise the front end derives a different deterministic flow_id (spec §4.3) and a fresh flow starts next to the one this command was asked to resume. Pass the original arguments after -- when the flow took any. After the child exits, this command re-reads the flow’s updated_at and says plainly when it looks like the wrong flow ran.

Non-py: entrypoints (no other front end designates durable flows yet), completed flows (nothing to resume — see keel replay), and dead flows (KEEL-E032, never auto-resumed) are refused with a precise what/why/next; see [Ineligible].

Structs

ResumeOptions

keel flows resume options: either one flow (id or substring) or all, never both — args only makes sense for a single flow.

Functions

run

keel flows resume for project: dispatch to the single-flow or --all path, judging leases and the retention-adjacent “already gone” case against now_ms. Rendered is only ever produced for a precondition failure or the --all summary — a single successful resume is invisible on the way in (like keel run), because the child IS the resume.