Author import-ready Tokens Studio JSON for the missing beta colour tokens

[pomfrida]

Part of #4740, follow-up from the Button migration test case (#5208).

The Button migration surfaced gaps and bugs in the Tokens Studio beta export that must be fixed at the source. The studio CLI is pull-only, so the changes are authored as token JSON in the same structure as the pulled raw sets (packages/eds-tokens/src/tokens/raw/) and imported via the Studio UI by design.

Scope

Author proposal JSON covering:

• Alpha-channel disabled tokens (🎨 Implement Alpha‑Channel approach for disabled states #4741) — as explicit values, not modify formulas (only the CSS export evaluates colour formulas)
• A semantic action/fill group for buttons (the current background-surface-accent-* values are unsuitable as solid fills; Button consumes steps 9/10/11 directly in the meantime)
• Accent text/border semantic tokens (secondary/ghost Button currently uses steps 12/8)
• Neutral/danger equivalents of the accent-only semantic surface group (tone support)
• Fix the border-focus self-reference in the semantic set (concept vs semantic name collision; border-disabled has the same collision with two conflicting values)
• Step-based state naming per 🧩 Re‑evaluate token naming conventions #4744, reusing existing colour values per 🎛 Review & Refine Colour Token values #4742

Notes

• The platform has no undo — changes go onto a Studio work branch with design review before merge and release
• Alpha percentages need design sign-off to become canonical

Definition of Done

• Import-ready JSON authored and shared with design
• Names and values reviewed by design
• Imported to Tokens Studio on a work branch and shipped in a beta release
• Verified after studio tokens pull that the src/tokens/css/ output contains and resolves the new tokens

[claude]

These issues appear closely related to this work and may be worth cross-referencing while authoring the token JSON:

• [Button] Migrate to new beta colour tokens #5208 — [Button] Migrate to new beta colour tokens (open): the migration test case that surfaced the export gaps this issue is meant to fix at the source.
• 🎨 Implement Alpha‑Channel approach for disabled states #4741 — 🎨 Implement Alpha-Channel approach for disabled states (open): the alpha-channel disabled tokens called out in the Scope section.
• 🎛 Review & Refine Colour Token values #4742 — 🎛 Review & Refine Colour Token values (open): the reuse-existing-colour-values requirement referenced for the new tokens.
• 🧩 Re‑evaluate token naming conventions #4744 — 🧩 Re-evaluate token naming conventions (open): the step-based state naming convention this JSON should follow.
• 🎨 Refine the EDS Colour & Token System #4740 — 🎨 Refine the EDS Colour & Token System (open): the parent epic this task is part of.

This comment was generated by an LLM and may be inaccurate. Please verify that the linked issues are actually relevant.

[pomfrida]

Additional export/palette finding from the Chip migration (#5225), dark scheme:

The dark step scale looks mis-generated around the subtle ladder (steps 2/4/6):

• Step 6 is identical to step 3 in every dark scale (e.g. --eds-dark-north-sea-3 and --eds-dark-north-sea-6 are both oklch(0.47 …)), and step 4 (L 0.52) is lighter than step 6. The semantic subtle ladder --eds-background-surface-*-subtle-{default,hover,pressed} = steps 2/4/6 therefore resolves to L 0.226 → 0.52 → 0.47 in dark: a huge jump on hover and a pressed state lighter than hover. (The legacy light palette has a similar duplicate, 6 == 4, so this may be inherited generator behaviour rather than new.)
• Step 2 in dark (L 0.226) is nearly the canvas colour (step 1 = L 0.19), so subtle-default fills are almost invisible on the dark canvas. Legacy chips used step 3 (L 0.47) here, which reads as a clearly visible fill. In light the step 2 vs 3 difference is negligible; in dark it is the difference between a visible chip and a ghost.
• --eds-text-on-accent in dark resolves to north-sea-14 (L 0.33), noticeably lighter than the legacy near-black on-emphasis text — same class of deviation as the light-mode one already listed, but on the dark side.

See the dark-mode comparison comment on the Chip PR (#5225) for the measured values and prod-vs-local screenshots. Affects any component using the subtle ladder for interactive fills (Chip now; Button secondary/ghost hover uses steps 4/6 too).

[pomfrida]

The import-ready JSON is authored and ready for design review: PR #5227.

The review document is token-proposals/5221-beta-colour-gaps/README.md — every change with rationale, the computed alpha values, and import instructions (Studio work branch, sets imported as replacements since the collision fixes are removals).

Three things that need a design decision:

1. The alpha percentages — derived to match today's opaque steps 3/7 exactly over white/black (≤ ±12/255 deviation over the canvas), but they need sign-off to become canonical.
2. Disabled strength — the semantic set previously said neutral.5 (text/icon) and neutral.2 (border) while the scheme sets and the legacy bundle use step 7; the proposal standardises on step 7.
3. text.accent — currently points at {info.8} (link blue); the proposal repoints it to {accent.12}, with link blue still available as text-link.

No rush — the proposal regenerates from a fresh studio tokens pull (node build-proposal.mjs), so it won't rot while this waits. cc @alexlvrs @eddiman

[pomfrida]

Note from #5239 (review finding): the three name collisions this issue tracks (border-focus self-reference, text-disabled, border-disabled double declaration) now have a slightly larger blast radius — the semantic layer is declared on every [data-color-scheme] element (not just :root), and it wins the collisions at equal specificity there. Once the content fix lands, consider adding an assertion in packages/eds-tokens/scripts/generate-css-bundle.mjs that no custom property is declared in both the color-scheme layer and the semantic layer, so regressions of this class fail the build.