Map the colour palette onto the design system's scales

[enf0rc3]

Stacked on #3261 — base is wl/design-system-tokens-css, not main. Merge that one first. First of several migration PRs it mentions.

What

The raw palette in vars.css duplicated hex literals that already exist in @octopusdeploy/design-system-tokens. Eighteen entries now reference the matching --colorScales* token.

-  --navy-700: #2e475dff;
+  --navy-700: var(--colorScalesNavy700);

--black, --white, --navy-100…700, --blue-100/200/500, --green-400/500, --red-500, --orange-400/500, --grey-500, and --blue-grey-lighter (which is navy 500 in the design system's scale).

Also removes one dead line: the dark block set --scrollbar-color: var(--navy-300), which is #a9bbcb — the same value :root already resolves to. Pre-existing dead code, found while mapping the palette.

Why only the palette

Scale tokens are theme-invariant, so this layer can move with zero visual risk. The semantic variables above it (--color-text, --body-link-color, --code-background) resolve through this layer unchanged.

Those semantic ones can't come along yet. The docs site's light theme already matches the design system closely, but its dark theme was hand-rolled from a different palette — every semantic swap changes dark mode. That's a design decision rather than a refactor, so it needs sign-off and its own PRs.

This is also why only one html[data-theme='dark'] override goes away here rather than a batch of them. An override becomes redundant when the token it points at themes itself, and scales don't — they carry one value for both themes. Collapsing that block is the payoff of the semantic PRs. The remaining 44 overrides all still change their resolved value, including --navy-200: #314c62, the one palette entry the site deliberately re-themes.

Consuming --colorScales* directly is discouraged for component authors, but this is palette-to-palette: the docs site's raw layer is a scale, and mapping it to the equivalent scale is the semantically correct pairing. The semantic layer will point at semantic tokens (--colorTextPrimary, --colorBorderPrimary) in the follow-ups.

Testing

Every value was verified identical to its token before the swap — 18 exact, 0 mismatched.

Then snapshotted all 886 computed custom properties plus the rendered color, background-color, border-color and font of seven elements (body, paragraph, body link, heading, nav link, code, footer), in both themes, before and after:

PASS: 886 computed properties and 7 rendered elements identical in both themes.
      (93 values changed hex casing / dropped a redundant ff alpha - same colour.)

The --scrollbar-color removal was verified separately against both the post-palette state and the original baseline. Production build clean: 2,697 pages.

Left as literals

--blue-qqq, --green, --light-green, --grey, --grey-light, and the --blue-midnight/--blue-grey families have no scale equivalent. Nothing else became unused — --blue-qqq and --octo-blue-lighter are both still referenced.

Next

Borders and separators, then surfaces, then text, then links — in that order, each needing a dark-mode design call.

🤖 Generated with Claude Code