Goal Run Dashboard
Goal Runs Without a Hidden Limit
Goal campaigns became open ended by default, with explicit ceilings treated as resumable stops.
0 milestones 4 tasks 11 agents
3 plan 4 execute 4 review
202k peak context
183k median execute
1h 4m total 13m 32s per task
4m 11s plan 28m 32s execute 25m 4s review
81 edits 396 commands
codex harness
This run removed a hidden boundary from Gantry goal campaigns. A goal run with no configured ceiling now keeps cycling while the goal remains amber and productive work is still possible, while an operator supplied ceiling remains meaningful as a calm place to stop, preserve completed cycle work, and resume later.
The decomposition kept the contract narrow before it touched runtime behavior, then made the display stack consume the same truth, and finally updated help and documentation. That order matters because the feature is mostly a semantic distinction: absent means unbounded, explicit means bounded, and every persistence, execution, rendering, and help surface has to preserve that distinction.
How this walkthrough is structured
Feature
What did the run build and ship?
Current Gantry still parses goal ceilings as optional, materializes only real goal cycles, stops explicit ceilings resumably, and documents goal campaigns as open ended by default.
Build
How did Gantry structure the work?
The run cut the change into contract, lifecycle, rendering, and documentation units, with extra review pressure landing where runtime semantics first met public progress surfaces.
Cycle Ceiling Contract
2 agents 8m 36s wall time 117k peak context
The live goal front matter parser and pattern invocation path still represent the ceiling as optional data. Empty input and missing front matter resolve without inventing a bound, while supplied values are validated as positive and retained. The old build-driver files named by the original commits have since moved into the generic pattern runner, but the semantic shape survives there and in the goal parsing module. Non-goal loop handling remains a separate path.
This first unit carried the persistence contract before any runtime loop behavior changed. Its brief was to keep an absent goal ceiling distinct from an explicit positive ceiling through construction, overrides, front matter, serialization, deserialization, and inspection. That was a contained job for a fresh agent because the success condition was round trip meaning, not campaign control flow. The sprint stayed green, so later work could depend on the stored value being either genuinely absent or deliberately set.
Run Lifecycle Management
3 agents 18m 28s wall time 183k peak context 1 replan
Current goal execution still routes configured ceilings through resumable finish handling instead of the older failure-shaped stop. Completed cycle work can be finalized through the same completed-cycle target used for partial goal merges, and a worktree is kept for continuation when the goal is still amber. The runner also marks goal runs with a top-level cycle noun, so consumers do not need a predeclared roster of future cycles. That behavior is now implemented in the generic pattern runner and finish code rather than the original goal-driver module.
This was the runtime unit, and it inherited a settled ceiling contract from the prior sprint. Its brief asked the goal driver to let unbounded runs continue past the former implicit stop while making explicit ceilings stop without looking like build failure. The run facts show the boundary drew extra attention: review completed, the gate was run again, and a re-plan followed before the remaining display work began. That pressure fits the slice, because this sprint introduced the graceful stop contract and the metadata later surfaces had to obey.
Progress Status Rendering
2 agents 23m 59s wall time 208k peak context
The live tree still carries progress descriptors through registry, command, headless, terminal, MCP, and window-title surfaces. Goal cycle rows are created from observed run events and projection metadata rather than fabricated in the display fold. Open-ended goal progress can show the current materialized cycle without a total, while bounded runs can still use the configured ceiling where a total is helpful. Stop output and summaries use completed cycle information rather than speculative rows.
This sprint translated the runtime contract into operator-facing status. The brief gave it many surfaces, but one coherent rule: progress must come from materialized goal cycles and run metadata, not from guessed future rows. The facts show another post-review gate pass here, which is the right stress point for a rendering sweep that had to keep command, headless, terminal, status, summary, sidebar, and window-title output aligned. Because the lifecycle sprint had already defined graceful ceiling stops, this agent could focus on display vocabulary and counts instead of loop termination.
Help And Docs
2 agents 5m 33s wall time 85k peak context
The current command help, driver documentation, goal-run reference, and shipped goal pattern text still describe the ceiling as optional. The docs say goal campaigns continue by default and that a configured ceiling stops calmly while keeping completed cycle work resumable. They also keep Ralph-style loop ceilings separate, so the goal change is not overstated as a general loop-driver rule. The original planning documents were later retired or rewritten, but the public help and reference material still carry the corrected semantics.
The final unit was intentionally low risk because behavior and rendering were already settled. Its brief excluded runtime changes and asked only for user-facing help and documentation to describe goal runs as unbounded by default, with explicit ceilings as resumable stopping points. That made the slice small enough for a fresh agent to audit wording without reopening the engine. It stayed green, closing the run by aligning the public contract with the implemented one.