Skip to main content

Module flow

Module flow 

Source
Expand description

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
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.
VerdictSource
Where a stage’s verdict came from.

Constants§

DEFAULT_FLOW_NAME
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).
resolve_verdict
Resolves a stage’s verdict, source, and reason from its exit-code reading and an optional reported verdict.