had no rule either, and it is the one text element overflow-wrap cannot reach: white-space:pre forbids the line break that overflow-wrap would take. So the block scrolls instead — the same treatment .tablewrap gets, and the right one for code, where wrapping a line misrepresents it. */ pre { max-width: 100%; overflow-x: auto; } /* A bare is usually STRUCTURAL — nav, a card that links, a brand mark — and those must not read as body-copy links. Left at the browser default they came out underlined and, once tinted, painted every nav item accent-blue, which breaks the one-accent-per-page rule (the accent belongs to the primary CTA alone). So the base link inherits its surroundings and only reveals itself on hover; a link inside PROSE opts back into looking like a link. Anything carrying .btn keeps its own colour — a class beats an element. */ a { color: inherit; text-decoration: none; } /* :not(.btn) on both of these, and it is load-bearing (2026-08-13). An element selector with a pseudo-class or an ancestor outranks a bare class: `a:hover` and `.empty a` are both (0,1,1), `.btn` is (0,1,0). So an anchor rendered as a button LOST to them — every `` inside an empty state came out underlined and accent-coloured instead of a solid button, and every link-button anywhere recoloured its label on hover. Source order does not save it: `.btn` is four hundred lines further down and still loses. Reported from a real generated app, whose agent could only work around it in its own markup — design.css is frozen, so the app side cannot reach this. These three selectors mean "a link in PROSE". A button is not prose, so the right fix is for them not to MATCH it, rather than for `.btn` to fight back with a heavier selector. `.btn` re-states its own colour at :hover as well — see the note there for why both halves are kept. */ a:not(.btn):hover { color: var(--accent); } p a:not(.btn), .empty a:not(.btn) { color: var(--accent); text-decoration: underline; text-underline-offset: 2px; text-decoration-thickness: 1px; } /* Every number, ID, badge and metric is mono — this is what stops a data app from reading like a document. */ .num, td.num, th.num { font-family: var(--font-mono); font-variant-numeric: tabular-nums; } /* ================================================================== * * APP SHELL — sidebar + topbar + content * ================================================================== */ .shell { display: grid; grid-template-columns: var(--sidebar-w) 1fr; min-height: 100vh; } /* A grid item's default min-width is AUTO, not 0 — it refuses to shrink below its content's min-content width. So one wide table drags the whole 1fr track past the viewport and the PAGE scrolls sideways: measured 192px of horizontal overflow at 375px, with the shell's single column computing to 566.672px in a 375px window. The second cost is quieter and worse. .tablewrap already carries overflow-x:auto so a wide table scrolls INSIDE its card — but it never received a narrow box to scroll in, so it never scrolled once. This one declaration both stops the page overflowing and lets that existing rule do the job it was written for. */ .shell > * { min-width: 0; } .sidebar { background: var(--surface); border-right: 1px solid var(--border); padding: 14px 12px; display: flex; flex-direction: column; gap: 18px; } .sidebar .brand { display: flex; align-items: center; gap: 9px; font-weight: 600; padding: 4px 8px 0; } .sidebar .brand .mark { display: grid; place-items: center; width: 26px; height: 26px; border-radius: var(--radius-sm); background: var(--accent); color: var(--accent-ink); font-weight: 600; font-size: 13px; } .navgroup { display: flex; flex-direction: column; gap: 2px; } .navgroup > .label { font-size: 11px; font-weight: 600; letter-spacing: 0.08em; text-transform: uppercase; color: var(--icon); padding: 6px 8px; } .navgroup a { display: flex; align-items: center; gap: 10px; padding: 7px 8px; border-radius: var(--radius); color: var(--ink); text-decoration: none; font-weight: 500; box-shadow: inset 0 0 0 1px transparent; transition: background var(--dur) var(--ease), color var(--dur) var(--ease), box-shadow var(--dur) var(--ease); } .navgroup a:hover { background: var(--tint); } .navgroup a[aria-current="page"] { background: var(--accent-soft); color: var(--accent); box-shadow: inset 0 0 0 1px color-mix(in srgb, var(--accent) 18%, transparent); } .navgroup a .count { margin-left: auto; font-family: var(--font-mono); font-size: 12px; color: var(--muted); } .sidebar .foot { margin-top: auto; display: flex; flex-direction: column; gap: 10px; } .topbar { display: flex; align-items: center; gap: 12px; padding: 12px 22px; background: var(--card); border-bottom: 1px solid var(--border); } .topbar .spacer { flex: 1; } .crumbs { color: var(--muted); } .crumbs b { color: var(--ink); font-weight: 500; } /* The cap without the centering left the column pinned to the sidebar and every pixel past it dead: on a 1920 screen the content ended at 1424 and 465px of canvas sat unused to the right. The landing genre already centers its own container (see the .band rule); this is the app genre doing the same thing. */ .content { padding: 22px; max-width: var(--content-max); margin-inline: auto; } .page-head { margin-bottom: 18px; } /* ================================================================== * * TYPE * ================================================================== */ /* WORDS, not characters. body sets `overflow-wrap: anywhere`, which is right for the machine strings a generated app fills up with — an id, a hash, a bare URL — and wrong for everything made of words: it breaks ANY word at ANY point the moment its box is narrow. In a 210px card column that shipped as "Websit e Relaun ch" and "Q3 Marketi ng Campai gn" (customer screenshot, 2026-08-13). `break-word` is the difference: it breaks a word only when that word cannot fit on a line BY ITSELF, so "Website Relaunch" wraps at its space and a 60-character hash still breaks rather than overflowing. The body rule was measured and `anywhere` chosen over `break-word` for a REASON that does not apply here — it was about a flex or grid PARENT being forced open by its min-content, and a heading inside an already-sized column is not that case. */ h1, h2, h3, summary, th, label, .field > span, .field > label { overflow-wrap: break-word; } /* A heading needs its own ratio. Left undeclared these inherited the body's 1.5, which is a BODY-COPY ratio: it put 11px of leading inside a 22px title and made every two-line heading read as two separate lines. The ratio falls as the size rises, which is why h1 is tighter than h2. */ h1 { font-size: 22px; font-weight: 600; line-height: 1.2; letter-spacing: var(--tracking-tight); margin: 0 0 4px; } h2 { font-size: 16px; font-weight: 600; line-height: 1.25; margin: 0 0 4px; } /* Levels 3 to 6 had NO rule at all, so they fell through to the browser's own em-relative sizes against a 14px body — and the scale came out inverted: h3 rendered at 16.38px/700, both LARGER and HEAVIER than the h2 above it, and every level below carried a 16-22px margin nothing in this system asked for. An app that used

for a subsection got a heading that outranked its own section title, which is the kind of wrongness that reads as "the pages look inconsistent" without anyone being able to point at it. One weight for the whole scale, sizes that only ever go down, and the same `0 0 4px` h1 and h2 already use. / h3 { font-size: 14px; font-weight: 600; line-height: 1.35; margin: 0 0 4px; } h4, h5, h6 { font-size: 13px; font-weight: 600; line-height: 1.35; margin: 0 0 4px; } / Prose. Also unstyled until now: a
carried the browser's 1em top AND bottom margin, so two paragraphs sat 14px apart in a card whose own rhythm is 16px, and a list was indented 40px — outside the grid everything else lines up to. The trailing margin is dropped on the last child so a card does not end in a gap. / / A paragraph gets its rhythm on BOTH sides, not just below (2026-08-13). `margin: 0 0 12px` works for as long as a paragraph follows a paragraph — the two margins collapse and 12px is what you get. It fails the moment one follows something that has no bottom margin of its own: an input, a control row, a table. That is exactly the helper line the reference example teaches (`
No notes yet.
`), which therefore sat flush against the bottom edge of the field above it in a real app. Adjacent margins still collapse, so paragraph-after-paragraph is unchanged at 12px. The one case that would regress is a paragraph FIRST inside a padded box, where padding blocks the collapse and the 12px would be added on top — so `:first-child` takes it back. Every deliberate exception below (`.stack > p`, `.empty p`, `.hero p`) already states its own margin and is unaffected. / p { margin: 12px 0; } p:first-child { margin-top: 0; } ul, ol { margin: 0 0 12px; padding-left: 20px; } blockquote { margin: 0 0 12px; padding-left: 12px; border-left: 2px solid var(--border); color: var(--muted); } figure { margin: 0 0 12px; } p:last-child, ul:last-child, ol:last-child, blockquote:last-child, figure:last-child { margin-bottom: 0; } / The browser's
is a 2px inset ridge — a 3D bevel from 1996 sitting in a flat system. It is the same hairline every card and table row uses. / hr { height: 0; border: 0; border-top: 1px solid var(--border); margin: 16px 0; } .muted { color: var(--muted); } .small { font-size: 12px; } / ================================================================== * * CARD * ================================================================== / .card { background: var(--card); border: 1px solid var(--border); border-radius: var(--radius-lg); box-shadow: var(--shadow); / How much padding THIS card has, for the .list pull-back below to cancel. Raised to 16px only on a card that actually gets padding. Declared here on every .card because custom properties INHERIT: without the reset a card nested inside a padded one would inherit 16px and pull its list out on a padding it does not have. / --card-pad: 0px; } .card-head { display: flex; align-items: center; gap: 10px; padding: 13px 16px; border-bottom: 1px solid var(--border); } .card-head h2 { margin: 0; } .card-head .spacer { flex: 1; } .card-body { padding: 16px; } .stack { display: flex; flex-direction: column; gap: 16px; } / A .stack OWNS the rhythm between its children, so a child that also carries a block margin adds to it — flex does not collapse margins, so the two stack up. Measured on a real form: a .field (14px bottom margin) followed by a hint
(12px top margin, UA default) inside a 16px stack rendered 42px apart, three times the 14px the same form used between its own fields. Scoped to DIRECT children on purpose: .field keeps its margin everywhere else, which is what spaces fields inside a plain .card-body. / .stack > .field { margin-bottom: 0; } .stack > p { margin-block: 0; } .grid { display: grid; gap: 12px; grid-template-columns: repeat(auto-fit, minmax(210px, 1fr)); } / SELF-HEALING LAYOUT. A .card is a SURFACE: its padding lives on .card-head / .card-body, and the space between two cards comes from .stack. Both are opt-in, so markup that skips them renders content flush to the border with no gap between cards — valid CSS, no error anywhere, wrong layout. These two rules repair that case without touching markup that composed correctly. The padding rule is written as :not(:has(...)) deliberately. Stated the other way round — pad every card, then zero the ones that carry a body — a browser without :has() drops the RESET and doubles the inset on correct markup. This way an unsupported :has() invalidates the whole selector, the rule is dropped and the card falls back to exactly the behaviour it has today. The fallback is the bug, not a worse bug. A card holding a table is excluded too: a table runs edge to edge on purpose so its header fill and row rules can span the full card width. A .list is NOT excluded — see the pull-back rule below for why. / / ORDER DEPENDENCY — THIS RULE MUST STAY ABOVE .steps .card. Both compute to (0,2,0): .card is one class, and :not() takes the specificity of its most specific argument, which is the :has(), which in turn takes its own most specific argument — a class either way. .steps .card is two classes. Equal specificity means SOURCE ORDER decides it, so the landing genre keeps its 18px only by being declared later in this file. Move either rule past the other and .steps silently drops to 16px, with nothing failing. designSystem.test.ts resolves this exact pair and asserts the winner is 18px, so a reorder breaks the suite instead of the layout. / .card:not(:has(> .card-head, > .card-body, > .empty, > table, > .tablewrap)) { padding: 16px; --card-pad: 16px; } / A .list sits INSIDE that padding and is pulled back out to the card's edges, rather than being excluded from it. Excluding it was the obvious move and it was wrong: whether a card holds a .list depends on the DATA, not on the markup. The reference shape renders a
when the collection is empty and a .list once it has rows, so the card was padded while empty and unpadded the moment the first row landed — the heading jumped to the border on the first insert. Padding that changes with the contents of the database is harder to diagnose than padding that is simply always wrong. Pulled per EDGE, never as a blanket margin:-16px. An all-sides negative margin drags the list UP over whatever heading sits above it, since h1/h2 only carry a 4px bottom margin. Horizontal always; top only when the list opens the card; bottom only when it closes it. A card that is nothing but a list therefore nets back to zero and renders exactly as it did before. The row keeps its own 10px 16px inset (see .list > li), so the row TEXT now lands on the same left edge as the heading while the divider still spans the full card width — the two were 16px apart before. .card-body > .list is a different shape and is deliberately untouched here. The pull is bound to --card-pad, not written as a literal, because it must cancel a padding that is CONDITIONAL. Written as a flat -16px it also fired on cards excluded from the padding rule — an "At a glance" card with a .card-head has no padding to cancel, so its list was dragged 16px clean outside the card on both sides and the row text landed 16px LEFT of the card-head's own heading. Nothing errored; it read as a card whose rows were mysteriously wider than its header. / .card > .list { margin-inline: calc(-1 var(--card-pad)); } .card > .list:first-child { margin-top: calc(-1 * var(--card-pad)); } .card > .list:last-child { margin-bottom: calc(-1 * var(--card-pad)); } /* A SUBMIT that follows a full-width control, with nothing between them. `.field` gives a field its bottom margin and `.actions` gives a button row its gap, but both are opt-in — so the plainest form anyone writes, ``, put the button flush against the input's bottom edge with no gap at all (customer screenshot, 2026-08-13). Neither element carries a margin of its own and nothing was there to supply one. Same shape and the same exclusion list as the sibling-card rule below: a margin on a flex or grid child ADDS to its container's gap, so this must not fire where the parent already spaces its children. The `.field` case is covered by that list too — a button inside one is the rare shape, and a button after one is a sibling of the .field, not of the input. / :not(.stack, .grid, .hero, .steps, .row, .actions) > input + button, :not(.stack, .grid, .hero, .steps, .row, .actions) > input + .btn, :not(.stack, .grid, .hero, .steps, .row, .actions) > select + button, :not(.stack, .grid, .hero, .steps, .row, .actions) > select + .btn, :not(.stack, .grid, .hero, .steps, .row, .actions) > textarea + button, :not(.stack, .grid, .hero, .steps, .row, .actions) > textarea + .btn { margin-top: 10px; } / Excluded wherever the parent ALREADY provides the gap: a margin on a flex or grid child ADDS to that container's gap, so an unscoped rule would open .stack to 32px instead of 16px. / :not(.stack, .grid, .hero, .steps, .row, .actions) > .card + .card { margin-top: 16px; } / …and the same for every OTHER pair of page-level blocks (2026-08-13). `.card + .card` alone covered the reference example — two bare cards under `
`, which has padding and no gap — and nothing else. A dashboard is `.grid + .grid + .grid + .card`: a row of KPI cards, a row of two, another row of two, then a full-width card. Not one of those pairs is card-to-card, so a whole page of blocks stacked flush against each other while the cards INSIDE each grid were correctly spaced by its gap. That is what the customer screenshot showed, and it reads as a design with no rhythm rather than as a rule that did not match. Kept as a SECOND rule rather than folded into the first: `:is()` is the only sane way to write sixteen pairs, and a selector list is invalidated whole by an unknown part. An engine without `:is()` drops this rule and still gets `.card + .card` above — the fallback is today's bug, never a worse one, the same reasoning the `:has()` rule below is written for. / :not(.stack, .grid, .hero, .steps, .row, .actions) > :is(.card, .grid, .alert, .tablewrap) + :is(.card, .grid, .alert, .tablewrap) { margin-top: 16px; } / Stat tile — label, mono figure, delta chip. / .stat { background: var(--card); border: 1px solid var(--border); border-radius: var(--radius-lg); box-shadow: var(--shadow); padding: 14px 16px; } .stat .label { color: var(--muted); font-size: 12px; margin-bottom: 6px; } .stat .figure { font-family: var(--font-mono); font-variant-numeric: tabular-nums; font-size: 24px; font-weight: 600; letter-spacing: var(--tracking-tight); display: flex; align-items: baseline; gap: 8px; } / ================================================================== * * BUTTONS — primary is solid ink, never a coloured gradient * ================================================================== / button, .btn { display: inline-flex; align-items: center; gap: 7px; padding: 7px 13px; border: 1px solid transparent; border-radius: var(--radius-sm); background: var(--ink); color: var(--card); font-family: inherit; font-size: 13px; font-weight: 500; line-height: 1.3; cursor: pointer; text-decoration: none; white-space: nowrap; } button, .btn { transition: background var(--dur) var(--ease), border-color var(--dur) var(--ease), box-shadow var(--dur) var(--ease), transform var(--dur) var(--ease); } / Fading a button to 90% opacity fades it into the PAGE — the label goes grey with it. Mixing the surface toward ink keeps the text at full strength. / button:hover, / text-decoration is RE-STATED here, not only excluded above: the exclusion says "a button is not a prose link", this says "a button knows what it looks like", so the next broad `a:hover` rule somebody adds cannot put a line through a label again. No variant sets text-decoration, so nothing can conflict with it. `color` is deliberately NOT re-stated. `.btn:hover` is (0,2,0) and so are `.btn.ghost` / `.accent` / `.danger` / `.success`, each of which sets its own colour and relies on it surviving the hover — a colour here would tie with them and be decided by source order alone, which is a trap waiting for the day somebody moves a block. The colour problem is already solved one rule up, by the hover no longer matching a button at all. / .btn:hover { background: color-mix(in srgb, var(--ink) 88%, #fff); text-decoration: none; } button:active, .btn:active { transform: translateY(0.5px); } button:focus-visible, .btn:focus-visible, a:focus-visible { outline: none; box-shadow: var(--ring); } button.ghost, .btn.ghost { background: var(--card); color: var(--ink); border-color: var(--border); } button.ghost:hover, .btn.ghost:hover { background: var(--tint); border-color: var(--border-strong); } button.accent, .btn.accent { background: var(--accent); color: var(--accent-ink); } button.accent:hover, .btn.accent:hover { background: color-mix(in srgb, var(--accent) 88%, #000); } / A COLOUR class names the role; .solid fills it. .danger alone is the QUIET destructive — a Delete in a table row, where a filled red on every line shouts. .danger.solid is the loud one: the confirm button in a dialog, where the action is the point of the screen. The same pair exists for success, so "did it" and "will destroy it" read alike. .danger had no hover at all until now, while .ghost and .accent both did. / button.danger, .btn.danger { background: var(--card); color: var(--danger); border-color: var(--border); } button.danger:hover, .btn.danger:hover { background: var(--danger-soft); border-color: color-mix(in srgb, var(--danger) 30%, transparent); } button.success, .btn.success { background: var(--card); color: var(--success); border-color: var(--border); } button.success:hover, .btn.success:hover { background: var(--success-soft); border-color: color-mix(in srgb, var(--success) 30%, transparent); } button.danger.solid, .btn.danger.solid { background: var(--danger); color: #fff; border-color: transparent; } button.danger.solid:hover, .btn.danger.solid:hover { background: color-mix(in srgb, var(--danger) 88%, #000); } button.success.solid, .btn.success.solid { background: var(--success); color: #fff; border-color: transparent; } button.success.solid:hover, .btn.success.solid:hover { background: color-mix(in srgb, var(--success) 88%, #000); } button.sm, .btn.sm { padding: 4px 9px; font-size: 12px; } / A FILLED button cannot be disabled with opacity: the label fades with the fill, so white-on-blue becomes pale-on-pale and the one state a button spends its time in — "you cannot press this yet" — is the least readable thing on screen. A filled control STATES its disabled colours; only an outlined one can be dimmed, and even then not below 0.6. / button:disabled, .btn:disabled { cursor: default; opacity: 0.6; } button:disabled, .btn:disabled, button.accent:disabled, .btn.accent:disabled, button.danger.solid:disabled, .btn.danger.solid:disabled, button.success.solid:disabled, .btn.success.solid:disabled { opacity: 1; background: var(--border); color: var(--muted); border-color: transparent; } button.ghost:disabled, .btn.ghost:disabled, button.danger:disabled, .btn.danger:disabled, button.success:disabled, .btn.success:disabled { opacity: 0.6; background: var(--card); border-color: var(--border); } / An is a BUTTON, and it was matching the text-field rule instead: measured 35px tall with an 8px radius and a white fill, next to a 32.9px, 6px-radius, ink-filled