Runs That Build Until a Goal Passes
Point Gantry at a check and let it plan, build, and re-plan until that check turns green.
Until this job, a Gantry run built a plan you had already written: a flat build, a set of milestones, or the same plan applied across many targets. That covers work you can describe up front. It does not cover work you can only *name* — "keep going until this test passes," "iterate until this script exits clean" — where you know the target as a command that either succeeds or does not, but cannot write the plan that reaches it in advance.
This job gave Gantry two ways to chase such a target. A goal run repeatedly plans and builds whole campaigns, re-running a frozen goal command after each one, and stops when it passes. A loop run takes the smaller step of one fresh agent per iteration against the same standing prompt, reverting any iteration that breaks the tests. Both rest on a new middle verdict called amber: a goal check that has not been satisfied *yet* is amber, held apart from a red failure, so an unfinished goal never looks like a broken build. The job also reshaped the existing build pipeline into reusable pieces those new modes could stand on, and reworked the website and docs to explain the modes honestly.
Build
The cut put two milestones of shared groundwork ahead of any user-facing mode, then built the goal driver before the loop that consumes it; the live-progress path is where the difficulty concentrated, exactly where an earlier milestone had predicted it.
The decomposition placed two milestones of groundwork ahead of anything a user could invoke. The briefs are explicit that no goal or loop flag ships until the shared pieces exist and are tested against the current pipeline's unchanged behavior: a first-class amber verdict that serializes and replays distinctly from failure, a campaign primitive that runs one whole build pass inside an existing run, Gantry-synthesized plan sources, partial merge lifted out of the map driver, and a single reviewer parameterized by review altitude. Only after those landed do the two driving modes arrive, each of which the briefs say may rely on the earlier seams. Building the machinery first meant amber and the campaign primitive were proven against behavior that already existed, rather than inside a brand-new mode that had nothing to hold them to.
The two goal-seeking modes were themselves ordered rather than built side by side: the goal mode first, the loop mode after it as a consumer. The loop brief states plainly that it may rely on the command and job infrastructure already built for the goal mode, including the driver-supplied live progress path completed there.
That live progress path is where the difficulty concentrated. The refactor milestone deliberately landed only half of it — every progress surface could render a descriptor, but descriptors were rendering-only — and its own plan-impact note recorded that the live event, codec, journal, and replay wiring had to be finished inside the goal mode, because the goal mode is the first whose live progress is not sprint-shaped. The run bears the prediction out: the goal mode's live-progress sprint had its re-plan attempts error repeatedly before the work came together. The stress surfaced precisely at the boundary the earlier milestone had flagged.
A second review-driven redraw reshaped the last milestone before it began. A review of the loop work recorded that goal and loop completion had to be described as gated by a clean run-level review before the final merge, not as merging the instant the goal turns green — so the web and docs copy was constrained by a correctness point learned during the build, not one written into the plan.
Feature
Before this job Gantry could only build a plan you supplied and had no verdict between pass and fail; the job added the test/goal/amber model and two goal-seeking modes, most of which still stands, though the surface positioning and the split web pages have since drifted.
Beforehand Gantry could build a plan you had written — flat, milestone-shaped, or mapped across targets — but could not be aimed at a goal and told to keep working until that goal held. There was also no verdict between success and failure, so a check that simply had not been satisfied yet was indistinguishable from one that was broken.
The design answers both. In the engine, a goal module freezes the goal command and captures its output at baseline, and adds amber as a serializable, replayable verdict for the not-yet-satisfied case. A tiny key-value parser reads the new prompt front matter, and a shared progress-descriptor path carries cycle- and iteration-shaped progress through the attach codec, the history journal, and replay. On top of that sit the two modes: a goal driver that plans and builds whole campaigns until the frozen check passes, and a loop driver that runs one fresh agent per iteration and reverts any regression.
Standing in the tree at today's HEAD, the load-bearing parts hold. Both driver files are present and largely intact, and the goal module, the descriptor module, and the parser survive nearly whole. The retired sprints entry point and the folded-together reviewer both stuck: the standalone sprint driver file and the separate milestone-review prompt are gone, replaced by the single altitude-parameterized reviewer.
Two things have since drifted, and honestly so. The surface positioning flipped: the job presented the goal mode as the headline and the loop mode as a subordinate aside, but at HEAD the loop flag is the headline command and the goal flag is documented as a permanent alias for it. And the separate Build, Map, and Design web pages this job split apart have folded back into the single landing page — the map and design routes now redirect to anchors on it, and the standalone page files are absent.