@humanforest/slidev-theme 0.1.0

package/styles/base.css

@@ -0,0 +1,2611 @@
+/* ───────────────────────────────────────────────────────────────────────────
+   Forest deck base — element styling for slide content.
+
+   Every value here resolves from styles/tokens.css. If a rule below wants a colour, a corner,
+   a duration or a size and there is no token for it, the token is the thing to add — not a
+   literal. That is the whole guardrail.
+
+   The type roles are the engine's, in the deck CONTEXT (--type-deck-*, generated by
+   scripts/type.ts). The mapping onto HTML is fixed here so an author writing plain markdown
+   lands on a role without knowing the role exists. Family/weight for every tier below come from
+   --type-deck-<role>-family/-weight, never a literal — that includes h1: it defaults to the
+   WORKING voice (GT Haptik Bold, sentence case — --type-deck-headline-family/-weight, text-
+   transform: none) so an ordinary content slide never has to ask for it. The four punctuation
+   layouts — divider, cover, statement, end — override their own :deep(h1) back to the BEAT voice
+   (Mohr Black uppercase — --type-deck-display-family/-weight), because that shout is a per-LAYOUT
+   choice, not a per-context one: see each layout's own <style> block. h2 is not layout-dependent —
+   it always speaks the GT Haptik shout, one tier down.
+
+     h1  display OR headline  Mohr Black uppercase on the four beat layouts (divider/cover/
+                               statement/end); GT Haptik bold sentence case everywhere else — the
+                               slide's one shout, voice chosen by the layout
+     h2  headline   GT Haptik bold, uppercase — a second shout, one tier down, always
+     h3  title      GT Haptik bold, sentence case — the calm title under a shout
+     h4  heading-sm GT Haptik bold — a sub-head inside content
+     h5  label      GT Haptik bold — the smallest labelled tier
+     h6  overline   GT Haptik bold, uppercase, tracked — eyebrows and kickers
+   ─────────────────────────────────────────────────────────────────────────── */
+
+/* ── The slide ────────────────────────────────────────────────────────────────────────────── */
+
+.slidev-layout {
+  font-family: var(--type-deck-body-family);
+  font-size: var(--type-deck-body-size); /* deck context: 2xl on the 1920×1080 canvas */
+  line-height: var(--type-deck-body-line-height);
+  color: var(--deck-fg);
+  background: var(--deck-bg);
+  /* ── The text inset — one value, all four edges ──────────────────────────────────────────
+     task-14-brief.md, superseding the asymmetric-then-symmetric-80/60 history this comment used
+     to record (see below for that history — it is worth keeping, because the defect it describes
+     is exactly what requirement 6's debug overlay exists to catch by eye instead of by memory).
+
+     THE PRINCIPLE: text is inset for its MEASURE, media for its FRAME. A paragraph's own ragged
+     right edge already supplies visual air a photograph's hard edge does not, so text and media
+     do not want the same margin — --deck-inset-text (90px = grid × 2.25) is text's; media reads
+     --deck-inset-media (36px) horizontally instead, in whichever layout places a figure against
+     an edge (split.vue, bleed.vue). Chrome (the mark, the page number, the section/confidentiality
+     pills) is a THIRD value, --deck-inset-chrome (36px) uniform on all four sides — furniture, not
+     content. All three derive from --deck-grid; see scripts/deck.ts's own comment above INSET for
+     the full reasoning, including why chrome and media share a number but not a meaning, and why
+     36 is deliberately off the space ladder (task-14b-brief.md revised these from the 40/40/100
+     first pass — the two-track PRINCIPLE didn't move, only the numbers).
+
+     slide-top.vue's/slide-bottom.vue's running chrome sits OUTSIDE this element (a sibling in
+     SlideWrapper.vue, not a descendant), so nothing here can see it or size around it dynamically
+     — but every layout that leaves this padding alone (all of them except bleed and split, which
+     each own their own vertical scheme for their own reasons) needs to leave room for it
+     regardless, because chrome is a per-SLIDE opt-out (`chrome: false`), not a per-LAYOUT one: any
+     layout can carry it.
+
+     ⚠ RE-MEASURED, AND THE ARITHMETIC THIS COMMENT USED TO CARRY IS STALE. It read: "the chrome
+     pill band … occupying canvas y 36–85 at the top … --deck-inset-text (90px) clears that band by
+     5px at BOTH edges." That was true when the top band was a 49px pill row. It is not true now:
+     `0fd9b12` grew the running mark to 72px and nothing re-derived this. Measured live on every
+     chromed slide in all three decks:
+
+         .deck-chrome-mark   72 x 72,  canvas y  36 → 108
+         .deck-chrome-pills  49 tall, centred on the mark, y 47.5 → 96.5
+         .deck-chrome-bottom 49 tall, y 995 → 1044
+
+     So 90px clears the BOTTOM band by 5px as claimed, and clears NEITHER top box: it under-clears
+     the pills by 6.5px and the mark by 18px. In practice no painted ink reaches the mark's own
+     square today, and the pill row overlaps only on the handful of slides whose layout starts a
+     heading at 90px rather than at `default`'s 130px — but the number below is no longer derived
+     from the band it is supposed to clear, and it should be treated as an OPEN geometry finding
+     rather than as a proof. It is left at 90 here deliberately: raising it moves every text box in
+     every deck, which is a re-typesetting decision, not a defect fix.
+
+     ★ THE DEFECT THIS REPLACED, kept in prose because the LESSON outlives the numbers. This rule
+     used to be padding-TOP only, on the reasoning that "the confidentiality pill sits inside the
+     existing bottom margin already, not competing with it". That reasoning counted the pill's
+     OFFSET from the edge and forgot its HEIGHT — the pill is the same ~49px BadgeStrip band as the
+     top one, so it needed offset + height of room, not just offset, and the bottom margin was
+     short by 13px. scripts/deckAudit.ts could not catch it: the audit measures OVERFLOW past the
+     canvas, and an element sitting inside the content box, merely too close to another element,
+     overflows nothing. Collision is a different property from overflow, and nothing measured it —
+     which is why requirement 6's red-line overlay exists: it draws the chrome bands themselves, so
+     a collision like this one is visible by eye on the slide that has it, not provable only by
+     redoing this arithmetic by hand. */
+  padding: var(--deck-inset-text);
+  /*
+    ★★ NOTHING LEAVES THE CANVAS BECAUSE IT COULD NOT FIND A BREAK.
+
+    Nothing in this theme set `overflow-wrap`, `word-break` or `hyphens` on anything — grepped, zero
+    hits — so an unbreakable run had no legal break point and simply painted out of its block. That
+    is not a hypothetical: deck-layouts slide 67's h1 paints from x=120 to x=6856.73, i.e. 4,937px
+    off the right of a 1920px canvas, with 63 of its 105 characters never reaching the screen and
+    the last visible one sliced through the middle.
+
+    It also renders as a CLEAN PASS in every geometry gate, and permanently will, because the gates
+    read `getBoundingClientRect()` on the ELEMENT: an overflowing inline run leaves the block's
+    border box at the column width, so the audit measures 120 → 1464 and reports "0 past the 90px
+    safe area" while the room sees the word run off the wall. A rule that cannot escape is worth
+    more here than a check that cannot see the escape.
+
+    `overflow-wrap` is INHERITED, so declaring it once on the layout root covers every heading,
+    paragraph, caption, table cell and chip on the slide — one rule rather than a list of selectors
+    that a new component can be added without joining.
+
+    `break-word`, not `anywhere`: both break a too-long word, but `anywhere` also feeds the break
+    opportunity into intrinsic (min-content) sizing, which would let every `auto`-sized grid track
+    and shrink-to-fit box in the theme collapse to one character. `break-word` changes only what
+    happens when a word genuinely does not fit.
+
+    It does not fight `white-space: nowrap` — a nowrap box (BadgeStrip's pills, .bars-label,
+    .bars-value) has no wrapping to do, so those keep their cap-and-ellipsis behaviour untouched.
+  */
+  overflow-wrap: break-word;
+}
+
+/* ── Headings ─────────────────────────────────────────────────────────────────────────────── */
+
+/* h1 defaults to the WORKING voice — GT Haptik Bold, sentence case — so default/split/bleed (an
+   ordinary content slide) get the calm register with no CSS of their own. Size/line-height stay
+   on the display step deliberately (this task changes voice, not size): only family/weight/
+   transform move. The four beat layouts override this block's family/weight/transform back to
+   Mohr uppercase in their own <style> — see divider.vue/cover.vue/statement.vue/end.vue. */
+.slidev-layout h1 {
+  font-family: var(--type-deck-headline-family);
+  font-weight: var(--type-deck-headline-weight);
+  font-size: var(--type-deck-display-size);
+  line-height: var(--type-deck-display-line-height);
+  letter-spacing: var(--type-deck-display-tracking);
+  text-transform: none;
+  color: var(--deck-fg);
+  text-wrap: balance;
+  /* The token, not a bare space step: the air above a title and the air below it are one decision,
+     and apps/deck budgets every paginated page from where content starts — so the number
+     has to be readable from deck.json rather than restated in two places. h2 keeps --deck-space-2:
+     it sits inside the content rather than starting it. */
+  margin: 0 0 var(--deck-heading-bottom-space) 0;
+}
+
+/* h2 is not a per-layout choice — always the GT Haptik shout, one tier down. Its own weight/
+   tracking, not h1's: the two used to share one rule keyed to --type-deck-display-weight, which
+   was silently correct only because both tiers clamped to the same 700 under Task 11's blanket
+   override. Now that h1 can diverge (Mohr 900 on the beat layouts), sharing that rule would hand
+   h2 a weight its own family never declares. */
+.slidev-layout h2 {
+  font-family: var(--type-deck-headline-family);
+  font-weight: var(--type-deck-headline-weight);
+  font-size: var(--type-deck-headline-size);
+  line-height: var(--type-deck-headline-line-height);
+  letter-spacing: var(--type-deck-headline-tracking);
+  text-transform: uppercase;
+  color: var(--deck-fg);
+  text-wrap: balance;
+  margin: 0 0 var(--deck-space-2) 0;
+}
+
+.slidev-layout h3 {
+  font-family: var(--type-deck-title-family);
+  font-weight: var(--type-deck-title-weight);
+  font-size: var(--type-deck-title-size);
+  line-height: var(--type-deck-title-line-height);
+  letter-spacing: var(--type-deck-title-tracking);
+  color: var(--deck-fg);
+  text-wrap: balance;
+  margin: 0 0 var(--deck-space-2) 0;
+}
+
+.slidev-layout h4 {
+  font-family: var(--type-deck-heading-sm-family);
+  font-weight: var(--type-deck-heading-sm-weight);
+  font-size: var(--type-deck-heading-sm-size);
+  line-height: var(--type-deck-heading-sm-line-height);
+  color: var(--deck-fg);
+  margin: 0 0 var(--deck-space-1) 0;
+}
+
+.slidev-layout h5 {
+  font-family: var(--type-deck-label-family);
+  font-weight: var(--type-deck-label-weight);
+  font-size: var(--type-deck-label-size);
+  line-height: var(--type-deck-label-line-height);
+  letter-spacing: var(--type-deck-label-tracking);
+  color: var(--deck-fg);
+  margin: 0 0 var(--deck-space-1) 0;
+}
+
+/* The eyebrow's own vertical block — its line box plus the gap it holds to whatever follows it.
+   Published as a custom property, not left implicit in the two declarations below, because
+   split.vue has to hang an eyebrow ABOVE its anchor by exactly this much (see `.split-content >
+   .deck-eyebrow` there). A layout that needs to know how tall an eyebrow is must not restate 41px;
+   it reads the same arithmetic this rule is built from. */
+/*
+  ★★ THE OTHER HALF OF `<Grid fill>`, AND IT HAS TO LIVE OUT HERE.
+
+  A filling grid means "take the space that is left", which only has a meaning inside a container
+  that lays its children out along an axis. Grid.vue cannot say that: a child cannot make its own
+  parent a flex container, and its <style scoped> could not reach the layout root even if it could.
+
+  Keyed on `:has()` so it fires for the layouts that actually hold one and for nothing else — every
+  other slide in the deck keeps the block flow it has always had, which matters because turning a
+  block container into a flex one stops adjacent margins collapsing and would re-space every
+  paragraph on it. Direct child only (`>`): a grid nested inside some other box is that box's
+  problem to size, and silently re-flexing an ancestor two levels up would be a surprise.
+
+  The pair was measured both ways. With `height: 100%` on the grid and no rule here, a grid under an
+  h1 ran to y 1112 against a 984 safe line. With this rule and `flex: 1 1 0%`, the same slide gives
+  the heading 136 → 232 and the grid 264 → 984 exactly, and a grid with no heading still fills
+  136 → 984 as before.
+*/
+.slidev-layout:has(> .deck-grid.is-fill) {
+  display: flex;
+  flex-direction: column;
+}
+
+/*
+  ★ A BARE FILLING CHART CLAIMS THE BODY THE SAME WAY A FILLING GRID DOES. `.deck-chart.is-fill`
+  asks for `height: 100%`, and a percentage resolves against a DEFINITE ancestor — under a heading
+  in normal flow there is none, so without the pair below the chart takes 100% of the LAYOUT and
+  overruns by exactly the heading's height. Measured: every XY chart slide ran to 1161 against a 984
+  safe line, an svg of 770 where 593 fits.
+
+  Its own rule rather than a comma on the grid's, because a static test pins that selector by exact
+  shape and a comma breaks it. Direct child only, for the reason the grid rule gives: a chart nested
+  inside some other box is that box's problem to size.
+*/
+.slidev-layout:has(> .deck-chart.is-fill),
+.slidev-layout:has(> .deck-map.is-fill) {
+  display: flex;
+  flex-direction: column;
+}
+.slidev-layout > .deck-chart.is-fill,
+.slidev-layout > .deck-map.is-fill {
+  flex: 1 1 0%;
+  min-height: 0;
+}
+
+/*
+  ★ TWO GRIDS STACKED NEED THE AIR TWO CELLS SIDE BY SIDE GET. The dashboard shape is two grids as
+  siblings — a content-height row of KPIs, then a filling row for the chart — and they came out
+  TOUCHING: every gap inside each grid was 32, and the seam between them was 0, which reads as one
+  malformed grid rather than two.
+
+  Not `row-gap` on the flex column, which was the first thing tried: a flex gap ADDS to margins
+  rather than collapsing with them, and the h1 above already carries `margin-bottom: 32`, so the
+  heading would have been pushed to 64 while the seam went to 32. The adjacent-sibling selector
+  puts the space only where it is missing and leaves every other relationship alone.
+
+  `--deck-space-4` because that is what `gap: 'base'` resolves to — the seam between two grids is
+  the same beat as the gap inside one, which is the whole reason it looked wrong at 0.
+*/
+.deck-grid + .deck-grid {
+  margin-top: var(--deck-space-4);
+}
+
+/*
+  ★★ A REGION HOLDING AN `::area-box` LAYS OUT AS A COLUMN, SO THE BOX CAN TAKE WHAT IS LEFT.
+
+  AreaBox fills its slot with `flex: 1 1 0%` and `align-self: stretch`, which covers a grid cell and
+  a flex column. It does not cover a BLOCK region that has something above the box: flex is inert
+  there, and the `height: 100%` this replaces resolved against the region's whole box rather than the
+  remainder, so the box started below its sibling and still claimed the full height.
+
+  Measured on the cover's area specimen: `.cover-content` 442-638 with `.cover-rule` plus margin
+  taking the first 40, and the box drawn 482-678 — forty pixels out of the bottom of the region it is
+  supposed to BE. The schematic ruler drew the region correctly and looked wrong for it.
+
+  Scoped with `:has(> .area-box)` so it touches only the specimen slides that draw regions as areas.
+  A real cover, quote or bleed keeps the block flow it has always had.
+*/
+.slidev-layout :is(.cover-content, .split-content, .stack-strip, .bleed-content, .quote-content):has(> .area-box),
+/*
+  ★ AND THE LAYOUT ROOT ITSELF, WHICH THE FIRST CUT OF THIS RULE MISSED.
+
+  `default` has no content region — its area box is a direct child of `.slidev-layout.default`,
+  which is `display: block`. So the list above (all of them content REGIONS) never reached it, flex
+  stayed inert, and with `height: 100%` gone the box fell to its own content height: measured 136-291,
+  155px inside an 888px frame, where every other area slide fills its region.
+
+  The beat layouts (divider, statement, end, quote) are already flex columns and match this harmlessly
+  — their boxes measured correct before and after. Only `default` needed it.
+*/
+.slidev-layout:has(> .area-box) {
+  display: flex;
+  flex-direction: column;
+}
+
+/*
+  ★★ A BROWSER WINDOW IS TOLD HOW MUCH ROOM IT HAS, AND THAT CANNOT COME FROM THE COMPONENT.
+
+  BrowserFrame derives its screen's height from its WIDTH and its ratio, so a window with no `width`
+  on the 1728px content band is 1080 of screen plus a bar — the whole canvas and then some. It was
+  fixed caller-side, by passing a width computed against the room, which every future caller would
+  have had to repeat: deck-template slide 25 did not, and hung 367px off the bottom of the canvas
+  until scripts/deckAudit.ts's canvas pass could see it again.
+
+  The component now caps its own width against the room's HEIGHT — `100cqh` of `.deck-browser-room`,
+  minus what the bar and the border take, times the screen's ratio. Which needs the room to HAVE a
+  height, and a height is only definite where something outside supplies one. Hence this rule and
+  the three hosts below, and hence `container-type: size` living here rather than in the component:
+  a size container with no external height is size-contained down to ZERO, and the cap would then
+  make the window vanish. So it is switched on exactly where the height is known and left off
+  everywhere else, where the cap falls back to `none` and the window is width-driven as before.
+
+  Same shape and same reasoning as `<Grid fill>` and `.area-box` above — a child that means "take
+  what is left" needs its parent laid out along an axis, and a child cannot flex its own parent. And
+  same cost, stated there: the room GROWS, so a slide that puts something after the window will find
+  it pushed to the bottom of the frame. That is the established behaviour of a filling child in this
+  theme rather than a new surprise, and `>` keeps it to windows the layout holds directly — the
+  specimen's window inside a grid cell, with its caption underneath, is untouched.
+*/
+.slidev-layout:has(> .deck-browser-room) {
+  display: flex;
+  flex-direction: column;
+}
+/*
+  The three regions whose height is definite: a flex column's filling child (the layout root above,
+  split's figure cell, stack's panel band) takes it from `flex`, a block region sized by its grid row
+  (stack's other bands) from `height`. Both are declared because which one applies depends on the
+  host, and the one that does not apply is inert.
+*/
+.slidev-layout > .deck-browser-room,
+.split-figure.is-figure > .deck-browser-room,
+.stack-band > .deck-browser-room {
+  flex: 1 1 0%;
+  min-height: 0;
+  height: 100%;
+  container-type: size;
+}
+/*
+  ★★ THE CAP IS SET ON THE CHILD, NOT ON THE ROOM, AND THAT IS A HARD REQUIREMENT RATHER THAN A
+  STYLE CHOICE. Declared on `.deck-browser-room` — as `--deck-browser-cap`, for the fit box to read
+  — the whole declaration came back EMPTY from getComputedStyle while every other declaration in the
+  same rule applied: a box asking its own size question is a cycle, and a cycle makes the value
+  invalid at computed-value time rather than an error anyone sees. Measured that way: the window
+  still rendered 1728x1142 in a room the room itself correctly reported as 679 tall.
+
+  One level down the same query is ordinary, so this is a plain `max-width` on the box it caps.
+*/
+.slidev-layout > .deck-browser-room > .deck-browser-fit,
+.split-figure.is-figure > .deck-browser-room > .deck-browser-fit,
+.stack-band > .deck-browser-room > .deck-browser-fit {
+  max-width: calc((100cqh - var(--deck-browser-frame-h)) * var(--deck-browser-screen-ratio));
+}
+
+/*
+  ★★ THE HEADING RISES WHEN THE SECTION PILL IS NOT THERE — AND NARROWS, BECAUSE THE MARK STILL IS.
+
+  `default` holds its heading at --deck-inset-text + --deck-heading-top-space (96 + 40 = 136). With
+  a section pill in the top-left that reads correctly: the pill occupies y36-85 and the heading sits
+  51 below it. With no pill the same 136 reads as the title floating, because the left half of the
+  chrome row is empty.
+
+  ★ WHAT THE 40 IS ACTUALLY FOR, which is the part that makes this more than a padding tweak. It is
+  not clearing the PILL. It is clearing the MARK, which is present either way:
+
+      mark          y 36-108,  x 1812-1884
+      heading band  x 96-1824          → the two columns OVERLAP by 12px
+      at y136       clears the mark's bottom by 28
+
+  So dropping the space unconditionally would put a full-width heading under the running mark, on
+  every slide with no pill, and nothing would catch it — scripts/deckAudit.ts scores occlusion for
+  split/stack media surfaces only. The heading may only rise if it also stops short of the mark's
+  column, which is what the second rule does.
+
+  The reduction is derived, never written down:
+
+      max width = mark_left − gap − text_inset
+                = (canvas − chrome_inset − mark) − chrome_inset − text_inset
+      reduction = content_width − max_width
+                = mark + 2·chrome_inset − text_inset      = 72 + 72 − 96 = 48px
+
+  48 of 1728, and the gap left beside the mark is one --deck-inset-chrome, the same clearance the
+  mark keeps from the canvas edge.
+
+  ⚠ KEYED ON AN EMPTY PILL, NOT ON A MISSING ONE. slide-top.vue renders `.deck-chrome-pills`
+  unconditionally and puts the BadgeStrip inside it behind a `v-if`, so a slide with no section has
+  an element containing a single `<!--v-if-->` comment. `:empty` matches that (comments do not
+  defeat it, text nodes would) — verified in the browser rather than assumed, because the whole rule
+  is dead if it does not.
+
+  The second selector is the `chrome: false` case: no chrome row at all, so no mark to clear, so the
+  heading rises with NO cap. Written separately rather than folded in, because they want different
+  answers to the width question.
+*/
+.slidev-page:has(.deck-chrome-pills:empty) .slidev-layout.default:not(.is-center),
+.slidev-page:not(:has(.deck-chrome-top)) .slidev-layout.default:not(.is-center) {
+  padding-top: var(--deck-inset-text);
+}
+/*
+  ★★ `align: start` ON A SPLIT MUST CLEAR THE CHROME TOO — THE SAME PROBLEM, ONE LAYOUT OVER.
+
+  split's `align: start` collapses the anchor row so the content column starts at the grid box's own
+  top, which is the root's text inset: y 96. That is the right answer on a bare slide and the wrong
+  one under running chrome. Measured on the specimen's `align: start` rung, which carries a section
+  pill: heading at y 96, pill at y 36-85, an ELEVEN pixel gap, and the two overlap horizontally
+  (pill x 36-222, heading x 96-864). It reads as a title jammed under a label.
+
+  `default` already solves this with --deck-heading-top-space and clears its occupant by 28. This is
+  the same rule, and it is keyed on WHICH piece of chrome is actually above the column, because that
+  depends on which side the content is on:
+
+    · content on the RIGHT sits under the MARK, which is drawn whenever chrome is;
+    · content on the LEFT sits under the SECTION PILL, which is only there when a section is named —
+      so a pill-less slide keeps the tighter start rather than paying for clearance it does not need.
+
+  Same `:empty` trick as the default rule above, for the same reason: slide-top.vue always renders
+  the pills container and puts the badge inside behind a v-if.
+*/
+/*
+  ★★ AND AN EYEBROW NEEDS THE RESERVE TO GROW, because it hangs ABOVE the thing the reserve protects.
+
+  The clearance below puts the HEADING at 136, clear of the pill. `.split-content`'s eyebrow rule
+  then pulls the eyebrow up by its own block so the heading keeps that anchor — which lands the
+  eyebrow at 95, back inside the exact 11px gap this whole rule was written to close. The heading was
+  protected and the thing above it was not.
+
+  So the reserve becomes the heading's PLUS the eyebrow's whenever the column carries one: the
+  eyebrow takes the line the heading would have had, and the heading sits its own block below,
+  anchored as before. Both keep their relationship; the pair just starts lower.
+
+  A variable rather than a second four-selector rule: the clearance below is already four selectors
+  because which chrome sits above the column depends on the side, and doubling that to eight to say
+  one thing about the eyebrow would bury the condition in the permutations.
+*/
+.split-grid:has(.deck-eyebrow) {
+  --split-chrome-reserve: calc(var(--deck-heading-top-space) + var(--deck-eyebrow-block));
+}
+.slidev-page:has(.deck-chrome-top) .slidev-layout.split.is-right.is-align-start .split-grid,
+.slidev-page:has(.deck-chrome-top) .slidev-layout.split.is-right.is-align-body-center .split-grid,
+.slidev-page:has(.deck-chrome-pills:not(:empty)) .slidev-layout.split.is-left.is-align-start .split-grid,
+.slidev-page:has(.deck-chrome-pills:not(:empty)) .slidev-layout.split.is-left.is-align-body-center .split-grid {
+  grid-template-rows: var(--split-chrome-reserve, var(--deck-heading-top-space)) minmax(0, 1fr) auto;
+}
+
+.slidev-page:has(.deck-chrome-pills:empty) .slidev-layout.default:not(.is-center) > h1,
+.slidev-page:has(.deck-chrome-pills:empty) .slidev-layout.default:not(.is-center) > hgroup {
+  max-width: calc(100% - (var(--deck-chrome-mark) + 2 * var(--deck-inset-chrome) - var(--deck-inset-text)));
+}
+
+/*
+  A CENTRED `default` CENTRES ITS CONTENT UNDER ITS EYEBROW, NOT WITH IT.
+
+  default.vue's `align: 'center'` makes the layout a flex column, and the eyebrow is a sibling of the
+  slot — so centring moved the running head along with whatever the slide held. Measured on
+  apps/deck's type-ramp pages: y 263, 203 and 251 on three consecutive pages of one
+  catalogue section. The kicker is a running head; it has to hold still.
+
+  Auto margins take the free space before `justify-content` sees any, so the slot block centres in
+  what is left below the eyebrow while the eyebrow keeps the top of the flow. Nothing is taken out
+  of flow, which matters: all four corners belong to the running chrome, and a layout that pins a box
+  in one has to ask `chromeShows()` first (deckNotch.static.test.ts). This asks nothing, because it
+  never leaves the column.
+
+  ★ HERE RATHER THAN IN default.vue's OWN <style scoped>, because a scoped rule cannot see slot
+  content: Vue stamps the component's own elements with a data attribute and the slide's markdown
+  carries none, so `.deck-eyebrow + *` written there matches nothing at all. The eyebrow's own
+  margin-top stays in default.vue, where the element does belong to the component.
+
+  Guarded on the eyebrow existing — a centred slide without one is still centred by
+  `justify-content` alone, exactly as it was.
+*/
+.slidev-layout.default.is-center > .deck-eyebrow + * {
+  margin-top: auto;
+}
+.slidev-layout.default.is-center:has(> .deck-eyebrow) > :last-child {
+  margin-bottom: auto;
+}
+
+/*
+  AND `body-center` CENTRES UNDER THE HEADING, WHICH IS THE SAME RULE ONE ELEMENT FURTHER IN.
+
+  The case it exists for: a wide mermaid diagram is a few hundred units tall on a 1080 canvas, so
+  `align: start` leaves the bottom half of the slide empty under it, and `align: center` fixes the
+  emptiness by dragging the heading into the middle — which costs the running rhythm every other
+  content slide keeps. Neither is right for a body that is short because it is WIDE.
+
+  So the heading takes the top exactly as it does on a start-anchored slide, and the free space is
+  split above and below whatever follows it. Auto margins again, for the same reason as the eyebrow
+  above: they absorb the free space before `justify-content` sees any, and nothing leaves the flow,
+  so no corner is claimed and `chromeShows()` never has to be asked.
+
+  `hgroup` is named beside `h1` because default.vue's own eyebrow prop and a hand-written kicker
+  produce different markup for the same slide — the eyebrow is a sibling `<p>`, a written one is an
+  `<hgroup>` wrapping the heading. Both are "the heading block", and the body centres under either.
+
+  ★ A SLIDE WITH NO HEADING FALLS BACK TO `start`, by construction rather than by a guard: the
+  sibling selector matches nothing and `:has()` is false, so no auto margin is handed out and the
+  column stays top-anchored. That is the right answer — there is no heading to hold the top, so
+  there is nothing to centre underneath.
+*/
+/*
+  ★★ `.slidev-page` IS A SPECIFICITY COUNTERWEIGHT, NOT A SCOPE — it is here to win one exact tie.
+
+  A chart slide leads with a spec label, and that paragraph is styled by
+  `.slidev-layout p:has(> .deck-spec-label:only-child)`, which sets `margin: 0 0 … 0`. Its
+  specificity is (0,3,1): `:has()` contributes its own argument's, and `.deck-spec-label:only-child`
+  is a class plus a pseudo-class. Written without the ancestor, the rule below is (0,3,1) too — an
+  exact tie, decided by source order, and the spec-label rule is further down this file. So the
+  paragraph kept `margin-top: 0`, the auto never applied, and the free space went entirely below the
+  body: the slide still hugged the top while reporting `is-body-center` correctly.
+
+  MEASURED on the specimen's Status track slide: two autos live instead of three, 103.5px each below
+  the chart and nothing above the label. Setting the same margin inline made all three resolve to 69
+  and the block moved — which is how the tie was found rather than the selector blamed.
+
+  The mermaid slides never showed it: their first body element is a plain wrapper with no rule of
+  its own to tie against.
+*/
+.slidev-page .slidev-layout.default.is-body-center > :is(h1, hgroup) + * {
+  margin-top: auto;
+}
+.slidev-layout.default.is-body-center:has(> :is(h1, hgroup)) > :last-child {
+  margin-bottom: auto;
+}
+/*
+  ★★ AND IT SITS ABOVE THE MIDDLE, BECAUSE THE MIDDLE LOOKS LOW.
+
+  Split evenly, the body is centred in a box the viewer cannot see — and the eye judges centring
+  against the FRAME. Measured on the specimen's Flowchart slide before this rule: the diagram's
+  centre landed 84px below the slide's own centre, because the heading occupies the top and the
+  split never knew. The two gaps a viewer actually perceives were 210 above and 274 below, off by
+  exactly the 64 that separates the heading's own 32px margin (which falls on the top side of the
+  split) from the container's 96px bottom inset (which falls on the bottom, and paints nothing).
+
+  ⚠ THE WEIGHTING CANNOT BE A NUMBER, because the free space is not one — it is whatever the body
+  leaves, and it changes with every diagram. Flexbox divides free space EQUALLY between auto
+  margins, so the ratio comes from HOW MANY there are rather than from a length: two autos give 1:1,
+  and a third below gives 1:2. The body then takes a third of the space above it and two thirds
+  below, i.e. it rides one sixth of the free space above centre.
+
+  That is why the correction is a pseudo-element and not a `calc()`. It also makes the rule
+  self-limiting for free: as a body grows the free space shrinks, the lift shrinks with it, and a
+  body tall enough to fill the slide converges on the plain centre. Nothing to clamp.
+
+  ★ GATED ON THE HEADING like the two rules above it, so a slide with no heading stays top-anchored
+  rather than gaining a lone auto margin with nothing to balance against.
+*/
+.slidev-layout.default.is-body-center:has(> :is(h1, hgroup))::after {
+  content: '';
+  margin-top: auto;
+}
+
+/*
+  ★★ AND A THIRD TIME, ON stack's `frame: content` BAND — THE SAME 96 UNDER THE SAME CHROME.
+
+  Every other stack band is a SURFACE: `panel`, `photo` and `figure` all notch, so the band rises to
+  the 36 chrome inset and the measured cut in useNotchCuts.js takes the chrome out of its corners.
+  `frame: content` is the one that paints no ground, so it never notches, and nothing reserved
+  anything — it simply kept the plain text inset and started at 96.
+
+  Measured on the specimen's only such slide (45), and the numbers are the split rule's numbers
+  again almost exactly:
+
+      section pill   y 36-85,   x 36-222
+      band           y 96,      x 96-1824      → an ELEVEN pixel gap, overlapping horizontally
+      first text run y 94                      → the painted line sits ABOVE its own box top
+
+  ★ AND THE 40 IS CLEARING THE MARK, NOT THE PILL — same as `default`, and it matters here more,
+  because a band is FULL WIDTH:
+
+      mark   y 36-108, x 1812-1884
+      band   x 96-1824             → the two columns overlap by 12px
+      at 136                       → clears the mark's bottom by 28
+
+  ⚠ KEYED ON THE CHROME ROW, NOT ON A NON-EMPTY PILL, and that is the one place this rule departs
+  from `default`'s. `default` lets its heading rise to 96 on a pill-less slide and NARROWS it by 48
+  so it stops short of the mark's column. A band cannot take that trade: its full width IS the
+  layout's statement — it is the thing distinguishing a band from a paragraph — so narrowing it to
+  dodge the mark would change what the frame means. The mark is present whenever the chrome row is,
+  so the clearance is owed whenever the chrome row is, pill or no pill. A `chrome: false` slide has
+  no mark to clear and keeps the tighter 96 from stack.vue's own rule.
+*/
+.slidev-page:has(.deck-chrome-top) .slidev-layout.stack .stack-band.is-content {
+  margin-top: calc(var(--deck-inset-text) + var(--deck-heading-top-space));
+}
+
+/*
+  ★★ A BLEEDING SURFACE HAS NO NOTCH, SO ITS CONTENT MUST CLEAR THE MARK ON ITS OWN.
+
+  Everywhere else the ring of ground around a figure is where the running chrome sits, and the notch
+  cuts it a seat. `bleed` gives up that ring on purpose, so the chrome is drawn ON the surface — which
+  is the documented trade for the SURFACE, and not a licence for the CONTENT to collide with it.
+
+  Measured on the specimen's bleeding panel band before this rule: the content's padding box began at
+  y 32, ABOVE the mark's own top at 36 and 76px above its bottom. The unbled band puts the same
+  content at 132, and the arithmetic behind that number is not the card padding — it is the notch:
+
+      chrome inset  36   where the mark's box starts
+      mark          72   its height
+      notch gap     24   the ring the cut leaves around it
+                   ---
+                   132   which is exactly where a notched panel starts its content
+
+  So the bleeding surface reproduces it from the same three tokens rather than restating 132, and the
+  two move together if any of them is ever retuned.
+
+  ⚠ KEYED ON THE CHROME ROW, like the two rules above it. With `chrome: false` there is no mark to
+  clear and the surface keeps the tighter top the layouts set — a bleeding slide with no chrome would
+  otherwise carry 132px of empty ground for a collision that cannot happen.
+
+  `photo` is excluded on purpose: an edge-to-edge photograph is the point of bleeding one, and its
+  content IS the image. That is the one case where the chrome really does sit on the picture, and the
+  answer there is `chrome: false` or the `bleed` layout's scrim — not padding.
+
+  ★★ AND `spill` IS EXCLUDED, WHICH IS A DEFECT THIS RULE WAS CAUSING RATHER THAN A NEW OPTION.
+  stack.vue's own spill rule already says `padding-top: 0`, with a note recording exactly what this
+  reservation does to a spilling band: "measured, it started the window 132px below the band's own
+  top edge and the slide then cut a window that had never reached the top." That rule was losing.
+  `:has()` contributes its ARGUMENT's specificity, so this selector is (0,8,0) against the scoped
+  rule's (0,5,0) — the same trap this repo has hit before, and no amount of care inside stack.vue
+  fixes it because the two rules are not in the same file.
+
+  Excluded here rather than out-specified there, because the exclusion is the true statement: a
+  spilling band's content is meant to leave the frame, so it is not a surface the chrome can collide
+  with in the way this reservation assumes. Measured on the live-page spill slide — the band's own
+  top is y=300 and the chrome mark's bottom is y=108, so there was nothing to clear in the first
+  place.
+*/
+.slidev-page:has(.deck-chrome-top) .slidev-layout.split .split-figure.is-bleed:not(.is-content):not(.is-photo):not(.is-spill),
+.slidev-page:has(.deck-chrome-top) .slidev-layout.stack .stack-band.is-bleed:not(.is-content):not(.is-photo):not(.is-spill) {
+  padding-top: calc(var(--deck-inset-chrome) + var(--deck-chrome-mark) + var(--deck-notch-gap));
+}
+
+.slidev-layout {
+  --deck-eyebrow-block: calc(
+    var(--type-deck-overline-size) * var(--type-deck-overline-line-height) + var(--deck-space-1)
+  );
+}
+
+/* h6 IS the overline role — the eyebrow tier. */
+.slidev-layout h6,
+.slidev-layout .deck-eyebrow {
+  font-family: var(--type-deck-overline-family);
+  font-weight: var(--type-deck-overline-weight);
+  font-size: var(--type-deck-overline-size);
+  line-height: var(--type-deck-overline-line-height);
+  letter-spacing: var(--type-deck-overline-tracking);
+  text-transform: uppercase;
+  color: var(--deck-accent);
+  margin: 0 0 var(--deck-space-1) 0;
+}
+
+/* ── The editorial hgroup — a heading with its kicker ──────────────────────────────────────
+   Same pattern the docs site runs (apps/docs/src/assets/docs.css): an <hgroup> is a heading
+   plus the line that introduces it, and a bare <p> inside one IS that kicker — so it takes the
+   overline role automatically. An author writes two lines of HTML and gets the system's
+   eyebrow rhythm; nothing has to be classed. */
+.slidev-layout hgroup {
+  display: flex;
+  flex-direction: column;
+  gap: var(--deck-space-1);
+  margin-bottom: var(--deck-space-3);
+}
+.slidev-layout hgroup > * {
+  margin-bottom: 0;
+}
+.slidev-layout hgroup > p {
+  font-family: var(--type-deck-overline-family);
+  font-weight: var(--type-deck-overline-weight);
+  font-size: var(--type-deck-overline-size);
+  line-height: var(--type-deck-overline-line-height);
+  letter-spacing: var(--type-deck-overline-tracking);
+  text-transform: uppercase;
+  color: var(--deck-accent);
+}
+/* A kicker over the big display line wants more air than one over a section title. */
+.slidev-layout hgroup:has(h1) {
+  gap: var(--deck-space-2);
+}
+
+/* ── Measure ──────────────────────────────────────────────────────────────────────────────
+   ★★ RUNNING PROSE IS NOT CAPPED. A paragraph, a list item and a caption run the width of
+   whatever holds them — the slide's own text inset on a full-width layout, the column inside a
+   split or a stack band.
+
+   It was capped: body at 20em (≈39 characters), lists at 22em, captions at 23em. The case
+   against those numbers is not that they were wrong for reading — 39 characters is comfortably
+   inside the conventional 45–75 — it is that a SLIDE is not a page. The 45–75 finding is about
+   sustained reading, many lines and many return sweeps; a slide's paragraph is one to three
+   lines and is scanned. MEASURED on a full-width `default` carrying a heading, a paragraph, a
+   nested list, an ordered list and a blockquote:
+
+     capped at 39 chars   paragraph 3 lines, blockquote 2   content ran to y 1079 — 95px PAST
+                                                            the 984 inset
+     uncapped (70 chars)  paragraph 2 lines, blockquote 1   the same content fits
+
+   That is the real cost, and it is the opposite of the one the cap was defending: capping trades
+   the dimension a slide has (width) for the dimension it runs out of (height). The right-hand
+   third it left empty was not composition either — nothing was placed there, it was leftover.
+
+   ⚠ THE BEAT LAYOUTS KEEP THEIR CAPS, and they are a different instrument: cover's 12.5em title,
+   quote's 17em, statement's 14em are display type being SHAPED — a deliberate two- or three-line
+   block — not running text being made readable. They are unaffected by any of this.
+
+   ★ AND THOSE CAPS ARE STILL IN `em`, NEVER `ch`, which is a brand-font fact rather than a
+   preference. MEASURED on the shipped faces:
+
+     GT Haptik    1ch = 0.778em   average lowercase advance = 0.511em
+     MohrAlt 900  1ch = 0.789em   average uppercase advance = 0.694em
+
+   The `ch` unit is the advance of "0", and in both faces that glyph is far wider than the average
+   letter — so a `max-width` in `ch` permits about 1.5× the characters it appears to promise.
+   `38ch` of GT Haptik is a 58-character line. Any cap added here takes <target characters> ×
+   <measured average advance>, using the uppercase figure for Mohr.
+   ───────────────────────────────────────────────────────────────────────────────────────── */
+
+/* ── Body copy ────────────────────────────────────────────────────────────────────────────── */
+
+.slidev-layout p {
+  margin: 0 0 var(--deck-space-2) 0;
+}
+
+/* The lead paragraph: the sans bridge directly under a Mohr shout. */
+.slidev-layout .deck-lead {
+  font-size: var(--type-deck-subtitle-size);
+  line-height: var(--type-deck-subtitle-line-height);
+  color: var(--deck-fg-muted);
+}
+
+/* Caption / footnote tier — the quiet line under a figure or at the foot of a slide. */
+.slidev-layout figure {
+  margin: 0;
+}
+.slidev-layout figcaption,
+.slidev-layout .deck-caption {
+  font-size: var(--type-deck-caption-size);
+  line-height: var(--type-deck-caption-line-height);
+  color: var(--deck-fg-muted);
+  margin-top: var(--deck-space-2);
+}
+.slidev-layout .deck-note {
+  font-size: var(--type-deck-body-sm-size);
+  color: var(--deck-fg-subtle);
+}
+
+/*
+  ── A LABELLED SPECIMEN: a label, then the thing it names ────────────────────────────────────
+  `.deck-spec` marks a wrapper whose FIRST paragraph is the label for whatever follows it;
+  `.deck-spec-under` puts the label last instead, for swatches and bands where the colour leads.
+
+  The register is the OVERLINE role in muted ink — the same quiet furniture tier the running
+  chrome's own pills use. A label must never compete with what it labels, and on a colour
+  specimen it must not introduce a colour of its own. That is why this is not `.deck-caption`
+  (caption size, sentence case) and not `.deck-eyebrow` (overline, but the ACCENT): the gap
+  between those two is exactly this class, and it had no name until a deck needed one.
+
+  ★ TWO WAYS IN, and which one a deck uses depends on whether there is anything to GROUP.
+
+  `.deck-spec-label` is the label carrying its own class, written `[text]{.deck-spec-label}`. That
+  needs comark, which Slidev 52 ships and a deck opts into with `comark: true` in its headmatter —
+  apps/deck does. On 0.50 it was not available at all: markdown could not attach a class,
+  and the alternative was a 250-character inline `style` on every label, 279 of them in one
+  generated deck, which is what made that file unreadable.
+
+  `.deck-spec` / `.deck-spec-under` keep the class on a WRAPPER, and they are not a legacy fallback:
+  they group a label AND the specimen it names, and the rule below is what positions one against the
+  other. A wrapper is the right shape when there are two things in it. It was the wrong shape when
+  there was one, which is the case the inline class now covers.
+
+  The coupling is a contract either way, which is why the rule names `.deck-spec` and never a bare
+  `div > p`.
+
+  ★★ `.deck-spec-wide` IS THE OPT-IN, AND IT EXISTS BECAUSE A PANEL CENTRES ITS CHILDREN.
+
+  `panelAlign: title-start|title-center` lays the panel out as a column with `align-items: center`,
+  so every direct child SHRINK-WRAPS and is centred on the panel's midline. On the panelAlign ladder
+  that is exactly right — the rungs must shrink-wrap so the ladder moves one variable — but on a
+  register PAIR it is wrong twice over: the specimen in the panel is a different width AND a
+  different alignment from its partner in the content column, so a reader comparing two registers is
+  also comparing two layouts. Measured on the unfilled-badges slide: the column half ran 768px wide
+  from x 96, the panel half 275px centred on 1440.
+
+  A half that needs its full width asks for it, per split.vue's own note, rather than the panel
+  handing it out to everyone.
+*/
+.deck-spec-wide {
+  align-self: stretch;
+}
+/*
+  ★ THE PARAGRAPH AROUND AN INLINE LABEL HAS TO TURN WITH IT. `[text]{.deck-spec-label}` on its own
+  line is a SPAN inside a <p>, and a line box is at least as tall as its parent's strut — so the
+  paragraph's body line-height won, the label's block came out taller than the overline it is set
+  in, and every chart budget derived from CAPTION_BLOCK (49px = a 33px overline line box plus
+  --deck-space-2) was short. MEASURED: charts to bottom 1098 on a 1080 canvas, 18px over, across 20
+  slides. The wrapper forms never had this — there the label IS the paragraph.
+*/
+.slidev-layout p:has(> .deck-spec-label:only-child) {
+  /* ★ FONT-SIZE AS WELL AS LINE-HEIGHT, because the overline's line-height is UNITLESS (1.1) and a
+     unitless value multiplies the element's OWN font-size. Setting only line-height on the wrapping
+     paragraph computed 1.1 against the paragraph's 48px body size — 52.8px, a 69px block against
+     the 49px CAPTION_BLOCK every chart budget is derived from. With both, the paragraph's strut is
+     the label's own line box: 30 x 1.1 = 33, plus --deck-space-2, exactly 49. */
+  font-size: var(--type-deck-overline-size);
+  line-height: var(--type-deck-overline-line-height);
+  margin: 0 0 var(--deck-space-2) 0;
+  max-width: none;
+}
+.slidev-layout .deck-spec > p:first-child,
+.slidev-layout .deck-spec-under > p:last-child,
+.slidev-layout .deck-spec-label {
+  font-family: var(--type-deck-overline-family);
+  font-size: var(--type-deck-overline-size);
+  font-weight: var(--type-deck-overline-weight);
+  line-height: var(--type-deck-overline-line-height);
+  letter-spacing: var(--type-deck-overline-tracking);
+  text-transform: uppercase;
+  color: var(--deck-fg-muted);
+  max-width: none;
+}
+.slidev-layout .deck-spec > p:first-child { margin: 0 0 var(--deck-space-2) 0; }
+/*
+  ★★ AN IDENTIFIER INSIDE A LABEL KEEPS ITS OWN CASE, and on a custom property that is correctness
+  rather than taste. The label register is an uppercase overline, which is right for the prose half
+  of a caption ("light register", "three cards, two clicks") and WRONG for a token: CSS custom
+  property names are case-sensitive, so `--DECK-SHADE-1` is a different property from the one the
+  swatch beside it is actually painting. A specimen book that misspells the thing it specimens is
+  worse than one with no label.
+
+  So a label says which half is which by writing the identifier as inline code, and this turns the
+  overline treatment off for that span only — case, tracking and family all come back. Sized in `em`
+  so it tracks whatever the label is set at rather than needing its own number, and left on the
+  label's own muted ink rather than the code chip's ground: a chip fill inside a 33px line box would
+  make the label a row of boxes.
+
+  ★★ AND IT MUST TURN OFF ALL OF THE CHIP, NOT JUST THE FILL. This zeroed `background` and `padding`
+  and stopped there, which was complete until the chip grew an EDGE and a RADIUS. After that a token
+  name in a label drew as a hollow lozenge: no fill, a 2px currentColor rule hugging the text at
+  `padding: 0`, and 16px of radius on a box the zeroed padding had shrunk to 40 canvas px — 65% of
+  its own height, where the chip rule budgets that same 16px as two fifths of a 65px chip.
+
+  The lesson is the shape rather than the value: a context that neutralises the chip has to
+  neutralise every property the chip rule sets, and the two are 250 lines apart. A gate in
+  packages/slidev-theme/test/ now checks that they agree.
+*/
+.slidev-layout .deck-spec > p:first-child code,
+.slidev-layout .deck-spec-under > p:last-child code,
+.slidev-layout .deck-spec-label code {
+  font-family: var(--font-mono);
+  font-size: 0.92em;
+  font-weight: 400;
+  text-transform: none;
+  letter-spacing: normal;
+  background: none;
+  border: none;
+  border-radius: 0;
+  padding: 0;
+  color: inherit;
+}
+
+/*
+  ★★ A CELL HANDS A FILLING CHART ITS LEFTOVER, NOT ITS WHOLE HEIGHT. `.deck-spec` is a label
+  paragraph followed by the specimen, and a filling frame asks for `height: 100%` — of the box the
+  label is also in. Measured on Legend positions with the grid filling and the rows stretching: the
+  grid's own box ended at the 984 safe line while the second row's FRAMES ran to 1066, 82px past it,
+  because each cell was paying for its label twice. The ink pass saw none of it; the text inside
+  those frames stopped at 747, so only the boxes crossed.
+
+  A flex column fixes it at the cell: the label takes its line, the chart takes the rest. `flex-basis`
+  of 0 is what makes the chart's own `height: 100%` stop mattering — a flex item sizes from its
+  basis, so the two no longer fight.
+
+  Scoped with `:has()` so a cell only becomes a flex column when it actually holds a filling chart.
+  Every other cell in the deck — swatches, bands, code, tables — is untouched.
+*/
+.slidev-layout .deck-spec:has(> .deck-chart.is-fill) {
+  display: flex;
+  flex-direction: column;
+  height: 100%;
+}
+.slidev-layout .deck-spec > .deck-chart.is-fill {
+  flex: 1 1 0%;
+  min-height: 0;
+}
+.slidev-layout .deck-spec-under > p:last-child { margin: var(--deck-space-2) 0 0 0; }
+
+/* Emphasis is the brand green. */
+.slidev-layout strong,
+.slidev-layout b {
+  color: var(--deck-accent);
+  font-weight: 700;
+}
+
+/*
+  ── Emphasis is TWO channels, and naming the second one is the point of this rule ──────────────
+  `strong` spends the ACCENT. `em` spends the OBLIQUE. On a deck where the accent is the loudest
+  thing on the page that distinction is worth having: an author needs a way to emphasise a word
+  without reaching for the one colour the whole slide is built around.
+
+  Colour and weight are INHERITED deliberately. An `em` that also changed colour would just be a
+  second `strong`, and the deck would have two ways to say one thing.
+
+  This rule is close to a no-op today — the browser default already resolves to the right face —
+  and that is exactly why it is written down. Italic worked by accident: nothing in this theme said
+  it was sanctioned, no other deck had ever used it, and the first one that did found the face
+  arriving late (see styles/index.ts). A treatment the system relies on should be a decision.
+
+  `font-synthesis-style: none` makes the face a guarantee rather than a coincidence. The brand
+  licenses and ships real obliques (GTHaptik-RegularOblique / -BoldOblique, declared
+  `font-style: italic`), so nothing should ever be slanting the roman by matrix. If the oblique
+  ever stops shipping, this renders upright — visibly wrong — instead of silently faking a face
+  that is not the brand's.
+*/
+.slidev-layout em,
+.slidev-layout i {
+  font-style: italic;
+  font-synthesis-style: none;
+}
+
+/*
+  `.hl` WAS HERE — a highlighter mark, accent ink on accent-soft, with a negative margin so the tint
+  bled past the text and `box-decoration-break: clone` so a wrapped phrase got rounded ends on each
+  fragment. It worked; nothing ever used it. Zero occurrences in either deck, in the generators, in
+  any component or test, for the deck's whole life, and it carried no note explaining the decision —
+  the signature of a treatment added speculatively rather than because a slide asked for it.
+
+  Two things worth keeping if it ever comes back. `strong` already spends the accent (see the note
+  above `em`), so a highlight is a THIRD emphasis tier and needs a reason to exist beside the two
+  that do. And it must not be accent-on-accent-soft: that is the inline `code` chip's pairing, and
+  two meanings on one visual is a genuine ambiguity at projector distance.
+*/
+
+/* ── Lists — the accent bullet ────────────────────────────────────────────────────────────── */
+
+/*
+  ★ THE GAP BETWEEN ITEMS IS 0.3em, NOT 0.6, BECAUSE THE LINE BOX ALREADY CARRIES HALF OF IT.
+  Body sets `line-height: 1.6`, so a 48px item has a 77px line box — 29px of leading, half above the
+  glyph and half below. A 0.6em margin adds another 29px on top of that, and two consecutive items
+  ended up 58px apart against a 48px cap height: the list read as separate paragraphs rather than as
+  one list. Measured on apps/deck's prose slide, which is where it was reported. 0.3em puts
+  the total separation at about 43px — still clearly a break between items, no longer a stanza.
+*/
+.slidev-layout ul {
+  list-style: none;
+  padding-left: 0;
+}
+.slidev-layout ul > li {
+  position: relative;
+  padding-left: 1.6em;
+  margin-bottom: 0.3em;
+}
+.slidev-layout ul > li::before {
+  content: '';
+  position: absolute;
+  /*
+    ★★ CENTRED ON THE LINE BOX, NOT ON A CONSTANT. This was `top: 0.62em`, which put the dot's
+    centre 0.87em below the item's top — measured on the specimen's own list, 41.8px against a
+    line-box centre of 34.8px, so it sat 7px low. The comment two rules up reasons from a body
+    line-height of 1.6 and the deck computes 1.45, which is how a hard-coded offset drifts: it is
+    independent of the thing it is supposed to centre against. `0.5lh - 0.25em` is half the line box
+    less half the dot, so it lands on the centre at any size and any tier and cannot drift again.
+
+    (For the record, 0.87em was almost exactly the X-HEIGHT centre, 40.8px — a real typographic
+    target, and the right one for lowercase-heavy text. Deck copy is sentence case and full of caps
+    and ascenders, so the eye reads the cap band instead and the dot looked low against it. Cap
+    centre is 36px, within 1.2px of the line box, so centring on the line box satisfies both.)
+
+    ★ AND IT SITS 0.55em IN RATHER THAN ON THE MARGIN. At `left: 0` the dot's right edge was 1.1em
+    from the text — more than twice the dot's own width — so the pair read as two objects rather
+    than one marker. Moving the dot rather than the text closes it to 0.55em and leaves the text
+    column where it is, which matters because a list usually sits under a paragraph and the two
+    share a left edge. What it gives up is the hanging bullet, where the dot aligns with the
+    paragraph margin and the text is indented past it.
+  */
+  left: 0.55em;
+  top: calc(0.5lh - 0.25em);
+  width: 0.5em;
+  height: 0.5em;
+  border-radius: var(--deck-radius-full);
+  background: var(--deck-accent);
+}
+/* `list-style-type: decimal` is not the browser default here — Slidev's own base styles (via
+   UnoCSS's Tailwind-style preflight) reset it to `none` on every list, the same normalisation
+   `ul` above deliberately keeps (it draws its own disc via `::before` instead of a native
+   marker). `ol` never got the equivalent restoration: found live, adding the first `<ol>` this
+   theme's own demo deck had ever rendered — `.slidev-layout ol > li::marker` two rules down has
+   existed since this file did, and had never had anything to colour, because `list-style-type:
+   none` means `::marker` generates no box at all regardless of what colours it. */
+.slidev-layout ol {
+  list-style-type: decimal;
+  padding-left: 1.4em;
+}
+.slidev-layout ol > li {
+  margin-bottom: 0.3em;
+}
+.slidev-layout ol > li::marker {
+  color: var(--deck-accent);
+  font-weight: 700;
+}
+/*
+  ── THE CONTENTS PAGE ──────────────────────────────────────────────────────────────────────────
+
+  Every section and subsection the deck declares, in five columns. It is an INDEX — scanned for one
+  word, not read — so the whole treatment is about making a section findable and its subsections
+  legible as belonging to it.
+
+  ★★ THE TWO TIERS ARE RAMP RUNGS, AND DIFFER BY SIZE, WEIGHT, INDENT AND INK. This deck has two
+  weights, so a hierarchy that needs a third of anything does not exist here: a section is
+  `heading-sm` (48px, 700) and a subsection is `body-sm` (36px, 400) — two rungs the ramp already
+  has, one bold and one not. Nothing is invented and nothing is a fraction of something else.
+
+  ★★ GREEN IS THE SUBJECT, WARM IS THE CONNECTIVE TISSUE. The sections carry `--deck-accent`, which
+  is what the deck already means by "this is a thing you can go to". The warm family is spent on the
+  parts that are not text — the rule a section's children hang from, and the ground a row takes when
+  it is under the pointer — so the page reads as one green list on paper rather than two colours
+  competing down a column. `--deck-ink-warm` appears only on hover, where it is the only warm INK on
+  the page and therefore unmistakably the thing being pointed at.
+
+  ★ THE PROSE ROW MARGIN COMES OFF, AND IT IS WHAT MAKES THE PAGE FIT. `ol > li` above carries
+  `margin-bottom: 0.3em` because consecutive prose items are separate thoughts; thirty-four of those
+  is 250px. Measured against the 96px bottom inset the audit enforces: with the margin the page
+  misses that line, without it it clears.
+*/
+.slidev-layout .deck-contents {
+  column-count: 5;
+  column-gap: var(--deck-space-4);
+}
+.slidev-layout .deck-contents ol {
+  list-style: none;
+  padding-left: 0;
+}
+/*
+  ⚠ NO BLANKET `margin-bottom: 0` HERE ANY MORE. One existed to cancel the prose row margin, and at
+  (0,2,1) it also beat the per-tier gaps below at (0,2,0) — so the two rules that give this page its
+  spacing silently did nothing and a wrapped row still read as two rows. Both tiers state their own
+  gap instead, and each is (0,2,0) against the prose rule's (0,1,2), which they win on class count.
+*/
+/* ★★ THE ROW IS THE UNBREAKABLE UNIT, NOT THE GROUP — AND THE PAGE ONLY FITS BECAUSE OF IT. Holding
+   a whole section together was the first answer (measured at three columns, a nested list broke away
+   from its own section and opened the next column alone, reading as a top-level entry), but a group
+   the balancer may not split sets a floor no column count can get under: held whole, the longest
+   section is 670px of a 720px column, so four columns could pack at most 827 against that budget and
+   the page overflowed by construction as the deck grew. A wrapped ROW still may not split. What
+   keeps a continuation reading as subordinate is the warm rule and the indent below, which travel
+   with the row rather than with the column. */
+.slidev-layout .deck-contents-section {
+  margin-bottom: var(--deck-space-5);
+}
+/*
+  ★★ THREE GAPS, AND THEY HAVE TO BE IN THIS ORDER OR A WRAPPED ROW READS AS TWO ROWS. A subsection
+  title long enough to wrap is the case that decides this page's spacing: with the ramp's own body-sm
+  leading (1.5) and no gap between items, the space INSIDE a wrapped item was exactly the space
+  BETWEEN two items, so "Device and browser / frames" read as two entries. Reported on sight.
+
+  So the three are separated deliberately, tightest first:
+
+      inside a wrapped row   1.2 line-height   ~7px of leading
+      between rows           --deck-space-3    24px
+      between sections       --deck-space-5    40px
+
+  ★★ AND THE TWO OUTER GAPS ARE SET BY THE SPACE LEFT OVER, not by the ladder's next rung. Five
+  columns of rows that may wrap took the page from 54px past the canvas to 121px short of the text
+  inset, and a list that stops two-thirds down a slide reads as a page that ran out rather than one
+  that was composed. MEASURED on the longer of the two contents slides, list bottom against the 984
+  inset: 16/24 ends at 863, 24/40 at 927, 32/40 at 959, 32/48 at 975. 24/40 spends the slack and
+  keeps 57px in hand for a face that sets wider; 32/48 is inside the noise.
+
+  ★ THE 1.2 IS NOT INVENTED — it is `--type-deck-label-line-height`, the ramp's own tight line box at
+  this exact size (2.25rem). The ramp pairs that size with two leadings, 1.5 for running prose and
+  1.2 for a label, and an index is the second thing rather than the first.
+
+  ★ AND THE ROW IS WHERE `break-inside: avoid` LIVES, for the reason above: a row that wrapped across
+  a column boundary would be the one thing on this page that genuinely cannot be read.
+*/
+.slidev-layout .deck-contents-subsection {
+  break-inside: avoid;
+  margin-bottom: var(--deck-space-3);
+}
+.slidev-layout .deck-contents-subsection:last-child {
+  margin-bottom: 0;
+}
+
+.slidev-layout .deck-contents-link {
+  /* The underline the theme gives every `a` is wrong on an index: thirty-four of them is a page of
+     rules rather than a list of names. */
+  text-decoration: none;
+  transition: color var(--motion-fast) var(--motion-ease-out);
+}
+/*
+  ★★ THE SIZE AND THE LINE BOX ARE SET ON THE ROW, NOT ON THE LINK. The link is inline, and an
+  inline element does not own its line box — the row's own strut does, so a `line-height` on the
+  `<a>` was simply outvoted by the `li`'s inherited 1.45 and every row stood a third taller than it
+  was measured to. The page overflowed its bottom inset by 41px on exactly that.
+*/
+.slidev-layout .deck-contents-section > .deck-contents-link.is-section,
+.slidev-layout li.deck-contents-section {
+  font-size: var(--type-deck-heading-sm-size);
+  line-height: var(--type-deck-heading-sm-line-height);
+}
+.slidev-layout .deck-contents-link.is-section {
+  font-weight: 700;
+  color: var(--deck-accent);
+}
+.slidev-layout li.deck-contents-subsection,
+.slidev-layout .deck-contents-subsection > .deck-contents-link {
+  font-size: var(--type-deck-body-sm-size);
+  line-height: var(--type-deck-label-line-height);
+}
+.slidev-layout .deck-contents-subsection > .deck-contents-link {
+  font-weight: 400;
+  color: var(--deck-fg-muted);
+}
+
+/*
+  ★ THE SUBSECTIONS HANG OFF A WARM RULE, which is the only thing on the page that says "these
+  belong to the name above them". A rule rather than an indent alone: at four columns the longest
+  title wraps, and a wrapped line under a bare indent reads as a new entry — against a rule it
+  reads as a continuation. The inset is the rule's own offset plus its gap, so a retune moves both.
+*/
+.slidev-layout .deck-contents ol.deck-contents-subsections {
+  position: relative;
+  margin-top: var(--deck-space-1);
+  /*
+    ★ THE WHOLE GROUP IS INSET, BAR INCLUDED. The bar is positioned against this box, so indenting
+    the box moves the rule and its rows together — the alternative, nudging only the `::before`,
+    would leave the rule floating inside the text block rather than hanging beside it. Flush at the
+    column edge it read as a border on the column rather than a mark belonging to the section.
+  */
+  margin-inline-start: var(--deck-space-2);
+  /*
+    ★ THE SELECTOR CARRIES `ol` ON PURPOSE. `.deck-contents ol { padding-left: 0 }` above is
+    (0,2,1) and strips the browser's list indent; a class-only rule here is (0,2,0) and loses to
+    it, so the indent silently stayed at zero and the subsections hung under their section with
+    nothing but weight telling them apart. Matched at (0,3,1) instead.
+  */
+  padding-left: var(--deck-space-2);
+}
+/*
+  ★★ THE BAR IS A PSEUDO-ELEMENT, BECAUSE A `border-left` HAS NO ENDS. It was one, and a border is
+  drawn to the edges of its box with square corners — there is no property that rounds only the two
+  ends of one side. Absolutely positioned instead, so it can carry a radius and a width of its own
+  without either touching the text's indent.
+
+  ★★ `--deck-bg-warm-mark`, NOT `--deck-bg-warm`. The fill is a GROUND — measured 1.30:1 against the
+  page, right for a panel behind type and invisible as a rule. The family's `mark` role is the one
+  meant to be seen on its own ground: 4.99:1 here. A rule that cannot be seen is worse than none,
+  because the indent then reads as an accident.
+*/
+.slidev-layout .deck-contents-subsections::before {
+  content: '';
+  position: absolute;
+  inset-block: 0;
+  inset-inline-start: 0;
+  width: calc(var(--deck-space-1) / 2);
+  border-radius: var(--deck-radius-full);
+  background: var(--deck-bg-warm-mark);
+}
+
+/*
+  ★ HOVER AND FOCUS TOGETHER, ALWAYS. The pointer is not the only way into this page — a presenter
+  tabs it, and an index whose affordance is pointer-only is an index half the room cannot use.
+*/
+.slidev-layout .deck-contents-link:hover,
+.slidev-layout .deck-contents-link:focus-visible {
+  color: var(--deck-ink-warm);
+}
+
+/*
+  Nested lists step down a tier rather than repeating the shout.
+
+  ★★ A TIER IS A SIZE, AND FOR A LONG TIME ONLY THE MARKER STEPPED. The rule below quietened the
+  disc — subtle instead of accent, 0.4em instead of 0.5 — and the TEXT beside it stayed at the
+  parent's size, so a nested item was a full-size line wearing a smaller bullet. Measured on
+  apps/deck's prose slide: both tiers at 48px.
+
+  The step is the ramp's own next rung, `body-sm`, taken from the token rather than expressed as a
+  fraction: the nested tier is not "a bit smaller", it is the role the type system already has for
+  subordinate running text, and a `0.75em` would be that same number restated where a retuned ramp
+  could not reach it. Its line-height comes with it, or the tighter type would sit in the taller
+  tier's leading.
+
+  Everything the marker is sized in is `em`, so it follows the text down on its own: 0.4em of the
+  nested 36px is a 14px disc where it was 19px at 48. The one number that does NOT follow is
+  `top`, which was tuned against the parent tier's 1.6 line box and is re-tuned here for body-sm's
+  1.5.
+*/
+.slidev-layout li ul,
+.slidev-layout li ol {
+  font-size: var(--type-deck-body-sm-size);
+  line-height: var(--type-deck-body-sm-line-height);
+  margin-top: 0.3em;
+}
+/* The nested tier carries the same two corrections, against its own smaller dot: half the line box
+   less half of 0.4em, and the same 0.55em inset. It runs at the dense type tier, whose line-height
+   differs again — which is the whole reason neither number is written as a constant. */
+.slidev-layout li ul > li::before {
+  background: var(--deck-fg-subtle);
+  width: 0.4em;
+  height: 0.4em;
+  left: 0.55em;
+  top: calc(0.5lh - 0.2em);
+  border-radius: var(--deck-radius-full);
+}
+
+/* ── Rules, links, code, quotes ───────────────────────────────────────────────────────────── */
+
+.slidev-layout hr {
+  border: none;
+  height: 4px;
+  width: var(--deck-space-7);
+  background: var(--deck-accent);
+  margin: var(--deck-space-3) 0;
+}
+
+.slidev-layout a {
+  color: var(--deck-accent);
+  text-decoration: underline;
+  text-underline-offset: 0.15em;
+  text-decoration-thickness: 0.06em;
+  transition: color var(--motion-fast) var(--motion-ease-out);
+}
+.slidev-layout a:hover {
+  color: var(--deck-accent-strong);
+}
+
+/* ⚠ NO `background` HERE, and the one that was is why this note exists. This set
+   `var(--deck-accent-soft)` at (0,1,1), and the rule below re-points inline code to --deck-surface
+   at (0,3,1) — so the declaration could never apply. It was left behind when the code block moved to
+   Catppuccin and the chip went back to the deck surface; measured live, the chip's computed fill is
+   the surface mix, identical to the block's. A dead declaration is worse than none: it reads as the
+   answer to "what colour is an inline code chip" and is not. */
+.slidev-layout code {
+  font-family: var(--font-mono);
+  font-size: 0.85em;
+  color: var(--deck-accent);
+  padding: 0.05em 0.3em;
+  /* ⚠ NO `border-radius` HERE, AND THE ONE THAT WAS NEVER APPLIED. This selector is (0,1,1) and
+     @slidev/client's `.slidev-layout :not(pre) > code` is (0,2,1), so its `var(--slidev-code-radius)`
+     won every time: the chip has been drawing at Slidev's 24px, not at the --deck-radius-item this
+     rule asked for, since the theme shipped. Measured live before moving it. The radius now sits on
+     the (0,3,1) rule below, beside the fill and the edge that had to go there for the same reason —
+     the same trap the note above this rule records for `background`. */
+}
+
+/*
+  ★★ INLINE CODE KEEPS THE DECK SURFACE; ONLY THE BLOCK TAKES CATPPUCCIN'S GROUND.
+
+  Slidev paints both from --slidev-code-background (its own code.css), and that token is Catppuccin's
+  base now — right for a block, wrong for a `code` chip sitting inside a sentence of Forest prose,
+  which is deck furniture and should read as one. So the chip is re-pointed back at the surface it
+  always had. The block below is the only thing that changes register-source.
+*/
+/*
+  ⚠ `:not(.shiki)` IS A SPECIFICITY COUNTERWEIGHT, NOT A FILTER, and it is here because the note in
+  styles/tokens.css already measured this exact collision. @slidev/client's own rule is
+  `.slidev-layout :not(pre) > code` at (0,2,1); repeating that selector verbatim TIES, and a tie is
+  decided by whichever stylesheet the bundler happens to emit last — which is not a thing to leave a
+  register-correct colour resting on. One more class-shaped pseudo makes it (0,3,1) and the tie is
+  gone. An inline `<code>` is never `.shiki` (Shiki writes that class on the `<pre>`), so the
+  selector matches exactly what it did before.
+*/
+/*
+  ★★ THE CHIP IS A WASH OF ITS OWN INK, NOT A FIXED SURFACE.
+
+  It was --deck-surface, which is the SLIDE's neutral surface mix and tracks the page rather than
+  whatever the chip is actually sitting on. Inside a warm panel that put a grey chip with green type
+  on a peach ground — three families in one word, and the thing that reads as wrong is the grey.
+
+  `currentColor` makes the fill and the edge derive from the chip's own colour, so the chip lands on
+  every ground the deck has without a rule per ground: on the page it is a wash of the accent, on a
+  named background it is a wash of that family's ink (below), and on the dark register it inverts
+  with the ink it is mixed from. A ground this theme has not invented yet is handled too.
+
+  ⚠ MIXED WITH `transparent`, NOT WITH THE GROUND. The chip must not know what is behind it — it sits
+  on panels, on cards and on the page, and a mix against a named ground would be wrong on two of the
+  three. An alpha wash is right on all of them.
+*/
+.slidev-note :not(pre) > code:not(.shiki),
+.slidev-layout :not(pre) > code:not(.shiki) {
+  background: color-mix(in oklab, currentColor 8%, transparent);
+  /*
+    THE STRONG EDGE ALPHA, AT THE CHIP'S OWN WIDTH. This was 18%, BELOW the 20% the card's
+    `hairline` edge takes — so the chip carried the faintest edge in the deck while being the
+    smallest thing that has one, and read as a hairline at room scale. 40% is the card's `strong`
+    alpha; the card spends 4px on it because it is a frame, and a chip inside a sentence spends 2.
+    Measured over the chip's own 8% fill: 1.30:1 at 18%, 1.84:1 here.
+  */
+  border: 2px solid color-mix(in oklab, currentColor 40%, transparent);
+  /*
+    A SOFT CORNER, NOT A PILL. The chip measures 65 canvas px tall, so Slidev's --slidev-code-radius
+    (24px, 39 canvas px) is 60% of its height and draws a lozenge. Twice the base rung is 26 canvas
+    px, two fifths of the height — a rounded box, still a box. There is no NAMED step here:
+    --deck-radius-nested is the same 16px today but is derived from the card radius and follows it,
+    which is not a dependency a chip in a sentence should have.
+  */
+  border-radius: calc(var(--deck-radius) * 2);
+}
+.slidev-layout pre {
+  font-family: var(--font-mono);
+  background: var(--slidev-code-background);
+  /* ★ THE EDGE FOLLOWS THE GROUND. This was --deck-border — deck-bg mixed 14% toward the ink — which
+     tracked the SLIDE, not the block. With the ground moved to Catppuccin's base the two came apart:
+     measured on the dark register, a #24443e border (hue 181, teal-green) around a #1e1e2e block
+     (hue 282, violet), a hundred degrees of hue between a box and its own edge. */
+  border: 1px solid var(--deck-code-border);
+  /* ★★ ONE RADIUS FOR EVERY CODE BLOCK-SHAPED THING, and it is Slidev's own `--slidev-code-radius`
+     rather than the nested step. `.slidev-code` already carries that value with an `!important` of
+     Slidev's making, so a bare `<pre>`, a code GROUP and a magic-move well rounding at the nested
+     16px meant four objects that sit in the same place on a slide drew four different corners —
+     visible the moment two of them appear on consecutive slides. The nested step stays where it
+     means something: a `pre` INSIDE a card, which is genuinely one box in another. */
+  border-radius: var(--slidev-code-radius);
+  padding: var(--deck-space-3) var(--deck-space-4);
+}
+/* A code chip inside a block is already on the block's ground — drop the double fill. */
+/*
+  ★★ THE FONT SIZE IS PART OF THE RESET. The rule above is for an inline code CHIP and shrinks it to
+  0.85em to sit in a line of prose; `code` inside a `pre` matches it too, so without this a block
+  renders at 30.6px against the 36px its own token asks for.
+
+  It also caused the seams between lit lines: 1.5 x 30.6 is 45.9px, a fractional line box, so each
+  row rounded to a device pixel on its own and a hairline of ground showed between backgrounds that
+  the layout says are flush (measured gap: exactly 0). At 36px the box is 54px and they tile.
+*/
+.slidev-layout pre code {
+  background: none;
+  padding: 0;
+  color: inherit;
+  font-size: inherit;
+}
+
+/* ── The code register switch — a MEASURED fix, not a preference ──────────────────────────────
+   Shiki in dual-theme mode writes both palettes onto every token span as `--shiki-light` and
+   `--shiki-dark`, and @slidev/client/styles/code.css picks between them with:
+
+       html.dark        .shiki span { color: var(--shiki-dark) }
+       html:not(.dark)  .shiki span { color: var(--shiki-light) }
+
+   ★★ `html.dark` IS NOT THIS DECK'S DARK. The deck runs LIGHT and marks individual slides
+   `class: deck-dark` — dark is punctuation here, not the ground (deck.css says so at length) — so
+   `html` stays `.light` all the way through a dark slide and Slidev's second rule keeps handing
+   out the LIGHT palette over a dark code block. Measured on a live render, Go on a deck-dark
+   slide, against the block's own #0c332d ground:
+
+       func     #1e754f   2.43:1      <- the commonest token in the sample
+       0        #2f798a   2.77:1
+       *        #ab5959   2.82:1
+       Fleet    #2e8f82   3.51:1
+       (        #999999   4.83:1      <- punctuation, the only scope that passed
+
+   A screenshot did not show it. At thumbnail size the eye reconstructs the glyphs; the DOM is what
+   said the contrast was not there, which is why this was probed rather than looked at.
+
+   SPECIFICITY IS THE WHOLE MECHANISM, so it is spelled out. Slidev's rule scores (0,2,2) —
+   `html` + `:not(.dark)` + `.shiki` + `span`. A plain `.deck-dark .shiki span` is (0,2,1) and
+   LOSES, silently, leaving this section looking correct and changing nothing. Qualifying with the
+   layout class makes it (0,3,1): three classes beats two whatever the element count, and it does
+   not depend on which stylesheet the bundler happens to emit last.
+
+   ★★ AND THE CLASS CAN LAND IN THREE PLACES, WHICH IS WHY THERE ARE THREE SELECTORS RATHER THAN
+   TWO. This listed the layout root (`class: deck-dark` in frontmatter) and an ancestor of it, and
+   missed the one placement that is now a PROP: `panelDark` puts the class on a panel INSIDE the
+   layout (split.vue, stack.vue), and styles/tokens.css has always said the class can land on "a
+   wrapper inside a slide (a dark card band, a chart well)". Every role follows it there, because
+   custom properties inherit; this rule did not, because it names its ancestor.
+
+   The failure was silent in the way this whole section is about: the panel's ground turned over,
+   the code block's ground turned over with it (--slidev-code-background is --deck-surface, a role),
+   and the TOKENS stayed on the light palette — the same 2.43:1 the table above measures, on a
+   surface that now looks deliberate. All three placements score (0,3,1); the descendant one is not
+   weaker for being a descendant. */
+.slidev-layout.deck-dark .shiki,
+.deck-dark .slidev-layout .shiki,
+.slidev-layout .deck-dark .shiki {
+  color: var(--shiki-dark, inherit);
+}
+.slidev-layout.deck-dark .shiki span,
+.deck-dark .slidev-layout .shiki span,
+.slidev-layout .deck-dark .shiki span {
+  color: var(--shiki-dark);
+}
+
+/* ★★ RETIRED — a code block inside a Card no longer needs lifting off it.
+   This raised the block to --deck-surface-strong because both it and the Card painted --deck-surface,
+   so a block inside a card vanished into its container. The block's ground is Catppuccin's own base
+   now (see tokens.css), which is a different colour from the Card on both registers — 1.04:1 apart on
+   light and 1.19:1 on dark is not much, but the two are no longer the SAME value, which is what the
+   rule existed for. Keeping it would have pushed the block a rung away from a ground it no longer
+   shares, for no reason a reader could see. */
+
+/* ── Code groups ──────────────────────────────────────────────────────────────────────────────
+   The tab strip and the block under it are ONE surface, and Slidev draws them as two: the strip
+   carries the code background and the block re-declares it, so at the seam a 1px inset shadow is
+   all that joins them. On a projector that reads as a floating label. Border and corner come from
+   the deck contract so the group matches every other container on the slide. */
+.slidev-layout .slidev-code-group {
+  border: 1px solid var(--deck-border);
+  /* The same radius a lone block takes — a group IS a block, with tabs. See the note on `pre`. */
+  border-radius: var(--slidev-code-radius);
+  overflow: hidden;
+}
+.slidev-layout .slidev-code-group .slidev-code {
+  border: none;
+  border-radius: 0 !important;
+}
+/* ★ A TAB IS A FILENAME, SO IT KEEPS ITS OWN CASE. Every other piece of furniture in this deck —
+   the section pill, the eyebrow, the specimen label — is set in the overline role, which uppercases.
+   A filename is not furniture, it is an IDENTIFIER: `Panel.vue` and `panel.vue` are two different
+   files on a case-sensitive disk, and `PANEL.VUE` is neither. So the tab strip takes the overline's
+   size and tracking (it is still small, quiet, room-scale furniture) and NOT its transform. */
+/*
+  ── THE NUMBERED GUTTER ────────────────────────────────────────────────────────────────────────
+
+  Slidev draws it as a `::before` on every `.line` and styles it
+  `--uno: w-4 mr-6 text-gray-400 dark-text-gray-600`. Three problems on this deck, all from the same
+  cause — those utilities were written against Uno's default scale, and uno.config.ts REPLACES
+  `theme.spacing` wholesale with the deck's own named ladder:
+
+    · `w-4` and `mr-6` are numeric steps that do not exist here, so they generate nothing and the
+      gutter's width and gap fall back to whatever the preset happens to give.
+    · `text-gray-400` is a grey belonging to no register in this deck, and it does not move between
+      light and dark the way every other quiet ink does.
+
+  A line number is the one thing on a code slide nobody reads in sequence — it is an index you jump
+  to when someone says "line four" — so it takes the muted role at the annotation rung, and its
+  width is stated in `ch` because it is counting DIGITS, not spanning a box.
+*/
+.slidev-layout .slidev-code-line-numbers .slidev-code code .line::before {
+  width: 2ch;
+  margin-right: var(--deck-space-4);
+  color: var(--deck-fg-subtle);
+}
+
+/* ★★ AND THE SAME STRIP SERVES A SINGLE BLOCK'S TITLE. Slidev draws ```go [fleet.go] with
+   `.slidev-code-block-title` — the same header bar as a code group's tab row, with one label
+   instead of a row of them — and this rule named only the group. A deck could put a filename on a
+   lone block and get mermaid's… no: get SLIDEV's stock strip, sans-serif and square against a
+   themed one three lines further down the same slide. Named together because they ARE the same
+   piece of furniture. */
+/*
+  ★★ THE TAB ROW IS SQUARED AND THE LONE TITLE IS LEFT ALONE, which is the opposite of where this
+  started. Stock already rounds BOTH strips — `client/styles/code.css:54`, `border-radius: R R 0 0`
+  — and this theme used to flatten both with a `border-radius: 0` that read as "keep Slidev's
+  corners out". That was the bug behind the square-topped block on `A numbered block, named`: the
+  `pre` rounds `0 0 R R` precisely because a strip sits above it, so suppressing the strip's corners
+  left the object round along the bottom and cut square along the top. Deleting the override is the
+  whole fix there — stock is right, and no rule for the title belongs here.
+
+  A GROUP is the other way round. `.slidev-code-group` is itself a rounded, clipping box, so stock's
+  radius on its tab row is a second curve inside the first; with the two at different values it drew
+  a visible seam — the group clipping on one arc, the row's grey ending on another, the group's 1px
+  border tracing a third. Reported on `Code group`. The wrapper clips; the row stays square.
+*/
+.slidev-layout .slidev-code-group-tabs {
+  border-radius: 0;
+}
+/*
+  ★★ NO HAIRLINE UNDER EITHER STRIP. Stock draws one as `box-shadow: inset 0 -1px` — a 1px rule
+  between the strip and the code. It is redundant here: the strip already sits on
+  `--deck-surface-strong` and the code on `--slidev-code-background`, two different grounds, so the
+  seam is a change of fill and does not also need a line drawn on it. Removing it is what lets the
+  filename centre (below), and it costs no height either way.
+
+  ★★ AND A LONE TITLE SPENDS THE TAB'S UNDERLINE AS PADDING RATHER THAN RESERVING IT. `border-bottom-width`
+  above is a TAB's active marker; a strip with one label has nothing to mark. It cannot simply be
+  dropped — a tab row is padding + label + that 8px, so a title without it stands 8px shorter than
+  the row on the previous slide, and this book puts the two on consecutive slides. Nor can it stay:
+  reserved at the BOTTOM it pushed the label up, measured 16px above and 24px below.
+
+  So the rung is taken off the border and added to the block padding, half at each end: same total
+  height as a tab row, label centred in it. (It was briefly a transparent border, which held the
+  height and kept the label 8px high — this is the same arithmetic with the space where it belongs.)
+*/
+.slidev-layout .slidev-code-block-title,
+.slidev-layout .slidev-code-group-tabs {
+  box-shadow: none;
+}
+.slidev-layout .slidev-code-block-title,
+.slidev-layout .slidev-code-group-tabs {
+  font-family: var(--font-mono);
+  /* ★ AND NOT THE OVERLINE'S TRACKING EITHER. This took the overline's letter-spacing along with
+     its size, on the reasoning that the strip is small, quiet furniture. Tracking is opened up to
+     make UPPERCASE furniture legible; a filename is neither uppercase (see above) nor furniture,
+     and letter-spaced mono reads as a label of a file rather than as the file's name. */
+  letter-spacing: normal;
+  /* The strip is a header ON the block, not a row floating above it: its own raised ground and one
+     divider, so the tabs and the code read as one object the way the design system's own code group
+     does.
+
+     ★ THE DIVIDER IS STOCK'S, NOT A BORDER OF OURS. `client/styles/code.css:55` already draws it as
+     `box-shadow: inset 0 -1px var(--slidev-code-tab-divider)`, and tokens.css points that variable
+     at `--deck-border` — the same line, the same colour. Adding a real border drew it twice and,
+     because a border occupies layout where an inset shadow does not, left the tab row exactly 1px
+     taller than a lone title strip. That was the last of a 14px difference between two strips this
+     book puts on consecutive slides. */
+  background: var(--deck-surface-strong);
+}
+/*
+  ★★ AND THE TWO STRIPS STAND THE SAME HEIGHT, which they did not: 70px against a tab row's 84.
+  Slidev wraps a lone filename in its own `.leading-1em` div, so the label sat in a 1em line box
+  while a tab sat in the inherited 1.45 one — same padding, same border, 14px apart, and the two
+  are read on consecutive slides in this book. The utility is neutralised rather than the padding
+  retuned, so both strips keep taking their height from the same three terms.
+*/
+.slidev-layout .slidev-code-block-title > .leading-1em {
+  line-height: inherit;
+}
+.slidev-layout .slidev-code-block-title,
+.slidev-layout .slidev-code-tab {
+  padding: var(--deck-space-2) var(--deck-space-4);
+  /* Stock draws a 2px underline. At 1920 across a room that is a hairline — the one thing on the
+     strip that says which file you are looking at, drawn at the width of a border. */
+  border-bottom-width: var(--deck-space-1);
+  border-bottom-style: solid;
+  /* Stock hard-codes `transition: color 0.25s`, which is off the ladder in both duration and
+     easing, and is the same class of miss as the magic-move timing below. */
+  transition:
+    color var(--motion-base) var(--motion-ease-out),
+    border-color var(--motion-base) var(--motion-ease-out);
+}
+/*
+  ★ AFTER the rule above, deliberately: both selectors are (0,2,0), so this only wins on order. It
+  was written before it once and silently lost — the strip kept the tab's 8px rung and its label
+  stayed 8px high.
+*/
+.slidev-layout .slidev-code-block-title {
+  border-bottom-width: 0;
+  padding-block: calc(var(--deck-space-2) + var(--deck-space-1) / 2);
+}
+/* The file-type mark. Slidev's TitleIcon renders it with `w-3.5 h-3.5`, and those utilities do not
+   exist in this deck — uno.config.ts replaces `theme.spacing` wholesale with the deck's own named
+   ladder, so a numeric `w-3.5` generates nothing at all and the icon fell back to whatever box the
+   preset gave it. Sized here against the tab's own text instead: an editor draws this mark at
+   roughly the cap height of the label beside it, and that proportion is what makes it read as a
+   file mark rather than as a picture. */
+.slidev-layout .slidev-code-block-title > [class*='i-vscode-icons'],
+.slidev-layout .slidev-code-tab > [class*='i-vscode-icons'] {
+  width: 1.1em;
+  height: 1.1em;
+  flex: none;
+}
+
+/*
+  ★ THE COPY BUTTON IS SIZED FOR A WEB PAGE, AND THIS IS A 1920 CANVAS.
+
+  Slidev renders it as `<svg class="slidev-icon p-2 w-8 h-8">` — a 32px icon, which is right at a
+  reader's arm's length and is 1.7% of the width of a slide. Beside 36px mono it reads as a speck.
+  MEASURED on apps/deck 9: a 32px icon in a button box 32 wide and SEVENTY tall, because
+  the button inherits the slide's body line-height (48px x 1.45 = 70) and never sets its own — so
+  most of what it occupies is leading around an icon that is not there.
+
+  Sized against the CODE rather than against the slide: the button takes the block's own font size,
+  the icon takes 1.1em of that, and `line-height: 1` makes the box the icon again. Same reasoning
+  and the same number as the file-type mark above — an editor draws its furniture at roughly the cap
+  height of the text beside it, and that proportion is what makes it read as a control rather than
+  as a picture.
+
+  It also sat flush in the block's corner, over the padding rather than inside it, so it crowded the
+  first line's last token. Inset by the block's own padding variable, which is the same edge every
+  other thing in the block is measured from.
+
+  Left at Slidev's own visibility — invisible until the block is hovered — deliberately: on a
+  projector nothing is ever hovered, so this costs the room nothing, and the specimen is also read
+  on a screen where copying a frontmatter sample is the point.
+*/
+.slidev-layout .slidev-code-wrapper .slidev-code-copy {
+  top: var(--slidev-code-padding);
+  right: var(--slidev-code-padding);
+  font-size: var(--slidev-code-font-size);
+  line-height: 1;
+}
+/*
+  ★★ AND IT MOVES INTO THE STRIP WHEN THERE IS ONE, because `top` above is measured from the
+  WRAPPER and the wrapper starts at the title bar, not at the code. On a bare block one code padding
+  down is the first line's last token, which is what that rule is for; put a 42px strip above the
+  same block and the button lands ASTRIDE the divider — measured on the specimen's `A numbered
+  block, named`: button 293.7→317.8, strip ending 316.7, so it hung 1px into the code below and cut
+  the one line that separates the two halves of the object.
+
+  Centred on the strip rather than nudged: the strip is its own vertical padding plus a 1em label
+  (`.leading-1em`), and the button is 1.1em, so half the difference is the whole correction and it
+  follows any retune of either variable.
+
+  ★ A CODE GROUP NEEDS NOTHING HERE, and the obvious companion selector for it is DEAD — checked
+  rather than assumed. A group's tab row hangs off `.slidev-code-group`, not `.slidev-code-wrapper`:
+  the tabs sit beside `.slidev-code-group-blocks`, and each block inside keeps its OWN wrapper. So
+  the copy button's wrapper never contains the tab row, `:has(.slidev-code-group-tabs)` matches
+  nothing, and the button correctly stays one code padding inside the code it copies.
+*/
+.slidev-layout .slidev-code-wrapper:has(.slidev-code-block-title) .slidev-code-copy {
+  /*
+    ★★ GIVEN THE LABEL'S OWN LINE BOX AND CENTRED IN IT, rather than offset by a number. This was
+    `calc(var(--deck-space-2) - 0.05em)`, solved against the strip as it was then — 16px padding and
+    a 1em label — and it silently stopped being centred the moment the strip took the tab's underline
+    rung as padding: measured 14.2px above the button and 29.7px below.
+
+    Two terms, both the strip's own: `top` is exactly the strip's padding-block, so the button starts
+    where the filename starts; `height` is the line box that filename sits in, so centring inside it
+    centres the two against each other. Nothing here is a measured constant, so a retune of the
+    padding rung or the tab font size moves both together.
+  */
+  top: calc(var(--deck-space-2) + var(--deck-space-1) / 2);
+  height: calc(var(--type-deck-body-line-height) * var(--slidev-code-tab-font-size));
+  display: flex;
+  align-items: center;
+}
+.slidev-layout .slidev-code-wrapper .slidev-code-copy .slidev-icon {
+  width: 1.1em;
+  height: 1.1em;
+  padding: 0;
+}
+
+/* ── The marquee, frozen for export ───────────────────────────────────────────────────────────
+   `slidev export` navigates to the /print route, which renders every slide inside
+   `#print-container`, and calls `page.pdf()`. It also does `emulateMedia({ media: 'screen' })`
+   first — so an `@media print` rule is dead here, and this ancestor class is the only hook there is.
+
+   Without it the PDF catches the band wherever the compositor had it: measured, the first item read
+   "…thwark" where "Southwark" should be. The band is designed to be legible standing still, and
+   translate(0) is the frame it must stand still ON — the same frame the engine's reduced-motion
+   floor lands it on.
+
+   ★★ IT IS HERE RATHER THAN IN Marquee.vue BECAUSE A SCOPED BLOCK DESTROYS IT. Vue compiles
+   `:global(#print-container) .deck-marquee-track { … }` down to `#print-container { … }` — the
+   descendant is dropped and the declaration lands on the container itself, doing nothing. The
+   component's own comment records that; this is where the rule actually lives. */
+#print-container .deck-marquee-track {
+  animation: none;
+}
+
+/* ── Magic move ───────────────────────────────────────────────────────────────────────────────
+   shiki-magic-move animates each token to its new position, and its stylesheet times that on its
+   own hard-coded durations. The deck has a motion ladder and a reduced-motion floor that every
+   other transition on a slide obeys; a code animation is not the one exception. `move` is the long
+   travel (a token crossing the block), `enter`/`leave` the short one. */
+/* ★ IT PAINTS THE CODE GROUND, NOT THE DECK SURFACE, and names the same two tokens `pre` does. The
+   two roles are not the same colour: a copy of `pre`'s fill here drifts the moment the block's
+   ground moves, and a magic-move slide then carries a different well from the slide before it. */
+.slidev-layout .shiki-magic-move-container {
+  background: var(--slidev-code-background);
+  border: 1px solid var(--deck-code-border);
+  /* The same radius a lone block takes — the well stands where a block would. */
+  border-radius: var(--slidev-code-radius);
+  padding: var(--deck-space-3) var(--deck-space-4);
+}
+.slidev-layout .shiki-magic-move-container pre.shiki {
+  background: none;
+  border: none;
+  padding: 0;
+}
+/* Magic move keeps shiki-magic-move's own timing. The --motion-* ladder is scaled for a control
+   answering a click, where the ceiling is 300ms; this is choreography an audience follows, and the
+   library's own 500ms default is scaled for that.
+
+   ⚠ An override here needs `!important`. The renderer sets the timing as an inline style on the
+   container (`container.style.setProperty('--smm-duration', …)`), which outranks a plain declaration.
+
+   Reduced motion is handled by the global floor in @humanforest/tokens/motion: it allow-lists
+   `transition-property`, so the travel and the container resize snap and the colour fade survives.
+   Nothing is needed here for it. */
+
+
+/* ── Maths (KaTeX) ────────────────────────────────────────────────────────────────────────────
+   The one built-in that arrived nearly right: KaTeX renders into ordinary DOM (no shadow root, no
+   canvas), inherits `color` from the slide, and needs no palette of its own. What it does need is
+   to be told the deck's SIZES, because its own are relative to a 16px web page.
+
+   ★ KATEX SETS 1.21em ON EVERY `.katex`, INLINE ONES INCLUDED. That multiplier is the TeX
+   convention for DISPLAY maths, and KaTeX applies it to the class rather than to display mode — so
+   measured on this deck, `$\frac{r}{v \cdot h}$` in a 48px paragraph rendered at 58.08px: maths
+   21% taller than the sentence carrying it, pushing the line box open around it. Inline maths
+   belongs ON the line.
+
+   The 1.05em that replaces it is an OPTICAL correction, not a reversal to 1. KaTeX_Main is a
+   Computer Modern cut with a noticeably smaller x-height than GT Haptik, so matched px-for-px it
+   reads smaller than the words either side of it. Nothing here re-points the family: a maths face
+   is a maths face, the brand does not have one, and setting GT Haptik on an equation would break
+   the glyph metrics KaTeX positions everything against.
+
+   Display maths takes a real rung instead of a multiple of whatever it happens to sit in — an
+   equation on its own line is the subject of the slide, so it is set one tier ABOVE body. */
+.slidev-layout .katex {
+  font-size: 1.05em;
+}
+.slidev-layout .katex-display > .katex {
+  font-size: var(--type-deck-title-size);
+}
+.slidev-layout .katex-display {
+  margin: var(--deck-space-4) 0;
+  /* A long equation cannot be re-broken — TeX has already set it — so the only honest options are
+     scroll it or let it paint off the canvas. `visible` is what KaTeX ships, and an equation that
+     leaves the slide is invisible to scripts/deckAudit.ts, which measures the ELEMENT's box. */
+  overflow-x: auto;
+  /* ★ AND THE SCROLL BOX CLIPS VERTICALLY TOO, which is a CSS rule rather than a choice: with
+     `overflow-x: auto`, a `visible` overflow-y computes to `auto`, so the box clips on both axes
+     whatever is written here. Tall constructs reach past their own line box — a summation's limits,
+     an integral, a stacked fraction — and the audit caught exactly that: the `n` above a \sum was
+     31% hidden, 12px cut off the top, with no ellipsis to say so. The padding is the room those
+     constructs need inside the box that now clips them. */
+  overflow-y: hidden;
+  padding-block: var(--deck-space-2);
+}
+
+/* ── DIMMING: MATHS ONLY. CODE IS STOCK. ──────────────────────────────────────────────────────
+   Slidev dims what is NOT under discussion to `opacity: 0.3` in both kinds of highlighting — a
+   `$$ {1|3|all}` maths block (`.mord.dishonored`) and a ```go {4-6} code block
+   (`.slidev-code-dishonored`). This theme used to override BOTH, on one measurement:
+
+       #a9b2ac on #f1ede6   1.86:1     (30 elements, the whole un-lit body of a code block)
+       #aac6b8 on #f1ede6   1.57:1
+       #d3bab4 on #f1ede6   1.57:1
+
+   The point of dimming a row is that the audience can still READ it and see it is not the one under
+   discussion; at 1.6:1 across a room it is not dimmed, it is gone.
+
+   ★ MATHS STILL TAKES THE OVERRIDE, and takes it as a COLOUR rather than an opacity. An equation
+   has one ink, so there is no hue to preserve, and a ground-relative mix is strictly better than an
+   opacity: it is contrast-gated, and the muted role is the deck's own answer to "present but not
+   the subject". The percentage table below is the tuning.
+
+   ★★ CODE NO LONGER DOES — 2026-09-06, deliberately, with the number above in view. See the block
+   further down for what came out with it and why. This file's rules stop at `.mord.dishonored`.
+*/
+/*
+  ⚠ THE CODE BLOCK'S OWN GROUND RE-POINT CAME OUT WITH THE MIX. `.slidev-code` used to set
+  `--deck-mermaid-label-bg: var(--slidev-code-background)` so the dimming mix was taken against the
+  surface the code actually sits on rather than against the page — correct while code was dimmed by
+  colour, and dead now that it is dimmed by opacity, which composites against whatever is behind it
+  without being told. The maths branch keeps the variable and its page default.
+*/
+.slidev-layout .slidev-katex-wrapper .mord.dishonored {
+  opacity: 1;
+  /*
+    ★★ A MIX TOWARD THE GROUND, NOT A ROLE, AND THAT IS WHAT LETS IT BE TUNED AT ALL.
+    `--deck-fg-subtle` is one colour for every ground, so its contrast is whatever each ground
+    happens to give it — MEASURED across the five, dimmed against ground:
+
+        page 4.55   neutral 4.17   accent 4.02   warm 3.50   vivid 2.62
+
+    A flat role also has nowhere to go: the next step down the ramp is neutral-400, at 2.51 on the
+    page and 1.44 on vivid. So "dim it further" was not available while the value was a role.
+
+    Ground-relative, the whole set moves together. MEASURED at each step, page → vivid:
+
+        55%   4.55  4.42  4.33  4.11  3.63     ≈ where the flat role sat
+        50%   3.85  3.77  3.72  3.56  3.21     the last step clearing 3:1 everywhere
+        45%   3.31  3.23  3.21  3.08  2.82
+        40%   2.83  2.77  2.76  2.67  2.49     ← shipped
+        35%   2.45  2.41  2.39  2.33  2.18
+
+    ⚠ 40% IS BELOW THE 3:1 LARGE-TEXT FLOOR AND THAT IS DELIBERATE. This is the one place in the
+    deck where the contrast that matters is not ink-against-ground but LIT-against-DIMMED: the whole
+    mechanism exists to make one row stand out, and a dimmed row held at the reading floor does not
+    dim enough to do that. The lit row is the subject and stays at full ink; these rows are context
+    a viewer glances at, not text they read from the back of the room. Held to the floor, `1|2|3` is
+    an equation with a slightly darker line in it.
+
+    The number is a judgement and the table is here so the next one is too — not a derivation.
+
+    The INK is the ground's own, not --deck-fg: on a toned panel those differ, and this is the same
+    pair the mermaid edge label mutes against. The variable's name is mermaid's by history; what it
+    carries is "the ground here and the ink that goes on it".
+  */
+  color: color-mix(
+    in oklab,
+    var(--deck-mermaid-label-ink, var(--deck-fg)) 40%,
+    var(--deck-mermaid-label-bg, var(--deck-bg))
+  );
+}
+/*
+  ★★ CODE HIGHLIGHTING IS STOCK SLIDEV, DELIBERATELY, AND THAT IS A REVERSAL WORTH READING.
+
+  This theme used to own the whole mechanism: a ground-relative mix that flattened the syntax hues
+  on dimmed rows, a neutral band on the lit row, and an accent bar in its gutter — each with a
+  measured justification, all of them removed on 2026-09-06 in favour of `client/styles/code.css`:
+
+      .slidev-code .slidev-code-highlighted { }              <- empty, in stock
+      .slidev-code .slidev-code-dishonored  { opacity: .3 }
+
+  So a lit row now gets NOTHING and the entire signal is that the others recede, which is stock's
+  design. Two things recommend it. It is the same treatment inside a magic move, where the theme's
+  `.line`-keyed rules never reached (magic-move stamps its class on every TOKEN, not on rows) — so
+  the two forms of highlighting stopped disagreeing. And it takes the `.line` machinery with it: the
+  inline-block, the negative-margin gutter reservation, and the `<code> { display: block }` that
+  only existed to stop the inline-blocks accumulating whitespace into a scrollbar.
+
+  ⚠ THE COST IS ON THE RECORD. 0.3 over this deck's warm paper measures 1.47–1.51:1, and the note
+  this block replaced put it plainly: at that ratio, across a room, a dimmed row is not dimmed, it
+  is gone. The deck is sized for a room. Chosen anyway, with the numbers in view — if it reads badly
+  from the back, the fix is a value on the rule below, not a return to the band and the bar.
+*/
+.slidev-layout .slidev-katex-wrapper .mord.highlighted {
+  color: var(--deck-fg);
+}
+
+/* ── …and the lit EQUATION row does NOT get one, which is a finding rather than an omission ───
+   The lit and dimmed rows here separate by 3.25:1 — the same ink-only gap a code block has, and
+   for the same reason it is not quite enough on its own. A code block gets a bar in the gutter.
+   Maths cannot have one, and it is worth saying why so nobody spends the afternoon again:
+
+     · Slidev classes the `.mord` CELL in every column of the aligned environment, so there are two
+       per lit row and neither is the row.
+     · The first column is `col-align-r`, so its cells' left edges move row by row with the width of
+       the word in them — a bar hung there zigzags.
+     · The two columns are ADJACENT. There is no gutter between them: a bar hung off either cell
+       lands through the middle of the equation. Tried, and it drew straight through the word.
+     · The `.vlist > span` row wrapper is a constant width at a constant x, which looks ideal, and is
+       `height: 0` — so a bar there needs an invented height, and the top row's anchor sits above
+       the block where `.katex-display`'s own `overflow-y: hidden` clips it. Rendered 8x66, accent
+       coloured, and invisible.
+     · Anchoring to `.katex-display` fails too: KaTeX marks several of its own spans `position:
+       relative`, so an absolutely positioned marker resolves against one of those, not the block.
+
+   The ink gap is therefore what maths gets, and it is at the floor of what the token ladder allows:
+   --deck-fg-subtle is 4.08:1 on paper and nothing lighter clears 3:1. The specimen slide states
+   this rather than leaving a reader to wonder why the two treatments differ. */
+/* ── …AND THE LIT LINES NEED A SHAPE, NOT JUST A HUE ──────────────────────────────────────────
+   Recolouring the dimmed lines fixed their legibility and broke the thing highlighting is FOR.
+   Measured on this deck's own highlighted-code slide, after that change:
+
+       lit ink   #002a24      dimmed ink  #545252      between them: 1.99:1
+
+   Two inks that close are one lightness with two hues, and hue is the first thing to go from the
+   back of a room — so every line looked the same and nothing read as lit.
+
+   ★★ A TINTED BAND CANNOT FIX IT, and that is a property of this token system rather than a
+   missing value. Measured against the code ground (#f1ede6): --deck-accent-soft scores **1.02:1**,
+   --deck-bg 1.06, --deck-surface-strong 1.09. The derived surface ladder is deliberately quiet —
+   every step sits within about a tenth of the others — so there is no band here that a room can
+   see. The same "paper on paper" finding the Callout tail and the Alert fill both produced.
+
+   So the marker is a BAR IN THE GUTTER: a shape, in the accent, at the start of every lit line.
+   The same answer Timeline's present marker and Carousel's current indicator arrived at — size and
+   shape survive distance, a ten-percent luminance step does not.
+
+   ★ EVERY LINE RESERVES THE GUTTER, lit or not (a transparent border on all of them), so the code
+   does not shift sideways as the highlight moves between clicks. And the lines have to become
+   `inline-block` to carry a border at all — shiki emits them inline, where a border wraps the text
+   rather than the row. `width: 100%` with border-box keeps the row the width of the block. */
+.slidev-layout blockquote {
+  border-left: 4px solid var(--deck-accent);
+  color: var(--deck-fg-muted);
+  padding-left: var(--deck-space-3);
+  margin: var(--deck-space-3) 0;
+}
+
+/* ── Tables ───────────────────────────────────────────────────────────────────────────────── */
+
+.slidev-layout table {
+  width: 100%;
+  border-collapse: collapse;
+  font-size: var(--type-deck-body-sm-size);
+}
+.slidev-layout th,
+.slidev-layout td {
+  text-align: left;
+  padding: var(--deck-space-1) var(--deck-space-2);
+  border-bottom: 1px solid var(--deck-border);
+}
+.slidev-layout th {
+  font-family: var(--font-sans);
+  font-weight: 700;
+  color: var(--deck-fg);
+  border-bottom: 2px solid var(--deck-accent);
+}
+.slidev-layout td {
+  color: var(--deck-fg-muted);
+}
+
+/* ── Card surface ─────────────────────────────────────────────────────────────────────────
+   The deck's one container, and the deck's copy of the web's .forest-card contract: a card is
+   a quiet fill one step AWAY from the slide ground — lighter on light, lighter again on dark —
+   never a shadow. Anything nested inside it picks up the concentric corner automatically.
+
+   ── THE EDGE IS THE CARD'S OWN INK, AND IT USED TO BE --deck-border ──────────────────────
+   That token is derived from the SLIDE's bg/fg, so a card sitting on anything other than the slide
+   ground drew an edge computed for a ground it is not on: measured on the warm panel, 1.07:1, which
+   is no edge. `currentColor` follows whatever ink the card inherited and holds 1.42–1.91 on every
+   fill a card can take. It also gave the four named backgrounds an edge they did not have — they
+   set `border-color: transparent` on the grounds that the fill was the separation, which is true of
+   vivid (1.74:1 off the slide ground) and false of accent (1.13) and neutral (1.09), and flatly
+   wrong for `accent` on a dark slide, where the fill IS --deck-bg and the card disappeared.
+
+   `border` picks the weight, and `none` is the DEFAULT: a card is a fill, and the edge is a thing
+   an author asks for. `hairline` is 1px at 20% (measured 1.42–1.91 against the fills a card can
+   take), `strong` is 4px at 40% (2.12–2.50 light, 2.27–3.59 dark). At 4px it is a frame rather than
+   an outline, which is the point — the two weights are different instruments, not two settings of
+   one. The 1px transparent border is declared on every card so switching to `hairline` costs no
+   reflow; only `strong` changes the box, by 3px a side.
+
+   ⚠ TWO BACKGROUNDS HAVE NOTHING ELSE. `transparent` at `border: none` is a box with no fill and
+   no edge — legitimate (a padded, aligned cell in a grid) but it takes both props to say, so it is
+   never an accident. `surface` sits 1.12:1 off the slide ground, a separation you can see on a
+   screen and can lose in a room, so a surface card that has to read as a tile takes the hairline. */
+.slidev-layout .deck-card {
+  background: var(--deck-surface);
+  border: 1px solid transparent;
+  border-radius: var(--deck-radius-card);
+  padding: var(--deck-card-pad);
+}
+.slidev-layout .deck-card.is-border-hairline {
+  border-color: color-mix(in oklab, currentColor 20%, transparent);
+}
+.slidev-layout .deck-card.is-border-strong {
+  border-width: 4px;
+  border-color: color-mix(in oklab, currentColor 40%, transparent);
+}
+.slidev-layout .deck-card > :last-child {
+  margin-bottom: 0;
+}
+.slidev-layout .deck-card :where(.deck-card, pre, img, figure > img) {
+  border-radius: var(--deck-radius-nested);
+}
+.slidev-layout .deck-card .deck-card :where(.deck-card, pre, img) {
+  border-radius: var(--deck-radius-nested-2);
+}
+/* The transparent card — the container that claims no ground at all. It borrows whatever it lands
+   on, and takes only the fill away: the edge above is already the card's own ink, which is the same
+   reasoning BadgeStrip's `outline` reads --deck-ink-<name> rather than a pinned half. It is the one
+   background where `border: none` leaves nothing at all, which is a legitimate thing to ask for
+   (a padded, aligned cell in a grid) and never an accident, because it takes two props to say. */
+.slidev-layout .deck-card.is-transparent {
+  background: none;
+}
+
+/* A card on a named background — the one that carries a claim rather than a container. The
+   fills are the FOLLOWING tokens, so the register picks the half; `dark` on the card adds
+   `.deck-dark`, which re-declares them to the dark half (deck.css). The ink is set once on the
+   card and every text role inside inherits it: a token pair is fine on its own and still fails
+   when a heading keeps reading the page's --deck-fg on a fill that is not the page. */
+.slidev-layout .deck-card.bg-warm { background: var(--deck-bg-warm); color: var(--deck-on-bg-warm); }
+.slidev-layout .deck-card.bg-accent { background: var(--deck-bg-accent); color: var(--deck-on-bg-accent); }
+.slidev-layout .deck-card.bg-vivid { background: var(--deck-bg-vivid); color: var(--deck-on-bg-vivid); }
+.slidev-layout .deck-card.bg-neutral { background: var(--deck-bg-neutral); color: var(--deck-on-bg-neutral); }
+/*
+  ★★ EVERY TEXT TIER ON A NAMED BACKGROUND READS THE PAIR'S INK, WHATEVER SURFACE IT IS. This was
+  scoped to `.deck-card.bg-*` and so reached exactly one of the four surfaces that wear these
+  classes. The others were wrong and only LOOKED right: a heading carries a hard `color:
+  var(--deck-fg)` at (0,1,1) from the type rules above, which beats inheriting the pair's ink, so
+  the h1 on a warm panel painted neutral-900 near-black while its own paragraphs painted warm-950
+  brown. Measured on the specimen's full-field warm band — h1 rgb(0.096 0.088 0.090) against a band
+  ink of rgb(0.249 0.144 0.117). It hid on the DARK half of every pair, where --deck-fg is
+  neutral-0 and the pair's ink is neutral-0 too: right by coincidence, not by rule.
+
+  Keyed on the background classes rather than on any component, so a card, a split panel, a stack
+  band, a full-field band and a `default` slide on a colour all behave the same, and the next
+  surface to take a named background inherits the behaviour instead of having to remember it.
+*/
+:is(.slidev-layout, .slidev-layout *):is(.bg-warm, .bg-accent, .bg-vivid, .bg-neutral) :where(h1, h2, h3, h4, h5, h6, strong, b, a),
+:is(.slidev-layout, .slidev-layout *):is(.bg-warm, .bg-accent, .bg-vivid, .bg-neutral) > .deck-eyebrow {
+  color: inherit;
+}
+/* ⚠ `li` IS NOT IN THIS SET, and it was for one commit. `opacity` on the item applies to its
+   ::before as well — a child cannot opt out of an ancestor's alpha — so dimming list text to 0.85
+   dimmed the bullet with it and dropped the vivid pairing from 3.55 to 2.86, under the 3:1 floor.
+   The audit caught it on the specimen's own vivid slide. A list item reads at full ink instead,
+   which is right anyway: a list here is a set of short statements, not running prose. */
+:is(.slidev-layout, .slidev-layout *):is(.bg-warm, .bg-accent, .bg-vivid, .bg-neutral) :where(p, .deck-caption) {
+  color: inherit;
+}
+/*
+  ⚠ THE 0.85 IS A CARD IDIOM AND STAYS ON THE CARD. Generalising it to every named background — one
+  commit — dimmed a paragraph that had stated its own colour on purpose: the Ink specimen draws each
+  role as a `p` with an inline `color`, and an inline colour survives `color: inherit` but nothing
+  survives an ancestor's alpha. --deck-fg-subtle on the accent panel's dark half fell from its own
+  value to #636767 and scored 2.70:1, under the 3:1 floor. The audit named the slide.
+
+  A claim card sits its body copy back from its heading because the card is one short statement. A
+  panel, a band or a full-field slide is a page, and its paragraphs are the page's body — they read
+  at full ink like every other slide's.
+*/
+.slidev-layout :is(.deck-card.bg-warm, .deck-card.bg-accent, .deck-card.bg-vivid, .deck-card.bg-neutral) :where(p, .deck-caption) {
+  opacity: 0.85;
+}
+
+/* ── Own-ground components — a Card on a named background ──────────────────────────────────────────────
+   An own-ground component establishes its OWN fill/ink pair rather than reading the page's, and a
+   Card on a named background is the last one: it paints --deck-bg-<name> with --deck-on-bg-<name>.
+   The ink is set once on the component's root, so any descendant that plainly INHERITS colour reads
+   correctly for free. The
+   element rules above this comment do not inherit: `strong`/`b`/`a`/headings/`.deck-caption`/
+   `.deck-note` all carry HARD colours at (0,2,0), which beat inheritance outright regardless of what
+   ground they sit on or how deep they are nested.
+
+   ⚠ THE TWO COMPONENTS THIS WAS WRITTEN FOR ARE BOTH GONE — Chip, whose `tone` picked a saturated
+   fill, and Callout, which painted its own paper. The measurements that produced the rule are kept
+   because they are the evidence for it and it still applies: `<Chip>` at its default tone containing
+   `**12%**` rendered the `<strong>` at 1.00:1 (--deck-accent text on a fill of the exact same
+   value), and `<Card variant="accent"><Callout>…</Callout></Card>` rendered white body copy on
+   Callout's own near-white paper at ~1.02:1. The second one is why the Card rules above exist.
+
+   Fixed HERE, in base.css, rather than in each component's own scoped `<style>`, for two reasons:
+
+   1. A Vue SFC's scoped CSS and this global stylesheet land in the SAME (0,2,0) specificity band
+      for a single-class selector, and which one wins a tie then depends on stylesheet injection
+      order — unpredictable across dev and a production build. Landing the override in the same
+      file as the rules it overrides turns that into a plain textual "declared later wins".
+   2. It also has to beat the NAMED-BACKGROUND CARD rule directly above (`:where(p, .deck-caption)`), which
+      is a plain descendant selector with NO exemption for a nested component that establishes its
+      own ground — so it wins regardless of how deep `.deck-chip`/`.deck-callout` is nested unless
+      something here specifically out-ranks or out-orders it. Both rules below tie that rule's
+      (0,2,0) specificity and are declared AFTER it, so the tie-break favours the component's own
+      ground no matter how deeply it's nested inside a named-background card.
+
+   `currentColor` rather than a specific token, deliberately: it resolves to whatever ink the
+   component actually set — Chip's per-tone ink, Callout's fixed `--deck-fg` — with ONE rule
+   instead of one per tone, and it keeps working if a tone is ever added or renamed. `opacity: 1`
+   is explicit rather than left to inherit the named-background card rule's 0.85 above: both components'
+   own pairs are already independently measured against the body-text floor (see
+   test/frontmatter.static.test.ts's "chip pairs clear the contrast floor" suite), and diluting
+   that with an unrelated opacity would spend back margin the fix just put in.
+
+   The next component that establishes its own ground (rather than reading the page's) needs the
+   same shape of rule, with its own root class beside `.deck-callout`. (`.deck-chip` was the other one until Chip
+   was retired — its tones live on as BadgeStrip's and IconTile's.) */
+/* List markers need the SAME treatment but were missed the first time round: `ul > li::before`
+   (the bullet disc) and `li ul > li::before` (its nested tier) paint through `background`, not
+   `color`, so adding them to the `:where(...)` list above would do nothing — `color: currentColor`
+   cannot reach a `background` declaration. Measured: `<Chip><ul><li>…</li></ul></Chip>` at the
+   default tone (`forest`) painted its bullet in `--deck-accent` on a `--deck-bg-vivid-dark` fill of
+   the identical value, 1.00:1 — the original Critical, unchanged, for markup a demo slide never
+   exercised. `.deck-callout` gets the same fix for the same reason a component with its own
+   ground always does (see the comment above), even though Callout's own ground/ink pair was never
+   independently reachable-broken for a marker the way Chip's tone-fill was — no configuration
+   pairs `--deck-accent` against a Callout ground dark enough to fail 3:1.
+
+   The nested tier stays QUIETER on purpose — `.slidev-layout li ul > li::before` above steps down
+   to `--deck-fg-subtle` rather than repeating the accent, and that hierarchy is worth keeping
+   rather than flattening both tiers to the same full-strength `currentColor`. `opacity: 0.6` is a
+   measured choice, not a guess: blending each own-ground pair's ink over its own fill at candidate
+   opacities and re-running contrast() against WCAG's 3:1 floor for a non-text/graphical object
+   (not the 4.5:1 body-text floor the rules above target — a bullet is UI chrome, not a sentence)
+   put the worst of the six pairs measured at the time at 3.37:1 at 0.6, clear of the floor — and
+   that worst pair was the forest-700 fill, the SAME one Critical 1's text repro used, not the bark
+   step (a first, uncomputed guess would have picked wrong: bark measures a comfortable 3.63:1 at
+   0.6). 0.5 was tried first and rejected — it drops forest-700 to 2.82:1 and the peach step to
+   2.76:1, both under the floor. (Those were the six poetic CHIP names, which no longer exist; the
+   numbers are kept because they are the measurement this 0.6 rests on, and the fills they name are
+   still in the table as `vivid-dark`, `warm-dark` and `warm-light`.)
+
+   ★ fix round 1, CRITICAL 1 re-measured this once the accent Card joined `.deck-own-ground`
+   (below). That card painted `--deck-accent` with `--deck-on-accent`: light forest-700 / #ffffff,
+   3.37:1 at 0.6, and dark forest-300 / forest-950, 3.32:1.
+
+   ★★ RE-MEASURED AGAIN, ALL EIGHT, when that card became `background` × `dark` and started reading
+   the named-backgrounds table instead. Neither of the two numbers above survives the move, and
+   assuming they did was wrong twice over: the fills are now the table's, so five of the eight
+   halves had never been measured here at all, and the ink is `--deck-on-bg-<name>` — neutral-0
+   (#FEFBFC), not the #ffffff `--deck-on-accent` was. Blending each half's ink over its own fill,
+   marker at 0.6 and body at 0.85:
+
+     warm-light     warm-200  / warm-950    3.51 · 6.91      accent-light  forest-100 / forest-950  4.01 · 8.61
+     warm-dark      warm-700  / neutral-0   3.57 · 5.44      accent-dark   forest-950 / neutral-0   6.20 · 11.20
+     vivid-light    forest-300/ forest-950  3.32 · 6.11      neutral-light neutral-100/ neutral-900 4.49 · 10.33
+     vivid-dark     forest-700/ neutral-0   3.31 · 5.02      neutral-dark  neutral-800/ neutral-0   6.21 · 10.94
+
+   Every half clears both floors, and the true worst case is vivid-dark at 3.31:1 — not the 3.32
+   the old note named, and not the 3.37 it called the worst, which only reproduces with the retired
+   pure-white ink. 0.85 bottoms out on the same half at 5.02:1 against the 4.5 body floor.
+
+   The top-tier bullet/marker rules below need no equivalent `opacity: 1` guard: `opacity` doesn't
+   inherit, and nothing else in this file sets it on `li::before`/`li::marker`, so browser-default
+   full strength is what they get without asking.
+
+   Specificity verified rather than assumed, because `li ul > li::before` carries one more element
+   than `ul > li::before` does: `.slidev-layout .deck-own-ground ul > li::before` is (0,2,3) against
+   the base rule's (0,1,3); `.slidev-layout .deck-own-ground li ul > li::before` is (0,2,4) against
+   (0,1,4). Both win outright on specificity, unlike the text rules above — no reliance on source
+   order.
+
+   ★★ fix round 1, CRITICAL 1 — this used to be `.deck-chip ul > li::before, .deck-callout ul >
+   li::before` (and the two rules below it, same shape): an enumerated pair, one selector per
+   component, exactly the thing "the next component that establishes its own ground needs the same
+   rule" (this file's own words, two paragraphs up) warned would need REMEMBERING. It did not get
+   remembered: the accent Card (today `.deck-card.bg-*`, "A card on a named background" above)
+   established its own ground exactly like Chip and Callout did — `background: var(--deck-accent)`
+   — and was never added here. A plain
+   markdown bullet list written directly inside the accent Card (a documented API, used
+   three times in apps/deck-template) painted its bullet in the GLOBAL `ul > li::before` rule's
+   `background: var(--deck-accent)` — the exact same value as its own ground. 1.00:1, invisible, in
+   both registers, and scripts/deckAudit.ts's rendered-contrast sweep could not see it either: its
+   collector only ever scored elements with a direct text-node child, and a `::before`/`::marker`
+   pseudo-element is neither an element nor a text node (fixed separately, see deckAudit.ts's own
+   comment on `PSEUDO_SELECTORS`).
+
+   Fixed HERE, once, by construction rather than by memory: `.deck-own-ground` is a plain marker
+   class with no styling of its own, added to the ROOT of every component that paints its own
+   fill/ink pair (then Chip.vue and Callout.vue; today Card.vue on a named background) instead of
+   reading the page's.
+   The three rules below key off that ONE class, so the next own-ground component only has to add
+   the class to its root — nothing here has to change, and nothing here can be forgotten to
+   change. */
+/* ⚠ `:is(.slidev-layout.deck-own-ground, .slidev-layout .deck-own-ground)`, NOT the descendant
+   alone. Every own-ground component so far has been a box INSIDE a slide, so a plain descendant
+   selector reached all of them and nobody noticed it could not reach a LAYOUT that establishes its
+   own ground — default.vue on a named `background` puts the class on `.slidev-layout` itself, which
+   is the element, not a descendant of it. Measured before this line was widened: a bullet on a
+   `background: vivid` slide painted --deck-accent, forest-300 on a forest-700 field. It passed the
+   audit at 3.55:1 and was still the wrong colour — the one green mark on a slide whose ink is
+   white — which is why the specimen draws a list on every one of those five slides. */
+:is(.slidev-layout.deck-own-ground, .slidev-layout .deck-own-ground) ul > li::before {
+  background: currentColor;
+}
+/*
+  ★★ EXCEPT ON A NAMED BACKGROUND, WHERE THE MARK TAKES THAT NAME'S OWN FAMILY. `currentColor` is
+  the safe answer for an own-ground surface whose fill is arbitrary — a solid Alert paints a status
+  colour, and a dot in some other hue on it would say the wrong thing. A NAMED background is not
+  arbitrary: the engine publishes a mark for each one, `--deck-bg-<name>-mark`, which is the
+  liveliest step of that family still clearing the 3:1 a graphical object is held to against the
+  fill it lands on. Orange on peach and on bark, the vivid green on both accent fields, mint on the
+  dark vivid one. See PANEL in scripts/deck.ts for how each was chosen and what it measures.
+
+  One rule per name and no register branch: the token is re-declared under `.deck-dark`, so a panel
+  carrying that class picks up its own half without this file knowing which register it is in.
+
+  ★ WHY NOT --deck-accent EVERYWHERE, which was the first attempt. It measures fine on all eight
+  halves, 3.55 worst. It also puts a forest dot on a peach panel and on a grey one, which is a
+  second hue on a slide that had already chosen one. The deck's own ground keeps the accent, because
+  there the accent IS the slide's colour.
+*/
+/* A mermaid edge label knocks its own line out, so its backing takes whatever ground it is over —
+   the page by default (--deck-bg, already per-register), or the named fill when it is on one. Read
+   inside the SVG by setup/mermaid-renderer.ts; a custom property is what carries across that
+   boundary, since the diagram cannot see the class its container wears. */
+:is(.slidev-layout, .slidev-layout *).bg-warm { --deck-mermaid-label-bg: var(--deck-bg-warm); --deck-mermaid-label-ink: var(--deck-ink-warm); }
+:is(.slidev-layout, .slidev-layout *).bg-accent { --deck-mermaid-label-bg: var(--deck-bg-accent); --deck-mermaid-label-ink: var(--deck-ink-accent); }
+:is(.slidev-layout, .slidev-layout *).bg-vivid { --deck-mermaid-label-bg: var(--deck-bg-vivid); --deck-mermaid-label-ink: var(--deck-ink-vivid); }
+:is(.slidev-layout, .slidev-layout *).bg-neutral { --deck-mermaid-label-bg: var(--deck-bg-neutral); --deck-mermaid-label-ink: var(--deck-ink-neutral); }
+
+:is(.slidev-layout, .slidev-layout *).bg-warm ul > li::before { background: var(--deck-bg-warm-mark); }
+:is(.slidev-layout, .slidev-layout *).bg-accent ul > li::before { background: var(--deck-bg-accent-mark); }
+:is(.slidev-layout, .slidev-layout *).bg-vivid ul > li::before { background: var(--deck-bg-vivid-mark); }
+:is(.slidev-layout, .slidev-layout *).bg-neutral ul > li::before { background: var(--deck-bg-neutral-mark); }
+
+/*
+  ★★ AND THE CHIP'S INK FOLLOWS THE SAME GROUND, which is what makes the wash above land in the
+  family rather than beside it. --deck-accent is the deck's green and is right on the page; on a
+  named background it is a third family in a word that already has two.
+
+  IT IS THE FAMILY'S INK, NOT ITS MARK, AND THAT IS MEASURED. The mark tone carries the bullets one
+  rule up, and bullets are a GRAPHICAL mark held to 3:1. Code is text and owes 4.5:1, which the mark
+  misses on two of the four:
+
+      family    ground     mark      mark:ground     ink       ink:ground
+      warm      #FFD6A6    #A75633       3.83 ✗      #44231C      10.26 ✓
+      accent    #CEF5DD    #046C4C       5.45 ✓      #002A24      13.07 ✓
+      vivid     #3BD996    #075640       4.78 ✓      #002A24       8.51 ✓
+      neutral   #F3EFF0    #757273       4.18 ✗      #191617      15.76 ✓
+
+  So the chip takes --deck-ink-<name>, the same ink the prose around it takes. It stops being a
+  different COLOUR from its sentence and stays a different THING: mono, boxed, edged. The fill and
+  the border derive from this colour, so naming the ink moves all three.
+*/
+:is(.slidev-layout, .slidev-layout *).bg-warm :not(pre) > code:not(.shiki) { color: var(--deck-ink-warm); }
+:is(.slidev-layout, .slidev-layout *).bg-accent :not(pre) > code:not(.shiki) { color: var(--deck-ink-accent); }
+:is(.slidev-layout, .slidev-layout *).bg-vivid :not(pre) > code:not(.shiki) { color: var(--deck-ink-vivid); }
+:is(.slidev-layout, .slidev-layout *).bg-neutral :not(pre) > code:not(.shiki) { color: var(--deck-ink-neutral); }
+:is(.slidev-layout.deck-own-ground, .slidev-layout .deck-own-ground) ol > li::marker {
+  color: currentColor;
+}
+:is(.slidev-layout.deck-own-ground, .slidev-layout .deck-own-ground) li ul > li::before {
+  background: currentColor;
+  opacity: 0.6;
+}
+
+/* ── The notch — ONE cut, worn by every figure that seats the running mark ────────────────
+   task-15-brief.md built this shape; task-18-brief.md moved it here. It used to live inside
+   split.vue's scoped <style>, which was correct while split was the only layout with a panel to
+   bite out of. stack.vue's band is the second, cutting the same corner around the same mark, and a
+   five-layer composited mask is not a thing this theme can afford two copies of — the geometry is
+   the DESIGN, not one layout's implementation detail.
+
+   Each layout still owns what is genuinely its own: whether there is a cut at all (../notch.js's
+   hasNotch(), which both call), which corner is the outer one (`data-notch-corner`, bound in the
+   template because it flips with split's `side`), the margin that raises the figure to meet the
+   mark, and the band a text-holding panel reserves from its own content.
+
+   ★★ NOT A STRETCHED MASK — the requirement that decides the implementation. Jose: "i mean, not
+   just stretch a fixed mask". The wrong build authors one shape and scales it to whatever size the
+   figure happens to be, so a 48px corner becomes an ellipse on a narrow panel and flattens on a
+   wide one; across split's six ratios that is six different corner treatments where the design says
+   there is one. So the mask is COMPOSED from gradients in ABSOLUTE units and composited: gradient
+   geometry sized in px does not stretch with its box, and only the figure's own width and height
+   differ between ratios. Nothing here is authored at an aspect ratio, so nothing here has one to
+   distort — there is no viewBox, no `mask-size: 100% 100%` on a shape, and no reused data URI.
+   Measured rather than asserted, at both extremes of the ratio ladder — see task-15-report.md, and
+   task-18-report.md for the same measurement repeated after this move.
+
+   FIVE LAYERS, and what each one is. Written top-first (CSS layer order), composited bottom-up:
+
+     FULL     the whole figure                                         subtract  (everything below)
+     RETURN-A the convex fillet where the cut meets the figure's TOP edge         add
+     RETURN-B the convex fillet where the cut meets the figure's OUTER edge       add
+     RECT     the cut itself: occupant + one gap, anchored in the corner subtract (the sliver below)
+     SLIVER   the concave corner's own curve, kept OUT of the cut                 add
+
+   So the removed region is (RECT − SLIVER) ∪ RETURN-A ∪ RETURN-B, and the figure is everything
+   else. The three curved layers are the SAME shape — a square minus a disc of radius --notch-r
+   pinned to one of its corners — placed three times. That single shape is what produces the
+   S-curve: rounding the figure's two convex corners takes material away, rounding the cut's concave
+   corner gives it back, and all three arcs share one radius.
+
+   Each curved layer overlaps its neighbour by --notch-overlap. Mask layers composite with
+   source-over, so two ANTIALIASED edges that merely abut sum to ~0.75 alpha and leave a hairline
+   seam; a 1px overlap removes the seam without moving any curve (the overlap extends into territory
+   the neighbouring layer already covers). The 0.5px feather on each colour stop is the other half of
+   the same concern: a hard gradient stop is rasterised without antialiasing and gives a stepped arc.
+
+   ⚠ MASKING CLIPS, IT DOES NOT REFLOW. The mask handles the SHAPE; the SPACE is each layout's own
+   problem, because only the layout knows whether its figure holds a photograph (clipping it IS the
+   effect) or words (which would silently lose a corner). See split.vue's `.is-panel.has-notch` and
+   stack.vue's `.stack-band.is-panel`. */
+.deck-notch {
+  /*
+    ★ DERIVED FROM THE OCCUPANT, never pinned beside it — the property that makes this a system
+    feature rather than a shape someone drew once. The occupant's box is the input and the cut is
+    that box plus one gap, so changing the mark (--deck-chrome-mark, scripts/deck.ts) moves both
+    with no second edit here, and a slide that widens the occupant — a forest+partner pair
+    (`partner:`), an image, a content block — widens the cut by the same amount with no code change
+    at all.
+
+    The default is written as var()'s FALLBACK rather than as a declaration in deck.css: a custom
+    property resolves once, where it is declared, so anything derived from an occupant declared at
+    :root would keep the :root answer even on a slide that overrode the occupant further down.
+    Undeclared, the override reaches every reader — this rule and slide-top.vue's own mark box.
+
+    --notch-r is clamped to half the cut on each axis. At the shipped numbers (108px cut, 48px
+    radius) the straight segments are 12px and the profile is very nearly a pure S; a SMALLER
+    occupant would otherwise ask for arcs that overlap each other, and min() degrades that to a
+    clean S-curve instead of a self-intersecting shape.
+  */
+  --notch-w: calc(var(--deck-notch-occupant-w, var(--deck-chrome-mark)) + var(--deck-notch-gap));
+  --notch-h: calc(var(--deck-notch-occupant-h, var(--deck-chrome-mark)) + var(--deck-notch-gap));
+  --notch-r: min(var(--deck-notch-radius), calc(var(--notch-w) / 2), calc(var(--notch-h) / 2));
+  /*
+    ★★ THE CUT IS A CLIP, NOT A MASK — and that is a correctness decision, not a preference.
+
+    This was five mask layers composited `subtract, add, add, subtract, add`. It drew the right
+    shape and it leaked: a hairline of panel painted out in the ground, tracing the figure's edges
+    and the cut rectangle's inner corner. A mask is ALPHA, so every layer rasterises independently
+    and any boundary that lands on a fractional device pixel resolves to partial coverage —
+    `subtract` then turns that into `1 - partial`, a few percent of panel left painted where the
+    cut should be empty. It is a colour artifact, so no geometric gate could see it, and it moved
+    with the window size, which made it read like a scaling bug.
+
+    Four attempts to patch it boundary-by-boundary all failed, and each is recorded in the history
+    rather than quietly dropped: widening the layer overlap, bleeding the cut layers past the box,
+    bleeding the base layer too, and promoting the element to its own compositing layer. Promotion
+    cleared the outer edges and left the inner corner, which is the tell — there was no single bad
+    boundary, the arithmetic itself was wrong for the job.
+
+    A clip is GEOMETRY. One path, rasterised once, antialiased once, with no compositing arithmetic
+    to leave a residue behind. That removes the whole class of defect rather than the instances of
+    it, which is why this is the shape of the fix.
+
+    VERIFIED NUMERICALLY, not by eye — every earlier visual judgement in this investigation was
+    wrong at least once. clip-path participates in hit-testing, so the rendered region can be
+    sampled directly: 3,481 points per corner, on both corners, checked against an independent
+    analytic model of the intended profile. Zero mismatches. The check was proved able to fail
+    first — shrinking the inner radius from 48 to 30 produced 34 mismatches.
+
+    The profile, corner-local, is exactly what the mask drew: a convex return of radius r meeting
+    the top edge at (w + r, 0), a straight run down x = w, a concave quarter-circle of radius r
+    centred on (w - r, h - r), and the mirrored return meeting the side edge at (0, h + r). The
+    two corner variants below differ only by mirroring x and flipping every sweep.
+  */
+}
+/*
+  WHICH CORNER — always the figure's OUTER one: on a split, the corner against the slide edge and
+  away from the text; on a stack's full-width band, the corner the mark is already in. That is where
+  the mark can sit without crowding the content it shares the slide with.
+
+  The cut is anchored to the FIGURE, not to the slide: every offset above is measured from the
+  figure's own edge, so it travels with the panel across split's six ratios (from half the row down
+  to a quarter of it) and across stack's band heights with no per-ratio rule, and would still be
+  correct if a seventh were added.
+
+  Three custom properties carry the corner, because a corner is not just a side: --notch-edge is
+  which physical edge every offset is measured from, and the two *-x values move each disc's centre
+  to the corresponding corner of its own tile. Physical (right/left), never logical: which side is
+  "outer" flips with split's `side`, never with writing direction.
+
+  RIGHT is the default rather than a required attribute — it is where the running mark sits on every
+  slide that has not mirrored — so a figure that forgets the attribute cuts a real corner rather
+  than resolving --notch-edge to nothing and invalidating the whole mask declaration (which renders
+  as an UNCUT figure: a silent failure, the exact shape this project keeps finding).
+*/
+.deck-notch,
+.deck-notch[data-notch-corner='right'] {
+  --notch-edge: right;
+  clip-path: shape(
+    from calc(100% - var(--notch-w) - var(--notch-r)) 0,
+    hline to var(--deck-radius-card),
+    arc to 0 var(--deck-radius-card) of var(--deck-radius-card) ccw,
+    vline to calc(100% - var(--deck-radius-card)),
+    arc to var(--deck-radius-card) 100% of var(--deck-radius-card) ccw,
+    hline to calc(100% - var(--deck-radius-card)),
+    arc to 100% calc(100% - var(--deck-radius-card)) of var(--deck-radius-card) ccw,
+    vline to calc(var(--notch-h) + var(--notch-r)),
+    arc to calc(100% - var(--notch-r)) var(--notch-h) of var(--notch-r) ccw,
+    hline to calc(100% - var(--notch-w) + var(--notch-r)),
+    arc to calc(100% - var(--notch-w)) calc(var(--notch-h) - var(--notch-r)) of var(--notch-r) cw,
+    vline to var(--notch-r),
+    arc to calc(100% - var(--notch-w) - var(--notch-r)) 0 of var(--notch-r) ccw,
+    close);
+}
+.deck-notch[data-notch-corner='left'] {
+  --notch-edge: left;
+  clip-path: shape(
+    from calc(var(--notch-w) + var(--notch-r)) 0,
+    hline to calc(100% - var(--deck-radius-card)),
+    arc to 100% var(--deck-radius-card) of var(--deck-radius-card) cw,
+    vline to calc(100% - var(--deck-radius-card)),
+    arc to calc(100% - var(--deck-radius-card)) 100% of var(--deck-radius-card) cw,
+    hline to var(--deck-radius-card),
+    arc to 0 calc(100% - var(--deck-radius-card)) of var(--deck-radius-card) cw,
+    vline to calc(var(--notch-h) + var(--notch-r)),
+    arc to var(--notch-r) var(--notch-h) of var(--notch-r) cw,
+    hline to calc(var(--notch-w) - var(--notch-r)),
+    arc to var(--notch-w) calc(var(--notch-h) - var(--notch-r)) of var(--notch-r) ccw,
+    vline to var(--notch-r),
+    arc to calc(var(--notch-w) + var(--notch-r)) 0 of var(--notch-r) cw,
+    close);
+}
+
+/* ── Motion ───────────────────────────────────────────────────────────────────────────────
+   ★★ THE DECK CROSS-FADES THROUGH THE VIEW TRANSITIONS API, AND THAT IS A CONTRAST FIX RATHER
+   THAN A FLOURISH. `transition: fade` (what this theme shipped) animates BOTH slides' opacity at
+   once over two absolutely-positioned siblings whose own grounds are painted on the layout INSIDE
+   them, so during the overlap neither is opaque and the page behind shows through. That page is
+   white — #slide-content, #app and body all are — and the leak is the product of the two
+   transparencies: measured stepping off a dark divider, 0.25/0.75 at 115ms of the 240ms fade, so
+   18.8% of pure white across the whole frame, peaking near 25% at the crossover. Invisible cream
+   to cream. A flash on every dark slide, and a strobe when an author pages fast.
+
+   `view-transition` is the fix because the UA default composites the pair CORRECTLY: measured on a
+   live transition, `::view-transition-image-pair(root)` carries `isolation: isolate` and both
+   halves `mix-blend-mode: plus-lighter`, so the two opacities SUM to 1 instead of stacking one
+   over the other. Proved on a throwaway page with a magenta backdrop, which never appeared.
+
+   What the API does not bring is the ladder: it ships 0.25s on its own curve and never reads
+   --slidev-transition-duration. Hence the two rules below. The Vue-transition curves are kept
+   because a slide can still opt back into `fade` from its own frontmatter, and Slidev hard-codes
+   `ease` and `ease-in` there — ease-in is the curve the doctrine bans outright, since it starts
+   slow and reads as unresponsive at exactly the moment the audience is watching the slide change. */
+::view-transition-old(root),
+::view-transition-new(root) {
+  animation-duration: var(--motion-slow);
+  animation-timing-function: var(--motion-ease-out);
+}
+
+/* The global floor in packages/tokens/motion/motion.css cannot reach these: it targets
+   `*, *::before, *::after`, and a view-transition pseudo-element is none of the three. Without
+   this block a reduced-motion viewer gets the full cross-fade, which is the one case the floor
+   exists to prevent. Not `animation: none` — removing the animation would leave the old snapshot
+   painted over the new slide, so the pair still has to run, just imperceptibly. */
+@media (prefers-reduced-motion: reduce) {
+  ::view-transition-old(root),
+  ::view-transition-new(root) {
+    animation-duration: 1ms !important;
+  }
+}
+
+.slidev-vue-transition-enter-active,
+.slidev-vue-transition-leave-active,
+.slidev-page-enter-active,
+.slidev-page-leave-active {
+  transition-timing-function: var(--motion-ease-out) !important;
+}
+
+/* ── Slidev's own chrome: the closed "go to slide" dialog ─────────────────────────────────
+   UPSTREAM BUG, worked around here. Slidev hides #slidev-goto-dialog by parking it at a FIXED
+   offset — `:class="showGotoDialog ? 'top-5' : '-top-20'"` (internals/Goto.vue) — so the closed
+   dialog sits at top:-80px. That hides 80px. The dialog is not 80px tall: it also renders an
+   autocomplete list under `v-if="result.length > 0"`, and in fuse.js 7.x `search('')` returns
+   EVERY item, so with an empty input the list is every slide in the deck. MEASURED on this deck:
+   563px tall, 483px of it hanging into the canvas at opacity 1 with pointer-events auto — which
+   is why it cannot be dismissed. There is nothing to dismiss; it was never open.
+
+   It scales with slide count, so it is invisible on a two-slide demo and unmissable on a real
+   deck, and it is NOT dev-only: play.vue mounts <Controls> under `v-if="!isPrintMode"` with no
+   __DEV__ guard, so a built deck ships it too. (Slidev here is 0.50.0; upstream is 52.x.)
+
+   Keyed off the class Slidev itself toggles, so the dialog still opens normally. */
+#slidev-goto-dialog:not(.top-5) {
+  visibility: hidden;
+  pointer-events: none;
+}
+
+/* v-click reveals: a fade at the near-element bucket, no travel. */
+.slidev-vclick-target {
+  transition:
+    opacity var(--motion-base) var(--motion-ease-out),
+    color var(--motion-base) var(--motion-ease-out);
+}
+
+/* ── Reduced motion ───────────────────────────────────────────────────────────────────────
+   Nothing here. The system-wide floor arrives with the ladder, in
+   @humanforest/tokens/motion/motion.css (imported by styles/index.ts): it targets
+   `*, *::before, *::after`, which already covers every slide.
+
+   This file used to carry its own copy, scoped to `.slidev-layout *` and `[class*='slidev-']`.
+   That copy was not merely redundant, it was NARROWER — its allow-list omitted `box-shadow`, so a
+   deck honouring reduced motion also lost shadow fades the product keeps. Deleting it is the point
+   of importing the real thing. */
+
+/*
+  ── THE CHART TOOLTIP, THEMED AT THE ROOT BECAUSE IT IS MOUNTED ON THE BODY ────────────────────
+
+  ★★ A TOOLTIP INSIDE A SLIDE IS POSITIONED WRONG, and the error grows with distance. Slidev draws
+  the 1920x1080 canvas by SCALING it — `matrix(0.579687, …)` at the size this deck was measured at —
+  and Unovis positions its panel by writing screen pixels into `left`/`bottom`. Inside the scaled
+  slide those pixels are then scaled AGAIN: measured on the Grouped bars slide, a pointer at x 700
+  put the panel at x 264, several columns to its left. Near the origin it looks almost right, which
+  is what makes it a late discovery rather than an obvious one.
+
+  `document.body` is the only ancestor the slide's transform does not reach, which is why the
+  product mounts its tooltip there too — for a different reason (clamping inside a short chart), and
+  arriving at the same place.
+
+  ⚠ THE COST, STATED: a panel in the body cannot inherit a slide's register, so a tooltip on a
+  `deck-dark` slide is drawn in the light one. That is the right trade here — it reads as an overlay
+  above the deck rather than a surface of it, and the alternative is a panel that points at the
+  wrong column.
+*/
+/*
+  ★ AND IT IS SCALED BY HAND, because leaving the slide's transform also left its SIZE behind. The
+  panel is themed at the deck's own rung — 36px type, room-scale padding — which is correct inside a
+  1920x1080 canvas and far too large sitting in the body beside a canvas drawn at 0.58. Slidev
+  publishes the factor it is using as `--slidev-slide-scale`, so the panel takes the same one and
+  ends up the size it would have been had it stayed inside the slide.
+
+  ★★ THE SCALE IS `zoom`, ON THE CONTENT, AND `transform` IS THE BUG IT REPLACES. Unovis places the
+  panel from `this.element.offsetWidth/offsetHeight` — it subtracts the panel's own HEIGHT to sit it
+  above the pointer, halves its WIDTH to centre it, and clamps both against the viewport. A
+  transform paints a smaller box without changing either measurement, so the library reserved
+  397x204 for a panel that drew 230x118 and placed the difference as empty air: measured on the
+  scatter slide, the panel floated 103px above the pointer — exactly `5 + 12 + 0.42 x 204` — and the
+  clamp fired at x 191 for a box that was never 397 wide.
+
+  `zoom` is laid out rather than painted, so the element's own measurements come back at the size it
+  draws (231x119, both) and the library's arithmetic is right again — including the flip to below
+  the pointer near the top edge, and the clamp. It sits on the CONTENT because zoom on the panel
+  itself would scale the `left`/`top` the library just wrote.
+
+  Radius is the one thing left outside the zoom, on the panel's own box, so it carries the factor by
+  hand or a 24px corner arrives at full size on a panel drawn at 58%.
+
+  Matched on the class Unovis emits rather than on `body > div`, and on the deck's own root so it
+  cannot reach a chart rendered anywhere else.
+*/
+body > [class*='-tooltip'] > * {
+  zoom: var(--slidev-slide-scale, 1);
+}
+
+body > [class*='-tooltip'] {
+
+  /*
+    ★★ DECLARED ON THE PANEL, NOT ON `:root`, AND THAT IS NOT TIDINESS. Unovis injects its own
+    stylesheet at RUNTIME, after this one, and its defaults sit on `:root` too — so a declaration
+    there ties on specificity and loses on order. Measured: the corner came out at Unovis' own 5px
+    while this file asked for 24. Inside the chart the same variables worked, because ChartFrame is
+    a nearer ancestor than `:root` and proximity settles an inherited value; moving the panel to the
+    body took that advantage away. Set on the element itself, nothing inherited can reach it.
+  */
+  /*
+    ★ THE FADE WAS OFF THE LADDER IN BOTH HALVES. Unovis' root sets `transition: opacity` with a
+    300ms default and no curve, so the panel ran the browser's `ease` — the same fault this file
+    already corrects for Slidev's own slide transitions further up. The doctrine names this exact
+    element: `fast` is "small / near elements — tooltips", and every curve in the system is
+    ease-out. The shorthand in Unovis' emotion class is a single class, so declaring the curve here
+    outranks it.
+
+    ⚠ ONE DURATION FOR BOTH DIRECTIONS, where the product's tooltip enters at `fast` and leaves at
+    `instant`. Unovis carries the two states on emotion classes built WITHOUT a label — they render
+    as bare hashes (`css-eec57t`, `css-38lglc`) that move on any version bump — so splitting the
+    two would mean pinning a hash, which is the landmine removed from ScatterChart in e8a893c. The
+    enter bucket is the one an audience sees; the exit runs 60ms long and is not worth that.
+
+    The fade itself survives `prefers-reduced-motion`: the floor's allow-list keeps `opacity`,
+    because this is a colour change rather than travel. It reaches the panel at all only because
+    that floor targets `*` — the deck-local copy this file deleted was scoped to `.slidev-layout *`,
+    which a body-mounted panel is not inside.
+  */
+  --vis-tooltip-transition-duration: var(--motion-fast);
+  transition-timing-function: var(--motion-ease-out);
+
+  /*
+    ★ GLASS, THE SAME AS THE PRODUCT'S. packages/tokens/dataviz/unovis.css themes the product's
+    chart tooltip as `color-mix(… --ui-bg-elevated 80%, transparent)` over `blur(12px)
+    saturate(1.4)`, and this deck does not import that adapter — it only takes dataviz.css for the
+    palette — so the treatment has to be restated here in deck tokens rather than inherited. It was
+    a flat opaque surface until now, which is the one thing that made the panel read as belonging to
+    a different system.
+
+    The blur is free here in a way it is not elsewhere: a tooltip only exists under a live pointer,
+    so it never reaches an export, where a backdrop-filter over a WebGL canvas is the kind of thing
+    that composites differently.
+  */
+  --vis-tooltip-background-color: color-mix(in oklab, var(--deck-surface-strong) 80%, transparent);
+  --vis-tooltip-backdrop-filter: blur(12px) saturate(1.4);
+  --vis-tooltip-border-color: var(--deck-border-strong);
+  --vis-tooltip-text-color: var(--deck-fg);
+  --vis-tooltip-border-radius: calc(var(--deck-radius) * 3 * var(--slidev-slide-scale, 1));
+  --vis-tooltip-padding: 0;
+  --vis-tooltip-title-color: var(--deck-fg);
+  /* The separator is the panel's own edge, restated, so the register override reaches both.
+     It sits inside the zoomed child, so the width divides the scale back out to land on the
+     same device pixel the unzoomed panel border does. */
+  --vis-tooltip-title-border-bottom: calc(1px / var(--slidev-slide-scale, 1)) solid
+    var(--vis-tooltip-border-color);
+  --vis-tooltip-title-font-size: var(--type-deck-label-size);
+  --vis-tooltip-title-font-weight: var(--type-deck-label-weight);
+  --vis-tooltip-title-padding: var(--deck-space-2) var(--deck-space-2) calc(var(--deck-space-2) / 2);
+  --vis-tooltip-title-margin: 0 0 calc(var(--deck-space-2) / 2) 0;
+  --vis-tooltip-title-text-transform: none;
+  --vis-tooltip-label-color: var(--deck-fg-muted);
+  --vis-tooltip-label-font-size: var(--type-deck-caption-size);
+  --vis-tooltip-value-color: var(--deck-fg);
+  --vis-tooltip-value-font-size: var(--type-deck-caption-size);
+  --vis-tooltip-value-font-weight: var(--type-deck-label-weight);
+  /* The product draws an 8px dot beside 14px type; this keeps that ratio against the deck's 36px,
+     which the 8px default did not — it read as a speck. */
+  --vis-tooltip-dot-size: calc(var(--type-deck-caption-size) * 4 / 7);
+  --vis-tooltip-content-gap: calc(var(--deck-space-2) / 2) var(--deck-space-2);
+  --vis-tooltip-content-padding: 0 var(--deck-space-2) var(--deck-space-2);
+}
+
+/*
+  ★★ AND IT FOLLOWS THE SLIDE'S REGISTER, WHICH A BODY-MOUNTED PANEL CANNOT DO ON ITS OWN. The
+  block above notes the cost of mounting here: the tooltip is outside `.slidev-layout`, so a
+  `deck-dark` slide used to be read through a light panel — near-black ink on cream, floating over a
+  forest-950 ground.
+
+  ★ THE VISIBLE SLIDE IS SELECTABLE, which is what makes this CSS rather than a watcher. Slidev
+  mounts every slide and hides all but one with an INLINE `display: none`, so
+  `:not([style*="display: none"])` names the one on screen — measured, 213 hidden and 1 not.
+
+  ⚠ RE-POINTING THE DECK TOKENS, NOT THE --vis-* ONES, and the derived three have to be restated by
+  hand. `--deck-surface-strong`, `--deck-border` and `--deck-border-strong` are color-mix results
+  DECLARED at `:root, .dark, .deck-dark` — a custom property computes where it is declared, so
+  setting `--deck-bg` here alone would leave them at their light values. Same trap deck.css records
+  for a dark card. The mixes below are that file's own, at the same percentages.
+
+  Everything downstream then resolves for free: the `--vis-tooltip-*` declarations above read these
+  on the SAME element, so they take whichever set is in force.
+*/
+body:has(.slidev-page:not([style*="display: none"]) .slidev-layout.deck-dark) > [class*='-tooltip'] {
+  --deck-bg: var(--forest-950);
+  --deck-fg: var(--neutral-0);
+  --deck-fg-muted: var(--neutral-400);
+  --deck-surface-strong: color-mix(in oklab, var(--forest-950), var(--neutral-0) 10%);
+  --deck-border: color-mix(in oklab, var(--forest-950), var(--neutral-0) 14%);
+  --deck-border-strong: color-mix(in oklab, var(--forest-950), var(--neutral-0) 26%);
+}
+
+
+
+/* ── `.deck-bare` — a chart slide stripped to its fills ───────────────────────────────────────
+   A SLIDE CLASS, the same shape as `.deck-pairs`: the slide asks for it and every chart under it
+   follows without knowing the class exists.
+
+   ★★ IT IS HERE RATHER THAN AS A PROP ON FOUR COMPONENTS, and the reason is what it is FOR. This
+   is one specimen slide whose whole subject is whether the palettes re-point on the dark register —
+   a colour test, where a tick label, a row label and a printed total are three text elements
+   competing with the only thing being tested. That is a presentation choice about one slide, not a
+   capability a chart should advertise: `axes: false` on LineChart would be a chart with no scale,
+   which is a worse chart, and every call site would then have to be told not to use it.
+
+   `display: none` rather than `visibility` or opacity, deliberately — the row has to COLLAPSE, or
+   the bars keep a label gutter with nothing in it and the marks stay where the text put them. It
+   also takes these elements out of the audit's reach, which is correct: an element that is not
+   painted is not ink, and scoring a hidden tick against a ground it never touches would be noise.
+
+   Legends, axis titles and the donut's central label are NOT here — those come off through each
+   component's own props (`legend: false`, no `xLabel`, no `centralLabel`), which is where a real
+   switch already exists. Only the three with no prop are swept. */
+/* The axes are NOT here — they come off through `axes: false` on the components themselves, and
+   they have to: Unovis reserves the axis band whether or not it paints, so hiding one in CSS left
+   the plot inset by a tick row and a label column that were no longer drawn. Only the two with no
+   prop are swept. */
+.deck-bare [class*='-central-label'],
+.deck-bare .bars-label,
+.deck-bare .bars-value {
+  display: none;
+}
+
+/* ★★ AND THE BAR TRACK HAS TO BE TOLD ITS WIDTH ONCE THE TEXT IS GONE. `.bars` is
+   `auto minmax(0, 1fr) auto`, so the track is a fraction of whatever width the grid has — and the
+   grid had that width because the label and the value were IN it. Remove both and it shrink-wraps
+   to nothing, `1fr` resolves to 0, and every bar draws at the 2px `min-width` its fill declares.
+   Five vertical ticks down the left margin, which is what the first version of this rule shipped. */
+/* ★★ `.slidev-layout` IS A SPECIFICITY COUNTERWEIGHT, NOT A SCOPE. Bars.vue sets
+   `grid-template-columns` in a SCOPED block, which compiles to `.bars[data-v-…]` — (0,2,0), the
+   same as `.deck-bare .bars`, and the component's stylesheet is injected after this file, so the
+   tie went to the component and the columns never changed. Three class-level selectors settle it.
+   (The `display: none` rules above need no such help: nothing declares `display` on those. */
+.slidev-layout.deck-bare .bars {
+  width: 100%;
+  /* ★★ AND THE COLUMNS HAVE TO BE RE-DECLARED, not just the width. `.bars` is
+     `auto minmax(0, 1fr) auto` and each row is a `subgrid` spanning all three, so the track is the
+     MIDDLE column — middle because the label holds the first. Hide the label and the row has one
+     child left, which lands in column 1: an `auto` track sizing to a bar with no intrinsic width.
+     Measured: `.bars` at its full 1728px with a 1px track, so every bar drew at the 2px `min-width`
+     its fill declares — five vertical ticks down the left margin. One `1fr` column is the fix; the
+     subgrid rows adopt it and the bar is the only thing left to fill it. */
+  grid-template-columns: minmax(0, 1fr);
+}
+
+/* No hover, either. A tooltip is a reading aid, and this slide has nothing to read — the marks
+   carry no labels and no scale, so a panel naming a value would be the only text on the slide and
+   would be describing a chart the slide has deliberately stripped of its numbers. Killed at the
+   POINTER rather than per component: it takes the crosshair with it (which would otherwise draw a
+   rule and two circles over a bare line), and it needs no prop on four components. */
+.deck-bare .deck-chart,
+.deck-bare .bars,
+.deck-bare .deck-track {
+  pointer-events: none;
+}