The Fresh-Box Readiness Check and Release Path
gantry doctor for a clean machine, plus a path to shipping Gantry as a versioned binary
Gantry leans on tools it does not ship — git, bubblewrap, and whichever coding-agent CLI a run uses — and for a long time it simply assumed they were installed. On a fresh machine that meant a cryptic spawn failure deep inside a run instead of a clear "install this first." Gantry also had no real way to be handed to someone: it built only against a neighbouring source checkout, reported no version, and produced no downloadable binary.
This job addressed both. It added `gantry doctor`, a one-shot command that reports every external tool's status with copy-pasteable install commands and runs before any repository or run exists, and rewired the automatic startup check to read the same catalogue so the two cannot disagree. Alongside it, the job made the repository build on its own, gave Gantry a version to report, and laid out a way to produce versioned binaries for Linux and macOS, plus a quiet notice when a newer build is available.
Build
The run split into a preflight milestone and a release milestone, each ordered so its most-shared and hardest piece landed first, and every stage passed its gate on the first attempt with no retry and no re-plan.
The preflight milestone was cut around one catalogue module, which its brief names the keystone. The reasoning it states: because `gantry doctor` and the startup check both read a single enumeration of external tools, the two can never drift — and that property is only testable if the enumeration exists as a self-contained, injectable unit before either reader is written. So the module — the data model, the reuse of Gantry's existing sandbox and harness probes, the platform-to-hint mapping — was the first sprint and carried the milestone's only high-effort mark; the doctor verb and the startup refactor that came after were readers over work already proven.
The release milestone put vendoring first for a blunt reason the brief spells out: the repository pointed its menu-widget dependency at a sibling checkout, so a CI runner cloning Gantry alone could not build at all. Nothing else in the milestone could run until that crate was copied in as checked-in source. The version flag followed because the release smoke test needed a version to report, and the release-pipeline sprint — scoped to well-formed configuration rather than a locally runnable build, since genuine cross-compilation and notarization only happen on hosted runners — came after both.
The run never went red. The one boundary drawn to flex is the version-check sprint: its brief permitted either wiring the notice or leaving a written follow-up, so the milestone could not be held hostage by the piece hardest to exercise offline. Nothing here forced a repair, and the ordering is why — the shared, depended-on pieces were isolated and grounded before anything leaned on them, which is where a red gate would otherwise have appeared.
Feature
Before this job a clean checkout could not build alone and a missing tool failed cryptically mid-run; the preflight catalogue and doctor command answering that still stand today, while the release mechanism the job produced has since been replaced.
Before this job, Gantry's external-tool requirements were scattered inline assumptions: git was shelled throughout the engine with no check, the sandbox and auth probes sat in the startup path, and a missing tool surfaced as a raw error. The repository could not build from a clean clone at all, because its menu widget resolved to a sibling directory that a lone checkout does not have.
What the job left is a preflight module owning one catalogue — hard requirements like git, optional ones like bubblewrap including its userns-blocked degraded case, and each configured harness — with detection and install hints kept separate from the real binaries so the tests can drive them. At today's `HEAD` that module is still the largest single artifact of the run and has grown rather than shrunk; `gantry doctor` is a live bare verb dispatched ahead of the git-repository requirement, and the startup check reads the same catalogue. The menu widget is vendored under `vendor/`, and the convention took: two more sibling widgets now sit beside it. The version-check notice is present and wired into startup, its network fetch still a deliberate stub pointing at a manifest the website has yet to serve, with a follow-up doc recording the rest.
The release pipeline is where the tree has moved on. The cargo-dist configuration and the GitHub Release workflow this job produced are gone; a note in `Cargo.toml` now states plainly that Gantry is not released through a GitHub Release, and a local script cross-builds the static-musl Linux targets instead. The workflow file and its configuration test are both absent at `HEAD`. The preflight half of this job still runs on every start; the specific release mechanism it wrote was replaced by a simpler local build.