Task: Close the ores.reporting checklist

The parent task's B06 row calls ores.reporting.core.hpp "the namespace documentation header … which G08 exempts because an empty namespace is their whole content". The file was not that: it was an aggregate include over the domain, repository and service headers, with 19 lines of includes and no namespace. The census that called it a file with no production includer was right; the reason it gave was wrong. The file is now the namespace header the item asks for.

Seven items fail, and none of them is a documentation problem.

These surfaced while checking the items above. None of them breaks an item as the standard words it, and all three are this component's own work.

1. The instance's definition key is unvalidated. The generated insert function for report_instance validates the tenant, the workspace, the change reason and the acting account, and never the definition the instance belongs to: reporting_report_instances_create.sql:95-145. The sibling entity does validate its equivalent, because its model declares the key in a * Foreign keys drawer with :target_column: and :error_message: (risk_report_config.org:504-508), which produces reporting_risk_report_configs_create.sql:143. An instance can therefore name a definition that does not exist, and the failure surfaces later, inside a workflow step, instead of at the write. The fix is to declare the key the same way in the model.
2. The report input bundle is unmodelled. The table ores_reporting_report_input_bundles_tbl, its entity and its repository are hand-written, all three without the generated marker, and the repository talks to sqlgen directly with no mapper. A search of the modeling directory finds only a mention in component_overview.org:50, so nothing generates them and no drift gate covers them: this is the component's only hand-written data layer. Whether it should be modelled is a real question, since every other entity's data layer here is generated, but it is not an item failure. B03's survey called the repository generatable, the parent task called it infrastructure by elimination, and neither reading has been settled.
3. The cron expression is an unvalidated string. report_definition's schedule_expression is std::string (report_definition.org:113-117), while ores.scheduler types the same concept as domain::cron_expression with :is_value_type: true (ores.scheduler.job_definition.org:108-116), which is what stops an invalid expression from entering that domain. A malformed schedule is accepted here and then rejected, or silently ignored, when the job reaches the scheduler.

Every line reference in this table was read from the tree at the commit this task's branch is based on. Main moves under the table, so a citation can drift by a few lines without the finding changing: when the branch was rebased onto 315f3bc7a7, four of them had, and the findings they support were unaffected. A citation is a pointer to the evidence, not the evidence.

V04, V08, V01 and P05 could not be closed while the tree did not compile. origin/main currently references ores.dq.api/messaging/fsm_protocol.hpp in three places — ores.workflow/core/src/service/fsm_state_map.cpp:21, ores.trading/core/include/ores.trading.core/messaging/trade_handler.hpp:29 and ores.trading/modeling/ores.trading.trade.org:662 — and that header does not exist: commit dd131c388b replaced it with fsm_state_protocol.hpp and fsm_transition_protocol.hpp and updated neither consumer. A whole-tree build fails at ores.workflow.core.lib.

The repair landed as dbfb31d45d and e25313b2d2, which replaced the protocol include with the FSM repository include in both consumers. On the rebased branch the whole tree builds (exit 0), check_component_drift.py --component reporting reports no drift, and the four reporting suites pass 4 of 4. V01 and P05's build half are therefore satisfied, and V04 and V08 are open work rather than a block.

All 51 generated commands were replayed with check_shell_recipes.py against a database rebuilt with compass db recreate -y -k and a fleet restarted on the rebuilt binaries. Thirty-five answer and sixteen do not. Each cause is a defect, and none is a missing test.

The collision is the sharper finding, and it is verified from both ends: dq_commands::register_commands (repl.cpp:105) registers DQ's report_definitions menu before reporting's at repl.cpp:116, and the service log records the request at dq.v1.report_definitions.list rather than reporting.v1.report_definitions.list. Until it is resolved the report_definitions family cannot be exercised from the shell at all, so S01 passes on the unit and the test rather than on a working command.

repository_report_input_bundle_repository_tests.cpp is added. It creates a bundle and finds it back by instance id, asserting the literal values it wrote, and asserts that an unknown instance id returns nothing. Both cases run and pass in ores.reporting.core.tests.

That leaves the composition and entry-point files, whose test is the fleet starting and whose reason is recorded. The item asks for a test or a recorded reason for every source file, so it is satisfied.

The first pass verified too little, and the gap is worth recording because it looks like success. The build was current, but the fleet was not: the reporting service had started at 10:47 and its binary was rebuilt at 11:40, so the running process was the previous tree's. Only the four reporting suites had been run, the database was 59 SQL files behind, and V04 had been replayed against that fleet. Re-done, on the current tree:

The five failures are not this component's and not this branch's: the branch changes thirteen files, all under projects/ores.reporting/ or doc/agile/, and none under ores.dq, ores.refdata, ores.marketdata or ores.platform. They are captured as Five test binaries fail on main, and four of them share one cause.

So V01, V02 and V03 hold for this component, V02's repo-wide half does not, and V04's result is reproducible rather than an artifact of a stale fleet.

From the inbox: The report-definition eventing re-drive collides with the temporal exclusion constraint; The storage server refuses the report-data bucket its own consumers write to; Three services default their storage base URL to a port the server does not use; Task: Fix reporting entity model drift: update to latest format and regenerate; Finish the eventing payload migration, or read the legacy shape. From next: Party's per-party report_events pgmq queue looks half-baked / unused; Wire service token provider for all services; publish_from_dq codegen facet: hand-writing artefact tables is a recurring cost; Story: Codegen facet: generate the DQ publish-from-dq pattern. From deferred: Trade-aware market data filtering for report execution.

The model-drift capture is satisfied by the parent pass, which brought the reporting models onto the current format and left the drift gate clean. The storage-bucket capture's specific clause — the HTTP server's hard-coded allow-list — was deleted upstream while this work was in flight; its general point, that a bucket is an allocation the facility should be told about rather than a name it hardcodes, is still open.

The parent task's Handoff says the checklist "has a recorded result for all 49 items". Its Result names 29 items and its table carries a row for 30, so 19 items have no row at all: the nine that appear nowhere in the file (B02, G03, G04, H04, M04, M05, M07, M08, P05) and the ten that appear only in a plan heading or in the summary sentence (B05, G08, H01, H03, P01, P06, S01, S02, W03, W04). A census of the rows' leading cell over the parent task is the evidence.

This is the failure check_registry_exceptions.py exists to prevent, one level up: the component is listed in COMPONENTS_UNDER_TEST while items are neither passing nor recorded, and the gate cannot see it because it only validates the exceptions that exist, never the ones that should.

The parent task's V04 rows report eleven commands, then thirteen, then "fourteen of fifteen verbs answer"; one row calls set verified and a later one calls it unverified. The replay in this task is the tie-breaker.

The completed walk in the parent task depended on two ORES_*_SERVICE_HTTP_BASE_URL variables added to .env by hand. That file has been regenerated from the environment profile, so it is consistent again, and the durable fix stays where it belongs.