modernize-preflight

Check whether this environment is ready to analyze — and eventually transform — legacy/$1, and tell the user exactly what to fix before the other commands run into it. Modernization sessions fail late and confusingly when this isn't done: assessment metrics silently degrade without analysis tools, characterization tests can't run without a build toolchain, and dependency maps come out wrong when half the source isn't in the tree.

Run every check even when an early one fails — the point is one complete readiness report, not the first error.

Check 0 — Ask the human (these answers are not in the source)

Before any automated check, ask the person running this command the five questions below. The most expensive modernization mistakes are things a person who knows the system answers in seconds and that cost real money to discover wrong from the source alone. Ask only these — add none — and accept "don't know" for any of them.

Ask, then do not block on the answers. None of Checks 1–6 needs one (Check 6 verifies the scope boundary from the source independently — the human's answer says whether a crossing matters, not whether it exists), so proceed to the checks immediately after asking and write the report with whatever answers exist by then. Any question still unanswered goes in the report verbatim, marked as an open item the human must fill in — it is not dropped. This way an interactive user answers while the checks run, a headless or scripted run still produces a complete PREFLIGHT.md, and the one thing that never happens is a readiness report silently missing the questions.

1. Scope — Is legacy/$1 the complete system, or one slice of a larger codebase? If a slice: what outside it depends on code inside it, and is breaking those consumers acceptable? (Check 6 verifies this from the source independently; the human's answer says whether it matters.)
2. Build & test locally — Can this environment restore, build, and run the tests? Roughly how long does the full CI pipeline take? (A pipeline measured in hours changes the whole validation strategy: you cannot afford to first learn you were wrong from CI.)
3. Bespoke build infrastructure — Is there organization-specific build or dependency-resolution machinery (an internal package feed, a custom binary store, a code generator, a wrapper around the standard build tool) that someone new to this codebase would not guess? Where is it documented?
4. Prior attempts — Has anyone tried to modernize any of this before? What went wrong?
5. Off limits — Is anything under legacy/$1 not allowed to change in this pass (a component another team owns, a frozen branch, generated code)?

Record every answer verbatim in the report — downstream commands, and /modernize-brief most of all, read them from there. Do not paraphrase away a caveat the human gave you.