void 0.26.0 → 0.26.1

package/{skills/void/docs → docs}/guide/edge/revalidation.md

@@ -108,7 +108,7 @@ Requests with `Cookie`, `Authorization`, or Cloudflare Access's `Cf-Access-Jwt-A
 
 For a dispatch rewrite, the cache key includes both the destination and original pathname. A direct request to `/en/docs/foo` therefore uses a different entry from `/docs/foo` rewritten to that destination.
 
-Query parameters are excluded by default. Add `routing.revalidateQueryAllowlist` when specific parameters should produce separate cached responses. Middleware `c.rewrite()` runs after the ISR lookup, so it doesn't create an additional cache variant.
+Query parameters are excluded by default. Add `routing.revalidateQueryAllowlist` when specific parameters should produce separate cached responses. Requests with other query parameters get the cached page. If nothing is cached yet, they render live and are not stored, so add every parameter a page reads to `routing.revalidateQueryAllowlist`. Middleware `c.rewrite()` runs after the ISR lookup, so it doesn't create an additional cache variant.
 
 Purge the destination pathname with `revalidate({ paths })`. Purging `/en/docs/foo` clears both direct and rewritten variants. Purging only `/docs/foo` won't clear them, because the entries are stored under the destination.
 

package/{skills/void/docs → docs}/guide/edge/rewrites.md

@@ -109,15 +109,13 @@ The file can include [3xx redirects](./redirects) too. Rules in `void.config.ts`
 
 ## Client navigation
 
-Rewrites run on the server. In Pages mode, a client-side `<Link to="/docs">` navigation may fetch loader data for `/docs` rather than the rewritten route `/en/docs`.
+Rewrites run on the server. In Pages mode, a client-side `<Link href="/docs">` navigation may fetch loader data for `/docs` rather than the rewritten route `/en/docs`.
 
 Use `<a href="/docs">` to make a full server request when the destination has a different loader. Use a redirect if the URL should change.
 
 ## ISR cache keys with rewrites
 
-Static rewrites cache the destination separately for each original pathname. Query parameters vary the cache only when included in `routing.revalidateQueryAllowlist`. Middleware rewrites don't create a separate cache variant.
-
-Purge the destination with `revalidate({ paths: ['/en/docs/foo'] })` to clear direct and rewritten requests. Purging only `/docs/foo` does not clear that entry. See [Revalidation](./revalidation).
+Purge the destination path, such as `/en/docs/foo`, to clear rewritten cache entries. See [Cache keys and rewrites](./revalidation#cache-keys-and-rewrites).
 
 ## Debugging with `X-Void-Routing`
 

package/{skills/void/docs → docs}/guide/email/receiving.md

@@ -100,13 +100,13 @@ There is no local inbound trigger yet — `void dev` serves the outbound dev inb
 
 ## Testing inbound handlers {#testing-inbound-handlers}
 
-Use `createInboundTestHarness` to capture replies, forwards, and rejections. For shared platform mail, pass the full address including the project prefix, such as `acme+support+abc-123@acme.dev`. For direct Cloudflare mail, set `slug: null` and use `support+abc-123@mail.acme.com`.
+Use `createInboundTestHarness` to capture replies, forwards, and rejections. For shared platform mail, pass the full address including the project prefix, such as [`acme+support+abc-123@acme.dev`](mailto:acme+support+abc-123@acme.dev). For direct Cloudflare mail, set `slug: null` and use [`support+abc-123@mail.acme.com`](mailto:support+abc-123@mail.acme.com).
 
 ```ts
 import { describe, it, expect } from 'vitest';
 import { createInboundTestHarness } from 'void/email/testing';
-import support from './email/support+[ticket]';
 import defaultHandler from './email/_default';
+import support from './email/support+[ticket]';
 
 describe('email handlers', () => {
   it('routes to support+[ticket] and extracts the tag', async () => {

package/{skills/void/docs → docs}/guide/email/sending.md

@@ -59,8 +59,6 @@ Cloudflare emails the recipient with a verification link. Once they click it and
 void email destinations
 ```
 
-The project owner’s email is added automatically, but still needs verification as described in [Setup](#setup).
-
 ::: warning When this is the right fit
 The shared sender suits team alerts, project notifications, and replies to inbound mail.
 

package/{skills/void/docs → docs}/guide/env-vars.md

@@ -39,8 +39,12 @@ STRIPE_KEY=sk_test_example
 VITE_API_ORIGIN=http://localhost:5173
 ```
 
+An unquoted value ends at `#`, which starts a comment. Quote a value that contains `#`, such as `DATABASE_URL="postgres://user:p#ss@localhost/my-app"`.
+
 Keep `.env` out of Git. Other dotenv files, including `.env.local`, `.env.production`, `.env.example`, and Wrangler’s `.dev.vars*`, are not supported.
 
+Names starting with `__VOID_` are reserved for Void. Void stops with an error if `.env` or `env.ts` defines one.
+
 Run the local check at any time:
 
 ```sh

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

@@ -70,10 +70,10 @@ curl -X POST http://localhost:5173/__void/scheduled \
   -d '{"cron":"0 * * * *","scheduledTime":'"$(date +%s000)"'}'
 ```
 
-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.
-
 The endpoint works in native Void apps and supported frameworks. Framework jobs run in the adapter's development runtime and use the bindings it provides.
 
 ## Deployment behavior
 
 Native scheduled events do not require a manual HTTP token. For framework deployments, HTTP requests to `/__void/scheduled` require a matching `x-void-internal` token: the managed platform supplies its proxy token, or you can explicitly configure `CRON_SECRET` for manual calls. An absent or mismatched token returns `401` without running a job.
+
+On a Void platform, each project can use up to 100 different cron expressions and 1,000 schedules (each expression a job exports counts as one schedule). Jobs that share an expression count once toward the expression limit. When you deploy to your own Cloudflare account, Cloudflare's [Cron Trigger limits](https://developers.cloudflare.com/workers/platform/limits/) apply instead.

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

@@ -22,6 +22,8 @@ export const live = defineLiveStream({
 });
 ```
 
+This example accepts visitors who are not signed in. Without `onSubscribe`, any connection can subscribe to any topic, so read [Authorization](#authorization) before you publish private data.
+
 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:
@@ -101,6 +103,8 @@ await live.withEnv(env).publish('post:12', { title: 'Updated title' });
 
 Only a connection's owner can change its subscriptions. The example above allows anonymous connections; authenticated streams use the current Void user by default.
 
+The owner decides who can change a connection's subscriptions, not which topics the connection can read.
+
 For authenticated streams, pass the same owner key to `connect()` and
 `control()`:
 
@@ -127,16 +131,17 @@ current authenticated user and uses `user:${user.id}` when the user has a string
 `id`. If neither path produces an owner and `allowAnonymousControl` is not set,
 the request is rejected with `403`.
 
-For stream-local subscription rules, use `onSubscribe`:
+Without `onSubscribe`, any connection that passes the owner check (any signed-in user, or any visitor when `allowAnonymousControl` is set) can subscribe to any topic and receives everything published to it. Topic names are easy to guess. Use `onSubscribe` to decide who can read each topic: return a `Response` to reject the subscription, or return nothing to allow it.
 
 ```ts
 export const live = defineLiveStream({
   id: 'app',
   async onSubscribe(ctx) {
-    const match = /^post:(.+)$/.exec(ctx.topic);
-    if (match && !(await canReadPost(ctx.env, ctx.user, match[1]))) {
-      return new Response('Forbidden', { status: 403 });
-    }
+    const post = /^post:(.+)$/.exec(ctx.topic);
+    if (post && (await canReadPost(ctx.env, ctx.user, post[1]))) return;
+    const inbox = /^user:(.+):inbox$/.exec(ctx.topic);
+    if (inbox && ctx.owner === `user:${inbox[1]}`) return;
+    return new Response('Forbidden', { status: 403 });
   },
 });
 ```

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

@@ -11,10 +11,10 @@ Use an action to change server data from a form or button. Define it in the page
 Export `action` from a `.server.ts` file. Use `withValidator()` with a [schema-derived validator](../database.md#schema-derived-validators) to validate the request body:
 
 ```ts
+import { users, insertUserSchema } from '@schema';
 // pages/users/index.server.ts
 import { defineHandler } from 'void';
 import { db } from 'void/db';
-import { users, insertUserSchema } from '@schema';
 
 export const action = defineHandler.withValidator({
   body: insertUserSchema,
@@ -176,10 +176,10 @@ const form = useForm('/users/:id', { name: '' }, { params: { id: '42' } });
 When a page needs multiple mutations, such as updating and deleting a user on the same page, export `actions` (plural) instead of `action`:
 
 ```ts
+import { users, updateUserSchema } from '@schema';
 // 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({
@@ -355,20 +355,32 @@ On the server, use `c.req.parseBody()` to access the uploaded file:
 
 ```ts
 // pages/photos.server.ts
-import { defineHandler } from 'void';
+import { defineHandler, ValidationError } from 'void/handler';
 import { storage } from 'void/storage';
 
+// file.name and file.type come from the browser. Don't use them as the key or trust the type.
+const imageTypes = new Map([
+  ['image/jpeg', 'jpg'],
+  ['image/png', 'png'],
+  ['image/webp', 'webp'],
+]);
+
 export const action = defineHandler(async (c) => {
   const body = await c.req.parseBody();
-  const file = body['photo'] as File;
-  if (file && file.size > 0) {
-    await storage.put(file.name, file.stream(), {
-      httpMetadata: { contentType: file.type },
-    });
+  const file = body['photo'];
+  if (!(file instanceof File) || file.size === 0) return;
+  const ext = imageTypes.get(file.type);
+  if (!ext) {
+    throw new ValidationError({ photo: 'Upload a JPEG, PNG, or WebP image.' });
   }
+  await storage.put(`uploads/${crypto.randomUUID()}.${ext}`, file.stream(), {
+    httpMetadata: { contentType: file.type },
+  });
 });
 ```
 
+Pick the storage key on the server and allow only the file types you expect. See [Serving Files](../storage.md#serving-files) to send them back safely.
+
 ## Choosing a Primitive
 
 | Primitive        | Page update | Form state                 | Framework-specific |

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/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
@@ -83,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

@@ -98,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/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.