void 0.20.3 → 0.21.0

package/skills/void/docs/integrations/frameworks/sveltekit.md

@@ -21,53 +21,56 @@ cd my-app
 npm install -D @sveltejs/adapter-cloudflare void
 ```
 
-### 3. Configure `svelte.config.js`
-
-```js
-import adapter from '@sveltejs/adapter-cloudflare';
-import { withVoidTSConfig } from 'void/sveltekit';
-
-export default {
-  kit: {
-    adapter: adapter(),
-    typescript: {
-      config: withVoidTSConfig(),
-    },
-  },
-};
-```
-
-### 4. Add `voidPlugin()` to `vite.config.ts`
+### 3. Configure `vite.config.ts`
 
 ```ts
+import adapter from '@sveltejs/adapter-cloudflare';
 import { sveltekit } from '@sveltejs/kit/vite';
 import { voidPlugin } from 'void';
+import { withVoidTSConfig } from 'void/sveltekit';
 import { defineConfig } from 'vite';
 
 export default defineConfig({
-  plugins: [voidPlugin(), sveltekit()],
+  plugins: [
+    voidPlugin(),
+    sveltekit({
+      adapter: adapter({
+        config: './.void-wrangler.jsonc',
+        platformProxy: { configPath: './.void-wrangler.jsonc' },
+      }),
+      typescript: {
+        config: withVoidTSConfig(),
+      },
+    }),
+  ],
 });
 ```
 
-### 5. Create `wrangler.jsonc`
+If your project already configures SvelteKit in `svelte.config.js`, keep that file and add `typescript.config: withVoidTSConfig()` under its `kit` options instead. SvelteKit ignores `svelte.config.js` when options are passed directly to `sveltekit()`.
 
-SvelteKit's adapter reads bindings from `wrangler.jsonc` for local dev. `voidPlugin()` auto-syncs inferred bindings into this file on dev startup, so you only need the base config:
+### 4. Create `void.config.ts`
 
-```jsonc
-{
-  "name": "my-app",
-  "compatibility_date": "2026-02-24",
-  "compatibility_flags": ["nodejs_compat"],
-}
+Point SvelteKit's adapter at Void's generated Cloudflare config as shown above. Add your Cloudflare settings to `void.config.ts`:
+
+```ts
+import { defineConfig } from 'void/config';
+
+export default defineConfig({
+  cloudflare: {
+    name: 'my-app',
+    compatibility_date: '2026-02-24',
+    compatibility_flags: ['nodejs_compat'],
+  },
+});
 ```
 
 By default, SvelteKit's Cloudflare adapter, `voidPlugin()` migrations, and `void db` commands share local state at `.wrangler/state/v3`, so no extra `platformProxy.persist` configuration is required.
 
-### 6. Configure `tsconfig.json`
+### 5. Configure `tsconfig.json`
 
 SvelteKit generates `.svelte-kit/tsconfig.json` and expects your root config to extend it. Void generates `.void/tsconfig.json` for project-specific aliases such as `void/db` and `@schema`.
 
-Do not add Void's `compilerOptions.paths` to the root `tsconfig.json`; SvelteKit warns because root-level paths override its generated aliases. The `withVoidTSConfig()` hook above merges Void's generated files and aliases into SvelteKit's generated config instead.
+Do not add Void's `compilerOptions.paths` to the root `tsconfig.json`; SvelteKit warns because root-level paths override its generated aliases. The `withVoidTSConfig()` hook merges Void's generated files and aliases into SvelteKit's generated config instead.
 
 ```json
 {
@@ -80,7 +83,7 @@ Do not add Void's `compilerOptions.paths` to the root `tsconfig.json`; SvelteKit
 
 Run `void prepare` after a fresh clone or before typechecking in CI so `.void/tsconfig.json` exists before SvelteKit syncs its config.
 
-### 7. Deploy
+### 6. Deploy
 
 ```bash
 void auth login
@@ -132,7 +135,7 @@ import { ai } from 'void/ai';
 
 export const actions = {
   summarize: async () => {
-    return ai.run('@cf/meta/llama-3.1-8b-instruct', {
+    return ai.run('@cf/meta/llama-3.3-70b-instruct-fp8-fast', {
       prompt: 'Summarize the latest news',
     });
   },

package/skills/void/docs/integrations/frameworks/tanstack-start.md

@@ -92,7 +92,7 @@ import { createServerFn } from '@tanstack/react-start';
 import { ai } from 'void/ai';
 
 const summarize = createServerFn().handler(async () => {
-  return ai.run('@cf/meta/llama-3.1-8b-instruct', {
+  return ai.run('@cf/meta/llama-3.3-70b-instruct-fp8-fast', {
     prompt: 'Summarize the latest news',
   });
 });

package/skills/void/docs/integrations/nodejs-bun-deno.md

@@ -4,7 +4,7 @@ outline: deep
 
 # Node.js, Bun, and Deno
 
-Set `target` in `void.json` to build for Node.js, Bun, or Deno. You can run the resulting server on your own machine, in a container, or with a hosting provider.
+Set `target` in `void.config.ts` to build for Node.js, Bun, or Deno. You can run the resulting server on your own machine, in a container, or with a hosting provider.
 
 ```json
 { "target": "node" }
@@ -25,7 +25,7 @@ All three produce the same project structure and use the same Hono-based routing
 ### 1. Configure the target
 
 ```json
-// void.json
+// void.config.ts
 { "target": "node" }
 ```
 
@@ -140,7 +140,7 @@ Inbound [email handlers](../guide/email.md#inbound) in `email/` need Cloudflare
 
 ### Ignored config fields
 
-Void warns and ignores these Cloudflare-specific `void.json` fields on other targets:
+Void warns and ignores these Cloudflare-specific `void.config.ts` fields on other targets:
 
 - `inference.bindings`: Cloudflare binding configuration
 - `remote`: remote binding proxy
@@ -166,11 +166,11 @@ my-app/
       hello.ts
   package.json
   vite.config.ts
-  void.json
+  void.config.ts
 ```
 
 ```json
-// void.json
+// void.config.ts
 { "target": "node" }
 ```
 

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

@@ -10,7 +10,7 @@ This page is the source of truth for user-facing `void` exports. Use it when you
 
 ### `voidPlugin(options?)`
 
-Named export from `"void"`. Returns an array of Vite plugins that set up file-based routing, migration support, and the Cloudflare Workers runtime. Application-level configuration is read from [`void.json`](./config.md); the optional `options` object controls Vite/Cloudflare plugin behavior.
+Named export from `"void"`. Returns an array of Vite plugins that set up file-based routing, migration support, and the Cloudflare Workers runtime. Application-level configuration is read from [`void.config.ts`](./config.md); the optional `options` object controls Vite/Cloudflare plugin behavior.
 
 ```ts
 import { voidPlugin } from 'void';
@@ -25,6 +25,23 @@ export default defineConfig({
 | `persistTo`        | `string`                  | Directory path for persisting local dev state (D1, KV, R2). Defaults to `.void/` in the project root.                                                                                                                             |
 | `auxiliaryWorkers` | `AuxiliaryWorkerConfig[]` | Additional workers to run inside the same Miniflare instance during dev. Passed through to `@cloudflare/vite-plugin`. Useful for running multiple workers that share bindings (e.g. a separate API worker alongside a dashboard). |
 
+## Project configuration
+
+### `defineConfig(config)`
+
+Import from `void/config` in the root `void.config.ts`. It returns the config with editor completion and TypeScript checking. Void validates the result when loading it, including values computed at runtime.
+
+```ts
+import { defineConfig } from 'void/config';
+
+export default defineConfig({
+  cloudflare: { name: 'my-app' },
+  routing: { revalidate: 60 },
+});
+```
+
+See the [config reference](./config.md) for all fields.
+
 ## Handlers
 
 Imported from `"void"` or `"void/handler"`.
@@ -278,7 +295,7 @@ function defineHead<P = Record<string, unknown>>(
 
 ## Rewrites
 
-URL rewrites re-dispatch a request at a different internal path without changing the browser's URL. `c.rewrite()`, `c.originalUrl()`, and `c.isRewritten()` are available on every Hono `Context` the Void runtime hands you. See the [Rewrites guide](../guide/edge/rewrites.md) for the full overview, including static `routing.rewrites` / `routing.fallbacks` in [`void.json`](./config.md#routing).
+URL rewrites re-dispatch a request at a different internal path without changing the browser's URL. `c.rewrite()`, `c.originalUrl()`, and `c.isRewritten()` are available on every Hono `Context` the Void runtime hands you. See the [Rewrites guide](../guide/edge/rewrites.md) for the full overview, including static `routing.rewrites` / `routing.fallbacks` in [`void.config.ts`](./config.md#routing).
 
 ### `c.rewrite(destination)`
 
@@ -345,7 +362,7 @@ import type { RewriteDestination } from 'void/routes';
 Union of the exact route patterns from your generated `RouteMap` plus a `string` fallback (`RouteName | (string & {})`). Known route patterns (e.g. `/posts/[id]`) are offered as autocomplete entries in your editor, while the `string` branch keeps the type assignable from concrete runtime paths like `` `/posts/${id}` `` — there is no `:id` template-literal resolution at the type level. Used as:
 
 - The parameter type of [`c.rewrite()`](#c-rewrite-destination).
-- The type of `destination` entries in `routing.rewrites` and `routing.fallbacks` in [`void.json`](./config.md#routing).
+- The type of `destination` entries in `routing.rewrites` and `routing.fallbacks` in [`void.config.ts`](./config.md#routing).
 
 Like [`RouteMap`](#routemap), `RewriteDestination` lives in the virtual `void/routes` module and is refreshed whenever routes change.
 
@@ -752,7 +769,7 @@ Typed AI client for Cloudflare AI models and provider-native AI Gateway requests
 ```ts
 import { ai } from 'void/ai';
 
-const result = await ai.run('@cf/meta/llama-3.1-8b-instruct', {
+const result = await ai.run('@cf/meta/llama-3.3-70b-instruct-fp8-fast', {
   messages: [{ role: 'user', content: 'Summarize this release note.' }],
 });
 

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

@@ -48,6 +48,7 @@ Use this page as a command reference. If you are setting up a project for the fi
 | `void email disallow <address>`   | Remove a recipient from the allowlist                                         |
 | `void email domain`               | Send and receive at your own domain on a Cloudflare zone                      |
 | `void init`                       | Setup wizard for new or existing projects                                     |
+| `void migrate`                    | Convert legacy `void.json` and root Wrangler JSON/JSONC into `void.config.ts` |
 
 ## Binary Invocation
 
@@ -75,6 +76,10 @@ Use `void --help` for the command list. For a specific command, try `void deploy
 
 ## Setup
 
+### `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 init`
 
 ```
@@ -108,7 +113,7 @@ After that, the full interactive flow walks through:
 3. **Agent instructions:** always creates or updates `AGENTS.md` with brief Void instructions and the bundled docs path, preserving content outside the versioned block.
 4. **Skills:** links Void skills for detected coding agents.
 5. **Demo code:** for existing non-Pages projects, optionally scaffolds a `db/migrations/` directory plus an API route and typed fetch example.
-6. **Deployment platform:** asks where `void deploy` should send the app: Cloudflare (the default), Void, or Skip deployment setup. The choice is stored as `platform` in `.void/project.json`. Choosing Cloudflare creates or augments `wrangler.jsonc`, checks the Cloudflare session through Void's bundled tooling, opens secure browser sign-in when needed, and writes the selected account as `account_id` (automatically when only one account is available).
+6. **Deployment platform:** asks where `void deploy` should send the app: Cloudflare (the default), Void, or Skip deployment setup. The choice is stored as `platform` in `.void/project.json`. Choosing Cloudflare records settings in `void.config.ts` and `void.lock.json`, checks the Cloudflare session through Void's bundled tooling, opens secure browser sign-in when needed, and writes the selected account as `account_id` (automatically when only one account is available).
 7. **GitHub Actions:** optionally creates `.github/workflows/void-deploy.yml` for the selected target. Cloudflare workflows run `void deploy --platform cloudflare` with `CLOUDFLARE_API_TOKEN` and pass the optional `DATABASE_URL` secret needed by PostgreSQL/MySQL apps. Void workflows use the selected platform's API URL and are offered only when its discovery document advertises GitHub Actions support.
 8. **`env.ts` scaffold:** if the project has no `env.ts` but has a root `.env`, generates an `env.ts` pre-populated with its keys. Values get conservative type inference (`boolean`/`url`/`number`/`string`) — the file carries a banner nudging you to tighten anything the heuristic got wrong.
 9. **Void project setup:** when Void is selected, optionally logs you in, lets you select or create a project, and adds the link to `.void/project.json` so your first deploy can just be `void deploy`.
@@ -154,7 +159,7 @@ void connect --platform void
 
 Connect a project to its deployment destination. With no arguments, choose Cloudflare or a Void platform interactively. A URL selects a Void platform directly. `--platform void` offers saved platforms and an option to enter another URL.
 
-For Cloudflare, Void signs in through the browser when needed, selects an accessible account, and saves `account_id` in the root `wrangler.jsonc` or `wrangler.json`. It shares this setup with `void init`. An existing account selection is preserved; conflicting or inaccessible account settings must be resolved before continuing.
+For Cloudflare, Void signs in through the browser when needed, selects an accessible account, and saves `cloudflare.account_id` in `void.config.ts` or resolved state in `void.lock.json`. It shares this setup with `void init`. An existing account selection is preserved; conflicting or inaccessible account settings must be resolved before continuing.
 
 For a Void platform, Void validates its discovery document, reuses a valid session or opens browser login using the platform's supported providers, and saves the verified API and proxy origins. Credentials are stored in the operating-system keychain for that API origin. A sole login provider is selected automatically.
 
@@ -220,11 +225,11 @@ An API token or global API key pair in the environment takes precedence over bro
 Show deployments for the configured target.
 
 - Void targets show recent hosted deployments; `[name]` looks up a project by slug and otherwise the linked project is used.
-- Cloudflare targets list Worker Versions, identify the active version, and show the recorded migration count. A project name is not accepted because the Worker name comes from root `wrangler.jsonc`.
+- Cloudflare targets list Worker Versions, identify the active version, and show the recorded migration count. A project name is not accepted because the Worker name comes from `cloudflare.name` in `void.config.ts`.
 
 ### `void project link [name]`
 
-Link current directory to an existing hosted Void project by slug, or select interactively if omitted. State is stored in `.void/project.json`. Direct Cloudflare apps use the Worker name in the root config and do not need linking.
+Link current directory to an existing hosted Void project by slug, or select interactively if omitted. State is stored in `.void/project.json`. Direct Cloudflare apps use `cloudflare.name` in `void.config.ts` and do not need linking.
 
 ### `void project list`
 
@@ -309,7 +314,7 @@ in the two entries when the Access policies require them.
 void project logs [--level <level>] [--filter <text>] [--range <duration>] [--deployment <id>]
 ```
 
-Show runtime logs from the deployed target. Hosted Void targets query retained log history. Cloudflare targets open a live tail for the Worker named in root `wrangler.jsonc`; they do not provide historical log storage.
+Show runtime logs from the deployed target. Hosted Void targets query retained log history. Cloudflare targets open a live tail for the Worker named in `void.config.ts`; they do not provide historical log storage.
 
 | Flag                 | Purpose                                                                                                                                                                                                         | Default |
 | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
@@ -625,7 +630,7 @@ void platform signup allow identity <connection-id> <subject> [--note <text>]
 void platform signup disallow identity <connection-id> <subject>
 ```
 
-Connection IDs are shown by `void platform config auth list`. Identity subjects match exactly and case-sensitively; wildcards, email inference, and account linking are not applied. The login method's domain or group restrictions must still pass, and a newly admitted account has the ordinary user role. With restrictions enabled and an empty allowlist, nobody new can sign up.
+Connection IDs are shown by `void platform config auth list`. Identity subjects match exactly and case-sensitively; wildcards, email inference, and account linking are not applied. The login method's domain or group restrictions must still pass, and a newly admitted account has the ordinary user role. Under invited/allowlisted signup, an empty allowlist blocks new accounts. Under company-approved signup, explicit grants admit people in addition to the company rules.
 
 #### Invitations {#operator-invitations}
 
@@ -637,7 +642,7 @@ void platform invitation send <email[,email...]>
 void platform invitation revoke <id>
 ```
 
-Send accepts up to 100 comma-separated addresses. Invitations grant signup access even if email delivery is unavailable or fails; delivery is reported separately. Revoking a pending invitation removes its exact email grant. A broader domain entry can still allow that person to sign up.
+Send accepts up to 100 comma-separated addresses. Invitations grant signup access even if email delivery is unavailable or fails; delivery is reported separately. Share the platform's `/invite` page or `void connect '<platform URL>'` command yourself when no email is sent. Revoking a pending invitation removes its exact email grant. A broader domain entry can still allow that person to sign up.
 
 #### Email {#operator-email}
 
@@ -772,8 +777,12 @@ To enable email during install or upgrade, set both `VOID_EMAIL_SENDER_DOMAIN` a
 
 `--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.
 
+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.
+
 Use an empty PostgreSQL database dedicated to the installation. You can correct a failed initial connection, but after the database is claimed or Hyperdrive is provisioned, commands reject a different URL.
 
+During interactive installation, choose whether Void creates Hyperdrive or uses one you manage separately. If the separately managed configuration is missing, Void shows the required name and setup instructions, then stops before provisioning. Once it exists, Void shows its database, host, port, runtime user, and cache setting for confirmation. Supply an owner PostgreSQL URL at the normal prompt for database claims and migrations. Void adopts the Hyperdrive after verifying its origin and disabled SQL result caching; its configuration stays under the external manager's control. Unattended installs can set `VOID_PLATFORM_HYPERDRIVE_ID`, `VOID_PLATFORM_HYPERDRIVE_ORIGIN_HOST`, and `VOID_PLATFORM_HYPERDRIVE_ORIGIN_USER` together.
+
 Recovery secrets are encrypted with AES-256-GCM using a key in your system keychain. The encrypted data is tied to the installation identity. Without a keychain, supply a canonical base64-encoded 32-byte `VOID_PLATFORM_RECOVERY_KEY`; otherwise Void stops before saving secrets. CI can generate a temporary key when its original credentials remain in protected secrets.
 
 If a newly created zone is waiting for registrar delegation, resume after it becomes active:
@@ -855,11 +864,11 @@ void deploy [--platform <cloudflare|void>] [--require-email]
 
 Auto-detects your project type and chooses the right pipeline. See [Supported App Types](../guide/app-types.md) and [Deployment](../guide/deployment.md) for details.
 
-An unlinked project with a root `wrangler.jsonc` or `wrangler.json` gets a prompt to link and deploy to Cloudflare using its existing Worker and resources. Accepting verifies the target, saves Cloudflare as the destination, and continues deployment. A failed build retains the link for retry. Declining changes nothing. Explicit platform/project selections and saved destinations take precedence; CI must select a destination explicitly.
+An unlinked project with a root `wrangler.jsonc`, `wrangler.json`, or a single root `wrangler*.json(c)` file explicitly referenced by a supported framework adapter gets a prompt to link and deploy to Cloudflare using its existing Worker and resources. Accepting verifies the target, saves Cloudflare as the destination, and continues deployment. A failed build retains the link for retry. Declining changes nothing. Explicit platform/project selections and saved destinations take precedence; CI must select a destination explicitly.
 
 The first handoff preserves production bindings, variables, secrets, event handlers, and triggers. The active version must be the latest uploaded version so inherited secrets have an unambiguous source. Apart from an explicitly enabled ISR cache, new resources, migrations, runtime features, auth setup, or local secret overrides must be handled separately. See [Deploy an existing Worker](../integrations/cloudflare.md#deploy-an-existing-worker).
 
-When prerendered or revalidated pages need a cache during migration, Void asks whether to enable ISR and saves `routing.isr` in `void.json`. Yes provisions the KV cache during this handoff; No keeps ISR disabled on every later deploy until you change the setting. CI must set `routing.isr` explicitly if a pending migration has no saved choice. Existing ISR namespaces are reused; application KV bindings are still required.
+When prerendered or revalidated pages need a cache during migration, Void asks whether to enable ISR and saves `routing.isr` in `void.config.ts`. Yes provisions the KV cache during this handoff; No keeps ISR disabled on every later deploy until you change the setting. CI must set `routing.isr` explicitly if a pending migration has no saved choice. Existing ISR namespaces are reused; application KV bindings are still required.
 
 For Drizzle projects, deploy performs a read-only schema drift check. If a new migration would be generated, deploy stops and tells you to run `void db generate`, review the migration, commit it yourself, and rerun `void deploy`.
 
@@ -925,7 +934,7 @@ That fallback is mainly for projects that skipped Void project setup during `voi
 
 ### `void deploy --platform cloudflare`
 
-Build and deploy to your Cloudflare account using the root `wrangler.jsonc`:
+Build and deploy to your Cloudflare account using `void.config.ts`:
 
 ```sh
 void deploy --platform cloudflare
@@ -938,13 +947,13 @@ Void signs you in through your browser when needed and saves the selected accoun
 | ------------------------------ | -------------------------------------------------------------------------------------- |
 | `--dir`, `--spa`               | Deploy static output through a small Worker and Workers Assets                         |
 | `--skip-build`                 | Reuse existing static, SPA, or SSG output; unavailable for Worker apps                 |
-| `--project`                    | Unavailable; the Worker and account come from the Cloudflare config                    |
-| Named environments             | Unavailable; use the top-level root config                                             |
+| `--project`                    | Unavailable; the Worker and account come from `void.config.ts` and `void.lock.json`    |
+| Named environments             | Unavailable; use the top-level `cloudflare` config                                     |
 | `CLOUDFLARE_WORKERS_SUBDOMAIN` | Needed in fresh CI when versions have no preview URL; cached locally after a deploy    |
 | `--require-email`              | Fail instead of deploying without email when the email step cannot run, as in CI       |
 | `DATABASE_URL`                 | Required in the deploy environment for PostgreSQL or MySQL provisioning and migrations |
 
-The token needs Workers Scripts: Edit, read access to bound resources, and edit permissions for products Void provisions. First-time Hyperdrive provisioning specifically needs `CLOUDFLARE_API_TOKEN` with Hyperdrive edit permission, or an existing config ID in `wrangler.jsonc`.
+The token needs Workers Scripts: Edit, read access to bound resources, and edit permissions for products Void provisions. First-time Hyperdrive provisioning specifically needs `CLOUDFLARE_API_TOKEN` with Hyperdrive edit permission, or an existing config ID in `cloudflare.hyperdrive` in `void.config.ts`.
 
 Email setup needs a browser session from `void cloudflare login`, which carries the Email Routing and Email Sending scopes (a session created by older Cloudflare tooling lacks them: `void cloudflare logout`, then sign in again), or a `CLOUDFLARE_API_TOKEN` that also has Email Routing Edit and Email Sending Edit. A Global API Key pair is refused.
 
@@ -956,13 +965,13 @@ If Cloudflare Access protects readiness URLs, supply an allowed `CF_ACCESS_CLIEN
 
 Secrets and migrations are validated after the build, so a failed check may leave provisioned resources. It doesn't apply remote D1 migrations or upload the application Worker. PostgreSQL migrations are transactional; MySQL schema changes may partially apply on error.
 
-Provisioning reuses known resource IDs and writes newly resolved IDs into `wrangler.jsonc`, preserving comments but possibly changing indentation. 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.
+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.
 
-`.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 root config and reject named environments and alternate config-path overrides.
+`.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.
 
 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.json` 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 `wrangler.jsonc` 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 `wrangler.jsonc`, and lets wrangler 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 `add "email": { "from": "you@mail.acme.com" } to void.json` 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 wrangler.jsonc, then redeploy` and deploy without email (or with the setup `wrangler.jsonc` 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.** 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.
 
 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.
 
@@ -1017,7 +1026,7 @@ Run ad-hoc SQL against the database. Provide SQL inline or from a file. SELECT q
 By default, targets the local database. Pass `--remote` to run against the deployed database selected in `.void/project.json`:
 
 - **Void platform D1 projects**: routes the query through the selected platform's registered proxy using your auth token. Void Cloud's proxy is `proxy.void.cloud`; a self-hosted platform uses its own proxy URL.
-- **Direct Cloudflare D1 projects**: invokes Cloudflare against the pinned D1 binding from root `wrangler.jsonc`.
+- **Direct Cloudflare D1 projects**: invokes Cloudflare against the pinned D1 binding from `void.config.ts` or `void.lock.json`.
 - **Hosted PostgreSQL and MySQL projects**: fetches the stored connection string from the platform and connects directly.
 - **Direct Cloudflare PostgreSQL and MySQL projects**: uses `DATABASE_URL` from the current shell; Cloudflare cannot return the password from Hyperdrive.
 
@@ -1209,7 +1218,7 @@ void gen queue emails
 void secret list [--project <name>]
 ```
 
-List production secret names for the saved target. Secret values are never printed. Direct Cloudflare targets query the Worker named in root `wrangler.jsonc`; `--project` is hosted-only.
+List production secret names for the saved target. Secret values are never printed. Direct Cloudflare targets query the Worker named in `void.config.ts`; `--project` is hosted-only.
 
 ### `void secret put`
 
@@ -1495,7 +1504,7 @@ Remove a custom domain from the saved target. For Cloudflare, this removes the m
 void domain list [--project <name>]
 ```
 
-List all custom domains. Hosted projects show active/pending state from the platform; direct Cloudflare projects list the custom-domain routes currently configured in root `wrangler.jsonc`.
+List all custom domains. Hosted projects show active/pending state from the platform; direct Cloudflare projects list the custom-domain routes currently configured in `void.config.ts`.
 
 ### `void domain status`
 
@@ -1509,7 +1518,7 @@ Pass `--verbose` to additionally print the raw multi-line status breakdown (DB s
 
 Project resolution for domain commands follows the same order as deploy (`--project`, `VOID_PROJECT`, linked project).
 
-For direct Cloudflare projects, status reports whether the route is present in the root config. It does not claim to inspect remote certificate issuance; Cloudflare owns that state and exposes it in the dashboard. `--project` is hosted-only.
+For direct Cloudflare projects, status reports whether the route is present in the Void Cloudflare config. It does not claim to inspect remote certificate issuance; Cloudflare owns that state and exposes it in the dashboard. `--project` is hosted-only.
 
 ## Email
 
@@ -1621,7 +1630,7 @@ Disable the domain assignment and record cleanup. Zone resources used by another
 void email status --platform cloudflare
 ```
 
-Read-only. Checks the email setup on your own Cloudflare account for the domain of `email.from` in `void.json` — session scopes, zone, MX records, Email Routing (and its subaddressing setting), Email Sending, the routing rule for every `email/` handler, and the `send_email` binding — then prints the status rows and the address map (`inbound <address> → email/<handler>`, `outbound sendEmail() from <email.from>`). Exits 1 when anything is not ready. A domain still not onboarded for Email Sending reads as set up once the `send_email` binding is committed — the binding is written only after an onboarding attempt, so that pair is how a Workers Free refusal is remembered — and the sending row says so (`not onboarded — verified destinations only; after upgrading to Workers Paid run void email setup --platform cloudflare`). Takes no `--project`: it reads the local project and your Cloudflare session, never a Void project.
+Read-only. Checks the email setup on your own Cloudflare account for the domain of `email.from` in `void.config.ts` — session scopes, zone, MX records, Email Routing (and its subaddressing setting), Email Sending, the routing rule for every `email/` handler, and the `send_email` binding — then prints the status rows and the address map (`inbound <address> → email/<handler>`, `outbound sendEmail() from <email.from>`). Exits 1 when anything is not ready. A domain still not onboarded for Email Sending reads as set up once the `send_email` binding is committed — the binding is written only after an onboarding attempt, so that pair is how a Workers Free refusal is remembered — and the sending row says so (`not onboarded — verified destinations only; after upgrading to Workers Paid run void email setup --platform cloudflare`). Takes no `--project`: it reads the local project and your Cloudflare session, never a Void project.
 
 Without `--platform cloudflare` (or with `--platform void`) the command is not available yet; on the Void platform use `void email usage` and `void email destinations`. The older `--backend cloudflare` spelling remains available as a compatibility alias on `void email status` and `void email setup`, with the same rules as `void deploy`: at most once, and never together with `--platform`.
 
@@ -1631,12 +1640,12 @@ Without `--platform cloudflare` (or with `--platform void`) the command is not a
 void email setup --platform cloudflare
 ```
 
-The same setup `void deploy --platform cloudflare` offers on its first deploy, on its own — for CI, which cannot press Enter: run it locally once, commit `wrangler.jsonc`, then let CI run `void deploy --platform cloudflare --require-email`. Needs `email.from` in `void.json` and a `void cloudflare login` session (a session created by older Cloudflare tooling lacks the email scopes: `void cloudflare logout`, then sign in again) or a `CLOUDFLARE_API_TOKEN` with Email Routing Edit + Email Sending Edit — the CI credential. It runs the preflight above, prints the checklist of what will change on your account, asks once, then:
+The same setup `void deploy --platform cloudflare` offers on its first deploy, on its own — for CI, which cannot press Enter: run it locally once, commit `void.lock.json`, then let CI run `void deploy --platform cloudflare --require-email`. Needs `email.from` in `void.config.ts` and a `void cloudflare login` session (a session created by older Cloudflare tooling lacks the email scopes: `void cloudflare logout`, then sign in again) or a `CLOUDFLARE_API_TOKEN` with Email Routing Edit + Email Sending Edit — the CI credential. It runs the preflight above, prints the checklist of what will change on your account, asks once, then:
 
 1. enables Email Routing on the domain (on an apex through Void's bundled Cloudflare tooling; a subdomain through your session's bearer, borrowed for that one call and dropped),
 2. turns on subaddressing for the zone, so `support+anything@` reaches `support@`,
 3. onboards the domain for Email Sending (a Workers Free account keeps inbound and sends to verified destinations only),
-4. writes `send_email: [{ "name": "SEND_EMAIL" }]`, the derived `addresses` array, and `vars.__VOID_EMAIL_FROM` into your root `wrangler.jsonc`, comments preserved.
+4. writes `send_email: [{ "name": "SEND_EMAIL" }]`, the derived `addresses` array, and `vars.__VOID_EMAIL_FROM` into `void.lock.json`.
 
 The routing rules themselves are created by the next `void deploy --platform cloudflare`: wrangler applies its Email Routing plan from `addresses` on deploy. `void email setup` never writes `addresses` unless routing is ready for the domain, prunes an address already routed to another worker or a forward (and says so), and skips the whole step when the existing `addresses` array holds entries it did not derive. A run that finds every row ready asks nothing and changes nothing on your account — with one exception: a domain still not onboarded for Email Sending while the `send_email` binding is committed (a remembered Workers Free refusal, see `void email status`) is offered as a retry on its own prompt, `Onboard <domain> for Email Sending? Inbound already works; onboarding needs Workers Paid.` — the step to run once after upgrading; answer No and nothing changes. The deploy never retries it. Needs an interactive terminal; exits 1 when the inbound rows are still not ready afterwards — routing not enabled, subaddressing still off, or `addresses` withheld — naming the row and saying to rerun. A Workers Free account's refused sending row is not a failure: inbound is complete, `addresses` is written, the plan hint is printed, and the binding written alongside is what makes the next deploy and `void email status` read the domain as set up. See [Your own Cloudflare account](../guide/email.md#your-own-cloudflare-account).
 

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

@@ -6,38 +6,44 @@ outline: deep
 
 ## Config File Format
 
-Use this page as the exact reference for `void.json`. 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.
-
-Project-level configuration lives in a `void.json` file at the project root. Most fields are optional. Cloudflare-targeted apps must pin a Workers `compatibility_date` in `worker.compatibility_date` or in a supported Cloudflare fallback file (`wrangler.jsonc` or `wrangler.json`). If no date is configured, Void writes the latest known-good date to `void.json` so future runs stay explicit and stable.
-
-```json
-{
-  "$schema": "./node_modules/void/schema.json",
-  "sourceDir": "src",
-  "target": "cloudflare",
-  "auth": {
-    "providers": ["email", "github", "google"]
+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.
+
+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.
+
+```ts
+// void.config.ts
+import { defineConfig } from 'void/config';
+
+export default defineConfig({
+  sourceDir: 'src',
+  target: 'cloudflare',
+  auth: { providers: ['email', 'github', 'google'] },
+  routing: {
+    revalidate: { '/': 60, '*': 30 },
+    headers: {
+      '/assets/*': ['Cache-Control: public, max-age=31536000, immutable'],
+      '/*': ['X-Frame-Options: DENY', 'X-Content-Type-Options: nosniff'],
+    },
   },
-  "routing": {
-    "revalidate": { "/": 60, "*": 30 },
-    "headers": {
-      "/assets/*": ["Cache-Control: public, max-age=31536000, immutable"],
-      "/*": ["X-Frame-Options: DENY", "X-Content-Type-Options: nosniff"]
-    }
+  inference: {
+    bindings: { db: true, kv: false },
+    appType: 'spa',
+    outputDir: 'dist',
   },
-  "inference": {
-    "bindings": { "db": true, "kv": false },
-    "appType": "spa",
-    "outputDir": "dist"
+  worker: {
+    compatibility_date: '2025-12-01',
+    compatibility_flags: ['nodejs_compat'],
   },
-  "worker": {
-    "compatibility_date": "2025-12-01",
-    "compatibility_flags": ["nodejs_compat"]
-  }
-}
+  cloudflare: {
+    name: 'my-app',
+    account_id: 'your-account-id',
+  },
+});
 ```
 
-Add the `$schema` field for autocomplete and validation in your editor. The schema ships with the `void` package at `node_modules/void/schema.json` and is also exposed as the `void/schema.json` package subpath.
+TypeScript provides editor completion and checks. Void validates the config again when it runs, including values computed at runtime.
+
+The shorter JSON fragments below show individual fields to place inside `defineConfig({ ... })`.
 
 ## Fields
 
@@ -53,7 +59,7 @@ When set, those conventions move under the configured directory:
 { "sourceDir": "src" }
 ```
 
-With that config, Void reads `src/pages`, `src/routes`, `src/db/schema.ts`, `src/db/migrations`, `src/auth.ts`, and `src/env.ts`. Project files such as `void.json`, `vite.config.ts`, `package.json`, `tsconfig.json`, `wrangler.json`, `public/`, and the local-only `.env` stay at the project root. Void does not scan both locations; if source conventions exist in both places during dev/build, remove one copy so the active source tree is unambiguous.
+With that config, Void reads `src/pages`, `src/routes`, `src/db/schema.ts`, `src/db/migrations`, `src/auth.ts`, and `src/env.ts`. Project files such as `void.config.ts`, `vite.config.ts`, `package.json`, `tsconfig.json`, `public/`, and the local-only `.env` stay at the project root. Void does not scan both locations; if source conventions exist in both places during dev/build, remove one copy so the active source tree is unambiguous.
 
 ### `auth`
 
@@ -152,7 +158,7 @@ What `from` does depends on where the app runs:
 
 - **`void dev`** — becomes the default `from` of every `sendEmail()` call, captured in the dev inbox; no mail leaves the machine.
 - **`void deploy`** (managed platform) — not used: the sender is pinned to your project's own platform address, which Void fills in for you.
-- **`void deploy --platform cloudflare`** (your own Cloudflare account) — the address host (`mail.acme.com`) is the domain Void sets Email Routing and Email Sending up on, and the address becomes the default `from` (written into the worker as the `__VOID_EMAIL_FROM` var). The host must be a zone in the pinned Cloudflare account, or a subdomain of one; a subdomain is the usual choice, and the apex is refused when it already receives mail elsewhere. An app that uses email without `email.from` deploys without it and prints the line to add. Void never picks a zone or writes `void.json` for you. See [Your own Cloudflare account](../guide/email.md#your-own-cloudflare-account).
+- **`void deploy --platform cloudflare`** (your own Cloudflare account) — the address host (`mail.acme.com`) is the domain Void sets Email Routing and Email Sending up on, and the address becomes the default `from` (written into the worker as the `__VOID_EMAIL_FROM` var). The host must be a zone in the pinned Cloudflare account, or a subdomain of one; a subdomain is the usual choice, and the apex is refused when it already receives mail elsewhere. An app that uses email without `email.from` deploys without it and prints the line to add. Void never picks a zone or writes `void.config.ts` for you. See [Your own Cloudflare account](../guide/email.md#your-own-cloudflare-account).
 
 ### `head`
 
@@ -215,7 +221,7 @@ Use remote D1/KV/R2 bindings during local development instead of local miniflare
 - Must have a linked project (`void project link`)
 - Only affects D1 (`DB`), KV (`KV`), and R2 (`STORAGE`) bindings
 
-You can also enable remote mode via the `VOID_REMOTE=1` environment variable without modifying `void.json`:
+You can also enable remote mode via the `VOID_REMOTE=1` environment variable without modifying `void.config.ts`:
 
 ```bash
 VOID_REMOTE=1 pnpm dev
@@ -270,7 +276,7 @@ Void-managed WebSocket route files (`*.ws.ts`) are Cloudflare-only because they
 
 ### `worker`
 
-Curated Cloudflare Workers configuration. Cloudflare-targeted apps require an explicit `compatibility_date` here unless it is provided by a supported Cloudflare fallback file. If no date is configured, Void writes the latest known-good date here. Binding arrays such as `d1_databases`, `kv_namespaces`, and `r2_buckets` are not allowed here because Void manages bindings through inference and `inference.bindings`. If you need custom bindings with real IDs, add them to `wrangler.jsonc`; Void preserves them during deployment.
+Curated Cloudflare Workers configuration. `void init` pins `compatibility_date` here. Binding arrays such as `d1_databases`, `kv_namespaces`, and `r2_buckets` go in [`cloudflare`](#cloudflare), where Void preserves custom settings and resolved IDs during deployment.
 
 | Field                 | Type       | Description                            |
 | --------------------- | ---------- | -------------------------------------- |
@@ -293,7 +299,24 @@ Curated Cloudflare Workers configuration. Cloudflare-targeted apps require an ex
 
 `worker.vars` values must be strings. Root `.env` values override them during local development only. Production builds do not load `.env`, and reject any `worker.vars` name declared as a server key in `env.ts`. Use `void secret put` for production server values.
 
-`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.json`. 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.
+### `cloudflare`
+
+The complete Cloudflare Worker configuration for direct Cloudflare builds and deployment. Put custom bindings, `name`, `account_id`, routes, services, vars, migrations, and any other Cloudflare fields here. Void passes these fields through to the generated Cloudflare build configuration. Settings you edit here take precedence over values Void previously recorded in `void.lock.json`.
+
+```ts
+// Inside defineConfig({ ... })
+cloudflare: {
+  name: 'my-app',
+  d1_databases: [{ binding: 'ANALYTICS', database_name: 'analytics', database_id: '...' }],
+  vars: { PUBLIC_API_BASE: 'https://api.example.com' },
+},
+```
+
+Void writes a generated Cloudflare config for its tooling and records provisioned resource IDs and append-only migration history in `void.lock.json`. Commit the lock when it changes. Root `wrangler.jsonc` and `wrangler.json` are migrated on `void init` or `void deploy`; Void keeps backup copies under `.void/config-migration/`.
+
+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.
 
 ```json
 {
@@ -472,7 +495,7 @@ Each binding accepts `true` (use default name), `false` (disable), or a string (
 
 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.
 
-`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` writes a `send_email` binding named `SEND_EMAIL` into `wrangler.jsonc` itself 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 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.
 
 #### `inference.build`
 

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

@@ -14,7 +14,7 @@ const items = [
   { name: "public/", description: "Static assets (served as-is)", link: "#public" },
   { name: ".void/", description: "Auto-generated (gitignored)", link: "#void" },
   { name: "vite.config.ts", description: "Vite config with voidPlugin()", link: "#config-files" },
-  { name: "void.json", description: "Void project config (optional)", link: "#config-files" },
+  { name: "void.config.ts", description: "Void project config (optional)", link: "#config-files" },
   { name: ".env", description: "Environment variables", link: "#config-files" },
   { name: "package.json" },
   { name: "tsconfig.json" },
@@ -167,7 +167,7 @@ Generate or refresh it with `void prepare`, or let `vite dev` / `vite build` pop
 | File             | Purpose                                                                                                                                                  |
 | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `vite.config.ts` | Vite configuration. Must include `voidPlugin()`.                                                                                                         |
-| `void.json`      | Optional Void config for [routing](/reference/config#routing), [inference](/reference/config#inference), and [worker settings](/reference/config#worker) |
+| `void.config.ts` | Optional Void config for [routing](/reference/config#routing), [inference](/reference/config#inference), and [worker settings](/reference/config#worker) |
 | `tsconfig.json`  | TypeScript config. Extend `.void/tsconfig.json` for auto-generated types; run `void init --tsconfig` when an existing config already uses `extends`.     |
 | `.env`           | Local development values only (gitignored; never deployed)                                                                                               |
 | `env.ts`         | Checked-in env names, types, defaults, and requiredness                                                                                                  |