Module flows_suggest 

keel flows suggest — replay-safety analysis over candidate flow entrypoints (dx-spec §1 Level 2: “Durability, still config-only”).

Combines two evidence sources exactly like keel init does (dx-spec §2): the static scan’s per-function attribution (scan::FunctionFacts — intercepted-effect call sites, idempotent-unsafe effects, time/random reads Tier 2 would virtualize, and constructs that defeat replay outright) and .keel/discovery.db’s observed call counts, joined on the targets a function’s effects reference. A function is a candidate when it performs at least one intercepted effect — a pure helper has nothing to make durable.

Verdict. replay-safe: NO only when the scan found a construct that defeats replay outright (unsafe_reasons: threads, subprocesses, raw sockets, child_process/worker_threads). Idempotent-unsafe effects and time/random reads do not flip the verdict — Tier 2 injects an idempotency key into retried effects automatically (CCR-2, contracts/adapter-pack.md) and virtualizes time/random reads on replay; they are surfaced as context for the reviewer, not blockers.

Ranking. Candidates are ordered by observed traffic first (the functions actually being exercised are the best flow candidates), then by effect count, then by (file, line) as the final deterministic tie-break (dx-spec §5) — never by insertion order alone, so a re-run against unchanged evidence reproduces byte-identical --json output.

Honesty about coverage. The JS/TS pass attributes by a brace-depth line heuristic, not a parse (scan::js module docs) — it cannot see class methods, object-literal methods, or a function whose opening { sits on its own line. Python attribution is exact (real ast containment). Both python_available and a fixed note about the JS/TS limitation ride along in the report so --json output never overclaims precision it does not have.

Structs

Candidate

One candidate flow entrypoint — the machine twin of one keel flows suggest line.

Functions

run

keel flows suggest for project.