@sondalab/ui-kit 0.4.0 → 0.5.0

package/agent/HANDOFF.md

@@ -38,7 +38,7 @@ For elements already named eyebrow/tag, the recipe (mono + uppercase + tracking
 Evaluated and **dropped**: the only literal faces across the calibrated surfaces are introspect's IBM Plex Mono (a blessed mono substitute) and spexr's editor font (blessed). A font check would yield nothing. Just keep using `var(--sl-font-display|sans|mono)`; the only allowed substitution is a *narrower mono* where fixed pixel grids demand it (`design-language.md` L1), recorded as a blessed `font` deviation.
 
 ### Accent step derivation  *(check 7 — advisory this release, mechanical next)*
-`design-language.md` §Decision 2 now requires each accent step (`--sl-accent-hover/active/subtle`) to be a `color-mix()` off `--sl-accent-default`, not a baked literal — a literal is allowed only as an explicit per-(theme, step) token override with a reason (e.g. dark-active `#E0942A`). This is **syntactically checkable** (unlike the value-level checks above): a step declaration whose value is a bare hex/`rgb()` and is *not* a registered token override is a derivation defect. It ships **advisory** this release — judge it by eye, flag it in the migrate/author report, but the script does not yet fail on it. The mechanical check lands next release once the token-override escape-hatch list is settled. **How to judge:** open the product's theme layer; every accent step should read `color-mix(in srgb, var(--sl-accent-default) …)` or be a `sondalab.tokens.json accent.*` override carrying a `why`.
+`design-language.md` §Decision 2 requires **every** accent step (`--sl-accent-hover/active/subtle`) to be a hue-relative expression off `--sl-accent-default` — `color-mix()` (Baseline) or `oklch(from var(--sl-accent-default) …)` relative colour (dark-active only) — never a bare literal that would leak the previous hue when a product overrides only the default. The relative-colour step carries a preceding baked-literal **fallback** line (for browsers below the relative-colour floor); that fallback is the *only* legitimate bare-literal accent-step declaration, and it is always paired with a following `oklch(...)`/`var(--sl-accent-default)` line. This is **syntactically checkable** (unlike the value-level checks above): an accent-step declaration whose value is a bare hex/`rgb()` with **no** sibling relative-colour declaration for the same property is a derivation defect. It ships **advisory** this release — judge it by eye, flag it in the migrate/author report, but the script does not yet fail on it. The mechanical check lands next release. **How to judge:** open the product's theme layer; every accent step should read `color-mix(in srgb, var(--sl-accent-default) …)` or an `oklch(from var(--sl-accent-default) …)` (optionally preceded by its fallback literal on the same property).
 
 ## Structural / judgement rules the script never sees
 

package/agent/blessed/default.json

@@ -13,15 +13,10 @@
     {
       "kind": "color",
       "values": [
-        "#F7B863",
         "#8b96ff",
-        "#a3acff",
-        "rgba(139,150,255,0.12)",
-        "#2ee6c0",
-        "#5ad1ff",
-        "rgba(46,230,192,0.12)"
+        "#2ee6c0"
       ],
-      "why": "The showcase demonstrates the per-product accent registry (design-language.md §Decision 2): spexr's indigo and introspect's cyan (plus derived hover/subtle) appear as demo swatch content, not as a second accent adopted by the showcase. Blessed by exact value, not selector — the swatches live in a JS object with no distinctive selector. #F7B863 is the amber demo hover, hardcoded in the same switcher object; once the dark accent hover became color-mix-derived it left the token allowlist, so it is blessed here alongside the other demo hovers (the switcher itself re-deriving is deferred to the migration)."
+      "why": "The two non-amber demo hues in the showcase accent switcher: spexr's indigo and introspect's cyan, both registered product accents (accent-registry.json). They appear as demo swatch content so the page can show the per-product registry (design-language.md §Decision 2), not as a second accent adopted by the showcase. Blessed by exact value — they live in a JS object with no distinctive selector. Only the hue is listed now: hover/active/subtle are no longer hardcoded (the switcher sets only the hue and they re-derive), so the previous demo step-literals are gone."
     }
   ]
 }

package/agent/design-language.md

@@ -44,7 +44,7 @@ Shared grammar, per-product accent. The brand default is amber (with a teal *dep
 
 Machine values of this table: `packages/ui-kit/agent/accent-registry.json` (consumed by the compliance audit). The table above stays authoritative for the reasoning; `scripts/accent-registry.test.mjs` asserts product-set parity between the two.
 
-Rule: a product picks **one** accent hue and derives hover/active/subtle from it; it never introduces a second chromatic accent. **Derivation is concrete:** the generator emits each accent step as a `color-mix()` off `--sl-accent-default` (e.g. `--sl-accent-hover: color-mix(in srgb, var(--sl-accent-default) 89%, black)`), so a product override sets **only the hue** and the family re-derives. A baked step *literal* is allowed only as an explicit per-(theme, step) override in `sondalab.tokens.json` `accent.*` carrying a reason — the escape hatch for the few steps a straight mix can't reproduce (e.g. dark-active's slight hue rotation). This is enforced advisorily today (a judgement note); the audit gains a mechanical derivation check in a following release (see `packages/ui-kit/agent/HANDOFF.md`). Semantic status colours (ok/warn/err) are separate from the accent and shared — but the `--sl-status-*` tokens are tuned for **on-canvas** use. On an inverted surface (a block whose background is the strongest neutral, e.g. an ink-on-paper output panel) they lose contrast; there, derive an on-ink status pair locally rather than using the canvas tokens (daos `.artifact .ok`/`.no` are a correct instance of this — kept as light-on-ink greens/reds, not swapped to the darker canvas tokens).
+Rule: a product picks **one** accent hue and derives hover/active/subtle from it; it never introduces a second chromatic accent. **Derivation is concrete and complete:** the generator emits **every** accent step as a hue-relative expression off `--sl-accent-default`, so a product override that sets **only the hue** re-derives the whole family (the one-var contract — no step is a bare literal that could leak the previous hue). Two forms: `color-mix()` off `--sl-accent-default` for steps a straight mix reproduces (hover everywhere, subtle everywhere, light/HC active), and CSS **relative colour** — `oklch(from var(--sl-accent-default) calc(l * k) calc(c * s) h)` — for a step whose hand-tune a mix can't reach while preserving hue (dark-active, whose value carries a slight chroma/hue shift; `color-mix` in sRGB would leave it fixed and off-hue for other products). The relative-colour step also emits a preceding baked-literal declaration as a graceful fallback for browsers below the relative-colour floor (Safari 16.4 / Chrome 119 / Firefox 128); `color-mix` itself is Baseline. This is enforced advisorily today (a judgement note); the audit gains a mechanical derivation check in a following release (see `packages/ui-kit/agent/HANDOFF.md`). Semantic status colours (ok/warn/err) are separate from the accent and shared — but the `--sl-status-*` tokens are tuned for **on-canvas** use. On an inverted surface (a block whose background is the strongest neutral, e.g. an ink-on-paper output panel) they lose contrast; there, derive an on-ink status pair locally rather than using the canvas tokens (daos `.artifact .ok`/`.no` are a correct instance of this — kept as light-on-ink greens/reds, not swapped to the darker canvas tokens).
 
 ## The family-resemblance layer
 

package/package.json

@@ -1,10 +1,12 @@
 {
   "name": "@sondalab/ui-kit",
-  "version": "0.4.0",
+  "version": "0.5.0",
   "description": "Sondalab design tokens as CSS custom properties + the agentic core: component catalog, compliance audit (sl-audit), and author/migrate/adopt workflows.",
   "license": "MIT",
   "author": "marcellobarile",
-  "publishConfig": { "access": "public" },
+  "publishConfig": {
+    "access": "public"
+  },
   "type": "module",
   "bin": {
     "sl-audit": "./agent/sl-audit.mjs"

package/themes/dark.css

@@ -18,6 +18,7 @@
   --sl-accent-default: #F5A83C;
   --sl-accent-hover: color-mix(in srgb, var(--sl-accent-default) 80%, white);
   --sl-accent-active: #E0942A;
+  --sl-accent-active: oklch(from var(--sl-accent-default) calc(l * 0.92) calc(c * 0.96) h);
   --sl-accent-subtle: color-mix(in srgb, var(--sl-accent-default) 16%, transparent);
   --sl-accent-depth: #35A0B4;
   --sl-focus-ring: #F5A83C;

package/themes/high-contrast.css

@@ -18,7 +18,7 @@
   --sl-accent-default: #ffff00;
   --sl-accent-hover: color-mix(in srgb, var(--sl-accent-default) 37%, white);
   --sl-accent-active: color-mix(in srgb, var(--sl-accent-default) 80%, black);
-  --sl-accent-subtle: #1a1a00;
+  --sl-accent-subtle: color-mix(in srgb, var(--sl-accent-default) 10%, black);
   --sl-accent-depth: #00ffff;
   --sl-focus-ring: #ffff00;
 }

package/themes/light.css

@@ -18,7 +18,7 @@
   --sl-accent-default: #B56A0C;
   --sl-accent-hover: color-mix(in srgb, var(--sl-accent-default) 89%, black);
   --sl-accent-active: color-mix(in srgb, var(--sl-accent-default) 76%, black);
-  --sl-accent-subtle: rgba(197,122,22,0.12);
+  --sl-accent-subtle: color-mix(in srgb, var(--sl-accent-default) 12%, transparent);
   --sl-accent-depth: #14606C;
   --sl-focus-ring: #B56A0C;
 }