Module flow 

Flow definitions and the pure walk over them. Parsing turns a committed YAML file into a validated Flow; next_step then turns a flow and the evidence gathered so far into the next stage to run or a terminal reading. Neither half touches a clock, a process, or the store, so policy can be tested without a daemon.

Structs

Flow

OnFail

A stage’s optional repair configuration. It configures the repair worker (prompt, attempt budget, and target/model/effort overrides) but can never alter the stage’s verdict policy, command, or ordering.

Reported

A worker’s self-reported verdict for the stage it is running, gated to at most one report per stage.

Stage

StageEvidence

One stage’s recorded result. Rows persist as they are produced, so a daemon crash mid-flow resumes idempotently at the first stage without a row: next_step re-derives the same answer from the same rows.

Enums

StageKind

Step

What the walk does next, given a flow and its evidence so far.

Verdict

A stage’s pass/fail reading. Richer verdicts (e.g. changes-requested) are a later phase; v1 is strictly binary.

VerdictPolicy

VerdictSource

Where a stage’s verdict came from.

Constants

DEFAULT_FLOW_NAME

MAX_ON_FAIL_ATTEMPTS

The inclusive upper bound on on_fail.attempts.

REVIEW_PROMPT_INSTRUCTION

REVIEW_PROMPT_PATH

Functions

next_step

The pure decision at the heart of a flow: given the flow and the evidence recorded so far, what runs next. Linear and halt-on-fail, with no notion of loops, branches, or retries (see sloop-flows.md §4).

parse

resolve_verdict

Resolves a stage’s verdict, source, and reason from the evidence selected by its policy. Reports are authoritative only for Reported; other policies ignore them.