Pinned Home Branch
Home Branch Pinning
Gantry records the launch branch, merges back to it, and names it in output.
0 milestones 4 tasks 10 agents
2 plan 4 execute 5 review 1 fix
235k peak context
148k median execute
1h 43m total 20m 5s per task
2m 38s plan 54m 11s execute 19m 10s review
45 edits 309 commands
codex harness
This run corrected a branch-safety assumption in Gantry's own orchestration path. A run now belongs to the branch it started from, even if the operator checkout moves before resume or final merge, and the interfaces that describe the merge destination use that branch when it is known. The work was cut from runtime state into merge behavior, then into product language and documentation. That made the early pieces establish a contract before later agents used it in prompts, status, partial merge, and live docs.
How this walkthrough is structured
Feature
What did the run build and ship?
The current tree still carries a persisted home branch through run metadata, merge checks, partial merge, TUI and headless labels, and live documentation.
Build
How did Gantry structure the work?
The run held one branch concept steady across persistence, merge safety, output naming, and documentation, with stress concentrated where the new invariant met final merge and display text.
Capture Home Branch
1 agents 23m 19s wall time 58k peak context
The persisted branch is still present in the modern run state path. Current code reads and writes the value in the pattern pin, carries it into run metadata, and builds worktrees with an explicit branch value rather than sampling again on resume. The docs also state that this runtime state survives resume while staying out of run identity.
This first unit had to establish the runtime contract without depending on any later merge behavior. Its brief kept the scope to capture, persistence, resume, and detached-start refusal, which made the boundary small enough for a fresh agent to reason about identity separately from state. The ledger shows it completed cleanly, so later work could treat the pinned value as already available instead of rediscovering checkout state.
Merge Through Branch
4 agents 1h 2m wall time 235k peak context
The merge path still uses the run's home branch as the destination concept. Current finish code checks checkout drift before final or partial merge, emits a resumable diagnostic when the checkout is no longer on the pinned branch, and leaves conflict-prone offline partial merge to fail cleanly instead of half-applying. The CLI merge command also names the destination branch and keeps the run resumable after landing committed work.
This unit moved from recording the branch to enforcing it at the dangerous boundary: writing completed work back to the shared checkout. The brief asked for target-tip reads, mergeability checks, final merge, and partial merge to use the pinned value, plus a resumable stop when checkout drift made the destination unsafe. Review sent this piece back for another attempt, which is exactly where the cut was tight: the invariant had to cover both normal completion and the operator-controlled checkout.
Name Target Branch
3 agents 16m 52s wall time 148k peak context 1 fix
The current interfaces still expose branch-aware wording where the data is available. Headless completion chooses the recorded branch as the merge target label, TUI state can render a merge card with that branch from run metadata, and the fallback wording is neutral when an old tape or synthetic emitter lacks the value. Some original files from this sprint were later reorganized, but the user-facing contract remains visible in the live output paths.
After correctness was in place, this unit made the system's text match the new model. Its brief was deliberately broad across completion output, merge prompts, status, mock data, and front-end labels, but it depended on a settled metadata contract rather than a new behavior question. The gate went red and a fix ran here, locating the fragility in replacing fixed branch language across surfaces without breaking existing expectations.
Document Home Branch
2 agents 5m 42s wall time 87k peak context
The live docs now describe Gantry as merging back to the run's home branch, explain that the branch is pinned for the run lifetime, and document the detached-start refusal and resumable drift stop. The strongest surviving references are in the configuration, lifecycle, command, and how-it-works docs. Later documentation moves have removed or archived some files touched by the sprint, but the published model still matches the implementation.
The final unit was a documentation sweep over behavior that the earlier units had already proven. Its brief kept archived history out of scope and focused the fresh agent on live user and agent docs, which made the work mostly editorial rather than another implementation pass. It completed cleanly because the code-facing contracts already existed for the docs to describe.