Build Progress Dashboard
Live Testing Cards
The build feed learned to tick for mechanical tests and keep finished card durations honest.
0 milestones 4 tasks 12 agents
2 plan 4 execute 4 review 4 fix
124k peak context
110k median execute
2h 5m total 22m 12s per task
2m 35s plan 21m 3s execute 9m 58s review
45 edits 346 commands
codex harness
This run made Gantry's build monitor treat mechanical verification work like visible work. The internal stage name stayed the same for ledgers, wire values, and configuration, while the operator-facing card became Testing, live command runs emitted elapsed progress, and completed cards took their displayed time from final stage metrics.
The cut moved from presentation copy, to card state, to the engine command runner, and finally to attach and demo consumers. That order let the user-facing vocabulary and final-duration rule settle before the run introduced a live heartbeat that every downstream surface had to preserve without inventing agent token data.
How this walkthrough is structured
Feature
What did the run build and ship?
Current Gantry still shows testing as human-facing card chrome, folds final stage metrics into completed cards, emits progress from mechanical test commands, and preserves those events through attach and demo paths.
Build
How did Gantry structure the work?
The run separated the presentation sweep, finished-card state fold, command-runner heartbeat, and attach/demo propagation so each fresh agent owned one boundary of the feed contract.
Feed Test Labels
4 agents 43m 33s wall time 97k peak context 2 fixes
The current stage model still keeps two names for the same mechanical phase. `Stage::Gate` remains the serialized and ledger label, while `display_label` and the default headline render as Test and Testing for humans. The fix-stage wording also names a test failure, not a gate failure. The overlay readiness helper from the repair is no longer central to this feature, but the user-facing copy contract is still present in the live tree.
This first slice was deliberately narrow: rename the user-facing test-stage chrome while leaving the machine contract untouched. That made it a good setup unit for the rest of the dashboard work, because later duration and progress cards would appear under the vocabulary an operator actually sees. The boundary still caught stress: the gate sent it back, and the repair landed a replay-overlay readiness wait alongside the copy change before the sprint settled. The useful lesson is that even a presentation sweep touched capture infrastructure because the visible feed is also test material.
Finished Card Durations
2 agents 16m 40s wall time 77k peak context
Finished cards still copy a closing stage's measured duration into the card state when the finish event arrives. Rendering still treats a completed card with a known short duration as having real elapsed time, while a running card without progress does not pretend to have elapsed. That means a silent mechanical command can finish and still display the final duration supplied by its metrics. The surviving behavior is concentrated in TUI state and card rendering rather than in command execution.
This sprint owned the card-state rule, not the command runner. The brief asked it to make completion metrics authoritative for the displayed duration and to preserve the distinction between a running card that has not ticked and a finished fast card. That scope fit one agent because the change sat in the TUI fold and render path, with focused cases proving the edge conditions. It passed through its boundary without repair, which left the harder live-command work free to depend on a settled final-state rule.
Live Command Progress
2 agents 17m 54s wall time 124k peak context
The current gate runner still spawns the verification command, polls it, and calls a progress callback as elapsed time advances. Abort during a running command reaps the child process family and returns an abort-shaped result instead of manufacturing a red verdict. The current run engine passes that callback through baseline, sprint, merge, and post-merge test flows, and the goal-command wrapper accepts the same progress hook. Some original build-driver files have been reorganized, but the mechanical heartbeat path remains in the live command runner and run gate code.
This was the engine-side change and the broadest conceptual unit. The sprint had to replace a blocking command wait with a child-process polling loop, report elapsed-only mechanical progress, preserve abort semantics, and thread the callback through normal testing plus goal and loop verification. It stayed green, which says the prior slices gave it a stable display contract and enough focused command coverage to prove the risky path. Its boundary was the subprocess interface: emit progress while work is alive, but keep final verdict and duration accounting where they already belonged.
Attach Demo Progress
4 agents 26m 29s wall time 110k peak context 2 fixes
Attach decoding still preserves mechanical progress events whose process and token fields are absent, and round-trip coverage keeps those optionals from becoming default values. Demo gate events still use the test stage, emit visible progress without token counts, and finish with measured duration metrics. The TUI state fold updates elapsed progress for a mechanical card while leaving token metrics absent. Together those pieces make the heartbeat observable to attached consumers and replay demonstrations, not only to the original local monitor.
The final slice made the new heartbeat a first-class event outside the local TUI. Its brief was about preserving optional fields through attach, letting demo runs show representative testing progress, and ensuring the state fold did not convert absent token data into agent usage. The gate sent this sprint back as well, and the repair centered on preserving mechanical progress fields before the final check passed. That stress fits the unit boundary: the engine could already emit the event, but wire and demo consumers had to keep its shape intact.