Spec — Primitive color palette

Tier: primitive (the "wheel"). This is the layer below semantic roles. A role like accent or success (color-roles.kmd) and a product icon's dominant color (icons/products.kmd) MUST resolve to a named step here (e.g. blue-600), never a free hex. This kills the "which blue / how deep" guesswork by making every color a reference.

Relationship to the existing color specs (no duplication)

R1 — Method (OKLCH, gamut-clipped)

Ramps are generated in OKLCH (Björn Ottosson) for perceptual uniformity — equal numeric steps look equally far apart, fixing the uneven-brightness jumps of naïve HSL. Each named hue is anchored by a 600-ish hex; the generator fixes a perceptual-lightness target L per step and scales chroma along a peak-in-the-middle curve, then clips chroma into the sRGB gamut where a step would otherwise be unrepresentable. Resolved sRGB hex is persisted (with the source oklch in $extensions) so non-CSS targets (RFC-006: 7 languages) get hex directly. Generator: palette/primitives/generate_primitives.py.

Per-step perceptual lightness L (OKLCH, 0–1):

R2 — Named hues (the wheel)

11 hues: one neutral (slate) + a 10-hue chromatic wheel covering every product/domain need. Full step values + WCAG contrast live in primitives.json; this table is the symbolism/derivation index.

R3 — Usage matrix (which step goes where)

A band discipline that holds across all hues (because OKLCH L is constant per step). Light theme shown; dark theme mirrors (swap the band, keep the hue).

Contrast gate (hard): any text/icon step on its background MUST meet WCAG AA (4.5 normal / 3.0 large). primitives.json carries contrast_on_white / contrast_on_black per step; kicon validate and koder-spec-audit themes enforce. Roles in color-roles.kmd keep their existing contrast targets — this spec just makes the chosen step explicit.

R4 — Domain → signature hue (RFC-003 L1)

Each L1 domain gets a signature hue for domain-level identity (domain landings, console chrome, docs section accents). This is the systematic anchor; it does NOT force every product in the domain to that hue (see R5).

R5 — Product → hue alias (icon dominant color)

Product launcher icons need mutual distinctiveness on a home screen, so each product picks its own wheel hue (it does not collapse to its domain hue). What makes them read as one family — the #1 gap in #038 — is not a shared hue but a shared band rule:

Icon family rule. Dominant fill = <hue>-600. Icon gradient runs <hue>-700 (deep, bottom) → <hue>-500 (mid) → <hue>-400 (light, top). White symbol in negative space. All hues sit in the same OKLCH lightness band, so seven different hues still look like siblings. This supersedes the ad-hoc hexes of the 2026-06 proposal and refines icons/products.kmd §1 ("cor derivada da paleta Koder") from prose to a concrete reference.

The single-hue-per-product rule (products.kmd §1) stays; the optional analogous-neighbor light end (e.g. Mail → orange-400) is the only sanctioned two-tone, and stays within one wheel-neighbor — not Google's full polychromy. New products: pick a free wheel hue; record it here.

R6 — Machine-readable source of truth

palette/primitives/primitives.json (DTCG, koder.* extensions) is authoritative; palette.kmd is the human mirror. Regenerate with generate_primitives.py (pure-Python OKLCH, no deps). Distribution to the 7 token languages rides RFC-006; Figma sync rides RFC-005. Never hand-edit the JSON hexes — change the anchors/curve and regenerate.

Open decisions (owner sign-off → ratify)

• Ratify the 11-hue set + L-band targets (or tune).
• Confirm domain→hue map (R4) and product→hue map (R5).
• Whether color-roles.kmd should be migrated to reference primitive steps now, or in a follow-up (this spec is non-breaking until then).

Sign-off