void 0.21.1 → 0.21.3

package/dist/{skills-B-690E7h.mjs → skills-O6FUaizK.mjs}

@@ -1,6 +1,6 @@
-import { a as join, l as relative } from "./dist-4WkAWhWx.mjs";
+import { a as join, l as relative } from "./dist-BVqXeR_h.mjs";
 import { j as log } from "./dist-Dn6nn2IU.mjs";
-import { n as getPackageDir } from "./agents-gni4eqBu.mjs";
+import { n as getPackageDir } from "./agents-B_pX_HmQ.mjs";
 import { existsSync, mkdirSync, readFileSync, readdirSync, readlinkSync, symlinkSync } from "node:fs";
 //#region src/cli/skills.ts
 function parseSkills(skillsDir) {

package/dist/sveltekit.mjs

@@ -1,4 +1,4 @@
-import { a as join, i as isAbsolute, l as relative, u as resolve } from "./dist-4WkAWhWx.mjs";
+import { a as join, i as isAbsolute, l as relative, u as resolve } from "./dist-BVqXeR_h.mjs";
 import { existsSync, readFileSync } from "node:fs";
 //#region src/sveltekit.ts
 /**

package/dist/{validate-qNhV00PD.mjs → validate-CIUwFpjB.mjs}

@@ -1,5 +1,5 @@
-import { a as join } from "./dist-4WkAWhWx.mjs";
-import { n as readJournal, r as stripSqlExt } from "./collect-DXHNWHcT.mjs";
+import { a as join } from "./dist-BVqXeR_h.mjs";
+import { n as readJournal, r as stripSqlExt } from "./collect-DiTn9yr6.mjs";
 import { t as DESTRUCTIVE_PRAGMA, u as tokenizeSql } from "./plan-BEZ8VJW0.mjs";
 import { existsSync, readdirSync } from "node:fs";
 //#region src/migrations/validate.ts

package/dist/validate-EKmJWxmy.mjs

@@ -0,0 +1,2 @@
+import { i as validateMigrations } from "./validate-CIUwFpjB.mjs";
+export { validateMigrations };

package/dist/{wrangler-D01qs6VB.mjs → wrangler-BymcxrRa.mjs}

@@ -1,6 +1,6 @@
-import { a as join, i as isAbsolute, n as dirname, o as normalize, t as basename } from "./dist-4WkAWhWx.mjs";
-import "./project-paths-CKQ-Q5JS.mjs";
-import { m as readConfig } from "./config-Dxr6cTXn.mjs";
+import { a as join, i as isAbsolute, n as dirname, o as normalize, t as basename } from "./dist-BVqXeR_h.mjs";
+import "./project-paths-GgcMozYz.mjs";
+import { m as readConfig } from "./config-CafTW6Cz.mjs";
 import { createRequire } from "node:module";
 import { existsSync, mkdirSync, readFileSync, renameSync, rmSync, writeFileSync } from "node:fs";
 import { appendSqliteClassMigration } from "@void/deploy-core";

package/dist/{yarn-pnp-CVEc3gE7.mjs → yarn-pnp-BV4AzNul.mjs}

@@ -1,4 +1,4 @@
-import { a as join, n as dirname } from "./dist-4WkAWhWx.mjs";
+import { a as join, n as dirname } from "./dist-BVqXeR_h.mjs";
 import { existsSync, readdirSync } from "node:fs";
 import { pathToFileURL } from "node:url";
 //#region src/cli/yarn-pnp.ts

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "void",
-  "version": "0.21.1",
+  "version": "0.21.3",
   "repository": {
     "type": "git",
     "url": "git+https://github.com/voidzero-dev/void.git",
@@ -325,11 +325,11 @@
     "@cloudflare/vite-plugin": "1.54.7",
     "@cloudflare/workers-types": "^4.20260702.1",
     "@napi-rs/keyring": "2.0.0",
-    "@void/deploy-cloudflare": "0.21.1",
-    "@void/deploy-core": "0.21.1",
-    "@void/edge": "0.21.1",
-    "@void/isr": "0.21.1",
-    "@void/platform": "0.21.1",
+    "@void/deploy-cloudflare": "0.21.3",
+    "@void/deploy-core": "0.21.3",
+    "@void/edge": "0.21.3",
+    "@void/isr": "0.21.3",
+    "@void/platform": "0.21.3",
     "acorn": "^8.15.0",
     "better-auth": "^1.7.3",
     "better-sqlite3": "^13.0.3",
@@ -379,7 +379,7 @@
     "zod": "^4.6.1"
   },
   "peerDependencies": {
-    "@void/md": "0.21.1",
+    "@void/md": "0.21.3",
     "arktype": ">=2.0.0",
     "valibot": ">=1.0.0-beta.7",
     "vite": "^8.0.0",

package/schema.json

@@ -385,6 +385,24 @@
       },
       "additionalProperties": false
     },
+    "deploy": {
+      "type": "object",
+      "description": "Void deployment choices. Cloudflare Worker settings belong in cloudflare instead.",
+      "properties": {
+        "cloudflare": {
+          "type": "object",
+          "properties": {
+            "mode": {
+              "type": "string",
+              "enum": ["staged", "atomic"],
+              "description": "Staged is the default and verifies readiness before traffic. Atomic publishes a Durable Object Worker directly and verifies readiness afterward."
+            }
+          },
+          "additionalProperties": false
+        }
+      },
+      "additionalProperties": false
+    },
     "database": {
       "type": "string",
       "enum": ["pg", "mysql"],

package/skills/migrate-vite-cloudflare-to-void/SKILL.md

@@ -83,7 +83,7 @@ export default defineConfig({
 7. Deploy workflow migration
 
 - Replace old deploy instructions with:
-  - `void auth login`
+  - `void account login`
   - `void deploy`
 - If CI must target a specific project, use:
   - `void deploy --project <slug>`

package/skills/void/SKILL.md

@@ -59,7 +59,7 @@ dedicated Access applications or connect existing ones, including a separate
 identity account. Protection setup verifies API/proxy coverage and uses scoped
 service credentials for installation and CI. Use `platform config auth protection`
 to show, enable, or disable protection; retain the company gate when probes fail.
-Users link another enabled method with `void auth link [connection-id]` after
+Users link another enabled method with `void account link [connection-id]` after
 recent sign-in and explicit browser identity confirmation. For expired first-admin
 codes, resume installation or repair completed provisioning. Lost-provider recovery
 uses `platform config auth recover` with installation ownership, original recovery
@@ -79,6 +79,8 @@ For Void platform project access, use `void project team`: invite only an email
 
 Use Void commands for every user-facing workflow. Never ask the user to install, authenticate, or run Wrangler directly. Say Cloudflare or Void instead, except when naming literal `wrangler.jsonc` / `wrangler.json` files or `WRANGLER_*` environment variables the user must inspect.
 
+`void auth login|status|logout` follows the saved deploy destination or asks the user to choose; `void account` explicitly manages a Void platform account.
+
 Use `void` in examples and commands in this skill. For first-time setup, prefer `void init` followed by `void deploy`; in an empty directory, install `void` first and let `void init` add the matching Pages adapter and starter dependencies with Vite+ as the default scaffold toolchain. In an existing app, `void init` configures Void in place by adding missing Vite scripts and creating or patching `vite.config.*` with `voidPlugin()`. For Cloudflare deployment, Void uses bundled tooling and secure browser OAuth; init or the first deploy saves the selected `account_id`, and `void cloudflare login|status|logout` manages the session; Void-managed deployment requires an explicitly connected platform. Use `void connect <url>` for an existing platform or `void platform install --plan` to preview a company control plane in the user's Cloudflare account. The core self-hosted platform excludes the dashboard, GitHub App, and build Containers; lifecycle commands are resumable and verify remote, Worker, and R2 ownership before mutations. `void platform disable` gates traffic through installation-owned routing storage and remains disabled through repair or upgrade; `void platform enable` explicitly restores traffic. Safe uninstall retains name-addressed Workers, R2, AI Gateway, external PostgreSQL, and zones for explicit manual cleanup. Direct Cloudflare deploys support native Void apps, static/SPA/SSG output, and Cloudflare builds from TanStack Start, React Router, vinext, SvelteKit, Nuxt, Analog, and Astro. They provision inferred resources, validate and apply migrations, require schema-declared server values in encrypted remote secret storage, upload and probe an immutable Worker Version, then activate and synchronize triggers. Native Void features are Workers Free-compatible by default; `void/sandbox` is an explicit exception because it uses Cloudflare Containers and therefore requires Workers Paid. A Sandbox deploy checks Containers access before provisioning/building, while apps without Sandbox perform no entitlement probe. Versions without preview URLs are staged at 0% and probed through workers.dev using a version override; the same safe fallback applies when Access blocks a generated preview alias but admits the stable Worker hostname. Set `CLOUDFLARE_WORKERS_SUBDOMAIN` in a fresh CI checkout, while local deploys cache it automatically. When Cloudflare Access protects `workers.dev`, use an admitted `CF_ACCESS_CLIENT_ID` / `CF_ACCESS_CLIENT_SECRET` service-token pair for CI, or a short-lived `CF_ACCESS_TOKEN` from `cloudflared` for an interactive local readiness probe. With Cloudflare saved in `.void/project.json`, secret, domain, project status/log/rollback, and remote database commands operate directly on the pinned Worker/account. Logs are a live tail. Rollback restores the selected version's saved schedules, queues, workflows, routes, and domains but never reverses database migrations; versions without complete trigger snapshots use code-only rollback and keep the current routes and schedules. On either deployment platform, auth-enabled `void deploy` preserves an existing `BETTER_AUTH_SECRET` or creates a persistent encrypted secret when missing; always use Void's deployment flow so it can manage that secret safely.
 
 Use `void` and `@void/*` in code examples and package manifests.
@@ -110,7 +112,7 @@ If invoked without a concrete task, do a brief app status check and report:
 3. Runtime signals (`void/db`, `void/kv`, `void/storage`, queue usage).
 4. Auth signals (`void/auth`, `auth` client imports, OAuth env vars).
 5. Deployment platform and optional Void project linkage (`.void/project.json`), plus config readiness (`void.config.ts`, Cloudflare `account_id`, tsconfig extends).
-6. Optional health checks (`void auth whoami`, `void db status` when relevant).
+6. Optional health checks (`void account whoami`, `void db status` when relevant).
 
 Then ask what to do next.
 

package/skills/void/docs/guide/app-types.md

@@ -104,7 +104,7 @@ export default defineConfig({
 
 `vitepress build` emits the site, then `vite build` copies `publicDir` into `dist/client` and emits the worker into `dist/ssr`. Keep `voidPlugin()` in the **root** `vite.config.ts` only — not in the generator's own config (e.g. `.vitepress/config.ts`).
 
-Because the worker now owns unmatched requests, add [`routing.notFound`](../reference/config.md#routing-notfound) if you want the generator's `404.html` instead of the SPA-style `index.html` fallback:
+The Worker handles unmatched requests. Set [`routing.notFound`](../reference/config.md#routing-notfound) to serve the generator's `404.html` for those requests:
 
 ```json
 { "routing": { "notFound": "404-page" } }

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

@@ -218,11 +218,11 @@ When auth is active, Void configures Better Auth with these conventions:
 - D1/SQLite uses the app `DB` binding
 - PostgreSQL apps (`"database": "pg"`) use the app `HYPERDRIVE` binding
 
-Auth sessions live in the same database system as the rest of the app. `AUTH_KV` is no longer used.
+Auth sessions live in the same database system as the rest of the app.
 
 On both deployment targets, Void keeps an existing `BETTER_AUTH_SECRET` or generates one when it's missing. The value is stored as an encrypted Worker secret and reused by later versions.
 
-Localhost development uses a built-in fallback secret automatically. Production deployment through Void manages the secret lifecycle for you.
+The Vite development server uses a built-in fallback secret automatically. A local preview of a production build needs `BETTER_AUTH_SECRET`; production deployment through Void manages the secret lifecycle for you.
 
 ## Customization
 

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

@@ -21,6 +21,12 @@ For write-heavy workloads, complex queries, or connecting to existing infrastruc
 
 None. D1 is the default dialect, so you can start by defining your schema and querying.
 
+## Read replication
+
+Void enables [D1 read replication](https://developers.cloudflare.com/d1/best-practices/read-replication/) when it provisions a database. For a database that was already configured before this feature, run `void deploy --platform cloudflare --provision` once to enable it. Queries through `db` from `void/db` use a D1 session for each Void request, so reads can run near the request and later queries in that request see at least the same data. Framework handlers without Void's request scope start each database operation on the primary. `createDb` starts a replica-capable session for the binding you pass it.
+
+Replicas can lag between requests. Authentication session checks start on the primary so a revoked session is not accepted because of replica lag. If another read must start with the latest primary data, use `env.DB.withSession('first-primary')` from `cloudflare:workers`. Other query libraries and raw D1 calls need their own `withSession()` to use replicas; a bare D1 binding reads from the primary.
+
 ## Local Database
 
 `void dev` and local `void db` commands share the same database. If `cloudflare.d1_databases` in `void.config.ts` declares the D1 binding, Void uses its ID. A `preview_database_id` takes precedence during local development.

package/skills/void/docs/guide/durable-state.md

@@ -129,7 +129,7 @@ export default Counter;
 
 These state migrations are separate from Cloudflare's Durable Object class migration. Void generates the latter with `new_sqlite_classes` when it discovers the file.
 
-Do not delete or reorder generated Durable Object migrations in `void.lock.json` after deployment. Native Cloudflare beta deploys can create these classes with the Worker's first deployment, but do not yet apply a later class migration to an existing Worker. Additions, renames, and removals require an explicit supported Cloudflare deployment workflow; after its migration tag is active, `void deploy --platform cloudflare` can resume ordinary version uploads.
+Do not delete or reorder generated Durable Object migrations in `void.lock.json` after deployment. For a class addition, rename, or removal on an existing Worker, review the migration and run `void deploy --platform cloudflare --atomic`. If this Worker needs atomic publication on every deploy, set `deploy: { cloudflare: { mode: 'atomic' } }` in `void.config.ts`. Cloudflare applies class lifecycle changes in one deployment. The Worker receives traffic before Void checks readiness, and you cannot roll back across that migration boundary. Staged deploys keep pre-traffic readiness verification.
 
 ## Deployment support
 

package/skills/void/docs/guide/edge/rewrites.md

@@ -22,7 +22,7 @@ Define source patterns and destination paths in `routing.rewrites` in [`void.con
 
 ## When to use rewrites
 
-Use rewrites instead of [redirects](./redirects) when you want to decouple the **public URL** from the **internal route** without the user seeing a URL change. Common scenarios:
+Use rewrites to decouple the **public URL** from the **internal route**. Common scenarios:
 
 - **i18n routing** — serve the default locale at unprefixed paths (`/docs` serves `/en/docs`)
 - **URL restructuring** — reorganize internal route files without changing public URLs or SEO
@@ -40,7 +40,6 @@ If you **do** want the user to see the new URL (e.g., for SEO canonical signals
 - `:splat` in the destination is replaced with the portion of the path matched by `*` in the source pattern.
 - When multiple rules match, the **first match wins**. Put more-specific rules above more-general ones (matches Netlify `_redirects` and Vercel `vercel.json` semantics).
 - On the default target, rewrites are evaluated at the edge **before** the request reaches the worker. On `node` / `bun` / `deno` targets they run in-process as Hono middleware, still before route dispatch. Either way, the rewritten path is then used for static asset serving, ISR, and SSR.
-- Unlike redirects, rewrites do **not** change the URL in the browser or send a `Location` header.
 
 ## Example: i18n routing
 
@@ -107,7 +106,7 @@ After reorganizing from `/blog/:slug` to `/posts/:slug`, keep the old URLs worki
 }
 ```
 
-Unlike a redirect, users on `/blog/hello-world` won't see the URL change — they'll just see the content from `/posts/hello-world`.
+Users on `/blog/hello-world` see the content from `/posts/hello-world` at the original URL.
 
 ## Programmatic rewrites in middleware
 

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

@@ -1,6 +1,6 @@
 # Environment migration
 
-The environment model now uses `.env` for local development only and remote secrets for every server-side production value. There are no compatibility shims for the previous four-file behavior.
+Use `.env` for local development and remote secrets for server-side production values.
 
 ## 1. Preserve production values and consolidate local development values
 

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

@@ -265,7 +265,7 @@ The array is sorted by path and updates on HMR in dev when `.md` files are added
 
 ## Default CSS Theme
 
-The markdown plugin provides a minimal default theme. Unlike Vitepress, this theme is CSS only - it is designed to be built on top of. The theme ships two entry points depending on your needs:
+The markdown plugin provides a minimal CSS theme with two entry points:
 
 ### Full theme (reset + baseline + content)
 

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

@@ -107,7 +107,7 @@ Cloudflare applications for deliberate cleanup. Disabling an Access login method
 does not remove the gate.
 
 Users can add another enabled login to their existing account with
-`void auth link <connection-id>` or **Account** in the optional
+`void account link <connection-id>` or **Account** in the optional
 dashboard. Sign in again first if prompted, then authenticate with the additional
 provider and confirm the identity shown. Matching email addresses alone do not
 link accounts.

package/skills/void/docs/guide/platform/development/local.md

@@ -16,7 +16,7 @@ vpr install:void-dev
 void-dev --help
 ```
 
-Use the Node.js version recorded in `.node-version`. The workspace uses public npm packages; a GitHub Packages token is not required.
+Use the Node.js version recorded in `.node-version`.
 
 `install:void-dev` builds the CLI, shared packages, and platform runtime, then makes this checkout's built CLI globally available as `void-dev`. Public packages export their built files, so run `vp run build:core` after later source changes to refresh the alias. The installer refuses to replace an unrelated global command. Remove only this checkout's alias with `vpr uninstall:void-dev`. The commands on these development pages run from the repository root.
 

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

@@ -8,7 +8,7 @@ Start with a Cloudflare account you can administer, an account with your chosen
 
 Void creates the Workers, storage, queues, routing, and database tables through the CLI.
 
-This setup has costs: Workers for Platforms requires a paid plan, and your database and Cloudflare usage have their own pricing. External PostgreSQL is required in either mode. Native single-app deployments remain Workers Free-compatible unless the app uses a paid-only product.
+This setup has costs: Workers for Platforms requires a paid plan, and your database and Cloudflare usage have their own pricing. External PostgreSQL is required in either mode.
 
 ## Prepare Your Cloudflare Account and Domain
 
@@ -85,4 +85,4 @@ For a dedicated Supabase project, [disable the Data API](https://supabase.com/do
 
 Once installation claims the database, continue using that same database for resume and maintenance commands. Uninstall never deletes external PostgreSQL.
 
-During interactive installation, choose whether Void creates Hyperdrive or uses one you manage separately. If you choose a separately managed Hyperdrive and none exists, Void gives you the required name and setup instructions, then stops so you can create it. Name it `void-<installation-name>-database`, point it at the same dedicated PostgreSQL database using a runtime user, and disable SQL result caching. See [Cloudflare's Hyperdrive setup guide](https://developers.cloudflare.com/hyperdrive/get-started/), or ask your organization's Hyperdrive administrator to create it. Rerun the installer; Void shows the matching Hyperdrive's database, host, port, and runtime user for confirmation. Paste a database owner connection into the PostgreSQL URL prompt for installation and migrations. Void verifies that Hyperdrive points to the same database and records its identity for later maintenance without taking ownership of it. For unattended installation, supply the existing Hyperdrive ID, origin host, and runtime user through the environment variables in [Install from CI](/guide/platform/installation/ci).
+During interactive installation, choose whether Void creates Hyperdrive or uses an existing configuration in your Cloudflare account. Select an existing configuration by name and confirm its database, host, port, runtime user, and disabled SQL result caching. If you need a new separately managed configuration, choose **Set up a separately managed Hyperdrive**; Void pauses and gives you setup instructions. Create it with any unused name, point it at the dedicated PostgreSQL database using a runtime user, and disable SQL result caching. See [Cloudflare's Hyperdrive setup guide](https://developers.cloudflare.com/hyperdrive/get-started/), or ask your organization's Hyperdrive administrator to create it. Rerun the installer and select it. Paste a database owner connection into the PostgreSQL URL prompt for installation and migrations. Void verifies the selected Hyperdrive against that database, records its identity for later maintenance, and leaves its configuration under your external manager's control. For unattended installation, supply the existing Hyperdrive ID, origin host, and runtime user through the environment variables in [Install from CI](/guide/platform/installation/ci).

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

@@ -138,7 +138,7 @@ For the default GitHub-only setup:
 3. Set the **Redirect URI** (also called **Authorization callback URL**) to the exact printed URL ending in `/auth/callback`, then register the application. This URL is now pinned in your saved draft and remains the same if credential setup is interrupted.
 4. Save the **Client ID**, generate a **Client Secret**, and save that too. GitHub's [registration guide](https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/creating-an-oauth-app) describes the form.
 
-This OAuth App handles sign-in. A GitHub App with repository access and build webhooks is not required for the core platform.
+This OAuth App handles sign-in.
 
 For the default GitHub-only setup, the prompts collect the runtime token, administrator GitHub username, PostgreSQL URL, GitHub client ID and secret, R2 credentials, and signing/encryption keys. Other login methods collect their configured provider credentials and use the one-time administrator setup code described above. Secret values are masked and setup progress is encrypted locally using the system keychain. Keep a password-manager copy for recovery on another machine.
 

package/skills/void/docs/guide/project-collaboration.md

@@ -77,7 +77,7 @@ and run `void project link`.
 
 If the invitation is missing, check the platform and signed-in account. To
 switch accounts, set `VOID_API_URL` to the invitation's platform URL, unset
-`VOID_TOKEN` if present, then run `void auth logout` and `void auth login` using
+`VOID_TOKEN` if present, then run `void account logout` and `void account login` using
 the invited email address. For an expired or revoked invitation, ask a project
 administrator to invite you again.
 

package/skills/void/docs/guide/server-routing.md

@@ -29,10 +29,9 @@ routes/
 
 Excluded routes aren't included in the Worker bundle, generated types, or route and WebSocket configuration.
 
-Two things do not follow the suffix:
+`void prepare` is the exception: it boots no Vite, so it has no environment to read. It generates types for routes in both environments.
 
-- `void prepare` boots no Vite, so it has no environment to read. It generates types for every route in both environments.
-- [Binding inference](../reference/resource-inference.md) scans your source for imports and does not read the suffix. A `void/storage` import inside `api/debug.dev.ts` still adds an R2 binding to your production config, and `void deploy` still provisions the bucket. Set the binding explicitly with [`inference.bindings`](../reference/config.md#inference-bindings) if you do not want it.
+[Binding inference](../reference/resource-inference.md) follows the suffix for files in `routes/`. For example, a `void/storage` import used only in `api/debug.dev.ts` adds a development R2 binding, but does not provision a production bucket. Imports in other source directories remain available in both environments.
 
 The suffix applies to files in `routes/` only. It has no effect in `pages/`, `middleware/`, `crons/`, or `queues/`.
 

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

@@ -15,9 +15,7 @@ For most apps, [Pages Routing](./pages-routing/overview) handles SSR automatical
 Custom SSR is separate from Pages Routing. Use Custom SSR when you want to bring
 your own root component, router, data loading, HTML shell, and hydration logic.
 
-The `App` component in the examples below is not a Void convention and it is not
-the same thing as `pages/layout.tsx`. It is just the root component for your
-custom-rendered application:
+The `App` component below is the root of this custom-rendered application:
 
 ```tsx
 // src/App.tsx
@@ -26,11 +24,8 @@ export default function App({ url }: { url: string }) {
 }
 ```
 
-If you are using `pages/` with `@void/react`, `@void/vue`, `@void/svelte`, or
-`@void/solid`, do not create `src/main.ssr.*`, `src/main.client.*`, or
-`src/App.*` for Pages mode. The adapter generates the SSR and hydration entries
-and automatically composes your `pages/layout.*`, route components, loaders, and
-actions.
+Pages Routing adapters generate their own SSR and hydration entries and compose
+`pages/layout.*`, route components, loaders, and actions.
 
 ## Required entries
 
@@ -105,8 +100,7 @@ hydrateRoot(document.getElementById('root')!, <App url={window.location.pathname
 
 ## Client Asset Injection
 
-Void no longer mutates your rendered HTML automatically.
-You decide whether and where to inject client asset tags.
+Place the client asset tags in the HTML returned by your `render()` function.
 
 The `assetTags` values are computed by Void:
 

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

@@ -10,7 +10,7 @@ Typed WebSocket routes currently work in native Void apps. They aren't available
 
 Create a `.ws.ts` route to add a typed WebSocket endpoint. Void runs each route instance in a Cloudflare Durable Object, which coordinates the clients connected to it. These routes require the Cloudflare target; Node.js, Bun, and Deno builds reject them.
 
-New route classes use SQLite-backed Durable Objects on both deployment platforms. Void preserves legacy key-value-backed migration history for existing hosted projects and never reclassifies an already-created class.
+New WebSocket route classes use SQLite-backed Durable Objects on both deployment platforms.
 
 For example, a chat route at `/rooms/[id]` gives each room its own instance. Use it for chat, presence, collaborative documents, or notifications.
 

package/skills/void/docs/integrations/cloudflare.md

@@ -313,6 +313,8 @@ For apps using auth, Void creates a random 32-byte `BETTER_AUTH_SECRET` only whe
 
 Void usually checks an uploaded version before sending it traffic. When Cloudflare provides a version preview URL, Void probes that URL. Otherwise, it stages the version at 0% traffic and checks it through `workers.dev` using Cloudflare's version-override header.
 
+For an existing Durable Object Worker that Cloudflare cannot stage, review the Worker and database changes, then run `void deploy --platform cloudflare --atomic`. To use that mode on every deploy, set `deploy: { cloudflare: { mode: 'atomic' } }` in `void.config.ts`. Void will then publish directly, without first attempting staging, and check `/__void/ready` afterward. Production traffic can reach the new version before that check finishes, and a Durable Object class migration cannot be rolled back across its migration boundary. The default `staged` mode continues to check readiness before traffic. A failed staged upload is recorded locally in `.void/cloudflare-candidate.json`; keep that file for a safe retry from the same checkout.
+
 If readiness or trigger synchronization fails, Void restores the previous deployment. If you already have a gradual rollout splitting traffic across versions, finish or cancel it in Cloudflare before deploying through Void.
 
 A new Worker may need one ordinary deployment before version uploads work. This can happen when creating the Worker, establishing its first Durable Object migration history, or enabling preview URLs. Void checks that the Worker did not exist before first-deploy secret setup, deploys it once, then checks the active Worker through `/__void/ready`. It keeps that earlier check even if attaching a secret creates a placeholder version. This bootstrap is never used for an existing application.

package/skills/void/docs/reference/api.md

@@ -1193,7 +1193,7 @@ See [Markdown Pages](../guide/pages-routing/markdown.md) for setup and framework
 
 ## User-Facing Imports
 
-This table lists app-facing imports. Exported implementation subpaths such as `void/pages*`, `void/runtime/*`, and `void/remote*` are used by adapters, generated entries, or internal runtime wiring and are not documented as application APIs.
+Import Void's app-facing APIs from these paths:
 
 | Import path               | Contents                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   |
 | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |

package/skills/void/docs/reference/cli.md

@@ -28,7 +28,8 @@ Use this page as a command reference. If you are setting up a project for the fi
 | `void secret sync .env`           | Bulk upload secrets from dotenv file                                          |
 | `void env check [--remote]`       | Validate env.ts schema                                                        |
 | `void env types`                  | Regenerate .void/env.d.ts from env.ts                                         |
-| `void auth login`                 | Authenticate with Void                                                        |
+| `void auth login`                 | Authenticate with the project’s saved destination, or choose one              |
+| `void account login`              | Authenticate with a Void platform                                             |
 | `void cloudflare login`           | Authenticate with Cloudflare through Void                                     |
 | `void platform install`           | Install a company Void platform in Cloudflare                                 |
 | `void connect <url>`              | Connect the CLI to a Void platform                                            |
@@ -169,9 +170,23 @@ The deployment preference is saved in `.void/project.json`. Connecting to anothe
 
 In a non-interactive shell, supply a URL or explicit target. Cloudflare requires usable credentials and an unambiguous account (`CLOUDFLARE_ACCOUNT_ID` when needed). For a Void platform, provide `VOID_TOKEN` with a matching `VOID_API_URL`, or reuse a valid origin-scoped keychain session. Use `void connect <url> --no-login` to save the verified connection without authenticating; this option is only available for Void platforms.
 
-## Auth
+## Authentication
 
-### `void auth login`
+`void auth login`, `void auth status`, and `void auth logout` use the destination
+saved for the current project by `void init` or `void connect`. If no destination
+is saved, interactive commands let you choose Cloudflare or a connected Void
+platform. In a non-interactive shell, pass `--platform cloudflare|void` or use
+the explicit `void cloudflare` and `void account` commands. Choosing a destination
+for authentication does not change the project's deploy target.
+
+`void auth whoami`, `void auth link`, and `void auth token` remain supported for
+existing scripts. `whoami` follows the selected destination; `link` and `token`
+are Void account operations. Prefer `void auth status`, `void account link`, and
+`void account token` in new scripts.
+
+## Void platform account
+
+### `void account login`
 
 Browser login through one of the platform's currently enabled methods. The token is saved in the operating-system keychain, scoped to the platform origin. Login fails closed when no keychain is available instead of writing the token to a plaintext file; headless environments use `VOID_TOKEN` from their secret manager.
 
@@ -182,22 +197,22 @@ saved login instead, unset `VOID_TOKEN`.
 
 This is optional if you already completed auth during `void connect` or the interactive `void init` flow.
 
-### `void auth link [connection-id]`
+### `void account link [connection-id]`
 
 Link another enabled login method to your current account. Sign in again if your
 session is no longer recent, complete the additional provider's browser login,
 and confirm the displayed identity. With no connection ID, choose an enabled
 method interactively. The optional dashboard exposes the same flow in **Account**.
 
-### `void auth logout`
+### `void account logout`
 
 Removes saved credentials.
 
-### `void auth whoami`
+### `void account whoami`
 
 Prints your current login.
 
-### `void auth token`
+### `void account token`
 
 Copies your human auth token to the system clipboard. It is intended for
 interactive troubleshooting and remains subject to login-method revocation. Do
@@ -785,7 +800,7 @@ Setup drafts save Worker names, the login callback, and partial credentials encr
 
 Use an empty PostgreSQL database dedicated to the installation. You can correct a failed initial connection, but after the database is claimed or Hyperdrive is provisioned, commands reject a different URL.
 
-During interactive installation, choose whether Void creates Hyperdrive or uses one you manage separately. If the separately managed configuration is missing, Void shows the required name and setup instructions, then stops before provisioning. Once it exists, Void shows its database, host, port, runtime user, and cache setting for confirmation. Supply an owner PostgreSQL URL at the normal prompt for database claims and migrations. Void adopts the Hyperdrive after verifying its origin and disabled SQL result caching; its configuration stays under the external manager's control. Unattended installs can set `VOID_PLATFORM_HYPERDRIVE_ID`, `VOID_PLATFORM_HYPERDRIVE_ORIGIN_HOST`, and `VOID_PLATFORM_HYPERDRIVE_ORIGIN_USER` together.
+During interactive installation, choose whether Void creates Hyperdrive or uses an existing one. The installer lists the account's Hyperdrive configurations, suggests a matching generated name when present, and lets you select any configuration. Review its database, host, port, runtime user, and cache setting before confirming; its name need not match the installation name. If you need to create a separately managed configuration, Void shows setup instructions and stops before provisioning. Supply an owner PostgreSQL URL at the normal prompt for database claims and migrations. Void adopts the selected Hyperdrive after verifying its database origin and disabled SQL result caching; its configuration stays under the external manager's control. Unattended installs can set `VOID_PLATFORM_HYPERDRIVE_ID`, `VOID_PLATFORM_HYPERDRIVE_ORIGIN_HOST`, and `VOID_PLATFORM_HYPERDRIVE_ORIGIN_USER` together.
 
 Recovery secrets are encrypted with AES-256-GCM using a key in your system keychain. The encrypted data is tied to the installation identity. Without a keychain, supply a canonical base64-encoded 32-byte `VOID_PLATFORM_RECOVERY_KEY`; otherwise Void stops before saving secrets. CI can generate a temporary key when its original credentials remain in protected secrets.
 
@@ -864,6 +879,7 @@ See [Disable and Uninstall](../guide/platform/installation/uninstall.md) for the
 ```
 void deploy [--project <name>] [--dir <path>] [--spa] [--skip-build] [--debug]
 void deploy [--platform <cloudflare|void>] [--require-email]
+void deploy --platform cloudflare --atomic
 ```
 
 Auto-detects your project type and chooses the right pipeline. See [Supported App Types](../guide/app-types.md) and [Deployment](../guide/deployment.md) for details.
@@ -884,8 +900,11 @@ For Drizzle projects, deploy performs a read-only schema drift check. If a new m
 | `--spa`                         | Use SPA mode instead of SSG for static deploys                                                     |
 | `--skip-build`                  | Skip the build step; on Cloudflare this is supported for static/SPA/SSG deploys only               |
 | `--require-email`               | Fail when email cannot be set up instead of deploying without it; requires `--platform cloudflare` |
+| `--atomic`                      | Publish an existing Durable Object Worker directly; readiness is checked after traffic changes     |
 | `--debug`                       | Mirror the structured deploy log to stderr (also written to `~/.void/logs/`)                       |
 
+`--atomic` applies to one deployment. For an existing Durable Object Worker that consistently cannot stage, set `deploy: { cloudflare: { mode: 'atomic' } }` in `void.config.ts` so plain `void deploy` uses atomic publication. The default is `staged`.
+
 The older `--backend cloudflare` spelling remains available as a compatibility alias for `--platform cloudflare`.
 
 Every deploy writes a structured JSONL trace to `~/.void/logs/deploy-<timestamp>.jsonl` regardless of `--debug`. On failure the path is printed at the end of the error message so you can attach it when reporting platform issues. `VOID_DEPLOY_DEBUG=1` is accepted as an alternate trigger for stderr mirroring.
@@ -971,7 +990,7 @@ If Cloudflare Access protects readiness URLs, supply an allowed `CF_ACCESS_CLIEN
 
 Secrets and migrations are validated after the build, so a failed check may leave provisioned resources. It doesn't apply remote D1 migrations or upload the application Worker. PostgreSQL migrations are transactional; MySQL schema changes may partially apply on error.
 
-Void records provisioned resource IDs in `void.lock.json`. Commit it for other machines and CI. Run the first deploy from one machine at a time; provisioning locks are local. The `--provision` flag is accepted but no longer needed.
+Void records provisioned resource IDs in `void.lock.json`. Commit it for other machines and CI. Run the first deploy from one machine at a time; provisioning locks are local.
 
 `.env` stays local. Store server keys declared in `env.ts` with `void secret put <NAME>`; Void rejects them as plaintext Worker vars. If the first deploy reports missing remote secrets, set them and retry. Custom D1 migration layouts must match the exact files, contents, and order Void validated. Direct deploy and Cloudflare commands use the top-level settings, not named environments or alternate config paths.
 
@@ -1095,7 +1114,9 @@ void db export [--output <path>] [--no-data] [--no-schema] [--table <name>]
 
 Dump the local database as SQL. Outputs to stdout by default (pipeable), or to a file with `--output`.
 
-Data exports preserve SQLite AUTOINCREMENT and PostgreSQL SERIAL counters, including IDs consumed by deleted rows. PostgreSQL schema exports create serial sequences before their tables and restore ownership, constraints, and indexes afterward. `--no-schema` restores counter values into an existing schema; `--no-data` starts counters at their schema-defined starting values.
+Data exports preserve SQLite AUTOINCREMENT and PostgreSQL SERIAL and identity counters, including IDs consumed by deleted rows. SQLite schema exports include indexes, views, and triggers. PostgreSQL schema exports preserve column types, generated columns, identity definitions, serial sequences, constraints, and indexes. `--no-schema` restores counter values into an existing schema; `--no-data` starts counters at their schema-defined starting values.
+
+For PostgreSQL schemas with views, triggers, custom types, functions, or standalone sequences, use `pg_dump` for a complete backup. `void db export` reports these objects before writing a schema dump.
 
 | Flag              | Purpose                            |
 | ----------------- | ---------------------------------- |
@@ -1300,12 +1321,12 @@ Deploy-on-GitHub works from **any** Void login — Google, GitHub, or other SSO.
 void github link
 ```
 
-Link your current Void account to a GitHub identity. Opens your browser to authorize Void on GitHub (a localhost + PKCE handshake, the same mechanics as `void auth login`), then binds that GitHub identity to the logged-in account. Requires an authenticated CLI (`void auth login` first).
+Link your current Void account to a GitHub identity. Opens your browser to authorize Void on GitHub (a localhost + PKCE handshake, the same mechanics as `void account login`), then binds that GitHub identity to the logged-in account. Requires an authenticated CLI (`void account login` first).
 
 You normally don't need to run this directly — `void github install` runs the link automatically when your account has no GitHub identity yet. Run it on its own to link ahead of time, or to link a GitHub identity without installing the App.
 
 ::: warning Existing GitHub sign-in
-Void accounts cannot be merged. If the GitHub account you authorize is already linked to a different Void account, including one created through GitHub sign-in, `void github link` is refused with `This GitHub account is already linked to another Void account.` Run `void auth logout` and sign in to that existing account, or authorize a different GitHub account. The command is also refused if your current Void account is already linked to a different GitHub identity. Re-authorizing the GitHub account attached to your current Void account is allowed and reports `GitHub account already linked.`
+Void accounts cannot be merged. If the GitHub account you authorize is already linked to a different Void account, including one created through GitHub sign-in, `void github link` is refused with `This GitHub account is already linked to another Void account.` Run `void account logout` and sign in to that existing account, or authorize a different GitHub account. The command is also refused if your current Void account is already linked to a different GitHub identity. Re-authorizing the GitHub account attached to your current Void account is allowed and reports `GitHub account already linked.`
 :::
 
 ### `void github install`
@@ -1334,7 +1355,7 @@ Join the GitHub App installations your organization already has. If a teammate i
 
 In an interactive terminal you rarely need to run this yourself — `void github connect` runs the same join automatically when no active installations are linked to your account. Running `void github join` yourself matters mainly for non-interactive use (without a TTY, `void github connect` never opens a browser), or to link installations ahead of time.
 
-Requires an authenticated CLI (`void auth login` first) and organization-installation sharing enabled on your Void instance; when it is not enabled the command fails closed with a clear message. You can only join installations your GitHub authorization actually returns — you cannot name or join one you cannot access on GitHub.
+Requires an authenticated CLI (`void account login` first) and organization-installation sharing enabled on your Void instance; when it is not enabled the command fails closed with a clear message. You can only join installations your GitHub authorization actually returns — you cannot name or join one you cannot access on GitHub.
 
 ### `void github connect`
 

package/skills/void/docs/reference/config.md

@@ -217,7 +217,7 @@ Use remote D1/KV/R2 bindings during local development instead of local miniflare
 
 **Requirements:**
 
-- Must be logged in (`void auth login`)
+- Must be logged in (`void account login`)
 - Must have a linked project (`void project link`)
 - Only affects D1 (`DB`), KV (`KV`), and R2 (`STORAGE`) bindings
 
@@ -316,6 +316,17 @@ Void writes a generated Cloudflare config for its tooling and records provisione
 
 If you need to remove a value that Void previously generated, remove it from the `resolved` object in `void.lock.json`. Void refreshes the generated Cloudflare file on the next command. Put ongoing custom settings in `cloudflare` in `void.config.ts`.
 
+### `deploy.cloudflare.mode`
+
+Direct Cloudflare deploys use `staged` by default: Void checks the new Worker before sending it production traffic. If Cloudflare cannot stage an existing Durable Object Worker, choose `atomic` after reviewing the pending Worker and database changes:
+
+```ts
+// Inside defineConfig({ ... })
+deploy: { cloudflare: { mode: 'atomic' } },
+```
+
+This choice applies to subsequent `void deploy` runs. Atomic deployment sends traffic to the new Worker before Void checks readiness; a Durable Object class migration cannot be rolled back across its migration boundary. Use `--atomic` for a single deployment instead. `deploy` is a Void setting and is not passed to Cloudflare's Worker config.
+
 `worker.limits.cpu_ms` sets the CPU time limit per request, from 1 to 300000 ms. On a Void platform, deploy fails if the limit exceeds the account plan; lower it in `void.config.ts` before retrying. Rollback instead caps the old limit at the current plan ceiling. On direct deploys, [Cloudflare enforces the value](https://developers.cloudflare.com/workers/platform/limits/#cpu-time): Workers Free allows up to 10 ms and Workers Paid up to 300000 ms per request.
 
 ```json

package/skills/void/docs/reference/resource-inference.md

@@ -31,7 +31,7 @@ This runs once before plugins initialize, so the results are available to config
 
 Auth detection also triggers when importing the `auth` specifier from `void/client` or a framework-specific client subpath such as `void/client/react` (but not when importing only `fetch`).
 
-Durable state uses a filesystem convention rather than the import scanner. For example, `durable-objects/shopping-cart.ts` creates the `SHOPPING_CART` binding, exports `ShoppingCartDurableObject`, and adds a `new_sqlite_classes` migration. See [Durable State](../guide/durable-state.md).
+Durable state is inferred from files in `durable-objects/`. For example, `durable-objects/shopping-cart.ts` creates the `SHOPPING_CART` binding, exports `ShoppingCartDurableObject`, and adds a `new_sqlite_classes` migration. See [Durable State](../guide/durable-state.md).
 
 ## Scanned Directories
 

package/dist/client-DAAivdid.mjs

@@ -1,2 +0,0 @@
-import { n as PlatformClient } from "./client-PdAJ-F0t.mjs";
-export { PlatformClient };

package/dist/collect-DAUItMDS.mjs

@@ -1,2 +0,0 @@
-import { t as collectMigrations } from "./collect-DXHNWHcT.mjs";
-export { collectMigrations };

package/dist/config-DDIFxQYx.mjs

@@ -1,2 +0,0 @@
-import { t as writeDrizzleConfig } from "./config-BSe70f4T.mjs";
-export { writeDrizzleConfig };