The frame the cards sit in

Between a design system and a single screen there is a third level: the shell and the handful of page patterns most pages share. This site catalogues that level as layouts you can see, check and copy.

• 1. Seven zones
• 2. Shells
• 3. Page patterns
• 4. Widths and the reflow table
• 5. The scorecard
• 6. Composing with cards and worlds
• 7. Taking a layout away
• 8. Batch 001: Application shells

1. Seven zones

Every layout here is built from the same seven zones, each with one job that stays the same on every page. A layout may leave zones out; it never invents an eighth, and the wireframe labels use only these seven words.

Two decisions cut across the zones: what stays fixed when the page scrolls, and how much height the fixed chrome takes before the content begins. The site writes the second down in pixels for every layout and holds it to a budget.

2. Shells

A shell is the arrangement of the zones: which exist, where they sit, what stays fixed. It is named by where the navigation lives (top, left, a rail, the bottom, a drawer, or nowhere) and how many panes there are. The first round defines fourteen: eight for applications, four for mobile, one for the web and the dashboard, which is the sidebar shell with a grid for content.

3. Page patterns

A pattern is what the content zone holds, as named slots: a list has a toolbar, a table, a footer and an optional panel; a record has an identity, tabs, a main column and an aside. Each pattern carries its own rules in plain words, a maximum width where reading or filling matters, and which slot scrolls. A layout is one shell plus one pattern.

4. Widths and the reflow table

Four widths with four names, used everywhere: on the stage radios, as the keys of every reflow table and in the exports.

The reflow table is the core of every layout: one line per present zone at each width, saying what that zone does there. A line that says default inherits the site's default for that zone (below); a line that says same means nothing changes from the width before. The table on each layout page highlights the column the stage is showing.

Each layout's CSS reflows with container queries on its own root (container: screen / inline-size), at min-width 768, 1024 and 1440; compact is the base. The stage's screen is exactly the chosen width, so the radios simply set the width and the queries fire as they would in a real window.

5. The scorecard

tools/check.py validates every record and runs the zone rules. Each rule gives one word, Pass, Watch or Fail, printed on the layout page and faceted in Browse. Four of the rules are measured on the rendered stage: the build renders every layout at the four widths in headless Chrome with the site's own renderer and reads the fixed chrome, the scrolling zones, the panel's side and whether the messages zone clears the header's primary. Zones that overlap or leave the screen there are errors, not words.

6. Composing with cards and worlds

Wireframe is the default everywhere: grey blocks drawn into the slots by kind (text lines, a media block, rows, tiles, two buttons) and one shared chrome vocabulary for the nav and header, so the layouts differ in structure, not in sample copy.

Filled mode reads the layout's one honest fill, written as card:<id> x N with commas between items, and renders real cardui cards into the slots through cardui's own renderer, loaded from /cardui/js/app.js and /cardui/js/kit.js, never copied. With no world the cards sit on cardui's paper palette with the Inter pairing. The world select dresses the stage in a Worlds token sheet through CU.applyWorld: colours, radii, shadows, control heights and fonts change together, because every template uses the world tokens and never a literal.

7. Taking a layout away

Two exports, both on every layout page. The skeleton is the template HTML with its zones and slots as named regions, and the CSS with its container queries, standalone, with the chosen world's tokens inlined in a block (or the defaults). The zone sheet is a Markdown file: the zones and their jobs, the reflow table, the chrome budget, the pattern's rules and slots, the recipe and the scorecard. It is what a model builds against: one line per zone per width, made concrete.

Layouts is a picker and a decision aid, not a starter kit. A real app copies what it needs from these two files and is built as needed.

8. Batch 001: Application shells

Every layout in the batch passes all eleven rules. The decisions worth knowing: the nav collapses to icons by default where a page needs width (the three-pane inbox, settings, the board and calendar at expanded); the top bar list lets its header scroll away so its fixed chrome is the top bar and the toolbar; the record's tabs sit in the toolbar because they change the view; the form's header carries no primary, so Save is never in two places; the canvas builder treats its layers as navigation and floats its toolbar over the canvas.