Task: Health review 3 — sprint 22 close analysis

The mission names three things: continue commissioning ores.refdata entities, correct codegen C++ generation drift, and carry postponed sprint 21 stories. All three are represented, but unevenly.

Unmapped scope observed: an entire Market data generation epic (13 stories: synthetic FX, IR rates, librarian support, temporal composite versioning, trade-import service layer) and a new Org-mode support epic (ores.orgmode + QA Validation Runner) run through this sprint with no line in the mission naming them. Neither is small — QA Validation Runner alone has 8 tasks, 6 done. A sprint whose mission statement covers roughly half of what's actually in flight is not a scoping problem discovered late; it was already true at review 2 and remains true today.

Daily commit counts (2026-07-02 → 2026-07-10): 58, 123, 96, 27, 103, 39, 137, 93, 65. No stall — the sprint has been consistently, heavily active for all 9 days, including two spikes (07-03: 123, 07-08: 137) that coincide with hotfix/CI-fix bursts rather than planned feature work. This is not a sprint that ran slightly hot and can be waved through as AMBER: 741 commits against a 300 target is worse than review 2's own worst-case projection (380-425), and the sprint has already run two days past its planned close while still producing 65 commits today. The 300-commit / 7-day targets were breached early and by a wide margin, not narrowly missed at the end.

Merge throughput itself is healthy and not the problem — 99 PRs in 9 days with only one currently open is a well-oiled merge pipeline. The sprint's problem is not that work isn't shipping; it is that far too much work was queued up to ship in the first place.

The 8-row drift is a distinct, concrete finding: QA Validation Runner, Commission: purpose_type, Commission: book, Composite child-entity and hierarchy Qt widgets, Implement temporal composite entity versioning, and Commission: party are all STARTED in their own story.org but still show BACKLOG in sprint.org's summary table; Commission: business_day_convention_type is DONE in its own file but BACKLOG in the summary; and Rethink synthetic reference-data generation across entities has a story directory with no row in sprint.org at all. Anyone reading only sprint.org — which is the document this skill and compass bearings point people to first — would materially undercount how much is actually in flight. This is a process gap, not just a paperwork nit: it means the 20-STARTED count below was invisible from the sprint's own summary table.

20 simultaneously STARTED stories is more than triple the 6-story RED threshold, and the theme spread is not a false positive from loosely related work sharing a tag — it is seven distinct entity-commissioning efforts (party_status, purpose_type, book, counterparty, currency, book_status, party) genuinely in flight at once, on top of codegen refactoring, Qt tooling, compass tooling, and market-data work. The collision flagged at review 2 (counterparty work touching the same code as the composite-widgets story) is still live: both are still STARTED today, unresolved for at least six days.

The sprint is closing stories at a reasonable clip, but new stories are being added faster than old ones close. A sprint under a RED verdict that responds by adding 19 more stories over the following six days is not correcting course; it is compounding the original finding.

Overall: RED. Two dimensions are RED (sprint load, focus) and two more are AMBER, which on its own would already clear the "AMBER if two or more are AMBER" bar, but a sprint with any RED dimension is RED by this skill's own rule, and here there are two. The single most important concern is not the raw commit count — PR velocity shows the team can ship what it starts — it is that the sprint kept starting new work (19 net new stories, 20 simultaneously STARTED) for six days after being told twice that focus and load were already broken, rather than converging toward the close it is now two days past. If one thing should change before the next sprint opens, it is a hard WIP limit enforced at story-start time (e.g. no new STARTED story while N are already open), not a bigger hammer on commit counting after the fact — the data shows load follows directly from how many stories are open at once, not from any single story running long.