Task: Health review 1 — sprint 28 close analysis

The mission has one goal: finish the work carried out of sprint 27 (the record screens, the remaining journeys and the rest of its remainders) before drawing anything new from the product backlog. It names nine themes.

The check against the mission fails in a different place. Of the 126 stories, 101 were created on or after the sprint opened, and 34 of those are CI and hotfix work. By #+created: date only 25 stories pre-date the sprint, and 21 of those are still BACKLOG. The mission says the sprint commits to finishing the carried stories rather than adding scope. The sprint did the opposite. The creation date is an approximation, because a carried story keeps its old date only when its author did not rewrite it, so the 25 is a floor. The conclusion holds either way: most of the sprint is new work.

Verdict AMBER: every theme advanced and none closed, but the mission does not describe what the sprint spent its capacity on.

The tree carries about two and a half times the commit ceiling. The rate is neither a stall nor a spike. Two peaks stand out, 471 on 10-17 and 334 on 10-18, and the sprint then slows to 87 and 154 on the days after its planned close. That slowdown is the planned close arriving while stories were still open: the work did not stop, it thinned out. The commits after 10-20 total 636, and 10-24 was a part day when the count was taken.

Verdict RED.

Correction on 2026-10-24. The first version of this review counted commits with a bare --since=2026-10-13. Git reads a bare date as that date at the current time of day, so the early hours of 10-13 were lost, and plain --since stops at the first old commit of a rebased history. The first version said 2518 commits and a first day of 282. The full count is 2615 and 344. The same two faults hit the charts, which also counted merge commits as PRs and plotted only the twenty slowest PRs. compass sprint charts is fixed, and the verdicts do not change.

A merge cycle of six minutes at the median says the work is merged as soon as the checks allow. It also says that most review is after the merge or by the author alone. That is a property of the process and not a defect of this sprint, but it means PR count measures commit grouping and not reviewed change.

Verdict RED on the count, GREEN on flow. The skill's rule is that a total over about 150 is red.

The eight undecomposed stories:

• Name the convention sets a report chooses
• Session activity: record the size of every NATS message per server
• Paint every web badge from the catalogue
• Link every reference to its record
• Bring the FX spot conventions onto the market standard
• Import and export conventions without a document aggregate
• Keep counting failed attempts on a locked account
• Move the installation's remaining reads onto its own class

Stories with ten or more tasks that are still STARTED, with the shape the skill calls sprawling. The owners should apply the split test (read each remaining task against the story's own acceptance) before the next sprint opens:

The owner then asked for the close of the sprint: every story ends with only closed tasks, or close to it. The section "Sprint close: closes, splits and carries" below records what that did to these numbers. The table above is the state before the close.

Verdict AMBER: the ratio is green, but eight stories are opaque and ten large stories hold most of the open task count.

Twenty-seven stories are in flight across at least seven themes, and nine other worktrees hold their own branches at the same time. The count fell from 29 because this review closed three stories. It is not a deliberate WIP limit. The sprint's retrospective asked for fewer stories in flight, and the sprint's own mission repeated the request, and the count did not move.

Verdict RED.

The default chart window is the sprint's end date plus one day, so a plain run shows work to 2026-10-21 only and leaves out the 100 PRs and 482 commits of 10-22 to 10-24. The committed charts were rendered with --end-date 2026-10-24, so they cover the whole overrun. A sprint that runs past its end date needs that flag or an updated end date, or the charts under-report its close. The first version of the commits chart showed two stray points before the sprint, on 2026-09-27 and 2026-10-10. It bucketed by author date and filtered by committer date. It now uses the committer date for both, and the points are gone.

Verdict AMBER.

The audit reported 95 findings. After the repairs below it reported 26. After the sprint close it reports none.

The three stories closed, each read against its own acceptance:

The audit named a fourth story and this review rejects it.

Duplicates resolved: none. The title comparison found two families of near matches, the three instrument-family audits (FX, rates, bonds) and the equity and FX reworks. Each pair covers a different family, and the two hotfixes for the debug builds cover different platforms. None overlaps.

What remains for the owners, not decided here:

• The 51 DONE tasks with no PR recorded. Most are scaffold tasks.
• The eight undecomposed stories, now in the product backlog inbox.

The owner asked for two things: close every open task and story that is done, and split each story that holds many closed tasks into a closed story and a backlog story. After the work, the sprint table holds 84 stories DONE and 41 ABANDONED, and no story STARTED or BACKLOG, except one that opened during the close (see below). Of the 41, 37 moved to the inbox and 4 closed with nothing shipped. The sprint holds 315 DONE tasks and 8 ABANDONED tasks, and no open task. The audit reports no finding.

Open tasks closed DONE. Each has a written * Result and every pull request it names merged.

The other 17 tasks of the audit's list stayed open and moved to the inbox with their stories. Each has no * Result, or its own text says the work is partial (for example "Partly delivered in PR 3128. The task stays STARTED."). A merged pull request did not prove those finished.

Stories closed DONE because every task is done: Carry the rates family's fields across the ORE boundary (3 of 3).

Stories split. Each closed story keeps its done tasks and narrows its Acceptance to them. Its remaining tasks and its original Acceptance moved to a new story, "<title> — the remaining work", in the product backlog inbox. The closed story names the new story in its Decisions. 25 stories were split and 123 tasks moved. The largest splits are Rework the market data feeds (20 done, 16 moved), Find why market data ticks lag the wall clock (10 done, 21 moved), Browse and follow the grid's jobs (20 done, 4 moved), Populate the ACME books (18 done, 6 moved) and Build the bindings screen (15 done, 1 moved).

Stories carried whole. 37 stories had no done task. Each moved by file or by folder into the inbox with its :ID: intact, and its sprint row is ABANDONED with the close date. They include the eight undecomposed stories, "Author the report configurations on guided screens" and "Complete the ACME report inputs and prove they run".

Five closes needed judgment, and the first pass was wrong for them:

• "See and change everything a report runs" has 18 done tasks that deliver the engine settings arc. Its acceptance names a six-tab report page that nothing built. The story closed DONE with the engine settings arc as its scope, and the report page, with its analysis task, moved to the new story.
• "Find a trade by its identifiers, state, book and date from one list" has one task, ABANDONED because the Trade Blotter story absorbed it. The story closed ABANDONED, not DONE, since nothing shipped under it.
• "Raise a notification for a scenario waiting for a tester", "Restore the trading guards the versioned model dropped" and "Trace a process run and the trade groups it creates" had only their scaffold task done. The release notes pass found this. The three stories are ABANDONED, and their real tasks stay in the backlog stories.
• "Replace the credit fact variant with typed arrays" and "Build the conventions list screens" left only a scaffold task. That is no work, so the split was undone: each story is whole and DONE, with the scaffold task ABANDONED.
• "Draw every coded value as its badge" was DONE with six open tasks listed as plain rows with no task file, so the first pass did not see them. The PR review found it. The story is split: it keeps its one done task, and the six open rows moved to a new inbox story.

The closed stories "Decide the XML strategy" and "Trade Blotter" keep ABANDONED tasks in their tables. Their Acceptance lists only the DONE tasks.

One story is outside the close. "Add a Hawkes tick arrival process to analytics.quant" was scaffolded on main by another environment (prime_origin) while this close was in review. It is STARTED with 2 tasks done and 4 open, and its branch is live, so moving it would pull the story from under that branch. It stays in sprint 28 and needs its own decision. A task "Subscribe every Acme party to market data" also arrived on main under the ticks story, with PR #3710 merged and no Result, and moved to that story's remaining-work story. Another environment finished "Record when a run starts and how long it took" (PR #3707) during the same window. It is DONE and stays in its closed story.

It did not read the acceptance of the 10 sprawling stories before the owner asked for the close. It did not verify that the equity round trip is lossless: it relied on the standing gate. The audit's 25 task files were read for their * Result and their Now cell only, not for the code. The "CI or hotfix" count is an estimate by title. The number of carried stories is the sprint's own claim of 41, and the creation-date count of 25 is a floor. The narrowed Acceptance of each closed story lists its done tasks by title. It does not restate each task's result, so the owner may refine it.

The sprint is RED. It carries two and a half times the commit ceiling and four times the PR count over twelve days, with twenty-seven stories in flight, and its mission promised no new scope while four in five of its stories are new. Flow is healthy: PRs merge within minutes, nothing waits, and every day merges. The bookkeeping was the weakest part, and this review repairs the part that has an unambiguous answer. The one change that would improve the next sprint most is a limit on stories in flight, enforced when a story starts, because the load, the focus and the open-task count all follow from starting more than the sprint can finish.