void 0.21.9 → 0.23.0

package/skills/void/docs/guide/server-routing.md

@@ -25,15 +25,9 @@ routes/
   api/metrics.prod.ts  →  production only
 ```
 
-`dev` is the Vite dev server. `prod` is every build, `void deploy`, and `vite preview` — preview serves a production build, so it uses the production routes.
+`.dev` routes run only in development; `.prod` routes run in builds, deployments, and production previews. A resource used only by `.dev` routes is not provisioned for production.
 
-Excluded routes aren't included in the Worker bundle, generated types, or route and WebSocket configuration.
-
-`void prepare` is the exception: it boots no Vite, so it has no environment to read. It generates types for routes in both environments.
-
-[Binding inference](../reference/resource-inference.md) follows the suffix for files in `routes/`. For example, a `void/storage` import used only in `api/debug.dev.ts` adds a development R2 binding, but does not provision a production bucket. Imports in other source directories remain available in both environments.
-
-The suffix applies to files in `routes/` only. It has no effect in `pages/`, `middleware/`, `crons/`, or `queues/`.
+Suffixes apply only in `routes/`, not in `pages/`, `middleware/`, `crons/`, or `queues/`. `void prepare` generates types for both environments.
 
 Each file exports named HTTP method constants to handle specific methods:
 
@@ -65,20 +59,10 @@ export const POST = defineHandler(async (c) => {
 });
 ```
 
-The `db` helper provides a typed query API over D1. See [Database](./database.md) for the full API.
+See [Database](./database.md) for queries with D1, PostgreSQL, or MySQL.
 
 ## `defineHandler`
 
-`defineHandler` wraps a route handler function:
-
-```ts
-import { defineHandler } from 'void';
-
-export const GET = defineHandler((c) => {
-  return { data: 'hello' };
-});
-```
-
 The handler receives a Hono `Context` with typed Cloudflare bindings on `c.env` (see [Cloudflare](../integrations/cloudflare.md)). You can use the full Hono API (`c.json()`, `c.text()`, `c.header()`, etc.).
 
 Return values are automatically converted:
@@ -108,23 +92,6 @@ export const POST = defineHandler.withValidator({
 
 See [Database: Schema-Derived Validators](./database.md#schema-derived-validators) for how to set up `createInsertSchema` with column refinements.
 
-You can validate the body, query, and route parameters together:
-
-```ts
-// routes/api/users/[id].ts
-import { defineHandler } from 'void';
-import { db, eq } from 'void/db';
-import { users, updateUserSchema } from '@schema';
-
-export const PUT = defineHandler.withValidator({
-  body: updateUserSchema,
-})(async (c, { body }) => {
-  const id = Number(c.req.param('id'));
-  const [updated] = await db.update(users).set(body).where(eq(users.id, id)).returning();
-  return updated;
-});
-```
-
 ### Manual validators
 
 For endpoints that don't map to a database table, you can write validators by hand using any [Standard Schema](https://standardschema.dev/)-compatible library (Valibot, Zod, ArkType, etc.):
@@ -160,7 +127,7 @@ When validation fails, a `400` response is returned with structured error detail
 }
 ```
 
-No extra dependencies are required. Void inlines the Standard Schema types, so you only need your chosen schema library.
+Install your chosen validator library; no separate Standard Schema dependency is needed.
 
 Validator schemas also power the [typed fetch client](./typed-fetch.md), so `body`, `query`, and `params` types are enforced at the call site.
 
@@ -208,9 +175,7 @@ export default defineMiddleware(async (c, next) => {
 });
 ```
 
-`defineMiddleware` uses Hono middleware semantics: `(c, next) => Promise<void> | void`.
-
-For a temporary full-site gate, use the built-in `basicAuth()` middleware with credentials from `void/env`. Void internal endpoints under `/__void` are excluded automatically so deploy migrations and dev tooling continue to work. Wrap `void/env` reads in functions so they are resolved per request after Void has bound the runtime env.
+Use `basicAuth()` for a temporary site gate. Void's reserved `/__void` endpoints remain accessible for deployment and development tooling. Read credentials through callbacks:
 
 ```ts
 // env.ts
@@ -238,25 +203,7 @@ Set `BASIC_AUTH_USERNAME` and `BASIC_AUTH_PASSWORD` as local environment variabl
 
 For app-specific bypasses such as health checks or public webhooks, compose that logic in your own middleware before calling `basicAuth()`.
 
-Middleware can set typed context variables using `c.set()`. Augment the `CloudContextVariables` interface so downstream handlers get full type safety:
-
-```ts
-// middleware/01.request-id.ts
-import { defineMiddleware } from 'void';
-
-declare module 'void' {
-  interface CloudContextVariables {
-    requestId: string;
-  }
-}
-
-export default defineMiddleware(async (c, next) => {
-  c.set('requestId', crypto.randomUUID());
-  await next();
-});
-```
-
-Now every route handler can call `c.get("requestId")` and get `string` back, with no type assertion needed. See [Type Safety](./type-safety.md#context-variables) for more details.
+Use `c.set()` to share data with downstream handlers. Augment `CloudContextVariables` for typed access with `c.get()`. See [Context variables](./type-safety.md#context-variables).
 
 ### Per-route middleware
 
@@ -273,19 +220,9 @@ Middleware runs in order. Each can short-circuit (return a response without call
 import { defineHandler } from 'void';
 import { cors } from 'hono/cors';
 
-const addServerTiming = async (c, next) => {
-  const start = performance.now();
-  await next();
-  c.header('Server-Timing', `app;dur=${Math.round(performance.now() - start)}`);
-};
-
-export const GET = defineHandler(
-  cors({ origin: 'https://app.example.com' }),
-  addServerTiming,
-  (c) => {
-    return { stats: '...' };
-  },
-);
+export const GET = defineHandler(cors({ origin: 'https://app.example.com' }), (c) => ({
+  stats: '...',
+}));
 ```
 
 Up to 5 middleware can be passed before the handler, with full type inference for each position.

package/skills/void/docs/guide/sse.md

@@ -65,11 +65,11 @@ await stream.send({
 await stream.comment('still connected');
 ```
 
-`data` may be a string or JSON-serializable value. Strings are sent as-is; other values are serialized with `JSON.stringify()`. Multi-line strings are split into multiple `data:` lines. Binary data is rejected because SSE is text-only.
+`data` accepts strings or JSON-serializable values. SSE is text-only.
 
-Void validates `event`, `id`, and `retry` before writing, so their values can't accidentally introduce extra SSE fields or events. Writing to a closed stream throws `SseStreamClosedError`.
+Writing to a closed stream throws `SseStreamClosedError`.
 
-If you already serialized the payload, use `formatSseText()` for lower-level formatting while keeping the same `id`, `event`, and `retry` validation:
+Use `formatSseText()` to format a payload you have already serialized:
 
 ```ts
 import { formatSseText } from 'void/sse';
@@ -98,8 +98,6 @@ return eventStream(start, {
 });
 ```
 
-The interval must be a positive finite number.
-
 ## Last Event ID
 
 Browsers send `Last-Event-ID` when reconnecting after an event with an `id` field. Use `getLastEventId()` to resume from your own storage:
@@ -115,8 +113,6 @@ export const GET = defineHandler((c) => {
 });
 ```
 
-`void/sse` does not store or replay events. Persist event offsets in your own database, queue, or Durable Object when replay matters.
-
 ## Client
 
 Use `connectEventStream()` from the browser-only `void/sse/client` subpath:
@@ -174,14 +170,4 @@ export const GET = defineHandler(async (c) => {
 
 Native `EventSource` can send cookies with `withCredentials: true`. For non-cookie auth, generate a short-lived signed URL and validate it in the route handler.
 
-## When to use SSE
-
-Plain SSE is enough when the producer belongs to the same request that opened the stream:
-
-- AI token streaming
-- One-off progress updates
-- Command output
-- Per-request deployment or build logs
-- Incremental status for a long-running action
-
-For shared topics and subscriptions, use [Live Event Streams](./live.md). For rooms with two-way communication, use [WebSockets](./websockets.md). Replay and database change streams need an application-level storage or delivery layer.
+For shared topics and subscriptions, use [Live Event Streams](./live.md). For two-way communication, use [WebSockets](./websockets.md).

package/skills/void/docs/guide/ssg.md

@@ -14,15 +14,11 @@ Set `output: "static"` in `void.config.ts` to prerender all pages at build time:
 
 When `output` is `"static"`:
 
-- All pages default to `prerender = true` and are written as HTML files to `dist/client/`. A standalone `vite build` renders them during the build; managed `void deploy` renders immediately afterward in its trusted parent process.
+- Pages default to `prerender = true` and are written as HTML files to `dist/client/`.
 - Use `export const prerender = false` in a page's `.server.ts` to opt out. That page will be server-rendered on request.
 - Dynamic pages without `getPrerenderPaths()` are implicitly not prerendered (the paths aren't known at build time).
 - The build output is self-contained and works for direct Cloudflare deployment, self-hosting, or `void deploy`.
 
-## How it works
-
-During `vite build`, after both the worker and client bundles are written to disk, Void spins up Miniflare with the built worker and fetches each page. The HTML responses are written to `dist/client/` as static files (e.g. `/about` becomes `dist/client/about.html`).
-
 ## Per-page overrides
 
 Individual pages can opt out of prerendering:
@@ -41,8 +37,6 @@ export async function getPrerenderPaths() {
 }
 ```
 
-Dynamic pages **without** `getPrerenderPaths()` are not prerendered because the paths are not known at build time. These pages are served dynamically by the worker at runtime.
-
 ## Comparison with edge prerendering
 
 | `output` value       | Default prerender | Per-page override                | Prerender timing           |
@@ -50,19 +44,15 @@ Dynamic pages **without** `getPrerenderPaths()` are not prerendered because the
 | `"server"` (default) | `false`           | `export const prerender = true`  | Deploy-time (platform ISR) |
 | `"static"`           | `true`            | `export const prerender = false` | Build or deploy post-build |
 
-When `output` is omitted or set to `"server"`, behavior is unchanged. `export const prerender = true` opts individual pages into deploy-time [edge prerendering](./edge/prerendering.md).
-
-Managed deploy keeps its deployment credential out of project-controlled build scripts and Vite plugins. When static rendering needs remote D1, KV, R2, or AI, the trusted deploy process supplies the built worker with a five-minute credential scoped to that project's binding proxy only.
+With the default `output: "server"`, use `export const prerender = true` for deploy-time [edge prerendering](./edge/prerendering.md).
 
 ## Deployment behavior
 
-When you run `void deploy` with `output: "static"`, Void inspects the build output to decide the optimal deploy strategy:
+`void deploy` chooses the deployment automatically:
 
 - **Fully static:** if every page is prerendered and there are no API routes, middleware, cron jobs, or queues, Void deploys as a pure static site with no worker.
 - **Hybrid:** if any pages are not prerenderable, such as dynamic pages without `getPrerenderPaths()` or pages with `export const prerender = false`, a worker is deployed to handle those routes at runtime. Prerendered pages are still served as static assets.
 
-You do not need to configure this. Void detects it automatically from your pages and project structure.
-
 ## Relationship to `inference.appType: "static"`
 
 The `inference.appType` field describes app type (SPA, static, void), while `output` controls rendering strategy:
@@ -72,5 +62,3 @@ The `inference.appType` field describes app type (SPA, static, void), while `out
 | **What**     | Deploy a pre-built static site (no Void plugin) | Prerender a Void app at build time            |
 | **Worker**   | None (static assets only)                       | Only if some pages can't be prerendered       |
 | **Use case** | VitePress, plain HTML, external SSG tools       | Void apps with mostly or fully static content |
-
-When all pages are prerendered and there are no backend features, `output: "static"` produces the same deploy result as `inference.appType: "static"`: pure static assets with no worker. The difference is that `output: "static"` figures this out by analyzing your build output, while `inference.appType: "static"` is a manual declaration for non-Void projects.

package/skills/void/docs/guide/ssr.md

@@ -4,18 +4,11 @@ outline: deep
 
 # Custom SSR
 
-Void supports framework-agnostic SSR via explicit server and client entries. This is for advanced use cases where you want full control over rendering and hydration.
+Use custom SSR to choose your own router, data loading, HTML shell, and hydration code. If you want Void to handle these for you, use [Pages Routing](./pages-routing/overview).
 
-::: tip
-For most apps, [Pages Routing](./pages-routing/overview) handles SSR automatically. You do not need entry files or hydration code.
-:::
+## Create the app
 
-## Relationship to Pages Routing
-
-Custom SSR is separate from Pages Routing. Use Custom SSR when you want to bring
-your own root component, router, data loading, HTML shell, and hydration logic.
-
-The `App` component below is the root of this custom-rendered application:
+Start with a root component. This React example renders a page based on the request path:
 
 ```tsx
 // src/App.tsx
@@ -24,50 +17,21 @@ export default function App({ url }: { url: string }) {
 }
 ```
 
-Pages Routing adapters generate their own SSR and hydration entries and compose
-`pages/layout.*`, route components, loaders, and actions.
-
 ## Required entries
 
-SSR mode is enabled when both of these exist:
+Create both entry files:
 
 - `src/main.ssr.ts` or `src/main.ssr.tsx`
 - `src/main.client.ts` or `src/main.client.tsx`
 
-Only one server entry and one client entry may exist.
-If only one side is present, build/deploy fails with a clear error.
+Use one server entry and one client entry. Both are required.
 
 ## Render API
 
-`src/main.ssr.ts(x)` must export either:
-
-```ts
-render(c: CloudContext, assetTags: RenderAssetTags): Response | Promise<Response>
-```
-
-or:
-
-```ts
-export default defineRender((c, assetTags) => Response | Promise<Response>);
-```
-
-The recommended form is `defineRender(...)` for inferred types.
-
-`assetTags` contains the HTML tags for your client assets:
-
-```ts
-{
-  css: string; // stylesheet links for <head>
-  preloads: string; // modulepreload/Vite client+preamble tags for <head>
-  body: string; // main client entry script tag before </body>
-}
-```
-
-If no render export is found, build/deploy fails with a clear error.
-
-Example:
+Wrap your server renderer with `defineRender()` and return an HTML response. Insert `assetTags.css` and `assetTags.preloads` in `<head>`, and `assetTags.body` before `</body>`:
 
 ```tsx
+// src/main.ssr.tsx
 import { renderToString } from 'react-dom/server';
 import { defineRender } from 'void';
 import App from './App';
@@ -89,34 +53,22 @@ export default defineRender(async (c, assetTags) => {
 });
 ```
 
-`src/main.client.ts(x)` should hydrate/mount your app:
+You can also export a named `render(c, assetTags)` function with the same signature. See [`defineRender`](../reference/api/handlers.md#definerender-handler) for the types.
+
+## Hydrate in the browser
+
+In the client entry, hydrate the same component:
 
 ```tsx
+// src/main.client.tsx
 import { hydrateRoot } from 'react-dom/client';
 import App from './App';
 
 hydrateRoot(document.getElementById('root')!, <App url={window.location.pathname} />);
 ```
 
-## Client Asset Injection
-
-Place the client asset tags in the HTML returned by your `render()` function.
-
-The `assetTags` values are computed by Void:
-
-- In production: from `dist/client/.vite/manifest.json` (entry script, CSS, modulepreload)
-- In dev: includes Vite HMR client and React refresh preamble (when React plugin is active), plus the client entry script
-
 ## Caching
 
 See [Revalidation](./edge/revalidation.md) for stale-while-revalidate caching of SSR pages.
 
-## Request flow
-
-With SSR enabled:
-
-1. `/api/*` requests go to worker API routes
-2. static asset hits are served from R2
-3. unmatched non-API requests fall back to `render(c, assetTags)`
-
-Without SSR entries, non-API requests keep SPA static fallback behavior.
+API routes and static files are served before custom rendering. Unmatched non-API requests use `render(c, assetTags)`.

package/skills/void/docs/guide/storage.md

@@ -35,13 +35,14 @@ for (const obj of listed.objects) {
 const head = await storage.head('uploads/photo.jpg');
 ```
 
-The `storage` object is a full `R2Bucket`. Every method from the [Cloudflare R2 API](https://developers.cloudflare.com/r2/api/workers/workers-api-reference/) is available directly, with no wrapper layer.
+`storage` supports the full [R2Bucket API](https://developers.cloudflare.com/r2/api/workers/workers-api-reference/).
 
 ## Serving Files
 
 A common pattern is serving uploaded files from an API route:
 
 ```ts
+import { defineHandler } from 'void';
 import { storage } from 'void/storage';
 
 export const GET = defineHandler(async (c) => {
@@ -60,8 +61,12 @@ export const GET = defineHandler(async (c) => {
 });
 ```
 
-## How It Works
+## Custom bindings
 
-`storage` resolves the `env.STORAGE` binding when you use it. It exposes the R2 API directly, so methods and options work as described in Cloudflare's documentation.
+Use `createStorage(bucket)` with your own R2 binding, or in tests:
 
-The `createStorage()` factory exists for testing and for frameworks that manage their own routing. It accepts an `R2Bucket` and returns it directly.
+```ts
+import { createStorage } from 'void/storage';
+
+const storage = createStorage(env.MY_BUCKET);
+```

package/skills/void/docs/guide/type-safety.md

@@ -4,7 +4,7 @@ outline: deep
 
 # Type Safety
 
-Void provides end-to-end type safety across the stack. Types come from your source code and Drizzle schema, so you are not hand-writing or duplicating interfaces.
+Void infers types from your database schema, route handlers, and page loaders. When you change a field, TypeScript shows which queries, requests, and components need to change.
 
 ## The Type Pipeline
 
@@ -114,7 +114,7 @@ The `action()` helper gets the same type checking. See [Actions & Forms](./pages
 
 ## Serialization
 
-Handler return types are transformed via `Serialize<T>` so the client sees what actually arrives over the wire:
+The client types reflect JSON serialization through `Serialize<T>`:
 
 | Source type                       | Serialized type                                        |
 | --------------------------------- | ------------------------------------------------------ |
@@ -163,17 +163,6 @@ Extend the generated tsconfig in your project:
 }
 ```
 
-If your project already extends another config, use `void init --tsconfig` so Void can patch the file without dropping existing `files` or `compilerOptions.paths` entries. The resulting config may use TypeScript's multi-extends form:
-
-```json
-{
-  "extends": ["./tsconfig.base.json", "./.void/tsconfig.json"],
-  "compilerOptions": {
-    "types": ["void/env"]
-  }
-}
-```
-
-The `.void/tsconfig.json` uses `"files"` and `compilerOptions.paths` for generated declarations such as `routes.d.ts`, `db.d.ts`, and `queues.d.ts`. TypeScript inherits those fields, but `files` and `paths` are replaced rather than deeply merged when another config defines them. `void init --tsconfig` handles the common existing-config cases by adding Void's generated files and aliases directly to the root config when needed.
+If you already have a TypeScript config, run `void init --tsconfig` to add Void types while preserving your settings.
 
 Run `void prepare` in CI or after a fresh clone, or let `vite dev` / `vite build` generate the `.void/` files during normal app workflows.

package/skills/void/docs/guide/typed-fetch.md

@@ -4,7 +4,7 @@ outline: deep
 
 # Typed Fetch
 
-Void ships a typed `fetch` client that knows every route in your app. Import it from `void/client` and get autocomplete for paths, type-checked request bodies, and fully inferred response types.
+Import `fetch` from `void/client` for route autocomplete, checked request bodies, and inferred response types.
 
 ## Basic Usage
 
@@ -26,8 +26,6 @@ const user = await fetch('/api/users/:id', {
 });
 ```
 
-No type annotations needed. Everything is inferred from your route handlers.
-
 ## What Gets Type-Checked
 
 The client constrains every part of the request:
@@ -90,7 +88,7 @@ try {
 
 ## Isomorphic Fetch During SSR
 
-`fetch()` from `void/client` works during server-side rendering and inside route handlers without an HTTP round-trip. In the worker environment, it calls your Hono app directly through `app.fetch()` and skips the network entirely.
+`fetch()` also works in server-side rendering and route handlers. Calls to your app run without an HTTP round-trip.
 
 ```ts
 // src/main.ssr.tsx
@@ -108,6 +106,4 @@ export default defineRender(async (c, assetTags) => {
 });
 ```
 
-**Automatic header forwarding**: `cookie` and `authorization` headers from the incoming request are automatically forwarded to subrequests, so authentication context is preserved. If you pass these headers explicitly, your values take precedence.
-
-**How it works**: In the browser, `fetch()` uses the normal HTTP client. In the worker, Void redirects the import to a virtual module that calls `app.fetch()` directly using the Hono app instance. AsyncLocalStorage threads the outer request context so headers and `waitUntil()` work correctly.
+Server-side calls forward the incoming request's `cookie` and `authorization` headers. Explicit headers take precedence.

package/skills/void/docs/guide/websockets.md

@@ -8,11 +8,9 @@ outline: deep
 Typed WebSocket routes currently work in native Void apps. They aren't available in meta-framework mode yet.
 :::
 
-Create a `.ws.ts` route to add a typed WebSocket endpoint. Void runs each route instance in a Cloudflare Durable Object, which coordinates the clients connected to it. These routes require the Cloudflare target; Node.js, Bun, and Deno builds reject them.
+Create a `.ws.ts` route to send typed messages between your server and connected clients. Each route instance has its own Cloudflare Durable Object for shared state. WebSocket routes require the Cloudflare target.
 
-New WebSocket route classes use SQLite-backed Durable Objects on both deployment platforms.
-
-For example, a chat route at `/rooms/[id]` gives each room its own instance. Use it for chat, presence, collaborative documents, or notifications.
+For example, `/rooms/[id]` gives each chat room its own instance. Use it for chat, presence, collaborative documents, or notifications.
 
 ## Route files
 
@@ -115,6 +113,28 @@ export default defineWebSocket({
 });
 ```
 
+## Client
+
+Use `connect()` from `void/ws` on the client:
+
+```ts
+import { connect } from 'void/ws';
+
+const socket = connect('/chat/:room', {
+  params: { room: 'general' },
+});
+
+socket.on('message', (event) => {
+  if (event.type === 'chat.message') {
+    console.log(event.text);
+  }
+});
+
+socket.send({ type: 'chat.message', text: 'hello' });
+```
+
+`connect()` resolves relative URLs against the current origin and automatically uses `ws:` or `wss:`. It also buffers messages until the socket opens and reconnects by default.
+
 ## Typed messages
 
 Define schemas for messages sent by the client and server:
@@ -125,19 +145,11 @@ Define schemas for messages sent by the client and server:
 - `ctx.room.broadcast()`, `ctx.connection.send()`, and `ctx.socket.send()` are typed from `messages.server`
 - `connect()` infers route params, outgoing client messages, and incoming server messages from generated route types
 
-The default protocol is JSON events. Raw string or binary framing is not the primary API.
-
-## Ambient auth
+Messages are JSON events. Raw string and binary messages are not supported.
 
-WebSocket hooks use the same built-in session resolution as HTTP auth. When Void auth is enabled, `ctx.user` is available in:
+## Authentication
 
-- `onBeforeConnect`
-- `onConnect`
-- `onMessage`
-- `onClose`
-- `onRequest`
-
-This makes cookie-authenticated sockets work without re-parsing the session manually.
+When Void auth is enabled, every WebSocket hook receives the current user as `ctx.user`, or `null` for an anonymous connection. Use `onBeforeConnect` to reject unauthenticated clients.
 
 ## Hooks
 
@@ -149,6 +161,9 @@ Both `defineRoom()` and `defineWebSocket()` support:
 - `onClose(ctx, details)`: receives `{ code, reason, wasClean }`
 - `onRequest(ctx)`: handles ordinary HTTP requests to the same path
 
+Void completes the WebSocket close handshake automatically. Use `onClose` for application cleanup;
+you do not need to close the socket again in this hook.
+
 Every hook receives a context with:
 
 - `ctx.id`: deterministic route instance id
@@ -160,42 +175,55 @@ Every hook receives a context with:
 
 If a route does not define `onRequest()`, non-WebSocket requests return `426 Upgrade Required`.
 
-## Client
+## Move a route while keeping its state
 
-Use `connect()` from `void/ws` on the client:
+Before moving a deployed route, run `void info`. For `routes/chat/[room].ws.ts`, the output includes:
 
-```ts
-import { connect } from 'void/ws';
+```text
+To preserve this resource when moving its code, add this to 'defineRoom':
+  name: "chat-room",
+```
 
-const socket = connect('/chat/:room', {
-  params: { room: 'general' },
-});
+Add the displayed name to your existing definition:
 
-socket.on('message', (event) => {
-  if (event.type === 'chat.message') {
-    console.log(event.text);
-  }
+```ts
+export default defineRoom({
+  name: 'chat-room',
+  messages: { client: ClientMessage, server: ServerMessage },
+  // Keep your existing hooks.
 });
-
-socket.send({ type: 'chat.message', text: 'hello' });
 ```
 
-`connect()` resolves relative URLs against the current origin and automatically uses `ws:` or `wss:`. It also buffers messages until the socket opens and reconnects by default.
+Move the file to `routes/rooms/[room].ws.ts`, update clients to connect to `/rooms/:room`, and deploy normally. Keep the same parameter names and values: room `general` still uses its existing storage. The Worker class, binding, and migration history stay the same on both Cloudflare and Void platform deployments.
 
-## Constraints
+Both `defineRoom()` and `defineWebSocket()` accept optional `name`. Use a static string, inline or in a local `const`. Each route must produce a distinct Worker class; changing the name selects a different resource. If you already moved a route, `void info` also shows unmatched identities recorded in `void.lock.json`. Identify the original resource before adopting its suggested name; otherwise restore the original source and discover the name there.
 
-WebSocket routes currently support:
+### Rename a route parameter
 
-- Cloudflare-only
-- one route-derived connection target per socket
-- no Socket.IO-style dynamic room join/leave API
-- no global pub/sub abstraction
-- JSON event messages only
+By default, the instance key includes parameter names. `/chat/:room` with `room: 'general'` uses `room=general`; a route without parameters uses `default`. Multiple parameters are joined in route order, for example `team=acme&room=general`. If a multi-parameter route has a value containing `&`, its key uses a versioned encoding to keep rooms separate.
 
-Each socket connects to one route instance. Applications that need to switch rooms should manage that connection change explicitly.
+When upgrading an existing multi-parameter route with `&` in its parameter values, those rooms start with isolated storage. The previous storage is retained, but may have been shared by multiple rooms. Migrate only data whose ownership you have verified into each new room. Single-parameter rooms and multi-parameter rooms without `&` keep their existing identities.
 
-## Deployment
+If you also rename `[room]` to `[id]`, preserve the old key explicitly:
+
+```ts
+// routes/rooms/[id].ws.ts
+export default defineRoom({
+  name: 'chat-room',
+  key: ({ params }) => `room=${params.id}`,
+  messages: { client: ClientMessage, server: ServerMessage },
+  // Keep your existing hooks.
+});
+```
+
+Clients now connect to `/rooms/:id` with `params: { id: 'general' }`. The key remains `room=general`, so storage and `ctx.id` stay the same. Returning only `params.id` would select a different instance.
 
-`void deploy --platform cloudflare` persists the required binding and append-only SQLite class migration in `void.lock.json`, then deploys the generated Worker directly to your account. Commit this migration history and never delete or reorder a step after deployment.
+`key` is optional on both WebSocket helpers. It must return a string synchronously and consistently for the same parameters. Preserve the complete old key when migrating multiple parameters. Keep the callback stable after deployment.
+
+## Constraints
+
+Each socket connects to one route instance. To switch rooms, close the current connection and open another. For publishing to multiple topics, see [Live Event Streams](./live.md).
+
+## Deployment
 
-`void deploy --platform void` uses the same shared migration planner in the hosted uploader. Existing hosted WebSocket classes created on legacy storage remain there; only genuinely new classes use SQLite.
+WebSocket routes work on Cloudflare and Void platform deployments. Commit `void.lock.json` when Void adds a binding or migration. Do not delete or reorder deployed migration steps.

package/skills/void/docs/integrations/agents.md

@@ -10,7 +10,7 @@ outline: deep
 npx void init --agents
 ```
 
-This always creates or updates `AGENTS.md` with four brief bullets covering Void, deployment targets, the development workflow, and where to find the docs. It preserves your existing content outside the versioned Void block and leaves other instruction files untouched. There is no coding-agent selection prompt.
+Void updates `AGENTS.md` with development guidance and links to the docs, preserving your existing instructions.
 
 The complete Markdown docs ship with the installed package at `node_modules/void/skills/void/docs/`. Agents can read them directly, even without a linked skill.
 
@@ -20,7 +20,7 @@ Skills point your agent to the commands and docs it needs for the task. They lin
 
 Void ships two skills:
 
-- **`void`:** main development skill. Routes agent requests to the right documentation for CLI commands, routing, pages, database, auth, deployment, and more.
+- **`void`:** commands and docs for app development.
 - **`migrate-vite-cloudflare-to-void`:** migration skill for converting existing `@cloudflare/vite-plugin` apps to Void.
 
-Skills are linked automatically by `void init --agents` when it detects a supported agent's configuration. For Claude Code, they are symlinked into `.claude/skills/`. Other detected agents have them linked to their respective directories. If no agent is detected, skill linking is skipped and `AGENTS.md` points directly to the bundled docs.
+Skills are linked automatically by `void init --agents` when it detects a supported agent's configuration. For example, Claude Code uses `.claude/skills/`. If no agent is detected, skill linking is skipped and `AGENTS.md` points directly to the bundled docs.