void 0.23.0 → 0.25.0

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

@@ -4,158 +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`.
+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`.
 
-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.
+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.
 
-To set up deployment later, use `void connect --platform cloudflare` or `void connect <platform-url>`.
+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).
 
-Owners can [share a platform project](./project-collaboration.md) with readers, collaborators, and project administrators. This does not apply to direct Cloudflare deployments.
+## 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:
+### Environment variables
 
-1. `--project <name>` flag
-2. `VOID_PROJECT` environment variable
-3. Linked project in `.void/project.json`
+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).
 
-If none is set, Void asks you to choose a project. Direct Cloudflare deploys use the Worker and account saved in your Cloudflare config.
+Keep the CLI and framework adapters on matching versions, and commit `void.config.ts` and `void.lock.json` when generated.
 
-### CI preparation
+## 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.
+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.
 
-Core self-hosted installations do not support this integration. Use your own CI workflow with a [project deploy token](./platform/installation/first-deployment.md).
+## Logs and rollback
 
-## Other Targets
+Inspect your deployment, read runtime logs, or select a previous deployment:
 
-### Your own Cloudflare account
-
-Select Cloudflare during setup, or run `void deploy --platform cloudflare`. See the [Cloudflare guide](../integrations/cloudflare.md) for configuration, CI credentials, and deployment limits.
-
-### 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/edge/headers.md

@@ -35,7 +35,7 @@ Header rules do not apply to ISR cache responses.
 
 ### Blocked headers
 
-`Set-Cookie` and `Clear-Site-Data` are ignored in header rules. On a shared domain such as `*.void.app`, a rule could otherwise affect cookies or data belonging to another project's subdomain.
+`Set-Cookie` and `Clear-Site-Data` are ignored in header rules. On a shared domain such as `*.apps.example.com`, a rule could otherwise affect cookies or data belonging to another project's subdomain.
 
 ## Framework `_headers` files
 

package/skills/void/docs/guide/email/domains.md

@@ -50,7 +50,9 @@ Use a mail subdomain to keep existing mail on `acme.com` with its current provid
 
 Sign in with `void cloudflare login`, or use a `CLOUDFLARE_API_TOKEN` with **Email Routing Edit** and **Email Sending Edit** in addition to deploy permissions. If your browser session lacks email permissions, log out and sign in again. Global API Keys aren't supported.
 
-Run `void deploy --platform cloudflare`. Void shows the domain, routing, sending, DNS, and handler addresses it would configure. Accept to set up email and deploy. Later deploys reuse the setup. Without `email.from`, or if you decline the initial setup, the app deploys without email.
+Run `void deploy --platform cloudflare`. Void shows the domain, routing, sending, DNS, and handler addresses it would configure. Accept to set up email and deploy. Later deploys reuse the setup. If you decline the initial setup, the app deploys without email.
+
+Without `email.from`, Void skips automatic setup and preserves authored `cloudflare.send_email` bindings and `cloudflare.addresses`; check their readiness yourself. `--require-email` still refuses deployment when automatic setup cannot be verified.
 
 If subdomain setup needs a dashboard step, follow the checklist under **Email → Settings → Subdomains**, then retry. After DNS changes, check readiness with:
 
@@ -78,6 +80,8 @@ Setup enables the zone's plus addressing so `support+T-42@mail.acme.com` reaches
 
 On Workers Free, `sendEmail()` can send to verified destinations listed under **Email Routing → Destination addresses** in Cloudflare.
 
+Configure your sender domain's SPF, DKIM, and DMARC records using [Cloudflare's email authentication guidance](https://developers.cloudflare.com/email-service/concepts/email-authentication/), then check the authentication results in a received message's original headers. A successful `sendEmail()` result confirms provider acceptance; it does not confirm delivery or authentication readiness.
+
 Sending to arbitrary recipients requires [Workers Paid](https://dash.cloudflare.com/?to=/:account/workers/plans) and Email Sending onboarding. After upgrading, run `void email setup --platform cloudflare`. Void doesn't retry onboarding during ordinary deploys.
 
 Existing DMARC or bounce-domain records can block onboarding; the checklist identifies conflicts to resolve. Inbound mail remains available.

package/skills/void/docs/guide/email/sending.md

@@ -34,7 +34,7 @@ Check both failure shapes: `result.error` reports a request failure, while `resu
 
 ## Setup {#setup}
 
-On a platform with email enabled, deploy without additional email configuration. Ask your administrator for its shared mail domain. Administrators [enable email during installation or upgrade](/guide/platform/installation/credentials#runtime-token-permissions); Void Cloud uses `mail.void.cloud`.
+On a platform with email enabled, deploy without additional email configuration. Ask your administrator for its shared mail domain. Administrators [enable email during installation or upgrade](/guide/platform/installation/credentials#runtime-token-permissions).
 
 Each project on an email-enabled platform has:
 

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/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) and [Sandbox](../sandboxes.md) actions, return `limit.response({ message: 'Try again shortly. Your draft is still editable.' })` from the operation's `limited` handler. `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

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

@@ -11,9 +11,7 @@ void platform auth login
 void platform config plans
 ```
 
-Choose a plan to inspect or edit it, copy one into a new plan, or choose the default for new accounts. Existing installations keep their plans, limits, and default until you change them. After upgrading the platform to support plan configuration, these changes require no app or platform redeploy.
-
-Inspection and previews are available immediately after a platform upgrade. Allow 15 minutes before applying changes.
+Choose a plan to inspect or edit it, copy one into a new plan, or choose the default for new accounts. Changes require no app or platform redeploy.
 
 ## Use the Dashboard
 
@@ -90,8 +88,6 @@ Storage figures shown for D1, R2, and KV are informational and cannot be edited
 
 The preview shows the affected account count and checks a sample for accounts already above a proposed quota. Lowering a quota can restrict existing apps, including accounts outside that sample. Usage history and billing periods are preserved, so a plan change does not reset usage. Manual administrator suspensions remain in effect.
 
-After the initial platform upgrade, request quota accounting includes unlimited plans too. For an account that was unlimited before that upgrade, its quota counter may not include earlier requests in the current billing period. Historical analytics remain available. When introducing its first cap, allow for the remaining period or wait until its next billing period.
-
 ## Archive or Remove a Plan
 
 Archive a plan to stop assigning it to new accounts while preserving its current accounts: