/* The RHoFL palette - the ONE declaration of it.
   Linked by the storefront (templates/base.html) and by the staff portal
   (templates/admin/base_site.html). Values are STYLE-GUIDE S3-S4.

   Why the four-selector list: the portal pins a single scheme, and its
   Django-property remappings have to beat django/contrib/admin's
   dark_mode.css, which declares html[data-theme="dark"]. Declaring the
   tokens the same way keeps one file valid on both surfaces. It is harmless
   on the storefront - nothing sets data-theme there, so :root matches and the
   other three never fire.

   Which scheme is pinned changed on 2026-08-02, from light to dark. The
   mechanism did not, and must not: agreeing with dark_mode.css on direction
   while disagreeing on values is a stronger reason to keep the pin, not a
   weaker one.

   Layout tokens (--gutter, --content-max, --rhythm) are deliberately NOT
   here: they are the storefront's column rhythm and the portal lays out on
   Django's grid. */

:root,
html[data-theme="light"],
html[data-theme="dark"],
html[data-theme="auto"] {
  /* The aurora's three stops. These replaced the light theme's teal trio on
     2026-08-02 and inherited its structural job - the page background's
     three gradient stops - which is why they were renamed rather than
     dropped and re-added. (The old names are not spelled here: tests/theming
     /test_dead_tokens.py hunts them across every stylesheet and template,
     and it cannot tell a comment from a live reference.) */
  --glow-red: #ff2a2a;
  --glow-magenta: #ff007f;
  --glow-purple: #9b4dff;

  --bg-base: #05070d;
  --accent-deep: #d60000;
  --accent-dark: #800000;

  /* LINK TEXT, AND THE REASON IT IS NOT --glow-purple (Greg, 2026-08-13).
     Every in-card link on the storefront read --glow-purple #9b4dff, which
     measures 3.78:1 against --surface-worst-case - under the 4.5:1 AA needs
     for normal text, on the only link rule the storefront has.

     The fix is a token of its own rather than a lighter --glow-purple. The
     three glow tokens are the AURORA'S GRADIENT STOPS: repainting one to
     pass a text check would visibly retune the page background to settle an
     argument about link colour, and portal.css says the same thing at the
     top of its own palette. A glow token should not be colouring chrome,
     and this was the last place one did.

     #ad6bff is the same purple a shade lighter: 4.88:1 on worst-case and
     6.07:1 on --bg-base. The headroom over 4.5 is deliberate - the
     worst-case literal is hand-maintained, and whoever retunes the aurora
     should not discover they have also broken every link. */
  --link-ink: #ad6bff;

  --ink: #f2f5fa;
  --muted: #a8b3c7;

  /* Glass. Translucent on purpose: panels sit over the aurora, and their
     1px border is a hole through to it. */
  --surface: rgba(18, 22, 34, 0.72);
  --surface-tile: rgba(10, 13, 22, 0.85);

  /* For panels that float over the PAGE rather than over the aurora - the
     chat widget is the only one so far. 0.72 works against a background that
     is a slow wash of colour; over a catalog grid it is product photographs
     and price text showing through the words you are trying to read. This is
     opaque enough to read on, and its users pair it with a backdrop blur so
     what little comes through is a tone rather than a picture.

     Not a replacement for --surface. A windowed panel MUST stay at 0.72 or
     its border stops being a hole through to the aurora. */
  --surface-float: rgba(12, 16, 26, 0.93);

  /* FULLY opaque, for a panel that floats over the page and CANNOT pair
     itself with a backdrop blur - aurora.css forbids one on a panel whose
     border is a window. --surface-float's remaining 7% is a tone behind the
     chat widget's blur; behind a modal on the orders list it is the table's
     own header colliding with the card's labels.

     The rail's --portal-rail-bg is the same decision for the same reason.
     Named as --surface's sibling and declared here rather than in modal.css
     so the family stays in one file.

     The value is the family's own end point, not a free choice: the surfaces
     darken as they thicken (18,22,34 at 0.72; 12,16,26 at 0.93), so the fully
     opaque member is 10,13,22. */
  --surface-modal: #0a0d16;

  /* The same value under a second name, and deliberately not a reference to
     --surface-modal - see the "two names, one value" note below. The colophon
     stages the hex tile at full strength over a near-black so the tile's own
     transparency stays visible; that it matches the modal surface is
     coincidence, and a modal re-tuned later must not drag the exhibit's
     backdrop with it. */
  --hex-stage-bg: #0a0d16;

  /* The shopper's side of the chat log: --surface-tile with the brand red
     washed through it, at the same opacity so the two sides of a
     conversation sit at the same depth. A token rather than a literal in
     site.css because its job is to be --surface-tile's sibling, and a
     sibling defined in another file drifts. */
  --bubble-shopper: rgba(64, 14, 22, 0.85);

  --hairline: rgba(255, 255, 255, 0.10);
  --rule: rgba(255, 255, 255, 0.06);
  --accent-wash: rgba(255, 42, 42, 0.12);

  /* Two names, one value. Django admin owns --accent as its own custom
     property, so the portal refers to the RHoFL red as --rh-accent in files
     that also touch Django's; declaring both here keeps them from drifting a
     file apart. */
  --accent: #ff2a2a;
  --rh-accent: #ff2a2a;
  --accent-ink: #ffffff;

  /* The STATIC illuminated edge, for panels the aurora window cannot reach:
     nested panels, modals over an opaque backdrop, and the no-support
     fallback. A panel that can see the aurora uses the window instead and
     does not consume this. */
  --edge-glow: rgba(255, 42, 42, 0.45);

  /* Semantic inks. These existed ONLY as the fallback half of
     var(--warn-ink, #8a6d1f) in portal-orders.css and were declared nowhere,
     which made the fallback their sole value source. --ok-ink and --info-ink
     joined them so every status pill has a token rather than a literal. */
  /* Categorical series colours. These four lived as raw hex on
     .my-peps-series-* in site.css, which made site.css the source of truth
     for a palette two features now share - and left a dashboard bound to
     "tokens only, no raw hex" with no token to use. Promoted here; the
     my-peps rules point at these. Distinct from the semantic inks below:
     these say "a different thing", those say "a good or bad thing". */
  --series-teal: #55d6b6;
  --series-violet: #a78bfa;
  --series-amber: #ffb454;
  --series-blue: #62b7ff;

  --warn-ink: #e0a52a;
  --danger-ink: #ff6b6b;
  --ok-ink: #3ecf8e;
  --info-ink: #b478ff;

  --mol-stroke: #eaf7f6;

  /* Both were tuned as near-white on TEAL, where they read as a whisper.
     On a near-black ground the same values are solid grey shapes - the hex
     field became the loudest thing on the login page, which is the exact
     opposite of "atmosphere, never content".

     --hex-opacity sits higher than --mol-opacity because the field is now
     the only watermark: the word-molecule was removed on 2026-08-03 and the
     grey tone is wanted. --mol-opacity is left declared for the generator,
     which still uses it, but nothing on a page background reads it. */
  --hex-opacity: 0.08;
  --mol-opacity: 0.12;

  /* A TEST FIXTURE, NOT A PAINTABLE SURFACE. Nothing may consume this in a
     CSS rule. It is what --surface resolves to over the brightest point of
     the aurora, and it exists because "the brightest point of the aurora" is
     not computable from tokens - tests/theming/test_contrast.py asserts
     against this literal. Whoever retunes the aurora owns updating it. */
  --surface-worst-case: #2a1b2e;

  --font-sans: "Inter", "Segoe UI", system-ui, -apple-system, sans-serif;
}