void 0.10.13 → 0.20.1

package/dist/{yarn-pnp-DJn3SAHF.mjs → yarn-pnp-DxSInkzL.mjs}

@@ -1,4 +1,4 @@
-import { a as join, n as dirname } from "./dist-DaKKDf8D.mjs";
+import { n as dirname, o as join } from "./dist-BrsS7cai.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.10.13",
+  "version": "0.20.1",
   "repository": {
     "type": "git",
     "url": "git+https://github.com/voidzero-dev/void.git",
@@ -13,14 +13,14 @@
     "dist",
     "schema.json",
     "skills",
-    "AGENT_PROMPT.md",
-    "getting-started-prompt.txt",
+    "AGENTS_TEMPLATE.md",
     "README.md"
   ],
   "type": "module",
   "imports": {
     "#self": "./dist/index.mjs",
     "#self/_env": "./dist/runtime/env.mjs",
+    "#self/email": "./dist/runtime/email.mjs",
     "#self/env": "./dist/runtime/env-public.mjs",
     "#self/client": "./dist/runtime/client.mjs",
     "#self/handler": "./dist/runtime/handler.mjs",
@@ -38,9 +38,9 @@
     "#self/runtime/live-server": "./dist/runtime/live-server.mjs",
     "#self/runtime/fetch": "./dist/runtime/fetch.mjs",
     "#self/runtime/fetch-stream": "./dist/runtime/fetch-stream.mjs",
-    "#self/runtime/isr-cache": "./dist/runtime/isr-cache.mjs",
     "#self/runtime/migration-handler": "./dist/runtime/migration-handler.mjs",
     "#self/runtime/migration-handler-pg": "./dist/runtime/migration-handler-pg.mjs",
+    "#self/runtime/migration-handler-mysql": "./dist/runtime/migration-handler-mysql.mjs",
     "#self/runtime/ws-server": "./dist/runtime/ws-server.mjs"
   },
   "exports": {
@@ -50,6 +50,16 @@
       "require": "./dist/index.mjs"
     },
     "./schema.json": "./schema.json",
+    "./database-provider": {
+      "types": "./dist/database-provider.d.mts",
+      "import": "./dist/database-provider.mjs",
+      "require": "./dist/database-provider.mjs"
+    },
+    "./edge": {
+      "types": "./dist/edge.d.mts",
+      "import": "./dist/edge.mjs",
+      "require": "./dist/edge.mjs"
+    },
     "./handler": {
       "types": "./dist/runtime/handler.d.mts",
       "import": "./dist/runtime/handler.mjs",
@@ -103,16 +113,6 @@
       "import": "./dist/runtime/client-solid.mjs",
       "require": "./dist/runtime/client-solid.mjs"
     },
-    "./runtime/fetch": {
-      "types": "./dist/runtime/fetch.d.mts",
-      "import": "./dist/runtime/fetch.mjs",
-      "require": "./dist/runtime/fetch.mjs"
-    },
-    "./runtime/fetch-stream": {
-      "types": "./dist/runtime/fetch-stream.d.mts",
-      "import": "./dist/runtime/fetch-stream.mjs",
-      "require": "./dist/runtime/fetch-stream.mjs"
-    },
     "./sse": {
       "types": "./dist/runtime/sse.d.mts",
       "import": "./dist/runtime/sse.mjs",
@@ -143,6 +143,11 @@
       "import": "./dist/runtime/db.mjs",
       "require": "./dist/runtime/db.mjs"
     },
+    "./durable": {
+      "types": "./dist/runtime/durable.d.mts",
+      "import": "./dist/runtime/durable.mjs",
+      "require": "./dist/runtime/durable.mjs"
+    },
     "./seed": {
       "types": "./dist/runtime/seed.d.mts",
       "import": "./dist/runtime/seed.mjs",
@@ -173,6 +178,11 @@
       "import": "./dist/runtime/schema-pg.mjs",
       "require": "./dist/runtime/schema-pg.mjs"
     },
+    "./schema-mysql": {
+      "types": "./dist/runtime/schema-mysql.d.mts",
+      "import": "./dist/runtime/schema-mysql.mjs",
+      "require": "./dist/runtime/schema-mysql.mjs"
+    },
     "./kv": {
       "types": "./dist/runtime/kv.d.mts",
       "import": "./dist/runtime/kv.mjs",
@@ -203,6 +213,16 @@
       "import": "./dist/runtime/ai.mjs",
       "require": "./dist/runtime/ai.mjs"
     },
+    "./email": {
+      "types": "./dist/runtime/email.d.mts",
+      "import": "./dist/runtime/email.mjs",
+      "require": "./dist/runtime/email.mjs"
+    },
+    "./email/testing": {
+      "types": "./dist/runtime/email/testing.d.mts",
+      "import": "./dist/runtime/email/testing.mjs",
+      "require": "./dist/runtime/email/testing.mjs"
+    },
     "./sandbox": {
       "types": "./dist/runtime/sandbox.d.mts",
       "import": "./dist/runtime/sandbox.mjs",
@@ -213,26 +233,6 @@
       "import": "./dist/runtime/remote/index.mjs",
       "require": "./dist/runtime/remote/index.mjs"
     },
-    "./remote/binding-handler": {
-      "types": "./dist/runtime/remote/binding-handler.d.mts",
-      "import": "./dist/runtime/remote/binding-handler.mjs",
-      "require": "./dist/runtime/remote/binding-handler.mjs"
-    },
-    "./runtime/migration-handler": {
-      "types": "./dist/runtime/migration-handler.d.mts",
-      "import": "./dist/runtime/migration-handler.mjs",
-      "require": "./dist/runtime/migration-handler.mjs"
-    },
-    "./runtime/migration-handler-pg": {
-      "types": "./dist/runtime/migration-handler-pg.d.mts",
-      "import": "./dist/runtime/migration-handler-pg.mjs",
-      "require": "./dist/runtime/migration-handler-pg.mjs"
-    },
-    "./runtime/ws-server": {
-      "types": "./dist/runtime/ws-server.d.mts",
-      "import": "./dist/runtime/ws-server.mjs",
-      "require": "./dist/runtime/ws-server.mjs"
-    },
     "./pages": {
       "types": "./dist/pages/index.d.mts",
       "import": "./dist/pages/index.mjs",
@@ -248,11 +248,6 @@
       "import": "./dist/pages/head.mjs",
       "require": "./dist/pages/head.mjs"
     },
-    "./pages-head-client": {
-      "types": "./dist/pages/head-client.d.mts",
-      "import": "./dist/pages/head-client.mjs",
-      "require": "./dist/pages/head-client.mjs"
-    },
     "./pages-prefetch": {
       "types": "./dist/pages/prefetch.d.mts",
       "import": "./dist/pages/prefetch.mjs",
@@ -306,57 +301,73 @@
       "types": "./dist/runtime/db-pg.d.mts",
       "import": "./dist/runtime/db-pg.mjs",
       "require": "./dist/runtime/db-pg.mjs"
+    },
+    "./_db-mysql": {
+      "types": "./dist/runtime/db-mysql.d.mts",
+      "import": "./dist/runtime/db-mysql.mjs",
+      "require": "./dist/runtime/db-mysql.mjs"
     }
   },
   "dependencies": {
-    "@cloudflare/sandbox": "^0.12.3",
-    "@cloudflare/vite-plugin": "^1.43.0",
+    "@cloudflare/sandbox": "^0.12.9",
+    "@cloudflare/vite-plugin": "1.54.7",
     "@cloudflare/workers-types": "^4.20260702.1",
-    "@hono/oauth-providers": "^0.8.5",
-    "@napi-rs/keyring": "1.3.0",
-    "better-auth": "^1.6.23",
-    "better-sqlite3": "^12.11.1",
+    "@napi-rs/keyring": "2.0.0",
+    "@void/deploy-cloudflare": "0.20.1",
+    "@void/deploy-core": "0.20.1",
+    "@void/edge": "0.20.1",
+    "@void/isr": "0.20.1",
+    "@void/platform": "0.20.1",
+    "better-auth": "^1.7.3",
+    "better-sqlite3": "^13.0.3",
     "blake3-jit": "^1.1.0",
     "drizzle-arktype": "^0.1.3",
     "drizzle-kit": "^0.31.10",
     "drizzle-orm": "^0.45.2",
     "drizzle-valibot": "^0.4.2",
     "drizzle-zod": "^0.8.3",
-    "es-module-lexer": "^2.3.0",
-    "hono": "^4.12.27",
-    "ignore": "^7.0.5",
+    "email-validator": "^2.0.4",
+    "es-module-lexer": "^3.0.2",
+    "hono": "^4.13.7",
+    "ignore": "^7.0.9",
     "jsonc-parser": "3.3.1",
-    "pg": "8.22.0",
+    "minimatch": "^10.2.6",
+    "mysql2": "3.24.4",
+    "pg": "8.23.0",
+    "postal-mime": "^2.7.4",
     "proper-lockfile": "^4.1.2",
-    "wrangler": "^4.107.0"
+    "wrangler": "4.131.0"
   },
   "devDependencies": {
-    "@clack/prompts": "^1.7.0",
-    "@electric-sql/pglite": "0.5.4",
-    "@types/better-sqlite3": "^7.6.13",
-    "@types/node": "^26.1.0",
-    "@types/pg": "^8.20.0",
+    "@clack/core": "1.5.0",
+    "@clack/prompts": "^1.8.0",
+    "@electric-sql/pglite": "0.5.8",
+    "@types/better-sqlite3": "^9.6.0",
+    "@types/node": "^26.5.1",
+    "@types/pg": "^8.23.1",
     "@types/proper-lockfile": "^4.1.4",
-    "@typescript/native-preview": "7.0.0-dev.20260507.1",
-    "arktype": "^2.2.2",
+    "arktype": "^2.2.3",
+    "ci-info": "^4.4.0",
     "estree-walker": "^3.0.3",
-    "magic-string": "^0.30.21",
+    "fast-wrap-ansi": "^0.2.2",
+    "magic-string": "^1.3.1",
     "ofetch": "2.0.0-alpha.3",
     "pathslash": "^0.1.0",
     "pglite-server": "0.1.5",
     "picocolors": "^1.1.1",
     "tinyglobby": "^0.2.17",
-    "valibot": "^1.4.2",
-    "vite": "npm:@voidzero-dev/vite-plus-core@0.2.2",
-    "vite-plus": "^0.2.2",
-    "zod": "^4.4.3"
+    "typescript": "7.0.2",
+    "valibot": "^1.5.0",
+    "vite": "npm:@voidzero-dev/vite-plus-core@0.3.1",
+    "vite-plus": "0.3.1",
+    "zod": "^4.6.1"
   },
   "peerDependencies": {
+    "@void/md": "0.20.1",
     "arktype": ">=2.0.0",
     "valibot": ">=1.0.0-beta.7",
     "vite": "^8.0.0",
-    "zod": "^3.25.0 || ^4.0.0",
-    "@void/md": "0.10.13"
+    "zod": "^3.25.0 || ^4.0.0"
   },
   "peerDependenciesMeta": {
     "@void/md": {
@@ -372,9 +383,12 @@
       "optional": true
     }
   },
+  "engines": {
+    "node": ">=24.21.0"
+  },
   "scripts": {
     "build": "node scripts/sync-skill-docs.mjs && vp pack",
     "dev": "vp pack --watch",
-    "typecheck": "tsgo --noEmit"
+    "typecheck": "tsc --noEmit --rootDir ../.."
   }
 }

package/schema.json

@@ -144,6 +144,10 @@
       "type": "object",
       "description": "Routing configuration — headers, redirects, rewrites, fallbacks, revalidation, prerendering.",
       "properties": {
+        "isr": {
+          "type": "boolean",
+          "description": "Enable inferred ISR caching. Set false to disable ISR and edge prerendering, including per-page prerender and revalidate policies. Does not disable output: static build-time prerendering."
+        },
         "notFound": {
           "type": "string",
           "enum": ["single-page-application", "404-page", "none"],
@@ -257,8 +261,12 @@
               "description": "Enable R2 bucket binding. `true` uses default name \"STORAGE\", a string sets a custom binding name."
             },
             "ai": {
+              "oneOf": [{ "type": "boolean" }, { "type": "string" }],
+              "description": "Enable Workers AI binding. `true` uses default name \"AI\", a string sets a custom binding name."
+            },
+            "email": {
               "type": "boolean",
-              "description": "Enable Workers AI binding"
+              "description": "Enable email support (used by void/email)."
             }
           },
           "additionalProperties": false
@@ -379,8 +387,8 @@
     },
     "database": {
       "type": "string",
-      "enum": ["pg"],
-      "description": "Database backend. Omit for D1 (SQLite, default). Set to \"pg\" for PostgreSQL via Hyperdrive."
+      "enum": ["pg", "mysql"],
+      "description": "Database backend. Omit for D1 (SQLite, default). Set to \"pg\" for PostgreSQL or \"mysql\" for MySQL via Hyperdrive."
     },
     "ai": {
       "type": "object",
@@ -392,6 +400,17 @@
         }
       },
       "additionalProperties": false
+    },
+    "email": {
+      "type": "object",
+      "description": "Email configuration for void/email.",
+      "properties": {
+        "from": {
+          "type": "string",
+          "description": "Default sender for sendEmail(): one address, optionally with a display name (\"Acme <noreply@mail.acme.com>\"). On `void deploy --backend cloudflare` its host is the domain Void sets Email Routing and Email Sending up on."
+        }
+      },
+      "additionalProperties": false
     }
   },
   "additionalProperties": false

package/skills/void/SKILL.md

@@ -11,21 +11,74 @@ Docs in this skill are bundled from `docs/` during `void` package build and live
 
 - `skills/void/docs/**/*.md`
 
+`void init --agents` always writes brief instructions to `AGENTS.md`, pointing to `node_modules/void/skills/void/docs/`. It preserves content outside its versioned block, leaves other instruction files untouched, and links skills for detected agents without asking which agent is in use.
+
+`void init` offers Git initialization with `--git` / `--no-git` overrides and suggests an optional initial commit command. It preserves existing repositories and never commits automatically; see `docs/reference/cli.md` for CI and workspace behavior.
+
 ## Command Naming
 
-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()`. `void init` can also handle auth and project linking interactively.
+For a new platform installation, prefer an app domain at the zone apex. Nested
+app domains need an active wildcard edge certificate and SSL-and-Certificates
+read permission; `void platform install --plan` verifies coverage. Use the
+self-hosted platform guide for certificate setup rather than enabling a paid
+product without an explicit request.
+
+For first-time platform setup, follow `docs/guide/self-hosted-platform.md` in order and introduce credentials when the user reaches that step. Recommend a domain; offer explicit `void platform install --workers-dev` for testing before one is ready. PostgreSQL, GitHub OAuth registration, runtime/R2 credentials, and saved signing/encryption keys are still required. Domain-free installation skips zone/DNS/certificate operations and can use browser login. `void platform domain set <domain>` later performs resumable DNS/HTTPS setup while preserving existing test URLs and the API origin. The command checks the deployed runtime token's cache-purge permission for the new zone; it does not ask users to retrieve that token. Prefer interactive prompts for secrets and keep CI variables in the CI workflow. Void creates the platform infrastructure and database tables.
+
+For an existing Cloudflare site, run `void deploy` with its root `wrangler.jsonc` or `wrangler.json`. An unlinked project gets a prompt to link and deploy using the existing Worker and resources. Accepting verifies and saves the destination, then continues deployment. Keep new application resources, migrations, auth setup, and secret changes separate from this first handoff; ISR has its own explicit cache choice. The active Worker Version must be the latest upload so inherited secrets have an unambiguous source. Failed builds retain the link for retry. Read `docs/integrations/cloudflare.md` for the supported configuration and rollback behavior.
+
+When linking reports missing inferred resources, check the listed bindings and inference reasons against the existing Worker and `void.json`; preserve `.void/cloudflare-link.json` for retries. For prerendered/revalidated sites without a cache, migration saves an explicit `routing.isr` choice in `void.json`. True provisions the cache during this deployment; false keeps ISR disabled on retries and later deployments until changed. Keep page-level exports with either choice. CI must configure the boolean before resuming a migration with no saved choice. An application KV binding explicitly named `ISR_CACHE` is still required. Existing D1 bindings without checked-in migrations retain their local migration settings during handoff.
+
+For Cloudflare upload failures, use the detailed error message printed by the CLI and saved in the deploy log. A numeric error code alone may not identify the cause.
+
+Platform administration uses `void platform auth login` and the nested
+`user`, `project`, `deployment`, `build`, `signup`, `invitation`, `system`, and
+hosted-only `worker` groups. Open the operator section of `docs/reference/cli.md`
+before running these commands. Use `--json` for structured reads and `--plan`
+to inspect mutations; approved noninteractive mutations require `--yes`.
+The last active administrator cannot be deleted or suspended. If an allowed
+administrator removal reports partial cleanup, access remains revoked; use a
+remaining administrator to inspect the result and retry.
+Operator credentials are separate from application deployment credentials and
+ignore repository platform selections. `VOID_OPERATOR_TOKEN` requires an
+explicit `VOID_API_URL` or `--connection`; credentials must never be written to
+project files. `signup open` allows public signup and `signup restrict` enforces
+the allowlist. Inspect `system events` and the target object after an ambiguous
+mutation failure before retrying.
+
+Use `void connect` for deployment onboarding: no arguments offers Cloudflare or a Void platform, `--platform cloudflare` signs in and selects an account, and a platform URL verifies discovery and signs in with a supported provider. It preserves existing project links when connecting elsewhere. `--no-login` saves only verified Void connection metadata; authenticated headless connection requires a valid origin-scoped keychain session or `VOID_TOKEN` with matching `VOID_API_URL`. Platform installation and administration use `void platform`.
+
+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.
+
+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.
 
+Non-interactive self-hosted platform install, upgrade, repair, disable, enable, and uninstall commands require `--yes`; `--plan` is read-only and needs no acknowledgement.
+
+Platform install plans show actual resource names, the GitHub callback, and credential links without opening credential pages or saving a draft; Cloudflare browser login still opens if needed. New platforms use `void-<name>-<role>` names without random suffixes. Conflicts stop installation; existing installations retain recorded names. Approved interactive installs open the runtime-token, GitHub OAuth, and R2 pages only when those credentials are missing, with fallback instructions. Local credential drafts preserve the callback across retries and encrypt partial inputs. Interactive installs list unfinished installs, including interrupted provisioning, or offer "Start a new platform install". Entering an unfinished name asks to resume it; declining returns to name entry. Completed platforms are excluded, and new installs never inherit or delete old credentials or resources. Use `--resume --name <id>` to continue directly or in CI. Do not generate replacement signing keys or create another installation to recover a cancelled prompt.
+
+Cloudflare browser login does not grant AI Gateway access. A platform installation preview may mark that resource `inspect`; apply must verify it with the existing runtime-token input (Account → AI Gateway → Edit) before any provisioning. Never treat a permission failure as an empty resource inventory or skip ownership verification. The runtime token is used only for AI Gateway provider calls; other operations retain the operator credential.
+
+Use `--runtime <directory>` on platform install, upgrade, repair, enable, or rollback when deploying a locally built `@void/platform` runtime. The directory must contain the generated integrity manifest, Worker artifacts, and migration tree. Build it with `vp run --filter @void/platform build`; Git source revisions are detected automatically, with `-dirty` for uncommitted changes. `VOID_PLATFORM_SOURCE_REVISION` is an optional override. Do not treat this as a safety bypass: custom and packaged runtimes follow the same verification and rollback path.
+
+For self-hosted platform installation, require a dedicated empty PostgreSQL database. Interactive lifecycle commands use Cloudflare browser OAuth with keyring storage. Wrangler OAuth has Zone Read, so a plan that creates a zone or DNS record requires a scoped `CLOUDFLARE_API_TOKEN` with Account → Zone → Edit and/or Zone → DNS → Edit; finish Workers onboarding and choose a workers.dev subdomain for a fresh Cloudflare account. The installed platform uses a separate `VOID_PLATFORM_RUNTIME_CLOUDFLARE_API_TOKEN`. Its core permissions include Hyperdrive: Write at account scope and Cache Purge: Purge on the application zone; SSL and Certificates: Edit is needed only when a custom runtime enables custom project domains. The installer preflights account and Hyperdrive access and safely verifies Cache Purge for an existing zone with a unique nonexistent URL. Fresh installs require unique per-installation values from the operator's secret manager: `VOID_PLATFORM_JWT_SECRET` with at least 32 random bytes and `VOID_PLATFORM_PROJECT_SECRET_KEY` as canonical base64 for 32 random bytes. Never let a local checkpoint or ephemeral CI runner be their only custodian. The installer transactionally claims the database for one installation, pins that URL after a successful claim, never removes the claim during uninstall, and uses it for a cross-host lifecycle lock plus a secret-free authoritative lifecycle manifest. Local recovery checkpoints are AES-256-GCM encrypted with an OS-keychain key; never place platform secrets in plaintext files. After discovery on a new machine, provide `VOID_PLATFORM_DATABASE_URL`. Normal upgrades preserve deployed Worker secrets; restoring the original runtime, GitHub, R2, JWT, and project-encryption values is required only when recreating a missing Worker. Managed platform Sandbox is paused for removal: preview `void platform system sandbox-drain --plan`, follow each returned `nextCursor` with `--cursor '<value>'` to inspect bounded pages, then apply with `--yes` and rerun until the DB-backed response reports `complete: true`; never delete an unverified app by name. The installer trusts only DB-backed sandbox-drain probe protocol v1. Before it accepts an empty inventory, the database admission barrier makes older deployment inserts finish and become visible or rejects them after the protocol floor is armed. Lifecycle redeploys preserve unmanaged Worker routes and custom domains in both the new trigger state and rollback snapshot. They stop before migrations or uploads when live Hyperdrive origin metadata differs from the pinned database. Platform upgrade SQL is forward-only: packaged hashes and the live Drizzle prefix must match, pending migrations require an exact source-version/schema rollback edge, and the old version remains authoritative until target health succeeds. Use `void platform rollback --runtime <earlier>` only when the installed runtime declares the exact earlier version/schema compatible; pass `--from-runtime` for the exact current custom artifact. Rollback preserves the forward database schema and cannot lower a database-required safety protocol. Safe uninstall retains Worker routes, custom domains, and R2 for explicit manual cleanup because Cloudflare cannot condition their deletion on an immutable generation.
+
+For self-hosted recovery, `VOID_PLATFORM_PROJECT_SECRET_KEY` restores an original `v1` project-secret keyring. After rotation, restore every retained version with `VOID_PLATFORM_PROJECT_SECRET_KEYS_JSON` and its active entry with `VOID_PLATFORM_PROJECT_SECRET_ACTIVE_KEY_VERSION`. These inputs restore a missing API Worker and never replace the live keyring of an existing Worker. Inject them from a secret manager without logging them or writing plaintext files.
+
+For Cloudflare user switching, `void cloudflare login` always opens a fresh browser sign-in. `void cloudflare status` distinguishes the authenticated user and credential method from the project's pinned deployment account. Login never retargets a project. Remove API-credential environment overrides from the current shell before browser sign-in, without printing their values; automatic deployment checks continue to reuse valid sessions.
+
 ## No-Args Behavior
 
+Published self-hosted platform routes and custom domains are observed and recorded as retained attachments. Lifecycle commands gate traffic through installation-owned routing storage but never delete those attachments unattended.
+
 If invoked without a concrete task, do a brief app status check and report:
 
 1. App type (`void`, `framework`, `spa`, `static`) using `docs/app-types.md` criteria.
 2. Backend feature usage (`routes/`, `pages/`, `middleware/`, `migrations/`, `crons/`, `queues/`, SSR entries).
 3. Runtime signals (`void/db`, `void/kv`, `void/storage`, queue usage).
 4. Auth signals (`void/auth`, `auth` client imports, OAuth env vars).
-5. Project linkage (`.void/project.json`) and config readiness (`void.json`, tsconfig extends).
+5. Deployment platform and optional Void project linkage (`.void/project.json`), plus config readiness (`void.json`, Cloudflare `account_id`, tsconfig extends).
 6. Optional health checks (`void auth whoami`, `void db status` when relevant).
 
 Then ask what to do next.
@@ -49,6 +102,9 @@ Then ask what to do next.
 | Rewrites, redirects, fallbacks             | `docs/guide/edge/rewrites.md`, `docs/guide/edge/redirects.md`, `docs/reference/config.md` |
 | Static site generation                     | `docs/guide/ssg.md`                                                                       |
 | Deployment and CI                          | `docs/guide/deployment.md`, `docs/reference/cli.md`                                       |
+| Install or maintain a company platform     | `docs/guide/self-hosted-platform.md`, `docs/reference/cli.md`                             |
+| Develop or deploy a platform fork          | `docs/guide/platform-development.md`, `docs/guide/self-hosted-platform.md`                |
+| Platform administration                    | `docs/guide/platform-administration.md`, `docs/reference/cli.md`                          |
 | Self-host deploy to own Cloudflare account | `docs/integrations/cloudflare.md`, `docs/reference/cli.md`                                |
 | Project status, deployment history         | `docs/reference/cli.md`                                                                   |
 | Cache purging                              | `docs/reference/cli.md`                                                                   |
@@ -73,4 +129,5 @@ Then ask what to do next.
 - Never guess or infer `void` CLI command names or flags. Always consult `docs/reference/cli.md` for the exact command before running it.
 - For multi-topic tasks, combine only the needed doc files.
 - If docs and memory differ, follow docs.
+- For Void-managed auth, `void db generate` automatically includes the production Better Auth schema in the generated migration, including configured model/field renames and plugin tables. Keep those migrations under `db/migrations/`; do not duplicate generated auth tables in the application Drizzle schema.
 - **Env vars:** When the project has `env.ts`, the canonical access pattern is `import { env } from "void/env"`. Declare every env key in `env.ts` via `defineEnv({...})` so values are typed and validated. Do not introduce ad-hoc `process.env.X` or untyped `c.env.X` access in new code — add the key to `env.ts` first.

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

@@ -4,7 +4,7 @@ outline: deep
 
 # AI
 
-Void provides a typed AI client powered by Cloudflare's [AI Gateway](https://developers.cloudflare.com/ai-gateway/). Import `ai` from `void/ai` and run inference directly from your route handlers. Usage is metered through Void.
+Void provides a typed AI client for Workers AI and Cloudflare's [AI Gateway](https://developers.cloudflare.com/ai-gateway/). Import `ai` from `void/ai` and run inference directly from your route handlers. Direct deployments use your Cloudflare account; a team platform routes requests through its installation's proxy and usage controls.
 
 ```ts
 import { ai } from 'void/ai';
@@ -71,21 +71,34 @@ const result = await ai.toMarkdown([{ name: 'document.pdf', blob: pdfBytes }]);
 
 ## Local Development
 
-AI requires Void credentials for local development. Run `void auth login` and `void project link` (or follow the interactive setup during `vite dev`) to connect your project.
+For a direct Cloudflare project, connect your account and start development:
 
-Once linked, credentials are injected automatically as worker bindings. You do not need to configure them by hand. All inference traffic goes through the Void AI proxy over HTTPS, so usage is tracked and metered the same way it is in production.
+```sh
+void connect --platform cloudflare
+npm run dev
+```
 
-## Usage Limits
+When the app imports `void/ai`, Void enables a remote Workers AI binding during
+development and preview. Requests use your Cloudflare account and its allowance;
+Workers AI has no local simulator. The session uses the same keychain-backed
+Cloudflare login as the CLI, or `CLOUDFLARE_API_TOKEN` in an automated environment.
 
-Workers AI usage is metered in [**neurons**](https://developers.cloudflare.com/workers-ai/platform/pricing/), which is Cloudflare's unit for inference cost. Usage resets at the start of each billing cycle.
+For a team platform, use `void connect <platform-url>` and link your project.
+Development requests use that platform's HTTPS proxy and usage controls.
+Credentials are injected into server bindings automatically.
+
+## Usage Limits
 
-| Plan | Included      | At limit                           |
-| ---- | ------------- | ---------------------------------- |
-| Free | 100,000/month | Blocked until billing cycle resets |
-| Solo | 300,000/month | Overage billed                     |
-| Pro  | 500,000/month | Overage billed                     |
+Workers AI usage is measured in [neurons](https://developers.cloudflare.com/workers-ai/platform/pricing/).
+On a direct deployment, usage belongs to your Cloudflare account. Provider-native
+requests also use your provider credentials and their billing terms.
 
-On the **free tier**, AI requests return a `429` error once the limit is reached. On **paid tiers**, usage beyond the included allowance is tracked as overage on your monthly bill.
+A team platform tracks usage in its own account and can apply per-user limits.
+Fresh self-hosted installations assign the `custom` profile, which has no
+platform-imposed AI allowance. Administrators can select a quota profile through
+[Platform Administration](./platform-administration.md). These profiles do not
+subscribe users to a commercial plan or charge them automatically; the operator
+remains responsible for its infrastructure and provider accounts.
 
 ## Cloudflare Gateway Models
 
@@ -126,11 +139,16 @@ const result = await ai.run(
 );
 ```
 
-Void always injects the `void` gateway ID and project metadata for metering.
+Managed requests use the installation's gateway and project metadata. Direct
+requests use your Workers AI binding; provider-native requests require your own
+`ai.gateway` configuration.
 
 ## Provider-Native Requests
 
-Use `ai.provider(provider).fetch(path, init)` when you want to call a provider-native API with your own provider key. The request still routes through Cloudflare AI Gateway and Void metering, but the request shape is the provider's native HTTP API.
+Use `ai.provider(provider).fetch(path, init)` for a provider-native API with your
+own provider key. The request goes through the configured Cloudflare AI Gateway
+and retains the provider's native HTTP shape. On a team platform, it also passes
+through that installation's proxy.
 
 ### OpenAI
 
@@ -266,7 +284,7 @@ For production, add your API key as a project secret:
 void secret put OPENAI_API_KEY=sk-...
 ```
 
-For local development, add it to `.env.local` in your project root:
+For local development, add it to `.env` in your project root:
 
 ```
 OPENAI_API_KEY=sk-...

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

@@ -14,7 +14,7 @@ The type is auto-detected from your project structure, or you can set it explici
 
 ## Void Apps
 
-A Vite app powered by Void's framework layer. In this mode, **Void is both the framework and the platform**. It is opinionated in the backend and deployment story, while still staying frontend-framework-agnostic. You can use it with React, Vue, Svelte, Solid, or any frontend that works with Vite.
+In a Void app, Void handles server routing and deployment. Use React, Vue, Svelte, or Solid for server-rendered pages, or build a frontend with any library that works with Vite.
 
 All Void features that involve backend logic are available in this mode, including [server routing](./server-routing.md), [pages mode](./pages-routing/overview.md), [authentication](./auth.md), [typed fetch](./typed-fetch.md), [cron jobs](./jobs.md), and [queues](./queues.md).
 
@@ -26,7 +26,7 @@ Your worker handles API routes, page rendering, and (optionally) [custom SSR](./
 
 Void apps can also use [`output: 'static'`](./ssg.md) to pre-render all pages at build time. That gives you a fully static site that can be deployed anywhere, with no Cloudflare Worker required.
 
-**Deploy:** `void deploy` builds via Vite, infers bindings, provisions D1/KV/R2 resources, applies migrations, uploads assets and worker, and makes the site live at `{slug}.void.app`. See [Deployment](./deployment.md) for details.
+**Deploy:** `void deploy` builds the app, provisions resources, applies migrations, and uploads it to your saved Cloudflare or Void target. See [Deployment](./deployment.md) for setup.
 
 **Detected when any of these exist:**
 
@@ -52,7 +52,7 @@ Void supports deploying Vite-based meta-framework apps with `void deploy`. The f
 
 Add `voidPlugin()` to the framework's Vite config to get binding inference, typed DB generation, migration management, cron jobs, queues, and caching. Void-managed auth is not supported in framework mode; use Better Auth's official integration for your framework. See the [Meta Frameworks Integration](../integrations/frameworks/overview.md) for the full feature matrix, deploy pipeline, and per-framework setup guides.
 
-**Deploy:** `void deploy` runs the framework build, packages the output, and deploys to Void. The framework still owns routing and SSR, while Void handles resource provisioning, migrations, and edge hosting.
+**Deploy:** `void deploy` runs your framework's build, provisions resources, applies migrations, and deploys to the selected target. Your framework continues to handle routing and rendering.
 
 **Detected when** any of the above packages is in your dependencies.
 
@@ -75,9 +75,9 @@ At the edge, the resolution order is:
 
 ## Adding a backend to a static site
 
-A static site generator plus a few API routes is a Void app, not a static site. Auto-detection sees the SSG dependency first (priority 2 below), so if you leave `inference.appType` unset, `void deploy` refuses rather than deploying the site and silently dropping `routes/`. Tell it which you meant.
+If you add API routes to a static site generator, tell Void whether to deploy the backend too. Auto-detection sees both the SSG dependency and backend files, and stops until you set `inference.appType`.
 
-To deploy the site **and** the backend, run both builds from one command and let Void's build fold the generated site into its client output:
+To deploy both, set `appType` to `"void"` and build the static site before the Void app:
 
 ```json
 // void.json
@@ -109,7 +109,7 @@ Because the worker now owns unmatched requests, add [`routing.notFound`](../refe
 { "routing": { "notFound": "404-page" } }
 ```
 
-To deploy the static output only and **not** the backend, say so explicitly:
+To deploy only the static output, set:
 
 ```json
 { "inference": { "appType": "static" } }