efficient-storefront-blocks 0.57.0 → 0.58.1

package/dist/render/app/globals.css

@@ -0,0 +1,3264 @@
+/* THE SITE'S STYLESHEET — the design tokens, the theme-derived surfaces, every
+   section's and card's own rules, the word styles, the motion. It is the blocks'
+   look, so it lives with the blocks (efficient-storefront doc/adr/0009).
+
+   It carries no `@import "tailwindcss"` and no `@source`: those are the HOST's,
+   because only the host knows which files its pages are built from. The
+   storefront's entry is its `app/tailwind.css` (`@import "tailwindcss"`, then
+   this file, then the storefront's `@source` exclusions); the package's canvas
+   is built from this repository's own. Everything below is the storefront's
+   `app/globals.css` from line 79 on, as it stood on 2026-10-10. */
+
+/* ─── Storefront design tokens ───────────────────────────────────── */
+/* ⚠️ THE SURFACE, LINE AND RADIUS TOKENS ARE `--site-*`, AND THAT IS A NAME
+   COLLISION FIXED, NOT A STYLE. efficient-shell's UI kit declares `--surface`,
+   `--line` and `--radius-sm…2xl` as ITS tokens, and this sheet publishes the
+   site's on <body> (the surface mapping below, the corner tokens in
+   app/layout.tsx). Where both are on one page — the storefront's editor harnesses — the kit's
+   dialogs, popovers and colour picker are portalled to <body> and inherited the
+   SITE'S values: light-on-light in dark mode, square menus on a site whose
+   Corners is 0. Harness UI-24 says editor chrome resolves to the kit's tokens,
+   so the site's own carry a prefix the kit never reads. Tailwind's class names
+   are unchanged: `bg-surface`, `border-line` and `rounded-*` reach the prefixed
+   properties through the theme block (`inline`) with the named colours below.
+
+   The `-base` inputs and `--bg` / `--fg` / `--accent` keep their names: the kit
+   declares none of them. A STORED fill that names the old spelling —
+   `var(--surface)` in a published section's background — is translated where it
+   is painted (`paintedFill` in lib/content/section-background), not here. */
+/* Dark theme (default) */
+:root {
+  /* Surface BASES — the light/dark page surfaces. Split out from the live token
+     for the same reason --fg-base is (below): the colour Theme's per-site
+     surfaces (--theme-bg / --theme-surface / --theme-line / --theme-muted) remap
+     these on `.sf-theme-surfaces`, in EVERY mode since 66238, and an un-themed
+     site falls back to the base. A base is a plain literal; the live token is
+     always `var(<base>)`.
+
+     ⏳ THIS USED TO SAY "in DARK MODE ONLY … so a near-black themed background
+     can never end up under the light theme's near-black ink". That protection
+     went when a theme became one flat palette and the surfaces started applying
+     in both modes. The sentence stayed, and the gap it described re-opened in
+     the CHROME, which was still taking its ink from the mode. Fixed by mapping
+     --fg beside --bg on `.sf-theme-surfaces`; see the note there. */
+  --bg-base: #0a0a0a;
+  --bg: var(--bg-base);
+  --surface-base: #131313;
+  --site-surface: var(--surface-base);
+  --surface-2-base: #1c1c1c;
+  --site-surface-2: var(--surface-2-base);
+  /* Foreground BASE — the light/dark page ink. Split out from --fg so the colour
+     Theme's per-site ink (--theme-fg) can remap --fg on `.sf-theme-surfaces` and
+     `.sf-themed-content`, in EVERY mode; a site that has chosen no theme falls
+     back to this base.
+
+     ⏳ THIS USED TO SAY "in DARK mode only … so a dark-mode cream text can't land
+     on the cream light-mode page". True when a preset carried an ink and no
+     background of its own. A flat palette (66238) carries both, so the ink can
+     only ever land on that palette's own background — the case this guarded
+     against cannot arise, and the guard itself became the bug in the chrome. */
+  --fg-base: #f5f1e8;
+  --fg: var(--fg-base);
+  --fg-dim-base: #9a9388;
+  --fg-dim: var(--fg-dim-base);
+  --line-base: #2a2a2a;
+  --site-line: var(--line-base);
+  /* Theme-colour BASES. Split out from the live token for exactly the reason
+     --fg-base and the surface bases are: the merchant's theme colour is now TWO
+     colours, one per mode, and .sf-theme-accent below maps whichever the mode
+     calls for onto --accent. A base is a plain literal per mode; the live token is
+     always `var(<base>)`, so a site with no theme of its own resolves to
+     precisely the values it uses today. */
+  --accent-base: #c9a461;
+  --accent: var(--accent-base);
+  --accent-2-base: #b08a44;
+  --accent-2: var(--accent-2-base);
+
+  /* ⛔ THE FOUR MODE-PINNED accent bases (--accent-base-on-dark / -on-light and
+     their -2 pair, card 66401.g) WERE DELETED HERE on 2026-09-04. They existed
+     for one reader — the `.sf-section-surface-*` blocks, which pinned a mode and
+     so could not read the page-following --accent-base. Nothing pins a mode any
+     more (see the note above `.sf-section-accent` below), so nothing read them.
+     Adding them back without a mode-pinned block to read them is dead weight. */
+  /* The ink a filled control puts ON the accent. A BASE like the others, and a
+     literal here because :root has no theme to derive from: it is accentInk()'s
+     answer for the house gold above (black, 8.97:1). A themed site overrides it
+     from the carrier; see .sf-theme-accent. */
+  --accent-ink-base: #000000;
+  --accent-ink: var(--accent-ink-base);
+  /* THE BUTTON'S FILL, and by default it IS the accent (card 66504). A theme
+     may carry its own button colour; one that does not — every theme that
+     exists today — resolves straight back to the accent triple beside this, so
+     the button is byte-identical to what it painted before this token existed.
+
+     ⚠️ DECLARED IN EVERY SCOPE THAT REBINDS --accent, not only here. A custom
+     property is resolved where it is DECLARED, so a single `--btn: var(--accent)`
+     on the carrier would freeze the site accent and a section that pinned its own
+     accent would stop moving its buttons. Same rule, same reason, as --accent-ink
+     next door; scripts/test-button-ink.ts holds it for that one. */
+  --btn: var(--theme-btn, var(--accent));
+  --btn-2: var(--theme-btn-2, var(--accent-2));
+  --btn-ink: var(--theme-btn-ink, var(--accent-ink));
+  /* Discount / "savings" + "fits perfect" success accent. Tuned to
+     read on the dark page bg without becoming a neon highlight. */
+  --green: #7aa672;
+  /* Foreground text that sits over dark media — video posters, photo
+     overlays — and must stay cream in BOTH themes (unlike --fg, which
+     flips to near-black in light mode). Defined once here, deliberately
+     not overridden in the [data-theme="light"] block below. */
+  --overlay-fg: #f5f1e8;
+  /* Its mirror: foreground text that sits over a LIGHT surface and must stay
+     near-black in BOTH themes. Same contract as --overlay-fg above — declared
+     once here and deliberately NOT overridden in the [data-theme="light"] block
+     below. Its one consumer is the site header's "Text colour at the top =
+     Dark" override, which is a merchant saying "the thing under my nav is
+     light" about a page in either theme, so it cannot be var(--fg). The value
+     is the same near-black the deleted light surface class used to paint. */
+  --overlay-fg-on-light: #0a0a0a;
+  /* Alert / destructive accent — a muted terracotta. Used for inline
+     error messages and the cart "remove" hover. Theme-independent. */
+  --alert: #c97a6a;
+  /* Deep warm tint used as the far stop of the decorative card-panel
+     gradients (gallery card hover panel, PDP process panel). */
+  --panel-tint: #181410;
+  /* Pure black / white reserved for chrome composited over media —
+     video letterbox scrims and the controls + borders layered on top.
+     Theme-independent: media renders dark regardless of page theme. */
+  --overlay-scrim: #000;
+  --overlay-chrome: #fff;
+  /* Tells the browser to paint OS chrome (select dropdown panels,
+     scrollbars, native checkboxes) in dark mode so they match the
+     site palette instead of flashing white. */
+  color-scheme: dark;
+  /* ─── Card-surface tokens ─────────────────────────────────────
+     Used by the home page ProductCard, the wheels CatalogCard, and
+     the journal ArticleCard / Cover article. Dark mode lifts each
+     card to a medium-dark grey (~#4d4b48 — a clear step lighter than
+     the page bg #0a0a0a so cards don't melt into the page). The
+     hover variant nudges another 10pp toward the foreground for a
+     visible "lifted" state. Light mode keeps the originals so the
+     cream-on-cream card system stays untouched.
+     The journal "Recent issues" panel uses --journal-panel-bg, which
+     dark mode collapses to --bg (no visible grey rectangle in the
+     bottom-right) while light mode keeps the original --site-surface fill.
+     The wheels catalog grid container uses --catalog-grid-bg, which
+     dark mode collapses to --bg (so empty grid cells in partial last
+     rows match the page) while light mode keeps the original --site-line
+     fill (which paints the hairline-divider effect through the 2px
+     gap between cards).
+     Card mix ratios pushed down again per request — another 20%
+     darker step. Now 92/8 rest, 82/18 hover (was 85/15 / 75/25),
+     resolving to roughly ~#2d2d2c rest / ~#3c3a37 hover. Each step
+     shaves more cream/foreground out of the mix and pulls the result
+     closer to the underlying --site-surface-2 #1c1c1c base, while still
+     keeping enough lift to read as a clear card surface against the
+     #0a0a0a page background.
+     The five recipes themselves live in the "theme-derived" block
+     below rather than here — they read --site-surface-2 / --bg / --fg,
+     and a custom property substitutes its var()s where it is
+     DECLARED, so declaring them at :root alone would freeze the
+     built-in surfaces and ignore the merchant's palette. */
+  /* ─── Component-scoped tokens ──────────────────────────────────
+     Used by single components but defined here so the underlying
+     colour stays a one-place change. Theme-independent unless the
+     light block overrides. */
+  /* Muted accent tint used by the PDP fitment-diagram outline. */
+  --accent-dim:                #9a8050;
+  /* PhotoPlate's plate band (card 029) — the spec strip docked over the
+     plate photograph's bottom edge (or below it on phones). PHOTOGRAPHY
+     FURNITURE: like --overlay-fg it stays dark on BOTH page themes, so it
+     is deliberately NOT overridden in the light block below — a light-theme
+     tenant (XM) still gets the dark band the design draws. A tenant theme
+     may override all three. Values are the XM draft's: band #131313, ink
+     #C9C9C5, dim ink #6A6A64 (the mobile artboard's second line). */
+  --plate-band-bg:           #131313;
+  --plate-band-fg:           #c9c9c5;
+  --plate-band-fg-dim:       #6a6a64;
+  /* Always-dark tooltip surface — overlaid on light + dark pages. */
+  --tooltip-bg:              #3a3a3a;
+  /* The stage a wheel render sits on inside the product cards — the shared
+     components/WheelCardFrame (Product Grid + Alloy Wheels Listing) and the
+     /wheels CatalogCard. This is the DARK value; light mode overrides it in
+     the theme-derived light block below.
+     🔁 REVERSAL (66035, 2026-08-09) — do NOT "fix" this back. Between
+     1.25.1 and now this token was deliberately always-black, so the render
+     sat on one consistent backdrop in both themes. The owner has reversed
+     that: in light mode the stage now FOLLOWS THE LIGHT THEME (cream) and
+     only dark mode keeps the black. Dark mode is unchanged. */
+  --wheel-stage:             #0a0a0a;
+  /* Radial gradient backing the Subscribe popup's left panel. The popup
+     now follows the page theme, so the DARK value lives here and the cream
+     value is overridden in the [data-theme="light"] block below. Warm
+     near-black tones echo the cream panel's warmth; the gold rings +
+     crosshatch layered on top read stronger against this dark ground. */
+  --subscribe-panel-bg:      radial-gradient(80% 100% at 50% 40%, #221d15 0%, #151210 65%, #0a0908 100%);
+  /* ─── Font roles ───────────────────────────────────────────────
+     The swappable faces behind the font utilities below. Each defaults
+     to the site's built-in next/font face, so an un-themed page is
+     unchanged. The editor's "Fonts" control (Website settings)
+     overrides these tokens on the SITE-WIDE accent carrier — see
+     fontRoleStyle() in lib/fonts.ts and root.render in lib/puck/config
+     — so picking a font re-sets every section AND the header/footer
+     chrome around them without touching the loaded @font-face vars.
+     Published on <main> alone until card 8824, which is why a themed
+     site used to render in three typefaces. Theme-independent (no
+     light override). */
+  --font-role-heading: var(--font-display);
+  /* Heading 2 and 3 are styles of their own (Site styles lists six peers), and
+     their default IS Heading 1's face: unset means "the same as Heading 1", so a
+     site that has never opened those rows keeps one typeface across all three.
+     `fontRoleStyle` overrides these on the carrier when a face is chosen. */
+  --font-role-heading2: var(--font-role-heading);
+  --font-role-heading3: var(--font-role-heading);
+  --font-role-body:    var(--font-body);
+  --font-role-accent:  var(--font-serif);
+  /* The small-caps eyebrow/label face behind the `font-mono` utility below.
+     Defaults to the built-in JetBrains Mono, swappable via the Appearance
+     panel's "Labels" font (fontRoleStyle → --font-role-label). */
+  --font-role-label:   var(--font-mono-loaded);
+  /* The OS-monospace tail that sits BEHIND whichever face the label role names.
+     Split out of --font-mono so a rule can put the LIVE --font-role-label in
+     front of it (see .mono-eyebrow) without restating eight family names.
+     Deliberately contains no var() of its own: a custom property's var() is
+     substituted where the property is DECLARED, so anything referencing
+     --font-role-label from here would freeze to the :root face — which is the
+     whole reason --font-mono cannot be used for this (card 8824). */
+  --font-mono-fallback: ui-monospace, "SF Mono", "Cascadia Mono", "Cascadia Code",
+    "Consolas", "DejaVu Sans Mono", Menlo, monospace;
+}
+
+/* Light theme — applied when <html data-theme="light"> */
+[data-theme="light"] {
+  /* Light-mode surfaces + ink. Only the BASES flip here — the live tokens
+     inherit the `var(<base>)` mapping declared at :root, so every surface has
+     exactly one light value and one dark value, in one place each. */
+  --bg-base: #f5f1e8;
+  --surface-base: #ffffff;
+  --surface-2-base: #ebe6d9;
+  --fg-base: #0a0a0a;
+  --fg-dim-base: #6b6357;
+  --line-base: #d8d2c2;
+  /* Only the BASES flip here — the live tokens inherit the `var(<base>)`
+     mapping declared at :root. This pair is what an UN-themed light page uses,
+     and what a themed one falls back to when its preset carries no light
+     colour. */
+  --accent-base: #8a6a2a;
+  --accent-2-base: #c9a461;
+  /* accentInk() for the light-page accent above — WHITE, not the :root black.
+     #8a6a2a scores 4.18:1 under black and 5.03:1 under white, so the ink flips
+     with the accent even between two shades of the house gold. */
+  --accent-ink-base: #ffffff;
+  /* Same role as the dark-theme --green, but darkened for the cream
+     bg. The dark-theme #7aa672 reads as pastel-bright on cream — this
+     #4a6b42 is the same hue, lower lightness. */
+  --green: #4a6b42;
+  /* Switch OS chrome back to light when the user toggles light mode. */
+  color-scheme: light;
+  /* Light-mode card overrides — preserve the original behaviour the
+     light theme shipped with: card body = --site-surface (the white surface
+     the design used pre-cleanup), hover = --site-surface-2 (the warm tan
+     step). The dark-mode lifted-grey treatment does NOT apply here.
+     The journal panel reverts to --site-surface (its original cream-white
+     fill).
+     The catalog grid container uses --bg in BOTH themes now — the
+     original --site-line fill was painting a visible warm-tan rectangle
+     in the bottom-right empty grid cell on partial last rows (e.g.
+     Monoblock Cast = 7 wheels in 4 cols leaves 1 empty track). With
+     --bg, that empty cell now matches the page background. The
+     side-effect is that the inter-card hairline dividers (line color
+     painting through the 2px gap) are gone in light mode too, but
+     the white card surface (--site-surface) on the cream page bg already
+     gives cards clear visual separation.
+     These five recipes, and the light --tooltip-bg, live in the
+     theme-derived block below for the reason given there. */
+  /* Muted accent for the fitment-diagram outline — slightly deeper than
+     the light-theme --accent (#8a6a2a) so the silhouette still reads
+     against the cream page background. */
+  --accent-dim:          #7a5d23;
+  /* Cream radial gradient backing the Subscribe popup's left panel in
+     light mode — the original design value (dark override lives in :root). */
+  --subscribe-panel-bg: radial-gradient(80% 100% at 50% 40%, #f5edd8 0%, #ebe6d9 65%, #ddd5c0 100%);
+}
+
+/* ─── Theme-derived surface tokens ──────────────────────────────────────
+   The card / panel / section fills, which are all recipes over --site-surface-2,
+   --site-surface, --bg and --fg rather than colours of their own.
+
+   Declared BOTH at the root and on `.sf-theme-surfaces` — the element that
+   carries the merchant's palette (<body> on the live site, the preview wrapper
+   in the editor). This is not a second copy: a custom property has its var()s
+   substituted where it is DECLARED, so a recipe declared only at :root would
+   bake in the built-in surfaces and quietly ignore the theme. Re-declaring the
+   same recipes on the themed element is what lets a merchant's surface colour
+   actually reach the cards, the journal panel and the section bands.
+
+   The dark block must stay ABOVE the light one: `:root` and
+   `[data-theme="light"]` have equal specificity, so source order decides. */
+:root,
+.sf-theme-surfaces {
+  --card-bg:           color-mix(in oklab, var(--site-surface-2) 92%, var(--fg));
+  --card-bg-hover:     color-mix(in oklab, var(--site-surface-2) 82%, var(--fg));
+  --journal-panel-bg:  var(--bg);
+  --catalog-grid-bg:   var(--bg);
+  /* ─── Section-level "highlighted" background ────────────────
+     Used by alternating sections across the contact / about / fitment
+     / PDP pages to break up long dark-on-dark stretches with a tonal
+     band. Resolves to --card-bg (medium-grey ~#2d2d2c) in dark mode.
+     Tweak in this one place to update every section at once. */
+  --section-bg:        var(--card-bg);
+}
+
+[data-theme="light"],
+[data-theme="light"] .sf-theme-surfaces {
+  --card-bg:           var(--site-surface);
+  --card-bg-hover:     var(--site-surface-2);
+  --journal-panel-bg:  var(--site-surface);
+  --catalog-grid-bg:   var(--bg);
+  /* Light mode skips the gold-band — sections fall back to the cream
+     page bg so the dark-mode gold treatment doesn't leak through. */
+  --section-bg:        var(--bg);
+  /* Tooltip surface follows the cream palette in light mode (was the
+     always-dark #3a3a3a, which read as a hard black highlight when it
+     popped over a hovered fitment row). Uses --site-surface so the tooltip
+     contrasts with the row's --site-surface-2 hover state. */
+  --tooltip-bg:        var(--site-surface);
+  /* The wheel image well follows the light theme instead of staying black
+     (66035). --bg, not --site-surface-2: --site-surface-2 is exactly --card-bg-hover
+     in light, so a surface-2 stage would vanish into the card the moment
+     the shopper hovered it. --bg keeps the well readable in BOTH the rest
+     and hover states, and matches what the COMPACT ProductCard variant has
+     always used for its own image well (`bg-bg`), so the two wells finally
+     agree. Lives in the theme-derived block, not the plain light block,
+     because it is a var() recipe: declared only at :root it would bake in
+     the built-in cream and ignore the merchant's palette. */
+  --wheel-stage:       var(--bg);
+}
+
+/* Colour-Theme content text. themeColorStyle() sets --theme-fg on the page
+   CONTENT wrapper (the live <main> in LayoutChrome, the editor preview body in
+   lib/puck/config) — the merchant's per-site text colour. Mapped onto --fg in
+   EVERY mode: a theme is one flat palette (66238), so the preset states one ink
+   and it paints wherever the theme paints.
+
+   It used to map in DARK mode only, with a parallel light-page ink token,
+   because --theme-fg was dark-mode ink and mapping it unconditionally put
+   cream text on the cream light page — the bug where the Product Grid header
+   vanished. A flat preset carries its background as well as its ink, so the two
+   travel together and there is no mode left for them to disagree across.
+
+   The chrome (Header / Footer) sits OUTSIDE this wrapper and keeps the plain
+   light/dark --fg. */
+.sf-themed-content {
+  --fg: var(--theme-fg, var(--fg-base));
+}
+
+/* Colour-Theme SURFACES. themeSurfaceStyle() sets --theme-bg / --theme-surface /
+   --theme-surface-2 / --theme-line / --theme-muted on the element carrying this
+   class: <body> on the live site, the preview wrapper inside the editor.
+
+   Why <body> and not the accent carrier: <body> is the element that PAINTS the
+   page canvas (`bg-bg`), and the carrier is one of its children — custom
+   properties inherit downwards, so a background set on the carrier could never
+   reach the canvas behind the content. The values are server-computed from the
+   site's theme row and identical on both renders, so they add no hydration
+   surface beyond the --sf-header-h length var already set there.
+
+   The mapping reads --theme-*, exactly as --theme-fg does, and applies in
+   EVERY mode. Each fallback is the token's own base, which is why an un-themed
+   site — and any preset stored before these colours existed — resolves to
+   precisely the values it uses today.
+
+   There used to be a SECOND set of names for light pages, and two routes that
+   emitted them (a per-surface light colour, card 22014; a whole-palette opt-in,
+   card 11039). Both existed because a preset's surfaces were dark-mode colours
+   and the light page had to be protected from them — a near-black background
+   under the light theme's near-black ink is a site nobody can read. A theme is
+   one flat palette now (66238): the preset states its ink and its background
+   together, so they are readable or unreadable as a pair and there is no half
+   to protect the other from. One set of names, one rule. */
+.sf-theme-surfaces {
+  --bg: var(--theme-bg, var(--bg-base));
+  --site-surface: var(--theme-surface, var(--surface-base));
+  --site-surface-2: var(--theme-surface-2, var(--surface-2-base));
+  --site-line: var(--theme-line, var(--line-base));
+  --fg-dim: var(--theme-muted, var(--fg-dim-base));
+  /* THE INK TRAVELS WITH THE BACKGROUND, and it has to be on THIS element.
+     Lewis, 2026-09-08: on SHARPEN he scrolled past the hero and the header text
+     was white on a white bar. Measured on the live page, header solid, at rest:
+     a light preset in dark mode gave a bar of #f4f4f6 under ink of #f5f1e8 —
+     dLum 3. The mirror broke too: a dark preset in light mode, #0a0a0a on
+     #2e2e2e, dLum 36.
+
+     Both had one cause. This element is <body>, so everything above maps the
+     merchant's SURFACES onto the whole page, chrome included. The merchant's
+     INK was mapped only on `.sf-themed-content` (<main>) below, and the Header
+     and Footer are that element's SIBLINGS, not its children. So the chrome
+     took its background from the palette and its ink from whichever light/dark
+     mode was on, and the two halves were free to disagree.
+
+     A theme is one flat palette (66238): the preset states its background and
+     its ink together, so they are readable or unreadable AS A PAIR. That is
+     only true while both halves reach the same elements. Declaring it here is
+     what makes it true for the chrome.
+
+     ⚠️ This is the line the old "chrome keeps the plain light/dark --fg" rule
+     used to be, and that rule was SAFE ONLY WHILE THE SURFACES WERE DARK-MODE
+     ONLY. 66238 made them apply in every mode; the protection went with it and
+     nobody noticed, because the comments around here still said "dark mode
+     only" for another year. They are corrected now — do not restore the split.
+     `scripts/test-chrome-theme-pair.ts` §2 fails if one half ever travels
+     without the other.
+
+     `.sf-themed-content` still re-declares --fg on <main>. That is NOT dead:
+     a custom property has its var()s substituted where it is DECLARED, so the
+     value resolved here freezes against THIS element's --theme-fg. Re-declaring
+     it down there is what lets a section pin its own ink and have it resolve
+     against the section's value instead of the page's. */
+  --fg: var(--theme-fg, var(--fg-base));
+}
+/* Colour-Theme ACCENT — the merchant's theme colour.
+   themeAccentStyle() sets --theme-accent (+ its companion shade) on the element
+   carrying this class: the boxless accent carrier in app/layout.tsx on the live
+   site, the preview wrapper inside the editor.
+
+   Why the indirection rather than setting --accent inline: a custom property set
+   in a style attribute beats every stylesheet rule on that same element, so an
+   inline --accent could never be overridden — and the per-SECTION accent
+   override below has to be able to win. The colour arrives as data and lets CSS
+   pick, the same reason --theme-fg and the themed surfaces exist.
+
+   It used to carry a second colour for light pages, with a two-step fallback to
+   the dark one. A theme is one flat palette now (66238): one accent, one rule. */
+.sf-theme-accent {
+  --accent: var(--theme-accent, var(--accent-base));
+  --accent-2: var(--theme-accent-2, var(--accent-2-base));
+  --accent-ink: var(--theme-accent-ink, var(--accent-ink-base));
+  --btn: var(--theme-btn, var(--accent));
+  --btn-2: var(--theme-btn-2, var(--accent-2));
+  --btn-ink: var(--theme-btn-ink, var(--accent-ink));
+}
+
+/* ── A SECTION'S THEME PAINTS IT (card ss.section-theme-picker) ─────────────
+   Lewis, 2026-09-03: he set a Box to Theme 6, a blue preset, and nothing moved.
+   Nothing could — only a preset's ACCENT was ever published per preset, so the
+   wrapper could reach one of six colours, and an empty Box draws nothing that
+   uses an accent. `ThemeColors.background` had always said what this should be:
+   "THE PAGE when the page is on this theme, THE SECTION when a section is."
+
+   IT USED TO SIT BEFORE THE SURFACE CLASSES AND THE POSITION WAS LOAD-BEARING:
+   `.sf-section-surface-*` and `.sf-section-accent` were both (0,1,0), so source
+   order decided --bg between them, and this block after them cost a pinned
+   accent bar its fill (`scripts/test-accent-colour-parity` caught it). The
+   surface classes were deleted on 2026-09-04, so there is nothing left at equal
+   specificity to order against — but do not move this block on the strength of
+   that: a section's theme is what paints everything, and a new class in this
+   family would bring the whole question back.
+
+   The fallbacks live here rather than in the emitted style attribute so the
+   wrapper stays a pure reference with no hex in it (DD's rule, 2026-08-25). */
+/* ⚠️ TWO SELECTORS, ONE COPY OF THE MAPPING — the map/paint split the
+   `[ADD] The Header Can Take Its Own Space, And Pick A Theme` card owed an
+   answer for, and it is a SELECTOR LIST rather than a second block on purpose.
+
+   `.sf-section-accent` both MAPS a preset's tokens onto --bg/--fg/… and PAINTS
+   with them (`background: var(--bg); color: var(--fg)`, at the end of this
+   block). A SECTION wants both. The HEADER wants only the first half: its bar
+   must stay see-through at the top of a `Shared` page, so a rule that painted
+   unconditionally would fill it in. Copying the nine references into a second
+   block would be the duplication DD's rule and card 66152 both exist to stop —
+   a copy is cheap the day it is made and permanent afterwards.
+
+   So the mapping is declared ONCE, for both, and only the paint is
+   `.sf-section-accent`'s alone below. `scripts/test-header-theme.ts` §3 fails if
+   the header class ever picks up a `background` or `color` here. */
+.sf-section-accent,
+.sf-header-theme {
+  /* ⛔ THE SURFACES BELOW ARE CARD ss.section-theme-picker, AND WITHOUT THEM THE
+     CONTROL DOES ALMOST NOTHING. Lewis, 2026-09-03: he set a Box to Theme 6, a
+     blue preset, and nothing moved. Only the accent triple above existed, so a
+     section could reach one of a preset's six colours — and an empty Box uses no
+     accent at all, which is why every theme looked identical on it.
+
+     `ThemeColors.background` has always said what this should be: "THE PAGE when
+     the page is on this theme, THE SECTION when a section is." This is the
+     section half, finally wired.
+
+     THE FALLBACKS ARE IN THE REFERENCE, NOT HERE — `sectionAccentVars` builds
+     each `--sf-sec-*` as `var(--theme-preset-<i>-x, var(--theme-x, <base>))`, so
+     a stale preset index lands on the page's own token rather than on nothing. A
+     bare `var(--sf-sec-bg)` here would be the cycle-free half of that chain; the
+     second value is kept only for a wrapper written before this card. */
+  --bg: var(--sf-sec-bg, var(--theme-bg, #0a0a0a));
+  --fg: var(--sf-sec-fg, var(--theme-fg, #f5f1e8));
+  --site-surface: var(--sf-sec-surface, var(--theme-surface, #131313));
+  --site-surface-2: var(--sf-sec-surface-2, var(--theme-surface-2, #1c1c1c));
+  --site-line: var(--sf-sec-line, var(--theme-line, #2a2a2a));
+  --fg-dim: var(--sf-sec-muted, var(--theme-muted, #9a9388));
+  /* The derived fills that read --bg / --site-surface-2, restated because a custom
+     property resolves where it is DECLARED: the :root copies froze against the
+     PAGE's tokens and would keep the page's card colour inside a themed band.
+     Same rule, same reason, as --btn above. */
+  --card-bg: color-mix(in oklab, var(--site-surface-2) 92%, var(--fg));
+  --card-bg-hover: color-mix(in oklab, var(--site-surface-2) 82%, var(--fg));
+  --journal-panel-bg: var(--bg);
+  --catalog-grid-bg: var(--bg);
+  --section-bg: var(--card-bg);
+}
+/* THE PAINT HALF, and a SECTION's alone. The header takes the mapping above and
+   paints from its own branches instead: `<Header/>` sets background and colour
+   inline once the bar is solid, and the `data-top-space="own"` rule further up
+   paints a page that takes its own space. Both read the very --bg / --fg the
+   list above just re-pointed, which is how picking a theme moves the bar without
+   this declaration ever reaching it. */
+.sf-section-accent {
+  background: var(--bg);
+  color: var(--fg);
+}
+
+/* ⛔ THERE ARE NO `.sf-section-surface-*` CLASSES ANY MORE, AND THAT IS A
+   DECISION — do not write a new one here.
+   Card 22018 gave a SECTION a pinned dark / light / accent surface;
+   ss.section-theme-picker took that away on 2026-09-03 (a section is on a THEME
+   and nothing else), leaving the HEADER as the only element that wore one; and
+   the header's own Background control went on 2026-09-04 (Lewis: the header
+   follows the theme). With no element left to wear them, the three surface
+   blocks, their three `.sf-section-accent` pairings and the four
+   `--accent-*-base-on-{dark,light}` tokens they alone read were removed.
+   NOTHING ON ANY SITE MOVED: all 9 stored header `surface` values were empty.
+   Bringing one back means giving some element two colour rules again, with no
+   panel able to say which of them paints. */
+
+
+/* Per-SECTION accent. The wrapper stores only a preset INDEX and emits
+   --sf-sec-accent* as `var(--theme-preset-<i>-accent…)` REFERENCES into the
+   per-preset accents the carrier publishes (themePresetAccentVars in
+   lib/theme.ts) — no copied colour anywhere, so editing the palette re-paints
+   every overridden section. A stale index resolves nothing and every chain
+   below falls back to the page accent: degraded, readable, never garbage.
+
+   Mode: the section follows the PAGE's mode, always. There used to be a second
+   case — a PINNED surface picked the accent's mode itself, through three
+   `.sf-section-surface-*.sf-section-accent` rules sitting last at (0,2,0). Those
+   went with the surface classes on 2026-09-04; nothing pins a mode now, so this
+   one rule is the whole story. */
+/* The header joins this one too: a themed bar's buttons and links must come out
+   of the SAME preset as its background, or the bar is half on one theme. Pure
+   mapping, no paint, so there is nothing here to keep off the header. */
+.sf-section-accent,
+.sf-header-theme {
+  --accent: var(--sf-sec-accent, var(--accent-base));
+  --accent-2: var(--sf-sec-accent-2, var(--accent-2-base));
+  --accent-ink: var(--sf-sec-accent-ink, var(--accent-ink-base));
+  --btn: var(--theme-btn, var(--accent));
+  --btn-2: var(--theme-btn-2, var(--accent-2));
+  --btn-ink: var(--theme-btn-ink, var(--accent-ink));
+}
+
+
+/* ─── Corners ──────────────────────────────────────────────────────────
+   The Appearance panel's site-wide "Corners" control drives the site's radius
+   scale (cornerStyleTokens in lib/theme.ts sets --site-radius-* on the theme
+   carrier), which reaches every `rounded-sm|md|lg|xl|2xl` on the site because
+   the site's `inline` theme block (with the named colours, further down)
+   compiles those to `border-radius: var(--site-radius-<size>)`.
+
+   ⚠️ NOT TAILWIND'S OWN `--radius-*`. Until 2026-10-11 the setting overrode
+   Tailwind's scale directly, and efficient-shell's UI kit reads that same scale
+   for its chrome — so a site at 0 squared the kit's dialogs wherever the two
+   shared a page (see the note on the design tokens above). `inline` makes each
+   utility name the site's property itself, so nothing the site draws reads
+   Tailwind's `--radius-*` any more. The values on :root are Tailwind 4.3's own
+   scale, which is what the utilities drew before; the bare `rounded` keeps its
+   quarter-rem the same way.
+
+   The bare `rounded` utility does NOT follow the scale: it compiles to a literal
+   `0.25rem`, so it would sit out the setting and leave a site with square cards
+   and rounded inputs. Re-point it at a variable whose default is that same
+   0.25rem — the utility keeps its exact value until the merchant chooses
+   otherwise.
+
+   `rounded-full` is deliberately NOT re-pointed. It compiles to
+   `calc(infinity * 1px)` and is what makes a thing CIRCULAR — toggle knobs,
+   status dots, finish swatches, the wheel placeholder's rings. A circle is a
+   shape, not a corner, and squaring those would be a regression with no upside;
+   the design that motivated this setting has no rounded panels but still has
+   round dots. */
+:root {
+  --site-radius: 0.25rem;
+  --site-radius-xs: 0.125rem;
+  --site-radius-sm: 0.25rem;
+  --site-radius-md: 0.375rem;
+  --site-radius-lg: 0.5rem;
+  --site-radius-xl: 0.75rem;
+  --site-radius-2xl: 1rem;
+  --site-radius-3xl: 1.5rem;
+  --site-radius-4xl: 2rem;
+}
+@layer utilities {
+  .rounded {
+    border-radius: var(--site-radius);
+  }
+}
+
+/* The BUTTON's corners, and the one place the `Corners` setting can reach them.
+   Card `[FIX] The Corners Setting Says Buttons And Skips Them`.
+
+   The same hole as `.sf-card` further down, found from the other end. `Corners`
+   reaches an element by re-pointing the `--site-radius-*` scale above, which only
+   works if that element writes a `rounded-*` utility — and `components/Btn.tsx`,
+   the shared button every section draws, writes NONE. So the row's hint said
+   "Applies to panels, cards, inputs and buttons" while a button was square at 0,
+   at 9 and at 40. `--sf-button-radius` is the property `cornerRadiusTokens`
+   publishes for buttons, at half the card's ratio — the amount the inputs and
+   panels beside it already take — and it is UNSET at the identity, so the `0`
+   here is exactly what a button draws today: square, on every site that never
+   opened the panel. No migration, and the hint becomes true.
+
+   ⚠️ IT LIVES HERE, WITH `Corners`, AND NOT IN THE CARD-LOOK BLOCK BELOW. It was
+   written there first and `scripts/test-card-style-settings.tsx` §1a caught it:
+   every rule between those two markers must be scoped to `.sf-card` /
+   `.sf-card-grid`, because a card-look rule that is not would reach a colour
+   swatch or a toggle knob (Lewis, 2026-09-01). This is not a card-look rule —
+   it is a corner rule — and the guard reading its neighbourhood by position is
+   the reason position matters.
+
+   ⚠️ NO `overflow: clip` HERE, unlike `.sf-card`. A button's only children are
+   its label and its arrow glyph, and the arrow TRANSLATES 3px right on hover —
+   clipping the box would shave that arrow at the moment it moves. Nothing in a
+   button bleeds past its border, so there is nothing to clip. */
+.sf-button { border-radius: var(--sf-button-radius, 0); }
+
+/* ─── Stacking layers ──────────────────────────────────────────────────
+   The site's layers above the page, by NAME (SSOT-12), in steps of 100 (the
+   owner's layer rule, 2026-10-12). Markup takes a layer as `z-(--sf-layer-…)`.
+
+   `--sf-layer-lightbox` is every lightbox (components/Lightbox.tsx). Its value
+   is the `z-[100]` the three lightboxes wrote by hand, so nothing re-orders
+   against them. It is above the fixed header (`z-50`), the drawers (60 / 61)
+   and the dialogs (90) — but only because the lightbox is portalled out of its
+   section: a layer orders things inside ONE stacking context, and the owner
+   photos' dialog, drawn inside a `relative z-[2]` section, sat under the header
+   at any number (hartesmetal.com, 2026-10-15).
+
+   ⏳ The other site layers are still numbers in their components (the header
+   and its menu 40 / 50, drawers and menus 60 / 61, dialogs 90, the select list
+   200). They move here, onto steps of 100, as their own change. */
+:root {
+  --sf-layer-lightbox: 100;
+}
+
+/* ─── Floating launchers step aside for an overlay ─────────────────────
+   A floating launcher (`data-sf-floating`: the chat bubble and its panel, the
+   classic one and the assistant) is fixed to the bottom-right corner above
+   the page. A blocking overlay — the phone menu, the cart drawer, search, the
+   footer menu, a popup — marks <html> `data-sf-overlay` while it is open
+   (components/useModalDismiss.ts), and under that mark the launcher is hidden:
+   in the phone menu the bubble sat on the Region button and on "Your account"
+   (inovit.com.au at 390, 2026-10-17, card [FIX] Region Picker On Phone).
+   A rule rather than a layer number: it holds whatever the overlay's own
+   z-index, and the chat comes back, as it was, when the overlay closes.
+   Guard: scripts/test-phone-menu-region-picker.tsx §3-§4. */
+:root[data-sf-overlay] [data-sf-floating] { visibility: hidden; }
+
+/* ─── Card look (card 66332) ───────────────────────────────────────────
+   Site styles ▸ Basics ▸ Card shadow / Shadow colour / Card gap / Hover —
+   three site-level settings beside `Corners`, for the reason Corners is one
+   decision: a card appears in a product grid and a filter cell,
+   and one set per section is one idea with seven answers.
+
+   ⚠️ EVERY RULE HERE IS SCOPED TO `.sf-card` OR `.sf-card-grid`, AND THAT IS
+   THE EXEMPTION. Lewis, 2026-09-01: corners, shadow and hover must not leak
+   onto swatches, switches and status dots. `Corners` exempts them structurally
+   — `rounded-full` compiles to a literal that reads no token, so the radius
+   override cannot reach it (see the Corners block above) — and this is that
+   same rule in the only vocabulary a shadow can use: a thing that does not
+   carry the class is out of reach by construction, not by a list of exceptions
+   somebody has to maintain. `scripts/test-card-style-settings.tsx` §1 holds
+   both halves — the rules stay scoped, and no round control wears the class.
+
+   ⚠️ EVERY `:hover` CARRIES THE SAME `:active`. Lewis, 2026-09-01: a phone has
+   no hover, so the hover effect IS the press feedback. A rule with no `:active`
+   is a setting a shopper on a phone can never see, and it looks correct on
+   every desktop it is tested on. §2 keeps it that way. (The selector lists are
+   written on ONE line each because that guard reads a rule's whole selector;
+   splitting them over two lines would let a `:hover` sneak past it.)
+
+   ⚠️ NO SELECTOR NAMES A PAGE, A SECTION OR A FILTER. A filter cell is a card
+   and takes these values automatically — it gets no settings of its own
+   (settled). That is only true while these rules key off the site carrier and
+   the class alone; a page or filter-bar ancestor here would produce a card that
+   follows the site in one place and not in another. §3.
+
+   UNLAYERED, like the heading-compression rules below: a card writes its hover
+   as a Tailwind `hover:bg-[…]` utility inside `@layer utilities`, and a custom
+   property cannot override a declaration that does not read it. An unlayered
+   rule can.
+
+   An untouched site carries NO `data-sf-card-*` attribute (the identity value
+   of each setting emits none — cardShadowAttr / cardGapAttr / hoverEffectAttr
+   in lib/theme.ts), so not one rule below can match and the site renders
+   byte-identically. */
+
+/* The shadow colour reaches the shadows through `--sf-shadow-color`, whose
+   BUILT-IN VALUE LIVES HERE rather than in the carrier: a site that never
+   touched the colour then publishes no declaration at all, the way `small`
+   corners publish none. Lewis's default, 2026-09-01. */
+[data-sf-card-shadow="soft"] { --sf-card-shadow: 0 1px 2px color-mix(in srgb, var(--sf-shadow-color, #141416) 7%, transparent), 0 4px 12px -4px color-mix(in srgb, var(--sf-shadow-color, #141416) 10%, transparent); }
+[data-sf-card-shadow="lifted"] { --sf-card-shadow: 0 2px 4px color-mix(in srgb, var(--sf-shadow-color, #141416) 6%, transparent), 0 14px 30px -10px color-mix(in srgb, var(--sf-shadow-color, #141416) 22%, transparent); }
+
+/* The raised state a `lift` hover moves to, and the distance it moves. Both
+   read the merchant's shadow colour for the reason the resting shadow does —
+   a black lift on a near-black page is a setting that visibly does nothing. */
+[data-sf-card-hover="lift"] { --sf-card-shadow-hover: 0 6px 10px color-mix(in srgb, var(--sf-shadow-color, #141416) 8%, transparent), 0 20px 40px -14px color-mix(in srgb, var(--sf-shadow-color, #141416) 26%, transparent); --sf-card-lift: translateY(-3px); }
+
+/* The gutter between cards. A LENGTH rather than an attribute, because the
+   wheels listing SUBTRACTS its gutter when working out how wide one of N
+   columns would be (lib/wheels/plp-grid) — a visual gap and an arithmetic gap
+   that were two values would drift, which is the one thing that file exists to
+   prevent. Root-relative, like the 1rem it replaces: the gutter has always
+   scaled with the visitor's own browser text size, and a px figure here would
+   shrink it for anyone who raised theirs. */
+[data-sf-card-gap="tight"] { --sf-card-gap: 0.5rem; }
+[data-sf-card-gap="roomy"] { --sf-card-gap: 1.625rem; }
+
+/* The resting card, and the state it moves to. Both read a custom property that
+   is UNSET on an untouched site, so both fall back to what a card draws today —
+   no shadow, and no transform. */
+/* The card's CORNERS, and the one place the `Corners` setting can reach them.
+   A card writes no `rounded-*` utility — not one of the four card components
+   does — so overriding the `--site-radius-*` scale moved buttons and panels
+   and left every card square, whatever the panel said. `--sf-card-radius` is
+   the property `cornerStyleTokens` publishes for cards alone, and it is UNSET
+   at the identity, so the `0` here is what an untouched site keeps: square,
+   which is what a card draws today. No migration, and `Round` works.
+
+   `overflow: clip` rather than `hidden`: a rounded card whose photo runs to its
+   own edge (Latest Posts, the journal index) would otherwise wear a square
+   image over a round corner. `clip` does that without making a scroll
+   container, so the catalog card keeps its `sticky` behaviour. Nothing bleeds
+   outside a card today — no negative offset in any of the four — so at the
+   identity this clips nothing and the site renders byte-identically. */
+/* ⚠️ THE RADIUS IS A CHAIN, READ CARD FIRST (`[ADD] A Card Sets Its Own
+   Corners`): this card's own answer, then the section's, then the site's, then
+   square. `--sf-card-box-radius` is published ONLY by a card that has been given
+   a number of its own, on a `display: contents` carrier the injection pass in
+   lib/puck/config.tsx wraps it in — so a card nobody has touched declares
+   nothing, falls straight through to `--sf-card-radius` and renders exactly as
+   it did before this rule grew a level. lib/content/card-corners.ts says why the
+   card tier needs a name of its own rather than overriding the inherited token.
+   The final `0` is unchanged and is still today's corner for a site that has set
+   none. */
+.sf-card { box-shadow: var(--sf-card-shadow, none); border-radius: var(--sf-card-box-radius, var(--sf-card-radius, 0)); overflow: clip; }
+
+/* The carrier that publishes it. `display: contents` generates no box at all, so
+   a card inside a grid stays the grid item and the markup gains nothing that can
+   be laid out — the same reason `.sf-section-corners` is `display: contents` one
+   tier up. Declared here rather than left to the inline style alone so no class
+   is rendered that the stylesheet never styles. */
+.sf-card-corners { display: contents; }
+
+/* The PICTURE inside a card, and the one place a section's `Card image` setting
+   can reach it. The card's own corner (`--sf-card-radius`, above) rounds the
+   card's OUTER edge and, through `overflow: clip`, any picture that runs all the
+   way to that edge — Latest Posts and the journal index both do. It cannot reach
+   an INSET picture, and that is the card Lewis actually saw on 2026-09-04: every
+   wheel card pads its image well by 5–30px, so the photo sits inside the card
+   and stays square whatever `Corners` says.
+
+   Hence a second property, NOT a second setting: `--sf-card-image-radius` is
+   published per SECTION by `cardImageShapeTokens` (lib/content/card-image-shape.ts)
+   and inherits down to the pictures in that section alone. Site-wide was the
+   first proposal and Lewis rejected it — 「有些是要分开的, 有些是要文字在图片上的」
+   — because one value cannot let the Collections card keep its overlay caption
+   while a product grid rounds its photos.
+
+   `0` is the fallback, so a section that has chosen nothing declares nothing and
+   the picture keeps the square cut it draws today. No migration, and the whole
+   setting is provably inert until used.
+
+   `overflow: clip` for the same reason `.sf-card` uses it rather than `hidden`:
+   these wells hold absolutely-positioned siblings (the badge, the gradient, the
+   hover crossfade) and `clip` rounds them off without making a scroll container,
+   so the catalog card keeps its `sticky` behaviour. */
+.sf-card-image { border-radius: var(--sf-card-image-radius, 0); overflow: clip; }
+.sf-card:hover, .sf-card:active { box-shadow: var(--sf-card-shadow-hover, var(--sf-card-shadow, none)); transform: var(--sf-card-lift, none); }
+
+/* Only a site that has chosen gets the extra transitions. `transition-property`
+   ALONE — the duration and the easing stay with the card's own
+   `transition-colors duration-200|300` utility, so a card keeps the timing it
+   has always had and only gains two more properties to animate. */
+[data-sf-card-shadow] .sf-card, [data-sf-card-hover] .sf-card { transition-property: color, background-color, border-color, box-shadow, transform; }
+
+/* `None` and `Lift` must also STOP the fill lightening every card already does
+   — a row that says the hover is None while the card still changes colour is a
+   row that lies. `Highlight` is the name of that existing effect, so it emits
+   no attribute and matches nothing here. `var(--card-bg)` resolves on the CARD,
+   which is what lets a card inside a themed section band keep that band's own
+   surface instead of the page's. */
+/* ⚠️ THIS ONE RULE IS KEYED ON `.sf-card-fill`, NOT `.sf-card`, AND THAT IS WHAT
+   LETS EVERY SECTION BE A CARD. Lewis, 2026-09-03: "所有的 section 也都可以加入
+   corner. 但是默认是直角的." — every section takes Corners, and square stays the
+   default.
+
+   The blocker was this rule. It cancels a card's own fill-lightening by setting
+   the card back to `var(--card-bg)`, which is right for a card that lightens and
+   WRONG for one that does not: a section drawing `bg-surface` would jump to a
+   different colour the moment a merchant chose "Hover: None", the one option
+   whose whole job is to hold the colour still. Measured before this change: of
+   the 36 unmarked card sections, exactly ZERO lightened their own card fill —
+   every `hover:bg-*` in them was on a BUTTON inside the section.
+
+   So the vocabulary splits, one grammar with one modifier rather than two
+   grammars:
+     `.sf-card`       a card SURFACE — corners, shadow, lift, gap. Colour-free,
+                      so wearing it is safe for any section and is one line.
+     `.sf-card-fill`  …and this card lightens its fill on hover, so the None and
+                      Lift options have something to cancel. Worn only by the
+                      cards that actually do it.
+   `scripts/test-card-style-settings.tsx` §8 holds both halves. */
+[data-sf-card-hover="none"] .sf-card-fill:hover, [data-sf-card-hover="none"] .sf-card-fill:active, [data-sf-card-hover="lift"] .sf-card-fill:hover, [data-sf-card-hover="lift"] .sf-card-fill:active { background-color: var(--card-bg); }
+
+/* ⚠️ THE RULE THAT USED TO LIVE HERE IS GONE — [ADD] Gap Inherits From Site.
+   It read `[data-sf-card-gap] .sf-card-grid { gap: var(--sf-card-gap); }`, and it
+   is removed rather than left beside the new one because it would WIN: its
+   specificity is (0,2,0) against `.sf-gap-zone`'s (0,1,0), so on precisely the
+   sites that stored `tight` or `roomy` it would have pinned the old gutter and
+   the site's new Block gap would have done nothing — on those sites only, which
+   is the hardest kind of bug to see.
+
+   The two words themselves are NOT retired: `--sf-card-gap` is still defined
+   above, and every card grid now reads it as the MIDDLE rung of
+   `var(--sf-block-gap, var(--sf-card-gap, <own built-in>))`. So a site that
+   stored one keeps drawing it, and keeps drawing it ONLY on the card grids it
+   ever governed — see cardGridGapProps for why that middle rung has to exist. */
+
+/* The brand plate is not a card — it is the strip laid over the lower quarter of
+   one — but it follows the card's fill, so `None` and `Lift` have to stop its
+   lightening too or the card stops changing colour and the plate inside it does
+   not. Same pair of states, same reason. */
+[data-sf-card-hover="none"] .sf-card:hover .sf-card-plate, [data-sf-card-hover="none"] .sf-card:active .sf-card-plate, [data-sf-card-hover="lift"] .sf-card:hover .sf-card-plate, [data-sf-card-hover="lift"] .sf-card:active .sf-card-plate { background-color: var(--card-bg); }
+
+/* ─── End card look (card 66332) ─────────────────────────────────────── */
+
+/* ─── Heading compression ──────────────────────────────────────────────
+   The Appearance panel's "Headings" compression rung, applied to real headings
+   (h1–h4) under the theme carrier. Delivered as a data attribute rather than a
+   custom property because every heading in the codebase writes its own
+   `leading-*` / `tracking-*` utility, and a variable cannot override a
+   declaration that does not read it. These rules are UNLAYERED, so they win
+   over Tailwind's `@layer utilities` regardless of specificity.
+
+   `normal` emits no attribute at all, so neither rule below can match and the
+   default is byte-identical to today — the reason this is an attribute the
+   carrier omits rather than one it always sets.
+
+   Metrics are the display-type values from the Apex design system: closed
+   leading with slightly negative tracking.
+
+   ⚠️ THE TOP RUNG USED TO ADD `text-transform: uppercase`, AND THAT WAS THE BUG
+   CARD 66162 REMOVED. The Appearance panel also has a `Capitals` setting, which
+   emits `--sf-heading-case` and is read by a Tailwind arbitrary utility inside
+   `@layer utilities`. Unlayered beats layered whatever the specificity, so these
+   rules won every time: a merchant who chose "As typed" was shown their choice
+   selected and served capitals anyway. Measured on production before the fix
+   (inovit.com.au/wheels, the real `div.sf-theme-accent` carrier, a real <h2>):
+
+     Spacing=Normal     + Capitals=As typed -> text-transform: none        obeyed
+     Spacing=Compressed + Capitals=As typed -> text-transform: uppercase   IGNORED
+     Spacing=Tight      + Capitals=As typed -> text-transform: none        obeyed
+
+   Capitalisation is not a spacing metric. `Capitals` is now the only thing on
+   the platform that writes a heading's case, which is what lets these two rungs
+   be split into a line gap and a text gap without either of them lying. DO NOT
+   ADD IT BACK: scripts/test-text-styles-panel.tsx §2 reads this very block and
+   fails on any `text-transform` in it, and it fails on a case in
+   lib/theme's `compressionMetrics` too, because the panel can tell the same lie
+   from the other end. A design that wants capitals has `Capitals: As designed`,
+   which is the default and is what every site is already on. */
+[data-sf-headings="tight"] :is(h1, h2, h3, h4) {
+  line-height: 0.95;
+  letter-spacing: -0.01em;
+}
+[data-sf-headings="compressed"] :is(h1, h2, h3, h4) {
+  line-height: 0.86;
+  letter-spacing: -0.01em;
+}
+
+/* A part's own PARAGRAPH spacing on the editor canvas (plan S2). The cell
+   writes `--sf-part-para` on the part and flags it with `data-sf-part-para`; an
+   inline style cannot reach the part's line breaks, so these rules do. The gap
+   goes after each line except the last, list rows too; a blank line keeps its
+   height. The published page gets the same three rules from `paragraphRules`
+   in lib/puck/part-styles.ts — keep the two the same. A part without the flag
+   is untouched. */
+[data-sf-part-para] br:not(br + br) {
+  display: block;
+  content: "";
+  margin-top: var(--sf-part-para);
+}
+[data-sf-part-para] :is([data-sf-bullet], [data-sf-number]):not(:first-child) {
+  margin-top: var(--sf-part-para);
+}
+[data-sf-part-para] :is([data-sf-bullet], [data-sf-number]):not(:last-child) {
+  margin-bottom: var(--sf-part-para);
+}
+
+/* ─── Header at-top (transparent) text colour ─────────────────────────
+   Before it goes solid on scroll, the fixed site Header paints its nav in
+   --sf-header-overlay-fg. Default = the PALETTE's ink, in both modes.
+
+   ⚠️ IT USED TO BE THE MODE'S INK — cream `--overlay-fg` in dark, `--fg` in
+   light — and that split is the one the solid bar lost on 2026-09-08 (see
+   `.sf-theme-surfaces`). A theme is one flat palette (66238): its background
+   reaches the page in every mode, so a light palette in dark mode put cream
+   nav on a white page. Found 2026-10-07 on INOVIT /journal, and on SHARPEN's
+   404, where Next's error shell never runs the theme boot script, so even a
+   light-mode site has no `data-theme="light"` there. A page with no marker
+   leaves the body canvas under the bar, and the palette's ink is what reads on
+   it. `--fg` on <body> IS that ink; an unthemed site resolves it to the mode
+   base exactly as before (dark `--fg-base` is the same #f5f1e8 as
+   `--overlay-fg`). `scripts/test-chrome-theme-pair.ts` §6 holds it.
+
+   AUTO. A page publishes the ink its FIRST section DECLARES it needs, as
+   `data-lead-ink` on the page body (lib/puck/header-ink, read by both
+   StorefrontPageView and the editor preview). Cream over a band the section
+   itself paints cream on — a `dark` or `accent` surface, or a full-bleed hero
+   with its own dark legibility gradient — and nothing at all otherwise, so a
+   light content page keeps its near-black ink and cream-on-cream stays
+   impossible. A DECLARATION, never a sampled colour: see the module.
+
+   This replaced a hand-maintained list of route names plus a "does this page
+   open with a hero?" marker. Neither asked whether the thing under the header
+   was dark, so a dark section that was not a hero got ink-on-ink and no control
+   could fix it (card 66216).
+
+   `:has()` lets the header — a body child rendered ABOVE the page content —
+   react to a marker set DEEP inside the page body, so it stays pure CSS:
+   resolved at first paint, re-resolved on client navigation, with no boot
+   script and no React state driving the colour.
+
+   EVERY INK HAS ITS GROUND. Each rule that sets --sf-header-overlay-fg also
+   sets --sf-header-overlay-ground: the colour that ink was picked to sit ON
+   (cream ink -> near-black ground, near-black ink -> cream, --fg -> --bg). The
+   see-through bar has no background of its own, so this pair is the only
+   place its "background colour" exists. The cart badge draws its number in
+   it (components/HeaderTools, via --sf-header-ground, which Header and
+   BoxHeaderBar set inline). Add an ink rule without its ground and
+   scripts/test-cart-count-badge.tsx fails. */
+.sf-site-header {
+  --sf-header-overlay-fg: var(--fg);
+  --sf-header-overlay-ground: var(--bg);
+}
+body:has([data-lead-ink="light"]) .sf-site-header {
+  --sf-header-overlay-fg: var(--overlay-fg);
+  --sf-header-overlay-ground: var(--overlay-fg-on-light);
+}
+body:has([data-lead-ink="dark"]) .sf-site-header {
+  --sf-header-overlay-fg: var(--overlay-fg-on-light);
+  --sf-header-overlay-ground: var(--overlay-fg);
+}
+/* THE MERCHANT'S OVERRIDE — Header → Look → "Text colour at the top". Auto
+   reads 99% of pages; this is the merchant taking over on the one it reads
+   wrong, so it has to beat Auto in BOTH directions, including the direction
+   Auto is confident about.
+
+   The leading `body ` is there for SPECIFICITY alone, and it is load-bearing:
+   the Auto rules above score (0,2,1) — one attribute inside :has(), one class,
+   one type — so a bare `.sf-site-header[data-header-ink]` at (0,2,0) would lose
+   to them and the control would silently do nothing.
+   `scripts/test-header-lead-ink.ts` §3b computes both and pins the winner. */
+body .sf-site-header[data-header-ink="light"] {
+  --sf-header-overlay-fg: var(--overlay-fg);
+  --sf-header-overlay-ground: var(--overlay-fg-on-light);
+}
+body .sf-site-header[data-header-ink="dark"] {
+  --sf-header-overlay-fg: var(--overlay-fg-on-light);
+  --sf-header-overlay-ground: var(--overlay-fg);
+}
+
+/* ─── THE BOX HEADER ON A PHONE ───────────────────────────────────────
+   Blueprint step H.5, as the approved Box header mockup draws it. Under 801px
+   the row holding the site header's one-row Menu shows the logo at the left
+   and the rest together at the right, the menu button last; Search and the
+   region picker move into the menu's panel (components/PhoneMenuTools).
+
+   Only a row in the site header (`[data-section-group="header"]`) that holds a
+   one-row Menu (`[data-menu-row]`, components/FooterMenu). A page's Boxes, and
+   a header without such a Menu, keep their own `Columns on phone`.
+
+   ⚠️ UNLAYERED ON PURPOSE. A Box's phone cells are Tailwind utilities
+   (lib/content/box-layout `PHONE_ROW_CLASS`) in `@layer utilities`, and
+   unlayered CSS beats layered whatever the specificity. */
+@media (max-width: 800px) {
+  /* The row, and the rows inside it: one line, each block its own width. A
+     block is the row's own child on the site and sits inside the editor's
+     frame (`[data-puck-component]`) in the editor, so each rule reads both. */
+  [data-section-group="header"] .flex-row:has([data-menu-row]),
+  [data-section-group="header"] .flex-row:has([data-menu-row]) .flex-row {
+    flex-direction: row;
+    flex-wrap: nowrap;
+  }
+  [data-section-group="header"] .flex-row:has([data-menu-row]) > *,
+  [data-section-group="header"] .flex-row:has([data-menu-row]) .flex-row > * {
+    flex: 0 0 auto;
+    /* A Box's frame is `w-full`; here it is as wide as what it holds. */
+    width: auto;
+    min-width: 0;
+  }
+  /* The menu button last, beside the cart. */
+  [data-section-group="header"] .flex-row:has([data-menu-row]) > :is([data-menu-row], :has([data-menu-row])) {
+    order: 99;
+  }
+  /* The first block (the logo) takes the room left over, and is the query
+     container a long store name shrinks to fit: components/Logo
+     `fitToContainer`, which the Logo block sets in the site header. */
+  [data-section-group="header"] .flex-row:has([data-menu-row]) > :first-child:not([data-menu-row], :has([data-menu-row])) {
+    flex: 1 1 0;
+    container-type: inline-size;
+    overflow-x: clip;
+  }
+  /* Search and the region picker are in the menu's panel instead: the block,
+     and in the editor the frame around it, so no gap is left. Only the frame
+     whose block IS the tool, never a Box frame that merely holds one. */
+  [data-section-group="header"]:has([data-menu-row]) [data-phone-menu-tool],
+  [data-section-group="header"]:has([data-menu-row]) [data-puck-component]:has(> * > [data-phone-menu-tool]) {
+    display: none;
+  }
+}
+
+/* ─── THE BOX HEADER AT MID WIDTHS ────────────────────────────────────
+   801px to 1500px: TWO ROWS, as the old header draws them from 801px
+   (components/Header, its medium top bar). The logo and the tools on the top
+   line, the one-row Menu's links on a second line under a hairline. Ruled by
+   Victor Mau 2026-10-01: the approved mockup draws only 1440px (one row) and
+   390px (the phone bar above), and a row that ran out of room folded the
+   links onto two lines inside it. Same scope as the phone rules: only the
+   site header's row that holds a one-row Menu. Unlayered for the same reason.
+   The gap and the hairline are today's header's own: `gap-3`, `border-line/60`
+   and `pt-2.5`.
+   NOT for a group on `Same row` (the Site Header's Menu row, the old header's
+   `menu_row: inline`, lib/content/header-bar): its links stay on the logo's
+   row at every width above a phone.
+   UP TO 1500px, NOT 1100px: Victor's rule ended at 1100px (the approved
+   mockup is one row at 1440px). Lewis, 2026-10-12, card [ADD] Every Old
+   Header Setting To The Box Header: `Own row` stacks exactly as the old
+   header did, to 1500px, so a switched site looks the same at every width. */
+@media (min-width: 801px) and (max-width: 1500px) {
+  [data-section-group="header"]:not([data-header-menu-row="inline"]) .flex-row:has([data-menu-row]) {
+    flex-wrap: wrap;
+    row-gap: 12px;
+  }
+  /* The links: their own line, last, under the hairline. */
+  [data-section-group="header"]:not([data-header-menu-row="inline"]) .flex-row:has([data-menu-row]) > :is([data-menu-row], :has([data-menu-row])) {
+    order: 99;
+    flex: 1 0 100%;
+    border-top: 1px solid color-mix(in oklab, var(--site-line) 60%, transparent);
+    padding-top: 10px;
+  }
+  /* The logo takes the top line's room, so the tools sit at its end. */
+  [data-section-group="header"]:not([data-header-menu-row="inline"]) .flex-row:has([data-menu-row]) > :first-child:not([data-menu-row], :has([data-menu-row])) {
+    flex: 1 1 0;
+    container-type: inline-size;
+    overflow-x: clip;
+  }
+}
+
+/* ─── THE BOX HEADER'S LETTERS ────────────────────────────────────────
+   The Site Header's `Letters` (the old header's `nav_text_case`,
+   lib/content/header-bar): ONE value for the menu's links AND the tool words,
+   which sit in one bar — Lewis asked for them controlled together
+   (2026-09-03). Uppercase, the default, is the menu's own capitals and 0.18em
+   tracking, worn by the tool words too, so a bar is never half capitalised.
+   Capitalised takes both off and lets the words read as they are written —
+   a removed transform, never `capitalize`, which would rewrite a merchant's
+   `FusionForge`. The phone panel's links are inside the menu, so they follow.
+   Unlayered: the menu's capitals are Tailwind utilities in `@layer
+   utilities`, and unlayered CSS beats layered whatever the specificity. */
+[data-section-group="header"] .mono-eyebrow-ctl {
+  /* The menu's own type (components/FooterMenu, its row: `font-mono`
+     `text-[13px]`), so a word tool reads as part of the same strip, as the
+     old bar's tools did. An icon tool draws no text, so nothing moves. */
+  font-family: var(--font-role-label), var(--font-mono-fallback);
+  font-size: 13px;
+  text-transform: uppercase;
+  letter-spacing: 0.18em;
+}
+[data-section-group="header"][data-header-nav-case="capitalised"] [data-menu-row] ul,
+[data-section-group="header"][data-header-nav-case="capitalised"] .mono-eyebrow-ctl {
+  text-transform: none;
+  letter-spacing: normal;
+}
+
+/* ─── THE BOX HEADER'S MENU ALIGNMENT ─────────────────────────────────
+   Where the old header put its menu, as the page Menu's `Link alignment` and
+   `Show links` (lib/content/menu-row; Lewis 2026-10-12, Q2 and Q4 option B).
+   The bar stays ONE FLAT ROW — Logo, Menu, tools — so the phone and mid-width
+   rules above keep working; these only place the menu where the bar is one
+   row, and step aside where it stacks.
+
+   One row (801px up): a Menu with `Link alignment` takes the bar's free space
+   and puts its links at its start, centre or end. `Center` gives the cells
+   either side equal shares, so the links sit on the bar's centre (the old
+   1fr auto 1fr). A link outside a Menu's `Show links` range is hidden.
+
+   A LEAD part — a ranged Menu that stops before the last link, left of a
+   centred logo — makes the bar three cells: the lead and the cell after the
+   logo share the bar equally, the logo keeps its width. Where the bar stacks
+   (a phone, and a laptop on Own row) the lead steps aside and the Menu after
+   the logo shows EVERY link, its Box opened (`display: contents`) so its Menu
+   and tools are the bar's own: one menu, one button, as the old header.
+
+   Unlayered, like the rules above, and after them where they meet: the
+   mid-width rules are more specific and win the cells they place. */
+@media (min-width: 801px) {
+  [data-section-group="header"] .flex-row > :is([data-menu-align], :has([data-menu-align])) {
+    flex: 1 1 0%;
+    min-width: 0;
+  }
+  /* Start and End fill the cell they grow into; a centred menu is as wide as
+     its links, so the links sit on the bar's centre. */
+  [data-section-group="header"] [data-menu-row]:is([data-menu-align="start"], [data-menu-align="end"]) {
+    width: 100%;
+  }
+  [data-section-group="header"] [data-menu-row][data-menu-align="start"] > ul {
+    justify-content: flex-start;
+  }
+  [data-section-group="header"] [data-menu-row][data-menu-align="center"] > ul {
+    justify-content: center;
+  }
+  [data-section-group="header"] [data-menu-row][data-menu-align="end"] > ul {
+    justify-content: flex-end;
+  }
+  /* Centred links: the cells either side share the rest equally. */
+  /* NOT `min-width: 0`: a side cell never shrinks below what it holds, as
+     the old grid's `1fr` columns did not, so a wide logo pushes the links
+     over rather than running under them. */
+  [data-section-group="header"] .flex-row:has([data-menu-align="center"]) > :not([data-menu-align]):not(:has([data-menu-align])) {
+    flex: 1 1 0%;
+  }
+  [data-section-group="header"] .flex-row > :is([data-menu-align="center"], :has([data-menu-align="center"])) {
+    flex: 0 1 auto;
+  }
+  [data-section-group="header"] [data-menu-row] li[data-menu-out] {
+    display: none;
+  }
+  /* A centred logo: the cell after the lead part keeps its own width. */
+  [data-section-group="header"] .flex-row > :is([data-menu-part="lead"], :has([data-menu-part="lead"])) + * {
+    flex: 0 0 auto;
+  }
+}
+@media (max-width: 800px) {
+  [data-section-group="header"] .flex-row > :is([data-menu-part="lead"], :has([data-menu-part="lead"])) {
+    display: none;
+  }
+  [data-section-group="header"] .flex-row > :is([data-menu-part="lead"], :has([data-menu-part="lead"])) + * {
+    flex: 1 1 0;
+    container-type: inline-size;
+    overflow-x: clip;
+  }
+}
+@media (min-width: 801px) and (max-width: 1500px) {
+  /* Own row stacks: the links start their own line, as the old second row. */
+  [data-section-group="header"]:not([data-header-menu-row="inline"]) [data-menu-row][data-menu-align] > ul {
+    justify-content: flex-start;
+  }
+  [data-section-group="header"]:not([data-header-menu-row="inline"]) [data-menu-row] li[data-menu-out] {
+    display: list-item;
+  }
+  [data-section-group="header"]:not([data-header-menu-row="inline"]) .flex-row > :is([data-menu-part="lead"], :has([data-menu-part="lead"])) {
+    display: none;
+  }
+  [data-section-group="header"]:not([data-header-menu-row="inline"]) .flex-row > :is([data-menu-part="lead"], :has([data-menu-part="lead"])) + * {
+    flex: 1 1 0;
+    container-type: inline-size;
+    overflow-x: clip;
+  }
+  /* The old stacked bar drew Search FIRST among its tools, whatever its
+     Search position (components/Header, the medium band); the position only
+     ever applied to the one-row bar. The logo stays ahead of it where a
+     centred logo's Box is opened below. */
+  [data-section-group="header"]:not([data-header-menu-row="inline"]) [data-phone-menu-tool="search"] > *,
+  [data-section-group="header"]:not([data-header-menu-row="inline"]) [data-puck-component]:has(> * > [data-phone-menu-tool="search"]) {
+    order: -1;
+  }
+  [data-section-group="header"]:not([data-header-menu-row="inline"]) .flex-row > :is([data-menu-part="lead"], :has([data-menu-part="lead"])) + * {
+    order: -2;
+  }
+  [data-section-group="header"]:not([data-header-menu-row="inline"]) .flex-row:has([data-menu-part="lead"]) > :has([data-menu-row]):not([data-menu-row]):not(:has([data-menu-part="lead"])),
+  [data-section-group="header"]:not([data-header-menu-row="inline"]) .flex-row:has([data-menu-part="lead"]) > :has([data-menu-row]):not([data-menu-row]):not(:has([data-menu-part="lead"])) :has([data-menu-row]):not([data-menu-row]) {
+    display: contents;
+  }
+}
+
+/* ─── Header TOP SPACE ────────────────────────────────────────────────
+   The page's own "Top space" (Page settings → `Top space`; the resolver is
+   lib/puck/header-clearance). A page that takes its own space publishes
+   `data-top-space="own"` on its body, and the bar above it paints a real
+   background from the first pixel instead of being see-through.
+
+   ⚠️ THIS IS THE MAP/PAINT SPLIT THIS CARD OWED AN ANSWER FOR, and the answer
+   is that the header does NOT wear `.sf-section-accent`. That class both MAPS
+   the theme tokens and PAINTS with them (`background: var(--bg)` at its end),
+   and a bar that must stay see-through at the top of most pages cannot wear a
+   rule that paints unconditionally. So the MAPPING stays where it already is —
+   the theme tokens the header inherits from the carrier — and the PAINT is
+   these three declarations, which apply only to a page that asked for them.
+
+   WHY THE INK GOES THROUGH THE VARIABLE. <Header/> sets `color:
+   var(--sf-header-overlay-fg)` INLINE while it is not solid, and an inline
+   style cannot be beaten from a stylesheet. Re-pointing the variable — the same
+   indirection the Auto/override rules above already use — lands the theme ink
+   without a specificity fight and without touching the component.
+
+   The border is the one declaration that IS a fight: the bar carries Tailwind's
+   `border-transparent` at (0,1,0) while not solid, and this selector scores
+   (0,2,1) — `body` type + the attribute inside `:has()` + the class. That is
+   the same arithmetic `scripts/test-header-lead-ink.ts` §3b pins for the ink
+   override, and `scripts/test-header-top-space.ts` pins it for this rule.
+
+   ON SCROLL NOTHING HERE APPLIES ANY MORE and that is correct: <Header/> goes
+   solid and sets background and colour inline, which beat this block. Solid is
+   solid either way, so the bar does not change appearance as the reader
+   scrolls — it was already painted. */
+body:has([data-top-space="own"]) .sf-site-header {
+  --sf-header-overlay-fg: var(--fg);
+  --sf-header-overlay-ground: var(--bg);
+  background: var(--bg);
+  border-bottom-color: var(--site-line);
+  backdrop-filter: blur(12px);
+}
+
+/* ─── The page's WIDTH reaching the chrome ────────────────────────────────
+   A page set to `Full width` publishes `data-page-width="full"` on its own
+   wrapper, and the bar above it plus the footer below it stop capping — so
+   the three sit on one column, or run edge to edge, together.
+
+   ⚠️ WHY `:has()` AND NOT A VARIABLE INHERITED DOWN THE TREE. The header is a
+   SIBLING of the page body, not an ancestor of it — measured in the browser on
+   2026-09-09: a custom property published on the page's wrapper resolves to
+   `none` inside the header, every time. The carrier that DOES wrap all three
+   (`.sf-theme-accent`) is rendered in app/layout.tsx, and a Next layout cannot
+   read the pathname (see the note above `isEditorShellRequest`), so it cannot
+   know which page it is wrapping. `:has()` is the one thing that reaches back
+   up and across, and card 66514 already proved it here for the header's ink.
+
+   ⚠️ AND WHY IT RE-POINTS A VARIABLE RATHER THAN SETTING `max-width`. The cap is
+   an INLINE style (`siteWidthCapStyle`), which no stylesheet can beat. Setting
+   the variable it reads is not a specificity trick, it is the only way in.
+
+   `none` rather than a wider number: `Full width` means no cap at all, and a
+   number would be a second opinion about how wide "no cap" is.
+
+   ⛔ A BAR THAT ANSWERED FOR ITSELF IS NOT LISTENING. Header and Footer each
+   have their own Width row; when one is set to `Content width` the component
+   writes the cap literally instead of through the variable, so this rule
+   cannot move it. That is the three-level rule made mechanical: the level that
+   spoke wins, and silence means follow. */
+body:has([data-page-width="full"]) .sf-site-header,
+body:has([data-page-width="full"]) footer {
+  --sf-chrome-cap: none;
+}
+
+@theme inline {
+  --color-bg: var(--bg);
+  --color-surface: var(--site-surface);
+  --color-surface-2: var(--site-surface-2);
+  --color-fg: var(--fg);
+  --color-fg-dim: var(--fg-dim);
+  --color-line: var(--site-line);
+  --color-accent: var(--accent);
+  --color-accent-2: var(--accent-2);
+  --color-accent-ink: var(--accent-ink);
+  /* The button's own fill/ink trio (card 66504), so `bg-btn` / `text-btn-ink`
+     compile. Each resolves to the accent unless a theme carries a button
+     colour — the chain is in `.sf-theme-accent` and its siblings above. */
+  --color-btn: var(--btn);
+  --color-btn-2: var(--btn-2);
+  --color-btn-ink: var(--btn-ink);
+  --color-overlay-fg: var(--overlay-fg);
+  --color-green: var(--green);
+  --color-alert: var(--alert);
+  --color-overlay-scrim: var(--overlay-scrim);
+  --color-overlay-chrome: var(--overlay-chrome);
+  --color-plate-band: var(--plate-band-bg);
+  --color-plate-band-fg: var(--plate-band-fg);
+  --color-plate-band-fg-dim: var(--plate-band-fg-dim);
+
+  /* font families — resolve through the swappable --font-role-* tokens
+     (defined on :root above, default to the built-in faces) so the
+     editor's Fonts control can remap them per site. */
+  --font-display: var(--font-role-heading), "Inter", system-ui, sans-serif;
+  /* Heading 2 and Heading 3 each get a utility of their own, so a section can
+     DRAW the face those rows set. Until this existed they could not: every
+     heading on the site wrote `font-display`, which resolves
+     `--font-role-heading` — Heading 1's face — while its size token said
+     `--size-headingMedium`. Measured on main before this change, 43 lines took
+     their size from Heading 2 and their face from Heading 1, and 30 did the
+     same for Heading 3, so BOTH Font controls in Site styles saved a value and
+     moved zero pixels.
+
+     ⚠️ THE FALLBACK TAIL IS THE SAME AS `--font-display`'s ON PURPOSE. These
+     are the same typographic slot at a different rank, not a different family,
+     and a heading that fell back to a different stack while the webfont loaded
+     would flash a face nobody chose.
+
+     ⚠️ SWAPPING `font-display` FOR THESE MOVES NO PIXELS TODAY.
+     `--font-role-heading2` and `--font-role-heading3` are declared on :root as
+     `var(--font-role-heading)`, and `normalizeFonts` resolves an unset
+     heading2/heading3 back to Heading 1's key, so a site that has never opened
+     those two rows renders exactly as it did. What changes is that opening
+     them now does something. */
+  --font-heading2: var(--font-role-heading2), "Inter", system-ui, sans-serif;
+  --font-heading3: var(--font-role-heading3), "Inter", system-ui, sans-serif;
+  --font-body: var(--font-role-body), system-ui, sans-serif;
+  /* Fraunces (default) — editorial italic serif, used by the Journal
+     page for gold-italic emphasis in headlines + pull-quotes. Falls
+     back to Georgia so the cascade never bare-metals to Times New
+     Roman. The accent role is swappable via the Fonts control. */
+  --font-serif: var(--font-role-accent), Georgia, "Iowan Old Style", serif;
+  /* Space Mono web font (loaded by next/font in layout.tsx) is the
+     primary face — same family lineage as Space Grotesk, identical
+     look on every OS. The OS-mono cascade sits behind it as graceful
+     fallback while the webfont is loading or if it fails to load. */
+  --font-mono: var(--font-role-label), var(--font-mono-fallback);
+
+  /* Tailwind's radius scale, pointed at the SITE'S corners — the `Corners`
+     block above says why it is `--site-radius-*` and where the defaults live. */
+  --radius-xs: var(--site-radius-xs);
+  --radius-sm: var(--site-radius-sm);
+  --radius-md: var(--site-radius-md);
+  --radius-lg: var(--site-radius-lg);
+  --radius-xl: var(--site-radius-xl);
+  --radius-2xl: var(--site-radius-2xl);
+  --radius-3xl: var(--site-radius-3xl);
+  --radius-4xl: var(--site-radius-4xl);
+}
+
+* {
+  box-sizing: border-box;
+}
+
+/* Layered — see the element-reset block below for why every bare-element
+   rule in this file must sit inside `@layer base`. */
+@layer base {
+  html,
+  body {
+    background: var(--bg);
+    color: var(--fg);
+    /* Body copy face — via the swappable body role (defaults to Inter). The
+       editor's Fonts control re-declares font-family on the page wrapper so
+       content re-resolves to the chosen face; this keeps chrome outside the
+       wrapper (e.g. the header) on the default body face. */
+    font-family: var(--font-role-body);
+    -webkit-font-smoothing: antialiased;
+    /* Theme switch should feel instant — the long 0.4s fade read as lag. Keep a
+       hair of easing so it's not a hard cut. */
+    transition: background 0.15s ease, color 0.15s ease;
+  }
+
+  /* Smooth-scroll for in-page hash anchors (header nav: /wheels#fusionforge etc.) */
+  html {
+    scroll-behavior: smooth;
+  }
+}
+
+/* The header's DRAWN height in px — what the bar actually measures on screen,
+   which is the merchant's "Header height" OR the bar's own content, whichever is
+   taller. <Header/> publishes it from a ResizeObserver on the bar. The
+   body-clearance, the section-anchor offset, the bars that pin under the header
+   and every `calc(100svh - header)` all read it, so page content never slides
+   under a taller — or floats below a shorter — bar.
+
+   ⚠️ NOT the slider value. That is `--sf-header-set-h` below, and only the bar's
+   own min-height may read it. The two were one var until 2026-09-16, and a bar
+   that had grown past the slider (a tall logo, or the stacked two-row layout
+   between 801px and 1500px) hid the top of the page under itself by the
+   difference. See lib/puck/header-clearance.ts.
+
+   Default = the historical fixed header height, so the first paint of a site
+   whose content fits is byte-identical to what it has always been. Keep it in
+   step with HEADER_HEIGHT_PX.default (lib/puck/header-clearance.ts). */
+:root {
+  --sf-header-h: 88px;
+}
+
+/* The merchant's CHOSEN header height — the Appearance → "Header height" slider,
+   published per site by app/layout.tsx (on <body>) and by <Header/> (on <html>).
+   Read by the bar's own `min-height` and by NOTHING else: a taller bar must still
+   be allowed to grow, or the stacked two-row header would clip its own menu.
+   Keep this default in step with HEADER_HEIGHT_PX.default. */
+:root {
+  --sf-header-set-h: 88px;
+}
+
+/* The site's content column, in px — how wide this whole website is. Default =
+   the width every storefront rendered at while it was hard-coded; app/layout.tsx
+   overrides it per site (on the page content wrapper) from the site's theme row,
+   and every page-width cap reads it as `max-w-[var(--sf-site-width,1600px)]`. A
+   site that has set no width publishes nothing, so the cap takes its own
+   fallback and lands right back on this number. Keep this default in step with
+   PAGE_WIDTH.default (lib/content/page-width.ts) — scripts/test-site-width.ts
+   reads it out of this file and fails if the two drift. NOT the same value as
+   the per-PAGE `--sf-page-width`, which the page builder's own Width control
+   publishes lower down for the page it is on. */
+:root {
+  --sf-site-width: 1600px;
+}
+
+/* Offset a page body below the fixed Header (HEADER_CLEARANCE_CLASS). Reads the
+   live header height so the gap tracks the merchant's chosen "Header height"
+   instead of a fixed 88px; the fallback keeps SSR's first paint correct before
+   <Header/>'s effect publishes the real value. */
+.sf-header-clearance {
+  padding-top: var(--sf-header-h, 88px);
+}
+
+/* Bars that stick directly under the site header (STICKY_UNDERHEADER_CLASS — the
+   Product Grid section header, the Journal category bar, the document-tabs bar).
+   Each pins at the live header height on its own (`top-[var(--sf-header-h,88px)]`);
+   this rule handles WHEN it should pin. By default they pin while the page scrolls,
+   which only reads right when the site header itself stays pinned. <Header/>
+   publishes its sticky mode as `data-header-sticky` on <html>; when the header is
+   set to scroll away ("none") or to hide on scroll-down ("on_scroll_up"), a bar
+   pinned at the top would hang over the gap the departed/hidden header left — so
+   un-pin it and let it scroll away with the content. Absent attribute (first paint,
+   or the default "always") keeps the pin, so the common case is unchanged. */
+:root[data-header-sticky="none"] .sf-sticky-underheader,
+:root[data-header-sticky="on_scroll_up"] .sf-sticky-underheader {
+  position: static;
+}
+
+/* Stick to top — the pin any section or card can be given (efficient-web-builder
+   lib/content/section-sticky.ts, card [ADD] Every Section Can Stick To The Top).
+   The pass wraps a node that sticks in `.sf-section-stick` and publishes the
+   distance below the header as `--sf-stick-distance` (and `-phone`); nothing
+   is emitted for a node that does not stick, so these rules match nothing on
+   a page that never used it.
+
+   It stops under the live header height, the same `--sf-header-h` the
+   under-header bars use. When the header does not stay pinned — the header
+   publishes `data-header-sticky` "none" or "on_scroll_up" on <html> — there
+   is no header to stop under, so the stop is the screen top. */
+.sf-section-stick {
+  position: sticky;
+  top: calc(var(--sf-header-h, 88px) + var(--sf-stick-distance, 0px));
+}
+.sf-section-stick.sf-section-stick-desktop-off {
+  position: static;
+}
+:root[data-header-sticky="none"] .sf-section-stick,
+:root[data-header-sticky="on_scroll_up"] .sf-section-stick {
+  top: var(--sf-stick-distance, 0px);
+}
+/* What comes after a pinned node slides OVER it. A sticky box is positioned,
+   and a positioned box paints above the plain boxes that follow it, so the
+   next section would slide UNDER the pinned one. Giving the followers a
+   position of their own puts them back in page order. Only siblings of a pin
+   are touched, so a page with no pin is unchanged. `:where()` makes the rule
+   weigh nothing: a follower that sets its own position (the Category bar's
+   own `sticky`, an `absolute` layer) keeps it. */
+:where(.sf-section-stick ~ :not(.sf-section-stick)) {
+  position: relative;
+}
+/* The phone's own answer (below 720px, VIEW_TABLET_MIN, written as in the
+   phone padding block below). */
+@media not all and (min-width: 720px) {
+  .sf-section-stick.sf-section-stick-phone-on {
+    position: sticky;
+    top: calc(var(--sf-header-h, 88px) + var(--sf-stick-distance-phone, 0px));
+  }
+  .sf-section-stick.sf-section-stick-phone-off {
+    position: static;
+  }
+  :root[data-header-sticky="none"] .sf-section-stick.sf-section-stick-phone-on,
+  :root[data-header-sticky="on_scroll_up"] .sf-section-stick.sf-section-stick-phone-on {
+    top: var(--sf-stick-distance-phone, 0px);
+  }
+}
+
+/* Section height — the "Height" field on any Puck section (card 66215). The
+   injected pass wraps a section that sets one in this class and publishes the
+   length as a custom property; the property is what varies per section, so the
+   rule itself lives here once.
+
+   MIN-height, never height, and no overflow anywhere in this block: content
+   taller than the number the merchant chose makes the section GROW (the owner's
+   ruling — clipping would hide a merchant's own words with no sign of it in the
+   editor). `display:grid` on the wrapper (set inline, beside the property) is
+   what makes the section STRETCH into the height rather than sit at the top of
+   an empty box; a grid row still grows past its minimum when the content is
+   taller, so stretching costs nothing at the clip end.
+
+   TWO DECLARATIONS, because one React style object cannot carry `min-height`
+   twice. The first is in `vh` and every browser understands it. The second is in
+   `svh` — the SMALL viewport height, which accounts for the mobile address bar
+   the old `vh` ignores — and only browsers that have the unit enter the
+   @supports block to take it. A section whose length carries no viewport unit at
+   all (Fixed in px) publishes only the base property, so the inner var() names
+   the base as its own fallback rather than resolving to nothing. */
+.sf-section-minh {
+  min-height: var(--sf-section-minh);
+}
+@supports (min-height: 1svh) {
+  .sf-section-minh {
+    min-height: var(--sf-section-minh-s, var(--sf-section-minh));
+  }
+}
+
+/* Section anchors — the "Anchor" field on any Puck section. When set,
+   the section renders an invisible, zero-height <span id> as its first child
+   (see SectionAnchor in lib/puck/config.tsx). `display:block; height:0` makes it
+   a real scroll target that adds no layout box; `scroll-margin-top` clears the
+   fixed header — now the live --sf-header-h (fallback 88px) — so a
+   /<page>#<anchor> deep-link lands with the section below the header, not under
+   it — the same JS-free path as the /wheels collection anchors above. */
+.sf-section-anchor {
+  display: block;
+  height: 0;
+  scroll-margin-top: var(--sf-header-h, 88px);
+}
+
+/* Hero slider — never show the horizontal scroll-snap scrollbar. Covers the
+   track itself AND any descendant, because in the page-builder Puck wraps the
+   slot children, so the actual scroll container can be a nested element the
+   utility classes on `.hero-track` don't reach. */
+.hero-track,
+.hero-track * {
+  scrollbar-width: none; /* Firefox */
+  -ms-overflow-style: none; /* legacy Edge */
+}
+.hero-track::-webkit-scrollbar,
+.hero-track *::-webkit-scrollbar {
+  display: none; /* Chrome / Safari */
+  width: 0;
+  height: 0;
+}
+
+/* ─── Element resets ─────────────────────────────────────────────────
+   EVERY bare-element reset in this file lives inside `@layer base`, and
+   new ones must too. An UNLAYERED rule beats every layered one no matter
+   how specific, and Tailwind's utilities live in `@layer utilities` — so
+   a top-level `a { color: inherit }` silently outranks `text-accent`,
+   `underline`, `hover:text-bg`… on that element. The class is still in
+   the markup, still in the generated CSS, and still does nothing: the
+   failure is invisible until someone measures a computed colour.
+
+   That is not hypothetical. It cost <button> its font/background/border
+   once (fixed by layering it, below), and it had swallowed the colour on
+   every <a> in the storefront — 74 links across 44 files carrying a
+   `text-*` / `underline` utility that never applied.
+
+   `scripts/test-css-layers.ts` fails the build if a bare-element reset
+   reappears at top level. */
+@layer base {
+  a {
+    color: inherit;
+    text-decoration: none;
+  }
+
+  img {
+    display: block;
+    max-width: 100%;
+  }
+
+  button {
+    font: inherit;
+    color: inherit;
+    background: none;
+    border: 0;
+    cursor: pointer;
+  }
+
+  /* A HEADING MAY ALWAYS SHRINK TO THE BOX IT IS IN, AND BREAK A WORD THAT IS
+     WIDER THAN THAT BOX. (Card [FIX] Big Text Spills Out Of A Section.)
+
+     A flex item defaults to `min-width: auto`: it refuses to be narrower than
+     its own longest WORD. That is invisible while a section draws a heading at
+     the size it was designed at, and it is the whole defect the moment a
+     merchant raises that size — which they can, from Site styles, from a part's
+     own Text style, and (since the Booking Form's four text kinds) from a
+     section's own control. Measured on the Booking Form, 2026-09-10: its step
+     label is an `<h3>` beside a numbered circle in `flex items-center gap-3`,
+     and pointed at Heading 1 it laid out 470px wide in a 384px row and pushed
+     the page's scroll width from 992 to 1081. Nothing clipped it with
+     `overflow` — the page simply grew wider than the viewport and the tail was
+     off-screen, which reads to a merchant as "cut off at the card's edge".
+
+     ⚠️ WRAP AND GROW, NEVER CAP. Capping how far a run may grow would undo the
+     owner's 2026-09-05 ruling ("following a style brings the size too") one
+     section at a time. A cap already exists and is the merchant's to set —
+     `PartStyle.width`, "how far the part may run, in px". This makes the
+     DEFAULT honest: the words wrap, the section gets taller, nothing is lost.
+
+     ⚠️ BOTH DECLARATIONS OR NEITHER. Once the item may shrink, a single word
+     wider than the box still runs out of it; `break-word` breaks a word only
+     when it cannot fit a line of its own, so every heading that fits today is
+     drawn exactly as it is today.
+
+     ⚠️ HEADINGS ONLY, AND THAT IS A SCOPE RATHER THAN AN OVERSIGHT. A blanket
+     `.flex > * { min-width: 0 }` would reach 346 flex rows and let icons and
+     fixed-size boxes squash under pressure they currently resist. A run that is
+     NOT a heading is reached by the other half of this fix, which is keyed to
+     the thing that actually makes it big: `partStyleDeclarations` in
+     `lib/puck/part-styles.ts` writes the same two properties whenever it states
+     a size. Together they cover both ways a run can outgrow its box.
+
+     Layered, like every bare-element rule in this file — so a section that
+     really does want `min-w-*` or `whitespace-nowrap` on a heading still wins
+     with a utility. `scripts/test-css-layers.ts` fails the build if it is not. */
+  h1,
+  h2,
+  h3,
+  h4,
+  h5,
+  h6 {
+    min-width: 0;
+    overflow-wrap: break-word;
+  }
+}
+
+/* Visible focus ring on dark + light themes */
+:focus-visible {
+  outline: 2px solid var(--accent);
+  outline-offset: 2px;
+}
+
+/* Native <select> dropdown options + popup panel.
+   Theme-aware:
+     dark theme  → option panel = black bg, white text
+     light theme → option panel = white bg, black text
+   `color-scheme` on the select itself tells the browser which OS
+   chrome to render (Chrome/Edge/Safari respect this for the popup
+   panel background). The explicit option {bg,color} pair covers
+   Firefox + the option rows themselves so contrast stays correct in
+   both themes. */
+/* Layered — see the element-reset block above. The `option:hover/:checked`
+   and `[data-theme="light"]` rules below stay unlayered on purpose: they are
+   state/theme OVERRIDES of these defaults, not resets. */
+@layer base {
+  select {
+    color-scheme: dark;
+    accent-color: var(--accent);
+  }
+  option {
+    background-color: #0a0a0a;
+    color: #f5f1e8;
+  }
+}
+option:hover,
+option:focus,
+option:checked,
+option:active {
+  background: var(--accent) linear-gradient(0deg, var(--accent), var(--accent));
+  color: #0a0a0a;
+}
+[data-theme="light"] select {
+  color-scheme: light;
+}
+[data-theme="light"] option {
+  background-color: #ffffff;
+  color: #0a0a0a;
+}
+[data-theme="light"] option:hover,
+[data-theme="light"] option:focus,
+[data-theme="light"] option:checked,
+[data-theme="light"] option:active {
+  background: var(--accent) linear-gradient(0deg, var(--accent), var(--accent));
+  color: #0a0a0a;
+}
+
+/* Mono caps eyebrow utility — the header's nav, wordmark strip and utility
+   links (components/Header.tsx is its only user).
+
+   The face reads --font-role-label DIRECTLY, never `var(--font-mono)`. A custom
+   property's var() is substituted on the element that DECLARES it, and
+   --font-mono is declared on :root — so it computes to the house JetBrains Mono
+   there and inherits that literal everywhere, whatever a site publishes further
+   down. Measured on one element with the site's Labels font set to Outfit:
+   `var(--font-mono)` -> JetBrains Mono, `var(--font-role-label)` -> Outfit. That
+   is why the header nav stayed monospace on both demo sites even once the roles
+   reached it (card 8824). The Tailwind `font-mono` utility is unaffected — it
+   inlines the theme value, so its var() resolves per element already.
+
+   The size and tracking below stay hard-coded: making them per-site is a
+   separate card. */
+.mono-eyebrow {
+  font-family: var(--font-role-label), var(--font-mono-fallback);
+  font-size: 14px;
+  letter-spacing: 0.18em;
+  text-transform: uppercase;
+}
+
+/* ── Site styles ▸ Accent ▸ Size ────────────────────────────────────────────
+   The size a gold `==phrase==` takes. The row was added on 2026-09-05 and read
+   by NOTHING until 2026-09-08: `typeSizesStyle` published `--size-accent` and
+   zero lines in `components/` or `app/` looked at it, so the control saved a
+   number and moved not one pixel.
+
+   ⚠️ A RULE, NOT A CLASS ON THE ELEMENT, and the reason is measured rather than
+   stylistic. `goldPhrases` renders every accent run, and its output is
+   byte-frozen: `scripts/test-markup-byte-identity.tsx` compares it against the
+   parser that shipped, and `scripts/test-word-styles.tsx` compares 900 PUBLISHED
+   strings against a named commit. Adding one utility class there moved all 900 —
+   a real diff on every live page, to deliver a size the cascade delivers with no
+   markup at all.
+
+   It also reaches the accent runs written by hand in CartDrawer, GalleryItem,
+   checkout and the PDPs, which `goldPhrases` never sees and which are the same
+   style. Scoped to `em` so it cannot catch the many other elements that wear
+   `text-accent` for its COLOUR alone.
+
+   ⚠️ THE FALLBACK IS `inherit`, NOT A NUMBER. An accent is a phrase inside a
+   line, so with no size stated it must take that line's size — which is what an
+   `<em>` already did. A site that has never opened the row publishes no
+   `--size-accent` and renders byte for byte as it did. The tokens are published
+   on the page content wrapper, so chrome outside `<main>` keeps inheriting too.
+   `scripts/test-style-face-matches-size.tsx` §4 pins both halves. */
+em.text-accent {
+  font-size: var(--size-accent, inherit);
+}
+
+/* Letters: Capitalised — the header's "Letters" control turning the caps OFF
+   (card 66518).
+
+   IT HAS TO LIVE HERE, beside `.mono-eyebrow`, and it cannot be a Tailwind
+   utility. `.mono-eyebrow` above is declared OUTSIDE every `@layer`, and
+   unlayered CSS beats layered CSS whatever the specificity — measured in the
+   built stylesheet: `.mono-eyebrow` at byte 143878 unlayered, `.normal-case`
+   at 77347 inside `@layer utilities`. So `normal-case` landed in the DOM and
+   changed nothing on screen, which is exactly how it reached Lewis.
+
+   Same specificity as `.mono-eyebrow`, same (un)layer, declared AFTER it — so
+   the cascade picks this one, and it keeps working if either rule moves as
+   long as this one stays below. The 0.18em tracking goes with the caps: that
+   spacing is drawn for capitals and reads as a gap between lowercase letters. */
+.mono-eyebrow-plain {
+  letter-spacing: normal;
+  text-transform: none;
+}
+
+/* The header's three tool controls — search, account, cart — taking the case
+   from the strip they sit in (card 66518).
+
+   A <button> does NOT inherit `text-transform`: every UA stylesheet sets
+   `text-transform: none` on form controls, and that beats the inherited value.
+   So the nav strip said `uppercase`, the account <a> obeyed, and the cart and
+   search <button>s did not. Measured in Chrome on the real storefront:
+
+       nav                text-transform: uppercase
+       a       Account    uppercase          <- inherits
+       button  Bag        none               <- does not
+       button  Search     none               <- does not
+
+   Lewis saw it as "ACCOUNT  Bag  Search" in one bar. It was always true; the
+   glyphs just had no letters to show it with.
+
+   SCOPED to the three controls rather than to `.mono-eyebrow button`, so the
+   region picker and the theme toggle in the same strip keep the case they draw
+   today. Unlayered, like the two rules above, for the same cascade reason. */
+.mono-eyebrow-ctl {
+  letter-spacing: inherit;
+  text-transform: inherit;
+}
+
+/* Finish-swatch border — a neutral mid-grey perimeter. Each swatch
+   already carries its own hex fill; this border just provides a clean
+   edge line so the colour disc reads as a deliberately-bordered chip.
+   Theme-independent: the mid-grey is quiet enough on the dark page bg
+   and visible enough on the light card surface, so it is not flipped
+   in the [data-theme="light"] block. Consumed by ProductCard and the
+   wheels CatalogCard swatches. */
+:root {
+  --swatch-border: #888;
+}
+
+/* Ticker keyframes — track is duplicated and translates -50% to loop seamlessly.
+   FOUR of them, one per answer of the Scrolling Bar's `Scroll direction` row.
+
+   ⚠️ `storefront-ticker` KEEPS ITS BARE NAME AND IS THE LEFTWARD ONE. It is the
+   travel every published marquee already has, and the section-style baseline
+   pins the ticker's default markup down to this exact animation string — so
+   renaming it would move a fixture for a strip whose pixels had not changed,
+   which costs a normaliser or a CHANGED_SECTIONS row to say nothing at all.
+   The three new directions are the ones that get new names. */
+@keyframes storefront-ticker {
+  from {
+    transform: translateX(0);
+  }
+  to {
+    transform: translateX(-50%);
+  }
+}
+/* Rightward is the same travel read backwards, NOT a negative duration or an
+   `animation-direction: reverse` on the shared name: both would need a second
+   property on the element, and the element already says everything it says in
+   one `animation` shorthand. */
+@keyframes storefront-ticker-right {
+  from {
+    transform: translateX(-50%);
+  }
+  to {
+    transform: translateX(0);
+  }
+}
+/* The vertical pair. Same -50% loop on the other axis — the track is stacked
+   rather than laid across, so the duplicated half tiles downwards instead. */
+@keyframes storefront-ticker-up {
+  from {
+    transform: translateY(0);
+  }
+  to {
+    transform: translateY(-50%);
+  }
+}
+@keyframes storefront-ticker-down {
+  from {
+    transform: translateY(-50%);
+  }
+  to {
+    transform: translateY(0);
+  }
+}
+
+/* `.hero-poster` (two radial gradients over a dark ramp, plus a 45° crosshatch
+   on ::before) was deleted by card 66237. The Hero's z-1 layer now paints one
+   flat `var(--site-surface)` inline, like every other picture slot. Nothing else
+   used the class, and the hardcoded #2a2218 / #1a1410 / #0a0a0a in it were
+   dark-theme literals that never followed a merchant's palette. Do not
+   reintroduce it: `scripts/test-placeholder-copy.ts` §3b fails on the name. */
+
+/* Studio-map editorial overrides moved inline to ContactPageClient.tsx
+   so they reliably ship with the component (Turbopack dev mode doesn't
+   always hot-reload mid-session edits to globals.css). */
+
+/* Footer — the first block (the brand logo) fills its whole column so no menu
+   ever wraps beneath it. --footer-logo-rows is measured from the live block and
+   column counts in FooterSection and set on <footer>; the logo cell spans that
+   many rows and pins to column 1, pushing every other block into the columns to
+   its right. The per-tier toggles (logoFill{Desktop,Tablet,Mobile}) live in that
+   measurement: a disabled tier — or a single-column layout — resolves the var to
+   1, so this same rule collapses to a normal cell and the logo just stacks.
+
+   The logo can instead fill its whole ROW: --footer-logo-col (also set on
+   <footer> per tier) is `1 / -1` when that view's row-fill is on, making the
+   logo span every column as its own top row while the other blocks flow beneath.
+   Row-fill and column-fill can't both apply, so when row-fill is on FooterSection
+   forces --footer-logo-rows back to 1; off, the var defaults to `1` (a normal
+   single-column cell) and the row span above takes over. */
+.footer-block-grid > :first-child {
+  grid-column: var(--footer-logo-col, 1);
+  grid-row: 1 / span var(--footer-logo-rows, 1);
+}
+
+/* Alloy Wheels Listing — how many wheel cards sit in one row, authored PER VIEW
+   ("Wheels per row" in the section's Results settings). The three track lists
+   are computed in lib/wheels/plp-grid and set on the grid element as custom
+   properties; this rule is only the media-query switch that picks one, because a
+   published page has no JS device to ask. The editor sets all three to the
+   previewed view's list instead — its iframe width is not the device being
+   previewed — so the same rule serves both without branching.
+
+   No fallback values on purpose: an element that carries the class always
+   carries the vars, and a silent fallback here would be a second, invisible
+   source of truth for the default the grid module already owns.
+
+   The breakpoints ARE lib/content/view-tiers' VIEW_TABLET_MIN / VIEW_DESKTOP_MIN
+   — CSS cannot read those constants, so scripts/test-view-tier-breakpoints.ts
+   fails if this file and that module ever disagree. */
+.plp-card-grid {
+  display: grid;
+  gap: var(--plp-grid-gap);
+  grid-template-columns: var(--plp-grid-cols-mobile);
+}
+@media (min-width: 720px) {
+  .plp-card-grid {
+    grid-template-columns: var(--plp-grid-cols-tablet);
+  }
+}
+@media (min-width: 1100px) {
+  .plp-card-grid {
+    grid-template-columns: var(--plp-grid-cols-desktop);
+  }
+}
+
+/* Integrations wall marquee (components/IntegrationsSection.tsx): the chip
+   track is rendered twice, so -50% is exactly one full list — the loop is
+   seamless at any width. Reduced-motion users get a static wall (the
+   component sets [animation:none] via motion-reduce). */
+@keyframes sf-marquee {
+  from { transform: translateX(0); }
+  to { transform: translateX(-50%); }
+}
+
+/* ── Word styles — Highlight · Bold · Quiet (card 66119) ────────────────────
+   A selected word wears a NAMED style, defined once for the whole site: change
+   the definition and every word wearing it follows. Three NEW marks, one each:
+
+       @@phrase@@   Highlight      ++phrase++   Bold        ^^phrase^^   Quiet
+
+   ⚠️ `**` AND `==` ARE NOT INVOLVED AND MUST NOT BE. `**` is bold and `==` is
+   the brand-colour highlight, on this site and in the email campaign designer,
+   which parses the same authored string through the same shared grammar. See
+   lib/word-styles.ts for why re-pointing them was considered and rejected.
+
+   EACH MARK'S BUILT-IN LOOK LIVES HERE, ONCE. `wordStyleTokens` emits a
+   `--sf-ws-*` custom property only for a facet the merchant has actually set,
+   so the fallback in each `var()` below IS the default — there is no second
+   copy of these values in TypeScript to drift from. A `var(--x, inherit)` reads
+   as "the merchant said nothing about this facet, so leave it alone".
+
+   NOT in @layer utilities, so these beat any Tailwind utility on the same
+   element. Nothing sets one today — a word-style span carries no class at all —
+   but a section that later wrapped one would otherwise silently win over a
+   merchant's explicit choice.
+
+   The three differ only in their DEFAULT colour and weight; every other facet
+   starts unset, because a word style should change as little as it must. */
+[data-sf-ws] {
+  font-family: var(--sf-ws-font, inherit);
+  font-size: var(--sf-ws-size, inherit);
+  font-style: var(--sf-ws-style, inherit);
+  line-height: var(--sf-ws-line, inherit);
+  letter-spacing: var(--sf-ws-track, inherit);
+}
+
+/* Highlight — the site's brand colour, the same ink `==` paints in. They are
+   two different marks on purpose: `==` is a fixed brand-colour highlight shared
+   with email, this one is a style a merchant can redefine.
+
+   THE SELECTOR AND EVERY TOKEN BELOW SPELL THE KEY, NOT THE LABEL. A merchant
+   read Emphasis from card 66172 until 2026-10-04 and reads Highlight again now;
+   `highlight` is what every published page and the backend column already
+   store, and it does not move for a copy change. */
+[data-sf-ws="highlight"] {
+  --sf-ws-font: var(--sf-ws-highlight-font, inherit);
+  --sf-ws-size: var(--sf-ws-highlight-size, inherit);
+  --sf-ws-style: var(--sf-ws-highlight-style, inherit);
+  --sf-ws-line: var(--sf-ws-highlight-line, inherit);
+  --sf-ws-track: var(--sf-ws-highlight-track, inherit);
+  font-weight: var(--sf-ws-highlight-weight, var(--sf-ws-highlight-weight-bold, inherit));
+  color: var(--sf-ws-highlight-color, var(--accent));
+}
+
+/* Strong — heavier than its sentence, in the sentence's own ink. 600 rather
+   than 700 so it matches the weight `**` already renders at: a merchant reaching
+   for "the strong one" should not find it louder than the bold beside it. */
+[data-sf-ws="strong"] {
+  --sf-ws-font: var(--sf-ws-strong-font, inherit);
+  --sf-ws-size: var(--sf-ws-strong-size, inherit);
+  --sf-ws-style: var(--sf-ws-strong-style, inherit);
+  --sf-ws-line: var(--sf-ws-strong-line, inherit);
+  --sf-ws-track: var(--sf-ws-strong-track, inherit);
+  font-weight: var(--sf-ws-strong-weight, var(--sf-ws-strong-weight-bold, 600));
+  color: var(--sf-ws-strong-color, inherit);
+}
+
+/* Quiet — the site's Labels ink, the dim tone eyebrows and captions already
+   use, so a quiet word recedes by the same amount everywhere. */
+[data-sf-ws="quiet"] {
+  --sf-ws-font: var(--sf-ws-quiet-font, inherit);
+  --sf-ws-size: var(--sf-ws-quiet-size, inherit);
+  --sf-ws-style: var(--sf-ws-quiet-style, inherit);
+  --sf-ws-line: var(--sf-ws-quiet-line, inherit);
+  --sf-ws-track: var(--sf-ws-quiet-track, inherit);
+  font-weight: var(--sf-ws-quiet-weight, var(--sf-ws-quiet-weight-bold, inherit));
+  color: var(--sf-ws-quiet-color, var(--fg-dim));
+}
+
+/* ── A Hero slide's GROUPS, and the anchor each one sits on (card 66189) ───────
+
+   A group carries an ANCHOR, never a pair of coordinates. The owner's reason is
+   the design: the hero's height is the merchant's, a phone breaks every stored
+   coordinate, and "bottom left" means the same thing at any size.
+
+   ⚠️ WHY THIS IS A GRID AND NOT NINE ABSOLUTE CORNERS. Puck 0.20 hands a slot's
+   children to ONE container as a flat list — there is no per-child wrapper — so
+   `HeroSlide` cannot sort its groups into nine corner boxes, and nine absolute
+   siblings cannot stack by content height without measuring in JS (which means
+   the published page moving after it paints). One grid solves both: three bands
+   of four rows with a `1fr` spacer between them, the vertical anchor picking the
+   band's first row and the horizontal anchor riding `justify-self`.
+
+   That last part is load-bearing and easy to lose: three anchors in ONE band
+   share a row, so `bottom-left` and `bottom-right` sit SIDE BY SIDE — which is
+   what today's hero is (heading left, body right, one line). A design that gave
+   each band a flex column would stack them and quietly break it.
+
+   Empty `auto` rows collapse to nothing, so a band holding one group hugs its
+   edge exactly as if the other three rows were not there.
+
+   ⚠️ THE STACK RULES BELOW WIN ON SPECIFICITY, NOT ON SOURCE ORDER, AND THAT IS
+   DELIBERATE. `~` is the GENERAL sibling combinator, so `.g[a] ~ .g[a]` matches
+   the 2nd group on that anchor AND the 3rd AND the 4th — every one of them. The
+   right row still wins because each longer chain is a more specific selector
+   (three compound selectors beat two), and specificity is settled before source
+   order ever comes into it. So these rules may be written in any order and may
+   be reordered safely — but do NOT "tidy" them by collapsing the chains or by
+   assuming the last one wins, because the 3rd and 4th rows would silently fall
+   back to the 2nd row's rule and two groups would draw on top of each other.
+
+   THE STACK IS CAPPED AT FOUR, and the cap is enforced in the EDITOR as well as
+   here — a fifth group would land on the fourth's row, and a guard is not in the
+   room when a merchant presses Add. See `heroGroupAddBlocked` and
+   `placementPoints` in lib/hero-group-placement.ts: the Add row and the full
+   anchor's square both go unavailable, with a sentence saying why.
+
+   The whole model — the row maths, the depth, the nudge limit — lives in
+   lib/hero-group-placement.ts, and scripts/test-hero-group-placement.tsx pins
+   this file against it (a tenth anchor with no rule here fails there).
+
+   NOT in @layer utilities, like the word-style rules above and for the same
+   reason: a group's row must beat any utility a later section puts on it. */
+.sf-hero-group-layer {
+  display: grid;
+  grid-template-columns: minmax(0, 1fr);
+  /* FIVE rows per band, not four: the first row of each band belongs to the
+     slide's OWN copy (card 66213) and the four after it are the groups' stack.
+     Keep in step with HERO_GROUP_BAND_ROWS — lib/hero-group-placement carries
+     the whole reason, and a band that disagrees with this line puts a group on
+     a row the grid does not have, which is an implicit row BELOW the slide
+     rather than an error anybody sees. */
+  grid-template-rows: repeat(5, auto) 1fr repeat(5, auto) 1fr repeat(5, auto);
+  /* The layer covers the whole slide, so it would swallow every click meant for
+     what is underneath it. Only the copy and the groups are hit targets. */
+  pointer-events: none;
+}
+/* …except in the editor, where the empty drop zone IS the drop target. Card
+   66213 moved this off the LAYER and onto the zone: the layer now also holds the
+   slide's own copy, and making the whole layer a target would put the drop
+   surface on top of the merchant's own heading. */
+.sf-hero-group-layer-edit .sf-hero-group-zone { pointer-events: auto; }
+
+/* Puck's own drop zone, laid over the SAME rows as the copy beside it (card
+   66213). This is the one layer, and this element is what makes it one:
+   `subgrid` means a group's `--sf-hg-row` counts the layer's tracks, not a
+   private set of its own, so a group and the copy on one square STACK instead of
+   overlapping — which two stacked layers can never do.
+
+   ⚠️ A REAL BOX, DELIBERATELY, AND NOT `display: contents`. Puck measures this
+   element to decide where a drag lands; `display: contents` removes the box and
+   takes the measurement with it. Spanning every row costs nothing because the
+   zone is not a hit target (above) and its rows are the layer's own.
+
+   Measured in a real browser before it was written (900×500 slide, 40px inset):
+   copy 406→424 at the left edge, group one 424→442 directly beneath it, group
+   two 442→460, a top-right group at 40→58 against the right edge, and ZERO
+   overlapping pairs. scripts/harness/hero-copy-grid-probe.html is that probe. */
+.sf-hero-group-zone {
+  grid-column: 1;
+  grid-row: 1 / -1;
+  display: grid;
+  grid-template-columns: minmax(0, 1fr);
+  grid-template-rows: subgrid;
+  pointer-events: none;
+}
+
+.sf-hero-group {
+  /* The BAND's own row, stated by the component as a custom property so the
+     sibling rules below can add to it. An inline `grid-row` would beat them. */
+  grid-row: var(--sf-hg-row);
+  /* EXPLICIT, and it is not decoration: the zone above spans every row of
+     column 1, so auto-placement has no free cell left and would flow the copy
+     into an implicit SECOND column — which is exactly what the browser probe
+     did before this line existed, parking the copy off to the right of a
+     narrowed zone. */
+  grid-column: 1;
+  min-width: 0;
+  pointer-events: auto;
+}
+
+/* A group's own two numbers, applied from CUSTOM PROPERTIES the component
+   renders rather than from the inline `max-width` / `translate` it used to
+   write directly (card 66255).
+
+   ⚠️ THIS IS NOT A TIDY-UP, AND PUTTING THEM BACK INLINE BREAKS THE PHONE. An
+   inline style beats every stylesheet rule that is not `!important`, so the
+   phone block below could not reach either of them — and both have to be
+   reached: a `width` is a % of the SLIDE (60% of 375px is 201px, a number no
+   merchant chose) and a nudge is a ±40px fine adjustment against an ANCHOR,
+   which a stack does not have. Free to change, because no stored document holds
+   a HeroGroup at all: measured 2026-08-29 across every schema, in both `layout`
+   and `published_layout`, soft-deleted rows included.
+
+   An UNTOUCHED group still renders nothing for the nudge — the component omits
+   the property entirely — so the fallback here is what carries the "no nudge"
+   case, exactly as the inline style's absence used to. */
+.sf-hero-group {
+  max-width: var(--sf-hg-w, 100%);
+  translate: var(--sf-hg-nudge, none);
+}
+
+/* A box's WIDTH BUILT-IN, and it is two different numbers because the two
+   positions are two different questions (owner 2026-09-04: "是需要在那个百分之
+   60 的盒子里, 100% 的出现").
+
+   A box parked on the SLIDE is a column of copy over a photograph, and 60% of
+   the slide is the shape that reads — so the zone's own children carry 60%
+   here. A box parked INSIDE another box was handed the same 60% and it was
+   simply wrong: it is not measuring the slide, it is measuring the box its
+   merchant just drew, and 60% of that is a second unasked-for indent. It takes
+   the `var()` fallback one rule up — 100%, fill the box you are in.
+
+   ⚠️ THE BUILT-IN LIVES HERE AND NOT IN `defaultProps` — doc/editor-ui.md E11,
+   the same call `lib/content/container-gap.ts` and `container-direction.ts`
+   already made for this very box. A seeded default is a second copy of a
+   number, free to drift from the one the render uses; worse here than for
+   either of those, because this number depends on WHERE the node sits and
+   `defaultProps` is stamped before the node has a position.
+
+   ⚠️ AND IT IS A CUSTOM PROPERTY ON A SELECTOR, NOT A `max-width`. The rule
+   above is the one place a box's width is applied, so a merchant's stored
+   width still beats this (it arrives inline) and the phone block below still
+   overrides both. A `max-width` here would be a second application of one
+   idea, which is the defect the inline-vs-stylesheet note above is about. */
+.sf-hero-group-zone > .sf-hero-group {
+  --sf-hg-w: 60%;
+}
+
+/* The second group on ONE anchor drops 1 row, so a stack never overlaps.
+   Document order is Layer-panel order, so the tree order IS the stack order. */
+.sf-hero-group[data-hg="top-left"] ~ .sf-hero-group[data-hg="top-left"],
+.sf-hero-group[data-hg="top-center"] ~ .sf-hero-group[data-hg="top-center"],
+.sf-hero-group[data-hg="top-right"] ~ .sf-hero-group[data-hg="top-right"],
+.sf-hero-group[data-hg="left"] ~ .sf-hero-group[data-hg="left"],
+.sf-hero-group[data-hg="center"] ~ .sf-hero-group[data-hg="center"],
+.sf-hero-group[data-hg="right"] ~ .sf-hero-group[data-hg="right"],
+.sf-hero-group[data-hg="bottom-left"] ~ .sf-hero-group[data-hg="bottom-left"],
+.sf-hero-group[data-hg="bottom-center"] ~ .sf-hero-group[data-hg="bottom-center"],
+.sf-hero-group[data-hg="bottom-right"] ~ .sf-hero-group[data-hg="bottom-right"] {
+  grid-row: calc(var(--sf-hg-row) + 1);
+}
+
+/* The third group on ONE anchor drops 2 rows, so a stack never overlaps.
+   Document order is Layer-panel order, so the tree order IS the stack order. */
+.sf-hero-group[data-hg="top-left"] ~ .sf-hero-group[data-hg="top-left"] ~ .sf-hero-group[data-hg="top-left"],
+.sf-hero-group[data-hg="top-center"] ~ .sf-hero-group[data-hg="top-center"] ~ .sf-hero-group[data-hg="top-center"],
+.sf-hero-group[data-hg="top-right"] ~ .sf-hero-group[data-hg="top-right"] ~ .sf-hero-group[data-hg="top-right"],
+.sf-hero-group[data-hg="left"] ~ .sf-hero-group[data-hg="left"] ~ .sf-hero-group[data-hg="left"],
+.sf-hero-group[data-hg="center"] ~ .sf-hero-group[data-hg="center"] ~ .sf-hero-group[data-hg="center"],
+.sf-hero-group[data-hg="right"] ~ .sf-hero-group[data-hg="right"] ~ .sf-hero-group[data-hg="right"],
+.sf-hero-group[data-hg="bottom-left"] ~ .sf-hero-group[data-hg="bottom-left"] ~ .sf-hero-group[data-hg="bottom-left"],
+.sf-hero-group[data-hg="bottom-center"] ~ .sf-hero-group[data-hg="bottom-center"] ~ .sf-hero-group[data-hg="bottom-center"],
+.sf-hero-group[data-hg="bottom-right"] ~ .sf-hero-group[data-hg="bottom-right"] ~ .sf-hero-group[data-hg="bottom-right"] {
+  grid-row: calc(var(--sf-hg-row) + 2);
+}
+
+/* The fourth group on ONE anchor drops 3 rows, so a stack never overlaps.
+   Document order is Layer-panel order, so the tree order IS the stack order. */
+.sf-hero-group[data-hg="top-left"] ~ .sf-hero-group[data-hg="top-left"] ~ .sf-hero-group[data-hg="top-left"] ~ .sf-hero-group[data-hg="top-left"],
+.sf-hero-group[data-hg="top-center"] ~ .sf-hero-group[data-hg="top-center"] ~ .sf-hero-group[data-hg="top-center"] ~ .sf-hero-group[data-hg="top-center"],
+.sf-hero-group[data-hg="top-right"] ~ .sf-hero-group[data-hg="top-right"] ~ .sf-hero-group[data-hg="top-right"] ~ .sf-hero-group[data-hg="top-right"],
+.sf-hero-group[data-hg="left"] ~ .sf-hero-group[data-hg="left"] ~ .sf-hero-group[data-hg="left"] ~ .sf-hero-group[data-hg="left"],
+.sf-hero-group[data-hg="center"] ~ .sf-hero-group[data-hg="center"] ~ .sf-hero-group[data-hg="center"] ~ .sf-hero-group[data-hg="center"],
+.sf-hero-group[data-hg="right"] ~ .sf-hero-group[data-hg="right"] ~ .sf-hero-group[data-hg="right"] ~ .sf-hero-group[data-hg="right"],
+.sf-hero-group[data-hg="bottom-left"] ~ .sf-hero-group[data-hg="bottom-left"] ~ .sf-hero-group[data-hg="bottom-left"] ~ .sf-hero-group[data-hg="bottom-left"],
+.sf-hero-group[data-hg="bottom-center"] ~ .sf-hero-group[data-hg="bottom-center"] ~ .sf-hero-group[data-hg="bottom-center"] ~ .sf-hero-group[data-hg="bottom-center"],
+.sf-hero-group[data-hg="bottom-right"] ~ .sf-hero-group[data-hg="bottom-right"] ~ .sf-hero-group[data-hg="bottom-right"] ~ .sf-hero-group[data-hg="bottom-right"] {
+  grid-row: calc(var(--sf-hg-row) + 3);
+}
+
+/* ── A BUTTON IN A SLIDE BOX SET TO `One row` DROPS ITS FULL-WIDTH FRAME ─────
+   Card `[FIX] Two Buttons Side By Side In A Hero`.
+
+   THE DEFECT. `components/ButtonBlock.tsx` draws a frame that asks for the
+   whole line — `w-full`, or the site frame, which is `w-full` inside a cap.
+   That is right wherever a Button block owns its own row, and it is exactly
+   wrong in the one place a merchant puts TWO of them on one line. Measured in a
+   real browser on this stylesheet before this rule was written, two Buttons in
+   a 1200px Slide box set to `One row`:
+
+     each block 1200px wide, stacked one under the other — two lines, not one.
+
+   Card 66262 had already drawn the right answer and called it THE HERO LOOK:
+   "the button alone, with no frame and no row of its own, because the hero puts
+   BOTH its buttons in one row". It reached the component as a `hero` prop set
+   by the slide's own built-in button — and that button was deleted when the
+   hero moved onto Boxes (#1280), so the prop had no caller left and the look
+   was unreachable. This is that look, restored where it can actually be reached.
+
+   ⚠️ IT IS A RULE AND NOT A PROP, AND THAT IS THE WHOLE MECHANISM. The question
+   is "what is holding this block?", and the block cannot answer it: it renders
+   on the published site, where there is no document to walk, and every block in
+   a hero is a server component, so there is no React context to read either.
+   `components/HeroGroup.tsx` makes the identical call one tier up for
+   `--sf-hg-w` and states the reason there in full — CSS already knows, so the
+   answer is asked where it is free. `lib/puck/config.tsx`'s cell-width pass is
+   the same shape for the EDITOR half of a position question.
+
+   ⚠️ TWO SELECTORS, BECAUSE THE EDITOR ADDS A LAYER. Puck 0.20 wraps every slot
+   child in a drag element unless the component declares `inline`; the published
+   page has no wrapper (HeroGroup's own docblock carries that measurement, card
+   66290). So the first line is the page and the second is the canvas.
+
+   ⛔ `:not(.sf-hero-group)` IS LOAD-BEARING. A Slide box may hold a Slide box,
+   and that inner box answers this question FOR ITSELF — it carries its own
+   `Direction`, so it matches this rule on its own when it is a row and must not
+   be reached through its parent when it is `Stacked`. Without it, a button in a
+   stacked box inside a one-row box would silently lose its width.
+
+   ⚠️ NOT GATED ON THE DESKTOP. Below 800px the block above turns this container
+   into a column while the `flex-row` class stays on it, so this rule still
+   applies — and it must: `align-items` is unset on a Slide box, so a flex item
+   with `width: auto` is STRETCHED to the column, which is the full-width button
+   a phone already draws. A `min-width: 801px` gate here would give the phone
+   two shrink-wrapped buttons instead, which nobody asked for.
+
+   UNLAYERED, like every rule in this section, and here that is load-bearing
+   rather than incidental: `w-full`, `max-w-*`, `mx-auto` and `px-*` are all
+   Tailwind utilities inside `@layer utilities`, and an unlayered rule beats a
+   layered one whatever their specificity. */
+.sf-hero-group-blocks.flex-row > .sf-button-block,
+.sf-hero-group-blocks.flex-row > *:not(.sf-hero-group) > .sf-button-block {
+  width: auto;
+  max-width: none;
+  margin-inline: 0;
+  padding-inline: 0;
+}
+
+/* ── ON A PHONE THE NINE SQUARES BECOME ONE COLUMN (card 66255) ──────────────
+
+   THE DEFECT THIS FIXES IS A COLLISION, NOT A MISSING FEATURE. The layer above
+   is ONE grid column and an anchor resolves to a grid ROW, so a band's three
+   anchors deliberately SHARE a row and are pulled apart by `justify-self` —
+   correct on a wide screen, and what makes today's hero expressible. The
+   sibling chains above only drop a group that shares an ANCHOR with the one
+   before it, so a `left` group and a `right` group sit in ONE cell at every
+   width. At the default 60% each, that is 120% of the slide.
+
+   Measured in a real browser on this stylesheet before the block was written,
+   two groups anchored left and right with a 28px heading in each:
+
+     375px   left 20 → 221   right 154 → 355   both top 242 → 355
+             OVERLAPPING BY 67px, on identical vertical bounds.
+     1280px  left 40 → 259   right 989 → 1240  both top 298 → 372
+             side by side, 730px of clear air. Correct, and untouched below.
+
+   ⚠️ THE CONTAINER CHANGES, THE CHILDREN DO NOT. `grid-row` is INERT on a flex
+   item, so nothing here has to out-specify the ~60 lines of sibling chains
+   above — and a `grid-row: auto` override could not have: those chains are four
+   classes and four attributes deep and a media query adds no specificity. Turn
+   the container into a single-line column and every box gets a line of its own
+   by the flexbox model itself. The chains stay exactly as they are and come
+   back untouched at 801px.
+
+   Both boxes are laid out here: `.sf-hero-group-layer` holds the slide's own
+   copy and the zone, `.sf-hero-group-zone` holds the groups. Two containers,
+   one column — the copy first because it is first in the document, and the
+   document order is the reading order. There is deliberately no `order:` here:
+   sorting the column by band would move the box without moving the markup, so
+   a screen reader and the tab key would disagree with the screen.
+
+   THE PHONE LINE IS 800px, WHICH IS THE HERO'S OWN. The picker hides below it,
+   the arrows hide below it, the slideshow's bottom dots appear below it and the
+   slide's type and padding step down at it — see lib/hero-phone-stack.ts, which
+   carries the number for the guard to read (a media query cannot take a custom
+   property, so it is spelled out here too). */
+@media (max-width: 800px) {
+  .sf-hero-group-layer {
+    display: flex;
+    flex-direction: column;
+    flex-wrap: nowrap;
+    /* The slide's own padding steps down HERE rather than on the element (card
+       66265). It used to be `max-[800px]:px-5 max-[800px]:pt-[100px]
+       max-[800px]:pb-[90px]`, which Tailwind compiles to
+       `@media (width < 800px)` — one pixel short of this block's own line — so
+       at exactly 800px THIS DIV was a phone column with desktop padding on it.
+       The values are the ones those three utilities emitted, `--spacing` and
+       all, so a phone renders the pixels it rendered before the move. */
+    padding-inline: calc(var(--spacing) * 5);
+    padding-top: 100px;
+    padding-bottom: 90px;
+    /* The two rows the Hero asks, as the merchant's own answer or the default
+       every published hero already draws: bottom, left. The FALLBACKS carry the
+       default rather than the component writing it, so an unasked hero renders
+       the same style attribute it rendered before this card — see
+       `heroPhoneStackStyle`, and keep the two in step. */
+    justify-content: var(--sf-hero-phone-y, flex-end);
+    align-items: var(--sf-hero-phone-x, flex-start);
+  }
+  .sf-hero-group-zone {
+    display: flex;
+    flex-direction: column;
+    flex-wrap: nowrap;
+    /* The zone is the column's full width even when the column hugs a side, so
+       a group is aligned against the SLIDE and not against the widest group
+       beside it. Without this the layer's `align-items` shrink-wraps the zone
+       and `Sideways` would move the whole block instead of each box. */
+    align-self: stretch;
+    align-items: var(--sf-hero-phone-x, flex-start);
+  }
+  .sf-hero-group {
+    /* A group's stored width is a % of the SLIDE. 60% of 375px is 201px — a
+       number nobody chose — so in the stack a group may use the whole column
+       and its box is as wide as its own words, which is what leaves `Sideways`
+       something to move. */
+    max-width: 100%;
+    /* ±40px is a fine adjustment against an ANCHOR. There is no anchor in a
+       stack, and 40px of a 375px screen is 11% of the picture — enough to push
+       a box under the slide's own `overflow: hidden`. */
+    translate: none;
+  }
+  /* …and the blocks INSIDE a group stack too (card 66264). A group may be set to
+     `One row`, which is a wide-screen answer: on a phone a heading beside a
+     button is the same collision this whole block exists to prevent, one tier
+     down. The stored answer is untouched and comes straight back at 801px.
+
+     IT LIVES HERE, IN THIS BLOCK, RATHER THAN AS A `max-[800px]:flex-col` ON THE
+     ELEMENT — which is how components/Flex.tsx spells the same idea, and how the
+     rest of the shop spells every phone rule it has. Tailwind compiles that
+     variant to `@media (width < 800px)`, which stops at 799; this block is
+     `max-width: 800px`, which does not. A group's blocks would therefore have
+     flipped one pixel away from the group's own stack. One line in the block
+     that already owns the hero's phone line keeps the two together, and keeps
+     the number in exactly one place.
+
+     UNLAYERED, like every rule in this section, and here that is load-bearing
+     rather than incidental: `flex-row` is a Tailwind utility inside
+     `@layer utilities`, and an unlayered rule beats a layered one whatever their
+     specificity. */
+  .sf-hero-group-blocks {
+    flex-direction: column;
+  }
+  /* ── AND THE REST OF THE HERO, MOVED HERE BY CARD 66265 ──────────────────
+     Everything below drew its phone answer from a `max-[800px]:` variant on the
+     element until that card. Tailwind v4 compiles that variant to
+     `@media (width < 800px)`, which STOPS AT 799, while this block is
+     `@media (max-width: 800px)`, which does not — so at a viewport of exactly
+     800px the hero was in two modes at once: the layer, the zone and the groups
+     above had already collapsed to the phone column while these four still drew
+     the wide layout. Card 66264 found that and stepped around it; this is the
+     same move it made for `.sf-hero-group-blocks`, applied to the rest.
+
+     `max-[801px]:` would also have worked and is refused: it leaves a number in
+     the source that reads wrong to everyone who meets it afterwards. The line is
+     800 on both sides, declared once, above.
+
+     UNLAYERED, like every rule in this section, and here that is load-bearing
+     rather than incidental: each of these elements still carries the Tailwind
+     utility for its WIDE value (`py-3.5`, `left-6`), those live in
+     `@layer utilities`, and an unlayered rule beats a layered one whatever their
+     specificity. (Card 66288 took the copy grid and the copy button row out of
+     this run with the rest of the slide's built-in copy; the two that remain are
+     the ticker and the editor's video control.) The values are the ones the removed
+     utilities emitted, so a phone renders exactly what it rendered before.
+     `scripts/test-hero-800-line.tsx` resolves all four at 799, 800 and 801. */
+  .sf-hero-ticker {
+    padding-block: calc(var(--spacing) * 3);
+  }
+  /* Editor-only chrome, and it moves for the same reason as the rest: a control
+     that stepped in at 799 while the slide under it stacked at 800 is the same
+     disagreement, just one a shopper never sees. */
+  .sf-hero-video-control {
+    left: calc(var(--spacing) * 4);
+  }
+  /* ── AND THE HERO'S OVER-MEDIA CHROME, MOVED HERE BY CARD 66270 ──────────
+     The MIRROR HALF of the block above. Those declarations arrived because
+     `max-[800px]:` compiles to `@media (width < 800px)`, which stops one pixel
+     SHORT of this block's line. These two arrive because `min-[800px]:`
+     compiles to `@media (width >= 800px)`, which INCLUDES 800 — exactly as this
+     block does. So at a viewport of exactly 800px the slide had already
+     collapsed into its phone column, above, while the slideshow still drew its
+     DESKTOP chrome over the top of it: the slide picker and the prev / next
+     arrows shown, and the phone's own dot row — the control that is meant to
+     REPLACE them down here — hidden. No width had both.
+
+     `min-[801px]:` would also have worked and is refused, for the same reason
+     `max-[801px]:` was: it leaves a number in the source that reads wrong to
+     everyone who meets it afterwards. The line is 800 on both sides, declared
+     once, at the top of this block.
+
+     UNLAYERED, and load-bearing rather than incidental: each element still
+     carries a Tailwind utility for its OTHER answer (`flex` on the rail,
+     `hidden` on the dots), those live in `@layer utilities`, and an unlayered
+     rule beats a layered one whatever their specificity. Same fact card 66265
+     leans on. `scripts/test-hero-800-chrome.tsx` resolves all three elements at
+     799, 800 and 801, and proves these two rules are unlayered from the source.
+
+     THE RAIL IS BOTH FEATURES AT ONCE. `heroOverlayRailClass` in
+     lib/hero-overlay-anchor.ts is the one desktop gate, written once, and the
+     picker and the arrows both read it — so this single selector is why "the
+     arrows follow whatever the picker does on a phone" stays true by
+     construction. Do not give either of them a rule of its own. */
+  .sf-hero-overlay-rail {
+    display: none;
+  }
+  /* The dots are NOT a caller of that gate — they are the phone's own control,
+     drawn inline by components/HeroSection.tsx, and they had to move with it:
+     hiding the picker and the arrows at 800 while these stayed hidden too would
+     leave an 800px visitor no way to change slide at all. */
+  .sf-hero-phone-dots {
+    display: flex;
+  }
+  /* The air between stacked boxes, put on the GROUPS alone and never as a `gap`
+     on the layer. An empty groups zone is still a flex item, so a `gap` would
+     push the copy of every published slide — none of which has a group — 28px
+     off the bottom for no reason anyone asked for. A margin on a box that does
+     not exist costs nothing. */
+  .sf-hero-group-zone .sf-hero-group {
+    margin-top: 28px;
+  }
+  /* ── ON A PHONE THE HERO GROWS TO FIT ITS WORDS (card [FIX] Hero Grows On
+     Phone, GG 2026-10-16) ─────────────────────────────────────────────────
+     The phone column above is bottom-aligned (`justify-content: flex-end`) in
+     a layer that covered a hero of FIXED height (`absolute inset-0` on a
+     `h-[…]` / `h-screen min-h-[680px]` section). Words taller than the hero
+     therefore rose off the TOP of the page, under the site's header:
+     hartesmetal.com/dealers' heading began 181px above the page at 390x844, and
+     hartesmetal.com.au's home slideshow 100px above it at 375x667.
+
+     So on a phone the hero's height is a MINIMUM and its words size it:
+       · the hero (HeroSingle's section, the slideshow's viewport) is a column
+         at least as tall as the height that applies at this width: the set
+         phone height (`--sf-hero-h-m`, which the builder writes on the
+         element), from 720px the set desktop height (`--sf-hero-h-d`; 720 is
+         the height control's own line and picks WHICH height, nothing else —
+         the rule just below this block), or, with no set height,
+         `max(100vh, 680px)`: the pixels `h-screen min-h-[680px]` drew;
+       · the slideshow's track fills that column and is as tall as its tallest
+         slide (a flex row stretches its slides), and each slide is a column;
+       · the word layer joins the flow, fills its hero or slide, and is its
+         width. `width: 100%` and not stretch: the layer keeps `mx-auto` for the
+         wide screen, and in a flex column auto side margins switch stretching
+         off, so it would shrink to its widest word and `lib/fit-words` would
+         never see that word overflow.
+     Words that already fit stay exactly where the bottom-aligned stack put
+     them. 801px and up is untouched.
+
+     HERE, on the hero's one phone line, and not as `max-[720px]:` utilities on
+     the components (17.0.1 did that, and drew the layout on a second line —
+     between 720 and 800 the old overflow stayed). UNLAYERED, like the rest of
+     this block: it must beat the height and position utilities the elements
+     carry for their wide layout. Selected by the hooks the hero already has.
+     `scripts/test-hero-grows-on-phone.ts` resolves every line at 799, 800 and
+     801. */
+  section:not([data-slide-name]):has(> .sf-hero-group-layer),
+  div:has(> .hero-track) {
+    display: flex;
+    flex-direction: column;
+    height: auto;
+    min-height: var(--sf-hero-h-m, max(100vh, 680px));
+  }
+  .hero-track {
+    height: auto;
+    flex: 1 1 auto;
+  }
+  .hero-track > * {
+    height: auto;
+  }
+  section[data-slide-name] {
+    display: flex;
+    flex-direction: column;
+    height: auto;
+  }
+  .sf-hero-group-layer {
+    position: relative;
+    flex: 1 1 auto;
+    width: 100%;
+  }
+}
+/* …and WHICH height is the minimum between 720 and 800: the desktop one, as
+   the builder's own `min-[720px]:h-[var(--sf-hero-h-d)]` says (VIEW_TABLET_MIN,
+   the line the Height control switches on). Only the height is chosen here;
+   the layout above is on the hero's one line, 800. */
+@media (min-width: 720px) and (max-width: 800px) {
+  section:not([data-slide-name]):has(> .sf-hero-group-layer),
+  div:has(> .hero-track) {
+    min-height: var(--sf-hero-h-d, max(100vh, 680px));
+  }
+}
+
+/* ── NEGATIVE GAP = THE BLOCKS OVERLAP (card ss.negative-gap) ────────────────
+   The other half of `containerGapProps` in lib/content/container-gap.ts, which
+   is where the whole argument for this shape is written down. In short: CSS
+   `gap` rejects a negative length outright — `gap: -12px` is an invalid
+   declaration, the browser drops it, and the page lays out exactly as it does at
+   `gap: 0` (measured in Chromium 2026-09-03). So below zero the render stops
+   asking `gap` and pulls the blocks together with a margin instead.
+
+   HALF THE OVERLAP ON EVERY CHILD, and the same half given back to the slot as
+   padding. Two neighbours each move half way, so they meet the full overlap
+   inside each other, and the group's own outer edge does not move at all. The
+   half arrives as `--sf-gap-overlap`, because it is a runtime number and a class
+   cannot carry one.
+
+   ⚠️ NOT `> * + *`, which is one rule shorter and wrong twice: on a wrapping row
+   it indents the first block of every line after the first (CSS cannot see that
+   the line broke), and between grid rows it does nothing at all, because grid
+   rows are tracks rather than siblings. Both measured failing first.
+
+   ONLY REACHED BELOW ZERO. Nothing on this page is emitted for a gap of 0 or
+   more, which is what makes this card unable to move a single live site: the
+   floor was 0 until today, so no stored document holds a negative.
+
+   UNLAYERED, like the hero rules above, so these beat the Tailwind utilities the
+   same elements carry. */
+/* ── The gap between the blocks inside a container ────────────────────────────
+   The LENGTH arrives as `--sf-gap-len` from lib/content/container-gap.ts, which
+   sets it to either a stored number (`24px`) or, when the container is
+   inheriting, the site token with that container's own built-in as the fallback
+   (`var(--sf-block-gap, 24px)`). So the cascade does the inheriting and no site
+   value is ever plumbed through React to get here.
+
+   ⚠️ HALVED BELOW 800px, UNCONDITIONALLY — owner's ruling 2026-09-03, chosen
+   over "only when the merchant set a value" with the cost stated. Every live
+   page's PHONE spacing therefore changes the day this ships: Grid and Box 24→12,
+   Footer box 16→8, Events 24→12, Product range 8→4, the wheels listing 1rem→0.5rem.
+   DESKTOP does not move by a pixel. This is the ruling, not a bug — anyone
+   reading a "the gaps got smaller on mobile" report should stop here.
+
+   800px is the breakpoint the Gallery already shipped a 2:1 step at
+   (`gap-2 max-[800px]:gap-1`), so the one number every container now halves at
+   is the one number one of them already used, rather than a sixth opinion.
+
+   `calc(… / 2)` rather than a second property from the render: the halving is a
+   RULE, and a rule belongs in the stylesheet where it is stated once, not in
+   four call sites that could each forget it.
+
+   UNLAYERED, like the overlap rules below, so these beat the Tailwind gap
+   utilities the same elements still carry. */
+.sf-gap-zone {
+  gap: var(--sf-gap-len);
+}
+@media (max-width: 800px) {
+  .sf-gap-zone {
+    gap: calc(var(--sf-gap-len) / 2);
+  }
+}
+
+/* The overlap below zero halves on the same screen, for the same reason and by
+   the same ruling. It needs its OWN derived property rather than redefining
+   `--sf-gap-overlap`: a custom property cannot be defined in terms of itself,
+   so `--sf-gap-overlap: calc(var(--sf-gap-overlap) / 2)` is a cycle and CSS
+   throws the whole declaration away — silently, which is the shape of bug this
+   repo keeps writing guards for. One extra name, and the four rules below read
+   it instead. */
+.sf-gap-overlap {
+  --sf-gap-overlap-eff: var(--sf-gap-overlap);
+}
+@media (max-width: 800px) {
+  .sf-gap-overlap {
+    --sf-gap-overlap-eff: calc(var(--sf-gap-overlap) / 2);
+  }
+}
+.sf-gap-overlap > * {
+  /* WHICH BLOCK SITS ON TOP, pinned rather than left to chance — owner's pick
+     2026-09-03: the block LOWER in the Layers list paints over the one above it,
+     and a merchant changes it by dragging in Layers.
+
+     That is already what CSS does between plain siblings, but only while every
+     one of them is unpositioned: measured 2026-09-03, a column of two where the
+     FIRST block alone sets `position: relative` paints the first ON TOP, which
+     would make the answer depend on which block a merchant happened to drop.
+     Positioning them all puts every child in the same class, where tree order
+     decides again — measured restoring later-on-top. A block that sets its own
+     `z-index` still wins, and that is left alone deliberately: it is a block
+     saying something louder than a container default. */
+  position: relative;
+}
+.sf-gap-overlap-block,
+.sf-gap-overlap-both {
+  padding-block: var(--sf-gap-overlap-eff);
+}
+.sf-gap-overlap-block > *,
+.sf-gap-overlap-both > * {
+  margin-block: calc(-1 * var(--sf-gap-overlap-eff));
+}
+.sf-gap-overlap-inline,
+.sf-gap-overlap-both {
+  padding-inline: var(--sf-gap-overlap-eff);
+}
+.sf-gap-overlap-inline > *,
+.sf-gap-overlap-both > * {
+  margin-inline: calc(-1 * var(--sf-gap-overlap-eff));
+}
+
+/* ── Grid cell width (the cell-width card) ──────────────────────────────────
+   How many of a Grid row's positions ONE block takes.
+
+   ⚠️ THE RULE IS WRITTEN TWICE ON PURPOSE, AND DELETING EITHER HALF BREAKS
+   EXACTLY ONE OF THE TWO PLACES THIS RUNS. Puck 0.20 wraps every slot child in
+   a drag element of its own unless the component declares `inline`
+   (components/HeroGroup.tsx carries the measurement, card 66290). So:
+
+     published page   .sf-grid-zone > [data-sf-span]        the block itself is
+                                                            the grid item
+     editor canvas    .sf-grid-zone > *:has(> [data-sf-span]) Puck's wrapper is
+                                                            the grid item, and
+                                                            the attribute is one
+                                                            level inside it
+
+   A rule written only the first way is the defect the hero anchor shipped with
+   for weeks: right on the live site, silently ignored in the editor, and it
+   reads as a styling question rather than a wrapper one. `:has()` is how the
+   width reaches the wrapper — it is the only direction CSS travels upward, and
+   it is already this stylesheet's own idiom (see the lead-ink rules above and
+   the overlay rules in storefront-editor.css).
+
+   NOT `display: contents` on the wrapper, which is the other way to make the
+   block the grid item: Puck MEASURES that element to place a drop and to draw
+   its selection overlay, and `display: contents` removes the box and takes the
+   measurement with it. The same warning is written out at .sf-hero-group-zone.
+
+   A block with NO span stamps no attribute and matches nothing here, so it
+   auto-places into one position exactly as it did before this card. */
+.sf-grid-zone {
+  grid-template-columns: repeat(var(--sf-grid-cols, 3), minmax(0, 1fr));
+}
+
+.sf-grid-zone > [data-sf-span="1"],
+.sf-grid-zone > *:has(> [data-sf-span="1"]) { grid-column: span 1; }
+.sf-grid-zone > [data-sf-span="2"],
+.sf-grid-zone > *:has(> [data-sf-span="2"]) { grid-column: span 2; }
+.sf-grid-zone > [data-sf-span="3"],
+.sf-grid-zone > *:has(> [data-sf-span="3"]) { grid-column: span 3; }
+.sf-grid-zone > [data-sf-span="4"],
+.sf-grid-zone > *:has(> [data-sf-span="4"]) { grid-column: span 4; }
+.sf-grid-zone > [data-sf-span="5"],
+.sf-grid-zone > *:has(> [data-sf-span="5"]) { grid-column: span 5; }
+.sf-grid-zone > [data-sf-span="6"],
+.sf-grid-zone > *:has(> [data-sf-span="6"]) { grid-column: span 6; }
+.sf-grid-zone > [data-sf-span="7"],
+.sf-grid-zone > *:has(> [data-sf-span="7"]) { grid-column: span 7; }
+.sf-grid-zone > [data-sf-span="8"],
+.sf-grid-zone > *:has(> [data-sf-span="8"]) { grid-column: span 8; }
+.sf-grid-zone > [data-sf-span="9"],
+.sf-grid-zone > *:has(> [data-sf-span="9"]) { grid-column: span 9; }
+.sf-grid-zone > [data-sf-span="10"],
+.sf-grid-zone > *:has(> [data-sf-span="10"]) { grid-column: span 10; }
+.sf-grid-zone > [data-sf-span="11"],
+.sf-grid-zone > *:has(> [data-sf-span="11"]) { grid-column: span 11; }
+.sf-grid-zone > [data-sf-span="12"],
+.sf-grid-zone > *:has(> [data-sf-span="12"]) { grid-column: span 12; }
+
+/* The phone. A span is a DESKTOP statement — twelve positions across a phone is
+   unreadable — so below the breakpoint every cell takes one position of a
+   1–3 column row. `grid-column: auto` beats the span rules above on order, not
+   on specificity, which is why this block sits after them. */
+@media (max-width: 800px) {
+  .sf-grid-zone {
+    grid-template-columns: repeat(var(--sf-grid-cols-phone, 1), minmax(0, 1fr));
+  }
+  .sf-grid-zone > [data-sf-span],
+  .sf-grid-zone > *:has(> [data-sf-span]) { grid-column: auto; }
+}
+
+/* A cell's HEIGHT — the same wrapper as the span rules above, and the same two
+   halves ([FIX] Grid Cell Card Stretches In The Editor):
+
+     published page   .sf-grid-zone > *                     the block is the grid
+                                                            item, and the grid's
+                                                            own default stretch
+                                                            makes it the row height.
+                                                            No rule: there is
+                                                            nothing to add.
+     editor canvas    .sf-grid-zone > [data-puck-component] the editor's drag
+                                                            wrapper is the grid
+                                                            item. IT stretches;
+                                                            the block inside it
+                                                            is a plain block, as
+                                                            tall as its words.
+
+   Measured on the Hartes homepage (first Grid, 1440): the white card was 774px
+   live and 638px in the canvas, so the black page showed under it.
+
+   The editor half makes the wrapper a grid of ONE column. Its child — or, through
+   a `display: contents` host the editor adds, its grandchild — is then a grid
+   item, and a grid item stretches to its area, so the block is the cell's height
+   exactly as it is live. `minmax(0, 1fr)` keeps the width what a block child had:
+   the wrapper's own width, allowed to shrink below its content.
+
+   Matched on the attribute, not with `:has()` as the span rules are: a span is
+   a property of the BLOCK, so the rule has to look inside; a stretch is a
+   property of EVERY wrapper in this zone. The published page never carries the
+   attribute, so this cannot touch a live layout. A block declared `inline`
+   carries the attribute on its own root and would become a grid here — none is
+   droppable into a Grid, and scripts/test-cell-stretch.ts holds that.
+
+   Still NOT `display: contents` on the wrapper — see the warning on the span
+   rules above: the editor measures that element for drops and the outline. */
+.sf-grid-zone > [data-puck-component] {
+  display: grid;
+  grid-template-columns: minmax(0, 1fr);
+}
+
+/* …and the same HEIGHT in a Box laid out in one ROW, and in a Slide box set to
+   One row ([FIX] Box Row Children Stretch In The Editor). The same wrapper, the
+   same two halves, one container over:
+
+     published page   row > *                               the block is the flex
+                                                            item, and the row's
+                                                            stretch makes it the
+                                                            row height. No rule.
+     editor canvas    row > [data-puck-component]           the drag wrapper is
+                                                            the flex item. IT
+                                                            stretches; the block
+                                                            inside it is as tall
+                                                            as its words.
+
+   Measured with scripts/probe-row-stretch.tsx on the real Box markup: a block
+   beside a 774px block was 774px live and 638px in the canvas, for a Box row
+   with Align unset or Stretch and for a Slide box row.
+
+   WHICH ROWS. A row stretches unless it was told where to sit, so the selector
+   is "a row with no Start, Center or End on it". That covers Stretch, and an
+   Align never stored (every older Box, every Slide box — the flex default is
+   stretch). A Box with a picture always carries an anchor, so it never matches.
+   The row class is a general one, so the reach was counted in the live config
+   (every block with a slot, rendered): only three zones ever wear it — the Box,
+   the Slide box, and a Footer group set to Horizontal, whose panel always
+   stores Start, Center or End.
+   A Stacked box has no row class, so a column zone never matches — and that is
+   on purpose: there the wrapper already fills the width, and a grid would also
+   stop the block's margins collapsing out of it.
+
+   ⚠️ UNDER 800px A BOX ROW BECOMES A COLUMN AND KEEPS ITS ROW CLASS, so the rule
+   still applies there (and in a Slide box row at 800px and under). That is
+   measured, not assumed: at 390 every height and width is unchanged except one
+   — a block whose words carry a margin was 618px in the canvas and 638px live,
+   because the margin collapsed out of the block into the wrapper. The grid
+   wrapper keeps it inside, so the canvas now draws 638 as live does. A Stacked
+   box still draws 618 in the canvas; that is the column case above, left alone.
+
+   The class names are the ones lib/content/container-direction and
+   lib/content/box-layout emit; scripts/test-cell-stretch.ts §4 reads them from
+   there, so a renamed class goes red there instead of silently matching nothing
+   here.
+
+   `100%` AND NOT THE CELL'S `minmax(0, 1fr)`, and the reason is the width. A
+   grid cell is sized by the grid, so its wrapper may shrink below its words. A
+   flex item is not: its smallest size is its content's, unless the row says
+   otherwise. A `minmax(0, 1fr)` column makes the wrapper's smallest size zero,
+   so a word wider than the row was squeezed in the canvas where live it runs
+   out. A `100%` column is the content's size while the row is measuring, and
+   exactly the wrapper's width once it is laid out — which is what a plain
+   block child was. The probe holds both: every width is unchanged.
+
+   `:not([class])` — ONLY EASEL'S WRAPPER, NEVER A BLOCK'S OWN ROOT. A block
+   declared `inline` (the Slide box) has no wrapper: Easel puts the SAME two
+   attributes on the block's own root, which is already the flex item and
+   already stretched, and must not become a grid. No attribute tells the two
+   apart. Their shape does: Easel draws its wrapper as a bare div with no class
+   (efficient-easel/easel), and every block root draws one. §4 holds both.
+
+   ⚠️ THREE `:not()`s, NOT ONE WITH A LIST, and no comma anywhere in the
+   selector. scripts/css-rules.ts — the reader the hero guards resolve real
+   classes with — splits a rule on its commas, so `:not(.a, .b)` reached it as a
+   bare `.b`, and it handed `display: grid` to the hero's arrows and dot row. A
+   browser reads both spellings the same; §4 holds the reader too.
+
+   Still NOT `display: contents` on the wrapper, for the reason above. */
+.flex-row:not(.items-start):not(.items-center):not(.items-end) > [data-puck-component]:not([class]) {
+  display: grid;
+  grid-template-columns: 100%;
+}
+
+/* ── THE PHOTO WALL'S LAYOUT ────────────────────────────────────────────────
+   The Customer Photo Grid draws one of `lib/content/gallery-layout.ts`'s
+   patterns. THE PER-LAYOUT RULES ARE NOT HERE: nineteen layouts over two tracks
+   is four hundred-odd nth-child rules, and every page would carry all of them.
+   `galleryLayoutCss()` emits the chosen one beside the wall, which is this
+   repo's own inline-<style> idiom (ProductGridSection, ContactLocations, FAQ).
+   What lives here is only what every layout shares.
+
+   ⚠️ NOTHING BELOW APPLIES UNTIL A LAYOUT IS CHOSEN. The class is stamped only
+   by the chosen-layout branch, so every published gallery — all of them today —
+   renders the three-step wall it always has, byte for byte.
+
+   ⚠️ THE ROW HEIGHT IS THE WHOLE REASON THIS BLOCK EXISTS. A tile sizes itself
+   from its WIDTH (`galleryCardRatioClass`, square by default), so a wide photo
+   is automatically a tall photo and "span two rows" would mean nothing. Inside a
+   wall the CELL decides instead: the rows are a fixed height, a two-row photo is
+   exactly twice a one-row photo, and the card stretches to fill whatever it was
+   given. That is what makes a feature photo actually big rather than merely
+   wide.
+
+   The card's own ratio is overridden by specificity, not by `!important` —
+   `.sf-gallery-zone .sf-card` is two classes against Tailwind's one. */
+.sf-gallery-zone {
+  display: grid;
+  grid-auto-flow: row dense;
+  /* One row of the wall. Scales with the viewport so a wall is not a strip of
+     stamps on a wide screen nor a stack of billboards on a small one. */
+  grid-auto-rows: clamp(140px, 15vw, 260px);
+}
+
+/* A cell may be narrower than its content wants; without this a long caption
+   pushes the column wider and the whole wall drifts off the pattern. */
+.sf-gallery-zone > * {
+  min-width: 0;
+}
+
+/* The tile fills the cell it was given, through Puck's wrapper in the editor and
+   directly on the published page — the same "both are the grid item" fact the
+   nth-child rules rely on. */
+.sf-gallery-zone > *,
+.sf-gallery-zone > * > * {
+  height: 100%;
+}
+
+/* …and the card stops deciding its own shape, because the layout decided it. */
+.sf-gallery-zone .sf-card {
+  aspect-ratio: auto;
+  height: 100%;
+}
+
+@media (max-width: 800px) {
+  .sf-gallery-zone {
+    grid-auto-rows: clamp(90px, 26vw, 150px);
+  }
+}
+
+/* ── A SECTION'S OWN BOX, ROUNDED ───────────────────────────────────────────
+   Lewis, 2026-09-04: the corner setting is for the BOX. Before this it was not:
+   `sectionCornerStyle` publishes the radius as custom properties onto a carrier
+   that is `display: contents`, so the value reached anything INSIDE the section
+   that already read a radius — a card, a `rounded-*` utility — and never the
+   section's own edge. Measured the same day on origin/main: of the 71 sections
+   carrying the Shape group, only 20 wear `.sf-card` and had anything inside to
+   catch the value at all. The other 51 include Hero Slideshow, Collections, Stats
+   and Gallery, and he found it by setting 27px on a Hero and watching nothing
+   happen. (Re-measured 2026-09-05; an earlier 22/49 was taken before main moved.)
+
+   ⚠️ THE CARRIER STAYS `display: contents`, AND THIS IS WHY IT CAN. The obvious
+   fix — make the carrier a real box and put the radius on it — is the one thing
+   `lib/puck/config.tsx` says not to do: a block box between a section and its
+   parent breaks a full-viewport cover's `absolute inset-0` and any sticky child.
+   A `display: contents` element generates no box but IS still in the DOM for
+   selectors, and its child is the section's own root — measured 2026-09-05 by
+   walking the rendered React tree of every one: ALL 71 carriers hold exactly one
+   element, none holds more, and none failed to render. (An earlier count of 64
+   was a limit of the measurement, not of the sections.) So this paints the box the section already had rather than adding one,
+   and the layout is untouched at every value.
+
+   ⚠️ AND IT ONLY EXISTS WHEN THE SECTION HAS CHOSEN. The carrier is emitted only
+   for a section with its own corner (an inheriting one returns the render
+   untouched), so this selector matches nothing on an untouched page and the
+   zero-regression claim `test-section-corners` makes is unchanged.
+
+   `overflow: clip` for the reason `.sf-card` uses it rather than `hidden`: a
+   rounded box whose photo runs to its own edge would otherwise wear a square
+   image over a round corner, and `clip` does that without making a scroll
+   container — so a sticky child inside a section keeps working.
+
+   ⚠️ IT READS `--sf-section-radius`, NOT THE CARD PROPERTY, AND THAT IS THE
+   WHOLE OF THE TWO-TIER SPLIT. It read `--sf-card-radius` for one day, which
+   meant the section's own edge and every card inside it were one number and
+   could never differ — Lewis asked for a Product Grid rounded one way with its
+   product cards rounded another (2026-09-04). The two properties are named and
+   explained in lib/content/section-corners.ts. That control now exists — a row on
+   the CARD BLOCK, where Lewis ruled on 2026-09-05 it belongs — and it writes a
+   THIRD property, `--sf-card-box-radius`, so this rule is still the section's own
+   edge and nothing else. The fallback `0` costs nothing today and is what stops
+   this rule painting a box on any future carrier that arrives without a section
+   radius. */
+.sf-section-corners > * { border-radius: var(--sf-section-radius, 0); overflow: clip; }
+
+/* ── A SECTION'S (AND A BOX'S) OWN BORDER ────────────────────────────────────
+   Box Border, approved by Lewis 2026-10-15. efficient-web-builder 17.0.0's one
+   resolver (`lib/content/borders.ts`) publishes the Border a section or a Box
+   sets as custom properties on a `display: contents` carrier,
+   `.sf-section-border`, emitted ONLY when the section has a border of its own —
+   so this selector matches nothing on an untouched page. The line is drawn on
+   the carrier's CHILD, the section's own box, as the radius above is.
+
+   Only what was set is published, so each `var()` falls back to "nothing set":
+   an unset side is 0 (no line), an unset style is solid, an unset colour is the
+   site's Borders colour (`--site-line`, the theme's `line`). A Box inside a
+   section that has a border inherits the section's properties for whatever it
+   did not set itself: the Box follows the tier above, as Corners does.
+
+   On a phone the `-phone` properties come first and the desktop ones are the
+   fallback, so an unset phone value follows the desktop. The boundary is the
+   phone padding's below (`not all and (min-width: 720px)`, lib/content/
+   view-tiers' VIEW_TABLET_MIN). scripts/test-section-border-css.ts.
+
+   `.sf-section-border-self` is the same line drawn on the block's OWN root:
+   efficient-web-builder 18.2.0 puts it there for a Box inside a row or another
+   Box, where a carrier would take the row's place and break its layout. The
+   properties sit on that root itself, so the rule reads them the same way. */
+.sf-section-border > *,
+.sf-section-border-self {
+  border-style: var(--sf-border-style, solid);
+  border-color: var(--sf-border-color, var(--site-line));
+  border-width: var(--sf-border-top-width, 0) var(--sf-border-right-width, 0) var(--sf-border-bottom-width, 0) var(--sf-border-left-width, 0);
+}
+@media not all and (min-width: 720px) {
+  .sf-section-border > *,
+  .sf-section-border-self {
+    border-style: var(--sf-border-style-phone, var(--sf-border-style, solid));
+    border-color: var(--sf-border-color-phone, var(--sf-border-color, var(--site-line)));
+    border-width: var(--sf-border-top-width-phone, var(--sf-border-top-width, 0)) var(--sf-border-right-width-phone, var(--sf-border-right-width, 0)) var(--sf-border-bottom-width-phone, var(--sf-border-bottom-width, 0)) var(--sf-border-left-width-phone, var(--sf-border-left-width, 0));
+  }
+}
+
+/* ── A SECTION THAT RUNS EDGE TO EDGE HANDS ITS CARDS BACK TO THE SITE ────────
+   Lewis, 2026-09-10: a card stops following its section when the section
+   ACTUALLY RENDERS EDGE TO EDGE. Such a section has no visible edges, so its
+   corner is off the page and passing that number down would round the cards by
+   a value whose source the merchant cannot see. The class is put on the section's
+   own corners carrier by the injection pass in lib/puck/config.tsx, off
+   `sectionRunsFullWidth` — NEVER off a bare `mode === "full"`, which reads every
+   untouched section as full. lib/content/card-corners.ts carries the whole
+   ruling, including why the site's Hero image switch does not enter it.
+
+   ⚠️ IT LEADS WITH THE CARD'S OWN PROPERTY, and that is what makes source order
+   irrelevant: a card that answered for itself wins here exactly as it wins in
+   `.sf-card` above, whichever rule the cascade happens to pick.
+
+   ⚠️ AND THE FALLBACK IS `--sf-site-card-radius`, NOT `--sf-card-radius`. Inside
+   a section that has its own corner, `--sf-card-radius` IS the section's answer —
+   that is the whole two-tier split — so reaching past it needs a name only the
+   two roots publish. */
+.sf-section-bleeds .sf-card { border-radius: var(--sf-card-box-radius, var(--sf-site-card-radius, 0)); }
+
+/* ── A Scrolling Marquee that sits INSIDE the section next to it ──────────────
+   `lib/sections/ticker-join.ts` carries the why. The short of it: a full-screen
+   section is 100vh, so a marquee under it lands below the fold; joined, the
+   strip takes NO page height and is pinned to the boundary instead, which puts
+   it inside that first screen. The Hero's own strip has always done this with
+   `absolute inset-x-0 bottom-0` (components/HeroSection.tsx) — the box below is
+   what lets a SIBLING section do the same, by putting a containing block on the
+   seam for it to hang off.
+
+   ⚠️ THE `z-index` IS ON THE BOX, NOT ON THE STRIP, and moving it back breaks
+   the thing it protects. The strip's own `z-[2]` (PR #515) lifts it over a
+   pinned Scroll-Over Intro, but a z-index inside a positioned box only orders
+   the box's own children — it cannot lift the pair past a SIBLING section. So
+   the pair's stacking order has to be declared here, on the element that is
+   actually the sibling, and it is the same 2 for the same reason.
+
+   ⚠️ `height: 0` MUST NOT BECOME `height: 0; overflow: hidden`. The strip is
+   entirely outside its box on purpose — that is what "inside the section next
+   to it" means — so any clipping on this element erases the marquee. See the
+   corners rule directly below, which exists because the section-corners carrier
+   would have done exactly that. */
+.sf-ticker-join { position: relative; height: 0; z-index: 2; }
+.sf-ticker-join-above { bottom: 0; }
+.sf-ticker-join-below { top: 0; }
+
+/* ⛔ THE CORNERS CARRIER WOULD HAVE CLIPPED THE STRIP AWAY, and this is the two
+   lines that stop it. `.sf-section-corners > *` (above) rounds and CLIPS a
+   section's outermost box; for a joined marquee that box is the zero-height one,
+   so `overflow: clip` on a 0px-tall element deleted the whole marquee from the
+   page while the panel still reported a corner radius. Lewis asked on 2026-09-07
+   that the border and the corners stay the marquee's own settings, so the fix is
+   to move the rounding one level in — onto the strip, which is the box a
+   merchant is actually looking at — rather than to exclude Ticker from the
+   corners pass and take the control away.
+
+   The specificity is (0,2,0) against the (0,2,0) of the rule above, so these
+   come LAST on purpose: source order is what decides, exactly as the
+   `.sf-section-surface-*` pairs in this file are ordered. */
+.sf-section-corners > .sf-ticker-join { border-radius: 0; overflow: visible; }
+.sf-section-corners > .sf-ticker-join > * { border-radius: var(--sf-section-radius, 0); overflow: clip; }
+
+/* ── A section's phone padding ────────────────────────────────────────────────
+   The phone half of the override ruled by the owner on 2026-09-07: ONE value
+   used on both screens, and a setting MAY also carry a phone value. Set, the
+   phone uses it; unset, the phone follows the desktop value.
+
+   "Unset follows the desktop" is expressed by the ABSENCE of these classes, not
+   by a fallback inside `var()`. lib/content/section-padding.ts emits a class
+   only for the axis that actually has a phone value, so a section with no phone
+   value carries no class, matches no rule here, and renders byte-identically to
+   before this block existed.
+
+   ⚠️ `!important` IS LOAD-BEARING, and it is the reason for the class. The
+   desktop padding is an INLINE style on the same element (sectionPadStyle), and
+   an inline style beats any stylesheet declaration that is not `!important`.
+
+   ⚠️ NO FALLBACK IN THE `var()`, for the same reason the grid block above gives:
+   the class and the property are emitted together, so a fallback here would be a
+   second, invisible answer to a question the render already answered.
+
+   The boundary IS lib/content/view-tiers' VIEW_TABLET_MIN. Written as `not all
+   and (min-width: 720px)` rather than a `max-width` so the literal is the SAME
+   720 the two blocks above use, with no fractional-pixel gap to get wrong. */
+@media not all and (min-width: 720px) {
+  .sf-pad-top-phone {
+    padding-top: var(--sf-pad-t-phone) !important;
+  }
+  .sf-pad-bottom-phone {
+    padding-bottom: var(--sf-pad-b-phone) !important;
+  }
+  /* The sideways pair, and ONLY a Box standing on a picture ever wears these.
+     Owner, 2026-09-09: the card's left and right inner padding has to be
+     settable. No section has a sideways padding and these classes do not give
+     it one — nothing emits them but `components/Flex` for a card. */
+  .sf-pad-left-phone {
+    padding-left: var(--sf-pad-l-phone) !important;
+  }
+  .sf-pad-right-phone {
+    padding-right: var(--sf-pad-r-phone) !important;
+  }
+  /* A picture's PHONE focus (Lewis 2026-10-19: one picture, one dot; the view
+     you drag in sets that view's point). The same split as the padding above:
+     the desktop point is the picture's INLINE `object-position`, and the
+     builder's `phoneFocus` (efficient-web-builder lib/content/phone-focus)
+     adds this class and its variable only when a phone point is set, so a
+     picture without one matches nothing here and draws the bytes it drew. */
+  .sf-focus-phone {
+    object-position: var(--sf-focus-phone) !important;
+  }
+}
+
+/* ── A card owns the room at its own sides ────────────────────────────────────
+   Owner, 2026-09-09, choosing A over B when both were drawn: the card owns it,
+   and the number a merchant sets is the only one.
+
+   ⛔ WHAT THIS UNDOES, AND WHY IT IS NOT A HACK. A block inside a Box still
+   renders its own BlockFrame, and that frame draws the SITE's Side space — so
+   the words on a card sat 40px in from the picture on a wide screen and 24px in
+   on a phone, from a frame that belongs to the block rather than to the card.
+   Stacked under the Box's own frame gutter it read as 80px at the default Width,
+   and none of it was reachable from any panel.
+
+   It is the same defect the owner already ruled on for the axis next door
+   (2026-09-04: a block inside a box does not answer width, the box does). That
+   ruling took the CONTROL away and left the BEHAVIOUR, which is why the gutter
+   was still being drawn.
+
+   ⚠️ SCOPED TO A CARD'S OWN CONTENT LAYER, not to every Box. The class is
+   emitted only where there is a background picture, so an ordinary layout Box
+   and every block on every page are untouched.
+
+   ⚠️ AND IT ZEROES ONLY THE SIDES. `padding-top`/`bottom` on a block are its own
+   spacing control and are left alone; blocks have no sideways spacing control at
+   all, so there is nothing here a merchant could have set. */
+.sf-box-sides > * {
+  padding-left: 0;
+  padding-right: 0;
+}
+
+/* ── A section's height on a phone ────────────────────────────────────────────
+   The phone half of the Height group. Lewis chose 甲 on 2026-09-08: the phone
+   overrides the group AS ONE UNIT, so a section either follows the desktop
+   completely or holds its own mode + number + unit.
+
+   "Follows the desktop" is the ABSENCE of this class, not a fallback inside
+   `var()` — lib/content/section-min-height.ts emits the class only when the node
+   stores a phone MODE, so a section without one matches no rule here and renders
+   byte-identically to before this block existed.
+
+   ⚠️ `display: grid` LIVES HERE, NOT IN THE INLINE STYLE, whenever the phone is
+   the only screen with a height. It is what makes a short section stretch to its
+   minimum, and an inline copy would apply at every width — turning a section the
+   merchant left on `Auto` for the desktop from a block into a grid there. Here it
+   reaches the phone alone.
+
+   ⚠️ `!important` because the desktop's height is an INLINE style on the same
+   element, and an inline style beats any stylesheet rule without it.
+
+   The boundary IS lib/content/view-tiers' VIEW_TABLET_MIN — written as `not all
+   and (min-width: 720px)` so the literal is the same 720 the tier blocks above
+   use. The `@supports` leg mirrors the desktop pair: `svh` where the browser has
+   it, the plain unit as the fallback. */
+@media not all and (min-width: 720px) {
+  .sf-section-minh-phone {
+    display: grid !important;
+    min-height: var(--sf-section-minh-p) !important;
+  }
+  @supports (min-height: 1svh) {
+    .sf-section-minh-phone {
+      min-height: var(--sf-section-minh-ps, var(--sf-section-minh-p)) !important;
+    }
+  }
+}
+
+/* ── A BOX WHOSE GAP IS THE ONLY SPACING ────────────────────────────────────
+   Owner, 2026-09-11: 「为什么 eyebrow 没有padding, 别的text有?」 Every block frames
+   itself with its own vertical padding and no two agree (none / 16 / 24 / 48),
+   so the space between two blocks in a Box has three sources — the block above,
+   the Gap, and the block below. This is the Box saying its Gap is the only one.
+
+   ⚠️ UNLAYERED ON PURPOSE. Written as `[&>*]:py-0` it would be a Tailwind
+   utility, landing in `@layer utilities` beside the `py-4` it must beat, at the
+   same specificity — decided by emission order, with the larger value later. It
+   would do nothing, silently. Unlayered CSS beats every layered rule whatever
+   its specificity, which is why this is here and not a class in the markup.
+
+   `padding-block`, not `padding`: a block's own SIDE padding is its business and
+   several blocks read the site gutter through it. */
+.sf-box-gap-only > * {
+  padding-block: 0;
+}
+
+/* …and a block with its OWN padding is still a block of the Box. Lewis
+   2026-10-16: a Heading or Text has its own padding (Left/Right/Top/Bottom),
+   drawn by the builder's wrapper, `div.sf-section-pad`, AROUND the block's
+   frame. That wrapper is then the Box's direct child, so the rule above zeroes
+   the wrapper and the frame's own `py-4` came back: +32px on the Hartes US
+   footer tagline given 20px on its right. This reaches the frame inside it. The
+   wrapper's own padding is an INLINE style, which this never beats, so what the
+   merchant typed still draws. Unlayered, like the rule above, for its reason. */
+.sf-box-gap-only > .sf-section-pad > * {
+  padding-block: 0;
+}
+
+/* ── A SECTION ANIMATES IN ─────────────────────────────────────────────────────
+   card [ADD] A Section Can Animate In — step two of three. Step one taught the
+   site to answer `prefers-reduced-motion` (#1364, the rule directly below this
+   one); step three draws the Animation tab. This is the motion itself.
+
+   THREE MOTIONS, and the three ideas behind them are written in
+   `lib/content/section-animation.ts` rather than repeated here. What belongs
+   HERE, and nowhere else, is the timing: CSS is what runs it, so the duration,
+   the curve and the distance live in exactly one place and no TypeScript
+   constant restates them. Nothing times this animation from JS — the wrapper
+   ends on the element's own `animationend`.
+
+   ⚠️ EVERY MOTION DECLARES A `from` AND NO `to`, AND THAT IS LOAD-BEARING.
+   A keyframe list with no `to` animates to the element's OWN computed style, so
+   the resting appearance of a section is never described twice. The alternative
+   — `to { opacity: 1; transform: none }` — is a second statement of how the
+   section looks, and it is the statement that would be wrong the first time a
+   section arrives already carrying a transform of its own.
+
+   ⚠️ AND IT IS WHY A DROPPED `animationend` COSTS NOTHING. With
+   `animation-fill-mode: both` the element rests on the last keyframe, and the
+   last keyframe IS its natural appearance. The wrapper clears the state to drop
+   the compositor layer, not to make the content visible.
+
+   ── HOW THE REDUCE-MOTION RULE BELOW REACHES THIS ────────────────────────────
+   It is not asked about anywhere. The rule below sets
+   `animation-duration: 1ms !important` on everything, so an armed section plays
+   its one pass in a millisecond and lands at rest — i.e. it is simply there,
+   which is what "reduce motion" means. `!important` is why order does not
+   matter and why these rules may sit above it. `scripts/probe-section-animation.mjs`
+   reads that back out of a real Chrome with the media feature emulated instead
+   of trusting this paragraph.
+
+   ⛔ AND THAT IS ALSO WHY THE HIDDEN STATE IS NOT A KEYFRAME'S JOB. `armed` is
+   a plain `opacity: 0` written by JS, never by the server, and only ever onto a
+   section that is below the fold with an observer already watching it. See
+   `SECTION_ANIM_STATE` in lib/content/section-animation.ts. */
+@keyframes sf-section-fade {
+  from { opacity: 0; }
+}
+@keyframes sf-section-rise {
+  from { opacity: 0; transform: translateY(24px); }
+}
+@keyframes sf-section-scale {
+  from { opacity: 0; transform: scale(0.96); }
+}
+
+[data-sf-anim][data-sf-anim-state="armed"] {
+  opacity: 0;
+}
+
+[data-sf-anim][data-sf-anim-state="play"] {
+  animation-duration: 600ms;
+  /* Ease-out. A section arrives quickly and settles — the shape every entrance
+     in the house drawings has, and the inverse of the ease-in a thing leaving
+     would take. */
+  animation-timing-function: cubic-bezier(0.22, 1, 0.36, 1);
+  animation-fill-mode: both;
+}
+
+[data-sf-anim="fade"][data-sf-anim-state="play"] {
+  animation-name: sf-section-fade;
+}
+[data-sf-anim="rise"][data-sf-anim-state="play"] {
+  animation-name: sf-section-rise;
+}
+[data-sf-anim="scale"][data-sf-anim-state="play"] {
+  animation-name: sf-section-scale;
+}
+
+/* ── THE VISITOR'S OWN "REDUCE MOTION" SETTING ──────────────────────────────
+   [ADD] The Site Respects Reduce Motion.
+
+   "Reduce motion" is a switch on every phone and laptop. People turn it on
+   because movement on a screen makes them ill — vestibular disorders, migraine,
+   motion sickness — not because they dislike animation. The browser hands the
+   answer to CSS for free and, until this rule, this site threw it away.
+
+   Measured on main, 2026-09-11: 95 files under app/ components/ lib/ carry a
+   `transition-` utility and 3 of them guard it. So 92 files moved for everyone,
+   always. `components/useReducedMotion.ts` is the JS half of this answer and
+   has been here for a while; this is the CSS half it was always missing.
+
+   ── WHAT "REDUCE" MEANS HERE, AND WHY IT IS NOT "KILL EVERYTHING" ──────────
+   The crude rule — every duration to zero — is the one most sites ship, and it
+   is wrong in a way that is easy to miss: it also kills the fades. A focus ring
+   that snaps into place, a menu whose background flicks from one colour to
+   another, a dialog that appears with no fade at all — those transitions carry
+   no movement, so they harm nobody, and removing them makes the interface
+   harder to follow rather than kinder.
+
+   So this rule sorts transitions by WHAT THEY ANIMATE, not by how long they
+   take. `transition-property` is replaced with a fixed list of properties that
+   change only ink and light. Everything the author asked for that is not on the
+   list — transform, translate, height, top, margin, background-position, the
+   whole family of movement — is simply no longer a transitioned property, so it
+   changes instantly. The author's own duration and easing survive on the fades.
+
+   A disclosure that animated its height now opens in one step. That is the
+   intended result and not a regression: a growing box pushes every word below
+   it down the screen, which is exactly the movement being asked about.
+
+   ── ANIMATIONS ────────────────────────────────────────────────────────────
+   A keyframe list cannot be sorted this way — CSS cannot see inside one — so
+   every animation is collapsed to a single 1ms pass. Two decisions in that:
+
+     · NOT `animation: none`. An element whose static styles are invisible and
+       which becomes visible through a `forwards` fill would then never appear.
+       Nothing in this repo is built that way today, but a one-line rule that
+       can hide content later is the wrong default. Running the animation to its
+       end instead always lands where the author meant it to land.
+     · 1ms rather than 0s, so a JS handler waiting on `animationend` still gets
+       its event and does not hang a component half-open.
+
+   The six looping marquees here (the four ticker directions, the integrations
+   wall, the editor's thumbnail strip) each end one iteration exactly one list
+   width along, which is the seam — so they stop where they started and read as
+   a still image, which is the point.
+
+   ── ⚠️ UNLAYERED AND `!important`, BOTH LOAD-BEARING ───────────────────────
+   The card that opened this work asked for the rule inside `@layer base`, on
+   the reasoning that a component needing to keep a motion could then win with a
+   utility. That is the right instinct about escape hatches and the wrong
+   mechanism, and it would have shipped a rule that does nothing at all:
+
+     · `@import "tailwindcss"` orders the layers base → components → utilities,
+       so EVERY Tailwind utility outranks everything in `@layer base` whatever
+       its specificity. All 92 unguarded files move via utilities. Layered here,
+       this rule would lose to every single one of them, silently, and the only
+       way to find out would be to read a computed style.
+     · `@layer utilities` is no better: `*` is specificity 0,0,0 and loses to the
+       `.transition-all` beside it.
+     · Unlayered, it beats all of them — the same cascade fact `.sf-box-gap-only`
+       above relies on, and the inverse of the one `scripts/test-css-layers.ts`
+       guards. That guard is about bare-element RESETS and does not reach `*`;
+       it would not have caught this being layered. `test-reduced-motion.ts`
+       does.
+
+   `!important` then covers the two things being unlayered does not reach: the
+   unlayered class rules in this very file, and inline styles. Three components
+   set an animation inline — the search dialog, the cart drawer, the subscribe
+   popup — and an inline style beats any stylesheet rule that is not important.
+
+   ── THE ESCAPE HATCH ──────────────────────────────────────────────────────
+   `data-motion-keep` on an element exempts it and its subtree. It is written
+   into the selector rather than as a second rule that reverts, so there is no
+   cascade puzzle to solve when reading it, and one grep finds every exception.
+   Nothing carries it today. A motion that genuinely must survive this setting
+   is rare enough to be argued for in review, which is what the attribute makes
+   someone do. */
+@media (prefers-reduced-motion: reduce) {
+  *:not([data-motion-keep], [data-motion-keep] *),
+  *:not([data-motion-keep], [data-motion-keep] *)::before,
+  *:not([data-motion-keep], [data-motion-keep] *)::after {
+    /* Ink and light only. Nothing on this list moves anything on the screen. */
+    transition-property:
+      opacity, color, background-color, border-color, outline-color,
+      text-decoration-color, caret-color, fill, stroke, box-shadow, filter,
+      backdrop-filter !important;
+    animation-duration: 1ms !important;
+    animation-delay: 0ms !important;
+    animation-iteration-count: 1 !important;
+    /* Beats the `html { scroll-behavior: smooth }` reset in @layer base. A
+       scroll the visitor did not ask for is movement like any other. */
+    scroll-behavior: auto !important;
+  }
+}