@humanforest/slidev-theme 0.1.0

package/setup/mermaid-renderer.ts

@@ -0,0 +1,2120 @@
+// A CUSTOM MERMAID RENDERER, and the reason it has to be a renderer rather than a config.
+//
+// Slidev offers two hooks. `setup/mermaid.ts` returns a config object — but @slidev/client's
+// setup/mermaid.ts wraps it in `createSingletonPromise`, so it is resolved ONCE for the lifetime of
+// the page. One config, one palette. This deck runs light and marks individual slides
+// `class: deck-dark` (deck.css: "dark is punctuation, not the ground"), so a single frozen config
+// can serve one of the two registers and gets the other wrong — which, on a diagram whose edges are
+// drawn in the accent, means arrows a shade off the ground they sit on.
+//
+// `setup/mermaid-renderer.ts` is the other hook, and it is called PER RENDER
+// (@slidev/client/modules/mermaid.ts: `for (const setup of mermaidRenderers) { const renderer =
+// await setup(); if (renderer) { … } }`). That is what lets one deck hold both registers.
+//
+// ★ THE REGISTER TRAVELS AS `theme`, deliberately reusing mermaid's own prop rather than inventing
+// one. Two things fall out for free. Slidev already passes `theme: isDark ? 'dark' : undefined`
+// from the global toggle, so pressing `d` re-renders every diagram in the dark palette with no
+// author involvement. And `options` is part of modules/mermaid.ts's own CACHE KEY
+// (`lzEncoded + JSON.stringify(options)`), so the light and dark renders of the same diagram are
+// two entries rather than one stale one — which a bespoke prop outside that key would not have been.
+// A slide opts in per diagram with:
+//
+//     ```mermaid {theme: 'dark'}
+//
+// ★★ AND `useMaxWidth` IS WHY THE SVG FITS. mermaid stamps a fixed `width`/`max-width` on its root
+// <svg> from the diagram's own natural size. With labels set at the deck's 36px body rung — which
+// is what makes a diagram legible from the back of a room in the first place — natural size is
+// routinely wider than the slide, and the overflow leaves the canvas rather than scaling. Each
+// diagram family has its own `useMaxWidth` switch (they do not share one), and the ones this deck
+// draws are set in components/mermaidTheme.ts; the post-processing below is the backstop for the
+// families that ignore it.
+import type { MermaidRenderFn } from '@slidev/types';
+import type { Register } from '../components/deckPalette';
+import { MERMAID_FONT_FAMILY, MERMAID_FONT_PX, MERMAID_EDGE_LABEL_FONT_PX, MERMAID_INDEX_FONT_PX, MERMAID_TAG_FONT_PX, MERMAID_LEGEND_FONT_PX, DIAGRAM_STROKE_PX, mermaidConfig, mermaidInkRules, mermaidBackgroundRules } from '../components/mermaidTheme';
+
+/** mermaid's ESM build, the same specifier @slidev/client resolves. */
+async function loadMermaid() {
+  const mod = await import('mermaid/dist/mermaid.esm.mjs');
+  return (mod as { default: typeof import('mermaid').default }).default;
+}
+
+let counter = 0;
+
+/**
+ * Fit the rendered SVG to its column — SHRINK ONLY, never stretch.
+ *
+ * mermaid emits a hard `width` and a `style="max-width: …px"` from the diagram's natural size.
+ * Left alone, a diagram wider than its column paints past the slide edge, and it does so as an SVG
+ * overflow that scripts/deckAudit.ts cannot see, because the host element's own border box is still
+ * inside the column.
+ *
+ * ★★ AND THE OBVIOUS FIX IS WORSE THAN THE PROBLEM. A plain `width:100%` makes every diagram fill
+ * its column, including the ones that are narrower than it — measured on a five-state vertical
+ * `stateDiagram-v2` (viewBox 263 x 510, aspect 0.52): stretched across a 1160px column it came out
+ * **2247px tall**, four slides' worth of height for five boxes, with the first label alone taller
+ * than the slide heading. The cap has to be the diagram's OWN width, so `min(natural, 100%)`:
+ * a wide diagram shrinks to fit, a narrow one is left at the size mermaid laid it out at.
+ *
+ * ★★ AND THE HEIGHT IS A CAP TOO, because for one whole family it is the binding one. A sequence
+ * diagram grows a ROW per message and a COLUMN per actor, so it runs out of slide vertically long
+ * before it runs out of column. MEASURED: the specimen's own three-message sequence is 882x739 in a
+ * 1728px column — no width shrink at all, and 739 against the 720 the slide has between the
+ * diagram's top and the bottom inset. Three messages already over. A five-actor, sixteen-message
+ * one measured 1776x2380 and the audit put it 1500px past the bottom of the canvas.
+ *
+ * The cap is expressed as a THIRD TERM IN THE WIDTH, not as a max-height: the SVG is a replaced
+ * element whose height follows its width by the viewBox ratio, so `H_MAX x naturalW / naturalH` is
+ * the width at which the drawing is exactly H_MAX tall. min() then picks whichever bound bites.
+ * A max-height would need a definite height on a parent this function cannot reach.
+ *
+ * A diagram shorter than the budget is untouched — the third term is larger than its natural width,
+ * so min() never selects it.
+ *
+ * Rewritten in the string rather than styled: the SVG is inside a shadow root, so no stylesheet in
+ * this theme can reach it. The viewBox is left exactly as mermaid computed it, so nothing is
+ * re-laid-out — only the box the drawing is fitted into changes.
+ */
+/*
+  The height a diagram may occupy, in canvas px, and the CSS variable a layout overrides it with.
+
+  720 is the DEFAULT layout: 1080 canvas − the 264 a diagram's top sits at under a heading − the 96
+  bottom inset. MEASURED on slide 245, whose host box starts at 264 and whose safe area ends at 984.
+
+  ★★ A LAYOUT THAT GIVES A DIAGRAM MORE HAS TO SAY SO, because this function cannot see where it is.
+  A split's figure column carries no heading above it, so its budget is 1080 − 96 − 96 = 888 — a
+  quarter more, which for a height-bound diagram is a quarter more of everything. split.vue sets the
+  variable; anything that does not, gets the default.
+*/
+export const DIAGRAM_MAX_H = 720;
+export const DIAGRAM_MAX_H_VAR = '--deck-diagram-max-h';
+
+export function fitToColumn(svg: string): string {
+  const viewBox = /viewBox="([^"]+)"/.exec(svg)?.[1]?.trim().split(/\s+/);
+  const naturalWidth = viewBox?.length === 4 ? Number(viewBox[2]) : Number.NaN;
+  const naturalHeight = viewBox?.length === 4 ? Number(viewBox[3]) : Number.NaN;
+  // No viewBox is not a case to guess at: without one there is no natural size to cap against, and
+  // 100% would be the stretch this function exists to avoid.
+  const sized = Number.isFinite(naturalWidth) && naturalWidth > 0;
+  const tall = sized && Number.isFinite(naturalHeight) && naturalHeight > DIAGRAM_MAX_H;
+  const ratio = naturalWidth / naturalHeight;
+  const terms = sized
+    ? [`${Math.ceil(naturalWidth)}px`, '100%',
+       ...(tall ? [`calc(var(${DIAGRAM_MAX_H_VAR}, ${DIAGRAM_MAX_H}px) * ${ratio.toFixed(4)})`] : [])]
+    : [];
+  const cap = terms.length ? `min(${terms.join(', ')})` : '100%';
+  return svg
+    .replace(/<svg([^>]*?)\swidth="[^"]*"/, '<svg$1')
+    .replace(/<svg([^>]*?)\sheight="[^"]*"/, '<svg$1')
+    .replace(/<svg([^>]*?)\sstyle="[^"]*"/, '<svg$1')
+    .replace(/<svg\b/, `<svg style="width:${cap};height:auto;display:block;margin:0 auto"`);
+}
+
+/*
+  ── THE ROOM-SCALE FLOOR ───────────────────────────────────────────────────────────────────────
+
+  Some of mermaid's own sizes are not configurable at all. They are literals inside the stylesheet
+  it generates, driven by no theme variable and no config key, and two of them are wrong for a deck:
+
+    · `.edgeLabel .label { font-size: 14px }`  — the ER diagram's relationship labels ("contains",
+      "holds"). Measured: 14px beside 36px entity names, on a 1920px canvas. `er.fontSize` does not
+      move it, because nothing reads that key for this rule.
+    · `.slice { font-family: "trebuchet ms", verdana, arial, … }` — the pie chart's labels, hard-
+      coded past the `fontFamily` the rest of the diagram obeys.
+
+  ★ THE SHADOW ROOT IS NOT THE OBSTACLE HERE, because this runs BEFORE the SVG becomes one. The
+  renderer returns a STRING, and mermaid's own <style> block is inside it, so appending rules to
+  that block puts them in the same shadow root at the same specificity — and later in source order,
+  which is what wins a tie. A stylesheet in this theme could never do this; a string rewrite can.
+
+  Deliberately a SHORT, NAMED list rather than a blanket `* { font-size: … }`: mermaid uses relative
+  sizes in places, and flattening all of them would break diagrams that are currently correct. Each
+  entry is a measured literal with the diagram family it belongs to.
+*/
+/*
+  ★★ A STROKE IS IN THE DRAWING'S OWN UNITS, SO IT SCALES WITH IT.
+
+  fitToColumn caps a wide diagram at its column, which scales the whole SVG down — measured on the
+  specimen's flowchart, a 1603-unit viewBox drawn into 872px, a factor of 0.544. Mermaid's stroke
+  widths are in SVG units, so they shrink with it: the node border and every link, both set to 1px,
+  render at 0.54 canvas px. A half-pixel line is a line the back row cannot see, and because the
+  factor is per-diagram, two diagrams on consecutive slides carry visibly different weights.
+
+  This was `vector-effect: non-scaling-stroke`, which takes stroke width out of the scaled
+  coordinate space so the value below renders whatever the diagram's size. It cures the thin end by
+  making the line the ONE thing on a slide that does not scale, and the thick end is just as wrong:
+  at a fit of 0.37 — the sixteen-message sequence — every box, gap and letter shrinks while the ink
+  stays put, so the line reads thirteen times heavier relative to its diagram than at natural size.
+
+  Stated in UNITS instead, it scales like the corner radius, the type and the node it outlines. At
+  natural size it is still 4 canvas px, where every other strong edge in the deck sits; at 0.5 it is
+  2, and the diagram reads as the same drawing seen from further away rather than a different one.
+
+  ⚠ The thin end is back in principle, and the height cap is what holds it off — a diagram cannot be
+  scaled arbitrarily small before fitToColumn stops it. At the smallest fit the specimen actually
+  produces this is 1.5 canvas px against mermaid's own 0.37. Past that the answer is fewer things on
+  the slide, not a heavier line.
+
+  The FILL is deliberately left alone. A mermaid node is a Card, and the deck draws a card as a quiet
+  --deck-surface fill read by its border and its corner — not by a loud ground. Fixing the border so
+  it renders is the system-consistent repair; reaching for a stronger fill would be treating the
+  symptom.
+*/
+/* ★ DECLARED IN mermaidTheme.ts AND RE-EXPORTED HERE. It moved the day radar needed it: that
+   family states its axis, graticule and curve weights as THEME VARIABLES, which are built in
+   mermaidTheme, and this file already imports from there — so declaring it here and importing it
+   back would have been a cycle. Re-exported rather than relocated in every caller, because the
+   rules below are where the number is most often read and the import list is not the story. */
+export { DIAGRAM_STROKE_PX } from '../components/mermaidTheme';
+/*
+  ★ THE RADIUS IS IN SVG UNITS AND THOSE SCALE, which is why this is not one of the deck's own
+  corner steps. fitToColumn draws a wide diagram at a fraction of its natural size — 0.544 on the
+  specimen's flowchart — so the rendered corner is this value times that fraction. At the item step
+  (8) it came out at 4 canvas px, a square with the edge taken off rather than a rounded box. There
+  is no non-scaling equivalent for a corner the way there is for a stroke, so the number is chosen
+  for what it RENDERS at, and a diagram drawn at a different scale carries a proportionally different
+  corner — which is right for a radius, unlike for a line.
+*/
+const DIAGRAM_RADIUS = 28;
+/*
+  ★★ A POLYGON ROUNDS FAR LESS THAN A RECT, AND THE ARROWS ARE WHY. Mermaid computes an edge's
+  endpoint against the SHARP shape and leaves a fixed gap for the head to cover — 4 user units to a
+  rectangle. Rounding a corner pulls the silhouette back from the vertex the arrow was aimed at, and
+  on a 45-degree diamond point the tip retreats by roughly the radius times cos 45. At the rect's 28
+  that is ~20 units of daylight the head has no way to cross, because the path was laid out before
+  this rewrite and cannot be moved without redoing mermaid's own intersection maths.
+
+  Mermaid already leaves a diamond 14.4 units rather than 4 — measured on the specimen's flowchart —
+  so the gap starts wider and this only decides how much worse it gets. Small enough to read as a
+  softened point, not so large that the arrow stops in mid-air.
+*/
+const POLYGON_RADIUS = 10;
+
+
+/*
+  The fragment keyword's size is mermaidTheme's, because the TAB it sits in is scaled from the same
+  number there. Set through CSS because mermaid's sequence font keys are all dead.
+*/
+const TAG_FONT_PX = MERMAID_TAG_FONT_PX;
+
+/* The gap mermaid leaves between an autonumber's disc centre and the baseline it writes the digit
+   on — MEASURED off the rendered markup, a marker at y=175 against `<text y="179">`. It is half a
+   cap height at mermaid's own 12px, and a constant, so it does not follow the deck's type. */
+const SEQUENCE_NUMBER_BASELINE_DROP = 4;
+
+/* The same gap for a fragment keyword, and it comes from a different place: drawLabel puts the text
+   y at the tab's centre and drawText's valign-middle yfunc then adds boxTextMargin/2 on top of it,
+   so every keyword is laid out below its own tab's centre by half the tag scale (6/2, plus 0.5 from
+   the rounding). MEASURED off the rendered markup, not derived. */
+const TAG_BASELINE_DROP = 3.5;
+
+/* The disc's radius as a fraction of the index's type, which is left where it is — this number
+   moves the disc alone. mermaid's own is a flat half, r=6 against a 12px digit, and at deck size
+   that reads as a token the eye stops on rather than a marker on the line. Tightened twice: 0.44
+   still sat as a filled counter beside the message, 0.36 reads as a bullet the number happens to
+   be in. A two-digit index overhangs at any of these, mermaid's own included — the disc is a mark
+   on the line, not a container. */
+const SEQUENCE_NUMBER_DISC_RATIO = 0.36;
+
+// The pie legend's own size, the same 0.8 step mermaidTheme sets `pieLegendTextSize` from — one
+// number, so the spacing pass and the text it is spacing cannot disagree.
+const PIE_LEGEND_PX = Math.round(MERMAID_FONT_PX * 0.8);
+
+/*
+  The radar legend's swatch, and the gap between it and the word it names. mermaid draws a 12x12
+  chip and puts the text 16 units to its right — both sized for its own ~12px legend, and both
+  presentation attributes, so a rule and a rewrite reach them. Stated as fractions of the legend
+  rung rather than as numbers, because the whole point of the pass below is that the three move
+  together.
+*/
+const RADAR_SWATCH_PX = Math.round(MERMAID_LEGEND_FONT_PX * 0.8);
+const RADAR_SWATCH_GAP_PX = Math.round(MERMAID_LEGEND_FONT_PX * 0.4);
+
+// How far a sequence message label drops so its INK, rather than its em box, is what sits between
+// the two lines. A quarter of an em is half the descender depth this face reserves and never uses
+// on these labels; see the rule below for the measurement it corrects.
+export const MESSAGE_INK_DROP = 0.25;
+
+// A journey's satisfaction face, as a multiple of the label beside it. mermaid draws it at r=15,
+// sized for its own 14px type; this is what makes it a mark rather than a speck at the deck's rung.
+export const FACE_DIAMETER_EM = 1.7;
+
+/*
+  ★★ A GANTT LABEL SITS LOW BECAUSE OF A CONSTANT THAT DOES NOT SCALE. mermaid places the baseline
+  from its own renderer as
+
+      text y = order * gap + barHeight / 2 + (fontSize / 2 - 2) + topPad
+      rect y = order * gap + topPad
+
+  so the baseline drops `fontSize / 2 - 2` below the bar's centre. At mermaid's own 11px that `- 2`
+  is 18% of the term and the result lands close to centring the CAP HEIGHT, which is what the eye
+  reads as centred. At this deck's 36px the same 2 is 5.5%, and the label drops low.
+
+  MEASURED against the shipped face: cap height 25.21 at 36px (0.70em), so cap-centring wants the
+  baseline 12.6 below the middle and mermaid puts it at 16 — 3.4 units low, uniform across every
+  row. The ratio is a property of the face and is pinned here rather than assumed; a face swap moves
+  it, which is why it is named.
+*/
+export const GANTT_CAP_RATIO = 0.7;
+export const GANTT_LABEL_RISE = MERMAID_FONT_PX / 2 - 2 - (GANTT_CAP_RATIO * MERMAID_FONT_PX) / 2;
+
+const ROOM_SCALE_RULES = [
+  // ER relationship labels — mermaid's hard 14px.
+  /*
+    ★ A TRANSITION NAME IS AN ANNOTATION ON A LINE, not prose, and takes the same rung the autonumber
+    index does. mermaid's own is a hard 14px — sized for its 16px type — and this rule used to lift
+    it to the full body rung, which put the word on a transition at the same size as the state it
+    joins. It is already muted to 75% for the same reason; the size and the mute are one argument.
+  */
+  `.edgeLabel .label{font-size:${MERMAID_EDGE_LABEL_FONT_PX}px;}`,
+  /*
+    ★ THE GIT COMMIT ID IS ANOTHER HARD LITERAL. mermaid writes `.commit-label` at 10px — its own
+    16px-era size — with no config key that reaches it, the fourth instance of this pattern in the
+    family after the ER edge label's 14, the gantt title's 18 and the autonumber's 12. It names a
+    commit, so it takes the same rung a transition name does.
+  */
+  `.commit-label{font-size:${MERMAID_EDGE_LABEL_FONT_PX}px;}`,
+  /*
+    ★★ THE TIMELINE'S CONNECTORS ARE HARD-CODED PASTELS, and they are the last unthemed colour in
+    the family. mermaid draws the line from a period band down to its events as `line.node-line-N`
+    with a literal per-index pastel — MEASURED off the rendered slide, `rgb(165,206,255)` pale blue,
+    `rgb(255,207,183)` peach and `rgb(255,219,239)` pink. None is derived from anything the theme
+    sets, and on this deck's cream paper all three are very nearly invisible.
+
+    They carry the connection between a period and what happened in it, which is the same job every
+    other edge in the deck does, so they take the same accent. One colour rather than three: the
+    band above already says which period a line belongs to, and a second encoding of that in a tint
+    nobody can see is not an encoding.
+  */
+  `line[class*="node-line"]{stroke:var(--deck-accent);}`,
+  `.branch-label{font-size:${MERMAID_EDGE_LABEL_FONT_PX}px;}`,
+  /*
+    ★★ THE LABEL KNOCKS OUT THE LINE, SO ITS FILL MUST BE THE GROUND IT SITS ON — and mermaid's own
+    `edgeLabelBackground` cannot be trusted to be it. MEASURED across one page's renders: this theme
+    sets that variable to the page ground (#fff9f2 light), and mermaid honoured it on one diagram
+    and fell back to `mainBkg`/`tertiaryColor` on the next — which is --deck-surface, #f2ece5. A
+    grey box on cream paper, differing between two diagrams on the same slide. Same family of
+    defect as the dead `sequence.*FontSize` keys documented in mermaidTheme.
+
+    A custom property rather than a colour, because the ground is not always the page: a diagram
+    inside a named background has to knock out to THAT fill. The four backgrounds set this variable
+    in styles/base.css and it inherits into the SVG; the fallback is --deck-bg, which is already
+    per-register, so the dark register needs no second rule.
+
+    These are appended AFTER mermaid's own <style>, at the same specificity, so they win on order —
+    which is what `scope` and the append in applyRoomScale() are for.
+  */
+  /*
+    ★★ A COMPOSITE STATE DRAWS TWO RECTS, and `.cluster rect` in the stroke list gives BOTH the deck's
+    4px border — so the container came out double-ruled along the bottom, two lines a few units apart.
+    mermaid nests an inner rect inside `rect.outer`; the outer IS the container and the inner is
+    scaffolding. The corner rule already singles out `rect.outer`, so this makes the stroke agree.
+  */
+  `.statediagram-cluster rect:not(.outer):not(.basic){stroke:none;fill:none;}`,
+  /*
+    ★★ A MILESTONE IS A DIAMOND, AND THE DECK'S OWN CORNER WAS ERASING IT. mermaid draws one as a
+    square rotated 45°, sized from `barHeight` — 56 here — and `rect.task` is in the corner rule
+    above at 28px. A 56x56 square with a 28px radius IS A CIRCLE, and a circle rotated 45° is the
+    same circle: the diamond that distinguishes a milestone from a task never appeared. Measured on
+    this slide before the rule, and it is the one place in the family where the deck's own treatment
+    destroys a notation rather than restyling it.
+
+    Squared off, because the corner is what the shape means here.
+  */
+  `rect.milestone,.milestone rect,rect.task.milestone{rx:0;ry:0;}`,
+  `.edgeLabel .label rect{fill:var(--deck-mermaid-label-bg,var(--deck-bg));}`,
+  /*
+    ⚠ A LABEL INSIDE A CONTAINER STILL KNOCKS OUT TO THE PAGE, and nesting cannot fix it. An edge
+    label drawn inside a `subgraph` or a composite sits on the container's surface, so the
+    page-coloured knockout above is the wrong ground there. A descendant rule was tried and is DEAD:
+    mermaid collects every edge label into one `g.edgeLabels` at the ROOT and positions it by
+    transform, so no label is ever a descendant of the cluster it appears to sit in. Reaching it
+    would mean matching on coordinates, which a stylesheet cannot do.
+  */
+  `.edgeLabel .label span{background:var(--deck-mermaid-label-bg,var(--deck-bg));}`,
+  /*
+    ★★ AND INSIDE A CONTAINER THE GROUND IS THE CONTAINER. groundLabelsOnContainers marks the labels
+    a `subgraph` or a composite state encloses; this is what the mark does. Re-pointing the VARIABLE
+    rather than painting the rect is what makes one declaration enough:
+
+      · the knockout `rect` and the `span` are two different label forms — mermaid ignores
+        `htmlLabels: false` for edge labels in 11.17.2, so a flowchart's are HTML in a foreignObject
+        and a state diagram's are SVG — and a custom property inherits into both;
+      · the ink is a MIX TOWARD ITS OWN GROUND, so the word mutes toward the surface it sits on
+        instead of toward a page it does not, which painting the rect alone would have got wrong.
+
+    ★ Its own variable, defaulting to the surface, so a named background can re-point the container
+    ground without touching the page ground beside it. `.marker.aggregation` reads
+    --deck-mermaid-label-bg too and must keep the PAGE value: it lives in <defs>, where a property
+    set on a group inside the drawing cannot reach it — which is exactly why this is scoped here and
+    not at the SVG root.
+  */
+  `.edgeLabel .label[data-on-container]{--deck-mermaid-label-bg:var(--deck-mermaid-container-bg,var(--deck-surface));}`,
+  /*
+    ── THE THREE FAMILIES THE TWELVE-SLOT CATEGORICAL WAS WRITTEN FOR ────────────────────────────
+    Each states weights and opacities mermaid writes as PRESENTATION ATTRIBUTES or as literals in
+    its own stylesheet, so a plain rule appended here beats them with no `!important` anywhere.
+    What is NOT here is as deliberate as what is — the exclusions are recorded on the slides.
+  */
+  /* The radar legend's swatch is a 12x12 presentation attribute sized for mermaid's own ~12px
+     legend. `width`/`height` are SVG2 geometry properties on a rect, so a rule reaches them. */
+  /*
+    ★★ THE GRATICULE IS A STACK OF FILLED DISCS, NOT RINGS, and no theme variable says so. mermaid
+    paints each tick circle with `graticuleColor` as BOTH fill and stroke, so `graticuleOpacity: 1`
+    — which is what a ring at the deck's border colour wants — turns the whole plot into one grey
+    disc with every tick invisible underneath it. Measured: four concentric circles, r 75 to 300,
+    every one of them fill-opacity 1.
+
+    Dropping the fill is the only way to get the scale back. The rings then read as what they are,
+    a measure, against the page — rather than as a coloured ground the data happens to sit on.
+  */
+  `.radarGraticule{fill:none;}`,
+  /*
+    ★★ AND THE WORD HANGS FROM ITS BASELINE, WHICH DEFEATS THE SEATING. mermaid's own stylesheet
+    carries `.radarLegendText{dominant-baseline:hanging}` — so the y a rule or a rewrite sets is the
+    text's TOP, not its baseline, and spaceRadarLegend's 0.35em cap-height nudge pushes it further
+    down instead of centring it. MEASURED: the word's box came out at y 4.27 for 36.54 units against
+    a chip spanning -11.5 to 11.5, i.e. 22.5 units low — the word sitting a row below the chip that
+    names it. Back to the alphabetic baseline, which is what the nudge is written against.
+
+    ★ AND THE CHIP IS A KEY, NOT A SAMPLE OF THE WASH. It inherits the curve's own fill-opacity, so
+    at the 0.16 that makes two overlapping areas readable it renders as an all-but-empty outline at
+    a quarter of the size. A legend states WHICH COLOUR, once, at the size of a word — so it states
+    it solidly, and the stroke it already carries is the same hue.
+  */
+  `.radarLegendText{dominant-baseline:auto;}`,
+  `[class^="radarLegendBox-"]{width:${RADAR_SWATCH_PX}px;height:${RADAR_SWATCH_PX}px;fill-opacity:1;}`,
+  /*
+    ★★ A TREEMAP CELL IS A CARD, so it takes the deck's edge — mermaid draws the leaf at
+    stroke-width 3 and the section at 2, both presentation attributes, and both a shade under the
+    weight every other box in this deck carries. The fill opacities come with them because the two
+    are one reading: at mermaid's 0.3 leaf over 0.6 section the nesting is a wash of one hue, and
+    the deck's own answer to "a group of Cards is a Card" is a quiet surface read by its border.
+
+    ⚠ AND THE CORNER RULE MUST NOT REACH THE CLIP RECTS. treemap nests a plain <rect> inside a
+    <clipPath> per cell; rounding those would crop every label to a rounded window it was never
+    laid out for. The corner rule below names `rect.treemapLeaf` and `rect.treemapSection` rather
+    than the family's rects in general, for that reason alone.
+  */
+  `rect.treemapLeaf{stroke-width:${DIAGRAM_STROKE_PX};fill-opacity:0.18;}`,
+  /*
+    ⚠ THE SECTION KEEPS A LIGHTER EDGE THAN THE LEAF, and it is the value in its corner that decides
+    it. mermaid anchors the section's total at `x = width - 10`, hard against the cell's right edge,
+    so a border at the deck's full 4 units runs UNDER the digits — measured by the audit's painted-
+    pixel pass, which scored three of them at 1.02:1 against the stroke rather than against the
+    fill. Nothing can move the text: the x is computed, not configured. So the border gives way.
+  */
+  `rect.treemapSection{stroke-width:${DIAGRAM_STROKE_PX / 2};stroke-opacity:1;fill-opacity:0.5;}`,
+  `rect.treemapLeaf,rect.treemapSection{rx:${POLYGON_RADIUS}px;ry:${POLYGON_RADIUS}px;}`,
+  /*
+    ★ THE SECTION HEADER'S TYPE IS AN INLINE STYLE at 12px, and `!important` is the only thing that
+    reaches it. Taken, unlike the treemap LEAF label below it, because a section header is not
+    fitted by a shrink loop — it is truncated against a width, so raising it costs an ellipsis at
+    worst rather than a culled label. Short section names keep it from ever truncating, which is
+    why the slide's are one word.
+  */
+  /*
+    ★★ THE SECTION HEADER TAKES THE INDEX RUNG, NOT THE TRANSITION ONE, AND THE BAND DECIDES THAT.
+    Its room is fixed at 35 units — mermaid's 25-unit header plus 10 of inner padding, which is what
+    d3 was handed as `paddingTop`, so growing it means moving every leaf the layout already placed.
+    MEASURED at the transition rung: the cap ink is 21 units, seated at 5 above and 9 below, i.e.
+    the word exactly fills its band and reads as jammed between the cell's top edge and the first
+    leaf. One rung down the ink is 18 and the air is even on both sides.
+
+    ★ A section name is subordinate to the leaf labels it groups — those sit at the body rung, 38 by
+    mermaid's own leaf-count ladder — so being quieter than them is right on its own terms too.
+  */
+  `text.treemapSectionLabel{font-size:${MERMAID_TAG_FONT_PX}px !important;}`,
+  `text.treemapSectionValue{font-size:${MERMAID_TAG_FONT_PX}px !important;font-style:normal;}`,
+  /*
+    ★★ MINDMAP TAPERS ITS EDGES BY DEPTH — 17 - 3n, so 11, 8, 5, 2 and then NEGATIVE, which renders
+    as nothing at all past the fourth rank. The taper is a literal in mermaid's generated stylesheet
+    with no key behind it. The deck does not taper: a line is a line at the weight every other line
+    in the deck carries, and a mindmap that fades out by depth is telling the room its fifth rank
+    matters less than its first, which is not what a hierarchy means.
+  */
+  `.edge,[class^="edge-depth-"]{stroke-width:${DIAGRAM_STROKE_PX};}`,
+  /*
+    ★★ A KANBAN COLUMN IS A CONTAINER, NOT A CATEGORY, and mermaid colours it as though it were.
+    The family reuses mindmap's `.section-N` machinery for its columns, so each one arrives filled
+    with a categorical slot — and past the slots the deck states, with a HUE ROTATION of them:
+    measured on this slide, three columns came out bright blue, violet and magenta, none of which
+    is in any Forest scale.
+
+    Colour is the wrong encoding here whatever the hue. A column is a STAGE — backlog, in progress,
+    shipped — and stages are ordered, not categorical; painting them as three unrelated colours says
+    they are three kinds of thing. The deck's own answer to a group of Cards is a Card: one surface,
+    one border, one corner, which is what a flowchart `subgraph` and a composite state already take.
+
+    ★ SCOPED TO `.cluster` SO MINDMAP IS UNTOUCHED. Both families draw `.section-N`, and on a
+    mindmap the colour IS the reading — a branch and everything under it share a slot, which is what
+    makes the picture legible by branch. Kanban's columns are the ones that are clusters.
+  */
+  `.cluster[class*="section-"] > rect{fill:var(--deck-surface);stroke:var(--deck-border);}`,
+  /*
+    ★ AND THE WORD ON THE LINE IS MUTED, because a transition NAME is subordinate to the states it
+    joins — at full ink it competes with the node labels for the same reading.
+
+    75%, and that number is a floor rather than a taste. The mute is a mix toward the label's own
+    ground, so how far it can go is set by whichever family has the least headroom. MEASURED, ink
+    against its ground at each step:
+
+        ground     100%     80%     75%     74%     72%     70%
+        page      17.19    9.33    7.74    7.50    6.96    6.52
+        warm      10.26    6.03    5.23    5.08    4.85    4.57
+        accent    13.07    7.30    6.26    6.07    5.71    5.37
+        vivid      8.51    5.40    4.76    4.63    4.44    4.20
+        neutral   15.76    8.82    7.42    7.19    6.67    6.27
+
+    ★★ VIVID BINDS, AND IT BINDS AT 74. Below that it breaches the 4.5 body floor — 4.44 at 72 and
+    4.20 at 70 — while every other family still has room. 75 is the last step with a margin rather
+    than a rounding error, so the mute stops there and not at whatever looked right on a cream slide.
+    One number for all five grounds, which is why the mute lives here and the per-ground INK lives in
+    base.css beside the fill.
+  */
+  `.edgeLabel .label text,.edgeLabel .label span{`
+  + `fill:color-mix(in oklab,var(--deck-mermaid-label-ink,var(--deck-fg)) 62%,var(--deck-mermaid-label-bg,var(--deck-bg)));`
+  + `color:color-mix(in oklab,var(--deck-mermaid-label-ink,var(--deck-fg)) 62%,var(--deck-mermaid-label-bg,var(--deck-bg)));}`,
+  /*
+    ★★ `!important`, AND IT IS THE ONLY THING THAT REACHES THIS TEXT. mermaid writes the fragment
+    keyword with an INLINE STYLE — `<text class="labelText" style="font-family: …; font-size: 36px">`,
+    taken from the top-level `fontSize` — and an inline style beats a stylesheet rule at any
+    specificity. Without the flag this rule was inert: MEASURED off the rendered markup, the keyword
+    stayed at the body rung's 36px through three separate reductions of the number below, while
+    `labelBoxWidth` — which comes from config at layout time and IS scaled from it — shrank each
+    time. The visible result was the word overflowing its own tab, and the cause looked like the tab
+    being too small rather than the text never having moved.
+
+    Everything else in this list wins on source order, because mermaid states it in its own
+    stylesheet. This one it states on the element.
+  */
+  `.labelText,.labelText>tspan{font-size:${TAG_FONT_PX}px!important;}`,
+  /*
+    ★★ AND THE KEYWORD SITS LOW IN ITS OWN TAB — BUT `dominant-baseline` CANNOT TAKE IT BACK. mermaid
+    writes `alignment-baseline="middle"` as a PRESENTATION ATTRIBUTE, and in Chrome that beats a
+    `dominant-baseline` declaration at any importance, so the `central` this line used to carry
+    never rendered at all (measured: em box top 306.5 with the attribute, 308.5 without — `central`
+    would have pushed the word two units LOWER still).
+
+    The drop is mermaid's own arithmetic, so cancel it directly: the word was landing half on the
+    tab's own hairline stroke, and the audit scored its ink against that band at 4.39:1 rather than
+    against the fill. Translated back, every keyword clears both hairlines — worst case "critical",
+    3.1 units of daylight at the top — and every glyph pixel sits on the fill at 13.36:1. Same lever
+    `.sequenceNumber` below already uses, for the same class of bug.
+  */
+  `.labelText{alignment-baseline:middle!important;transform:translateY(-${TAG_BASELINE_DROP}px);}`,
+  /*
+    ★★ AUTONUMBER IS THREE HARD-CODED VALUES IN THE MARKUP, and no config key reaches any of them.
+    mermaid writes the index as
+        <text font-family="sans-serif" font-size="12px" class="sequenceNumber">1</text>
+    inside a `<circle r="6">` — 12px and a 6-unit disc, both sized for its own 16px era, beside this
+    deck's 36px type. Its own stylesheet sets only `.sequenceNumber { fill }`, so the size is not
+    something a theme variable can move.
+
+    They are PRESENTATION ATTRIBUTES, which any rule beats — the same lever the ER edge label above
+    needs. The number takes the fragment keyword's rung: it is an index on a line rather than part
+    of the diagram's prose, subordinate in exactly the same way. The disc follows the type at
+    mermaid's own ratio, r = half the font size, so a two-digit index still fits the way it does at
+    12px.
+  */
+  `.sequenceNumber{font-family:${MERMAID_FONT_FAMILY};font-size:${MERMAID_INDEX_FONT_PX}px;`
+  /*
+    ★★ AND THE NUMBER HAS TO BE RE-CENTRED, because mermaid positions it as a BASELINE. The disc is
+    a marker on a zero-length line at y, and the digit is a separate <text> at y + 4 — four units
+    below the centre, which is half a cap height at the 12px it wrote the markup for. Enlarge the
+    font and the glyph hangs: measured on the specimen, the digit sat about five units high in its
+    own disc.
+
+    `dominant-baseline: central` centres the glyph on its own y instead of sitting it on one, and
+    the translate takes back mermaid's baseline offset so that y is the disc's centre rather than
+    four below it. Both are needed: either alone leaves it off by the other's amount.
+  */
+  + `dominant-baseline:central;transform:translateY(-${SEQUENCE_NUMBER_BASELINE_DROP}px);}`,
+  `[id$="-sequencenumber"] circle{r:${Math.round(MERMAID_INDEX_FONT_PX * SEQUENCE_NUMBER_DISC_RATIO)}px;}`,
+  /*
+    ★★ A HOLLOW DIAMOND IS GROUND-FILLED, NOT TRANSPARENT. UML's aggregation end is an OPEN diamond
+    against composition's solid one, and mermaid draws "open" as no fill at all — so the relationship
+    line, which is drawn along the whole gap between the two classes, runs straight through it. At
+    mermaid's own size that reads as a small lozenge on the line; at the size this theme draws it,
+    it reads as a diamond with a line through the middle, which is not the notation.
+
+    The ground rather than a colour, for the same reason the edge label knocks out to one: a diagram
+    inside a named background has to fill to THAT ground, and the variable already carries it.
+
+    Composition is deliberately untouched — its diamond is meant to be solid, and it takes the line
+    colour from mermaid's own `.marker` rule.
+  */
+  `.marker.aggregation{fill:var(--deck-mermaid-label-bg,var(--deck-bg));}`,
+  // Pie labels — mermaid's hard-coded trebuchet stack.
+  `.slice{font-family:${MERMAID_FONT_FAMILY};}`,
+  `.pieTitleText,.legend text{font-family:${MERMAID_FONT_FAMILY};}`,
+  // Every drawn edge, named by family: flowchart nodes and links, sequence actors and messages,
+  // state, class and ER. A blanket `* { vector-effect }` would also catch the arrowhead fills and
+  // the pie slices, which are shapes rather than lines and read correctly as they are.
+  // ⚠ `ellipse` is listed because mermaid's OWN node rule lists it — `.node rect,.node circle,
+  // .node ellipse,.node polygon,.node path`. A shape family missing from this side is not styled
+  // half-way, it is left entirely on mermaid's 1px, which the diagram's own scale then draws at
+  // half a pixel.
+  `.node rect,.node polygon,.node circle,.node ellipse,.node path,.cluster rect,`
+  + `.task-line,rect.task,rect.journey-section,rect.actor,circle[class^="actor-"],.face,.actor-line,.messageLine0,.messageLine1,.flowchart-link,.edgePath .path,`
+  /* ⚠ `.er.entityBox` AND `.er.relationshipLine` WERE BOTH DEAD, and censusing the rendered
+     classes is what found them. In 11.17.2 there is no `entityBox` class at all — an entity is a
+     `g.node.default` whose box rectifyOuterPaths turns into a <rect>, so `.node rect` above
+     already covers it — and the relationship line carries
+     `edge-thickness-normal edge-pattern-solid relationshipLine` with NO `er` beside it, so the
+     compound selector matched nothing and the line kept mermaid's own weight. */
+  + `.transition,.stateGroup rect,.relationshipLine,.relation`
+  + `{stroke-width:${DIAGRAM_STROKE_PX};}`,
+  // A round cap on the line so the end that meets the chevron is the same shape the chevron's own
+  // arms end in. A butt cap leaves a square nub inside the V at this weight.
+  `.flowchart-link,.edgePath .path,.messageLine0,.messageLine1,.relation,.transition`
+  + `{stroke-linecap:round;stroke-linejoin:round;}`,
+  /*
+    ★★ THE LINK'S WEIGHT NEEDS ONE MORE CLASS, and which one matters. Mermaid sets it through
+    `.edge-thickness-normal`, which ties the rule above on specificity, so the winner is whichever
+    the browser sees last — not something to depend on. Naming both classes settles it.
+
+    ⚠ `.edge-thickness-thick` is deliberately NOT matched. That class is what an author asks for with
+    a `==>` arrow, and a rule flattening it would remove the one weight distinction mermaid offers.
+  */
+  `.flowchart-link.edge-thickness-normal,.edgePath .path.edge-thickness-normal`
+  + `{stroke-width:${DIAGRAM_STROKE_PX};}`,
+  /*
+    ⚠ THE GANTT'S LAST TWO SIZES. `gantt.fontSize` moves the task and section text and the layout
+    with it, but the chart title and the axis ticks have no key at all — mermaid draws them at a
+    literal 18px and 10px, which on a 1920px canvas is 10 and 5 rendered pixels. Neither has a box
+    laid out around it, so unlike the task text they can be moved from CSS without the bars
+    disagreeing. The ticks take the 0.8 step a pie legend takes, because an axis is a caption.
+  */
+  `.titleText{font-size:${MERMAID_FONT_PX}px;}`,
+  `.grid .tick text{font-size:${Math.round(MERMAID_FONT_PX * 0.8)}px;}`,
+  /*
+    ★★ A DASH HAS TO CLEAR ITS OWN CAP. mermaid dashes a sequence reply at `stroke-dasharray: 2,2`
+    and re-states it inline as `3,3`; the deck then draws that line at 4px with a ROUND cap. A round
+    cap adds half the stroke width at each end, so a 3-unit dash is DRAWN 7 units long with 3 units
+    of gap after it — the dashes overlap and the line reads solid with a bumpy edge.
+
+    The pattern is therefore derived from the stroke rather than picked: dash 2x, gap 3x. That draws
+    a 12-unit dash with 8 units of daylight, which reads as dashed at any of the sizes this deck
+    renders a diagram at.
+
+    ⚠ `!important` IS LOAD-BEARING HERE, and it is the only one in this list. mermaid puts the
+    sequence value in an INLINE style, which a stylesheet rule cannot outrank on specificity or on
+    source order. Every other rule in this file wins by being appended after mermaid's own.
+  */
+  /* ★★ `.edge-pattern-dashed` BARE, NOT PER-FAMILY. It was named on the flowchart link and the
+     edgePath only, so a dashed CLASS relation (`..>`, `<|..`) and a dashed ER relationship (`..`)
+     took the 4px stroke and the round cap from the rules above and mermaid's own 3-unit dash —
+     which is the exact overlap this rule exists to prevent: half the stroke is added at each
+     end, so a 3-unit dash draws 7 long with 3 of gap and the line reads solid. Every family
+     spells the class the same way, so one bare selector is the honest scope. `.relation` is
+     named too: the class diagram sets its dash inline rather than through the pattern class. */
+  `.messageLine1,.loopLine,.task-line,.edge-pattern-dashed,.relation.edge-pattern-dashed`
+  + `{stroke-dasharray:${DIAGRAM_STROKE_PX * 2}px ${DIAGRAM_STROKE_PX * 3}px !important;}`,
+  /*
+    A dot is the same mechanism with no dash at all — the round cap IS the dot, so the length is a
+    hair above zero and the gap carries the rhythm.
+
+    ⚠ `-.->` EMITS `edge-pattern-DOTTED`, measured — not `dashed`, which is the name the arrow's
+    look suggests. So this rule is the one a flowchart actually exercises (the specimen draws it),
+    and `edge-pattern-dashed` above is matched but drawn by nothing here; the sequence reply is what
+    evidences that half.
+  */
+  `.flowchart-link.edge-pattern-dotted,.edgePath .path.edge-pattern-dotted`
+  + `{stroke-dasharray:0.01px ${DIAGRAM_STROKE_PX * 2.5}px !important;stroke-linecap:round;}`,
+  /*
+    ★★ A SEQUENCE MESSAGE LABEL IS CENTRED ON ITS EM BOX, AND SITS UNDER THE WRONG LINE BECAUSE OF
+    IT. Measured on the specimen: 24.1 units of air above the label and 40.8 below, in a 110-unit
+    band — so the label is nearly twice as far from the line it NAMES as from the previous message's.
+
+    The em box itself is close to centred; what is not is the INK. These labels carry no descenders,
+    so the descender space the em box reserves is empty and reads as a gap the type does not fill.
+    Shifting by a fraction of an em corrects the ink rather than the box, which is why it is stated
+    in `em` and holds at any size — `dy` would have to be recomputed per font size.
+  */
+  /*
+    An edge label knocks its line out rather than veiling it. mermaid gives the label's backing rect
+    `opacity: 0.5` — element opacity, not fill-opacity — so the edge runs through the word at half
+    strength and the label reads as printed on tracing paper. At this deck's weight, where that edge
+    is 4px rather than 1, the ghost line is thicker than the letterforms it crosses.
+
+    Only the opacity moves: the FILL is already right. mermaid takes it from `edgeLabelBackground`,
+    which this theme points at the page's own ground per register, so the rect is already the exact
+    colour of the paper behind it and going opaque simply finishes the knockout.
+  */
+  `.edgeLabel rect,.edgeLabel .label rect,.icon-shape .label rect,.image-shape .label rect`
+  + `{opacity:1;}`,
+  `.messageText{transform:translateY(${MESSAGE_INK_DROP}em);}`,
+  // Both placements, because both are laid out by the formula above — an outside label is moved
+  // sideways, not vertically, so it carries the same drop.
+  `.taskText,.taskTextOutsideLeft,.taskTextOutsideRight{transform:translateY(-${GANTT_LABEL_RISE}px);}`,
+  // A journey's actor dot is drawn at r=7 for 14px type. Beside the deck's rung it reads as a
+  // speck, so it takes a third of the label's size — `r` is a CSS geometry property, so no surgery
+  // is needed. Scoped to `circle` because a sequence diagram's `actor-line` shares the prefix.
+  `circle[class^="actor-"]{r:${Math.round(MERMAID_FONT_PX / 3)}px;}`,
+  // Rectangular nodes take the deck's corner.
+  `.node rect,.cluster rect,rect.actor,.stateGroup rect,`
+  + `rect.task,rect.journey-section`
+  + `{rx:${DIAGRAM_RADIUS}px;ry:${DIAGRAM_RADIUS}px;}`,
+  /*
+    ★★ THE STATE DIAGRAM NEEDS ITS OWN NAMES, and without them it is the one family in this deck
+    that draws square. mermaid states its corner as `.statediagram-state rect.basic` — (1,2,1)
+    against the (1,1,1) of `.node rect` above, so the generic rule loses and a state box keeps
+    mermaid's 5. Repeating mermaid's own selectors TIES on specificity, and these rules are appended
+    to the stylesheet it generated, so source order settles it.
+  */
+  `.statediagram-state rect.basic,.statediagram-state .title-state,`
+  + `.statediagram-cluster rect.outer,.statediagram-note rect`
+  + `{rx:${DIAGRAM_RADIUS}px;ry:${DIAGRAM_RADIUS}px;}`,
+  // The rounded rhombus is a <path> by the time it renders (see roundPolygons), and a path takes its
+  // corners from the geometry rather than from CSS. The join is still stated so the stroke follows
+  // the curve cleanly where two arcs meet a short edge.
+  `.node polygon,.node path{stroke-linejoin:round;}`,
+];
+
+/*
+  ── THE ARROWHEAD ──────────────────────────────────────────────────────────────────────────────
+
+  Mermaid sizes its heads with `markerWidth`/`markerHeight` at `markerUnits="userSpaceOnUse"`, which
+  means two things: the head does NOT grow with stroke width the way a default marker would, and it
+  DOES shrink with the diagram, because user space is what fitToColumn scales. Measured on the
+  specimen's flowchart, an 8-unit head on a diagram drawn at 0.544 renders about 10 canvas px — a
+  tenth of the label beside it, against a line that is now three.
+
+  The box is scaled and the viewBox is not: the head's geometry is in viewBox units and is fitted
+  into the marker box, so multiplying the box enlarges the drawing.
+
+  ★★ AND `refX` HAS TO MOVE WITH IT, WHICH IS THE WHOLE DIFFICULTY. `refX` names the point on the
+  marker that sits on the line's endpoint, and mermaid puts it mid-head — so the tip already extends
+  PAST the endpoint by design, and the line is drawn short to match. Scaling the box multiplies that
+  overhang too, and the tip lands inside the node's border rather than against it.
+
+  So the anchor is moved to hold the tip where it was and let the head grow BACKWARD along the line.
+  Which end is the tip comes from the marker's own name — mermaid names them `…End` and `…Start` —
+  and the arithmetic is the same both ways: keep the tip's offset from the anchor constant in
+  rendered units while the box grows by `k`.
+
+      End    (tip at the viewBox's right edge)   refX' = vbW - (vbW - refX) / k
+      Start  (tip at the left edge)              refX' = refX / k
+
+  A head already anchored at its own tip — mermaid's `pointEnd-margin`, refX 11.5 of 11.5 — comes out
+  unchanged, which is the arithmetic agreeing with the intent rather than a special case.
+*/
+export const ARROWHEAD_SCALE = 1.9;
+
+/*
+  ★ ONLY THE ARROW MARKERS. A mermaid diagram's <defs> holds every marker the family can use, and
+  most are not arrowheads: `sequencenumber` is a numbered badge, `circleEnd` and `crossEnd` are
+  terminators with their own meaning. Scaling all of them turned the sequence diagram's number badge
+  from 60 units to 114. The name is the filter, because mermaid names them plainly.
+*/
+/* ⚠ NO WORD BOUNDARIES AND NO /i. `\bpoint\b` does not match `pointEnd` — 't' and 'E' are both word
+   characters, so there is no boundary between them — and case matters: `crosshead` is the sequence
+   diagram's X terminator and must not be opened into a chevron, which a case-insensitive `head`
+   would catch. Each name is matched as mermaid spells it. */
+/*
+  ★★ SHAPE AND SIZE ARE TWO DIFFERENT QUESTIONS, AND THE DIAMOND ANSWERS THEM DIFFERENTLY.
+
+  `aggregationEnd` is a hollow diamond and `compositionEnd` a filled one. Opening either into a
+  chevron would say "arrow" where UML says "part of", so they are absent from the SHAPE list — but
+  they were absent from the SIZE list too, and nothing justified that. Every arrow in the deck is
+  grown to the deck's type while the diamond kept mermaid's stock 17-unit path, so `Bay o-- Vehicle`
+  drew a marker a third the weight of the arrowhead on the line beside it.
+
+  ★★ AND THE DIAMOND CANNOT BORROW THE ARROWS' SIZING. viewBoxArrowheads reads markerWidth as the
+  size the content already had, which holds for an arrow — `pointEnd` declares 8 to 20 against a
+  10-unit path. mermaid declares `aggregationStart` at markerWidth=190, markerHeight=240 for the
+  SAME 17-unit path it gives `aggregationEnd` at 20x28. Handing that to the arrow path would map 17
+  units into 190 and draw a diamond eleven times too big. sizeDiamondMarkers reads the extent off
+  the path's own `d` instead, which is the one measurement mermaid is consistent about.
+*/
+/*
+  ⚠ THE ER CROW'S FEET ARE NOT IN HERE, AND MUST NOT BE — `markerUnits` is why. MEASURED off the
+  rendered ER diagram:
+
+      <marker class="marker onlyOne er" refX="0" refY="9" markerWidth="18" markerHeight="18"
+              orient="auto"><path d="M9,0 L9,18 M15,0 L15,18"/></marker>
+
+  No `markerUnits` attribute, so it takes the SVG default of `strokeWidth` — the marker is scaled by
+  the line it ends, and this deck's line is 4 units, so it already tracks the deck's weight with no
+  help. The class diagram's diamond declares `markerUnits="userSpaceOnUse"`, which opts out of that
+  scaling, and is the only reason it needed sizing by hand.
+
+  Adding the crow's feet to this list multiplied an already-scaled marker by ARROWHEAD_SCALE again:
+  they rendered several times the height of the entity they pointed at. A marker belongs here only
+  if it declares `userSpaceOnUse`; check before adding one.
+*/
+const DIAMOND_MARKER = /(aggregationStart|aggregationEnd|compositionStart|compositionEnd)/;
+/*
+  ★★ EVERY FAMILY NAMES ITS ARROWHEAD SOMETHING ELSE, and a family missing from this list keeps
+  mermaid's own — a filled triangle at its 16px-era size, next to the deck's chevrons. CENSUSED off
+  the rendered SVG of every diagram in the specimen rather than guessed:
+
+    flowchart  pointEnd / pointStart
+    sequence   arrowhead / filled-head
+    state      barbEnd                    ← was missing, and it is the same plain arrow
+    class      extensionStart / extensionEnd, dependencyStart / dependencyEnd
+
+  The rest of the census is shapes, not arrows, and is listed under NOTATION_MARKER below.
+*/
+const ARROW_MARKER = /(pointEnd|pointStart|arrowhead|ArrowHead|filled-head|barbEnd|extensionStart|extensionEnd|dependencyStart|dependencyEnd)/;
+
+/**
+ * Size a class diagram's diamond ends to the deck's type, keeping their shape.
+ *
+ * refX/refY are left where mermaid put them: with a viewBox they are read in the path's own
+ * coordinates, which is exactly what they already were.
+ */
+/*
+  ── THE SHAPE MARKERS THAT SCALE WITH THE LINE, AND THEREFORE WITH THE DECK'S 4px ──────────────
+
+  A <marker> with no `markerUnits` takes the SVG default, `strokeWidth`: everything it draws is
+  multiplied by the width of the line it sits on. mermaid draws the ER cardinalities and the class
+  lollipop for its own 1px line, so at this deck's 4px they render FOUR TIMES the size they were
+  drawn at — a crow's foot taller than the entity it points at.
+
+  MEASURED: `<marker class="marker onlyOne er" markerWidth="18" markerHeight="18">` with no
+  markerUnits, on a 4-unit line, is 72 units of marker.
+
+  The cure is to take them out of that space — `userSpaceOnUse` plus a viewBox, so the box is the
+  size and the content maps into it — and to draw them at the same scale the aggregation diamond
+  ends up: its 17-unit path at ARROWHEAD_SCALE is about 32, so an 18-unit crow's foot lands at 34
+  and the two families' line ends finally match each other.
+
+  ⚠ THE viewBox IS NOT OPTIONAL. Without one, markerWidth sets the CLIP and not the scale, so the
+  marker would keep its 18 units inside a 34-unit window — the same trap viewBoxArrowheads exists
+  for on the arrowheads.
+*/
+const STROKE_SCALED_MARKER = /(onlyOne|zeroOrOne|oneOrMore|zeroOrMore|lollipop|circleEnd|circleStart|crossEnd|crossStart)/;
+
+export function unscaleStrokeMarkers(svg: string): string {
+  return svg.replace(/<marker\b[^>]*>/g, (tag) => {
+    if (!STROKE_SCALED_MARKER.test(tag) || /markerUnits="userSpaceOnUse"/.test(tag) || /viewBox=/.test(tag)) return tag;
+    const w = Number(/\bmarkerWidth="([\d.]+)"/.exec(tag)?.[1]);
+    const h = Number(/\bmarkerHeight="([\d.]+)"/.exec(tag)?.[1]);
+    if (!Number.isFinite(w) || !Number.isFinite(h) || w <= 0 || h <= 0) return tag;
+    return tag
+      .replace(/<marker\b/, `<marker viewBox="0 0 ${w} ${h}"`)
+      .replace(/\bmarkerUnits="[^"]*"/, '')
+      .replace(/<marker\b/, '<marker markerUnits="userSpaceOnUse"')
+      .replace(/\bmarkerWidth="[\d.]+"/, `markerWidth="${(w * ARROWHEAD_SCALE).toFixed(2)}"`)
+      .replace(/\bmarkerHeight="[\d.]+"/, `markerHeight="${(h * ARROWHEAD_SCALE).toFixed(2)}"`);
+  });
+}
+
+/*
+  ── THE TIMELINE'S BANDS CARRY THEIR CORNER IN THE PATH ────────────────────────────────────────
+
+  Every other node in this deck takes its 28px corner from CSS, because it is a `<rect>` and `rx`
+  reaches it. A timeline band is not: mermaid emits `<path class="node-bkg">` whose `d` already
+  contains the curve — `M0 H v-(H-5) q0,-5,5,-5 h W q5,0,5,5 v H H0 Z` — a 5-unit radius on the TOP
+  two corners only, square along the bottom. No rule can move it, so a timeline sat among rounded
+  cards with square ones.
+
+  Rewritten as a full rounded rect over the same box. Guarded on the exact template mermaid emits:
+  anything else keeps whatever it drew, which is the same rule roundPolygons follows for the shapes
+  whose outline is their meaning.
+*/
+export function roundTimelineNodes(svg: string, radius: number): string {
+  return svg.replace(
+    /(<path\b[^>]*class="[^"]*\bnode-bkg\b[^"]*"[^>]*\bd=")M0 ([\d.]+) v-[\d.]+ q0,-5,5,-5 h([\d.]+) q5,0,5,5 v[\d.]+ H0 Z(")/g,
+    (whole, pre: string, hRaw: string, wRaw: string, post: string) => {
+      const h = Number(hRaw);
+      const w = Number(wRaw) + 10;
+      if (!Number.isFinite(h) || !Number.isFinite(w) || h <= 0 || w <= 0) return whole;
+      const r = Math.min(radius, w / 2, h / 2);
+      const f = (n: number) => Number(n.toFixed(2));
+      const d = `M ${f(r)},0 h ${f(w - r * 2)} a ${f(r)},${f(r)} 0 0 1 ${f(r)},${f(r)}`
+        + ` v ${f(h - r * 2)} a ${f(r)},${f(r)} 0 0 1 ${f(-r)},${f(r)}`
+        + ` h ${f(-(w - r * 2))} a ${f(r)},${f(r)} 0 0 1 ${f(-r)},${f(-r)}`
+        + ` v ${f(-(h - r * 2))} a ${f(r)},${f(r)} 0 0 1 ${f(r)},${f(-r)} Z`;
+      return `${pre}${d}${post}`;
+    },
+  );
+}
+
+export function sizeDiamondMarkers(svg: string): string {
+  return svg.replace(/<marker\b[^>]*>[\s\S]*?<\/marker>/g, (whole) => {
+    const tag = /^<marker\b[^>]*>/.exec(whole)?.[0] ?? '';
+    if (!DIAMOND_MARKER.test(tag) || /viewBox=/.test(tag)) return whole;
+    const d = /<path\b[^>]*\bd="([^"]+)"/.exec(whole)?.[1];
+    const nums = d?.match(/-?\d*\.?\d+/g)?.map(Number);
+    if (!nums || nums.length < 4 || nums.length % 2 || nums.some(Number.isNaN)) return whole;
+    const xs = nums.filter((_, i) => i % 2 === 0), ys = nums.filter((_, i) => i % 2 === 1);
+    const minX = Math.min(...xs), minY = Math.min(...ys);
+    /* ★ THE BOX IS THE EXTENT PLUS THE PATH'S OWN INSET, NOT THE EXTENT. A viewBox tight to the
+       path puts all four vertices exactly on the edge, and the stroke straddles it — measured on
+       an export, the diamond came out as an open chevron with its right and bottom points shaved
+       off. mermaid already draws the shape inset by minX/minY inside its box; mirroring that inset
+       on the far side is what gives the stroke somewhere to sit. */
+    const w = Math.max(...xs) + minX, h = Math.max(...ys) + minY;
+    if (!(w > 0 && h > 0)) return whole;
+    /* ★★ AND THE ANCHOR HAS TO MOVE WITH IT, or the shape grows the wrong way. mermaid anchors the
+       Start diamond at its FAR vertex (refX=18 on an 18-wide path), so the body hangs backward off
+       the line's first point — which is the owning class's own edge. At mermaid's size that fits in
+       the gap; at 1.9x it does not, and the export showed the left half of the diamond painted over
+       by the node, leaving a shape that reads as an arrowhead. Anchoring the NEAR vertex instead
+       grows it along the line, into the gap that is already empty. */
+    const anchor = /\bid="[^"]*Start[^"]*"/.test(tag) ? minX : Math.max(...xs);
+    const sized = tag
+      .replace(/<marker\b/, `<marker viewBox="0 0 ${w} ${h}"`)
+      .replace(/\brefX="[\d.]+"/, `refX="${anchor}"`)
+      .replace(/\bmarkerWidth="[\d.]+"/, `markerWidth="${(w * ARROWHEAD_SCALE).toFixed(2)}"`)
+      .replace(/\bmarkerHeight="[\d.]+"/, `markerHeight="${(h * ARROWHEAD_SCALE).toFixed(2)}"`);
+    return sized + whole.slice(tag.length);
+  });
+}
+
+/*
+  ── THE HEAD IS A CHEVRON ──────────────────────────────────────────────────────────────────────
+
+  Mermaid draws a filled triangle: `M 0 0 L 10 5 L 0 10 z`, closed and filled. The same three points
+  without the close, stroked rather than filled, are a chevron — an open V that reads as a direction
+  rather than a blob, and that carries the line's weight into its tip instead of ending in a mass.
+
+  ★★ AND THE HEAD IS STROKED IN UNITS LIKE THE LINE IS, which is the only way the two can agree.
+  A marker's contents live in viewBox units and the link's stroke now does too, so both are scaled
+  by the diagram together and the head is stroked at exactly the link's width, by construction
+  rather than by tuning. Measured when they disagreed: a 2.2-unit chevron rendered 1px against a
+  3px line, and the ratio moved with every diagram's scale.
+*/
+
+/*
+  ── THE CHEVRON'S ANGLE ────────────────────────────────────────────────────────────────────────
+
+  Mermaid's head is a long, narrow triangle — `M 0 0 L 10 5 L 0 10`, arms 10 units back for 5 across,
+  which is a 53-degree V. Opened into a chevron that reads as a dart rather than an arrow.
+
+  Widening it is done in the shape's own terms rather than by substituting a hand-written path, so it
+  survives mermaid drawing a different triangle: the tip is the vertex furthest from the midpoint of
+  the other two, and each arm is shortened along the AXIS (tip to base-midpoint) while its
+  perpendicular spread is left alone. Less axial length for the same spread is a wider angle, and the
+  head keeps its width, its anchor and its tip exactly where they were — so none of the arithmetic
+  that lands the tip on the node's border has to change.
+*/
+const CHEVRON_AXIAL = 0.62;
+
+/*
+  ★ A TRIANGLE IS NOT ALWAYS SPELLED AS SIX NUMBERS. The flowchart writes its head the long way,
+  `M 0 0 L 10 5 L 0 10 z`, but the class diagram's inheritance end writes `M 1,7 L18,13 V 1 Z` —
+  the third point's x is implied by `V`, so a naive number count sees five and gives up. Expanding
+  the shorthand first is what lets one chevron routine serve both.
+*/
+function trianglePoints(d: string): [number, number][] | null {
+  const tokens = d.match(/[MLHVmlhv]|-?[\d.]+/g);
+  if (!tokens) return null;
+  const pts: [number, number][] = [];
+  let cmd = '';
+  let i = 0;
+  while (i < tokens.length) {
+    if (/[MLHVmlhv]/.test(tokens[i])) { cmd = tokens[i]; i += 1; continue; }
+    const last = pts[pts.length - 1] ?? [0, 0];
+    if (cmd === 'M' || cmd === 'L') {
+      pts.push([Number(tokens[i]), Number(tokens[i + 1])]); i += 2;
+    } else if (cmd === 'm' || cmd === 'l') {
+      pts.push([last[0] + Number(tokens[i]), last[1] + Number(tokens[i + 1])]); i += 2;
+    } else if (cmd === 'H') { pts.push([Number(tokens[i]), last[1]]); i += 1; }
+    else if (cmd === 'h') { pts.push([last[0] + Number(tokens[i]), last[1]]); i += 1; }
+    else if (cmd === 'V') { pts.push([last[0], Number(tokens[i])]); i += 1; }
+    else if (cmd === 'v') { pts.push([last[0], last[1] + Number(tokens[i])]); i += 1; }
+    else return null;
+  }
+  if (pts.length === 3) return pts;
+  /*
+    ★★ AND THE STATE DIAGRAM'S HEAD IS A TRIANGLE WITH A NOTCH IN IT. `barbEnd` is
+    `M 19,7 L9,13 L14,7 L9,1 Z` — four points, where (14,7) sits INSIDE the other three and cuts the
+    concave barb out of the base. Rejecting it for having four points left the state diagram with
+    mermaid's own filled head beside the flowchart's chevrons, and adding it to the size transforms
+    alone just drew that head 1.9x bigger. Dropping the interior vertex leaves the same triangle
+    every other family spells directly, and one chevron routine serves them all.
+  */
+  if (pts.length === 4) {
+    const inside = pts.findIndex((p, i) => {
+      const [a, b, c] = pts.filter((_, j) => j !== i);
+      const sign = (u: number[], v: number[], w: number[]) => (u[0] - w[0]) * (v[1] - w[1]) - (v[0] - w[0]) * (u[1] - w[1]);
+      const d1 = sign(p, a, b), d2 = sign(p, b, c), d3 = sign(p, c, a);
+      return !((d1 < 0 || d2 < 0 || d3 < 0) && (d1 > 0 || d2 > 0 || d3 > 0));
+    });
+    if (inside >= 0) return pts.filter((_, i) => i !== inside) as [number, number][];
+  }
+  return null;
+}
+
+export function widenChevron(d: string): string {
+  const pts = trianglePoints(d);
+  if (!pts) return d;
+  /*
+    ★★ THE TIP IS THE APEX OF THE ISOSCELES, NOT THE VERTEX FURTHEST FROM THE OTHER TWO.
+
+    An arrowhead is symmetric about the line it sits on, so its tip is the one vertex whose two
+    edges are equal. That was originally written as "furthest from the midpoint of the other two",
+    which is the same vertex ONLY while the triangle is longer than it is wide — and mermaid does
+    not guarantee that. MEASURED on `stateDiagram-barbEnd`, whose triangle is 10 long and 12 across:
+
+      tip   (19,7) -> midpoint of the base (9,7)   distance 10
+      base  (9,13) -> midpoint of the others       distance 10.3   ← wins, wrongly
+
+    So the chevron was built around a base corner and the state diagram drew backward ticks that sat
+    beside the line instead of on it. By edge symmetry the same barb gives 11.66 / 11.66 at the tip
+    against 11.66 / 12 at either base corner, and the flowchart's own head still resolves the same
+    way it always did.
+  */
+  let tipIndex = 0, best = Infinity;
+  for (let i = 0; i < 3; i++) {
+    const [a, b] = [pts[(i + 1) % 3], pts[(i + 2) % 3]];
+    const skew = Math.abs(
+      Math.hypot(pts[i][0] - a[0], pts[i][1] - a[1]) - Math.hypot(pts[i][0] - b[0], pts[i][1] - b[1]),
+    );
+    if (skew < best) { best = skew; tipIndex = i; }
+  }
+  const tip = pts[tipIndex];
+  const arms = [pts[(tipIndex + 1) % 3], pts[(tipIndex + 2) % 3]];
+  const mid = [(arms[0][0] + arms[1][0]) / 2, (arms[0][1] + arms[1][1]) / 2];
+  const axisLen = Math.hypot(mid[0] - tip[0], mid[1] - tip[1]) || 1;
+  const axis = [(mid[0] - tip[0]) / axisLen, (mid[1] - tip[1]) / axisLen];
+  const moved = arms.map(([x, y]) => {
+    const v = [x - tip[0], y - tip[1]];
+    const along = v[0] * axis[0] + v[1] * axis[1];
+    const par = [axis[0] * along * CHEVRON_AXIAL, axis[1] * along * CHEVRON_AXIAL];
+    const perp = [v[0] - axis[0] * along, v[1] - axis[1] * along];
+    return [tip[0] + par[0] + perp[0], tip[1] + par[1] + perp[1]];
+  });
+  const f = (n: number) => n.toFixed(2);
+  // Drawn arm-tip-arm so the join at the point is a single stroke join rather than two ends meeting.
+  return `M ${f(moved[0][0])} ${f(moved[0][1])} L ${f(tip[0])} ${f(tip[1])} L ${f(moved[1][0])} ${f(moved[1][1])}`;
+}
+
+export function chevronArrowheads(svg: string, strokePx = DIAGRAM_STROKE_PX): string {
+  return svg.replace(/<marker\b([^>]*)>([\s\S]*?)<\/marker>/g, (whole, attrs, body) => {
+    if (!ARROW_MARKER.test(attrs)) return whole;
+    // Only a closed triangle is convertible; anything else keeps whatever mermaid drew.
+    const opened = body.replace(/\sd="([^"]*?)\s*[zZ]"/g, (_m: string, d: string) => ` d="${widenChevron(d.trim())}"`);
+    if (opened === body) return whole;
+    /*
+      ⚠ `overflow="visible"`, OR THE POINT IS CLIPPED FLAT. A <marker> clips to its own viewport by
+      default, and the tip sits ON the viewBox edge — mermaid's `M 0 0 L 10 5 L 0 10` in a 0..10 box.
+      A filled triangle is entirely inside that box, but a STROKED chevron is not: the stroke extends
+      half its width past the geometry, and at a non-scaling 4px that is far outside a box only 10
+      units wide. The join at the tip is cut off square, which reads as a chopped arrow.
+    */
+    const opened2 = attrs.includes('overflow=') ? attrs : `${attrs} overflow="visible"`;
+    /*
+      ★★ `fill` GOES IN THE STYLE, NOT IN AN ATTRIBUTE, AND THAT IS THE WHOLE BUG.
+
+      A presentation attribute is the LOWEST-priority way to set an SVG property — any stylesheet
+      rule beats it. mermaid ships `.marker { fill: <lineColor>; stroke: <lineColor> }`, so
+      `fill="none"` on the path was overridden and the chevron was filled back in: the arms and
+      their round joins closed over the gap and the head read as a solid triangle again. Measured on
+      the dark sequence slide at 260dpi — the V is there under the fill, which is why the geometry
+      looked right in every unit test of widenChevron().
+
+      An inline style beats a plain rule, which is what this needs. Nothing here uses `!important`;
+      if mermaid ever sets fill with one, the value it forces is `none` anyway.
+    */
+    /*
+      ★★ AND THE HEAD'S WEIGHT IS DIVIDED BY THE MARKER'S OWN MAGNIFICATION. growArrowheads sets
+      markerWidth to ARROWHEAD_SCALE times the viewBox, so everything the marker draws — the stroke
+      included — is drawn that much larger. Under `non-scaling-stroke` that did not matter, because
+      the width was pinned to canvas pixels whatever the marker did. In units it matters exactly:
+      the head came out 1.9x the weight of the line it ends. Dividing here lands it back on the
+      line's own width once the marker has scaled it.
+    */
+    const stroked = opened.replace(/<path\b/g,
+      '<path style="fill:none;stroke-width:'
+      + `${Number((strokePx / ARROWHEAD_SCALE).toFixed(3))}" stroke-linecap="round" stroke-linejoin="round"`);
+    return `<marker${opened2}>${stroked}</marker>`;
+  });
+}
+
+/*
+  ── EVERY ARROW MARKER GETS A viewBox, WHICH IS WHAT MAKES THEM ONE ARROWHEAD ──────────────────
+
+  A <marker> WITHOUT a viewBox does not scale its content: markerWidth/Height set the clip and
+  nothing else, so growing the box grows the window and leaves the path the size it was. WITH one,
+  the content is mapped into the box and grows with it.
+
+  Mermaid is inconsistent about this, and that inconsistency is the whole defect. MEASURED in a
+  rendered deck:
+
+    flowchart  pointEnd      viewBox="0 0 10 10"  markerWidth=8   -> 10 units drawn into 8px
+    sequence   arrowhead     (none)               markerWidth=12  -> 10 units drawn at 10px
+    class      extensionEnd  (none)               markerWidth=20  -> 10 units drawn at 10px
+
+  All three then take the same non-scaling 4px stroke. At the flowchart's scale that is a clean V;
+  at 10px, with CHEVRON_AXIAL shortening the arms first, the two round caps meet at the point and
+  the head reads as a blob rather than an arrow. Giving the bare ones a viewBox equal to the size
+  they already had puts every family on the flowchart's footing before anything is grown, so one
+  arrowhead is drawn deck-wide.
+*/
+export function viewBoxArrowheads(svg: string): string {
+  return svg.replace(/<marker\b[^>]*>/g, (tag) => {
+    if (!ARROW_MARKER.test(tag) || /viewBox=/.test(tag)) return tag;
+    const w = Number(/\bmarkerWidth="([\d.]+)"/.exec(tag)?.[1]);
+    const h = Number(/\bmarkerHeight="([\d.]+)"/.exec(tag)?.[1]);
+    if (!Number.isFinite(w) || !Number.isFinite(h) || w <= 0 || h <= 0) return tag;
+    return tag.replace(/<marker\b/, `<marker viewBox="0 0 ${w} ${h}"`);
+  });
+}
+
+export function growArrowheads(svg: string): string {
+  return svg.replace(/<marker\b[^>]*>/g, (tag) => {
+    if (!ARROW_MARKER.test(tag)) return tag;
+    const vb = /viewBox="([^"]+)"/.exec(tag)?.[1]?.trim().split(/[\s,]+/).map(Number);
+    const vbW = vb?.length === 4 ? vb[2] : Number.NaN;
+    const grown = tag.replace(/\b(markerWidth|markerHeight)="([\d.]+)"/g,
+      (_m, attr, value) => `${attr}="${(Number(value) * ARROWHEAD_SCALE).toFixed(2)}"`);
+    // Without a viewBox there is no coordinate space to move the anchor in, and leaving it put is
+    // the honest fallback: a bigger head in the same place beats one placed by guesswork.
+    if (!Number.isFinite(vbW) || vbW <= 0) return grown;
+    const pointsBackward = /\bid="[^"]*Start[^"]*"/.test(tag);
+    return grown.replace(/\brefX="([\d.]+)"/, (_m, value) => {
+      const refX = Number(value);
+      const moved = pointsBackward ? refX / ARROWHEAD_SCALE : vbW - (vbW - refX) / ARROWHEAD_SCALE;
+      return `refX="${moved.toFixed(3)}"`;
+    });
+  });
+}
+
+/*
+  ── ROUNDING A POLYGON ─────────────────────────────────────────────────────────────────────────
+
+  SVG gives `rx` to <rect> and to nothing else, so mermaid's decision node — a rhombus, drawn as a
+  <polygon> — has no corner radius available to it. `stroke-linejoin: round` rounds the OUTLINE's
+  joins, and the radius that buys is half the stroke width: under 2px here, which is not a rounded
+  shape, it is a slightly soft point.
+
+  So the points are rewritten as a path. At each vertex the two edges are trimmed by `r` and joined
+  with a quadratic whose control point is the original corner — the standard construction, and the
+  one whose curvature matches a rect's `rx` closely enough that a diamond and a box on the same slide
+  read as the same family.
+
+  ★ `r` IS CLAMPED PER CORNER to half the shorter adjoining edge. A rhombus node sized to a short
+  label has edges shorter than the radius, and an untrimmed corner would overshoot into the next one
+  and turn the shape inside out.
+
+  Every <polygon> mermaid emits is a node shape — rhombus, hexagon, parallelogram, trapezoid — so
+  this applies to all of them rather than singling out the diamond. Pie slices and arrowheads are
+  <path> already and are not touched.
+*/
+/*
+  ── THE EDGE LABEL ────────────────────────────────────────────────────────────────────────────
+
+  ★★ AN EDGE LABEL IS CENTRED FROM A HEIGHT MEASURED AT THE WRONG FONT SIZE, and the deck is what
+  makes it visible. mermaid nests the label three deep:
+
+      g.edgeLabel   translate(x, y)      the path's own midpoint — correct
+      g.label       translate(0, -h/2)   mermaid's centring
+      rect.background + text             the label as drawn
+
+  `h` there is the height mermaid RECORDED for the label, and it records it against its own
+  hard-coded `.edgeLabel .label { font-size: 14px }` — the exact rule ROOM_SCALE_RULES overrides,
+  after the layout has run. So the translate is half a 14px line box while the glyphs and their
+  background are a 36px one, and the label hangs below the line it belongs to.
+
+  MEASURED on the specimen's ER diagram: `g.label` translate(0, -8.75) against a background rect of
+  y -2, height 49 — 13.75 user units, 7.48 canvas px, on a line the label is supposed to bisect.
+
+  The repair takes the height from the rect mermaid ACTUALLY EMITTED rather than from a font size
+  this file would then have to keep in step: `createFormattedText` sizes that rect from the text's
+  own getBBox plus 2 units of padding, so it is the drawn box by construction, at any size.
+
+  ★ BOTH AXES, and x is deliberately included even though it is usually a no-op. A centred label's
+  bbox is already symmetric about 0, so `-(x + w/2)` returns the translate unchanged — and where it
+  is NOT symmetric (a start/end terminal label, which mermaid anchors differently) the same
+  arithmetic centres it for the same reason. A rule that is inert exactly where mermaid is right is
+  cheaper to trust than a second rule that decides when to fire.
+*/
+/*
+  ── THE PIE LEGEND ────────────────────────────────────────────────────────────────────────────
+
+  ★★ THE SECOND INSTANCE OF THE SAME DEFECT AS THE EDGE LABEL, and worth naming as one rather than
+  as two fixes. mermaid stacks legend rows on a pitch it hard-codes for its OWN text size — the rows
+  come out at `translate(x, -55 | -33 | -11 | 11 | 33)`, a 22-unit step. `pieLegendTextSize` is the
+  deck's body-sm rung times 0.8, i.e. 29, so five 29-unit labels are stacked 22 units apart and every
+  row overlaps the one below it.
+
+  The pitch is READ from the rows mermaid emitted rather than assumed to be 22: two consecutive rows
+  give it, whatever mermaid changes it to.
+
+  ★ THE BLOCK'S CENTRE IS HELD, which is why the deviations are scaled and not the coordinates.
+  mermaid centres this stack on the pie, and multiplying each `y` outright would drag the whole
+  legend down by however much the spacing opened. Scaling each row's distance FROM THE MEAN opens
+  the gaps symmetrically and leaves the block where it was placed.
+
+  A legend of one row has no pitch to read and no overlap to fix, so it is left alone.
+*/
+/*
+  ── THE JOURNEY'S SATISFACTION AXIS ───────────────────────────────────────────────────────────
+
+  ★★ THE FACE'S POSITION IS ARITHMETIC MERMAID HARD-CODES, and it is the reason this family cannot
+  simply be given bigger type. From its own renderer:
+
+      const maxHeight = 300 + 5 * 30;
+      line ... .attr("y2", maxHeight)
+      drawFace(g, { cy: 300 + (5 - task.score) * 30 })
+
+  A score is drawn 30 units below the one above it, the column starts at 300 and ends at 450, and no
+  config key reaches any of those numbers. They are sized for mermaid's default 50-unit task box,
+  whose bottom lands at 298 — just above the first face.
+
+  A box that holds 36px type is 112 units, so its bottom sits at 360, INSIDE that column: scores 5, 4
+  and 3 are drawn behind the box they belong to. And a face big enough to read across a room is
+  wider than the 30-unit step between two scores, so it collides on the other side too. Both are the
+  same conflict — a fixed lattice under type it was never sized for.
+
+  So the lattice is rebuilt from the box that actually rendered: the first face clears the box by a
+  fraction of its own radius, the step is the face's own size, and the column ends below the last
+  one. The score is recovered from mermaid's formula rather than re-parsed from the diagram.
+
+  ★ ONE TRANSFORM, NOT TWO PASSES. The face and its features are siblings, and the eyes carry
+  absolute coordinates while the mouth carries its own translate — so moving the assembly by
+  rewriting children would mean three different edits. Both elements instead take the SAME transform
+  about the face's own centre, which moves and scales them together and cannot drift apart.
+*/
+export function placeJourneyFaces(svg: string, faceDiameter: number): string {
+  const FACE = /<circle\b[^>]*\bclass="face"[^>]*>(?:<\/circle>)?(\s*)<g>/g;
+  if (!FACE.test(svg)) return svg;
+  FACE.lastIndex = 0;
+
+  const attr = (tag: string, name: string) => {
+    const hit = new RegExp(`\\b${name}="([-\\d.]+)"`).exec(tag);
+    return hit ? Number(hit[1]) : NaN;
+  };
+  const box = /<rect\b[^>]*\bclass="task task-type-\d+"[^>]*>/.exec(svg)?.[0];
+  if (!box) return svg;
+  const boxBottom = attr(box, 'y') + attr(box, 'height');
+  if (!Number.isFinite(boxBottom)) return svg;
+
+  const radius = faceDiameter / 2;
+  const gap = radius * 0.4;
+  // mermaid's own lattice, named so the arithmetic below reads against it rather than against
+  // three unexplained numbers.
+  const MERMAID_TOP = 300;
+  const MERMAID_STEP = 30;
+  const MERMAID_SCORES = 5;
+  const top = boxBottom + gap + radius;
+  const step = faceDiameter * 0.9;
+  const bottom = top + (MERMAID_SCORES - 1) * step + radius + gap;
+  const remap = (cy: number) => top + ((cy - MERMAID_TOP) / MERMAID_STEP) * step;
+
+  let out = svg.replace(FACE, (whole, space: string) => {
+    const face = whole.slice(0, whole.indexOf('>') + 1);
+    const cx = attr(face, 'cx');
+    const cy = attr(face, 'cy');
+    const r = attr(face, 'r');
+    if (![cx, cy, r].every(Number.isFinite) || r <= 0) return whole;
+    const k = faceDiameter / (r * 2);
+    const dy = remap(cy) - cy;
+    const t = `transform="translate(0 ${dy}) translate(${cx} ${cy}) scale(${k}) translate(${-cx} ${-cy})"`;
+    return `${face.replace(/>$/, ` ${t}>`)}</circle>${space}<g ${t}>`;
+  });
+
+  // The dashed guide each face slides along, and the rule the column stands on — an unclassed,
+  // full-width line, which is what `y1 === y2` identifies it by.
+  out = out.replace(/<line\b[^>]*\bclass="task-line"[^>]*>/g, (line) =>
+    line.replace(/\by2="[-\d.]+"/, `y2="${bottom}"`));
+  out = out.replace(/<line\b(?![^>]*\bclass=)[^>]*>/g, (line) => {
+    const y1 = attr(line, 'y1');
+    const y2 = attr(line, 'y2');
+    if (!Number.isFinite(y1) || y1 !== y2) return line;
+    return line.replace(/\by1="[-\d.]+"/, `y1="${bottom - 2}"`).replace(/\by2="[-\d.]+"/, `y2="${bottom - 2}"`);
+  });
+
+  // The column is now taller than the box mermaid measured, so the viewBox has to follow or the
+  // lowest score is simply cropped off the diagram.
+  return out.replace(/viewBox="([-\d.]+) ([-\d.]+) ([-\d.]+) ([-\d.]+)"/, (vb, x, y, w, h) => {
+    const minY = Number(y);
+    const wanted = bottom - minY + radius + gap;
+    return Number(h) >= wanted ? vb : `viewBox="${x} ${y} ${w} ${wanted}"`;
+  });
+}
+
+/*
+  ── THE RADAR LEGEND, WHICH MERMAID GIVES NO HANDLE AT ALL ─────────────────────────────────────
+
+  ★★ THE ROW IS AN UNCLASSED GROUP AND ITS PITCH IS A LITERAL 20. mermaid appends each legend entry
+  as `g.append("g").attr("transform", translate(legendX, legendY + index * 20))` — no class, no id,
+  no config key — so there is nothing for a stylesheet to select and nothing for `mermaidConfig` to
+  set. `legendFontSize` is therefore capped at about 18 by a number no theme can reach, which is
+  why the legend read as a footnote beside a diagram sized for a room.
+
+  A string rewrite CAN reach it, and the same pass fixes the two things the pitch was hiding.
+  MEASURED off the render, in the plot group's own units:
+
+      row 0   translate(352.5, -292.5)     rect 12x12 at (0,0)     text x=16 y=0
+      row 1   translate(352.5, -272.5)          "                       "
+
+  · THE PITCH is 20 against a line box the deck's legend rung wants at 36.
+  · THE SWATCH IS NOT CENTRED ON ITS WORD. The chip spans y 0..12 while the text sits on a BASELINE
+    at y=0, so the word rides above the chip that names it — invisible at mermaid's size, plain at
+    the deck's.
+  · THE BLOCK IS NOT CENTRED ON ANYTHING. Both rows sit at the top of the right margin because the
+    first is placed at a fixed `legendY` and the rest step down from it, so a two-curve legend hangs
+    high and a six-curve one runs past the bottom of the frame.
+
+  All three come out of one rewrite: rows pitched at the deck's line box, stepped either side of the
+  plot's own centre line, with the chip seated on the baseline it labels.
+*/
+/*
+  ── THE TREEMAP SECTION HEADER, SEATED FOR THE TYPE IT NOW CARRIES ─────────────────────────────
+
+  ★★ THE BASELINE IS A LITERAL 12.5 AND THE THEME MOVED THE TYPE OUT FROM UNDER IT. mermaid writes
+  a section's name and its total on one line at `y = SECTION_HEADER_HEIGHT / 2`, a number chosen for
+  its own 12px label; this deck lifts that label to the transition rung and nothing re-seats it.
+  MEASURED on the render: `Camden` at 29px bold sits on a baseline of 12.5 with its box reaching to
+  y = -9 — nine units ABOVE the cell's own top edge, so the word crosses the border it is inside.
+
+  The same literal puts the name 6 units from the left edge and the total 10 from the right, both of
+  which are inside the 4-unit border at the deck's weight rather than clear of it.
+
+  ★ THERE IS ROOM WITHOUT MOVING ANYTHING ELSE. d3 is handed a `paddingTop` of 35 — the 25-unit
+  header plus 10 of inner padding — so the leaves already start well below the band. Measured:
+  a section 395 tall holding a 350-tall leaf, i.e. 35 above and 10 below. The seating below places
+  the ink inside that reserve and leaves the layout exactly where mermaid computed it.
+*/
+/*
+  The baseline that centres the header's ink in the band it has. Cap ink measures 0.72 of the type
+  on this face (21 units at 29px, read off the render), so the ink is centred by putting half the
+  slack above it and the rest below — derived rather than picked, because the rung above it moved
+  once already and the seating has to move with it.
+*/
+const TREEMAP_HEADER_INK = MERMAID_TAG_FONT_PX * 0.72;
+const TREEMAP_HEADER_INSET = Math.round(MERMAID_EDGE_LABEL_FONT_PX * 0.48);
+/*
+  The room a header actually has: mermaid hands d3 a `paddingTop` of the 25-unit header plus 10 of
+  inner padding, so nothing is laid out above this line. Confirmed against the render rather than
+  taken from the source — a section 395 tall holding a 350-tall leaf leaves 35 above and 10 below.
+*/
+const TREEMAP_HEADER_BAND = 35;
+/*
+  ★★ THE BAND IS SMALLER THAN IT LOOKS, because two borders eat into it. The section's own 4-unit
+  edge is drawn on its top line, so half of it is inside; the first leaf carries the same edge, and
+  half of THAT is above its top. The room the ink actually has is 2 to 33, not 0 to 35 — and
+  centring against the nominal band is what left the word visibly nearer the leaf than the border.
+  Measured before this: 9.5 clear above the cap, 7.7 below the ink, and the visible halves 7.5
+  against 5.7.
+*/
+const TREEMAP_HEADER_EDGE = DIAGRAM_STROKE_PX / 2;
+const TREEMAP_HEADER_BASELINE = Math.round(
+  TREEMAP_HEADER_EDGE + (TREEMAP_HEADER_BAND - 2 * TREEMAP_HEADER_EDGE - TREEMAP_HEADER_INK) / 2 + TREEMAP_HEADER_INK,
+);
+
+export function seatTreemapHeaders(svg: string): string {
+  /*
+    ★★ AND THE BAND CLIPS AT 25, WHICH IS WHAT ACTUALLY CUT THE WORD. Seating the baseline alone
+    made it worse, not better: mermaid gives every header its own `<clipPath>` sized to the 25-unit
+    band, so a label seated for the deck's type was cropped through the middle — measured, ink from
+    4.5 to 40.7 against a clip ending at 25. The clip has a NAME rather than a number to match on:
+    the header's is `clip-section-…` where a leaf's is `clip-…`, so this reaches the four that hold
+    a title and none of the ten that hold a cell.
+  */
+  const opened = svg.replace(/(<clipPath id="clip-section-[^"]*"><rect\b[^>]*)\sheight="[^"]*"/g,
+    (whole: string, head: string) => `${head} height="${TREEMAP_HEADER_BAND}"`);
+  return opened.replace(/<text\b([^>]*)>/g, (whole: string, attrs: string) => {
+    const label = /\bclass="[^"]*\btreemapSectionLabel\b[^"]*"/.test(attrs);
+    const value = /\bclass="[^"]*\btreemapSectionValue\b[^"]*"/.test(attrs);
+    if (!label && !value) return whole;
+    const held = /\sx="([-\d.eE+]+)"/.exec(attrs);
+    if (!held) return whole;
+    /*
+      ★ THE NAME IS ANCHORED LEFT AND THE TOTAL RIGHT, so one is set and the other is NUDGED. The
+      total's x is `width - 10`, and the width is not in the tag — moving it in by the difference is
+      the only way to inset it without re-deriving a number mermaid already computed.
+    */
+    const x = label ? TREEMAP_HEADER_INSET : Number(held[1]) - (TREEMAP_HEADER_INSET - 10);
+    if (!Number.isFinite(x)) return whole;
+    const seated = attrs
+      .replace(/\sx="[^"]*"/, ` x="${round4(x)}"`)
+      .replace(/\sy="[^"]*"/, ` y="${TREEMAP_HEADER_BASELINE}"`);
+    return `<text${seated}>`;
+  });
+}
+
+export function spaceRadarLegend(svg: string, textPx: number): string {
+  /*
+    ★★ A DEPTH SCAN, AND THE NON-GREEDY VERSION OF THIS WAS WRITTEN FIRST AND WAS WRONG — the same
+    trap recentreEdgeLabels documents two screens up, walked into anyway. `<g …>([\s\S]*?)</g>` on
+    the PLOT group matches from its opening tag to the first `</g>` in the file, which is the end of
+    legend row 0. That match is correctly rejected (its body contains a nested `<g`), but `replace`
+    has already consumed the span — so row 0 never got a match of its own and only row 1 moved.
+    Measured on the render: one row re-seated, one left exactly as mermaid drew it.
+
+    The scanner below counts opens and closes, so the group it edits is the group it matched.
+  */
+  const OPEN = /<g transform="translate\(\s*([-\d.eE+]+)[\s,]+([-\d.eE+]+)\s*\)"\s*>/g;
+  type Row = { open: number; bodyStart: number; end: number; x: string; body: string };
+  const rows: Row[] = [];
+  for (let m = OPEN.exec(svg); m; m = OPEN.exec(svg)) {
+    const bodyStart = m.index + m[0].length;
+    const end = groupEnd(svg, bodyStart);
+    if (end < 0) continue;
+    const body = svg.slice(bodyStart, end - 4);
+    // A legend row is an unclassed group holding one swatch and one word, and nothing else.
+    if (!/<rect\b[^>]*radarLegendBox-/.test(body) || /<g[\s>]/.test(body)) continue;
+    rows.push({ open: m.index, bodyStart, end, x: m[1], body });
+  }
+  if (!rows.length) return svg;
+
+  // A line box, not the glyph height — the same 1.25 spaceLegendRows gives the pie's.
+  const pitch = textPx * 1.25;
+  const top = -((rows.length - 1) / 2) * pitch;
+
+  let out = '';
+  let cursor = 0;
+  rows.forEach((row, i) => {
+    /*
+      ★★ THE CHIP IS SEATED ON THE BASELINE, NOT HUNG FROM IT. Its own y is half its height above
+      the row's origin, which puts its centre on the line the word sits on — and the word then takes
+      the deck's own answer to centring text in a box: an alphabetic baseline plus 0.35em, half a cap
+      height for this face, rather than `dominant-baseline: central`, which centres the em box with
+      its descender space included and leaves a word with no descenders riding high. The same
+      correction recentreEdgeLabels makes, for the same reason.
+    */
+    const seated = row.body
+      .replace(/<rect\b([^>]*)>/, (rect: string, attrs: string) => (
+        /radarLegendBox-/.test(attrs)
+          ? `<rect${attrs.replace(/\s(?:x|y)="[^"]*"/g, '')} x="0" y="${round4(-RADAR_SWATCH_PX / 2)}">`
+          : rect
+      ))
+      .replace(/<text\b([^>]*)>/, (whole2: string, attrs: string) => (
+        `<text${attrs.replace(/\s(?:x|y|dy)="[^"]*"/g, '')} x="${RADAR_SWATCH_PX + RADAR_SWATCH_GAP_PX}" y="0" dy="0.35em">`
+      ));
+    out += svg.slice(cursor, row.open)
+      + `<g transform="translate(${row.x}, ${round4(top + i * pitch)})">`
+      + seated
+      + '</g>';
+    cursor = row.end;
+  });
+  return out + svg.slice(cursor);
+}
+
+export function spaceLegendRows(svg: string, textPx: number): string {
+  const ROW = /<g class="legend" transform="translate\(\s*([-\d.]+)\s*,\s*([-\d.]+)\s*\)"/g;
+  const rows = [...svg.matchAll(ROW)];
+  if (rows.length < 2) return svg;
+  const ys = rows.map((m) => Number(m[2]));
+  if (!ys.every(Number.isFinite)) return svg;
+  const pitch = Math.abs(ys[1] - ys[0]);
+  // A line box, not the glyph height — the same 1.25 the deck gives a label elsewhere.
+  const wanted = textPx * 1.25;
+  if (!(pitch > 0) || pitch >= wanted) return svg;
+  const k = wanted / pitch;
+  const mean = ys.reduce((a, b) => a + b, 0) / ys.length;
+  let i = 0;
+  return svg.replace(ROW, (whole, x: string) => {
+    const y = mean + (ys[i++] - mean) * k;
+    return whole.replace(/translate\([^)]*\)/, `translate(${x}, ${y})`);
+  });
+}
+
+/*
+  ── THE JOURNEY'S ACTOR LEGEND ────────────────────────────────────────────────────────────────
+
+  The same defect as the pie legend, in different markup, which is why it needs its own pass rather
+  than a wider regex. A pie stacks `<g class="legend" transform="translate(x,y)">`; a journey emits
+  a BARE `<circle class="actor-N" cy>` followed by a `<text class="legend" y>`, both children of the
+  root, on a hard-coded 20-unit pitch. Under 36px type the two rows print on top of each other.
+
+  ★ THE DOT MOVES WITH ITS LABEL. They are separate elements with separate coordinates, so a pass
+  that opened only the text spacing would leave every dot behind on the old pitch, beside the wrong
+  name. The delta is computed once per row and applied to both.
+*/
+export function spaceJourneyLegend(svg: string, textPx: number): string {
+  const PAIR = /(<circle\b[^>]*\bclass="actor-\d+"[^>]*>(?:<\/circle>)?)(\s*)(<text\b[^>]*\bclass="legend"[^>]*>)/g;
+  const rows = [...svg.matchAll(PAIR)];
+  if (rows.length < 2) return svg;
+  const yOf = (tag: string, attr: string) => {
+    const hit = new RegExp(`\\b${attr}="([-\\d.]+)"`).exec(tag);
+    return hit ? Number(hit[1]) : NaN;
+  };
+  const ys = rows.map((m) => yOf(m[3], 'y'));
+  if (!ys.every(Number.isFinite)) return svg;
+  const pitch = Math.abs(ys[1] - ys[0]);
+  const wanted = textPx * 1.25;
+  if (!(pitch > 0) || pitch >= wanted) return svg;
+  const k = wanted / pitch;
+  const mean = ys.reduce((a, b) => a + b, 0) / ys.length;
+  let i = 0;
+  return svg.replace(PAIR, (whole, dot: string, gap: string, label: string) => {
+    const was = ys[i++];
+    const delta = mean + (was - mean) * k - was;
+    const cy = yOf(dot, 'cy');
+    const movedDot = Number.isFinite(cy)
+      ? dot.replace(/\bcy="[-\d.]+"/, `cy="${cy + delta}"`)
+      : dot;
+    const movedLabel = label.replace(/\by="[-\d.]+"/, `y="${was + delta}"`);
+    return `${movedDot}${gap}${movedLabel}`;
+  });
+}
+
+/*
+  One canvas, reused: creating a 2D context per label on a diagram with a dozen edges is the kind of
+  cost that shows up as a slow slide rather than as a wrong one. Returns 0 when there is no canvas to
+  measure with — under a test runner, say — and the caller keeps mermaid's own box in that case.
+*/
+let labelMetrics: CanvasRenderingContext2D | null | undefined;
+function measureLabel(text: string): number {
+  if (labelMetrics === undefined) {
+    labelMetrics = typeof document === 'undefined' ? null : document.createElement('canvas').getContext('2d');
+    if (labelMetrics) labelMetrics.font = `${MERMAID_EDGE_LABEL_FONT_PX}px ${MERMAID_FONT_FAMILY}`;
+  }
+  if (!labelMetrics || !text.trim()) return 0;
+  return labelMetrics.measureText(text.trim()).width;
+}
+
+/*
+  ⚠ AN EDGE LABEL ALWAYS KNOCKS OUT TO THE PAGE, EVEN INSIDE A CONTAINER — a known miss, recorded
+  because two different attempts at it have now failed and the next reader deserves the map.
+
+  A label knocks the line out behind itself, so its fill should BE the ground it sits on: the page on
+  a plain slide, the container's surface inside a `subgraph` or a composite. Getting it wrong paints
+  a page-coloured card onto a surface-coloured box, which is what happens today.
+
+  · A DESCENDANT RULE CANNOT REACH IT. mermaid collects every edge label into one `g.edgeLabels` at
+    the ROOT and positions it by transform, so a label is never a descendant of the cluster it
+    appears to sit in.
+  · A POINT-IN-RECT TEST HERE DID NOT WORK EITHER. The geometry is all in the markup — clusters
+    carry absolute `<rect x y width height>`, each `g.edgeLabel` an absolute `translate` — but the
+    two are not in the same coordinate space by the time this runs, and a test built on them fired
+    on the flowchart's `cluster` and never on the state diagram's `statediagram-cluster`.
+
+  Whoever picks this up: compare the two families' transform chains first. The answer is probably a
+  parent transform this pass is not accounting for, not the test itself.
+*/
+export function recentreEdgeLabels(svg: string): string {
+  /*
+    ★ A DEPTH SCAN, NOT A REGEX, and the difference is not stylistic. `g.label` wraps ANOTHER `<g>`
+    around the rect and the text, so a non-greedy `([\s\S]*?)</g>` stops at the INNER close tag and
+    a rewrite built on it emits markup with one `</g>` too few. The scanner below counts `<g` and
+    `</g>` so the group it edits is the group it matched.
+  */
+  const OPEN = /<g class="label"([^>]*)>/g;
+  let out = '';
+  let cursor = 0;
+  for (let m = OPEN.exec(svg); m; m = OPEN.exec(svg)) {
+    /*
+      ★★ A MATCH INSIDE A GROUP ALREADY EMITTED IS SKIPPED, or the splice eats itself. This loop now
+      emits the body it rewrote and moves the cursor PAST the whole group, where it used to leave the
+      body to the final copy. `OPEN.lastIndex` keeps scanning from inside that consumed region, so a
+      nested or adjacent `g.label` matched at an index BEHIND the cursor: `svg.slice(cursor, m.index)`
+      then returns empty and the group is written twice, with one `</g>` too many. Found on the class
+      diagram the moment cardinality labels added a second label group — the whole diagram failed to
+      render, which is what invalid markup looks like from the outside.
+    */
+    if (m.index < cursor) continue;
+    const bodyStart = m.index + m[0].length;
+    let depth = 1;
+    let i = bodyStart;
+    while (depth > 0 && i < svg.length) {
+      const nextOpen = svg.indexOf('<g', i);
+      const nextClose = svg.indexOf('</g>', i);
+      if (nextClose < 0) break;
+      if (nextOpen >= 0 && nextOpen < nextClose) { depth += 1; i = nextOpen + 2; } else { depth -= 1; i = nextClose + 4; }
+    }
+    if (depth !== 0) continue;
+    const body = svg.slice(bodyStart, i - 4);
+    const rect = /<rect[^>]*class="background"[^>]*>/.exec(body)?.[0];
+    // Only an edge label carries a background rect. A NODE label is the same `g.label` with a
+    // foreignObject in it, and mermaid positions that one correctly — so it is left alone.
+    if (!rect) continue;
+    const num = (attr: string) => {
+      const hit = new RegExp(`\\b${attr}="([-\\d.eE+]+)"`).exec(rect);
+      return hit ? Number(hit[1]) : NaN;
+    };
+    const [x, y, w, h] = ['x', 'y', 'width', 'height'].map(num);
+    // A rect mermaid has not sized yet leaves its label where it is rather than centred on NaN.
+    if (![x, y, w, h].every(Number.isFinite)) continue;
+    const attrs = m[1].replace(/\stransform="[^"]*"/, '');
+    /*
+      ★★ AND THE TEXT INSIDE IS CENTRED ON THAT RECT, not left on mermaid's baseline. The transform
+      above centres the BOX; the `<text>` in it keeps a `y` mermaid worked out for the size it laid
+      the label out at, which is its own hard 14px. Re-point the size and the glyph hangs — the same
+      defect the fragment keyword and the autonumber index each had, and the same cure: put the text
+      at the rect's own vertical centre and let `central` centre the glyph box on it rather than
+      sitting it on a baseline.
+
+      The rect's centre in this group's space is y + h/2, which is already in hand.
+    */
+    /*
+      ★★ THE KNOCKOUT BOX IS MEASURED, NOT SCALED, AND ITS PADDING IS EQUAL ON BOTH AXES.
+
+      mermaid sizes this rect around the text at the size IT laid out — its own hard 14px — and this
+      theme re-points the font in CSS afterwards, so the box keeps mermaid's proportions and its
+      padding is whatever falls out of them: wider at the sides than above and below, and both wrong
+      once the type has moved. Scaling the box by the type ratio fixed the size and kept the
+      asymmetry.
+
+      This runs in the browser, during the render, so the text can simply be MEASURED at the size it
+      will actually be drawn at — the same canvas trick the audit uses — and the box built around it
+      with one padding in both directions.
+    */
+    /*
+      ★ THE TWO PADDINGS ARE NOT THE SAME NUMBER, AND THAT IS THE POINT RATHER THAN AN OVERSIGHT.
+      They started equal, which fixed mermaid's own lopsided box — but a knockout is not a card: it
+      exists to break the line behind a word, so it wants enough air at the SIDES to separate the
+      word from the line it interrupts, and only enough above and below to clear the glyph. Equal on
+      both axes reads as a label with a box around it; tighter vertically reads as a gap in the line
+      with a word in it, which is what an edge label is.
+    */
+    const padX = Math.round(MERMAID_EDGE_LABEL_FONT_PX * 0.34);
+    const padY = Math.round(MERMAID_EDGE_LABEL_FONT_PX * 0.16);
+    const lineH = MERMAID_EDGE_LABEL_FONT_PX * 1.2;
+    const words = /<text\b[^>]*>([\s\S]*?)<\/text>/.exec(body)?.[1]?.replace(/<[^>]*>/g, '') ?? '';
+    const measured = measureLabel(words);
+    const cx = x + w / 2, cy = y + h / 2;
+    // A measurement that fails falls back to mermaid's own box rather than to a guess of zero.
+    const sw = measured > 0 ? measured + padX * 2 : w;
+    const sh = lineH + padY * 2;
+    const setAttr = (attrs: string, name: string, value: number) => {
+      const re = new RegExp(`\\b${name}="[-\\d.eE+]*"`);
+      return re.test(attrs) ? attrs.replace(re, `${name}="${value}"`) : `${attrs} ${name}="${value}"`;
+    };
+    const scaledBody = body.replace(/<rect\b([^>]*)>/, (whole2: string, rectAttrs: string) => {
+      if (!/class="background"/.test(rectAttrs)) return whole2;
+      let next = rectAttrs;
+      next = setAttr(next, 'x', cx - sw / 2);
+      next = setAttr(next, 'y', cy - sh / 2);
+      next = setAttr(next, 'width', sw);
+      next = setAttr(next, 'height', sh);
+      return `<rect${next}>`;
+    });
+    /*
+      ★★ AND THE TSPAN'S OWN `y`/`dy` HAVE TO GO, or none of the centring reaches the glyph. mermaid
+      writes `<text y="-10.1"><tspan x="0" y="-0.1em" dy="1.1em">`, and a tspan's own `y` is ABSOLUTE
+      in the text's coordinate space — it does not offset the parent's, it replaces it. So setting
+      the <text> y centred the element and the tspan put the glyph back a line below it. Dropping
+      both makes the tspan inherit the position and the baseline set on its parent.
+    */
+    const strippedBody = scaledBody.replace(/<tspan\b[^>]*>/g, (tag: string) => (
+      /text-outer-tspan|text-inner-tspan/.test(tag)
+        ? tag.replace(/\s(?:y|dy)="[^"]*"/g, '')
+        : tag
+    ));
+    /*
+      ★★ CENTRED ON CAP HEIGHT, NOT ON THE EM BOX. `dominant-baseline: central` centres the glyph box
+      with its descender space included, so a word that has no descenders — `unlocked`, `returned` —
+      rides visibly high in its own knockout. The typographic answer is the alphabetic baseline placed
+      at the box's centre plus a 0.35em nudge, half a cap height for this face, which lands the visual
+      middle of the word on the middle of the box whatever letters it happens to contain.
+    */
+    const centredBody = strippedBody.replace(/<text\b([^>]*)>/, (_t: string, tagAttrs: string) => {
+      const cleaned = tagAttrs
+        .replace(/\s(?:y|dy)="[^"]*"/g, '')
+        .replace(/\s(?:dominant|alignment)-baseline="[^"]*"/g, '');
+      return `<text${cleaned} y="${cy}" dy="0.35em">`;
+    });
+    out += svg.slice(cursor, m.index)
+      + `<g class="label"${attrs} transform="translate(${-(x + w / 2)}, ${-(y + h / 2)})">`
+      + centredBody
+      + '</g>';
+    cursor = i;
+  }
+  return out + svg.slice(cursor);
+}
+
+/*
+  ── WHAT A CONTAINER OWNS ──────────────────────────────────────────────────────────────────────
+
+  Two defects, one piece of geometry, so one scanner serves both:
+
+    · an edge label INSIDE a `subgraph` or a composite state knocked out to the PAGE, painting a
+      cream card onto the container's surface;
+    · a container's TITLE sat on its own top border and, in the state family, underneath the first
+      label inside it.
+
+  ★★ AND THE ANSWER TO THE ONE THAT HAD FAILED TWICE IS THAT CONTAINMENT IS STRUCTURAL, NOT
+  GEOMETRIC. The note that used to sit here said a point-in-rect test "fired on the flowchart's
+  `cluster` and never on the state diagram's `statediagram-cluster`", and guessed at an unaccounted
+  parent transform. There is none. MEASURED off the live render of the specimen's nested-states
+  slide, reading each element's nearest ancestor `g.root`:
+
+      label     "released" / "below 20%" / "swapped"   root: (the outer one, no transform)
+      label     "unlocked" / "returned"                root: translate(448.875, 0)
+      rect.outer  (the Deployed container)             root: translate(448.875, 0)
+
+  mermaid lays a composite state out as its OWN nested graph, and emits a nested `g.root` for it
+  holding that graph's `g.clusters`, `g.edgeLabels` and `g.nodes` as siblings. So a label drawn
+  inside a composite IS in the same coordinate space as the container's rect — they share a root —
+  and a label from the outer graph is in a DIFFERENT one. The old test compared across those two
+  spaces, where the numbers are meaningless but happen to overlap: "released" sits at x 351.7 in the
+  OUTER root, and the Deployed rect spans x 8–641.9 in the INNER one, so a naive test called it
+  contained. It is not, and no transform arithmetic was ever going to say so.
+
+  A flowchart has no nesting — one graph, one root, every subgraph a cluster in it — so scoping the
+  test to a root is exactly right there too, and both families fall out of one rule:
+
+      A LABEL IS INSIDE A CONTAINER IFF THEY SHARE A ROOT AND THE LABEL'S ORIGIN IS IN ITS RECT.
+
+  Nothing here is a stylesheet's job, which is the other half of the old note that was true: mermaid
+  puts every one of a graph's edge labels in ONE `g.edgeLabels`, so no label is a DESCENDANT of the
+  cluster it sits in and no descendant selector can reach it. A string rewrite can.
+*/
+
+/** End index (past `</g>`) of the group whose open tag ends at `bodyStart`, or -1 if unbalanced. */
+function groupEnd(svg: string, bodyStart: number): number {
+  let depth = 1;
+  let i = bodyStart;
+  while (depth > 0 && i < svg.length) {
+    const nextOpen = svg.indexOf('<g', i);
+    const nextClose = svg.indexOf('</g>', i);
+    if (nextClose < 0) return -1;
+    if (nextOpen >= 0 && nextOpen < nextClose) { depth += 1; i = nextOpen + 2; } else { depth -= 1; i = nextClose + 4; }
+  }
+  return depth === 0 ? i : -1;
+}
+
+type Span = { open: number; bodyStart: number; bodyEnd: number; end: number };
+
+/**
+ * Every `<g>` in `[from, to)` carrying `cls` as one of its class tokens, with its span.
+ *
+ * ★ A DEPTH SCAN RATHER THAN A NON-GREEDY MATCH, for the reason recentreEdgeLabels already carries:
+ * these groups nest, and `([\s\S]*?)</g>` stops at the first inner close tag.
+ */
+function groupsWithClass(svg: string, cls: string, from = 0, to = svg.length): Span[] {
+  const OPEN = /<g\b([^>]*)>/g;
+  OPEN.lastIndex = from;
+  const out: Span[] = [];
+  for (let m = OPEN.exec(svg); m && m.index < to; m = OPEN.exec(svg)) {
+    const classes = /\bclass="([^"]*)"/.exec(m[1])?.[1]?.split(/\s+/) ?? [];
+    if (!classes.includes(cls)) continue;
+    const bodyStart = m.index + m[0].length;
+    const end = groupEnd(svg, bodyStart);
+    if (end < 0) continue;
+    out.push({ open: m.index, bodyStart, bodyEnd: end - 4, end });
+  }
+  return out;
+}
+
+const attrNum = (tag: string, name: string): number => {
+  const hit = new RegExp(`\\b${name}="([-\\d.eE+]+)"`).exec(tag);
+  return hit ? Number(hit[1]) : Number.NaN;
+};
+
+type Box = { x: number; y: number; w: number; h: number };
+
+/** The container rects in one cluster group — the biggest wins, which is the one that is drawn. */
+function clusterBox(svg: string, cluster: Span): { tag: string; box: Box } | null {
+  let best: { tag: string; box: Box } | null = null;
+  const RECT = /<rect\b[^>]*>/g;
+  RECT.lastIndex = cluster.bodyStart;
+  for (let m = RECT.exec(svg); m && m.index < cluster.bodyEnd; m = RECT.exec(svg)) {
+    const classes = /\bclass="([^"]*)"/.exec(m[0])?.[1]?.split(/\s+/) ?? [];
+    // `inner` is scaffolding the deck already hides; `background` is the title's own knockout and
+    // carries no geometry at all.
+    if (classes.includes('inner') || classes.includes('background')) continue;
+    const box = { x: attrNum(m[0], 'x'), y: attrNum(m[0], 'y'), w: attrNum(m[0], 'width'), h: attrNum(m[0], 'height') };
+    if (!Object.values(box).every(Number.isFinite) || box.w <= 0 || box.h <= 0) continue;
+    if (!best || box.w * box.h > best.box.w * best.box.h) best = { tag: m[0], box };
+  }
+  return best;
+}
+
+/** The `translate(x, y)` on a tag, or null. */
+function translateOf(tag: string): { x: number; y: number } | null {
+  const m = /\btransform="translate\(\s*([-\d.eE+]+)[\s,]+([-\d.eE+]+)\s*\)"/.exec(tag);
+  return m ? { x: Number(m[1]), y: Number(m[2]) } : null;
+}
+
+/**
+ * One graph: a `g.root` and the `g.clusters` / `g.edgeLabels` that are ITS OWN, not a nested
+ * graph's. Nested roots live inside `g.nodes`, so rejecting anything inside one is the whole test.
+ */
+type Graph = { root: Span; clusters: Span[]; edgeLabels: Span[] };
+
+function graphsOf(svg: string): Graph[] {
+  const roots = groupsWithClass(svg, 'root');
+  return roots.map((root) => {
+    const nested = roots.filter((r) => r !== root && r.open > root.bodyStart && r.end <= root.end);
+    const own = (s: Span) => !nested.some((n) => s.open > n.open && s.end <= n.end);
+    const holders = groupsWithClass(svg, 'clusters', root.bodyStart, root.bodyEnd).filter(own);
+    const clusters = holders.flatMap((h) => {
+      // The direct children of `g.clusters` ARE the clusters — `g.cluster` on a flowchart,
+      // `g.statediagram-state.statediagram-cluster` on a state diagram. Take every group that
+      // starts at the holder's own depth.
+      const out: Span[] = [];
+      let i = h.bodyStart;
+      while (i < h.bodyEnd) {
+        const open = svg.indexOf('<g', i);
+        if (open < 0 || open >= h.bodyEnd) break;
+        const close = svg.indexOf('>', open);
+        if (close < 0) break;
+        const end = groupEnd(svg, close + 1);
+        if (end < 0) break;
+        out.push({ open, bodyStart: close + 1, bodyEnd: end - 4, end });
+        i = end;
+      }
+      return out;
+    });
+    return {
+      root,
+      clusters,
+      edgeLabels: groupsWithClass(svg, 'edgeLabels', root.bodyStart, root.bodyEnd).filter(own),
+    };
+  });
+}
+
+/** Every edge label in `graph`, with the origin mermaid positioned it at. */
+function labelsOf(svg: string, graph: Graph): Array<Span & { at: { x: number; y: number } }> {
+  return graph.edgeLabels.flatMap((holder) =>
+    groupsWithClass(svg, 'edgeLabel', holder.bodyStart, holder.bodyEnd)
+      .map((span) => {
+        const at = translateOf(svg.slice(span.open, span.bodyStart));
+        return at ? { ...span, at } : null;
+      })
+      .filter((v): v is Span & { at: { x: number; y: number } } => v !== null));
+}
+
+const inside = (at: { x: number; y: number }, b: Box) =>
+  at.x >= b.x && at.x <= b.x + b.w && at.y >= b.y && at.y <= b.y + b.h;
+
+/*
+  A LABEL KNOCKS THE LINE OUT BEHIND ITSELF, SO ITS FILL HAS TO BE THE GROUND IT SITS ON — and
+  inside a container that ground is the container's surface, not the page.
+
+  Marked with an ATTRIBUTE rather than a class, and the difference is load-bearing:
+  recentreEdgeLabels matches `<g class="label"` exactly, so adding a second class to that attribute
+  would silently take every marked label out of the pass that centres it. The rule this pairs with
+  re-points `--deck-mermaid-label-bg` on the group, which INHERITS — so the knockout fill and the
+  text's own mix-toward-the-ground both follow from one declaration.
+*/
+export const CONTAINER_GROUND_ATTR = 'data-on-container';
+
+export function groundLabelsOnContainers(svg: string): string {
+  const marks: number[] = [];
+  for (const graph of graphsOf(svg)) {
+    const boxes = graph.clusters.map((c) => clusterBox(svg, c)?.box).filter((b): b is Box => !!b);
+    if (!boxes.length) continue;
+    for (const label of labelsOf(svg, graph)) {
+      if (!boxes.some((b) => inside(label.at, b))) continue;
+      const inner = groupsWithClass(svg, 'label', label.bodyStart, label.bodyEnd)[0];
+      if (inner) marks.push(inner.open);
+    }
+  }
+  if (!marks.length) return svg;
+  // Rewritten back to front so an earlier splice cannot move a later index.
+  let out = svg;
+  for (const at of marks.sort((a, b) => b - a)) {
+    const close = out.indexOf('>', at);
+    if (close < 0) continue;
+    out = `${out.slice(0, close)} ${CONTAINER_GROUND_ATTR}=""${out.slice(close)}`;
+  }
+  return out;
+}
+
+/*
+  ── SEATING A CONTAINER'S TITLE ────────────────────────────────────────────────────────────────
+
+  ★★ THE TITLE BAND IS SIZED AT LAYOUT TIME AND THE TYPE IS RE-POINTED AFTERWARDS, which is the same
+  defect this file has already met on the fragment keyword, the autonumber index and the edge label:
+  mermaid measures, this theme changes the size, and nothing reflows. MEASURED on the nested-states
+  slide, in the container's own units:
+
+      rect.outer        y 8      -> 196.5
+      g.cluster-label   y 5.81   -> 51.05      (2.19 units ABOVE the box it titles)
+      "unlocked"        text top 50.35         (the first thing inside)
+
+  So the word sat ON its own 4-unit border — which is what "cut off" looks like — and the gap to the
+  first label was NEGATIVE. Both halves are one sum: the band a title needs is its own height plus a
+  padding at each end, and the band it HAS is from the box's top edge to the first thing inside.
+
+  ★ THE CLEARANCE IS MEASURED TO THE TEXT, NOT TO THE KNOCKOUT. An edge label's box is deliberately
+  taller than its word (recentreEdgeLabels pads it), and now that the box paints the container's own
+  surface it is invisible — so seating the title against the BOX leaves an optical hole above the
+  title that reads as worse than the collision it fixed. Measured both ways on the live render.
+
+  ★★ AND GROWING THE BOX MEANS GROWING THE viewBox. The container's top edge can rise above the
+  diagram's own bounds, and the outermost <svg> clips there. fitToColumn reads the viewBox for the
+  natural size it caps against and runs LAST, so extending it here is picked up for free — but only
+  because of that ordering.
+*/
+/*
+  ★ PAD IS THE GAP FROM THE BOX'S TOP EDGE TO THE TITLE'S ORIGIN, and mermaid's own value for it is
+  ZERO — `translate(x, clusterY - 2)` against a band that starts at clusterY. A sixth of the body
+  rung is the smallest step that reads as deliberate air rather than a rounding error at room scale.
+*/
+const CLUSTER_TITLE_PAD = Math.round(MERMAID_FONT_PX * 0.17);
+
+/*
+  ★★ THE TITLE'S HEIGHT IS ALREADY IN THE MARKUP, so nothing here has to measure anything. mermaid
+  writes `rect.inner.y = clusterY + bbox.height + 2` (clusters.js, roundedWithTitle) where bbox is a
+  LIVE measurement of the title text taken at layout time. Read backwards, the inner rect states the
+  height mermaid measured — 45 on the nested-states slide, against 45.24 for the group's painted box
+  — so this pass is pure arithmetic on the string and provable red in vitest without a canvas.
+
+  It is also the reason the pass is scoped to clusters that HAVE an inner rect. That is the state
+  family's composite, which is where the collision is; a flowchart subgraph draws one rect and no
+  content box, so there is no stated title height to reason from and its band is left alone.
+*/
+const TITLE_BAND_SLACK = 2;
+
+export function seatClusterTitles(svg: string): string {
+  const edits: Array<{ from: string; to: string }> = [];
+  let rise = 0; // how far past the diagram's own top edge the tallest container now reaches
+
+  for (const graph of graphsOf(svg)) {
+    const labels = labelsOf(svg, graph);
+    for (const cluster of graph.clusters) {
+      const found = clusterBox(svg, cluster);
+      const title = groupsWithClass(svg, 'cluster-label', cluster.bodyStart, cluster.bodyEnd)[0];
+      if (!found || !title) continue;
+      const titleTag = svg.slice(title.open, title.bodyStart);
+      const seat = translateOf(titleTag);
+      if (!seat) continue;
+      const { box } = found;
+
+      const innerRect = /<rect\b[^>]*\bclass="[^"]*\binner\b[^"]*"[^>]*>/.exec(svg.slice(cluster.bodyStart, cluster.bodyEnd));
+      if (!innerRect) continue;
+      const innerY = attrNum(innerRect[0], 'y');
+      const titleHeight = innerY - box.y - TITLE_BAND_SLACK;
+      if (!Number.isFinite(titleHeight) || titleHeight <= 0) continue;
+
+      /*
+        ★ THE CLEARANCE IS MEASURED TO THE INK, NOT TO THE KNOCKOUT. recentreEdgeLabels pads an edge
+        label's box well past its word, and now that the box paints the container's own surface that
+        padding is invisible — so seating the title against the BOX opens an optical hole above the
+        title that reads worse than the collision it fixes. Measured both ways on the live render.
+      */
+      const lineH = MERMAID_EDGE_LABEL_FONT_PX * 1.2;
+      const contentTop = Math.min(
+        innerY,
+        ...labels.filter((l) => inside(l.at, box)).map((l) => l.at.y - lineH / 2),
+      );
+
+      const grow = Math.max(0, titleHeight + CLUSTER_TITLE_PAD * 2 - (contentTop - box.y));
+      const top = box.y - grow;
+
+      if (grow > 0) {
+        edits.push({
+          from: found.tag,
+          to: found.tag
+            .replace(/\by="[-\d.eE+]*"/, `y="${round4(top)}"`)
+            .replace(/\bheight="[-\d.eE+]*"/, `height="${round4(box.h + grow)}"`),
+        });
+        rise = Math.max(rise, grow - (box.y - viewBoxTop(svg)));
+      }
+      const seated = top + CLUSTER_TITLE_PAD;
+      if (Math.abs(seated - seat.y) > 0.01) {
+        edits.push({
+          from: titleTag,
+          to: titleTag.replace(/\btransform="translate\([^)]*\)"/, `transform="translate(${round4(seat.x)}, ${round4(seated)})"`),
+        });
+      }
+    }
+  }
+  if (!edits.length) return svg;
+
+  let out = svg;
+  for (const e of edits) {
+    const at = out.indexOf(e.from);
+    if (at < 0) continue;
+    out = out.slice(0, at) + e.to + out.slice(at + e.from.length);
+  }
+  return rise > 0 ? growViewBoxTop(out, rise) : out;
+}
+
+const round4 = (n: number) => Number(n.toFixed(4));
+
+function viewBoxTop(svg: string): number {
+  const vb = /viewBox="([^"]+)"/.exec(svg)?.[1]?.trim().split(/\s+/);
+  return vb?.length === 4 ? Number(vb[1]) : Number.NaN;
+}
+
+/*
+  ★★ GROWING THE BOX MEANS GROWING THE viewBox, or the outermost <svg> clips the top edge off the
+  container it was just given. fitToColumn reads the viewBox for the natural size it caps against
+  and runs LAST in the pipeline, so the new numbers are picked up for free — but only because of
+  that ordering.
+*/
+function growViewBoxTop(svg: string, by: number): string {
+  return svg.replace(/viewBox="([^"]+)"/, (whole, v: string) => {
+    const n = v.trim().split(/\s+/).map(Number);
+    if (n.length !== 4 || n.some(Number.isNaN)) return whole;
+    return `viewBox="${n[0]} ${round4(n[1] - by)} ${n[2]} ${round4(n[3] + by)}"`;
+  });
+}
+
+/*
+  ── THE BOX THAT IS NOT A RECT ─────────────────────────────────────────────────────────────────
+  mermaid draws a class box, a state NOTE and an ER entity through its unified shape registry, which
+  hands them to rough.js. rough returns a <g> of two <path>s — a solid fill path and a double-stroked
+  outline of eight open beziers — so the element is `g.basic.label-container.outer-path` and there is
+  no <rect> anywhere in it. Every corner rule in DIAGRAM_RULES names `rect`, including the one that
+  repeats mermaid's own `.statediagram-note rect`, so all of them match nothing and the boxes draw
+  square. mermaid's own note rule is dead upstream for the same reason.
+
+  roundPolygons cannot reach these: it reads the `points` ATTRIBUTE of a <polygon> and walks one
+  closed ring of straight segments. rough emits neither.
+
+  So restore the rect. THE RECTANGLE TEST IS THE SCOPING — `outer-path` is shared with the cylinder,
+  the stadium and every other rough shape, and on those the outline IS the meaning. Their fill path
+  opens with a curve; only a real box gives four axis-aligned corners. Colours travel as PRESENTATION
+  attributes, exactly as rough wrote them, so the tone rules still override them.
+*/
+function axisAlignedRect(d: string): { x: number; y: number; w: number; h: number } | null {
+  const tokens = d.trim().match(/[A-Za-z]|-?\d*\.?\d+/g);
+  if (!tokens) return null;
+  const letters = tokens.filter((t) => /[A-Za-z]/.test(t));
+  /* ★ THE COMMAND LIST IS CHECKED BEFORE THE COORDINATE COUNT, and both are load-bearing. A curve
+     is rejected here even when it happens to carry eight numbers — `M x y C x y, x y, x y` does,
+     and a coordinate-count test alone would read it as a box. */
+  if (letters.length < 4 || letters[0] !== 'M' || !letters.slice(1, 4).every((c) => c === 'L')) return null;
+  if (letters.slice(4).some((c) => c !== 'Z' && c !== 'z')) return null;
+  const nums = tokens.filter((t) => !/[A-Za-z]/.test(t)).map(Number);
+  if (nums.length !== 8 || nums.some(Number.isNaN)) return null;
+  const [x0, y0, x1, y1, x2, y2, x3, y3] = nums;
+  if (y0 !== y1 || x1 !== x2 || y2 !== y3 || x3 !== x0) return null;
+  const w = x1 - x0, h = y3 - y0;
+  if (!(w > 0 && h > 0)) return null;
+  return { x: x0, y: y0, w, h };
+}
+
+export function rectifyOuterPaths(svg: string): string {
+  return svg.replace(/<g class="([^"]*\bouter-path\b[^"]*)">([\s\S]*?)<\/g>/g, (whole, cls: string, body: string) => {
+    // A nested group would end the non-greedy match early and the replacement would eat live markup.
+    if (body.includes('<g')) return whole;
+    const paths = [...body.matchAll(/<path\b([^>]*?)\/?>/g)].map((m) => m[1]);
+    if (!paths.length) return whole;
+    const attr = (s: string, name: string) => (s.match(new RegExp(`\\b${name}="([^"]*)"`)) || [])[1];
+    const box = axisAlignedRect(attr(paths[0], 'd') ?? '');
+    if (!box) return whole;
+    const stroke = paths[1] ?? '';
+    const dash = attr(stroke, 'stroke-dasharray');
+    const out = [
+      `class="${cls.replace(/\bouter-path\b/, '').trim()}"`,
+      `x="${box.x}" y="${box.y}" width="${box.w}" height="${box.h}"`,
+      `fill="${attr(paths[0], 'fill') ?? 'none'}"`,
+      `stroke="${attr(stroke, 'stroke') ?? 'none'}"`,
+      `stroke-width="${attr(stroke, 'stroke-width') ?? '0'}"`,
+      dash && dash !== '0 0' ? `stroke-dasharray="${dash}"` : '',
+    ].filter(Boolean).join(' ');
+    return `<rect ${out}/>`;
+  });
+}
+
+export function roundPolygons(svg: string, radius: number): string {
+  /* ⚠ THE CLOSING TAG IS PART OF THE MATCH. Replacing only `<polygon …>` leaves a `</polygon>` with
+     no opening tag, and the parser then nests the node's LABEL inside the new <path> — the shape
+     rounds correctly and the text disappears, which looks like a labelling bug rather than a markup
+     one. Both the self-closing and the paired form are consumed. */
+  return svg.replace(/<polygon([^>]*?)points="([^"]+)"([^>]*?)\/?>(?:<\/polygon>)?/g, (whole, pre, points, post) => {
+    /*
+      ⚠ NOT EVERY POLYGON IS A NODE. The sequence fragment's tab is one — a five-point shape with a
+      clipped bottom-right corner, `<polygon class="labelBox" points="351,390 407,390 407,406
+      398.6,413 351,413">` — and that clip is the notation: it is what makes the tab read as a tab
+      rather than a small box sitting on the frame. Rounded at the node radius it came out as a
+      lozenge, and the clipped corner disappeared into the curve. mermaid's own shape is right here
+      and the deck leaves it alone.
+    */
+    if (/\blabelBox\b/.test(pre) || /\blabelBox\b/.test(post)) return whole;
+    const pts = points.trim().split(/\s+/).map((pair: string) => pair.split(',').map(Number));
+    if (pts.length < 3 || pts.some((q: number[]) => q.length !== 2 || q.some(Number.isNaN))) return whole;
+    const n = pts.length;
+    let d = '';
+    for (let i = 0; i < n; i++) {
+      const prev = pts[(i - 1 + n) % n], cur = pts[i], next = pts[(i + 1) % n];
+      const seg = (a: number[], b: number[]) => {
+        const dx = b[0] - a[0], dy = b[1] - a[1];
+        const len = Math.hypot(dx, dy) || 1;
+        return { ux: dx / len, uy: dy / len, len };
+      };
+      const from = seg(cur, prev), to = seg(cur, next);
+      const r = Math.min(radius, from.len / 2, to.len / 2);
+      const a = [cur[0] + from.ux * r, cur[1] + from.uy * r];
+      const b = [cur[0] + to.ux * r, cur[1] + to.uy * r];
+      d += `${i === 0 ? 'M' : 'L'}${a[0].toFixed(2)},${a[1].toFixed(2)} Q${cur[0].toFixed(2)},${cur[1].toFixed(2)} ${b[0].toFixed(2)},${b[1].toFixed(2)} `;
+    }
+    return `<path${pre}d="${d.trim()}Z"${post.replace(/\/$/, '')}/>`;
+  });
+}
+
+/**
+ * Append the floor to mermaid's own stylesheet, scoped to this diagram's id.
+ *
+ * Scoped rather than global for the same reason mermaid scopes its own: two diagrams on one slide
+ * are two shadow roots today, but the id prefix is what makes that an implementation detail rather
+ * than something these rules depend on.
+ */
+export function applyRoomScale(svg: string, id: string, register: Register = 'light'): string {
+  /*
+    ★★ EVERY SELECTOR IN THE LIST IS SCOPED, NOT JUST THE FIRST. `#${id} ${rule}` prefixes the string,
+    which reaches the first selector of a comma list and no other — so a rule written for five shapes
+    arrived as one scoped selector at (1,1,1) and four unscoped ones at (0,1,1), and mermaid's own
+    `#id .node …` beat every one of the four. The visible symptom was a rounded rhombus keeping a 1px
+    border while the rectangle beside it took 3.
+  */
+  const scope = (rule: string) => {
+    const open = rule.indexOf('{');
+    if (open < 0) return `#${id} ${rule}`;
+    const selectors = rule.slice(0, open).split(',').map((sel) => `#${id} ${sel.trim()}`).join(',');
+    return selectors + rule.slice(open);
+  };
+  // The background rules carry literal hex and so are the one part of this list that differs by
+  // register — appended rather than interleaved, so a background always wins the tie against the
+  // untoned rule above it.
+  const rules = [...ROOM_SCALE_RULES, ...mermaidInkRules(register), ...mermaidBackgroundRules(register)].map(scope).join('');
+  // If mermaid ever stops emitting a <style>, silently dropping the floor would look like the
+  // fonts simply being wrong again — so the rules go in either way.
+  return svg.includes('</style>')
+    ? svg.replace('</style>', `${rules}</style>`)
+    : svg.replace(/(<svg[^>]*>)/, `$1<style>${rules}</style>`);
+}
+
+/*
+  ★★ RENDERS ARE SERIALISED, AND THIS IS THE ONE THING IN THIS FILE THAT ONLY EXPORT COULD FIND.
+
+  `mermaid.initialize()` does not configure a render — it mutates ONE piece of module-global state
+  that the next `mermaid.render()` reads. This renderer therefore does initialize-then-render as a
+  pair, and that pair has to be atomic.
+
+  In the browser it looked atomic for free: Slidev mounts one slide at a time, so no two diagrams
+  are ever in flight together. `slidev export` does not work that way — it renders the WHOLE deck
+  into one print container, so every diagram mounts at once and four `initialize` calls interleave
+  with four `render` calls. The last configuration written wins for all of them.
+
+  MEASURED, on the exported PDF of this very deck: the specimen's four diagram slides are three
+  light and one dark, and in the PDF all four came out in the DARK palette — near-black nodes with
+  white labels, sitting on the deck's cream ground. The sequence diagram's message labels were
+  near-white text on cream, i.e. invisible. Every one of them renders correctly in a browser, and
+  the audit (which drives a browser) passed them, because the audit visits one slide at a time.
+
+  The queue is a plain promise chain: each call waits for the previous pair to finish before writing
+  its own config. It costs nothing in the browser, where the queue is never more than one deep.
+*/
+let renderQueue: Promise<unknown> = Promise.resolve();
+
+export default function setupMermaidRenderer(): MermaidRenderFn {
+  return async (code, options) => {
+    const register = options?.theme === 'dark' ? 'dark' : 'light';
+
+    // `theme` is consumed here — it names a REGISTER in this deck, not one of mermaid's own themes,
+    // and passing it through would select mermaid's built-in 'dark' palette and discard every
+    // themeVariable below it. `scale` belongs to Slidev's own component, not to mermaid.
+    const { theme: _theme, scale: _scale, ...rest } = options ?? {};
+
+    const run = renderQueue.then(async () => {
+      const mermaid = await loadMermaid();
+      mermaid.initialize({ ...mermaidConfig(register), ...rest });
+
+      // Same container @slidev/client's own fallback path uses — mermaid measures text in a live
+      // DOM node, and without one every label is laid out against a zero-width box.
+      const container = document.getElementById('mermaid-rendering-container') ?? undefined;
+      const id = `forest-mermaid-${register}-${counter++}`;
+      const { svg } = await mermaid.render(id, code, container as Element);
+      const shaped = recentreEdgeLabels(
+        chevronArrowheads(growArrowheads(viewBoxArrowheads(unscaleStrokeMarkers(sizeDiamondMarkers(roundTimelineNodes(roundPolygons(rectifyOuterPaths(svg), POLYGON_RADIUS), DIAGRAM_RADIUS)))))),
+      );
+      /*
+        ★ BOTH CONTAINER PASSES RUN AFTER recentreEdgeLabels, AND FOR DIFFERENT REASONS. The ground
+        pass adds an ATTRIBUTE to `g.label`, which recentre matches as `<g class="label"` and would
+        still find — but seating reads where the labels ENDED UP, and recentre is what moves them.
+      */
+      const contained = seatClusterTitles(groundLabelsOnContainers(shaped));
+      const spaced = seatTreemapHeaders(spaceRadarLegend(spaceJourneyLegend(spaceLegendRows(contained, PIE_LEGEND_PX), PIE_LEGEND_PX), MERMAID_LEGEND_FONT_PX));
+      const placed = placeJourneyFaces(spaced, MERMAID_FONT_PX * FACE_DIAMETER_EM);
+      return fitToColumn(applyRoomScale(placed, id, register));
+    });
+    // The queue must survive a failed render, or one bad diagram wedges every one after it.
+    renderQueue = run.catch(() => {});
+    return run;
+  };
+}