@thebase/ui 1.2.1 → 1.3.0

package/docs/owl-components.md

@@ -1,44 +1,42 @@
-# Base Components
+# Nodex UI Component
 
 See the [Usage Guide](usage-guide.md) for when to reach for this API versus the static `b-ui` one. This page covers the pure Base API only.
 
-The Base UI ships a second, additive public API alongside the static `b-ui` markers: real Owl component classes you import, compose with `static components`, and mount as part of your own application. This page covers how to load and use it; see [Component Authoring](component-authoring.md) for how components implement both APIs from one source folder.
+Nodex UI ships a second, additive public API alongside the static `b-ui` markers: real Nodex component classes you import, compose with `static components`, and mount as part of your own application. This page covers how to load and use it; see [Component Authoring](component-authoring.md) for how components implement both APIs from one source folder.
 
-As of 1.1.0, every component in the registry (all 74) has a pure Base export — there are no static-only components left. Compound components export a root class plus sub-components (e.g. `Dialog`/`DialogTrigger`/`DialogContent`/...); check a component's `owlComponents` entry in `dist/baseui.registry.json`, or its doc page under [`docs/components/`](components/), for the exact export list. A few components have a deliberately reshaped pure Base API versus their static markup-scanning adapter — see [Registry](registry.md#component-export-policy) for which ones and why.
+As of 1.1.0, every component in the registry (all 74) has a pure Base export — there are no static-only components left. Compound components export a root class plus sub-components (e.g. `Dialog`/`DialogTrigger`/`DialogContent`/...); check a component's `owlComponents` entry in `dist/nodexui.registry.json`, or its doc page under [`docs/components/`](components/), for the exact export list. A few components have a deliberately reshaped pure Base API versus their static markup-scanning adapter — see [Registry](registry.md#component-export-policy) for which ones and why.
 
 ## What you need to load
 
-Everything — the static `b-ui` runtime, the Owl framework, every Base component class, and the theme helper — is one file: `dist/baseui.esm.js` (or `dist/baseui.min.js` as a classic script). There is no separate `baseui.owl.*`/`baseui.components.esm.js`/`baseui.theme.esm.js` to load.
+Everything — the static `b-ui` runtime, the Nodex runtime, every Base component class, and the theme helper — is one file: `dist/nodexui.esm.js` (or `dist/nodexui.min.js` as a classic script). There is no separate `nodexui.owl.*`/`nodexui.components.esm.js`/`nodexui.theme.esm.js` to load.
 
 | File | Purpose |
 | --- | --- |
-| `dist/baseui.min.css` | Bootstrap + the Base UI styling, shared by both APIs. |
-| `@base/owl` (`dist/baseui.esm.js`) | The Owl framework — `Component`, `mount`, `xml`, `useState`, etc. Pinned to Owl `2.8.3`, embedded directly in this file. Import your app's own Owl usage from here too, not `@odoo/owl`. |
-| `@base/component` (`dist/baseui.esm.js`) | The Base component classes — same file as `@base/owl` above, just a different import-map key for readability. |
-| `@base/theme` (`dist/baseui.esm.js`) | Same file again — the theme helper for persisted light/dark toggles, URL overrides, button-label sync, and iframe preview sync. |
-| `@base/templates` (`dist/baseui.templates.xml`) | The Owl templates the component classes reference (`static template = "baseui.Button"`, etc). Must be loaded and passed to `mount()` before any Base UI component tag renders — a component class alone does not carry its template. |
+| `dist/nodexui.min.css` | the built-in styles + Nodex UI styling, shared by both APIs. |
+| `nodexui` (`dist/nodexui.esm.js`) | The Nodex runtime — `Component`, `mount`, `xml`, `useState`, etc. Pinned to Nodex `2.8.3`, embedded directly in this file. Import your app's own Nodex usage from here too, not `@odoo/owl`. |
+| `nodexui` (`dist/nodexui.esm.js`) | The Base component classes — same file as `nodexui` above, just a different import-map key for readability. |
+| `nodexui` (`dist/nodexui.esm.js`) | Same file again — the theme helper for persisted light/dark toggles, URL overrides, button-label sync, and iframe preview sync. |
+| `nodexui/templates` (`dist/nodexui.templates.xml`) | The Nodex templates the component classes reference (`static template = "nodexui.Button"`, etc). Must be loaded and passed to `mount()` before any Nodex UI component tag renders — a component class alone does not carry its template. |
 
 ## Browser (import map) usage
 
 ```html
-<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/@thebase/ui@latest/dist/baseui.min.css">
+<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/nodexui@latest/dist/nodexui.min.css">
 <script type="importmap">
 {
   "imports": {
-    "@base/owl": "https://cdn.jsdelivr.net/npm/@thebase/ui@latest/dist/baseui.esm.js",
-    "@base/component": "https://cdn.jsdelivr.net/npm/@thebase/ui@latest/dist/baseui.esm.js",
-    "@base/theme": "https://cdn.jsdelivr.net/npm/@thebase/ui@latest/dist/baseui.esm.js",
-    "@base/templates": "https://cdn.jsdelivr.net/npm/@thebase/ui@latest/dist/baseui.templates.xml"
+    "nodexui": "https://cdn.jsdelivr.net/npm/nodexui@latest/dist/nodexui.esm.js",
+    "nodexui/templates": "https://cdn.jsdelivr.net/npm/nodexui@latest/dist/nodexui.templates.xml"
   }
 }
 </script>
 <script type="module">
-  import { Component, mount, xml } from "@base/owl";
-  import { Button, Card, CardBody, CardHeader, CardTitle } from "@base/component";
+  import { Component, mount, xml } from "nodexui";
+  import { Button, Card, CardBody, CardHeader, CardTitle } from "nodexui";
 
-  // "@base/templates" is an import-map entry, not a JS module — resolve it
+  // "nodexui/templates" is an import-map entry, not a JS module — resolve it
   // to its mapped URL and fetch the text.
-  const templates = await fetch(import.meta.resolve("@base/templates")).then((r) => r.text());
+  const templates = await fetch(import.meta.resolve("nodexui/templates")).then((r) => r.text());
 
   class Root extends Component {
     static components = { Button, Card, CardBody, CardHeader, CardTitle };
@@ -55,19 +53,19 @@ Everything — the static `b-ui` runtime, the Owl framework, every Base componen
 </script>
 ```
 
-`https://unpkg.com/@thebase/ui@latest/dist/...` mirrors the same files as an alternative CDN if jsDelivr is unreachable — swap the host in each URL above. For a self-hosted build, replace the CDN host with your own served path (e.g. `/dist/baseui.esm.js`). These snippets use `@latest` for readability; pin an exact version (e.g. `@1.2.1`, or `@1` to take only non-breaking updates) in production so a new release can't change what your page loads.
+`https://unpkg.com/nodexui@latest/dist/...` mirrors the same files as an alternative CDN if jsDelivr is unreachable — swap the host in each URL above. For a self-hosted build, replace the CDN host with your own served path (e.g. `/dist/nodexui.esm.js`). These snippets use `@latest` for readability; pin an exact version (e.g. `@1.3.0`, or `@1` to take only non-breaking updates) in production so a new release can't change what your page loads.
 
-No `@odoo/owl` import appears anywhere in that snippet — `@base/owl` is the only Owl entry point the Base UI components and consumer apps need. Because `@base/owl`, `@base/component`, and `@base/theme` all point at the exact same `dist/baseui.esm.js` URL, the browser fetches and evaluates it once and every key shares the same module instance — no separate classic `<script>` needs to load first to set up a shared global.
+No `@odoo/owl` import appears anywhere in that snippet — `nodexui` is the only Nodex entry point Nodex UI components and consumer apps need. Because `nodexui`, `nodexui`, and `nodexui` all point at the exact same `dist/nodexui.esm.js` URL, the browser fetches and evaluates it once and every key shares the same module instance — no separate classic `<script>` needs to load first to set up a shared global.
 
 ## npm / bundler usage
 
 ```sh
-npm install @thebase/ui
+npm install nodexui
 ```
 
 ```js
-import { Component, mount, xml, Button, Card } from "@thebase/ui";
-import baseuiTemplates from "@thebase/ui/dist/baseui.templates.xml?raw"; // exact loader syntax depends on your bundler
+import { Component, mount, xml, Button, Card } from "nodexui";
+import nodexuiTemplates from "nodexui/dist/nodexui.templates.xml?raw"; // exact loader syntax depends on your bundler
 
 class Root extends Component {
   static components = { Button, Card };
@@ -75,40 +73,40 @@ class Root extends Component {
 }
 ```
 
-There's only one package entry now — `@thebase/ui` exports the Owl framework (built from the exact `@odoo/owl@2.8.3` this Base UI release vendors; you do not need to install `@odoo/owl` yourself), every Base component class, and the theme helper together. Browser import-map examples above still use the `@base/owl`/`@base/component`/`@base/theme` keys for readability, but they're just local aliases to the same file.
+There's only one package entry now — `nodexui` exports the Nodex runtime (built from the exact `@odoo/owl@2.8.3` this Nodex UI release vendors; you do not need to install `@odoo/owl` yourself), every Base component class, and the theme helper together. Browser import-map examples above still use the `nodexui`/`nodexui`/`nodexui` keys for readability, but they're just local aliases to the same file.
 
-When a bundler cannot import XML with `?raw`, load `dist/baseui.templates.xml` as a served asset and pass the fetched string to `mount(Root, target, { templates })`. The template file is part of the runtime contract, not optional documentation.
+When a bundler cannot import XML with `?raw`, load `dist/nodexui.templates.xml` as a served asset and pass the fetched string to `mount(Root, target, { templates })`. The template file is part of the runtime contract, not optional documentation.
 
 ## Mixing with the static API
 
 Both APIs come from the exact same bundle now, so there's nothing extra to load — just be clear about which mechanism owns which markup:
 
 - `thebase.mountAll(root)` enhances static `[b-ui]` and `[b-icon]` markers.
-- Owl `mount(Root, target, { templates })` renders component tags such as `<Button/>`.
+- Nodex `mount(Root, target, { templates })` renders component tags such as `<Button/>`.
 - Importing the package always also runs `autoMount()` (its `[b-ui]`/`[b-icon]` DOM scan on `DOMContentLoaded`) — harmless if your page has none, but means there's no side-effect-free way to import just the component classes anymore.
-- Both APIs share `dist/baseui.min.css`, `@base/theme`, and the same `b-theme` / `data-bs-theme` root attributes.
+- Both APIs share `dist/nodexui.min.css`, `nodexui`, and the same `b-theme` / `data-bs-theme` root attributes.
 
 ## Props, events, slots
 
 - Props are camelCase (`variant`, `label`, `disabled`, `className`).
 - Almost every component that renders its own root element also accepts `style` (a string or a plain object of CSS properties) alongside `className`. Components that only forward a default slot with no wrapping element of their own (`AlertDialog`, `Pwa`, `Sheet`, `ContextMenu`, `Drawer`) have neither prop. A handful of components that already compute an internal style (`Icon`, `AspectRatio`, `Progress`, `ContextMenuContent`, `SidebarMenuSkeleton`) merge your `style` with their own computed value instead of one overwriting the other.
 - Events are callback props (`onClick`, `onChange`, `onOpenChange`), not DOM `CustomEvent`s — that's the static API's contract, not this one.
-- Default slot content works as normal Owl children (`<Badge>Draft</Badge>`); compound components use named slots/sub-tags (`<CardHeader>`, `<DialogFooter>`).
+- Default slot content works as normal Nodex children (`<Badge>Draft</Badge>`); compound components use named slots/sub-tags (`<CardHeader>`, `<DialogFooter>`).
 
 ## Global component fallback
 
-`Component` exported from `@base/owl` / `@thebase/ui` is Owl's `Component` with one addition: any component that extends it can use every registered the Base UI component (`<Icon/>`, `<Button/>`, `<Card/>`, ...) in its template, even if its own `static components` doesn't list it. Without this, Owl only checks a component's own `static components` map, so a nested child that used `<Icon/>` without declaring it crashed with `Cannot find the definition of component "Icon"`.
+`Component` exported from `nodexui` / `nodexui` is Nodex's `Component` with one addition: any component that extends it can use every registered Nodex UI component (`<Icon/>`, `<Button/>`, `<Card/>`, ...) in its template, even if its own `static components` doesn't list it. Without this, Nodex only checks a component's own `static components` map, so a nested child that used `<Icon/>` without declaring it crashed with `Cannot find the definition of component "Icon"`.
 
 - The fallback applies to every component in the tree, not only the root passed to `mount()`.
-- Entries in your own `static components` still take precedence over a Base UI component with the same name.
-- Listing the Base UI classes in `static components` is still allowed and is the clearest choice for shared or library code. The fallback mainly protects deeply nested app components.
-- The fallback only works for classes that extend the Base UI's `Component`. A class built on `Component` from `@odoo/owl` directly does not get it.
+- Entries in your own `static components` still take precedence over a Nodex UI component with the same name.
+- Listing Nodex UI classes in `static components` is still allowed and is the clearest choice for shared or library code. The fallback mainly protects deeply nested app components.
+- The fallback only works for classes that extend Nodex UI's `Component`. A class built on `Component` from `@odoo/owl` directly does not get it.
 
 ```js
-import { Component, mount, xml } from "@base/owl";
+import { Component, mount, xml } from "nodexui";
 
 class SaveRow extends Component {
-  // No static components — <Button/> and <Icon/> resolve from the BaseUI registry.
+  // No static components — <Button/> and <Icon/> resolve from the NodexUI registry.
   static template = xml`<div><Icon name="'save'"/><Button label="'Save'"/></div>`;
 }
 
@@ -118,11 +116,11 @@ class Root extends Component {
 }
 ```
 
-See each component's page under [`docs/components/`](components/) for its specific props table and an Owl usage example alongside the static `b-ui` one.
+See each component's page under [`docs/components/`](components/) for its specific props table and a Nodex usage example alongside the static `b-ui` one.
 
 ## Common mistakes
 
 - **Rendering a bare `<Button/>` with no template loaded.** `mount(Root, target)` without `{ templates }` (or `app.addTemplates(...)`) throws — the `.xml` file is a real build/runtime input, not documentation.
-- **Registering `Button` under the wrong tag name.** `static components = { Button }` must match the tag used in the template (`<Button/>`), same as any other Owl component. If you alias a Base UI class under a different tag (`{ PrimaryButton: Button }`), the alias exists only in that component's map.
-- **Importing from `@odoo/owl`.** Always import from `@base/owl` instead, even in your own app code — it keeps your app on the exact Owl version this Base UI release was tested against, and only `@base/owl`'s `Component` provides the [global component fallback](#global-component-fallback).
-- **Adding a `baseui.owl.min.js`/`baseui.owl.esm.js`/`baseui.components.esm.js` script or import-map entry.** None of those files are published anymore — point `@base/owl`/`@base/component`/`@base/theme` all at `dist/baseui.esm.js` instead.
+- **Registering `Button` under the wrong tag name.** `static components = { Button }` must match the tag used in the template (`<Button/>`), same as any other Nodex component. If you alias a Nodex UI class under a different tag (`{ PrimaryButton: Button }`), the alias exists only in that component's map.
+- **Importing from `@odoo/owl`.** Always import from `nodexui` instead, even in your own app code — it keeps your app on the exact Nodex version this Nodex UI release was tested against, and only `nodexui`'s `Component` provides the [global component fallback](#global-component-fallback).
+- **Adding a `nodexui.owl.min.js`/`nodexui.owl.esm.js`/`nodexui.components.esm.js` script or import-map entry.** None of those files are published anymore — point `nodexui`/`nodexui`/`nodexui` all at `dist/nodexui.esm.js` instead.

package/docs/registry.md

@@ -1,36 +1,36 @@
 # Registry
 
-Every release publishes `dist/baseui.registry.json`. The registry lists package metadata, CDN paths, build files, themes, and per-component metadata (type, dependencies, `b-*` attributes, events, and — since the Phase 8 pure Base rollout — Owl component/template metadata). It only registers components under `src/components/`; example blocks under `examples/blocks/` are not part of the registry.
+Every release publishes `dist/nodexui.registry.json`. The registry lists package metadata, CDN paths, build files, themes, and per-component metadata (type, dependencies, `b-*` attributes, events, and — since the Phase 8 pure Base rollout — Nodex component/template metadata). It only registers components under `src/components/`; example blocks under `examples/blocks/` are not part of the registry.
 
-The Base UI ships as bundled files only — there is no per-component source distribution. Use the registry's `components` entries to look up a component's contract, not to locate individual source files.
+Nodex UI ships as bundled files only — there is no per-component source distribution. Use the registry's `components` entries to look up a component's contract, not to locate individual source files.
 
 ## Build files
 
 `buildFiles` lists every top-level `dist/` artifact the release validates and hashes:
 
-- `baseui.min.css` — Bootstrap 5 + the Base UI styles (static and pure Base APIs share the same stylesheet).
-- `baseui.min.js` / `baseui.esm.js` — the one bundle for both APIs: the static `b-ui` runtime (`BaseUI.register(...)`, `thebase.mountAll()`), the Owl framework (`Component`, `mount`, `xml`, ...), every Base component class (`Button`, `Card`, `Tabs`, ...), and the theme helper (`createThemeController`, `BaseUITheme`). Bootstrap's JS bundle and Owl's global build are embedded ahead of the Base UI's own code, in that load order — no separate `baseui.owl.*`/`baseui.components.esm.js`/`baseui.theme.esm.js`/`bootstrap.bundle.min.js` script is needed.
-- `bootstrap.bundle.min.js` — vendored Bootstrap JS, standalone, unmodified. Ships in case a project wants it on its own; the Base UI's own bundle never needs it loaded separately (it's embedded in `baseui.min.js`/`baseui.esm.js` too).
-- `baseui.icons.esm.js` — the 2000+ generated `Icon<Name>` components (`IconEye`, `IconSearch`, ...), split out because they'd blow the main bundle's size budget. The one deliberate exception to "everything is one bundle".
-- `baseui.templates.xml` — every Base component's compiled `<templates>` body, concatenated into one file. Load this into the Owl `App`'s `templates` config before mounting; `.xml` files under `src/components/` are authoring sources, not something a consumer app loads directly.
-- `baseui.analytics.esm.js` / `baseui.analytics.min.js` — the optional, standalone cookieless analytics service (`@thebase/ui/analytics`). Not part of the main bundles and needs no other Base UI file; see [Analytics](analytics.md).
-- `baseui.i18n.esm.js` / `baseui.i18n.min.js` — the optional, standalone gettext-style i18n service (`@thebase/ui/i18n`). Not part of the main bundles and needs no other Base UI file; see [i18n](i18n.md).
+- `nodexui.min.css` — Nodex UI styles (static and pure Base APIs share the same stylesheet).
+- `nodexui.min.js` / `nodexui.esm.js` — the one bundle for both APIs: the static `b-ui` runtime (`NodexUI.register(...)`, `thebase.mountAll()`), the Nodex runtime (`Component`, `mount`, `xml`, ...), every Base component class (`Button`, `Card`, `Tabs`, ...), and the theme helper (`createThemeController`, `NodexUITheme`). The JS bundle and Nodex's global build are embedded ahead of Nodex UI's own code, in that load order — no separate `nodexui.owl.*`/`nodexui.components.esm.js`/`nodexui.theme.esm.js`/`bootstrap.bundle.min.js` script is needed.
+- `bootstrap.bundle.min.js` — vendored built-in JS, standalone, unmodified. Ships in case a project wants it on its own; Nodex UI's own bundle never needs it loaded separately (it's embedded in `nodexui.min.js`/`nodexui.esm.js` too).
+- `nodexui.icons.esm.js` — the 2000+ generated `Icon<Name>` components (`IconEye`, `IconSearch`, ...), split out because they'd blow the main bundle's size budget. The one deliberate exception to "everything is one bundle".
+- `nodexui.templates.xml` — every Base component's compiled `<templates>` body, concatenated into one file. Load this into the Nodex `App`'s `templates` config before mounting; `.xml` files under `src/components/` are authoring sources, not something a consumer app loads directly.
+- `nodexui.analytics.esm.js` / `nodexui.analytics.min.js` — the optional, standalone cookieless analytics service (`nodexui/analytics`). Not part of the main bundles and needs no other Nodex UI file; see [Analytics](analytics.md).
+- `nodexui.i18n.esm.js` / `nodexui.i18n.min.js` — the optional, standalone gettext-style i18n service (`nodexui/i18n`). Not part of the main bundles and needs no other Nodex UI file; see [i18n](i18n.md).
 - `icons/lucide.json` — the built-in icon manifest.
 
 ## Component export policy
 
 Every component folder under `src/components/<name>/` is one of:
 
-1. **Both APIs** — has `<name>.js` (static `BaseUI.register(...)` adapter) *and* `<name>.component.js` (pure Base `Component` class(es)). As of the Phase 8 rollout this is **all 74** registry components; there are no static-only exceptions left. A handful of components (`chart`, most notably) have lighter-fidelity pure Base treatments than their static adapter — see their component doc page for the documented gap — but every registry component has a real Owl export.
+1. **Both APIs** — has `<name>.js` (static `NodexUI.register(...)` adapter) *and* `<name>.component.js` (pure Base `Component` class(es)). As of the Phase 8 rollout this is **all 74** registry components; there are no static-only exceptions left. A handful of components (`chart`, most notably) have lighter-fidelity pure Base treatments than their static adapter — see their component doc page for the documented gap — but every registry component has a real Nodex export.
 2. Static-only components would report `"type": "static"` with no `owlComponents` field, but none currently exist in this registry.
 
 Per-component registry entries now include:
 
-- `owlComponents` — the exact list of exported Owl class names from `<name>.component.js`, e.g. `["Dialog", "DialogTrigger", "DialogContent", ...]` for compound components. Import these from `@thebase/ui`.
-- `templateName` — the namespaced template name the component's *root* class renders, e.g. `"baseui.Dialog"`. Every template also registers a short un-namespaced alias (e.g. `Dialog`) via `t-call` for local convenience; `templateName` documents the namespaced form because that's the collision-safe one to rely on across a large template set.
+- `owlComponents` — the exact list of exported Nodex class names from `<name>.component.js`, e.g. `["Dialog", "DialogTrigger", "DialogContent", ...]` for compound components. Import these from `nodexui`.
+- `templateName` — the namespaced template name the component's *root* class renders, e.g. `"nodexui.Dialog"`. Every template also registers a short un-namespaced alias (e.g. `Dialog`) via `t-call` for local convenience; `templateName` documents the namespaced form because that's the collision-safe one to rely on across a large template set.
 
-Existing fields (`type`, `dependencies`, `attributes`, `events`) are unchanged and describe the static `b-ui` contract; they apply regardless of whether an Owl export also exists.
+Existing fields (`type`, `dependencies`, `attributes`, `events`) are unchanged and describe the static `b-ui` contract; they apply regardless of whether a Nodex export also exists.
 
 ## Validation
 
-The build validates every registry path against `dist/` and adds SHA-384 integrity hashes for build files and themes. Example blocks (composed static HTML demos styled by `baseui.min.css`) live under `examples/blocks/` with per-block CSS split from `examples/blocks/shared.css`, but are not registry or JavaScript components.
+The build validates every registry path against `dist/` and adds SHA-384 integrity hashes for build files and themes. Example blocks (composed static HTML demos styled by `nodexui.min.css`) live under `examples/blocks/` with per-block CSS split from `examples/blocks/shared.css`, but are not registry or JavaScript components.

package/docs/runtime-api.md

@@ -1,6 +1,6 @@
 # Runtime API
 
-The Base UI exposes one browser global: `window.thebase`. `window.BaseUI` still points to the same object as a deprecated alias for 1.x pages; it will be removed in 2.0.0.
+Nodex UI exposes one browser global: `window.thebase`. `window.NodexUI` still points to the same object as a deprecated alias for 1.x pages; it will be removed in 2.0.0.
 
 ```js
 thebase.version
@@ -18,43 +18,43 @@ thebase.i18n.init({ languages, defaultLanguage })
 thebase.i18n.t(text, params)
 ```
 
-`thebase.analytics` is set only when the optional `dist/baseui.analytics.min.js` is loaded (it is not in the main bundles), and `thebase.track` is bound once it is initialized — see [Analytics](analytics.md). Likewise `thebase.i18n` is set only when the optional `dist/baseui.i18n.min.js` is loaded — see [i18n](i18n.md).
+`thebase.analytics` is set only when the optional `dist/nodexui.analytics.min.js` is loaded (it is not in the main bundles), and `thebase.track` is bound once it is initialized — see [Analytics](analytics.md). Likewise `thebase.i18n` is set only when the optional `dist/nodexui.i18n.min.js` is loaded — see [i18n](i18n.md).
 
-The static runtime calls `autoMount()` when imported through `dist/baseui.esm.js` or `dist/baseui.min.js`. Existing `[b-ui]` and `[b-icon]` markers are enhanced automatically once the DOM is ready.
+The static runtime calls `autoMount()` when imported through `dist/nodexui.esm.js` or `dist/nodexui.min.js`. Existing `[b-ui]` and `[b-icon]` markers are enhanced automatically once the DOM is ready.
 
-`mountAll(rootElement)` scans `[b-ui]` and `[b-icon]` below the given root. Repeated calls are idempotent for already-mounted nodes, so it is safe to call after rendering an AJAX partial or replacing a small subtree. `mount(selectorOrElement, options)` mounts one element and returns its instance metadata when a registered component exists. `destroy(rootElement)` calls component cleanup handlers and dispatches `baseui:destroyed` before a mounted subtree is removed.
+`mountAll(rootElement)` scans `[b-ui]` and `[b-icon]` below the given root. Repeated calls are idempotent for already-mounted nodes, so it is safe to call after rendering an AJAX partial or replacing a small subtree. `mount(selectorOrElement, options)` mounts one element and returns its instance metadata when a registered component exists. `destroy(rootElement)` calls component cleanup handlers and dispatches `nodexui:destroyed` before a mounted subtree is removed.
 
 Mounted components dispatch lifecycle events on their root element:
 
-- `baseui:mounted` with `{ name, instance }` in `event.detail`.
-- `baseui:destroyed` with `{ name }` in `event.detail`.
+- `nodexui:mounted` with `{ name, instance }` in `event.detail`.
+- `nodexui:destroyed` with `{ name }` in `event.detail`.
 
-`thebase.theme.set(...)` is the low-level setter. For persisted light/dark toggles, button-label synchronization, URL `?theme=` overrides, and iframe preview sync, import `createThemeController` from `@base/theme` in browser import maps or `@thebase/ui` in npm/bundler apps.
+`thebase.theme.set(...)` is the low-level setter. For persisted light/dark toggles, button-label synchronization, URL `?theme=` overrides, and iframe preview sync, import `createThemeController` from `nodexui` in browser import maps or `nodexui` in npm/bundler apps.
 
-`thebase.mountAll()` is for static `b-ui`/`b-att-*` markers and `b-icon` markers only. It does not register Owl component tags (`<Button/>`, `<Card/>`, ...) and does not know about `@thebase/ui` or `dist/baseui.templates.xml`. To use Base components, extend `Component` from `@base/owl`, fetch the templates XML, and pass it to `mount()`. Registered the Base UI components then resolve in every template, whether or not they are listed in `static components`; see [Base Components](owl-components.md#global-component-fallback).
+`thebase.mountAll()` is for static `b-ui`/`b-att-*` markers and `b-icon` markers only. It does not register Nodex component tags (`<Button/>`, `<Card/>`, ...) and does not know about `nodexui` or `dist/nodexui.templates.xml`. To use Base components, extend `Component` from `nodexui`, fetch the templates XML, and pass it to `mount()`. Registered Nodex UI components then resolve in every template, whether or not they are listed in `static components`; see [Nodex UI Component](owl-components.md#global-component-fallback).
 
 ## `cn()` class-name helper
 
 `cn(...classNames)` joins strings, arrays, and falsy values into one space-separated class string, flattening nested arrays and skipping anything falsy:
 
 ```js
-import { cn } from "@thebase/ui";
+import { cn } from "nodexui";
 
 cn("btn", isActive && "active", ["b-button", className]);
 // "btn active b-button my-class" (when isActive is truthy and className is "my-class")
 ```
 
-It's a standalone named export — `import { cn } from "@thebase/ui"` in npm/bundler apps, or `BaseUIBundle.cn` in the browser IIFE global — not a method on `BaseUI` itself. Use it to build your own components' class lists on top of the Base UI's conventions.
+It's a standalone named export — `import { cn } from "nodexui"` in npm/bundler apps, or `NodexUIBundle.cn` in the browser IIFE global — not a method on `NodexUI` itself. Use it to build your own components' class lists on top of Nodex UI's conventions.
 
 ## `mergeStyle()` inline-style helper
 
 `mergeStyle(...styles)` combines a component's own computed inline style with a caller-supplied `style` (string or object) into one `;`-joined declaration string, dropping empty/nullish entries. Object keys may be camelCase (converted to kebab-case); later entries win on conflicting properties since they're appended last:
 
 ```js
-import { mergeStyle } from "@thebase/ui";
+import { mergeStyle } from "nodexui";
 
 mergeStyle("--b-progress-value:50%", { color: "red" }, "opacity:0.5;");
 // "--b-progress-value:50%;color:red;opacity:0.5"
 ```
 
-It's a standalone named export — `import { mergeStyle } from "@thebase/ui"` in npm/bundler apps, or `BaseUIBundle.mergeStyle` in the browser IIFE global. Unlike `cn()`, which joins class names with a space, `mergeStyle()` joins CSS declarations with `;` — the two are not interchangeable.
+It's a standalone named export — `import { mergeStyle } from "nodexui"` in npm/bundler apps, or `NodexUIBundle.mergeStyle` in the browser IIFE global. Unlike `cn()`, which joins class names with a space, `mergeStyle()` joins CSS declarations with `;` — the two are not interchangeable.

package/docs/theming.md

@@ -15,16 +15,16 @@ thebase.theme.set({ primary: "#0057d8", radius: "0.5rem" });
 
 ## Make your own theme
 
-`dist/baseui.min.css` is the only stylesheet an app loads; it already includes the default light and dark themes. A custom theme is two small files, `baseui-light.css` and `baseui-dark.css` (readable copies in `dist/themes/`, minified `.min.css` versions beside them), loaded after it.
+`dist/nodexui.min.css` is the only stylesheet an app loads; it already includes the default light and dark themes. A custom theme is two small files, `nodexui-light.css` and `nodexui-dark.css` (readable copies in `dist/themes/`, minified `.min.css` versions beside them), loaded after it.
 
-1. Build one visually in the **theme creator** (the **Theme** tab of the examples app (`examples/index.html#/theme`)): pick a base colour, accent and radius, preview Base UI live in light or dark, then download `baseui-light.css` and `baseui-dark.css`.
+1. Build one visually in the **theme creator** (the **Theme** tab of the examples app (`examples/index.html#/theme`)): pick a base colour, accent and radius, preview Nodex UI live in light or dark, then download `nodexui-light.css` and `nodexui-dark.css`.
 2. Or download the two files from `dist/themes/` (or copy `src/themes/`) and edit the values by hand.
-3. Load them after the Base UI stylesheet:
+3. Load them after Nodex UI stylesheet:
 
 ```html
-<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/@thebase/ui@1.2.1/dist/baseui.min.css">
-<link rel="stylesheet" href="/css/baseui-light.css">
-<link rel="stylesheet" href="/css/baseui-dark.css">
+<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/nodexui@1.3.0/dist/nodexui.min.css">
+<link rel="stylesheet" href="/css/nodexui-light.css">
+<link rel="stylesheet" href="/css/nodexui-dark.css">
 ```
 
 Each file declares the same variables on its own selector (`light`: `:root`, `[b-theme="light"]`, `.light`; `dark`: `[b-theme="dark"]`, `.dark`), so loading yours after the defaults replaces them. Edit only the values; keep the selectors and variable names. The tokens you will usually change:
@@ -35,7 +35,7 @@ Each file declares the same variables on its own selector (`light`: `:root`, `[b
 | `--b-surface`, `--b-card`, `--b-popover` (+ `-foreground`) | Raised surfaces |
 | `--b-primary`, `--b-primary-rgb`, `--b-primary-foreground` | Primary buttons, links, active states (keep `-rgb` in sync with the colour) |
 | `--b-secondary`, `--b-muted`, `--b-accent` (+ `-foreground`) | Subtle fills and hover states |
-| `--b-danger`, `--b-success`, `--b-warning`, `--b-info` (each with `-rgb` and `-foreground`) | Error/destructive, success, warning and info states: buttons (`.btn-success` …), badges, alerts, Bootstrap `text-*`/`bg-*` helpers |
+| `--b-danger`, `--b-success`, `--b-warning`, `--b-info` (each with `-rgb` and `-foreground`) | Error/destructive, success, warning and info states: buttons (`.btn-success` …), badges, alerts, built-in `text-*`/`bg-*` helpers |
 | `--b-border`, `--b-input`, `--b-ring` | Borders, field outlines, focus ring |
 | `--b-chart-1` … `--b-chart-5`, `--b-sidebar-*` | Charts and the sidebar |
 | `--base-radius` | Corner roundness; every `--b-radius-*` step is derived from it |
@@ -43,7 +43,7 @@ Each file declares the same variables on its own selector (`light`: `:root`, `[b
 
 To change a few values without a full theme, override them on `:root` / `[b-theme="dark"]` in your own CSS, or at runtime with `thebase.theme.set({ primary: "#0057d8", radius: "0.5rem" })`.
 
-The Base UI maps semantic tokens such as `--b-background`, `--b-primary`, `--b-border`, and `--b-radius` into Bootstrap 5 variables. Radius tokens are sourced from the shorter public alias family `--base-radius`, `--base-radius-sm`, `--base-radius-md`, `--base-radius-lg`, `--base-radius-xl`, `--base-radius-2xl`, `--base-radius-3xl`, `--base-radius-4xl`, and `--base-radius-full`, then mirrored to `--b-radius*` for component CSS.
+Nodex UI maps semantic tokens such as `--b-background`, `--b-primary`, `--b-border`, and `--b-radius` into built-in variables. Radius tokens are sourced from the shorter public alias family `--base-radius`, `--base-radius-sm`, `--base-radius-md`, `--base-radius-lg`, `--base-radius-xl`, `--base-radius-2xl`, `--base-radius-3xl`, `--base-radius-4xl`, and `--base-radius-full`, then mirrored to `--b-radius*` for component CSS.
 
 For a reusable theme toggle with persistence, URL override, button-label sync, and iframe preview sync, import the theme helper:
 
@@ -51,12 +51,12 @@ For a reusable theme toggle with persistence, URL override, button-label sync, a
 <script type="importmap">
 {
   "imports": {
-    "@base/theme": "https://cdn.jsdelivr.net/npm/@thebase/ui@latest/dist/baseui.esm.js"
+    "nodexui": "https://cdn.jsdelivr.net/npm/nodexui@latest/dist/nodexui.esm.js"
   }
 }
 </script>
 <script type="module">
-  import { createThemeController } from "@base/theme";
+  import { createThemeController } from "nodexui";
 
   const theme = createThemeController({
     storageKey: "my-app-theme",
@@ -68,18 +68,18 @@ For a reusable theme toggle with persistence, URL override, button-label sync, a
 </script>
 ```
 
-`https://unpkg.com/@thebase/ui@latest/dist/baseui.esm.js` mirrors the same file as an alternative CDN if jsDelivr is unreachable. Pin an exact version (e.g. `@1.2.1`, or `@1` to take only non-breaking updates) instead of `@latest` for production. Npm/bundler consumers can import the same API from `@thebase/ui`.
+`https://unpkg.com/nodexui@latest/dist/nodexui.esm.js` mirrors the same file as an alternative CDN if jsDelivr is unreachable. Pin an exact version (e.g. `@1.3.0`, or `@1` to take only non-breaking updates) instead of `@latest` for production. Npm/bundler consumers can import the same API from `nodexui`.
 
-For a ready-made icon button, use the Base UI component instead of wiring your own click handler:
+For a ready-made icon button, use Nodex UI component instead of wiring your own click handler:
 
 ```html
 <button b-ui="theme-button" b-att-variant="outline" b-att-storage-key="my-app-theme" type="button"></button>
 ```
 
-The documentation and example pages use the same theme infrastructure. Owl example modules import `createThemeController` from `@base/theme`; static chrome relies on `b-ui="theme-button"`, which uses the helper internally, so one selected theme is persisted across components, docs, chart galleries, block viewers, and same-origin block preview iframes. Theme changes dispatch `baseui:theme-change` on `document` with `{ theme }` in `event.detail`.
+The documentation and example pages use the same theme infrastructure. Nodex example modules import `createThemeController` from `nodexui`; static chrome relies on `b-ui="theme-button"`, which uses the helper internally, so one selected theme is persisted across components, docs, chart galleries, block viewers, and same-origin block preview iframes. Theme changes dispatch `nodexui:theme-change` on `document` with `{ theme }` in `event.detail`.
 
 ## Design tokens
 
-The default light/dark palettes and radius follow the current [shadcn/ui](https://ui.shadcn.com) Base UI neutral theme: black/neutral primary on white in light mode, neutral-900/50 foreground-background inversion in dark mode, neutral `--b-secondary`/`--b-muted`/`--b-accent` surfaces, `--base-radius: var(--radius, 0.625rem)` (set in the theme files), and a derived radius scale (`--base-radius-sm|md|lg|xl`, mirrored as `--b-radius-sm|md|lg|xl`) and shadow scale (`--b-shadow-sm|md|lg`) for consistent elevation across popovers, menus, dialogs, and toasts. The Base UI reads an existing upstream `--radius` value when present, but it does not redefine `--radius` back to `--b-radius`; that one-way bridge avoids CSS custom-property cycles. `--b-card`/`--b-popover` alias `--b-surface` for shadcn-token-name parity.
+The default light/dark palettes and radius follow the current [shadcn/ui](https://ui.shadcn.com) Nodex UI neutral theme: black/neutral primary on white in light mode, neutral-900/50 foreground-background inversion in dark mode, neutral `--b-secondary`/`--b-muted`/`--b-accent` surfaces, `--base-radius: var(--radius, 0.625rem)` (set in the theme files), and a derived radius scale (`--base-radius-sm|md|lg|xl`, mirrored as `--b-radius-sm|md|lg|xl`) and shadow scale (`--b-shadow-sm|md|lg`) for consistent elevation across popovers, menus, dialogs, and toasts. Nodex UI reads an existing upstream `--radius` value when present, but it does not redefine `--radius` back to `--b-radius`; that one-way bridge avoids CSS custom-property cycles. `--b-card`/`--b-popover` alias `--b-surface` for shadcn-token-name parity.
 
-Because the Base UI ships Bootstrap's stock precompiled CSS, most `.btn-*`/badge colors are not driven by `--bs-*` variables directly — `src/styles/base-extensions.css` re-points the `.btn-primary`/`.btn-secondary`/`.btn-danger`/`.btn-outline-secondary`/`.btn-light` variants at the Base UI tokens so `thebase.theme.set(...)` overrides actually render. Badges use their own `b-badge-*` classes (`src/components/badge/badge.css`) instead of Bootstrap's `text-bg-*`, which hardcode non-overridable colors.
+Because Nodex UI ships the built-in stock precompiled CSS, most `.btn-*`/badge colors are not driven by `--bs-*` variables directly — `src/styles/base-extensions.css` re-points the `.btn-primary`/`.btn-secondary`/`.btn-danger`/`.btn-outline-secondary`/`.btn-light` variants at Nodex UI tokens so `thebase.theme.set(...)` overrides actually render. Badges use their own `b-badge-*` classes (`src/components/badge/badge.css`) instead of the built-in `text-bg-*`, which hardcode non-overridable colors.