Task: Bind ores.reporting entities to profiles; verify zero-diff regen

Regenerated all 5 models of reporting against an untouched tree. The output is byte-identical. There is no pre-existing drift.

reporting is already in the KNOWN_DRIFT_FREE registry. The story names reporting-cpp, but the catalogue holds no such entry. --address selects the technical space, and the component is called reporting.

Four entity models carry variability: concurrency_policy, report_type, report_definition, report_instance. The module and the component overview are structurally not entities, so exclude both. No junction and no legacy lookup_entity exists, so no migration is needed.

All four entities already bind a profile. Two binds are clean:

Two binds are wrong.

report_definition binds uuid-identified-lookup and sets :has_workspace_id: true. The profile fixes has_workspace_id to false. The generated SQL confirms the override: the table carries a workspace_id column, a workspace index, and a workspace validation call.

report_instance binds fk-scoped-child. That profile requires parent_entity_singular and fixes has_explorer_api to true. The entity sets neither. No explorer artefact exists for any reporting entity. The entity has its own top-level MDI window instead, which contradicts the profile.

Both wrong binds resolve to the same shape: UUID primary key, tenant and workspace scope, standard Qt tier, no parent. No existing profile covers it. The skill allows a new profile once a second entity repeats the combination. Here two entities repeat it.

A classification of all 206 reporting source files by the AUTO-GENERATED FILE - DO NOT EDIT MANUALLY marker gives 148 generated and 58 hand-written.

Two entity families in the hand-written set have SQL tables but no org model:

Both families mirror the generated shape exactly, minus the marker. Both use a stale include guard of the form ORES_REPORTING_REPOSITORY_..., where the generator emits ORES_REPORTING_CORE_REPOSITORY_.... The component description advertises "risk report configurations", but the module lists only four entities.

No model change was needed. Both entities already carry workspace_id in all three layers:

Both default to utility::uuid::live_workspace_id(), so a new definition already lands in the live workspace. report_definition sets the flag explicitly; report_instance inherits it from fk-scoped-child.

report_definition keeps has_workspace_id: true against its profile. This is deliberate and recorded here, not drift.

report_instance gains parent_entity_singular: report_definition plus parent_id_field_camel: definitionId and parent_id_field: definition_id. The last two are needed because the resolver derives parent_report_definition_id by default, and the column is definition_id. Regeneration adds openAddWithParent() and a prefill block. Output is idempotent.

projects/ores.qt/reporting/ holds 36 generated files. It is the only ores.qt/* directory with no CMakeLists.txt and no add_subdirectory entry. projects/ores.qt/compute/ instead builds 40 hand-written files with the same class names, the same ores::qt namespace, and the same ores.qt/... include paths.

All 16 shared files differ. The hand-written set has four typed history dialogs the generated set lacks; the generated set has the explorer API and version-history plumbing the hand-written set lacks. Neither is a superset.

Consequence: codegen for reporting's Qt produces output the application never compiles. PRs #1904 and #1918 are where the two sets diverged.

Decision (2026-09-17): two steps. Step 1, this task, lets the model edits regenerate into ores.qt/reporting and leaves the build alone. Step 2, a separate task, brings the templates to parity, wires the plugin, and deletes the hand-written copies. Until step 2 the generated controller changes do not reach the application, so no tree widget appears yet.

The unused qt_component knob in core.py exists for exactly this split. No entity in the repo sets it.

check_component_drift.py exits 1 whenever any file in the tree is dirty, because it runs git diff over the whole repository rather than over the component's generated paths. A dirty agile doc is enough to fail it. Verified: with only the two agile org files modified, the regeneration is byte-identical and the run still exits 1.

The call is at line 115 of projects/ores.codegen/scripts/check_component_drift.py: subprocess.run(["git", "diff"], cwd=REPO_ROOT, ...), with no pathspec. The script's own docstring describes the intent, which is to catch a hand-edited generated file.

Consequence: --all can only be run against a committed tree. Run it after the commit that lands the regeneration, not before. Scoping the diff to the component's generated paths would remove the false positive and make the check usable before a commit.

The model is projects/ores.reporting/modeling/ores.reporting.risk_report_config.org. It was reverse-engineered from the hand-written C++, because no model existed. Regeneration replaced 15 files and refreshed two component_files.cmake lists.

The archetypes cannot express these tables. No exclusion was added, so the drift check still sees them.

:has_tenant_id: false does not rescue the two junctions. The template ties the tenant_id column to the same flag, so the column the tables do carry would disappear.

The report_input_bundle gap is not confined to the SQL. The entity, mapper, and domain templates carry the same assumption. Its hand-written entity declares sqlgen::PrimaryKey<std::string> id and a bare db_timestamp created_at, with no valid_from, valid_to, version, or audit members. Generating it would add seven columns to the table and change its primary key. That is a schema decision, not a codegen detail.

The junction gap is wider than one flag. Wrapping the version and audit block in a flag is necessary, and not sufficient: the generated junction also puts tenant_id in the primary key and in the exclusion constraint, and names the left and right indexes from the column names rather than the hand-chosen ..._config_idx. Three template capabilities, not one.

Nothing writes either junction table today. A repo-wide search finds only readers: reporting_resolve_book_ids_fn, the RLS policies, and the two hand-written scope queries in risk_report_config_repository.cpp. No INSERT exists in C++, SQL, or seed data. That is why the gap is not urgent.

Two claims from the first pass did not survive checking. The corrections change the recommendation for both families.

The immutable archetype is not new; it is orphaned. The retired JSON-model pipeline had sql_schema_non_temporal_create.mustache, and three checked-in files still name it:

The template does not exist. projects/ores.codegen/generate_workflow_schema.sh still points at models/workflow/*_domain_entity.json and src/generator.py, both retired. So the marker on those three files lies: nothing regenerates them. Neither workflow nor database is in KNOWN_DRIFT_FREE, so the gate never looks. This is a separate finding from the three exceptions, and it is the one a reader is most likely to be misled by.

The generated shape in those files matches report_input_bundles closely: uuid id, tenant_id, a plain created_at, no temporal columns, and no partial-index predicate. One difference is instructive: workflow_instance uses primary key (id) while report_input_bundles uses primary key (tenant_id, id).

The bundle is live; the junctions are not. report_input_bundle is written today by report_execution_handler.cpp (the assemble_bundle step) through report_input_bundle_repository::create, and read by find_by_instance_id. Its hand-written surface is five files and two methods. The entity archetype generates a bitemporal, versioned, audited, eventing-enabled, history-enabled, paginated stack. Forcing the bundle through it would add seven columns to a live table, move the primary key, and emit far more code than the two methods that exist.

The gap is therefore not a missing SQL branch. It is a lifecycle the archetype does not model: write once, never update, never delete, keep no history.

Revised recommendation. Hold both families as recorded exceptions, and record the trigger to revisit each:

• The two junctions: revisit when something first writes them. At that point conform them to the conventional junction shape by hand and generate them, or close the three template gaps. Order does not matter while no writer exists, because the audit columns would stay empty either way.
• report_input_bundle: revisit when a second write-once entity appears. One entity does not justify a new archetype. The same rule the skill applies to profiles applies here: a novel combination earns its own name only once a second entity repeats it.

The orphaned sql_schema_non_temporal_create.mustache output is a separate task. It belongs with the ores.dq artefact tier finding, not with this one.

The legacy archetype references are deleted (2026-09-17)

The archetype itself was already gone. The template is absent from projects/ores.codegen/library/templates/. Only its references remained. Three changes remove them.

• projects/ores.codegen/generate_workflow_schema.sh is deleted. The script called src/generator.py with models/workflow/*_domain_entity.json. Both are absent. Its template is absent. Nothing could run it.
• The three SQL files lost their false AUTO-GENERATED block. Only comment lines were removed, so the DDL is unchanged and the recreated schema is unaffected. The database_info file also lost a meaningless * Table title, an artifact of its empty entity title.
• ores_schema.puml is regenerated, along with the ores_schema.png and ores_schema.cmapx artifacts the same script renders. The three notes no longer carry the stale text.

git grep now finds zero references under projects/. The remaining hits are past-sprint org files, which are history and stay unchanged.

Two findings came out of this.

The whole family of generator scripts is dead. src/generator.py and models/ are both absent, so every generate_*.sh script in projects/ores.codegen/ calls a module that does not exist. A backlog story already scopes the cleanup: Decommission legacy ores.codegen bash scripts (doc/agile/product_backlog/next/decommission_codegen_bash_scripts/story.org, ID 1C659EB3-5227-46B6-8B5C-68E9F98C10D1). It is in state BACKLOG with one unstarted task. This task deleted only the script the archetype referenced.

The ER diagram was six weeks stale. Regenerating it changed 1786 lines. The last generation was 2026-08-07, so the diff is real drift across every component, not noise from this change. The repository convention is to regenerate and commit the diagram with SQL work, so this is overdue rather than wrong. It is one commit's worth of unrelated churn and can be split out.

ores.reporting/core/src/messaging/registrar.cpp is hand-written. It builds each *_handler directly, so the generated per-entity registrar classes have nowhere to join. Two families are orphaned today, four classes each:

Nothing calls either family. The *_event_registrar family is composed: ores.reporting/service/src/app/application.cpp calls all four register_*_event_mapping functions, so it is not part of the finding.

The skill allows two end states: composed at the composition point, or recorded as a deliberately unwired subject. These are the second state.

The physical space table in the risk_report_config model follows from this finding. Generating a registrar with no caller adds dead code.

Recorded, not fixed. A nullable plain scalar with no :default_value: leaves its C++ member uninitialised, so default construction reads indeterminate values. Eight columns across three components have this shape:

The four ores.reporting columns are fixed in this task's model. The four outside ores.reporting are left alone: fixing them changes generated output for ores.compute and ores.trading, which breaks their drift gates. They belong to a separate codegen-gap task.

reporting_create.sql and reporting_drop.sql were both run inside one transaction against the development database, then rolled back. The whole reporting component was exercised, not only the changed file. Both directions completed with no error.

One migration note. The live database still carries risk_report_configs_definition_uniq_idx. The regenerated create script does not create that name, and the drop script does not drop it. A fresh database from compass db recreate is unaffected. An upgraded database keeps the stale index until someone drops it by hand.

The four older reporting entities each have a hand-written api/tests/domain_<entity>_tests.cpp. Tests are not generated in this component, so no test appeared for risk_report_config.

The template is already covered four times over in this component, and the regenerated header was diffed line by line against the hand-written one. The gap is recorded rather than filled: the four hand-written repository methods (find_by_definition_id, resolve_book_ids, get_book_scope, get_portfolio_scope) have no coverage either, and they are the part that a test should target.

ores.reporting.api/domain/report_definition_template.hpp and its report_definition_template_json_io pair are hand-written. They are a read model for a row of ores_dq_report_definitions_artefact_tbl.

The type is not a reporting entity and has no table of its own, so no reporting model can generate it. Its true home is the ores.dq artefact tier, which is un-modelled: the repository holds about fifty dq_*_artefact_create.sql tables and one model, ores.dq.artefact_type.

Reported here for the backlog. Fixing it means modelling the DQ artefact tier, which is a different component and a different task.

Three checks passed.

• Build. ./compass.sh build exited 0 at 100 percent with zero error: lines. All seven new risk_report_config translation units compiled, and ores.reporting.api, ores.reporting.core, .service, and every test target linked.
• Regeneration is idempotent. ./compass.sh codegen regenerate --component reporting --address ores ran against the already-regenerated tree. The git diff hash, the untracked-file hash, and git status --short are all unchanged. The same command inside check_component_drift.py ran a third time and again changed nothing. Skill step 5 is satisfied.
• CMake source lists. regenerate_cmake_component_files.py --all --check exits 0. Every component_files.cmake in the repository is current.

The component test target compiles; four of its tests need a running NATS.

./compass.sh build test_ores.reporting.core.tests --preset linux-clang-debug-make built and linked the target at 100 percent, then ran 18 test cases. Four failed, all with the same message: NATS connect failed: No server available for connection. The other 14 passed.

The failure is the environment, not the code under test. The four failures are the eventing integration tests, and no ORE Studio service was running for this worktree at the time. compass services status showed 23 of 23 units stopped, and the NATS broker for this worktree listens on port 21605 only while nats-server-clever_dijkstra is up. Starting the services fixed the cause; the ctest result recorded below is the run made after that start.

Two services, marketdata and synthetic, failed to start for the same reason described next.

The database was twenty days stale. That was the root cause.

The first full rat run failed. Two targets did not pass: ores.compute.core.tests (7 of 13) and ores.analytics.core.tests (2 of 34). The compute failures read column "version" of relation "ores_compute_app_version_platforms_tbl" does not exist. The rat target aborted there, so it never reached a clean reporting result.

compass db status gave the cause. The schema was built from commit fdbdf2f98d-d on 2026-08-28 and reported drift: stale, twenty days behind HEAD. compass db recreate -y -k rebuilt it in 16 minutes and 32 seconds. The status now reads drift: current and built from: bcbcb8e380-d, which is this task's own commit. The database therefore holds the new risk_report_config schema.

After the recreate all 23 services started, including marketdata and synthetic. No service fails now. The two earlier failures were stale-schema symptoms, not defects in those components.

The full suite is green. The acceptance is met.

./compass.sh build rat --preset linux-clang-debug-make ran 72 test suites and exited 0. It reports zero failed: lines, and 62 suites print "All tests passed". The acceptance clause "Full local build and ctest green after regeneration" is therefore satisfied.

ores.reporting.core.tests passes all 18 test cases with 58 assertions in this run. The four eventing integration tests that failed on the stopped environment now pass. The two targets that failed on the stale database, ores.compute.core.tests and ores.analytics.core.tests, both pass.

The drift check passes once the tree is committed.

Both claims above were confirmed by running the check twice more. Before the commit it exited 1, printing this task's own change set. After the commit it printed "No drift: regenerated output matches the checked-in tree" and exited

1. --all over the KNOWN_DRIFT_FREE registry then exited 0 as well, which

retires skill step 8 for this component.