Sprint 22

• Shipped the Currency Pairs & Conventions reference-data entity end to end: knowledge-base foundation, domain/db/codegen model, Qt UI (list, detail, duplicate/inverted-pair rejection, Conventions cross-navigation), and a full user-manual chapter with captured screenshots.
• Proved out the org-mode literate codegen model on party (PR #963) — a single org file now drives both C++ and SQL generation with inline custom repository methods, replacing the two-JSON-file pattern; the mechanism is now the template for future entity migrations.
• Landed ores.orgmode, a new C++ component parsing org-mode docs and resolving id: links via the existing org-roam index, and built the QA Validation Runner on top of it — an in-app Qt panel turning a test_scenario doc into a guided, trackable test session across the multi-worktree fleet.
• Added codegen support for view groups (Qt detail-dialog tabs), piloted on currency, replacing the single-tab-only generated dialog layout for entities with many fields.
• Closed out a cluster of Windows/macOS CI reliability issues: the MSVC C4273 dllimport failure (via a new ores.qt.headless extraction), a stale-Qt-plugin-after-ABI-change crash, missing EXPORT macros across 20 refdata/scheduler service classes, and the macOS relevance-guard silently skipping the build matrix.
• Fixed a real multi-tenant correctness bug: tenant-scoped variability system settings other than bootstrap_mode weren't seeded per-tenant, silently hiding gated features for every non-system tenant.
• Found and fixed the NATS-port-inside-the-kernel-ephemeral-range bug (moved BASE_PORT_START below 32768) after it caused a real bind collision during this sprint's own manual-chapter work — .env format version bumped to 11.
• Ran three System 2 health reviews (day 3, day 4, close) tracking the sprint honestly through two consecutive RED verdicts to a third; the close review's findings (8 stale sprint.org rows, 20 simultaneously STARTED stories, 741 commits against a 300 target) directly drove this closure's scope: 43 of 70 stories carried back to the product backlog rather than force-closed or silently dropped.

Dual-axis bar chart. PRs (left axis) and commits (right axis) per day. A high commits-to-PR ratio may indicate scope creep.

Lines added (green) and deleted (red) per day. Building work produces mostly additions; refactoring produces a mix. Days with no churn may indicate blockers.

Hours from PR open to merge, one bar per PR. Long bars indicate review bottlenecks. Generated only when PR data is available.

Line chart tracking stories marked DONE during the sprint. Steady upward slope is healthy; plateauing signals a stall.

• Merge throughput and PR cycle time were genuinely healthy all sprint (99 PRs merged, only one ever open at a time in the fleet view, cycle times mostly under 24h) — the review/merge pipeline was never the bottleneck.
• The health-review discipline worked as designed: three System 2 reviews (day 3, day 4, close) caught and named the same underlying problem consistently rather than drifting into optimism, and this closure's scope (43 stories carried, not force-closed) was a direct consequence of taking the close review's RED verdict at face value.
• Several deep, hard pieces of infrastructure landed cleanly: ores.orgmode + the QA Validation Runner, the org-mode literate codegen proof-of-concept on party, and a full Currency Pairs entity shipped end to end including its own two new authoring recipes and a skill.
• Root-causing over patching, twice in one sprint: the Windows dllimport failure was traced to a real architectural mismatch (Widgets-free logic in a Widgets-linked component) rather than silencing the compiler warning, and the NATS port collision was traced to the kernel's ephemeral port range rather than just restarting the service until it worked.

• Twenty stories were simultaneously STARTED at close, more than triple this project's own RED threshold, spanning at least seven parallel entity-commissioning efforts plus codegen, Qt tooling, compass tooling, and market-data work at once. This — not any single story running long — is what drove both the RED sprint-load verdict and the RED focus-signal verdict in every health review.
• The sprint kept growing after being told it was unhealthy: 51 stories at the day-4 review, 70 by close — 19 net new stories added in the six days after two consecutive RED verdicts, the opposite of the course-correction a RED verdict should trigger.
• sprint.org's own Stories table silently drifted out of sync with 8 stories' actual state (mostly under-reporting STARTED as BACKLOG) — the sprint's own summary document was, for stretches of the sprint, not a reliable source of truth for what was actually in flight.
• The initial mechanical carry-to-inbox at close swept 43 stories on the assumption that anything not force-verified was incomplete; a post-close re-triage against real evidence found 13 of those were already substantially or fully done — individual task/story Now:=/=State: fields had gone stale during the sprint rather than being updated as work actually finished. Bookkeeping discipline needs to improve: update status fields the moment work changes, not in a batch reconciliation after close.
• The mission as written ("continue commissioning ores.refdata entities and correct codegen C++ drift") covered only a fraction of what actually shipped or was attempted — an entire Market Data epic and the Org-mode/QA-Runner epic ran through the sprint with no line naming them, which made "is this sprint on-mission" an unanswerable question from sprint.org alone.

• Enforce a hard WIP limit on simultaneously-STARTED stories at the point a story is picked up, not just observe it after the fact in a health review. The data this sprint is unambiguous: PR velocity was fine, story-completion slope was fine, the only broken metric was concurrency.
• Treat a RED health-review verdict as a stop-adding-scope signal, not just a stop-and-look signal. This sprint's story count going 51 → 70 after two RED reviews is the clearest single thing to fix before the next close.
• Re-sync sprint.org's Stories table against each story's own story.org state at every health review, not just at close — the 8-row drift found this time went undetected for at least a week.
• When a sprint's actual work diverges this far from its stated mission, update the mission mid-sprint rather than letting sprint.org silently stop describing what's happening.
• Update a story/task's Now:=/=State:=/=Waiting on:=/=Next: fields the moment work actually finishes, not in a batch reconciliation after close — that discipline gap is what made the post-close re-triage necessary in the first place.