/* Theme Name: Chumuk Theme URI: https://chumuk.com/ Author: Chumuk Description: Block theme for Chumuk. Token layer plus the C33/C02/C37/C16 skeleton, the C04 hero, the C01 marquee, the C05 bento grid and the C06/C34 ingredients carousel. Requires at least: 6.7 Tested up to: 7.0 Requires PHP: 8.0 Version: 0.4.0 !! BUMPING THE FIELD ABOVE DOES NOT BUST ANY CACHE !! It is theme metadata only, and WordPress requires it. The cache-buster for this stylesheet and for every theme script is the file's own mtime, via chumuk_asset_version() in functions.php [checklist section 10.78 r4]. Editing this file changes what a browser fetches without touching the field above; the field was retired as the cache-buster because it has to be remembered, and in audit 06 it was not. License: GNU General Public License v2 or later License URI: http://www.gnu.org/licenses/gpl-2.0.html Text Domain: chumuk Tags: block-theme, full-site-editing */ /* ========================================================================== TOKEN LAYER — build step 1 (build-specs/f-foundation.md) Every colour value referenced below is SAMPLED from the comp per checklist §3.11 and defined once, in theme.json settings.color.palette. Nothing here restates a hex. 🔴 THE COMP MOVED 2026-08-27 [§10.157]. design/ no longer exists — it mixed the client's confidential archive with our own artefacts under one name. ~~wp-content/design/pink-new-3.png~~ -> wp-content/design-source/comp/pink-new-3.png EVERY `design/…` PATH IN THE PROVENANCE COMMENTS BELOW MAPS THE SAME WAY: the comp to design-source/comp/, the source images (BG-1.jpg, expert-scene.png, glass-hydration.png, ice-band-bg.jpg, doodles-white.png, footer-card-tile.png, footer-doodles-ref.png, ingredient-images/, expert-guidance-icons/) to design-source/assets/. Those comments were left in their original wording on purpose — they are contemporaneous measurement records, and rewriting a path inside each one would add noise to the evidence. Full table: docs/claude-code-agent-instructions.md item 3. NOTE (spec defect F-D1, see build report): design-tokens.md §2 requires a per-value `SAMPLED from wp-content/design/pink-new-3.png` comment in theme.json AND style.css. JSON has no comment syntax, so the provenance note lives here for the whole palette. Component CSS starts in the build-step-2 layer below. ========================================================================== */ :root { /* --- Semantic aliases — design-tokens.md §2.1.2 ------------------------ */ --chumuk-bg: var(--wp--preset--color--white); --chumuk-surface: var(--wp--preset--color--ice); --chumuk-surface-alt: var(--wp--preset--color--pink-soft); --chumuk-surface-warm: var(--wp--preset--color--sand); --chumuk-text: var(--wp--preset--color--ink); /* §10.30 SITE-WIDE RULE — on ANY light-or-mid brand ground (cyan, pink, pink-deep, pink-soft, pink-ghost, ice, sand, mint, lime, lime-pale, all three veils) text is `ink`, NEVER white. `--chumuk-text-invert` is ONLY for genuinely dark grounds: `ink` itself and the §15.4 flavour DEEP tones. Do not add a darkened `cyan-deep` — REJECTED, it collides with Natural Bliss deep #0A7C96. See design-tokens.md §2.1.2. */ --chumuk-text-on-brand: var(--wp--preset--color--ink); --chumuk-text-invert: var(--wp--preset--color--white); --chumuk-primary: var(--wp--preset--color--ink); /* buttons */ --chumuk-secondary: var(--wp--preset--color--cyan); --chumuk-accent: var(--wp--preset--color--pink); --chumuk-success: var(--wp--preset--color--green); --chumuk-error: var(--wp--preset--color--red); --chumuk-warning: var(--wp--preset--color--gold); /* --- Bare-channel companions of two palette slugs — §10.192 ------------- */ /* 🔴 THESE ARE NOT NEW COLOURS. They are `forest` and `blue-deep` — both already registered in theme.json (slugs 18 and 11) and both already emitted as `--wp--preset--color--*` — restated as bare `R G B` channels. WHY THEY HAVE TO EXIST: C05's brand-tinted wash needs a TRANSLUCENT palette colour, and `rgb( / )` is not legal CSS. The alpha must be applied to channels, so the channels must be available separately. WHY THEY ARE HERE AND NOT IN theme.json: `--wp--preset--color--*` names are GENERATED by WordPress from palette slugs, and `17 58 0` is not a colour value, so no palette entry can produce them. The name is the design's own [chumuk-homepage.dc.html :root] and is kept verbatim so the design file and the theme spell the token identically. ⚠️ THE TWO HALVES MUST MOVE TOGETHER. Changing #113A00 in theme.json without changing `17 58 0` here silently desynchronises C05's tint from C10's ink, and nothing computes to `unset` to warn you — the wash simply becomes a different colour from the one it was contrast-solved against. */ --wp--preset--color--forest-rgb: 17 58 0; /* #113A00 — theme.json slug `forest` */ --wp--preset--color--blue-deep-rgb: 2 63 130; /* #023F82 — theme.json slug `blue-deep` */ /* ➕ §10.193, when the wash became a registered block style and `ink` joined the offered set. Same rule as the two above: the value is theme.json's, restated as channels because CSS has no `rgb( / )` form. */ --wp--preset--color--ink-rgb: 52 52 52; /* #343434 — theme.json slug `ink` */ /* --- Derived surfaces — design-tokens.md §2.1 -------------------------- */ /* Translucency over a parent. A flat hex would be wrong. ⚠️ ~~these are the only colour values in this file, and none of them is a palette entry~~ AMENDED at §10.192: the two `*-rgb` companions above are also colour values, and they ARE palette entries — restated as channels because CSS has no `rgb( / )` form. Everything in THIS block remains non-palette. */ /* ⚠️ THE OLD COMMENT WAS WRONG AND IS CORRECTED HERE [§10.98 / D]: this token has TWO consumers, not one. Besides `.chumuk-hero__card` it also fills the SELECTED flavour thumbnail's plate — `.chumuk-hero__variants input:checked + .screen-reader-text + .chumuk-hero__variant-jar`. Any future change to this value moves the selected-state plate too. Same class of defect as §10.82 r8's veil-light: a token's scope comment trusted instead of grepped. */ --chumuk-veil-card: rgb(255 255 255 / 0.50); /* the selected switcher plate. NO LONGER the hero card — see below */ /* 🔴 THE C04 HERO CARD'S OWN VEIL — MEASURED OFF THE COMP, APPLIED 2026-08-24 BY OWNER RULING 1 [checklist §10.126]. SPLIT FROM `--chumuk-veil-card` RATHER THAN CHANGING IT, because that token has TWO consumers (see the note above) and the switcher plate is not part of this ruling. Same split as `veil-card` / `veil-light` and `verdict-yes`. HOW 0.20 WAS OBTAINED, and why it is not a guess: the comp's hero ground just above the card reads rgb(234,138,184) — which is the palette's own `pink` #EA8AB8, EXACTLY — and the veil just inside reads rgb(238,162,198). Solving v = a*255 + (1-a)*g per channel gives a = 0.190 / 0.205 / 0.197. 🔴 THE THREE CHANNELS AGREEING TO WITHIN 1.5 % IS WHAT PROVES THE OVERLAY IS WHITE AND NOT A PINK TINT — a tinted overlay solves to three different alphas. Round-trip check: white@0.20 over rgb(234,138,184) computes rgb(238,161,198) against the comp's measured rgb(238,162,198) — one channel out by 1/255. */ /* 🔴 DARKENED AT §10.192 so the card's white copy is legible — and SPLIT IN TWO, because one token was doing two unrelated jobs. It painted the hero CARD and the switcher's jar PLATES, which the comp specifies as "both 20% white": darkening a single token would have dragged the plates dark with the card. The plate keeps the measured design value under its own name; only the card's ground changes. ⚠️ 0.68 IS SOLVED, NOT CHOSEN BY EYE: white text needs the ground under it at <= 118.6 per channel for 4.5:1, and `ink` #343434 at alpha a over a worst-case PURE WHITE region of the photograph gives 255 - 203a <= 118.6, so a >= 0.672. 0.68 is the first hundredth clear of it, which is why it holds on all four variant photographs rather than on the one that was checked. ⚠️ ~~--chumuk-hero-card-veil: rgb(255 255 255 / 0.20)~~ SUPERSEDED. The old value is not deleted; it moves to `--chumuk-hero-plate-veil` below. */ --chumuk-hero-card-veil: rgb(52 52 52 / 0.68); --chumuk-hero-plate-veil: rgb(255 255 255 / 0.20); /* 🔴 THE C10 VERDICT ICONS' OWN ROLE TOKENS [F19, checklist §10.101]. The tick used the `green` preset directly and MEASURED **2.43:1** against the composited comparison card `rgb(251,255,255)` — under WCAG 1.4.11's 3:1 floor for a graphical object. 🔴 THE SHARED `green` TOKEN IS DELIBERATELY NOT DARKENED. `green` backs `--chumuk-success`, whose real consumers — the newsletter confirmation and form states — are still UNBUILT. Changing it would pre-empt those surfaces with no measurement behind the choice. So the ROLE gets its own property and the shared token is left alone: the same split as `--chumuk-veil-card` / `--chumuk-veil-light`. ➕ AND IT COINS NO NEW COLOUR. `mint-ink` is already in the palette and is already this build's icon-glyph green (C35's discs). Measured against the same composited card it gives **5.51:1** — not a marginal pass. A hue-preserving darkening of `green` was the alternative and reached only 3.11:1, i.e. it would have invented a colour to scrape the floor. ⚠️ The cross is UNCHANGED. `red` measures **3.97:1** on the same card and already clears the floor; it takes a role property here for symmetry, with the same value it always had. */ --chumuk-verdict-yes: var(--wp--preset--color--mint-ink); --chumuk-verdict-no: var(--wp--preset--color--red); /* [MEASURED] the comp's hero jar leans 12deg counter-clockwise — axis-of- symmetry fit over three y-bands, rms 1.26-1.37 px [§10.98 / B]. */ --chumuk-hero-jar-tilt: -12deg; /* [MEASURED] all four jar attachments are 1707 x 2560 = 2/3 [§10.98 / A1]. */ --chumuk-hero-jar-aspect: 2 / 3; /* 🔴 AN ALPHA IS MEANINGLESS WITHOUT ITS GROUND [checklist §10.82 r8, design-tokens.md §2.4]. VALUE CORRECTED 2026-08-19: 0.18 → 0.42. GROUND IT IS DERIVED AGAINST: the step card is nested INSIDE `--chumuk-veil-strong`'s 0.85 white inner card, not laid on the section photograph. Over 0.85 white the largest delta 0.18 can produce is ~7/255 and the rendered delta measured 0/255 — a structurally invisible card. 0.42 is the comp's own value, sampled at 11 x positions just inside and outside the step card's top edge in pink-new-3.png (range 0.379–0.490, flat — a plain veil over a gradient ground, not a gradient veil). So: 0.18 was a reasonable veil OVER A PHOTOGRAPH and useless over an 0.85 veil. Do not reuse this token on a different ground without re-deriving the alpha for that ground — C13 and C15 both have veils ahead of them. */ --chumuk-veil-light: rgb(255 255 255 / 0.42); /* nested step-card veil, over --chumuk-veil-strong */ /* ROLE, NOT SECTION [checklist §10.82 r8]: this reads "near-opaque card veil over a photographic ground" — that is the contract. It was coined for C10's card over BG-2.jpg (not built yet); today its ONLY rendered consumer is C08's inner `.chumuk-howto` card at line ~2809, which is why the old "C10 card over photo" comment had become false. A comment that names a consumer instead of a role goes stale the moment a second consumer arrives. */ --chumuk-veil-strong: rgb(255 255 255 / 0.85); /* 🔴 12 % -> 20 % 2026-08-22 [F4, checklist §10.101]. ~~`rgb(52 52 52 / 0.12)`~~ composited over white to **#E7E7E7**; the comp's C09 rules measure **(214,214,214) = #D6D6D6** at all five rows. Anti-aliasing can only LIGHTEN a 1 px line, never darken it, so the gap was real rather than a sampling artefact. 20 % is solved, not guessed: 255 - 0.20 x 203 = 214.4 -> #D6. F4 was deferred at step 6 because this token is SHARED with the bento, the carousel and the FAQ — and step 12 is the pass that owns exactly that. Every consumer was re-measured on its own ground; see the step-12 report. */ --chumuk-border-hairline: rgb(52 52 52 / 0.20); /* C09 rules, FAQ dividers, C10 table, trust bar, footer base, carousel ring */ --chumuk-border: var(--chumuk-border-hairline); /* --- The two-tone focus ring's LIGHT COMPANION [checklist §10.82 r4] ---- Both tones are existing tokens and NO value is coined: the dark tone stays theme.json's `--wp--custom--focus-ring` (#1A1A1A, §15.4) and the companion is the `white` PALETTE entry. Its width is aliased to the ring's own width rather than restated, so the two can never drift (§3.11 define-once). The rule that consumes these — and the reason a single dark ring is unsatisfiable over a photograph — is the standing block below the button focus rules. */ --chumuk-focus-ring-companion: var(--wp--preset--color--white); --chumuk-focus-ring-companion-width: var(--wp--custom--focus-ring-width); /* --- Spacing — design-tokens.md §2.3 ---------------------------------- */ --chumuk-section-pad: clamp(48px, 6vw, 80px); /* C37 banner height — [DERIVED at build step 2]. c37-page-banner.md: "Height and spacing are [DERIVED] — no comp exists for any non-front page. Shorter than the C04 hero; define once as a token so all templates match." The C04 hero band is 1030 px (design-tokens.md §2.5); this ceiling is 320 px, well under it, and the floor keeps the banner usable at 375. */ --chumuk-banner-min-height: clamp(200px, 18vw, 320px); /* C02 header action-icon box — [MEASURED] from pink-new-3.png: the icon row runs y 87–112, x 1615–1780. Declared once here because the icons are now supplied by WooCommerce blocks whose own stylesheet does not size them (measured 0 × 0 on the rendered page). */ --chumuk-header-icon: 26px; /* 🔴 THE TWO HEADER CONTROL BOXES — §10.192, from the finalised homepage. The GLYPH stays 26 (above); these are the BOXES around it. WCAG 2.5.5 wants 44 × 44 and the account link, the cart button and the hamburger were all rendering at the glyph's own size. The cart is 45 and not 44 because the design measures it at 45 — the mini-cart button's own box in the comp — and a 1px difference between two adjacent boxes is not worth normalising away against a measured value. */ --chumuk-header-action-box: 44px; --chumuk-header-cart-box: 45px; /* THE C05 BENTO CARD CORNER RADIUS — the C05 bento cards are now the only thing it actually paints, plus the SHARED `.chumuk-carousel__media` base rule that C06 overrides and C13 inherits at step 8. [MEASURED] from pink-new-3.png by tracing the corner arc: bento card B top-left runs y 1411 x716 → y 1425 x702, an arc of 14 px. 🔴 THIS TOKEN NO LONGER SERVES THE C06 INGREDIENT CARD MEDIA, AND ITS 16 px CAME FROM THAT NOW-SUPERSEDED READING [checklist §10.69 r2]. The 16 was a consolidation of TWO single-corner traces that disagreed by 2 px — the bento's 14 px above and the first ingredient card's media at y 2531 x156 → y 2546 x140 (arc 16 px) — resolved by taking the larger. §10.69 r2 retired the C06 media reading: that card is one continuous card and takes the canonical --chumuk-card-radius-lg (20 px) top and bottom, measured far more rigorously (twice per card across four cards, with an arc-centre cross-check). ⚠️ THE VALUE DELIBERATELY STAYS 16 px. §10.69 r2 retired one reading on one element; it did NOT re-measure the bento. The bento's own trace is 14 px, so 14-vs-16 goes to §3.10 — a narrower question than before, because only one section now depends on the answer. ⚠️ Still deliberately NOT merged into --chumuk-card-radius-lg below: checklist §10.68 r2 refuses to merge 12 px and 16 px into 20 px "by assumption", because they may be genuinely distinct, and §10.69 r2 states that refusal still stands. */ --chumuk-card-radius: 16px; /* THE CANONICAL CARD RADIUS — [MEASURED], and the consolidation of two measurements of one design radius [checklist §10.68 r2]. It was --chumuk-hero-card-radius (20 px, step 3, measured on the hero card box at x 140–660 / y 700–915) and --chumuk-card-panel-radius (19 px, build fix 05, measured twice per card on all four C06 description panels — see the padding token below for the method). The two land 1 px apart on different comp surfaces, and tracing a curve in a raster carries ±1 px of anti-aliasing error, so §10.68 r2 rules them ONE radius measured twice: the rounder value is canonical, which also avoids re-pointing the hero. Named for CARDS, not for the hero, because its consumers are the hero card, the hero switcher jar plate and the C06 ingredient card panel. */ --chumuk-card-radius-lg: 20px; /* C05 body-scrim panel corner — [DERIVED at build step 4]. The comp draws a chip behind the card TITLE only (fully rounded, y 1458–1522) and no panel behind the body copy, so there is nothing to measure: the body scrim is an accessibility addition (c05-bento.md's "scrim or overlay where it fails"), and a pill radius on a three-line block reads wrong. Sized against the card radius above rather than invented independently. */ --chumuk-bento-panel-radius: 12px; /* ~~[MEASURED] the comp's bento title chip, by differencing rows inside it against rows above and below: least-squares white alpha 0.116. --chumuk-bento-chip-veil: rgb(255 255 255 / 0.12)~~ SUPERSEDED at §10.192. 🔴 THE CHIP IS NO LONGER OPAQUE `ink` AND NO LONGER A WHITE WASH. C06's 23 carousel labels drop `has-ink-background-color` and take this veil instead, so the photograph reads through the chip. The alpha is the same 0.68 the hero card is solved at, and for the same reason: white copy needs its ground at <= 118.6 per channel, and `ink` #343434 at alpha a over a worst-case pure-white region gives 255 - 203a <= 118.6, i.e. a >= 0.672. ⚠️ THIS IS THE ONE PLACE ON THE PAGE WHERE A PHOTOGRAPH CAN NOW REACH A TEXT GROUND. It was 12.45:1 by construction before, on an opaque fill; it is now a measured value per card. Pixel-sampled on all 23 — see report 73. */ --chumuk-bento-chip-veil: rgb(52 52 52 / 0.68); --chumuk-bento-pad-top: 71px; --chumuk-carousel-gap: 19px; --chumuk-ingredient-media-h: 407px; --chumuk-ingredient-panel-h: 187px; --chumuk-ingredient-panels-gap: 44px; --chumuk-ingredient-pad-bottom: 42px; --chumuk-ingredient-tabs-gap: 67px; /* ⚠️ ~~--chumuk-tabs-pad-block: 5px~~ · ~~--chumuk-tab-w: 166px~~ — BOTH RETIRED at §10.192. The 166 was a real measurement (four label inks solving for one equal tab width twice over, 4 × 166 = 664 against the comp's 665 strip) and the tabs are no longer equal-width, so it describes nothing that renders. Removed rather than left declared and unused — a token no rule reads is a maintenance trap. */ /* ====================================================================== SHARED TAB TOKENS — C07's store tabs and C34's ingredient tabs are ONE style [§10.192]. 🔴 PROMOTED TO SITE SCOPE, NOT DUPLICATED. These are the store handoff's tab values verbatim; they previously lived only in `--cs-*`, which is declared under `.chumuk-store` and is therefore INVISIBLE to C06 — the same scoping trap already on record for `--cs-cyan`. Copying the hexes into C06 would have put one colour in two places with nothing keeping them equal. Both bands read these now, so the two strips cannot drift. ⚠️ The two whites are written as the palette slug rather than as the design file's `#FFFFFF`: a registered slug exists, so a literal is not justified. Same computed value; the only place this file departs from the design's literal bytes, and it is declared in report 73 §2.4. ⚠️ The other three literals have NO palette slug — they are the store's own `--cs-dark` / `--cs-grey` / `--cs-tab-hover`, verified identical here and re-pointed AT these tokens in the C07 commit so the value exists once. ====================================================================== */ --chumuk-tab-gap: 4px; --chumuk-tab-strip-pad: 6px; --chumuk-tab-strip-bg: var(--wp--preset--color--white); --chumuk-tab-strip-shadow: 0 2px 14px rgba(158, 27, 60, 0.08); --chumuk-tab-ink: #6B6068; --chumuk-tab-hover-bg: #F6EEF2; --chumuk-tab-active-bg: #232323; --chumuk-tab-active-ink: var(--wp--preset--color--white); --chumuk-tab-font-size: 13px; --chumuk-tab-tracking: 0.12em; --chumuk-tab-pad-block: 14px; --chumuk-tab-pad-inline: 44px; /* [MEASURED] from the comp's card shadow — 17/255 of darkening at the edge over a 20 px falloff is 0.07 of `ink` at the peak of a 20 px blur. */ --chumuk-card-shadow: rgb(52 52 52 / 0.14); /* 🔴 C07's nine comp-measured geometry tokens are SUPERSEDED and removed — ~~--chumuk-store-pad-top: 65px~~ ~~--chumuk-store-pill-h: 40px~~ ~~--chumuk-store-rail-card-h: 78px~~ ~~--chumuk-store-rail-card-pad: 22px~~ ~~--chumuk-store-row-gap: 64px~~ ~~--chumuk-store-rail-card-pad-x: 32px~~ ~~--chumuk-store-pad-bottom: 45px~~ ~~--chumuk-store-title-gap: 30px~~ ~~--chumuk-store-desc-gap: 45px~~ Each was measured from pink-new-3.png for the rail-and-segmented-control layout the 2026-08-26 handoff replaces. Every one was verified to have ZERO remaining `var()` consumers before deletion, not assumed unused. The handoff's own geometry lives with its rules in the C07 block below. Struck rather than silently dropped — build-reports/47, §3. */ --chumuk-howto-pad: 91px; --chumuk-howto-veil: rgb(255 255 255 / 0.75); --chumuk-howto-col-gap: 67px; /* Card DESCRIPTION-PANEL padding — [MEASURED] from pink-new-3.png by tracing the ingredients band (checklist §10.67 r1, build audit 04 MINOR 1). The comp draws each ingredient item as one rounded panel with the media flush at its top and the description below on the panel's own ground, which is what makes it read as a card — joined into one continuous card per checklist §10.68 r3. 🔴 THE RADIUS THIS BLOCK USED TO DECLARE IS RETIRED. --chumuk-card-panel-radius (19 px) was consolidated into --chumuk-card-radius-lg (20 px) by checklist §10.68 r2 — see that token above for the reasoning. The 19 px derivation is kept here because it is the [MEASURED] evidence behind the canonical value. METHOD, and it is two independent derivations of the same arc per card: the panel ground is #E9FBFF against the band's `ice` #E5FBFB, so the panel is separable by exact colour match. On each card the straight left edge, the bottom row's leftmost panel pixel, and the left column's lowest panel pixel give r twice — bottom-row inset and left-column rise. Card 1 left x 140, bottom y 3110, bottom row starts x 159, left column ends y 3091 → 19 and 19. Cards 3, 4 and 5 (left x 803 / 1134 / 1465) repeat it: 19 / 19 / 19, and 19 / 19 / 19 on the right corners. All four panels measure 315 px wide. Padding is the same trace: the description ink starts exactly 20 px inside the left edge on ALL FOUR cards, and card 3's longest line ends 20 px inside the right edge, so 20 px is the box and not a ragged-edge artefact. The glyph-top inset reads 24 px on all four, which is 20 px of padding plus the cap gap of a 16 px / 24 px line box — consistent, not a second value. Named for CARDS, not for C06: the next card panel reuses this rather than coining another literal. ⚠️ design-tokens.md §2.4 records only the 999 px button radius and has no card entry; these are reported in build-fix-05 and build-fix-06 for §2.4 to record — the theme does not own that document. 🔴 DO NOT shave this 20 px to make band arithmetic work [checklist §10.68 r3]: trimming a [MEASURED] value to satisfy a target is how a token stops meaning anything. If the band overflows, the number gets reported, not absorbed. */ --chumuk-card-panel-pad: 20px; /* --- Motion — design-tokens.md §2.6 (all [DERIVED]) -------------------- */ --chumuk-dur-fast: 150ms; --chumuk-dur-base: 300ms; --chumuk-dur-slow: 600ms; --chumuk-ease: cubic-bezier(.2, .7, .3, 1); --chumuk-marquee-dur: 40s; --chumuk-counter-dur: 1600ms; --chumuk-lift: translateY(-4px) scale(1.02); /* --- C07 store rail states — SUPERSEDED 2026-08-26 --------------------- */ /* 🔴 ~~--chumuk-store-rail-hover: #FDF3F7~~ ~~--chumuk-store-rail-darken: 88%~~ Both encoded checklist §15.4's rail-card behaviour: an inactive card that tints to #FDF3F7 on hover, and an ACTIVE card that darkens one step because it was FILLED with the flavour's deep tone. The handoff retires the filled card entirely. Its Option C card stays white with #111 ink in BOTH states and identifies by rail + rimmed dot, so there is no fill left to darken, and the inactive hover is now #e2c9d4 on the BORDER rather than a tint on the ground. §15.4's two values therefore describe a control that no longer exists. ⚠️ The `--chumuk-store-rail-darken` note claimed a derivation calibrated against §15.4's `#87082E` example. That claim was true and is not being overturned — it is simply moot, because the surface it tinted is gone. Struck, not deleted, so the next pass does not re-derive it. Both were verified to have zero `var()` consumers before removal. */ } /* -------------------------------------------------------------------------- Line height per SIZE preset — design-tokens.md §2.2 Keyed to the size preset, never to the heading LEVEL: level and size are independent (§2.2.1, "level ≠ size"), so an

carrying the `h6` token must take the h6 line height. theme.json fontSizes entries cannot carry a line height, which is why these live here. ⚠️ The `h2`–`h6` slugs are emitted KEBAB-CASED by WordPress: the theme.json slug `h2` becomes the class `.has-h-2-font-size` and the property `--wp--preset--font-size--h-2` (_wp_to_kebab_case splits letter→digit). Block markup still uses the documented slug — {"fontSize":"h2"} — but any hand-written CSS or var() reference must use the emitted `h-2` form. Measured on WP 7.0.4, build step 1. See build report finding F-D3. -------------------------------------------------------------------------- */ .has-display-1-font-size { line-height: 1; } .has-display-2-font-size { line-height: 0.91; } .has-display-3-font-size { line-height: 1; } .has-h-2-font-size { line-height: 1.07; } .has-h-3-font-size { line-height: 1.1; } .has-h-4-font-size { line-height: 1.15; } .has-h-5-font-size { line-height: 1.2; } .has-h-6-font-size { line-height: 1.2; } .has-question-font-size { line-height: 1.4; } .has-body-lg-font-size { line-height: 1.56; } .has-body-font-size { line-height: 1.5; } .has-body-sm-font-size { line-height: 1.6; } .has-label-xs-font-size, .has-label-sm-font-size, .has-label-md-font-size, .has-label-lg-font-size { line-height: 1.4; } /* -------------------------------------------------------------------------- The `label` ROLE — design-tokens.md §2.2, checklist §10.40 / §10.51 r1 `label` is a STYLE ROLE, not a size: uppercase + 0.08em tracking + the body face, applied on top of whichever of the four label-* size presets the element takes. It is deliberately NOT a fontSizes entry. The emitted selector is `.is-style-label` (the block style variation registered in functions.php). `.chumuk-label` is the rule's name in prose only and is never emitted. -------------------------------------------------------------------------- */ .is-style-label { font-family: var(--wp--custom--font-body); text-transform: uppercase; letter-spacing: 0.08em; line-height: 1.4; } /* -------------------------------------------------------------------------- THE `sans` HEADING STYLE — checklist §10.97, build-fix-22 F6 Registered on core/heading in functions.php; this is the rule it emits. WHY IT EXISTS. §2.2's `h5` row says serif, and for C35's expert card titles that is correct. It is wrong for C08's step titles: the comp draws "Mix", "Shake" and "Drink" in the sans. Both elements carry the `h5` SIZE token, so the token cannot fix it — a type token carries SIZE ONLY and the family comes from `styles.elements.heading` (§2.2.1). This is the family half of that split, made a reusable role rather than a private fact about C08. WEIGHT 600, MEASURED, NOT ASSUMED. Comp step titles ink: "Mix" 41 x 20, "Shake" 73 x 20, "Drink" 64 x 20 (threshold 128, crop-edge assertion clean on all four sides). Geist 600 reproduces all three within 4.1-8.2 % on width and EXACTLY on height at 27 px; Geist 700 runs 6.2-9.6 % wide on the same strings. 600 it is. ⚠️ THIS RULE DOES NOT CLOSE THE C08 GAP ON ITS OWN — see F10 in build-fix-22. At the `h5` token's 30 px these three strings render 15-19 % WIDER than the comp on all three; the comp's own size is ~26-27 px. The SIZE is a separate, unauthorised question and is REPORTED, not fixed here. ⚠️ It carries NO `letter-spacing`. The `h5` tracking of -0.015em is solved against PLAYFAIR ink on C35's serif titles (§10.95 r3) and must not follow the family across — which is why `.is-style-sans` is excluded from that rule below, exactly as `.is-style-label` is [§10.91 r3: the fit is not uniform across faces OR sizes, so nothing transfers by assumption]. -------------------------------------------------------------------------- */ .is-style-sans { font-family: var(--wp--custom--font-body); font-weight: 600; } /* -------------------------------------------------------------------------- THE DISPLAY SERIF'S WEIGHT, TRACKING AND FIGURES — Playfair Display [checklist §10.87, family unlocked by the owner 2026-08-20] The family changed from Instrument Serif because the comp's headings are a high-contrast Didone and Instrument Serif is a condensed, low-contrast transitional: at a matched 41 px cap the comp's string is 25 % WIDER and its stems twice as thick. Three properties ride with the face, and all three were MEASURED off `pink-new-3.png` rather than chosen: • WEIGHT 500. The comp's `D` at a 41 px cap has an 8 px stem and a 1 px hairline — stroke contrast 8.0. Playfair 500 measures 7 / 1 = 7.0, the closest of every weight tested. 600 matches the stem exactly (8 px) but its hairline thickens to 2 px, halving the contrast match to 4.0. Per-glyph shape overlap against the comp also peaks at 500 (0.713 mean over D,e,p,H,a,o,n, against Instrument Serif's 0.382). • TRACKING -0.048em, h2 ONLY. Playfair's natural advances run ~9 % wider than the comp's at matched cap height. Solved independently over FIVE comp headings — -0.0465, -0.0532, -0.0427, -0.0418, -0.0563 em — mean -0.0481, SD 0.37 px. ⚠️ It is applied to `h2` alone. ⚠️ CORRECTED 2026-08-21 by §10.91 r3, which made the old wording FALSE — it read ~~"h2 is the only role whose tracking was measured; h3–h6 and display-1/2/3 are NOT tracked here"~~. `h3` IS now measured, and its answer is `normal`: at 52 px Playfair's advances run 1.2 % NARROW of the comp — the OPPOSITE sign to h2's 9 % wide — so closing it would need +0.006 em and no declaration is warranted. 🔴 DO NOT "fix" the inconsistency by copying h2's -0.048em down to h3; the fit is not uniform across the size range, which is why each role needs its own measurement. ⚠️ SUPERSEDED 2026-08-21 by §10.95, which made this census FALSE too — it read ~~"Still genuinely UNMEASURED: h4–h6 and display-1/2/3"~~. Measured since: `h4` 38 px / `normal` — DELIBERATELY untracked, its three comp instances disagree by 16 % so there is nothing to match (§10.95 r1); `h5` -0.015em and `h6` -0.011em, both declared BELOW this block, keyed to the SIZE CLASS not the heading level (read the note there before touching them); `display-2` `normal`, 104 → 102 px in theme.json (r2); `display-3` 128 px / `normal` (r6). STILL genuinely unmeasured: `display-1` — the hero ghost word, whose mask no attempt has yet defeated — and `question`. • LINING FIGURES. Playfair's default `0` is 0.5425 em against a 0.7075 em cap — roughly x-height. The comp's "100%" measures 41–43 px against its own 41 px cap, so the comp sets lining figures. Without this the C06 heading's digits render two-thirds height. 🔴 SCOPED `:not( .is-style-label )` ON PURPOSE. `styles.elements.heading` gives every heading the serif; `.is-style-label` swaps it to the body face for the label role (footer column heads, eyebrows, the C04 `h1`). Those keep weight 400 and the label role's own +0.08em tracking, so this treatment must not reach them. ⚠️ At the family change the cap-derived SIZE tokens did not move: display-1, display-2, h2, h4 and h6 all back-solve from the comp's measured ink at a cap ratio of 0.702–0.711, and Playfair's is 0.7075 where Instrument Serif's is 0.7200. The scale was Playfair's all along; only the family name was wrong. ⚠️ CORRECTED 2026-08-21 by §10.95 — the old wording read ~~"The cap-derived SIZE tokens did not change and did not need to"~~, which is no longer true of two of them. §10.94 r2 derived the instrument's own constant: Chromium RASTERISES this face at a 0.724 cap ratio, not the 0.7075 design figure the sizes were divided by, and that 2.3 % gap made three tokens read 2–4 % large. Re-solved on comp INK WIDTH, which does not depend on the ratio: `display-2` 104 → 102 px (§10.95 r2, two strings agreeing to 0.3 %) and `h6` 26 → 25 px (§10.95 r4). ✅ `h2` 58 px, `h3` 52 px, `h4` 38 px and `display-3` 128 px are UNCHANGED and were re-measured to confirm it — `h4` in particular was proposed for 37 px and REVERSED (§10.95 r1): its three comp instances disagree by 16 %, so there is no value to match. 🔴 Do not read the 0.7075 ratio above as a way to derive a NEW size; it is kept because it is what identified the family. Sizes are solved on ink width. -------------------------------------------------------------------------- */ /* ➕ `.is-style-sans` joins `.is-style-label` in the exclusion [§10.97 / F6]. It is not decoration: this rule is `h5:not(...)` = (0,1,1) and `.is-style-sans` is (0,1,0), so WITHOUT the exclusion the serif weight 500 would beat the sans style's own weight and the C08 step titles would render the body face at the display weight. Same mechanism, same fix, as the label role. */ /* ➕ 2026-08-26 — C07's two headings are excluded, using this rule's OWN escape hatch. The store handoff sets no weight on either heading, so both render at the UA's bold 700. This rule overrides that to the display weight 500 site-wide, and at (0,2,1) it outranks a single class — so the section could not simply state its own weight without strengthening a selector, which §9 forbids. Adding the two classes to the exclusion list is the mechanism already here for `.is-style-label` and `.is-style-sans`, and it changes no other heading. ⚠️ Measured before and after: every other h1–h6 on the page still computes 500. */ h1:not( .is-style-label ):not( .is-style-sans ), h2:not( .is-style-label ):not( .is-style-sans ):not( .cs-head__title ):not( .cs-buy__title ), h3:not( .is-style-label ):not( .is-style-sans ), h4:not( .is-style-label ):not( .is-style-sans ), h5:not( .is-style-label ):not( .is-style-sans ), h6:not( .is-style-label ):not( .is-style-sans ) { font-weight: 500; font-variant-numeric: lining-nums; } /* 🔴 RE-KEYED FROM THE LEVEL TO THE SIZE CLASS 2026-08-22 [F21, checklist §10.101]. This read `h2:not( .is-style-label )`, which is the exact anti-pattern §10.95 r2 corrected for `h5` and `h6`: **the value was derived from the comp's 58 px h2 STRINGS, so it belongs to the SIZE, not to the element level.** Keying it to the level meant every `

` on the site took 58 px-derived tracking regardless of what size it actually rendered at. MEASURED before the change, at 1920: `Ready To Feel The Difference?` display-2, 102 px -> -4.896px `Electrolyte` h3 size, 52 px -> -2.496px WooCommerce mini-cart `Your cart` no size class, 32 -> -1.536px WooCommerce `Products in cart` no size class, 24 -> -1.152px None of those four is a 58 px heading and none of them was ever measured. The Woo pair is third-party cart chrome inheriting this build's display tracking purely because it happens to use `

`. ⚠️ THE PROMOTION IS WHAT EXPOSED IT. F21 promoted the store title from `h3` to `h2` to close the page's only skipped heading level; its SIZE token was deliberately unchanged, and the size did hold at 48.67 px — but its tracking silently went `normal` -> `-2.336px` because of this rule. Level and size are independent (§10.35 r2), and so is tracking: it follows the size it was solved against. ➕ `display-2`'s own tracking is now UNSET, and that is the honest state rather than a regression — the -0.048em it was inheriting was never derived for 102 px. Recorded as F22; deriving it needs the comp, and the comp draws the CTA with Version B's headline, which this build does not use. */ .has-h-2-font-size:not( .is-style-label ) { letter-spacing: -0.048em; } /* -------------------------------------------------------------------------- TRACKING for the `h5` and `h6` SIZE tokens — checklist §10.95 r3 and r4 🔴 KEYED TO THE EMITTED SIZE CLASS, NOT TO THE HEADING LEVEL, and the `h2` rule above is NOT the shape to copy here. Level and size are independent (§2.2.1, and see the line-height block near the top of this file): BOTH of these tokens render on `

` elements — C08's three step titles carry `h5`, C06's 23 chip labels carry `h6`, and there is not one `

` or `
` element on the page. An `h5:not(...)` / `h6:not(...)` rule in the `h2` rule's shape would match NOTHING. The `h2` rule can be level-keyed only because the `h2` token happens to land on `h2` elements there. Measured, not assumed. • `h5` → -0.015em. Derived over THREE comp strings at 30 px, to §10.87's multi-string standard: `Clinical Nutrition & Dietetics` solves -0.0179, `Digestive & Gut Health` -0.0175, `General Medicine & Wellness` -0.0090. -0.015em MINIMISES THE SPREAD instead of fitting one string — residuals +0.8 % / +0.5 % / -1.3 %, mean absolute 0.9 %. ⚠️ §10.94 r3 proposed -0.018em from the FIRST STRING ALONE, at which the third lands -2.1 % out. THE SIZE IS NOT CHANGED: 30 px is confirmed exact (§10.94 r3). • `h6` → -0.011em, with the size corrected 26 → 25 px in theme.json (§10.95 r4). The clean instance is `BEETROOT`, the ONLY chip label with no word space, comp ink 129 × 18: at 26 px live is +6.2 % wide, at 25 px +1.6 %, at 25 px / -0.011em +0.8 %. Cap height agrees independently — comp 18, live 18 at 25 px and 19 at 26 px. ⚠️ ONE-STRING derivation, and §10.95 r4 labels it as such: below this project's five-string standard. The other two chip labels are UNUSABLE, not ignored — their inter-word gap measures no wider than their inter-letter gaps and §10.95 r5 could not separate a narrow comp word space from a mask bridging it, so NO `word-spacing` is declared anywhere. 🔴 THE `h6` TRACKING IS SCOPED TO SERIF HEADINGS ON PURPOSE, AND `.chumuk-stat__value` IS THE REASON. C09's four stat values are PARAGRAPHS carrying the `h6` token, and a paragraph does not take `styles.elements.heading` — they render in GEIST 600, not Playfair (the `.chumuk-stat__value` block further down says so explicitly). Both values above are solved against PLAYFAIR ink, and pushing a serif-derived tracking onto a sans face is the transfer §10.91 r3 forbids. The SIZE change does reach those paragraphs — unavoidable, it is the token's own value — but the tracking must not. `:not( .is-style-label )` excludes the body-face label role for the same reason it does on the weight rule above. ⚠️ REPORTED, not decided here: §10.95 anticipated `h6` reaching C06 only. C09's four stat values are a SECOND consumer of the token. ⚠️ `display-2` takes NO tracking declaration — §10.95 r2 solves it at `normal` on both comp lines. Its 104 → 102 px lives in theme.json alone. -------------------------------------------------------------------------- */ :is( h1, h2, h3, h4, h5, h6 ):not( .is-style-label ):not( .is-style-sans ).has-h-5-font-size { letter-spacing: -0.015em; } :is( h1, h2, h3, h4, h5, h6 ):not( .is-style-label ).has-h-6-font-size { letter-spacing: -0.011em; } /* -------------------------------------------------------------------------- LINK STATES — checklist §10.57 r1 theme.json carries the two settled values: colour `ink` and `text-decoration: underline`, in styles.elements.link (plus :hover, :focus, :active and :visited, all pinned to `ink` so no UA state colour — #0000EE unvisited, #551A8B visited — can win by matching the element). 🔴 The underline is NOT optional. Because the link colour is IDENTICAL to body text (`ink` on both), colour conveys nothing, so the underline is the only affordance — WCAG 1.4.1. Do not drop it for aesthetics. Hover and focus change the UNDERLINE, never the colour. Thickness and offset are not expressible in theme.json's typography schema, so they live here. Nav is exempt from the underline (theme.json styles.blocks.core/navigation) — the rules below only touch decoration geometry, so they are inert where the line is `none`. Focus ring: 3 px #1A1A1A at 3 px offset (checklist §15.4). The hex is a fixed a11y value and deliberately NOT a palette entry (§10.30 rejected a muted-text token; `ink` is the muted text colour). It is declared once, in theme.json settings.custom, so no hex literal lives in this file. `:focus-visible`, not `:focus`, per §15.4's wording. -------------------------------------------------------------------------- */ a:where( :not( .wp-element-button ) ):hover, a:where( :not( .wp-element-button ) ):focus-visible { text-decoration-thickness: 2px; text-underline-offset: 3px; } /* 🔴 REMOVED 2026-08-22 [§10.97 / D2 + F8] — folded into the global two-tone rule below. Was: ~~a:where( :not( .wp-element-button ) ):focus-visible { outline: ...; outline-offset: ...; }~~ Its `:where()` already gave it zero specificity, so it and the global rule were the same weight and the LATER one won — meaning links already took the two-tone ring in practice. Deleting it removes a second definition that agreed with the first only by source order. The hover/underline rule above is NOT part of this and stays. */ /* 🔴 THREE BUTTON CONTROLS FROM EARLIER STEPS, WRITTEN AGAINST THE ELEMENTS AND NOT AGAINST `.wp-element-button` [checklist §10.66 r3, build audit 04 MAJOR 3]. §10.65 r4 scoped the focus-ring gap to `.wp-element-button` and recorded step 4 as shipping the build's first buttons. §10.66 r3 CORRECTS that: these three are `