/* ═══════════════════════════════════════════════════════════════════════════
   ivo-tokens-7.css - the single source of truth for IVO brand TOKENS.
   Split out of ivo-tokens-6.css on 2026-09-18. Nothing in here is a rule:
   every declaration is a custom property. That is the whole point.

   WHY THE SPLIT
   -------------
   ivo-tokens-6.css was two files in one: token DEFINITIONS (its sections 1-3)
   and element RULES for the WHMCS/Bootstrap markup (sections 4-8: body/p/h1-h6
   font sizes, label weights, .form-control metrics, the .btn spec, the
   modal-open height fix). Because of the rules it had to be gated off the SPA
   with {if $smarty.get.m != 'ivo'} - and that gate took the tokens with it, so
   the dashboard had no brand token at all while the rules it did not want were
   the only reason for the gate.

   Measured on 2026-09-18 by rendering the SPA with the whole file ungated
   (light+dark x coral+blue x 1280+390, pixels sampled off a text-transparent
   plate, not read off the CSS): the rules restyle the dashboard - every heading
   changes typeface, p goes 13px -> 15px, label 400 -> 600, .btn line-height
   1.5 -> 1.2 - and section 7 repaints bare input[type=submit] as a filled pill
   whose white label measures 3.74:1 (light coral), 2.82:1 (dark coral) and
   3.68:1 (dark blue) against the SPA's own raw accent. Three of four
   combinations below AA. The rules belong to the client area; the tokens belong
   to everything. Hence two files.

   THE TOKENS LOAD ON EVERY SURFACE. The rules file loads where its markup is.

   WHY THIS FILE EXISTS AT THIS PATH
   ---------------------------------
   /_v4css/ is OURS. WHMCS core updates replace core PHP, vendor/, templates/six,
   templates/twenty-one and the admin templates WHMCS ships - they never touch
   /_v4css/. A Nexus THEME update would overwrite templates/nexus/** including
   custom.css, so brand values must not live there. Keeping every token here
   means an update can clobber the vendor theme without losing the brand; the
   only thing to restore is the single <link> line in header.tpl.

   ORDER. This file must stay immediately BEFORE ivo-brand-rules-1.css, at the
   exact point ivo-tokens-6.css used to load. Splitting a file in two and
   linking the halves back to back is a cascade no-op only if the order holds;
   that is what keeps the client area byte-identical across this change.

   DO NOT add colours or sizes anywhere else. If a value is needed, add a token.
   DO NOT add a rule here. A rule here would reach the SPA, which is the defect
   this split exists to end.
   ═══════════════════════════════════════════════════════════════════════════ */

/* ── 1. ACCENT ──────────────────────────────────────────────────────────────
   One accent, and it is an accessibility decision, not a taste one. Measured
   against white label text:
       #5b8cff  3.16:1  FAIL   (was on register, login, reset, clientarea)
       #007bff  3.98:1  FAIL   (vendor Nexus default)
       #4687ff  3.40:1  FAIL   (.promo-banner.nordvpn leftover demo CSS)
       #2563eb  5.17:1  PASS   <- chosen; already --primary in custom.css
       #1d4ed8  6.70:1  PASS   <- hover/active
   The coral accent had the same defect (#f2664a = 3.10:1). #c4533c is the same
   hue darkened until white text reaches 4.52:1.

   --ivo-brand-accent is the brand's own copy of that value, under a name nothing
   else on the platform defines. --ivo-accent points at it, and so does the
   --primary re-point below; the note there says why the indirection is not
   decoration.                                                                */
:root{
  --ivo-brand-accent:#2563eb;
  --ivo-brand-accent-deep:#1d4ed8;

  --ivo-accent:var(--ivo-brand-accent);
  --ivo-accent-deep:var(--ivo-brand-accent-deep);
  --ivo-accent-ink:#ffffff;
}
[data-accent="coral"]{
  --ivo-brand-accent:#c4533c;
  --ivo-brand-accent-deep:#a8442f;
}
/* --primary is a VENDOR-owned name. Stock theme.min.css declares --primary:#007bff
   at :root, and the child theme's custom.css reads it nine times: a{color},
   .btn-primary, .btn-outline-primary, .form-control:focus, .form-check-input:checked,
   .page-link / .page-item.active .page-link, .store-promoted-product .btn-success
   and the domain-checker gradient. Those nine are what this re-point is for.
   (Bootstrap's own compiled utilities are NOT among them: theme.min.css and
   all.min.css contain zero var(--primary) - Bootstrap 4 compiles the hex. An
   earlier version of this comment claimed they read it. That was wrong.)

   It reads --ivo-brand-accent and NOT --ivo-accent, deliberately. Since the
   2026-09-18 split this file loads on the SPA too, and on the SPA :root
   --ivo-accent belongs to the 14-theme system, not to the brand - reading it
   here would make --primary resolve to whichever theme the viewer picked.
   Measured on the rendered dashboard, that is #a87749 in the default 'tan' light
   theme and #60a5fa in dark, instead of the brand accent. Nothing reads
   --primary on the SPA today, so that was latent rather than live; but --primary
   is a name a WHMCS or Nexus update is entitled to start consuming at any time,
   and a token whose value depends on which surface it is read from is a trap.
   --ivo-brand-accent has exactly one owner: this file.                        */
:root{ --primary:var(--ivo-brand-accent); --primary-lifted:var(--ivo-brand-accent-deep); }

/* ── 2. TYPE SCALE ──────────────────────────────────────────────────────────
   NOT invented here. These are the canonical tokens from
   platform/assets/design-tokens.json, which generates
   platform/assets/css/ivo-tokens.css (--ivo-font-*) and the mobile theme.
   The component styleguide at workspace/shared/design/styleguide/index.html is
   the reference all surfaces target.

   Each token reads the generated variable and falls back to the canonical
   number, so this file is correct whether or not /assets/css/ivo-tokens.css is
   linked on the page - and if it ever is, these follow it automatically instead
   of drifting. Do not hardcode a size here; add a token upstream.

   Canonical: xs 11 · sm 12 · meta 13 · body 14 · base 15 · md 16 · lg 17
              xl 22 · hero 26                                                */
/* --ivo-font is DELIBERATELY still duplicated, in the same sense as the radii
   below. platform/assets/css/ivo-ui.css:17 declares its own :root --ivo-font
   ('Inter', -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif)
   and consumes it four times (ivo-ui.css:176,250,395,899) plus once from
   ivo_spa.js:2537. ivo-ui loads AFTER this file on the SPA, so the dashboard
   keeps its own stack - rendered and confirmed identical before and after the
   split. Collapsing the two means changing the SPA's fallback chain
   (BlinkMacSystemFont out, system-ui / Helvetica Neue / Arial in), which is a
   design decision, not a mechanical one, so it is not made here. Counting this
   file's tokens as "one definition per token" is therefore wrong: --ivo-font,
   --ivo-radius-sm, --ivo-radius-lg and --ivo-accent all still have a second,
   SPA-side owner, and --primary / --primary-lifted are duplicated against the
   vendor theme on purpose.                                                   */
:root{
  --ivo-font: Inter, -apple-system, "system-ui", "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif;

  --fs-xs:   var(--ivo-font-xs,   11px);
  --fs-sm:   var(--ivo-font-sm,   12px);
  --fs-meta: var(--ivo-font-meta, 13px);
  --fs-body: var(--ivo-font-body, 14px);
  --fs-base: var(--ivo-font-base, 15px);
  --fs-md:   var(--ivo-font-md,   16px);
  --fs-lg:   var(--ivo-font-lg,   17px);
  --fs-xl:   var(--ivo-font-xl,   22px);
  --fs-hero: var(--ivo-font-hero, 26px);

  /* Marketing display type only. The token scale stops at 26px because it was
     built for the app; DESIGN_CONSISTENCY.md leaves the marketing scale (base
     14) versus the token scale (base 15) as an OPEN Phase B decision, so the
     marketing sizes measured on live are preserved rather than forced to 26.
     These are the only two sizes in this file not from design-tokens.json. */
  --fs-display:clamp(34px, 5.2vw, 54px);
  --fs-display-hero:clamp(40px, 6.4vw, 66px);

  --lh-tight:1.05;
  --lh-snug:1.25;
  --lh-normal:1.55;

  --fw-body:400;
  --fw-ui:500;
  --fw-strong:600;
  --fw-display:700;
}

/* ── 3. BUTTON SPEC ─────────────────────────────────────────────────────────
   Adopted from the marketing .v3x .btn rule, which was already the most
   considered button on the platform. Now every surface uses it.              */
:root{
  /* styleguide: .btn{font-weight:600;font-size:14px;padding:10px 18px}
                  .btn-sm{padding:6px 13px;font-size:12.5px}                */
  --ivo-btn-fs:var(--fs-body, 14px);
  --ivo-btn-fw:600;
  --ivo-btn-pad:10px 18px;
  --ivo-btn-pad-sm:6px 13px;
  --ivo-btn-fs-sm:12.5px;
  /* Canonical radii (design-tokens.json): 4 / 8 / 12 / 16 / 18 / pill.
     RESOLVED 2026-09-13 by owner decision: full-round pills, everywhere.
     This was previously held at --r-lg 12px because the styleguide's .btn
     uses --r-pill (999) while DESIGN_CONSISTENCY.md called full-round pills
     "a marketing-layer styling choice, not a token", and nobody had settled
     it. The owner settled it in favour of the styleguide, platform-wide, so
     the client area, cart, login, register and marketing now match the SPA
     (which was already 999px via its own shell styles). DESIGN_CONSISTENCY.md
     should be updated to record that pills ARE the token. */
  --ivo-btn-radius:var(--r-pill, 999px);
  --ivo-radius-sm:var(--r-md, 8px);
  --ivo-radius-md:var(--r-lg, 12px);
  --ivo-radius-lg:var(--r-xl, 16px);
}

/* The client-area button fill does not read --primary at all. It resolves
   through a three-file chain, which is how a colour failing AA reached every
   signup and login button:
       whmcs-skin-11.css   #main-body .btn-primary{background:var(--w-acc)!important}
       ca-dash-rebuild.css #main-body{--w-acc:var(--accent,#e8502e)}
       ca-theme-7.css      html[data-accent="blue"] #main-body{--accent:#5b8cff}
   Re-point the fill token instead of fighting three !important declarations.
   Equal specificity to ca-dash-rebuild's rule (1,0,0); this file loads later.

   --accent itself is deliberately NOT re-pointed. It is also used for text and
   borders on dark panels, where a fill-strength blue is too dark to read. Fill
   and accent-text are different jobs and keep different tokens. */
#main-body{
  --w-acc:var(--ivo-accent);
  --w-acc-deep:var(--ivo-accent-deep);
}