@cube-dev/ui-kit 0.170.0 → 0.172.0

package/docs/components/fields/RadioGroup.md

@@ -10,6 +10,18 @@ A radio group allows users to select exactly one option from a set of mutually e
 - Display filter options where only one can be active
 - Provide clear selection options in surveys or questionnaires
 
+Every variant of this component — `Radio.Tabs` included — is a **form control**: it runs through `useFieldProps` / `wrapWithField`, publishes `role="radiogroup"` semantics, and takes part in `Form` validation. Reach for one when the selection is a _value the user is setting_.
+
+### When not to use
+
+If the control is not a field — a toolbar that swaps which view is on screen, a segmented control over page content — use [Tabs](../navigation/Tabs.md) instead, with `type="radio"` when the connected-button look was the point. It renders the same chrome without the field wiring, and it owns the panels it switches between.
+
+| In a `Form`? | Switches which controls render? | Use |
+| --- | --- | --- |
+| yes | yes | `Radio.Tabs` |
+| yes | no | `Radio.Group type="button"` |
+| no | — | `Tabs` (with `type="radio"` when the radio look was wanted) |
+
 ## Component
 
 ---
@@ -181,8 +193,10 @@ When using `type="button"`, you can customize the button appearance:
 
 ### Tabs Group
 
+Only inside a `Form`, and only when the choice changes which fields follow it — see [When not to use](#when-not-to-use). A toolbar switcher is `Tabs type="radio"`.
+
 ```jsx
-<Radio.Tabs label="Status">
+<Radio.Tabs name="status" label="Status">
   <Radio value="active">Active</Radio>
   <Radio value="inactive">Inactive</Radio>
   <Radio value="pending">Pending</Radio>
@@ -308,22 +322,28 @@ When using `type="button"`, you can customize the button appearance:
    </Radio.Group>
    ```
 
-3. **Visual Type**: Use `Radio.Tabs` for compact toolbars, `type="button"` for spaced selections, traditional radios for forms
+3. **Visual Type**: pick by the shape of the choice, not by the look you want — `Radio.Tabs` for a compact connected group _inside a form_, `type="button"` for spaced selections, traditional radios for longer or descriptive option lists
 
    ```jsx
-   {/* Good for compact toolbars */}
-   <Radio.Tabs label="View">
-     <Radio value="list">List</Radio>
-     <Radio value="grid">Grid</Radio>
+   {/* Good for a compact form field that gates the fields below it */}
+   <Radio.Tabs name="mode" label="Mode">
+     <Radio value="basic">Basic</Radio>
+     <Radio value="advanced">Advanced</Radio>
    </Radio.Tabs>
 
+   {/* Don't: a toolbar view switcher is not a field — use Tabs */}
+   <Tabs type="radio" defaultActiveKey="list">
+     <Tab key="list" title="List">...</Tab>
+     <Tab key="grid" title="Grid">...</Tab>
+   </Tabs>
+
    {/* Good for button selections */}
    <Radio.Group type="button" label="Priority">
      <Radio value="low">Low</Radio>
      <Radio value="high">High</Radio>
    </Radio.Group>
 
-   {/* Good for forms */}
+   {/* Good for a longer or descriptive option list */}
    <Radio.Group label="Gender">
      <Radio value="male">Male</Radio>
      <Radio value="female">Female</Radio>
@@ -335,7 +355,7 @@ When using `type="button"`, you can customize the button appearance:
 6. **Grouping**: Use meaningful group labels that describe the choice
 7. **Options**: Keep option labels concise and mutually exclusive
 8. **Layout**: Use horizontal layout only when space permits and options are short
-9. **Tabs Mode**: Use `Radio.Tabs` for compact, connected button groups in limited space
+9. **Tabs Mode**: `Radio.Tabs` is for compact, connected button groups in limited space _that are form fields_. Outside a `Form` — or inside one, when the choice doesn't change which controls render — reach for `Tabs type="radio"` or `type="button"` instead
 
 ## Integration with Forms
 

package/docs/components/layout/Board.md

@@ -141,7 +141,7 @@ An aligned board never shrinks its rows, so pair it with `isAutoHeight` on the c
 - **`compact`** `'vertical' | 'horizontal' | 'free' | null` (default: `'vertical'`) — Compaction behavior. `'vertical'`/`'horizontal'` reflow widgets to remove gaps; `'free'` places each widget exactly where dropped and never pushes its neighbours (blocked from occupied cells unless `allowOverlap`); `null` disables compaction but still resolves collisions the legacy react-grid-layout way.
 - **`allowOverlap`** `boolean` (default: `false`) — Allow widgets to overlap (stack). It also **switches compaction off**: with it on, `compact="vertical"`/`"horizontal"` no longer reflow, and `preventCollision`/`collisionMode` have no effect at all, since nothing is ever refused. In `'free'` mode it is what distinguishes stacking from blocking a drop onto an occupied cell.
 - **`preventCollision`** `boolean` (default: `false`) — Block movement into occupied cells instead of pushing. Applies to `'vertical'`, `'horizontal'` and `null` only: `compact="free"` derives blocking from `allowOverlap` and ignores this prop, and `allowOverlap` overrides it everywhere.
-- **`collisionMode`** `'revert' | 'downscale' | 'swap'` (default: `'revert'`) — How to resolve a drop the grid would otherwise refuse. Only applies where a collision _blocks_ a move — `compact="free"` (which prevents collisions) or an explicit `preventCollision` — and never under `allowOverlap`, where nothing is blocked. `'revert'` snaps the widget back. `'downscale'` shrinks it into the free space at the drop cell, growing rightward and downward, floored at its `minW`/`minH` (below that it reverts). Within one board, `'swap'` trades places with **one** widget — the one the drop covers most — which takes the cell the drag began at, each keeping as much of its own size as fits there. It never displaces more than that one widget. A drop straddling two widgets trades with one of them rather than refusing, so the swap never blinks away as you sweep across a boundary; ties go to the widget earlier in reading order. Dragging back retraces the original arrangement exactly. For a widget arriving from another board (including a nested board entering its parent), the destination board's `'swap'` mode becomes strict insertion: the requested anchor cell must be empty, the incoming widget keeps its size when possible or downscales into the available room to its right and below, and existing destination widgets are neither exchanged nor reflowed. Releasing over an occupied anchor or where `minW`/`minH` cannot fit cancels the transfer and restores both boards; it does not reuse the last valid preview or search for another slot. No mode ever _grows_ a widget. Applies to single-widget drags. Arrow keys honour it too but never resize anything — each press is a gesture of its own, so a press that shrank a widget would have nothing to restore from, and only an exchange that fits outright is allowed. A multi-widget selection still only moves where it fits outright, and a resize is still blocked by a collision.
+- **`collisionMode`** `'revert' | 'downscale' | 'swap'` (default: `'revert'`) — How to resolve a drop the grid would otherwise refuse. Only applies where a collision _blocks_ a move — `compact="free"` (which prevents collisions) or an explicit `preventCollision` — and never under `allowOverlap`, where nothing is blocked. `'revert'` snaps the widget back. `'downscale'` shrinks it into the free space at the drop cell, growing rightward and downward, floored at its `minW`/`minH` (below that it reverts). Within one board, `'swap'` trades places with **one** widget — the one the drop covers most — which takes the cell the drag began at, each keeping as much of its own size as fits there. It never displaces more than that one widget. A drop straddling two widgets trades with one of them rather than refusing, so the swap never blinks away as you sweep across a boundary; ties go to the widget earlier in reading order. Dragging back retraces the original arrangement exactly. For a widget arriving from another board (including a nested board entering its parent), there is no slot on the destination to give back, so `'swap'` resolves as `'downscale'`: the incoming widget keeps its size when possible or downscales into the available room to its right and below, and existing destination widgets are never exchanged. A release over an occupied anchor commits whatever the preview was showing rather than cancelling the transfer: the widget holds the last cell it fitted in as you sweep across a destination widget, and enters at the nearest fitting cell when the very first cell it is offered is occupied. No mode ever _grows_ a widget. Applies to single-widget drags. Arrow keys honour it too but never resize anything — each press is a gesture of its own, so a press that shrank a widget would have nothing to restore from, and only an exchange that fits outright is allowed. A multi-widget selection still only moves where it fits outright, and a resize is still blocked by a collision.
 - **`isDraggable`** `boolean` (default: `true`) — Enable dragging for all widgets. A ceiling, not a default: `false` here cannot be re-enabled by a widget, and a `static` layout item is never draggable regardless.
 - **`isResizable`** `boolean` (default: `true`) — Enable resizing for all widgets. Same ceiling semantics as `isDraggable`.
 - **`isDroppable`** `boolean` (default: `true`) — Whether the board accepts widgets dropped from _other_ boards. `false` does not affect dragging within the board.
@@ -323,7 +323,7 @@ Centre the resize grip on the widget's corner with `resizeGripPlacement="corner"
 
 ### Resolving a blocked drop
 
-On a free grid a drop onto occupied cells is refused. `collisionMode` resolves it instead: `'downscale'` shrinks the widget into whatever room is at the drop cell. Within one board, `'swap'` trades places with the widget already there. Across boards, the same mode inserts only at an empty anchor and downscales without moving destination widgets; an invalid release cancels the transfer. None of these paths ever grows a widget. The examples below show all three behaviors.
+On a free grid a drop onto occupied cells is refused. `collisionMode` resolves it instead: `'downscale'` shrinks the widget into whatever room is at the drop cell. Within one board, `'swap'` trades places with the widget already there. Across boards, the same mode downscales into an empty cell without exchanging destination widgets, and an occupied anchor commits the previewed cell instead of cancelling. None of these paths ever grows a widget. The examples below show all three behaviors.
 
 ### Card widgets
 

package/docs/components/navigation/Tabs.md

@@ -112,7 +112,7 @@ For individual tabs:
 - `default` - Standard tabs with selection indicator below (default)
 - `narrow` - Same as default but with collapsed horizontal label padding for compact layouts
 - `file` - File-style tabs with border bottom highlight on selection, delimiter between tabs
-- `radio` - Radio button style for tab selection
+- `radio` - Radio button style for tab selection. This is the right choice for a compact switcher that is _not_ a form field — a view toolbar, a segmented control over page content. [`Radio.Tabs`](../fields/RadioGroup.md) looks the same but is a form control, so keep it for choices inside a `Form`
 
 ### Sizes
 

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, schema-aware via `#shadow-md`)
+- `shadow` — `$shadow` (design-system elevation token, scheme-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 schema.
+There are **no baked-in brand hexes**, which is what lets the marks work on any surface and in any scheme.
 
-## Light and dark schemas
+## Light and dark schemes
 
 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 schema
+### Pinning a scheme
 
-`@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:
+`@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:
 
 ```jsx
 {/* A fixed-dark panel inside a light app */}
 <Block fill="#surface-inverse">
-  <CubeFullLogo schema="dark" color="#white" />
+  <CubeFullLogo scheme="dark" color="#white" />
 </Block>
 
 {/* A themed region — `tokens` overrides token *values*, so it cannot reach a state */}
-<Block tokens={renderColorTokens({ schema: 'dark' })} fill="#surface">
-  <CubeFullLogo schema="dark" />
+<Block tokens={renderColorTokens({ scheme: 'dark' })} fill="#surface">
+  <CubeFullLogo scheme="dark" />
 </Block>
 ```
 
-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.
+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.
 
 ## Properties
 
-- **`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)
+- **`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)
 - **`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 schema for the tooltip
+- **`isLight`** `boolean` — Uses light color scheme 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 schema instead of dark
+- **`light`** `boolean` — Uses light color scheme instead of dark
 - **`open`** `boolean` — Indicates whether the tooltip is currently visible
 
 ## Usage Patterns
@@ -144,7 +144,7 @@ Control where the tooltip appears relative to its trigger:
 The tooltip is capped at `36x` wide (or the viewport minus `4x`, whichever is smaller) and wraps its content to stay inside that cap. Runs with no spaces — URLs, tokens, identifiers, error strings — are broken mid-word rather than allowed to overflow the bubble.
 
 ```jsx
-<TooltipProvider title="https://cubecloud.example.com/deployments/12345/schema/files/model/cubes/very_long_cube_name.yml">
+<TooltipProvider title="https://cubecloud.example.com/deployments/12345/scheme/files/model/cubes/very_long_cube_name.yml">
   <Button>Hover me</Button>
 </TooltipProvider>
 ```

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 schema for the tooltip
+- **`isLight`** `boolean` — Uses light color scheme 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.170.0",
+  "version": "0.172.0",
   "type": "module",
   "description": "UIKit for Cube Projects",
   "repository": {
@@ -96,7 +96,7 @@
     "@statoscope/cli": "^5.20.1",
     "@storybook/addon-docs": "^10.3.6",
     "@storybook/react-vite": "^10.3.6",
-    "@tenphi/eslint-plugin-tasty": "^1.0.3",
+    "@tenphi/eslint-plugin-tasty": "^1.0.5",
     "@testing-library/dom": "^10.4.1",
     "@testing-library/jest-dom": "^6.7.0",
     "@testing-library/react": "^16.3.0",