Task: Health review 1 — sprint 22 mid-sprint analysis

The mission states two goals: (A) continue commissioning ores.refdata entities, and (B) correct codegen C++ generation drift, carrying postponed sprint 21 stories. Of the 49 stories in sprint.org's tables, 17 map cleanly to Goal A (the per-entity commissioning stories: currency and its aux types, party and its aux types, book/book_status, business_unit/centre, portfolio, purpose_type, contact_type, counterparty, plus the currency/Qt reconciliation story). 12 map to Goal B (the Codegen epic stories plus the two explicitly "carried from sprint 21" stories — Resolve codegen model unification blockers, Compass quality of life). The remaining 20 stories (41% of the sprint) — the entire Market data generation epic (8), most of Compass (4), all of Infrastructure (5), Documentation (1), Hotfixes (1), and sprint-admin (1) — do not serve either stated goal. None of this is wasted work, but it means the mission statement undersells what the sprint is actually doing; calling this "a commissioning + codegen-drift sprint" is a wishful simplification of a sprint that is really running four workstreams at once. Neither goal is uncovered — both have substantial, active work — but Goal A in particular is thin on completions relative to its size (see below).

193 commits landed by mid-day-3 (37 on 07-02, 114 on 07-03, 42 partial on 07-04) against a 7-day, ≤300-commit target. The day-2 spike of 114 is more than half the entire sprint budget in a single day — either a burst of genuinely productive parallel work (36 PRs merged in the same window supports this) or a sign that review depth is being sacrificed for throughput. Projecting from the two complete days (75.5 commits/day average) across the remaining ~4.5 days gives a projected total in the 520-580 range — well past the 400-commit RED line, even allowing for the pace to cool. Even a conservative reading (193 commits in under 3 days, needing to hold under ~27/day for the remaining 4 days to land at 300) requires a sharp, unobserved slowdown that hasn't shown up yet.

36 PRs merged since sprint start against 0 currently open — by the mechanical PR metric this is excellent: roughly 14 PRs/day, no long-open review bottleneck, and no visible WIP pileup. But the gh pr view is misleadingly clean: the fleet shows 8 active worktrees with in-progress branches that haven't yet become PRs, and three of them are already dangerously stale — 35, 51, and 117 commits behind main respectively. That is WIP accumulation the PR metric cannot see: those branches will face brutal rebases (or silent abandonment) the longer they sit, and the 117-behind branch (commission_purpose_type) is functionally orphaned at this point. The mechanical PR-velocity verdict is GREEN, but it is hiding a real integration-debt problem outside its own field of view.

175 tasks exist across the sprint's 49 stories: 96 DONE, 69 BACKLOG, 7 ABANDONED, 2 BLOCKED, 1 STARTED. At the story level, 12 stories are DONE against 37 BACKLOG+STARTED, a DONE ratio of 0.324 — inside the skill's 0.3-0.5 AMBER band, not the failing zone, but close to the floor for day 3 of 7. Fifteen stories (31% of the sprint) have zero tasks filed at all — entirely undecomposed. Encouragingly, none of the five currently-STARTED stories are among them (each STARTED story has at least 2 tasks), so there is no active black-box story right now. But undecomposed BACKLOG is still a planning risk: with 4 days left, several zero-task commission_* stories (book, business_centre, business_unit, contact_type, party, party_id_scheme, portfolio, purpose_type) will need decomposition before any visible progress can be tracked on them, and that hasn't started.

Separately: commission_counterparty's own story.org shows State: STARTED with all three of its tasks DONE — the story was never closed even though the work is finished. Worse, sprint.org's Stories table for this same story still shows BACKLOG, a state that matches neither the story file nor reality. This is a live example of the paperwork drifting behind actual work, not a one-off: two other fleet-active stories (commission_book, commission_purpose_type, commission_party) show BACKLOG/zero-tasks in the docs while their worktrees have accumulated dozens to well over a hundred commits of in-progress work.

sprint.org tracks 5 STARTED stories: commission_counterparty, commission_currency, compass_github_actions_support, open_sprint_22, and synthetic-data-collections — spanning three themes (refdata commissioning, Compass tooling, market data) plus sprint admin. That alone lands in the 4-5-stories / mixed-themes AMBER band. But the paperwork undercounts actual concurrency: the fleet shows 8 worktrees with active branches, three of which (commission_book, commission_purpose_type, macos_ci relevance-guard hotfix — the last already closed as DONE) are not reflected as STARTED in the docs at all. Real concurrent work in flight is closer to 6-8 threads across commissioning, codegen/hotfix, market data, and Compass — squarely in the "6+ or wildly divergent themes" RED band once fleet reality is counted instead of the docs. open_sprint_22 itself is also still STARTED on day 3 despite its own tasks being effectively wrapped up (2 of 3 DONE), which should have been closed already and is itself a small focus/paperwork leak.

The task-completion rate looks strong in isolation, but it is concentrated in a handful of stories that were already well-decomposed and largely finished before the sprint's stated commissioning goal (17 stories, 1 DONE) made real progress. Goal A specifically is behind pace for the calendar elapsed.

Overall: RED. Two dimensions land RED — sprint load (commit pace projects to nearly double the 300-commit target even on a conservative reading) and focus (five stories are tracked as STARTED, but the real fleet picture shows 6-8 concurrent threads spanning four unrelated themes, with two branches (51 and 117 commits behind main) at real risk of becoming unmergeable or abandoned). The single most important concern is that the paperwork is actively lying about the sprint's true state: commission_counterparty is finished but still shows STARTED/BACKLOG in two different places, commission_book and commission_purpose_type show zero tasks and BACKLOG while their worktrees have been running for dozens to well over a hundred commits. If sprint.org and story.org are not trusted as ground truth, every other metric in this review is built on sand. The one fix that would most improve sprint health: stop new work, spend an hour reconciling every fleet-active branch against its story.org state (closing commission_counterparty, correcting book/purpose_type/party to STARTED with real task breakdowns), and force a decision on the two most-stale branches (51 and 117 commits behind) — rebase now or abandon, before they get further from main.