Task: Bring ores.analytics to the clean standard

No legacy JSON model remains and no lookup_entity remains, so M01 is already satisfied.

No hand-written file is generatable, so G02 has no deletion target in this list. The core/messaging/registrar.cpp history-provider block is a hand-written duplicate of the generated *_history_provider_registrar family and is removed by W01.

Four protocol headers, all generated, all under api/include/ores.analytics.api/messaging/: pricing_engine_type_protocol.hpp, pricing_model_config_protocol.hpp, pricing_model_product_protocol.hpp, pricing_model_product_parameter_protocol.hpp. Sixteen subjects in the retired vocabulary, four per entity: list, save, delete, history under analytics.v1.<plural>. Regeneration replaces the vocabulary with the canonical one.

Raw subject strings outside a protocol header:

• ores.analytics.<entity> in each domain header, the entity identity the history registry and the event mapping key on;
• ores.analytics.<entity>_changed in each generated eventing/*_changed_event.hpp, retired by the canonical eventing/*_event.hpp;
• three literals in the hand-written service/src/app/application.cpp ("ores.analytics.<entity>_changed"), removed by the W01 port.

Open captures, read so this pass does not collide: Move generic quant primitives to ores.analytics, Evaluate adding screamer to ores.analytics, Replace hardcoded permission strings with per-component constants, Fix repo-wide component_overview.org drift. None is in flight against this tree; the permission-constants capture becomes relevant at W02 because the generated handlers carry literal permission strings.

In-flight branches:

• feature/remove-the-legacy-qt-remnants (eager_maxwell, PR #2138) edits the same four analytics models for M09. It removes the Qt keys (item_var, settings_group, window_title, icon) that this pass also removes, so the two changes overlap on those four lines and the merge conflict is a trivial same-result one. This pass removes the retired protocol class properties as well, which that branch does not.
• feature/codegen-ts-messages-analytics (solid_dirac) carries only agile and documentation commits; no code overlap.
• The analytics codegen drift story is STARTED in another environment, waiting on its post-merge live system test. That test and this pass exercise the same component; this pass does not touch its records.

check_component_drift.py --component analytics-cpp --dry-run reports 53 changed and 20 created files (73 total), exit 1. By area: core 28+4 tests, api 12+4 eventing created, service 4, shell/analytics 12 created, SQL 8, web TypeScript 4, shell recipes 4 created, analytics root CMakeLists 1.

check_model_drift.py --summary reports "No model drift: every bound model agrees with its profile (2 known exception(s))"; both exceptions are in ores.compute and ores.reporting, not analytics.

The Component Architecture Audit ran on ores.analytics and on the new ores.shell.analytics part. Fixed in this pass:

• the quant part's See also listed its entries by file path and named no sibling; it now uses org-roam id-links and lists the other parts;
• system_model_domain.org omitted ores.analytics.quant from the sub-component table and described the component as risk-result aggregation, which no part does; the row is listed and the narrative and the core role now describe the pricing model configuration and quant math the parts hold;
• the models lost their Table display sections, so the generated tables rendered an empty header and no rows.
• The diagrams were stale and the tooling could not refresh them. All four analytics part diagrams still showed the retired get_*, save_* and *_changed_event types and none of the canonical ones, because generate_component_puml.py resolved only simple components and refused a composite part. The generator now resolves a part named <group>.<part>, the automated pass was re-run on the four analytics parts and on ores.shell.analytics, and the manual pass added the compositions and relationships the automated pass cannot infer. The two passes were fixed as the audit describes: the manual edges use fully qualified names, because a bare name beside a namespaced class makes PlantUML draw a second node, and a note hangs off a free note rather than note right of a qualified name, which made PlantUML invent a phantom ores node. All five images were re-rendered and read back.

Recorded findings (not fixed here):

• The System Model's expectation of a per-component messaging reference is unmet repo-wide. The iam part overview links one whose id (D3C4E5F6-A7B8-9012-CDEF-123456789012) exists nowhere in the tree, and no generator produces one. A new document type with no precedent is a documentation decision, not a mechanical fix.
• ores.shell.iam has no modeling/ores.shell.iam.puml, so validate_docs.sh reports one MISSING_PUML violation on the tree. It is pre-existing and belongs to that part, not this story.
• The complexity measure: 10965 NLOC over 492 functions at an average CCN of 2.8, with five warnings. The generated parts dominate the raw totals, so they are a template signal; the warnings are all in the hand-written quant library. Top file by CCN: curve_bootstrap_engine::bootstrap at CCN 24 and 112 NLOC, followed by quadratic_gaussian_process at CCN 23. Recorded for a later refactoring pass; the audit fixes nothing here.

The comment pass covered the comments this change adds or moves: event_registrar.hpp, event_registrar.cpp, application.cpp and the core registrar. Each explains a non-obvious why: why the aggregate is the one hand-maintained call site, and why the subscription vector is held for the run. No comment restates code, narrates an edit, or trails a line. Generated files keep their template comments.

The first build failed on ores.analytics.core/service/pricing_model_config_service.cpp: it called repo.read_latest_by_name, which the generated repository never declared. Root cause: key_finders in org_loader.py deduplicated the legacy service_find_by_code_column finder against the declared-key finder by column alone. The two are one method only when the suffix agrees, because the method is spelled for its suffix; the service resolves a caller's key through the declared-key read, so the two differ exactly when the legacy column is the declared key and the legacy method keeps the name code. The fix compares column and suffix together. An entity whose declared key is code is unaffected, which is iam's case. It also repairs four refdata entities that opt in on a column they declare as their key: counterparty and party on short_code, counterparty_contact_information and party_contact_information on contact_type. Each gains the declared-key read beside the legacy one. No gate sees that side effect today, because the drift registry holds iam and analytics only and refdata already reports pre-existing drift. The regression test is in test_org_loader_keys.py.

The build then completed clean, and check_component_drift.py --all reports no drift.

The first attempt was blocked. Nine services from an earlier session were still running pre-change binaries on the same subjects, and the sandbox has no systemd user bus, so compass services start needs --use-busctl and the stale services could not be stopped from inside. A host restart cleared both.

After the restart the environment was refreshed to format version 23, and the whole cycle was then run from scratch on 2026-09-26:

1. The fleet was stopped, the database recreated with compass db recreate -y -k, and the fleet started again. Twenty-two of twenty-three units reached ready; only the web BFF failed, and the analytics surface does not use it.
2. The system was provisioned with the Acme Corporation holding group: the system bootstrap, the two ORE packages, provision tenant --source acme, and the risk_management bundle. The tenant and its admin both exist and every workflow step completed.
3. The shell run was made as that tenant admin, not as the system bootstrap account.
4. V02. Five suites ran against the recreated database and all passed: ores.shell.analytics.tests, ores.analytics.api.tests, ores.analytics.core.tests, ores.analytics.quant.tests and ores.analytics.service.tests.
5. V04. All 40 generated analytics scripts ran against the live fleet as tenant_admin@acme_corporation, each one through compass shell -l on its own script under projects/ores.shell/scripts/library/. Every script in that library is committed, so the run reproduces from a clone. Fourteen answered ok, among them the four list reads, the pricing_engine_types read that returns the 44 seeded engine types, and the add of the two uuid-keyed entities that the shared-template fix unblocked. Fifteen answered missing, for a key that addresses no row. Eight answered failed, each carrying the verdict of a database validation or constraint: Invalid instrument_type_code: __none__, or the _id_check constraint on the zero uuid a recipe sends for a declared id. That is the command working, not failing. One of the eight is a repository defect, and three scripts aborted in the client; both are recorded below. The verdicts were read from the output because compass shell -l exits 0 on an abort (capture).
6. The sweep leaves the tables as it found them. The two add commands that answered ok insert a row named __none__, and the delete-many that follows each one removes it; the three analytics tables hold no rows for the Acme tenant at the end.
7. Third cycle on a rebased base. The fleet was stopped, the database recreated, the environment refreshed to format version 24, and the system provisioned with the Acme holding group before this sweep, which logged in as tenant 69b28d7e-dfb6-4697-8541-f5eb883a2b28. Twenty-three units run, and only ores.web.service stays down.

pricing_model_product_parameters delete-many answers internal_error with a syntax error at ) rather than a verdict:

Repository error: Query execution failed: ERROR:  syntax error at or near ")"
LINE 1: ...') AND ("id" IN ())) AND ("...

The service guards request.removals.empty() but not the set it resolves, so when the script's __none__ key matches no row the repository is called with an empty id list and the generated sqlgen predicate renders =IN () =.

The defect is context-dependent, and both branches were observed on this base. pricing_model_configs delete-many answers ok when the add before it created a row named __none__, and the same command run alone against a tenant with no such row answers internal_error with the empty IN () =. The =pricing_model_product_parameters script reaches the failing branch on every sweep because its add aborts in the client and leaves no row behind, which is why it is the one that fails there.

Generated code sits on both sides of the join, so the fix is a codegen change with a regression test. Recorded as Refuse an empty key list before delete-many renders IN ().

The three pricing_model_product_parameters write scripts abort before they leave the client. add, set and put-many each pass __none__ for pricing_model_product_id, whose declared :cpp_type: is std::optional<boost::uuids::uuid>, and command_token.hpp reserves '-' for an absent optional, so the token does not parse and the shell prints ✗ Invalid value for pricing_model_product_id: __none__. The other three entities' writes reach the service because their recipes carry no such optional uuid.

This is a generator defect in org_loader._sentinel_value, which carries no std::optional entry and falls back to __none__. iam declares seven optional uuid columns, so the fix changes iam's committed recipes and its script library as well. That makes it a codegen-round change rather than one this story can carry without editing a closed component's tree, so it is recorded as Fix the shell recipe sentinel for optional columns. V04's own rule allows a command that cannot run to be recorded with its reason, which is what these three are; the other 37 answered.

The analytics suites all pass: ctest -R analytics is 5 of 5 and the codegen suite is 551 passed. The full suite is 66 of 71, and every failure is outside this component, so each is captured rather than chased here.

ores.synthetic.core.tests fails a business-centre case on a data-state dependency that predates this branch. The other four — ores.trading.core.tests, ores.ore.core.tests, ores.reporting.core.tests and ores.marketdata.core.tests — fail on !(received.empty()) in their eventing integration cases, and ores.synthetic.core.tests fails several of those too. That one is base-level and silent, so it is recorded with its evidence at Finish the eventing payload migration, or read the legacy shape.

The branch was cut from main at 8d2565db07. main then took PR #2138 (the Qt remnants, which rewrites the same four analytics models), PR #2140 (which deletes ores.cli) and PR #2139 (which deletes ores.connections), so the branch was rebased twice, onto 388a90445f and then onto 5de59e3fb8. Three conflicts resolved: the model Presentation drawers keep this pass's two keys, and the two deleted file lists stay deleted.

Everything was re-verified on each base. check_component_drift.py --all reports no drift, the CMake file lists, protocol twin coverage, handler permissions, populate references, recipe inventory and model drift are all clean, and the codegen suite passes (523; the count fell with the CLI component's tests). The whole-tree build follows the last rebase.

A third rebase followed, onto 89cc8d8acd after PR #2148, the platform clean pass. main had moved 46 commits and deleted ores.fpml outright, so the two ores.fpml file lists this branch had marked stay deleted. That pass also fixed two defects in generate_component_puml.py — a one-line declaration body left the parser one brace level too deep, and a wrapped declaration read as a field — and regenerated no diagram. The analytics diagrams were therefore regenerated under the fixed parser: ores.analytics.core loses the duplicate +verifier the old parser invented, and ores.analytics.quant recovers five one-line enums and their structs. Both images were re-rendered, and every class in all five analytics diagrams renders as exactly one node, with the section below each sentinel byte-identical.

The marker commit was rescoped in the same pass. It had regenerated 143 file lists across every component to make --all --check green, which fixed 133 lists that belong to other components' stories — the same lists the fpml pass left in place and the platform pass scoped past. It now owns only the eight analytics lists and the two ores.shell.application lists this story wires.