void 0.22.0 → 0.24.0

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

@@ -56,36 +56,9 @@ Void asks you to choose Vite+ or Vite, a UI framework, a starter, and a deployme
 
 With pnpm, you can start with `pnpm create void my-app`. It configures native build permissions before installing Void.
 
-If a manual pnpm install reports blocked build scripts, run `pnpm approve-builds` for `esbuild`, `sharp`, and `workerd`. Set `better-sqlite3: false` in `pnpm-workspace.yaml`'s `allowBuilds`; Void uses its bundled binaries. Setup updates the pnpm lockfile, including in CI. Later installs can use `pnpm install --frozen-lockfile`.
-
 The examples below use `void` for brevity. Outside package scripts, run the local binary with `npx void`, `pnpm void`, `yarn void`, or `bunx void`. Keep Void installed in the project so the CLI and app use the same version.
 
-## Using with Coding Agents
-
-`void init` detects your coding agent and installs its instructions and skills. If detection fails, choose an agent when prompted. In agents that support it, load the `/void` skill and describe the app you want to build. See [Coding Agents](../integrations/agents) for setup details.
-
-## Meta Frameworks
-
-Use Void's [Pages routing](./pages-routing/overview) or keep a framework such as TanStack Start, React Router, or SvelteKit. Follow the [framework guides](../integrations/frameworks/overview) for setup.
-
-## Adding to an Existing Vite App
-
-Install Void using the package manager command [above](#start-in-an-empty-directory).
-
-Enable the plugin in `vite.config.ts`:
-
-```ts
-import { defineConfig } from 'vite';
-import { voidPlugin } from 'void';
-
-export default defineConfig({
-  plugins: [voidPlugin()],
-});
-```
-
-Then run `void init` with your package manager to configure the remaining project files. Existing compatibility dates are preserved; new projects use Void's tested Workers compatibility date.
-
-## Once You Have a Working App
+## Run and deploy
 
 ### 1. Edit the generated API route
 
@@ -110,32 +83,60 @@ Then visit:
 - App: `http://localhost:5173`
 - API route: `http://localhost:5173/api/hello`
 
-### 3. Choose where to deploy
+### 3. Deploy
 
-If you chose a deployment target during setup, you're ready. If you skipped it, run `void init` again or choose Cloudflare for the first deploy:
+If you chose a deployment target during setup, run:
+
+```sh
+void deploy
+```
+
+If you skipped deployment setup, select your Cloudflare account for the first deploy:
 
 ```sh
 void deploy --platform cloudflare
 ```
 
-Void opens your browser to sign in when needed. To use your team's platform, connect using the API URL from your administrator:
+Void opens your browser to sign in when needed. To use your team's platform, connect using the API URL from your administrator, then link a project and deploy:
 
 ```sh
 void connect https://platform.example.com
 void project link
+void deploy
 ```
 
-### 4. Deploy
+Void builds the app, provisions its resources, applies pending migrations, and prints the deployed URL. If a production secret is missing, [set it](./env-vars.md) and deploy again. Later deploys use the saved target.
 
-With your target configured, run:
+See [Deployment](./deployment.md) for CI setup and rollback.
 
-```sh
-void deploy
+## Using with Coding Agents
+
+`void init` detects your coding agent and installs its instructions and skills. If no agent is detected, use the bundled docs linked in `AGENTS.md`. In agents that support it, load the `/void` skill and describe the app you want to build. See [Coding Agents](../integrations/agents) for setup details.
+
+## Meta Frameworks
+
+Use Void's [Pages routing](./pages-routing/overview) or keep a framework such as TanStack Start, React Router, or SvelteKit. Follow the [framework guides](../integrations/frameworks/overview) for setup.
+
+## Adding to an Existing Vite App
+
+Install Void using the package manager command [above](#start-in-an-empty-directory).
+
+Enable the plugin in `vite.config.ts`:
+
+```ts
+import { defineConfig } from 'vite';
+import { voidPlugin } from 'void';
+
+export default defineConfig({
+  plugins: [voidPlugin()],
+});
 ```
 
-Void builds the app, provisions the resources it uses, applies pending migrations, and prints the deployed URL. If it reports a missing production secret, [configure that secret](./env-vars.md) and deploy again.
+Then run `void init` with your package manager to configure the remaining project files.
+
+## Troubleshooting pnpm installs
 
-Subsequent deploys use the same target. See [Deployment](./deployment.md) for CI setup, migrations, and rollback. To generate a supported push-to-deploy workflow, run `void init --github`.
+If a manual pnpm install reports blocked build scripts, run `pnpm approve-builds` for `esbuild`, `sharp`, and `workerd`. Set `better-sqlite3: false` in `pnpm-workspace.yaml`'s `allowBuilds`; Void uses its bundled binaries.
 
 ## Next steps
 

package/skills/void/docs/guide/remote-dev.md

@@ -42,18 +42,14 @@ VOID_REMOTE=1 vite dev
 | R2      | Local file-backed R2       | Remote R2 bucket    |
 | AI      | Always proxied             | Always proxied      |
 
-AI inference is always routed through the proxy regardless of remote mode. There is no local AI emulation.
+AI requests use your platform’s account and allowance in both local and remote mode. There is no local AI simulator.
 
-## How It Works
-
-In remote mode, binding calls go through your platform's proxy, authenticated with your login token. The proxy uses the linked project's configuration to choose the D1 database, KV namespace, or R2 bucket.
-
-You don't need to change any code. Imports like `import { db } from "void/db"` and direct binding access via `c.env.KV` both work transparently.
+## Checking Remote Mode
 
 When the dev server starts with remote mode active, it prints:
 
 ```
-⚡ Remote bindings active (my-project.void.app)
+⚡ Remote bindings active (my-project.apps.example.com)
    DB      → remote D1
    KV      → remote KV
    STORAGE → remote R2
@@ -63,7 +59,6 @@ When the dev server starts with remote mode active, it prints:
 
 - **Network latency:** each binding call makes a network request, so responses may be slower than local development.
 - **R2 multipart uploads:** `createMultipartUpload()` and `resumeMultipartUpload()` are not supported in remote mode.
-- **R2 conditional writes:** `put(..., { onlyIf })` requires a current Void platform and an active deployment with the native remote-binding handler. Update the platform and redeploy the project if this operation is unavailable. Failed preconditions return `null`; Void never retries a conditional write as an unconditional REST upload.
+- **R2 conditional writes:** `put(..., { onlyIf })` requires a current Void platform and an active deployment with the native remote-binding handler. Update the platform and redeploy the project if this operation is unavailable. Failed preconditions return `null`.
 - **D1 dump:** `db.dump()` is not supported in remote mode.
-- **D1 batch compatibility:** `db.batch()` requires an active deployment with the native remote-binding handler. Void does not split a batch into REST calls because that would lose D1's atomic all-or-nothing behavior.
-- **Writes affect real data:** remote mode connects to your actual deployed resources. Inserts, updates, and deletes are real, so use it carefully or point it at a staging project.
+- **D1 batches:** `db.batch()` requires an updated platform and project deployment.

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

@@ -12,13 +12,13 @@ import { getSandbox } from 'void/sandbox';
 
 export const POST = defineHandler(async (c) => {
   const sandbox = await getSandbox('default');
-  const process = await sandbox.exec(['node', '--version']);
-  const result = await process.output();
-
-  return c.json({
-    exitCode: result.exitCode,
-    stdout: new TextDecoder().decode(result.stdout),
-    stderr: new TextDecoder().decode(result.stderr),
+  return sandbox.run(['node', '--version']).match({
+    ok: (result) =>
+      c.json({
+        exitCode: result.exitCode,
+        stdout: new TextDecoder().decode(result.stdout),
+      }),
+    limited: (limit) => limit.response({ message: 'Execution is temporarily unavailable.' }),
   });
 });
 ```
@@ -27,7 +27,7 @@ Importing from `void/sandbox` enables the required resources. Local development,
 
 ## Configuration
 
-Most apps do not need config. The default binding is `SANDBOX`, the Durable Object class is `SandboxV1`, and the default environment provides Node.js 24 on Debian Trixie. Local development and native deploys build Void's packaged Dockerfile, so Docker must be running. Managed platform deploys use Cloudflare's managed Node.js image.
+The default environment provides Node.js 24 on Debian Trixie. Local development and native deploys need Docker running. Managed platform deploys use Cloudflare's managed Node.js image.
 
 Use `void.config.ts` when you need a custom image or container size:
 
@@ -62,7 +62,7 @@ WORKDIR /workspace
 CMD ["sleep", "infinity"]
 ```
 
-For a managed platform, push your custom image to that platform account's Cloudflare registry and set `platformImage` to its digest-pinned reference. If `image` is already a Cloudflare registry reference, it also becomes the default `platformImage`. External registry references and mutable tags are not supported by the new scheduling policy. See [Cloudflare's image management guide](https://developers.cloudflare.com/containers/guides/image-management/#push-images-to-the-cloudflare-registry).
+For a managed platform, push your custom image to that platform account's Cloudflare registry and set `platformImage` to its digest-pinned reference. If `image` is already a Cloudflare registry reference, it also becomes the default `platformImage`. External registries and mutable tags are not supported. See [Cloudflare's image management guide](https://developers.cloudflare.com/containers/guides/image-management/#push-images-to-the-cloudflare-registry).
 
 ## Runtime API
 
@@ -75,37 +75,45 @@ const sandbox = await getSandbox(`user-${user.id}`, {
   inactivityTimeoutMs: 10 * 60 * 1000,
   enableInternet: false,
 });
-await sandbox.files.writeFile('/workspace/input.txt', 'hello');
-const process = await sandbox.exec(['cat', '/workspace/input.txt'], {
-  signal: AbortSignal.timeout(5_000),
-});
-const { stdout, exitCode } = await process.output();
-const text = new TextDecoder().decode(stdout);
+const response = await sandbox
+  .run(['node', '--version'], {
+    signal: AbortSignal.timeout(5_000),
+  })
+  .match({
+    ok: (result) => Response.json({ exitCode: result.exitCode }),
+    limited: (limit) => limit.response(),
+  });
 ```
 
 Commands take an executable and arguments as an array. For shell syntax, explicitly run `['sh', '-c', command]`. Execution options include `cwd` (default `/workspace`), `env`, `user`, `signal`, `pty`, `stdin`, `stdout`, and `stderr`.
 
-`exec()` returns a process immediately after it starts. Read its `stdout` and `stderr` streams, or call `output()` to collect both as `ArrayBuffer`s together with the exit code. `exitCode` is a promise; `kill(signal?)` and `resize(cols, rows)` are asynchronous. Use `stdin: 'pipe'` to receive a writable `stdin` stream. A process can continue running after a request returns, until it exits or its container stops. When streaming output from a long command, await `process.exitCode` alongside consuming its streams. This keeps an explicit command wait active even while the command produces no output; unattended background commands can stop when the Sandbox becomes idle.
+`run()` collects command output and handles limits throughout execution with one required `.match({ ok, limited })`. Both handlers are required. Other failures still reject.
 
-File operations live under `sandbox.files`: `readFile`, `writeFile`, `stat`, `lstat`, `readDirectory`, `mkdir`, `rename`, and `remove`. `readFile()` returns a streaming `Response`; use `.text()`, `.arrayBuffer()`, or `.body`. `writeFile()` accepts text, binary data, or a byte stream. Relative file paths require an explicit `cwd` option.
+`exec()` returns a lazy operation yielding a process through its `ok` handler. Use `output()` to collect `stdout` and `stderr` as `ArrayBuffer`s with the exit code, or read the streams and match `exitCode`. Both `output()` and `exitCode` require their own `.match({ ok, limited })`. Matching `exitCode` keeps a long command active during pauses in its output; unattended background commands can stop when the Sandbox becomes idle.
 
-To reach a server inside the container, call `sandbox.fetch(port, new Request(url))`. `sandbox.running()` checks whether the container is running; `sandbox.destroy()` stops it.
+Use `stdin: 'pipe'` for a writable input stream. `kill(signal?)` stops a process, and `resize(cols, rows)` resizes its terminal.
+
+File operations live under `sandbox.files`: `readFile`, `writeFile`, `stat`, `lstat`, `readDirectory`, `mkdir`, `rename`, and `remove`. Each file operation requires `.match({ ok, limited })`. `readFile()` yields a streaming `Response` to `ok`; use `.text()`, `.arrayBuffer()`, or `.body`. `writeFile()` accepts text, binary data, or a byte stream. Relative file paths require an explicit `cwd` option.
+
+To reach a server inside the container, call `sandbox.fetch(port, new Request(url)).match({ ok, limited })`. `sandbox.running()` checks whether the container is running; `sandbox.destroy()` stops it.
 
 `getSandbox()` options include `inactivityTimeoutMs` (default ten minutes, maximum six hours), `enableInternet` (default `false`), and string `labels`. Internet access and labels take effect on the next container start. `binding` selects a custom native binding; managed platforms use the configured binding.
 
 For code that runs on both deployment targets, use `getSandbox()`. Direct access through `c.env.SANDBOX` is available only on local and native Cloudflare deployments.
 
+The `limited` handler receives `resource: 'sandbox'`, a `reason` of `concurrency` or `runtime_budget`, and `response({ message })` for a structured HTTP 429. Keep user input available so it can be retried. Resolving a Sandbox, checking `running()`, stopping a process, and `destroy()` do not need a quota handler; cleanup remains available after a limit.
+
 ## State persistence
 
 `getSandbox(id)` selects the same Durable Object for that ID within a deployment. Native Cloudflare deployments preserve that namespace across Worker versions. Each managed platform deployment has its own namespace; rolling back to a retained deployment reconnects to that deployment's namespace.
 
-Files, running processes, and listening servers last only as long as the container. It can stop after inactivity, crash, or restart. Save anything you need to keep in your database, KV, or R2. For custom Durable Object implementations, `void/sandbox` also exports the SDK's `Files`, `DirectoryBackup`, `DirectoryBackupGateway`, `S3Mount`, and `S3Gateway` helpers. Deleting a project on a Void platform removes both its Durable Objects and containers.
+Files, running processes, and listening servers last only as long as the container. It can stop after inactivity, crash, or restart. Save anything you need to keep in your database, KV, or R2. Deleting a project on a Void platform removes both its Durable Objects and containers.
 
 ## Deployment
 
-Sandboxes require [Workers Paid](https://dash.cloudflare.com/?to=/:account/workers/plans) and Containers access. Void checks this before provisioning or building. A managed platform's runtime token needs Account / Containers: Edit and Account / Cloudchamber: Edit. Applications without Sandbox do not require Containers or perform this entitlement check.
+Sandboxes require [Workers Paid](https://dash.cloudflare.com/?to=/:account/workers/plans) and Containers access. A managed platform's runtime token needs Account / Containers: Edit and Account / Cloudchamber: Edit.
 
-`void deploy --platform cloudflare` builds native images and deploys the Sandbox alongside the application. `void deploy` on a connected Void Platform creates a deployment-scoped Sandbox controller, which enforces concurrency and runtime limits. Upgrade the platform before deploying an application built with this Sandbox API.
+`void deploy --platform cloudflare` builds native images and deploys the Sandbox alongside the application. `void deploy` on a connected Void Platform applies the platform's Sandbox concurrency and runtime limits. Upgrade the platform before deploying an application built with this Sandbox API.
 
 ## Moving from Sandbox SDK 0.x
 

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);
+```