@humanforest/slidev-theme 0.1.0

package/layouts/split.vue

@@ -0,0 +1,1875 @@
+<script setup>
+/*
+  The workhorse. Content on one side, a figure on the other — five of the reference deck's eleven
+  archetypes are this layout with different slot content.
+
+  ★★ THE FIGURE IS `image` (A URL) + `alt` (THE TEXT), AND `image` IS SLIDEV'S OWN KEY.
+
+  It is not `src`: that is in Slidev's FRONTMATTER_FIELDS and would be stripped before frontmatter
+  ever became a prop. `image` was briefly used for the ALT TEXT, which broke on Slidev 52 — its
+  extractImagesUsage() harvests frontmatter `image` as a URL and emits a <link rel=preload
+  as=image>, so all ten of the specimen deck's alt strings became preloads for paths like
+  `/A woman cycling on a city road in daylight`.
+
+  The fix was to use the key the way Slidev does, not to dodge it: `image` holds the URL, this
+  layout renders the <img>, and the preload is then correct rather than a collision. `image` is
+  therefore NOT on test/props.ts's reserved list — it is the name to use, not one to avoid.
+
+  ★ ONE image prop is the ceiling, and it is Slidev's, not a preference. extractImagesUsage()
+  (@slidev/parser core.mjs) iterates the literal list ["image", "backgroundImage", "background"]
+  and guards on `typeof val === 'string'`. MEASURED against the installed parser: a second key
+  (`image2`) is preloaded 0 times, and an `images: [a, b]` ARRAY fails the typeof guard and
+  preloads NEITHER — it silently costs the first image its preload too. A slide that needs a second
+  photograph writes markdown `![alt](url)` in the slot, which IS harvested (unconditionally, so a
+  query string survives) and does preload.
+*/
+
+// Vue strips prop validators from a production build, so an out-of-range value (e.g. `ratio:
+// '5:7'`, an AI's typo) would otherwise reach the template raw and build a class name (`is-5-7`)
+// with no matching CSS rule — an unstyled grid, invisible until an overflow shows up in the audit.
+// This lookup clamps the value the template actually renders, independent of the validator below.
+const RATIO_CLASS = {
+  '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',
+};
+
+/*
+  ★ THE MEDIA KIND IS A FACT ABOUT THE SLIDE, not only about the figure — so it is stamped on the
+  ROOT as well as on the figure, and clamped through a lookup for the same reason `ratio` is.
+
+  This is a fix, not a tidy-up. task-14b's conditional gutter is written `.is-content .split-grid` — a
+  DESCENDANT selector — but `is-content` was only ever put on `.split-figure`, which is a descendant of
+  `.split-grid`, not an ancestor. The rule therefore never matched anything, and every same-kind
+  split has been rendering with the mixed-kind zero gutter since. Measured live on
+  apps/deck-template's own two-column slide: two 870px columns in a 1740px row, i.e. no gap at all,
+  where the same-kind rule asks for a real gutter (36px at the time; the token is 96 now). Static
+  tests could not see it — deckInsets.static.test.ts asserts the rule EXISTS in the source, which it
+  did, correctly written, against a class that was never in the right place for it to match.
+*/
+/*
+  ★ FOUR VALUES, AND `anchor` IS ONE OF THEM RATHER THAN THE ABSENCE OF THE OTHER THREE. Split's
+  text column has always started at the one-third line (see --deck-anchor-third and the note on
+  .split-grid) so headings do not jump between slides. That is the right default and stays it, but
+  it is not `start`, so it needs a name of its own — otherwise the enum would have three values and
+  a fourth unnamed state you get by omitting the prop, which is exactly the shape `frame: none` was.
+*/
+const ALIGN_CLASS = {
+  anchor: 'is-align-anchor',
+  start: 'is-align-start',
+  center: 'is-align-center',
+  'body-center': 'is-align-body-center',
+  end: 'is-align-end',
+};
+/* `anchor` has no meaning on a panel — it is the deck's one-third line, which the text column
+   stands on and a filled frame does not — so this vocabulary is the other three. */
+const PANEL_ALIGN_CLASS = {
+  start: 'is-panel-align-start',
+  'title-start': 'is-panel-align-title-start',
+  center: 'is-panel-align-center',
+  'title-center': 'is-panel-align-title-center',
+  end: 'is-panel-align-end',
+};
+/* The two rungs that hold a heading's height back before aligning what is left. */
+const BANDED_ALIGNS = new Set(['title-start', 'title-center']);
+
+/*
+  The panel's register, and the same four stack's band takes. Split did not have this axis at all —
+  its panel was one hardcoded fill — so `frame: 'panel'` meant a different surface in each layout.
+  The values, the class names and the four rules below are stack's, read from the same tokens.
+*/
+/*
+  ★★ 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',
+};
+
+/*
+  The text tier the two columns run at. `base` is the deck's body role, the same 48px every other
+  layout sets; `sm` steps the whole grid down to `body-sm` for a slide that genuinely has more to
+  say than the column holds at full size.
+*/
+const BODY_CLASS = {
+  base: 'is-body-base',
+  sm: 'is-body-sm',
+};
+
+const FRAME_CLASS = {
+  photo: 'is-photo',
+  panel: 'is-panel',
+  code: 'is-code',
+  figure: 'is-figure',
+  content: 'is-content',
+};
+
+import { computed, inject, onBeforeUnmount, onMounted, ref, watch } 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({
+  /** Content's share of the row against the figure's — e.g. '3:2' gives content the bigger half, '2:3' gives the figure the bigger half. Content-relative: independent of `flip`, so swapping sides never changes which one is bigger. The ladder stops at `3:1` because the share IS the content column's measure here, and the rung below that is narrower than a line wants. `stack` carries two rungs this does not — `1:3`, a band that dominates harder than two thirds, and `0:1`, the band with no strip at all — because a full-width band is the shape that needs them. */
+  ratio: {
+    type: String,
+    default: '1:1',
+    // Inlined rather than reading RATIO_CLASS: 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_CLASS anyway, which is what
+    // actually protects a real deck, since validators are stripped from production builds.
+    validator: (r) => ['1:1', '3:2', '2:3', '2:1', '1:2', '3:1'].includes(r),
+  },
+  /**
+   * Mirror the layout: by default the content takes the left column and the figure the right; flipped, they swap.
+   * A pure mirror — it does not affect either one's share (see `ratio`), only where each appears.
+   *
+   * ★★ A BOOLEAN, AND SHARED WITH `stack` — which is the only shape that gives the two layouts one
+   * key with one DEFAULT. They invert deliberately (split leads with the title, stack subordinates
+   * it), so any value that names a POSITION comes out opposite between them: content-first on one
+   * is content-last on the other. `false` means "this layout's own arrangement" on both, and that
+   * is the only thing they genuinely share — there is no word for "figure right" and "band top" at
+   * once. It replaced `flip`, which had no third value in prospect either.
+   *
+   * ⚠ IT IS RELATIVE, WHICH IS THE TRADE. `flip: true` said where the content went; `flip` says
+   * "the other way from the default", so reading a slide needs the default in hand — and reversing
+   * a layout's default would silently change every flipped slide. The defaults are doctrine and do
+   * not move, which is what makes that acceptable.
+   */
+  flip: { type: Boolean, default: false },
+  /**
+   * 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 far side is FRAMED: clipped as a photo, matted in a tinted panel, left bare for a
+   * figure centred in the cell, or not a figure at all — a second column of content.
+   *
+   * ★★ THIS PROP WAS CALLED `frame`, AND HALF ITS VALUES WERE NOT MEDIA. `content` is a second
+   * column of the author's own prose and `figure` is any component; only `photo` and `panel` frame
+   * media at all. Worse, `content` was called `none` — a positive behaviour (36px gutter, dropped
+   * to row 2, header spanning both columns) named as an absence, which cost a real bug: a live map
+   * declared `frame: content`, inherited the prose treatment, and began a third of the way down the
+   * slide with the space above it empty. `figure` had to be invented to separate the two jobs.
+   *
+   * Under the honest names the four are plainly four things: `photo` fills and crops to the card
+   * shape, `panel` centres at natural size inside a tinted card, `figure` is CAPPED to the cell and
+   * centred with no treatment at all, and `content` is not a figure at all.
+   *
+   * ⚠ THAT LINE USED TO READ "`figure` fills with no treatment", WHICH IS THE ONE THING IT DOES NOT
+   * DO — and it is the sentence an author reads when choosing. `.is-figure` centres its child and
+   * caps it on both axes (see the rule and its note further down); a child that wants the whole
+   * cell has to ask with its own height, and even then the cap is what it is measured against.
+   * Measured on the map-as-evidence slide: at `figure` a map declaring `height: 100%` drew 816px in
+   * a 1008px cell, centred with 96 above and below; at `photo` it drew 1008. The difference that
+   * matters when picking between the two is CROPPING — `photo` fills and cuts what does not fit,
+   * `figure` shows the whole thing and letterboxes.
+   *
+   * ★★ THE DEFAULT WAS `content`, AND IT WAS WRONG FOR EVERY PRESET THAT RELIED ON IT. Four do —
+   * `split` ("body copy beside a figure"), `map`, `map-inset` and `trend` — and all four want a
+   * figure. Measured on deck-template before this changed: every one rendered `is-content`, took
+   * the 36px same-kind gutter, and dropped its figure to grid row 2 starting at canvas y 360. That
+   * is the prose treatment, and a map or a chart starting a third of the way down with empty space
+   * above it is the exact failure the `figure` value was invented to fix — shipping by default on
+   * the recipes most likely to be copied.
+   *
+   * `figure` is the neutral one: it is centred in its cell and given no treatment. A layout called `split`
+   * that is given no further instruction should put something beside the words, not assume the
+   * far side is more words — that is the case worth stating explicitly, and six presets do.
+   *
+   * ★★ AND THE SLOT IS `aside`, NOT `right`, FOR THE SAME REASON THIS PROP IS NOT CALLED `media`.
+   * `right` named a POSITION the slot does not control: `flip` decides which half each column
+   * takes, so on `flip: true` the content moves right and the slot called `right` renders on the
+   * LEFT. Measured on deck-template's `chart-right`, which is exactly that combination — the
+   * ::right:: slot came out at grid column 1, left edge 96, while the content sat at 978.
+   *
+   * `figure` was the obvious replacement and is wrong the same way one level down: it would name a
+   * CONTENT KIND the slot does not control either, and at `frame: content` that slot holds a second
+   * column of prose. `aside` names the REGION, which is the one thing that never moves — split is
+   * always two columns and this is always the one the content is not in.
+   */
+  frame: { type: String, default: 'figure', validator: (f) => ['photo', 'panel', 'figure', 'content', 'code'].includes(f) },
+  /**
+   * Take the figure to the CANVAS EDGE instead of the 36px media inset — same frame, same fill, same
+   * content, no ring of ground around it.
+   *
+   * A MODIFIER, not a fifth `frame`, because it is orthogonal to what the figure IS. A photo, a
+   * tinted panel and a component figure can each want the edge, and each keeps its own treatment
+   * when it goes there; a fifth enum value would have had to pick one of the three and would have
+   * made the other two unreachable. Inert on `frame: content`, which is a column of the author's own
+   * prose and wants the text inset it already has.
+   *
+   * `inset` keeps the ring of ground around the figure; `bleed` takes it to the canvas.
+   *
+   * ⚠ IT IS ONLY VISIBLE ON A FRAME THAT PAINTS A GROUND. What this gives up is the RING of deck
+   * ground around the figure, so on `photo`, `panel` and `code` — the three that paint one — the
+   * difference is the whole point of the slide. On this layout's DEFAULT frame, `figure`, there is
+   * no ground to give up: the box still reaches the canvas, but nothing about it is drawn, so the
+   * two values look nearly alike. Measured on a specimen pair that took the default and had to be
+   * moved to `panel` before it showed anything. Choose the frame before blaming the prop.
+   *
+   * ★ 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, and that is arithmetic rather than a preference. The cut exists
+   * to seat the running mark in the ring of ground around the figure; at inset 0 there is no ring,
+   * so there is nothing to bite. The chrome is then drawn OVER the figure — pair it with
+   * `chrome: false`, or use the `bleed` LAYOUT, whose scrim solves that across the whole canvas.
+   */
+  /*
+   * ★★ `spill` IS `bleed` PLUS ONE MORE STEP, AND THE STEP IS THE POINT. `bleed` takes the figure's
+   * BOX to the canvas and then gives the inset back as padding, so the content lands exactly where
+   * it would have unbled — the frame changes, the thing inside it does not. `spill` takes the box
+   * there and lets what is inside run PAST it: a map drawn at half again the column's width, a
+   * render whose front wheel leaves the slide, a browser window whose foot is below the canvas.
+   *
+   * The cover's mosaic proved the move — a grid of pictures cut by two edges reads as a field the
+   * slide is a window onto, where the same pictures matted read as a gallery. This is that, for a
+   * figure a deck already has.
+   *
+   * ⚠ IT IS A CROP, SO WHAT IT CROPS HAS TO BE WORTH CROPPING. A photograph spills badly: the
+   * subject is what the picture is FOR, and pushing it off the edge is just a smaller photograph.
+   * What spills well is a thing with no single subject — a map, a repeating grid, a product render
+   * whose silhouette is legible from a third of it, a device or browser frame whose chrome is the
+   * shape being shown.
+   */
+  edge: { type: String, default: 'inset', validator: (e) => ['inset', 'bleed', 'spill'].includes(e) },
+  /**
+   * The panel's register, for `frame: panel` only — exactly as on `stack`, whose band takes the same
+   * four. 'warm' is the deck's own mat; 'subtle' is the quiet grey fill; 'soft' is the accent tint;
+   * 'vivid' is the saturated one.
+   *
+   * ★ IT HAS NO EFFECT ON ANY OTHER FRAME, and that is scoped in the CSS rather than guarded here:
+   * every rule is `.split-figure.is-panel.tone-*`, so a photo or a figure carrying a tone renders
+   * exactly as it would without one. stack states the same thing about its own.
+   */
+  background: { type: String, default: 'warm', validator: (t) => ['warm', 'accent', 'vivid', 'neutral'].includes(t) },
+  /**
+   * The text tier both columns run at — `base` (the deck's body role, 48px) or `sm` (`body-sm`,
+   * 36px, the dense tier).
+   *
+   * ★ THE DEFAULT IS `base`, AND IT USED TO BE THE ONLY BEHAVIOUR — the wrong one. This grid was
+   * pinned to body-sm on the reasoning that "two columns halve the measure, so both sides take the
+   * dense body tier". The measure being halved is exactly why the TIER should not be: a slide's
+   * body is 48px because that is what carries a room, and a column is not a reason for the back row
+   * to get 36. A narrow column simply wraps sooner, which is what a column is for.
+   *
+   * `sm` is the escape hatch for the case that argument does not cover: a slide whose column really
+   * does hold more than 48px allows and cannot be split in two. It is a deliberate, per-slide
+   * decision now rather than something every split inherited without asking.
+   */
+  body: { type: String, default: 'base', validator: (b) => ['base', 'sm'].includes(b) },
+  /**
+   * Where the CONTENT column sits vertically. `anchor` is the deck's own one-third line — the
+   * default, and the reason headings do not jump between consecutive split slides. `start`, `center`
+   * and `end` are the vocabulary `bleed` and `statement` already use.
+   *
+   * `body-center` is the fifth and moves the column in two pieces rather than as a block: the
+   * HEADING keeps the top and everything under it centres in what is left. It is default.vue's mode
+   * of the same name, and it is the COLUMN'S HALF OF A PAIR — set it beside `panelAlign:
+   * title-center` and both sides of the slide read the same way, a title at the top with the
+   * substance centred in the space below it on each side. See the CSS rule for the auto margins
+   * that do it and why there are three of them.
+   *
+   * ★ THE FIGURE IS UNAFFECTED BY ALL FIVE: it spans `grid-row: 1 / 3`, so it fills the frame
+   * whatever the content does. Aligning what sits INSIDE the figure is `panelAlign`, a separate prop
+   * for a separate box — its own doc says why they cannot be one.
+   */
+  align: {
+    type: String,
+    default: 'anchor',
+    validator: (a) => ['anchor', 'start', 'center', 'body-center', 'end'].includes(a),
+  },
+  /**
+   * Where the PANEL's own content sits vertically — `align` for the other half of the slide.
+   *
+   * Two of the five hold a band the height of the slide's h1 back before aligning what is left, so
+   * the panel reads against the column's BODY rather than against the whole column: `title-start`
+   * begins where that body begins, and `title-center` centres in the space under the band. Both
+   * work on every panel — plain, notched, bleeding — because the band is a margin on the panel's
+   * content rather than an addition to a top padding four different rules can decide, and both
+   * measure the real heading rather than deriving one, so a two-line title moves them too.
+   *
+   * There is no `title-end`: a top margin cannot move an item already pinned to the bottom, so it
+   * would be `end` under another name.
+   *
+   * `title-center` has a companion on the other half: `align: body-center` gives the COLUMN the same
+   * reading — heading at the top, body centred in what is left — and the two are meant to be set
+   * together on a slide that wants both sides to say it.
+   *
+   * ★★ IT IS A SECOND PROP BECAUSE THEY ARE TWO BOXES, NOT ONE. `align` moves the content column
+   * inside the grid band; a panel holds its children inside its own padding box, and on a bleeding
+   * panel that box starts lower than the band because the frame reaches the canvas edge and pads to
+   * clear the chrome. Two boxes with the same bottom and different tops give two different centres —
+   * 18px apart, measured — so a slide whose halves read as ROWS across the seam cannot get there by
+   * centring both. Setting both to `end` stands them on the bottom edge they already share, which
+   * needs no number and survives one half carrying a heading the other does not.
+   *
+   * Folding it into `align` was the alternative and would have moved every panel split in the deck,
+   * on a prop whose own documentation promises the figure is left alone.
+   *
+   * ★ SCOPED TO `panel`, as `background` is: it is the frame that holds content in a box of its own. A
+   * `code` frame stacks its children in a column, where the vertical axis is `justify-content`
+   * rather than `align-items`, and `photo`/`figure`/`content` have nothing to align.
+   */
+  panelAlign: { type: String, default: 'center', validator: (a) => ['start', 'title-start', 'center', 'title-center', 'end'].includes(a) },
+  /**
+   * 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,
+   * the same element, said as a prop the layout documents rather than a raw class name an author
+   * had to know. `default` and `bleed` already spelled it this way; split did not, so a split slide
+   * was the one place in the deck where the register had to be written as `class: 'deck-dark'`.
+   *
+   * ★★ NOT `panelDark`, WHICH IS THE PROP ABOVE AND A DIFFERENT AXIS. That one darkens the PANEL's
+   * own fill on an otherwise light slide — a dark card on cream. This darkens the SLIDE, and the
+   * panel follows it like everything else. Both can be set; they answer different questions.
+   *
+   * ⚠ A LIVE MAP DOES NOT FOLLOW IT. The register is CSS custom properties and a Mapbox basemap is
+   * painted in WebGL from its own style, so a `dark` split slide carrying a map also needs
+   * `light-preset: night` on the map. DeckMap's own prop doc says the same from the other side.
+   */
+  dark: { type: Boolean, default: false },
+  /** 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: '' },
+  /**
+   * TWO pictures instead of a picture and a column of prose — `[{ image, alt }, { image, alt }]`,
+   * content side first. One `image` is a figure; two here is a PAIR, and the content column becomes
+   * the second one.
+   *
+   * ★★ THE SAME KEY SHAPE THE MOSAIC USES, rather than a directional `imageLeft`. "Left" flips with
+   * `flip`, so a slide that set it and then mirrored would have had its two pictures swap meaning
+   * silently; content-first is the order every other prop on this layout is read in (`ratio` is
+   * content-first, and so is `frame`).
+   *
+   * ⚠ TWO, THREE OR FOUR. Two is a picture per column; three stacks the extra in the figure column;
+   * four is two and two. The split is `floor(n / 2)` to the content side, so the figure column — the
+   * one with no measure to protect — takes the odd one. One entry is `image` with extra steps and a
+   * fifth has nowhere to go without a grid this layout does not have, so the list clamps at four.
+   *
+   * ★ THE SLOT STILL WINS where it is written: a pair is what an author gets when they hand the
+   * layout two pictures and no words, which is what a diptych IS. Text in the default slot alongside
+   * a pair renders over the second picture, and that is the author's own decision to make.
+   */
+  images: { type: Array, default: () => [] },
+  /**
+   * How the pictures of a set are separated: by the layout's own seam (`gap`, the default) or not at
+   * all (`flush`), where they meet and the set reads as one field cut into pieces.
+   *
+   * ★★ A SECOND AXIS, NOT A THIRD `edge` VALUE. `edge` is about the figure and the CANVAS — where
+   * the outer edges land. This is about the pictures and EACH OTHER. They cross: a flush set still
+   * insets from the canvas by default, and `edge: bleed` with `seam: gap` is four pictures at the
+   * canvas edge with the deck's own seam still between them.
+   *
+   * ⚠ FLUSH TAKES THE INNER CORNERS OFF AND KEEPS THE OUTER ONES. A rounded corner where two
+   * pictures meet draws a lens of ground between them and the set stops reading as one field; the
+   * corners on the OUTSIDE are the set's own edge against the slide, and squaring those makes a
+   * bleeding rectangle of a thing that has not bled. Inert unless `images` holds a set — a single
+   * figure has nothing to be flush WITH.
+   */
+  seam: { type: String, default: 'gap', validator: (g) => ['gap', 'flush'].includes(g) },
+  /** Kicker above the heading. */
+  eyebrow: { type: String, default: '' },
+});
+
+/*
+  task-15-brief.md — THE NOTCH IS CONDITIONAL ON ITS OCCUPANT EXISTING.
+
+  The cut only happens when the running chrome is actually drawing a mark to put in it: a notch on
+  a `chrome: false` slide is a hole with nothing in it, which is the brief's own named failure case.
+  The predicate is ../notch.js's, not a second copy — slide-top.vue gates its own render on the
+  same function, so the two cannot disagree about whether there is a mark on this slide.
+
+  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));
+// task-18 — `notch: false` joins the two existing conditions. All three live in ../notch.js so this
+// layout, stack.vue and the chrome cannot disagree about whether there is a cut on this slide.
+/*
+  ★ `&& props.edge !== 'bleed'` IS APPLIED HERE RATHER THAN PASSED INTO hasNotch(), deliberately. That
+  function answers one question — "does this frame kind sit under the chrome" — for both layouts, and
+  it has already been given one argument too many once (a `flip` that made it wrong); a test pins its
+  arity at three for that reason. Bleeding is a property of THIS slide's frame, not of the frame KIND,
+  so the layout that knows about it is the one that applies it.
+*/
+/* ⚠ DECLARED BEFORE THE NOTCH INSTANCES BELOW, and that is load-bearing rather than tidy:
+   useNotchCuts() evaluates its `enabled` callback during setup, so a `pairColumns` declared after it
+   threw "Cannot access 'pairColumns' before initialization" and the slide rendered EMPTY — layout
+   gone, no fallback, one console line. */
+/*
+  Content-first, clamped to four: see the prop. `pair` is the switch every rule below reads, so the
+  layout asks "is this a set of pictures" once rather than in five places, and the two columns are
+  derived from it rather than sliced at each use.
+*/
+const pair = computed(() => (props.images.length >= 2 ? props.images.slice(0, 4) : null))
+const pairColumns = computed(() => {
+  if (!pair.value) return null
+  const n = pair.value.length
+  // floor, so an odd picture lands in the FIGURE column — the one with no measure to protect.
+  const cut = Math.floor(n / 2)
+  return { content: pair.value.slice(0, cut), figure: pair.value.slice(cut) }
+})
+const notched = computed(() =>
+  props.edge === 'inset'
+  && hasNotch(props.frame, chromeShows(frontmatter, currentPage.value), notchShows(frontmatter)),
+);
+
+// The cut, measured. `notched` above still decides WHETHER this panel is cut — chrome showing, a
+// real media side, `notch: false` not set — and this decides what shape the cut is, from whatever
+// running chrome actually lands on the panel: the mark or a co-brand pair at one top corner, the
+// page marker at the bottom, a section pill on a band. styles/base.css's own single-notch rule is
+// what paints the first frame; this replaces it on mount. See ../useNotchCuts.js.
+const figureEl = ref(null);
+const { clip: notchClip } = useNotchCuts(figureEl, { enabled: () => notched.value });
+/*
+  ★★ THE PAIR'S OTHER PICTURE IS A FIGURE TOO, SO IT GETS ITS OWN CUT. Jose: "it should have the same
+  behaviour of the right side... same padding and all... and should notch". A picture standing where
+  the prose would is not a content column with an image in it — it is the second half of one object,
+  and half an object that keeps its square corner under the running mark is the tell.
+
+  Both instances are enabled on the same condition: useNotchCuts seats whatever actually TOUCHES the
+  box and returns null when nothing does, so the left column cuts for the section pill at its bottom
+  corner and the right one for the mark at its top, without either being told which is which.
+*/
+const pairEl = ref(null);
+const { clip: pairClip } = useNotchCuts(pairEl, { enabled: () => notched.value && !!pairColumns.value });
+
+/*
+  ── `panelAlign: title-start` — the band, MEASURED ─────────────────────────────────────────────
+  The same trade useNotchCuts.js makes above, for the same reason: the number cannot be derived.
+
+  The CSS rule states a heading's height from the display role's own tokens, and that is right for a
+  one-line title on a plain panel. It is wrong twice over otherwise — a two-line title is a line
+  short, and a panel's top reservation is decided by whichever of four rules wins (card-pad, the
+  notch's max(), a bleeding panel's inset-text, or base.css's chrome clearance), which no expression
+  on this side can know. What the rung actually wants is "begin where the column's body begins", and
+  only the DOM can answer that.
+
+  ★ MEASURED OFF THE HEADING, NEVER OFF THE BODY. This margin is what moves the body, so reading the
+  body back would be circular — the second measurement would include the first.
+
+  ★ THE CSS VALUE IS THE FALLBACK, not a duplicate. It paints the first frame and it is what an
+  export gets if this never runs, so the rung degrades to the derived band rather than to nothing.
+
+  The scale is read off the figure itself (rect width against offset width) because the slide is
+  drawn inside a transform: rects come back in painted pixels and the margin is authored in canvas
+  ones, and mixing the two silently scales the band.
+*/
+const contentEl = ref(null);
+const band = ref(null);
+/*
+  ⚠ THE HEADING IS OBSERVED, NOT THE COLUMN, and the difference is the whole reliability of this.
+  `.split-content` is a grid item in a `minmax(0, 1fr)` row, so its BOX does not change when the
+  heading inside it rewraps — a ResizeObserver on the column never fires. Caught by driving a
+  one-line title to four in the running deck: the band stayed at its one-line value and the panel
+  sat 288px above the body it was supposed to meet.
+*/
+let observedHeading = null;
+
+const measureBand = () => {
+  const fig = figureEl.value;
+  const col = contentEl.value;
+  if (!fig || !col || !BANDED_ALIGNS.has(props.panelAlign) || props.frame !== 'panel') {
+    band.value = null;
+    return;
+  }
+  const heading = col.querySelector('h1, hgroup');
+  if (!heading) {
+    band.value = null;
+    return;
+  }
+  if (heading !== observedHeading) {
+    if (observedHeading) observer?.unobserve(observedHeading);
+    observer?.observe(heading);
+    observedHeading = heading;
+  }
+  const scale = fig.getBoundingClientRect().width / fig.offsetWidth || 1;
+  const figPad = parseFloat(getComputedStyle(fig).paddingTop) || 0;
+  const headingGap = parseFloat(getComputedStyle(heading).marginBottom) || 0;
+  const toBody = (heading.getBoundingClientRect().bottom - fig.getBoundingClientRect().top) / scale;
+  band.value = Math.max(0, Math.round(toBody + headingGap - figPad));
+};
+
+let observer = null;
+onMounted(() => {
+  observer = new ResizeObserver(measureBand);
+  if (figureEl.value) observer.observe(figureEl.value);
+  if (contentEl.value) observer.observe(contentEl.value);
+  measureBand();
+});
+onBeforeUnmount(() => {
+  observer?.disconnect();
+  observer = null;
+  observedHeading = null;
+});
+watch(() => [props.panelAlign, props.frame, props.ratio, props.edge], measureBand);
+
+const bandStyle = computed(() => (band.value === null ? null : { '--panel-align-band': `${band.value}px` }));
+
+/*
+  CO-BRANDING. When the slide declares a `companion:`, the running chrome draws a wider lockup and
+  this cut has to be exactly that much wider. Both sides call the same pure function on the same
+  frontmatter (../notch.js's coBrandFitted()), so the occupant and the cut cannot be pinned to
+  different numbers.
+
+  That function CLAMPS the occupant to what this ratio's panel can actually seat, which is why it
+  takes the page number and the whole token file rather than just `chrome`. See ../notch.js's
+  notchBudgetPx().
+
+  Set INLINE, and only when there is a companion: `--deck-notch-occupant-w` is deliberately left
+  undeclared otherwise so a `class:` override on the slide still reaches the mask's own
+  var(…, var(--deck-chrome-mark)) fallback. See the same note in slide-top.vue.
+*/
+const companion = computed(() => coBrandFitted(frontmatter, currentPage.value, deckTokens));
+const figureStyle = computed(() =>
+  notched.value && companion.value
+    ? { '--deck-notch-occupant-w': `${companion.value.occupantPx}px` }
+    : undefined,
+);
+</script>
+
+<template>
+  <div
+    class="slidev-layout split h-full flex flex-col"
+    :class="[
+      RATIO_CLASS[ratio] ?? 'is-1-1',
+      flip ? 'is-right' : 'is-left',
+      FRAME_CLASS[frame] ?? 'is-figure',
+      ALIGN_CLASS[align] ?? 'is-align-anchor',
+      PANEL_ALIGN_CLASS[panelAlign] ?? 'is-panel-align-center',
+      BODY_CLASS[body] ?? 'is-body-base',
+      edge === 'bleed' || edge === 'spill' ? 'is-bleed' : '',
+      edge === 'spill' ? 'is-spill' : '',
+      pair && seam === 'flush' ? 'is-flush' : '',
+      dark ? 'deck-dark' : '',
+    ]"
+  >
+    <!--
+      Header and footer are GRID ITEMS, not siblings of the grid — see `.split-grid`'s own comment
+      for the anchor arithmetic that requires it.
+    -->
+    <div class="split-grid">
+      <!--
+        ⚠ A FIGURE, NOT A CONTENT COLUMN WITH PICTURES IN IT. It carries the figure's own classes so
+        every rule that shapes the other half — the claw-back to the media inset, the card corner,
+        the cover crop, the cut — applies to this one by construction rather than by being restated.
+        `is-pair` moves it into the CONTENT column's track and mirrors the one thing that is
+        handed: which of its edges is the outer one.
+      -->
+      <div
+        v-if="pairColumns"
+        ref="pairEl"
+        class="split-figure is-photo is-pair"
+        :class="[
+          edge === 'bleed' || edge === 'spill' ? 'is-bleed' : '',
+          edge === 'spill' ? 'is-spill' : '',
+          notched ? 'has-notch deck-notch' : '',
+        ]"
+        :data-notch-corner="notched ? (flip ? 'right' : 'left') : undefined"
+        :style="pairClip ? { clipPath: pairClip } : null"
+      >
+        <img v-for="(p, i) in pairColumns.content" :key="i" :src="assetUrl(p.image)" :alt="p.alt">
+      </div>
+      <div v-else ref="contentEl" class="split-content">
+        <p v-if="eyebrow" class="deck-eyebrow">{{ eyebrow }}</p>
+        <slot />
+      </div>
+      <!--
+        `has-notch` is this LAYOUT's marker (its own margin/reservation rules key off it, and
+        scripts/deckAudit.ts counts it); `deck-notch` is the SHARED cut, one rule in styles/base.css
+        that stack.vue's band wears too. `data-notch-corner` is which of the figure's own corners is
+        the outer one — physical, never logical, because "outer" flips with `flip`.
+      -->
+      <div
+        ref="figureEl"
+        class="split-figure"
+        :class="[FRAME_CLASS[frame] ?? 'is-figure', TONE_CLASS[background] ?? 'bg-warm', edge === 'bleed' || edge === 'spill' ? 'is-bleed' : '', edge === 'spill' ? 'is-spill' : '', panelDark && (frame === 'panel' || frame === 'code') ? 'deck-dark' : '', notched ? 'has-notch deck-notch' : '']"
+        :data-notch-corner="notched ? (flip ? 'left' : 'right') : undefined"
+        :style="[figureStyle, notchClip ? { clipPath: notchClip } : null, bandStyle]"
+      >
+        <slot name="aside">
+          <!-- ⚠ NO WRAPPING TEMPLATE TAG HERE, and that is about a gate rather than about Vue. The
+               anchor test slices this file from the opening template tag to the first CLOSING one to
+               find the footer inside the grid, so an inner one ends the slice early and the gate
+               reports the footer as missing from a layout that has not moved it. (Spelling the tag
+               out in this comment does it too — which is why it is described rather than written.)
+               A `v-for` over an empty list renders nothing, so the three cases sit as siblings. -->
+          <img v-for="(p, i) in (pairColumns?.figure ?? [])" :key="i" :src="assetUrl(p.image)" :alt="p.alt">
+          <img v-if="!pairColumns && frame === 'photo' && image" :src="assetUrl(image)" :alt="alt">
+          <Placeholder v-if="!pairColumns && frame === 'photo' && !image" :label="alt || 'Image'" />
+        </slot>
+      </div>
+      <div v-if="$slots.footer" class="split-footer"><slot name="footer" /></div>
+    </div>
+  </div>
+</template>
+
+<style scoped>
+/*
+  ★★ NO VERTICAL PADDING RESET ANY MORE. This used to zero `padding-top`/`padding-bottom` so that
+  `--deck-anchor-third`, then written `calc(100% / 3)`, resolved against a full-canvas box. The
+  token is a canvas pixel now, so the box it sits in no longer has to be the canvas — and the layout
+  keeps the same four-sided inset every other layout gets from base.css.
+
+  That reset was the root of a whole class of bug: with the root carrying no vertical padding, every
+  region inside had to re-add its own edge clearance, and nothing enforced that it be right.
+  `.split-content` reserved 96px of bottom clearance unconditionally, so the first slide to use the
+  footer slot had a column 96px shorter than it needed sitting 120px above its own footer. Regions
+  no longer own edge clearance at all; the grid box IS the safe area.
+*/
+.slidev-layout.split {
+  /*
+    Which grid COLUMN each half lands in. Declared once here, on the root, rather than as an
+    `order` on each item: `order` only works on auto-placed items, and header/footer now have to be
+    placed EXPLICITLY (see `.split-grid` below), which means the content and figure columns have to
+    be nameable from those rules too. Physical column numbers, not logical ones — which track is
+    "the content's" flips with `flip`, never with writing direction.
+  */
+  --split-content-col: 1;
+  --split-figure-col: 2;
+}
+.slidev-layout.split.is-right {
+  --split-content-col: 2;
+  --split-figure-col: 1;
+}
+.split-grid {
+  flex: 1;
+  display: grid;
+  column-gap: 0; /* task-14b-brief.md — the DEFAULT is "no gutter"; `.is-content` below restores one */
+  min-height: 0; /* lets the row shrink instead of overflowing the slide */
+  /*
+    task-14b-brief.md — THE VERTICAL ANCHOR. Jose: "text side should always start at 2/3 of the
+    slide vertically, not centered, so the headings dont jump between slides" — confirmed as the
+    one-third line, y = 360 on the 1080 canvas. Replaces the old `align-content: center` (which, on
+    the single `minmax(0, 1fr)` row task-13-brief.md pinned to full height, had nothing left to
+    centre — a row that already fills 100% of the container can't be moved within it by
+    `align-content` at all; this task looked closer and found that rule was dead code, not merely
+    the wrong VALUE).
+
+    Two explicit rows instead of one:
+      row 1  the remainder        a spacer — nothing is placed in it directly.
+      row 2  minmax(0, 1fr)       `.split-content` lives here, so its box starts exactly where
+                                   row 1 ends.
+
+    ★★ ROW 1 IS THE ANCHOR MINUS THE ROOT'S OWN INSET, and the subtraction is the whole point.
+    `--deck-anchor-third` is a canvas coordinate — 360px, measured from the top of the SLIDE. The
+    grid box does not start there; it starts at the text inset, because this layout is an ordinary
+    padded box now. So the spacer only has to cover what is left between them. Naming the anchor
+    bare here would place the column at 456.
+
+    It was bare, and correct, while the token was `calc(100% / 3)` and this layout zeroed its own
+    vertical padding to make the grid box and the canvas the same thing. Both halves of that went
+    together: a percentage needs the canvas underneath it, and a layout with no padding makes every
+    region inside it responsible for its own edge clearance. See the note at the top of this
+    stylesheet for the bug that came out of it.
+
+    `.split-figure` spans BOTH rows (below) rather than living in one alongside the spacer, so it
+    still fills its own cell top to bottom — a photo must not float with dead space above it just
+    because the TEXT column has a fixed start. It needs no margin of its own to do that: the cell's
+    top edge already sits at the safe line. Where it reaches PAST that line — a notched figure going
+    to the chrome inset — it does so with a negative MARGIN, not padding, which would draw inside
+    `.is-photo`'s own border-radius/overflow box and shrink the visible photograph rather than
+    positioning the frame in its cell (and cannot be negative at all).
+
+    `column-gap` only, never the `gap` shorthand: `gap` sets row-gap too, and a row-gap between rows
+    1 and 2 would push row 2's start past the anchor, throwing off the one figure this whole
+    mechanism exists to hit exactly.
+
+    ★★ THE HEADER/FOOTER DEFECT, and why there is a THIRD row now (task-15, fixing what task-14b
+    shipped). Back when the anchor was `calc(100% / 3)` it resolved against THIS grid's box — not
+    against the canvas. task-14b arranged for those to be the same thing by zeroing the layout's
+    vertical padding, but only for a bare split: `::footer::` used to render as a flex SIBLING of
+    this grid, below it, so on a slide carrying one the grid was shorter than the canvas and a third
+    of it landed somewhere else entirely — the text column started at y ~ 400, not 360. The anchor
+    exists so "the headings dont jump between slides" (Jose); the token was a contract that held
+    only over the input it was tested on.
+
+    A pixel anchor is immune to that particular failure, but the row placement below is NOT
+    decoration left over from it: the footer is still a grid item because an `auto` row is the only
+    thing that keeps a footer's height off the flexible row above it.
+
+    The fix is to place the slot INSIDE the grid instead of beside it, so nothing can shorten it:
+
+      row 1  --deck-anchor-third   empty now that there is no header slot. Kept as a fixed length
+                                    because it IS the anchor: `.split-content` starts where this row
+                                    ends, and `align` is the prop that collapses it on purpose.
+      row 2  minmax(0, 1fr)        `.split-content` — its box starts exactly at the anchor.
+      row 3  auto                  the footer, spanning both columns. An `auto` row takes its
+                                    height from the FLEXIBLE row above it, never from row 1's fixed
+                                    length, so a footer cannot move the anchor either.
+  */
+  /*
+    ★ THE ANCHOR MINUS THE INSET, because the grid now starts at the padded origin rather than at
+    the canvas edge. `--deck-anchor-third` is a CANVAS position (360) — that is what the ruler draws
+    and what scripts/deckAudit.ts asserts — so inside a box already inset by the text inset, row 1
+    is the difference. Written as the subtraction rather than as 264 so retuning either token moves
+    it, and so the reader can see which two numbers it is between.
+  */
+  grid-template-rows: calc(var(--deck-anchor-third) - var(--deck-inset-text)) minmax(0, 1fr) auto;
+}
+/*
+  ★★ THERE IS NO `header` SLOT, AND THE REMOVAL IS THE DESIGN DECISION IT LOOKS LIKE. It existed to
+  put a title in its own band above the content row, and it did two different things depending on
+  `frame` — spanning both columns at `content`, confined to the content column otherwise.
+
+  Both jobs turned out to be covered better elsewhere. A full-width title over an evenly divided
+  body is `default` plus a two-column `::grid`: measured against the split version, same title
+  position, same column top, and grid's columns 18px wider for having the narrower gutter — and the
+  h1 spans because an h1 spans, not because of a conditional rule. A title above the content column
+  with a figure running full height beside it is `align: start`: measured on the same content and the
+  same map, the two differed by 40px of title position and nothing else.
+
+  It also carried real weight for one slide's use: a conditional span, a row-sizing rule, a branch in
+  the audit's anchor gate, and a constant in that gate predicting where the content would start —
+  which assumed a one-line title, failed on a two-line one, and cost a misdiagnosis that outlived it.
+*/
+.split-footer {
+  grid-row: 3;
+  grid-column: 1 / -1;
+}
+/*
+  THE CONDITIONAL GUTTER. `frame` tells split.vue which case this is — `photo`/`panel`/`figure`
+  mean a real figure (mixed: text meets media, no gutter, the default above, with the clearance
+  living in the content column's padding instead); `content` means the far slot is a second CONTENT
+  column (same-kind: text meets text), which takes a real gutter because there is no figure edge to
+  separate the two.
+
+  ★ 96, NOT THE 36 task-14b ASKED FOR. Jose's original rule was "both sides text or both sides
+  image: gutter 36px", and it stood until the ruler made the pairing visible: 36px is 1.00em at the
+  deck's 36px body, while text beside a figure was getting 2.67em. The case with no edge between
+  the columns had less than half the air of the case that has one. Both are `--deck-inset-text`
+  now — see the token's own note in scripts/deck.ts.
+*/
+.is-content .split-grid {
+  column-gap: var(--deck-split-gutter-same);
+}
+/*
+  ── WHERE THE CONTENT COLUMN SITS VERTICALLY ───────────────────────────────────────────────────
+  Row 1 is the anchor: at `anchor` it is the one-third line and the content starts there. The other
+  three collapse it to 0 so row 2 spans the whole frame, and then `align-self` decides where in that
+  space the column sits. Three of the four therefore share one row change and differ by one line.
+
+  ★ THE FIGURE DOES NOT MOVE, and that is what makes this safe to add. `.split-figure` spans
+  `grid-row: 1 / 3`, so it fills the frame no matter what row 1 is — a map stays full-height beside
+  a heading pushed to the bottom. Measured on all four values before this was committed.
+
+*/
+.is-align-center .split-grid,
+.is-align-end .split-grid {
+  grid-template-rows: 0 minmax(0, 1fr) auto;
+}
+/*
+  ★★ `start` TAKES THE TEXT INSET, NOT 0, AND THE FIRST CUT GOT THIS WRONG. Collapsing row 1 to
+  zero for all three put the heading at canvas y 0 — hard against the edge with no clearance at
+  all — because split's ROOT carries no vertical padding: the anchor row was the only thing holding
+  the column off the top, so removing it removed the inset too. Measured before the fix: heading top
+  0 against the 96px every other edge of the same column keeps.
+
+  center and end are unaffected by that trap: they push the column away from the top edge anyway,
+  and its own padding-bottom holds the other end.
+*/
+/*
+  ★ ZERO, NOT THE TEXT INSET — the grid already starts at it. This was `var(--deck-inset-text)` back
+  when split's root had no vertical padding and row 1 was the only thing holding the column off the
+  edge. The root pads now, so naming the inset here applied it twice and put the column at 192.
+  `start` means "no anchor row at all"; the clearance is the root's, like every other layout's.
+*/
+/*
+  `body-center` collapses the anchor row for the same reason `start` does, and needs it more: its
+  whole premise is that the HEADING holds the top, so leaving the one-third row in place starts the
+  column 224px down and the free space it means to distribute is spent before it begins. Measured
+  before this rule: the column opened at 360 and its last block ran to 1014, 30px past the safe line.
+*/
+.is-align-start .split-grid,
+.is-align-body-center .split-grid {
+  grid-template-rows: 0 minmax(0, 1fr) auto;
+}
+/*
+  ★ `safe`, BECAUSE PLAIN `center` OVERFLOWS BOTH ENDS. Row 2 is `minmax(0, 1fr)` against a fixed
+  frame, so it never grows to fit the column: a column taller than 888 centres by running half its
+  surplus PAST THE TOP INSET, and the h1's own border box is the first thing outside the safe area.
+  Caught on the bled-code slide, whose three-line heading makes the column 892.75 — 2.375px out at
+  each end, which the audit prints as "2px past the top inset". `safe` falls back to `start` only
+  when the subject overflows, so a column that fits is untouched (measured: fitting column, top 244
+  either way; overflowing column, -2.375 unsafe against 0 safe).
+
+  ★ THE SURPLUS THEN ALL GOES TO THE BOTTOM, where the last block's own margin absorbs it — 16px on
+  a `p`, which is what every one of these slides ends in. A column ending in a block with NO bottom
+  margin would put the whole surplus past 984 rather than half of it.
+*/
+.is-align-center .split-content { align-self: safe center; }
+.is-align-end .split-content { align-self: end; }
+/*
+  ★★ `body-center` — THE HEADING HOLDS THE TOP AND EVERYTHING UNDER IT CENTRES IN WHAT IS LEFT. It is
+  default.vue's mode of the same name, on this layout's own column, and it pairs with the panel's
+  `title-center`: set both and the two halves of a split read the same way — a title at the top of
+  the slide, the substance centred in the space below it on each side.
+
+  The three autos are default.vue's, and so is the reason for the third. Flexbox splits free space
+  EQUALLY between auto margins, so the ratio comes from HOW MANY there are rather than from a
+  length: two give 1:1, and the `::after` makes it 1:2, which rides the body one sixth of the free
+  space above centre. The eye judges centring against the FRAME, and the heading occupying the top
+  is what a plain split cannot know about.
+
+  ★ THE COLUMN MUST STRETCH, which is why no `align-self` is set here. The two rungs above pin the
+  column to a point in the row, leaving it its own height; auto margins need the row's full height
+  or there is no free space for them to absorb and the mode silently degrades to `start`.
+
+  ★ GATED ON A HEADING, by construction rather than by a guard: with no `h1` the sibling selector
+  matches nothing, `:has()` is false, no auto is handed out, and the column stays top-anchored —
+  which is right, because there is no heading holding the top to centre underneath.
+*/
+.is-align-body-center .split-content {
+  display: flex;
+  flex-direction: column;
+}
+.is-align-body-center .split-content > :is(h1, hgroup) + * { margin-top: auto; }
+.is-align-body-center .split-content:has(> :is(h1, hgroup)) > :last-child { margin-bottom: auto; }
+.is-align-body-center .split-content:has(> :is(h1, hgroup))::after {
+  content: '';
+  margin-top: auto;
+}
+/* The panel's own vertical alignment — see `panelAlign` for why it is a second prop rather than a
+   fifth value of `align`. All four are written out, and the base `.is-panel` rule below no longer
+   carries `align-items`, so this is the ONE place a panel's cross-axis is decided. */
+.is-panel-align-start .split-figure.is-panel { align-items: flex-start; }
+.is-panel-align-center .split-figure.is-panel { align-items: center; }
+.is-panel-align-end .split-figure.is-panel { align-items: flex-end; }
+/*
+  ★★ THE TWO TITLE RUNGS ARE ONE CONSTRUCTION, and the only difference is what they do with the
+  space under the band. The panel becomes a COLUMN: the band is a `::before` item, then
+  `title-start` parks what follows at the top of it, while `title-center` hands the remainder to
+  three auto margins that flexbox splits equally — 1:2, the same sixth of a lift `align: body-center`
+  takes, which is the whole reason those two are usable as a pair.
+
+  ★ THE BAND IS MEASURED; the value here is the FALLBACK. It paints the first frame and is what an
+  export gets if the script never runs — see the script's own note for why it cannot be derived.
+
+  ⚠ COLUMN MEANS THE AXES SWAP. Horizontal alignment moves from `justify-content` to `align-items`,
+  and the autos need a main axis to absorb, so both are restated here rather than left to the base
+  rule, which is a row.
+
+  ⚠ HORIZONTAL IS UNTOUCHED — these rungs centre like every other panel. Making them `stretch`
+  instead was a real defect and the ladder is what caught it: the three plain rungs shrink-wrap their
+  occupant to 206px and these two blew it out to the full 860, so a ladder meant to move ONE variable
+  moved position AND width, and a reader could not tell which they were seeing. A half that needs to
+  fill its width asks for it where that belongs — Grid's `justify`, which takes the width it needs to
+  centre across.
+
+  There is no `title-end`: the band would sit above an item already pinned to the bottom, so it would
+  render identically to `end`. Simulated before ruling it out.
+*/
+.is-panel-align-title-start .split-figure.is-panel,
+.is-panel-align-title-center .split-figure.is-panel {
+  flex-direction: column;
+  align-items: center;
+  justify-content: flex-start;
+}
+.is-panel-align-title-start .split-figure.is-panel::before,
+.is-panel-align-title-center .split-figure.is-panel::before {
+  content: '';
+  flex: none;
+  height: var(--panel-align-band, calc(
+    var(--type-deck-display-size) * var(--type-deck-display-line-height) + var(--deck-heading-bottom-space)
+  ));
+}
+.is-panel-align-title-center .split-figure.is-panel > * {
+  margin-top: auto;
+  margin-bottom: auto;
+}
+.is-panel-align-title-center .split-figure.is-panel::after {
+  content: '';
+  margin-top: auto;
+}
+.split-content {
+  /* Row 2 only — this is what makes the text column start exactly at the anchor line above. */
+  grid-row: 2;
+  grid-column: var(--split-content-col);
+}
+/*
+  The text column's INNER inset, against a figure.
+
+  Jose's rule is two clauses, and only the first was implemented: "text one side, image other side:
+  no gutter, and text side should have 90px margin horizontally". The zero gutter is a property of
+  the GRID (column-gap: 0, above); it says nothing about what the text column owes on its own edges.
+  The outer edge gets --deck-inset-text for free from the layout root's horizontal padding, so the
+  omission was invisible there — but the inner edge sits on the grid column boundary, which is
+  exactly the figure's edge. Measured on deck-template 18 before this rule: the figure ends at x=786
+  and `.split-content` began at x=786, so every line of body copy started flush against the
+  photograph while the same paragraph's right edge held a clean 90.
+
+  ★★ WRITTEN AS `:not(.is-content)`, NOT AS A LIST OF THE FIGURE KINDS, and that is the whole
+  point of the rule rather than a tidier way to spell it. It WAS a list — `.is-photo, .is-panel` —
+  and `.is-figure` was simply never added to it, so text ran flush into a map with nothing between
+  them: content padding 0, and 0px from the last letter to the figure's edge, against the 96px every
+  photo and panel got. It hid while `content` was split's default, because those slides took the
+  36px same-kind gutter instead, which looked like clearance and is a different mechanism; making
+  `figure` the default (ae99c03) is what exposed it.
+
+  An allow-list of variants is a thing a new variant falls off, silently, and this one did. Every
+  other layout in this theme is immune to the same mistake by construction: stack puts its 40px
+  between band and strip on the GRID as a row-gap, quote puts its 120px on the flex container, and a
+  gap on the parent is inherited by every variant there will ever be. Split cannot use a gap — the
+  gutter is zero for a figure precisely BECAUSE the text column carries the clearance itself — so
+  the next best thing is to state the ONE exception and let everything else be covered by default.
+
+  The exception is real: a `frame: content` split is text meeting text and already has a genuine
+  96px gutter doing this job. Adding an inset there too would put 96 + 96 + 96 between two columns
+  of prose — nearly eight ems, which is a chasm rather than a gutter.
+*/
+.is-left:not(.is-content)  .split-content { padding-right: var(--deck-inset-text); }
+.is-right:not(.is-content) .split-content { padding-left:  var(--deck-inset-text); }
+/*
+  ★★ THE ANCHOR ANCHORS THE HEADING, NOT THE COLUMN — and until this rule it only did the latter.
+
+  `.split-content`'s own top is y=360 on all 142 split slides in the three decks; the token is
+  correct and always was. But an `eyebrow:` renders INSIDE that column, above the heading, so on a
+  slide that carries one the HEADING landed 41px lower. Measured across deck-showcase's split
+  slides: 112 with no eyebrow put their h1 at y=360, 12 with an eyebrow put it at y=401. Slides 13
+  → 16 and 41/42 → 43 are near-consecutive, so the jump is visible on the click-through. The
+  anchor's stated reason is Jose's — "so the headings dont jump between slides" — and on an eyebrow
+  slide they still jumped. The mechanism held; the purpose failed. (scripts/deckAudit.ts asserts
+  `.split-content`'s own top and nothing else, which is why it reported 0 anchor failures.)
+
+  The eyebrow is therefore HUNG ABOVE THE ANCHOR: it is pulled up by exactly its own block
+  (--deck-eyebrow-block, base.css — line box + the gap it holds below itself), so the element after
+  it starts at the anchor whether it is there or not. Two properties this deliberately keeps:
+
+    · `.split-content`'s own box top is UNMOVED at 360 — the negative margin is on the eyebrow, not
+      on the column — so every existing measurement of the anchor still reads 360.
+    · The eyebrow does not move when the heading changes size, because the lift is the eyebrow's own
+      height, not the heading's.
+
+*/
+.split-content > .deck-eyebrow:first-child {
+  margin-top: calc(-1 * var(--deck-eyebrow-block));
+}
+.split-figure {
+  /*
+    ★★ A DIAGRAM IN HERE GETS THE COLUMN'S HEIGHT, NOT THE DEFAULT LAYOUT'S. mermaid's fitToColumn
+    caps a tall diagram against a height budget it cannot measure for itself, so it reads this
+    variable and falls back to the 720 a `default` slide leaves under its heading. A figure column
+    carries no heading above it: 1080 canvas less the inset at each end. For a height-bound diagram
+    — every sequence diagram is one — that is a quarter more of the whole drawing.
+  */
+  --deck-diagram-max-h: calc(1080px - 2 * var(--deck-inset-text));
+  /* Rows 1-2 — see the maths note on `.split-grid` above for why this is what "fills its cell top
+     to bottom" actually means once the text column has its own fixed start. Explicitly `1 / 3`,
+     not `1 / -1`: with the footer's own row now in the template, `-1` is the line AFTER it, and a
+     figure spanning into the footer's row would be drawn straight over any footer content. */
+  grid-row: 1 / 3;
+  grid-column: var(--split-figure-col);
+  /*
+    ★★ ZERO, BECAUSE THE ROOT'S OWN PADDING IS THE CLEARANCE NOW. These were both
+    `var(--deck-inset-text)` — the figure paying its own way in a layout whose root had no vertical
+    padding. With the root inset like every other layout, repeating it here would inset the figure
+    twice and land it at 192.
+  */
+  margin-top: 0;
+  margin-bottom: 0;
+}
+/*
+  ★★ THE ANCHOR APPLIES UNIFORMLY — task-18-brief.md's ruling, replacing task-15's header-only
+  scoping.
+
+  A `frame: content` figure side is documented as "nothing (a second content column)" — an author's own
+  content, not a figure. It used to span rows 1-2 like a real photo, which put its top at
+  --deck-inset-text (90px) while the text column beside it started at the anchor (360px): two
+  columns of the same KIND, on the same slide, starting 270px apart.
+
+  task-15 built this fix and then reverted it to the header-only case, because the anchor caps a
+  `frame: content` column at 630px instead of 900px and apps/deck-showcase #188 (a card grid in the
+  figure slot) runs to y 1218 with the cap on, y 990 without — probed live, both ways. The ruling
+  reverses that: the anchor exists so "the headings dont jump between slides" (Jose), and a rule
+  whose position depends on what happens to be in the OTHER slot fails that purpose on its own
+  terms. A heading is at 360 or it is not; "360 unless the neighbour is a card grid" is not an
+  anchor. The overflow is one slide's content being too tall for the slot, which is a content
+  problem with a content fix, and is deliberately NOT resolved by weakening the rule here.
+
+  Real photos and panels are unaffected — they still span rows 1-2 and fill their cell, because a
+  photograph floating with dead space above it is a different (and wrong) thing. This is only ever
+  about a second column of CONTENT.
+
+*/
+.is-content .split-figure {
+  /*
+    The row is the whole rule now. It also said `margin-top: 0`, which was live while `.split-figure`
+    carried the text inset — and is dead the moment the base is 0 too: the only rule that raises a
+    figure is `.has-notch`, and hasNotch() requires a PANEL frame, so it can never match this
+    selector. A declaration that restates the value it is already inheriting reads as a live override
+    to the next person who moves the base, which is worse than not being there.
+  */
+  grid-row: 2;
+}
+.is-1-1 .split-grid { grid-template-columns: 1fr 1fr; }
+/*
+  Every other ratio is content:figure, and the grid's two tracks are POSITIONAL — track 1 is
+  whichever element `order` (below) places there, not "the content one". So the fr values have
+  to swap with `flip` for the share documented on `ratio` to stay attached to CONTENT rather than
+  to a screen position.
+
+  Verified live before this fix: three of the six (ratio, side) combinations that differ were
+  backwards — `ratio="2:3"` at the default `side="left"` put content in the WIDER track (the
+  opposite of "2:3" read as content:figure), because a single un-keyed `.is-2-3` rule fixed the
+  track sizes regardless of which element `order` had moved into them.
+*/
+.is-3-2.is-left  .split-grid { grid-template-columns: 3fr 2fr; }
+.is-3-2.is-right .split-grid { grid-template-columns: 2fr 3fr; }
+.is-2-3.is-left  .split-grid { grid-template-columns: 2fr 3fr; }
+.is-2-3.is-right .split-grid { grid-template-columns: 3fr 2fr; }
+.is-2-1.is-left  .split-grid { grid-template-columns: 2fr 1fr; }
+.is-2-1.is-right .split-grid { grid-template-columns: 1fr 2fr; }
+.is-1-2.is-left  .split-grid { grid-template-columns: 1fr 2fr; }
+.is-1-2.is-right .split-grid { grid-template-columns: 2fr 1fr; }
+.is-3-1.is-left  .split-grid { grid-template-columns: 3fr 1fr; }
+.is-3-1.is-right .split-grid { grid-template-columns: 1fr 3fr; }
+/* `flip` is a pure mirror, and it is expressed ONLY as the two column numbers on the root above —
+   there is no `order` here any more. `order` re-sequences AUTO-placed items, and header/footer are
+   now placed explicitly by line (they have to be: they belong to particular rows), so a mixture of
+   the two would have placed some items by order and others by line against the same tracks. */
+/*
+  task-14-brief.md, numbers revised by task-14b-brief.md — THE FIGURE ESCAPES TO THE MEDIA INSET,
+  HORIZONTALLY, ON ITS OUTER EDGE ONLY.
+
+  Text is inset for its measure (--deck-inset-text, 90px, from `.slidev-layout`'s own padding —
+  see base.css); media is inset for its frame (--deck-inset-media, 36px) — a photo's hard edge
+  reads as inset too far at the value that reads correctly around a paragraph. `.split-grid` is a
+  descendant of `.slidev-layout` and inherits that 90px padding HORIZONTALLY (vertical is zeroed
+  above, for the anchor), same as the content column, so the figure needs to CLAW BACK the 54px
+  difference on its own outer edge only — the inner edge (against the gap that separates it from
+  content) stays put, and the CONTENT side never moves at all.
+
+  A negative margin is the mechanism: `.split-figure` sits inside a `fr`-sized grid track, so a
+  margin shifts the rendered box without feeding back into track sizing (unlike an `auto` track,
+  where a margin would resize the column itself). `margin-right`/`margin-left`, not `margin-inline
+  -end/-start`: which PHYSICAL side is "outer" flips with `flip` (see `--split-figure-col` on the
+  root) but never with writing direction, so the physical property is correct and the logical one
+  would be wrong here.
+
+  Scoped to the three FIGURE kinds — `.is-photo`, `.is-panel`, `.is-figure` — and NOT `.is-content`:
+  `frame: content` is documented as "nothing (a second content column)" — an author's own content, not
+  a figure, and content wants the TEXT inset it already has. Escaping it to the media inset would
+  narrow its measure on the very edge the whole point of `--deck-inset-text` is to protect.
+*/
+.is-left .split-figure.is-photo,
+.is-left .split-figure.is-panel,
+.is-left .split-figure.is-code,
+.is-left .split-figure.is-figure {
+  margin-right: calc(-1 * (var(--deck-inset-text) - var(--deck-inset-media)));
+}
+.is-right .split-figure.is-photo,
+.is-right .split-figure.is-panel,
+.is-right .split-figure.is-code,
+.is-right .split-figure.is-figure {
+  margin-left: calc(-1 * (var(--deck-inset-text) - var(--deck-inset-media)));
+}
+
+/*
+  ★★ `bleed` — THE SAME FIGURE, AT THE CANVAS EDGE. FOUR DECLARATIONS, AND NO TREATMENT OF ITS OWN.
+
+  Everything above claws back the DIFFERENCE between the text inset and the media inset, and stops at
+  36. This gives up the whole text inset instead, so the figure's outer, top and bottom edges are the
+  canvas edges: 0, 0 and 1080. The frame keeps whatever it already was — a photo still crops, a panel
+  still carries its fill and padding, a component figure is still centred and capped — which is the
+  point of making this a modifier rather than a fifth `frame` value.
+
+  The card radius comes off because a radius is what a thing sitting ON something has; flush to the
+  canvas there is no ground for it to sit on and the corner would read as a mistake.
+
+  ⚠ SCOPED AWAY FROM `.is-content`. That kind is a second column of the author's PROSE, and running
+  body copy to the canvas edge is the one thing this must never do — measured on a first draft that
+  did exactly that, the paragraph ran off the right of the slide and under the running mark.
+
+  The INNER edge is untouched: it still meets the content column's gutter, because a figure that bled
+  inwards would run under the text rather than beside it.
+*/
+.is-left .split-figure.is-bleed:not(.is-content)  { margin-right: calc(-1 * var(--deck-inset-text)); }
+.is-right .split-figure.is-bleed:not(.is-content) { margin-left:  calc(-1 * var(--deck-inset-text)); }
+.split-figure.is-bleed:not(.is-content) {
+  border-radius: 0;
+  margin-top: calc(-1 * var(--deck-inset-text));
+}
+/* Scoped the way the notch's bottom escape is: a `::footer::` occupies the row below, so a figure
+   bleeding past it would run under the footer rather than to the canvas. */
+.split-grid:not(:has(.split-footer)) .split-figure.is-bleed:not(.is-content) {
+  margin-bottom: calc(-1 * var(--deck-inset-text));
+}
+
+/*
+  ★★ THE SURFACE BLEEDS; THE CONTENT INSIDE IT MUST NOT.
+
+  Giving up the inset moves the box, and the padding rides along with it — so a bleeding panel put
+  its content 36px closer to the slide edge than the same panel unbled, and a bleeding figure put its
+  component right on the canvas edge. Measured, `frame: panel` at ratio 1:1: notched, the content box
+  runs to x 1852; bleeding, to 1888. The frame is supposed to look identical apart from its own
+  edges, and it did not.
+
+  So each bled edge gives the inset back as PADDING. The surface still reaches the canvas; the
+  content lands exactly where it would have without the bleed. Written per frame because the two
+  start from different places — a panel already insets its content by --deck-card-pad and a figure
+  by nothing — and adding the same number to both would put the figure 32px in from where its
+  unbled version sits.
+
+  `photo` is deliberately absent: an edge-to-edge photograph is the whole point of bleeding one, and
+  padding it would show the ground behind. `content` is absent because it never bleeds at all.
+
+  ⚠ THE TOP IS ONLY HALF-ANSWERED HERE. These values assume nothing is above the surface. When the
+  chrome row IS drawn there is a mark to clear, and the rule that raises this lives in styles/base.css
+  — a layout's own scoped CSS cannot see `.slidev-page`, which is where the chrome is.
+*/
+/*
+  ★★ 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) 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.
+*/
+.split-figure.is-bleed.is-panel  { padding-top: var(--deck-inset-text); }
+.split-figure.is-bleed.is-figure { padding-top: var(--deck-inset-media); }
+/*
+  ★★ A BLEEDING PANEL PADS BOTH SIDES EQUALLY, WHICH IS NOT WHAT "GIVE THE INSET BACK" ALONE GIVES.
+
+  The rule above is per-EDGE, so only the bled edge got the inset back and the panel's interior came
+  out lopsided: measured at ratio 1:1, content ran 992-1852, i.e. 32px from the seam and 68px from
+  the canvas edge. Both of those are hard edges of the same box — one against the slide, one against
+  the content column — and a fill with twice as much air on one side as the other reads as a mistake
+  rather than as a bleed.
+
+  So the panel takes the bled value on BOTH sides. It is the panel, not the figure, because a panel
+  is a visible box whose interior is read as a box: `is-figure` brings no fill, its inner edge meets
+  the content column's own 96px, and padding it again would push a map 68px off a seam that is not
+  drawn.
+
+  The cost is 36px of panel width, paid on the inner edge. Jose asked the question that found it.
+*/
+.split-figure.is-bleed.is-panel { padding-left: var(--deck-inset-text); padding-right: var(--deck-inset-text); }
+.is-left  .split-figure.is-bleed.is-figure { padding-right: var(--deck-inset-media); }
+.is-right .split-figure.is-bleed.is-figure { padding-left:  var(--deck-inset-media); }
+/* Bottom only where the bottom actually bled — same `::footer::` scope as the margin above. */
+.split-grid:not(:has(.split-footer)) .split-figure.is-bleed.is-panel  { padding-bottom: var(--deck-inset-text); }
+.split-grid:not(:has(.split-footer)) .split-figure.is-bleed.is-figure { padding-bottom: var(--deck-inset-media); }
+
+/*
+  A COMPONENT FIGURE — centred in its cell, capped to it, and brings no surface of its own.
+
+  It needs no grid-row of its own: `.split-figure` already spans rows 1-2, and the only thing that
+  ever moved it was `.is-content`'s deliberate drop to row 2. What it does need is for the component
+  inside it to take the height, which a plain block child will not do on its own.
+
+  ★ NO MATTE, and that is the difference from `panel`. A panel is a mounting board — a tinted card
+  with the media centred inside its padding, which is right for a screenshot and wrong for a map
+  that has its own ground and its own corner radius.
+
+  ★★ AND IT CLAWS BACK THE 54px LIKE THE OTHER TWO, above. It is a FIGURE, so its outer edge takes
+  --deck-inset-media (36px), not the text inset the layout pads with — measured before this was
+  added, the map sat 90px from the canvas edge while its own top and bottom were at 36px, which is
+  the inset system applied to three of a box's four sides.
+*/
+/*
+  ★★ CENTRED AND FITTED, NOT STRETCHED — and the difference only shows on a figure that keeps its
+  own aspect. The child used to take `flex: 1`, so it grew to the full height of the cell; a map or
+  a chart that will not distort then drew itself at its own aspect inside that stretched box and sat
+  at the TOP of it. Measured on the specimen's `frame: figure` slide: cell 924x1008, child stretched
+  to 1008, and the map's own svg 780x601 against the cell's top edge with 407px of void beneath it.
+
+  Centring the CELL could not have fixed that, because the child already filled the cell — the empty
+  space was inside the child. The stretch had to go first.
+
+  So the child takes its natural size, is capped to the cell on both axes, and is centred in what is
+  left. A figure that genuinely wants the whole cell asks for it the same way it always did, with
+  its own `height` — `::deck-map` and every chart already do, and they are unaffected because their
+  height is declared rather than inherited from a stretch.
+*/
+.split-figure.is-figure {
+  display: flex;
+  flex-direction: column;
+  align-items: center;
+  justify-content: center;
+}
+.split-figure.is-figure > :deep(*) {
+  /*
+    `width: 100%` so it can GROW, both maxes so it can never spill. Capping alone stopped a figure
+    overflowing and left it at whatever size it declared — the borough map sat 780 wide in a 924
+    cell and simply never used the other 144.
+  */
+  width: 100%;
+  max-width: 100%;
+  max-height: 100%;
+  min-height: 0;
+}
+/*
+  ══ SPILL ══════════════════════════════════════════════════════════════════════════════════════
+
+  ★★ THE THREE LINES ABOVE ARE WHAT SPILL HAS TO UNDO. `width: 100%` plus both maxes is the rule
+  that makes a figure FIT: it grows a small drawing up to the cell and stops a large one escaping.
+  A spilling figure is the deliberate opposite — it is sized past its cell and cropped by the canvas
+  — so it needs all three released, not one. Released and then RE-anchored: with the maxes gone and
+  nothing saying which way the overflow leaves, a centred child overflows both sides equally and the
+  figure reads as badly cropped rather than as running off one edge.
+
+  ⚠ WHICH EDGE IT LEAVES BY IS THE COLUMN'S, NOT THE SLIDE'S. `.is-left` puts the FIGURE on the
+  right (that is why its bleed rule pulls `margin-right`), so its content anchors to the inner edge
+  and overflows outwards, and `.is-right` mirrors it. Anchored the other way round, the drawing runs
+  under the text column instead of off the canvas.
+*/
+/*
+  ★★ THE CAPS COME OFF AND NOTHING IS IMPOSED. A spilling component knows its own size — a map's
+  `width`, a device frame's `height` — and what the figure was doing was capping it. Sizing the child
+  here instead (a flat 150%) made the map's own `width` prop silently inert, which is the same defect
+  in the other direction: a number an author states and the layout overrides.
+*/
+/*
+  ⚠ THE WIDTH IS STATED HERE, and two other answers were measured before this one. `auto` made the
+  map fall back to its intrinsic SVG size and render SMALLER than unspilled (350px in a 780px
+  column). Leaving it alone kept the base rule's `width: 100%`, so the figure filled its cell exactly
+  as it always had and nothing spilled at all (751px, right edge at 1884, inside the canvas). The
+  base rule has to be beaten, so the ratio lives here — and a component's own width prop is then
+  inert on a spilling figure, which is why the specimen's map states none.
+*/
+.split-figure.is-spill.is-figure > :deep(*) {
+  width: var(--spill, 150%);
+  max-width: none;
+  max-height: none;
+}
+/*
+  ⚠ THE ROOM STOPS CENTRING ITS WINDOW, AND THAT IS THE WHOLE OF IT — the cap stays on, unlike the
+  band's case in stack.vue.
+
+  The rule above widens the figure's direct child, which for a browser window is
+  `.deck-browser-room`; the WINDOW is a grandchild, so it kept the room's horizontal centring.
+  Measured on the right-edge spill: the room ran 672-2490 as asked and the window sat 827-2335
+  inside it, so 155px of ground opened between the copy and a window that was supposed to start at
+  the column's inner edge. Jose, on the ruler overlay: "whats with this padding here?"
+
+  ★★ AND BREAKING THE CAP AS WELL WAS THE OVER-CORRECTION. `max-width: none; width: 100%` filled the
+  room — and the room is 150% of a column, so at 16:9 the window came out 1085px tall in a 1008px
+  box and left the canvas at the TOP as well as the sides. A split spills SIDEWAYS; the cap is what
+  keeps the other axis honest, and BrowserFrame computes it from the room's own height for exactly
+  this. Jose: "can you put padding top bottom? so it doesnt overflow at the top?" — the padding was
+  always there, the window was ignoring it.
+
+  So the window is as big as the height allows and hard against the inner edge, and whatever that
+  leaves over goes out the outer side, which is what `spill` means. A band spills DOWNWARD and so
+  breaks the same cap; the two layouts differ because their crop axes do.
+*/
+.split-figure.is-spill :deep(.deck-browser-room) {
+  align-items: flex-start;
+}
+/* ⚠ MEDIA IS THE EXCEPTION, because a photograph has no size of its own worth honouring — an <img>
+   released from its caps is its intrinsic 8917px. A spilling photo frame oversizes by a RATIO of the
+   column and keeps the cover crop. */
+.split-figure.is-spill.is-photo > :deep(img) {
+  width: var(--spill, 150%);
+  max-width: none;
+  height: 100%;
+  object-fit: cover;
+}
+/*
+  ★★ AND THE CROP KEEPS THE FAR SIDE OF THE PICTURE. Jose, on the flipped slide: "if the edge spill
+  and flip true, the image should be put showing the right side of the image... otherwise it will cut
+  off the wrong part".
+
+  ⚠ TWO PROPERTIES, AND ONLY ONE OF THEM IS `object-position` — which is the trap. It picks which
+  part of the SOURCE fills the img's box; it says nothing about which part of that BOX survives the
+  figure's clip. Set alone it looked right in the CSS and wrong on the slide: measured on the flipped
+  spill, the figure ran 0 → 787 with the img at 0 → 1181, so the img hung off the figure's RIGHT edge
+  and the visible 787 was its left end — the exact half the composition is meant to lose.
+
+  So the box is anchored first: on a figure that leaves by the LEFT edge the img is pushed to the
+  figure's right, and the overflow goes left. Then `object-position` sends the source's own crop the
+  same way, so the side that stays on the slide is the side that stays in the picture.
+*/
+.is-right .split-figure.is-spill.is-photo { justify-content: flex-end; }
+.is-left  .split-figure.is-spill.is-photo { justify-content: flex-start; }
+.is-right .split-figure.is-spill.is-photo > :deep(img) { object-position: right center; }
+.is-left  .split-figure.is-spill.is-photo > :deep(img) { object-position: left center; }
+.is-left  .split-figure.is-spill.is-figure { align-items: flex-start; }
+.is-right .split-figure.is-spill.is-figure { align-items: flex-end; }
+/*
+  ★ AND THE VERTICAL ANCHOR IS THE TOP, so a figure taller than its cell — a browser window whose
+  foot is meant to be below the canvas, three device frames standing on the bottom edge — grows
+  downwards rather than centring and losing its head as well as its feet.
+*/
+.split-figure.is-spill.is-figure { justify-content: flex-start; }
+/*
+  ★★ THE SLIDE DOES THE CROPPING, AND IT HAS TO SAY SO. Nothing on this layout clipped before —
+  a figure that fits needs no clip and the canvas is not a clipping context by default, so the
+  overflow simply painted over the chrome and past the slide into the deck's own page. `overflow`
+  on the root is what turns "sized past its cell" into "cropped by the slide edge".
+*/
+.split.is-spill { overflow: hidden; }
+
+/*
+  ★★ AND THE DRAWING FITS ON WHICHEVER AXIS BINDS FIRST. An <svg> carrying a viewBox has an
+  intrinsic ratio, so at width/height 100% its own default preserveAspectRatio="xMidYMid meet" does
+  exactly what object-fit: contain does for a photo — grows until one axis touches, centres on the
+  other, never distorts. That is the whole behaviour, and it comes from the SVG spec rather than
+  from arithmetic here, so there is no ratio for this file to compute or keep in sync.
+
+  Scoped to the figure kind: `panel` mattes its content at natural size on purpose, and `photo`
+  already crops with object-fit: cover.
+*/
+.split-figure.is-figure :deep(svg) {
+  max-width: 100%;
+  max-height: 100%;
+}
+/*
+  THE FIGURE SIDE OWNS ITS OWN TREATMENT. An author writes the content and nothing else:
+
+      ::aside::
+      <img src="/warehouse.jpg" />
+
+  and gets a filled, corner-clipped photo. Before this, `.is-photo` carried NO CSS at all — the
+  rounding and the fill lived only inside <Placeholder>, so the frame vanished the moment a real
+  image replaced the placeholder and the author had to rebuild it by hand with utility classes.
+  `frame`'s own description promises "a photo frame"; this is that frame.
+
+  `object-fit: cover` rather than a raw stretch is what makes filling safe for an <img> of any
+  intrinsic ratio. Same rule and same reasoning as bleed.vue's `.bleed-media :deep(> *)`.
+
+  Scoped to real MEDIA, not `:deep(> *)`: a <Placeholder> is a <div> and keeps its own
+  aspect-ratio behaviour, so `frame: photo` with no slot content still mocks up at its declared
+  ratio instead of being stretched to the cell.
+
+  ESCAPE HATCH, so this cannot silently defeat a caller who wants something else: use
+  `frame: content`, which carries no treatment at all, and bring your own figure.
+*/
+.split-figure.is-photo {
+  border-radius: var(--deck-radius-card);
+  overflow: hidden;
+  display: flex;
+  min-height: 0;
+}
+.split-figure.is-photo :deep(img),
+.split-figure.is-photo :deep(video),
+.split-figure.is-photo :deep(picture) {
+  width: 100%;
+  height: 100%;
+  object-fit: cover;
+  display: block;
+}
+/*
+  ══ THE PAIR ══════════════════════════════════════════════════════════════════════════════════
+
+  ★★ THE CONTENT COLUMN TAKES THE FIGURE'S OWN TREATMENT, WORD FOR WORD, when it is holding the
+  first of two pictures — the same corner, the same crop, the same clip. A diptych only reads if
+  the two halves are the same KIND of object: one radius against none, or a cover crop against an
+  image sized to its own ratio, and the slide is a photograph beside a picture of a photograph.
+
+  ⚠ SCOPED TO `.is-picture`, WHICH THE LAYOUT ONLY ADDS WHEN `images` HOLDS TWO. Written as a bare
+  `.split-content :deep(img)` it would have cropped every inline image in every prose column in the
+  deck to the height of its box — a diagram, a mark, an emoji-sized glyph.
+*/
+/*
+  ★★ THE PAIR'S OTHER PICTURE SITS IN THE CONTENT COLUMN'S TRACK AND IS OTHERWISE A FIGURE. It
+  carries `.split-figure.is-photo`, so the corner, the crop, the clip and the claw-back to the media
+  inset are the rules that already shape the other half rather than a second set written to match
+  them. Two things are its own: which track it sits in, and which of its edges is the outer one.
+
+  ⚠ THE MIRRORED CLAW-BACK IS THE WHOLE OF THAT SECOND THING. Every `.split-figure` rule keys its
+  outer edge off `.is-left`/`.is-right`, which name where the FIGURE is — so applied unchanged to a
+  box in the other column they clawed the inner edge and left the outer one at the text inset: one
+  picture 96 from the canvas beside another at 36, which is what "it looks off" was.
+*/
+.split-figure.is-pair {
+  grid-column: var(--split-content-col);
+  grid-row: 1 / 3;
+}
+.is-left .split-figure.is-pair  { margin-right: 0; margin-left:  calc(-1 * (var(--deck-inset-text) - var(--deck-inset-media))); }
+.is-right .split-figure.is-pair { margin-left: 0;  margin-right: calc(-1 * (var(--deck-inset-text) - var(--deck-inset-media))); }
+/*
+  ★★ ONE SEAM, USED EVERYWHERE IN THE SET. The gutter between the two columns and the gap between
+  two pictures stacked in one column are the same number — Jose: "the space in the middle should be
+  the same separator". They were not: the grid's own column-gap is 0 on a mixed split (the figure's
+  edge does the separating) and --deck-split-gutter-same (96) when two columns are the same KIND,
+  while a stack inside a column used the grid gutter of 32. Three values in one picture set.
+
+  ⚠ AND IT IS THE GRID GUTTER, NOT THE SAME-KIND TOKEN. 96 is the air two columns of DIFFERENT
+  content need between them; a picture set is one object cut into pieces, and the seam inside an
+  object is the same 32 a `::grid` of tiles uses.
+*/
+.split-grid:has(.split-figure.is-pair) { column-gap: var(--deck-space-4); }
+/*
+  ══ FLUSH ══════════════════════════════════════════════════════════════════════════════════════
+
+  ★★ THE INNER CORNERS GO AND THE OUTER ONES STAY. Squaring all of them — which is what this did
+  first — draws a hard rectangle in the middle of a slide that has not bled, and the set reads as a
+  photograph someone forgot to finish rather than as one field. Jose: "flush doesn't look good, take
+  a look at the images". The corners on the OUTSIDE are the set's own edge against the deck ground,
+  and they are the same card corner every other figure on this layout carries.
+
+  ⚠ WHICH CORNERS ARE OUTER DEPENDS ON THE COLUMN, AND THE COLUMN DEPENDS ON `flip`. `.is-pair` is
+  the content-column picture, so it is the LEFT column on `.is-left` and the right one on
+  `.is-right`; the figure is the mirror. Written in logical corners — `start-start` is top-left in
+  this deck's writing mode — so each rule names the side rather than the corner twice.
+*/
+/*
+  ★★ THE SET'S OWN CORNER IS CAPTURED BEFORE THE TOKEN IS ZEROED. The rule below has to zero
+  --deck-radius-card on the figure so useNotchCuts draws a square outline — and the picture corners
+  read that same token, so zeroing it took the set's outer rounding with it: measured, all four
+  pictures at 0 and the set a hard rectangle again. Held on the ROOT, which does not override the
+  token, so the corners keep the card radius while the boxes under them go square.
+*/
+.split.is-flush { --set-corner: var(--deck-radius-card); }
+.split.is-flush .split-grid { column-gap: 0; }
+.split.is-flush .split-figure.is-photo {
+  gap: 0;
+  border-radius: 0;
+  /*
+    ⚠ AND THE NOTCH'S OWN RADIUS GOES WITH IT. useNotchCuts reads --deck-radius-card off the panel's
+    computed style and draws the whole outline — so the clip put a 48px arc back on EVERY corner,
+    including the two at the seam, and a flush set had a bite taken out of the middle of it at the
+    top and the bottom. `border-radius: 0` above cannot reach the clip; the token can, and the
+    rounding the set does keep is drawn on the pictures rather than on the box.
+  */
+  --deck-radius-card: 0px;
+}
+.split.is-flush .split-figure.is-photo > :deep(img) { border-radius: 0; }
+/* The left-hand column, whichever of the two boxes that is: first picture keeps the top-left corner,
+   last keeps the bottom-left. A single picture in the column is both, so `:first-child` and
+   `:last-child` both match it and it rounds the whole left side. */
+.split.is-flush.is-left  .split-figure.is-pair > :deep(img):first-child,
+.split.is-flush.is-right .split-figure:not(.is-pair) > :deep(img):first-child {
+  border-start-start-radius: var(--set-corner);
+}
+.split.is-flush.is-left  .split-figure.is-pair > :deep(img):last-child,
+.split.is-flush.is-right .split-figure:not(.is-pair) > :deep(img):last-child {
+  border-end-start-radius: var(--set-corner);
+}
+/* And the right-hand column, mirrored. */
+.split.is-flush.is-left  .split-figure:not(.is-pair) > :deep(img):first-child,
+.split.is-flush.is-right .split-figure.is-pair > :deep(img):first-child {
+  border-start-end-radius: var(--set-corner);
+}
+.split.is-flush.is-left  .split-figure:not(.is-pair) > :deep(img):last-child,
+.split.is-flush.is-right .split-figure.is-pair > :deep(img):last-child {
+  border-end-end-radius: var(--set-corner);
+}
+/*
+  ⚠ EXCEPT AT THE CANVAS EDGE, where there is no ground left for a corner to sit against: a bleeding
+  flush set is the whole frame in pieces, and a rounded corner there cuts a notch out of the slide.
+
+  ⚠⚠ AND IT HAS TO MATCH THE FOUR RULES ABOVE ON SPECIFICITY, WHICH IS WHY THE CHILD SELECTORS ARE
+  REPEATED HERE. Written as a plain descendant it is one class short of them — corner longhands are
+  resolved per property, so `border-start-start-radius` from a 5-class rule beat `border-radius: 0`
+  from a 4-class one and the bleeding set kept all four corners. Measured on the flush+bleed slide:
+  48px at every corner, against a canvas the pictures already reached.
+*/
+.split.is-flush.is-bleed .split-figure.is-photo > :deep(img):first-child,
+.split.is-flush.is-bleed .split-figure.is-photo > :deep(img):last-child { border-radius: 0; }
+/*
+  ★★ AND THE SET BLEEDS AS ONE OBJECT, WHICH TOOK A SECOND MIRROR. `edge` was bound to the figure
+  element alone, so a bleeding set had one column at the canvas and the other still inset: measured
+  on the flush+bleed slide, the figure ran 960 → 1920 and 0 → 1080 while the pair sat at 36 → 960 and
+  96 → 984. The vertical claw-backs are side-agnostic and apply to both as written; the horizontal
+  one names `.is-left`/`.is-right`, which is where the FIGURE is, so the pair takes the mirror.
+*/
+.is-left .split-figure.is-pair.is-bleed  { margin-right: 0; margin-left:  calc(-1 * var(--deck-inset-text)); }
+.is-right .split-figure.is-pair.is-bleed { margin-left: 0;  margin-right: calc(-1 * var(--deck-inset-text)); }
+/*
+  ★★ EACH COLUMN IS A STACK, because a column can hold two. Three pictures is one and two; four is
+  two and two. The gutter between two pictures in a column is the same one the layout puts between
+  its columns — `--deck-space-4` is `.split-grid`'s own gap — so a 2x2 set reads as one grid rather
+  than as two columns that happen to be beside each other.
+*/
+.split-figure.is-photo:has(> img + img) {
+  flex-direction: column;
+  gap: var(--deck-space-4);
+}
+.split-figure.is-photo > :deep(img) {
+  /* `flex: 1` rather than `height: 100%`: two pictures in one column share it, one takes all of it. */
+  flex: 1 1 0;
+  width: 100%;
+  min-height: 0;
+  object-fit: cover;
+  display: block;
+  border-radius: var(--deck-radius-card);
+}
+/*
+  ★★ `--warm-100`, THE SAME MAT stack's BAND TAKES, because `frame: 'panel'` has to mean one thing.
+
+  This was `--deck-bg-subtle` — `color-mix(--deck-bg, --deck-fg 8%)`, the page ground pushed toward
+  the ink — which renders grey. stack's band at the same `frame: 'panel'` defaults to `background: 'warm'`
+  and renders `--warm-100`. So one prop name gave two different surfaces depending on which layout
+  you were in, and this layout's own doc for the prop calls it "a TINTED box", which the grey was
+  not. Jose, on a panel split: "why is the color neutral? isn't the default the warm color?"
+
+  The AXIS came with it: `background` below is stack's prop, its four values, and its four rules read from
+  the same tokens — so the two layouts now agree about what a panel is and what can be done to one,
+  rather than sharing a prop name and meaning different things by it.
+*/
+.split-figure.is-panel {
+  border-radius: var(--deck-radius-card);
+  padding: var(--deck-card-pad);
+  display: flex;
+  /* The cross axis is `panelAlign`'s, above. */
+  justify-content: center;
+}
+/*
+  The four registers, scoped to `.is-panel` so a background on any other frame is inert. The same four
+  named backgrounds stack's bands take — one table, read by both — because a panel and a band of the
+  same name should be the same colour, and two copies of that list would not stay so.
+
+  ⚠ This named `--deck-accent-soft`, `--deck-bg-subtle`, `--warm-100` and `--forest-300`, which was
+  the loose-fill palette that predates the one table.
+*/
+.split-figure.is-panel.bg-warm { background: var(--deck-bg-warm); color: var(--deck-on-bg-warm); }
+.split-figure.is-panel.bg-accent { background: var(--deck-bg-accent); color: var(--deck-on-bg-accent); }
+.split-figure.is-panel.bg-vivid { background: var(--deck-bg-vivid); color: var(--deck-on-bg-vivid); }
+.split-figure.is-panel.bg-neutral { background: var(--deck-bg-neutral); color: var(--deck-on-bg-neutral); }
+
+/*
+  ── 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.
+*/
+.split-figure.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.
+*/
+.split-figure.is-code {
+  --slidev-code-padding: 0px;
+}
+.split-figure.is-code :deep(.slidev-code-wrapper),
+.split-figure.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.
+*/
+/*
+  ★★ A NOTCHED CODE SURFACE RESERVES THE TOP AND NOT THE BOTTOM, which is where it parts company
+  with a notched panel.
+
+  The shared reservation below puts `max(card-pad, notch-h)` at BOTH ends, and its own note is honest
+  about why: the bottom "buys nothing but symmetry", so that media CENTRED in the panel shares the
+  centre a viewer sees. A code surface is not centred media — it is a block that starts at the top of
+  its box — so the mirrored 96px at the foot is 64px of code height bought for a reason that does not
+  apply here. The top keeps it, because that is the mark's seat and it is structural.
+
+  The horizontal stays at --deck-card-pad, which is where a plain code block already insets its text,
+  so a code frame and a code block agree on the one edge they can be compared across.
+*/
+.split-figure.is-code.has-notch {
+  border: none;
+  padding-top: max(var(--deck-card-pad), var(--notch-h));
+  padding-bottom: var(--deck-card-pad);
+}
+/*
+  ★★ BLEEDING, IT KEEPS THE CODE'S OWN INSET HORIZONTALLY RATHER THAN THE REGION'S.
+
+  Every other bleeding panel takes --deck-inset-text on all four sides, so its content lines up with
+  the content column across the seam — that is the rule the panel's own note argues for, and it is
+  right for PROSE, which is what a content column holds.
+
+  A code surface is not prose. Its neighbour on the other side of the seam is a paragraph; its
+  neighbour on every other slide is a code block, and a code block insets its text by
+  --deck-card-pad. Matching the block is worth more than matching the column, because the reader
+  compares code to code. So the horizontal follows the notched code surface above, and the vertical
+  keeps the region inset it needs to stand off the canvas edge.
+*/
+.split-figure.is-code.is-bleed {
+  border: none;
+  border-radius: 0;
+  padding: var(--deck-inset-text) var(--deck-card-pad);
+}
+
+/* Media matted inside a panel takes the CONCENTRIC radius — the card's corner minus its padding —
+   so the inner curve sits parallel to the outer one instead of fighting it. */
+/*
+  ⚠ `: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
+  (`.split-figure.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.
+*/
+.split-figure.is-panel :deep(img:not(.mark-pair-companion)),
+.split-figure.is-panel :deep(video),
+.split-figure.is-panel :deep(picture) {
+  max-width: 100%;
+  border-radius: var(--deck-radius-nested);
+  display: block;
+}
+/* ── THE NOTCH ──────────────────────────────────────────────────────────────────────────────────
+  task-15-brief.md. The panel's outer top corner is cut INWARD so the running Forest mark sits in
+  the cut-out, and the panel's edge reads convex → concave → convex around it.
+
+  ★ THE CUT ITSELF IS NOT HERE. It is one shared rule, `.deck-notch` in styles/base.css, because
+  task-18 gave the theme a SECOND notched figure: stack.vue's band cuts the same corner around the
+  same mark. Two copies of a five-layer composited mask is exactly the drift this codebase keeps
+  re-discovering the hard way, so the shape moved out and both layouts wear the class. What stays
+  here is what is genuinely split's: which corner is the outer one (bound in the template, since it
+  flips with `flip`), the margin that raises the panel to meet the mark, and the band a notched
+  PANEL reserves from its own content.
+
+  ★ THE PANEL RISES TO MEET THE MARK. Without this, there is nothing to notch: the mark is inset
+  --deck-inset-chrome (36px) from the top, the figure's own vertical bound is --deck-inset-text
+  (90px), and the two boxes overlap by only 18px — a bite that shallow is a nick, not a seat, and
+  what actually renders without it is a 72px mark parked on top of a photograph's corner. On a
+  notched panel the TOP margin therefore drops to the chrome inset, which is also exactly why chrome
+  and media share that number (scripts/deck.ts, above INSET): the mark's outer corner and the
+  panel's outer corner become the SAME POINT, so the mark reads as seated in the corner with one
+  clean ring of clearance — 36px of slide margin outside it, 36px of cut-out inside it.
+
+  ★★ AND THE BOTTOM COMES WITH IT (task-26). This rule used to move the TOP only, on the reasoning
+  that "there is no chrome in the panel's bottom corner to make room for". True, and it is an
+  argument for not needing a notch at the bottom — not for keeping the bottom 54px further in than
+  the other three sides. Measured, every one of the 86 media figures in the three decks rendered
+
+      outer edge 36 · top 36 · bottom 90
+
+  i.e. a frame hanging 54px higher off the bottom edge than off the other three, on every media
+  slide in the deck, with deck.css's own token comment calling the asymmetry intended. Jose's rule
+  is 36 on every side for media; the notch is what makes 36 safe at the top, and nothing ever made
+  it unsafe at the bottom — the only bottom chrome is the `confidential:` pill, which renders only
+  when a slide declares one and sits on the pills side, i.e. the opposite side of the slide from the
+  figure on every split — the chrome no longer mirrors at all (see ../notch.js above hasNotch).
+
+  So a notched figure is 36 on all four sides and an un-notched one is 90 top and bottom — the
+  vertical pair moves TOGETHER with the cut, which is what makes `notch: false`'s documented promise
+  ("EXACTLY its pre-notch geometry") true of both edges rather than one.
+
+  ⚠ ALL OF IT DROPS TOGETHER ON `notch: false`. The mask (via the class), these margins and the
+  reservation below all key off the same `notched` computed, so an opted-out figure returns to
+  exactly its pre-notch geometry rather than keeping a raised top with no cut in it — see
+  notchShows() in ../notch.js for what that restores and why the escape hatch exists.
+*/
+.split-figure.has-notch {
+  /*
+    The panel's own outer corner moves up to the mark's. See the note above.
+
+    ★ NEGATIVE NOW, AND FOR THE SAME REASON THE HORIZONTAL CLAW-BACK IS: these used to be absolute
+    positions (36 from a canvas edge the root did not pad). The root pads by the text inset today, so
+    reaching the chrome/media inset is the DIFFERENCE between the two — exactly the shape the outer
+    edge already uses. Same two numbers, expressed as the gap between them rather than restated.
+  */
+  margin-top: calc(-1 * (var(--deck-inset-text) - var(--deck-inset-chrome)));
+}
+/*
+  ★★ THE BOTTOM ESCAPE ONLY EXISTS WHEN THERE IS NOTHING BELOW IT. A figure spans rows 1-2 and
+  claws past the grid's bottom edge to reach the media inset — which is right when row 2 ends at the
+  safe line, and wrong the moment a `::footer::` occupies row 3: the escape then reaches 60px PAST
+  the row boundary and lands 36px inside the footer. Measured on the footer specimen: figure bottom
+  971 against a footer starting at 935.
+
+  Scoped with `:not(:has(.split-footer))` rather than fixed by trimming the number, because the
+  number is right — a figure with nothing under it should reach the media inset. It is the presence
+  of a footer that removes the edge to escape to.
+*/
+.split-grid:not(:has(.split-footer)) .split-figure.has-notch {
+  margin-bottom: calc(-1 * (var(--deck-inset-text) - var(--deck-inset-media)));
+}
+/*
+  THE SPACE, as opposed to the shape. A mask clips; it does not reflow, so a tinted panel holding
+  real content would have that content's corner sliced off — the asymmetry where a photo panel
+  looks perfect and a text panel silently truncates a word. The cut's own height is reserved as top
+  padding (never less than the card padding the panel already had), which keeps every child clear
+  of the notch band regardless of what the panel holds or how it is aligned inside it.
+
+  A band rather than a corner-shaped exclusion: `.is-panel` centres its content with flex, and a
+  float with `shape-outside` — the only way to actually wrap text around a corner — does not apply
+  to a flex item at all. The band is the honest version of the same guarantee.
+
+  `.is-photo` deliberately gets none of this: clipping the photograph IS the effect.
+*/
+/*
+  ★★ RESERVED AT BOTH ENDS, SO WHAT SITS IN A NOTCHED PANEL IS ACTUALLY CENTRED.
+
+  The top reservation is the notch: content must clear the bite cut out of the corner for the running
+  mark, so the panel keeps `--notch-h` (mark 72 + ring 24 = 96) above it. Only the top was reserved,
+  which left the box 96/32 — and anything centred in it lands (96 - 32) / 2 = 32px LOW inside the
+  panel. Measured on the video slide: phone y 142-1002 in a panel y 36-1044, dead centre of the
+  CONTENT box and 32 off the centre of the panel. Jose spotted it as "the iphone is not centered
+  vertically".
+
+  ⚠ THE BOTTOM RESERVATION BUYS NOTHING BUT SYMMETRY, and that is the whole point of it. There is no
+  notch down there and nothing to clear; the padding exists so the box a figure is centred in has the
+  same centre as the panel a viewer sees. It costs 64px of usable height on every notched panel split
+  — the honest price, paid once in the frame, rather than a magic offset on each slide that happens
+  to hold something centred.
+*/
+.split-figure.is-panel.has-notch,
+/*
+  ★ `.is-figure` TAKES THE SAME RESERVATION, WITHOUT THE FILL. A naked figure had no padding at all,
+  so it sat flush to the cell — which puts its top edge inside the notch's own bite and lets a wide
+  one run under the running mark. Jose: "can we still give the padding to the naked version, so it
+  doesnt overlap... similar treatment as panel, just without the bg."
+
+  The same expression rather than a bare `--notch-h`, so the two kinds cannot drift: whatever a
+  notched panel reserves, a notched figure reserves. What `.is-figure` still does NOT get is the
+  background, the radius and the horizontal card padding — it is a figure sitting on the page, not a
+  matted one, and only the vertical clearance was ever the shared problem.
+*/
+.split-figure.is-figure.has-notch {
+  padding-top: max(var(--deck-card-pad), var(--notch-h));
+  padding-bottom: max(var(--deck-card-pad), var(--notch-h));
+}
+.split-content { min-width: 0; }
+.split-figure { min-width: 0; }
+/*
+  ★ THE SPLIT COLUMN RUNS AT THE BODY TIER BY DEFAULT, THE SAME AS EVERY OTHER SLIDE.
+
+  It used to step down to body-sm on the argument that "two columns halve the measure, so both sides
+  take the dense body tier". The measure is halved and that is exactly why the tier should NOT be:
+  a slide's body copy is 48px because that is what carries a room, and a column is not a reason for
+  the audience at the back to get a smaller one. The measure is already handled where it belongs —
+  a narrow column simply wraps sooner, which is what a column is for.
+
+  The cost is real and is paid deliberately: at 48px a split column fits about a third less copy
+  than it did, so a slide that was full is now over. That is the deck telling the author the column
+  holds less, which is a better failure than shrinking the type until it fits.
+*/
+.is-body-base .split-grid { font-size: var(--type-deck-body-size); line-height: var(--type-deck-body-line-height); }
+/* The dense tier, opted into per slide — see the `body` prop for when that is the honest answer. */
+.is-body-sm .split-grid { font-size: var(--type-deck-body-sm-size); line-height: var(--type-deck-body-sm-line-height); }
+/* No margin-bottom here: the h1 inside the band already carries `margin: 0 0 var(--deck-space-3)`
+   (base.css), and against a row fixed at 360 the second one was invisible slack. With the row sized
+   to its band it would double the title-to-body gap to 48 where `default` gives 24. */
+.split-footer { margin-top: var(--deck-space-3); }
+</style>