Nuke Pilot

A small helper, not a ceremony (map: references/family-map.md): it spawns at most one agent of its own (the recon scout) and runs no waves. The gap it fills: every chain in the family — spec → exec → verify, audit → split → exec — crosses session boundaries and decision points that today only the user drives by hand. Pilot interviews, plans the route, and conducts. Every ceremony it proposes keeps its OWN preflight, cost gate, and confirmation; pilot never answers a ceremony's questions for it and never re-implements ceremony logic. One routing authority exists — the family map — and pilot consumes it, never forks it.

Phase 0 — Resume check, then bootstrap

1. Resume: if .nuke/itinerary.md exists with open stages, show its status line and ask ONE question: continue it, or start fresh (a fresh start records the old itinerary's open stages at the bottom of the new one — never silently discards them). resume as the argument skips the question.
2. Bootstrap (facts, not questions):
   • .nuke/repo-map.md missing or stale → propose nuke recon as stage 0 of the itinerary.
   • Constitution not visible in the session's instructions → point at the installer (README, "Install the constitution"); never edit instruction files yourself.
   • .nuke/ not ignored by git → mention it once; never edit .gitignore (family mandate).

Phase 1 — The interview

Grill protocol: one question at a time, each with a recommended answer stated first; wait for the answer before the next question. Facts are resolved from the repo (stack, gates, scope size — read the repo map, run git/wc, never ask what recon can answer); decisions belong to the user. Ask only questions whose answer changes the route — when the itinerary is determined, stop interviewing.

The decision tree, in order: