/* ══ xWise shared design tokens ══ v1.0 ═══════════════════════════════════════════
   Served at /static/xwise/tokens.css on every xWise host. ONE definition of the
   family palette, replacing the copy that used to sit in each page's own <style>.

   ⚠️ WHY THIS EXISTS. Before consolidation these 13 tokens were declared in SIX files
   x TWO themes = 156 identical declarations. That is not hypothetical drift: the apps
   had already reached the point of using DIFFERENT NAMES for identical values, fixed
   only in Aug 2026, and dark mode had just doubled the surface.

   ⚠️ LOAD ORDER MATTERS. Link this BEFORE a page's own <style>, so a page can still add
   its own tokens (the workbench stage colours, an inline-SVG data URI) and override
   anything here. Linking it after silently reverts a deliberate per-page override.

   ⚠️ IF THIS FILE FAILS TO LOAD every var() in the app resolves to nothing and the page
   renders unstyled. That failure is LOUD by design: each app page's `_styleCheck` opens
   by asserting a token it can only get from here, and reports the sheet by name. Do not
   "harden" it with inline fallbacks — a fallback copy is the duplication this removes.

   ⚠️ CHANGING A VALUE HERE CHANGES EVERY xWise APP THAT LOADS IT. That is the point, and
   it is also the risk: this file is shared state, so treat an edit as a cross-app change
   (xwise-shared Rule 22) rather than as a tweak to whichever app you happen to be in.
   ══════════════════════════════════════════════════════════════════════════════════ */

:root{
  /* ⭐⭐ THE ONE PROPERTY THAT IS NOT A COLOUR, AND THE ONE DARK MODE CANNOT WORK WITHOUT.
     Without `color-scheme`, the user agent keeps every NATIVE control in its light styling no
     matter what the page does — because the UA has no way to know the page went dark. Measured
     on TrackWise's workbench before this line existed: **41 of 42 form controls rendered BLACK
     ink in dark mode**, several of them on a `#1c1c1e` field, i.e. genuinely unreadable.
     ⚠️ NO CSS CAN REACH WHAT THIS FIXES. Scrollbars, a <select>'s native <option> popup, spin
     buttons, date pickers and the default ink of any unstyled input are UA-drawn. A stylesheet
     can restyle the box; only this tells the UA which theme it is drawing into.
     ⚠️ It is INERT IN LIGHT — verified, not assumed: 0 colour changes and 0 elements moved
     across 42 controls. So it is a pure dark-mode repair with no light-mode cost.
     ⚠️ Both apps shipped dark mode without it. Handed to NeckWise, who confirmed the same gap and
     fixed it the same day (their v536) — so the blind spot was real on both sides, not ours alone. */
  color-scheme: light dark;

  --text:#1c1c1e;
  --text2:#636366;
  --text3:#aeaeb2;
  --border:#d1d1d6;
  --bg:#fff;
  --bg2:#f5f5f7;
  --hi:#fff;
  --accent:#1a4fa8;
  --red:#b03020;
  --green:#008741;
  --gold:#b45e00;
  --gold-hover:#a85d0d;
  --gray:#8e8e93;
}

/* ⭐ DARK — OS-following only; there is deliberately no manual toggle (STYLE_GUIDE §1.2a).
   The neutrals are NeckWise's shipped values verbatim, per Jeff's take-NeckWise-as-default
   rule; the semantic colours are lifted by the OKLCH transform with hue and chroma held. */
@media (prefers-color-scheme: dark){
 :root{
  --text:#f5f5f7;
  --text2:#aeaeb2;
  --text3:#636366;
  --border:#3a3a3c;
  --bg:#1c1c1e;
  --bg2:#2c2c2e;
  --hi:#242426;
  --accent:#5289e8;
  --red:#ed6955;
  --green:#2ea75e;
  --gold:#d67d26;
  --gold-hover:#e08f3f;
  --gray:#929297;
 }
}

/* ══ Type scale ══ v1.1, Aug 13 2026 ═══════════════════════════════════════════════
   ⭐ WHY THIS EXISTS, and it is the same argument the colour tokens won on: measured across
   TrackWise's six files there were **19 distinct font sizes in 241 declarations**, with **44
   below 11px** and no floor stated anywhere. That is exactly the state colour was in before
   consolidation — dozens of literals, drifting, with no single place to change them.

   ⚠️ `--fs-floor` IS THE POINT. `FRETBOARD_SPEC` §2 sets an absolute 11px minimum, and it is the
   one place a ratio-based spec breaks: a pure ratio can produce an unreadable label that still
   satisfies the ratio. An absolute floor cannot be satisfied by proportion.
   With the scale in place the floor is enforceable by ONE grep rather than by a dozen judgment
   calls — `font-size:` followed by anything under 11px is now a defect by definition.

   ⚠️ These are DECLARED VALUES, not a ramp to interpolate. Sizes between tiers (11.5, 12, 13.5)
   still exist in the apps and are deliberately left literal for now rather than being forced into
   the nearest tier — collapsing them would move layout everywhere for no legibility gain. The
   floor is the accessibility fix; tier adoption is housekeeping and can follow.

   ⚠️ Every token here has real uses today. An unused token is a third artifact free to drift —
   the same reason `theory.js` stays undeployed until something loads it. */
:root{
  --fs-floor:11px;   /* absolute minimum — nothing may render smaller */
  --fs-label:11px;   /* uppercase micro-labels, table headers, pills, badges */
  --fs-meta:12.5px;  /* secondary and supporting text */
  --fs-ctl:13px;     /* controls — the established control font (STYLE_GUIDE §5) */
  --fs-body:15px;    /* body copy; matches the declared base */
  --fs-title:19px;   /* panel and section titles */
}

/* ══ Workbench stage colours ══════════════════════════════════════════════════════
   Used as BADGE FILLS carrying white labels, not as text. Shared because they were
   duplicated across ingest.html and both guides; kept in their own section because
   they are a workbench vocabulary rather than part of the chrome palette (STYLE_GUIDE
   §1.2's chrome/viz split). Unused tokens cost nothing on pages that never read them.

   ⚠️ DELIBERATELY NOT THEMED, and that is measured rather than lazy: all three are
   fills, so what governs is the WHITE LABEL on the fill, which does not move with the
   theme. ⚠️ Two of them fail that test TODAY, in BOTH themes -- --orange 2.93 and
   ⭐ ANSWERED Aug 13 2026 (Jeff: *"darken to one value"*) — and the answer differs by theme,
   which is the interesting part. **LIGHT: one value serves both roles.** Contrast is symmetric, so
   #b45e00 is 4.62 as ink on white AND 4.62 as a fill under white ink — which matters because
   --gold is used both ways (fill on .pill.chart/.adminbadge, ink on .admin-link/.appver).
   ⚠️⚠️ **DARK: one value is IMPOSSIBLE, and it is arithmetic rather than taste.** White-on-fill ≥4.5
   needs the fill's luminance ≤0.183; the same fill read as ink on the #1c1c1e page needs ≥0.228.
   The ranges do not overlap. So the dark forms stay LIGHT (they are ink) and their FILLS carry
   DARK ink instead — see the per-variant rules in each app file. --teal is lifted because dark ink
   on #1a8f8f was only 4.35. */
:root{
  --purple:#7952b3;
  --orange:#b35f00;
  --teal:#008282;
}
/* ⚠️⚠️ THIS DARK BLOCK MUST STAY AFTER THE STAGE `:root` ABOVE, and that is not stylistic.
   The stage colours are declared in their own late `:root`, so a dark override placed up in the
   CORE dark block loses to it on SOURCE ORDER at equal specificity — it computes the LIGHT value
   in dark mode and looks exactly like a missing override. That is how it was first written here,
   and a probe caught it: `--teal` reported #008282 in dark. Same trap as the dark select caret.
   ⭐ Values: dark fills carry DARK ink (see the note above on why one value is impossible in dark),
   so these are the LIGHT-ON-DARK forms. `--teal` is lifted from #1a8f8f because dark ink on it was
   only 4.35; `--orange` gets its first dark form now that its light value darkened to #b35f00. */
@media (prefers-color-scheme: dark){
 :root{
  --teal:#229494;
  --orange:#d9822b;
 }
}