Module record 

keel record — capture effects during a run, then turn the capture into an offline replay fixture + generated test glue (dx-spec §6 standing structure item 5; docs/recording-format.md).

Subcommands:

• keel record run <script> [args…] — exactly keel run <script> [args…] (same dispatch via run::plan/[run::exec_with], same exit-code passthrough), plus KEEL_RECORD=<fresh path> in the child’s environment. The front end (not this binary) does the actual capture — see python/keel/src/keel/_record.py, node/keel/src/record.mjs.
• keel record list — recordings under .keel/recordings/, newest first.
• keel record test <recording> [--out DIR] — generate a pytest fixture (Python recording) or node:test file (Node recording) from a completed recording.

Non-contract end to end: the .ndjson line format lives entirely in the front ends and is versioned but outside contracts/ — this module only reads/writes plain files under .keel/recordings/, never contracts/.

Constants

RECORDINGS_SUBDIR

The subdirectory of .keel/ holding recordings (mirrors keel-core::events::EVENTS_SUBDIR’s convention for non-contract, per-run tooling data).

RECORDING_EXT

File extension of a recording (newline-delimited JSON).

Functions

list

keel record list for project: one row per .keel/recordings/*.ndjson file, newest first. A file that isn’t a readable Keel recording (no meta header) is skipped rather than failing the whole listing — best-effort, like keel tail’s NDJSON line hygiene.

run

keel record run <target> [args…]: plan the dispatch exactly like keel run, then exec with KEEL_RECORD set to a fresh path under .keel/recordings/ so the front end tees every intercepted call into it. Otherwise byte-identical to keel run — recording is a pure observer (docs/recording-format.md).

test_gen

keel record test <recording> [--out DIR]: read the recording’s meta header to learn its language, then write one ready-to-run generated test file next to it (or under out_dir).