/* tokens.css: HQ's design tokens, one place to change.
   Loads AFTER the engine's admin.css (so it can override the engine's
   --field-* values where HQ chooses) and BEFORE hq-admin.css and central.css
   (which consume these names). Three tiers, top to bottom:
     1. primitives  (a grey ramp, a radius scale, shadows, type and spacing steps)
     2. semantics   (--ink, --surface, --line, --brand, status triples)
     3. components  (--btn-*, --card-*, --chip-*)
   Rule: a value changes here or it does not change. Components read tokens;
   views never type a hex, a radius or a shadow. The engine's --field-* family
   stays the engine's; HQ overrides individual --field-* values here, never the
   whole block. Sections are appended in the order they landed (CSS list two). */

/* ---- Shadow tokens -------------------------------------------------------
   Six card-hover rules and three dropdown/menu rules each hand-wrote their
   own rgba(15,23,42,...) shadow, close to each other but not the same
   (0.06, 0.09 and 0.10 opacity on the cards; a mix of blur/offset/opacity on
   the menus). Naming the two shapes actually used here means the next card
   or menu reaches for a token instead of guessing a new rgba value. This
   nudges the six card shadows to one shared depth and the three menu shadows
   to one shared depth, a small deliberate visual change (Mitchell, fix 96). */
:root {
    --shadow-hover: 0 6px 18px rgba(15,23,42,.09);
    --shadow-menu: 0 12px 28px rgba(15,23,42,.18);
}

/* ---- Radius tokens --------------------------------------------------------
   Every white content card in HQ was either 12px or 14px, split by which
   screen it was written on, and one pill (.es-chip and its two siblings in
   the section picker) was 99px against every other pill's 999px. Named here
   so the next card or pill reaches for a token instead of picking a number:
   --radius-card settles every white card at 12px (the more common of the
   two), --radius-pill matches the 999px every other pill already used
   (fix 95). */
:root {
    --radius-card: 12px;
    --radius-pill: 999px;
}

/* ---- z-index scale (fix 98) -----------------------------------------------
   .sg-modal used to be 1200, a "just win" number six times higher than
   anything else in HQ's own CSS (central.css, hq-admin.css, style-guide2.css,
   nav-builder.css). Brought down to 300, the top of the scale actually in
   use across those four files, grouped roughly by what each step is for:
     1-8    an element stacking above its own siblings inside one component
            (a badge on a row, a slider handle, a layout guide) - never
            needs to beat anything outside its own parent.
     20-30  a small dropdown or menu panel (kebab menus, the font menu,
            per-row menus).
     40-61  sidebars, rails, and the backdrops/flyouts anchored to them.
     75-90  a full-screen overlay (a picker, the "welcome"/history panel,
            the Explore-sections peek and wizard).
     120    the save toast, above everything but a true modal.
     200    the busy bar and floating menus that must sit above page chrome.
     300    .sg-modal, the one true modal HQ's own CSS defines. Nothing here
            should go higher; a new overlay that thinks it needs to should
            fit an existing step instead.
   Not touched: public/admin.css (the engine's own file, gitignored, never
   edited here) has its own scale up to 1300 for its modals and drawers;
   HQ's screens that use those components inherit that scale, which is the
   engine's decision to make, not this fix's.
   One documented exception, above even 300: --z-drawer-top (fix 33/26),
   the shared fields editor drawer (.fe-drawer/.fe-backdrop), which has to
   sit above the engine's own drawers and so has to sit above their 1300
   ceiling too. It was found at a bare 12040/12050, copy-pasted three times,
   roughly 40 times higher than either ceiling for no documented reason;
   1310 is the smallest step that still clears the engine's own scale. */

/* ---- Shape: radius scale and shadows --------------------------------------
   --radius-card and --radius-pill (above) were correct but only reached 38
   percent of the cards and 6 percent of the pills they were named for; every
   other integer from 2px to 16px was still a hand-picked literal. This adds
   the two missing steps a control needs: --radius-control for buttons,
   inputs and small chips, and --radius-sheet for the one 16px panel
   (.sg-modal-card). Four named steps now cover control, card, sheet and
   pill; a script repoints every exact-match literal at the step it already
   equalled, so no rendered value moves. Odd values (7px, 9px, 11px) have no
   home yet and wait for a human pass, not this one.

   Shadows follow the same pattern. --shadow-hover and --shadow-menu (fix 96,
   above) are kept as they are; nothing here renames or removes them.
   --shadow is the card's resting state, none today: Phase 3 is the step that
   turns it on, so it is named now while nothing yet uses it, for that later
   change to be a one-line edit. --shadow-up is what a card lifts to on
   hover, an alias of --shadow-hover so the six card-hover rules can read a
   name that describes what it does rather than the fix that introduced it.
   --shadow-modal is the .sg-modal-card shadow, the dominant one-off, now
   shared by the two other full-screen overlays close enough in shape to
   fold into it (the section-picker and the wizard box; both move a few
   pixels and a little opacity to match, listed in the changelog as an
   accepted fold). --ring and --ring-neutral name the two focus rings that
   already agreed on a width and a colour before this fix: --ring is the
   brand-tinted ring already used at 3px/16% in two places, --ring-neutral is
   the grey ring already used at 3px/16% in two places plus one more that was
   sitting one point higher, at 18%, folded into the same value. Every other
   ring width and opacity in central.css is deliberately left alone; that
   wider ring cleanup is Phase 2 item 43, not this fix. */
:root {
    --radius-control: 8px;
    --radius-sheet: 16px;

    --shadow: none;
    --shadow-up: var(--shadow-hover);
    --shadow-modal: 0 24px 60px rgba(15,23,42,.3);

    --ring: 0 0 0 3px color-mix(in srgb, var(--brand-primary) 16%, transparent);
    --ring-neutral: 0 0 0 3px rgba(148,163,184,.16);
}

/* ---- Type, spacing, motion, fonts (CSS list two, items 12-15) -------------
   Four families landing together because they share one shape: a hill of
   near-identical literals with no scale underneath them. Font sizes ran
   107 distinct values from 9.5px to 17px with no gap between; spacing ran
   six separate rem values (0.3 to 0.6rem in 0.05rem steps) standing in for
   one or two real steps; 164 transitions and 27 animations spelled out
   their own timing with no shared name; five monospace stacks and three
   hand-typed 'Plus Jakarta Sans' restatements did one job each. The seven
   size steps, six spacing steps and three duration steps below are each
   picked from the heaviest existing cluster, not invented: the highest
   count literals move to the new token, nothing changes size (items 12a,
   13a, 14a, 15a).

   The root/body mismatch (item 13): public/admin.css:9 sets the body to
   15px but never resets `html`, so the browser's 16px default root is
   still what every `rem` in HQ's own CSS resolves against, one pixel more
   than the body copy it was likely sized relative to. Documented here,
   not changed (item 13, option a): changing the root would move every rem
   value in the app at once, which is a redesign-sized decision, not a
   token-naming one. Treat the root as 16px and the body as its own 15px
   override until that decision is made. */
:root {
    --font-sans: "Plus Jakarta Sans", -apple-system, BlinkMacSystemFont, "Segoe UI", system-ui, sans-serif;
    --font-mono: ui-monospace, SFMono-Regular, Menlo, monospace;

    --text-xs: 11px;
    --text-sm: 12.5px;
    --text-base: 14px;
    --text-md: 15px;
    --text-lg: 17px;
    --text-xl: 20px;
    --text-2xl: 26px;
    --title-weight: 700;
    --title-lh: 1.25;

    --space-1: 4px;
    --space-2: 8px;
    --space-3: 12px;
    --space-4: 16px;
    --space-5: 24px;
    --space-6: 32px;

    --dur-fast: 120ms;
    --dur: 200ms;
    --dur-slow: 300ms;
    --ease: ease;
    --ease-spring: cubic-bezier(0.16, 1, 0.3, 1);
}

/* ---- Engine field tokens: HQ overrides (item 8) ---------------------------
   hq-admin.css used to redeclare the engine's WHOLE 30-token --field-*
   block from admin.css's :root, just to change two of the thirty values.
   hq-admin.css's own header comment named this exact problem as an open
   question: was each copied line a deliberate override or a stale copy
   that should defer to the engine now that deferring is free. For 28 of
   the 30 the answer is "stale copy" (they were byte-identical to the
   engine's own values); the two below had genuinely drifted, and the
   HQ value is the intended one because it matches HQ's own readability
   rule (hq-admin.css's comment: "#6b7280 placeholders and field meta
   only") better than the engine's lighter grey does.
   The rule from here on: override ONE --field-* property when HQ needs a
   different value, never the whole block, so the next engine change to
   any of the other 28 tokens reaches HQ automatically instead of being
   silently masked by a full copy nobody remembers to update. */
:root {
    --field-placeholder: #6b7280;  /* engine default is #94a3b8; HQ wants it darker for readability */
    --field-meta-color: #64748b;   /* "Max N characters" etc; engine default is #94a3b8 */

    /* --editor-bar-h is not a drifted value, it is identical to the
       engine's own admin.css:989 (52px both places) - HQ's page-header
       toolbar and the editor drawer's dark head both key off it directly,
       so it is restated here rather than left implicit, next to the two
       tokens it used to live beside in hq-admin.css's old block. */
    --editor-bar-h: 52px;
}

/* ---- Components: buttons, cards, chips, tables, shell (CSS list two,
   items 16 and 17) ----------------------------------------------------------
   The engine never wrote a token for its own admin chrome buttons (a hex
   primary, a literal radius, admin.css:895-910 and :2123-2132) even though
   it already ships a mature, working token contract for the buttons a
   site's visitor sees, lib/Render/buttons.css in Slipstream-Client. This
   section ports that shape sideways for HQ's own buttons, then does the
   same for the handful of tokens each shared HQ component needs: card
   background, border, radius, padding, shadow; chip radius, weight, size;
   table header colour; the page ground; the sidebar and rail colours.
   These are the knobs a later step turns one at a time (a button colour,
   a card radius) and then together (a full theme).

   Every value below is today's rendered value, read from public/admin.css
   (the engine, gitignored, never edited here) and public/central.css (HQ's
   own file), not guessed. Some reference a primitive or semantic token
   (--brand, --line, --radius-control, --surface, --shadow, --text-base)
   that another agent is declaring alongside this one in the same
   integration and is NOT present in this worktree yet; every one of those
   references carries the literal fallback that renders today, so this
   file is correct alone and stays correct once the other sections land.
   Component rules read only the names on the left below (--btn-bg, not
   --brand), so the alias can be repointed at a different primitive later
   without touching every consumer.

   --chip-weight is 700, not the 600 first proposed for it: that figure was
   .filter-pill's own weight, not .ctx-chip's (central.css:105), and
   .ctx-chip is the dominant chip family (22 views) this token is named
   for. Folding .filter-pill's weight into the same token would visibly
   change one of the two, which this phase does not allow, so
   .filter-pill's font-weight stays its own literal 600, untouched. */
:root {
    /* Buttons (item 16) */
    --btn-bg: var(--brand, #1e7a3e);
    --btn-ink: var(--brand-ink, #fff);
    --btn-hover-bg: #155928;
    --btn-secondary-bg: #fff;
    --btn-secondary-ink: #1f2937;
    --btn-secondary-line: #d1d5db;
    --btn-danger-bg: #b91c1c;
    --btn-border-w: 1px;
    --btn-weight: 600;
    --btn-radius: var(--radius-control, 8px);
    --btn-size: var(--text-base, 0.875rem);

    /* Cards and page ground (item 17) */
    --ground: #f7f7f8;
    --card-bg: var(--surface, #fff);
    --card-line: var(--line, #e5e7eb);
    --card-radius: var(--radius-card, 12px);
    --card-pad: 1.4rem;
    --card-shadow: var(--shadow, none);

    /* Chips and pills (item 17) */
    --chip-radius: var(--radius-pill, 999px);
    --chip-weight: 700;
    --chip-size: 0.66rem;

    /* Tables (item 17) */
    --tbl-head-ink: #64748b;
    --tbl-head-bg: #f8fafc;
    --tbl-line: #e5e7eb;

    /* Shell: rail and sidebar (item 17) */
    --rail-bg: #13161f;
    --sidebar-bg: #1f2433;
    --sidebar-ink: #e2e8f0;

    /* Disabled state (item 36a). The shared .btn:disabled was already
       0.5; two containers overrode it to 0.6 with no comment, and other
       controls sat at 0.35, 0.4 and 0.55, six numbers for one idea. Every
       disabled button and control in central.css, hq-admin.css,
       style-guide2.css and nav-builder.css now reads this one token, so
       the disabled look is one decision instead of six. The 0.35, 0.4,
       0.55 and 0.6 values fold up or down to 0.5, a small accepted visible
       change (listed in the changelog); the base 0.5 values move to the
       token with no visible change. The engine's own 0.5 base in
       admin.css is untouched: that file is a gitignored copy of the
       engine's, never edited here. */
    --opacity-disabled: 0.5;
    /* Icon buttons (Phase 2 items 24, 25). .row-act was already the
       HQ-wide 36px row action icon button; naming its size here lets the
       three other HQ-authored icon button families (style-guide2.css'
       .fs-btn and .sg2-hbtn.is-icon, central.css' .btn.is-icon) converge on
       the same footprint instead of each carrying its own literal. The
       engine's .abr-icon-btn and .pages-row-icon-btn are not part of this:
       they stay at their own sizes. */
    --icon-btn-size: 36px;

    /* Fields editor drawer (item 33/26). See the z-index scale comment
       above: this is the one documented step above HQ's own 300 ceiling,
       since this drawer must sit above the engine's own drawers (1300). */
    --z-drawer-top: 1310;
    /* Underline tabs (item 27 step one). #4338ca was already the shared
       .tab idiom's own accent (item 54); naming it means the Style guide's
       .sg-tab, folded into .tab in the same item, moves onto this token
       instead of its own --brand-primary, and a later bulk restyle of
       every tab in HQ (Mitchell's stated aim) changes this one value. */
    --tab-accent: #4338ca;
}

/* ---- Colour: ink, surfaces, lines, brand, status, rail (fixes 4, 5, 6, 9) -
   Four separate colour audit items land together because they are the same
   kind of fix: a handful of names for a few hundred near-identical hand-
   typed hexes, each value set to whatever literal already dominates, so
   nothing on screen moves. The board's own palette (Phase 4) then becomes a
   change to this one file instead of a search-and-replace across four. */
:root {
    /* The ink ramp (fix 4). #64748b alone is used around 260 times across
       nine near-twin greys pulled from two different Tailwind ramps
       (slate and gray) mixed at random; these four names are what absorb
       all nine, split by the four weights the interface actually needs:
       heading/body, secondary text, muted/caption text, and placeholder/
       disabled. --ink-3 is the single highest-volume literal in the whole
       codebase. */
    --ink: #0f172a;
    --ink-2: #475569;
    --ink-3: #64748b;
    --ink-4: #94a3b8;

    /* Surfaces and lines (fix 5). Thirteen near-identical "card's quiet
       edge" greys, all within four RGB units of each other, become one
       line token; seven near-white surface hexes become one white and one
       off-white. --surface-3 is the third, slightly cooler panel tone
       (#f1f5f9) alongside --surface-2, kept distinct because central.css
       already uses both as two different depths of panel, not
       interchangeably. */
    --surface: #ffffff;
    --surface-2: #f8fafc;
    --surface-3: #f1f5f9;
    --line: #e2e8f0;
    --line-strong: #cbd5e1;

    /* Brand. --brand is the shared default accent (a real site overrides
       --brand-primary per site from lib/shell.php; this is HQ's own use of
       the same green, e.g. in the two HQ sheets, not the engine's).
       --brand-strong is not a guess: it is the engine's own
       .btn-primary:hover background, read straight off public/admin.css
       so the hover shade can never quietly drift from what a button
       actually does when you hover it. */
    --brand: #1e7a3e;
    --brand-strong: #155928;
    --brand-ink: #ffffff;

    /* Status triples (fix 6): text, background, line, one source for every
       chip, note and banner, values taken from each status's most-used
       literal. style-guide2.css already reads var(--status-success, ...)
       and var(--status-danger, ...) with a fallback, because neither name
       was ever declared anywhere, so those four reads have been silently
       running on their fallback. The four aliases below declare them for
       the first time; nothing in style-guide2.css needed to change. */
    --ok-fg: #15803d; --ok-bg: #f0fdf4; --ok-line: #bbf7d0;
    --warn-fg: #b45309; --warn-bg: #fffbeb; --warn-line: #fde68a;
    --danger-fg: #b91c1c; --danger-bg: #fef2f2; --danger-line: #fecaca;
    --info-fg: #1d4ed8; --info-bg: #eff6ff; --info-line: #dbeafe;
    --status-success: var(--ok-fg);
    --status-warn: var(--warn-fg);
    --status-danger: var(--danger-fg);
    --status-info: var(--info-fg);

    /* Named accents (Phase 2 item 44). A teal did triple duty: a focus
       outline (item 43's, not named here), the timeline's done/current
       pips, and an "ok" note colour that disagreed with every other ok
       green in the app. --accent-teal keeps the pips their own colour,
       since teal reads as a distinct state (done/current) rather than the
       shared ok green; the note folded into --ok-fg instead, since it was
       never anything but an ok message wearing the wrong shade.
       Three unrelated purples covered "informational tag": #4338ca (6
       uses) and #3730a3 (4 uses, a shade darker) name the same idea, so
       both fold onto one token, --tag-ink, at the lighter of the two
       values (the higher-volume literal). #6d28d9 (5 uses) is left its
       own token, --accent-violet: every one of its uses is the same
       self-consistent "behaviour marker" family (a mode badge and its
       dashed-line siblings), a distinct meaning from a plain tag, not a
       fourth purple that happened to survive. */
    --accent-teal: #0f766e;
    --tag-ink: #4338ca;
    --accent-violet: #6d28d9;

    /* The dark rail palette (fix 9): rail, history sheet and the style
       guide/nav builder dark canvases. The same eight values were hand-
       copied into four separate rules (nav-builder.css .dock, central.css
       .hist-sheet, style-guide2.css .welcome and .dock), and two of nav-
       builder.css's eight had quietly drifted from the other three, which
       agreed exactly. The values kept here are the ones the majority (three
       of four) already used; nav-builder.css's .dock now inherits them
       instead of its own slightly different --w-ink-2, --w-ink-3 and
       --w-focus, which is a small, deliberate colour correction on that one
       screen (see the changelog). */
    --w-bg: #101318;
    --w-panel: #171b22;
    --w-line: #262c37;
    --w-line-2: #303846;
    --w-ink: #eef1f6;
    --w-ink-2: #c3ccdb;
    --w-ink-3: #9aa6b8;
    --w-focus: #8fbfa1;
}