void 0.21.0 → 0.21.1

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

@@ -4,11 +4,11 @@ outline: deep
 
 # Cloudflare
 
-Void runs on Cloudflare Workers. This page covers how bindings work, how the plugin merges Cloudflare configuration, and how to deploy directly to your own Cloudflare account.
+Void runs on Cloudflare Workers. Use this guide to access bindings, configure your Worker, and deploy to your own account.
 
 ## Bindings
 
-Void automatically infers and provisions Cloudflare bindings (D1, KV, R2, AI, Queues) by scanning your source files. There are two ways to access them at runtime depending on your setup.
+Void detects supported resource use in your source and provisions the corresponding bindings. How you access them depends on your framework.
 
 ### Via Hono context (`c.env`)
 
@@ -132,43 +132,36 @@ For environment variables, declare the schema in `env.ts` and put local values i
 API_URL=https://api.example.com
 ```
 
-Binding arrays such as `d1_databases`, `kv_namespaces`, and `r2_buckets` belong in the `cloudflare` field. Void adds inferred bindings that are missing by name and preserves custom bindings with real resource IDs. See [Cloudflare config merging](#cloudflare-config-merging) for details.
+Binding arrays such as `d1_databases`, `kv_namespaces`, and `r2_buckets` belong in the `cloudflare` field. Void adds inferred bindings that are missing by name and preserves custom bindings with real resource IDs. See [Cloudflare Configuration](#cloudflare-configuration) for details.
 
 For non-secret plain-text defaults, you can also set `worker.vars` in `void.config.ts`. Local `.env` values override `worker.vars` during development. Production builds reject any `worker.vars` name that is declared as a server key in `env.ts`; store those values remotely with `void secret put` instead.
 
-## Cloudflare config merging
+## Cloudflare Configuration
 
-Void reads `void.config.ts`, combines its `cloudflare` settings with provisioned values in `void.lock.json`, and generates the Cloudflare config needed by the build and deploy tools. Root `wrangler.jsonc` and `wrangler.json` files from existing apps are migrated automatically by `void init` or `void deploy`. Bindings are inferred from source code and use local placeholder IDs for development.
+Set Worker options in `void.config.ts`. Void combines its `cloudflare` settings with resource IDs in `void.lock.json` for development and deployment. `void init` and `void deploy` migrate root `wrangler.jsonc` or `wrangler.json` files from existing apps.
 
-Edit `cloudflare` in `void.config.ts` for custom Worker settings. Commit `void.lock.json` when Void records resource IDs or Durable Object migration history.
+Commit `void.lock.json` when Void records resource IDs or Durable Object migration history.
 
 ### Void-only mode and Vite-based frameworks
 
-In Void's default mode and frameworks where Void controls the Cloudflare integration (TanStack Start, React Router), Void manages `@cloudflare/vite-plugin` directly. It merges inferred bindings with the generated Cloudflare config:
+In native Void apps, TanStack Start, and React Router, Void manages the Cloudflare Vite plugin. It merges inferred bindings with your `cloudflare` settings:
 
-1. The plugin reads the generated config containing your `cloudflare` settings and Void's recorded resource values.
-2. Void checks each inferred binding **by name** (e.g. `"DB"`, `"KV"`, `"STORAGE"`). If a binding with that name already exists in your config, it is left untouched.
-3. Only bindings that are **missing** from your config are added with local placeholder IDs (e.g. `database_id: "local"`).
-4. The merged config is used for both `vite dev` (Miniflare) and `vite build` (output `wrangler.json` in `dist/`).
+- An existing binding with the same name stays unchanged.
+- Missing inferred bindings get local placeholder IDs for development. Deploy replaces them with provisioned IDs.
+- Other `cloudflare` settings, such as routes, services, variables, and compatibility settings, pass through.
 
-All other `cloudflare` fields -- `name`, `routes`, `services`, `vars`, `env`, `compatibility_date`, etc. -- flow through to the build output.
-
-Fields that Void always sets (`main`, `triggers`, `assets`) don't need to be in your Cloudflare config -- they're added programmatically based on your project structure.
-
-In this mode, normal inferred bindings are merged in memory. Typed state modules in `durable-objects/` are the exception: Void records their bindings and append-only `new_sqlite_classes` history in `void.lock.json`. Commit the lock.
+Void sets `main`, `triggers`, and `assets` from your project structure. It also records typed Durable Object bindings and migration history from `durable-objects/` in `void.lock.json`.
 
 ### Adapter-based frameworks (SvelteKit, Nuxt, Astro)
 
-When using SvelteKit, Nuxt, or Astro, the framework's own Cloudflare adapter owns the worker build and dev server. Void does **not** provide `@cloudflare/vite-plugin` in that setup. It only contributes DB type codegen, migration management, and binding sync.
+SvelteKit, Nuxt, and Astro build Workers through their own adapters. Void provides database types, migrations, and binding sync without replacing those adapters.
 
-Because Void does not control the Cloudflare plugin in this mode, it syncs inferred bindings to the generated Cloudflare config on dev startup:
+At dev startup, Void updates the framework's generated Cloudflare config:
 
-- Only adds bindings that are **missing** by name -- existing bindings are never modified or removed.
-- If `worker.compatibility_date` is set in `void.config.ts`, syncs that date into the Cloudflare config so the framework adapter reads the same value.
-- Also ensures the `nodejs_als` compatibility flag is present.
-- The framework adapter reads the generated config through its configured path.
+- It adds missing bindings by name without changing existing ones.
+- It copies `worker.compatibility_date`, when set, and adds the `nodejs_als` compatibility flag.
 
-The framework adapter reads the generated config. Void adds bindings as you import resources, and `void deploy --platform cloudflare` replaces local placeholder IDs when it provisions production resources.
+`void deploy --platform cloudflare` provisions production resources for inferred bindings.
 
 ### Merge precedence
 

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

@@ -78,7 +78,9 @@ Use `void --help` for the command list. For a specific command, try `void deploy
 
 ### `void migrate`
 
-`void migrate` converts `void.json` and root `wrangler.jsonc` or `wrangler.json` into a typed `void.config.ts`. It also recognizes a single root `wrangler*.json(c)` file explicitly referenced by a supported framework adapter. Void backs up the originals under `.void/config-migration/`, keeps Cloudflare resource state in `void.lock.json`, and updates supported framework adapters to use its generated Cloudflare config. `.void-wrangler.jsonc` is a generated Cloudflare tooling file; migration adds it to `.gitignore`. `void init` and `void deploy` run this migration automatically when they find legacy files. Before Cloudflare deployment, the project's installed `void` package must match the CLI version. Review and commit the new config, lock, and `.gitignore`. If multiple Cloudflare config files exist or existing files disagree, resolve them before retrying.
+`void migrate` converts legacy `void.json` and root `wrangler.jsonc` or `wrangler.json` files into `void.config.ts`. It also accepts one root `wrangler*.json(c)` file referenced by a supported framework adapter. Void saves backups in `.void/config-migration/`, records resource IDs in `void.lock.json`, and updates supported adapters to use its generated Cloudflare config.
+
+`.void-wrangler.jsonc` is generated for Cloudflare tooling and belongs in `.gitignore`; migration adds the entry. Review and commit `void.config.ts`, `void.lock.json`, and `.gitignore`. `void init` and `void deploy` migrate legacy files automatically. If the project has conflicting or multiple Cloudflare configs, resolve them first. The project's installed `void` package must match the CLI version before Cloudflare deployment.
 
 ### `void init`
 
@@ -775,9 +777,11 @@ The installed platform needs a separate runtime token to provision resources for
 
 To enable email during install or upgrade, set both `VOID_EMAIL_SENDER_DOMAIN` and `VOID_EMAIL_SHARED_ZONE_ID`. Void records the pair for later upgrades; supplying only one is an error.
 
-`--plan` prints the actual resource names, selected login methods, login callback, and direct setup links without opening credential pages or saving a draft; Cloudflare browser login still opens if needed. New platform resources use `void-<name>-<role>` names without random suffixes. Existing installations keep their recorded names, and unowned name conflicts stop installation without overwriting resources. After you confirm an interactive install, Void opens each missing credential's setup page and shows a short permission/checklist fallback. The runtime-token link preselects all required account permissions, including Workers Tail, Hyperdrive, and AI Gateway when needed; domain installations must also select the indicated zone. Supplied credentials skip browser opening. Setup drafts pin Worker names and the login callback and save partial credentials encrypted locally. Interactive installs list unfinished installations, including interrupted provisioning, or offer a new install. Entering an existing unfinished name asks to resume it; declining returns to name entry. Starting new leaves previous setup, credentials, and resources untouched. Completed platforms are not offered for resumption. `--resume` skips the choice and is required for non-interactive recovery.
+`--plan` shows resource names, login methods, the callback URL, and setup links without opening credential pages or saving a draft. Cloudflare browser login can still open if needed. It prints an install command with the resolved name, account, domain, and any supplied authentication file or runtime. Run that command later to recalculate and confirm the plan. If you chose login methods interactively, choose them again during installation. For unfinished installations, the plan prints the saved `--resume` command instead.
+
+New resources use `void-<name>-<role>` names. Existing installations keep their recorded names; an unowned name conflict stops installation. After confirmation, Void opens setup pages for missing credentials. The runtime-token link preselects required account permissions, including Workers Tail, Hyperdrive, and AI Gateway when needed; select the indicated zone for domain installs. Supplied credentials skip those pages.
 
-At the end of a plan, Void prints a command to install with the resolved name, account, domain, and any supplied authentication file or runtime. Running that command later recalculates the plan; interactive use asks for confirmation and missing credentials. If you chose login methods interactively, choose them again during installation. A plan for an unfinished installation instead prints its checkpointed `--resume` command.
+Setup drafts save Worker names, the login callback, and partial credentials encrypted locally. Interactive installs offer unfinished installations, including interrupted provisioning, or a new one. Choosing an unfinished name asks to resume it; choosing a new one leaves earlier setup, credentials, and resources untouched. Use `--resume` for non-interactive recovery. Completed platforms cannot be resumed.
 
 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.
 
@@ -959,19 +963,21 @@ Email setup needs a browser session from `void cloudflare login`, which carries
 
 Sandbox apps need Docker, [Workers Paid](https://dash.cloudflare.com/?to=/:account/workers/plans), and Containers access. API tokens need Account / Containers: Edit and Account / Cloudchamber: Edit. Void checks access before provisioning or building; apps without Sandbox skip that check.
 
-Void provisions inferred resources, builds and validates the app, applies migrations, validates remote secrets, and checks the uploaded Worker Version before sending it traffic. After activation it synchronizes routes, custom domains, cron triggers, queue consumers, and the Email Routing rules derived from `addresses`. Static, hybrid, and SSR output from supported frameworks is also supported. A brand-new Worker may need one ordinary deployment before the Versions API can be used.
+Void provisions inferred resources, builds and validates the app, applies migrations, checks required secrets, and verifies the uploaded Worker before sending it traffic. It then updates routes and triggers. Supported frameworks can deploy static, hybrid, and SSR output. A new Worker may need one initial deployment before versioned deployment is available.
+
+During deployment, Void shows the current phase and an animated spinner in an interactive terminal. CI and redirected output receive plain progress lines. Cloudflare CLI setup notices and successful command output are hidden; Void reports deployment errors directly.
 
 If Cloudflare Access protects readiness URLs, supply an allowed `CF_ACCESS_CLIENT_ID` and `CF_ACCESS_CLIENT_SECRET` pair, or a short-lived local `CF_ACCESS_TOKEN`. These credentials are used only for matching HTTPS readiness requests. Versions without accessible previews can be checked at 0% traffic through the stable hostname.
 
 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.
 
-Provisioning reuses known resource IDs and records newly resolved IDs in `void.lock.json`. Commit that file for other machines and CI. Run the first deploy from one machine at a time because provisioning locks are local. The old `--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. The `--provision` flag is accepted but no longer needed.
 
-`.env` is local-only and isn't emitted into Worker vars. Store every schema-declared server key with `void secret put <NAME>`; Void emits required names through `secrets.required` and blocks plaintext server vars. On a new Worker, set required secrets before retrying if the initial remote check reports them missing. Custom D1 layouts are accepted only when Cloudflare's exact file set, bytes, and numeric order match the migrations Void validated. Direct deploy and operational commands use the top-level Cloudflare settings and reject named environments and alternate config-path overrides.
+`.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.
 
 Existing remote secrets are preserved. Void also preserves or creates `BETTER_AUTH_SECRET` for auth apps.
 
-**Email.** When the app uses email (`sendEmail()` or `email/` handlers) and `void.config.ts` has `email.from`, the deploy reads the state of that address's zone before the build — session scopes, zone, MX records, Email Routing, subaddressing, routing rules, Email Sending, and what Void's Cloudflare config holds — prints a checklist of what it would change in your account, and asks once (default Yes). On Yes it enables what is missing, writes `send_email: [{ "name": "SEND_EMAIL" }]`, the `__VOID_EMAIL_FROM` var and the `addresses` array into Void's Cloudflare config, and lets Cloudflare tooling create the routing rules when the activated version's triggers are synchronized; the deploy ends with the address map. A deploy with nothing left to set up asks nothing. Without `email.from` the deploy prints `set email.from in void.config.ts` and continues without email. Non-interactive runs (CI, or stdin/stdout not a terminal) never prompt: they print the checklist plus `Run void email setup --platform cloudflare once locally, commit void.lock.json, then redeploy` and deploy without email (or with the setup Void's Cloudflare config already carries, when the binding is committed) — unless `--require-email` is passed, which fails instead. If setup has committed the exact subdomain `addresses` plan but the deploy's resolver still sees no MX records, Void preserves the plan and stops before build or upload until DNS can be verified. A deploy whose account rows all read ready reconciles the two config rows — `addresses` against the current derivation and `vars.__VOID_EMAIL_FROM` against `email.from` — with a plain file write and no prompt. See [Your own Cloudflare account](../guide/email.md#your-own-cloudflare-account) for the whole flow, including the subdomain-vs-apex rule and what stays manual.
+**Email.** If the app uses `sendEmail()` or `email/` handlers, set `email.from` in `void.config.ts`. Void shows the Cloudflare account changes and asks before applying them. Later deploys skip the prompt once setup is ready. Without `email.from`, deploy continues without email. For CI, run `void email setup --platform cloudflare` locally and commit `void.lock.json`; pass `--require-email` to fail when email is unavailable. DNS propagation may delay a deploy after setup. See [Email on your own Cloudflare account](../guide/email.md#your-own-cloudflare-account) for setup and recovery.
 
 See the [Cloudflare guide](../integrations/cloudflare.md#deploy-to-your-own-cloudflare-account) for the complete deployment sequence, first-deploy exceptions, secret precedence, and recovery behavior.
 

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

@@ -6,9 +6,9 @@ outline: deep
 
 ## Config File Format
 
-Use this page as the exact reference for `void.config.ts`. If you are still learning how the pieces fit together, start in the guide first and come back here when you need field-by-field details.
+Use `void.config.ts` to configure your app. For a guided introduction, start with [What is Void?](../guide/).
 
-Project configuration lives in a typed `void.config.ts` at the project root. Import `defineConfig` from `void/config`; all fields are optional. `void init` creates this file, and `void init`, `void deploy`, or `void migrate` converts existing `void.json` and root Wrangler JSON/JSONC files. Void saves the originals under `.void/config-migration/`. Commit `void.config.ts` and `void.lock.json` when Void creates the lock file. You can edit the typed config at any time; the lock records Cloudflare resource IDs and migration history that Void resolves for you.
+Put `void.config.ts` at the project root and import `defineConfig` from `void/config`. All fields are optional. `void init`, `void deploy`, and `void migrate` can convert older Void and Cloudflare JSON config files, saving backups under `.void/config-migration/`. Commit `void.config.ts` and `void.lock.json` when Void creates the lock; it records resource IDs and migration history.
 
 ```ts
 // void.config.ts
@@ -253,7 +253,7 @@ Enable and configure Cloudflare Sandboxes for Void apps. Importing from `void/sa
 | `instanceType`      | `string` | `lite` on Void deploy                |
 | `maxInstances`      | `number` | `20` on Void deploy                  |
 
-Sandbox support currently applies to Void apps on the Cloudflare target. Native deployment requires [Workers Paid](https://dash.cloudflare.com/?to=/:account/workers/plans) because Cloudflare Containers are unavailable on Workers Free. `void deploy --platform cloudflare` verifies Containers access before provisioning resources or building the app and explains how to fix a missing plan or API-token permission. Managed deployment checks the platform account and runtime token only when a Sandbox app is deployed; the token needs Account / Containers: Edit and Account / Cloudchamber: Edit. Apps that do not import `void/sandbox` or configure `sandbox` emit no Container and perform no entitlement check. The default registry image is pinned to the installed `@cloudflare/sandbox` version, so local and native Cloudflare deploys run the same container as Void Platform. If `sandbox.image` is a custom local Dockerfile path, set `sandbox.platformImage` to the pushed image that the platform should run.
+Sandbox is available to Void apps on the Cloudflare target and requires [Workers Paid](https://dash.cloudflare.com/?to=/:account/workers/plans) and Containers access. Void checks access before provisioning or building. For a managed platform, its runtime token needs Account / Containers: Edit and Account / Cloudchamber: Edit. Apps without Sandbox use neither Containers nor an entitlement check. The default image matches the installed `@cloudflare/sandbox` version. If `sandbox.image` points to a local Dockerfile, set `sandbox.platformImage` to the pushed image for the platform.
 
 ### `target`
 
@@ -316,7 +316,7 @@ 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`.
 
-`worker.limits.cpu_ms` caps Workers CPU time per request, in milliseconds. It must be an integer between 1 and 300000 (Cloudflare's hard maximum, 5 minutes). A deploy that requests more than your account plan's ceiling fails with an error naming both the requested value and the plan maximum. Only a rollback clamps: rolling back to a deployment whose configured limit now exceeds your plan applies the plan ceiling instead of failing. If your plan changes so that a previously valid value now exceeds the ceiling, deploys keep failing until you lower `cpu_ms` in `void.config.ts`. On the direct Cloudflare path, the value is written into the generated `dist/ssr/wrangler.json` as `limits.cpu_ms` and enforced by Cloudflare directly. The Void plan ceiling does not apply there, but your Cloudflare account's own CPU-time allowance still does: the Workers Free plan caps CPU at 10 ms per request, and the Workers Paid plan allows up to 300000 ms. A value above what your Cloudflare account permits is constrained or rejected by Cloudflare, not by Void.
+`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
 {
@@ -493,9 +493,9 @@ Each binding accepts `true` (use default name), `false` (disable), or a string (
 | `ai`      | `AI`            | `Ai`          | `"ai": "MY_AI"`          |
 | `email`   | —               | —             | Boolean only             |
 
-Custom resource binding names flow through deploy manifests, Cloudflare config generation, remote binding proxying, internal migrations, and generated runtime helpers such as `void/db`, `void/kv`, and `void/storage`. Custom AI names apply to generated Cloudflare configuration and `void/ai` runtime resolution for direct Cloudflare builds; managed Workers AI continues to use Void's service proxy.
+Custom binding names work with `void/db`, `void/kv`, and `void/storage` during development and deployment. Custom AI names also work with `void/ai` on direct Cloudflare deploys; managed Workers AI uses the platform's proxy.
 
-`email` is a feature switch rather than a Cloudflare binding, so it has no binding name or type. On the platform, outbound mail is sent through the Void proxy, which owns the `send_email` binding — none is written into your worker; on your own Cloudflare account, `void deploy --platform cloudflare` records a `send_email` binding named `SEND_EMAIL` in `void.lock.json` once email is set up (see [`email.from`](#email)). Set it to `true` to turn the [email integration](../guide/email.md) on — which registers the `void dev` inbox — even when no scanned file imports `void/email`, or `false` to turn it off.
+`email` is a boolean feature switch. Set it to `true` to enable [email](../guide/email.md) and the `void dev` inbox without an import from `void/email`, or `false` to disable them. On a Void platform, sending uses the platform proxy. Direct Cloudflare setup records a `SEND_EMAIL` binding in `void.lock.json`; see [`email.from`](#email).
 
 #### `inference.build`
 

package/dist/gen-BBiIZw6g.mjs

@@ -1,2 +0,0 @@
-import { r as runGenCommand } from "./gen-CFOEEc-t.mjs";
-export { runGenCommand };

package/dist/help-CS_nAsWu.mjs

@@ -1,2 +0,0 @@
-import { r as printHelpPage } from "./help-C46mnlUS.mjs";
-export { printHelpPage };

package/dist/login-Ch9cgWRF.mjs

@@ -1,2 +0,0 @@
-import { r as selectPlatformLoginMethod } from "./login-CKk5NX4d.mjs";
-export { selectPlatformLoginMethod };

package/dist/migrate-CLty4mZR.mjs

@@ -1,2 +0,0 @@
-import { n as runMigrateCommand } from "./migrate-DcW8F2W8.mjs";
-export { runMigrateCommand };