void 0.21.9 → 0.23.0

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

@@ -4,7 +4,7 @@ outline: deep
 
 # MySQL
 
-Void supports MySQL through [Cloudflare Hyperdrive](https://developers.cloudflare.com/hyperdrive/). You bring a MySQL-compatible database; Void provides the Drizzle runtime, local tooling, migration workflow, and deployment wiring.
+Connect your MySQL database through [Cloudflare Hyperdrive](https://developers.cloudflare.com/hyperdrive/), then define tables and query them with Drizzle. Void configures the connection and applies your migrations when you deploy.
 
 ## Configure
 

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

@@ -36,25 +36,17 @@ This connects directly to your Postgres database during local Vite development.
 
 ### 3. Deploy
 
-When deploying to a Void platform, the CLI asks for a connection string if Hyperdrive isn't configured:
+For a Void platform, deploy prompts for the connection string if needed. You can also set it with `void db set-url`. For direct Cloudflare deploys, export the production `DATABASE_URL` in your shell.
 
-```
-Your project uses PostgreSQL. Enter your connection string:
-> postgresql://user:password@host:5432/mydb?sslmode=require
-```
-
-Void provisions Hyperdrive and records its config ID. The connection string isn't written to `void.config.ts`, `void.lock.json`, or generated Worker config.
-Both `postgres://` and `postgresql://` URLs are supported, including provider-supplied query strings such as `?sslmode=require`.
-
-For a linked Void project, you can also configure the connection with `void db set-url`. For a direct Cloudflare deploy, export the production `DATABASE_URL` in your shell.
+Void provisions Hyperdrive without saving the connection string in project config. Both `postgres://` and `postgresql://` URLs are supported, including provider query strings such as `?sslmode=require`.
 
 ## Schema Definition
 
-With the `postgresql` dialect, import schema helpers from `void/schema-pg` (re-exports from `drizzle-orm/pg-core`):
+Import schema helpers from `void/schema-pg`:
 
 ```ts
 // db/schema.ts
-import { pgTable, serial, text, timestamp, boolean, doublePrecision } from 'void/schema-pg';
+import { pgTable, serial, text, timestamp, boolean } from 'void/schema-pg';
 
 export const users = pgTable('users', {
   id: serial('id').primaryKey(),
@@ -86,20 +78,7 @@ void db status
 
 The main difference is that PostgreSQL supports **transactional DDL**. Each migration is wrapped in `BEGIN` and `COMMIT`, so a failure rolls back the whole migration instead of leaving the database half-updated.
 
-## Deploy Workflow
-
-When deploying a PostgreSQL project to a Void platform:
-
-1. The app is built
-2. Migration files are collected from `db/migrations/`
-3. If Hyperdrive hasn't been provisioned yet, you're prompted for the connection string
-4. Pending migrations run inside the deployed worker via Hyperdrive
-5. The new worker goes live
-
-When deploying to your own account with `void deploy --platform cloudflare`, export the production
-connection string as `DATABASE_URL`. Void uses it to provision Hyperdrive and apply the checked-in
-migrations transactionally before it uploads the Worker. The connection string is not written to
-`void.config.ts`, `void.lock.json`, or the generated Worker config.
+`void deploy` applies pending migrations before making the new version live. See [Deployment](../deployment.md).
 
 ## Updating the Connection String
 

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

@@ -39,16 +39,13 @@ Define your tables in TypeScript, then query them with `db` from `void/db`. Void
 
 ## Choosing a Dialect
 
-Void supports three database backends. All use the same Drizzle-based workflow for schema definition, querying, and migrations.
+Choose a database during `void init`, or set `database` in `void.config.ts`:
 
-`void init` can start you with D1, PostgreSQL, MySQL, or no database yet. D1 stays implicit; PostgreSQL writes `"database": "pg"`; MySQL writes `"database": "mysql"`.
-
-|            | [D1 (SQLite)](./database/d1) | [PostgreSQL](./database/postgresql) | [MySQL](./database/mysql)     |
-| ---------- | ---------------------------- | ----------------------------------- | ----------------------------- |
-| Config     | Default                      | `"database": "pg"`                  | `"database": "mysql"`         |
-| Managed by | Void                         | Bring your own database             | Bring your own database       |
-| Best for   | Prototypes, read-heavy apps  | Complex queries, existing Postgres  | Existing MySQL infrastructure |
-| Connection | Automatic D1 binding         | Hyperdrive                          | Hyperdrive                    |
+|            | [D1 (SQLite)](./database/d1) | [PostgreSQL](./database/postgresql) | [MySQL](./database/mysql) |
+| ---------- | ---------------------------- | ----------------------------------- | ------------------------- |
+| Config     | Default                      | `"database": "pg"`                  | `"database": "mysql"`     |
+| Managed by | Void                         | Bring your own database             | Bring your own database   |
+| Connection | Automatic D1 binding         | Hyperdrive                          | Hyperdrive                |
 
 ## Schema Definition
 
@@ -235,25 +232,15 @@ const usersWithPosts = await db.query.users.findMany({
 });
 ```
 
-The user schema is automatically loaded into the `db` instance via a Vite plugin, so relational queries work out of the box.
-
 ::: warning ⚠️ Nuxt and Analog limitations
-Nuxt and Analog use Nitro, which bundles server routes outside of Vite's plugin pipeline. The schema cannot be injected into the `db` instance, so `db.query.*` relational queries are not available in Nuxt and Analog. Use the standard query builder API (`db.select().from(table)`) instead.
+In Nuxt and Analog, use the query builder (`db.select().from(table)`). The `db.query.*` relational API is not available in these frameworks.
 :::
 
 ## Seeding
 
 Use `void db seed` to reset your local database, re-apply migrations, and then run a seed file.
 
-Void resolves default seed files in this order:
-
-1. `db/seed.ts`
-2. `db/seed.mts`
-3. `db/seed.js`
-4. `db/seed.mjs`
-5. `db/seed.sql`
-
-If more than one default seed file exists, pass `--file <path>` explicitly.
+Use `db/seed.ts` for a programmatic seed or `db/seed.sql` for SQL. JavaScript and `.mts` / `.mjs` files also work. If more than one seed file exists, choose one with `--file <path>`.
 
 ### Programmatic seeding
 
@@ -274,7 +261,7 @@ export default defineSeed<typeof import('./schema')>(async ({ db, schema }) => {
 
 The seed context includes:
 
-- `dialect`: `"sqlite"` or `"postgresql"`
+- `dialect`: `"sqlite"`, `"postgresql"`, or `"mysql"`
 - `db`: a Drizzle instance for the local database
 - `schema`: the exports from your `db/schema.ts` or `db/schema/` modules
 
@@ -288,25 +275,14 @@ INSERT INTO messages (text) VALUES ('Hello from SQL');
 
 ## Schema-Derived Validators
 
-You can derive request validators from your Drizzle tables with [`void/drizzle-zod`](../reference/api.md#user-facing-imports), [`void/drizzle-valibot`](../reference/api.md#user-facing-imports), or [`void/drizzle-arktype`](../reference/api.md#user-facing-imports). These adapters use Void's bundled Drizzle version, keeping the validators compatible with your table types.
+Derive request validators from your tables with `void/drizzle-zod`, `void/drizzle-valibot`, or `void/drizzle-arktype`. Add the validator after your table definition:
 
 ::: code-group
 
 ```ts [Zod]
 // db/schema.ts
-import { sqliteTable, text, integer } from 'void/schema-d1';
-import { sql } from 'void/db';
 import { createInsertSchema } from 'void/drizzle-zod';
 
-export const users = sqliteTable('users', {
-  id: integer('id').primaryKey({ autoIncrement: true }),
-  name: text('name').notNull(),
-  email: text('email').notNull(),
-  createdAt: text('created_at')
-    .notNull()
-    .default(sql`(datetime('now'))`),
-});
-
 export const insertUserSchema = createInsertSchema(users, {
   name: (schema) => schema.min(1),
   email: (schema) => schema.email(),
@@ -315,20 +291,9 @@ export const insertUserSchema = createInsertSchema(users, {
 
 ```ts [Valibot]
 // db/schema.ts
-import { sqliteTable, text, integer } from 'void/schema-d1';
-import { sql } from 'void/db';
 import { createInsertSchema } from 'void/drizzle-valibot';
 import { pipe, minLength, email } from 'valibot';
 
-export const users = sqliteTable('users', {
-  id: integer('id').primaryKey({ autoIncrement: true }),
-  name: text('name').notNull(),
-  email: text('email').notNull(),
-  createdAt: text('created_at')
-    .notNull()
-    .default(sql`(datetime('now'))`),
-});
-
 export const insertUserSchema = createInsertSchema(users, {
   name: (schema) => pipe(schema, minLength(1)),
   email: (schema) => pipe(schema, email()),
@@ -337,20 +302,9 @@ export const insertUserSchema = createInsertSchema(users, {
 
 ```ts [ArkType]
 // db/schema.ts
-import { sqliteTable, text, integer } from 'void/schema-d1';
-import { sql } from 'void/db';
 import { createInsertSchema } from 'void/drizzle-arktype';
 import { type } from 'arktype';
 
-export const users = sqliteTable('users', {
-  id: integer('id').primaryKey({ autoIncrement: true }),
-  name: text('name').notNull(),
-  email: text('email').notNull(),
-  createdAt: text('created_at')
-    .notNull()
-    .default(sql`(datetime('now'))`),
-});
-
 export const insertUserSchema = createInsertSchema(users, {
   name: type('string > 0'),
   email: type('string.email'),
@@ -397,35 +351,29 @@ npm install arktype
 
 ## CLI Commands
 
-| Command            | Purpose                                                         |
-| ------------------ | --------------------------------------------------------------- |
-| `void db push`     | Apply schema directly to local database (no migration files)    |
-| `void db connect`  | Connect or provision PostgreSQL/MySQL and save `DATABASE_URL`   |
-| `void db generate` | Generate app and Better Auth SQL migrations for production      |
-| `void db migrate`  | Apply pending migrations locally                                |
-| `void db status`   | Show schema drift and pending migrations                        |
-| `void db reset`    | Drop the local DB and re-apply all migrations                   |
-| `void db seed`     | Reset + run seed file (`--file <path>`)                         |
-| `void db execute`  | Run ad-hoc SQL against local DB (`--file <path>`)               |
-| `void db studio`   | Open Drizzle Studio for the local database                      |
-| `void db export`   | Dump local DB as SQL (`--output`, `--no-data`, `--no-schema`)   |
-| `void db set-url`  | Update the PostgreSQL or MySQL connection string for deployment |
-
-See the [CLI reference](../reference/cli.md#database) for details.
+| Command            | Purpose                                              |
+| ------------------ | ---------------------------------------------------- |
+| `void db push`     | Apply schema changes locally without migration files |
+| `void db generate` | Generate SQL migrations                              |
+| `void db migrate`  | Apply pending migrations locally                     |
+| `void db status`   | Check schema drift and pending migrations            |
+| `void db seed`     | Reset the local database and run a seed file         |
+
+See the [CLI reference](../reference/cli/database.md#database) for connection setup, SQL execution, Studio, exports, and other commands.
 
 ## Scaffolding
 
 The `void gen model` command generates dialect-appropriate `sqliteTable`, `pgTable`, or `mysqlTable` definitions.
 
 ```bash
-void gen model post title:string body:text published:boolean
+void gen model posts title:string body:text published:boolean
 ```
 
 This creates:
 
-1. `db/schema/post.ts`: a Drizzle table definition with `id`, `createdAt`, `updatedAt`, and your columns
-2. Updates `db/schema.ts` with `export * from "./schema/post"`
+1. `db/schema/posts.ts`: a Drizzle table definition with `id`, `createdAt`, `updatedAt`, and your columns
+2. Updates `db/schema.ts` with `export * from "./schema/posts"`
 3. `routes/api/posts/index.ts`: `GET` for list and `POST` for insert with validation
 4. `routes/api/posts/[id].ts`: `GET` by id with `404` handling
 
-See the [CLI reference](../reference/cli.md#code-generation) for the full list of generators.
+See the [CLI reference](../reference/cli/generate.md#code-generation) for the full list of generators.

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

@@ -6,7 +6,7 @@ outline: deep
 
 `void deploy` builds your app, provisions its resources, applies migrations, and deploys it to your own Cloudflare account or a Void platform run by your team.
 
-Choose Cloudflare for your own account or Void for a shared team platform. You can [install a Void platform](./self-hosted-platform.md) in your team's Cloudflare account.
+You can [install a Void platform](./self-hosted-platform.md) for shared team deployments.
 
 ## Deployment Targets
 
@@ -51,21 +51,13 @@ Your choice is saved in `.void/project.json`, so the next deploy is just `void d
 
 Already have a Cloudflare Worker and a root `wrangler.jsonc` or `wrangler.json`? Run `void deploy`. If no destination is selected, Void offers to link and deploy using the existing Worker and resources. Accept once to keep deploying to that site. See [Deploy an existing Worker](../integrations/cloudflare.md#deploy-an-existing-worker) for the first-deployment checks.
 
-To connect to your team's platform and sign in, run `void connect <url>` using the URL from your administrator. Use `void connect --platform cloudflare` to set up your own Cloudflare account. Connecting preserves existing project links. New Void projects need a platform connection.
+To set up deployment later, use `void connect --platform cloudflare` or `void connect <platform-url>`.
 
 Owners can [share a platform project](./project-collaboration.md) with readers, collaborators, and project administrators. This does not apply to direct Cloudflare deployments.
 
 ### Migrations
 
-If your app uses Drizzle, `void deploy` runs migrations as part of the deploy flow:
-
-1. Build the app
-2. Read SQL migrations from `db/migrations/`
-3. Check that the migrations match your current schema
-4. Apply pending migrations to the target database
-5. Make the new deploy live
-
-If you've changed your schema without a matching migration, deploy stops. Run `void db generate`, review and commit the SQL, then deploy again. For the full database workflow and backend-specific details, see the [Database guide](./database.md).
+Deploy applies pending SQL migrations from `db/migrations/`. If your schema has changes without a migration, deploy stops. Run `void db generate`, review and commit the SQL, then deploy again. See the [Database guide](./database.md).
 
 ### Flags
 
@@ -117,131 +109,53 @@ If your platform supports managed GitHub builds, the Void GitHub App can build a
 
 You don't need a deployment workflow file or a repository `VOID_TOKEN` for this path.
 
-1. Initialize your Void project
-
-```bash
-void init
-# Or, for existing Void project:
-void project link
-```
-
-2. Install the Void GitHub app
+With a linked project, connect the repository:
 
-```bash
+```sh
 void github install
-```
-
-Void opens GitHub so you can install and authorize the `Void Deploy` app.
-
-In the browser, select the GitHub account/organization and grant access to the repository.
-
-:::details If someone already installed the App for your organization
-Join that installation instead:
-
-```bash
-void github join
-```
-
-:::
-
-3. Link your repository to your project
-
-```bash
 void github connect --executor container
-```
-
-Organization installations always require a browser proof for the specific repository, including for the person who installed the App. Void does not reveal the installation's full private repository list. If an upgraded platform marks an older organization connection as requiring reconnection, run the same `void github connect` command again to renew that repository-scoped authorization before builds resume.
-
-4. Verify the connection
-
-```bash
 void github status
 ```
 
-The output shows the repository, branch, and build executor:
+If your organization already installed the App, Void can join that installation during setup. Organization repositories require browser authorization.
 
-```bash
-Repository      <owner/repository>
-Branch          main
-Build executor  container
-Deploy workflow .github/workflows/void-deploy.yml (unused for container builds)
+Push to the configured branch to deploy, then follow progress with `void build logs --follow`. See [GitHub commands](../reference/cli/github.md#github) for installation sharing and connection options.
 
-```
+### GitHub Actions
 
-5. Push to the configured branch to trigger a new deploy
+Run `void init --github` to generate the workflow for your saved platform and package manager. On Void platforms with GitHub Actions support, authorize the repository once:
 
-```bash
-git push origin main
+```sh
+void github connect <project> --repo <owner/repo> --executor github_actions
 ```
 
-6. Follow the build
+Set the repository's `VOID_API_URL` variable to your platform's API URL. Keep `permissions: id-token: write` in the workflow for [GitHub OIDC](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect). The workflow uses your linked project, or the `VOID_PROJECT` repository variable.
 
-```bash
-void build logs --follow
-```
-
-### GitHub Actions
+Core self-hosted installations do not support this integration. Use your own CI workflow with a [project deploy token](./platform/installation/first-deployment.md).
 
-On platforms that support it, the generated workflow uses [GitHub OIDC](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect) to obtain a short-lived deploy token for your project. `void deploy` handles the exchange automatically. Keep `permissions: id-token: write` in the workflow so GitHub can issue that credential.
-
-The generated workflow uses the platform selected during `void init`. Core self-hosted installations don't yet support this integration, so Void doesn't offer the workflow for them. For a platform that does, the npm version looks like this; set the repository's `VOID_API_URL` variable to your platform's API URL:
-
-```yaml
-name: Deploy to Void
-on:
-  push:
-    branches: [main]
-
-# Latest push wins: a newer commit cancels an in-flight deploy for the same
-# repo + branch, so an older commit can never overtake a newer one.
-concurrency:
-  group: void-deploy-${{ github.repository }}-${{ github.ref }}
-  cancel-in-progress: true
-
-permissions:
-  id-token: write
-  contents: read
-
-env:
-  VOID_API_URL: ${{ vars.VOID_API_URL }}
-  VOID_PROJECT: my-app
-
-jobs:
-  deploy:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v6
-      - uses: actions/setup-node@v6
-        with:
-          node-version: lts/*
-          cache: npm
-      - run: npm ci
-      - name: Deploy
-        run: npx void deploy --platform void --project "$VOID_PROJECT"
-```
+## Other Targets
 
-Authorize the repository once with `void github connect <project> --repo <owner/repo> --executor github_actions`. Choose the `github_actions` executor for this workflow; `container` runs builds on the platform instead.
+### Your own Cloudflare account
 
-The generated workflow uses your package manager and linked project. If no project is linked, it reads the `VOID_PROJECT` repository variable.
+Select Cloudflare during setup, or run `void deploy --platform cloudflare`. See the [Cloudflare guide](../integrations/cloudflare.md) for configuration, CI credentials, and deployment limits.
 
-## Other Targets
+### Node.js, Bun, and Deno
 
-### Your own Cloudflare account
+Set [`target`](../reference/config.md#target) in `void.config.ts` to build a standalone server for Node.js, Bun, or Deno. You can run the result on your own server or in a container.
 
-Select Cloudflare during setup, or run:
+Deploy `dist/ssr` and `dist/client` together. See the target guide for startup commands.
 
-```sh
-void deploy --platform cloudflare
-```
+These targets don't provide Cloudflare bindings such as D1, KV, R2, and Workers AI. See the [Node.js, Bun, and Deno guide](../integrations/nodejs-bun-deno.md) for the features available on each target.
 
-Void supports full Worker apps, static sites, SPAs, and Cloudflare builds from supported frameworks. It provisions resources, applies migrations, and manages secrets for you. `.env` stays local; production server keys declared in `env.ts` must exist in encrypted remote secret storage and are rejected as plaintext Worker vars. Commands such as `void secret put`, `void project logs`, and `void project rollback` then use the same account and Worker.
+## Usage and execution limit pages
 
-See the [Cloudflare guide](../integrations/cloudflare.md#deploy-to-your-own-cloudflare-account) for supported features, CI setup, and deployment limits.
+Void platforms show a built-in page when an app exhausts its request allowance or an invocation exceeds its CPU limit. API requests and Pages action requests receive a structured HTTP 429 with `code: 'usage_limit'`, `resource`, `reason`, and `message`.
 
-### Node.js, Bun, and Deno
+To customize browser error pages, add either optional file to your app's public assets:
 
-Set [`target`](../reference/config.md#target) in `void.config.ts` to build a standalone server for Node.js, Bun, or Deno. You can run the result on your own server or in a container.
+- `public/usage-limit.html` for exhausted request allowances.
+- `public/execution-limit.html` for execution limits.
 
-Deploy `dist/ssr` and `dist/client` together. The server loads the Pages client manifest and assets relative to its emitted module; start it from the app root with `node dist/ssr/index.js`, `bun dist/ssr/index.js`, or `deno run -A dist/ssr/index.js`.
+Use standalone HTML with inline CSS and data-URL images. These pages run with scripts, external assets and form submissions disabled, so they remain usable while application requests are blocked. Void serves them directly from the deployed assets; your Worker, loaders and database are not involved. A missing or unreadable custom page uses the built-in page.
 
-These targets don't provide Cloudflare bindings such as D1, KV, R2, and Workers AI. See the [Node.js, Bun, and Deno guide](../integrations/nodejs-bun-deno.md) for the features available on each target.
+Responses are not cached. Once a streaming response has started, it cannot be replaced with an error page; clients should display stream failures and end their pending state. These platform pages apply to Void platform deployments. Direct Cloudflare runtime limits use Cloudflare's own response behavior.

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

@@ -6,9 +6,9 @@ outline: deep
 
 Use a Durable Object when requests need to share state under one name, such as a shopping cart, room, or rate limiter. Void gives you typed methods and stores the object's state between calls.
 
-Void turns each module in `durable-objects/` into a SQLite-backed Cloudflare Durable Object. The filename determines the binding, Worker class, and initial Cloudflare migration, so no manual Cloudflare configuration is needed.
+Create a module in `durable-objects/` with `defineDurableState()`. Void provides a SQLite-backed Cloudflare Durable Object for it. This feature supports native Void apps deployed directly to Cloudflare.
 
-Void records the inferred binding and migration entry in `void.lock.json`. Commit that file: Cloudflare Durable Object migrations are append-only, and the persisted order ensures a newly added module is migrated after every class already deployed.
+Commit `void.lock.json` when Void adds a resource. Keep its deployed migration entries in their original order.
 
 ## Define state and methods
 
@@ -32,21 +32,11 @@ export const Counter = defineDurableState({
 export default Counter;
 ```
 
-The default export must be the object returned by `defineDurableState()`. Void uses it to export the generated Cloudflare class and associate the inferred binding at worker startup.
-
-For `counter.ts`, Void generates:
-
-| Resource                 | Generated name            |
-| ------------------------ | ------------------------- |
-| Binding                  | `COUNTER`                 |
-| Worker class             | `CounterDurableObject`    |
-| Cloudflare migration tag | `void-durable-counter-v1` |
-
-Names are derived from kebab-case filenames: `shopping-cart.ts` becomes `SHOPPING_CART` and `ShoppingCartDurableObject`.
+Default-export the object returned by `defineDurableState()`.
 
 ## Call it from a route
 
-Import the same named definition and select an object by name. Calls are typed from the method definitions, including arguments and return values.
+Import your definition and call `get()` with a name to select an object. Method arguments and return values are typed:
 
 ```ts
 // routes/api/counter.ts
@@ -64,8 +54,6 @@ The same name always resolves to the same Durable Object. Use `getById(id)` when
 
 ## Execution and persistence
 
-Typed methods run through Cloudflare RPC on the generated Durable Object class. Only your declared methods are exposed; Void’s state-loading and persistence helpers stay private.
-
 Void loads state before the first operation and runs RPC methods one at a time. After a method, `fetch`, or `alarm` handler succeeds, it saves the updated state.
 
 If the handler or save fails, Void restores `context.state` to its previous value. Direct writes to `context.storage` aren't included in that rollback.
@@ -127,14 +115,51 @@ export const Counter = defineDurableState({
 export default Counter;
 ```
 
-These state migrations are separate from Cloudflare's Durable Object class migration. Void generates the latter with `new_sqlite_classes` when it discovers the file.
+State migrations update your saved values. Void manages Cloudflare’s separate class migrations in `void.lock.json`.
 
 Do not delete or reorder generated Durable Object migrations in `void.lock.json` after deployment. For a class addition, rename, or removal on an existing Worker, review the migration and run `void deploy --platform cloudflare --atomic`. If this Worker needs atomic publication on every deploy, set `deploy: { cloudflare: { mode: 'atomic' } }` in `void.config.ts`. Cloudflare applies class lifecycle changes in one deployment. The Worker receives traffic before Void checks readiness, and you cannot roll back across that migration boundary. Staged deploys keep pre-traffic readiness verification.
 
+## Rename a file while keeping its state
+
+Before renaming a deployed definition, run:
+
+```sh
+void info
+```
+
+For `durable-objects/counter.ts`, Void prints:
+
+```text
+To preserve this resource when moving its code, add this to 'defineDurableState':
+  name: "counter",
+```
+
+Add that property to the existing definition:
+
+```ts
+export const Counter = defineDurableState({
+  name: 'counter',
+  initialState: { count: 0 },
+  methods: {
+    read(context) {
+      return context.state.count;
+    },
+  },
+});
+
+export default Counter;
+```
+
+Rename the file within `durable-objects/`, update its imports, and deploy. Keep `name: 'counter'` and the names passed to `Counter.get()` unchanged to preserve the stored state.
+
+`name` is optional. Use a static string, either inline or in a local `const`, containing words that start with a letter, such as `'shopping-cart'`. Names must produce distinct Worker classes and bindings. Changing an existing resource's `name` selects a different resource.
+
+If you already moved the file, `void info` also shows resources recorded in `void.lock.json` without a matching definition. Identify the original resource and use its suggested name. If no name can be suggested, restore the original file from source history and run `void info` before moving it again. Keep the existing lock and migration history.
+
 ## Deployment support
 
 Typed state works in local development and direct Cloudflare deploys of native Void apps. Deploy with `void deploy --platform cloudflare`.
 
-Deploying custom Durable Object modules to a Void platform isn't supported yet. `void deploy --platform void` stops before building and points you to the Cloudflare path. Meta-frameworks and Node.js, Bun, and Deno targets also reject `durable-objects/` with guidance.
+Custom Durable Object modules are not supported on Void platforms, in meta-frameworks, or on Node.js, Bun, and Deno.
 
 This is separate from [typed WebSocket routes](./websockets.md), which also use SQLite-backed Durable Objects and work on both direct Cloudflare and hosted Void deployments.

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

@@ -25,44 +25,13 @@ Define custom response headers in [`void.config.ts`](../../reference/config) usi
 - All matching rules are merged. When multiple rules set the same header name, the **last match wins**.
 - User-defined `Cache-Control` overrides the built-in default. The default still applies when no rule matches.
 
-## Example: security headers
-
-```json
-{
-  "routing": {
-    "headers": {
-      "/*": [
-        "X-Frame-Options: DENY",
-        "X-Content-Type-Options: nosniff",
-        "Referrer-Policy: strict-origin-when-cross-origin"
-      ]
-    }
-  }
-}
-```
-
-## Example: override caching
-
-```json
-{
-  "routing": {
-    "headers": {
-      "/*.html": ["Cache-Control: public, max-age=300"],
-      "/config.json": ["Cache-Control: no-store"]
-    }
-  }
-}
-```
-
 ## Scope
 
-The dispatch Worker applies header rules to static assets, SSR pages, and API responses, including hashed assets served from cache. For example, you can add the cross-origin headers a page needs for Worker or WebAssembly files.
+Header rules apply to static assets, SSR pages, and API responses, including hashed assets served from cache.
 
 For hashed assets, you can add headers, but the platform keeps control of caching and response encoding. Rules cannot replace `Cache-Control`, `Content-Type`, `Content-Encoding`, `Content-Length`, `Content-Range`, `Accept-Ranges`, or `Transfer-Encoding` on these files.
 
-Header rules do not apply to:
-
-- ISR cache responses (these have their own cache-control headers)
+Header rules do not apply to ISR cache responses.
 
 ### Blocked headers
 
@@ -70,17 +39,4 @@ Header rules do not apply to:
 
 ## Framework `_headers` files
 
-Meta-frameworks like SvelteKit, Nuxt, and Astro generate a `_headers` file with cache rules for their hashed asset directories. Void automatically parses this file during deploy and merges the rules into the deploy manifest.
-
-- Framework-generated rules are applied **before** `void.config.ts` rules. Since the last match wins, `routing.headers` in `void.config.ts` takes precedence and can override framework defaults.
-- The `_headers` file is not uploaded as a static asset. Its contents are parsed and included in the manifest only.
-
-No configuration is needed. If the framework generates a `_headers` file, it is picked up automatically.
-
-## How headers work
-
-1. `void deploy` reads header rules from the framework `_headers` file (if present) and `routing.headers` in `void.config.ts`, then includes them in the deploy manifest.
-2. The platform stores the rules in the KV routing entry for your project.
-3. The dispatch Worker adds matching headers before returning a response. Most cached responses include those headers. Hashed assets get header rules on each response, including cache hits, so a rule change takes effect without changing the file.
-
-Headers are applied at the edge as part of serving the response; no separate network request is needed.
+Void reads `_headers` files produced by supported frameworks. Your `routing.headers` rules run afterward, so they can override framework defaults. No additional setup is needed.