Colour naming
=============

Spec: descriptive guidance, not a checkable rule.
It carries no forbidden and instead pair, and no `jig check` detector applies to it directly.
Section: Design Tokens

Two layers, and only one of them is used in component code.

**Primitive** — named by appearance, numbered 0–1000 by contrast. `grey.light.700`, `green.dark.1000`. These exist to be referenced by semantics. **Never use a primitive directly in a component.**

**Semantic** — named by use, in the order `element.tone.emphasis.state`:

| element | tone | emphasis | state |
| --- | --- | --- | --- |
| text | neutral | strong | hover |
| stroke | brand | weak | press |
| icon | error | | focus |
| fill | warning | | disabled |
| background | success | | |

Words that are the default are omitted, which is why `--color-text-strong` needs no tone and `--color-fill` needs neither. Examples: `--color-text-error`, `--color-stroke-strong`, `--color-fill-success`, `--color-stroke-brand-weak`.

The payoff is mode switching: one semantic name maps to a different primitive in light and dark, so component code never mentions a mode.

Resist per-component tokens (`--button-bg`). They multiply fast and rarely earn it.