refactor(examples)!: rename hub examples to the hub-* prefix and add the hub-*-minimal family

The two reference hosts become hub-vite and hub-next; the middleware
demos become hub-nitro-minimal and hub-hono-minimal, joined by new
hub-vite-minimal, hub-next-minimal, and hub-rsbuild-minimal — each a
single initHub({ ui: createUi() }) handler mounted on its framework
(the whole minimal integration is the config/route file). The Nitro one
now uses a catch-all server route (+ index route) per @atinux's review;
the Rsbuild one lazy-inits the hub inside server.setup so importing the
config is side-effect free.

Also: .gitignore now covers .next/.nitro/.output so knip (which respects
gitignore) doesn't scan Next/Nitro build output; playwright/vitest/turbo/
knip/verify-typecheck-coverage/scripts/AGENTS/docs and the sidebar are
repointed at the new names, and docs gain a page per minimal example.

BREAKING CHANGE: example package names changed (vite-devframe-hub ->
hub-vite, next-devframe-hub -> hub-next, nitro/hono-devframe-hub ->
hub-nitro-minimal/hub-hono-minimal).

Author: antfubot

.gitignore

@@ -7,6 +7,9 @@
 *.tsbuildinfo
 coverage
 dist
+.next
+.nitro
+.output
 lib-cov
 logs
 node_modules

AGENTS.md

@@ -4,7 +4,7 @@
 
 **`devframe`** is the framework-neutral container for one devtool integration, portable across viewers. Build a single tool (its RPC, its SPA, its diagnostics, its CLI/build/spa/embedded outputs) without caring how it'll be displayed. A devframe app 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-integration orchestration (docks, terminals, messages, commands). It does not ship UI — implementers (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 plugin like the a11y inspector runs code inside the page being inspected. See `examples/vite-devframe-hub/` 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-integration orchestration (docks, terminals, messages, commands). It does not ship UI — implementers (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 plugin like the a11y inspector runs code inside the page being inspected. See `examples/hub-vite/` for a working ~120-line Vite host demonstrating the protocol end to end.
 
 ## Stack & Structure
 
@@ -70,7 +70,7 @@ These reinforce devframe's positioning as "the container for one devtool integra
 
 ### Hub example parity
 
-`examples/vite-devframe-hub/` (Vite plugin + vanilla client) and `examples/next-devframe-hub/` (Next.js App Router + React client) are the two reference hosts, and they stay at **feature parity**. They mount the same set of plugins and demo devframes, expose the same dock rail / iframe stage / subsystem drawer, and speak the same hub protocol — the only differences should be the host framework's own plumbing (how static assets are mounted, how the side-car server starts, how the client is rendered).
+`examples/hub-vite/` (Vite plugin + vanilla client) and `examples/hub-next/` (Next.js App Router + React client) are the two reference hosts, and they stay at **feature parity**. They mount the same set of plugins and demo devframes, expose the same dock rail / iframe stage / subsystem drawer, and speak the same hub protocol — the only differences should be the host framework's own plumbing (how static assets are mounted, how the side-car server starts, how the client is rendered).
 
 Any change to one lands in the other in the same PR: adding a dock, wiring a new hub subsystem, changing the drawer layout, adopting a new client-runtime API. Their READMEs mirror each other too. If a capability genuinely can't exist on one host, say so explicitly in both READMEs rather than letting the examples silently drift.
 

docs/.vitepress/config.ts

@@ -86,8 +86,13 @@ function examplesItems(prefix: string) {
     { text: 'json-render', link: `${prefix}/examples/json-render` },
     { text: 'streaming-chat', link: `${prefix}/examples/streaming-chat` },
     { text: 'next-runtime-snapshot', link: `${prefix}/examples/next-runtime-snapshot` },
-    { text: 'vite-devframe-hub', link: `${prefix}/examples/vite-devframe-hub` },
-    { text: 'next-devframe-hub', link: `${prefix}/examples/next-devframe-hub` },
+    { text: 'hub-vite', link: `${prefix}/examples/hub-vite` },
+    { text: 'hub-next', link: `${prefix}/examples/hub-next` },
+    { text: 'hub-vite-minimal', link: `${prefix}/examples/hub-vite-minimal` },
+    { text: 'hub-next-minimal', link: `${prefix}/examples/hub-next-minimal` },
+    { text: 'hub-nitro-minimal', link: `${prefix}/examples/hub-nitro-minimal` },
+    { text: 'hub-hono-minimal', link: `${prefix}/examples/hub-hono-minimal` },
+    { text: 'hub-rsbuild-minimal', link: `${prefix}/examples/hub-rsbuild-minimal` },
   ] satisfies DefaultTheme.NavItemWithLink[]
 }
 

docs/errors/DF8004.md

@@ -18,6 +18,7 @@ outline: deep
 import { initHub } from '@devframes/hub/initiate'
 
 initHub({
+  base: '/__devframes/',
   devframes: [defineDevframe({ id: 'devframes:plugin:my-tool', /* … */ })], // ✗ throws DF8004
 })
 

docs/examples/hub-hono-minimal.md

@@ -0,0 +1,27 @@
+---
+outline: deep
+---
+
+# hub-hono-minimal
+
+The minimal [Hono](https://hono.dev) host for [`@devframes/hub`](/guide/hub): one `initHub()` call behind a catch-all route, running on **Node and Bun** from the same app file, the UI supplied by `@devframes/hub-ui`.
+
+Package: `hub-hono-minimal` · framework: **Hono**
+
+## What it shows
+
+- `initHub({ base, devframes: [inspect, messages], ui: createUi() })` in `src/app.ts` plus `app.all(\`${hub.base}*\`, c => hub.handler(c.req.raw, c.env))`.
+- On Node (`@hono/node-server`), the RPC WebSocket runs on an eager side-car port.
+- On Bun (`Bun.serve({ fetch, websocket: hub.websocket })`), WebSocket upgrades complete through `hub.handler(request, server)` on the app's own origin — no side-car. The repo's `scripts/smoke-bun.ts` exercises this path end to end.
+
+## Run it
+
+```sh
+pnpm install
+pnpm --filter hub-hono-minimal dev       # Node
+pnpm --filter hub-hono-minimal dev:bun   # Bun
+```
+
+## Source
+
+[`examples/hub-hono-minimal`](https://github.com/devframes/devframe/tree/main/examples/hub-hono-minimal)

docs/examples/hub-next-minimal.md

@@ -0,0 +1,28 @@
+---
+outline: deep
+---
+
+# hub-next-minimal
+
+The minimal [Next.js](https://nextjs.org) host for [`@devframes/hub`](/guide/hub): one `initHub()` call on an App Router catch-all route, the UI supplied by `@devframes/hub-ui`.
+
+Package: `hub-next-minimal` · framework: **React (Next.js)**
+
+## What it shows
+
+- `initHub({ base, devframes: [inspect, messages], ui: createUi() })` behind one route (`app/%5F_devframes/[[...path]]/route.ts`) delegating to `hub.handler(request)`.
+- The plugins and `@devframes/hub-ui` load via a bundler-ignored dynamic `import()`, so Next resolves their published `dist` at runtime (their `import.meta.url` asset lookups don't survive static bundling).
+- Next route handlers can't accept WebSocket upgrades, so the instance runs its eager side-car WS server, advertised through `<base>__connection.json`.
+
+## Run it
+
+```sh
+pnpm install
+pnpm --filter hub-next-minimal dev
+```
+
+Open the printed URL for the host page with the floating dock, or `/__devframes/` for the standalone viewer.
+
+## Source
+
+[`examples/hub-next-minimal`](https://github.com/devframes/devframe/tree/main/examples/hub-next-minimal)

docs/examples/hub-next.md

@@ -0,0 +1,31 @@
+---
+outline: deep
+---
+
+# hub-next
+
+The same hub protocol as the [Vite host](./hub-vite), hosted from a **Next.js** App Router app with a hand-built React viewer — proof that the hub is host-runtime-agnostic.
+
+Package: `hub-next` · framework: **React (Next.js)**
+
+## What it proves
+
+- `initHub({ base, devframes, configure })` boots the whole hub from one call; a single App Router catch-all route (`app/%5F_devframes/[[...path]]/route.ts`) delegates to `hub.handler(request)`.
+- Next route handlers can't accept WebSocket upgrades, so the instance starts its eager side-car WS server, advertised through `<base>__connection.json`.
+- The [JSON-render](/guide/json-render) hub integration with **registry replacement**: the React client renders the server-authored view with a small in-example React registry (rather than the Vue `@devframes/json-render-ui`) — the path a non-Vue host uses.
+- [Client-only docks](/guide/client-context#client-only-docks) the page registers itself with `context.docks.register()`.
+
+For the minimal counterpart — the hub UI supplied by `@devframes/hub-ui` instead of a hand-built viewer — see [hub-next-minimal](./hub-next-minimal).
+
+## Run it
+
+```sh
+pnpm install
+pnpm --filter hub-next dev
+```
+
+Open the printed URL to see the docks, commands, messages, and terminals the hub exposes.
+
+## Source
+
+[`examples/hub-next`](https://github.com/devframes/devframe/tree/main/examples/hub-next)

docs/examples/hub-nitro-minimal.md

@@ -0,0 +1,28 @@
+---
+outline: deep
+---
+
+# hub-nitro-minimal
+
+The minimal [Nitro](https://nitro.build) host for [`@devframes/hub`](/guide/hub): one `initHub()` call behind a catch-all route, the UI supplied by `@devframes/hub-ui`.
+
+Package: `hub-nitro-minimal` · framework: **Nitro**
+
+## What it shows
+
+- `initHub({ base, devframes: [inspect, messages], ui: createUi() })` in `hub.ts`, delegated to by a catch-all route (`routes/__devframes/[...path].ts`, plus its `index.ts` sibling for the namespace root) via `hub.handler(event.req)`.
+- `nitro.config.ts` keeps the devframe packages external so their prebuilt client assets resolve from the packages themselves rather than Nitro's build output.
+- The RPC WebSocket runs on an eager side-car port, advertised through `<base>__connection.json`.
+
+## Run it
+
+```sh
+pnpm install
+pnpm --filter hub-nitro-minimal dev
+```
+
+Open the printed URL for the host page with the floating dock, or `/__devframes/` for the standalone viewer.
+
+## Source
+
+[`examples/hub-nitro-minimal`](https://github.com/devframes/devframe/tree/main/examples/hub-nitro-minimal)

docs/examples/hub-rsbuild-minimal.md

@@ -0,0 +1,28 @@
+---
+outline: deep
+---
+
+# hub-rsbuild-minimal
+
+The minimal [Rsbuild](https://rsbuild.dev) host for [`@devframes/hub`](/guide/hub): one `initHub()` call mounted into the dev server's middleware stack, the UI supplied by `@devframes/hub-ui`.
+
+Package: `hub-rsbuild-minimal` · framework: **Rsbuild**
+
+## What it shows
+
+- `initHub({ base, devframes: [inspect, messages], ui: createUi() })` created inside `server.setup` in `rsbuild.config.ts` — lazily, so importing the config never spawns the hub's side-car.
+- `server.setup` registers `hub.nodeMiddleware`, which owns the `/__devframes/` namespace and hands everything else back to Rsbuild.
+- The RPC WebSocket runs on an eager side-car port, advertised through `<base>__connection.json`; `html.tags` injects the `${hub.base}embedded.js` bootstrap.
+
+## Run it
+
+```sh
+pnpm install
+pnpm --filter hub-rsbuild-minimal dev
+```
+
+Open the printed URL for the host page with the floating dock, or `/__devframes/` for the standalone viewer.
+
+## Source
+
+[`examples/hub-rsbuild-minimal`](https://github.com/devframes/devframe/tree/main/examples/hub-rsbuild-minimal)

docs/examples/hub-vite-minimal.md

@@ -0,0 +1,28 @@
+---
+outline: deep
+---
+
+# hub-vite-minimal
+
+The minimal [Vite](https://vite.dev) host for [`@devframes/hub`](/guide/hub): one `initHub()` call mounted as dev middleware, the UI supplied by `@devframes/hub-ui`. No hand-built viewer — the whole integration is the config file.
+
+Package: `hub-vite-minimal` · framework: **Vite**
+
+## What it shows
+
+- `initHub({ base, devframes: [inspect, messages], ui: createUi() })` in `vite.config.ts` — runs in Vite's Node config process, never bundled into the browser.
+- `server.middlewares.use(hub.nodeMiddleware)` mounts the whole `/__devframes/` namespace; the WebSocket upgrade shares Vite's own server at `<base>__ws`.
+- `transformIndexHtml` injects `<script type="module" src="${hub.base}embedded.js">`, so the floating dock mounts itself on the host page.
+
+## Run it
+
+```sh
+pnpm install
+pnpm --filter hub-vite-minimal dev
+```
+
+Open the printed URL for the host page with the floating dock, or `/__devframes/` for the standalone viewer.
+
+## Source
+
+[`examples/hub-vite-minimal`](https://github.com/devframes/devframe/tree/main/examples/hub-vite-minimal)