basalt-ui 1.26.0 → 1.28.0

package/src/theme/border-coverage.test.ts

@@ -1,272 +0,0 @@
-/**
- * Border coverage — closes an ABSENCE the `check-theme` guard structurally cannot see.
- *
- * `check-theme`'s regex scans (src/guard/index.ts) can only flag violations that are PRESENT in
- * consumer source — a raw hex, an inline border, a `withBorder` on Card. They can never flag a
- * theme `.extend()` block that was simply never written: Button and ActionIcon shipped with NO
- * entry in `baseTheme.components` at all, so they silently fell through to Mantine's stock
- * `variant="default"` 1px hairline — a real, shipped bug (docs/DESIGN-SPEC.md doctrine inversion
- * #1: depth is `shadow-card`, never a hairline, for every default-variant panel/control; borders-
- * as-borders stay reserved for layout dividers). Nothing short of a mechanical inventory of
- * Mantine's OWN shipped CSS would have caught it before ship.
- *
- * This test IS that inventory: it enumerates every `@mantine/core` component whose shipped CSS
- * declares a real border (`border:` / `border-color:` / a directional `border-*:` / a `--*-bd`
- * custom property — never `border-radius`, which is shape, not edge) and asserts each one is
- * EITHER a themed key in `baseTheme.components` OR carries a written, reasoned entry in
- * `BORDER_ALLOWLIST` below. Mantine's CSS is resolved via the module system
- * (`import.meta.resolve('@mantine/core/styles.css')`), never a hardcoded `node_modules/.bun/…`
- * path, which differs per install/lockfile and would be brittle.
- *
- * THIS TEST IS DELIBERATELY COUPLED TO MANTINE'S INTERNAL CSS. A future Mantine upgrade that
- * introduces a new bordered component (or removes a border from an existing one) SHOULD fail this
- * test — that failure IS the point: it forces a deliberate theme-or-allowlist decision instead of
- * silently shipping a consumer-visible hairline the doctrine says shouldn't exist. Do NOT "fix" a
- * future failure here by loosening the scan, widening the regex, or bulk-allowlisting — classify
- * the new/changed component the same way every entry below was classified: read its shipped CSS,
- * decide whether the border is a real panel/control edge (theme it), a layout divider (allowlist),
- * or not a surface at all (allowlist), and write a one-line reason.
- */
-import { readdirSync, readFileSync } from 'node:fs'
-import { dirname, join } from 'node:path'
-import { fileURLToPath } from 'node:url'
-import * as MantineCore from '@mantine/core'
-import { describe, expect, test } from 'bun:test'
-import { baseTheme } from './index'
-
-// ── Mantine CSS resolution ──────────────────────────────────────────────────────────────────────
-
-// Resolved via the module system — never a hardcoded `node_modules/.bun/@mantine+core@…` path,
-// which differs per install/lockfile hash and would be brittle across machines/CI.
-const MANTINE_CORE_ROOT = dirname(fileURLToPath(import.meta.resolve('@mantine/core/styles.css')))
-const MANTINE_STYLES_DIR = join(MANTINE_CORE_ROOT, 'styles')
-
-// A real border declaration: `border:`, a directional `border-top/-bottom/-left/-right/-inline-
-// start/-inline-end/-block-start/-block-end(-color)?:`, `border-color:`/`border-width:`/
-// `border-style:`, or a `--*-bd` custom property. The negative lookbehind on `[\w-]` excludes a
-// property NAME that merely ENDS in "border" (`--mantine-color-default-border:`,
-// `--app-shell-border-color:`, `--blockquote-border:`) — those are variable DEFINITIONS, not a
-// rendered edge; the file only counts if it also uses that variable in an actual border-family
-// property, which the same regex catches at its own declaration site. `border-radius` never
-// matches — shape, not edge.
-const BORDER_DECLARATION =
-  /(?<![\w-])border(-top|-bottom|-left|-right|-inline-start|-inline-end|-block-start|-block-end|-color|-width|-style)?\s*:|(?<![\w-])--[\w-]*-bd(-[\w-]+)?\s*:/
-
-/** True if `name` is a real, themeable `@mantine/core` factory-component export (`.extend`
- * exists) — filters out non-component CSS files (`default-css-variables`, `global`, `baseline`)
- * and internal, unexported support components (`InlineInput`) that happen to ship their own CSS
- * file but can never be a `theme.components` key. */
-function isThemeableComponent(name: string): boolean {
-  const candidate = (MantineCore as Record<string, unknown>)[name]
-  return typeof candidate === 'function' && 'extend' in candidate
-}
-
-/** Every `@mantine/core` component whose OWN shipped CSS file declares a real border, per
- * `BORDER_DECLARATION` above. Scans the non-layer `.css` files only (`*.layer.css` duplicates the
- * same declarations under Mantine's CSS-layers build; scanning both would just double-count). */
-function borderedMantineComponents(): string[] {
-  const found: string[] = []
-  for (const file of readdirSync(MANTINE_STYLES_DIR)) {
-    if (!file.endsWith('.css') || file.endsWith('.layer.css')) continue
-    const name = file.slice(0, -'.css'.length)
-    if (!isThemeableComponent(name)) continue
-    const text = readFileSync(join(MANTINE_STYLES_DIR, file), 'utf8')
-    if (BORDER_DECLARATION.test(text)) found.push(name)
-  }
-  return found.toSorted()
-}
-
-// ── BORDER_ALLOWLIST ────────────────────────────────────────────────────────────────────────────
-
-type BorderAllowlistEntry = {
-  readonly component: string
-  /** `layout-divider`: the border IS the component's job — a structural boundary between regions/
-   * rows/panes (DESIGN-SPEC's own carve-out: "Layout dividers … still use plain borders — only
-   * card/control depth moved to shadow"). `not-a-surface`: a reset (`border: 0`/`none`), a shape/
-   * affordance ring on a non-panel element, or content styling inside `Typography` prose — never a
-   * `variant="default"` panel/control edge. */
-  readonly kind: 'layout-divider' | 'not-a-surface'
-  readonly reason: string
-}
-
-/**
- * The closed registry of bordered `@mantine/core` components the theme deliberately does NOT
- * theme, each with a one-line reason. Modeled on `GUARD_RULES` (src/guard/index.ts) / `SURFACES`
- * (src/surfaces.ts): every entry is real, reviewable, and reasoned — never a bare string array.
- */
-export const BORDER_ALLOWLIST: readonly BorderAllowlistEntry[] = [
-  // ── Layout dividers ──────────────────────────────────────────────────────────────────────────
-  {
-    component: 'AppShell',
-    kind: 'layout-divider',
-    reason:
-      'Border is opt-in via [data-with-border] on individual navbar/header/footer/aside sections — a structural boundary between page regions, not a default-variant control.',
-  },
-  {
-    component: 'Divider',
-    kind: 'layout-divider',
-    reason:
-      'The layout-divider primitive itself — its border-top/border-inline-start IS the line it draws; already reads the hairline token via the strict-surface lever.',
-  },
-  {
-    component: 'Fieldset',
-    kind: 'layout-divider',
-    reason:
-      'A <fieldset> group container — the border groups related form fields into a labeled section (a structural boundary, like AppShell/Table), not a floating card. Both the default and filled variants intentionally keep the hairline.',
-  },
-  {
-    component: 'Splitter',
-    kind: 'layout-divider',
-    reason:
-      'The resize-handle bar between two panes IS a divider by definition — it separates two layout regions.',
-  },
-  {
-    component: 'Tree',
-    kind: 'layout-divider',
-    reason:
-      'border-top is a tree-line connector drawn between hierarchical rows (--tree-line-color) — a structural row-relationship indicator, the same family as Table row dividers, not a panel surface.',
-  },
-  {
-    component: 'TreeSelect',
-    kind: 'layout-divider',
-    reason:
-      'Same tree-line connector as Tree (--ts-line-color) — a structural row-relationship indicator, not a panel surface.',
-  },
-  // ── Not a surface at all ─────────────────────────────────────────────────────────────────────
-  {
-    component: 'Alert',
-    kind: 'not-a-surface',
-    reason:
-      'No variant="default" exists for Alert (filled | light | outline | transparent | white); its default (light) variant already ships --alert-bd: 1px solid transparent — no stock hairline to fix.',
-  },
-  {
-    component: 'Anchor',
-    kind: 'not-a-surface',
-    reason: 'A text link — border: 0 is a reset, never a rendered edge.',
-  },
-  {
-    component: 'Avatar',
-    kind: 'not-a-surface',
-    reason:
-      'The root avatar ships --avatar-bd: 1px solid transparent by default; the one real border (AvatarGroup, a 2px page-bg ring) separates overlapping stacked circles, not a panel edge.',
-  },
-  {
-    component: 'BackgroundImage',
-    kind: 'not-a-surface',
-    reason: 'border: 0 reset plus a shape-only border-radius var — never a rendered edge.',
-  },
-  {
-    component: 'Blockquote',
-    kind: 'not-a-surface',
-    reason:
-      "A typography/content primitive — border-inline-start is the quote's colored accent bar, its defining visual feature, not a stock hairline.",
-  },
-  {
-    component: 'CheckboxIndicator',
-    kind: 'not-a-surface',
-    reason:
-      "The checkbox glyph box itself — its border is the control's shape/affordance (a native-checkbox-style outline), not a panel edge. Already reads --vx-surface-border via the existing gray-4/dark-4 strict-surface lever.",
-  },
-  {
-    component: 'ColorPicker',
-    kind: 'not-a-surface',
-    reason:
-      'The selected-swatch preview ring (2px solid white) is a shape/preview accent, not a panel.',
-  },
-  {
-    component: 'ColorSwatch',
-    kind: 'not-a-surface',
-    reason: 'border: none — swatch grid tiles are shape-only (border-radius), no rendered edge.',
-  },
-  {
-    component: 'Loader',
-    kind: 'not-a-surface',
-    reason:
-      "The spinner ring's border-color IS the animated graphic itself — a utility/a11y element, not a panel surface.",
-  },
-  {
-    component: 'RadioIndicator',
-    kind: 'not-a-surface',
-    reason:
-      "Same as CheckboxIndicator — the radio glyph's own shape/affordance border, not a panel edge.",
-  },
-  {
-    component: 'Slider',
-    kind: 'not-a-surface',
-    reason:
-      "The draggable thumb's border is its shape/affordance (a handle needs a visible edge to grab), not a panel surface.",
-  },
-  {
-    component: 'ThemeIcon',
-    kind: 'not-a-surface',
-    reason:
-      'Ships border: var(--ti-bd, 1px solid transparent) — transparent by default; --ti-bd is a call-site escape hatch, not a stock hairline.',
-  },
-  {
-    component: 'Typography',
-    kind: 'not-a-surface',
-    reason:
-      "Prose/content styling (hr/table/code/kbd borders) — styles user-authored rich-text content inside .mantine-Typography-root, not the app's own UI chrome.",
-  },
-  {
-    component: 'UnstyledButton',
-    kind: 'not-a-surface',
-    reason:
-      'border: 0 reset — the deliberately bare base every other button-like component (Button, Chip, CheckboxCard, RadioCard, …) builds on.',
-  },
-  {
-    component: 'VisuallyHidden',
-    kind: 'not-a-surface',
-    reason: 'border: 0 reset on an a11y-only, visually hidden element — never rendered at all.',
-  },
-]
-
-// ── Tests ────────────────────────────────────────────────────────────────────────────────────────
-
-describe('BORDER_ALLOWLIST is well-formed', () => {
-  test('every entry has a non-empty reason', () => {
-    for (const entry of BORDER_ALLOWLIST) {
-      expect(entry.reason.length).toBeGreaterThan(0)
-    }
-  })
-
-  test('no duplicate component entries', () => {
-    const names = BORDER_ALLOWLIST.map((e) => e.component)
-    expect(new Set(names).size).toBe(names.length)
-  })
-})
-
-describe('every bordered @mantine/core component is themed or allowlisted', () => {
-  // The coverage assertion below is `expect(gaps).toEqual([])`, which passes VACUOUSLY if the scan
-  // finds nothing — a silently-empty scan would report full coverage while checking zero components.
-  // That is not hypothetical: an early version of this file filtered on `typeof === 'object'` (Mantine
-  // factory components are FUNCTIONS with a static `.extend`) and enumerated nothing while staying
-  // green. This test is the tripwire: if a Mantine upgrade restructures the dist and the scan stops
-  // resolving, fail loudly here rather than quietly nodding the real assertion through.
-  test('the scan actually resolves Mantine components (guards against a vacuous pass)', () => {
-    const found = borderedMantineComponents()
-    expect(found.length).toBeGreaterThan(20)
-    // Card is the canonical bordered surface and the origin of doctrine inversion #1 — if the scan
-    // can't see IT, the scan is broken, whatever its count says.
-    expect(found).toContain('Card')
-  })
-
-  test('doctrine inversion #1 (docs/DESIGN-SPEC.md §8) has no unaddressed gap', () => {
-    const themed = new Set(Object.keys(baseTheme.components ?? {}))
-    const allowlisted = new Set(BORDER_ALLOWLIST.map((e) => e.component))
-
-    const gaps = borderedMantineComponents()
-      .filter((name) => !themed.has(name) && !allowlisted.has(name))
-      .map(
-        (name) =>
-          `${name}: ships a stock Mantine border (@mantine/core/styles/${name}.css) but is neither ` +
-          `a key in baseTheme.components (src/theme/index.ts) nor an entry in BORDER_ALLOWLIST ` +
-          `(src/theme/border-coverage.test.ts). Classify it: theme it (panel bg + ` +
-          `box-shadow: var(--vx-shadow-card), no border, scoped to variant="default" or its ` +
-          `equivalent), or allowlist it as a layout divider / not-a-surface with a written reason. ` +
-          `See docs/DESIGN-SPEC.md doctrine inversion #1.`,
-      )
-
-    expect(gaps).toEqual([])
-  })
-})

package/src/theme/contrast.test.ts

@@ -1,354 +0,0 @@
-/**
- * The color gate — three invariants the theme cannot express in types, only in measurements.
- *
- *  1. THE FILL BAND. A filled control does not invert across schemes, so its color must satisfy
- *     both pages at once while carrying a white label: ≥4.5:1 for the label, ≥3:1 against each
- *     page. That pins every fill into one narrow luminance window (see `FILL` / `ACCENT` in
- *     tokens/palette.ts). Untuned, five families sat below the page floor and three needed black
- *     labels.
- *
- *  2. SINGLE SOURCE. Mantine's chrome must read the `--vx-*` tokens, not its own JS hex ramp —
- *     otherwise the palette is dual-sourced, and retuning a token (in the theme lab, or anywhere)
- *     moves the charts while the buttons stay put. That was a real, shipped bug.
- *
- *  3. ON-COLOR. Mantine picks a filled surface's FOREGROUND in JS, once, via `parseThemeColor()`
- *     with no `colorScheme` — and via a BT.601 brightness heuristic that does not track WCAG
- *     contrast (it handed white to lime at 2.24:1). Basalt decides it in CSS instead, per scheme,
- *     by measurement.
- *
- * These are THEME-RESOLUTION invariants, not call-site patterns — no lint rule can see them; the
- * gate has to compute the two colors that actually meet on screen and measure them. The WCAG math
- * below is deliberately a SECOND, independent implementation: the theme is checked against the
- * standard, never against its own helper.
- */
-import { DEFAULT_THEME, getPrimaryShade, mergeMantineTheme } from '@mantine/core'
-import type { MantineTheme } from '@mantine/core'
-import { describe, expect, test } from 'bun:test'
-import { ACCENT, FILL, STATUS, SURFACE } from '../tokens/palette'
-import { baseTheme, cssVariablesResolver } from './index'
-
-const theme: MantineTheme = mergeMantineTheme(DEFAULT_THEME, baseTheme)
-const SCHEMES = ['light', 'dark'] as const
-const COLORS = Object.keys(theme.colors)
-const AA = 4.5 // WCAG 2.x AA, normal-size text
-
-/** WCAG 2.x relative luminance. */
-function relativeLuminance(hex: string): number {
-  const n = Number.parseInt(hex.slice(1), 16)
-  const channels = [(n >> 16) & 255, (n >> 8) & 255, n & 255].map((c) => {
-    const s = c / 255
-    return s <= 0.03928 ? s / 12.92 : ((s + 0.055) / 1.055) ** 2.4
-  })
-  return 0.2126 * channels[0]! + 0.7152 * channels[1]! + 0.0722 * channels[2]!
-}
-
-/** WCAG 2.x contrast ratio. */
-function contrastRatio(a: string, b: string): number {
-  const [hi, lo] = [relativeLuminance(a), relativeLuminance(b)].toSorted((x, y) => y - x)
-  return (hi! + 0.05) / (lo! + 0.05)
-}
-
-/** The hex a filled surface of `color` actually paints in `scheme`. */
-function filledBackground(color: string, scheme: 'light' | 'dark'): string {
-  return theme.colors[color]![getPrimaryShade(theme, scheme)]!
-}
-
-/** The `--vx-on-{color}` declaration the CSS-variables resolver emits for `scheme`. */
-function onColorVar(color: string, scheme: 'light' | 'dark'): string {
-  return cssVariablesResolver(theme)[scheme][`--vx-on-${color}`]!
-}
-
-/** The hex `--vx-on-{color}` ultimately resolves to. */
-function onColorHex(color: string, scheme: 'light' | 'dark'): string {
-  const declaration = onColorVar(color, scheme)
-  if (color === theme.primaryColor) return ACCENT.onAccent[scheme]
-  return declaration === 'var(--mantine-color-black)' ? theme.black : theme.white
-}
-
-describe('--vx-on-* is emitted for every theme color, in both schemes', () => {
-  for (const scheme of SCHEMES) {
-    test(scheme, () => {
-      for (const color of COLORS) expect(onColorVar(color, scheme)).toBeDefined()
-    })
-  }
-})
-
-describe('the accent delegates to the palette, not to a computed guess', () => {
-  // `ACCENT.onAccent` is the spec's declared "text on an accent fill" — the token stays the single
-  // source (a palette retune must move the chrome with it), with a generated per-scheme fallback
-  // for the `injectPalette={false}` window before the palette <style> lands.
-  for (const scheme of SCHEMES) {
-    test(scheme, () => {
-      expect(onColorVar(theme.primaryColor, scheme)).toBe(
-        `var(--vx-on-accent, ${ACCENT.onAccent[scheme]})`,
-      )
-    })
-  }
-})
-
-describe('--vx-on-accent has no collision with the per-color --vx-on-* family', () => {
-  // The 1.4.0 kebab-case rename moved the token layer's `--vx-onAccent` to `--vx-on-accent`.
-  // `onColorVars` (above) ALSO emits a `--vx-on-{name}` per Mantine color name — but `theme.colors`
-  // never registers a color literally named `'accent'` (the primary color is `'blue'`), so that
-  // family can never itself produce a `--vx-on-accent` key. The two stay distinct sources, not a
-  // merge: `--vx-on-accent` is exclusively the token layer's `ACCENT.onAccent` alias target.
-  test('theme.colors has no color named "accent"', () => {
-    expect(COLORS).not.toContain('accent')
-  })
-
-  for (const scheme of SCHEMES) {
-    test(`the resolver's own --vx-on-* map carries no accent key (${scheme})`, () => {
-      const vars = cssVariablesResolver(theme)[scheme]
-      expect(vars['--vx-on-accent']).toBeUndefined()
-    })
-  }
-})
-
-describe('every filled surface is legible against its on-color', () => {
-  // The floor is structural, not tuned: contrast(bg, white) * contrast(bg, black) is a constant
-  // (~17.9 for this black), so always taking the larger of the two cannot drop below ~4.23.
-  const FLOOR = 4.2
-
-  for (const scheme of SCHEMES) {
-    for (const color of COLORS) {
-      test(`${color} / ${scheme}`, () => {
-        const ratio = contrastRatio(filledBackground(color, scheme), onColorHex(color, scheme))
-        expect(ratio).toBeGreaterThanOrEqual(FLOOR)
-      })
-    }
-  }
-
-  // The accent carries the primary CTA's label — it clears full AA in both schemes, and the light
-  // accent hex is pinned to the depth that makes that true (see `ACCENT` in tokens/palette.ts).
-  for (const scheme of SCHEMES) {
-    test(`accent clears AA (${scheme})`, () => {
-      const ratio = contrastRatio(
-        filledBackground(theme.primaryColor, scheme),
-        onColorHex(theme.primaryColor, scheme),
-      )
-      expect(ratio).toBeGreaterThanOrEqual(AA)
-    })
-  }
-
-  // The accent is also a LINK/icon color on the bare page, not just a fill — same AA bar.
-  test('accent is AA-legible as text on the light page', () => {
-    expect(contrastRatio(ACCENT.accent.light, '#fafafa')).toBeGreaterThanOrEqual(AA)
-  })
-})
-
-describe('every non-accent on-color is the higher-contrast of black/white', () => {
-  // The exact property Mantine's brightness heuristic violates: it hands white to saturated
-  // mid-tones (lime `#97ba2e` at 2.24:1) where black scores 7.91:1.
-  for (const scheme of SCHEMES) {
-    for (const color of COLORS.filter((c) => c !== theme.primaryColor)) {
-      test(`${color} / ${scheme}`, () => {
-        const background = filledBackground(color, scheme)
-        const chosen = onColorHex(color, scheme)
-        const rejected = chosen === theme.white ? theme.black : theme.white
-        expect(contrastRatio(background, chosen)).toBeGreaterThanOrEqual(
-          contrastRatio(background, rejected),
-        )
-      })
-    }
-  }
-})
-
-describe('the accent is split by role: ink inverts, surface does not', () => {
-  const PAGE = { light: '#fafafa', dark: '#232326' }
-
-  test('the accent SURFACE is the same hex in both schemes', () => {
-    // It is squeezed from both sides (white text vs. the fill, and the fill vs. the page), and on
-    // the dark page those constraints leave a single narrow window — the same one that works on
-    // light. So the fill does NOT invert, and its label is white in both schemes.
-    expect(filledBackground(theme.primaryColor, 'light')).toBe(
-      filledBackground(theme.primaryColor, 'dark'),
-    )
-    expect(onColorHex(theme.primaryColor, 'light')).toBe(theme.white)
-    expect(onColorHex(theme.primaryColor, 'dark')).toBe(theme.white)
-  })
-
-  test('the accent INK does invert — it is read against the page, not against a fill', () => {
-    expect(ACCENT.accent.light).not.toBe(ACCENT.accent.dark)
-    for (const scheme of SCHEMES) {
-      expect(contrastRatio(ACCENT.accent[scheme], PAGE[scheme])).toBeGreaterThanOrEqual(AA)
-    }
-  })
-
-  for (const scheme of SCHEMES) {
-    test(`the accent surface stays visible AGAINST the ${scheme} page`, () => {
-      // The reason the fill is not simply darkened until white text is comfortable: at 3:1 (WCAG
-      // non-text) the control must be distinguishable from the page. Darkening the fill further
-      // buys white-text contrast but can drop this ratio below 3 — a button fading into the
-      // background.
-      const ratio = contrastRatio(filledBackground(theme.primaryColor, scheme), PAGE[scheme])
-      expect(ratio).toBeGreaterThanOrEqual(3)
-    })
-  }
-
-  test('a hovered accent surface keeps its white label legible', () => {
-    expect(contrastRatio(ACCENT.accentFillHover.dark, theme.white)).toBeGreaterThanOrEqual(AA)
-  })
-})
-
-describe('THE FILL BAND: every filled surface reads white, on either page', () => {
-  // The law that replaces per-color judgement (see FILL in tokens/palette.ts). A fill does not
-  // invert across schemes, so it must satisfy BOTH pages at once, while carrying a white label:
-  //   white label ≥ 4.5:1 against the fill   → luminance ≤ 0.183
-  //   control     ≥ 3.0:1 against each page  → luminance ≥ 0.150 (the dark page is the binding one)
-  // Untuned, five families sat under the page floor (grape 2.17:1) and three needed black labels.
-  const PAGE = { light: '#fafafa', dark: '#232326' }
-  const BAND = Object.keys(FILL).concat(theme.primaryColor)
-
-  for (const color of BAND) {
-    const fill = filledBackground(color, 'light')
-
-    test(`${color}: white label clears AA`, () => {
-      expect(onColorHex(color, 'light')).toBe(theme.white)
-      expect(onColorHex(color, 'dark')).toBe(theme.white)
-      expect(contrastRatio(fill, theme.white)).toBeGreaterThanOrEqual(AA)
-    })
-
-    test(`${color}: visible against BOTH pages`, () => {
-      for (const scheme of SCHEMES) {
-        expect(contrastRatio(fill, PAGE[scheme])).toBeGreaterThanOrEqual(3)
-      }
-    })
-
-    test(`${color}: the JS ramp and the --vx-fill-* token agree`, () => {
-      // Shade 6 is pinned to the band hex, so `-outline` / light `-text` (which read the ramp)
-      // cannot drift away from the fill the CSS token paints.
-      expect(filledBackground(color, 'dark')).toBe(fill)
-    })
-  }
-})
-
-describe('the accent is single-sourced: Mantine chrome is bridged to --vx-*', () => {
-  for (const scheme of SCHEMES) {
-    test(`every non-primary family bridges its fill (${scheme})`, () => {
-      const vars = cssVariablesResolver(theme)[scheme]
-      for (const [name, hex] of Object.entries(FILL)) {
-        expect(vars[`--mantine-color-${name}-filled`]).toBe(`var(--vx-fill-${name}, ${hex})`)
-        expect(vars[`--mantine-color-${name}-filled-hover`]).toContain(
-          `var(--vx-fill-hover-${name},`,
-        )
-      }
-    })
-  }
-
-  // Why the theme lab looked broken: the accent was DUAL-SOURCED. The `--vx-*` layer drove charts
-  // and links; Mantine's chrome drove buttons off a JS hex ramp that pointed at nothing. Overriding
-  // `--vx-accent` restyled the charts and left every button untouched. These lock the bridge.
-  for (const scheme of SCHEMES) {
-    test(`the filled surface resolves through --vx-accent-fill (${scheme})`, () => {
-      const vars = cssVariablesResolver(theme)[scheme]
-      // `getThemeColor()` resolves any plain theme color to `-filled`, so this ONE var reaches the
-      // variant resolver AND every component that fills from its own varsResolver.
-      expect(vars[`--mantine-color-${theme.primaryColor}-filled`]).toBe(
-        `var(--vx-accent-fill, ${ACCENT.accentFill[scheme]})`,
-      )
-      expect(vars[`--mantine-color-${theme.primaryColor}-filled-hover`]).toBe(
-        `var(--vx-accent-fill-hover, ${ACCENT.accentFillHover[scheme]})`,
-      )
-    })
-
-    test(`the ink roles resolve through --vx-accent (${scheme})`, () => {
-      const vars = cssVariablesResolver(theme)[scheme]
-      for (const role of ['text', 'outline', 'light-color']) {
-        expect(vars[`--mantine-color-${theme.primaryColor}-${role}`]).toBe(
-          `var(--vx-accent, ${ACCENT.accent[scheme]})`,
-        )
-      }
-    })
-  }
-})
-
-describe('the variant resolver hands off to CSS, never to a baked color', () => {
-  const resolve = (color: string) => theme.variantColorResolver({ color, theme, variant: 'filled' })
-
-  for (const color of COLORS) {
-    test(`filled ${color} resolves to var(--vx-on-${color})`, () => {
-      const { color: foreground } = resolve(color)
-      // The bug in one assertion: a scheme-blind literal here is unreadable in one of the schemes.
-      expect(foreground).not.toBe('var(--mantine-color-white)')
-      expect(foreground).toBe(`var(--vx-on-${color})`)
-    })
-  }
-
-  test('an indexed color keeps the Mantine default — its fill is scheme-static', () => {
-    expect(resolve('blue.9').color).toBe('var(--mantine-color-white)')
-  })
-
-  test('a raw hex keeps the Mantine default — nothing to resolve per scheme', () => {
-    expect(resolve('#ff0000').color).toBe('var(--mantine-color-white)')
-  })
-
-  test('autoContrast:false at the call site is still honored', () => {
-    const { color } = theme.variantColorResolver({
-      color: 'blue',
-      theme,
-      variant: 'filled',
-      autoContrast: false,
-    })
-    expect(color).toBe('var(--mantine-color-white)')
-  })
-})
-
-describe('doctrine inversion #1 reaches every default-variant CONTROL, not just Card/Paper', () => {
-  // `defaultVariantColorsResolver`'s `variant === 'default'` branch draws its border from this ONE
-  // var (`border: 1px solid var(--mantine-color-default-border)`) for every component that uses
-  // it — Button, ActionIcon, Chip, CheckboxCard, RadioCard, … A future edit that re-points this at
-  // a hairline token would silently reintroduce the stock 1px border on all of them at once; this
-  // is the seam that catches it, since none of those components render their border any other way.
-  for (const scheme of SCHEMES) {
-    test(`--mantine-color-default-border is transparent (${scheme})`, () => {
-      const vars = cssVariablesResolver(theme)[scheme]
-      expect(vars['--mantine-color-default-border']).toBe('transparent')
-    })
-  }
-
-  test('a default-variant control resolves through the transparent border, not a hairline', () => {
-    // The variant resolver itself doesn't special-case `default` (see the `basaltVariantColorResolver`
-    // early return above) — it hands off to `defaultVariantColorsResolver`, which is what actually
-    // reads the var. Assert the var is what a `default`-variant Button/ActionIcon border resolves
-    // through, closing the loop from token to the real render-path seam.
-    const { border } = theme.variantColorResolver({
-      color: theme.primaryColor,
-      theme,
-      variant: 'default',
-    })
-    expect(border).toContain('solid var(--mantine-color-default-border)')
-    expect(border).not.toContain('surface-border')
-  })
-})
-
-describe("the StatCard tone rail reads against the panel it's drawn on", () => {
-  // The rail (`dashboard/stat-card.tsx`) is a 3px non-text mark carrying a threshold verdict, so it
-  // takes WCAG's 3:1 non-text floor against `--vx-surface-panel` — the card background it overlays,
-  // not the page — in BOTH schemes. Worth measuring rather than eyeballing for the same reason the
-  // fill band is: the status solids are DERIVED, so retuning the generator could sink one of them
-  // into the panel it sits on without anything else failing.
-  const TONES = ['good', 'warn', 'bad'] as const
-
-  for (const scheme of SCHEMES) {
-    for (const tone of TONES) {
-      test(`${tone} / ${scheme}`, () => {
-        expect(contrastRatio(STATUS[tone][scheme], SURFACE.panel[scheme])).toBeGreaterThanOrEqual(3)
-      })
-    }
-  }
-})
-
-describe('the shipped palette is the generator output at DEFAULT_DERIVE_CONFIG', () => {
-  // A handful of exact hexes from `deriveTokens(DEFAULT_DERIVE_CONFIG)` (`tokens/derive.ts`) — the
-  // shipped default identity (seed #0077bd, zinc, all four knobs at level 0). Drift here means
-  // either the derive constants moved or `palette.ts` stopped reading the generator's output.
-  test('accentFill (light + dark, same hex)', () => {
-    expect(ACCENT.accentFill.light).toBe('#4374a6')
-    expect(ACCENT.accentFill.dark).toBe('#4374a6')
-  })
-
-  test('surface-bg', () => {
-    expect(SURFACE.bg.light).toBe('#f2f2f5')
-    expect(SURFACE.bg.dark).toBe('#27272a')
-  })
-})