Module draft 

Non-interactive draft core (roadmap f-1-1): the sequencing behind kranz draft, hoisted out of the CLI so any surface (CLI, REST) can drive a ticket through its planning conversation.

drive_draft owns the engine call order — write_state(Drafting) → record_mission → planning_turn (seeded with the whole ticket) → request_plan → branch on the result — and the terminal filesystem/queue side effects (Ticket::append_needs_context, Ticket::append_wrong_plan, approve_plan, queue::enqueue). It does not print anything and does not touch the operator’s git checkout; both stay with the caller.

Structs

DraftDrive

drive_draft’s return: the terminal DraftOutcome plus the display payload a caller needs to reproduce the pre-hoist CLI output exactly — the seed reply (from the session-start turn) and, on the Approve path, the approved Plan. The core itself never prints either; it only avoids dropping them.

Enums

DraftDecision

What a draft turn resolved to, given the PlanRequest and whether --yes (auto-approve+enqueue) was passed. Separating the decision from the I/O keeps the state-machine unit-testable without a backend.

DraftOutcome

Terminal result of driving one ticket through a draft turn.

Functions

draft_decision

Map a completed plan request + the --yes flag to the next action. Pure: the caller performs the git/state side effects the decision names.

drive_draft

Drive ticket through one non-interactive draft turn against an already-constructed engine (holding its backend): seed the orchestrator with the whole ticket, demand the plan, and resolve via draft_decision.

looks_like_plan_json

Does a NotReady reply look like a COMPLETE plan the orchestrator chatted out as prose instead of returning through the plan channel? Matches the plan schema’s two distinctive top-level keys.

split_questions

Split the orchestrator’s “not ready” prose into individual questions: each non-empty line, with any leading bullet/number marker stripped. A reply with no line breaks becomes a single one-item list.