Sprint Loop Re-enumeration
Live Replans Stay In The Run
A sprint-level replan became work the current loop executes and displays.
0 milestones 2 tasks
1 plan 2 execute 2 review
50m 36s total 21m 43s per task
30.3M tokens in 160k tokens out
$25.64 nominal cost
This run fixed the gap between a reviewer changing the remaining sprint briefs and the active build loop noticing those changed briefs. The decomposition is narrow: first make the executor read the plan again after each completed sprint, then make the revised roster visible to every surface that watches or replays a run.
The record is unusually clean for a correctness change. Both sprints passed through their own checks without repair, which makes the cut itself the interesting fact: execution semantics landed before display semantics, and neither sprint had to absorb the other's concerns.
How this walkthrough is structured
Feature
What did the run build and ship?
Current Gantry still treats a changed task catalog as live input and carries the changed roster through durable and interactive projections.
Build
How did Gantry structure the work?
The run split mid-run replanning into a contained executor change followed by a contained observer change, and both boundaries stayed green.
Sprint Loop Integration
2 agents 20m 46s wall time 74.2k tokens out $10.08 nominal cost
The original build-loop file has since been replaced by the pattern engine, but the behavior survives in the directory work-list selector. Current code re-enumerates a directory source, recomputes the first pending item from durable completion state, and halts if a completed task vanishes from the current set. That keeps edited or inserted remaining work inside the running process rather than deferring it to resume. The old sprint-driver tests no longer own the whole surface, but the present interpreter has equivalent coverage around re-announcement, insertion, and corrupt-plan detection.
This sprint carried the core correctness fix alone: the active sprint loop had to stop walking the briefs it read at startup and instead re-read the remaining spec files after each completed sprint. That was small enough for one agent because the brief excluded monitor and roster work, and it named the existing milestone loop as the model to follow. The boundary was proven without a repair pass, including the corrupt-plan halt for a done sprint disappearing from disk. Its tests were aimed at the live-no-op bug: edited pending briefs, inserted prerequisites, unchanged runs, and milestone-internal replans.
Display Replanned Sprints
2 agents 22m 39s wall time 74k tokens out $13.47 nominal cost
The visible contract is still present as `RosterUpdated` for flat runs and `MilestoneSprintsPlanned` for nested rosters. The sidecar code grows cards for newly present tasks and drops stale card entries so the roster reflects the current briefs. History encodes and decodes roster updates, headless output emits a concise replan note instead of a second run banner, the TUI reconciles rows without clearing status or feed state, and the window title refreshes its ordered sprint list. Later pattern-run code also re-announces catalogs when a directory work list changes, so the feature now applies beyond the original flat sprint loop.
This sprint was deliberately sequenced after execution was fixed, so it could treat the changing on-disk roster as a proven input instead of arguing about whether the inserted sprint would run. Its job was to make that changed roster legible in the live monitor, headless stream, and journal replay, while preserving accumulated state rather than pretending the run had started again. It also had to give inserted rows card text through the same best-effort path as ordinary card generation. The sprint stayed green, which says the observer contract was isolated well enough to land as a second layer.