@@ -4,7 +4,7 @@
 
 **`devframe`** is the framework-neutral container for one devtool integration, portable across hub UI providers. Build a single tool (its RPC, its SPA, its diagnostics, its CLI/build/embedded outputs) without caring how it'll be displayed. A devframe runs standalone (CLI, static deploy, embedded SPA) just as well as it mounts inside a hub.
 
-**`@devframes/hub`** is the framework-neutral hub layer that sits on top of devframe and provides the multi-devframe orchestration (docks, terminals, messages, commands). It does not ship UI - hub UI providers (e.g. `@vitejs/devtools-kit`) provide their own UI on top of the hub's RPC + shared-state protocol. It does ship a **headless client runtime** (`createDevframeClientHost()` from `@devframes/hub/client`): booted in the host page, it assembles the shared `DevframeClientContext` (panel, docks, commands, when) and imports each dock entry's client script (`action` / `custom-render` / iframe `clientScript`) into that page - how a built-in devframe like the a11y inspector runs its page script inside the user app's page. See `examples/hub-vite/` for a working ~120-line Vite host demonstrating the protocol end to end.
+**`@devframes/hub`** is the framework-neutral hub layer that sits on top of devframe and provides the multi-devframe orchestration (docks, terminals, messages, commands). It does not ship UI - hub UI providers (e.g. `@vitejs/devtools-kit`) provide their own UI on top of the hub's RPC + shared-state protocol. It does ship a **headless client runtime** (`createDevframeClientRuntime()` from `@devframes/hub/client`): booted in the host page, it assembles the shared `DevframeClientContext` (panel, docks, commands, when) and imports each dock entry's client script (`action` / `custom-render` / iframe `clientScript`) into that page - how a built-in devframe like the a11y inspector runs its page script inside the user app's page. See `examples/hub-vite/` for a working ~120-line Vite host demonstrating the protocol end to end.
 
 ## Terminology
 
@@ -14,7 +14,7 @@ The docs' canonical vocabulary lives in [`docs/content/1.guide/1.terms.md`](docs
 - **The tool is "a devframe"** - never "integration", "frame", or "app". The ready-to-run `@devframes/plugin-*` packages are **built-in devframes**: Devframe has no plugin concept; the `plugin-` npm prefix only sets those packages apart from core packages. "Vite plugin" stays for the bundler mechanism, and RPC ids keep the literal `devframes:plugin:<slug>:` namespace because it mirrors the package names on the wire.
 - **host framework** is the environment a devframe or hub mounts into (a Vite dev server, a Next.js app, a Hono server); named forms like "the Vite host" are fine. **host page** is the browser document where the client runtime boots; **user app** is the application being developed and inspected.
 - A devframe's two halves are the **node side** and the **browser side**.
-- Browser-side terms: **client runtime** (`createDevframeClientHost()`), **client context**, **client script**, **page script** (a devframe's script in the user app's page - never "agent"; **coding agent** is the only agent), **RPC client** (`connectDevframe()`), **SPA**, **panel** (a devframe's SPA as a rendered surface), **surface** (any rendered browser view - say "API", not "API surface").
+- Browser-side terms: **client runtime** (`createDevframeClientRuntime()`), **client context**, **client script**, **page script** (a devframe's script in the user app's page - never "agent"; **coding agent** is the only agent), **RPC client** (`connectDevframe()`), **SPA**, **panel** (a devframe's SPA as a rendered surface), **surface** (any rendered browser view - say "API", not "API surface").
 - Hub terms: **hub UI provider** (a hub UI implementation - never "shell" or bare "viewer"; "external viewer" stays for cross-origin surfaces in the security docs), **dock entry** / **dock rail** / **dock panel**, **mounted devframe** (never "frame").
 - The three communication paths: **RPC** (browser side ↔ node side), the **client context** (client scripts ↔ client runtime), and the **in-page channel** (page script ↔ panel, same-origin in-browser).
 - Storage scopes: **workspace scope** (committable, per-repo), **project scope** (per-checkout), **global scope** (per-user) - never describe the project scope as "per-workspace".
@@ -70,7 +70,7 @@ Ahead-of-time build artifacts that live under `src/` - the shadow-root styleshee
 The framework kits - `@devframes/vite`, `@devframes/nuxt`, `@devframes/next` - each split their surface into **two clearly-scoped subpaths**, because a consumer is always doing one of two distinct jobs. Keep all three parallel:
 
 - **`.../single`** - **build & dev-serve a single devframe's SPA** with that tool (the "I'm authoring one devframe" scope). Vite: the `devframeVitePlugin` / `devframeViteBridge` / `devframeVite` plugins. Next: `withDevframe` + `createDevframeNextHandler`, with its React client at `.../single/client`. Nuxt: the Nuxt module (registered as `modules: ['@devframes/nuxt/single']`).
-- **`.../hub`** - **mount a whole `@devframes/hub` (many devframes) inside that tool** (the "I'm standing up devtools" scope). Wraps `initHub`, defaults the UI slot to `@devframes/hub-ui`'s `createUi()` (overridable via `ui`, or `ui: false` for headless), and ships a browser client helper at `.../hub/client` (a thin, lifecycle-managing wrapper over `@devframes/hub/client`'s `createDevframeClientHost`). `@devframes/hub` and `@devframes/hub-ui` are **optional peers** of these packages; `hub-ui` is loaded lazily (a bundler-ignored dynamic `import()` in the Next hub) so it stays optional and its `import.meta.url` asset lookups resolve at request time.
+- **`.../hub`** - **mount a whole `@devframes/hub` (many devframes) inside that tool** (the "I'm standing up devtools" scope). Wraps `initHub`, defaults the UI slot to `@devframes/hub-ui`'s `createUi()` (overridable via `ui`, or `ui: false` for headless), and ships a browser client helper at `.../hub/client` (a thin, lifecycle-managing wrapper over `@devframes/hub/client`'s `createDevframeClientRuntime`). `@devframes/hub` and `@devframes/hub-ui` are **optional peers** of these packages; `hub-ui` is loaded lazily (a bundler-ignored dynamic `import()` in the Next hub) so it stays optional and its `import.meta.url` asset lookups resolve at request time.
 - **The bare root (`.`) throws** a helpful error pointing at the two subpaths - never put real code on it.
 - **Vite and Nuxt already have native hub UI providers** (`@vitejs/devtools-kit`, `@nuxt/devtools`), so `@devframes/vite/hub` and `@devframes/nuxt/hub` still work but emit a one-time `console.warn` recommending those (silence with `{ quiet: true }`). `@devframes/next/hub` has no native counterpart, so it warns nothing.
 - The **full hub examples** (`examples/hub-vite`, `examples/hub-next`) consume `.../hub` on the node side but keep hand-rolling their own hub UI provider against `@devframes/hub/client` with `ui: false` - that hand-rolled hub UI provider is the whole point of those reference hosts. The **minimal** ones (`examples/hub-*-minimal`) consume `.../hub` with the default `@devframes/hub-ui` and inject its `embedded.js`, needing no browser-side code.
 
@@ -41,7 +41,7 @@ A devframe has two halves: the **node side** registers RPC functions and owns st
 | **browser side** | The half of a devframe running in a page. | `devframe/client` |
 | **user app** | The application being developed and inspected. | — |
 | **host page** | The browser document where the client runtime boots — in dev, usually the user app's own page. | — |
-| **client runtime** | The headless runtime booted once per host page: it connects RPC, assembles the client context, and imports client scripts. | `createDevframeClientHost()` |
+| **client runtime** | The headless runtime booted once per host page: it connects RPC, assembles the client context, and imports client scripts. | `createDevframeClientRuntime()` |
 | **client context** | The shared object client scripts receive: panel, docks, commands, when-clauses. | `DevframeClientContext` |
 | **client script** | A dock entry's script, imported into the host page by the client runtime. | `clientScript` |
 | **page script** | A devframe's script running in the user app's page — loaded as a client script or standalone. The a11y page script runs axe-core. | — |
 
@@ -254,7 +254,7 @@ Broadcast notifications (`devframe:docks:activate`, `devframe:terminals:updated`
 
 ## Running a devframe's code in the host page
 
-The hub ships a headless client runtime, `createDevframeClientHost()` (`@devframes/hub/client`): booted in the host page, it assembles the client context and imports each dock entry's client script ([Client Scripts & Client Context](/guide/client-context)).
+The hub ships a headless client runtime, `createDevframeClientRuntime()` (`@devframes/hub/client`): booted in the host page, it assembles the client context and imports each dock entry's client script ([Client Scripts & Client Context](/guide/client-context)).
 
 ## Example
 
 
@@ -10,14 +10,14 @@ A dock **client script** runs a devframe's code inside the **host page**; the **
 
 ## The client runtime
 
-`createDevframeClientHost()` (`@devframes/hub/client`) boots the host page: it connects (or adopts) an RPC client, publishes the `DevframeClientContext`, and imports each dock's client script:
+`createDevframeClientRuntime()` (`@devframes/hub/client`) boots the host page: it connects (or adopts) an RPC client, publishes the `DevframeClientContext`, and imports each dock's client script:
 
 ```ts
 // main.ts — the host page's browser entry
-import { connectDevframe, createDevframeClientHost } from '@devframes/hub/client'
+import { connectDevframe, createDevframeClientRuntime } from '@devframes/hub/client'
 
 const rpc = await connectDevframe({ baseURL: '/__hub/' })
-const { context, dispose } = await createDevframeClientHost({ rpc })
+const { context, dispose } = await createDevframeClientRuntime({ rpc })
 ```
 
 ### Options
@@ -83,7 +83,7 @@ For a URL, attach it via `ctx.install(myDevframe, { dock: { clientScript: { impo
 
 ### Bare npm specifiers
 
-Resolving a bare specifier is the **host framework's capability**: a host framework advertises a resolution template at `ConnectionMeta.configs.dock.clientModuleResolution` (loaders replace `{specifier}` before import). A Vite host declares this by default (`@devframes/vite/hub`) as `initHub({ clientModuleResolution: '/@id/{specifier}' })`; then use the specifier alone as `importFrom`. A host framework with no template (Next.js) supports the URL shape only, warning [`DF8111`](/errors/DF8111) on a specifier. A hub UI provider can override with `createDevframeClientHost({ resolveClientModule })`.
+Resolving a bare specifier is the **host framework's capability**: a host framework advertises a resolution template at `ConnectionMeta.configs.dock.clientModuleResolution` (loaders replace `{specifier}` before import). A Vite host declares this by default (`@devframes/vite/hub`) as `initHub({ clientModuleResolution: '/@id/{specifier}' })`; then use the specifier alone as `importFrom`. A host framework with no template (Next.js) supports the URL shape only, warning [`DF8111`](/errors/DF8111) on a specifier. A hub UI provider can override with `createDevframeClientRuntime({ resolveClientModule })`.
 
 Client scripts execute in the user app's page realm (`window`); anchor shared state on `globalThis`.
 
 
@@ -80,7 +80,7 @@ initHub({
 })
 ```
 
-A renderer registered at boot (`createDevframeClientHost({ renderers })`) overrides the manifest; an uncovered type shows the hub UI provider's missing-renderer fallback.
+A renderer registered at boot (`createDevframeClientRuntime({ renderers })`) overrides the manifest; an uncovered type shows the hub UI provider's missing-renderer fallback.
 
 Registrations are validated fail-fast: one module per type (`DF8108`), an existing bundle (`DF8109`), a route-safe type name (`DF8110`).
 
 
@@ -46,7 +46,7 @@ disabling action dispatch there.
 ## Plugging it in
 
 - **Local registration** — a hub UI provider bundling its own client runtime passes
-  `createDevframeClientHost({ renderers: { 'json-render': myRenderer } })`;
+  `createDevframeClientRuntime({ renderers: { 'json-render': myRenderer } })`;
   local registrations win over the manifest.
 - **A prebuilt renderer module** — bundle your renderer as one self-contained
   browser ES module (framework and styles included), default-exporting the
 
@@ -28,7 +28,7 @@ into `ConnectionMeta.configs` and read by the RPC client at handshake.
 ## The browser-side contracts
 
 A hub UI provider renders from the hub's shared state via
-[`createDevframeClientHost()`](/guide/client-context), which assembles the
+[`createDevframeClientRuntime()`](/guide/client-context), which assembles the
 `DevframeClientContext` (docks, commands, renderers, when-clauses, connection)
 and loads dock client scripts. Honor:
 
 
@@ -141,10 +141,10 @@ missing-renderer fallback). A host page can register a
 
 ```ts
 // host page — a locally-bundled frontend wins over the manifest module
-import { createDevframeClientHost } from '@devframes/hub/client'
+import { createDevframeClientRuntime } from '@devframes/hub/client'
 import { myJsonRenderDockRenderer } from './my-renderer'
 
-const host = await createDevframeClientHost({
+const host = await createDevframeClientRuntime({
   renderers: { 'json-render': myJsonRenderDockRenderer },
 })
 
 
@@ -124,7 +124,7 @@ globalThis.cache = cache
 
 It reads `globalThis` at query time, so later assignments appear next run (opt out: `DEVFRAME_DATA_INSPECTOR_GLOBAL=0`).
 
-The inject endpoint binds `127.0.0.1`, requires the trust handshake with a per-run token, and advertises itself in `node_modules/.data-inspector/agent.json`, which `attach` reads (or pass `ws://…` + `--token`).
+The inject endpoint binds `127.0.0.1`, requires the trust handshake with a per-run token, and advertises itself in `node_modules/.data-inspector/discovery.json`, which `attach` reads (or pass `ws://…` + `--token`).
 
 ## RPC
 
 
@@ -29,13 +29,13 @@ The page script and the panel talk over the in-page channel (a same-origin `Broa
 
 ## In a hub
 
-The page script is the a11y dock's [client script](/guide/client-context): attach `a11yAgentBundlePath` as the dock's `clientScript` and the hub imports it into the page. It also mirrors each scan into the hub's messages feed — a summary plus one per rule:
+The page script is the a11y dock's [client script](/guide/client-context): attach `a11yPageScriptBundlePath` as the dock's `clientScript` and the hub imports it into the page. It also mirrors each scan into the hub's messages feed — a summary plus one per rule:
 
 ```ts
-import createA11yDevframe, { a11yAgentBundlePath } from '@devframes/plugin-a11y'
+import createA11yDevframe, { a11yPageScriptBundlePath } from '@devframes/plugin-a11y'
 
 await ctx.install(createA11yDevframe(), {
-  dock: { clientScript: { importFrom: `/@fs/${a11yAgentBundlePath}` } },
+  dock: { clientScript: { importFrom: `/@fs/${a11yPageScriptBundlePath}` } },
 })
 ```