Look back over a report's history prototype

A run list is easy. The hard part is that the list is alive: a scheduled report produces a new run while somebody is reading an old one, and the screen has to say so without taking the page away from them. The second question is what "the history" is measured in, because the firings and the runs are not the same set.

Switch with the bottom bar, or with ?variant.

The panel shows the last five fire times, because a person needs to tell an hourly report from a daily one and to notice a window where nothing ran. Each time is derived from a run, and that is stated, because it is not the same thing as a firing. A firing that produced no run, because the concurrency policy skipped it or the trigger was refused, leaves no trace the screen can read.

The page goes further and points at a gap. The five runs it draws are 59 minutes 50 seconds apart except across one window where no run started, and the panel says so rather than smoothing the timestamps into a tidy cadence. That is what the honest version of this panel looks like.

Every run carries its started and completed time to the second, and the newest is marked LATEST in a column of its own, so it is found without reading timestamps in order. A run that completed while carrying errors reads differently from a clean one at a glance.

A history is a series, so the page plots it. One card sits under the fire times and above the run list, and it carries a line of the report's SA-CCR exposure across every run the page holds, oldest to newest.

The form is chosen by the shape of the numbers, not by decoration: a run-by-run series is a change over time, and a change over time is a line. The latest run's point is marked and named, so the line's direction has a subject; when the newest run is still in flight and has no figure yet, the mark falls on the newest run that has one, the label says so, and the caption says why the newest run is a break in the line rather than a point. The day boundaries are drawn as labelled markers, so an hourly axis keeps readable clock ticks; and the value axis states the range it spans instead of starting at zero, because a line of levels drawn from zero would flatten a series this narrow.

The form of every plot on this page follows one rule, and the rule is written on the page beside the plots so the next person does not guess:

What that rule draws on this page:

A run that completed carrying errors wrote an exposure over the trades it placed, so its point is drawn hollow with its segment dashed, the card carries the same partial tag the run rows carry, and the caption names the runs and says what the errors leave out. A run that failed wrote no archive and has no exposure at all: the line breaks at it rather than drawing a zero, because a failure is not a value of zero. The exact numbers are in the table under the plot, one row per run, with each row's state and its partial mark, so the plot never replaces what a reader checks. The plot is inline SVG written in the prototype's own script: a prototype opens from file:// with no build, no CDN and no network, so no chart library is loaded or copied in.

A donut never hides a part the errors left out. The latest run's donut hatches the positions the run did not place as a slice of its own, labelled excluded and stated in the legend with its count, so the pie is the whole population the window priced and not a quietly smaller set. Its hole carries the two counts together, and the caption says which is which. A run that completed clean leaves no such slice, because it left nothing out.

The scenario results-with-errors, reachable with ?scenario set to that value, draws the latest run as a run that completed carrying what its errors left out: it adds three error rows and four unplaced positions to the fixture, the exposure point goes hollow and dashed, the donut's hatched slice appears, and the run's health changes to completed with errors. It arranges the run's own fixtures and changes no run; the page says so in a banner that carries no dismiss, because a partial figure a reader may put away is a figure a reader will take as whole.

The exposure figure itself is a fixture, like the runs: it is what a run's archive says once something parses it, and nothing parses it today. The amber note on the page says so.

This is the part the prototype exists for. The pattern is the one the record screen standard calls Recency, and the page follows it exactly:

• The change signal is `reporting.v1.events.report_instances.created`, which the screen listens to. It does not poll.
• When a run arrives, Refresh draws the eye.
• Rows newer than the previous load are marked for three seconds after a reload. The first load marks nothing, and a person can turn the marking off.
• A notice, not a modal, states that the run being read is no longer the latest, names the new run's time, and offers a way to it. It does not navigate on its own and does not steal focus.

The arrival is simulated with a button in the bar, and the page says so, because nothing on a page opened from a file can receive an event.

Everything. The report, its party, its schedule, the twelve runs, their times, their durations, their errors, and the exposure each run carries are mock, so every point on the trend is a fixture. No service is read, there is no reporting BFF route, and the application has no reporting UI.

doc/prototypes/reporting/look-back-over-a-reports-history/. Three files, plain HTML, CSS and JavaScript, no framework and no build step.

None yet. This page is on the branch that proposes it and waits for review. The part that must survive whichever variant wins is the notice: a person reading a superseded run is told, quietly, and is not thrown at the new one.

Whether a history belongs to a report definition or to a report type. This page argues a definition, because that is what the runs belong to and what the schedule is attached to. If a reader thinks in report types across parties, the page is answering a narrower question than they are asking.