/* ============================================================================
   Klariqo v4 design tokens
   MEASURED from the Figma artboard "homenew2-wireframe" (file 5EGdc65YPvA…,
   node 818:2) via Figma MCP on 2026-08-13. These are read values, not
   estimates. Where the file disagreed with the verbal spec, the file wins.

   🔴 THE ARTBOARD IS 1920 WIDE. Every number below is the value AT 1920 and is
   encoded as the MAX of a clamp(), so smaller viewports scale rather than
   break. On a 1440 screen everything renders proportionally smaller. That is
   correct, not a build error.

   ⚠️ NO FIGMA VARIABLES EXIST in the file (get_variable_defs returned {}), so
   this file is the single source of truth for tokens, not a mirror of Figma.
   ============================================================================ */

:root {
  /* ---- Type family -------------------------------------------------------
     Onest, variable 100-900 on Google Fonts. Regular 400 everywhere;
     ExtraBold 800 used ONLY for the transparent outlined display text. */
  --font: 'Onest', system-ui, -apple-system, sans-serif;

  /* ---- Type scale (measured) --------------------------------------------
     size / line-height / tracking, straight off the artboard:
       150 / 150 / -7.5     72 / 70 / -3.6     36 / 45 / -1.8    28 / 38 / -1.4
     Every tracking value is exactly -5% of its size. */
  --t-display: clamp(3.5rem,   7.81vw, 9.375rem);  /*  56 → 150 */
  --t-h1:      clamp(2.5rem,   3.75vw, 4.5rem);    /*  40 →  72 */
  --t-h2:      clamp(1.5rem,   1.88vw, 2.25rem);   /*  24 →  36 */
  /* 🔴 BODY IS 22, NOT THE ARTBOARD'S 28. Ansh's call, 2026-08-13, after seeing
     all four rendered side by side at 1:1.
     Why 28 looked right in Figma and wrong in a browser: a 1920 artboard is
     viewed zoomed-to-fit, so 28px reads as roughly 18px on screen. At true 1:1
     it is nearly the same visual weight as the 36px section header sitting
     above it, and the eye cannot tell which to read first.
     The scale is a clean 2x at every other step (150→72 is 2.08, 72→36 is
     2.00); 28 made the last step 1.29 and broke the rhythm. 22 restores it to
     1.64 and leaves display/h1/h2 exactly as drawn. */
  --t-body:    clamp(1rem, 1.1458vw, 1.375rem);    /*  16 →  22 */

  /* measured, not guessed. h1 is TIGHTER than 1 (70 on 72). */
  --lh-display: 1;      /* 150 / 150 */
  --lh-h1:      0.972;  /*  70 /  72 */
  --lh-h2:      1.25;   /*  45 /  36 */
  --lh-body:    1.357;  /*  38 /  28 */

  /* -5% at every size. MUST be re-declared per size in CSS: set once on body
     it resolves to -1.4px and inherits as a fixed LENGTH, so 150px text would
     get -1.4px instead of -7.5px. */
  --ls: -0.05em;

  /* One step below Regular on the named scale. Onest is a true variable face
     (100-900), so 300 is a real instance, not a synthesised fake-light. */
  --w-regular: 300;
  --w-outline: 800;

  /* ---- Layout (measured) -------------------------------------------------
     Two different insets, and this is the thing to get right:
       PANELS  are 1820 wide on a 1920 artboard  →  50px margin each side
       TEXT    starts at x=150                   →  150px from the viewport
     So a full-bleed panel sits 50px in, and its content sits 100px inside it. */
  --panel-inset:   clamp(1rem,    2.60vw, 3.125rem);  /* 16 →  50 */
  --content-inset: clamp(1.25rem, 7.81vw, 9.375rem);  /* 20 → 150 */

  /* 🔴 The wrapper bound is the ARTBOARD width, not the panel width. Under
     border-box, padding sits INSIDE max-width, so capping at 1820 and padding
     50 yields a 1720 panel at x=92. Capping at 1920 yields the 1820 panel at
     x=50 that the artboard actually shows. Same logic for content → 1620 @150.
     Measured wrong once; this comment is why. */
  --maxw: 1920px;

  /* ---- Spacing (measured) ------------------------------------------------
     Section-to-section runs 150-200 on the artboard; 200 is the common case
     between a section's last element and the next headline. Inner rhythm:
       stacked list items      319 apart
       heading → its body       65
       chip / card gutters      20 (hero pair) and 50 (07 chips) */
  /* 🔴 100, NOT 200, AND THE REASON MATTERS.
     The artboard specifies 150-200px BETWEEN sections. This token is applied as
     `section { padding-block: ... }`, i.e. to the top AND bottom of every
     section, so two adjacent sections summed to 400px. Ansh spotted it as
     "way apart" and was right; the only pairs that looked correct were the ones
     with a blob divider, whose negative margins were clawing some of it back.
     At 100 each side, adjacent sections total 200. That is the artboard number. */
  --gap-section: clamp(2rem,   5.2vw,  6.25rem);   /* 32 → 100 */
  --gap-block:   clamp(2.5rem,  7.81vw, 9.375rem); /* 40 → 150 */
  --gap-inner:   clamp(1.5rem,  2.60vw, 3.125rem); /* 24 →  50 */
  --gap-tight:   clamp(0.75rem, 1.04vw, 1.25rem);  /* 12 →  20 */

  /* ---- Radius (measured) -------------------------------------------------
     🔴 CORRECTS THE VERBAL SPEC. Ansh said "50px on all"; the artboard uses
     three distinct values and the difference is visible:
       20  nav, hero panel, hero cards, pricing cards
       50  blog/feature cards, 07 chips, the big split card, footer notch
       100 buttons (on a 138px-tall button this reads as a full pill)         */
  --r-panel:  20px;
  --r-card:   50px;
  --r-pill:  100px;

  /* ---- Colour (sampled from the exports) ---------------------------------
     GREYSCALE ONLY, deliberately. Ansh's direction: monochrome type, imagery
     carries all colour, ink flips conditionally on whether a background is
     light or dark. */
  --ground:    #FFFFFF;
  --panel:     #D9D9D9;
  /* 🔴 ONE DARK. Locked by Ansh 2026-08-13. There used to be two (#2D2D2D for
     the band and footer, #0F141A for the pricing card) and two darks read as a
     mistake rather than a system. He picked the deeper one. Verified before
     swapping: every on-dark token gains contrast on #0F141A rather than losing
     it (white 13.77 -> 18.5, soft grey 9.76 -> 13.1, accent 6.14 -> 8.25).
     --dark-card is kept as an alias so nothing that referenced it breaks. */
  --dark:      #0F141A;
  --dark-card: var(--dark);
  /* Two lifts off --dark for controls that sit ON the dark band (resting pill,
     hover). Not new colours: the same hue raised in lightness, so the band
     still reads as one surface. */
  --dark-lift:   #1C242E;
  --dark-lift-2: #27313D;
  --mid:       #616161;   /* image placeholder sitting on dark */

  --ink:            #000000;
  --ink-soft:       #565A62;
  --ink-faint:      #8A8F97;
  --ink-onDark:     #FFFFFF;
  --ink-onDark-soft:#D9D9D9;  /* the artboard uses panel grey for body on dark */

  --line:        #E8E9EC;
  --line-strong: #000000;  /* dividers on the artboard are 2px solid black */
  --line-onDark: #3A3A3A;

  /* ---- ACCENT: sky blue. Locked by Ansh 2026-08-13. --------------------
     Sampled from the imagery rather than picked: bucketing the blue-dominant
     pixels of the hero sky and the KCR photo returns the SAME top two in both
     (#1070B0 and #3080C0), so the accent was already in the art.

     🔴 IT IS A PAIR, NOT ONE VALUE, and that is not a stylistic choice.
     The sampled #1070B0 scores 5.29 on white but only 2.60 on --dark #2D2D2D.
     No single blue clears 4.5:1 against both white and near-black.
       --accent        #0F6FB0  -> 5.36 as text on white, AND 5.36 under white
                                   text as a button fill. One hex, both jobs.
       --accent-onDark #6FB4E8  -> 6.14 on #2D2D2D, 8.25 on #0F141A.
     .on-dark swaps them automatically, so tag the section and forget it.
     v3's lime #a3ff0f is retired. Red was ruled out: it reads as danger, which
     is wrong for a compliance product. */
  --accent:        #0F6FB0;
  --accent-onDark: #6FB4E8;

  /* ---- Motion ------------------------------------------------------------ */
  --ease: cubic-bezier(0.2, 0, 0, 1);
  --dur-fast: 160ms;
  --dur:      280ms;
  --dur-slow: 480ms;
}

/* ---- Ink over imagery ------------------------------------------------------
   🔴 MEASURED, NOT ASSUMED. Over the hero photo the soft-grey body token
   (#565A62) scored 1.73:1 against a required 4.5:1. The headline passed at
   4.63 and the bold line at 5.66, so the failure is specific to ink LIGHTNESS.

   The rule that follows: OVER IMAGERY, HIERARCHY CANNOT COME FROM INK
   LIGHTNESS. A photo backdrop is not a uniform tone, so a grey that reads as
   "secondary" on white reads as "unreadable" on sky. Every ink goes to full
   strength and hierarchy comes from SIZE, which is the locked v3 rule anyway.

   .on-image over a LIGHT image, .on-image-dark over a dark one, per Ansh:
   "if bg image is dark, we use light color, else we use dark." */
.on-image {
  --ink: #000; --ink-soft: #000; --ink-faint: #1A1A1A;
  --line-strong: #000; --accent: #000;
  color: var(--ink);
}
.on-image-dark {
  --ink: #FFF; --ink-soft: #FFF; --ink-faint: #E8E8E8;
  --line-strong: #FFF; --accent: #FFF;
  color: var(--ink);
}

/* ---- Conditional ink -------------------------------------------------------
   Ansh: "if bg image is dark, we use light color, else we use dark."
   Tag a section .on-dark and everything inside follows as a set. */
.on-dark {
  --ink: var(--ink-onDark);
  --ink-soft: var(--ink-onDark-soft);
  --ink-faint: var(--ink-onDark-soft);
  --line-strong: var(--line-onDark);
  /* hairline dividers too, or they inherit the light #E8E9EC and glare */
  --line: var(--line-onDark);
  --accent: var(--accent-onDark);
  color: var(--ink);
}
