A screen is assembled from the outside in, and each layer does one thing. Keep the order and two screens from different applications look like one product — which is the only reason the kit exists.

1. IngotAppFrame — the screen's width and the margins beside it, with the bar stuck to the window. Its contentClassName takes INGOT_FRAME_ROW, so the bar's row lines up with the content below.
2. IngotPageLayout — the vertical rhythm of the blocks and the shape of the content: full for lists, wide for a detail, aside for a screen with its own index.
3. The blocks in the binding order: breadcrumbs, the header, IngotToolbar above the data, IngotSection around each whole.
4. Inside a block, IngotColumns for a form and IngotDescriptionList for facts. A screen writes no grid of its own — that is exactly where applications drift apart.
5. IngotSkeleton instead of a blank until the data is there, and IngotActionBar as the last block, so Save stays in reach past the ninth field.

The reference consumer assembles exactly two screens this way — a list of orders and a detail — and a guard holds it: a hand-written table, button or list in them fails the build. Without that, “composed only from the kit” is a claim rather than a check.

The frame is one row at the top: the brand, the application's sections and the account. Content below it runs full width. The admin has no side menu — its screens are wide tables, and a column bitten off on the left is a column missing from the table.

• A section is a button, not a link — it opens a menu and goes nowhere on its own. The links are the items inside.
• The customer-facing product uses the same bar with different content: another brand without the badge, other sections, possibly a trial badge. Two products, one frame.
• The bar does not wrap — whatever does not fit falls off the edge. The measure is not a fixed count but the narrowest supported width: every section with its label must fit at 1280 px. The admin carries eight today; when the bar breaks, shorten labels or merge two sections.

The frame measures height in dvh, not vh. On iOS Safari vh is the height of the window with the browser chrome retracted — with the bottom bar out the screen therefore ends below the lower edge, and a dialog takes its footer, the one holding the primary action, down with it. dvh follows the chrome as it comes and goes.

The safe areas are held by the kit itself: the top bar pads above, the action bar below, and the panel on the side it slides in from. Switching them on is the consumer's job, though — without viewport-fit=cover, env() returns zero and no padding appears anywhere:

<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">

• Without that line nothing changes — not on a phone, not on the desktop. It is not a choice about looks, it switches the measurement on.
• With it the top bar's surface reaches under the notch, and in a window launched from the home screen the action bar no longer sits under the home indicator. The bar's row and the actions stay above them.
• On Android and on the desktop the insets are zero, so the result there is the same to the pixel as before.

A section opens into groups of links — one column up to seven items, two above that — plus a preview column on the right. The preview describes the item you are on, by mouse or by keyboard; until you are on one, it describes the first.

• The preview follows the item under the cursor and under focus — the keyboard is not a second-class citizen. A screen reader hears the description from the link itself, so the preview column is a visual copy.
• An open section is marked with the --surface-3 surface, not the accent. The accent means an action, and an open menu is not one.
• The count next to an item is mono — it is a number meant to be compared with the rows around it.
• Columns grow from the content, they are not a fixed grid. Real sections hold one to eight items, so three hard-coded columns leave most of them with two empty ones — and an empty column tells the reader something is missing.
• The preview follows the reader; it does not stay on the first item. Describing the item they are on answers the question they are asking right now; describing the first item would, at the eighth, answer the one they asked a moment ago. The section's drawing above the text stays — it marks the section, it does not illustrate the item.
• From the keyboard the arrow keys drive the panel: they open the section and walk its items. Tab does not fall out of an open panel, and Esc closes it and returns focus to the section button.

The account holds more than links: it holds the preferences that apply across the whole product — theme, language, vocabulary and on-page help.

• A preference is stored on the account, not in the browser — it follows the person to another computer.
• Turning help off must not change the page layout. What is hidden is visibility, not space; otherwise the screen reflows under the reader and they lose the spot they were looking at.
• The vocabulary drives domain terms across the whole product, not just on one screen.
• The advanced raw-data view is never on by default.

Below the bar the order is always the same: breadcrumbs, the page header, and only then the content. The numbers a screen is read by at a glance sit right under the header.

The right side of the header holds actions OR numbers — not both. A screen where nothing gets created puts a cluster of two or three numbers there instead of buttons; it is the same component as the strip, only denser.

• There is exactly one primary action and it sits at the top right of the header. It never floats above the content.
• The numbers in the header and the strip below it are two densities of one component, not two components. Two or three numbers fit in the header, four to six in the strip — and both at once turns the screen into an overview of an overview.
• The last breadcrumb is not a link — it is where you stand. On a section's root page breadcrumbs are not drawn at all.
• A coloured number means that number is a problem, not that it is the most important one. Half a coloured strip says nothing.

Settings screens are assembled from recurring blocks. Configuration is not one long form — steps get finished on different days by different people, so each step carries its state permanently.

• A finished step is recognisable by shape, not colour alone — the green header comes with a tick instead of a number.
• A step's footer adds another item. A step is not confirmed by a button: it is done when it has what it needs.
• A choice with a consequence is made on a card with an explaining sentence, not an option in a dropdown. That sentence is half the choice.
• A finished step collapses on its own and leaves a header with a summary behind (“3 / 3 active”). Otherwise a setup of eight steps pushes the unfinished one below the fold.

A named group of records is its own card: the header says whose it is and how much it holds, the table shows the content, and the footer adds another item to it. The card carries no padding of its own so the table lines up with its frame.

• Every block has its own header and its own “add” footer. A single floating button above the list of groups would have to ask which group it adds to.
• The footer sits on --surface-2, so it reads as a tool of the card rather than one more table row.
• Adding from a list, not an empty field: attributes are an enumeration someone established elsewhere. A free field here would establish typos as new attributes.
• The key is code, so it is set as code — and not translated. A row's state is carried by a dot and a word, not colour alone.

A screen listing records assembles its blocks in a fixed order. The order is not a choice — a reader who knows it from one screen finds it on all of them.

1. IngotToolbar — search and filters above the list.
2. IngotTable — the records; selecting rows opens the bulk actions.
3. IngotRowActions — the actions of one row, always at its end.
4. IngotEmptyState — when there are no records, it says why and what to do.
5. IngotPagination — paging below the list.

Editing a record goes into a side drawer so the context stays visible. Confirming an irreversible step belongs in a confirm dialog that states the impact, and the result is announced by a toast with an undo. A modal is only for a step that must not be interrupted.