Task: Write the configuration screen standard
Table of Contents
This page documents a task in the Make every configuration screen follow one standard story. It captures the goal, current status, acceptance, and any notes or results.
1. Goal
One standard page states the words, the list, the record page, the sections, the documentation, the reach, the history, the import, the lifecycle and the naming rules for every configuration screen, with the engine run settings as the reference and the pricing engine configuration as the second application.
2. Status
| Field | Value |
|---|---|
| State | DONE |
| Parent story | Make every configuration screen follow one standard |
| Now | Nothing. |
| Waiting on | Nothing. |
| Next | Nothing. |
| Last touched | 2026-10-24 |
3. Acceptance
- The standard is a knowledge page in doc/knowledge/ui and is wired into the UX hub reading order.
- The screen review checklist carries one line per rule, naming the standard and its section.
- The standard fixes the screen words for every configuration kind and states which model names they replace.
- The standard states which rules are universal and which a kind declares, including its sections and its lifecycle.
- The standard carries a conformance table for the two configuration screens that exist, with each gap named.
- The standard states the prototype changes it requires, and the story carries those tasks.
- The standard follows ASD-STE100 and the UX Language.
4. Plan
4.1. Why
The engine run settings work of sprint 28 produced a screen shape that every configuration coming off an ORE document can use: a named configuration, a tab per section, documentation read from data, editing in place, a read of the reach and the shared timeline. The pricing engine configuration predates it and does some of those things differently. The two kinds also carry names that a person confuses. The owner decided the screen words and the per-section lifecycle on 2026-10-24, and asked that the journeys and prototypes carry them before this page was written.
4.2. What this page states
- The words, and the name of each of the 19 configuration kinds.
- The family: a configuration is a named, party-owned, versioned set that a report binds in a slot.
- The list, the record page and the fixed tab order.
- The two section shapes: a group edited in place, a collection edited in dialogs.
- Reading a group and changing it, including the value in force and the default.
- The one documentation contract.
- The reach, the history and the per-section lifecycle.
- The import and the export.
- The sentence that says what a configuration decides, and the related configurations card.
- The states, the owning-party rule, and how to add a kind.
- The conformance of the two screens that exist today, and the prototype changes the page still requires.
4.3. Where it is wired
- The UX hub reading order, after the feed standard.
- The screen review checklist, as 14 lines that name this page.
- The menu structure, where the Reporting area now names its configuration screens.
5. Measurements
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.
| What | Value | Command | Commit |
|---|---|---|---|
| Configuration kinds named | 19 | the configuration_type seed |
546313dbbf |
| Checklist lines added | 14 | the section this page adds | the standard branch |
| Rules in the conformance table | 10 across 2 screens | the table below | the standard branch |
6. Notes
6.1. Conformance of the two configuration screens today
Measured on origin/main at the time of the investigation, from the BFF routes and
the web screens. This is the gap list the standard must normalise; it is not the
standard.
| # | Rule | Engine run settings | Pricing engine configuration |
|---|---|---|---|
| 1 | A named, party-owned, versioned configuration bound in a slot | Meets | Meets |
| 2 | Details, one tab per section, Used by and History | Meets | Gap: Details, Products and Settings are stacked sections; no Used by and no History |
| 3 | A group edits in place; a collection edits in dialogs | Meets | Meets for the collection dialogs |
| 4 | One documentation contract, keyed by schema and XPath | Meets, from ore_parameter |
Gap: wording lives in pricing_model, pricing_method, pricing_pair_setting and sensitivity_template |
| 5 | The value in force and its default, with Simple and Advanced | Meets | Partial: usual values, no default-in-force and no schema panel |
| 6 | Reach is read, not guessed | Meets: the BFF reads the bindings by configuration id | Gap: the page states that the reach cannot be read |
| 7 | History is the shared timeline with Revert | Meets | Gap: no History tab |
| 8 | A numbers-changing change is a proposal; an operational change lands directly | Gap: every section edits in place | Gap: the model has no status, cycle or sign-off; the prototype draws them |
| 9 | Import parses on the server, states findings and difference, and drops nothing in silence | Gap: no screen; the run document import drops with a warning | Gap: no parse or diff operation |
| 10 | The page says what it decides and lists the related configurations | Partial: the lead says what it is; no relationship, no card | Partial: the lead says what it is; no relationship, no card |
Reads behind the table: projects/ores.web/packages/bff/src/engine-settings.ts,
projects/ores.web/packages/bff/src/pricing-engines.ts,
projects/ores.web/packages/web/src/engineSettings/,
projects/ores.web/packages/web/src/pricingEngines/ and
projects/ores.reporting/modeling/.
6.2. Where the rules come from
The ten rules are distilled from the engine run settings arc and the ORE source extraction in the investigation. Each one names the page and section that will state it, and the checklist will copy one line per rule.
7. Test Scenarios
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.
| Scenario | State | Notes |
|---|---|---|
8. PRs
| PR | Title |
|---|---|
| 3721 | [doc] Write the configuration screen standard (draft, waits on #3720) |
9. Review
| Comment summary | File | Decision | Notes |
|---|---|---|---|
10. Result
Merged in #3721. The configuration screen standard states the words and the name of each of the 19 kinds, the family and its slots, the list, the record page with the fixed tab order (Details, Global parameters, the sections, Used by, History), the group and collection shapes, the documentation contract, the value in force and the read/write rule, the reach, the history, the per-section lifecycle, the import and export, the related-configuration rule, the states, the access rule, how to add a kind and the conformance table.
It is wired into the UX hub, the screen review checklist (14 lines) and the menu structure.