/* ================================================================
   hsops — shared theme
   ================================================================
   Every color used anywhere in the app lives here, once. To change
   the brand palette in future, edit the values in this file only —
   index.html, login.html, clock.html, driver.html, and
   payroll-kiosk.html all link to it, so a single edit updates every
   screen.

   Every page must link this file as "/theme.css" (leading slash), never
   "theme.css". driver.html is served at /driver/:id and login.html can
   be served at /login/:slug — a relative link resolves against that
   extra path segment and asks the server for e.g. /driver/theme.css,
   which the server's own /driver/:id route swallows and answers with
   driver.html itself instead of the stylesheet. The page still loads,
   just with every var(--...) style silently missing (only literal
   hardcoded colors in that page's own <style> block survive) — easy to
   miss since nothing errors loudly.

   Clean, light, burgundy-accented palette — white/near-white surfaces
   throughout, burgundy reserved as the accent (never a large fill),
   near-black for primary text, cool gray for secondary/muted text.
   Inter as the typeface. An organisation can override the accent
   colour and add its own logo per-org from Settings → Branding (see
   applyBrandColor()/applyBranding() in index.html) — those overrides
   only ever touch the accent-family tokens below (--accent,
   --accent-strong, --accent-bg, --accent-text, --sidebar-accent),
   nothing else.
   The default below is burgundy (not the old indigo) specifically so
   the brief flash before an org's own colour loads over the network
   is on-brand instead of looking like a wrong/stale colour. index.html,
   payroll-kiosk.html and driver.html all also cache the last-applied
   org colour/logo in localStorage and re-apply it immediately on page
   load (before any network round-trip), so on any repeat visit this
   default is only ever seen for a first-ever visit, not on every load.

   Status colors (green/amber/red/blue/purple used for shipment
   stages and stage chips) are UNCHANGED and separate from the brand
   palette on purpose — they carry meaning (success/warning/error)
   independent of branding, so they're not touched by a rebrand.
   ================================================================ */
:root{
  /* Dark chrome — used by the pre-auth login screen and the personal
     bundy/kiosk header bar (deliberately distinct from the light main
     app body). */
  --navy:#1e1b2e;
  --navy-light:#2a2640;
  --navy-border:#3a3555;
  --sidebar-text:#a5a0c0;
  --sidebar-text-active:#ffffff;
  --sidebar-accent:#7a2333;

  /* There was a --app-sidebar-* family here for the main app's own
     navigation rail. The rail is gone — the page title opens a popover
     instead — and nothing read them any more. --sidebar-accent above
     stays: it is the dark header bar on login/clock/driver/kiosk, and
     the small logo tile in the app header. */

  /* Page + surfaces — predominant brand tone lives here, deliberately light */
  --page-bg:#f7f8fa;
  --page:#f7f8fa; /* alias used by login/clock/driver */
  --surface:#ffffff;
  --surface-2:#f1f2f5;

  /* Borders */
  --border:#e5e7eb;
  --border-strong:#d1d5db;

  /* Text */
  --text-primary:#111827;
  --text:#111827; /* alias used by login/clock/driver */
  --text-secondary:#4b5563;
  --text-muted:#9399a8;

  /* The "hsops" wordmark specifically — a fixed near-black burgundy,
     deliberately NOT the org-overridable --accent family (this is the
     platform's own mark, shown alongside an org's logo once uploaded,
     not replaced by it — see applyLogoBranding() in index.html). */
  --logo-color:#2b0e12;

  /* Primary action color — burgundy, with white text. This is only the
     default shown before an org sets its own colour (or before that
     colour has loaded) — most orgs will override it via Settings →
     Branding, same as before. */
  --accent:#7a2333;
  --accent-text:#ffffff;
  --accent-bg:#f7e9eb;
  --accent-strong:#5c1a26;

  /* Login page only — fixed dark burgundy, deliberately NOT part of the
     org-overridable --accent family above. The login page runs before
     we know which organisation someone belongs to, so there's no org
     brand colour to apply yet; this is just this app's own fixed look
     for that one pre-auth screen. */
  --auth-accent:#7a2333;
  --auth-accent-strong:#5c1a26;
  --auth-accent-text:#ffffff;

  /* Secondary buttons — a solid medium grey, for controls that need to
     read as a BUTTON rather than as a link, but are not the primary
     action on the screen. Scott's call for the board's Expand all /
     Collapse all and the column collapse controls: they were plain text
     with a chevron and nobody could tell they were clickable, but a dark
     fill would compete with the primary action next to them.
     Not part of the org-overridable --accent family: it is deliberately
     neutral, so it never fights whatever brand colour a tenant sets. */
  --btn-grey:#d8dce2;
  --btn-grey-hover:#c7cdd6;
  --btn-grey-border:#b9c0ca;

  /* Status colors — DO NOT change these as part of a rebrand, they
     carry meaning in the dispatch pipeline and are independent of
     brand identity */
  --green:#00b341;
  --green-bg:#e6f9ee;
  --amber:#f59e0b;
  --amber-bg:#fffbeb;
  --red:#e53e3e;
  --red-bg:#fff5f5;
  /* EXPIRY — its own scale, and the reason it is here rather than
     hardcoded next to each rule. The chips were literal hexes in
     index.html while the count badge used --amber (#f59e0b, an orange),
     so the same "deal with it" state was two different yellows on one
     screen and Scott spotted it immediately. One place now: anything
     saying "expired" or "expiring" reads these, and moving the yellow
     moves all of it. Deliberately NOT the --amber/--red family, which
     belongs to shipment stages: restyling a stage must not restyle an
     expiry date, which is the same separation exp-overdue/exp-soon was
     introduced for. */
  --exp-red-bg:#fee2e2;
  --exp-red-line:#f87171;
  --exp-red-text:#7f1d1d;
  --exp-amber-bg:#fef9c3;
  --exp-amber-line:#fde047;
  --exp-amber-text:#854d0e;
  /* ISSUE CATEGORY GROUPINGS — their own scale, for the same reason the
     expiry one is. Scott: "i also thing the issue catagory colours are to
     bold, make them nicer brighter colours." They were borrowed from the
     status family (--red, --blue, --green) plus --accent, which is a dark
     burgundy — so a chart of five categories read as an alarm, and the
     Operational bar was nearly black.

     These are brighter and lighter on purpose. They are a PALETTE, not a
     severity scale: nothing here means "bad", they only have to be told
     apart from each other. Borrowing the status colours implied a
     severity that was never there, and it also meant restyling a shipment
     stage would have restyled the issues dashboard — the same separation
     --exp-* was introduced for. */
  --issue-safety:#ff8787;
  --issue-quality:#4dabf7;
  --issue-operational:#b197fc;
  --issue-environment:#69db7c;
  --issue-other:#adb5bd;
  --blue:#3b82f6;
  --blue-bg:#eff6ff;
  --purple:#7c3aed;
  --purple-bg:#f5f3ff;
  --stage-unconfirmed:#94a3b8;
  --stage-confirmed:#3b82f6;
  --stage-packed:#f59e0b;
  --stage-dispatched:#00b341;
  --stage-issue:#e53e3e;
  --stage-unsuccessful:#e53e3e;

  /* Shape + shadow + type — not color, but shared for consistency */
  --radius:12px;
  --radius-sm:8px;
  --shadow:0 1px 2px rgba(16,24,40,.06);
  --shadow-md:0 4px 12px rgba(16,24,40,.10),0 2px 4px rgba(16,24,40,.05);
  --font:'Inter',system-ui,-apple-system,sans-serif;
}