/* ===================================================================== THE DARK GROUND -- `.joetennis-ground-dark`. SPEC-sitewide-white-ground. Added v1.12.4 (story 1), became the only home for these values in v1.13.0 (story 2). WHAT THIS FILE IS FOR. Until v1.12.3 the dark ground was the `:root` default of site-interactive-states.css, so every surface that declared nothing inherited it and every white surface was a delta someone had to remember. White is the site's palette; dark is a deliberate exception for project case studies. Story 2 inverted that -- `:root` now carries the white ground and this file is the only place the dark values exist. Seven consumers ask for it by name: the six `project` case-study templates and the `/projects/?layout=stacked` archive prototype. THE COMMENTARY BELOW MOVED HERE WHOLESALE FROM `:root`, unedited except where a sentence named its old location. Every derivation these values rest on -- the link-luminance window that USED to force #0f8c9d and the 2026-10-02 reversal that dissolved it, the two fill roles Joe ruled OFF on dark rather than retune, the `` pair that exists because a highlight must contrast with the PAGE -- is argued in place, where the value it argues for lives. It was moved once, with the declarations, rather than summarised in one file and restated in another. THESE VALUES NO LONGER READ THE NEVE PALETTE, and that is the change that makes this ground survivable. Nineteen of them were `var(--nv-primary-accent, #00e5ff)` / `var(--nv-secondary-accent, #a855f7)`, i.e. they resolved from whichever palette was ACTIVE. That was invisible while the active palette was Dark Signal and the site was dark. CAP-5 switches the active palette to a light one -- at which point those nineteen would have repainted the dark templates in the new palette's accent, and the dark ground would have silently stopped being Dark Signal. They are pinned to literals for that reason. Joe's ruling, 2026-09-21: keep the dark grounds in case he wants to use them. A ground that changes colour when someone edits an unrelated Customizer setting is not kept. So: DO NOT REINTRODUCE `var(--nv-*)` HERE. The Neve palette drives Neve's own chrome -- header band, body ink, form fields, the hairline border. This file drives the dark ground. They are separate on purpose now, and the seam is what lets either move without the other. VALUES, NOT RULES -- the standing contract this sheet inherits from site-interactive-states.css. A selector declaring only custom properties is a binding scope and is allowed; a selector declaring a painting property is a rule and stays with its consumer. TWO rules are licensed here, both at the foot of this file, and both for the same reason: they paint something no custom property can reach. 1. The page ground itself. Added v1.13.1 -- see its own note; it is the one thing the seven dark consumers cannot get from anywhere else now that Neve paints from a light palette. 2. The drawer hamburger's `.icon-bar`, which Neve paints through a bare `background-color` with no custom property behind it. Nothing else here may paint, and checks/05 asserts the licensed pair by SELECTOR rather than by counting properties, so a third painter fails even if it reuses one of these property names. LOAD ORDER. Enqueued with a `$deps` edge on `joetennis-site-interactive-states`, never by call order -- WP_Styles reorders the queue freely and a sheet landing ahead of that one silently loses every override, with no visible diff in either file. See functions.php's header. HOW A CONSUMER OPTS IN. One call to `joetennis_child_opt_into_dark_ground()`, which enqueues this sheet AND registers the body_class filter that emits the class. Both halves or neither: the class without the sheet renders white-ground values on a dark page, the sheet without the class renders nothing at all, and neither errors. That is the same two-part-contract hazard the asset map and the `band` flag already exist to make unrepresentable, so it is made unrepresentable the same way -- do not call one half by hand. --------------------------------------------------------------------- */ /* The page half. Body-scoped, so every token inherits down through the page -- including into the footer bar, exactly as the `:root` copy did before the inversion. `.joetennis-site-footer`'s counter-bindings in site-interactive-states.css are unaffected: they bind on a descendant of body, so inheritance settles it and specificity is never consulted. Both `--ground-mark-*` are bound here. `:root` binds them too, at the same values, because no white pair was ever decided and no `` renders on the site -- see the note on them below. That is decided design, not a table waiting to be tidied into symmetry. */ .joetennis-ground-dark { /* ----------------------------------------------------------------- Ground tokens. NOT in token-contract.md -- this story extends the contract with ground-level names so the baseline fallback at the foot of this file has something to resolve from. `bmad-spec` owns that file; the extension is flagged in the story report rather than hand-edited into it. ----------------------------------------------------------------- */ --ground-ink: #e2e8f0; /* body ink on the dark ground */ --ground-ink-strong: #f8fafc; /* heading ink */ --ground-fill: #111827; /* recessed surface fill */ --ground-edge: rgba(226, 232, 240, 0.25); --ground-default-ring: #00e5ff; /* needs its own pair rather than borrowing ink/fill: a highlight has to contrast with the PAGE, so on the dark ground it inverts to a pale block with dark text. Binding it as `color: var(--ground-fill); background: var(--ground-ink)` would read correctly here but only by using each token in the other's role, which contradicts every other rule in this sheet and inverts again on a light ground. Two names, no inversion. */ --ground-mark-fg: #111827; --ground-mark-bg: #e2e8f0; /* ----------------------------------------------------------------- FAMILY A -- interactive states. Transient, driven by input. `--state---`; a bare stem never appears in a rule. Role suffixes: -fg ink, -bd edge, -ring focus ring, -bg fill. Ink/edge/ring re-bind when the ground flips; -bg does not. ----------------------------------------------------------------- */ /* Nav item (primary nav, header + drawer + footer nav) */ --state-nav-rest-fg: #e2e8f0; /* NAV HOVER IS THE MARKER HUE, v1.11.22 (Joe, states bench 2026-09-21). It was the primary accent (cyan) on dark and grey and #0b6b78 on white -- three values for one cell. The bench now sets nav hover equal to nav CURRENT on all three grounds, so this reads the Family B token directly rather than restating its value per ground: every ground already binds `--current-marker`, and hover now follows it for free. Deleting the white header's own `--state-nav-hover-fg` override is the other half of the change. WHAT THIS COSTS, recorded because it is a real trade and not free. Family A and Family B now share a colour on the nav, so "you are here" is carried against "you are hovering" by WEIGHT ALONE (600 vs 500). token-contract.md's precedence rule still holds -- a hovered current item keeps 600 -- but the marker's colour is no longer distinctive on its own. That is the thing to look at in review. Measured, 4.5:1 text floor: dark #a855f7 on #0a0e1a 4.87:1 PASSES; white #8100fc on #ffffff 6.29:1 PASSES; the footer band's #a855f7 on #403f3f 2.65:1 DOES NOT -- same shortfall the footer marker already ships with, and now it reaches hover too. Flagged, not fixed: Joe asked to see this built before tuning. (The white marker was #7a22ce at 7.12:1 and the band #21232b at 3.96:1 until v1.13.3; decisions 3 and 4 of SPEC-revision01-colour-adoption moved both, and the band's half of this shortfall got worse by ruling, not by drift.) */ --state-nav-hover-fg: var(--current-marker); --state-nav-focus-fg: #e2e8f0; --state-nav-focus-ring: #00e5ff; /* Button / CTA -- the theme's only one is Neve's `.button.button-primary` ("Get in touch", header and footer, both from one theme_mod). NOTE the inversion: ghost at rest, FILLED on hover. That is the biggest behavioural change this story ships and it is deliberate (state-values.md, through-line 1). */ --state-button-rest-fg: #ffffff; --state-button-rest-bg: transparent; --state-button-rest-bd: #00e5ff; --state-button-hover-fg: #000000; --state-button-hover-bg: #00e5ff; --state-button-hover-bd: #00e5ff; --state-button-focus-fg: #000000; --state-button-focus-bg: #00e5ff; --state-button-focus-ring: #00e5ff; --state-button-active-fg: #000000; --state-button-active-bg: #00b8cc; /* `dark button.disabled` measures 1.71:1 (#7d7d7d on #00b8cc), under the 4.5:1 text floor. Shipped anyway under this project's existing `opacity: 0.3` disabled convention, which exempts disabled controls from the contrast floor. The two live declarations of it are flush-split.css:619-622 and single-project.css:285-288; flush-split-white.css's rule-3 note only COMMENTS on the convention and declares no opacity of its own. CLOSED: the dark exemption was confirmed in story 1, and story 3 closed the white cell as not-a-defect -- on white, `opacity: 0.3` is the SOLE thing separating disabled from hover, since their colour cells are byte-identical. Do not re-raise either. */ --state-button-disabled-fg: #7d7d7d; --state-button-disabled-bg: #00b8cc; /* Inline body-copy link. REST IS WHITE AND CARRIES AN UNDERLINE. Joe's ruling, 2026-10-02, REVERSING the 2026-09-19 decision this block used to argue for. That one kept a no-underline design and moved the link HUE away from body ink; this one restores the rest underline and takes the brightest ink the ground allows. WHY THE REVERSAL IS NOT A RETUNE OF THE SAME DECISION. The old value was not a preference -- it was forced. Requiring >=4.5:1 against the page AND >=3:1 against body ink left a link-luminance window of 0.1954 to 0.2339, and that window sits entirely BELOW body ink: going lighter would have needed luminance >= 2.5052, which does not exist. So every hue that satisfied both floors was necessarily dimmer than the prose it sat in. #0f8c9d (luminance 0.2129, 4.82:1 on the page, 3.24:1 against ink) was the best cell in that window, not a chosen colour. THE SECOND FLOOR EXISTED ONLY BECAUSE THERE WAS NO UNDERLINE. With the rest state bare, WCAG 1.4.1 falls back to colour alone and compares against SURROUNDING TEXT rather than the page. Put the underline back -- a non-colour carrier, which is exactly what 1.4.1 asks for -- and that comparison stops applying. The ceiling vanishes with it, and the whole range above body ink opens up. SO WHITE IS NOT A COMPROMISE HERE, IT IS THE TOP OF THE RANGE: #ffffff has luminance 1.0 and measures 19.26:1 against the page, the highest ratio this ground can produce. VERIFIED LIVE 2026-10-02 before shipping, by injecting these declarations at this sheet's own position on /projects/cdroms-kiosks/ (the one dark page whose template emits the enumerated prose regions) and reading the computed style off a fixture anchor: colour rgb(255,255,255), text-decoration-line `underline`, offset 2px, and Neve's own `--linkdeco` resolving to `underline` too -- so the two decoration paths agree rather than one silently losing to the other. The old constraint is not being violated, it is being dissolved. WHAT WHITE WOULD HAVE COST WITHOUT THE UNDERLINE, recorded because it is the trap a future edit walks into. #ffffff against #e2e8f0 body ink is 1.23:1 -- numerically the SAME failure that retired the old brand cyan, which measured 1.25:1 there and was dropped because "the link was invisible AS a link to anyone not perceiving the hue." White arrives at that number from the opposite direction. The underline is the entire reason this value is legal. DO NOT REMOVE THE REST UNDERLINE WITHOUT MOVING THE INK BACK INTO THE WINDOW ABOVE. HOVER GOES DOWN TO THE TEAL, #0f8c9d -- Joe's ruling 2026-10-03, replacing the white-on-white hover v2.0.3 shipped. Nothing on this ground is brighter than white, so the colour step has to be downward or absent; v2.0.3 chose absent and carried hover on thickness alone. This chooses the step. #0f8c9d IS THE DARK-GROUND TEAL AND #0b6b78 IS NOT, which is the one thing to get right here. Both read as "the site's teal" and they are the same hue at 83% saturation, differing only in lightness -- but on THIS page #0f8c9d measures 4.82:1 and #0b6b78 measures 3.11:1. #0b6b78 is the WHITE ground's value, derived against a #ffffff page, and it fails here. AND THE UNDERLINE DOES NOT RESCUE IT, which is the trap worth spelling out because this file's own reasoning invites the mistake. Everything above argues from WCAG 1.4.1, where an underline IS the fix: it supplies a non-colour carrier, so the ink stops having to clear a floor against surrounding prose. 1.4.3 is a DIFFERENT criterion -- text against its own background, 4.5:1, and no decoration affects it. Rest at #ffffff clears it at 19.26:1 so it never came up; a hover that moves the ink down has to clear it on its own. 4.82:1 does. Do not reach for #0b6b78 on the grounds that "the underline covers it." THE STEP IS 3.99:1 REST -> HOVER (19.26 vs 4.82 against the page), far clearer than the 2.85:1 the pre-v2.0.3 pairing had, and the underline thickens 2px on top of it. checks/05 7d pins this value for the #0b6b78 reason above. THE RING IS STILL NOT MOVED WITH THE INK, and the reasoning is unchanged by any of the above: a focus ring is non-text and needs 3:1 against the GROUND rather than against prose, so it stays on the brand accent at 12.52:1. It is now the only thing on an inline link that is not white, which is what makes focus distinguishable from hover at a glance. */ --state-link-rest-fg: #ffffff; --state-link-hover-fg: #0f8c9d; --state-link-focus-fg: #ffffff; --state-link-focus-ring: #00e5ff; /* The underline the two floors above trade against. `none` at :root -- the white ground still runs the bare-rest design and its own derivation is a separate open question (see legal.css's block on #0b6b78 measuring 2.85:1, under the floor). This ground is the only one that underlines at rest today. */ --state-link-rest-decoration: underline; /* Carousel control. THE FILL ROLE IS NEW IN STORY 5, and it exists because nothing declared it. The bench draws `bg: none` on all five carousel cells, so no rule here ever set `background-color` -- which left Neve's `button:hover { background-color: var(--primarybtnhoverbg) }` free to paint #a855f7 on hover, measured live 2026-09-19. That is the Family B "you are here" purple appearing on a FAMILY A state: the exact family collision CAP-6 exists to prevent, arriving through a property nobody named rather than through a wrong value. Bound to `transparent` rather than left undeclared, for the same reason `--state-chip-hover-bg` is: a ground where a carousel fill DOES work supplies a value here instead of having to add a rule back. Only the two painted states need it -- `:focus-visible` and `:disabled` inherit whichever of rest/hover is also in play. */ --state-carousel-rest-bg: transparent; --state-carousel-rest-fg: #f8fafc; --state-carousel-rest-bd: rgba(0, 229, 255, 0.3); --state-carousel-hover-bg: transparent; --state-carousel-hover-fg: #00e5ff; --state-carousel-hover-bd: #00e5ff; --state-carousel-focus-bd: #00e5ff; --state-carousel-focus-ring: #00e5ff; --state-carousel-disabled-fg: #f8fafc; --state-carousel-disabled-bd: #00e5ff; /* Breadcrumb link. NEW IN STORY 2, and a contract extension: token-contract.md names no breadcrumb stem and state-values.md has no breadcrumb row, yet CAP-2's success criterion names the control explicitly ("the same control type ... in a dark template and a white template"). Flagged for bmad-spec rather than hand-edited into the companion. Rest ink is deliberately absent: a breadcrumb at rest is ground ink, not a state, and flush-split/simple-stack both take it from `color: inherit`. The focus RING is absent for the same reason -- the baseline `a:focus-visible` already paints one. HOVER FOLLOWS THE MARKER AS OF 2026-09-21 (Joe), the same as nav. It used to be the accent cyan here and #0b6b78 on white -- and both were the LINK family's *rest* colour out of the bench, i.e. the breadcrumb's hover was painted with a value that means "not hovered". On white that read as an unexplained green. Joe's call: "I'd like to change that to be the same purple hover color every other link has." WRITTEN AS `var(--current-marker)` IN EACH GROUND BLOCK, never once at `:root` -- and that is load-bearing, not style. A `var()` is substituted where it is DECLARED, so a single `:root` declaration would resolve against `:root`'s marker and inherit downward as a literal, ignoring every ground below it. That is exactly the live defect logged against `--state-nav-hover-fg` in deferred-work.md. Declaring it inside each block that also declares `--current-marker` is what makes the indirection ground-correct. If a fourth ground is added, it needs its own line here too. FOCUS IS DELIBERATELY NOT CHANGED. The bench's link focus fg is #00E5FF on dark and #0B6B78 on white, which is what these already carry -- focus keeps a resting-weight ink and is distinguished by its ring, so it is correct as it stands and only hover was wrong. Measured, 4.5:1 text floor: #a855f7 on the dark page ground #0a0e1a is 4.87:1 PASSES; #8100fc on #ffffff is 6.29:1 PASSES. */ --state-breadcrumb-hover-fg: var(--current-marker); --state-breadcrumb-focus-fg: #00e5ff; /* Archive filter chip. `-rest-bg` completes the fill role (story 5, after review). It was the last literal left on a chip rule -- archive-project.css carried `background-color: transparent` directly, which is a value doing a token's job and the one thing this whole spec exists to remove. It also made the acceptance grep look clean while a chip rule held a literal, because that grep only matched shorthands. */ --state-chip-rest-bg: transparent; --state-chip-rest-fg: #e2e8f0; --state-chip-rest-bd: #ffffff; --state-chip-hover-fg: #00c7fc; /* The decided cell is #000000, which measures 1.09:1 against this ground -- it renders as no fill at all. Shown to Joe on the live archive 2026-09-19; he ruled the fill role OFF on dark rather than retune it, so hover moves ink and edge only. Bound to `transparent` rather than deleted from the rule, so a ground where the fill DOES work (white hovers to a cyan fill) supplies a VALUE here instead of having to add a rule back -- which is the whole contract. */ --state-chip-hover-bg: transparent; --state-chip-hover-bd: #ffffff; --state-chip-focus-bd: #a855f7; --state-chip-focus-ring: #00e5ff; /* ----------------------------------------------------------------- FAMILY B -- current / selected. Persistent. Describes location or selection, NOT input. Never a value of Family A. Naming trap: CSS `:active` means "pointer is currently down". "The active nav item" is `--current-marker`, and archive-project.css's `.is-active` denotes a SELECTED chip, which is Family B. Do not read `.is-active` as `:active`. ----------------------------------------------------------------- */ --current-marker: #a855f7; --current-selected-fg: #a855f7; /* The decided cell is #000000, which measures 1.09:1 against this ground -- it renders as no fill at all. This is the SAME question story 2 answered for `chip.hover`, and it takes the same answer: the fill role is OFF on dark, bound to `transparent` rather than deleted, so the white ground still supplies a value. Joe confirmed it against a live render on 2026-09-19, choosing it over a retuned #7A22CE fill that would have kept the shipped loudness. What carries selection here instead: purple ink AND a purple edge AND weight 600 AND the x. That is three non-colour carriers, which is why the strict "colour is never the sole carrier" rule still binds Family B even though story 2 excepted chip HOVER from it. */ --current-selected-bg: transparent; --current-selected-bd: #a855f7; /* `--ground-band` IS DELIBERATELY ABSENT FROM THIS BLOCK, and this note exists so the absence is visible where the missing binding would go rather than only upstream. :root binds 53 roles; this block binds 52. The 53rd is #e4e4e4, added v1.13.8 (SPEC-archive-card-design CAP-2), and both its consumers -- the Portfolio archive's grid layout and the Flush Split White band -- are white-ground. No dark equivalent of that grey has been drawn, and picking one here would be inventing design; the precedent is `--ground-mark-*`, which is annotated in both places for the same reason. THE HAZARD IS REAL THOUGH, and it is the one this file's header warns about: the token is bound at :root, so it INHERITS into every dark page unrebound. Nothing reads it here today. The first dark rule that does will paint a white-ground grey on a dark page with every check green -- so if you are adding that rule, bind the role here in the same edit and restore checks/05's plain role-set equality. */ } /* FAMILY C -- shape -- IS NOT HERE, AND MUST NOT BE ADDED. Radius is component-level and ground-independent by site-interactive-states.css's own contract: a value chosen for the dark ground stays correct on white, and Family C keeps its own block, never inside a per-ground override. All six `--shape-*` tokens stay at `:root`. `.joetennis-ground-dark` binds 52 roles; `:root` binds 52 white ones plus those 6, which is why the two blocks are never compared wholesale. */ /* --------------------------------------------------------------------- THE HEADER HALF, in three binding scopes. WHY THE PAGE HALF DOES NOT REACH THESE. Neve's header builder declares `--bgcolor` on the header containers themselves and `--color` on each `.item--inner`, so a value bound on `body` never arrives -- the same finding the white ground recorded for the white chrome, in the opposite direction. THE FIRST TWO WERE ADDED IN STORY 1, WHILE THEY WERE STILL INERT, and that was the point. Neve's `darkMode` palette painted the header directly, so they restated what was already on screen -- measured live on dev.joetennis.com against installed v1.12.3 at `/projects/?layout=stacked`, then the site's only live dark consumer: `--bgcolor` computed #0a0e1a on `.hfg_header`, `#header-grid`, `.header-menu-sidebar` and `.header-menu-sidebar-bg`; `--color` computed #e2e8f0 on both `.item--inner` scopes. CAP-5 changes that palette, at which point Neve paints every header light including on these templates, and CAP-4's bar is byte-identical paint. Binding them while a dark render still existed to measure is what stopped story 2 having to characterise the header ground while the default was inverting. THE THIRD SCOPE IS STORY 2'S, and it exists because the inversion moved the burden. Story 1 recorded that dark needed only two scopes where white needed three, because white's third re-binds seven `--state-*` roles that DIFFER from the shared default and dark WAS that default. `:root` is white now, so that is no longer true: the white header values are the ones that fall through, and the dark header is the one that has to ask. The seven roles below are `:root`'s own pre-inversion values, restoring the dark header CTA and focus ring exactly as they were. SPECIFICITY -- THE `body` PREFIX IS LOAD-BEARING, do not tidy it away. These match the retired `.joetennis-ground-white` selectors at (0,2,1) exactly. site-interactive-states.css records why, and the reasoning transfers whole: written first at (0,2,0) the white rules measured correct but were WEAKER than the ones they replaced, and the mechanism that lets a rule here beat Neve's header ground was never characterised -- a live CSSOM probe could not locate the rule Neve declares `--bgcolor` through. Matching the known-winning specificity exactly is the only safe move; raising it is guessing and lowering it is the mistake that paragraph exists to prevent. */ /* Nav and wordmark ink. Scoped to the header's two rows ONLY: six more `.item--inner` live in the footer, and a bare selector would re-ink them against the #21232b band they were measured on. */ body.joetennis-ground-dark .header--row .item--inner, body.joetennis-ground-dark .header-menu-sidebar .item--inner { --color: #e2e8f0; } /* The header GROUND. The backdrop is included (it is part of the ground); it holds no controls, which is why the state scope below omits it. */ body.joetennis-ground-dark .hfg_header, body.joetennis-ground-dark .header-menu-sidebar, body.joetennis-ground-dark .header-menu-sidebar-bg { --bgcolor: #0a0e1a; } /* The header's state token values -- the seven roles whose dark value differs from the white ground now serving `:root`. `--state-nav-rest-fg` IS DELIBERATELY ABSENT and this is not a gap: no rule in site-interactive-states.css consumes it, because nav rest ink is left to Neve's own `.nav-ul li a { color: var(--color) }`, which the ink rule above already re-binds to #e2e8f0. Binding the token too would give one cell two sources that could drift. NOT SCOPED TO THE BACKDROP, and not to the footer. The footer's own "Get in touch" renders on the #21232b band and takes its values from `:root` plus `.joetennis-site-footer`'s counter-bindings -- which is the same division of labour the white header scope used, inverted. */ body.joetennis-ground-dark .hfg_header, body.joetennis-ground-dark .header-menu-sidebar { --state-button-rest-fg: #ffffff; --state-button-rest-bd: #00e5ff; --state-button-focus-ring: #00e5ff; --state-nav-focus-ring: #00e5ff; --state-button-active-bg: #00b8cc; --state-button-disabled-fg: #7d7d7d; --state-button-disabled-bg: #00b8cc; } /* --------------------------------------------------------------------- THE PAGE GROUND. Added v1.13.1, and it closes a real regression that v1.13.0 shipped. WHAT WENT WRONG, recorded because the shape of the mistake is the useful part. Through v1.12.3 nothing in this repo ever painted a dark page: Neve did it, from the active `darkMode` palette, and the ground sheets supplied only VALUES on top. CAP-5 changed the active palette to a light one -- correctly, that is the whole spec -- and at that moment the paint under all seven dark consumers vanished. None of the six template sheets carries a body background of its own; every one of them had been relying on the palette. Measured live at v1.13.0 on `/projects/?layout=stacked`: body painted #ffffff while `--ground-ink` was still #e2e8f0, i.e. a white page wearing the dark ground's tokens -- links at 4.0:1, focus rings at ~1.5:1, and any Tier-4 bare element rendering near-white on white. IT WAS FORESEEN AND STILL MISSED. The gap was raised at story 1's checkpoint, the header half was fixed there, and the page half was explicitly deferred to story 2 -- which then deleted the white paint rules without adding the dark one. Deleting a rule because "Neve paints it natively" is only safe for the ground Neve actually paints. The other ground needs its own. WHY IT LIVES HERE RATHER THAN IN SEVEN CONSUMER SHEETS. The contract says a painting rule stays with its consumer, and that was right while the paint differed per template. It does not differ: all seven want the same page ground, and putting it in seven files would rebuild exactly the duplication the v1.11.18 extraction removed. One rule, in the file that owns the ground, deleted with it -- which is also what keeps CAP-3's promise that removing the dark ground is one file and one enqueue. SPECIFICITY, VERIFIED LIVE BEFORE SHIPPING rather than reasoned about. Neve paints `body { background-color: var(--nv-site-bg) }` at (0,0,1) from style-main-new.min.css, which loads AFTER every child sheet. This selector is (0,1,1), so it wins on specificity and source order cannot take it back -- confirmed by inserting this exact rule into the LAST stylesheet of the live page, the most hostile position available: body computed rgb(10, 14, 26) and rgb(226, 232, 240), matching the v1.12.3 baseline byte for byte. The ink half is here for the same reason as the background: Neve sets `body { color: var(--nv-text-color) }`, which a light palette makes #16191d. `--ground-ink` is a token the Tier-4 rules read; nothing binds `body { color }` to it, so the page's own ink has to be stated. */ body.joetennis-ground-dark { background-color: #0a0e1a; color: #e2e8f0; } /* --------------------------------------------------------------------- THE SECOND LICENSED RULE, and the one line no ground can carry as a value. Neve draws the drawer close button's three bars at #e2e8f0 through a bare `background-color` with no custom property behind it, so there is nothing to re-bind and a ground that wants a different colour must declare a rule. THE WHITE GROUND USED TO PAY THIS COST TWICE. The same #000000 line was duplicated byte-identically in flush-split-white.css and archive-project.css, and checks/05 policed the two copies against drift because it was the only residue of the v1.11.18 extraction. Story 2 deleted both: white is the default, so the drawer's white treatment is now whatever Neve paints plus the baseline, and the DARK consumers are the ones that need a counter-rule. This is it -- one rule, in the file that owns the ground, which is why the third copy was never added. Specificity (0,4,0), matching the two retired white copies exactly. Neve's own rule is lower and loads later; four classes beat it either way. */ .joetennis-ground-dark .header-menu-sidebar .navbar-toggle .icon-bar { background-color: #e2e8f0; }