Task: Specify the reports a party runs screen and its server gaps

Yes for the definitions, and yes for the scoping, but the scope is row-level security and not a request field.

reporting.v1.report_definitions.list exists (report_definition_protocol.hpp:102). Its handler checks reporting::report_definitions:read (report_definition_handler.hpp:86). Its filter carries party_id and party_id_one_of (report_definition_protocol.hpp:74-78), and a caller is not expected to send either: the scoping is done by the store.

report_definitions_party_isolation_policy is a restrictive policy on ores_reporting_report_definitions_tbl whose condition is party_id = ANY(ores_iam_visible_party_ids_fn()) (reporting_rls_policies_create.sql, definitions section). The session variable it reads is set from the caller's token: make_context_from_jwt builds the context with with_party(tenant, party, visible_party_ids, actor) (request_context.cpp, the claims->party_id branch), and the pool sets app.visible_party_ids and app.current_party_id on every connection (tenant_aware_pool.hpp:267-268). The JWT itself carries both claims: party_id (jwt_claims.hpp:140) and visible_party_ids (:148), the latter computed at login as the party and its descendants.

One caveat a reader of the screen must know: the policy passes every row when visible_party_ids is null, which is the state of a session that chose no party. A definition read then returns the whole tenant. Verified in the policy's own comment and in the claims->party_id absent branch, which returns a tenant-scoped context with no party.

No, and yes: every instance is fetched and reduced.

reporting.v1.report_instances.list exists (report_instance_protocol.hpp:98), and its filter carries kind, id_one_of and kind_one_of only (:70-74). There is no filter by definition_id, none by party_id, none by state, and no order that means "newest per definition". The response is offset and limit over everything the policy admits.

The cost is written down in the tree by the one place that needed the same answer: "The generated repository offers only offset and limit, with no filter by definition and no filter by state, so a caller that wanted this answer through it would have to page the whole tenant and filter in C++" (reporting_in_flight_instance_fn_create.sql). That function exists precisely to avoid it, and it answers a different question: is one definition in flight, by id, one row.

No custom method closes this either. Custom repository methods is empty in ores.reporting.report_instance.org, and report_instance_repository.hpp offers read_latest by id and by name, read_all, read_at_version and the paginated read_latest, none of them by definition_id.

So the screen pages the party's whole run history on every load and keeps, per definition_id, the row with the greatest started_at. The cost grows with runs, not with reports: forty definitions with three years of daily runs is about forty thousand rows to draw forty.

Not on the reporting side, and next fire is not a trigger event anyway. It is reachable from the scheduler if the screen is willing to make a fourth read, and no person role may call it.

There is no report_trigger_event_protocol.hpp: the reporting component's messaging directory carries report_trigger_type_protocol.hpp and no protocol for the event, so no subject exists. The model does exist (ores.reporting.report_trigger_event.org), and so does a server-side repository with read_latest and a paginated form (report_trigger_event_repository.hpp), but it is generated for the service and nothing exposes it.

That is the right shape, because the trigger event is the history of firings already made: triggered_at, trigger_type, scheduler_job_id, schedule_job_run_id. It cannot answer when the next firing is.

The prototype draws no next-fire column at all. Its schedule cell is the label and the expression, and the word "next" does not occur in prototype.js. The column belongs to the story's arc, and this is how it could be sourced if it is drawn:

• scheduler.v1.ops.get_scheduler_status exists (scheduling_operations_protocol.hpp:121-125), is gated by scheduler::job_instances:read (scheduler_status_handler.hpp:71), and returns job_schedule_status per job with job_definition_id, job_name, schedule_expression, is_active, last_run_at, last_run_status, next_fire_at and running_count (:132-165).
• The join exists: report_definition.scheduler_job_id is stated to "link to ores_scheduler_job_definitions_tbl.id" (report_definition.hpp:53), and it is present only while the definition is scheduled (ores.reporting.report_definition.org).
• Three costs come with it. The request carries no fields "because the caller's session decides the scope and the scheduler holds the rest", and the handler reads every job definition in the tenant and loops over them, so the screen pays for all jobs to fill a few cells. next_fire_at is absent for a paused job and for an expression the evaluator cannot advance. And no person role holds the permission: see G8.

No. Health is not stored and not returned. The screen derives it, and the state ids it derives from resolve to names only through a fourth read.

The run carries fsm_state_id and no state name (report_instance.hpp:107). The lifecycle machine that id points into is seeded with seven states: pending, queued, running, completed, failed, cancelled, skipped (dq_fsm_report_instance_lifecycle_populate.sql:108-132). Their names, and whether each is terminal, are read over dq.v1.fsm_states.list, gated by dq::fsm_states:read (fsm_state_handler.hpp:85).

The five health words are then a mapping the BFF writes, and two of the seven states map to none of them: see G12.

Note what health does not depend on. It is not read from the output tarball. The retrieval stores that tarball and nothing parses it, and ores_compute_results_tbl holds output_uri, outcome and error_message only (compute_results_create.sql:50-52). Health comes from the run's state and the run's error rows, which is why the error read is on the list above.

The rows are readable and the count is not. The screen reads rows and counts them, and the split by severity is a column on the row.

reporting.v1.report_error_events.list exists (report_error_event_protocol.hpp:66) and its filter carries report_instance_id, report_instance_id_one_of, severity and severity_one_of (:45-51). So all the latest runs' errors come back in one call rather than one call per run, which is better than reading them one run at a time: list_by_report_instance_id (:124) exists as well and is the single-run form.

What is missing is any count. A run carrying twenty errors costs twenty rows to produce one number, and the response carries no grouping. The severity the row splits on is a closed text column, error or warning (ores.reporting.report_error_event.org), so no vocabulary read is needed to count.

Errors are events as well as rows: reporting.v1.report_error_events_events has created, updated and deleted (:156-158), and a database notify trigger publishes them (reporting_report_error_events_notify_trigger_create.sql). The journey's statement that no event exists for this entity is wrong, and this task corrects it. It does not change the design: the screen still reads the rows.

Every one of them is held by the two administrative roles and by service roles, and by no person role at all. That is the largest gap in this list.

The codes are exact and are the ones the handlers check: reporting::report_definitions:read, reporting::report_instances:read, reporting::report_error_events:read, dq::fsm_states:read and scheduler::job_instances:read. All five are seeded (iam_permissions_populate.sql).

The grants, from iam_roles_populate.sql at this commit:

The matcher reads the token's grant set, not role names: has_permission asks ores::security::authorization::grants(ctx.roles(), code) (handler_helpers.hpp:306-312), which accepts an exact code, the component wildcard component::* and the whole wildcard * (except for installation:: codes) (ores.security/authorization/grants.hpp). A person role therefore holds exactly what the seed gives its role, and the seed gives a trading desk nothing in reporting.

Consequence, stated plainly: the screen's two primary reads and the error read are refused for every actor the journey names except the tenant administrator. A read nobody can call is a gap, not a field. See G6, G7, G8 and G9.

It depends on row-level security fed by two JWT claims, and the JWT carries both. What the JWT does not carry is the party's short code.

The chain is: visible_party_ids claim, computed at login as the party and its descendants; make_context_from_jwt passing it into with_party; the pool setting app.visible_party_ids per connection; and ores_iam_visible_party_ids_fn(), which returns current_setting('app.visible_party_ids', true)::uuid[] (iam_session_functions_create.sql:79-82), read by every party-isolation policy. ores_iam_set_party_context_fn is the batch form of the same setting (iam_tenant_functions_create.sql).

Definitions, runs, trigger events and error events all carry the policy. For the error rows it is stated in the table's own DDL as well (reporting_report_error_events_create.sql:189-198).

The party's code is not in the token and not on the session summary. The session's PartySummary carries id, name, partyCategory and businessCenterCode and no code (domain.ts:130-137), while the party's code is short_code (ores.refdata.party.org). The read that carries it is iam.v1.ops.get_my_parties, whose reply states party_id, name, short_code, party_category and business_center_code, needs no permission, and is scoped to the caller's own account (membership.ts:44-110; account_operations_handler.hpp:987). It names only the parties the account is associated with, which is not the same set as the visible party set the policy uses. See G11.

The run's change events exist and the BFF can subscribe to them. The event names the run by name and carries no definition id, so the row cannot be identified from it.

reporting.v1.report_instances_events.created, .updated and .deleted exist (report_instance_protocol.hpp:279-281). The BFF's change registry builds the subject from a watch: {component, entity} becomes component.v1.entity_events.> (change-events.ts:160-162), and a session declares watches at POST /api/events/watch (server.ts:2936). So reporting + report_instances is exactly the subscription the journey asks for, and no new mechanism is needed.

The payload is the problem. The notify trigger states the key as jsonb_build_object('name', changed_name) and the header party as party_id (reporting_report_instances_notify_trigger_create.sql). The run's name is built at admission as the definition's name plus the run's start (report_instance_trigger_handler.hpp, plan.name). The trigger's UPDATE branch also announces nothing, because a versioned table's update is the close of the current row and the insert that follows carries the change.

So a screen that hears "a run changed" learns a name it can match only by rebuilding the definition-name-plus-timestamp string, and it learns no definition_id, no fsm_state_id and no error count. Today it must re-read. See G13.