One Default Build Path, No Startup Triage
Plain plan builds now go straight to the milestone driver, with the startup classifier and its build-family flags removed.
Every time Gantry started a plain build from a plan file, it first ran a small classification step to decide which build family to use: a flatter sprint pipeline for small plans, or the milestone decomposition for large ones. That decision happened at startup, before any work began, and it came with user-facing flags for forcing one family over another. The branching meant two live build paths to keep working and to explain.
This job collapsed the default to a single path. A plain `gantry <plan>` now goes directly to the milestone driver, which itself folds a small plan down to a single flat pass. The classification step — Gantry called it triage — was deleted along with its prompt, its agent, and the interface that showed it running, and the build-family flags were retired. Runs that had already been recorded under the old flat build still resume the way they always did; only the choice made for new builds changed.
Build
The removal was cut into three sprints under one milestone, ordered so the default-selection change came first and turned the classifier into dead code the next sprint could simply delete. The gate's single rejection landed on the closing documentation sprint.
The milestone owned the entire change, and its internal split is where the reasoning lives. The first sprint changed only default selection: a flagless build resolves to the milestone driver without consulting the classifier, while explicit design, redesign, and map modes keep winning through their own flags, and persisted flat runs keep resuming on their recorded driver. That sprint's brief is explicit about why it comes first — once selection no longer depends on classification, the triage code is unreferenced and can be deleted outright, rather than surgically separated from live dispatch. The second sprint then removed the classification stage, its prompt, its agent entry point, and the state and rendering that showed it running. Sequencing it this way meant the risky deletion operated on code that nothing called anymore.
A single constraint ran through every piece: the flat sprint pipeline had to stay intact for runs already persisted under it, and only new-run selection was permitted to change. Each brief restates that boundary, which is what kept the removal from widening into a rewrite of the pipeline itself.
The two code sprints cleared their gates directly. The gate's one rejection fell on the last sprint — the one aligning the user-facing documentation and prompt catalogs with the new behavior — and a fix followed before it landed green. No review forced a re-plan, and the milestone's boundaries held across the whole removal.
Feature
Before this job, Gantry chose a build family by running a classifier at startup and exposed flags to override it. Now the plain build path is unconditionally the milestone driver, the classifier and its flags are gone, and the change still holds at HEAD.
Before this change, the first thing a plain build did was decide what kind of build it was. A classification step ran at startup and routed the plan either to the flat sprint pipeline or to the milestone driver, and a set of build-family flags let a caller force the outcome. Two live routes meant two behaviors to reason about whenever selection came up.
What replaced them is a single unconditional default. A plain plan build now enters the milestone driver, and that driver collapses a modest plan into one flat pass internally, so the flat behavior survives without being a separately selectable mode. The old build-family flags remain only as hidden, deprecated aliases that warn once and route to the same milestone driver. Runs recorded under the flat build still resume on their original driver, read from their stored job kind.
Standing in the tree today, the removal has held: no triage code is left in the build engine, and the prompt file that drove it is gone. The documentation matches — the driver table names the milestone driver as the default for a plain build and lists the build-family flags only as compatibility aliases. The one visible drift is in the resume path this job set out to protect: the file that held the flat sprint driver no longer exists as its own module, yet the pipeline it guarded is still reachable, since the sprints job remains a resume-only driver for persisted flat runs. That compatibility promise stands even though the code behind it was later reorganized. Several files that carried the change have been substantially rewritten since, as the build engine kept evolving, but the arrangement this job established — one default, no classifier — is still what a plain build does.