@cube-dev/ui-kit 0.0.0-canary-bafd63a → 0.0.0-canary-c3b7b41

package/docs/Introduction.md

@@ -17,7 +17,7 @@ Cube UI Kit is built on two independent open-source projects:
 - [Tasty](https://tasty.style) is the declarative styling engine. It turns token-aware style objects, responsive values, and component states into conflict-free CSS.
 - [Glaze](https://github.com/tenphi/glaze) generates the semantic color palette. A small set of brand and status seeds resolves into light, dark, and high-contrast token sets.
 
-Use the [Theme Builder](/story/getting-started-theming--theme-builder) to tune a palette and preview the result across schemes and contrast levels.
+Use the [Theme Builder](/story/getting-started-theming--theme-builder) to tune a palette and preview the result across schemas and contrast levels.
 
 ## Get started
 

package/docs/Theming.md

@@ -1,6 +1,6 @@
 # Theming
 
-The whole palette is generated by [Glaze](https://github.com/tenphi/glaze) from a handful of seeds, one per **zone**: the accent, the base, and each of the four status themes. Those seeds are tunable at runtime — change one and every token re-resolves, in light, dark, and high-contrast schemes at once.
+The whole palette is generated by [Glaze](https://github.com/tenphi/glaze) from a handful of seeds, one per **zone**: the accent, the base, and each of the four status themes. Those seeds are tunable at runtime — change one and every token re-resolves, in light, dark, and high-contrast schemas at once.
 
 Every zone takes the same seed, and it comes in two forms: a **color**, which is usually what you actually have, or the **numbers** behind one. Never both — a zone is seeded one way or the other. See [One seed, two ways to spell it](#one-seed-two-ways-to-spell-it).
 
@@ -133,7 +133,7 @@ First, **exactness is scoped to the light, normal-contrast variant.** That is th
 
 Sizing those two the same is a mistake worth naming, because this palette made it. In light `surface` **is** white, so one measurement is both constraints at once and Lc 45 looks right for the pair. In dark the page is near-black and the same number becomes a demand that a filled shape reach text contrast against it — which nothing in the palette meets, the shipped fill included. Since a floor can only lighten, the surplus flattened the dark half of the tone axis onto a single value: every brand darker than the floor came out the same colour. The page floor is now sized for a shape and the label is guaranteed separately, by a cap on the seed's tone.
 
-They are APCA rather than WCAG on purpose. A single WCAG ratio means two different things depending on the scheme: measured across twelve hues, a fill sitting exactly at 3:1 comes out at Lc 56 in light but only Lc 23 in dark. That is why light brands kept getting crushed while dark ones sailed through the same rule. **A consequence to state plainly: the emitted fill can sit below WCAG 3:1.** `#0EA5E9` renders at 2.77:1 against a white page and is correct there — the Lc is the guarantee, not the ratio.
+They are APCA rather than WCAG on purpose. A single WCAG ratio means two different things depending on the schema: measured across twelve hues, a fill sitting exactly at 3:1 comes out at Lc 56 in light but only Lc 23 in dark. That is why light brands kept getting crushed while dark ones sailed through the same rule. **A consequence to state plainly: the emitted fill can sit below WCAG 3:1.** `#0EA5E9` renders at 2.77:1 against a white page and is correct there — the Lc is the guarantee, not the ratio.
 
 High contrast does **not** escalate the page floor. It is a request for separation over brand, but not for separation from the page: the same fill carries the label, and driving it off the page drives the label off it. The shipped ladder makes the same trade and lands the other side of it, ending up with _less_ page separation in high contrast than in normal, because it darkens the fill toward its label. What does escalate is the label cap, which searches the high-contrast variants too.
 
@@ -173,7 +173,7 @@ setPaletteConfig({ surfaceMode: 'tinted', base: { saturation: 25 } });
 
 Two tones is not a lightness change you would name — it is _room_. Everything below `surface` is positioned relative to it, so the ladder, the borders and the text ramp all follow, and the text's `['AA','AAA']` floors re-solve against the new background rather than drifting. The `code-*` family follows too: its mirrored `surface` exists to be the page, so it tracks both the tone and the base seed.
 
-**The tinted surfaces move with it.** A status theme's `surface` — and a runtime tint's, from `getColorTheme()` — is authored as an offset from the page's rather than as an absolute tone, and that offset is exactly the two tones `tinted` shifts by. Anchored absolutely they would land on the page's own new tone and a `note` banner would stop reading as a banner at all; anchored to the page they keep the separation the offset was chosen for, in both schemes. They also pick up a little more chroma there, being further from the extreme — so `tinted` makes a status surface easier to see, not harder.
+**The tinted surfaces move with it.** A status theme's `surface` — and a runtime tint's, from `getColorTheme()` — is authored as an offset from the page's rather than as an absolute tone, and that offset is exactly the two tones `tinted` shifts by. Anchored absolutely they would land on the page's own new tone and a `note` banner would stop reading as a banner at all; anchored to the page they keep the separation the offset was chosen for, in both schemas. They also pick up a little more chroma there, being further from the extreme — so `tinted` makes a status surface easier to see, not harder.
 
 The tint stays subtle by construction. Near white the sRGB gamut has very little chroma to give, so `tinted` buys a surface that reads as warm or cool rather than one that reads as colored — which is the whole ask. For a genuinely colored panel, reach for a status theme's `surface` instead.
 
@@ -331,7 +331,7 @@ The preview deliberately shows all three surface levels with their own text ramp
 
 ## Previewing a theme in a region
 
-`setPaletteConfig()` re-themes the whole document, which is no use for a theme picker — you want several themes visible at once, or a dark preview inside a light page. `renderColorTokens()` does that: it resolves the palette for **one** config and **one** scheme and returns flat literal values, ready to apply to a subtree through a tasty `tokens` prop.
+`setPaletteConfig()` re-themes the whole document, which is no use for a theme picker — you want several themes visible at once, or a dark preview inside a light page. `renderColorTokens()` does that: it resolves the palette for **one** config and **one** schema and returns flat literal values, ready to apply to a subtree through a tasty `tokens` prop.
 
 ```tsx
 import { renderColorTokens, tasty } from '@cube-dev/ui-kit';
@@ -339,20 +339,20 @@ import { renderColorTokens, tasty } from '@cube-dev/ui-kit';
 const Region = tasty({ styles: { fill: '#surface', color: '#surface-text' } });
 
 const preview = useMemo(
-  () => renderColorTokens({ accent: { hue: 210 }, scheme: 'dark' }),
+  () => renderColorTokens({ accent: { hue: 210 }, schema: 'dark' }),
   [],
 );
 
 <Region tokens={preview}>…everything in here renders in that theme…</Region>;
 ```
 
-The reason this needs its own API: the document palette emits **state maps** (`{ '': …, '@dark': …, '@hc': … }`), so a page can only ever show one scheme at a time — that is what `@dark` means. Collapsing the palette to a chosen scheme removes the conditionality, so several themes can coexist.
+The reason this needs its own API: the document palette emits **state maps** (`{ '': …, '@dark': …, '@hc': … }`), so a page can only ever show one schema at a time — that is what `@dark` means. Collapsing the palette to a chosen schema removes the conditionality, so several themes can coexist.
 
 | Option | Meaning |
 | --- | --- |
-| every `PaletteConfig` field | merged over the **current** config, so `{ scheme: 'dark' }` previews the active theme in dark |
-| `scheme` | `'light'` (default) or `'dark'` |
-| `highContrast` | resolve that scheme's high-contrast variant. Default `false` |
+| every `PaletteConfig` field | merged over the **current** config, so `{ schema: 'dark' }` previews the active theme in dark |
+| `schema` | `'light'` (default) or `'dark'` |
+| `highContrast` | resolve that schema's high-contrast variant. Default `false` |
 
 Nothing is applied globally — the live palette and the stored config are untouched, so previews are safe to render anywhere.
 
@@ -360,10 +360,10 @@ Note the one place the merge/replace split matters: this call **layers** over th
 
 Notes:
 
-- Real components work inside a region. Every color in the kit compiles to a CSS custom property, so overriding those properties on one element re-colors its whole subtree with no scheme attribute and no second `<Root>`.
+- Real components work inside a region. Every color in the kit compiles to a CSS custom property, so overriding those properties on one element re-colors its whole subtree with no schema attribute and no second `<Root>`.
 - The legacy aliases come along **by reference** (`'#dark': '#surface-text'`), and so do the shadow tokens and scrollbar colors, whose values embed a palette color. Tasty re-declares them on the region so each `var()` resolves against the region's own values; resolving them up front would freeze them to the outer theme instead.
 - Typography, spacing, sizes and layout are **not** included — nothing in their values references a color, so the region inherits them from `<Root>`.
-- `contrastLevel` works per region, so the whole 0–100 ramp can be shown at once — something a document cannot do, since it is only ever at one level. Level `0` reproduces the normal tier and `100` the high-contrast tier exactly, in both schemes. `highContrast: true` still returns the genuine high-contrast resolution at any level below `100`, because the level moves the baseline and the tier escalates from where `'auto'` would put it; at `100` the two coincide and it returns the same colors as the normal variant. Note that tokens carrying a contrast _floor_ (most text) can sit still over part of the ramp — the floor is solved, not approximated, so the value only moves once the interpolated target does. Tokens positioned by a plain tone pair, like `#border`, step at every level.
+- `contrastLevel` works per region, so the whole 0–100 ramp can be shown at once — something a document cannot do, since it is only ever at one level. Level `0` reproduces the normal tier and `100` the high-contrast tier exactly, in both schemas. `highContrast: true` still returns the genuine high-contrast resolution at any level below `100`, because the level moves the baseline and the tier escalates from where `'auto'` would put it; at `100` the two coincide and it returns the same colors as the normal variant. Note that tokens carrying a contrast _floor_ (most text) can sit still over part of the ramp — the floor is solved, not approximated, so the value only moves once the interpolated target does. Tokens positioned by a plain tone pair, like `#border`, step at every level.
 - Resolving a palette costs a few milliseconds. The last config is memoized, but `useMemo` on the caller side if you drive it from state.
 
 `renderPaletteTokens()` is the same thing without the aliases and companion tokens, if you want only the Glaze palette.
@@ -397,10 +397,7 @@ subscribePaletteConfig(() => {
 
 ## Reading the ambient schema
 
-The palette config is what the app *asked for*; the schema and contrast tier are
-what the viewer is *seeing* — `<html data-schema>` / `prefers-color-scheme`, and
-`<html data-contrast>` / `prefers-contrast`. They are not part of the config,
-so `getPaletteConfig()` says nothing about them:
+The palette config is what the app _asked for_; the schema and contrast tier are what the viewer is _seeing_ — `<html data-schema>` / `prefers-color-scheme`, and `<html data-contrast>` / `prefers-contrast`. They are not part of the config, so `getPaletteConfig()` says nothing about them:
 
 ```tsx
 import { useHighContrast, useSchema } from '@cube-dev/ui-kit';
@@ -409,23 +406,11 @@ const schema = useSchema(); // 'light' | 'dark'
 const isHighContrast = useHighContrast(); // boolean
 ```
 
-Both resolve exactly as the `@dark` / `@hc` states do — attribute opt-in first,
-media query only when the attribute is absent — and re-render when either input
-changes. Outside React: `resolveSchema()`, `resolveHighContrast()` and
-`subscribeSchema(listener)`, which fires on a change to either condition.
+Both resolve exactly as the `@dark` / `@hc` states do — attribute opt-in first, media query only when the attribute is absent — and re-render when either input changes. Outside React: `resolveSchema()`, `resolveHighContrast()` and `subscribeSchema(listener)`, which fires on a change to either condition.
 
-Reach for these only where CSS cannot go. Styling belongs in a state map
-(`{ '': …, '@dark': …, '@hc': … }`), which repaints on a schema flip with no
-re-render at all. What the states cannot reach is a surface that takes values
-rather than CSS — a Vega spec, a CodeMirror or Monaco theme, an iframe — or a
-control whose value *is* the condition, like the Light/Dark and
-Normal/High-contrast selectors over the [theme builder](#theme-builder).
+Reach for these only where CSS cannot go. Styling belongs in a state map (`{ '': …, '@dark': …, '@hc': … }`), which repaints on a schema flip with no re-render at all. What the states cannot reach is a surface that takes values rather than CSS — a Vega spec, a CodeMirror or Monaco theme, an iframe — or a control whose value _is_ the condition, like the Light/Dark and Normal/High-contrast selectors over the [theme builder](#theme-builder).
 
-Note the distinction from `contrastLevel`: the level is a config seed the app
-supplies and can read back, while high contrast is a viewing condition the
-document is in. They also pair up — `renderColorTokens({ scheme, highContrast })`
-takes both, so a region can be previewed in the conditions the page is actually
-showing.
+Note the distinction from `contrastLevel`: the level is a config seed the app supplies and can read back, while high contrast is a viewing condition the document is in. They also pair up — `renderColorTokens({ schema, highContrast })` takes both, so a region can be previewed in the conditions the page is actually showing.
 
 ## `<Root palette>`
 
@@ -452,7 +437,7 @@ This is a convenience wrapper over `setPaletteConfig()`, not a separate scope. *
 
 It also owns the accent's `saturation` outright — pinned to `100`, so a number passed _explicitly alongside_ it is inert and warned about (a number passed on its own turns pastel off instead). And it caps a color seed short of itself: the ceiling sits below where a saturated color lands, so `#EF4444` resolves to `#c47069`. Both are visible in the [Theme builder](#theme-builder), the first as a disabled slider and the second as the requested/resolved chips.
 
-**Re-seeding costs about 10 ms.** Rebuilding the eight themes and re-solving ~156 tokens across four scheme variants is not free, though it is inside a frame. A manual `contrastLevel` costs the same — it runs the same four passes — except at level `100`, which skips the two high-contrast ones because the normal pass already produced those values. Setting the config to a value it already holds is free — it does not even bump the version. If you are driving it from a slider, let the input coalesce to frames (a pointer-driven `onChange` already does) rather than writing on every event.
+**Re-seeding costs about 10 ms.** Rebuilding the eight themes and re-solving ~156 tokens across four schema variants is not free, though it is inside a frame. A manual `contrastLevel` costs the same — it runs the same four passes — except at level `100`, which skips the two high-contrast ones because the normal pass already produced those values. Setting the config to a value it already holds is free — it does not even bump the version. If you are driving it from a slider, let the input coalesce to frames (a pointer-driven `onChange` already does) rather than writing on every event.
 
 **If you call Glaze directly, tell the kit.** `glaze.configure({ darkTone })` and friends invalidate Glaze's own caches, but the kit's token maps are memoized against the palette config version:
 

package/docs/Usage.md

@@ -69,7 +69,7 @@ Defined in `src/tokens/sizes.ts`. Used for component heights and icon sizes.
 
 ## Shadow Tokens
 
-Defined in `src/tokens/shadows.ts`. Shadow colors (`#shadow-sm`, `#shadow-md`, `#shadow-lg`) are generated by Glaze and adapt automatically to dark / high-contrast schemes.
+Defined in `src/tokens/shadows.ts`. Shadow colors (`#shadow-sm`, `#shadow-md`, `#shadow-lg`) are generated by Glaze and adapt automatically to dark / high-contrast schemas.
 
 | Token            | Value                     |
 | ---------------- | ------------------------- |
@@ -92,30 +92,30 @@ Defined in `src/tokens/layout.ts`.
 
 All color tokens use `#name` syntax in styles. Opacity variants use `#name.NN` (e.g. `#surface-text.06` for 6% opacity).
 
-The palette is generated by [`@tenphi/glaze`](https://github.com/tenphi/glaze) (see `src/tokens/palette.ts`). Every color token is emitted as a state map with `light`, `@dark`, and `@hc` (high-contrast) variants, so the entire UI Kit adapts to dark / high-contrast schemes automatically.
+The palette is generated by [`@tenphi/glaze`](https://github.com/tenphi/glaze) (see `src/tokens/palette.ts`). Every color token is emitted as a state map with `light`, `@dark`, and `@hc` (high-contrast) variants, so the entire UI Kit adapts to dark / high-contrast schemas automatically.
 
 The seeds it is generated from — brand hue, saturation, per-status hues, `pastel`, `contrastLevel` — are tunable at runtime. See [Theming](./Theming.md).
 
-### Color Schemes
+### Color Schemas
 
 The `@dark` and `@hc` predefined states are wired up in `src/components/Root.tsx` to support both an attribute opt-in and the user's system preference:
 
 ```html
-<!-- Force dark scheme -->
+<!-- Force dark schema -->
 <html data-schema="dark">
 
-<!-- Force high-contrast scheme -->
+<!-- Force high-contrast schema -->
 <html data-contrast="high">
 
 <!-- Both can be combined -->
 <html data-schema="dark" data-contrast="high">
 ```
 
-When the attribute is absent, the scheme falls back to `@media (prefers-color-scheme: dark)` and `@media (prefers-contrast: more)`.
+When the attribute is absent, the schema falls back to `@media (prefers-color-scheme: dark)` and `@media (prefers-contrast: more)`.
 
 #### Reading the schema from JS
 
-For styling, use the state map — `{ '': light, '@dark': dark, '@hc': hc }`. Two cases it cannot serve: a surface the stylesheet never reaches (a Vega spec, a CodeMirror / Monaco theme, an iframe), and a control whose value *is* the ambient condition (a Light/Dark preview selector). For those, read the same two conditions from JS:
+For styling, use the state map — `{ '': light, '@dark': dark, '@hc': hc }`. Two cases it cannot serve: a surface the stylesheet never reaches (a Vega spec, a CodeMirror / Monaco theme, an iframe), and a control whose value _is_ the ambient condition (a Light/Dark preview selector). For those, read the same two conditions from JS:
 
 ```tsx
 import { useHighContrast, useSchema } from '@cube-dev/ui-kit';
@@ -124,7 +124,7 @@ const schema = useSchema(); // 'light' | 'dark' — the JS answer to `@dark`
 const isHighContrast = useHighContrast(); // boolean — the JS answer to `@hc`
 ```
 
-Both follow the attribute opt-in first and the media query second, exactly as the states do, and re-render when either changes. Outside React: `resolveSchema()`, `resolveHighContrast()`, and `subscribeSchema(listener)` (fires on either condition; re-read in the listener).
+Both follow the attribute opt-in first and the media query second, exactly as the states do, and re-render when either changes. Outside React: `resolveSchema()`, `resolveHighContrast()` and `subscribeSchema(listener)` (fires on either condition; re-read in the listener). This is the conditions half of the gap [`resolveTokenValue()`](#resolving-tokens-outside-css) closes for token _values_.
 
 Root-level only — there is no element-scoped or generic state reader, on purpose. Tasty's state vocabulary mixes element-local states (`hovered`, `pressed`, `disabled`) with ambient ones (`@media(…)`, `@root(…)`), and only the ambient half is answerable without an element.
 
@@ -169,7 +169,7 @@ Tokens a **container** sets to steer a component that cannot resolve the color o
 
 ```jsx
 <Block fill="#fixed-dark" color="#white" styles={{ '#current-fill': '#fixed-dark' }}>
-  <Button theme="current" type="primary">Legible in both schemes</Button>
+  <Button theme="current" type="primary">Legible in both schemas</Button>
 </Block>
 ```
 
@@ -177,7 +177,7 @@ Setting it moves the label, the icon slots and the chip's rim together. It also
 
 ### Accent System
 
-Each themed color (default, primary, success, danger, warning, note) provides an `accent-*` family anchored to a fixed white "accent surface text". These tokens stay recognizable across schemes (used for branded buttons, CTAs, etc.):
+Each themed color (default, primary, success, danger, warning, note) provides an `accent-*` family anchored to a fixed white "accent surface text". These tokens stay recognizable across schemas (used for branded buttons, CTAs, etc.):
 
 | Token (default theme; prefixed in others) | Role |
 | --- | --- |
@@ -218,10 +218,10 @@ resetPaletteConfig();
 
 Also available: `getPaletteConfig()`, `subscribePaletteConfig()`, the `usePaletteConfig()` hook, a `<Root palette={…}>` prop, `DEFAULT_PALETTE_CONFIG`, and `invalidatePaletteTokens()` for when you drive `glaze.configure(...)` yourself after mount. The palette is process-global — one palette per process, not per tree or per request.
 
-To theme a _region_ instead of the document — a theme preview, or a dark panel inside a light page — use `renderColorTokens()`. It resolves one config and one scheme to flat values you apply via a `tokens` prop, without touching the live palette:
+To theme a _region_ instead of the document — a theme preview, or a dark panel inside a light page — use `renderColorTokens()`. It resolves one config and one schema to flat values you apply via a `tokens` prop, without touching the live palette:
 
 ```tsx
-<Block tokens={renderColorTokens({ accent: { hue: 210 }, scheme: 'dark' })} fill="#surface">
+<Block tokens={renderColorTokens({ accent: { hue: 210 }, schema: 'dark' })} fill="#surface">
   …
 </Block>
 ```
@@ -340,7 +340,9 @@ resolveTokenValues(['#surface', '#surface-text', '#border']); // keyed by the to
 resolvePresetValues('s3'); // { fontFamily: 'ui-monospace, …', fontSize: '14px', lineHeight: '20px', … }
 ```
 
-`useTokenValue()`, `useTokenValues()` and `usePresetValues()` are the same three readers as hooks, re-resolved whenever the palette is re-seeded or the scheme / contrast tier flips. The object `useTokenValues()` returns keeps its identity while the values do, so it is safe as a dependency of the theme object built from it.
+`useTokenValue()`, `useTokenValues()` and `usePresetValues()` are the same three readers as hooks, re-resolved whenever the palette is re-seeded or the schema / contrast tier flips. The object `useTokenValues()` returns keeps its identity while the values do, so it is safe as a dependency of the theme object built from it.
+
+These resolve token _values_. For the ambient _conditions_ themselves — which schema and contrast tier the document is in — see [Reading the schema from JS](#reading-the-schema-from-js).
 
 So these helpers do not inspect the value. They read `$tokens-applied`, a marker the token block declares alongside the tokens, which answers the question that matters — _are the kit's tokens in effect on this element?_ Off that surface every read returns `null` (or `fallback`) and warns once in development; on it, the computed value is taken as the truth.
 

package/docs/components/content/ItemCard.md

@@ -55,7 +55,7 @@ Inherits all styling from `Item`. See [Item documentation](./Item.md) for sub-el
 
 ### Themes
 
-Use the `theme` prop to apply a semantic color scheme:
+Use the `theme` prop to apply a semantic color schema:
 
 - `default` — Standard card appearance
 - `success` — Green theme for positive outcomes

package/docs/components/content/PrismCode.md

@@ -28,7 +28,7 @@ Supports [Base properties](../../BaseProperties.md).
 
 ## Theme
 
-Syntax colors are driven by a dedicated, scheme-aware palette of `code-*` tokens. Each token uses a different hue so token classes stay visually separable, and every token meets at least **WCAG AA (4.5:1)** contrast against `#surface` in light, dark, and high-contrast schemes (AAA in HC).
+Syntax colors are driven by a dedicated, schema-aware palette of `code-*` tokens. Each token uses a different hue so token classes stay visually separable, and every token meets at least **WCAG AA (4.5:1)** contrast against `#surface` in light, dark, and high-contrast schemas (AAA in HC).
 
 | Token | Hue | Used for |
 | --- | --- | --- |
@@ -40,7 +40,7 @@ Syntax colors are driven by a dedicated, scheme-aware palette of `code-*` tokens
 | `#code-function` | pink | functions, class names, regex, variables |
 | `#code-attribute` | cyan | attribute names, properties, selectors, built-ins, keys |
 
-Diff insertion (`+`) and deletion (`-`) intentionally re-use the existing `#success-*` / `#danger-*` ramps — both the line background tint and the foreground color adapt to the active scheme.
+Diff insertion (`+`) and deletion (`-`) intentionally re-use the existing `#success-*` / `#danger-*` ramps — both the line background tint and the foreground color adapt to the active schema.
 
 ## Examples
 

package/docs/components/data/DataTable.md

@@ -371,7 +371,7 @@ A stale order is safe: keys for columns that no longer exist are ignored, and a
 
 `column.color` tints a whole column — header, cells and pinned totals. It takes a palette theme name, any CSS color, a `{ hue, saturation }` seed, or a `{ fill, text }` pair for full manual control.
 
-Every form but the last is _derived_: only the hue and saturation are kept, and the tone ramp plus an AA/AAA text floor are re-solved for light, dark and high-contrast. A column cannot end up unreadable in a scheme nobody checked.
+Every form but the last is _derived_: only the hue and saturation are kept, and the tone ramp plus an AA/AAA text floor are re-solved for light, dark and high-contrast. A column cannot end up unreadable in a schema nobody checked.
 
 ```tsx
 const columns = [

package/docs/components/fields/Picker.md

@@ -310,7 +310,7 @@ The trigger button supports various visual styles via the `type` prop:
 
 ### Trigger Button Themes
 
-Control the color scheme with the `theme` prop:
+Control the color schema with the `theme` prop:
 
 - **`default`** — Standard theme (default)
 - **`danger`** — Red/destructive color (also applied automatically when `isInvalid` is set)

package/docs/components/layout/Board.md

@@ -56,7 +56,7 @@ Dragging and resizing are powered by React Aria's `useMove`, so they work with m
 - **`selectedKeys`** `string[]` — Controlled selection. Keys are layout item ids (`LayoutItem.i`).
 - **`defaultSelectedKeys`** `string[]` — Initial selection for uncontrolled usage.
 - **`onSelectionChange`** `(keys: string[]) => void` — Called when the selection changes. Keys are deduped and returned in the board's layout order, never in click order.
-- **`selectionCancel`** `string` (default: `BOARD_SELECTION_CANCEL`) — CSS selector marking interactive descendants. A press on one never selects and never starts a drag, so the control keeps its own click _and_ its native focus; it also drops the selection, since interacting with a widget's content means the user has moved on. On a selectable board this doubles as the drag guard, so form controls stay usable without also configuring `dragCancel`. The default covers native form controls, links, and the common ARIA widget roles, plus `[data-no-select]` as an escape hatch. Pass `''` to disable the guard. Can be overridden per widget.
+- **`selectionCancel`** `string` (default: `BOARD_SELECTION_CANCEL`) — CSS selector marking interactive descendants. A press on one never selects and never starts a drag, so the control keeps its own click _and_ its native focus; it also drops the selection, since interacting with a widget's content means the user has moved on — and that holds however the control handles the press, including one that stops propagation or renders in a portal (a menu opened from a widget's toolbar). On a selectable board this doubles as the drag guard, so form controls stay usable without also configuring `dragCancel`. The default covers native form controls, links, and the common ARIA widget roles, plus `[data-no-select]` as an escape hatch. Pass `''` to disable the guard. Can be overridden per widget.
 - **`allowMarqueeSelection`** `boolean` (default: `selectionMode === 'multiple'`) — Draw a rubber-band selection when a drag starts on empty board space. A press on a widget selects and drags instead, so the lasso owns empty canvas only. Hold <kbd>Shift</kbd> or <kbd>Cmd</kbd>/<kbd>Ctrl</kbd> to add to the existing selection rather than replacing it. A board sized to its content has no empty space left once the grid fills up, which makes the lasso undiscoverable — use `extraRows` to keep a band of it.
 - **`onWidgetsDelete`** `(keys: string[]) => void` — Called when <kbd>Delete</kbd>/<kbd>Backspace</kbd> is pressed with a non-empty selection and focus is not in an editable field. **Board never mutates the layout itself** — removing the widgets is yours to do, which is what lets you make it undoable. Board only handles these keys when this handler is set.
 - **`constraints`** `LayoutConstraint[]` — Grid/item layout constraints.

package/docs/components/organisms/StatsCard.md

@@ -22,7 +22,7 @@ Extends Card with:
 - `placeContent` — `space-between`
 - `gap` — `1x`
 - `border` — none
-- `shadow` — `$shadow` (design-system elevation token, scheme-aware via `#shadow-md`)
+- `shadow` — `$shadow` (design-system elevation token, schema-aware via `#shadow-md`)
 - `padding` — `2.5x`
 
 ### Base Properties

package/docs/components/other/CubeLogo.md

@@ -37,35 +37,35 @@ Every path is drawn with `currentColor`. Inheriting is the default and usually c
 <CubeFullLogo color="#dark" />
 ```
 
-There are **no baked-in brand hexes**, which is what lets the marks work on any surface and in any scheme.
+There are **no baked-in brand hexes**, which is what lets the marks work on any surface and in any schema.
 
-## Light and dark schemes
+## Light and dark schemas
 
 The mark is two different drawings rather than one drawing recoloured — the dark variant is filled differently so it holds its weight against a dark surface. Both are rendered, and the `@dark` state swaps them in CSS.
 
 That means the swap costs no re-render, is correct during SSR and before hydration, and needs no prop in the normal case. It also means a snapshot of the DOM always contains both paths; assert on `[data-element="LightMark"]` / `[data-element="DarkMark"]` rather than on a single `path`.
 
-### Pinning a scheme
+### Pinning a schema
 
-`@dark` is a _state_, and it is resolved against the **document**. Where the background is known but the document scheme does not describe it, pass `scheme` to pin one mark:
+`@dark` is a _state_, and it is resolved against the **document**. Where the background is known but the document schema does not describe it, pass `schema` to pin one mark:
 
 ```jsx
 {/* A fixed-dark panel inside a light app */}
 <Block fill="#surface-inverse">
-  <CubeFullLogo scheme="dark" color="#white" />
+  <CubeFullLogo schema="dark" color="#white" />
 </Block>
 
 {/* A themed region — `tokens` overrides token *values*, so it cannot reach a state */}
-<Block tokens={renderColorTokens({ scheme: 'dark' })} fill="#surface">
-  <CubeFullLogo scheme="dark" />
+<Block tokens={renderColorTokens({ schema: 'dark' })} fill="#surface">
+  <CubeFullLogo schema="dark" />
 </Block>
 ```
 
-Use it only when you know the surface. Omitting it is the right default: a pinned scheme stops following the user's own light/dark preference.
+Use it only when you know the surface. Omitting it is the right default: a pinned schema stops following the user's own light/dark preference.
 
 ## Properties
 
-- **`scheme`** `'light' | 'dark'` — Pin one mark instead of letting the `@dark` state pick. Omit it unless you know the surface; see [Pinning a scheme](#pinning-a-scheme)
+- **`schema`** `'light' | 'dark'` — Pin one mark instead of letting the `@dark` state pick. Omit it unless you know the surface; see [Pinning a schema](#pinning-a-schema)
 - **`size`** — Maps onto `font-size`. Both axes on `CubeLogo`, height only on `CubeFullLogo`
 - **`color`** — Any color token. Both marks are drawn with `currentColor`, so this is inherited by default
 

package/docs/components/overlays/Tooltip.md

@@ -42,7 +42,7 @@ Display container for tooltip content. Has a directional arrow dependent on its
 - **`showIcon`** `boolean` — Controls whether an icon should be displayed in the tooltip
 - **`placement`** `PlacementAxis` (default: `'top'`) — Position of the tooltip relative to its trigger. Options: `top`, `bottom`, `left`, `right`
 - **`isMaterial`** `boolean` — Enables material-style tooltip with auto pointer events
-- **`isLight`** `boolean` — Uses light color scheme for the tooltip
+- **`isLight`** `boolean` — Uses light color schema for the tooltip
 - **`isOpen`** `boolean` — Controlled open state of the tooltip
 - **`defaultOpen`** `boolean` — Whether the tooltip is open by default (uncontrolled)
 - **`onOpenChange`** `(isOpen: boolean) => void` — Callback when the tooltip open state changes
@@ -78,7 +78,7 @@ These properties allow direct style application without using the `styles` prop:
 The `mods` property on the tooltip accepts the following modifiers you can override:
 
 - **`material`** `boolean` — Enables material-style tooltip with pointer events
-- **`light`** `boolean` — Uses light color scheme instead of dark
+- **`light`** `boolean` — Uses light color schema instead of dark
 - **`open`** `boolean` — Indicates whether the tooltip is currently visible
 
 ## Usage Patterns

package/docs/components/overlays/TooltipProvider.md

@@ -19,7 +19,7 @@ A convenience wrapper that combines `TooltipTrigger` and `Tooltip` into a single
 - **`delay`** `number` (default: `250`) — The delay time in ms for the tooltip to show up
 - **`closeDelay`** `number` (default: `500`) — The delay time in ms for the tooltip to close
 - **`isMaterial`** `boolean` — Enables material-style tooltip with auto pointer events
-- **`isLight`** `boolean` — Uses light color scheme for the tooltip
+- **`isLight`** `boolean` — Uses light color schema for the tooltip
 - **`isOpen`** `boolean` — Controlled open state of the tooltip
 - **`defaultOpen`** `boolean` — Whether the tooltip is open by default (uncontrolled)
 - **`onOpenChange`** `(isOpen: boolean) => void` — Callback when the tooltip open state changes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cube-dev/ui-kit",
-  "version": "0.0.0-canary-bafd63a",
+  "version": "0.0.0-canary-c3b7b41",
   "type": "module",
   "description": "UIKit for Cube Projects",
   "repository": {