Module sim 

keel sim <plan> — fault/latency/crash-restart simulation over a declarative plan (docs/sim-format.md; architecture-spec §8: v1 scope is ADAPTER-LEVEL fault injection, not full hermetic/wasmtime determinism).

This module owns the parts that are genuinely CLI-shaped:

• dispatch the plan’s target/args exactly like keel run (via run::plan), with KEEL_SIM_PLAN (read by the language front ends’ SimBackend) and KEEL_EVENTS=1 (force the Tier 1 event sink on, so assertions always have something to read) layered onto the child;
• detect a child that died to a signal (a "crash" directive fired) and re-invoke the same plan against the same script, up to max_restarts times — the fault-plan front end persists its own per-target cursor across the restart (docs/sim-format.md “Crash-restart”), so this loop only needs to know “did it die, and how many times has that happened”;
• after the loop settles, aggregate every event file the run(s) produced under .keel/events/ (diffed against what existed before the sim started) and check the plan’s assert block against them, plus the newest flow row in .keel/journal.db when assert.flow_status is set.

What actually injects a fault into an attempt lives entirely in the front ends (python/keel/src/keel/_sim.py, node/keel/src/sim.mjs) — this module never parses the plan’s faults block, only target/args/ max_restarts/assert (the fields it needs to drive and grade the run).

Functions

run

keel sim <plan> for project: dispatch, crash-restart-drive, then grade.

run_with

Like [run], but lets the caller layer extra configuration onto every spawned Command before it runs (an integration test’s PYTHONPATH, a hermetic KEEL_BACKEND, …) — mirrors crate::run::exec_with’s configure hook. run is exactly run_with(project, plan_path, &|_| {}).