/* Design tokens ---------------------------------------------------------- */

:root {
  /* Surfaces */
  --paper:        #ffffff;
  --navy-panel:   #232b38;
  --navy-deep:    #1a212b;

  /* Ink */
  --ink:          #0b1149;
  --ink-soft:     #5c618c;
  --on-dark:      #ffffff;
  --on-dark-soft: #b9bede;

  /* Accents */
  --red:          #e9292b;
  --red-muted:    #b4544a;

  /* Chart ramp — a MONOCHROME sequential scale, spread across each level's
     segments by lib/csv-feather.php. Must stay in step with LMD_TONE_RAMP:
     a tone with no token here makes the band's whole `fill` declaration
     invalid and it renders black, silently. tests/tone-tokens.php guards it. */
  /* A red fade, not the old red-then-blue jump. Every step below 60 is a tint
     of the brand red toward white, so the chart reads as one quantity getting
     lighter down the taper rather than as two unrelated colour families — the
     old ramp went #e9292b straight to #6b7fc7, and that blue bottom half looked
     like a different dataset sharing a silhouette.
     Tints of #e9292b toward white at roughly 26 / 46 / 65 / 84%. The spacing is uneven on
     purpose: equal steps in sRGB are not equal steps to the eye and need to
     bunch up at the pale end. Adjacent bands TOUCH, so the number that matters
     is neighbour-to-neighbour, not against the panel — measured 1.36 / 1.36 / 1.37 / 1.36:1, so
     every seam stays visible without any of them fighting the 60 accent.
     The palest step is ALSO floored at 1.25:1 against #ffffff, because the
     sections alternate and a 93%-white band simply disappeared on the light
     half of the page — a constraint the seam maths alone will not respect. */
  --tone-red-60: #e9292b;    /* brand red — accent */
  --tone-red-50: #ef6162;    /* red, 26% white */
  --tone-red-40: #f38b8d;    /* red, 46% white */
  --tone-red-30: #f7b4b5;    /* red, 65% white */
  --tone-red-20: #fbdddd;    /* red, 84% white */

  /* Retired tone names, kept defined on purpose. Tones are re-derived on read
     so nothing should reach these, but a snapshot naming one must never paint
     a band black. Mapped onto the ramp rather than their old hues, so a stale
     render is the right colour family. */
  --tone-red:        var(--tone-red-60);
  --tone-periwinkle: var(--tone-red-40);
  --tone-pale:       var(--tone-red-20);
  --tone-gold:       var(--tone-red-50);
  --tone-violet:     var(--tone-red-30);
  --tone-orange:     var(--tone-red-60);
  --tone-blue:       var(--tone-red-40);
  --tone-green:      var(--tone-red-20);

  /* Pin tones */
  --pin-red-body:     var(--red);
  --pin-red-face:     #ffffff;
  /* Still called `navy` because app.js, the admin dropdown and the stored data
     all say "navy" — renaming the token would mean a JS edit and a data
     migration for what is a colour change. The NAME is the slot; this is the
     value in it. */
  --pin-navy-body:    #9cc74b;
  --pin-navy-face:    #ffffff;
  /* The `muted` tone is now RED — there is no third pin colour.
     It was #b4544a with an off-white face, a desaturated terracotta that read as
     neither of the two the page actually uses. Three colours in one pin row made
     the odd one look like a state (disabled? stale?) rather than a category, when
     it only ever meant "a category whose tone was not set to navy".
     Kept as its own pair rather than deleted: app.js and the admin both still
     emit `is-muted`, so pointing it at red is the change that needs no JS edit
     and no data migration. */
  --pin-muted-body:   var(--red);
  --pin-muted-face:   #ffffff;

  /* The label sits on the pin's FACE, which is #ffffff in every tone and on
     every ground. It therefore must NOT follow --ink: the section alternation
     redefines that token to white on a dark section, which painted white text
     on the white face and emptied every pin on the page. Its own token, never
     flipped. */
  --pin-label-ink:    #0b1149;

  /* The same problem one level up, for any block that deliberately paints the
     OPPOSITE ground to the section it sits in — it cannot read --ink or
     --on-dark, because those are the two the alternation redefines, so it would
     follow the section it is trying to contrast with. The Recent Intel headline
     band is one: set to var(--on-dark) it rendered near-black on navy at 1.24:1.
     --paper is already safe (never flipped), so only the dark side needs this. */
  --ink-fixed:        #0b1149;

  /* Type */
  --font-display: 'Archivo', 'Archivo Black', 'Helvetica Neue', Helvetica, Arial, sans-serif;

  /* SECTION HEADINGS AND SUBHEADINGS ONLY — Reference/index.html's own two
     families, which header.php already loads. Deliberately not a change to
     --font-display: that token still dresses the pins, the eyebrows, the stat
     figures and the flag chart, none of which are in scope. */
  --font-head: 'Roboto', Arial, 'Helvetica Neue', Helvetica, sans-serif;
  --font-sub:  'Open Sans', Arial, 'Helvetica Neue', Helvetica, sans-serif;

  /* The reference's own heading colour. Its own token because it is NOT --ink
     (#0b1149) and the difference is visible side by side. */
  /* No --head-bg. The reference's pale blue ground went with the container it
     belonged to; the headings sit on the section's own ground now. */
  --head-ink:  #171b43;
  --font-body:    'Archivo', 'Helvetica Neue', Helvetica, Arial, sans-serif;

  --track-eyebrow: 0.16em;
  --track-display: -0.035em;
  --track-wide:    0.055em;

  /* Layout */
  --shell:      1280px;
  --gutter:     48px;
  --pin-hero:   292px;
  --pin-framed: 349px;
  --pin-mini:   192px;
  --pin-speaker: 220px;

  /* Feather geometry, from flag.svg */
  --flag-aspect: 0.3414;
  --flag-w:      214px;
  --flag-mini-w:  46px;
  --flag-label-gap: 34px;
  --flag-label-col: 186px;
  --flag-row-gap:   50px;

  /* Motion */
  --ease: cubic-bezier(0.22, 0.61, 0.36, 1);
}

/* Responsive tokens -------------------------------------------------------

   Two tiers, desktop-first: the values above are the untouched desktop
   defaults. The goal at every tier is to scale the composition down, not to
   reflow it into a single column — sections.css keeps the same
   grid-template-columns/flex-direction at every breakpoint except Section
   4's speaker grid (paragraph-length responsibility text, the one thing on
   the page that doesn't tolerate shrinking). Every consumer of these custom
   properties (pin sizes, flag chart geometry) picks a change up
   automatically — nothing else needs to know a breakpoint exists.

   --pin-hero at the tablet tier is deliberately well under a naive 1/3 of
   the narrowest tablet-portrait width (768px, ~235px per column after the
   gutter): .s1__pins is a plain repeat(3, 1fr) grid, and a 1fr track's
   automatic minimum is its content's intrinsic size — a fixed-width pin at
   or above the column width would force the grid, and the page, wider than
   the viewport. 200px leaves real margin below that 235px ceiling. */

@media (max-width: 1024px) {
  :root {
    --gutter:      32px;
    --pin-hero:    200px;
    --pin-framed:  280px;
    --pin-mini:    150px;
    /* 180px worked for a stacked Section 4; reverted to shrink-not-stack,
       .s4__grid's two ~336px-at-narrowest columns need more room left for
       the responsibilities list than that left them. */
    --pin-speaker: 140px;

    --flag-w:         170px;
    --flag-mini-w:     40px;
    --flag-label-gap:  24px;
    --flag-label-col: 150px;
    --flag-row-gap:    36px;
  }
}

@media (max-width: 640px) {
  :root {
    --gutter:      20px;
    --pin-hero:     92px;
    --pin-framed:  100px;
    --pin-mini:     64px;
    /* Section 4 was the one component that stacked instead of shrinking;
       reverted to match everything else, which needed shrinking harder
       than the tablet tier's 180px to leave real room for the
       responsibilities list beside it in a 335px card. Sized up slightly
       from an initial 90px once the responsibilities text shrank too
       (sections.css) — the two columns read better close in height than
       either did alone. Grown again to 130px once .speaker__resp's own
       max-width (180px, sections.css) freed real slack in the 335px row —
       measured to still leave the text column its full width, with the
       row's remaining space closed by .speaker__top's justify-content
       rather than left as a gap. */
    --pin-speaker: 130px;

    /* Two open levels (feather.js's WINDOW) at the original desktop-derived
       values needed 504px — measured directly on the rendered chart, not
       estimated — against 335px of real available width at 375px viewport
       (shell padding already subtracted), leaving no margin for error.
       Grown twice since: 72/8/65/12 first (326px content, 9px clearance),
       then to 79/9/71/12 (330px content, 5px clearance) — close to the
       335px ceiling this same shell width imposes on every other section,
       while still leaving real margin rather than the ~1px a fully maxed-
       out value would. --flag-mini-w scaled by the same ratio so a third
       collapsed level stays visually consistent with the open ones. */
    --flag-w:         79px;
    --flag-mini-w:     21px;
    --flag-label-gap:   9px;
    --flag-label-col:  71px;
    --flag-row-gap:    12px;
  }
}