/* SALTS FSM -- shared design tokens.
 *
 * WHY THIS FILE EXISTS
 * --------------------
 * The approved UI build defined its palette inside app/static/index.html.
 * engineer.html carried its own 18 tokens and portal.html its own 6, and only
 * FOUR were common to all three: three palettes wearing one name. A colour
 * change had to land in three places and, predictably, never did.
 *
 * This is now the ONLY definition of the palette. All three front ends and
 * both sign-in pages link it, and none of them declares a rival :root.
 * The values are lifted verbatim from the approved build, not re-authored.
 *
 * SCOPE -- deliberately tokens, not components.
 * Component CSS stays with each app. A desktop office data table and a
 * gloved-hand mobile engineer button are not the same component, and moving
 * office component rules onto the Engineer App would change how it looks --
 * a redesign, which is out of scope. What they share is the palette, and
 * that is what lives here.
 */

:root{--navy-deepest:#01050e;--navy-sidebar:#030913;--bg:#060c1a;--panel:#0c1426;--panel2:#121c32;--line:#22304e;--text:#e9f0ff;--muted:#8195b4;--blue:#1a6dff;--blue-hover:#3a80ff;--cyan:#27c7ea;--green:#22c55e;--amber:#f5a623;--orange:#f97316;--red:#ef4444;--purple:#8b5cf6;--grey:#94a3b8;--shadow:0 2px 14px rgba(0,0,0,.55);
  /* Semantic sub-tokens: these are themselves derived from the core
     palette above but named for their specific UI role, so a
     Scheduler status colour or a notice banner tint can be reused
     consistently without becoming indistinguishable from every other
     blue/red/green in the app. Data-driven meaning (which status is
     which colour) is preserved -- only the literal hex values are
     centralised here. */
  --status-scheduled:#5bb5ff;--status-onroute:#ffb84d;--status-onroute-bg:#3d2906;
  --status-onsite:#c78bff;--status-onsite-bg:#2a1342;--status-completed:#20c997;--status-completed-bg:#0a3025;
  --status-partsrequired:#ff5964;--status-partsrequired-bg:#3e101a;--status-cancelled:#8b98ae;--status-cancelled-bg:#18202f;
  --notice-red-border:#5a2530;--notice-red-bg:#230d14;--notice-amber-border:#5a4520;--notice-amber-bg:#241a09;
  --notice-green-border:#1f4a30;--notice-green-bg:#0a1e14;
  --pass-bg:#094038;--pass-text:#d6fff2;--fail-bg:#4b1822;--fail-text:#ffd0d4;--na-bg:#3d3518;--na-text:#ffe7a4;
  --duesoon-bg:#3e3011;--overdue-bg:#42161e;--badge-alert-bg:#4c370e;--badge-alert-text:#ffd66b}

/* Compatibility aliases.
 *
 * engineer.html and portal.html each named the same colours differently
 * (--accent for the same blue, --booked for the same scheduled-status
 * colour). Rather than rewrite hundreds of usages -- a large diff with real
 * regression risk and no visible benefit -- the local names are redefined as
 * references to the shared tokens. One palette, two vocabularies.
 *
 * The engineer status colours were already byte-identical to the approved
 * semantic tokens, so those aliases are provably no visual change at all.
 * The portal's six were slightly off (#0879e8 against the approved #1a6dff);
 * pointing them at the shared tokens is what brings it onto the system.
 */
:root{
  --navy:var(--bg);
  --accent:var(--blue);
  --accent-dim:#0d2f55;
  --faint:#70809f;  /* 4.63:1 on --panel, 4.93:1 on --bg; was #55688a at 3.26 */
  --booked:var(--status-scheduled);
  --onroute:var(--status-onroute);
  --onsite:var(--status-onsite);
  --parts:var(--status-partsrequired);
  --completed:var(--status-completed);
  --overdue:var(--red);
  --radius:14px;
  --radius-sm:9px;
  --safe-bottom:env(safe-area-inset-bottom,0px);
  /* The interface typeface, settable per company in Settings -> Branding.
     Defined here so it has one definition; the default is the stack the
     app used before it became configurable, so the default changes nothing. */
  --app-font:'Segoe UI',system-ui,-apple-system,Roboto,Arial,sans-serif;
}