cadrumo.application.flows.line_frontend module

The line-mode frontend: sequential paging over the engine, no full screen.

This is the degradation tier for hosts that cannot run the full-screen TUI: a forward-sequential walk that renders each page’s assembled copy (prompt, help, format hint, failure modes, current-answer echo) as plain lines, prompts through questionary primitives on injectable prompt_toolkit IO, re-prompts in place on a failing verdict, and finishes in a review loop that lists every page with its status and offers edit-by-number, restart, save-and-exit (only where the definition declares checkpointing for the mode — the no-op arm renders an explicit unavailability line instead), and submit.

The frontend contains zero flow logic: every semantic — visibility, validation, staleness, deferral, submit eligibility — is an engine transition or projection. Back-navigation in line mode is served by the review loop’s jump-to-edit; free cursor movement is the full-screen frontend’s job.

IO injection mirrors the retired one-shot prompter’s contract: explicit input/output devices host the prompts (the headless pipe-input test drive), and an un-injected frontend applies the full non-TTY / Windows no-console refusal before any progress.

class LineFlowFrontend(definition, *, input=None, output=None, checkpoint_store=None, on_answer_committed=None)[source]

Bases: object

Sequential line-mode projection of one flow run.

Parameters:
ensure_interactive_environment()[source]

Refuse before progress when this process cannot host prompts.

A frontend carrying explicit IO is already bound to a device that can host a prompt, so the process-stdio probe does not apply to it.

Return type:

None

run(*, mode, resume_state=None)[source]

Walk the flow to a submitted state and return it with its projection.

resume_state continues a projection built by resume_flow; otherwise the run starts fresh. The walk prompts every visible unanswered page in order, then enters the review loop until the operator submits, or saves and exits — the save is performed HERE, through the checkpoint port, before the state is returned; the caller never re-persists (single writer).

A mode whose definition declares checkpointing AVAILABLE demands an injected store: refusing up front is what keeps the save-and-exit affordance honest — a mis-wired frontend must never offer a save it cannot perform and then silently discard.

Return type:

tuple[FlowState, ReviewProjection]

Parameters: