/* Copied 2026-10-23 from the PL design-system tokens used across Arif's dashboards
   (primitives + semantic tokens only; component rules live in css/app.css). */

/* ═══════════════════════════════════════════════════════════════════════════
   Platinumlist design system — primitives and semantic tokens.

   There is no shared design-system.css package on this machine; the other
   ported dashboards inline their tokens, which is how ~30 rgba() literals of
   an old palette ended up hardcoded in one of them. This file exists so both
   pages of this project share ONE definition.

   Themes use CSS light-dark(). It resolves against `color-scheme`, so the
   theme switch is a color-scheme switch:

     :root                    color-scheme: light   (default — light loads first)
     [data-theme="light"]     color-scheme: light
     [data-theme="dark"]      color-scheme: dark

   Every semantic token below is therefore written once, not twice.
   ═══════════════════════════════════════════════════════════════════════════ */

@font-face {
  /* Bold is the ONLY licensed weight — never request another.
     Regular is not on this machine and preloading it 404s. */
  font-family: 'MD Nichrome';
  src: url('/fonts/MDNichrome-Bold.otf') format('opentype');
  font-weight: 700;
  font-style: normal;
  font-display: swap;
}

:root {
  color-scheme: light;

  /* ── Primitives ─────────────────────────────────────────────────────────
     Aussie is the neutral ramp, Poodle the brand purple. Named, not guessed:
     these are the values the rest of the estate already uses. */
  --aussie-100: #0F0F15;
  --aussie-95:  #18181E;
  --aussie-90:  #24242E;
  --aussie-80:  #2C2C38;
  --aussie-60:  #6E6E81;
  --aussie-40:  #9999AC;
  --aussie-30:  #B3B3C3;
  --aussie-20:  #ECEDF2;
  --aussie-10:  #F5F5F8;
  --aussie-0:   #FFFFFF;

  --poodle-primary: #7E05E8;
  --poodle-60:      #9737EC;
  --poodle-40:      #B169F1;
  --poodle-20:      #D8B4F8;

  --accent-success:  #30BB47;
  --accent-alert:    #F93643;
  --accent-warning:  #FF8300;   /* orange. NOT caution-yellow: it fails on white */
  --accent-caution:  #F9C54B;
  --accent-discount: #E8467C;
  --link-base:       #1A56FF;

  /* An accent has TWO jobs and they do not want the same value. A colour that
     is right as a 3px live-feed dot, a 1px border or a 10% fill is not right
     as 9px text sitting on that same fill — a dot is judged by whether you can
     see it at all, text by whether you can read the shape of every letter, and
     WCAG prices those differently (3:1 against 4.5:1).
     `--accent-success` is the FILL strength and stays exactly as it is: the
     dot, the `.is-real` border and the 10% chip ground are all correct at
     #30BB47. `--accent-success-ink` is the TEXT strength of the same colour
     family, and it is deliberately a different value — same hue, taken down
     until it clears 4.5:1 on the ground the text actually lands on.

     Measured (the ratios, not the eye — this whole class of bug exists because
     somebody looked at it and it seemed fine):

       #30BB47 on the 10% chip over a white card (#EAF8ED)  2.30   FAIL
       #1B6B37 on the 10% chip over a white card (#EAF8ED)  5.97   pass
       #1B6B37 on the 10% chip over the grey page (#D9E8E1) 5.17   pass
       #1B6B37 on plain white 6.55, on the grey page ground 5.60   pass

     Dark side: #30BB47 already clears 4.5 there (4.52–6.67 across the 10–18%
     tints over #0F0F15/#18181E/#24242E), so the dark ink is comfort rather
     than rescue — #6FD394 measures 6.20 at the worst of those tints and 9.16
     at the best. Use the ink token for text on both themes anyway, so a page
     never has to know which theme it is in to pick the right one.

     Red and amber have the SAME split and no ink token yet, because nothing in
     this file sets them as text — the failing rules are on the pages. For
     whoever adds them: #F93643 is 3.73 on white and 3.25 on its own 10% tint,
     #FF8300 is 2.47 and 2.26, and the lightest passing inks of those hues are
     about #A63F46 and #815D37. */
  --accent-success-ink: light-dark(#1B6B37, #6FD394);

  /* ── Semantic surfaces ──────────────────────────────────────────────────
     The page is grey and cards are white, never both white — a card has to be
     visible against the ground it sits on. */
  --bg-default:      light-dark(#FFFFFF, #0F0F15);
  --bg-secondary:    light-dark(#ECEDF2, #24242E);
  --bg-hover:        light-dark(#F5F5F8, #2C2C38);
  --bg-wash:         light-dark(#F5F5F8, #18181E);
  --bg-border:       light-dark(#DFE0E8, #34343F);
  --bg-border-hover: light-dark(#C4C5D2, #45454F);
  --bg-fade:         light-dark(rgba(15,15,21,0.45), rgba(0,0,0,0.62));

  /* ── Semantic content ───────────────────────────────────────────────────
     Three levels, and they are not interchangeable:
       primary    text you read
       secondary  labels, metadata, column headers — still read
       highlight  placeholder and disabled ONLY — decorative
     Mapping column headers to `highlight` renders them at #B3B3C3 and they
     effectively vanish.

     `--content-secondary` is read on TWO grounds and has to clear 4.5:1 on
     both. That is the whole story of its value. It was picked against white
     (#6E6E81 is 4.99 there, which passes) — but the app's page ground is
     `--bg-secondary` #ECEDF2, not white, and that is where `.note`,
     `.section-title`, `.footnote`, `#roundLabel` and the "Made with" pill
     actually sit. On the grey it measured 4.27 and failed. #66667A is 4.79 on
     the grey and 5.61 on white, so it passes on both. Check any change to this
     token against the GREY first: white is the surface it is easiest to pass
     on and the one this token is least often read on. Same class of error the
     comment above records for `--content-highlight` — a value validated
     against the wrong ground. The dark value is untouched (7.97 on #0F0F15,
     6.41 on #24242E). */
  --content-primary:   light-dark(#0F0F15, #FFFFFF);
  --content-secondary: light-dark(#66667A, #A6A6B8);
  --content-tertiary:  light-dark(#9999AC, #86869A);
  --content-highlight: light-dark(#B3B3C3, #6E6E81);
  --content-inverse:   light-dark(#FFFFFF, #0F0F15);

  /* ── Type ───────────────────────────────────────────────────────────────
     MD Nichrome is a DISPLAY face: headings and metric values only. Body,
     tables and labels stay on the UI face. */
  --font: 'Inter', -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif;
  --font-accent: 'MD Nichrome', 'Inter', sans-serif;
  --font-mono: 'JetBrains Mono', ui-monospace, SFMono-Regular, Menlo, monospace;
  --font-family-default: var(--font);

  /* ── The system's own furniture ─────────────────────────────────────────
     Every page sets `viewport-fit=cover` and iOS is told the status bar is
     `black-translucent`, which together mean the page is drawn UNDERNEATH the
     notch and the home indicator. Nothing consumed the TOP inset until now, so
     an installed iPhone drew the clock and the battery straight over the
     Platinumlist logo. Read through variables rather than calling env()
     inline, so a test can override them — a browser at 375x812 reports 0 for
     both and would show the bug as fixed whether it is or not. */
  --safe-top:    env(safe-area-inset-top, 0px);
  --safe-bottom: env(safe-area-inset-bottom, 0px);
  /* The left one matters now that the desktop nav is a rail against that edge.
     An iPad in landscape puts the home indicator's inset there, and a notched
     phone rotated left puts the notch there. */
  --safe-left:   env(safe-area-inset-left, 0px);

  /* The space above the header. It belongs to the BAR, not to `.app` — see the
     locked-header section. Two values because a phone gets less of it. */
  --app-pad-top: 28px;

  /* ── Shape, depth, motion ───────────────────────────────────────────────*/
  --radius-xs:   8px;
  --radius-sm:   10px;
  --radius-base: 14px;
  --radius-lg:   20px;

  /* The light-dark() goes around the COLOUR, not around the whole shadow.
     `light-dark()` is a colour function, so `light-dark(0 1px 2px rgba(...),
     ...)` does not parse — and a custom property is only validated where it is
     used, so nothing complained: the tokens looked fine and every
     `box-shadow: var(--shadow-*)` in the estate silently computed to `none`.
     The floating nav pill on a phone asks for --shadow-lg and had no shadow at
     all; so did the login card, the round menu and the alert drawer. Verified
     with CSS.supports: `color` accepts light-dark(), `box-shadow` refuses it.
     (2026-09-07.) */
  --shadow-sm: 0 1px 2px light-dark(rgba(15,15,21,0.06), rgba(0,0,0,0.4));
  --shadow-md: 0 4px 16px light-dark(rgba(15,15,21,0.10), rgba(0,0,0,0.5));
  --shadow-lg: 0 12px 32px light-dark(rgba(15,15,21,0.14), rgba(0,0,0,0.6));

  --duration-base: 160ms;
}

/* An explicit choice beats the OS. Both directions are declared so the toggle
   wins whichever way the system is set. */
[data-theme="light"] { color-scheme: light; }
[data-theme="dark"]  { color-scheme: dark; }