Prove the Merge Before It Lands
Merge-back that integrates and tests the combined tree before the main branch ever moves.
0 milestones 4 sprints 12 agents
2 plan 4 execute 4 review 2 fix
160k peak context
158k median execute
1h 10m total 11m 12s per sprint
1m 44s plan 27m 36s execute 6m 57s review
39 edits 361 commands
codex harness
Every Gantry run ends by merging the work it built back into the project's main branch. That merge used to lean on git: if the combined text carried no conflict markers, it was treated as done and the main branch advanced. But two changes can be textually compatible and still contradict each other in behaviour — one edits a function the other now calls a different way — and git sees nothing wrong. A clean merge could still leave the main branch broken.
This job rebuilt the merge so it proves itself. Before the main branch moves, Gantry pulls the current main tip into the run's throwaway worktree, runs the full test suite on that combined tree, and advances the main branch only once it passes. When the combined tree fails — even with no textual conflict — an agent is brought in to reconcile the two lines of work by meaning rather than by text. It gets a single attempt; if it cannot produce a passing, marker-free tree, the run stops with the main branch left exactly where it was and the worktree standing for a person to pick up.
How this walkthrough is structured
Feature
What did the run build and ship?
Gantry's merge-back stopped ending at git's textual verdict; a single shared path now integrates the current main, runs the real gate on the combined tree, and advances the main branch only for a proven-green result — with a lock spanning the whole sequence.
Build
How did Gantry structure the work?
The plan separated a correctness guarantee from the repair behaviour that only matters once that guarantee can fail, then carried the guaranteed path across every merge surface — and the two hard pieces each went red at the gate before they landed.
Clean Landing Guard
3 agents 14m 52s wall time 134k peak context 1 fix
What this left behind is a single conflict-safe landing core that reads the current main tip, folds it into the disposable worktree, and refuses to move the branch until the combined tree passes. A per-checkout lock spans that whole critical section, from reading the tip through the post-merge re-gate, so a second run sharing the checkout cannot shift the target between the proof and the commit. The core is still the center of the finalize flow at today's HEAD.
This was the correctness foundation, and it could stand on its own precisely because no resolver had to exist yet: prove that the main branch advances only for an integrated tree that has passed its tests, with a lock held across the whole read-tip, integrate, gate, land sequence. A fresh agent could carry that in one clean context because nothing downstream leaned on it. The gate sent this piece back once — it went red after its review and a repair landed it — which is the first place the run's difficulty showed itself.
Semantic Red Resolver
3 agents 13m 41s wall time 160k peak context 1 fix
A red integration no longer fails bluntly. When the combined tree carries no conflict markers but still fails its tests, one resolver pass is handed the two lines of work and asked to settle them; the result lands only if it comes back green, and a single failed attempt halts the run with master untouched and a worktree left for a person. Standing in the tree now, that escalation path is present and documented.
Repair only means anything once proving is there to fail, so this piece was sequenced second and inherited a grounded foundation to lean on. Its charge was the genuinely hard one: reason about two histories at once and reconcile a textually clean but test-red integration by meaning. It fought back — it went red as soon as it was built and was sent back once before it passed, the second and last place the cut came under real stress.
Merge Coverage Expansion
2 agents 8m 44s wall time 158k peak context
Finalize is no longer the sole caller of the landing core. The engine-owned partial path and the live command both route through the identical sequence rather than growing second copies of it, while the offline path keeps its conservative report-and-stop behaviour because it has no live agent to repair with. All three routes remain wired to the one core in the tree today.
This piece widened rather than deepened, and that shallow reach is what kept it agent-sized: carry the already-proven landing sequence across the other engine-owned surfaces — partial merge and the live-owned command — without inventing any new correctness. It stayed green throughout. That absence of stress is the honest signal that the boundaries the plan drew held once the two hard pieces beneath it were down.
Resolution Guidance Updates
2 agents 7m 5s wall time 126k peak context
What stands is the written guidance a person reaches for when a merge stops for them: the by-hand conflict instructions were rewritten next to the code so the docs describe the behaviour the run now actually has. The prose in the tree matches the semantic resolver it explains rather than the blunt textual-failure flow it replaced.
The closing piece was prompt and documentation work, and a short honest entry is the right size for it rather than a thing to pad: it revised the resolver and adjudicator prompts and the operator-facing guidance to describe reconciliation-by-meaning and the untouched-main guarantee. It never came near the gate's red edge and stayed green, and being unremarkable is exactly its role in the cut.