void 0.25.0 → 0.26.1

package/{skills/void/docs → docs}/guide/pages-routing/loaders.md

@@ -11,11 +11,11 @@ A loader fetches the data a page needs. Define it in a companion `.server.ts` fi
 `loader` runs on GET requests and returns an object that becomes the page's props:
 
 ```ts
+import { users } from '@schema';
 // pages/users/index.server.ts
 import { defineHandler } from 'void';
 import type { InferProps } from 'void';
 import { db } from 'void/db';
-import { users } from '@schema';
 
 export type Props = InferProps<typeof loader>; // [!code highlight]
 
@@ -79,9 +79,9 @@ defineProps<Props>();
 ```
 
 ```tsx [Solid]
+import { For } from 'solid-js';
 // pages/users/index.tsx
 import type { Props } from './index.server';
-import { For } from 'solid-js';
 
 export default function UsersPage(props: Props) {
   return (
@@ -102,11 +102,11 @@ export default function UsersPage(props: Props) {
 Use `defer()` for slow data. The page renders immediately and receives the result when it is ready:
 
 ```ts
+import { projects } from '@schema';
 // pages/dashboard.server.ts
 import { defineHandler, defer } from 'void';
 import type { InferProps } from 'void';
 import { db } from 'void/db';
-import { projects } from '@schema';
 
 export type Props = InferProps<typeof loader>;
 
@@ -157,6 +157,10 @@ around the Suspense boundary when the page should render a custom failure state.
 For explicit React prop annotations, import `Deferred` from `@void/react`; the
 adapter export is typed as `Promise<T>`.
 
+In production, an unexpected error in a deferred prop reaches the page as
+`Internal Server Error`; throw an
+[`HTTPException`](../../integrations/hono.md#utilities) to show your own message.
+
 In Vue, Svelte, and Solid, `Deferred<T>` behaves as a [discriminated union](https://www.typescriptlang.org/docs/handbook/2/narrowing.html#discriminated-unions) with three states:
 
 ```ts

package/{skills/void/docs → docs}/guide/pages-routing/markdown.md

@@ -64,11 +64,11 @@ Add the plugin to your Vite config **after** the framework adapter:
 ::: code-group
 
 ```ts [React]
+import { voidMarkdown } from '@void/md/plugin';
+import { voidReact } from '@void/react/plugin';
 // vite.config.ts
 import { defineConfig } from 'vite';
 import { voidPlugin } from 'void';
-import { voidReact } from '@void/react/plugin';
-import { voidMarkdown } from '@void/md/plugin';
 
 export default defineConfig({
   plugins: [voidPlugin(), voidReact(), voidMarkdown()],
@@ -76,11 +76,11 @@ export default defineConfig({
 ```
 
 ```ts [Vue]
+import { voidMarkdown } from '@void/md/plugin';
+import { voidVue } from '@void/vue/plugin';
 // vite.config.ts
 import { defineConfig } from 'vite';
 import { voidPlugin } from 'void';
-import { voidVue } from '@void/vue/plugin';
-import { voidMarkdown } from '@void/md/plugin';
 
 export default defineConfig({
   plugins: [voidPlugin(), voidVue(), voidMarkdown()],
@@ -88,11 +88,11 @@ export default defineConfig({
 ```
 
 ```ts [Svelte]
+import { voidMarkdown } from '@void/md/plugin';
+import { voidSvelte } from '@void/svelte/plugin';
 // vite.config.ts
 import { defineConfig } from 'vite';
 import { voidPlugin } from 'void';
-import { voidSvelte } from '@void/svelte/plugin';
-import { voidMarkdown } from '@void/md/plugin';
 
 export default defineConfig({
   plugins: [voidPlugin(), voidSvelte(), voidMarkdown()],
@@ -100,11 +100,11 @@ export default defineConfig({
 ```
 
 ```ts [Solid]
+import { voidMarkdown } from '@void/md/plugin';
+import { voidSolid } from '@void/solid/plugin';
 // vite.config.ts
 import { defineConfig } from 'vite';
 import { voidPlugin } from 'void';
-import { voidSolid } from '@void/solid/plugin';
-import { voidMarkdown } from '@void/md/plugin';
 
 export default defineConfig({
   plugins: [voidPlugin(), voidSolid(), voidMarkdown()],
@@ -401,7 +401,7 @@ Code blocks include a copy button.
 
 ### Line Numbers
 
-Enable per code block with `:line-numbers` or disable with `:no-line-numbers`:
+Enable per code block with `:line-numbers`:
 
 ````md
 ```ts :line-numbers
@@ -412,14 +412,6 @@ const b = 2;
 
 Start from a specific number with `:line-numbers=5`.
 
-### Snippet Imports
-
-Import code from external files:
-
-```md
-<<< ./path/to/file.ts
-```
-
 ### Emoji
 
 Shortcodes convert to unicode: `:tada:` becomes :tada:, `:rocket:` becomes :rocket:.
@@ -455,16 +447,16 @@ Headings include permalink anchors. Use `[[toc]]` for a table of contents. Image
 ```ts
 voidMarkdown({
   shiki: {
-    themes: { light: 'github-light', dark: 'github-dark' }, // Shiki themes
-    langs: ['sql', 'graphql'], // additional languages
+    themes: { light: 'github-light', dark: 'github-dark' },
   },
 });
 ```
 
-| Option         | Type                             | Default                                          | Description                  |
-| -------------- | -------------------------------- | ------------------------------------------------ | ---------------------------- |
-| `shiki.themes` | `{ light: string; dark: string}` | `{ light: "github-light", dark: "github-dark" }` | Shiki color themes           |
-| `shiki.langs`  | `string[]`                       | Common web languages                             | Additional languages to load |
+| Option         | Type                             | Default                                          | Description        |
+| -------------- | -------------------------------- | ------------------------------------------------ | ------------------ |
+| `shiki.themes` | `{ light: string; dark: string}` | `{ light: "github-light", dark: "github-dark" }` | Shiki color themes |
+
+Code block languages load on demand from Shiki's bundled languages.
 
 ## Building a Sidebar
 

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

@@ -41,10 +41,10 @@ Add both plugins to your Vite config:
 ::: code-group
 
 ```ts [React]
+import { voidReact } from '@void/react/plugin';
 // vite.config.ts
 import { defineConfig } from 'vite';
 import { voidPlugin } from 'void';
-import { voidReact } from '@void/react/plugin';
 
 export default defineConfig({
   plugins: [voidPlugin(), voidReact()],
@@ -52,10 +52,10 @@ export default defineConfig({
 ```
 
 ```ts [Vue]
+import { voidVue } from '@void/vue/plugin';
 // vite.config.ts
 import { defineConfig } from 'vite';
 import { voidPlugin } from 'void';
-import { voidVue } from '@void/vue/plugin';
 
 export default defineConfig({
   plugins: [voidPlugin(), voidVue()],
@@ -63,10 +63,10 @@ export default defineConfig({
 ```
 
 ```ts [Svelte]
+import { voidSvelte } from '@void/svelte/plugin';
 // vite.config.ts
 import { defineConfig } from 'vite';
 import { voidPlugin } from 'void';
-import { voidSvelte } from '@void/svelte/plugin';
 
 export default defineConfig({
   plugins: [voidPlugin(), voidSvelte()],
@@ -74,10 +74,10 @@ export default defineConfig({
 ```
 
 ```ts [Solid]
+import { voidSolid } from '@void/solid/plugin';
 // vite.config.ts
 import { defineConfig } from 'vite';
 import { voidPlugin } from 'void';
-import { voidSolid } from '@void/solid/plugin';
 
 export default defineConfig({
   plugins: [voidPlugin(), voidSolid()],
@@ -212,6 +212,8 @@ router.refresh(); // re-fetch current page props
 router.visit('/logout', { method: 'POST' }); // non-GET navigation
 ```
 
+`router.visit()` updates the page in place for same-origin URLs. `http(s)` URLs on another origin get a full page load, and other schemes such as `javascript:` are rejected.
+
 For dynamic route params, use `useParams()` from the same adapter package:
 
 ```tsx

package/{skills/void/docs → docs}/guide/platform/administration/access.md

@@ -30,15 +30,7 @@ the company sign-in before Void login. Interactive Access authentication uses a
 locally installed `cloudflared` and saves its short-lived credential in your
 system keychain for that platform origin. You do not need to copy browser cookies.
 
-For CI, use a [project deploy token](/guide/platform/installation/first-deployment) alongside your Access credentials. An Access service token does not authorize a Void deployment.
-
-Store Access credentials in origin-keyed `VOID_ACCESS_CREDENTIALS`. A deploy
-that uses prerendering or remote bindings needs entries for both the exact API
-and proxy HTTPS origins, even when both entries contain the same admitted
-service-token pair. `VOID_ACCESS_ORIGIN` selects only one recipient and therefore
-cannot cover both calls. Keep the JSON value in your secret manager, not in
-application configuration. See [CI deployment setup](/guide/platform/installation/first-deployment)
-for the required shape.
+For CI, use a [project deploy token](/guide/platform/installation/first-deployment) alongside your Access credentials in origin-keyed `VOID_ACCESS_CREDENTIALS`. An Access service token does not authorize a Void deployment. See [CI deployment setup](/guide/platform/installation/first-deployment) for the required origins and shape.
 
 ## Choosing a Platform
 
@@ -165,4 +157,4 @@ void platform invitation list
 Invitation history remains available after an involved account is removed. The stored actor ID
 remains visible when that account's login no longer exists.
 
-`void platform signup open` allows anyone to sign up. Use `void platform signup restrict` to require an allowlist match again. Disallowing an entry affects future signup; it does not suspend an existing account.
+`void platform signup open` allows anyone to sign up. Everyone who signs up can deploy apps on your application domain, so check how those apps [share cookies](/guide/platform/installation/domains#adding-a-domain) before opening signup. Use `void platform signup restrict` to require an allowlist match again. Disallowing an entry affects future signup; it does not suspend an existing account.

package/{skills/void/docs → docs}/guide/platform/administration/operations.md

@@ -66,18 +66,9 @@ 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.
+During an upgrade or rollback, the admin UI shows progress at `/admin/status`. See [Follow upgrade and rollback progress](/guide/platform/installation/maintenance#follow-upgrade-and-rollback-progress).
+
+For backups and restores, see [Prepare for disaster recovery](/guide/platform/installation/maintenance#prepare-for-disaster-recovery).
 
 ## Using Scripts
 

package/{skills/void/docs → docs}/guide/platform/administration/projects.md

@@ -23,7 +23,7 @@ void platform project show <project-id>
 
 Project details include resources, domains, and recent builds and deployments. The [command reference](../../../reference/cli/platform.md#operator-commands) also covers suspending and restoring users, deleting projects, and removing accounts.
 
-In the admin dashboard, open a project to view its team. Search for a platform user and choose a role to add them immediately; an email address is not required. You can also change or remove existing members. Pending invitations created through other project workflows remain visible until accepted or revoked. If email is unavailable for a pending invitation, share its ID so the user can accept it with `void project team accept <invitation-id>`. The owner cannot be removed from the team; transfer ownership first.
+In the admin dashboard, open a project to view its team. Search for a platform user and choose a role to add them immediately; an email address is not required. You can also change or remove existing members. Pending invitations created through other project workflows remain visible until accepted or revoked. If email is unavailable for a pending invitation, share its ID so the user can accept it with `void project team accept <invitation-id>`. The owner cannot be removed from the team; transfer ownership first. Removing a collaborator or admin, changing one to reader, or suspending or deleting their account [replaces the project's platform credentials](../../project-collaboration.md#change-or-remove-access), the same as the CLI.
 
 ### Transferring Project Ownership
 

package/{skills/void/docs → docs}/guide/platform/development/local.md

@@ -36,7 +36,7 @@ Use the Node.js version recorded in `.node-version`.
 
 The `@voidcloud/*` names identify workspace implementation packages. Their `private: true` flags prevent publishing those packages to npm. Deployable core Workers are bundled into the public `@void/platform` package.
 
-The core installer creates the API, dispatch, proxy, and tail Workers. The dashboard and managed GitHub build services are available in the source tree but are not included in that installation. Adding an optional service requires its infrastructure, bindings, authentication, and capability configuration together.
+The core installer creates the API, dispatch, proxy, tail, and email gateway Workers. The dashboard and managed GitHub build services are available in the source tree but are not included in that installation. Adding an optional service requires its infrastructure, bindings, authentication, and capability configuration together.
 
 ## Running the API Locally
 
@@ -44,7 +44,7 @@ Start a local PostgreSQL server and make `psql` and `pg_isready` available on yo
 
 ```sh
 vp run --filter @voidcloud/api setup --admin-email dev@example.com
-vp run --filter @voidcloud/api dev --local --enable-containers=false --host localhost --port 8787
+vp run --filter @voidcloud/api dev:admin
 ```
 
 The command disables the optional build containers, so basic API and admin work
@@ -55,6 +55,8 @@ Open `http://localhost:8787/admin/`. Setup writes the API's local database conne
 
 The API's development bypass lets you work on the browser admin UI without setting up OAuth. Operator CLI sessions still require administrator authentication; they do not use the browser bypass.
 
+`dev:admin` watches source files and automatically reloads the browser after edits. Keep it running while working on the admin dashboard's React components and styles; no platform deployment is needed. The setup includes sample users, projects, and deployments for trying each view locally.
+
 ## Running the Dashboard Locally
 
 The dashboard is a separate source app. After API setup, start it in another terminal:

package/{skills/void/docs → docs}/guide/platform/development/runtime.md

@@ -25,7 +25,7 @@ void-dev platform install \
   --plan
 ```
 
-Before applying the plan, complete the [installation guides](/guide/self-hosted-platform). Run the command without `--plan` to install. For testing before your domain is ready, replace `--application-domain` and `--zone` with `--workers-dev`; PostgreSQL and the runtime/GitHub/R2 credentials are still needed. Use `void-dev` in place of `void` and keep `--runtime packages/platform/dist/runtime` on install and resume commands. For an interrupted installation, keep that runtime build available until it completes.
+Before applying the plan, complete the [installation guides](/guide/self-hosted-platform). Run the command without `--plan` to install. For testing before your domain is ready, replace `--application-domain` and `--zone` with `--workers-dev`; PostgreSQL and the runtime, login-provider, and R2 credentials are still needed. Use `void-dev` in place of `void` and keep `--runtime packages/platform/dist/runtime` on install and resume commands. For an interrupted installation, keep that runtime build available until it completes.
 
 Later, run `void-dev platform domain set example.app`. Domain setup uses the existing installed runtime and needs no `--runtime`, rebuild, or app redeploy. It keeps the platform API URL and original workers.dev app URLs available.
 

package/{skills/void/docs → docs}/guide/platform/development/schema-ci.md

@@ -20,7 +20,7 @@ Review the generated SQL and migration journal before committing them. Released
 
 `@void/platform` contains installation manifests, resource naming, discovery contracts, Worker configuration, and deployable bundles under the `./installer` export. Platform source lives in `platform/packages/`.
 
-Runtime artifacts include migration SQL, its journal, and a rollback compatibility manifest. Drizzle authoring snapshots remain in the source tree. Migrations are forward-only; compatibility edges in `platform/packages/api/drizzle/compatibility.json` must be tested against the earlier runtime before publication. The build verifies schema lineage and hashes the journal and SQL files.
+Runtime artifacts include migration SQL, its journal, and a rollback compatibility manifest. Drizzle authoring snapshots remain in the source tree.
 
 ## CI in a Fork
 

package/{skills/void/docs → docs}/guide/platform/installation/credentials.md

@@ -8,7 +8,7 @@ Keep one password-manager entry for this platform. Paste the saved values into t
 
 ## Cloudflare API Tokens {#runtime-token-permissions}
 
-For a domain installation or Cloudflare Access setup, the installer guides you through creating separate management and runtime tokens using Cloudflare's [API token setup](https://developers.cloudflare.com/fundamentals/api/get-started/create-token/). Its links preselect the permissions and suggest names based on your platform's display name. Scope the tokens to your selected account and, when using a domain, its zone, save them in your password manager, and paste them into the masked CLI prompts.
+For a domain installation or Cloudflare Access setup, the installer guides you through creating separate management and runtime tokens using Cloudflare's [API token setup](https://developers.cloudflare.com/fundamentals/api/get-started/create-token/). Its links preselect the permissions and suggest names based on your platform's display name, but Cloudflare's form cannot preselect a zone: for a domain installation, change the zone policy from **All Domains** to **Specified Domains** and select your zone. If Void will create the zone, keep **All Domains** on both tokens: the zone does not exist yet, and the runtime token needs it to purge cache. Save the tokens in your password manager and paste them into the masked CLI prompts.
 
 For workers.dev testing with the default API hostname, browser login can authorize
 infrastructure setup. Void also checks account-wide Access requirements; if the
@@ -21,7 +21,7 @@ Browser login does not grant AI Gateway access. Include **Account → AI Gateway
 
 The management token lets your CLI install and maintain the platform. The runtime token is stored as a Worker secret so the platform can deploy apps after you close your terminal. They are separate credentials.
 
-Compare each token's form with the permission checklist below, and select the indicated account and zone for a domain installation. The installer saves a management token entered at the prompt in this installation’s encrypted local checkpoint and reuses it on resume. Upgrades, repairs, and other lifecycle maintenance also use that saved management token. During installation, a rejected token can be replaced at the prompt. An explicit `CLOUDFLARE_API_TOKEN` or `CF_API_TOKEN` takes precedence. Keep your password-manager copy for maintenance or another machine; scripts supply it through `CLOUDFLARE_API_TOKEN`.
+Compare each token's form with the permission checklist below. The installer saves a management token entered at the prompt in this installation’s encrypted local checkpoint and reuses it on resume. Upgrades, repairs, and other lifecycle maintenance also use that saved management token. During installation, a rejected token can be replaced at the prompt. An explicit `CLOUDFLARE_API_TOKEN` or `CF_API_TOKEN` takes precedence. Keep your password-manager copy for maintenance or another machine; scripts supply it through `CLOUDFLARE_API_TOKEN`.
 
 ::: details Permissions to select for each token
 

package/{skills/void/docs → docs}/guide/platform/installation/domains.md

@@ -23,6 +23,8 @@ Choose an application domain whose wildcard leaves existing Worker Custom Domain
 
 Browser login sessions are specific to each origin. Apps using their own OAuth providers may need to register their new callback URLs. Void's built-in auth uses the request origin automatically unless the app overrides that configuration.
 
+Apps on one application domain can set cookies that the other apps there receive. With a nested domain such as `apps.example.com`, apps can also set cookies for `example.com` and its other subdomains. Apps on `workers.dev` testing URLs can set cookies that every Worker on your account's `workers.dev` subdomain receives. If people outside your team can deploy, use a domain that serves only Void apps. A platform that serves thousands of independent developers can also apply to list its application domain on the [Public Suffix List](https://github.com/publicsuffix/list/wiki/Guidelines).
+
 ### What Changes in Testing Mode?
 
 In testing mode, each app gets a `workers.dev` URL. These URLs continue working after you add a domain; new apps then use the domain.
@@ -91,7 +93,7 @@ New platform resources use deterministic `void-<installation-name>-<role>` names
 | Workers                                   | 5, plus one per app using workers.dev | API/control plane, proxy, tail ingestion, dispatch, email gateway, and test-origin forwarders |
 | KV namespaces                             |                                     3 | Routing, ISR cache, and static asset storage                                                  |
 | R2 buckets                                |                                     1 | Static and deployment assets                                                                  |
-| Queues                                    |                                     2 | Usage events and cron firing                                                                  |
+| Queues                                    |                                     3 | Usage events, cron firing, and deployments                                                    |
 | Workers for Platforms dispatch namespaces |                                     1 | User application Workers                                                                      |
 | Hyperdrive configurations                 |                                     1 | External platform PostgreSQL                                                                  |
 | AI Gateways                               |                                     1 | Installation-isolated AI routing and metering                                                 |

package/{skills/void/docs → docs}/guide/platform/installation/first-deployment.md

@@ -4,6 +4,8 @@ outline: deep
 
 # First Deployment
 
+Open your platform's API URL in a browser to see its welcome page, CLI connection instructions, and a link to the administrator dashboard. Share this URL with teammates so they can connect to your platform.
+
 First verify the new platform and sign in with the administrator login method selected during setup:
 
 ```sh
@@ -34,7 +36,11 @@ void project token create --name ci --expires-in 30
 
 Store the printed `VOID_TOKEN` and `VOID_API_URL` in the CI secret manager, then
 run `void connect "$VOID_API_URL" --no-login` before deploying in each fresh CI
-environment. Project files do not replace this connection step. Rotate with `void project token renew <id>` and revoke with
+environment. Project files do not replace this connection step. CI cannot answer
+the project prompt, so choose the project before `void deploy`: set `VOID_PROJECT`,
+pass `--project <slug>`, or commit `.void/project.json` from `void project link`.
+New apps ignore `.void` in `.gitignore`; to commit the link, replace that line
+with `.void/*` and `!.void/project.json`. Rotate with `void project token renew <id>` and revoke with
 `void project token revoke <id>`. A human login token is not a CI credential.
 
 If Cloudflare Access protects the platform, Access proof and the project
@@ -79,7 +85,7 @@ void platform signup allow github teammate
 
 Void shows the proposed access change and asks you to confirm it. Once approved, `teammate` can connect to the platform's API URL and sign in with GitHub.
 
-To see who can join, run `void platform signup show`. You can also allow an email address or a domain such as `*@example.com`. For an OIDC user without verified email, use `void platform signup allow identity <connection-id> <subject>`; the subject match is exact and the provider's domain or group restrictions still apply. Remove that grant with `void platform signup disallow identity <connection-id> <subject>`. `void platform signup open` permits public signup; `void platform signup restrict` requires an allowlist match again.
+To allow email addresses, domains, or OIDC identities, or to open signup, see [Giving People Access](/guide/platform/administration/access#giving-people-access).
 
 Your administrator session lasts for one hour. Use it to inspect users, projects, logs, and platform health. The [Platform Administration guide](/guide/platform-administration) walks through those workflows, previews, and automation. You can also open `<API origin>/admin/login` to use the browser admin UI.
 

package/{skills/void/docs → docs}/guide/platform/installation/maintenance.md

@@ -6,7 +6,7 @@ outline: deep
 
 ## Resume, repair, recover, and upgrade
 
-You can omit an installation ID when only one is configured. With several installations, choose one interactively or pass its ID in CI.
+Run `void platform list` to find the installation slug beside its name. Lifecycle commands accept this slug, an installation ID, or a saved connection ID. You can omit the selector when only one installation is configured. With several installations, choose one interactively or pass its slug or ID in CI.
 
 ### Resume an installation
 
@@ -74,6 +74,8 @@ void platform upgrade [id]
 
 An upgrade validates the runtime, applies supported pending migrations, deploys the Workers, and checks their health. Existing Worker secrets are preserved.
 
+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.
+
 ::: details Migration safety, credential rotation, and interrupted upgrades
 
 Some upgrades briefly put the platform into maintenance mode. Traffic resumes after the new version passes health checks. If an upgrade is interrupted during maintenance, rerun the same command to complete it.
@@ -96,6 +98,10 @@ void platform rollback [id] --runtime /path/to/earlier/runtime
 
 Keep the earlier runtime files if you need rollback. If the installed version is a custom build, also pass its files with `--from-runtime /path/to/current/runtime`. Void checks that the earlier version can run against your current database and refuses incompatible rollbacks. A later `upgrade` can move forward again. See [Platform Development](/guide/platform/development/runtime#deploying-your-runtime) for working with custom builds.
 
+Do not roll back to 0.26.0 or earlier after upgrading to a later release. Void does not refuse this rollback, but those releases reject the credentials that later releases give your apps. Every project deployed or rotated since the upgrade loses AI, email, ISR revalidation, remote D1, KV, and R2, and prerendering until you upgrade again. If you have rolled back that far, upgrade again, then run `void platform system rotate-proxy-tokens --all --yes` and check with `--plan` until nothing is pending or failed.
+
+Let running rotations finish before you roll back. If an older proxy runs next to a newer API, prerendering and remote D1, KV, and R2 fail until both run the same release. After a rollback to the release just before credential rotation, projects deployed since the upgrade lose prerendering and remote D1, KV, and R2 until they are deployed again or you upgrade again. A rotated project deployed during any rollback stays broken after you upgrade again, and 0.26.0 and earlier also drop rotations that have not finished. After upgrading again from any rollback, run the same `rotate-proxy-tokens` commands.
+
 :::
 
 ### Follow upgrade and rollback progress

package/{skills/void/docs → docs}/guide/platform/installation/setup.md

@@ -12,7 +12,7 @@ For workers.dev testing, start the interactive install and choose your login met
 void platform install --workers-dev
 ```
 
-For a domain installation or Access setup, Void guides you to create a management API token and paste it into a masked prompt. Browser login can preview DNS, but cannot change it or configure Access. The token-creation link preselects the permissions for your choices; scope the token to your account and, when using a domain, its zone. No shell environment variable is needed for interactive installation.
+For a domain installation or Access setup, Void guides you to create a management API token and paste it into a masked prompt. Browser login can preview DNS, but cannot change it or configure Access. The token-creation link preselects the permissions for your choices. When using an existing domain, change the zone policy from **All Domains** to **Specified Domains** and select your zone, as the CLI prompt describes. No shell environment variable is needed for interactive installation.
 
 ::: details Use an existing management token from the shell
 

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

@@ -0,0 +1,102 @@
+---
+outline: deep
+---
+
+# Disable and Uninstall
+
+To pause a platform without removing its data:
+
+```sh
+void platform disable [id] --plan
+void platform disable [id]
+```
+
+Disabled platforms reject application traffic while retaining domains and routes. The platform API also rejects requests, so CLI commands that use it, including login and deploy, fail until you enable the platform again. Only the administrator status page at `<api-url>/admin/status` and administrator sign-in stay available. Repair and upgrade preserve that state.
+
+Enabling redeploys the platform Workers from the selected runtime, verifies them, and then restores traffic. Pass `--runtime <path>` to enable with a custom platform build:
+
+```sh
+void platform enable [id] --plan
+void platform enable [id]
+```
+
+Add `--yes` to commands that make changes in a non-interactive shell.
+
+While disabled, the platform retries queue batches after five minutes instead of delivering them to apps. Queue retention and retry limits still apply. For a long pause, plan a dead-letter queue or another way to recover messages.
+
+## Uninstall
+
+Preview removal before applying it:
+
+```sh
+void platform uninstall [id] --plan
+void platform uninstall [id]
+```
+
+Uninstall blocks platform traffic, removes Queues that no remaining platform Worker uses, and lists the resources left for you to review. Use `--plan` to review deletions and retained resources before making changes. By default, Workers, the Queues they use, KV, R2, Hyperdrive, the dispatch namespace, and AI Gateway remain in your account. Adopted resources, external PostgreSQL, and zones are always retained. Email Routing settings are retained; `--purge-resources` removes only the rules that send mail to the platform. DNS records, routes, custom domains, and Cloudflare Access resources are retained unless you use `--purge-resources`.
+
+When uninstall finishes, the record of what was kept stays at `~/.void/platforms/<account-id>/<installation-id>.json`. Without `--purge-data`, the encrypted credentials file `<installation-id>.recovery.enc` next to it is kept too. Delete both once you have finished the manual cleanup below.
+
+To also remove eligible data resources owned by the installer:
+
+```sh
+void platform uninstall [id] --purge-data
+```
+
+Even with `--purge-data`, Void retains Workers, the Queues they use, R2, AI Gateway, DNS records, routes, custom domains, Access resources, adopted resources, external PostgreSQL, and zones. Review those in the Cloudflare dashboard if you want to remove them, or use `--purge-resources`.
+
+### Remove everything Void created
+
+To delete every Cloudflare resource the installation created:
+
+```sh
+void platform uninstall [id] --purge-resources --plan
+void platform uninstall [id] --purge-resources
+```
+
+`--purge-resources` includes `--purge-data`. It also deletes the platform Workers, Queues, the application Workers left in the dispatch namespace, the R2 bucket and its objects, the AI Gateway, the platform DNS record, Worker routes and custom domains, and the Access applications and service tokens the installer created. The plan lists each resource in deletion order, and everything that stays. If Cloudflare shows that the AI Gateway was created after installation, for example because it was deleted and created again under the same name, it is kept and listed.
+
+If the platform sends email, it first deletes the Email Routing rules in the sender domain's zone that send mail to the platform email gateway Worker, and resets such a catch-all rule to drop mail. It leaves Email Routing enabled and keeps the sender domain's MX, SPF, and DKIM records.
+
+It never removes zones, adopted resources, external PostgreSQL, other Email Routing settings, Analytics Engine datasets, Access policies or identity providers you chose, or API tokens. Revoke the API tokens you created for the platform afterward.
+
+Before making changes, `--purge-resources` checks that no projects remain and that it can read the resources it plans to delete. Delete any projects with `void project delete <name>` first.
+
+Set `CLOUDFLARE_API_TOKEN` to a token with the Edit permissions listed by `--plan`. Browser login cannot delete DNS records or Access resources. Access resources in a separate identity account need permissions in that account; email-enabled platforms also need **Zone → Email Routing Rules → Edit** for the sender domain's zone.
+
+The read checks cannot verify Edit permissions. If a deletion is denied, uninstall may have already disabled traffic or removed resources. Update the token permissions and rerun the command to resume.
+
+If a route, custom domain, DNS record, or Access resource no longer matches what the installation recorded, for example a route that now sends traffic to another Worker, it is kept and listed with the reason, and uninstall continues. Do not run `--purge-resources` while someone else is changing the platform's Workers, routes, or custom domains: a change made after Void checks a resource and before it deletes it is not detected.
+
+If Cloudflare refuses a deletion, for example because a Worker you created yourself still sends logs to the platform tail Worker, uninstall stops and names the resource. Fix it, then rerun the same command to continue.
+
+If a plain or `--purge-data` uninstall stopped before it finished, rerun it with `--purge-resources` to also delete what it kept. Once an uninstall finishes, use the manual steps below instead.
+
+### Remove retained resources
+
+After an uninstall without `--purge-resources`, Cloudflare refuses to delete a resource while a platform Worker still uses it. In the Cloudflare dashboard, remove what is left in this order, skipping anything already gone:
+
+1. Delete the platform DNS record, Worker routes, and custom domains.
+2. If the platform sends email, open **Email Routing** for the sender domain's zone. Delete the routing rules and any catch-all rule that send mail to the platform email gateway Worker. Then remove the sender subdomain from Email Routing, or disable Email Routing if you enabled it only for the platform.
+3. Open each platform Queue and remove the platform API Worker from its consumers.
+4. Delete the platform Workers, except the tail Worker (its name ends in `-tail`).
+5. Delete the platform Queues.
+6. Delete the application Workers in the dispatch namespace, then delete the namespace.
+7. Delete the tail Worker. Cloudflare refuses while other Workers still send logs to it.
+8. Delete the platform KV namespaces and Hyperdrive configuration.
+9. Empty the R2 bucket, then delete it.
+10. Delete the AI Gateway.
+
+If installation configured Cloudflare Access, the uninstall plan lists its recorded applications and service tokens with their ownership and IDs. Review them in Zero Trust after uninstall. Remove installer-created resources only when nothing else uses them; resources connected from an existing company setup remain under their owner's control.
+
+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.
+
+::: details Why some resources require manual cleanup
+
+Resources that may have been shared or repurposed require manual review before deletion. Void verifies ownership, keeps those resources in place, and blocks platform traffic.
+
+If removal is interrupted, rerun the command to continue. If a resource has changed ownership, resolve the reported conflict before retrying.
+
+External PostgreSQL and its data always remain under your control.
+
+:::

package/{skills/void/docs → docs}/guide/project-collaboration.md

@@ -66,8 +66,8 @@ An invitation is bound to the registered account. Forwarding its ID does not let
 These three commands use the active platform connection selected by
 `void connect`, even inside a directory linked to another project or deployed
 directly to Cloudflare. `VOID_API_URL` takes precedence when set. If you use
-`VOID_TOKEN`, set `VOID_API_URL` to the matching platform; a token without that
-URL selects Void Cloud. Each command shows the platform it contacts.
+`VOID_TOKEN`, also set `VOID_API_URL` to the matching platform. Each command
+shows the platform it contacts.
 
 Accepting an invitation grants access without linking your current directory.
 Open the invited application's directory and run `void project link` if it is
@@ -92,3 +92,7 @@ void project team revoke <invitation-id>
 ```
 
 A non-owner member can leave with `void project team leave`. The owner cannot leave; an installation administrator must [transfer ownership](./platform/administration/projects.md#transferring-project-ownership) first.
+
+When a collaborator or admin is removed, leaves, or is changed to reader, the platform replaces the credentials the project's Workers use to call platform services such as AI, email, and remote bindings. The old credentials stop working once every Worker of the project has the new ones, usually within about 10 minutes, later while a deploy is running. If the replacement cannot finish, the old credentials keep working until it does, and owners and admins see a warning in `void project status` and `void project team list`. WebSocket connections reconnect once. While a Worker is switched to the new credentials, its calls to platform services can fail for a moment, a scheduled run can be skipped, and queue messages are delivered again a couple of minutes later.
+
+Code the removed person deployed keeps running until you replace it. If you no longer trust it, deploy code you trust; the platform replaces the credentials again after that deploy. Earlier deployments of theirs kept for rollback keep the old credentials, so after a rollback to one of them, AI, email, and ISR revalidation fail until you deploy again.

package/{skills/void/docs → docs}/guide/queues.md

@@ -137,6 +137,4 @@ curl -X POST http://localhost:5173/__void/queue \
   -d '{"queue":"my-queue","messages":[{"id":"1","timestamp":'"$(date +%s000)"',"body":{"hello":"world"},"attempts":1}]}'
 ```
 
-If you set `__VOID_PROXY_TOKEN` in `.env`, that explicit token takes precedence and the printed curl command uses `x-void-internal: <your-token>` instead.
-
 In supported meta-frameworks, use `/__void/queue` to test a consumer manually. It runs inside the framework adapter's development runtime with that adapter's bindings. Sending to a queue binding doesn't automatically invoke the consumer in this mode.

package/{skills/void/docs → docs}/guide/remote-dev.md

@@ -49,16 +49,16 @@ AI requests use your platform’s account and allowance in both local and remote
 When the dev server starts with remote mode active, it prints:
 
 ```
-⚡ Remote bindings active (my-project.apps.example.com)
-   DB      → remote D1
-   KV      → remote KV
-   STORAGE → remote R2
+[void] Remote bindings active
+         DB      → remote D1
+         KV      → remote KV
+         STORAGE → remote R2
 ```
 
 ## Limitations
 
 - **Network latency:** each binding call makes a network request, so responses may be slower than local development.
 - **R2 multipart uploads:** `createMultipartUpload()` and `resumeMultipartUpload()` are not supported in remote mode.
-- **R2 conditional writes:** `put(..., { onlyIf })` requires a current Void platform and an active deployment with the native remote-binding handler. Update the platform and redeploy the project if this operation is unavailable. Failed preconditions return `null`.
+- **R2 conditional writes:** `put(..., { onlyIf })` requires an updated platform and project deployment. Failed preconditions return `null`.
 - **D1 dump:** `db.dump()` is not supported in remote mode.
 - **D1 batches:** `db.batch()` requires an updated platform and project deployment.