/* ═══════════════════════════════════════════
   Monochrome affiliate surface — shared by honeybadger. and revolution.
   ═══════════════════════════════════════════

   The affiliate site is black, grey and white. The Co-Operate mark is the only
   thing on it that carries Electric Blue.

   WHY THIS IS A TOKEN OVERRIDE AND NOT ~130 EDITS.

   The accent reaches this surface through two token families and roughly 67
   inline styles across five pages, plus a long tail inside `affiliate.css` that
   three of the eight pages do not even load. Editing each call site would be a
   large diff that is wrong the moment someone adds one more. Neutralising the
   tokens catches every consumer, including the ones nobody has written yet.

   WHY `--color-primary` AND NOT JUST `--g-accent`.

   The first cut of this file overrode `--g-accent`, `--g-accent-hot` and
   `--g-accent-rgb` — and changed almost nothing, because apple.css defines
   `--g-accent: var(--color-primary)` and every button, `.accent` span and
   theme-switch track reads `--color-primary` DIRECTLY. Neutralising the child
   token while the parent stayed blue left 124 blue elements on the index alone.

   That was invisible until the audit stopped regex-matching computed colour
   strings: these tokens compute to `oklch()`, Chrome preserves the colour space
   rather than converting, and an `rgb()` pattern over the computed value
   matched nothing at all. It reported 12 offenders and no blue in the mark —
   both wrong. `verify-mono.mjs` resolves colours through a canvas instead.

   `--color-primary-foreground` has to move with it. `.a-btn-primary` is
   `background: var(--color-primary); color: var(--color-primary-foreground)`,
   and primary-foreground is near-white — so neutralising the fill alone turns
   every primary button into white-on-white.
*/

:root[data-brand="affiliate"] {
  /* The one colour that survives. Held separately so a future sweep over
     `--color-primary` cannot take the last colour off the site by accident. */
  --brand-mark: #5F7FFF;

  /* The accent, neutralised. Emphasis becomes contrast rather than hue. */
  --color-primary: var(--color-foreground);
  --color-primary-foreground: var(--color-background);

  --g-accent: var(--color-foreground);
  --g-accent-hot: var(--color-muted-foreground);

  /* Literal channels: consumed as `rgba(var(--g-accent-rgb), 0.08)`, and
     rgba() cannot take an oklch() token. The tints become white or black
     washes, which is what a greyscale surface is built from anyway. */
  --g-accent-rgb: 255, 255, 255;
}

:root[data-brand="affiliate"][data-theme="light"] {
  --g-accent-rgb: 0, 0, 0;
}

/* ── The mark keeps its blue ──
   It strokes `var(--color-primary, #5F7FFF)` inline, which is now neutral, so
   the colour has to come back from the token the override does not touch. */

:root[data-brand="affiliate"] .a-nav-mark circle:first-of-type {
  stroke: var(--brand-mark);
}

/* ── Accent used as a FILL behind hardcoded white text ──
   `.g-form-submit` is `background: var(--g-accent); color: #fff`. That reads
   fine against Electric Blue and becomes white-on-white the instant the token
   goes neutral — an invisible submit button on the role pages that carry a
   form. The `#fff` is inline in each page's <style>, so pair the fill with its
   own inverse here rather than editing four copies. */

:root[data-brand="affiliate"] .g-form-submit {
  background: var(--color-foreground);
  color: var(--color-background);
}

/* ── Links with no colour of their own ──
   The skip link and the body links in the three legal pages carry no colour
   rule, so they fall through to the user agent's default link blue — #0000EE
   in light, a pale blue in dark. Nothing in the token system reaches them, and
   on a monochrome surface they are the most obviously wrong thing on the page.
   Underline kept: it is what distinguishes a link once hue no longer does. */

:root[data-brand="affiliate"] .a-skip-link,
:root[data-brand="affiliate"] a:not([class]) {
  color: var(--color-foreground);
  text-decoration: underline;
  text-underline-offset: 2px;
}

/* ── ...and except in the nav, for the same reason ──
   `affiliate.js` builds the nav links with no class — `<li><a href="#b-how">How
   It Works</a></li>` — so `a:not([class])` above caught all seven of them and
   gave the affiliate hosts an underlined, full-contrast nav where every other host has
   muted, undecorated links. Same cascade bug as the footer immediately below,
   from the same rule, found the same way: by looking at the rendered page
   rather than at the markup, which was identical to apex's all along.

   `.g-nav-links a` in apple.css already sets exactly these two values; this
   restates them only to win against the `:root[data-brand]` specificity above,
   which no amount of ordering in apple.css can beat. */

:root[data-brand="affiliate"] .g-nav-links a {
  color: var(--color-muted-foreground);
  text-decoration: none;
}

:root[data-brand="affiliate"] .g-nav-links a:hover,
:root[data-brand="affiliate"] .g-nav-links a.active {
  color: var(--color-foreground);
}

/* ── ...except in the footer, which is the same on every host ──
   The footer's links carry no class either, so the rule above caught all seven
   of them and gave the affiliate surface a footer with brighter, underlined links while
   every other host kept muted, undecorated ones. The whole point of
   `shared/footer.html` is that this component does not vary by surface.
   `shared/footer.test.ts` did not notice because it compares MARKUP, and the
   markup was still identical — the divergence was entirely in the cascade.
   `tests/hig-conformance.spec.js` now compares the computed styles instead. */

:root[data-brand="affiliate"] footer[role="contentinfo"] a {
  color: var(--color-muted-foreground);
  text-decoration: none;
}

:root[data-brand="affiliate"] footer[role="contentinfo"] a:hover {
  color: var(--color-foreground);
}

/* ── The share rail's hardcoded blues ──
   `.share-bar a` is `color: #7B8FE0` with a `rgba(45, 79, 230, 0.15)` hover
   fill — literal values in the page's own <style>, reaching no token. The rest
   position it, so this cannot be fixed by neutralising anything.

   The link rule above already wins on `color` (the rail's anchors carry no
   class), but it sets no background, so the blue hover fill survived it. It
   only paints on hover, which is why the pixel audit — which never hovers —
   reported the page clean. Stated explicitly here so both states are grey. */

:root[data-brand="affiliate"] .share-bar a {
  color: var(--color-muted-foreground);
}

:root[data-brand="affiliate"] .share-bar a:hover {
  background: color-mix(in oklab, var(--color-foreground) 12%, transparent);
  color: var(--color-foreground);
}