Skip to content

v2.9.0 — Gate 3 grades the token system, not the colour notation

Latest

Choose a tag to compare

@staurus86 staurus86 released this 08 Sep 13:38
· 2 commits to master since this release

Gate 3 grades the token system, not the colour notation

The skill was run against a live site as a working test. The audit it produced failed that page's design system because its colours were written in hex. That was the gate's fault, not the page's.

Hex, rgb and OKLCH are notations. A design system is defined by something else: whether tokens are canonical, whether roles are semantic, whether the same colour means the same thing everywhere. Six tidy hex tokens used consistently are a good system. Two hundred chaotic oklch() calls are not.


Changed

Gate 3 is now design-token integrity.

  • One canonical :root — no token declared twice with conflicting values
  • Component colours come from semantic tokens; a raw literal is allowed only as a stated exception
  • Light and dark define the same roles, not ad-hoc pairs
  • Hover, focus and disabled reuse the scale instead of inventing colours
  • Type scale with clamp(), spacing on a 4px grid, all values as custom properties

Notation is a documented default, not a pass condition. OKLCH stays what the skill writes — equal lightness steps hold across hues, and a contrast fix is one number — but a consistent hex or rgb system passes the gate.

Updated in SKILL.md, quality-gates.md, checklists/global-design-review.md and the project CLAUDE.md.

The banned pattern "hex colors when OKLCH equivalents are available" is gone. What is actually banned is mixing notations inside one system, or a token defined twice with different values.

Converting a palette now carries an instruction: convert numerically and diff the result. An eyeballed "perceptual equivalent" changes the brand colour under cover of a colour-space migration. This was written after the skill produced three such approximations in a real audit and had them caught — the worst was off by 5% lightness and 10° of hue.

Added

verify-rendered.mjs gained a token-conflict check, and it is a hard failure. It reports any custom property declared twice in :root with different values. On the first real page it ran against it found:

FAIL Gate 3 token-conflict: --accent: #bd492e vs #b5462d

Those two values are 1.7% apart in lightness and 0.3° in hue — oklch(55.76% 0.1554 34.5) against oklch(54.07% 0.1497 34.2). No eye separates them, which is why the drift survived. No notation check would ever have surfaced it.

The old literal count remains, demoted to a warning that asks for justification rather than a rewrite:

N rule(s) hold a colour literal rather than a token — confirm each is a stated exception, not drift

Verified

Check Result
Runner self-test clean fixture exit 0, defective fixture exit 1
New check against a live site found a real token conflict unaided
Test suites 42 + 73 pass
gds doctor installed copy matches source

Upgrading

git pull
python scripts/gds install --tool=claude-code /path/to/your-project
python scripts/gds doctor /path/to/your-project

If you had adopted the old Gate 3 literally, the practical change is this: stop rewriting working hex palettes into OKLCH for the sake of the gate, and start checking that no token is defined twice.

Full detail: CHANGELOG.md.