void 1.3.0 → 1.5.0

package/docs/guide/platform/installation/maintenance.md

@@ -100,7 +100,9 @@ Repair recreates missing infrastructure that the installer owns. It does not res
 
 ### Upgrade the platform
 
-Keep the platform runtime current when updating the Void CLI.
+Upgrade the platform before your team updates its CLI. Install the new CLI on the administrator's machine, run the upgrade below, then have the team update.
+
+For apps using `void/sandbox`, add **Account → Containers → Edit** and **Account → Cloudchamber → Edit** to the runtime token. Edit its permissions in Cloudflare, or supply a replacement with `VOID_PLATFORM_RUNTIME_CLOUDFLARE_API_TOKEN`. See [Cloudflare API Tokens](/guide/platform/installation/credentials#runtime-token-permissions).
 
 Use the installed CLI's packaged runtime to upgrade:
 
@@ -113,11 +115,11 @@ An upgrade validates the runtime, applies supported pending migrations, deploys
 
 Before starting, Void checks access to the installation's Cloudflare account, Workers, and existing R2 buckets. If credentials are rejected, set `CLOUDFLARE_API_TOKEN` to a management token scoped to that account and retry. This overrides the installation's saved management token.
 
-Some upgrades pause application traffic during the cutover to the new version. Traffic resumes after the new version passes its health checks. If an upgrade or another lifecycle command fails after it paused traffic, traffic stays paused until a later run succeeds. To resume:
+Some upgrades pause application traffic until the new version passes health checks. If a command fails while traffic is paused:
 
 1. Run `void platform status <id>` to see the saved progress.
-2. Fix the problem that the error names.
-3. Run the resume command that the CLI printed. It is the same command, with the same runtime.
+2. Fix the reported problem.
+3. Run the printed resume command with the same runtime. Traffic resumes when it succeeds.
 
 ::: details Migration safety, credential rotation, and rollback
 
@@ -147,29 +149,13 @@ Let running rotations finish before you roll back. If an older proxy runs next t
 
 ### Platform Workers changed outside Void {#workers-changed-outside-void}
 
-Void manages the platform's own Workers. Do not change them in the Cloudflare dashboard or with the Cloudflare API. To change the platform, use the Void commands on this page.
-
-`upgrade`, `repair`, `enable`, `rollback`, and `install --resume` deploy the platform Workers again. Before they change a platform Worker or pause traffic, Void finds each platform Worker that:
-
-- was changed in the Cloudflare dashboard or with the Cloudflare API.
-- has an active version without a Void deployment record. This can occur when an earlier run replaced a change made outside Void, and then stopped or failed. If that run stopped during the cutover to the new version, the command first makes the earlier versions active again. Void checks those earlier versions too. A version that an older Void release deployed can also have no record.
-
-The `--plan` preview of `upgrade`, `repair`, `enable`, and `rollback` shows the same list as a warning.
-
-In a terminal, Void lists these Workers and asks **Replace the configuration of these Workers?** The default answer is No.
-
-- If you answer No, the command stops. No platform Worker changed, and the command did not pause traffic.
-- If you answer Yes, the command continues. First, Void prepares the platform resources and the database. Then, before it pauses traffic or deploys a Worker, the Cloudflare CLI asks you again for each Worker changed in the dashboard or with the API. For a dashboard change, it shows the differences. Void uploads a new version of each of these Workers and does not deploy it yet. For a Worker that has an active version without a Void deployment record, the Cloudflare CLI does not ask again.
-
-If you refuse in the Cloudflare CLI, the command stops. Void does not undo the resource and database changes. No deployment changed, and the command did not pause traffic.
-
-The replacement removes values that Void does not set, for example an `EMAIL_FROM` variable that you added. It also resets values that Void sets, for example `AUTH_REDIRECT_URI`.
+Use Void commands to manage the platform's Workers. If their configuration was changed in Cloudflare, or Void cannot identify the active version, maintenance asks you to approve replacing it. Preview the affected Workers with `--plan`.
 
-Without a terminal, for example in CI, or with `--yes`, the command stops before it changes a platform Worker, and it does not pause traffic. Run the command that Void prints once in a terminal, and answer the questions there. After that run completes, the command works in CI again.
+Run the printed command in a terminal and review **Replace the configuration of these Workers?** The default is No. Accepting restores Void's configuration, including removing manually added variables. You may see another confirmation with the configuration differences before deployment. Declining that later prompt leaves any resource and database preparation in place.
 
-If Void cannot read a platform Worker, the command also stops before it changes a platform Worker or pauses traffic. Run the command again. If a platform Worker has no single version that gets 100% of traffic, for example after a gradual deployment, deploy one version of it to 100% of traffic in the Cloudflare dashboard. Then run the command once in a terminal, so that you can approve the dashboard change.
+CI and `--yes` runs stop when this approval is needed. Complete the interactive command once, then resume automation. If a Worker uses a gradual deployment, first select one version for 100% of traffic in Cloudflare.
 
-If an earlier run failed after it paused traffic, traffic stays paused after these stops. To resume traffic, see [Upgrade the platform](#upgrade-the-platform).
+If traffic was already paused by an earlier failed run, follow [Upgrade the platform](#upgrade-the-platform) to resume it.
 
 ### Follow upgrade and rollback progress
 

package/docs/guide/platform/installation/prerequisites.md

@@ -37,7 +37,7 @@ If your account's dashboard has no **Enable** action, create a disposable Hello
 
 ## Install the CLI and Preview
 
-With Node.js 24.21.0 or later, install the CLI:
+With Node.js 24.22+ or 26.12+, install the CLI:
 
 ```sh
 pnpm add --global void

package/docs/guide/platform/installation/setup.md

@@ -260,6 +260,6 @@ You can also rerun `void platform install` and choose **Continue setup** for an
 
 Resume restores your selected Hyperdrive. If that selection is missing from the saved checkpoint, add `--hyperdrive <existing-id>` when resuming, using the same configuration you originally selected.
 
-If Cloudflare rejects a saved runtime token during continued credential setup, Void opens the token page and asks for a replacement in the same run. A missing [email permission](/guide/platform/installation/credentials#enable-email) does not discard the saved token: add the permission to the same token, then resume. Network or service failures do not discard saved tokens. Tokens supplied through the environment must be corrected there instead.
+If Cloudflare rejects a saved runtime token, Void opens the token page and asks for a replacement. For a missing [email permission](/guide/platform/installation/credentials#enable-email), update the existing token's permissions and resume. If you supplied a token through an environment variable, update that variable.
 
 :::

package/docs/guide/platform/installation/uninstall.md

@@ -91,7 +91,7 @@ If installation configured Cloudflare Access, the uninstall plan lists its recor
 
 Uninstall does not remove the applications created for [project Zero Trust](/guide/platform/administration/zero-trust). While Zero Trust is enabled or still has Access applications, uninstall and `--plan` stop before any change and list those applications. Run `void platform zero-trust disable` first. Uninstall reads this from the installation database, so it also stops when the database cannot be reached.
 
-If the installation database is permanently gone and cannot be restored, there is no uninstall command that can clear the local installation record or list its Cloudflare resources. Once you have decided not to recover that installation, delete `~/.void/platforms/<account-id>/<installation-id>.json` and any sibling `<installation-id>.recovery.enc` or `<installation-id>.secrets.enc` files. This removes only local state and encrypted credentials; it does not delete Cloudflare resources. Review and remove those resources manually using [Remove retained resources](#remove-retained-resources).
+If the installation database is permanently lost, [remove its Cloudflare resources manually](#remove-retained-resources). Once cleanup is complete, delete the local record at `~/.void/platforms/<account-id>/<installation-id>.json` and its sibling `<installation-id>.recovery.enc` and `<installation-id>.secrets.enc` files. These files contain installation metadata and encrypted credentials; deleting them leaves Cloudflare resources in place.
 
 If no platform user exists yet, for example because first administrator setup did
 not finish, nobody can run `zero-trust disable`. Uninstall then turns off project

package/docs/guide/queues.md

@@ -76,7 +76,7 @@ export default defineQueue<Message>(async (batch, env) => {
 - `batch.ackAll()`: acknowledge all messages in the batch
 - `batch.retryAll(options?)`: retry all messages in the batch
 
-The first call wins for each message. Calling `ack()` after `retry()`, or the reverse, does nothing. Messages with no explicit decision are acknowledged if the handler succeeds, or retried if it throws.
+The first `ack()` or `retry()` call wins for each message. Messages without an explicit decision are acknowledged when the handler succeeds and retried when it throws. Void logs handler errors automatically.
 
 The `timestamp` field on each message is a `Date` object.
 
@@ -118,15 +118,11 @@ Void provisions queues and connects their producers and consumers when you deplo
 
 ### Cloudflare queue names
 
-Queue names are unique per Cloudflare account. So `void deploy --platform cloudflare` names each queue after the Worker: in a Worker named `app-staging`, `queues/jobs.ts` uses the Cloudflare queue `app-staging-jobs` (a `_` in the Worker name becomes `-`). Two Workers in one account, such as `app-staging` and `app-production`, get separate queues. Your code keeps using the name from `queues/` (`queues.jobs.send()`), and `vp dev` uses that name too.
+With `void deploy --platform cloudflare`, queue names include the Worker name: `queues/jobs.ts` in `app-staging` creates `app-staging-jobs`. Underscores in the Worker name become hyphens. Your app uses `queues.jobs.send()` in every environment.
 
-The deploy stops before creating anything when:
+Keep the full name within 63 characters and unique within the account. Each Cloudflare queue supports one consumer; Void reports naming or consumer conflicts during deploy.
 
-- a new queue's full name is longer than 63 characters. Shorten the Worker name or the file name.
-- one queue's full name is the name of another file in `queues/`, such as `queues/jobs.ts` and `queues/app-jobs.ts` in Worker `app`. Rename one of the files.
-- another Worker already consumes the Cloudflare queue the deploy would use. A Cloudflare queue has one consumer.
-
-A queue that the Worker already consumes keeps its name, so an app deployed before Worker-named queues keeps its queue (for example `jobs`) and the messages in it. The deploy prints a note when it keeps a name. To move to the Worker-named queue, remove the Worker's consumer from the old queue in the Cloudflare dashboard, then deploy again. Messages that reach the old queue before that deploy finishes stay there, so do this when the app is not sending messages, and check that the old queue is empty before you delete it.
+Existing deployments keep their queues and messages. To adopt the new naming, pause producers, drain the old queue, remove its Worker consumer in Cloudflare, and redeploy. Check that the old queue is empty before deleting it.
 
 ## Local development
 

package/docs/guide/self-hosted-platform.md

@@ -6,11 +6,11 @@ outline: deep
 
 A Void platform lets your team deploy apps into a shared Cloudflare account. As an administrator, you install and maintain the platform. Developers connect the Void CLI to its URL, sign in through an enabled login method, and deploy their apps.
 
-If you're deploying an app for yourself, [deploy directly to Cloudflare](/integrations/cloudflare#deploy-to-your-own-cloudflare-account). You don't need to install a platform first.
+For an individual app, [deploy directly to Cloudflare](/integrations/cloudflare#deploy-to-your-own-cloudflare-account).
 
 The core platform supports GitHub, Google, generic OIDC, and Cloudflare Access login, CLI deploys, D1, KV, R2, Queues, cron jobs, Workers AI, WebSockets, SSE, ISR, routing, logs, and rollback.
 
-The core installation includes managed Sandboxes and an email gateway; email is enabled when you configure a shared mail domain and zone. The user dashboard, GitHub builds and webhooks, and build Containers aren't part of the core installation. [Project custom domains](/guide/platform/installation/domains#project-custom-domains) are opt-in with `--custom-domains`. Source-built platforms that add the optional GitHub services should follow the [isolated webhook ingress setup](/guide/platform/development/runtime#optional-github-webhook-ingress-for-access-protected-apis) when Access protects the API.
+The core installation also includes managed Sandboxes and an email gateway. Configure a shared mail domain and zone to enable email, and add `--custom-domains` for [project custom domains](/guide/platform/installation/domains#project-custom-domains). A user dashboard and managed GitHub builds require a [custom platform build](/guide/platform-development).
 
 ## Deployment features
 
@@ -26,7 +26,7 @@ Both targets use the same application APIs. A core platform adds shared access a
 | Application rollback                             | Worker versions                  | Retained platform deployments                 |
 | Typed Durable State and native Durable Objects   | Supported                        | Supported                                     |
 | Sandboxes                                        | Requires Workers Paid and Docker | Requires Workers Paid on the platform account |
-| Custom application domains                       | Supported                        | Unavailable in the core installation          |
+| Custom application domains                       | Supported                        | Enable with `--custom-domains`                |
 | Generated GitHub deployment workflow             | Supported                        | Use your CI with a scoped developer token     |
 | User dashboard and managed GitHub builds         | Not required                     | Not included in a standard installation       |
 

package/docs/guide/server-routing.md

@@ -12,7 +12,7 @@ Create route handlers in `routes/` using `.ts`, `.tsx`, `.js`, `.jsx`, `.mts`, o
 
 <RoutesFileTree />
 
-Dynamic segments use brackets: `[id]` becomes a route parameter and `[...slug]` becomes a catch-all. Files or directories starting with `_` are ignored, and so are those starting with `.`, except `.well-known`. Directories wrapped in parentheses like `(admin)` are route groups. They help organize files without changing the URL.
+Dynamic segments use brackets: `[id]` becomes a route parameter and `[...slug]` becomes a catch-all. Prefix files or directories with `_` or `.` to exclude them from routing; `.well-known` remains available for standard discovery endpoints. Directories wrapped in parentheses like `(admin)` are route groups. They help organize files without changing the URL.
 
 ### Environment-only routes
 
@@ -45,8 +45,8 @@ export const GET = defineHandler((c) => {
 A file can export multiple methods:
 
 ```ts
-import { users } from '@schema';
 // routes/api/users/index.ts  →  GET + POST /api/users
+import { users } from '@schema';
 import { defineHandler } from 'void';
 import { db } from 'void/db';
 
@@ -61,11 +61,13 @@ export const POST = defineHandler(async (c) => {
 });
 ```
 
+`GET` handlers also answer `HEAD` requests automatically.
+
 See [Database](./database.md) for queries with D1, PostgreSQL, or MySQL.
 
 ### JSX handlers
 
-Use `.tsx` or `.jsx` when a server handler contains JSX. Void doesn't choose a JSX runtime: route files compile with the same JSX settings as the rest of your Vite app. In a React or Solid app, that is the framework's JSX, so render it with the framework's server renderer and return HTML. For example, in a React app:
+Use `.tsx` or `.jsx` when a server handler contains JSX. Route files use your app's JSX settings. In React or Solid, render JSX to HTML with the framework's server renderer. For example, in React:
 
 ```tsx
 // routes/hello.tsx → GET /hello
@@ -75,7 +77,7 @@ import { defineHandler } from 'void';
 export const GET = defineHandler((c) => c.html(renderToStaticMarkup(<h1>Hello!</h1>)));
 ```
 
-In an app without a JSX framework (API only, Vue, or Svelte), use [Hono's JSX](https://hono.dev/docs/guides/jsx). Your app needs `hono` in its own dependencies (new Void apps have it). Set the runtime in `vite.config.ts`, so it applies to `.tsx` and `.jsx` files alike:
+For API-only, Vue, or Svelte apps, add `hono` as a dependency and configure [Hono's JSX](https://hono.dev/docs/guides/jsx) in `vite.config.ts`:
 
 ```ts
 // vite.config.ts
@@ -113,8 +115,8 @@ Return values are automatically converted:
 `defineHandler.withValidator()` adds input validation for `body`, `query`, and `params`. The recommended approach is to derive validators from your [Drizzle schema](./database.md#schema-derived-validators), which keeps validation in sync with the database.
 
 ```ts
-import { users, insertUserSchema } from '@schema';
 // routes/api/users/index.ts
+import { users, insertUserSchema } from '@schema';
 import { defineHandler } from 'void';
 import { db } from 'void/db';
 
@@ -252,8 +254,8 @@ defineHandler(middleware1, middleware2, handler);
 Middleware runs in order. Each can short-circuit (return a response without calling `next()`) or post-process (modify the response after `await next()`). Both `defineMiddleware`-wrapped functions and raw Hono `MiddlewareHandler` functions are accepted.
 
 ```ts
-import { cors } from 'hono/cors';
 // routes/api/stats.ts
+import { cors } from 'hono/cors';
 import { defineHandler } from 'void';
 
 export const GET = defineHandler(cors({ origin: 'https://app.example.com' }), (c) => ({

package/docs/guide/ssg.md

@@ -37,6 +37,14 @@ export async function getPrerenderPaths() {
 }
 ```
 
+## 404 pages
+
+Static builds that prerender at least one page include a default `404.html` in `dist/client/`. To provide your own, add `public/404.html` or prerender a page at `/404`.
+
+Fully static Void deployments serve this page for missing URLs with an HTTP 404 status by default. You can override this with [`routing.notFound`](../reference/config.md#routing-notfound). Hybrid deployments handle missing URLs in the Worker.
+
+When hosting `dist/client/` yourself, configure your host to serve `404.html` with a 404 status for missing pages.
+
 ## Comparison with edge prerendering
 
 | `output` value       | Default prerender | Per-page override                | Prerender timing           |

package/docs/guide/type-safety.md

@@ -102,6 +102,47 @@ const deleteForm = useForm('/users/:id?delete', { id: '' }, { params: { id } });
 
 The `action()` helper gets the same type checking. See [Actions & Forms](./pages-routing/actions-and-forms) for the full API.
 
+## Typed URLs and Navigation
+
+Use `routeUrl()` from `void/routes` to build URLs from your app's page, HTTP, and WebSocket route patterns. For a page at `pages/users/[id].tsx`, the pattern is `/users/:id`:
+
+```ts
+import { routeUrl } from 'void/routes';
+
+const url = routeUrl('/users/:id', {
+  params: { id: 42 },
+  query: { tab: 'activity' },
+  hash: 'details',
+});
+// /users/42?tab=activity#details
+```
+
+Your editor autocompletes route patterns and parameter names. TypeScript checks that the route exists and all required parameters are supplied. Parameter values accept strings or numbers; Void encodes them for the URL. Query keys are chosen by your app, and values can be strings, numbers, booleans, or arrays of those values. Arrays become repeated query parameters; `null` and `undefined` values are omitted.
+
+Pass the returned string to `Link`, a plain `<a>`, or `c.redirect()`. For programmatic navigation and `c.rewrite()`, you can pass a destination object directly:
+
+```ts
+import type { RouteDestination } from 'void/routes';
+
+const profile = {
+  pathname: '/users/:id',
+  params: { id: 42 },
+  query: { tab: 'activity' },
+  hash: 'details',
+} satisfies RouteDestination;
+```
+
+Destination objects use the same parameter checking and URL encoding as `routeUrl()`. See [Pages Routing](./pages-routing/overview.md#typed-navigation) for links and router methods, and [Rewrites](../reference/api/rewrites.md#c-rewrite-destination) for server navigation.
+
+For a catch-all page such as `pages/files/[...path].tsx`, use `/files/:path{.+}` and pass the full path as one value:
+
+```ts
+routeUrl('/files/:path{.+}', { params: { path: 'docs/get started' } });
+// /files/docs/get%20started
+```
+
+Route types update with the dev server. For CI or standalone typechecking, run `void prepare` and follow [Setup](#setup). The [API reference](../reference/api/types.md#void-routes) lists the URL helper and route types.
+
 ## What Gets Checked
 
 | Layer        | What's type-checked                                                                                                   |
@@ -109,6 +150,7 @@ The `action()` helper gets the same type checking. See [Actions & Forms](./pages
 | Database     | Table columns, value types, insert/update shapes from Drizzle schema                                                  |
 | Handlers     | `c.env` bindings, validator input, return type                                                                        |
 | Fetch client | Route paths, HTTP methods, `body`/`query`/`params`, response type                                                     |
+| Navigation   | Route patterns and required parameter names and values in `routeUrl()` and destination objects                        |
 | `useForm`    | Action URLs, `data` fields, `errors` keys, `reset()` args (including `{ initial: true }`), `params`, `resetOnSuccess` |
 | `action()`   | Action URLs, `data` payload, `params`                                                                                 |
 

package/docs/guide/typed-fetch.md

@@ -106,4 +106,4 @@ export default defineRender(async (c, assetTags) => {
 });
 ```
 
-Server-side calls to your app forward the incoming request's `cookie` and `authorization` headers. Explicit headers take precedence. Calls to an external `baseURL` use HTTP and do not inherit these headers.
+Server-side calls to your app forward the incoming request's `cookie` and `authorization` headers. Explicit headers take precedence. For an external `baseURL`, supply authentication headers explicitly.

package/docs/guide/websockets.md

@@ -32,7 +32,7 @@ Filename rules match regular server routes:
 - route groups like `(marketing)/chat.ws.ts` are ignored in the URL
 - `chat.dev.ws.ts` / `chat.prod.ws.ts` restrict the route to one environment
 
-The environment suffix goes **before** `.ws`. `chat.ws.dev.ts` is not a WebSocket route.
+Place the environment suffix **before** `.ws`, as in `chat.dev.ws.ts`.
 
 ## `defineRoom()`
 

package/docs/integrations/cloudflare.md

@@ -133,13 +133,14 @@ Apps using email need `email.from` in `void.config.ts`. Void reviews the domain'
 
 Set these CI secrets and variables as needed:
 
-| Name                                             | When needed                                                                                                   |
-| ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------- |
-| `CLOUDFLARE_API_TOKEN`                           | Required. Workers Scripts: Edit, read access to bound resources, and edit access to products Void provisions. |
-| `CLOUDFLARE_ACCOUNT_ID`                          | When the token can access several accounts.                                                                   |
-| `DATABASE_URL`                                   | PostgreSQL and MySQL provisioning and migrations.                                                             |
-| `CLOUDFLARE_WORKERS_SUBDOMAIN`                   | When the Worker has no version preview URL. Use `my-team` or `my-team.workers.dev`.                           |
-| `CF_ACCESS_CLIENT_ID`, `CF_ACCESS_CLIENT_SECRET` | When Cloudflare Access protects the readiness URL.                                                            |
+| Name                                             | When needed                                                                                                              |
+| ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------ |
+| `CLOUDFLARE_API_TOKEN`                           | Required. Workers Scripts: Edit, read access to bound resources, and edit access to products Void provisions.            |
+| `CLOUDFLARE_ACCOUNT_ID`                          | When the token can access several accounts.                                                                              |
+| `DATABASE_URL`                                   | PostgreSQL and MySQL provisioning and migrations.                                                                        |
+| `CLOUDFLARE_WORKERS_SUBDOMAIN`                   | When the Worker has no version preview URL. Use `my-team` or `my-team.workers.dev`.                                      |
+| `CF_ACCESS_CLIENT_ID`, `CF_ACCESS_CLIENT_SECRET` | When Cloudflare Access protects the readiness URL.                                                                       |
+| `CF_ACCESS_READINESS_ORIGIN`                     | When Access protects a route or Custom Domain and `workers_dev` is `false`. See [Cloudflare Access](#cloudflare-access). |
 
 For email, run `void email setup --platform cloudflare` locally, commit `void.lock.json`, and pass `--require-email` in CI. The token also needs Email Routing Edit and Email Sending Edit.
 
@@ -153,6 +154,14 @@ export CF_ACCESS_TOKEN="$(cloudflared access token --app=https://<worker>.<accou
 
 Void uses Access credentials for readiness checks without saving them. If checks are denied, the deployment fails. A first-deploy bootstrap can already be active behind Access when this happens.
 
+By default, Void sends Access credentials only to `workers.dev` URLs. If `workers_dev` is `false`, Void can check readiness through your first route or Custom Domain. To send the credentials there, set `CF_ACCESS_READINESS_ORIGIN` to that hostname's origin:
+
+```sh
+export CF_ACCESS_READINESS_ORIGIN="https://app.example.com"
+```
+
+Set this variable in the shell or CI environment running `void deploy`. Use an exact HTTPS origin for a hostname you control that serves this Worker; Void sends your Access credentials there.
+
 ### Databases and secrets
 
 For PostgreSQL and MySQL, supply `DATABASE_URL` to the deploy process. Void uses it for Hyperdrive and migrations without writing it to config. MySQL schema changes can partially apply before an error; see [failed MySQL migrations](../guide/database/mysql.md#failed-migrations).
@@ -184,7 +193,7 @@ void project status
 void project rollback [version]
 ```
 
-Void restores recorded triggers along with the code. Versions without a complete trigger snapshot keep current routes and schedules. Rollback does not reverse database migrations. To undo D1 migrations, run [`void db restore`](../reference/cli/database.md#void-db-restore) with the restore point that deploy printed before it applied them, within 7 days on Workers Free or 30 days on Workers Paid.
+Void restores recorded triggers along with the code. Versions without a complete trigger snapshot keep current routes and schedules. Database recovery is separate: use [`void db restore`](../reference/cli/database.md#void-db-restore) to undo D1 migrations.
 
 #### Scope and limitations
 

package/docs/integrations/frameworks/analog.md

@@ -109,8 +109,8 @@ Declare variables in `env.ts` and read them with `import { env } from "void/env"
 You can also access raw Cloudflare bindings via the H3 event context or the `cloudflare:workers` module:
 
 ```ts
-import { env } from 'cloudflare:workers';
 // src/server/routes/api/users.ts
+import { env } from 'cloudflare:workers';
 import { eventHandler } from 'h3';
 
 export default eventHandler(async () => {

package/docs/integrations/frameworks/nuxt.md

@@ -80,8 +80,8 @@ Void-managed auth is not supported in framework mode yet. Use Better Auth's offi
 ### Database
 
 ```ts
-import { users } from '@schema';
 // server/api/users.get.ts
+import { users } from '@schema';
 import { db } from 'void/db';
 
 export default defineEventHandler(async () => {

package/docs/integrations/frameworks/sveltekit.md

@@ -91,8 +91,8 @@ Void-managed auth is not supported in framework mode yet. Use Better Auth's offi
 ### Database
 
 ```ts
-import { users } from '@schema';
 // src/routes/users/+page.server.ts
+import { users } from '@schema';
 import { db } from 'void/db';
 
 export async function load() {

package/docs/integrations/frameworks/tanstack-start.md

@@ -92,7 +92,7 @@ export { Counter } from './counter';
 export default handler;
 ```
 
-Void preserves these named exports in development, production builds, and deploys. Without `cloudflare.main`, Void uses TanStack's default server entry. A package entry such as `@tanstack/react-start/server-entry` is resolved as a module.
+Void uses TanStack's default server entry unless you set `cloudflare.main`. You can also use a package entry such as `@tanstack/react-start/server-entry`.
 
 Bind an exported Durable Object or Workflow class under `cloudflare` as well, for example in `cloudflare.durable_objects`. These settings apply when you deploy with `void deploy --platform cloudflare`. On a Void platform, use [Durable State](../../guide/durable-state.md) instead.
 

package/docs/integrations/hono.md

@@ -17,16 +17,16 @@ Once `hono` is installed in your app, you can use built-in middleware, helpers,
 Use Hono's built-in middleware in your global middleware files or per-route:
 
 ```ts
-import { cors } from 'hono/cors';
 // middleware/01.cors.ts
+import { cors } from 'hono/cors';
 import { defineMiddleware } from 'void';
 
 export default defineMiddleware(cors({ origin: 'https://example.com' }));
 ```
 
 ```ts
-import { cache } from 'hono/cache';
 // routes/api/products.ts (per-route cache)
+import { cache } from 'hono/cache';
 import { defineHandler } from 'void';
 import { listProducts } from '../../lib/products';
 
@@ -41,8 +41,8 @@ export const GET = defineHandler(
 :::
 
 ```ts
-import { bearerAuth } from 'hono/bearer-auth';
 // routes/api/webhooks/stripe.ts (per-route usage)
+import { bearerAuth } from 'hono/bearer-auth';
 import { defineHandler } from 'void';
 
 export const POST = defineHandler(bearerAuth({ token: 'webhook-secret' }), async (c) => {
@@ -56,8 +56,8 @@ export const POST = defineHandler(bearerAuth({ token: 'webhook-secret' }), async
 Hono's context helpers are available on `c` in every handler:
 
 ```ts
-import { stream } from 'hono/streaming';
 // routes/api/download.ts
+import { stream } from 'hono/streaming';
 import { defineHandler } from 'void';
 
 export const GET = defineHandler((c) => {
@@ -84,8 +84,8 @@ export const GET = defineHandler((c) => {
 Any `hono/*` or `@hono/*` package works. Install the package in your app, then use it directly:
 
 ```ts
-import { rateLimiter } from 'hono-rate-limiter';
 // middleware/01.rate-limit.ts
+import { rateLimiter } from 'hono-rate-limiter';
 import { defineMiddleware } from 'void';
 
 export default defineMiddleware(rateLimiter({ windowMs: 60_000, limit: 100 }));

package/docs/reference/api/auth.md

@@ -79,7 +79,7 @@ function requireAuth(c: CloudContext): AuthUser;
 
 ## `AuthUser` {#authuser}
 
-Better Auth user shape re-exported by Void.
+Better Auth user shape re-exported by Void. It also includes the fields that Better Auth plugins and `user.additionalFields` in `auth.ts` add, for example `role` from `admin()` or a custom `plan` field. Your tsconfig needs the generated Void types for this; see [Type Safety setup](../../guide/type-safety.md#setup).
 
 ```ts
 interface AuthUser {
@@ -95,7 +95,7 @@ interface AuthUser {
 
 ## `AuthSession` {#authsession}
 
-Better Auth session shape re-exported by Void.
+Better Auth session shape re-exported by Void. It also includes the session fields that Better Auth plugins in `auth.ts` add, for example `impersonatedBy` from `admin()`.
 
 ```ts
 interface AuthSession {
@@ -110,6 +110,10 @@ interface AuthSession {
 }
 ```
 
+::: tip Types inside `auth.ts`
+In `auth.ts` and its imports, let Better Auth infer hook types or use its `User` and `Session` types. Using Void's inferred auth types or auth helper results there creates a circular reference. Callbacks such as `sendResetPassword` receive Better Auth's base `User` type.
+:::
+
 ## `AuthState` {#authstate}
 
 Combined authenticated request state:

package/docs/reference/api/deploy.md

@@ -8,7 +8,7 @@ Build the app in managed mode inside its isolated environment:
 VOID_DEPLOY_BUILD=1 VOID_DEPLOY_PROJECT_ID=artifact npm run build
 ```
 
-These values select a platform-compatible build. `artifact` is a build marker, not an existing project ID or a credential; the target project is selected during publish approval.
+These values select a platform-compatible build. The target project is selected during publish approval.
 
 ```ts
 import { prepareDeployArtifact } from 'void/deploy';
@@ -16,9 +16,9 @@ import { prepareDeployArtifact } from 'void/deploy';
 const { artifact, assets } = await prepareDeployArtifact('/path/to/app');
 ```
 
-`artifact` contains the deployment manifest, content-addressed asset metadata, and base64 Worker modules when the app needs a Worker. SPAs and static sites contain only assets, using the same app detection, output directory and routing configuration as `void deploy`. `assets` maps asset URL paths to base64 bytes. Keep this result immutable while requesting [publish approval](/guide/platform/administration/connected-apps).
+`artifact` contains the deployment manifest, asset metadata, and any Worker modules. `assets` maps asset URL paths to base64 bytes. SPAs and static sites use the same output directory and routing configuration as `void deploy`. Keep the prepared result unchanged while requesting [publish approval](/guide/platform/administration/connected-apps).
 
-Preparation packages existing build output; it does not build, contact a platform, provision resources, or deploy. It supports Void Cloudflare Worker builds, SPAs, and static sites. Node targets, Pages `output: 'static'`, remote data, deploy-time prerendering, Sandbox, and Live resources require the normal `void deploy` workflow instead.
+Use this API for built Cloudflare Worker apps, SPAs, and static sites. For Node targets, Pages `output: 'static'`, remote data, deploy-time prerendering, Sandbox, or Live resources, use `void deploy`.
 
 Run preparation inside the same isolated environment as the app build. App configuration and build plugins execute project code; keep platform credentials on the publishing server.
 
@@ -28,12 +28,15 @@ Run preparation inside the same isolated environment as the app build. App confi
 `prepareCfBuildOutput` follows Cloudflare's draft Build Output format. Its options and the prepared directory can change between Void releases.
 :::
 
-Use `prepareCfBuildOutput` to convert an existing Cloudflare Worker build into a disposable Cloudflare Build Output directory:
+Use `prepareCfBuildOutput` to prepare an existing Worker build for Cloudflare publication:
 
 ```ts
 import { prepareCfBuildOutput } from 'void/deploy';
 
-const prepared = await prepareCfBuildOutput('/path/to/app/dist/server', { mode: 'staging' });
+const prepared = await prepareCfBuildOutput('/path/to/app/dist/server', {
+  projectRoot: '/path/to/app',
+  mode: 'staging',
+});
 if (!prepared) {
   throw new Error('The Worker build could not be prepared.');
 }
@@ -45,11 +48,12 @@ try {
 }
 ```
 
-Pass the Worker output directory that contains a generated `wrangler.json`, such as `dist/ssr`, `dist/rsc`, or `dist/server`. When Cloudflare's build tooling built the app, pass the project root that contains its native Build Output at `.cloudflare/output/v0` instead. Preparation copies modules and assets without changing that input. Native output keeps its module types, auxiliary Workers, Container declarations, and build metadata. Preparation does not provision resources, upload a Worker, or activate a deployment. Container images built from a local Dockerfile exist only in the Docker environment that built them, so publish from that environment.
+Pass a Worker output directory containing a generated `wrangler.json`, such as `dist/ssr` or `dist/server`. For native Cloudflare Build Output, pass the project root containing `.cloudflare/output/v0`. The result is a temporary copy for your publication workflow. For Containers built from a local Dockerfile, publish from the same Docker environment used to build the image.
 
-| Option      | Description                                                                                                                                          |
-| ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `accountId` | Cloudflare account the build must target. A different account in the build returns `null`. When omitted, the build's account is kept or left unset.  |
-| `mode`      | Vite build mode. Native output keeps the mode it was built with, and a different value returns `null`. For other output it defaults to `production`. |
+| Option        | Description                                                                                                                                          |
+| ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `accountId`   | Cloudflare account the build must target. A different account in the build returns `null`. When omitted, the build's account is kept or left unset.  |
+| `mode`        | Vite build mode. Native output keeps the mode it was built with, and a different value returns `null`. For other output it defaults to `production`. |
+| `projectRoot` | App directory containing `package.json` and its installed dependencies. Defaults to the input directory.                                             |
 
-The result contains `directory`, an optional `assetsDirectory` pointing to the input assets, and an asynchronous `dispose()` method. Always dispose the result after use. Unsupported build configuration returns `null`. A directory without a Worker build, a missing or invalid Worker module, or an asset symlink outside the asset directory throws an error.
+The result provides `directory`, an optional `assetsDirectory` pointing to the input assets, and an async `dispose()` method. Dispose the result after publication. Unsupported configurations return `null`; missing or invalid build files throw an error.

package/docs/reference/api/pages.md

@@ -6,6 +6,14 @@ outline: deep
 
 Framework adaptors for [Pages Routing](../../guide/pages-routing/overview). Each adaptor provides a Vite plugin and client-side runtime.
 
+## Navigation destinations {#navigation-destinations}
+
+All four adapters support typed URLs through [`routeUrl()`](./types.md#routeurl-path-options). Pass the returned string to `Link`'s `href`.
+
+The router's `visit(destination, options?)`, `prefetch(destination, options?)`, and `flush(destination, method?)` accept [`RouteUrlInput`](./types.md#route-types): a string, `URL`, or typed destination object.
+
+See [Typed navigation](../../guide/pages-routing/overview.md#typed-navigation) for framework examples.
+
 ## `@void/vue` {#void-vue}
 
 ### `voidVue(options?)` {#voidvue-options}
@@ -109,6 +117,8 @@ Imported from `"@void/react"`.
 
 React `Link` GET `data` is merged into the rendered `href` query string. Primitive values are serialized with `String(value)`, arrays become repeated keys, `null` and `undefined` are omitted, and nested objects throw. `prefetch` and `reloadDocument` are GET-only and throw for mutation links.
 
+React `useForm()` accepts `onSuccess?: () => void | Promise<void>` and `onError?: (error: Record<string, string> | VoidActionError) => void | Promise<void>`. `pending` stays true until callbacks finish. See [submission callbacks](../../guide/pages-routing/actions-and-forms.md#react-submission-callbacks).
+
 React deferred props returned from `defer()` are Suspense resources. Read them
 with React's `use()` inside a `<Suspense>` boundary. React Pages requires React
 19 and uses streaming SSR for the initial deferred shell. Rejections throw from

package/docs/reference/api/plugin.md

@@ -16,10 +16,10 @@ export default defineConfig({
 });
 ```
 
-| Option             | Type                      | Description                                                                                                                                                                                                                       |
-| ------------------ | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `persistTo`        | `string`                  | Directory path for persisting local dev state (D1, KV, R2). Defaults to `.void/` in the project root.                                                                                                                             |
-| `auxiliaryWorkers` | `AuxiliaryWorkerConfig[]` | Additional workers to run inside the same Miniflare instance during dev. Passed through to `@cloudflare/vite-plugin`. Useful for running multiple workers that share bindings (e.g. a separate API worker alongside a dashboard). |
+| Option             | Type                      | Description                                                                                                                                                                                                                                 |
+| ------------------ | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `persistTo`        | `string`                  | Directory path for persisting local dev state (D1, KV, R2). Defaults to `.void/` in the project root.                                                                                                                                       |
+| `auxiliaryWorkers` | `AuxiliaryWorkerConfig[]` | Additional Workers to run alongside your app, such as a separate API Worker and dashboard that share bindings. Each entry accepts `configPath` (JSON, JSONC, or TOML), `config` (settings or a callback), `viteEnvironment`, and `devOnly`. |
 
 ## Project configuration {#project-configuration}
 

package/docs/reference/api/resources.md

@@ -128,6 +128,9 @@ import { logger } from 'void/log';
 
 logger.info('checkout completed', { orderId, userId });
 logger.error('webhook failed', { provider: 'stripe', attempt: 3 });
+
+const log = logger.child({ component: 'queue', queue: 'tasks' });
+log.info('task.started', { taskId });
 ```
 
-**Methods:** `logger.error(message, fields?)`, `logger.warn(message, fields?)`, `logger.info(message, fields?)`.
+**Methods:** `logger.error(message, fields?)`, `logger.warn(message, fields?)`, `logger.info(message, fields?)`, `logger.child(fields)`.