@cube-dev/ui-kit 0.0.0-canary-324d6c4 → 0.0.0-canary-e612701

package/docs/components/other/Calendar.md

@@ -0,0 +1,187 @@
+# Calendar
+
+`Calendar` renders a month grid for picking a single date. `RangeCalendar` picks
+a contiguous range, and `PeriodCalendar` picks a whole month, quarter or year.
+All three are the panels behind the date fields — [DatePicker](../fields/DatePicker.md),
+DateRangePicker and the
+[period pickers](../fields/PeriodPicker.md) — and they are built on
+React Aria's `useCalendar` / `useRangeCalendar`.
+
+The header title is the navigation: the month and the year are buttons that open
+a month list and a year list, so reaching a date two years out takes two clicks
+instead of twenty-four.
+
+## When to Use
+
+- Embedding a calendar directly in a page or panel rather than behind a field
+- Building a custom date input that needs the same grid and states
+- Otherwise, prefer the date fields — they add the text input, label, validation
+  and popover for you
+
+## Component
+
+---
+
+### Properties
+
+#### Calendar
+
+- **`value`** `DateValue` — The selected date (controlled)
+- **`defaultValue`** `DateValue` — The initially selected date (uncontrolled)
+- **`minValue`** `DateValue` — The earliest selectable date
+- **`maxValue`** `DateValue` — The latest selectable date
+- **`isDateUnavailable`** `(date: DateValue) => boolean` — Marks individual dates as unavailable
+- **`pickerMode`** `'day' | 'week'` (default: `day`) — `week` shows a week-number column and highlights the whole week of the selected day
+- **`hasMonthYearNavigation`** `boolean` (default: `true`) — Whether the header month and year are buttons that open the month and year lists
+- **`selectedRange`** `{ start: DateValue; end: DateValue }` — Highlights a range that lives outside the calendar's own state (used by `DateRangeSeparatedPicker`)
+- **`isDisabled`** `boolean` — Disables the whole calendar
+- **`isReadOnly`** `boolean` — Allows navigation but not selection
+- **`onChange`** `(value: DateValue) => void` — Fired when a date is selected
+
+#### RangeCalendar
+
+Accepts React Aria's `AriaRangeCalendarProps` (a `{ start, end }` value) plus
+**`hasMonthYearNavigation`**.
+
+#### PeriodCalendar
+
+- **`picker`** `'month' | 'quarter' | 'year'` — Which period the panel selects
+- **`value`** `DateValue | null` — The selected period, represented by its start date
+- **`minValue`** / **`maxValue`** `DateValue | null` — Range limits; a period is disabled only when *all* of it falls outside
+- **`isDateUnavailable`** `(date: DateValue) => boolean` — Called with the period's start date
+- **`isDisabled`** `boolean`
+- **`autoFocus`** `boolean` — Moves focus into the grid on mount
+- **`onChange`** `(date: CalendarDate) => void` — Fired with the period's start date
+
+### Base Properties
+
+Supports [Base properties](../../BaseProperties.md)
+
+### Modifiers
+
+Day cells and period cells share one set of modifiers:
+
+| Modifier      | Type      | Description                                          |
+| ------------- | --------- | ---------------------------------------------------- |
+| `selected`    | `boolean` | The cell is part of the current selection            |
+| `current`     | `boolean` | The cell contains today                              |
+| `outside`     | `boolean` | The cell belongs to an adjacent month or decade      |
+| `rangeHover`  | `boolean` | The whole row is highlighted (week mode)             |
+| `pressed`     | `boolean` | The cell is being pressed                            |
+| `focused`     | `boolean` | The cell holds keyboard focus                        |
+| `disabled`    | `boolean` | The cell is outside `minValue` / `maxValue`          |
+| `unavailable` | `boolean` | `isDateUnavailable` returned `true` for the cell     |
+
+## Examples
+
+### Basic Usage
+
+```jsx
+import { parseDate } from '@internationalized/date';
+
+<Calendar
+  defaultValue={parseDate('2026-08-12')}
+  onChange={(date) => console.log(date.toString())}
+/>;
+```
+
+### Week Selection
+
+```jsx
+<Calendar pickerMode="week" defaultValue={parseDate('2026-08-12')} />
+```
+
+### Limited Range
+
+Months and years that fall entirely outside `minValue` / `maxValue` are disabled
+in the month and year lists too, and the navigation arrows stop at the edge.
+
+```jsx
+<Calendar
+  defaultValue={parseDate('2026-08-12')}
+  minValue={parseDate('2026-08-05')}
+  maxValue={parseDate('2026-09-20')}
+/>
+```
+
+### Without Month/Year Navigation
+
+```jsx
+<Calendar hasMonthYearNavigation={false} defaultValue={parseDate('2026-08-12')} />
+```
+
+### Range
+
+```jsx
+<RangeCalendar
+  defaultValue={{
+    start: parseDate('2026-08-10'),
+    end: parseDate('2026-08-19'),
+  }}
+/>
+```
+
+### Period Panels
+
+```jsx
+<PeriodCalendar
+  picker="month"
+  value={new CalendarDate(2026, 8, 1)}
+  onChange={(date) => console.log(date.toString())}
+/>
+```
+
+## Accessibility
+
+### Keyboard Navigation
+
+Day grid (provided by React Aria):
+
+- `Arrow keys` — Move between days
+- `PageUp` / `PageDown` — Previous / next month
+- `Home` / `End` — First / last day of the week
+- `Enter` / `Space` — Select the focused day
+
+Month and year lists:
+
+- `Arrow keys` — Move between periods, rolling over into the neighbouring year or decade
+- `PageUp` / `PageDown` — Previous / next year (month list) or decade (year list)
+- `Home` / `End` — First / last selectable period on the page
+- `Enter` / `Space` — Choose the period
+- `Escape` — Step back to the previous panel without closing a surrounding popover
+
+### Screen Reader Support
+
+- Each panel is a `grid`, labelled `Months` / `Quarters` / `Years`
+- The visible month and year are the calendar's `heading`, and their buttons are
+  the controls that open the lists
+- Cells expose `aria-selected`; out-of-range periods are `disabled`
+
+## Best Practices
+
+1. **Do**: bound the calendar when the domain is bounded — the month and year
+   lists disable everything out of range, which is far clearer than letting the
+   user land somewhere unselectable.
+
+   ```jsx
+   <Calendar minValue={today(getLocalTimeZone())} />
+   ```
+
+2. **Don't**: reach for `PeriodCalendar` to pick a day. Its value is always the
+   *start* of a period, never an exact date.
+
+3. **Accessibility**: always give a standalone calendar an `aria-label` — inside
+   a field the label comes from the field.
+
+## Suggested Improvements
+
+- Range calendars paint every day in the range the same way; distinct start/end
+  caps would read better for long ranges.
+- Multi-month (`visibleDuration`) layouts are not implemented; the header falls
+  back to a plain title when a range spans more than one month.
+
+## Related Components
+
+- [DatePicker](../fields/DatePicker.md) — a date field with this calendar in a popover
+- DateRangePicker — a range field built on `RangeCalendar`
+- [PeriodPicker](../fields/PeriodPicker.md) — week / month / quarter / year fields

package/docs/glaze/api.md

@@ -411,9 +411,9 @@ promotion for that color.
 
 ## Manual contrast level
 
-`contrastLevel` puts the normal end of the two-tier contrast model on a `0–100`
-slider. It is a config field, so it works globally, per theme, per token, and
-through `extend()`:
+`contrastLevel` turns contrast from a two-tier switch into a `0–100` slider.
+It is a config field, so it works globally, per theme, per token, and through
+`extend()`:
 
 ```ts
 glaze.configure({ contrastLevel: 60 });
@@ -421,17 +421,12 @@ const theme = glaze(280, 80, { contrastLevel: 60 });
 glaze.color('#26fcb2', { contrastLevel: 60 });
 ```
 
-The level moves the **normal** variants — `light` and `dark` — along that slider.
-It says nothing about high contrast: `lightContrast` / `darkContrast` stay the
-true high-contrast resolution at every level, and
-[`modes.highContrast`](#output-modes) alone decides whether they are emitted.
-
-| Value            | Meaning                                                                    |
-| ---------------- | -------------------------------------------------------------------------- |
-| `'auto'`         | Default. The normal variants take the authored normal entries as-is.        |
-| `0`              | The same thing, reached through the slider — output-identical to `'auto'`.  |
-| `100`            | The normal variants *are* the high-contrast ones, so the tier is dropped.   |
-| anything between | The normal variants are resolved *at* that level.                          |
+| Value            | Meaning                                                              |
+| ---------------- | -------------------------------------------------------------------- |
+| `'auto'`         | Default. The two-tier model: normal variants plus a high-contrast tier. |
+| `0`              | Normal contrast, with **no** high-contrast tier.                      |
+| `100`            | The high-contrast scheme as the only scheme.                          |
+| anything between | Resolved *at* that level.                                            |
 
 Levels `0` and `100` reproduce the classic `light` / `dark` and
 `lightContrast` / `darkContrast` output **bit for bit**.
@@ -451,9 +446,6 @@ The interpolated values are then fed through the ordinary resolve, so a
 contrast floor at any level is **solved**, not approximated, and `autoFlip`
 decides once per level.
 
-These feed the two **normal** passes only. The high-contrast passes bypass the
-level entirely, so the tier resolves exactly as it does in `'auto'` mode.
-
 Everything that does not vary by high contrast today — hue, saturation,
 `darkDesaturation`, `opacity`, `pastel` — is unaffected by the level.
 
@@ -503,35 +495,24 @@ directly.
 
 ### High-contrast output
 
-The level and the high-contrast tier are independent, and they compose: the
-slider raises the baseline, and a `prefers-contrast: more` block still escalates
-on top of whatever baseline the user has chosen.
-
-- `resolve()` returns four variants at every level. `lightContrast` /
-  `darkContrast` are the **true** high-contrast resolution — bit-identical to
-  what `'auto'` resolves for those slots, at any level.
-- [`modes.highContrast`](#output-modes) alone decides whether the tier is
-  emitted, exactly as in `'auto'` mode. A level does not turn it off.
+A manual level already carries the contrast preference, so there is no second
+tier to emit:
+
+- `resolve()` still returns four variants, but `lightContrast` / `darkContrast`
+  **mirror** `light` / `dark`.
+- A **global** level turns high-contrast output off outright, so
+  `tokens()` / `tasty()` / `json()` / `dtcg()` / `dtcgResolver()` / `tailwind()`
+  emit no high-contrast tier. `modes.highContrast` goes inert — it reads as
+  "emit a separate high-contrast set *when* contrast is automatic" — so leaving
+  `highContrast: true` set in a build config while a user switches their
+  preference from auto to manual is fine, and silent.
 - `css()` always returns four strings and ignores `modes`, so its
-  `lightContrast` / `darkContrast` strings now carry genuinely escalated values
-  at a mid level, where they previously repeated the normal declarations. An
-  existing `@media (prefers-contrast: more)` block starts doing real work.
+  `lightContrast` / `darkContrast` strings repeat the normal declarations —
+  an existing `@media (prefers-contrast: more)` block keeps matching the base
+  block as the level changes, with nothing to rewire.
 - A level on a **single theme or token** does not change which modes are
-  emitted — `modes` is global-only, and a palette must not have one sibling
-  collapse the shared token structure.
-
-| `contrastLevel`   | `modes.highContrast: false` (default) | `modes.highContrast: true`               |
-| ----------------- | ------------------------------------- | ---------------------------------------- |
-| `'auto'` / `0`    | `light`, `dark`                       | + `lightContrast`, `darkContrast`        |
-| `1`–`99`          | `light`, `dark` at the level          | + the tier, unchanged by the level       |
-| `100` (global)    | `light`, `dark` = the HC values       | same — the tier is dropped as a duplicate |
-
-That last row is the one exception. At level 100 the normal variants *are* the
-high-contrast ones, so a separate tier would be an exact duplicate: a global
-level of 100 emits a single light/dark set, and even an explicit
-`modes: { highContrast: true }` on the call is suppressed, because it has nothing
-different left to ask for. A level of 100 on a single theme or token still
-reports into the tier, with values equal to its own normal ones.
+  emitted. Sibling themes in a palette keep their real high-contrast tier, and
+  the manual one reports its own resolved values there.
 
 ### Driving it at runtime
 
@@ -545,9 +526,8 @@ slider.oninput = () => {
 };
 ```
 
-A manual resolve runs the same four passes as an `'auto'` one. Only level 100
-skips the two high-contrast passes, because the normal ones already produced
-those values.
+Because a manual level skips the two high-contrast passes, a manual resolve is
+also half the work of an `'auto'` one.
 
 ### Clearing it, exporting it, base links
 
@@ -560,9 +540,7 @@ those values.
   matches how `modes` and `states` are treated.
 - **Set the level globally, or on both sides of a base link.** A per-token level
   on a dependent but not on its base anchors the two at different levels — the
-  same caveat as a per-instance `lightTone` override. It is visible in the
-  high-contrast tier too, since a dependent's high-contrast variant reads its
-  base's high-contrast slots (and at level 100, the base's mirrored normal ones).
+  same caveat as a per-instance `lightTone` override.
 
 `resolveContrastForLevel(spec, level, polarity?)` is exported for advanced use;
 see [Contrast solver](#contrast-solver).
@@ -581,9 +559,8 @@ type ColorDef = RegularColorDef | ShadowColorDef | MixColorDef;
 
 | Field        | Type                            | Description                                                                                                                                                                                                                                                                        |
 | ------------ | ------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `from`       | `GlazeColorValue`               | Seed this color from a literal value (hex, `rgb()`, `hsl()`, `okhsl()`, `okhst()`, `oklch()`, or a value object). Supplies `hue`, `tone`, and an **absolute** saturation — the one way a theme color escapes the seed ceiling. Light/normal-contrast reproduces it exactly. See [`from`](#from-a-literal-color).             |
-| `tone`       | `HCPair<ToneValue>`             | Number = absolute (0–100). `'+N'`/`'-N'` = a signed **tone delta** from the base (requires `base`). `'max'`/`'min'` = forced to the scheme's tone extreme (no `base`). Optional HC pair `[normal, hc]`. Defaults to the tone of `from`.                                             |
-| `saturation` | `number`                        | Saturation factor applied to the seed saturation (0–1). Default: `1`. With `from`, setting it overrides the color's absolute saturation and reverts to a factor of the seed.                                                                                                       |
+| `tone`       | `HCPair<ToneValue>`             | Number = absolute (0–100). `'+N'`/`'-N'` = a signed **tone delta** from the base (requires `base`). `'max'`/`'min'` = forced to the scheme's tone extreme (no `base`). Optional HC pair `[normal, hc]`.                                                                            |
+| `saturation` | `number`                        | Saturation factor applied to the seed saturation (0–1). Default: `1`.                                                                                                                                                                                                              |
 | `hue`        | `number \| RelativeValue`       | Number = absolute (0–360). String (`'+N'`/`'-N'`) = relative to the **theme seed hue** (never to a base color).                                                                                                                                                                    |
 | `darkHue`    | `number \| RelativeValue`       | Dark-scheme hue. Number = absolute (0–360). String = relative to the **theme dark seed hue**. Falls back to `hue`. See [Dark seed](#dark-seed-darkhue--darksaturation).                                                                                                            |
 | `darkSaturation` | `number`                    | Dark-scheme saturation factor (0–1) over the dark seed saturation. Falls back to `saturation`. When set, the global `darkDesaturation` reduction is **not** applied on top.                                                                                                        |
@@ -596,61 +573,6 @@ type ColorDef = RegularColorDef | ShadowColorDef | MixColorDef;
 | `role`       | `RoleInput`                     | Semantic role against `base` (`'text'` / `'surface'` / `'border'` or an alias). Fixes APCA contrast polarity. Resolved via: explicit `role` → name inference → opposite of the base's role → `'text'`. See [Roles](#roles).                                                        |
 | `inherit`    | `boolean`                       | Whether this color is inherited by child themes via `extend()`. Default: `true`. Set to `false` to make the color local to the current theme.                                                                                                                                      |
 
-#### `from` (a literal color)
-
-Most of Glaze answers the question "design me a palette". `from` answers the
-other one: **"honor this color."** White-label products, multi-tenant branding
-and imported design tokens all arrive with a value already chosen, and it is a
-contract rather than a starting point.
-
-```ts
-const theme = glaze(280, 80);
-
-theme.colors({
-  surface: { tone: 100, saturation: 0.12 },
-  brand: { from: '#2f5bff', base: 'surface', contrast: 3 },
-});
-```
-
-It accepts the same values as [`glaze.color()`](#input-forms) and supplies three
-things at once: `hue`, `tone`, and — uniquely among theme colors — an
-**absolute saturation**.
-
-That last one is the point. Every other color's `saturation` is a 0–1 factor of
-the theme seed, so the seed is a ceiling: without `from`, the only way to place
-a color more saturated than its theme is to re-seed the whole theme, dragging
-every sibling along. A `from` color carries its own chroma and is unaffected by
-the seed:
-
-```ts
-// Identical output at every seed saturation — the color is the color.
-for (const seed of [5, 50, 100]) {
-  glaze(280, seed).colors({ brand: { from: '#2f5bff' } }); // → #2f5bff
-}
-```
-
-**What "exactly" covers.** The **light, normal-contrast** variant reproduces the
-value (a local `lightTone: false`, the same default the value-shorthand form of
-`glaze.color()` applies). Dark and high contrast adapt as usual. That asymmetry
-is deliberate: those are the variants a reader reaches for when the normal one
-does not work for them, so readability outranks fidelity there — and a color
-pinned across all four would just be a worse `mode: 'static'`.
-
-A `contrast` floor still applies in every scheme and is still a floor, not a
-target: a value that already clears it is emitted untouched, and one that misses
-moves only as far as the floor. Because the floor is solved per scheme, which
-scheme comes out exact depends on the color — a light brand cannot clear 3:1 on
-a white page but clears it easily on a dark one.
-
-Sibling fields win over what the value supplied, so `{ from: '#2f5bff', hue: 300 }`
-keeps the saturation and tone and rotates the hue. Note that a `saturation`
-written alongside `from` reverts to its usual meaning — a factor of the seed,
-not of the color.
-
-A `from` color needs no `base` and no `tone`: it is placed absolutely, so it
-stands as a root on its own. Add `base` + `contrast` when it has to stay legible
-against something.
-
 #### Tone values
 
 `tone` (0–100) replaces authored OKHSL lightness with a contrast-shaped axis.
@@ -677,7 +599,7 @@ delta is kept and clamped on the authored side.
 
 **Extreme tone** (`'max'` / `'min'`) forces the color to the scheme's tone extreme without a contrast hack or a magic number. `'max'` resolves to author tone 100 and `'min'` to 0. Without a `base`, both flow through scheme mapping like an absolute tone, so under `mode: 'auto'` they invert in dark (`'max'` is lightest in light, darkest in dark). Use `mode: 'static'` to pin the same extreme across schemes, or `mode: 'fixed'` to keep the same end without inverting. No `base` required.
 
-**Extreme tone with a `base`** keeps the pair's contrast across schemes. The tone windows are asymmetric by default (`lightTone: [10, 100]`, `darkTone: [15, 95]`), so re-mapping the extreme through the dark window would squeeze the base-to-extreme span and cost contrast. Instead Glaze measures the tone shift the light scheme applied between the base and the extreme, then replays it against the base's resolved dark tone — mirrored under `mode: 'auto'` (both ends invert), same-signed under `'fixed'`. The result is clamped to `[0, 100]` only, so it may cross the `darkTone` window edge; that is intentional, since the author asked for the extreme. When the shift does not fit above or below the dark base, the color pins at tone 100 / 0. `mode: 'static'` is unaffected. High-contrast variants follow the same rule, but since their window is already the full range the replay reproduces the plain mapping unless the base itself sits asymmetrically across schemes.
+**Extreme tone with a `base`** keeps the pair's contrast across schemes. The tone windows are asymmetric by default (`lightTone: [10, 100]`, `darkTone: [15, 95]`), so re-mapping the extreme through the dark window would squeeze the base-to-extreme span and cost contrast. Instead Glaze measures the tone shift the light scheme applied between the base and the extreme, then replays it against the base's resolved dark tone — mirrored under `mode: 'auto'` (both ends invert), same-signed under `'fixed'`. The result is clamped to `[0, 100]` only, so it may cross the `darkTone` window edge; that is intentional, since the author asked for the extreme. When the shift does not fit above or below the dark base, the color pins at tone 100 / 0. `mode: 'static'` is unaffected, and high-contrast variants already use the full range.
 
 ```ts
 theme.colors({
@@ -1789,11 +1711,11 @@ boundaries, not the tone transfer.
 | `states.dark`         | `'@media(prefers-color-scheme: dark)'` | State alias for dark mode tokens ([Tasty](https://tasty.style) export). Defaults to a media query so tokens react to the OS preference without registering custom states.                                                                                                                                                                                                                                                                        |
 | `states.highContrast` | `'@media(prefers-contrast: more)'`     | State alias for HC tokens ([Tasty](https://tasty.style) export).                                                                                                                                                                                                                                                                                                                                                                                 |
 | `modes.dark`          | `true`                                 | Include dark variants in exports.                                                                                                                                                                                                                                                                                                                                                                                         |
-| `modes.highContrast`  | `false`                                | Include HC variants. Independent of [`contrastLevel`](#manual-contrast-level) — the level positions the normal variants while these stay the true HC resolution. A global level of `100` is the exception: the tier would duplicate the normal set, so it is dropped.                                                                                                                                                                                                                                                                                   |
+| `modes.highContrast`  | `false`                                | Include HC variants. Inert while a global [`contrastLevel`](#manual-contrast-level) is set — a manual level has no separate HC tier, so this reads as "emit HC variants when contrast is automatic".                                                                                                                                                                                                                                                                                   |
 | `shadowTuning`        | `undefined`                            | Default tuning for all shadow colors. Per-color tuning merges field-by-field.                                                                                                                                                                                                                                                                                                                                             |
 | `autoFlip`            | `true`                                 | Default for each color's `autoFlip`. When solving `contrast` (or applying a relative `tone` that overshoots `[0, 100]`), allow crossing to the opposite side instead of clamping. With `false`, only the requested direction is considered; unmet contrasts pin the tone to that direction's extreme (and emit a warning) and overshooting offsets clamp to the boundary. Override per color via [`autoFlip`](#autoflip). |
 | `inferRole`           | `true`                                 | Infer each color's [`role`](#roles) from its name when no explicit `role` is set. Set to `false` to opt out of name-based inference (the base-opposite and foreground-default fallbacks still apply).                                                                                                                                                                                                                     |
-| `contrastLevel`       | `'auto'`                               | Manual contrast level, `0`–`100`, putting the **normal** variants on a slider between themselves and the high-contrast ones. `0` reproduces the normal output and `100` the high-contrast output, bit for bit. The HC tier is unaffected. See [Manual contrast level](#manual-contrast-level).                                                                                                                                                                                          |
+| `contrastLevel`       | `'auto'`                               | Manual contrast level, `0`–`100`, replacing the two-tier high-contrast model with a slider. `0` reproduces the normal output and `100` the high-contrast output, bit for bit. See [Manual contrast level](#manual-contrast-level).                                                                                                                                                                                          |
 
 | Method                    | Description                                                                         |
 | ------------------------- | ----------------------------------------------------------------------------------- |
@@ -1801,7 +1723,7 @@ boundaries, not the tone transfer.
 | `glaze.getConfig()`       | Snapshot the current resolved config (shallow copy).                                |
 | `glaze.resetConfig()`     | Reset to defaults (also bumps the version counter).                                 |
 
-Themes and standalone color tokens keep a sparse local `GlazeConfigOverride` and merge the live global at resolve time for omitted fields. Authoring `.export(override?)` freezes the effective merge at call time; restored instances pin that freeze. `pastel` is instance-only (theme/token override or per-color) — not set via `configure()`. `contrastLevel` is the one field the freeze treats as a live preference: only an instance-authored level is written to the snapshot ([why](#clearing-it-exporting-it-base-links)).
+Themes and standalone color tokens keep a sparse local `GlazeConfigOverride` and merge the live global at resolve time for omitted fields. Authoring `.export(override?)` freezes the effective merge at call time; restored instances pin that freeze. `pastel` is instance-only (theme/token override or per-color) — not set via `configure()`. `contrastLevel` is the one field the freeze treats as a live preference: only an instance-authored level is written to the snapshot ([why](#two-rules-worth-knowing)).
 
 ---
 
@@ -1823,10 +1745,9 @@ palette.tokens({ modes: { dark: true, highContrast: true } });
 
 Resolution priority (highest first):
 
-1. A global [`contrastLevel`](#manual-contrast-level) of `100` — pins
-   `highContrast: false`, since the normal variants already *are* the
-   high-contrast ones and the tier would duplicate them. Any other level leaves
-   `highContrast` alone.
+1. A global [`contrastLevel`](#manual-contrast-level) — pins
+   `highContrast: false`, since a manual level leaves no separate high-contrast
+   tier to emit. `highContrast` is inert while it is set.
 2. Per-call `modes` option on `tokens` / `tasty` / `json`.
 3. `glaze.configure({ modes })` — global config.
 4. Built-in default: `{ dark: true, highContrast: false }`.
@@ -1987,6 +1908,6 @@ Exported constants: `APCA_PRESETS`, `APCA_HC_ENHANCEMENT` (`15`, the Enhanced Le
 | `maxIterations`    | `18`                 | Max binary-search iterations per branch.                                                                                                                                                               |
 | `initialDirection` | higher-contrast side | Direction to search first (`'lighter'` or `'darker'`).                                                                                                                                                 |
 | `flip`             | `false`              | When `true`, try the opposite direction if the initial one doesn't meet the target. When `false`, only the initial direction is searched — unmet contrasts pin the result to that direction's extreme. |
-| `preferInitial`    | `false`              | With `flip` on and **both** directions meeting the target, keep `initialDirection` instead of taking whichever result lands nearer `preferredTone`. Makes the chosen side independent of the target — what [`contrastLevel`](#manual-contrast-level) uses to keep a color on one side of its base across the ramp (on the normal passes only; the high-contrast ones never probe). The flip fallback is unaffected. |
+| `preferInitial`    | `false`              | With `flip` on and **both** directions meeting the target, keep `initialDirection` instead of taking whichever result lands nearer `preferredTone`. Makes the chosen side independent of the target — what [`contrastLevel`](#manual-contrast-level) uses to keep a color on one side of its base across the ramp. The flip fallback is unaffected. |
 
 Result: `{ tone, contrast, met, branch: 'lighter' | 'darker' | 'preferred', flipped? }`. `flipped: true` indicates the initial direction failed and the opposite direction satisfied the target.

package/docs/glaze/methodology.md

@@ -642,26 +642,24 @@ In HC variants, Glaze bypasses the normal tone window and uses the full
 `[0, 100]` range. Edge tones can reach the edge; contrast floors have more room
 to solve.
 
-### A slider through the tier
+### A slider instead of a tier
 
 The two-tier model assumes contrast is a binary OS preference. When contrast is
 instead a setting *your users* control, set
-[`contrastLevel`](api.md#manual-contrast-level) to a number and your **normal**
-palette slides along a `0–100` ramp: level `0` is the palette you authored, `100`
-is the HC palette you authored, and everything between is resolved at that level.
+[`contrastLevel`](api.md#manual-contrast-level) to a number and the HC tier
+becomes a `0–100` ramp: level `0` is your normal palette, `100` is the HC
+palette you already authored, and everything between is resolved at that level.
 
 The authoring work is the same — the HC pairs above are what the slider ramps
-toward, so a palette tuned for high contrast needs no new fields. Two things
-worth planning for:
-
-- The slider and the tier compose. The HC tier keeps resolving at full contrast
-  regardless of the level, so wire the level into your build or runtime *and*
-  keep your `prefers-contrast: more` block: a user who has raised the slider and
-  asked their OS for more contrast still gets the escalation on top. The one
-  exception is level `100`, where the two coincide and the tier is dropped as a
-  duplicate.
-- `contrastLevel: 0` is the natural rest position for a slider you ship but
-  default off — it reproduces the `'auto'` output bit for bit.
+toward, so a palette tuned for high contrast needs no new fields. Two
+consequences worth planning for:
+
+- The separate HC tier stops being emitted, so wire the level itself into your
+  build or runtime rather than a `prefers-contrast: more` block. Existing
+  media-query wiring keeps working; it just receives the same values as the base
+  block.
+- `contrastLevel: 0` is a useful state in its own right: normal contrast with no
+  HC tier at all, for products that ship the slider but default it off.
 
 ## Checklist
 

package/docs/glaze/okhst.md

@@ -98,10 +98,6 @@ hi(f) = hi + (100 - hi) * f
 `[15, 95] → [0, 100]`. The render `eps` is not interpolated, and a `false` window
 is already the full range and therefore level-invariant.
 
-This continuous form applies to the normal variants only. High-contrast variants
-are already at the full range, so the level does not widen them further — the
-bypass above is what makes the high-contrast tier level-independent.
-
 ## Scheme adaptation
 
 Each regular color has an adaptation `mode`:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cube-dev/ui-kit",
-  "version": "0.0.0-canary-324d6c4",
+  "version": "0.0.0-canary-e612701",
   "type": "module",
   "description": "UIKit for Cube Projects",
   "repository": {
@@ -90,7 +90,7 @@
     "@react-types/shared": "^3.32.1",
     "@tabler/icons-react": "^3.31.0",
     "@tanstack/react-virtual": "^3.13.12",
-    "@tenphi/glaze": "1.5.0",
+    "@tenphi/glaze": "1.3.0",
     "@tenphi/tasty": "^3.0.0",
     "clipboard-copy": "^4.0.1",
     "clsx": "^1.1.1",

package/dist/components/fields/ColorSwatch/ColorSwatch.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"ColorSwatch.js","names":[],"sources":["../../../../src/components/fields/ColorSwatch/ColorSwatch.tsx"],"sourcesContent":["import {\n  BASE_STYLES,\n  BaseProps,\n  BaseStyleProps,\n  BLOCK_STYLES,\n  BlockStyleProps,\n  DIMENSION_STYLES,\n  DimensionStyleProps,\n  OUTER_STYLES,\n  OuterStyleProps,\n  Styles,\n  tasty,\n} from '@tenphi/tasty';\nimport { ForwardedRef, forwardRef } from 'react';\n\nimport { extractStyles } from '../../../utils/styles';\nimport { ColorValue, parseColor, toHex } from '../color/color';\n\nconst STYLE_PROPS = [\n  ...BASE_STYLES,\n  ...OUTER_STYLES,\n  ...BLOCK_STYLES,\n  ...DIMENSION_STYLES,\n];\n\nconst SwatchElement = tasty({\n  qa: 'ColorSwatch',\n  styles: {\n    display: 'block',\n\n    /**\n     * The control the swatch sits in, when there is one.\n     *\n     * `Item`, `Button` and `TextInputBase` all publish their own height as\n     * `$size`, and a custom property reaches any descendant — so a swatch in an\n     * icon, prefix or suffix slot reads the host's height without either side\n     * knowing about the other. `$swatch-host` is the fallback chain: an explicit\n     * `size` pins it, and outside a control the medium default stands in.\n     *\n     * The named sizes are stated as the *host* they would fit, not as the swatch\n     * itself, so the `- 1x` below is the single place the inset is expressed.\n     */\n    '$swatch-host': {\n      // `var(--size, 4x)` — a host wins, and 32px is a medium control.\n      '': '($size, 4x)',\n      // An explicit size ignores the host: these are 28/32/36, one `1x` above\n      // the 20/24/28 the swatch ends up at.\n      'size=small': '3.5x',\n      'size=medium': '4x',\n      'size=large': '4.5x',\n    },\n    '$swatch-size': '($swatch-host - 1x)',\n\n    width: '$swatch-size $swatch-size',\n    height: '$swatch-size $swatch-size',\n    radius: '1r',\n    fill: {\n      '': '(#color-picker, #clear)',\n      empty: '#clear',\n    },\n    shadow: 'inset 0 0 0 1bw #dark.15',\n    // A single diagonal stroke is the conventional \"no color\" swatch.\n    image: {\n      '': false,\n      empty:\n        'linear-gradient(to bottom right, #clear 46%, #danger 46%, #danger 54%, #clear 54%)',\n    },\n  },\n});\n\nexport interface CubeColorSwatchProps\n  extends BaseProps,\n    BaseStyleProps,\n    OuterStyleProps,\n    BlockStyleProps,\n    DimensionStyleProps {\n  /** The color to show. Anything the color inputs accept; `null` shows the empty state. */\n  color?: string | ColorValue | null;\n  /**\n   * The edge of the swatch: 20px, 24px or 28px. Left unset, the swatch tracks\n   * the control around it — `1x` inside its height — and falls back to `medium`\n   * where there is no control.\n   */\n  size?: 'small' | 'medium' | 'large' | (string & {});\n  styles?: Styles;\n}\n\n/**\n * A square of color. Decorative on its own — pair it with the value as text, or\n * with a control that names it.\n *\n * The color travels as an inline custom property rather than through `styles`,\n * so the swatch keeps a single cached style rule however often it changes.\n */\nexport const ColorSwatch = forwardRef(function ColorSwatch(\n  props: CubeColorSwatchProps,\n  ref: ForwardedRef<HTMLDivElement>,\n) {\n  const { color, mods, qa, size } = props;\n  const styles = extractStyles(props, STYLE_PROPS);\n\n  const resolved =\n    typeof color === 'string' ? parseColor(color) : color ?? null;\n\n  return (\n    <SwatchElement\n      ref={ref}\n      qa={qa}\n      data-size={size}\n      mods={{ empty: !resolved, ...mods }}\n      styles={styles}\n      style={resolved ? { '--color-picker-color': toHex(resolved) } : undefined}\n    />\n  );\n});\n"],"mappings":";;;;;;;;AAkBA,MAAM,cAAc;CAClB,GAAG;CACH,GAAG;CACH,GAAG;CACH,GAAG;CACJ;AAED,MAAM,gBAAgB,MAAM;CAC1B,IAAI;CACJ,QAAQ;EACN,SAAS;EAcT,gBAAgB;GAEd,IAAI;GAGJ,cAAc;GACd,eAAe;GACf,cAAc;GACf;EACD,gBAAgB;EAEhB,OAAO;EACP,QAAQ;EACR,QAAQ;EACR,MAAM;GACJ,IAAI;GACJ,OAAO;GACR;EACD,QAAQ;EAER,OAAO;GACL,IAAI;GACJ,OACE;GACH;EACF;CACF,CAAC;;;;;;;;AA0BF,MAAa,cAAc,WAAW,SAAS,YAC7C,OACA,KACA;CACA,MAAM,EAAE,OAAO,MAAM,IAAI,SAAS;CAClC,MAAM,SAAS,cAAc,OAAO,YAAY;CAEhD,MAAM,WACJ,OAAO,UAAU,WAAW,WAAW,MAAM,GAAG,SAAS;AAE3D,QACE,oBAAC;EACM;EACD;EACJ,aAAW;EACX,MAAM;GAAE,OAAO,CAAC;GAAU,GAAG;GAAM;EAC3B;EACR,OAAO,WAAW,EAAE,wBAAwB,MAAM,SAAS,EAAE,GAAG;GAChE;EAEJ"}

package/dist/components/fields/ColorSwatch/index.d.ts

@@ -1,2 +0,0 @@
-
-import { ColorSwatch, CubeColorSwatchProps } from "./ColorSwatch.js";

package/dist/tokens/color-seed.d.ts

@@ -1,44 +0,0 @@
-
-//#region src/tokens/color-seed.d.ts
-/**
- * Turns a colour into the three numbers the palette is seeded from.
- *
- * A deliberate LEAF: it imports Glaze and nothing else. `./palette-config` reads it
- * from inside `resolveConfig`, and `./palette-config` is the one module the token
- * graph is not allowed to have a cycle through — so anything this file imported
- * would become a `palette-config` dependency too. Glaze has no edge back into the
- * token modules, so it is safe; `./palette` (which owns `TINT_RECIPE` and the global
- * `glaze.configure`) is not.
- *
- * There is no ordering hazard either, even though `./palette` runs
- * `glaze.configure()` at module scope and this file may be called before that
- * happens. A bare-string colour token defaults to `lightTone: false`, so its light
- * variant preserves the input tone exactly and its hue and saturation come straight
- * off the parse — all three readings are independent of the global config.
- */
-/** Hue, saturation and tone read off a colour, on the palette's own scales. */
-interface ColorSeed {
-  /** 0–360. */
-  hue: number;
-  /** 0–100 — the palette's seed scale, not Glaze's 0–1 factor. */
-  saturation: number;
-  /** 0–100 on the OKHST tone axis. */
-  tone: number;
-}
-/**
- * Read a colour's hue, saturation and tone.
- *
- * Accepts anything Glaze parses — hex, `rgb()`, `hsl()`, `okhsl()`, `okhst()`,
- * `oklch()`. CSS colour keywords (`rebeccapurple`) are **not** supported.
- *
- * Returns `null` on anything unparseable, having warned once, so a caller can fall
- * back to its numeric seed instead of throwing on a typo in a settings field.
- *
- * ```ts
- * colorSeed('#0ea5e9'); // → { hue: 237.32, saturation: 98.19, tone: 65.78 }
- * ```
- */
-declare function colorSeed(value: string): ColorSeed | null;
-//#endregion
-export { ColorSeed, colorSeed };
-//# sourceMappingURL=color-seed.d.ts.map

package/dist/tokens/color-seed.js

@@ -1,48 +0,0 @@
-/** @license MIT | @cube-dev/ui-kit v0.0.0-canary-324d6c4 | Cube Dev Team */
-import { glaze } from "@tenphi/glaze";
-
-//#region src/tokens/color-seed.ts
-/**
-* A colour picker being dragged emits a distinct string per frame, and
-* `resolveConfig` runs on every `setPaletteConfig` *and* every
-* `resolvePaletteConfig` preview. One resolve is only ~3µs, so this is insurance
-* against a drag rather than a hot path — hence a cap and a clear rather than an
-* LRU.
-*/
-const CACHE_LIMIT = 256;
-const cache = /* @__PURE__ */ new Map();
-/**
-* Read a colour's hue, saturation and tone.
-*
-* Accepts anything Glaze parses — hex, `rgb()`, `hsl()`, `okhsl()`, `okhst()`,
-* `oklch()`. CSS colour keywords (`rebeccapurple`) are **not** supported.
-*
-* Returns `null` on anything unparseable, having warned once, so a caller can fall
-* back to its numeric seed instead of throwing on a typo in a settings field.
-*
-* ```ts
-* colorSeed('#0ea5e9'); // → { hue: 237.32, saturation: 98.19, tone: 65.78 }
-* ```
-*/
-function colorSeed(value) {
-	const cached = cache.get(value);
-	if (cached !== void 0) return cached;
-	let seed = null;
-	try {
-		const { h, s, t } = glaze.color(value).resolve().light;
-		seed = {
-			hue: h,
-			saturation: s * 100,
-			tone: t * 100
-		};
-	} catch {
-		console.warn(`[cube-ui-kit] could not parse palette colour ${JSON.stringify(value)}; keeping the numeric seed. Accepted: hex, rgb(), hsl(), okhsl(), okhst(), oklch() — CSS colour keywords are not supported.`);
-	}
-	if (cache.size >= CACHE_LIMIT) cache.clear();
-	cache.set(value, seed);
-	return seed;
-}
-
-//#endregion
-export { colorSeed };
-//# sourceMappingURL=color-seed.js.map