void 0.24.0 → 0.25.0

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

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

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

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

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

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

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

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

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

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

package/skills/void/docs/guide/platform/administration/zero-trust.md

@@ -8,10 +8,7 @@ Project Zero Trust puts Cloudflare Access in front of the hostnames of projects
 
 This is separate from the Access login and protection for the platform API. Projects deployed directly to Cloudflare are not affected.
 
-New installations choose app access during `void platform install`. The installer
-reuses the platform policy or helps you select separate company rules, and finishes
-setup before opening traffic. Existing installations keep their settings when
-upgraded; use this page to configure app access if it has not been set up yet.
+Choose app access during `void platform install`, or configure it later using this page. The installer reuses the platform policy or helps you select separate company rules, and finishes setup before opening traffic.
 
 If you choose public apps in an account with Default-Deny, Void manages scoped
 public rules instead. New projects and custom domains remain public automatically.

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

@@ -14,7 +14,13 @@ vp run --filter @voidcloud/api db:generate
 
 Review the generated SQL and migration journal before committing them. Released migrations are append-only. An upgrade applies new migrations while the previous Workers may still serve requests, so schema changes must remain compatible with that code.
 
-`platform/packages/api/drizzle/compatibility.json` records which earlier runtimes have been verified against the new schema. Add an edge only after testing that compatibility. The runtime build checks that the migration files and recorded schema history agree. See `packages/platform/README.md` for the manifest contract.
+`platform/packages/api/drizzle/compatibility.json` records which earlier runtimes have been verified against the new schema. Add an edge only after testing that compatibility. The runtime build checks that the migration files and recorded schema history agree.
+
+## Runtime artifact contract
+
+`@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.
 
 ## CI in a Fork
 

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

@@ -42,11 +42,6 @@ secret manager to an object keyed by each exact API/proxy origin, with
 and stops if the gate still rejects its checks. Account-wide Default-Deny and
 deployed-application policies remain your responsibility.
 
-If **System Status** reports `proxy HTTP 302 (redirect)` on an older Access-protected
-installation, upgrade with `void platform upgrade <id>`. Current installations use
-a private connection for the dashboard's proxy health check. Keep the proxy's
-Access protection enabled.
-
 ### Expired administrator setup code
 
 Resume an unfinished installation with `void platform install --resume --name <id>`.
@@ -68,7 +63,7 @@ Repair recreates missing infrastructure that the installer owns. It does not res
 
 ### Upgrade the platform
 
-Keep the platform runtime current when updating the Void CLI. If a developer's CLI reports that project lookup requires an upgrade, upgrade the platform before retrying.
+Keep the platform runtime current when updating the Void CLI.
 
 Use the installed CLI's packaged runtime to upgrade:
 
@@ -92,10 +87,6 @@ manager so they can also restore a missing Worker during repair.
 
 Database migrations only move forward. Void checks compatibility before upgrading and tells you if an intermediate release is needed. If deployment fails, it attempts to restore the previous Workers against the compatible database schema. Retrying does not repeat completed migrations.
 
-Upgrades automatically enable managed Sandboxes. The platform runtime token needs Account / Containers: Edit and Account / Cloudchamber: Edit, and the Cloudflare account must use Workers Paid before its first Sandbox application deploy. The upgrade itself does not probe Containers access, so platforms that do not deploy Sandbox applications need no additional plan or permissions.
-
-When upgrading from a release that used tenant-owned Sandbox containers, the upgrade may first ask you to finish the legacy cleanup. Follow the [`sandbox-drain` instructions](../../../reference/cli/platform-operations.md#operator-system), then rerun the upgrade. Administrator login remains available during that maintenance step.
-
 After a successful upgrade, you can restore a declared-compatible earlier runtime without reversing migrations:
 
 ```sh
@@ -107,6 +98,35 @@ Keep the earlier runtime files if you need rollback. If the installed version is
 
 :::
 
+### Follow upgrade and rollback progress
+
+Watching progress is optional: a running upgrade or rollback proceeds through
+the CLI without action on the status page. During maintenance, navigating the
+admin UI automatically redirects to `/admin/status`. You can also open it
+directly on your platform API origin and sign in as an administrator.
+
+The read-only page shows the saved operation, source and target versions, and
+the traffic state reported by the API. It refreshes automatically every five
+seconds while visible. If updates fail, it keeps the last confirmed snapshot
+and marks it as out of date. Normal administrator changes remain paused.
+
+Sign-in and status remain available while the API and authentication database
+are reachable. An operation completing
+does not confirm every project's health. A disabled installation keeps traffic
+paused after an upgrade or rollback.
+
+If an operation fails or waits for DNS or Sandbox drain work, the CLI prints
+the recovery instructions and command needed to resume. Resolve the reported
+problem, then resume with the same runtime files. For a custom rollback, retain
+the source runtime files too. `void platform status <id>` also prints locally saved progress
+before checking the live API; this local checkpoint can be out of date if another
+administrator changed the installation.
+
+When application traffic is paused, visitors receive a temporary-unavailability
+page with a **Try again** link. API requests and form submissions still receive
+HTTP 503 responses. Void does not automatically replay requests; visitors who
+submitted a form should check its result before submitting it again.
+
 ### Manage an installation from another machine
 
 Use `discover` to restore the administrator's local installation records:

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

@@ -73,16 +73,88 @@ Use any PostgreSQL provider that accepts connections from your computer and Clou
 2. Open the provider's connection details and select the primary database. Use a direct connection or a session-mode pooler, not transaction pooling. The connection must work from both your computer and Cloudflare.
 3. Copy the PostgreSQL connection URL, including the password and SSL settings, into your password manager. Paste only the URL—not a surrounding `psql` command—into Void's `PostgreSQL DATABASE_URL` prompt, as the provider gives it, including SSL settings such as `sslmode=verify-full`. A Hyperdrive that Void creates trusts only public certificate authorities, so if your database uses a private certificate authority, use a separately managed Hyperdrive, as described below.
 
-| Provider                                                                     | Connection setup                                                                                                                                                                                                                                      |
-| ---------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| [PlanetScale Postgres](https://planetscale.com/docs/postgres/connecting)     | Choose **Postgres**, not Vitess/MySQL. Open **Connect**, create role credentials, and use the direct primary connection on port `5432`, not PgBouncer on `6432`.                                                                                      |
-| [Neon](https://neon.com/docs/get-started-with-neon/connect-neon)             | Open **Connect**, select the database and owner role, and turn **connection pooling off**.                                                                                                                                                            |
-| [Supabase](https://supabase.com/docs/guides/database/connecting-to-postgres) | Open **Connect** and use the direct connection where IPv6 is available, or the **Session pooler** on port `5432` for IPv4 connectivity. Do not select the transaction pooler on `6543`. Replace the password placeholder with your database password. |
-
-For a dedicated Supabase project, [disable the Data API](https://supabase.com/docs/guides/api/securing-your-api#disable-the-data-api) so the platform's tables are not exposed through Supabase's auto-generated endpoints. Void uses the PostgreSQL connection, not Supabase API keys.
+| Provider                                                                 | Connection setup                                                                                                                                                 |
+| ------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| [PlanetScale Postgres](https://planetscale.com/docs/postgres/connecting) | Choose **Postgres**, not Vitess/MySQL. Open **Connect**, create role credentials, and use the direct primary connection on port `5432`, not PgBouncer on `6432`. |
+| [Neon](https://neon.com/docs/get-started-with-neon/connect-neon)         | Open **Connect**, select the database and owner role, and turn **connection pooling off**.                                                                       |
 
 Once installation claims the database, continue using that same database for resume and maintenance commands. Uninstall never deletes external PostgreSQL.
 
+### Use a provider CLI
+
+You can create the database and retrieve its connection URL from either provider's CLI instead of its dashboard.
+
+::: details PlanetScale Postgres
+
+Install the latest [PlanetScale CLI](https://planetscale.com/docs/cli/planetscale-environment-setup). On macOS, use `brew install pscale`; the installation guide also covers Linux and Windows.
+
+Sign in and list your organizations and regions:
+
+```sh
+pscale auth login
+pscale org list
+pscale region list --org <organization>
+```
+
+Replace `<organization>` with your organization slug and choose a region. List the available Postgres cluster sizes and their prices for that region:
+
+```sh
+pscale size cluster list --org <organization> --engine postgresql --region <region>
+```
+
+Create a dedicated Postgres database with your chosen cluster size, then create a role with permission to create and migrate Void's tables:
+
+```sh
+pscale database create void-platform \
+  --org <organization> \
+  --engine postgresql \
+  --region <region> \
+  --cluster-size <cluster-size> \
+  --wait
+
+pscale role create void-platform main void_owner \
+  --org <organization> \
+  --inherited-roles postgres
+```
+
+Save the **DATABASE URL** printed by the role-creation command in your password manager and paste it into Void's `PostgreSQL DATABASE_URL` prompt. Use the direct primary connection on port `5432` with `sslmode=verify-full`. The role's password is shown when it is created, so save it before closing the terminal.
+
+See PlanetScale's [database commands](https://planetscale.com/docs/cli/database) and [role commands](https://planetscale.com/docs/cli/role) for more options.
+
+:::
+
+::: details Neon
+
+Install the latest [Neon CLI](https://neon.com/docs/cli/install) and sign in:
+
+```sh
+pnpm add --global neon@latest
+neon login
+```
+
+Create a dedicated project, database, and owner role. Replace `<region-id>` with one of Neon's [supported regions](https://neon.com/docs/cli/projects#create), such as `aws-us-east-2`:
+
+```sh
+neon projects create --name void-platform \
+  --database void_platform \
+  --role void_owner \
+  --region-id <region-id>
+```
+
+Use the project ID from the output to retrieve a direct primary connection URL with TLS certificate verification:
+
+```sh
+neon connection-string --project-id <project-id> \
+  --database-name void_platform \
+  --role-name void_owner \
+  --endpoint-type read_write \
+  --ssl verify-full
+```
+
+Save the printed URL in your password manager and paste it into Void's `PostgreSQL DATABASE_URL` prompt. Keep this connection unpooled. See Neon's [connection-string command](https://neon.com/docs/cli/connection-string) for more options.
+
+:::
+
 ### Use an existing Hyperdrive
 
 The installer can create Hyperdrive for you or use one you manage separately. For an existing configuration:

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

@@ -4,65 +4,51 @@ outline: deep
 
 # Quickstart
 
-Create a Void app, run it locally, and deploy it. You can also [add Void to an existing Vite app](#adding-to-an-existing-vite-app). Use Node.js 24.21.0 or later.
+Create a Void app, run it locally, and deploy it. You can also [add Void to an existing Vite app](#adding-to-an-existing-vite-app).
 
-## Start in an Empty Directory
+## Create an app
 
-Install Void in an empty project directory:
+In an empty directory, install Void and run setup:
 
 ::: code-group
 
 ```sh [npm]
 npm install -D void
+npx void init
 ```
 
 ```sh [pnpm]
 pnpm add -D void
+pnpm void init
 ```
 
 ```sh [yarn]
 yarn add -D void
+yarn void init
 ```
 
 ```sh [bun]
 bun add -D void
+bunx void init
 ```
 
 :::
 
-Run setup:
-
-::: code-group
-
-```sh [npm]
-npx void init
-```
+Choose your UI framework, a starter, and a deployment target. Vite+ is the default build tool. D1 is a good first database: it runs locally without a separate database server. Choose Cloudflare to deploy to your own account, or skip deployment setup for now.
 
-```sh [pnpm]
-pnpm void init
-```
+With pnpm, `pnpm create void my-app` also creates the project directory and configures native build permissions for you.
 
-```sh [yarn]
-yarn void init
-```
+## Run locally
 
-```sh [bun]
-bunx void init
+```sh
+npm run dev
 ```
 
-:::
-
-Void asks you to choose Vite+ or Vite, a UI framework, a starter, and a deployment target. Vite+ is the default. D1 needs no local database server; choose PostgreSQL or MySQL if you use an external database. You can skip deployment setup and decide later.
-
-With pnpm, you can start with `pnpm create void my-app`. It configures native build permissions before installing Void.
-
-The examples below use `void` for brevity. Outside package scripts, run the local binary with `npx void`, `pnpm void`, `yarn void`, or `bunx void`. Keep Void installed in the project so the CLI and app use the same version.
+Open `http://localhost:5173`. In a Pages starter, `pages/` contains your UI and companion `.server.ts` files contain its server loaders and actions. Loaders return data to page components as typed props.
 
-## Run and deploy
+## Call a server route
 
-### 1. Edit the generated API route
-
-Database-backed starters include `routes/api/hello.ts`. You can edit its `GET` handler, or create this file if you started with Static Pages:
+Edit `routes/api/hello.ts`, or create it if your starter doesn't include it:
 
 ```ts
 import { defineHandler } from 'void';
@@ -72,75 +58,46 @@ export const GET = defineHandler(() => {
 });
 ```
 
-### 2. Run locally
-
-```sh
-npm run dev
-```
+Visit `http://localhost:5173/api/hello` to see the response. From your client code, call it with Void's typed fetch:
 
-Then visit:
+```ts
+import { fetch } from 'void/client';
 
-- App: `http://localhost:5173`
-- API route: `http://localhost:5173/api/hello`
+const { message } = await fetch('/api/hello');
+```
 
-### 3. Deploy
+The file path defines the URL, and the handler defines the response type. Change `message` in the handler and TypeScript checks the client against the new shape.
 
-If you chose a deployment target during setup, run:
+Database starters also include `db/schema.ts`. Its Drizzle schema defines your tables and query types; Void runs a local database and provisions one when you deploy.
 
-```sh
-void deploy
-```
+## Deploy
 
-If you skipped deployment setup, select your Cloudflare account for the first deploy:
+If you chose a target during setup:
 
 ```sh
-void deploy --platform cloudflare
+npx void deploy
 ```
 
-Void opens your browser to sign in when needed. To use your team's platform, connect using the API URL from your administrator, then link a project and deploy:
+If you skipped setup, select your Cloudflare account:
 
 ```sh
-void connect https://platform.example.com
-void project link
-void deploy
+npx void deploy --platform cloudflare
 ```
 
-Void builds the app, provisions its resources, applies pending migrations, and prints the deployed URL. If a production secret is missing, [set it](./env-vars.md) and deploy again. Later deploys use the saved target.
-
-See [Deployment](./deployment.md) for CI setup and rollback.
-
-## Using with Coding Agents
-
-`void init` detects your coding agent and installs its instructions and skills. If no agent is detected, use the bundled docs linked in `AGENTS.md`. In agents that support it, load the `/void` skill and describe the app you want to build. See [Coding Agents](../integrations/agents) for setup details.
+Void opens your browser to sign in when needed, builds the app, provisions resources, applies migrations, and prints the deployed URL. Later deploys use the saved target. See [Deployment](./deployment.md) for team platforms, CI, and rollback.
 
-## Meta Frameworks
+## Adding to an existing Vite app
 
-Use Void's [Pages routing](./pages-routing/overview) or keep a framework such as TanStack Start, React Router, or SvelteKit. Follow the [framework guides](../integrations/frameworks/overview) for setup.
+Install Void and run `void init` with your package manager as shown [above](#create-an-app). Setup adds `voidPlugin()` to your Vite config and creates the remaining project files. If the config needs a manual edit, the CLI shows the change to make.
 
-## Adding to an Existing Vite App
+For a meta framework such as TanStack Start, React Router, or SvelteKit, follow its [integration guide](../integrations/frameworks/overview.md).
 
-Install Void using the package manager command [above](#start-in-an-empty-directory).
-
-Enable the plugin in `vite.config.ts`:
-
-```ts
-import { defineConfig } from 'vite';
-import { voidPlugin } from 'void';
-
-export default defineConfig({
-  plugins: [voidPlugin()],
-});
-```
-
-Then run `void init` with your package manager to configure the remaining project files.
+## Next steps
 
-## Troubleshooting pnpm installs
+- [Pages Routing](./pages-routing/overview.md): loaders, layouts, and forms
+- [Server Routing](./server-routing.md): params, middleware, and validation
+- [Database](./database.md): queries and migrations
+- [Environment Variables](./env-vars.md): local values and production secrets
+- [Coding Agents](../integrations/agents.md): use Void's bundled docs and skills
 
 If a manual pnpm install reports blocked build scripts, run `pnpm approve-builds` for `esbuild`, `sharp`, and `workerd`. Set `better-sqlite3: false` in `pnpm-workspace.yaml`'s `allowBuilds`; Void uses its bundled binaries.
-
-## Next steps
-
-- To understand what kind of apps are supported: [Supported App Types](./app-types)
-- [Server Routing](./server-routing): dynamic params, middleware, and validation
-- [Database](./database): queries, migrations, and generated types
-- [Type Safety](./type-safety): end-to-end typed fetch client