Change what a report runs prototype

1. The definition and the configurations it binds. The definition's name, type and party, then the five configuration types with what each supplies and where its data lives. A conventions configuration is a named convention set, so its row shows the set chosen below, and below the table sits the one page of sets the report chooses between: a row each with its name, its purpose, the kinds it covers and whether this report uses it, a radio to bind one, and one link out to the authoring UX marked as not in this MR. It draws no per-kind row. The other four types have no screen in the application, and they are stated as missing, never drawn as working. The panel also names the other definitions bound to the shared configuration, because the analytics belong to it and not to the definition that was opened.
2. The analytics. A read-only summary of the set the bound configuration carries: the count that is on, every row with its display_order and a one-line statement of what it produces, the rows kept off with the note that they keep their order and their parameters, and the rule strip when pfe is on without simulation. Then the link to Manage the analytics.
3. What a change reaches. What the change reaches and does not reach, the runs that stop being comparable, that past runs keep their configuration, and where the write happens.

The panels are deep-linked with ?step=1|2|3, and step is part of every URL the page writes.

The analytics belong to the run settings configuration, not to the definition, so the same set is what four definitions run. Two prototypes were drawing that set: this one with a switchboard and a nested flow, and Create a report with a switchboard and a rail step per analytic. The same fourteen types had two vocabularies for the same three states — on, off, and no row — and the parameters of an analytic were drawn twice.

The product owner asked for one screen to own analytic management. This page keeps the wizard over the definition and the configurations, and it keeps one panel that answers the question the journey asks: what does this report run, and what changes if I change it? Every control leaves the page. Step 2 states the set and the incompatibility, and links to the screen that changes it.

What the consolidation costs:

• A step out of the wizard. Reading the set and changing it are now two places. The person returns to step 2 when the shared screen is done, and this page cannot say whether it was opened or what changed while it was.
• No parameter control on the summary. The values are not on this page at all, so a person who wants to check one setting leaves the wizard. That is deliberate: a read-only summary that also drew the settings would be the second implementation again.
• The three variants move. They read the per-analytic step, so the open layout question travels to the shared prototype with the screen it belongs to. This page has no ?variant.

The state it keeps is the one this journey is about: which rows are on, in which order, which rows were kept off rather than deleted, and whether the pair pfe and simulation can run.

This page states the rule even though it does not draw the control: turning an analytic off is a write of active = false. The row keeps its display_order and its configuration_analytic_parameter rows, and reads as off, so the history shows the report used to produce it. A type the configuration never carried reads as "no row" on the summary, and the shared screen offers it as a type to add. No control anywhere removes a row.

pfe reads a cube that simulation writes, so pfe on without simulation cannot work. Step 2 marks the pair in red on the summary, with a tag on each side naming what is broken, and it names the rule: it lives in the ACME seeder, in generate_risk_config_data.py, function check_exposure_needs_simulation, and in no service, so the write would be accepted and the run would fail later. The refusal of the write itself belongs to Manage the analytics, which will not write either row of the pair while it is broken.

simulation and pfe need purpose-built editors for the cube, the shift and the time grid. Manage the analytics draws those settings as plain fields and labels each one a deferred editor on the parameter itself. This page says so once and names the screen, rather than drawing the fields a second time.

A run keeps the configuration it ran with, with its outputs and its errors. The configuration is shared, so a change reaches every definition bound to it, including the three the person did not open. Nothing reaches the definition's schedule, its processing phases, its concurrency policy or its other four configurations.

The results screen compares a run with a previous run of the same definition. A run made after a change did not produce the same measures, so the comparison between it and an older run is not a comparison, and step 3 says that plainly. It places each run by its own start time against the definition's version history and marks the placement an inference, because no operation says which configuration version a run used and the analytics are not on the definition. The results screen marks a comparison partial where a side carried errors; it cannot mark this case at all.

The definition, the five bindings, the eight analytic rows, the convention sets with their names, purposes, descriptions and kind counts, the runs, the versions and the clock are fixtures. Nothing reads a server and the page sends nothing. The rules are not fixtures: active = false is how the model turns an analytic off, and pfe without simulation is a rule the seeder enforces and no service does. The convention sets are a fixture for a reason the page states: no table stores a set's name or purpose, nothing marks the document a run reads for a kind, and the conventions configuration carries no children. Authoring a set is deferred to its own work, so the link out on that page opens nothing.

doc/prototypes/reporting/change-what-a-report-runs/. Three files, plain HTML, CSS and JavaScript, no framework and no build step. The stepper is this page's own; the standard steps UI belongs to Manage the analytics, because this journey is three panels about one definition rather than a walk through a set.

None yet. This page is on the branch that proposes it and waits for review.

Which runs a change reached. Until an operation names the configuration version behind a run, every placement on this page is an inference, and a build can only repeat that inference. The parameter's allowed values are unsettled too: no operation in the journey's set reads the value domain, so the shared screen draws a select only where its fixture knows the enumeration and a text field where it does not. The four configuration types without a screen are unsettled in the plain sense: nothing shows them, so step 1 can only say where the data lives. And it does not settle what a wizard should do when one of its steps is finished on another screen.