Task: Build the engine settings screens

A person lists the engine settings configurations of a party and opens one page with a tab for each group, its documentation read from ore_parameter, and edits a group in place.

• The list and the page follow the prototype see-the-engine-settings-a-party-holds.
• The documentation of each setting comes from ore_parameter and not from the screen.
• The Gemini review is taken up where the prototype page says so.

(Implementation strategy. Written when work starts; key decisions are distilled into the parent story's * Decisions at close, but the plan itself stays — it is the historical record of what we did.)

Every number this task claims about a tree, with the command that produced it and the commit it was measured at. A number without both is not a measurement, because a clean-up record describes a tree and trunk moves under a branch: a consumer count, a gate's component count and a suite's size all change with no code changing, and the reader of a bare number cannot tell which tree it came from. Where the raw output matters, put it in an evidence/ file beside the task and name that file in the Command column.

Manual QA scenarios (scaffolded via compass add test_scenario) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

The engine settings list and record screens are built from the prototype and the Gemini review. The list searches and orders the configurations and offers Add. The record page has a tab for the details, one for each of the three groups, one for the reports that bind the configuration and one for its history.

A group is read and changed in place. Each setting shows its value, or the default the engine uses when it is not set, with its documentation under it. Edit turns the group into a form, the first option of each control is the default, and Save writes the group alone against the version of its row, with a reason. A group that changed since is a conflict. Simple and Advanced is the shared switch, and Advanced adds the schema panel of the Gemini review: the ORE XML path, the release that introduced the setting, the release that removed it and the format.

What the prototype took from the Gemini review is in the screen: the schema panel, two filters and a count of the changes not yet saved. The filters are Set in this configuration and Changes the numbers. The first replaces Changed from default, because the data holds the default as text and the screen cannot say whether a set value differs from it. The Gemini settings that no ORE release reads are not on the screen.

All the wording of a setting comes from its ore parameter through the BFF. A setting whose ore parameter is missing shows its ORE name and a note, so a gap in the data is visible and not hidden. The History tab reads the versions of the central row and of each group, compares each group version with the one before, and offers Revert, which writes the values from before a change as a new version.

The tabs and the history are tested as a static render from a seeded cache, like the pricing engine screens. The model is tested on its own: the values of a group, the check of a value, the difference a change makes, the filters and the steps of the history. Nothing has run against a live service, because no service of this environment runs. The first run against a deployment should open a configuration, change a group and read the history.