A Menu System for Gantry's Run Monitor
Rebuilding the terminal front-end around an action registry, a shared file viewer, clipboard copy, and live run statistics.
While Gantry builds a plan, you watch it through a terminal monitor — a full-screen front-end that shows the run's progress. Before this job, that front-end was driven mostly by memorized key bindings and a scattering of views, with no consistent way to open the very files the run produces. This job rebuilt it as a menu system. A bar of dropdown menus is backed by a single action registry, so every key and every menu item reads from one place. A shared read-only viewer opens the run's own artifacts — its ledger, its plan, each sprint brief, the reports — inside the monitor. Copy items put run details on the clipboard, a statistics view is folded live from the run's event stream, and a ticker along the bar shows progress at a glance. The aim was to make everything a run generates reachable and legible from where you already are, rather than through keystrokes you have to remember.
Build
The work was cut into four milestones ordered by dependency; the difficulty concentrated in the second, whose job was to build the two pieces every later menu reuses.
The plan split into four milestones, and their order encodes what depends on what. The first built the part everything else reads from: an action registry and a menu bar reconstructed from run state on each frame. Nothing could show a menu until that structure existed and was tested, because every later menu item and key binding is an entry in it.
The milestone that took iteration was the second — the one charged with building the two components meant to be reused everywhere: a read-only viewer for the run's files, and a mechanism for copying to the clipboard. Its briefs are explicit that each is built once and proven immediately against a real consumer: the viewer wired to the Tools menu's artifact items, the copy path to its copy items, so that the later Chat and Environment views would inherit an exercised component rather than an untested abstraction. That is exactly where the run's difficulty gathered. After the viewer sprint and the clipboard sprint each cleared review, a review twice re-planned the milestone's remaining work, and the environment-and-metadata sprint drew a review note that sent it back for a second implementation pass before it landed. The other three milestones ran green from start to finish.
The re-plans locate the strain. The reuse contract — one viewer, one clipboard, many callers — was the part the plan had to adjust as it built, and it adjusted it inside the milestone that owns that contract, before any downstream menu depended on it. Building each shared piece alongside its first real consumer is what kept those adjustments cheap: a cut that specified all the menus first would have met the same friction only after several were already written against the untested piece.
Feature
The registry-driven menus, the file viewer, the clipboard path, the live statistics fold, and the ticker are all still in the tree; what has since changed is how many titles the bar carries.
Before this job, you operated Gantry's run monitor by recalling which key did what, and the run's own output had no uniform way to be opened from inside it. The job answered that with a connected design: one action registry that both the menu bar and key dispatch consult, a single read-only pager that every open-this-file item renders through, a clipboard helper that falls back to a disabled item with a stated reason when no terminal clipboard is reachable, a pure fold over the run's event stream into glanceable numbers, and a ticker that draws from that same fold.
At the current HEAD the machinery is intact. The artifact module still resolves and enumerates a run's files for the viewers; the clipboard module still holds the terminal escape-sequence copy path and its is-a-clipboard-reachable predicate; the statistics module survives nearly whole and still feeds both the stats view and the ticker; the registry and the per-frame rebuild still live in the monitor module. Most of the lines the job introduced remain.
What has drifted is the bar's arrangement. The job built a bar of many named dropdowns — View, Help, Tools, Chat, Run, Agents, Stats, and a prompt-attention menu. The bar today renders a shorter title set — Gantry, View, Stats, Inspect — with the Tools viewers, the copy items, and the old Agents stage logs folded into a single Inspect menu and the Prompt title dropped; tests in the tree now assert those older titles are gone. The capability was kept and compressed, not discarded. One file the job touched, a couple of lines in a build-driver test, is no longer present, tidied away since.