Task: Make the scheduler-triggered report execution correct

The scheduler-to-report path is dead. Proven live on 2026-09-26, not merely read:

1. A report_definition and a scheduler job were inserted, the job publishing reporting.v1.report-instances.trigger every minute.
2. The scheduler fired and reported success — Firing job: reporting.v1.fsm-live-probe then NATS publish action succeeded then Job succeeded.
3. The reporting service logged Handling ...reporting.v1.report-instances.trigger and then nothing.
4. select count(*) from ores_reporting_report_instances_tbl returned 0.

The cause is one missing header. ores.scheduler publishes the trigger with client::publish and no headers (nats_publish_action_handler.cpp:79). make_request_context takes the !verifier early return only when no verifier exists, and the reporting service always builds one from the IAM JWKS key (domain_service_runner_impl.hpp:94, request_context.cpp:133). So the trigger is rejected unauthorized.

The rejection is then thrown away. error_reply returns immediately when the message has no reply subject (handler_helpers.hpp:220-224), and a fire-and-forget publish has none. The scheduler therefore records the job as succeeded. Nothing anywhere reports the failure.

Three further defects sit on the same path, all currently unreachable because the auth check runs first:

The machine report_instance_lifecycle seeds 7 states and 7 transitions (dq_fsm_report_instance_lifecycle_populate.sql).

Two conclusions follow.

• The transitions table is enforced by nothing. ores_dq_fsm_transitions_tbl is seeded for this machine and read by no code. A caller assigns inst->fsm_state_id directly (report_execution_handler.cpp:96,175,380), and the generated CRUD handler accepts any state a client sends. The only consumer of the FSM tables is get_fsm_states_request, which returns names and UUIDs. So an illegal transition is unrepresentable in the tables and unconstrained in the code.
• The granular states the design proposes do not exist. 2026-04-05-report-execution.org lists 11 states (gathering_inputs, preparing_package, submitted_to_compute, computing, processing_results). None is in the SQL. The implementation plan deferred them deliberately, on the argument that workflow_step already gives per-step visibility, and narrowed the instance FSM to pending -> running -> completed/failed. That is a decision, not an omission, and this task keeps it unless the decision is revisited.

2026-04-06-report-execution-workflow-implementation.org marks phases 3.8 to 3.11 DEFERRED. The code says otherwise.

The definition is registered, not orphaned: ores.workflow/core/src/messaging/registrar.cpp:106 calls register_report_execution_workflow, and that registrar is reached from the workflow service's own application.cpp. Every command subject has a subscriber.

Step 4 is the interesting one. submit_compute deliberately does not complete its own step. It creates a batch and its workunits, dispatches the work assignments, writes a workflow_batch_link, and returns (report_submit_handler.cpp:133-143). ores.compute's batch_workflow_bridge publishes step_completed_event when the batch closes. The async wait therefore lives outside the engine, which has no wait_for_event primitive and no step timeout. If that bridge does not run, the report hangs in in_progress forever and nothing notices.

• gather_market_data exports every series for the tenant; nothing filters by trade type or date. The plan records this as a future enhancement.
• The definition lifecycle FSM has the same shape of gap: ores_reporting_initial_definition_state_fn() has no caller, so fsm_state_id is left NULL on a new definition, and reconcile() schedules every definition with no scheduler_job_id — including ones that should be archived.
• The trigger uses publish, not js_publish, so a trigger fired while the reporting service is down is lost with no record.
• One scheduler firing produced two Handling lines 103 ms apart in the reporting log. The cause is not yet established. It matters, because a doubled trigger would double-create instances once the auth check passes. Verify before the fix lands.

1. Insert a report_definition in the system tenant with concurrency_policy'fail'= and schedule_expression'* * * * *'=, using admin as =modified_by~ (the insert function validates it).
2. Insert a scheduler job with action_type'nats_publish'= and action_payload={"subject":"reporting.v1.report-instances.trigger", "report_definition_id":"<id>","tenant_id":"<tenant>"}.
3. compass services restart ores.scheduler.service so the loop reloads jobs.
4. Raise ORES_SERVICE_LOG_LEVEL to debug and restart ores.reporting.service to see the Handling line.
5. Wait for a minute boundary. Read the scheduler log, the reporting log, and ores_reporting_report_instances_tbl.

Authentication here has two layers, and the defect lives on the second.

• Transport is mTLS. build/config/nats-<label>.conf sets verify: true with the environment CA, so every client presents a certificate, one per service. There are no subject ACLs. Being able to publish to a subject means being a process in this environment.
• Message identity is the JWT bearer. It carries the tenant, the party scope and the roles, and those are what row-level security and has_permission read.

So the scheduler is not refused entry to the bus. Its message arrives and names no principal, and the handler demands one.

Three kinds of subject already exist:

trigger is not a canonical entity verb, so P01 and P04 place it in the second row. It is also a scheduler-to-reporting call, and every other service-to-service call in the tree authenticates with the caller's own service token: make_service_token_provider logs in at iam.v1.auth.service-login, caches the bearer, refreshes it, and authenticated_request attaches it. Reporting already calls trading, marketdata and the scheduler that way.

The fix therefore has four parts, and they are not alternatives:

1. Modelling. The trigger becomes an operation model under reporting.v1.ops., and its message generates from the model. The hand-written protocol header goes, as P04 requires. Variability's ores.variability.operations.org is the worked example.
2. Identity. The scheduler publishes with its own service account. ores_<env>_scheduler_service already exists, so this follows the existing service-call pattern and gives the audit trail a name.
3. Tenancy. The message carries the acted-on tenant_id, because one service account lives in one tenant while report definitions are per-tenant. This is the precedent complete_party_onboarding set for the party: the acting identity is the caller's, the acted-on identity is carried.
4. Failure. The scheduler sends the trigger as a request, so a reply subject exists and error_reply stops being discarded. A rejected trigger then marks the job failed instead of succeeded.

An instance state change goes through a checked transition against ores_dq_fsm_transitions_tbl, so an illegal transition fails loudly. Today inst->fsm_state_id is assigned directly and no code reads the table.

The component carries a test report — a definition, its risk_report_config and its book scope — so that an environment, freshly created, can walk the FSM from ores.shell. The fixture is deterministic: a book with no trades exports an empty list and succeeds (trade_handler.hpp:364-371), so the happy path needs no trade data.

The fixture covers the happy path pending -> running -> completed; a configuration with no book scope, which gather_trades rejects and which drives -> failed; and the three concurrency policies, exercised by triggering one definition twice.