@humanforest/tokens 0.1.0

package/deck/deck.css

@@ -0,0 +1,515 @@
+/* Forest deck surface — generated by scripts/deck.ts. Do not edit.
+
+   The presentation context's token layer: colour, space and shape for a 1920x1080 slide canvas. The
+   deck TYPE ramp is a separate artefact (type.deck.css, from scripts/type.ts) and the motion ladder is
+   shared with every other surface (motion.css).
+
+   A deck is a real Forest surface — the bold voice at projector scale — but NOT a UTheme context:
+   Nuxt UI components do not render on a slide, so the context tag/manifest/register machinery has
+   nothing to govern there. These roles are how the voice is actually delivered.
+
+   ★ FRAMEWORK-AGNOSTIC. Not one Tailwind at-rule. Slidev compiles through UnoCSS, which has no parser
+   for @theme / @utility / @custom-variant and passes them through silently — one at-rule here would
+   orphan the file with no warning. Plain custom properties only.
+
+   Consumers reference --deck-* and never a raw ramp step, so a slide cannot express an off-brand
+   colour, an off-ladder corner or a hand-picked px. */
+:root {
+  /* ── Spacing ─────────────────────────────────────────────────────────────────────────────
+     --deck-grid is the layout unit (margins, gutters, the safe area). The numbered steps are the
+     CONTENT rhythm, every one a multiple of 4px like the web scale. */
+  --deck-grid: 24px;
+  --deck-space-1:      calc(var(--deck-grid) / 3);                 /* 8px */
+  --deck-space-2:      calc(var(--deck-grid) * 2 / 3);             /* 16px */
+  --deck-space-3:      var(--deck-grid);                           /* 24px */
+  --deck-space-4:      calc(var(--deck-grid) * 4 / 3);             /* 32px */
+  --deck-space-5:      calc(var(--deck-grid) * 5 / 3);             /* 40px */
+  --deck-space-6:      calc(var(--deck-grid) * 2.5);               /* 60px */
+  --deck-space-7:      calc(var(--deck-grid) * 10 / 3);            /* 80px */
+
+  /* ── Insets — text for its MEASURE, media for its FRAME, and two more ────────────────────
+     Text needs a line length and a margin; a photograph has a hard edge and reads as inset too
+     far at the same value a paragraph reads correctly at. Chrome (the running mark, page number,
+     section pill) is a third, uniform value — furniture, not content. Display is a fourth: the
+     beat layouts set one line at 96–128px, and a margin is read relative to the type it frames.
+     Full reasoning above INSET.
+     chrome/media SHARE a value (one grid unit) but mean different things: chrome is a margin from
+     every edge, media is a margin from the left/right edges only.
+     ★ MEDIA'S VERTICAL BOUND, and why it is not one number. A figure's top and bottom follow the
+     NOTCH, together: a notched figure rises to --deck-inset-media on both, because the cut is what
+     keeps the running mark clear and the mark's own corner and the figure's are then the same
+     point; an un-notched one (notch: false, chrome: false, or a media:none second content column)
+     takes --deck-inset-text on both, which is the pre-notch geometry the escape hatch is
+     documented to restore. What it is NOT is 36 on three sides and 90 on the fourth — that was the
+     shipped state on all 86 media figures, and 54px of unexplained bottom-heaviness is not a rule,
+     it is a rule applied to half a box. See split.vue's .split-figure. */
+  --deck-inset-chrome:   calc(var(--deck-grid) * 1.5);             /* 36px   · corner furniture (mark, page number, section pill) — all four edges */
+  --deck-inset-media:    calc(var(--deck-grid) * 1.5);             /* 36px   · figures and illustrations — HORIZONTAL edges only; vertical bound is --deck-inset-media on a notched figure, --deck-inset-text otherwise */
+  --deck-inset-text:     calc(var(--deck-grid) * 4);               /* 96px   · text content — all four edges */
+  --deck-inset-display:  calc(var(--deck-grid) * 5);               /* 120px  · the beat layouts (cover/quote/statement/divider/end) — HORIZONTAL edges only, sized against 96–128px display type */
+
+  /* ── Layout anchors and extras — points and gaps, not edge margins ───────────────────────
+     task-14b-brief.md. Two things split.vue needs beyond the three insets above:
+       anchor-third   the text column's fixed vertical START, "so the headings dont jump between
+                       slides" (Jose). A FRACTION of the canvas, not a hard-coded 360px, so it stays
+                       correct if the canvas itself ever changes — see split.vue's own comment on
+                       .split-grid for the one place its 100% basis is actually the full 1080px
+                       canvas rather than some padded descendant of it.
+       heading-top-space   extra air above a NON-split heading, so it starts clear of the top edge
+                       rather than flush against it. One full grid unit — see default.vue.
+       heading-bottom-space  the gap under a slide's h1, before its first block — base.css. Paired
+                       with the one above so the air on both sides of a title is retuned in one
+                       place, and so a deck that budgets from where content starts (apps/deck
+                       does) reads the number instead of restating it. h2 keeps its own tighter gap:
+                       it sits INSIDE the content rather than starting it. */
+  --deck-anchor-third: 360px;                                      /* 360px  · split.vue's text column start — one third of the canvas down */
+  --deck-heading-top-space: var(--deck-space-5);                        /* 40px   · extra air above a non-split heading — see default.vue */
+  --deck-heading-bottom-space: var(--deck-space-4);                        /* 32px   · the gap under a slide's h1, before its first block — see base.css */
+  --deck-split-gutter-same: var(--deck-inset-text);                     /* 96px   · split.vue, same-kind columns only (text|text, media|media) — mixed splits use 0 and pad the content column instead */
+
+  /* ── The running mark, and the notch it leaves in a panel ────────────────────────────────
+     task-15-brief.md. The cut-out is DERIVED from its occupant and never sized beside it: the
+     occupant's own box is the input, the notch is that box plus one gap, and changing the mark
+     moves both with no second edit. Two readers agree on these because they are tokens rather than
+     a number inside one component — slide-top.vue draws the mark, split.vue cuts room for it.
+
+     The ring is the CHROME INSET again, not a new number: the mark already keeps 36px of clear
+     space on the two sides facing the slide's edge, so the same value on the two sides facing into
+     the panel gives it a uniform ring and makes it read as seated rather than parked. The occupant
+     sits FLUSH in the panel's outer corner (chrome and media share an inset, so the two corners
+     coincide), which is why the cut is occupant + ONE gap.
+
+     --deck-notch-occupant-w/-h are NOT declared here on purpose. Consumers read them as
+     var(--deck-notch-occupant-w, var(--deck-chrome-mark)) so the default lives in the fallback: a
+     custom property declared at :root resolves ONCE, there, and a slide overriding the occupant
+     further down would inherit the stale :root value of anything derived from it. Left undeclared,
+     an override on the slide root reaches every reader — which is what lets one mark and two marks
+     produce correctly-shaped notches with no code change. */
+  --deck-chrome-mark:      72px;                                       /* 72px   · the running chrome's Forest mark — and the notch's default occupant */
+  --deck-chrome-band:      calc(var(--deck-inset-chrome) + var(--deck-chrome-mark)); /* 108px  · how deep the running chrome reaches from the canvas edge — inset + mark */
+  --deck-chrome-pair-gap:  var(--deck-space-2);                        /* 16px   · between the Forest mark and a partner's, in a co-branded lockup (`partner:`) */
+  --deck-notch-gap:        calc(var(--deck-grid) * 1);                 /* 24px   · the breathing ring cut between occupant and panel — tighter than the slide margin, see scripts/deck.ts */
+  --deck-mark-radius:      15.75px;                                    /* 15.75px · the mark's own corner, read from logo.ts's square path — what a co-brand partner is clipped to */
+  --deck-mark-ring-width:  3px;                                        /* 3px    · matched against the artwork's own ring at 72 */
+  --deck-notch-radius:     39.75px;                                    /* 39.75px · concentric with the mark: its 15.75px corner + the 24px ring; split.vue clamps it to half the notch */
+
+  /* ── Radius contract — one lever, everything derives ─────────────────────────────────────
+     Same model and same lever value as the web's --ui-radius. The card step is *6 rather than the
+     web's xl/*3 on purpose: a deck is a BOLD surface, and on a 1920px canvas a 24px corner reads as
+     a hairline at presenting size. */
+  --deck-radius: 0.5rem;
+  --deck-radius-item:      calc(var(--deck-radius) * 1); /* 8px   · code chips, tags, swatches */
+  --deck-radius-control:   calc(var(--deck-radius) * 1.5); /* 12px  · buttons, pills */
+  --deck-radius-card:      calc(var(--deck-radius) * 6); /* 48px  · the slide card */
+
+  /* Concentric corners: a nested surface = parent radius − parent padding, floored at 8px, so the
+     inner curve stays parallel to the outer one. Two steps (48 → 16 → 8), like .forest-card. */
+  --deck-card-pad: var(--deck-space-4); /* 32px */
+  --deck-radius-nested: max(calc(var(--deck-radius-card) - var(--deck-card-pad)), 0.5rem);
+  --deck-radius-nested-2: max(calc(var(--deck-radius-card) - 2 * var(--deck-card-pad)), 0.5rem);
+
+  /* Fully rounded — the pill/circle end of the ladder, NOT a step on it. Deliberately a large
+     constant rather than a multiple of the lever: a pill's corner is "half my own height, whatever
+     that turns out to be", which no fixed multiplier expresses. Moving the lever must not turn a
+     pill back into a rounded rectangle. Used by the running chrome's page marker and by the small
+     chips, both of which read as markers rather than as surfaces. */
+  --deck-radius-full: 9999px;
+
+  /* ── Colour roles — light, and light IS the deck ─────────────────────────────────────────
+     Ice Cream (--warm-50) is a named brand pin, not a tint: warm paper, near-black ink, the accent
+     doing all of the shouting. Boldness comes from the display tier, the full-bleed accent sections
+     and the scale of the type — not from inverting the deck. */
+  --deck-bg: var(--warm-50);
+  --deck-fg: var(--neutral-900); /* neutral, not forest-950 — text is one ramp, so dimming is lightness and never a hue shift */
+  --deck-fg-muted: var(--neutral-600); /* 600, not 500 — the web contrast floor for muted text on light */
+  --deck-fg-subtle: var(--neutral-500);
+  --deck-accent: var(--forest-700);
+  --deck-accent-strong: var(--forest-800);
+  --deck-on-accent: #ffffff;
+
+  /* Named backgrounds and their ink, FOLLOWING the register — what anything that is PART OF the
+     deck reads: a panel, a band, a card ground. See PANEL for why the names are relative ('warm',
+     not 'bark'). The pinned halves are emitted once, below. */
+  --deck-bg-warm: var(--warm-200);
+  --deck-on-bg-warm: var(--warm-950);
+  --deck-bg-accent: var(--forest-100);
+  --deck-on-bg-accent: var(--forest-950);
+  --deck-bg-vivid: var(--forest-300);
+  --deck-on-bg-vivid: var(--forest-950);
+  --deck-bg-neutral: var(--neutral-100);
+  --deck-on-bg-neutral: var(--neutral-900);
+
+  /* The same four names as INK on the page, for anything that draws the tone as a stroke or a label
+     rather than as a ground: an outline badge, a rule, a keyline. See PANEL's ★ note on why this is
+     the OPPOSITE half from the one directly above. */
+  --deck-ink-warm: var(--warm-700);
+  --deck-ink-accent: var(--forest-950);
+  --deck-ink-vivid: var(--forest-700);
+  --deck-ink-neutral: var(--neutral-800);
+
+  /* ── the MARK a background carries ──────────────────────────────────────────────────────────
+     ★★ A SMALL SHAPE DRAWN ON THE BACKGROUND, IN THAT BACKGROUND'S OWN FAMILY — a list bullet
+     today, and anything else of that size later. Not the ink pair above, which is the OPPOSITE half
+     and exists for drawing this name on the PAGE; not on-bg, which is the body ink and reads as
+     text rather than as a mark. This is the liveliest step of the same family that still clears the
+     3:1 a graphical object is held to against the fill it lands on.
+
+     Chosen by measuring the whole ramp against each fill rather than by picking a rung. Warm wanted
+     an orange rather than the bark: on peach nothing lighter than 600 clears the floor (500 is
+     2.66) so 600 it is, and on bark the orange 300 clears at 3.84. The green fields wanted the
+     vivid green: on the quiet accent field forest-700 gives 5.45, and on the night step forest-300
+     gives 8.51. Vivid itself cannot take a mint on its light half — every light green is invisible
+     on forest-300, and 200 measures 1.28 — so it takes 800 there and the mint 200 on its dark half,
+     4.53.
+
+     MEASURED, mark against its own fill: warm 3.83 light / 3.84 dark, accent 5.45 / 8.51, vivid
+     4.78 / 4.53, neutral 4.18 / 5.74.
+
+     Named bg-NAME-mark rather than mark-NAME: --deck-mark-radius is the LOGO mark's corner and
+     --deck-status-STATE-mark is a semantic state's fill, so the prefix is already spoken for. This
+     one belongs to the background, and is named where it lives. */
+  --deck-bg-warm-mark: var(--warm-600);
+  --deck-bg-accent-mark: var(--forest-700);
+  --deck-bg-vivid-mark: var(--forest-800);
+  --deck-bg-neutral-mark: var(--neutral-500);
+
+  /* Chart series alias the published categorical palette in the product's ORDER, so a deck chart and
+     a product chart of the same data are the same chart. */
+  --deck-series-1: var(--dataviz-categorical-vivid-green);
+  --deck-series-2: var(--dataviz-categorical-vivid-amber);
+  --deck-series-3: var(--dataviz-categorical-vivid-sky);
+  --deck-series-4: var(--dataviz-categorical-vivid-indigo);
+  --deck-series-5: var(--dataviz-categorical-vivid-pink);
+  --deck-series-6: var(--dataviz-categorical-vivid-red);
+
+  /* The sequential ramp — one hue, five steps, for a quantity rather than a category. Light register
+     runs pale to deep, so more ink means more of whatever is being mapped. */
+  --deck-shade-1: var(--dataviz-sequential-forest-2);
+  --deck-shade-2: var(--dataviz-sequential-forest-3);
+  --deck-shade-3: var(--dataviz-sequential-forest-4);
+  --deck-shade-4: var(--dataviz-sequential-forest-6);
+  --deck-shade-5: var(--dataviz-sequential-forest-8);
+
+  /* The Thames takes the palette's own river pair rather than a grey — it is the one feature that
+     tells an audience which city they are looking at, a data colour doing a wayfinding job. */
+  --deck-dot-river: var(--dataviz-categorical-pairs-river-soft);
+
+  /* ── The pinned halves — PAIRED with their ink, never emitted alone ──────────────────────
+     The same four backgrounds, each half nailed to one register and never re-pointed. This is what
+     an OBJECT sitting on the deck reads — a badge, an icon tile, a running pill — where the names
+     above are what a SURFACE of the deck reads. A component picks "<name>-<half>" and never
+     assembles a fill and an ink from two different rows.
+
+     ★ THE INK IS "on-bg-<name>", NOT "on-<name>", and the bg- is load-bearing. This file already
+     has a --deck-accent role (the brand green for claims and chrome) whose ink is --deck-on-accent,
+     so a shortened on-accent here silently redefined it — measured, the role's forest-700 fill
+     ended up paired with forest-950 ink. The on- prefix wraps the FULL name of the fill it belongs
+     to, which is what on-status-danger and the old on-panel-accent already did.
+
+     ★★ ONE TABLE, WHICH IS THE POINT. This was CHIP, holding the same literals PANEL held, and the
+     two drifted the first time one moved: deep was accent's dark half until that half went to the
+     night step, and nothing said so. A name is a background plus a half now, so a value cannot go
+     stale in one copy.
+
+     ⚠ PINNED IS NOT THE SAME AS FOLLOWING, and the caller owns the difference. "accent-dark" on a
+     dark slide IS that slide's own ground and disappears — measured 1.00:1. That is not a fault in
+     the token; it is what a fixed dark object on a dark page means. The follow tokens above exist
+     so a surface never has to make that choice. */
+  --deck-bg-warm-light: var(--warm-200);
+  --deck-on-bg-warm-light: var(--warm-950);
+  --deck-bg-warm-dark: var(--warm-700);
+  --deck-on-bg-warm-dark: var(--neutral-0);
+  --deck-bg-accent-light: var(--forest-100);
+  --deck-on-bg-accent-light: var(--forest-950);
+  --deck-bg-accent-dark: var(--forest-950);
+  --deck-on-bg-accent-dark: var(--neutral-0);
+  --deck-bg-vivid-light: var(--forest-300);
+  --deck-on-bg-vivid-light: var(--forest-950);
+  --deck-bg-vivid-dark: var(--forest-700);
+  --deck-on-bg-vivid-dark: var(--neutral-0);
+  --deck-bg-neutral-light: var(--neutral-100);
+  --deck-on-bg-neutral-light: var(--neutral-900);
+  --deck-bg-neutral-dark: var(--neutral-800);
+  --deck-on-bg-neutral-dark: var(--neutral-0);
+
+  /* Status roles, a SET per state — see the STATUS table. The subtle four are alpha over the
+     semantic role, which is stock's own construction; the dark block restates them off the 400
+     because a var() inside a custom property is substituted where that property is DECLARED. */
+  --deck-status-info-fill: color-mix(in oklab, var(--river-500) 10%, transparent);
+  --deck-status-info-ink: var(--river-600);
+  --deck-status-info-icon: var(--river-500);
+  --deck-status-info-edge: color-mix(in oklab, var(--river-500) 25%, transparent);
+  --deck-status-info-solid: var(--river-500);
+  --deck-status-info-mark: var(--river-500);
+  --deck-on-status-info: #ffffff;
+  --deck-status-success-fill: color-mix(in oklab, var(--forest-500) 10%, transparent);
+  --deck-status-success-ink: var(--forest-600);
+  --deck-status-success-icon: var(--forest-500);
+  --deck-status-success-edge: color-mix(in oklab, var(--forest-500) 25%, transparent);
+  --deck-status-success-solid: var(--forest-500);
+  --deck-status-success-mark: var(--forest-500);
+  --deck-on-status-success: #ffffff;
+  --deck-status-warning-fill: color-mix(in oklab, var(--amber-500) 10%, transparent);
+  --deck-status-warning-ink: var(--amber-600);
+  --deck-status-warning-icon: var(--amber-500);
+  --deck-status-warning-edge: color-mix(in oklab, var(--amber-500) 25%, transparent);
+  --deck-status-warning-solid: var(--amber-500);
+  --deck-status-warning-mark: var(--amber-500);
+  --deck-on-status-warning: #ffffff;
+  --deck-status-danger-fill: color-mix(in oklab, var(--maple-500) 10%, transparent);
+  --deck-status-danger-ink: var(--maple-600);
+  --deck-status-danger-icon: var(--maple-500);
+  --deck-status-danger-edge: color-mix(in oklab, var(--maple-500) 25%, transparent);
+  --deck-status-danger-solid: var(--maple-500);
+  --deck-status-danger-mark: var(--maple-500);
+  --deck-on-status-danger: #ffffff;
+  --deck-status-neutral-fill: color-mix(in oklab, var(--neutral-500) 10%, transparent);
+  --deck-status-neutral-ink: var(--neutral-600);
+  --deck-status-neutral-icon: var(--neutral-500);
+  --deck-status-neutral-edge: color-mix(in oklab, var(--neutral-500) 25%, transparent);
+  --deck-status-neutral-solid: var(--neutral-500);
+  --deck-status-neutral-mark: var(--neutral-500);
+  --deck-on-status-neutral: #ffffff;
+}
+
+/* ── Dark — punctuation, not the ground ───────────────────────────────────────────────────────
+   The deck runs LIGHT. Dark is a per-slide instrument: a hard cut marking a pivot, landing a
+   statement, or letting a chart sit on a black ground.
+
+   Bound to TWO selectors: `.dark` is the whole-deck toggle (Slidev stamps it on <html>), and
+   `.deck-dark` is a single slide opting in from frontmatter. */
+.dark,
+.deck-dark {
+  --deck-bg: var(--forest-950);
+  --deck-fg: var(--neutral-0);
+  --deck-fg-muted: var(--neutral-400);
+  --deck-fg-subtle: var(--neutral-500);
+  --deck-accent: var(--forest-300);
+  --deck-accent-strong: var(--forest-200);
+  --deck-on-accent: var(--forest-950);
+
+  /* The same panel grounds, on the other side of the register — the half that did not exist. */
+  --deck-bg-warm: var(--warm-700);
+  --deck-on-bg-warm: var(--neutral-0);
+  --deck-bg-accent: var(--forest-950);
+  --deck-on-bg-accent: var(--neutral-0);
+  --deck-bg-vivid: var(--forest-700);
+  --deck-on-bg-vivid: var(--neutral-0);
+  --deck-bg-neutral: var(--neutral-800);
+  --deck-on-bg-neutral: var(--neutral-0);
+  --deck-ink-warm: var(--warm-200);
+  --deck-ink-accent: var(--forest-100);
+  --deck-ink-vivid: var(--forest-300);
+  --deck-ink-neutral: var(--neutral-100);
+  --deck-bg-warm-mark: var(--warm-300);
+  --deck-bg-accent-mark: var(--forest-300);
+  --deck-bg-vivid-mark: var(--forest-200);
+  --deck-bg-neutral-mark: var(--neutral-400);
+  --deck-dot-river: var(--dataviz-categorical-pairs-river-deep);
+
+  /* ★ THE RAMP REVERSES ON A DARK GROUND, because "more" is a bigger distance FROM the page and the
+     page moved. Deep forest on near-black is the step that disappears, exactly as pale forest is the
+     one that disappears on paper — so the same five steps run the other way and the reading ("more
+     ink means more") survives the register change. */
+  --deck-shade-1: var(--dataviz-sequential-forest-8);
+  --deck-shade-2: var(--dataviz-sequential-forest-6);
+  --deck-shade-3: var(--dataviz-sequential-forest-4);
+  --deck-shade-4: var(--dataviz-sequential-forest-3);
+  --deck-shade-5: var(--dataviz-sequential-forest-2);
+}
+
+/* ── The design system's own dual-mode tokens, answered in the DECK's register ────────────────
+   ★★ WITHOUT THIS BLOCK A CHART ON A DARK SLIDE PAINTS THE LIGHT PALETTE, and nothing anywhere
+   says so. The series and the Thames alias published dataviz tokens rather than restating them —
+   which is the point, so a deck chart and a product chart of the same data are the same chart. But
+   those tokens flip on .dark, and a dark SLIDE is .deck-dark: Slidev stamps .dark on <html>
+   only when the whole deck is dark. Measured on the built deck — html.dark false, no .dark
+   ancestor anywhere in the document — so on a .deck-dark slide the alias resolved to the LIGHT
+   value and the dark half of a dual-mode palette was unreachable.
+
+   It is the same shape as the shiki defect this theme already carries a note about: html.dark and
+   .deck-dark are different things, and code that assumes one covers the other is wrong quietly.
+
+   What it cost, measured against the deck's dark ground (forest-950):
+
+     series    light (what was drawn)   dark (what should be)
+     green            4.72                     8.70
+     indigo           2.39   ← under 3:1       5.00
+     amber            4.84                     9.04
+     pink             3.34                     5.60
+     sky              3.78                     7.02
+
+   Indigo sat below the 3:1 floor a graphical object is held to, and no gate could see it: the
+   audit's contrast pass measures TEXT, and a chart fill is not text.
+
+   ★★ THE FIX IS BOTH HALVES, AND THE SECOND ONE IS NOT OPTIONAL. Re-pointing the source token
+   alone looks sufficient and is not: a var() inside a custom property is substituted where that
+   property is DECLARED, and --deck-series-N is declared on :root, so its alias resolves against
+   :root's value no matter what this block says. Measured on the built deck after the source
+   re-point alone — --deck-series-4 (indigo) still read #4f39f6, the LIGHT indigo, on a .deck-dark slide.
+   The ROLE has to be re-declared here too, which is what re-resolves its alias in this register.
+   (--deck-dot-river needed nothing: it is already declared in the dark role block above, on the
+   same element, so its alias re-resolved on its own. That asymmetry is the whole rule — a role
+   declared only on :root is frozen there; one declared here is not.)
+
+   Re-pointing the token as well is still worth doing: it keeps the re-declared role pointing at
+   the PUBLISHED token rather than at a hex, so the palette stays the single source, and anything
+   reading a dataviz token directly in this register gets the right value.
+
+   Values come from colourEngine's own tables, the same source scripts/dataviz.ts generates from, so
+   there is no second copy of the palette to drift. packages/slidev-theme/test/deckRegister.static.test.ts
+   asserts this block covers every dual-mode dataviz token deck.css references.
+
+   .dark needs none of this: dataviz.css already answers it there. */
+.deck-dark {
+  --dataviz-categorical-vivid-green: #05df72;
+  --dataviz-categorical-vivid-amber: #fabc00;
+  --dataviz-categorical-vivid-sky: #00bbfd;
+  --dataviz-categorical-vivid-indigo: #7d87ff;
+  --dataviz-categorical-vivid-pink: #fb64b6;
+  --dataviz-categorical-vivid-red: #ff6568;
+  --dataviz-categorical-pairs-forest-deep: #0abb7f;
+  --dataviz-categorical-pairs-forest-soft: #99e9bc;
+  --dataviz-categorical-pairs-warm-deep: #f48519;
+  --dataviz-categorical-pairs-warm-soft: #ffd6a6;
+  --dataviz-categorical-pairs-river-deep: #43a2ff;
+  --dataviz-categorical-pairs-river-soft: #b2d9ff;
+
+  /* The semantic mark, one rung lighter — see STATUS_MARK_DARK for the measurement. */
+  --deck-status-info-mark: var(--river-400);
+  --deck-status-success-mark: var(--forest-400);
+  --deck-status-warning-mark: var(--amber-400);
+  --deck-status-danger-mark: var(--maple-400);
+  --deck-status-neutral-mark: var(--neutral-400);
+
+  /* ★★ AND THE SUBTLE FOUR WITH IT, restated rather than inherited. They are color-mix results
+     built off the mark, and a custom property computes where it is DECLARED — re-pointing the mark
+     above would leave a fill declared at :root holding the 500 it was substituted with there. Same
+     trap the derived surfaces and the series roles record. This is the whole of what stock gets for
+     free from a dark: class never appearing in its theme: the token moves, so the variant moves. */
+  --deck-status-info-fill: color-mix(in oklab, var(--river-400) 10%, transparent);
+  --deck-status-info-ink: var(--river-400);
+  --deck-status-info-icon: var(--river-400);
+  --deck-status-info-edge: color-mix(in oklab, var(--river-400) 25%, transparent);
+  --deck-status-success-fill: color-mix(in oklab, var(--forest-400) 10%, transparent);
+  --deck-status-success-ink: var(--forest-400);
+  --deck-status-success-icon: var(--forest-400);
+  --deck-status-success-edge: color-mix(in oklab, var(--forest-400) 25%, transparent);
+  --deck-status-warning-fill: color-mix(in oklab, var(--amber-400) 10%, transparent);
+  --deck-status-warning-ink: var(--amber-400);
+  --deck-status-warning-icon: var(--amber-400);
+  --deck-status-warning-edge: color-mix(in oklab, var(--amber-400) 25%, transparent);
+  --deck-status-danger-fill: color-mix(in oklab, var(--maple-400) 10%, transparent);
+  --deck-status-danger-ink: var(--maple-400);
+  --deck-status-danger-icon: var(--maple-400);
+  --deck-status-danger-edge: color-mix(in oklab, var(--maple-400) 25%, transparent);
+  --deck-status-neutral-fill: color-mix(in oklab, var(--neutral-400) 10%, transparent);
+  --deck-status-neutral-ink: var(--neutral-400);
+  --deck-status-neutral-icon: var(--neutral-400);
+  --deck-status-neutral-edge: color-mix(in oklab, var(--neutral-400) 25%, transparent);
+
+  /* The solid panel and its ink, as ONE PAIR — see STATUS_SOLID_DARK. The fill lifts so the block
+     separates from a near-black slide; the ink turns over because white cannot survive the lighter
+     fill it just moved to. */
+  --deck-status-info-solid: var(--river-400);
+  --deck-on-status-info: var(--river-950);
+  --deck-status-success-solid: var(--forest-400);
+  --deck-on-status-success: var(--forest-950);
+  --deck-status-warning-solid: var(--amber-400);
+  --deck-on-status-warning: var(--amber-950);
+  --deck-status-danger-solid: var(--maple-400);
+  --deck-on-status-danger: var(--maple-950);
+  --deck-status-neutral-solid: var(--neutral-400);
+  --deck-on-status-neutral: var(--neutral-950);
+
+  /* ★★ AND THE SERIES ROLES THEMSELVES, not only the token they alias. A var() inside a custom
+     property is substituted where that property is DECLARED — --deck-series-N is declared at :root,
+     so its alias resolves against :root and re-pointing the source here never reaches it. Measured
+     on the built deck after the source re-point alone: --deck-series-4 (indigo) still read #4f39f6, the LIGHT
+     indigo, on a .deck-dark slide. Re-declaring the role here is what re-resolves the alias in this
+     register. It still points at the published token rather than a hex, so there is no second copy
+     of the palette; the token beside it is what makes that reference land on the dark value. */
+  --deck-series-1: var(--dataviz-categorical-vivid-green);
+  --deck-series-2: var(--dataviz-categorical-vivid-amber);
+  --deck-series-3: var(--dataviz-categorical-vivid-sky);
+  --deck-series-4: var(--dataviz-categorical-vivid-indigo);
+  --deck-series-5: var(--dataviz-categorical-vivid-pink);
+  --deck-series-6: var(--dataviz-categorical-vivid-red);
+}
+
+/* ── The brand-pairs opt-in ───────────────────────────────────────────────────────────────────
+   A slide-level class, written beside `class: deck-dark` in frontmatter, that re-points the series
+   roles to the published BRAND pairs: three brand hues, each contributing a deep and a soft tone.
+   Nothing in a chart component knows about it — a declaration on the slide element beats :root's
+   inherited value, which is the same cascade rule the dark register already relies on.
+
+   ★ FAMILY ORDER, exactly as the product's own pairsVar() walks it (packages/charts/src/
+   useChartPalette.ts), so consecutive slots are the SAME hue. That is the whole semantics: a pair
+   says "these two series are two views of one thing". It also means a pairs chart wants an EVEN
+   series count — at five, slot 5 is river-deep with its soft tone out of reach, and the last series
+   reads as a lone hue rather than half a pair.
+
+   ★★ THE CEILING, WRITTEN DOWN, because it is severe and it is invisible to every gate this repo
+   has. On the LIGHT register the pairs do not clear the 3:1 a graphical mark is held to. Measured
+   against the deck's own grounds — bare cream / --deck-surface / the since-folded 8% bg-subtle:
+
+     forest-deep 3.25 / 2.90 / 2.69      forest-soft 1.74 / 1.55 / 1.44
+     warm-deep   3.46 / 3.09 / 2.87      warm-soft   1.75 / 1.56 / 1.45
+     river-deep  3.50 / 3.12 / 2.90      river-soft  1.84 / 1.64 / 1.53
+
+   The soft tones are the deck's lowest-contrast marks by a distance — below the 2.39 that got the
+   vivid indigo re-pointed one register over. Even the DEEP tones only clear 3:1 on bare cream, and
+   Bars draws its track in --deck-surface. So: pairs belong on a `deck-dark` slide, where all six
+   measure 4.72-11.37. That is not a workaround; a saturated brand chart on a dark ground is one of
+   the three things the dark register exists for.
+
+   ★ The cost on dark is COLOUR-VISION, not contrast, and it is why this is a small instrument
+   rather than a replacement for the vivid five. Cross-family the soft tones converge — forest-soft
+   against warm-soft is worst-case-CVD dE00 5, where vivid-5 holds 8. Within a pair the separation
+   is carried by lightness (a constant +17 L*) and survives every dichromacy at 13-18. Read that as
+   the instruction it is: pairs is at its best as TWO series from ONE family, and degrades as it is
+   asked to carry more unrelated categories.
+
+   NOT RE-WINDOWED for the deck. Taking each pair a rung darker clears contrast on cream but costs
+   the brand: warm-700 is #8a462e, a brown, and warm-500 is the only warm step that is both above
+   3:1 and still Acer orange. The published pairs are brand ramp steps exactly (light 500/300, dark
+   400/200); a deck-local re-derivation would be a second palette, which is the thing this file is
+   organised to avoid. */
+/* ★★ TWO SELECTORS, ONE TABLE, AND THE SECOND IS NOT REDUNDANT. A custom property substitutes its
+   var() where it is DECLARED, so on `.deck-pairs` alone every slot resolves against the slide
+   element — and a `deck-dark` PANEL inside that slide inherits the finished LIGHT colour, however
+   correctly the source token re-points beneath it. The panel would draw the light pairs on a dark
+   ground, which is the pairing this whole block exists to make unreachable.
+
+   Re-declaring under `.deck-pairs .deck-dark` makes the substitution happen again inside the
+   panel, where `.deck-dark` has already re-pointed --dataviz-categorical-pairs-* to their dark
+   values. Same trap, same fix, as the derived surfaces below and the dataviz aliases above. */
+.deck-pairs,
+.deck-pairs .deck-dark {
+  --deck-series-1: var(--dataviz-categorical-pairs-forest-deep);
+  --deck-series-2: var(--dataviz-categorical-pairs-forest-soft);
+  --deck-series-3: var(--dataviz-categorical-pairs-warm-deep);
+  --deck-series-4: var(--dataviz-categorical-pairs-warm-soft);
+  --deck-series-5: var(--dataviz-categorical-pairs-river-deep);
+  --deck-series-6: var(--dataviz-categorical-pairs-river-soft);
+}
+
+/* ── Surfaces and borders — DERIVED from the ground, not picked off a ramp ────────────────────
+   Each level is the page mixed with a little ink — the same mechanism as .forest-card's l1/l2/l3.
+   It obeys "surfaces step AWAY from the page: light DARKER, dark LIGHTER" automatically, because the
+   ink flips with the mode; and it re-tunes itself the moment --deck-bg moves, which a ramp step
+   cannot (the warm ramp has nothing between 50 and 100, a real peach).
+
+   ★★ Declared on EVERY mode boundary, NOT just :root. A custom property computes ONCE where it is
+   declared and then inherits that fixed colour — so on :root alone a `class: deck-dark` slide would
+   re-point --deck-bg and still inherit the LIGHT surface resolved at :root. Same trap, same fix, as
+   forest.css's card levels. */
+:root,
+.dark,
+.deck-dark {
+  --deck-surface: color-mix(in oklab, var(--deck-bg), var(--deck-fg) 5%); /* L1 — a card on the page */
+  --deck-surface-strong: color-mix(in oklab, var(--deck-bg), var(--deck-fg) 10%); /* L2 — a card on a card. Was surface-raised: a name claiming a direction the ladder has none of */
+  --deck-border: color-mix(in oklab, var(--deck-bg), var(--deck-fg) 14%);
+  --deck-border-strong: color-mix(in oklab, var(--deck-bg), var(--deck-fg) 26%); /* the heavier rule — an axis against its gridlines, an edge against a hatch */
+  --deck-dot-land: color-mix(in oklab, var(--deck-bg), var(--deck-fg) 34%); /* the map dot grid — has to read as a SHAPE across a room */
+}