@humanforest/slidev-theme 0.1.0

package/layouts/stack.vue

@@ -0,0 +1,944 @@
+<script setup>
+/*
+  The horizontal counterpart of `split` — a hero BAND across the top, the title demoted to a strip
+  below it. Everything else in this theme is either one region or a left/right split; nothing
+  divided top from bottom, and that was the single biggest gap the reference deck turned up.
+
+  ★ WHY IT EXISTS, from the source rather than from taste. The 65-page Forest template catalogue
+  (../../../.superpowers/sdd/2026-08-21-deck-layout-system/template-archetypes.md) uses this
+  arrangement NINE times — tied for the most-used interior structure in the whole document — for
+  numbered cards, icon cards, phone mockups, a data table, a milestone timeline and pricing tiers.
+  Its own §3 ranks it "the biggest gap", and its §5 records the rule that makes it a distinct layout
+  rather than a variant: "Two-band pages always subordinate the title. The content that matters
+  occupies the top ~65% colour band; title+body is pushed into a short bottom cream strip — the
+  reverse of normal top-down reading order, but consistent across all 9 instances."
+
+  That inversion is the whole point. On a `split` the title leads and the figure supports it; here
+  the hero content leads and the title captions it. A slide that wants the normal order already has
+  two layouts for it.
+
+  THE VOCABULARY IS SPLIT'S, deliberately — `ratio` content-relative, `frame` photo/panel/none, an
+  `eyebrow` — so an author who knows one knows the other, and the two read as one system rather than
+  as two people's ideas about slides. Only `flip` is missing, and only because a full-width band has
+  no side to sit on: its outer top corner IS the slide's, which is where the running mark already is.
+
+  ★★ WHY THERE IS NO ACCENT OR DARK BAND, and it is a MEASUREMENT, not a preference. The catalogue's
+  band is always the same mint whatever it holds ("never a different accent per content type", §5),
+  and the first pass here added the deck's two loud registers anyway on the grounds that `divider`
+  already proves both. Rendered, that is a defect: a full-width band rises to --deck-inset-chrome, so
+  the running chrome's PAGE PILL — which the notch cannot make room for, because its width is a
+  section name and therefore unbounded — lands ON the band. Measured pill fill (--deck-bg-vivid-dark,
+  forest-700) against each candidate ground:
+
+      soft   mint, forest-100        5.45:1   ✓
+      subtle --deck-bg-subtle        5.28:1   ✓   (split's own panel fill, so the two can match)
+      accent forest-700              1.00:1   ✗   the pill is the ground; it disappears entirely
+      dark   forest-950              2.40:1   ✗   under the 3:1 non-text floor
+
+  The chrome cannot adapt: slide-top.vue is forbidden from naming a layout (there is a test — see
+  frontmatter.static.test.ts, "names no layout, in any form" — because chrome that varies by layout
+  is a defect this project has already paid for). So the two loud grounds are not expressible here.
+  A slide that wants a full-field green or black cut has `divider`, which owns the whole canvas and
+  ships `chrome: false` on every occurrence in every deck.
+
+  ★★ `frame: photo` HAD the same risk in an unmeasurable form, and this comment used to answer it by
+  asking the author to remember something. A photograph's top-left corner can be any colour, so no
+  contrast row above can be written for it — and the notch only ever protected the MARK end, because
+  the chrome USED TO mirror, sending the pills to the text side, and a full-width band has none. Rendered
+  on the retired deck-layouts 28 that was a live defect, not a latent one: the mark sits in a clean cut and "28"
+  and "LAYOUTS" sit directly on a forest photograph.
+
+  A photo band therefore STANDS CLEAR of the running chrome rather than cutting into it — it starts
+  seated in a cut of its own — useNotchCuts measures every chrome element on the band, so both ends sit
+  on the slide's own cream ground and nothing depends on what is in the picture. The cost is stated
+  rather than discovered: those slides lose the mark's seat and 108px of band height. See
+  ../notch.js's retirement note for the full history; EVERY band notches now, because its
+  ground is one of the two tones measured in the table above.
+*/
+
+// Same clamp discipline as split.vue and bleed.vue: Vue strips prop validators from a production
+// build, so an out-of-range value (an AI's `ratio: '5:7'`, a typo'd background) must not reach the
+// template raw and mint a class name with no matching CSS rule — an unstyled slide, invisible until
+// something overflows. These lookups fall back to the documented default independent of the
+// validators below.
+//
+// The band is the FIGURE and the strip is the CONTENT, so a `ratio` reads exactly as it does on a
+// split: content first, figure second. '1:2' therefore gives the band two thirds of the usable
+// height, which is the catalogue's own ~65%. Split's six are all here so nothing an author already
+// knows is invalid, plus '1:3' — split has no such rung (its ladder is lopsided towards content:
+// 3:1 exists, 1:3 does not) and a band that dominates harder than 2/3 is the one thing this layout
+// specifically needs it for.
+//
+// ★★ AND '0:1' — THE BAND WITH NO STRIP, which is the panel filling the field. A ratio rather than a
+// second layout because that is what it is: content 0, figure everything.
+//
+// ⚠ IT WAS SPELLED '1:0' AND THAT WAS BACKWARDS. The convention two paragraphs up is content first,
+// figure second, and the sentence above defends the rung as "content 0, figure everything" — which
+// is 0:1. The old name said the strip took everything and the band nothing, the exact inverse of
+// what the rung does. Renamed while it was one release old. The band keeps every
+// treatment it has at any other rung — the panel frame, the named background, `panelDark`, the card
+// corner, the media inset — and, the point of it, THE NOTCH. `bleed` is the other way to make a band
+// big and it gives the notch up, because at the canvas edge there is no ring of deck ground left to
+// cut a seat out of. This rung keeps the ring: 36px all the way round, half margin and half cut-out,
+// mark seated top-right and section pill bottom-left.
+const RATIO_ROWS = {
+  '1:1': 'is-1-1',
+  '3:2': 'is-3-2',
+  '2:3': 'is-2-3',
+  '2:1': 'is-2-1',
+  '1:2': 'is-1-2',
+  '3:1': 'is-3-1',
+  '1:3': 'is-1-3',
+  '0:1': 'is-0-1',
+};
+
+// Split's own three, same meanings: a photo frame, a tinted panel, or nothing (the author brings
+// their own ground and owns their own corner — including the notch, which is why `none` is not in
+// PANEL_MEDIA).
+/*
+  Split's `panelAlign` without its two `title-*` values. Those position a HEADING that sits beside
+  the panel; a stack's heading is in the strip BELOW the band, so there is nothing beside the band
+  for them to act on and they would be `start` and `center` under another name. Same subsetting the
+  `frame` and `ratio` docs above state for their own omissions.
+*/
+const PANEL_ALIGN_CLASS = {
+  start: 'is-panel-start',
+  center: 'is-panel-center',
+  end: 'is-panel-end',
+};
+
+const FRAME_CLASS = {
+  photo: 'is-photo',
+  panel: 'is-panel',
+  code: 'is-code',
+  content: 'is-content',
+};
+
+// Two grounds, both light, both measured legible under the running chrome — see the ★★ note above
+// for the two that were cut and the numbers that cut them.
+/*
+  ★★ THE TONE VALUES ARE THE PANEL GROUNDS, AND THEY ARE HUES RATHER THAN TREATMENTS.
+
+  This read `soft | subtle | warm | vivid` — two treatment words and two hue words in one enum, and
+  half of them reaching past the roles into the raw ramp (`--warm-100`, `--forest-300`) so they did
+  not follow the register at all. A panel on a dark slide kept its light fill under light ink.
+
+  Each value is now a NAMED GROUND from the engine (see PANEL in scripts/deck.ts), which publishes a
+  fill AND its ink for BOTH registers. So the ink is paired rather than inherited, and every value
+  moves with the slide:
+
+      warm     peach on light, bark on dark      accent   the quiet green field
+      vivid    the loud green, MIRRORED          neutral  no hue at all
+
+  The renames are `soft` → `accent` (same forest-100 on light) and `subtle` → `neutral`. `warm` and
+  `vivid` keep their names; warm deepens one step (warm-100 → warm-200) to be a ground rather than a
+  tint of the page.
+
+  ★★ AND `dark` IS NOT ONE OF THEM, BECAUSE IT IS NOT A HUE — it is the OTHER axis. `background` says
+  which ground; `panelDark` says which register that ground is read in. They compose: every one of
+  the four has a light half and a dark half already, so a dark panel is `background` unchanged with the
+  register flipped, and the enum stays four values rather than five with one of them meaning
+  something different from the rest.
+*/
+const TONE_CLASS = {
+  warm: 'bg-warm',
+  accent: 'bg-accent',
+  vivid: 'bg-vivid',
+  neutral: 'bg-neutral',
+};
+
+import { computed, inject, ref } from 'vue';
+import { useNotchCuts } from '../useNotchCuts.js';
+import { injectionCurrentPage, injectionFrontmatter } from '@slidev/client/constants.ts';
+import deckTokens from '@humanforest/tokens/deck/deck.json';
+import { chromeShows, coBrandFitted, hasNotch, notchShows } from '../notch.js';
+import { assetUrl } from '../assetUrl.js';
+
+const props = defineProps({
+  /** The strip's share of the slide against the band's — content-relative, exactly like `split`'s. The default gives the band two thirds, which is the proportion the reference template uses on every one of its nine two-band pages. */
+  ratio: {
+    type: String,
+    default: '1:2',
+    // Inlined rather than reading RATIO_ROWS: Vue hoists defineProps() out of setup() at build
+    // time, so a validator cannot close over a script-setup-local const — it compiles in dev and
+    // breaks the production build. The template clamps through RATIO_ROWS anyway, which is what
+    // actually protects a real deck.
+    validator: (r) => ['1:1', '3:2', '2:3', '2:1', '1:2', '3:1', '1:3', '0:1'].includes(r),
+  },
+  /**
+   * A CODE SURFACE — the panel IS the block, rather than a mat with a block sitting on it.
+   *
+   * ★★ IT EXISTS TO AVOID TWO NESTED WELLS. On `frame: panel` a code block draws its own ground and
+   * edge inside the panel's, so the slide is a card on a card — on the dark register a #191617 well
+   * inside a neutral-800 panel, 1.10:1 apart, which is two surfaces an audience cannot separate and
+   * one of them doing no work.
+   *
+   * Here the panel takes `--slidev-code-background` and the block inside it goes flat: no fill, no
+   * edge, no padding of its own. The magic-move container owns its surface the same way; this is
+   * that rule with a name.
+   *
+   * ★ AN EXPLICIT VALUE, NOT A `:has()` ON `panel`. A panel that silently changed ground because it
+   * happened to contain a code block is exactly the shape of `frame: none` — a positive behaviour
+   * named as an absence — which this layout already paid for once. It also makes the conflict
+   * visible: `background` names a tinted ground and a code frame has none, so the two do not compose, and
+   * an author reading `frame: code` can see that where a silent override would not tell them.
+   */
+  /** How the band is FRAMED: clipped as a photo, matted in a tinted panel, or not a figure at all — the author's own full-width block, with no ground and no notch. Split's `frame` without `figure`, which a full-width band has no use for. */
+  frame: { type: String, default: 'panel', validator: (f) => ['photo', 'panel', 'content', 'code'].includes(f) },
+  /**
+   * Take the band to the CANVAS EDGE instead of the 36px media inset — same frame, same fill, same
+   * background, same content, no ring of ground around it.
+   *
+   * A MODIFIER rather than a fourth `frame`, and the same one split takes: a photo band and a tinted
+   * panel band can each want the edge and each keeps its own treatment there. Inert on
+   * `frame: content`, which is the author's own block and keeps the text inset it already has.
+   *
+   * `inset` keeps the ring of ground around the band; `bleed` takes it to the canvas.
+   *
+   * ★ NAMED `edge`, NOT `bleed`, BECAUSE `bleed` IS ALSO A LAYOUT. One word cannot mean both "this
+   * slide is a full-canvas image" and "this figure reaches the edge" in the same frontmatter. The
+   * key carries the axis and the value carries the state, so `layout: bleed` keeps sole ownership
+   * of the word as a layout and `edge: bleed` is unambiguous beside it.
+   *
+   * `inset` is the deck's own word — --deck-inset-text, --deck-inset-media and --deck-inset-chrome
+   * are the three it is measured in — so naming the default costs an author no new concept. It is
+   * NOT called "notched": `notch: false` is a separate key that keeps the inset and drops only the
+   * cut, so a slide can be inset without being notched.
+   *
+   * ★ `bleed` SUPPRESSES THE NOTCH. The cut seats the running chrome in the ring of ground around
+   * the band; at inset 0 there is no ring. A band is full width, so BOTH ends of the chrome then
+   * sit on it — pair this with `chrome: false`, or use the `bleed` layout and its scrim.
+   */
+  /*
+   * ★★ `spill` IS `bleed` PLUS ONE MORE STEP — see split.vue's own note, which this shares. The
+   * band's box reaches the canvas either way; on `spill` what is INSIDE it is sized past the box and
+   * cropped by the slide. On this layout the crop is the BOTTOM edge, because the band is a strip
+   * across the frame: a browser window whose foot is below the canvas, three device frames standing
+   * on the bottom of the slide.
+   */
+  edge: { type: String, default: 'inset', validator: (e) => ['inset', 'bleed', 'spill'].includes(e) },
+  // ⚠ THIS DESCRIBED 'soft' AND 'subtle', WHICH THE ENUM NO LONGER HAS, and it ships: a prop
+  // description lands in manifest.json and is what an AI consumer reads, so a stale one is a stale
+  // contract rather than a stale comment. The band took loose fills once — forest-100 ('soft', the
+  // reference template's own field) and --deck-bg-subtle — and it now takes the same four names
+  // split.vue's panel does.
+  //
+  // The reason 'soft' went is worth keeping: its contrast passed, but rendered against this deck's
+  // own --warm-50 ground it is a COOL field on a WARM one, a clash no ratio can express and one the
+  // designer rejected on sight. `warm` is the default for that reason.
+  /** The tinted band's register, for `frame: panel` only — one of the four named backgrounds, each a fill and the ink published with it. */
+  background: { type: String, default: 'warm', validator: (t) => ['warm', 'accent', 'vivid', 'neutral'].includes(t) },
+  /**
+   * Run the PANEL in the dark register, leaving the rest of the slide light.
+   *
+   * ★★ A SECOND AXIS, NOT A FIFTH `background`. The four tones are HUES and each already publishes both
+   * halves (see PANEL in scripts/deck.ts): warm is peach on light and bark on dark, accent is the
+   * quiet green field either way. So "dark" is not a ground to pick, it is which half of the ground
+   * you picked gets used — and folding it into `background` would have made one value mean a register
+   * while the other four meant colours.
+   *
+   * It works by putting `.deck-dark` on the panel element itself. That class is a plain class in
+   * packages/tokens/deck/deck.css — bound alongside `.dark`, not scoped to a slide root — so every
+   * `--deck-*` role is re-declared AT the panel and everything inside inherits the dark values:
+   * prose, chips, alerts, charts, anything reading the roles. Nothing has to opt in a second time.
+   *
+   * ★ SCOPED TO THE FRAMES THAT BRING A FILL — `panel` and `code` — exactly as `background` is scoped to
+   * `panel`, and for a stronger reason. Those two paint a ground, so flipping the register repaints
+   * it under the ink. `photo`, `figure` and `content` bring no fill at all: the class would flip the
+   * INK to the dark register's near-white and leave it on the slide's own light ground.
+   *
+   * On `code` it is the whole point of a dark code surface: the ground is --slidev-code-background,
+   * which is register-aware, so the panel becomes the DARK well (--neutral-900) rather than a dark
+   * tint of the light one.
+   *
+   *
+   * ★★ AND THE RUNNING CHROME FOLLOWS IT, PER END. A bleeding dark panel leaves no ring of ground
+   * for the chrome to sit on, so the row lands directly on it and half the row is then over a dark
+   * ground while the other half is over a light one. Measured before that was answered: the page
+   * marker painted the LIGHT pill (forest-700) on forest-900, 1.09:1. `darkChromeParts()` in
+   * ../notch.js decides which end flips, from this same frontmatter, so the layout and the chrome
+   * cannot disagree about where the dark half is.
+   * The whole slide going dark is a different thing and has its own spelling: `dark: true`, which
+   * every layout that can carry a register now takes — `default`, `bleed`, `divider`, `split` and
+   * `stack`. `class: deck-dark` still works and is what the prop writes.
+   */
+  panelDark: { type: Boolean, default: false },
+  /**
+   * Draw this slide on the dark register. Writes `deck-dark` on the layout root — the same class and
+   * the same element split takes, said as a prop the layout documents rather than a raw class name
+   * an author had to know.
+   *
+   * Distinct from `panelDark`, which flips the BAND alone and leaves the strip below it on the light
+   * ground. This flips the whole slide, strip included, and the running chrome follows the slide
+   * rather than an end of it.
+   */
+  dark: { type: Boolean, default: false },
+  /**
+   * Mirror the layout: by default the band leads and the strip captions it from below; flipped, the
+   * strip is on top and the band sits under it.
+   *
+   * ★★ THE SAME KEY AND THE SAME DEFAULT AS `split`, which is the whole reason it is a Boolean. The
+   * two layouts invert deliberately, so any value naming a POSITION comes out opposite between them
+   * — content-first on split is content-last here. `false` means "this layout's own arrangement" on
+   * both, and that is the only thing they genuinely share.
+   *
+   * ⚠ IT MOVES THE CHROME, NOT JUST THE BOX. A band is full width, so whichever end of the slide it
+   * occupies is the end whose running chrome lands on it: unflipped that is the top row, and the
+   * notch cuts a seat for the mark; flipped it is the bottom row, and the seat is cut for the page
+   * marker instead. ../notch.js reads this same key so the layout and the chrome cannot disagree.
+   */
+  flip: { type: Boolean, default: false },
+  /**
+   * Where the band's content sits on the band's own vertical axis when it is shorter than the band.
+   * `center` is the default and what the band did before this was a prop.
+   *
+   * Split's two `title-*` values are deliberately absent — they align a heading beside the panel,
+   * and a stack's heading is in the strip below the band.
+   */
+  panelAlign: { type: String, default: 'center', validator: (a) => ['start', 'center', 'end'].includes(a) },
+  /** The figure's image URL. This is Slidev's own frontmatter key, used as Slidev means it: `extractImagesUsage()` harvests it and emits a `<link rel=preload as=image>`, so the URL belongs here rather than in an `<img>` a slide writes by hand. Slot content still wins when a slide provides its own figure. */
+  image: { type: String, default: '' },
+  /** Alt text — for `image` when there is one, and the label the `<Placeholder>` carries when there is not. */
+  alt: { type: String, default: '' },
+  /** Kicker above the heading, in the strip. */
+  eyebrow: { type: String, default: '' },
+});
+
+/*
+  The notch, and the two frontmatter keys that reach it — the same three questions split.vue asks,
+  through the same shared module, so the two layouts cannot disagree about whether this slide has a
+  cut or how wide it is. See ../notch.js.
+
+  Read the same two injections slide-top.vue reads, and for the same reasons documented there:
+  `injectionFrontmatter` is the RAW object (not a ref), and `injectionCurrentPage` — never
+  useNav().currentPage — is the only page number that is correct on the param-less /print and
+  /overview routes the PDF export renders through.
+*/
+const frontmatter = inject(injectionFrontmatter, {});
+const currentPage = inject(injectionCurrentPage, computed(() => 1));
+/*
+  ★★ EVERY BAND NOTCHES, INCLUDING A PHOTOGRAPH — and it did not always.
+
+  task-26 made a full-width photo band stand CLEAR of the chrome instead of cutting into it, because
+  a band spans the whole canvas so both ends of the chrome land on it, and the cut of the day only
+  seated the mark: the page marker and the section pill sat directly on a photograph whose corner
+  can be any colour.
+
+  useNotchCuts.js retired that. It measures EVERY running-chrome element on the band and cuts the
+  corner each one sits in, so both ends are seated and nothing depends on what is in the picture.
+  MEASURED on apps/deck's `frame: photo` band: the clip opens at `M 234.508 0` — the
+  top-left cut for the section pill, mirroring the top-right cut for the mark — and the deck audit
+  reports 0 text elements painted under an opaque media surface across the whole deck.
+
+  See ../notch.js's retirement note for the full history.
+*/
+/* `&& props.edge !== 'bleed'` here rather than inside hasNotch(), for the reason split.vue gives at
+   line: bleeding is a fact about this slide's band, not about the frame KIND, and that function's
+   arity is pinned by a test after it was once given an argument too many. */
+const notched = computed(() =>
+  props.edge === 'inset'
+  &&
+  hasNotch(props.frame, chromeShows(frontmatter, currentPage.value), notchShows(frontmatter)),
+);
+
+// The cut, measured — see ../useNotchCuts.js. A full-width band is the case that forced this: it
+// runs under BOTH top corners, so the mark and the section pill each land on it, and the pill's
+// width is a section name that no token could ever have stated.
+const bandEl = ref(null);
+const { clip: notchClip } = useNotchCuts(bandEl, { enabled: () => notched.value });
+const companion = computed(() => coBrandFitted(frontmatter, currentPage.value, deckTokens));
+const bandStyle = computed(() =>
+  notched.value && companion.value
+    ? { '--deck-notch-occupant-w': `${companion.value.occupantPx}px` }
+    : undefined,
+);
+</script>
+
+<template>
+  <div
+    class="slidev-layout stack h-full flex flex-col"
+    :class="[
+      RATIO_ROWS[ratio] ?? 'is-1-2',
+      FRAME_CLASS[frame] ?? 'is-panel',
+      edge === 'bleed' || edge === 'spill' ? 'is-bleed' : '',
+      edge === 'spill' ? 'is-spill' : '',
+      dark ? 'deck-dark' : '',
+      flip ? 'is-flipped' : '',
+    ]"
+  >
+    <div class="stack-grid">
+      <!--
+        ⚠ `deck-notch` WITHOUT `has-notch`, and that asymmetry is deliberate rather than an
+        oversight. `has-notch` is split.vue's own marker, and scripts/deckAudit.ts counts it: on any
+        non-split layout a `.has-notch` element is reported as "a notch cut with no panel to seat
+        it", so wearing the class here would fail the audit on every stack slide. The CUT is the
+        shared `deck-notch` rule in styles/base.css either way.
+
+        ★★ THE AUDIT HAS SINCE LEARNED ABOUT THIS LAYOUT, and the gap this note used to describe was
+        real for as long as it stood: because `has-notch` is 0 on every stack slide by design, the
+        only notch assertion a stack could reach was satisfied by construction, and all 15 stack
+        slides in the specimen went unmeasured while the summary read "0 notch-seating failure(s)".
+        deckAudit.ts now counts `.is-notched` as this layout's own marker and seats the band at BOTH
+        ends — mark right, section pill left, because a band is full width. Each marker is a defect
+        on the other layout, so the two cannot be crossed silently.
+
+        The background class rides on the BAND, not the root: it is the band's own ground, and the strip
+        below is cream by definition — the archetype is "colour band, cream title strip".
+      -->
+      <div
+        ref="bandEl"
+        class="stack-band"
+        :class="[
+          FRAME_CLASS[frame] ?? 'is-panel',
+          TONE_CLASS[background] ?? 'bg-warm',
+          PANEL_ALIGN_CLASS[panelAlign] ?? 'is-panel-center',
+          panelDark && (frame === 'panel' || frame === 'code') ? 'deck-dark' : '',
+          // A panel band paints its own fill, so markdown inside it needs the same bullet and
+          // marker protection every other own-ground surface gets — base.css keys those off this
+          // one class. Missing since the layout shipped, and invisible until a full-field band made
+          // a list on one the obvious thing to write: the bullet painted --deck-accent, which is
+          // the one green mark on a slide whose ink is the panel's.
+          // ⚠ NOT WHILE SPILLING. A spilling band is a STAGE, not a surface — the thing inside it
+          // leaves the band on one edge, so a fill behind it draws a box the object visibly ignores.
+          // `deck-own-ground` is what re-points bullets and markers to a panel's own ink, and with no
+          // fill there is no own ground to re-point to.
+          frame === 'panel' && edge !== 'spill' ? 'deck-own-ground' : '',
+          edge === 'bleed' || edge === 'spill' ? 'is-bleed' : '',
+          edge === 'spill' ? 'is-spill' : '',
+          notched ? 'deck-notch is-notched' : '',
+        ]"
+        data-notch-corner="right"
+        :style="[bandStyle, notchClip ? { clipPath: notchClip } : null]"
+      >
+        <slot name="band">
+          <img v-if="frame === 'photo' && image" :src="assetUrl(image)" :alt="alt">
+          <Placeholder v-else-if="frame === 'photo'" :label="alt || 'Image'" ratio="16:9" />
+        </slot>
+      </div>
+      <div class="stack-strip">
+        <p v-if="eyebrow" class="deck-eyebrow">{{ eyebrow }}</p>
+        <slot />
+      </div>
+    </div>
+  </div>
+</template>
+
+<style scoped>
+/*
+  VERTICAL is owned here: the layout's top and bottom bounds are a function of whether there is a
+  notch, which `.slidev-layout`'s single uniform padding cannot express. Horizontally nothing
+  changes: padding-left/-right stay --deck-inset-text (base.css), so the strip gets the measure
+  every other text box in the theme gets and the band claws back the 54px difference to reach
+  --deck-inset-media.
+
+  ★ THIS USED TO SAY "exactly as split.vue owns its own", AND SPLIT NO LONGER DOES. Split zeroed its
+  root so a `calc(100% / 3)` anchor had the canvas to resolve against; that anchor is a pixel now
+  and split is an ordinary padded box. The two layouts arrived at the same reset for different
+  reasons, and only stack's reason survives — its band is full-bleed and has to reach the media
+  inset at the TOP as well, unconditionally, which a padded root cannot express without a negative
+  margin on every band rather than only a notched one.
+
+  The known cost is the one split just paid: a root with no vertical padding makes every region
+  inside responsible for its own edge clearance, and nothing enforces that. `.stack-strip` below
+  carries such a reserve. It is correct today because stack has no third region beneath the strip
+  for it to collide with — if one is ever added, that reserve is the first thing to re-derive.
+*/
+.slidev-layout.stack {
+  padding-top: 0;
+  padding-bottom: 0;
+}
+.stack-grid {
+  flex: 1;
+  display: grid;
+  min-height: 0; /* lets the rows shrink instead of overflowing the slide */
+  /*
+    THE GAP between band and strip, and why it is NOT split's conditional gutter.
+
+    Split's rule is Jose's: "text one side, image other side: no gutter... both sides text or both
+    sides image: gutter 36px." A mixed HORIZONTAL pair needs no gutter because the text column
+    already carries --deck-inset-text on its own outer edge and a paragraph's ragged right supplies
+    the air on the inner one. Neither is true on the VERTICAL axis: a heading's box has no ragged
+    top, and a band's hard bottom edge would meet the cap-height of the h1 directly. So the mixed
+    pair takes a real gap here, and it is --deck-space-5 — one full grid unit, the same figure
+    --deck-heading-top-space uses for precisely this problem one layout over (air above a heading
+    that would otherwise read as flush).
+  */
+  row-gap: var(--deck-space-5);
+  /*
+    Two rows. Every ratio is content:figure — strip:band — so each rung names its two shares and the
+    TRACK ORDER is applied once, below: positional order is the flip's business and the ratio is not.
+    Written as two custom properties rather than a `grid-template-rows` pair per rung so that
+    mirroring costs one rule instead of a second copy of all eight.
+  */
+  --stack-band-fr: 2fr;
+  --stack-strip-fr: 1fr;
+  grid-template-rows: var(--stack-band-fr) var(--stack-strip-fr);
+}
+.is-1-1 .stack-grid { --stack-band-fr: 1fr; --stack-strip-fr: 1fr; }
+.is-3-2 .stack-grid { --stack-band-fr: 2fr; --stack-strip-fr: 3fr; }
+.is-2-3 .stack-grid { --stack-band-fr: 3fr; --stack-strip-fr: 2fr; }
+.is-2-1 .stack-grid { --stack-band-fr: 1fr; --stack-strip-fr: 2fr; }
+.is-1-2 .stack-grid { --stack-band-fr: 2fr; --stack-strip-fr: 1fr; }
+.is-3-1 .stack-grid { --stack-band-fr: 1fr; --stack-strip-fr: 3fr; }
+.is-1-3 .stack-grid { --stack-band-fr: 3fr; --stack-strip-fr: 1fr; }
+
+/* ── THE MIRROR ────────────────────────────────────────────────────────────────────────────────
+   The strip takes row 1 and the band row 2, and the track pair reverses with them so each region
+   keeps the share its rung gave it. Everything below that names an outer edge — the band's margin,
+   the notch lift, the strip's own bound — swaps ends too, because the layout's outer edge is the
+   only thing that moved. */
+.is-flipped .stack-grid { grid-template-rows: var(--stack-strip-fr) var(--stack-band-fr); }
+.is-flipped .stack-band { grid-row: 2; }
+.is-flipped .stack-strip { grid-row: 1; }
+.is-flipped .stack-band { margin-top: 0; margin-bottom: var(--deck-inset-text); }
+.is-flipped .stack-band.is-notched { margin-top: 0; margin-bottom: var(--deck-inset-chrome); }
+.is-flipped .stack-strip { padding-bottom: 0; padding-top: var(--deck-inset-text); }
+/* ★★ ONE ROW, NOT A 0fr SECOND ONE. `0fr` sizes a track by its own min-content, and the strip
+   carries `padding-bottom: --deck-inset-text` — so a zero-share strip would still reserve 96px and
+   the band would stop short of the field it is meant to fill. The strip is removed instead, and the
+   gap with it, since a gap only exists between two rows. */
+.is-0-1 .stack-grid { grid-template-rows: 1fr; gap: 0; }
+.is-0-1 .stack-strip { display: none; }
+/* The band owns both ends now. `.is-notched` already lifts the top to the chrome inset so the mark's
+   outer corner and the band's are one point; the bottom needs the same ring for the section pill,
+   which at every other rung is the strip's business. */
+.is-0-1 .stack-band { margin-bottom: var(--deck-inset-text); }
+.is-0-1 .stack-band.is-notched { margin-bottom: var(--deck-inset-chrome); }
+
+/*
+  THE BAND. Its own vertical bound is --deck-inset-text, the same 96px every figure in this theme
+  gets for free from the shared ancestor padding that this layout zeroed — restored as an explicit
+  MARGIN, not padding, so it positions the frame rather than shrinking the photograph inside it
+  (split.vue's figure makes the same distinction for the same reason).
+
+  Horizontally it claws back the 54px difference between the text inset it inherits and the media
+  inset a hard-edged figure wants — on BOTH edges, because a full-width band has two outer edges
+  where a split's figure has one. Negative margins rather than a wider box: the band sits in an
+  `fr`-sized grid row, so a margin shifts the rendered box without feeding back into track sizing.
+*/
+.stack-band {
+  grid-row: 1;
+  min-height: 0;
+  margin-top: var(--deck-inset-text);
+  margin-inline: calc(-1 * (var(--deck-inset-text) - var(--deck-inset-media)));
+}
+/* `frame: content` is the author's own content, not a figure — it keeps the TEXT inset, because
+   escaping it to the media inset would narrow the measure on the very edge --deck-inset-text
+   exists to protect. Same carve-out, same reasoning, as split.vue's. */
+.stack-band.is-content {
+  margin-inline: 0;
+}
+/* ★ THE BAND RISES TO MEET THE MARK — the notch's other half, and the reason chrome and media share
+   an inset (scripts/deck.ts, above INSET). At --deck-inset-text the mark and the band would overlap
+   by 18px, which is a nick rather than a seat; at --deck-inset-chrome the mark's outer corner and
+   the band's outer corner are the SAME POINT, with one uniform 36px ring — half slide margin, half
+   cut-out. Drops back to the text inset on `notch: false`, together with the cut and the
+   reservation, so an opted-out band has no raised top with nothing cut into it. */
+.stack-band.is-notched {
+  margin-top: var(--deck-inset-chrome);
+}
+/*
+  ★★ `bleed` — THE SAME BAND, AT THE CANVAS EDGE. The band already claws back to --deck-inset-media
+  on BOTH outer edges, because a band has two of them where split's figure has one; this gives up the
+  whole text inset instead, so left, right and top are 0, 1920 and 0. The strip below is untouched
+  and keeps its text inset.
+
+  The frame keeps its treatment: a photo band still crops, a panel band still carries its background. Only
+  the edges and the corner radius move, which is what makes this a modifier rather than a frame kind.
+
+  ⚠ NOT ON `.is-content` — the author's own block, which wants the text inset it already has.
+
+  It never notches (see the prop's note), so this rule and `.is-notched` above can never both apply;
+  it is written after it anyway so the margin-top needs no specificity fight to win.
+*/
+.stack-band.is-bleed:not(.is-content) {
+  margin-top: 0;
+  margin-inline: calc(-1 * var(--deck-inset-text));
+  border-radius: 0;
+}
+/*
+  ⚠ THE FLIPPED BAND KEEPS A BOTTOM MARGIN, so it stopped 96px short of the canvas — the rule above
+  zeroes the TOP, which is the edge an unflipped band bleeds by. Measured on the spill slides, which
+  are the first flipped bleeding bands in the book: the band ran to y 984 with cream under it, and
+  a window "cut by the bottom of the slide" was cut by a line inside it instead.
+*/
+.is-flipped .stack-band.is-bleed:not(.is-content) { margin-bottom: 0; }
+/*
+  ★★ THE BAND BLEEDS; THE CONTENT INSIDE IT MUST NOT. Same correction as split's, same reason: the
+  padding rode out with the box, so a bleeding panel band put its content at x 32 where the same band
+  unbled puts it at 68. Each bled edge gives the inset back, so the content lands where it would have
+  without the bleed and only the surface moves.
+
+  Only `panel` — a bleeding photo band is meant to be edge to edge, and `content` never bleeds.
+
+  ⚠ The top value here assumes no chrome above it; styles/base.css raises it when the chrome row is
+  drawn, because a scoped style cannot see `.slidev-page`.
+*/
+/*
+  ★★ A BLEEDING PANEL TAKES THE REGION INSET (96), NOT THE CARD INSET (68).
+
+  These gave the bled edge its inset back as padding — card pad 32 + media inset 36 — so the content
+  landed exactly where the same panel puts it unbled. Correct arithmetic, wrong premise: it treats a
+  bleeding panel as a card that happens to reach the edge. It is not one. A card's interior is inset
+  from its own EDGES, which are drawn; a bleeding panel has no drawn edge left, so its interior is
+  measuring against the canvas and against the seam with the content column — which is exactly the
+  situation a text column is in, and --deck-inset-text is the number for it.
+
+  MEASURED on the register-comparison split (specimen 124, split) before this, which is the slide that found
+  it. Seam at 960:
+
+      left  column   96 -> 864     96 from the canvas edge, 96 from the seam   768 wide
+      right panel  1028 -> 1852    68 from the seam, 68 from the canvas edge   824 wide
+
+  Both halves internally symmetric, and 56px apart from each other — so the same paragraph wrapped to
+  three lines on the left and two on the right, on a slide whose whole claim is that the register is
+  the only thing that differs. At the region inset both halves are 768 and the comparison is exact.
+
+  ⚠ Only when it BLEEDS. A panel sitting on the ground keeps --deck-card-pad: it has edges, and 96
+  inside a 924px card is a frame with a stamp in it. Jose asked whether the two sides should match and
+  what it would cost; the answer is 3 slides, all bleeding panels, because that is the only case where
+  a panel stops being a card.
+*/
+.stack-band.is-bleed.is-panel {
+  padding-top: var(--deck-inset-text);
+  padding-inline: var(--deck-inset-text);
+}
+/*
+  ══ SPILL ══════════════════════════════════════════════════════════════════════════════════════
+
+  ★★ THE BAND IS ALREADY A STRIP ACROSS THE FRAME, so what spills here is its HEIGHT. `bleed` takes
+  the band's box to the canvas on three sides and keeps everything inside it; `spill` lets the thing
+  inside grow past the bottom of the box and be cut by the slide — a browser window whose foot is
+  below the canvas, three device frames standing on the bottom edge.
+
+  ⚠ THE STRIP BELOW IS UNTOUCHED, which is the whole reason this is a band modifier rather than a
+  full-bleed layout: the words keep their row and their inset, and the picture behind them runs out
+  of the frame.
+*/
+/*
+  ⚠ THE SELECTOR CARRIES THE CLASSES IT HAS TO BEAT. Two rules outranked a plain `.stack-band.is-spill`
+  at equal specificity and source order decided both against it: `.stack-band.is-panel.bg-warm` kept
+  the band's peach fill, and `.stack-band.is-panel-center` kept the vertical centring — which put a
+  900px row of device frames 54px ABOVE the band's own top and cropped their heads as well as their
+  feet. Named here rather than fought with `!important`.
+*/
+.stack-band.is-spill.is-panel:not(.is-content),
+.stack-band.is-spill.is-panel-center:not(.is-content),
+.stack-band.is-spill:not(.is-content) {
+  /* The band stops clipping its own content — the SLIDE does the cropping, three rules down. */
+  overflow: visible;
+  align-items: flex-start;
+  /*
+    ★★ AND IT PAINTS NOTHING. Jose: "for the stack, no need to paint the panel". A band's fill says
+    "this strip is a surface"; a spilling band's content runs off the canvas, so the fill draws a box
+    the object plainly ignores — two edges that disagree about where the thing ends. The frame still
+    decides the CONTENT's treatment (a photo band still crops); only the surface goes.
+  */
+  background: none;
+  border: none;
+  /*
+    ⚠ THE BLEED'S PADDING COMES OFF THE BLOCK AXIS AND STAYS ON THE INLINE ONE, and the asymmetry is
+    the whole point of a spill. `is-bleed` gives the inset back as padding so the content lands where
+    it would have unbled — correct for a bleed, and on the TOP the exact opposite of what a spill
+    wants: measured, it started the window 132px below the band's own edge and the slide then cut a
+    window that had never reached the top.
+
+    ★ THE SIDES ARE NOT THE SAME CASE, WHICH TOOK GOING TOO FAR TO ESTABLISH. Zeroing all four ran
+    the window 0-1920 and it stopped reading as a window at all — Jose: "leave some padding at the
+    sides". A spill crops in ONE direction, and here that is downward; the inset on the other axis is
+    what keeps the object recognisable as an object rather than as a texture. So `padding-block`
+    rather than `padding`.
+
+    ★ THE TOP ALSO NEEDED A FIX ONE FILE AWAY. This declaration was being outranked by base.css's
+    chrome-clearance rule, whose `:has()` made it (0,8,0) against this rule's (0,5,0). That rule now
+    excludes `.is-spill` — see its own note — so this one is what decides the top again.
+  */
+  padding-block: 0;
+}
+/*
+  ★★ SPILL RELEASES THE CAPS; THE CONTENT STATES ITS OWN SIZE. Two sizing schemes were tried and both
+  were wrong for half the cases: `height: 128%` did nothing to a browser frame (it takes its height
+  from its own ratio — measured, the room stayed 433px in a 597px band), and `width: 128%` blew up a
+  row of device frames that were already taller than the band. What every spilling component has in
+  common is that it KNOWS its size — a map's `width`, a frame's `height` — and what the band was
+  doing was capping it. So the cap comes off and nothing is imposed.
+*/
+.stack-band.is-spill > :deep(*) {
+  max-width: none;
+  max-height: none;
+  /* ⚠ AND IT STILL HAS TO FILL THE BAND. The band is a flex row, so a grid inside it shrink-wraps to
+     its own tracks the moment nothing stretches it — measured with the caps off: the row of three
+     phones came out 1428 wide against a 1728 band and sat hard left, 96 of air on one side and 396
+     on the other. Grid's own `justify: center` used to supply the stretch as a side effect; this
+     states it instead, so the centring below has the full band to centre in. */
+  width: 100%;
+}
+/*
+  ⚠ AND ONE CAP HAS TO BE BROKEN BY NAME. BrowserFrame sizes its window so the WHOLE of it fits the
+  room's height — that is the component doing its job, and it is computed as a max-width because a
+  height cap does not travel back through `aspect-ratio` (its own note says so at length). A spilling
+  band is the one state where the window is meant to be taller than the room, so the cap comes off —
+  and ONLY the cap. At the band's own width a 16:9 window is 972px tall against a band of 597, so the
+  ratio does the spilling and the window stays a recognisable window.
+
+  ⚠ 128% WAS THE FIRST TRY AND IT WAS WRONG, which is worth keeping: a window wider than the canvas
+  loses both of its side edges, and what is left reads as a horizontal band with a URL in it rather
+  than as a browser. `--spill` is still the knob for a slide that wants more.
+*/
+.stack-band.is-spill :deep(.deck-browser-fit) {
+  max-width: none;
+  width: var(--spill, 100%);
+}
+/* ⚠ AND THE ROOM STOPS CENTRING IT. The room centres its window vertically, which is right when the
+   window fits and wrong the moment it does not: a 128% window centred in the band grew UPWARDS as
+   well, over the heading in the strip above. Anchored to the top, all of the growth leaves by the
+   bottom, which is the edge the slide is cropping. */
+.stack-band.is-spill :deep(.deck-browser-room) { justify-content: flex-start; }
+/*
+  ★★ AND A ROW OF FIXED-WIDTH OBJECTS CENTRES IN ITS TRACKS. Grid's own `justify` reaches INSIDE a
+  cell — `.is-justify-center > *` makes each cell a centred flex column — which is right when a cell
+  holds content and does nothing at all when the cell IS the object: with one device frame per cell,
+  that selector matches the phone itself and centres the phone's own children. Measured: three
+  frames flush against the left of their tracks, the group running 96 → 1724 in a 1920 frame, 96 of
+  air on one side and 196 on the other.
+
+  `justify-items` is the property that moves a fixed-width cell within its track, and it is scoped to
+  a spilling band rather than added to Grid because Grid's note argues against it for its own case:
+  a cell that shrink-wraps to its content leaves the content at the shrunken cell's edge. A device
+  frame does not shrink-wrap — its width comes from its height — so here it is exactly right.
+*/
+.stack-band.is-spill :deep(.deck-grid) { justify-items: center; }
+/*
+  ★★ THE SLIDE DOES THE CROPPING, AND IT HAS TO SAY SO — same note as split.vue's. Nothing on this
+  layout clipped before, so an overflowing band painted over the strip below it and past the canvas
+  into the deck's own page.
+*/
+.stack.is-spill { overflow: hidden; }
+
+/*
+  THE BAND OWNS ITS OWN TREATMENT, same contract as split's figure: an author writes the content and
+  nothing else and gets a filled, corner-clipped photo or a tinted panel. `object-fit: cover` rather
+  than a raw stretch is what makes filling safe for an <img> of any intrinsic ratio.
+*/
+.stack-band.is-photo {
+  border-radius: var(--deck-radius-card);
+  overflow: hidden;
+  display: flex;
+}
+.stack-band.is-photo :deep(img),
+.stack-band.is-photo :deep(video),
+.stack-band.is-photo :deep(picture) {
+  width: 100%;
+  height: 100%;
+  object-fit: cover;
+  display: block;
+}
+.stack-band.is-panel {
+  border-radius: var(--deck-radius-card);
+  /*
+    ★★ THE INLINE PADDING PUTS CONTENT ON THE TEXT INSET, NOT ON THE CARD PAD. The band claws back
+    to --deck-inset-media, 36px, so a uniform card pad landed its content at 68 — 28px left of where
+    the strip below it, and every slide without a band, puts theirs. Two text columns on one slide
+    that do not share a left edge. `--deck-inset-text - --deck-inset-media` is the difference the
+    band gave up, handed back as padding, so the content lands at 96 exactly as it would with no
+    band at all and only the SURFACE reaches wider.
+
+    The bleeding rule below already did this for its own case (it gives back the whole text inset
+    because it gave up the whole thing); this is the same correction for the unbled band, which is
+    the common one. Vertical stays the card pad — the band's height is the ratio's business, and the
+    notched rule raises the top on its own.
+  */
+  padding: var(--deck-card-pad) calc(var(--deck-inset-text) - var(--deck-inset-media));
+  display: flex;
+  /* A COLUMN that stretches, where split's panel is a centred row. The difference is what the two
+     hold: split's panel is a mat for one figure, this band is the slide's main content region — a Grid
+     of cards, a table, a timeline — all of which want the full width and do their own internal
+     alignment.
+
+     The vertical placement of a block SHORTER than the band is `panelAlign`'s, in the three rules
+     below. It used to be a bare `justify-content: center` here, which was the default with no way
+     to say anything else. */
+  flex-direction: column;
+  align-items: stretch;
+}
+
+/* `panelAlign` — where a block shorter than the band sits on the band's own axis. Only meaningful
+   on a frame that HAS a band box to sit in; `content` brings its own and is unaffected. */
+.stack-band.is-panel-start  { justify-content: flex-start; }
+.stack-band.is-panel-center { justify-content: center; }
+.stack-band.is-panel-end    { justify-content: flex-end; }
+/* Media matted inside a panel takes the CONCENTRIC radius — the card's corner minus its padding —
+   and opts back OUT of the stretch above, because an <img> stretched to a band's full width is
+   distorted rather than filled. */
+/*
+  ── A CODE SURFACE ────────────────────────────────────────────────────────────────────────────
+  The panel IS the block. It takes the code ground and its own edge, and the `pre` inside goes flat,
+  so a code slide is ONE surface rather than a well inside a mat. See the `frame` prop's own note for
+  why this is a named value rather than a `:has()` on `panel`.
+
+  The inner reset is the same three declarations the magic-move container has always used on its own
+  `pre.shiki`, for the same reason: a container that owns the surface must strip the one its child
+  would otherwise draw, or the two edges sit 4px apart and read as a mistake.
+*/
+.stack-band.is-code {
+  background: var(--slidev-code-background);
+  border: 1px solid var(--deck-code-border);
+  border-radius: var(--deck-radius-card);
+  padding: var(--deck-card-pad);
+  display: flex;
+  flex-direction: column;
+  justify-content: center;
+  min-width: 0;
+}
+/*
+  ★★ THE PADDING IS ZEROED AT ITS SOURCE, NOT OVERRIDDEN — one cause, two effects.
+
+  The obvious way to flatten the block is `padding: 0 !important` (Slidev's own rule carries
+  `!important`, so nothing less wins). It works, and it leaves a 24px horizontal scrollbar on every
+  code frame, because a SECOND rule reads the same token: base.css sizes each line
+
+      width: calc(100% + space-1 + space-2 + var(--slidev-code-padding))
+
+  so the row overhangs to the right by exactly the block's own right padding, which is what lets a
+  lit band reach both padding edges. Flatten the padding without telling that rule and the overhang
+  has nothing left to fill: measured on this frame, scrollWidth 965 against clientWidth 941 — the
+  token, to the pixel.
+
+  Setting `--slidev-code-padding: 0px` collapses both at once: Slidev's padding resolves to zero with
+  no `!important` needed, and the line's overhang term goes with it. The surface's own inset is the
+  panel's, which is the whole point of the frame.
+*/
+.stack-band.is-code {
+  --slidev-code-padding: 0px;
+}
+.stack-band.is-code :deep(.slidev-code-wrapper),
+.stack-band.is-code :deep(pre.slidev-code) {
+  margin: 0 !important;
+  background: none;
+  border: none;
+  border-radius: 0;
+}
+/*
+  ★★ AN EDGE AND A CLIP CANNOT SHARE AN ELEMENT. `clip-path` cuts the rendered box, border included,
+  so a notched code surface drew its edge continuously on three sides and then simply lost it around
+  the cut — a frame that stops. Measured on the specimen's own pair: `border: 1px` and a clip-path on
+  the same figure.
+
+  The border is what a code surface has when it is a CARD on the slide. Notched, its outer corner is
+  the mark's seat rather than a corner; bleeding, there is no ground for it to sit on at all. Neither
+  is a card, so neither takes an edge. `panel` never hit this because it has no border to lose.
+*/
+.stack-band.is-code.is-notched {
+  border: none;
+  padding-bottom: var(--deck-card-pad);
+}
+/* Bleeding, it is a REGION like every other bleeding panel — the region inset on all four sides, so
+   the code lines up with a content column across the seam. See the note above the panel's own. */
+.stack-band.is-code.is-bleed {
+  border: none;
+  border-radius: 0;
+  padding: var(--deck-inset-text) var(--deck-card-pad);
+}
+
+/*
+  ⚠ `:not(.mark-pair-companion)`. A co-branding tile is not matted media: MarkPair clips the
+  partner's artwork to the MARK's corner — a ratio of the tile — and this rule outranked it
+  (`.stack-band.is-panel[data-v-…] img` beats a single class), so a pair dropped into a panel came out with
+  the panel's 16px nested radius on one half and the mark's on the other. Measured on the specimen's
+  own MarkPair slide: 31.49px on the light half, 16px on the dark one, same component, same size.
+  slide-top.vue carries the same exclusion for the same reason.
+*/
+.stack-band.is-panel :deep(img:not(.mark-pair-companion)),
+.stack-band.is-panel :deep(video),
+.stack-band.is-panel :deep(picture) {
+  max-width: 100%;
+  align-self: center;
+  border-radius: var(--deck-radius-nested);
+  display: block;
+}
+/*
+  ⚠ MASKING CLIPS, IT DOES NOT REFLOW — so a band holding real content reserves the cut's height as
+  top padding, never less than the card padding it already had. Identical guarantee, identical
+  mechanism and identical reason as split.vue's `.is-panel.has-notch`: a band a mask has bitten into
+  would otherwise slice the corner off a card. `.is-photo` deliberately gets none of it — clipping
+  the photograph IS the effect.
+*/
+/*
+  ★★ RESERVED AT BOTH ENDS, THE SAME WAY split's PANEL IS, AND FOR THE SAME MEASURED REASON.
+
+  The top reservation is the notch: content must clear the bite cut for the running chrome, so the
+  band keeps `--notch-h` (mark 72 + ring 24 = 96) above it. Only the top was reserved, leaving the
+  box 96/32 — so anything this band centres lands (96 - 32) / 2 = 32px LOW inside it. Measured across
+  five notched band slides, every one off by exactly 32:
+
+      slide 23   band 36-416   content 132-384   96 above, 32 below
+      slide 56   band 36-780   content 375-505  339 above, 275 below
+      slide 60   band 36-416   content 193-323  157 above,  93 below
+
+  ⚠ AND THE ARGUMENT FOR LEAVING THIS ONE ALONE WAS WRONG. It was "a band is full width and holds
+  full-width content, so it is less likely to look wrong" — which is about HORIZONTAL extent and has
+  nothing to do with a vertical offset. Slide 56 is the proof: 130px of content floating in a 744px
+  band is the most visible case in the deck, not the least.
+
+  The bottom padding buys nothing but symmetry — there is no notch down there — and that is the
+  point: the box this band centres in now shares its centre with the band a viewer sees.
+*/
+.stack-band.is-panel.is-notched {
+  padding-top: max(var(--deck-card-pad), var(--notch-h));
+  padding-bottom: max(var(--deck-card-pad), var(--notch-h));
+}
+
+/* ── The band's two registers ─────────────────────────────────────────────────────────────
+   The four named backgrounds, each a fill AND the ink published with it — so a band can never put an
+   ink on a fill that was not measured against it. They are the same four split.vue's panel takes, so
+   a stack band and a split panel in the same deck read as the same object.
+
+   ⚠ THIS DESCRIBED A PALETTE THAT NO LONGER EXISTS. It named 'soft' (--deck-accent-soft), 'subtle'
+   (--deck-bg-subtle), --warm-100 and --forest-300, from when a band picked a loose fill and kept the
+   slide's own ink. The rules below take --deck-bg-<name> / --deck-on-bg-<name>: one table, four
+   names, fill and ink together. See the ★★ note at the top of this file for the grounds that are
+   deliberately not offered, and the contrast numbers behind it. */
+.stack-band.is-panel.bg-warm { background: var(--deck-bg-warm); color: var(--deck-on-bg-warm); }
+.stack-band.is-panel.bg-accent { background: var(--deck-bg-accent); color: var(--deck-on-bg-accent); }
+.stack-band.is-panel.bg-vivid { background: var(--deck-bg-vivid); color: var(--deck-on-bg-vivid); }
+.stack-band.is-panel.bg-neutral { background: var(--deck-bg-neutral); color: var(--deck-on-bg-neutral); }
+/*
+  Two further grounds, added after the mint was judged to sit badly against the deck's ground — and
+  it does so for a reason the contrast table above could not show: --deck-bg is --warm-50, a WARM
+  cream, while forest-100 is a COOL mint. The table only ever asked "can the pill be seen", which
+  both pass; temperature is a separate question and the mint loses it.
+
+  'warm'  — --warm-100, the ground's own family one step up. Same temperature, so the band reads as
+            a deeper pour of the slide rather than a different material laid on top.
+  'vivid' — --forest-300. This is as green as this layout can legally go: the running page pill is
+            --deck-bg-vivid-dark (forest-700, #046C4C) and lands ON the band, so the band is bounded
+            by the 3:1 non-text floor against that fill. Measured against the same pill:
+
+                warm-100  peach cream   5.32:1  ✓
+                forest-200 deeper mint  4.53:1  ✓
+                forest-300 emerald      3.55:1  ✓   <- 'vivid', the last rung that clears
+                forest-700 brand green  1.00:1  ✗   the pill IS the ground; it vanishes
+                forest-950 dark         2.40:1  ✗
+
+            So "just use the brand green" is not available here, and the reason is structural rather
+            than aesthetic: the chrome cannot re-tone itself per layout (frontmatter.static.test.ts,
+            "names no layout, in any form"). A slide that wants a full-field forest-700 has `divider`,
+            which owns the whole canvas and ships chrome: false.
+*/
+
+/*
+  THE STRIP — the title, subordinated. Top-aligned in its own row (it captions the band above it, so
+  it belongs against it rather than floating in the middle of what is left), and carrying the same
+  --deck-inset-text bottom bound every other text box in the theme has, which is also what keeps it
+  clear of the confidentiality pill's band.
+*/
+.stack-strip {
+  grid-row: 2;
+  min-width: 0;
+  min-height: 0;
+  padding-bottom: var(--deck-inset-text);
+}
+/* The strip is a caption-scale region, not a full slide of prose: two tiers of content in a third
+   of the canvas. The dense body tier, same as split's two columns, for the same reason. */
+.stack-strip { font-size: var(--type-deck-body-sm-size); line-height: var(--type-deck-body-sm-line-height); }
+</style>