Record screen standard

• RS-LIST-01 The breadcrumb (Crumbs), whose shape is the Menu structure page's, then the plural as the title, in sentence case (PageHeader).
• RS-LIST-02 One sentence that says what the records are.
• RS-LIST-03 At the right, Refresh, then Import and Export for a kind that has an ORE document (Export stands on the record header instead when the document is one record; see RS-ORE-02), then Workflows, then Add. Add is the primary button and is drawn only for a person who may write. Workflows is a menu of the guided workflows that act on this kind of record, such as onboarding a party. It lists only those the person may start, and is not drawn when there are none. A workflow is not Add: Add is one record and one write in a dialog, and a workflow has several steps and its own address.

• RS-LIST-04 A search box over the display field and the key. The search goes to the server through the list contract's filter, so it searches every record, not the page on the screen. A filter over the rows on one page is not a search.
• RS-LIST-05 Where a kind has a natural classification, such as a tier or a type, a filter select beside the search. Where a kind hides some records by default, such as test tenants, a toggle that shows them. A filter is a ListFilter of the list's source; its value is held in the address as f.<id> and sent with the page.
• RS-LIST-06 What the list says about the page sits above the table as a note: what the server's answer adds, such as how many records a filter hides, and what the screen knows before any read, such as why the list is read only.
• RS-LIST-07 Where the generated list contract has no filter for a field the search needs, the contract is extended. The screen never reads every row to filter them itself. See Lists are always paged.
• RS-LIST-08 A filter that matches nothing says "No <plural> match the search." and offers to clear it.

• RS-LIST-09 The columns come from one column list per kind. The display field or the key is the first column.
• RS-LIST-10 One row opens the record page on a click, and on Enter when the row has focus. The table is reachable from the keyboard.
• RS-LIST-11 Selection is single. Bulk changes are a separate feature, not a table mode.
• RS-LIST-12 Every column sorts on the server through the list contract's order, on the value, not on the text shown. The default order is the kind's natural order: the display order, then the name, for reference data; most recent first for records that accumulate.
• RS-LIST-13 The audit columns (version, modified_by, performed_by, recorded_at, change_reason_code, change_commentary) are hidden by default and offered in a column menu. tenant_id and an id that is a UUID are never shown.
• RS-LIST-14 Which columns show, and in what order, is remembered per person in the browser, under a key that carries the column set's version.
• RS-LIST-15 A cell follows the cell rules in Icons and cells.

Every list pages on the server. This is the rule the Qt standard had, and the memory Lists are always paged repeats.

• RS-LIST-16 A list reads one page with offset, limit and the server's total, through the generated list contract. It never reads with a large fixed limit, and it never pages to the end to show everything.
• RS-LIST-17 The footer is the shared Pager: the count first ("1–15 of 168"), then First, Previous, Next, Last, then Page size with 15, 25, 50, 100, 200 and 500. Every paged list starts at 15 rows, about one screen (DEFAULT_PAGE_SIZE); no screen sets its own default.
• RS-LIST-18 Load all is offered only when the server's total is 1000 or less, and then reads that total in one page. It is the whole list by the server's count, never a cap, so it keeps the rule in Lists are always paged.
• RS-LIST-19 A new search, a new filter, a new order or a new page size returns to the first page. A write reloads nothing and turns Refresh gold. Refresh keeps the page the person is on, after a write as after any change, and the marked rows and the strip say where the change fell; a record that the sort moved off the page is the strip's case. The person loses their place only when the page no longer exists, and then the list shows the last page (decided 2026-10-25 by the owner; the Entity screen specification's Refresh section says how the list shows a change).
• RS-LIST-20 The page, page size, search and order are held in the address, so a link and the browser's back button restore the list.

RS-LIST-21 The list shows one of these states and never a blank table:

RS-LIST-22 When a change notification says a record of this kind changed, the list marks Refresh as stale. After a reload, a row that was not on the page before, or whose content is not what it was, gets a gold left edge and pulses three times, and the mark goes after four seconds (MARK_MS in refdata/changedRows.ts, three cycles of 900 ms in styles.css). The comparison is with the same page read before and uses no clock, so the first load marks nothing and moving to another page marks nothing. There is no control to turn the mark off (decided 2026-10-25; the rule is the Entity screen specification's Rows and entries that changed). The notifications come from Change notification.

• RS-PAGE-01 The breadcrumb, then the display field as the title.
• RS-PAGE-02 The lead line reads "<key> · version <n>" (refdata.records.lead).
• RS-PAGE-03 The actions at the right, in this order: the kind's own actions (such as Derive a calendar), then Edit, then Delete. Each is drawn only for a person who may take it, and only when the record allows it.
• RS-PAGE-04 Edit stands on the thing it changes, and the version stands beside the thing it versions. A record of one kind is one card, so both stand in its header. An entity is a card per record, so both stand on each card, as the Entity screen specification draws them (decided 2026-10-25).

RS-PAGE-09 The tabs are held in the address (useRecordTabs). In this order:

A tab that does not apply to this record is not drawn: a derived calendar has no Rules tab. A tab that applies but holds nothing yet is drawn, with "None yet." and its Add.

• RS-PAGE-05 A label above each value, in sentence case, with no colon.
• RS-PAGE-06 The values stand in a grid of one column, two from the small breakpoint and four from the large one (RecordDetails, grid gap-4 sm:grid-cols-2 lg:grid-cols-4), in the field table's order, so a value stands where its field stands in the form. Under a value stands what it means or why it is fixed, in one line of small faint text, when there is something to say (decided 2026-10-25).
• RS-PAGE-07 A value with nothing in it shows a muted dash, so a blank is not taken for a failure to load.
• RS-PAGE-08 A classification shows its label (ClassifiedValue). A code that names another record is a link to that record's page.

RS-PAGE-10 The Details tab ends with the provenance of the current version, in this order: version, modified by, performed by, recorded at, change reason, commentary. When modified_by and performed_by are the same person, the line names them once; otherwise it reads "<modified by> for <performed by>". The time follows the timestamp rule in Icons and cells: relative, with the exact value on hover. A record with no versions has no last-changed line.

RS-WRITE-32 The form is drawn from the field table. One control per field kind:

• RS-WRITE-01 A field that names another record or a classification is always a select, never free text.
• RS-WRITE-02 An optional field writes null when it is empty. A field with when is asked for only while the other values meet it, and writes null otherwise, as the rule form does for each rule kind.
• RS-WRITE-03 The key is entered when the record is created and is fixed after that (fixed). So is a field that changes what the record is.
• RS-WRITE-04 A field the server needs but the person does not edit, such as an image, is carried over from the record (keep). A field the screen sets, such as the parent of a part, is given by the screen (given).
• RS-WRITE-05 A field that fails its check shows the message under it when the person leaves it, and focus moves to the first such field on save. Save is disabled until the form is complete.
• RS-WRITE-06 Long text, such as commentary, is a text area, and a field table asks for one with the longtext kind. A field kind this table lacks, such as a time, a multiple choice, a percentage or an amount, is added to the table and to FieldInput before a screen uses it, as an icon is added to the icon table (decided 2026-10-25).
• RS-WRITE-07 A field that follows from others, such as a key derived from two codes, is not asked for. The dialog fills it before the write (complete), and a revert fills it the same way.
• RS-WRITE-08 A rule across fields, such as two codes that must differ, is said in the dialog before the save (check), and Save waits on it.

Decided 2026-10-25, from what the shared dialog does and what the Qt dialogs needed. Each rule names the part that carries it.

• RS-WRITE-09 One dialog, no tabs. A form is one scrolling dialog (Dialog with wide, which is 48 rem). It never splits its fields over tabs, as the Qt currency dialog did. A kind with many fields declares groups in its field table, and a group is a titled section inside the one dialog, in the field table's order. A form with twelve fields or fewer declares no group.
• RS-WRITE-10 Order. The fields stand in the field table's order: the key first, then the display field, then the rest in the order a person reads the record. The reason and the commentary come after every field, because they are about the change and not the record.
• RS-WRITE-11 Two columns. The fields stand in a grid of two columns from the small breakpoint and one column below it (grid gap-3 sm:grid-cols-2). A longtext field spans both columns, and apart from it a field is never wider or narrower than its column.
• RS-WRITE-12 Each field. The label stands above the control, in sentence case, with no colon (Field). Under the control stands one line of small faint text when there is something to say: the field's help, or what its value means (means), or why it is fixed. A wrong field shows its message under it when the person leaves it, in place of that line.
• RS-WRITE-13 Required and optional. Nothing marks a required field. A required field left empty shows Required under it when the person leaves it, which is the message of the rule above on a field that fails its check, and Save waits. An optional select offers a dash as its empty choice; an optional picker offers Clear, as the Entity screen specification says. No label carries the word optional.
• RS-WRITE-14 Buttons. The dialog's footer holds Cancel, then the primary button, Add or Save, at the right. Each carries its icon. Delete is never in the form: it is an action of the record page with its own dialog. While the closing guard is up, the footer holds Stay and Leave instead.
• RS-WRITE-15 Keyboard. Escape asks the closing guard when there are changes and closes when there are none. Enter in a field does not save, because a save carries a reason the person must have chosen. Tab moves through the fields in the field table's order.
• RS-WRITE-16 The dialog says when its record was loaded, under its title, and warns of a newer version above the form, as the Entity screen specification's An edit in progress says. This standard adds nothing to it.

• RS-WRITE-17 The dialog is titled "Add <thing>" and its button is Add.
• RS-WRITE-18 A new record is written with the reason system.new_record, the only reason that applies to a new record, so the dialog states it in a note instead of asking. It is written with must_not_exist: adding a key that exists is refused, and the refusal names the key.
• RS-WRITE-19 After the write the screen opens the new record's page.

• RS-WRITE-20 Edit opens the record dialog with the current values. Its title is Edit followed by the title of the page, which is the display field, so the dialog and the page name the record the same way; a card's dialog is Edit followed by the card's title (decided 2026-10-25). Its button is Save.
• RS-WRITE-21 The person picks a change reason from the server's reasons for an amendment (useReason('amend')), and writes a commentary when the reason needs one.
• RS-WRITE-22 The reasons follow the change. When a field changed, common.non_material_update is not offered. When no field changed, only that reason is offered. The set is worked out from the difference between the form and the record.
• RS-WRITE-23 The write claims the version read (must_match_version). A record that changed since is refused with 409, and the screen says so and offers to reload.
• RS-WRITE-24 Leaving the dialog with changes asks "You have unsaved changes. Close anyway?"

• RS-WRITE-25 Delete opens the remove dialog. Its title is "Delete <key>?" and it says what is lost, and whether history stays: a versioned record keeps its history; a link does not have one.
• RS-WRITE-26 The person picks a reason for a deletion (useReason('delete')) and writes a commentary when the reason needs one.
• RS-WRITE-27 The write claims the version read. A record that changed since is refused with 409.
• RS-WRITE-28 Parts that belong only to this record are deleted first, with the same reason, and the dialog says so. Links from other records are not deleted, and the dialog says so.
• RS-WRITE-29 The parts and the record are deleted one after another, because the server has no operation that deletes them together. If one fails, the dialog stays open and says which failed; the record itself is not deleted, so a retry finishes the work. A server operation that deletes a record with its parts in one transaction replaces this.
• RS-WRITE-30 After the delete the screen returns to the list.

RS-WRITE-33 A record the server does not let a person change, such as a QuantLib calendar or a country, shows no Edit and no Delete, and says why in one notice on the Details tab. Its kind may still offer an action that makes a writable record from it, as Derive a calendar does.

A link joins two records and has no versions, such as a currency's countries or a desk group's members. The links panel (LinkPanel):

• RS-RELATED-01 lists the linked records by key and name; a name opens the linked record's page;
• RS-RELATED-02 adds a link by picking a record that is not linked yet, and writes it with system.new_record;
• RS-RELATED-03 removes a link with Remove, not Delete, because the linked record stays.

A link has no history, so the panel has none.

A part belongs to one parent and has its own versions, such as a calendar's rules, exceptions and diary events. The parts panel:

• RS-RELATED-04 lists the parts in their natural order, with the columns the kind declares;
• RS-RELATED-05 offers History, Edit and Delete on each row, and Add under the table;
• RS-RELATED-06 opens the record dialog for add and edit, with the parent given, the shared timeline (Timeline) in a wide dialog for the one part, and the remove dialog for delete. The two-pane compare of HistoryPanel is the legacy shape and is not what this rule names (decided 2026-10-25).

Neither panel edits in the table. Neither offers Add while the parent is being created: the parent is saved first, and its page then offers the panel.

RS-FEEDBACK-07 Every message says what happened and what to do. "Error" on its own is not a message, and the server's own words are shown where a write was refused.

• RS-FEEDBACK-01 An action a person may not take is not drawn, rather than drawn disabled. useRecordPermissions decides from the registry and the person's roles.
• RS-FEEDBACK-02 Whether the person may change a record is shown by the access mark, Editable or Read only, in the record header and beside a form panel's title, as UX Language sets it. A screen never shows a permission code.
• RS-FEEDBACK-03 The server decides; the screen only hides what the server would refuse. A refusal is shown as a refusal, not as a failure.

• RS-FEEDBACK-04 Delete always confirms, names the record, and says what is lost.
• RS-FEEDBACK-05 Revert always writes a new version and says so.
• RS-FEEDBACK-06 Every write carries a change reason; there is no silent write.