void 0.24.0 → 0.26.0

package/skills/void/docs/guide/database/d1.md

@@ -6,12 +6,6 @@ outline: deep
 
 [Cloudflare D1](https://developers.cloudflare.com/d1/) is Void's default SQLite database. Start with a [schema](../database.md#schema-definition); Void manages the database locally and when you deploy.
 
-## Read replication
-
-Void enables [D1 read replication](https://developers.cloudflare.com/d1/best-practices/read-replication/) when it provisions a database. To enable it on an existing database, run `void deploy --platform cloudflare --provision`. Queries through `db` from `void/db` use a D1 session for each Void request, so reads can run near the request and later queries in that request see at least the same data. Framework handlers without Void's request scope start each database operation on the primary. `createDb` starts a replica-capable session for the binding you pass it.
-
-Replicas can lag between requests. Authentication session checks start on the primary so a revoked session is not accepted because of replica lag. If another read must start with the latest primary data, use `env.DB.withSession('first-primary')` from `cloudflare:workers`. Other query libraries and raw D1 calls need their own `withSession()` to use replicas; a bare D1 binding reads from the primary.
-
 ## Local Database
 
 `void dev` and local `void db` commands share the same database. If `cloudflare.d1_databases` in `void.config.ts` declares the D1 binding, Void uses its ID. A `preview_database_id` takes precedence during local development.
@@ -44,6 +38,12 @@ await db.batch([
 ]);
 ```
 
+## Read replication
+
+Void enables [D1 read replication](https://developers.cloudflare.com/d1/best-practices/read-replication/) when it provisions a database. To enable it on an existing database, run `void deploy --platform cloudflare --provision`. Queries through `db` from `void/db` use a D1 session for each Void request, so reads can run near the request and later queries in that request see at least the same data. Framework handlers without Void's request scope start each database operation on the primary. `createDb` starts a replica-capable session for the binding you pass it.
+
+Replicas can lag between requests. Authentication session checks start on the primary so a revoked session is not accepted because of replica lag. If another read must start with the latest primary data, use `env.DB.withSession('first-primary')` from `cloudflare:workers`. Other query libraries and raw D1 calls need their own `withSession()` to use replicas; a bare D1 binding reads from the primary.
+
 ## Alternative Query Layers
 
 Use `env.DB` from `cloudflare:workers` with another query library or the raw D1 API:
@@ -69,5 +69,5 @@ const { results } = await env.DB.prepare('SELECT * FROM users WHERE id = ?').bin
 Void still handles binding inference and deployment regardless of which query layer you use.
 
 ::: warning ⚠️ Meta framework limitation
-Nuxt and SvelteKit do not support `cloudflare:workers` imports during local development. Use `void/db` or your framework's binding access API.
+Nuxt and SvelteKit 2 do not support `cloudflare:workers` imports during local development. Use `void/db` or your framework's binding access API. SvelteKit 3 supports these imports.
 :::

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

@@ -361,6 +361,21 @@ npm install arktype
 
 See the [CLI reference](../reference/cli/database.md#database) for connection setup, SQL execution, Studio, exports, and other commands.
 
+## Hand-written migrations {#hand-written-migrations}
+
+Deploy compares your Drizzle schema with the snapshots in `db/migrations/meta/`. If you have SQL migrations without this metadata, running `void db generate` would create another migration for the same tables.
+
+To keep an existing migration history:
+
+1. Make your Drizzle schema match the tables your SQL migrations create.
+2. In a scratch copy of the project, remove `db/migrations/` and run `void db generate`.
+3. Copy the generated `meta/` folder into your original migration directory. In `_journal.json`, replace `entries` with an entry for each existing SQL file in order. Use consecutive `idx` values starting at `0`, the file name without `.sql` as `tag`, increasing timestamps as `when`, and the generated entry's `version`. Set `breakpoints` to whether the file uses `--> statement-breakpoint` lines.
+4. Rename the generated snapshot to `<prefix>_snapshot.json`, where `<prefix>` is the part of the last migration tag before its first `_`. For `001_create_users.sql`, use `001_snapshot.json`.
+
+Review and commit the metadata, then run `void deploy` again. If no database has applied the SQL yet, you can instead replace it with migrations from `void db generate`.
+
+For D1 migrations containing triggers, add a `--> statement-breakpoint` line after each complete SQL statement, including the trigger's closing `END;`. Keep the trigger body together.
+
 ## Scaffolding
 
 The `void gen model` command generates dialect-appropriate `sqliteTable`, `pgTable`, or `mysqlTable` definitions.

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

@@ -4,180 +4,114 @@ outline: deep
 
 # Deployment
 
-`void deploy` builds your app, provisions its resources, applies migrations, and deploys it to your own Cloudflare account or a Void platform run by your team.
+`void deploy` builds your app, provisions resources, applies migrations, and deploys it. Choose your own Cloudflare account or a Void platform run by your team.
 
-You can [install a Void platform](./self-hosted-platform.md) for shared team deployments.
+After a successful deployment, Void prints your deployment URL in a summary box with the details reported by your deployment target.
 
-## Deployment Targets
+## Deploy to Cloudflare
 
-Both targets use the same application APIs. Their deployment features differ:
+Choose Cloudflare during `void init`, or connect later:
 
-| Feature                                          | Direct Cloudflare                | Core self-hosted platform                     |
-| ------------------------------------------------ | -------------------------------- | --------------------------------------------- |
-| Static sites, SPAs, and native Pages SSR         | Supported                        | Supported                                     |
-| Routing rules, WebSockets, queues, cron, and ISR | Supported                        | Supported                                     |
-| D1, KV, R2, and external SQL through Hyperdrive  | Supported                        | Supported                                     |
-| Workers AI and provider requests                 | Your account and gateway         | Installation gateway and proxy                |
-| Runtime logs                                     | Live Cloudflare tail             | Retained platform logs                        |
-| Application rollback                             | Worker versions                  | Retained platform deployments                 |
-| Typed Durable State                              | Supported                        | Unavailable                                   |
-| Sandboxes                                        | Requires Workers Paid and Docker | Requires Workers Paid on the platform account |
-| Custom application domains                       | Supported                        | Unavailable in the core installation          |
-| 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       |
-
-Native apps can run on Workers Free within its quotas. A team platform requires Workers for Platforms and the [documented infrastructure](./platform/installation/domains.md#cloudflare-footprint). Rollback does not reverse database migrations.
-
-Native Void apps and static sites use Void routing rules. Framework deployments use their framework's routing and asset policies; direct deploy rejects unsupported Void rules.
-
-Use matching CLI and framework adapter versions. For a team platform, the available features depend on its installed version and configuration. Ask your administrator if a feature is unavailable or an upgrade is required.
-
-## CLI
-
-### First deploy
-
-```bash
-void init   # choose Cloudflare (default), Void, or Skip deployment setup
-void deploy # builds and deploys to the saved platform
+```sh
+void connect --platform cloudflare
+void deploy --platform cloudflare
 ```
 
-During setup, Void asks where you want to deploy:
-
-- **Cloudflare:** sign in through your browser and choose an account. Void saves the account in `void.config.ts` or `void.lock.json`.
-- **Void:** connect to a platform, sign in, and link or create a project.
-- **Skip:** set up deployment later with `void connect`.
-
-Your choice is saved in `.void/project.json`, so the next deploy is just `void deploy`.
-
-Already have a Cloudflare Worker and a root `wrangler.jsonc` or `wrangler.json`? Run `void deploy`. If no destination is selected, Void offers to link and deploy using the existing Worker and resources. Accept once to keep deploying to that site. See [Deploy an existing Worker](../integrations/cloudflare.md#deploy-an-existing-worker) for the first-deployment checks.
+Void opens your browser to sign in and asks which account to use. Later deploys use the saved target, so you can run `void deploy`.
 
-To set up deployment later, use `void connect --platform cloudflare` or `void connect <platform-url>`.
-
-Owners can [share a platform project](./project-collaboration.md) with readers, collaborators, and project administrators. This does not apply to direct Cloudflare deployments.
-
-### Deploy to another Void platform
-
-Connect to the additional platform once, then select it for the deployment:
-
-```sh
-void connect https://second.example.com
-VOID_API_URL=https://second.example.com void deploy --platform void --project my-app
-```
+Native apps work on Workers Free within its quotas. [Sandboxes](./sandboxes.md#requirements) require Workers Paid and Containers access. See the [Cloudflare guide](../integrations/cloudflare.md) for configuration, token permissions, and features with additional requirements.
 
-Void uses `my-app` on that platform and offers to create it if needed. Your saved
-destination stays unchanged, including when a new project is created or deployment
-fails. The next plain `void deploy` still uses your original destination.
+If you already have a Worker and a root `wrangler.jsonc` or `wrangler.json`, `void deploy` can link it and preserve its resources. See [Deploy an existing Worker](../integrations/cloudflare.md#deploy-an-existing-worker).
 
-Pass `--project` or `VOID_PROJECT` when selecting a different platform; project links
-belong to their original platform. Each platform has its own projects, secrets, and
-data. For an app without a saved destination, its first deployment still saves a link.
+## Prepare your app
 
 ### Migrations
 
-Deploy applies pending SQL migrations from `db/migrations/`. If your schema has changes without a migration, deploy stops. Run `void db generate`, review and commit the SQL, then deploy again. See the [Database guide](./database.md).
+Deploy applies pending SQL migrations from `db/migrations/`. If your schema has changes without a migration, deploy stops:
 
-### Flags
-
-```bash
-void deploy [--platform <cloudflare|void>] [--project <name>] [--dir <path>] [--spa]
+```sh
+void db generate
 ```
 
-| Flag                            | Purpose                                           |
-| ------------------------------- | ------------------------------------------------- |
-| `--platform <cloudflare\|void>` | Override the saved deployment platform            |
-| `--project <name>`              | Target a specific Void project by slug            |
-| `--dir <path>`                  | Deploy a pre-built static directory (skips build) |
-| `--spa`                         | Use SPA mode instead of SSG for static deploys    |
-
-### Project resolution
+Review and commit the SQL, then deploy again. Rollback does not reverse database migrations. See [Database](./database.md) for the local workflow.
 
-For a Void platform deploy, the CLI chooses the project in this order:
-
-1. `--project <name>` flag
-2. `VOID_PROJECT` environment variable
-3. Linked project in `.void/project.json`
+### Environment variables
 
-If none is set, Void asks you to choose a project. Direct Cloudflare deploys use the Worker and account saved in your Cloudflare config.
+Declare values in `env.ts` and set production server secrets with `void secret put`. Deploy never uploads your local `.env`. Supply public `VITE_*` values through the build environment. See [Environment Variables](./env-vars.md).
 
-### CI preparation
+Keep the CLI and framework adapters on matching versions, and commit `void.config.ts` and `void.lock.json` when generated.
 
-For a Void platform, run `void connect "$VOID_API_URL" --no-login` in each fresh
-CI environment before deployment. Set `VOID_API_URL` to the platform you selected;
-there is no default hosted platform. The generated GitHub Actions workflow
-includes this connection step.
+## Deploy from GitHub {#github}
 
-If your CI pipeline runs typechecking or other static analysis before deploy, run `void prepare` after install to generate the `.void/` artifacts without booting Vite.
+Generate a workflow for your saved target and package manager:
 
-### Environment variables
+```sh
+void init --github
+```
 
-| Variable       | Purpose                          |
-| -------------- | -------------------------------- |
-| `VOID_TOKEN`   | Auth token (for CI, skips OAuth) |
-| `VOID_PROJECT` | Project slug override            |
+For Cloudflare, add `CLOUDFLARE_API_TOKEN` to your repository secrets. The token needs access to the account and products your app uses. PostgreSQL and MySQL apps also need `DATABASE_URL`.
 
-## GitHub
+Follow the [Cloudflare CI setup](../integrations/cloudflare.md#deploying-from-ci) for Worker preview URLs and Cloudflare Access credentials.
 
-You can deploy from a GitHub repo on every push to `main`. Running `void init --github` generates `.github/workflows/void-deploy.yml` for the platform saved in `.void/project.json`.
+### Team platform CI
 
-For Cloudflare, add `CLOUDFLARE_API_TOKEN` to your repository secrets. The token needs access to the account and products your app uses. PostgreSQL and MySQL apps also need a `DATABASE_URL` secret.
+For a core self-hosted platform, use your own workflow with a [project deploy token](./platform/installation/first-deployment.md). Set `VOID_TOKEN`, `VOID_API_URL`, and the project slug, then connect in each fresh CI environment:
 
-If your Worker has no version preview URL, set the `CLOUDFLARE_WORKERS_SUBDOMAIN` repository variable. If Cloudflare Access protects the Worker, also add `CF_ACCESS_CLIENT_ID` and `CF_ACCESS_CLIENT_SECRET` secrets so Void can check that a deployment is ready. See [Cloudflare deployment](../integrations/cloudflare.md#deploy-to-your-own-cloudflare-account) for the setup details.
+```sh
+void connect "$VOID_API_URL" --no-login
+void deploy --platform void --project "$VOID_PROJECT"
+```
 
-Void platforms with GitHub Actions support use short-lived GitHub OIDC credentials. You don't need to store a `VOID_TOKEN` for that workflow.
+Platforms with the optional GitHub Actions integration use short-lived OIDC credentials. Authorize the repository with `void github connect <project> --repo <owner/repo> --executor github_actions`, set the repository's `VOID_API_URL`, and keep `permissions: id-token: write` in the generated workflow.
 
-### Void GitHub App
+If your platform supports managed GitHub builds, the GitHub App can deploy on push without a workflow file. See [GitHub commands](../reference/cli/github.md#github) to install the App and connect your repository.
 
-If your platform supports managed GitHub builds, the Void GitHub App can build and deploy your app when you push. This feature requires a platform with a configured GitHub App and build Containers; it isn't included in a core self-hosted installation.
+If CI runs typechecking before deploy, run `void prepare` after installing dependencies to generate the `.void/` types.
 
-You don't need a deployment workflow file or a repository `VOID_TOKEN` for this path.
+## Deploy to a team platform
 
-With a linked project, connect the repository:
+Use the API URL from your administrator. In a new or unlinked app:
 
 ```sh
-void github install
-void github connect --executor container
-void github status
+void connect https://platform.example.com
+void deploy --platform void --project my-app
 ```
 
-If your organization already installed the App, Void can join that installation during setup. Organization repositories require browser authorization.
+Sign in and confirm project creation when asked. To use an existing project, run `void project link`. Later deploys use the saved destination.
 
-Push to the configured branch to deploy, then follow progress with `void build logs --follow`. See [GitHub commands](../reference/cli/github.md#github) for installation sharing and connection options.
+Project owners can [share access](./project-collaboration.md). To install a platform for your team, start with [Install a Void Platform](./self-hosted-platform.md), which also compares the deployment features of both targets.
 
-### GitHub Actions
+### Deploy to another Void platform
 
-Run `void init --github` to generate the workflow for your saved platform and package manager. On Void platforms with GitHub Actions support, authorize the repository once:
+For a single deployment to a different platform, connect and name its project:
 
 ```sh
-void github connect <project> --repo <owner/repo> --executor github_actions
+void connect https://second.example.com
+VOID_API_URL=https://second.example.com void deploy --platform void --project my-app
 ```
 
-Set the repository's `VOID_API_URL` variable to your platform's API URL. Keep `permissions: id-token: write` in the workflow for [GitHub OIDC](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect). The workflow uses your linked project, or the `VOID_PROJECT` repository variable.
-
-Core self-hosted installations do not support this integration. Use your own CI workflow with a [project deploy token](./platform/installation/first-deployment.md).
-
-## Other Targets
+This keeps your saved destination. Each platform has its own projects, secrets, and data. See the [CLI reference](../reference/cli/deploy.md) for target selection and other flags.
 
-### Your own Cloudflare account
+## Logs and rollback
 
-Select Cloudflare during setup, or run `void deploy --platform cloudflare`. See the [Cloudflare guide](../integrations/cloudflare.md) for configuration, CI credentials, and deployment limits.
+Inspect your deployment, read runtime logs, or select a previous deployment:
 
-### Node.js, Bun, and Deno
+```sh
+void project status
+void project logs
+void project rollback
+```
 
-Set [`target`](../reference/config.md#target) in `void.config.ts` to build a standalone server for Node.js, Bun, or Deno. You can run the result on your own server or in a container.
+Cloudflare logs use a live tail; team platforms retain log history. Before rolling back, check that the earlier code works with your current database schema. See [Project commands](../reference/cli/project.md).
 
-Deploy `dist/ssr` and `dist/client` together. See the target guide for startup commands.
+## Other runtimes
 
-These targets don't provide Cloudflare bindings such as D1, KV, R2, and Workers AI. See the [Node.js, Bun, and Deno guide](../integrations/nodejs-bun-deno.md) for the features available on each target.
+Build a standalone server for [Node.js, Bun, or Deno](../integrations/nodejs-bun-deno.md) using the `target` setting. Deploy `dist/ssr` and `dist/client` together using your own hosting. Cloudflare bindings such as D1, KV, R2, and Workers AI are unavailable on these targets.
 
 ## Usage and execution limit pages
 
-Void platforms show a built-in page when an app exhausts its request allowance or an invocation exceeds its CPU limit. API requests and Pages action requests receive a structured HTTP 429 with `code: 'usage_limit'`, `resource`, `reason`, and `message`.
-
-To customize browser error pages, add either optional file to your app's public assets:
-
-- `public/usage-limit.html` for exhausted request allowances.
-- `public/execution-limit.html` for execution limits.
+Team platforms return a structured HTTP 429 to API and Pages action requests when an app exceeds its request or CPU allowance. Browser requests get an error page.
 
-Use standalone HTML with inline CSS and data-URL images. These pages run with scripts, external assets and form submissions disabled, so they remain usable while application requests are blocked. Void serves them directly from the deployed assets; your Worker, loaders and database are not involved. A missing or unreadable custom page uses the built-in page.
+To customize it, add `public/usage-limit.html` for request limits or `public/execution-limit.html` for execution limits. Use standalone HTML with inline CSS and data-URL images. Scripts, external assets, and form submissions are disabled. Missing custom pages use the built-in page.
 
-Responses are not cached. Once a streaming response has started, it cannot be replaced with an error page; clients should display stream failures and end their pending state. These platform pages apply to Void platform deployments. Direct Cloudflare runtime limits use Cloudflare's own response behavior.
+Responses are not cached. A streaming response that has already started cannot be replaced with an error page; handle stream failures in your UI.

package/skills/void/docs/guide/env-vars.md

@@ -39,7 +39,7 @@ STRIPE_KEY=sk_test_example
 VITE_API_ORIGIN=http://localhost:5173
 ```
 
-Keep `.env` out of Git. Other dotenv files, including `.env.local`, `.env.production`, `.env.example`, and Wrangler’s `.dev.vars*`, are not supported. See [Environment migration](./env-migration.md) if your app uses them.
+Keep `.env` out of Git. Other dotenv files, including `.env.local`, `.env.production`, `.env.example`, and Wrangler’s `.dev.vars*`, are not supported.
 
 Run the local check at any time:
 
@@ -105,7 +105,3 @@ Invalid-value diagnostics redact the supplied value by default. Set `VOID_ENV_UN
 ## Imports inside `env.ts`
 
 Use relative imports or package names inside `env.ts`. TypeScript path aliases and imports that need Vite transforms are not supported.
-
-## Migrating from the multi-file model
-
-See [Environment migration](/guide/env-migration) for the breaking-change checklist.

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

@@ -4,34 +4,35 @@ outline: deep
 
 # What is Void?
 
-Void adds server routes, typed data access, and deployment to Vite apps. Native Void apps run on Cloudflare Workers. You can also use Void with a [supported framework](../integrations/frameworks/overview).
+Void is a full-stack framework for Cloudflare Workers, powered by Vite. Build your UI with React, Vue, Svelte, or Solid, and write server code in the same project. Void connects routing, data access, and deployment while keeping types shared across your app.
 
-Start with the [Quickstart](./quickstart) to create an app, run it locally, and deploy it.
+Start with the [Quickstart](./quickstart.md) to create and deploy an app. If you already use a meta framework, follow its [integration guide](../integrations/frameworks/overview.md).
 
-The CLI and build tools require Node.js 24.21.0 or later.
+## Server routes and pages
 
-## Resources from your code
+Files define routes. A handler in `routes/api/users.ts` serves `/api/users`; a component in `pages/users/index.tsx` renders `/users`.
+
+Each page can have a companion `.server.ts` file. Its **loader** reads data and returns typed props to the component. Its **actions** handle forms and other mutations, then update the page. Server code stays on the server; components render there initially and run in the browser for navigation and interaction.
 
-Import `db` from `void/db`, and Void provides a local database and provisions one for deployment. The same pattern applies to KV, object storage, queues, and AI. Configure resources explicitly when you need to use existing infrastructure.
+Use [Pages routing](./pages-routing/overview.md) for a full-stack UI, or keep your own client-side router and call [server routes](./server-routing.md) with [typed fetch](./typed-fetch.md). You can also build an API without a frontend.
+
+## Resources from your code
 
-Your Drizzle schema defines database types. Route handlers infer return types, and the [typed fetch client](./typed-fetch.md) checks calls from the frontend. Changing a field shows you which callers need to change.
+Import `db` from `void/db` to query your database. Void provides a local database during development and provisions one when you deploy. Imports also enable resources such as [KV](./kv.md), [object storage](./storage.md), and [queues](./queues.md). Use configuration when you need to connect existing resources.
 
-Void connects these parts of your app:
+Your Drizzle schema defines database types. Handlers infer response types, and typed fetch checks their callers. Page loaders and actions carry the same types into components and forms. Changing a field shows you which parts of the app need to change.
 
-- [Server routes](./server-routing.md) and [pages](./pages-routing/overview.md) for your app's backend and UI
-- [Database](./database.md), [KV](./kv.md), and [storage](./storage.md) that work locally and in production
-- [Standard Schema](https://standardschema.dev/) validation for runtime values and TypeScript types
-- `void deploy` to build, apply migrations, provision resources, and deploy
+## From local development to production
 
-## Deployment targets
+Vite runs your app locally with Cloudflare's runtime. `void deploy` builds it, provisions resources, applies database migrations, and publishes it. [Environment variables](./env-vars.md) use a schema, local values, and production secrets.
 
-Deploy to [your own Cloudflare account](../integrations/cloudflare.md#deploy-to-your-own-cloudflare-account) or to a [Void platform](./self-hosted-platform.md) run by your team. Both use the same SDK and CLI.
+Deploy to [your own Cloudflare account](./deployment.md#deploy-to-cloudflare), or connect to a [Void platform](./self-hosted-platform.md) run by your team. Both use the same application APIs. A platform adds shared access, deployment history, and administration.
 
-[Static assets](./edge/static-assets) are cached at the edge. [Prerendering](./edge/prerendering) builds pages ahead of time, while [incremental revalidation](./edge/revalidation) caches pages rendered on demand. Database, storage, secrets, and deployment commands are available through Void.
+Void also deploys [existing frameworks and static sites](./app-types.md). Your framework keeps its routing and rendering; Void handles resources and deployment.
 
 ## Next steps
 
-- [Quickstart](./quickstart): get a running app in minutes
-- [Server Routing](./server-routing): dynamic params, middleware, and validation
-- [Pages Routing](./pages-routing/overview): full-stack pages with server loaders and actions
-- [Supported App Types](./app-types): full-stack, meta-framework, and static site modes
+- [Quickstart](./quickstart.md): create your first app
+- [Pages Routing](./pages-routing/overview.md): loaders, layouts, and forms
+- [Database](./database.md): schemas, queries, and migrations
+- [Deployment](./deployment.md): Cloudflare, team platforms, and CI

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

@@ -27,8 +27,6 @@ await kv.put('user:123', { name: 'Alice', role: 'admin' });
 
 Values, including strings, are JSON-serialized. Reads preserve their types, so a string such as `"123"` or `"null"` comes back as a string.
 
-If an older Void version stored a JSON-looking string as raw text, rewrite that key with `kv.put(key, originalString)`. Existing stored values keep their previous read behavior; Void cannot distinguish an old raw string such as `"123"` from a stored number. Use the original string or read its raw text through `c.env.KV.get(key)` when rewriting it.
-
 Add a TTL (in seconds) or absolute expiration (Unix timestamp):
 
 ```ts

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

@@ -22,6 +22,8 @@ export const live = defineLiveStream({
 });
 ```
 
+Void enables live streams when a [scanned file](../reference/resource-inference.md#scanned-directories) imports `void/live`, so keep this module in `src/` or another scanned directory. To keep it in an unscanned directory such as `lib/`, add that directory to [`inference.scanDirs`](../reference/resource-inference.md#custom-scan-directories) and list the default directories you still use, because `scanDirs` replaces them.
+
 Expose it from a normal route:
 
 ```ts

package/skills/void/docs/guide/pages-routing/actions-and-forms.md

@@ -29,57 +29,12 @@ export const action = defineHandler.withValidator({
 | Nothing (void)        | Re-runs the loader, page re-renders with fresh props. |
 | `c.redirect('/path')` | Navigates to another page.                            |
 
-## Named Actions
-
-When a page needs multiple mutations, such as updating and deleting a user on the same page, export `actions` (plural) instead of `action`:
-
-```ts
-// pages/users/[id].server.ts
-import { defineHandler } from 'void';
-import { db, eq } from 'void/db';
-import { users, updateUserSchema } from '@schema';
-
-export const actions = {
-  update: defineHandler.withValidator({
-    body: updateUserSchema,
-  })(async (c, { body }) => {
-    await db
-      .update(users)
-      .set(body)
-      .where(eq(users.id, Number(c.req.param('id'))));
-  }),
-
-  delete: defineHandler(async (c) => {
-    await db.delete(users).where(eq(users.id, Number(c.req.param('id'))));
-  }),
-};
-```
-
-Named actions are dispatched via a `?actionName` suffix on the URL (e.g. `/users/42?update`). The client primitives `useForm` and `action()` handle this automatically.
-
-Use `action` or `actions` in a file, not both.
-
-You can also define an `actions.default` key for the action that runs when no name is specified (i.e. a bare POST to the page URL):
-
-```ts
-export const actions = {
-  default: defineHandler(async (c) => {
-    // runs on POST /users/edit (no ?suffix)
-  }),
-  delete: defineHandler(async (c) => {
-    // runs on POST /users/edit?delete
-  }),
-};
-```
-
 ## Form
 
-Pair `Form` with `useForm` for automatic error presentation. It preserves controlled input on failure, announces validation and action errors, and displays the message from structured quota responses. Known retry deadlines prevent premature resubmission without locking the fields. It never retries a submission automatically.
+Pair `Form` with `useForm` to submit values and display validation and action errors. Inputs stay editable when a submission fails.
 
 Import `Form` from your adapter. Pass `form` and, optionally, `method="put"`, `"patch"`, or `"delete"`; the default is `"post"`. Use `renderError` for a custom action-error renderer (a snippet in Svelte).
 
-On the server, use `limit.response({ message: 'AI is temporarily unavailable. Your draft is still editable.' })` in an AI or Sandbox operation's required `limited` handler. It supplies the status and structured metadata consumed by `Form`.
-
 ## `useForm`
 
 `useForm` handles submissions, loading state, and validation errors. URLs, form values, and error fields are typed from your action.
@@ -216,6 +171,49 @@ const form = useForm('/users/:id', { name: '' }, { params: { id: '42' } });
 <Form form={form} method="put">{/* submits to /users/42 */}</Form>
 ```
 
+## Named Actions
+
+When a page needs multiple mutations, such as updating and deleting a user on the same page, export `actions` (plural) instead of `action`:
+
+```ts
+// pages/users/[id].server.ts
+import { defineHandler } from 'void';
+import { db, eq } from 'void/db';
+import { users, updateUserSchema } from '@schema';
+
+export const actions = {
+  update: defineHandler.withValidator({
+    body: updateUserSchema,
+  })(async (c, { body }) => {
+    await db
+      .update(users)
+      .set(body)
+      .where(eq(users.id, Number(c.req.param('id'))));
+  }),
+
+  delete: defineHandler(async (c) => {
+    await db.delete(users).where(eq(users.id, Number(c.req.param('id'))));
+  }),
+};
+```
+
+Named actions are dispatched via a `?actionName` suffix on the URL (e.g. `/users/42?update`). The client primitives `useForm` and `action()` handle this automatically.
+
+Use `action` or `actions` in a file, not both.
+
+You can also define an `actions.default` key for the action that runs when no name is specified (i.e. a bare POST to the page URL):
+
+```ts
+export const actions = {
+  default: defineHandler(async (c) => {
+    // runs on POST /users/edit (no ?suffix)
+  }),
+  delete: defineHandler(async (c) => {
+    // runs on POST /users/edit?delete
+  }),
+};
+```
+
 ### Named Actions with `useForm`
 
 When a page exports named actions, append `?actionName` to the URL:
@@ -258,7 +256,7 @@ Authentication errors (`401`, `403`), server errors (`500`, `502`), and unexpect
 Actions can throw `ValidationError` for custom validation logic:
 
 ```ts
-import { defineHandler, ValidationError } from 'void';
+import { defineHandler, ValidationError } from 'void/handler';
 
 export const action = defineHandler(async (c) => {
   const body = await c.req.json();
@@ -269,6 +267,10 @@ export const action = defineHandler(async (c) => {
 });
 ```
 
+### Usage limits
+
+For [AI](../ai.md#usage-limits) and [Sandbox](../sandboxes.md#usage-limits) actions, an uncaught `UsageLimit` automatically produces a structured HTTP 429. To customize the message, catch the error with `instanceof UsageLimit` and return `error.response({ message: 'Try again shortly. Your draft is still editable.' })`. `Form` displays the message and waits until a known retry deadline before allowing resubmission. It keeps the fields editable and never retries automatically.
+
 ## Authentication and origin checks
 
 Browser submissions must come from the same origin as the page, including its scheme, hostname, and port. Void rejects cross-origin page actions with `403 Forbidden`. Server clients can call actions without browser origin headers; actions still need authentication and authorization for protected data.

package/skills/void/docs/guide/pages-routing/overview.md

@@ -225,9 +225,9 @@ export default function PostPage() {
 
 ## Scroll Restoration
 
-Client-side navigation manages scroll position automatically:
+Void manages scroll position for Pages automatically:
 
-- **Back/forward navigation** restores the exact scroll position you were at before navigating away.
+- **Back/forward navigation and reloads** restore the saved scroll position.
 - **New navigation** scrolls to the top of the page.
 - **Hash links** (`/docs#api`) scroll to the target element. Same-page hash links (`#section`) skip the server fetch entirely.
 

package/skills/void/docs/guide/platform/administration/email.md

@@ -144,5 +144,3 @@ Run recovery with the same platform version that created the persisted intent.
 `applied` continues without replaying the write; `not-applied` permits that exact
 step to retry. Secret rotation keeps its staged generation, and removal resumes
 from the unresolved cleanup step. Age alone never authorizes a retry.
-
-Register administrator domains only after a platform upgrade has completed, and remove them before rolling the platform back to a version that predates this feature: an earlier runtime cannot use the platform credential for them and does not distinguish administrator-registered domains from owner-registered ones.

package/skills/void/docs/guide/platform/administration/operations.md

@@ -51,28 +51,6 @@ Following waits for the final logs before stopping, including diagnostics writte
 
 ## Checking the Platform
 
-### Migrating older deployment assets
-
-After upgrading the platform, inspect every page of its asset inventory:
-
-```sh
-void platform system asset-migrations --page 1 --limit 100
-void platform deployment migrate-assets <deployment-id> --plan
-void platform deployment migrate-assets <deployment-id> --yes
-```
-
-Migrate every deployment with a nonzero `needsMigration` count, including retained
-rollback targets and stored Worker bundles. Investigate entries marked `invalid`
-before continuing. The command verifies each copied asset, preserves originals,
-and applies successive batches. If interrupted, inspect the result and resume
-with the last successful `nextCursor` using `--cursor`; restarting without a
-cursor also verifies and reuses completed copies.
-
-Run the inventory again across all pages when finished. Existing applications
-continue serving during this migration, and the provider asset mirror remains.
-Legacy reads remain available while older platform runtimes and cached manifests
-can still reference original assets.
-
 ### Health checks
 
 Use the overview to see recent activity, or run a health check to test the platform's services and database:
@@ -88,6 +66,17 @@ The dashboard’s **System Status** page refreshes health checks every 30 second
 
 Use `void platform upgrade`, `repair`, `disable`, and `enable` to maintain your platform. See [platform maintenance](/guide/platform/installation/maintenance#resume-repair-recover-and-upgrade).
 
+Upgrades and rollbacks run through the CLI; watching their progress is optional.
+During maintenance, navigating the admin UI automatically redirects to
+`/admin/status`. You can also open that page directly on the API origin. It
+refreshes automatically and shows saved progress and the API's traffic state
+while the API and authentication database remain reachable. If a status refresh
+fails, the last confirmed snapshot is marked as stale. Normal administrator
+changes stay paused during maintenance.
+If the CLI reports an error or a waiting state, follow its recovery instructions
+to resume the operation. See
+[Follow upgrade and rollback progress](/guide/platform/installation/maintenance#follow-upgrade-and-rollback-progress).
+
 For disaster recovery, keep a matching PostgreSQL backup, provider data backups, installation identity and complete project-encryption keyring, and immutable runtime artifacts. Keep traffic disabled while restoring data, run `discover` to reconstruct verified local metadata, and review `repair --plan` before recreating missing installer-owned infrastructure. Neither command restores backed-up data. See [Prepare for disaster recovery](/guide/platform/installation/maintenance#prepare-for-disaster-recovery) for the full sequence.
 
 ## Using Scripts