Browse the grid's jobs prototype

Signed off on 2026-10-13. The layout, the three roles and the four states stand as drawn. The statistics need three tasks: the result fields, the wrapper's measurements and the aggregate read.

• A tree is the right shape. A batch holds workunits and a workunit holds results, and the person asks about one level at a time.
• Every level pages on the server. Opening a batch reads one page of its workunits, never all of them.
• The same screen serves three roles. The operator sees every party and the node of each run. The tenant administrator sees every party and no node. A party member sees one party and no party filter.
• The screen shows only fields the entity models hold, under the models' own headers. It computes no count and no state. A closed batch is not a successful batch: the person reads the outcome of each result.
• A workunit's Input URI and a result's Output URI are links to the stored files, so a person can take them away. A result has no input of its own: its Workunit ID link leads to it.

The story Browse and follow the grid's jobs compared this prototype with its acceptance and changed six things.

• An Outcome filter finds a failed result. It narrows the tree to the workunits that hold a run with that outcome.
• A Follow this job link on a workunit or a result opens the job page. The App Version ID links to the app version page.
• The run statistics are an ordinary panel, not a dashed block.
• The tabs are the ones the grid screen has: Overview, Usage, Machines, Nodes, Heatmap and Jobs.
• A failed workunit has a canonical result, as the job lifecycle states.
• The filters, the open rows, the page and the selection live in the address.

?role=operator|tenant|member and ?state=loaded|loading|empty|error|refused. The bar at the foot of the page switches both.

Every field shown is a field of batch, workunit, result or host. The external_ref values, party codes, storage URIs, host display names and the stored server_state and outcome (all Done and Success) come from the development database as it stood on 2026-10-13. The ids, the app_version_id, the failed and in-flight results and the batches in processing are invented.

The Run statistics panel is the one exception to the fields-only rule. A result shows its start and end time, its input and output bytes and its peak memory. A workunit and a batch show the aggregate of the results below them (earliest start, latest finish, summed bytes, largest peak memory). The result stores none of them: the wrapper measures the duration and the bytes and sums them per node, and the engine's peak memory is a log line. The story that adds the run statistics adds the fields, and the panel waits for it.

No server behind the screen exists yet for the filters, the failed-result read or the download route. The journey lists them as gaps.

Gemini drew the tab as one screen with one batch open and the workunit inspector. It is kept at the review. The agreed design stands. The prototype took two things from it and left the rest. An earlier build took three more (a red failure count, a has failures filter and tiles), and the entity-fields pass removed them: the models hold no count and no failure state.