preflight
Preflight
An unattended run stops for one of a handful of reasons: a ticket needs one that comes after it, a ticket leaves a decision to the agent, the app can't be driven end to end, a call hits production, or a prompt wants an admin. Preflight finds every one of them now, with the operator at the keyboard, and fixes the tickets so the run never meets them.
Two kinds of finding, kept apart throughout:
- A fact is the agent's to find — by reading, by sub-agent, or by a drill: a small, harmless, real execution that proves a claim instead of asserting it. Never ask the operator for a fact you can look up or drill.
- A decision is the operator's. Put each one to them; never settle one silently.
Preflight does not write a ticket's validation: the run works out which checks each ticket runs, in its own Methods phase, from the repo's validation catalogue (crew ADR-0035).
A blocker is a prerequisite the operator supplies once — a credential, a test account, an admin approval, a device — after which agents do the rest (ADR-0021). Preflight names each blocker with a command that shows it cleared.
1. Load
Read the spec, every sub-issue in list order with its body and comments, each one's blocked_by edges (see docs/agents/frontier.md, including its fallbacks for prose-only edges), and the repo's agent docs (CLAUDE.md, AGENTS.md, CONTEXT.md, docs/adr/), CI config and task runner. Done when you can list every ticket with its current blockers.