void 0.22.0 → 0.23.0

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

@@ -0,0 +1,88 @@
+---
+outline: deep
+---
+
+# Connections and Authentication {#connect}
+
+```sh
+void connect
+void connect https://platform.example.com
+void connect --platform cloudflare
+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 `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 checks the connection and signs you in through your browser when needed. It saves credentials in your system keychain separately for each platform.
+
+The deployment preference is saved in `.void/project.json`. Connecting to another Void platform preserves an existing project link; the CLI explains when that link or an environment override still selects a different destination. Use `void project link` to explicitly choose a project. Cloudflare selection also retains existing Void project metadata so you can switch back later.
+
+In a non-interactive shell, supply a URL or explicit target. Cloudflare requires usable credentials and an unambiguous account (`CLOUDFLARE_ACCOUNT_ID` when needed). For a Void platform, provide `VOID_TOKEN` with a matching `VOID_API_URL`, or reuse a valid origin-scoped keychain session. Use `void connect <url> --no-login` to save the verified connection without authenticating; this option is only available for Void platforms.
+
+## Authentication {#authentication}
+
+`void auth login`, `void auth status`, and `void auth logout` use the destination
+saved for the current project by `void init` or `void connect`. If no destination
+is saved, interactive commands let you choose Cloudflare or a connected Void
+platform. In a non-interactive shell, pass `--platform cloudflare|void` or use
+the explicit `void cloudflare` and `void account` commands. Choosing a destination
+for authentication does not change the project's deploy target.
+
+`void auth whoami`, `void auth link`, and `void auth token` remain supported for
+existing scripts. `whoami` follows the selected destination; `link` and `token`
+are Void account operations. Prefer `void auth status`, `void account link`, and
+`void account token` in new scripts.
+
+## Void platform account {#void-platform-account}
+
+### `void account login` {#void-account-login}
+
+Browser login through one of the platform's currently enabled methods. The token is saved in the operating-system keychain, scoped to the platform origin. Login fails closed when no keychain is available instead of writing the token to a plaintext file; headless environments use `VOID_TOKEN` from their secret manager.
+
+If an older CLI login is no longer recognized after updating Void, run `void account login` again. Your saved platform and project links remain unchanged.
+
+Set `VOID_API_URL` alongside `VOID_TOKEN` to identify the platform that issued it.
+A token without an API URL is only used for Void Cloud's production API; a saved
+connection or project cannot forward it to another platform. To use a platform's
+saved login instead, unset `VOID_TOKEN`.
+
+This is optional if you already completed auth during `void connect` or the interactive `void init` flow.
+
+### `void account link [connection-id]` {#void-account-link-connection-id}
+
+Link another enabled login method to your current account. Sign in again if your
+session is no longer recent, complete the additional provider's browser login,
+and confirm the displayed identity. With no connection ID, choose an enabled
+method interactively. The optional dashboard exposes the same flow in **Account**.
+
+### `void account logout` {#void-account-logout}
+
+Removes saved credentials.
+
+### `void account whoami` {#void-account-whoami}
+
+Prints your current login.
+
+### `void account token` {#void-account-token}
+
+Copies your human auth token to the system clipboard. It is intended for
+interactive troubleshooting and remains subject to login-method revocation. Do
+not combine it with a Cloudflare Access service token for CI; machine Access
+proof cannot turn a human Void token into an automation identity. Create a
+project-scoped credential with `void project token create` instead.
+
+## Cloudflare authentication {#cloudflare-authentication}
+
+Use Void's Cloudflare commands to sign in and manage credentials. No separate Cloudflare CLI is needed. Browser credentials are encrypted and protected by your system keychain.
+
+- `void cloudflare login` — sign in through your browser or switch Cloudflare users.
+- `void cloudflare status` — show your identity, credential source, accessible accounts, and deployment account.
+- `void cloudflare logout` — remove the local browser session.
+
+Interactive `void connect --platform cloudflare`, `void init`, and `void deploy --platform cloudflare` invoke the same login flow automatically when necessary. Non-interactive CI must set `CLOUDFLARE_API_TOKEN`.
+
+Signing in changes the browser session, not `account_id` in the project configuration. Check `void cloudflare status` after switching users; if the new user cannot access the pinned account, resolve the project target separately before deploying.
+
+An API token or global API key pair in the environment takes precedence over browser credentials. Explicit browser login stops with the names of these overrides; remove them from that shell before signing in. `status` reports the active credential source, and `logout` warns if environment credentials remain active. Explicit browser login requires an interactive terminal; automatic deployment checks continue to reuse valid sessions.

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

@@ -0,0 +1,128 @@
+---
+outline: deep
+---
+
+# Database {#database}
+
+## `void db push` {#void-db-push}
+
+Apply your Drizzle schema directly to the development database without creating migration files. D1 updates the local database; PostgreSQL and MySQL use `DATABASE_URL` from `.env`.
+
+Use this for quick schema iteration while prototyping. Before deploying, generate and review migration files with `void db generate`.
+
+## `void db generate` {#void-db-generate}
+
+Generate SQL migration files from schema changes.
+
+Compares your schema with the last Drizzle snapshot and writes migrations under `db/migrations/`. It includes Void-managed auth tables and configured auth plugins, even without an application schema. Review and commit the generated files before deploying.
+
+For SQLite, Void checks that the migration history applies to a fresh database. If generation fails this check, the previous SQL, snapshots, and journal are restored. If an existing migration fails, repair that unapplied migration first: rerunning generation compares snapshots and does not repair existing SQL. This check does not verify that a migration preserves existing data; review table rebuilds and foreign-key actions carefully.
+
+## `void db status` {#void-db-status}
+
+Show migration status. Displays which migrations are applied or pending locally, then uses the saved deployment target for remote status: the hosted API for Void projects, the pinned D1 database and its configured migration table for direct Cloudflare SQLite projects, or the shell `DATABASE_URL` for direct Cloudflare PostgreSQL/MySQL projects. If the remote credential or service is unavailable, local status is still shown.
+
+## `void db reset` {#void-db-reset}
+
+Drop the local D1 database and re-apply all migrations. Does not affect the remote database.
+
+## `void db seed` {#void-db-seed}
+
+```
+void db seed [--file <path>]
+```
+
+Reset the local database, re-apply all migrations, then execute a seed file.
+
+If `--file` is omitted, Void looks for default seed files in this order: `db/seed.ts`, `db/seed.mts`, `db/seed.js`, `db/seed.mjs`, `db/seed.sql`.
+
+If more than one default seed file exists, the CLI stops and asks you to pass `--file <path>`.
+
+Programmatic seed modules must export either a default function or a named `seed` function.
+
+## `void db execute` {#void-db-execute}
+
+```
+void db execute <sql>
+void db execute --file <path>
+void db execute --remote <sql>
+```
+
+Run ad-hoc SQL against the database. Provide SQL inline or from a file. SELECT queries display results as a formatted table; other statements execute silently.
+
+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 `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.
+
+For destructive statements (`DELETE`, `UPDATE`, `DROP`, etc.) when running in a TTY, you will be prompted to confirm before the query is sent to the deployed database. Non-TTY environments (CI) skip the prompt.
+
+## `void db migrate` {#void-db-migrate}
+
+```
+void db migrate [--remote]
+```
+
+Apply pending migrations to the local database without resetting. Unlike `void db reset`, this preserves existing data and only runs migrations that haven't been applied yet.
+
+Pass `--remote` to apply pending migrations to the saved target. Hosted projects require a Void login and link. Direct Cloudflare D1 projects use the binding's configured migration directory, table, and pattern; direct PostgreSQL and MySQL projects use the shell `DATABASE_URL`.
+
+## `void db studio` {#void-db-studio}
+
+```
+void db studio [--remote]
+```
+
+Open [Drizzle Studio](https://orm.drizzle.team/docs/drizzle-kit-studio) for the database. Launches a web-based GUI for browsing and editing your data.
+
+By default, targets the local database. Pass `--remote` to open Studio against the deployed database:
+
+- **PostgreSQL and MySQL projects**: fetch the stored connection string from the platform and open Studio against it. If the URL isn't stored yet, run `void db set-url` first.
+- **D1 projects**: remote Studio is not yet supported. Use `void db execute --remote` for ad-hoc queries against your deployed D1 database.
+
+On direct Cloudflare PostgreSQL/MySQL targets, remote Studio uses `DATABASE_URL` from the current shell. Direct D1 Studio remains unsupported; use `void db execute --remote`.
+
+## `void db rename-migrations` {#void-db-rename-migrations}
+
+Rename existing migrations from the old numeric prefix format (`0001_name.sql`) to timestamp-based format (`20260410161500_name.sql`). Updates local tracking table and remote records if logged in with a linked project.
+
+## `void db connect` {#void-db-connect}
+
+Connect an existing PostgreSQL/MySQL database or provision one through an adapter:
+
+```sh
+void db connect 'postgresql://user:password@host/database'
+NEON_API_KEY=... void db connect --provider neon --name my-app
+void db connect --provider @acme/void-db-provider --region region-id
+```
+
+The command saves `DATABASE_URL` in `.env`. When authenticated with a linked Void project, it also updates the encrypted deployment URL; pass `--local-only` to skip that sync. `neon` is built in. Other adapters are project dependencies or local modules exporting a `DatabaseProviderAdapter` from `void/database-provider`.
+
+Provider-created credentials are never printed. For direct Cloudflare deploys, configure the same URL as a protected `DATABASE_URL` in the shell or CI environment that runs deploy.
+
+## `void db set-url` {#void-db-set-url}
+
+Update the PostgreSQL or MySQL connection string for deployment. Available for projects with `"database": "pg"` or `"database": "mysql"`.
+
+Prompts for a connection string and sends it to the platform API to create or update the Hyperdrive configuration.
+
+## `void db export` {#void-db-export}
+
+```
+void db export [--output <path>] [--no-data] [--no-schema] [--table <name>]
+```
+
+Dump the local database as SQL. Outputs to stdout by default (pipeable), or to a file with `--output`.
+
+Data exports preserve SQLite AUTOINCREMENT and PostgreSQL SERIAL and identity counters, including IDs consumed by deleted rows. SQLite schema exports include indexes, views, and triggers. PostgreSQL schema exports preserve column types, generated columns, identity definitions, serial sequences, constraints, and indexes. `--no-schema` restores counter values into an existing schema; `--no-data` starts counters at their schema-defined starting values.
+
+For PostgreSQL schemas with views, triggers, custom types, functions, or standalone sequences, use `pg_dump` for a complete backup. `void db export` reports these objects before writing a schema dump.
+
+| Flag              | Purpose                            |
+| ----------------- | ---------------------------------- |
+| `--output <path>` | Write to a file instead of stdout  |
+| `--no-data`       | Schema only (no INSERT statements) |
+| `--no-schema`     | Data only (no CREATE TABLE)        |
+| `--table <name>`  | Export a single table              |

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

@@ -0,0 +1,85 @@
+---
+outline: deep
+---
+
+# Deployment {#deploy}
+
+## `void deploy` {#void-deploy}
+
+```
+void deploy [--project <name>] [--dir <path>] [--spa] [--skip-build] [--debug]
+void deploy [--platform <cloudflare|void>] [--require-email]
+void deploy --platform cloudflare --atomic
+```
+
+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.
+
+On an upgraded Void platform, an accepted deployment continues if the CLI disconnects. The CLI automatically reconnects to its progress. Pressing Ctrl+C stops observation; use `void project cancel` to request cancellation and `void project status` to inspect the result. If interrupted execution requires recovery, wait for its result before deploying again.
+
+For an existing Void Worker, `void deploy` can link the Worker and migrate its root Cloudflare config. Keep the first deployment focused on the existing app. See [Deploy an existing Worker](../../integrations/cloudflare.md#deploy-an-existing-worker) for requirements and the ISR cache choice.
+
+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`.
+
+| Flag                            | Purpose                                                                                            |
+| ------------------------------- | -------------------------------------------------------------------------------------------------- |
+| `--platform <cloudflare\|void>` | Override the platform stored in `.void/project.json`                                               |
+| `--project <name>`              | Target a specific Void project by slug; not supported with `--platform cloudflare`                 |
+| `--dir <path>`                  | Deploy a pre-built static directory (skips build)                                                  |
+| `--spa`                         | Use SPA mode instead of SSG for static deploys                                                     |
+| `--skip-build`                  | Skip the build step; on Cloudflare this is supported for static/SPA/SSG deploys only               |
+| `--require-email`               | Fail when email cannot be set up instead of deploying without it; requires `--platform cloudflare` |
+| `--atomic`                      | Publish an existing Durable Object Worker directly; readiness is checked after traffic changes     |
+| `--debug`                       | Mirror the structured deploy log to stderr (also written to `~/.void/logs/`)                       |
+
+`--atomic` applies to one deployment. For an existing Durable Object Worker that consistently cannot stage, set `deploy: { cloudflare: { mode: 'atomic' } }` in `void.config.ts` so plain `void deploy` uses atomic publication. The default is `staged`.
+
+Every deploy writes a JSONL log to `~/.void/logs/`. Failures print the log path and relevant details. Use `--debug` or `VOID_DEPLOY_DEBUG=1` to mirror it to stderr.
+
+Keep credentials out of build commands and register them as CI secrets so your CI provider can mask them in logs.
+
+Platform resolution precedence:
+
+1. `--platform <cloudflare|void>`
+2. `platform` in `.void/project.json`
+3. Void for projects initialized by an older SDK without a saved platform
+
+Selecting Skip deployment setup stores `"platform": "none"`; a later `void deploy` stops with guidance until a platform override is provided.
+
+For the Void platform, project resolution precedence is:
+
+1. `--project <name>`
+2. `VOID_PROJECT`
+3. linked project in `.void/project.json`
+
+If no project is linked and no override is provided, CLI prompts to link or create one. In CI (non-TTY), `void deploy` errors out instead — set `VOID_PROJECT` or pass `--project <slug>`.
+
+## `void deploy --platform cloudflare` {#void-deploy-platform-cloudflare}
+
+Build and deploy to your Cloudflare account using `void.config.ts`:
+
+```sh
+void deploy --platform cloudflare
+void deploy --platform cloudflare --require-email   # fail instead of deploying without email
+```
+
+Void signs you in through your browser when needed and saves the selected account. In CI, set `CLOUDFLARE_API_TOKEN` and, if the token can access several accounts, `CLOUDFLARE_ACCOUNT_ID`.
+
+| Option or setting              | Cloudflare behavior                                                                    |
+| ------------------------------ | -------------------------------------------------------------------------------------- |
+| `--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 `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 access to products Void provisions. Commit `void.lock.json` after the first deploy before using other machines or CI.
+
+Use `void secret put <NAME>` for production server values. Local `.env` values are never deployed. Run `void db generate` and commit schema changes before deploying.
+
+Sandbox requires [Workers Paid](https://dash.cloudflare.com/?to=/:account/workers/plans), Docker, and Containers access. API tokens need Account / Containers: Edit and Account / Cloudchamber: Edit.
+
+For email, set `email.from` and run `void email setup --platform cloudflare` locally. Commit the lock file and pass `--require-email` in CI. See [Email setup](../../guide/email/domains.md#your-own-cloudflare-account).
+
+For Access credentials, Hyperdrive permissions, readiness, and rollback, see [Cloudflare deployment](../../integrations/cloudflare.md#deploy-to-your-own-cloudflare-account).

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

@@ -0,0 +1,41 @@
+---
+outline: deep
+---
+
+# Custom Domains {#custom-domains}
+
+## `void domain add` {#void-domain-add}
+
+```
+void domain add <hostname> [--project <name>]
+```
+
+Add a custom domain to the saved target. Hosted Void projects print the DNS records needed for SaaS hostname validation. Direct Cloudflare projects add a `custom_domain` route and immediately synchronize only the route configuration, leaving cron, queue, and workflow triggers unchanged; Cloudflare manages the DNS record and TLS certificate in a zone on the pinned account. Convert a legacy singular `route` field to a `routes` array first so adding the domain cannot shadow the existing route.
+
+> Wildcard custom hostnames (`*.example.com`) are not supported — register each subdomain individually.
+
+## `void domain delete` {#void-domain-delete}
+
+```
+void domain delete <hostname> [--project <name>]
+```
+
+Direct Cloudflare projects apply the change immediately. Deleting the final custom domain uses your browser session from `void cloudflare login` or an API token with Workers Scripts: Edit permission. If Cloudflare rejects the change, Void attempts to restore the previous domain configuration and reports whether recovery succeeded.
+
+## `void domain list` {#void-domain-list}
+
+```
+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 `void.config.ts`.
+
+## `void domain status` {#void-domain-status}
+
+```
+void domain status <hostname> [--project <name>] [--verbose]
+```
+
+Show domain verification and TLS certificate status, including DNS records to configure and any required action. Domains activate automatically once verification and certificate issuance finish.
+
+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.

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

@@ -0,0 +1,129 @@
+---
+outline: deep
+---
+
+# Email {#email}
+
+Inspect email usage and manage the recipients a project is allowed to send to. See [Email](../../guide/email.md) for the runtime API.
+
+Project resolution for email commands follows the same order as deploy (`--project`, `VOID_PROJECT`, linked project). `void email setup` and `void email status --platform cloudflare` are the exception: they act on your own Cloudflare account through your Cloudflare sign-in (`void cloudflare login`) and need no Void project.
+
+## `void email usage` {#void-email-usage}
+
+```
+void email usage [--project <name>]
+```
+
+Show the current month's recipient attempts and inbound receipts, the monthly attempt limit, and how much of it is left. Reserved submissions count toward the limit; started attempts remain charged even if delivery fails or its outcome is unknown. A suspended project is flagged in the output.
+
+## `void email logs` {#void-email-logs}
+
+```
+void email logs [--limit <n>] [--project <name>]
+```
+
+Show recent email operation metadata retained for 30 days: timestamp, direction, operation ID, recipient, and state. `--limit` accepts 1–100. Subjects, bodies, and attachments are not stored. Provider acceptance does not confirm mailbox delivery; inspect unknown outcomes before retrying.
+
+## `void email destinations` {#void-email-destinations}
+
+```
+void email destinations [--project <name>]
+```
+
+List the project's recipient addresses and their state (`verified`, `pending`, or `failed`). Outbound mail is only delivered to verified addresses.
+
+## `void email allow` {#void-email-allow}
+
+```
+void email allow <address> [--project <name>]
+```
+
+Add one recipient to the project's destination list. Cloudflare emails that address a verification link — the recipient clicks it, with no Void or Cloudflare account required. Then run `void email destinations`: the listing is what records the click, and until it has, a send to that address returns `UNVERIFIED_DESTINATION` for that recipient. If the link did not arrive or has expired, run `void email allow <address>` again while the address is still pending — the CLI re-sends the link, or tells you how to get a fresh one.
+
+The project owner's email is added automatically when the project is created, so it skips this step but not the verification: unless Cloudflare already had it verified for an earlier project of yours, click the link it mailed and run `void email destinations`; until then a send to yourself returns `UNVERIFIED_DESTINATION` for that recipient.
+
+## `void email disallow` {#void-email-disallow}
+
+```
+void email disallow <address> [--project <name>]
+```
+
+Remove one recipient from the project's destination list. New sends to that address are refused immediately; previously admitted attempts may finish. No deploy is involved.
+
+## `void email domain` {#void-email-domain}
+
+```
+void email domain <add|status|list|sync|rotate-secret|remove> [<domain>] [--project <name>]
+```
+
+Send and receive at your own domain on a Cloudflare zone you own, registered to the project. Void platform only — on your own Cloudflare account the mail domain comes from `email.from` instead (see `void email setup`). The walkthrough is [Your own domain on the platform](../../guide/email/domains.md#your-own-domain-on-the-platform).
+
+### `void email domain add` {#void-email-domain-add}
+
+```
+void email domain add <domain> [--project <name>]
+```
+
+Register an exact domain with the project using a scoped Cloudflare API token. The CLI opens a token template, accepts a masked paste or newly copied token, and asks you to confirm account and zone restrictions. Credentials are encrypted for the zone connection. Custom inbound email requires a Cloudflare zone apex because its catch-all does not cover subdomains. Foreign MX records and catch-alls are preserved; use another zone apex or the platform shared mail address when the apex already receives mail. Each custom apex belongs to one project. Setup returns an operation ID so an interrupted request can be checked without restarting the operation.
+
+### `void email domain status` {#void-email-domain-status}
+
+```
+void email domain status <domain> [--project <name>]
+```
+
+Show the recorded inbound, outbound, and management readiness, observation times, and latest operation. Use `sync` to reconcile setup and refresh readiness.
+
+### `void email domain list` {#void-email-domain-list}
+
+```
+void email domain list [--project <name>]
+```
+
+List the project's registered email domains and readiness.
+
+### `void email domain sync` {#void-email-domain-sync}
+
+```
+void email domain sync <domain> [--project <name>]
+```
+
+Reconcile the domain connection and refresh readiness. Sync does not rotate its secret. A blocked or uncertain operation exits unsuccessfully and names the operation to inspect.
+
+### `void email domain rotate-secret` {#void-email-domain-rotate-secret}
+
+```sh
+void email domain rotate-secret <domain> [--project <name>]
+```
+
+Rotate the connection secret shared by this domain and other domains on the same zone. Inbound delivery must be ready; run `void email domain sync <domain>` first if setup is incomplete. Inspect an uncertain result before retrying.
+
+### `void email domain remove` {#void-email-domain-remove}
+
+```
+void email domain remove <domain> [--project <name>]
+```
+
+Disable the domain assignment and record cleanup. Zone resources used by another domain remain available. Unfinished or uncertain cleanup remains recorded until it can be reconciled safely.
+
+## `void email status` {#void-email-status}
+
+```
+void email status --platform cloudflare
+```
+
+Check the domain configured in `email.from`: permissions, DNS, routing, sending, handler addresses, and the email binding. Exits unsuccessfully when setup is incomplete. Workers Free setup can be ready with sending limited to verified destinations; run `void email setup --platform cloudflare` after upgrading to Workers Paid.
+
+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`.
+
+## `void email setup` {#void-email-setup}
+
+```
+void email setup --platform cloudflare
+```
+
+Set up email before deploying from CI. Requires `email.from` in `void.config.ts`, an interactive terminal, and Cloudflare email permissions.
+
+Void shows the planned DNS, routing, plus-addressing, and sending changes and asks before applying them. Commit `void.lock.json`, then run `void deploy --platform cloudflare --require-email` in CI.
+
+On Workers Free, inbound mail and sends to verified recipients remain available. Run this command again after upgrading to Workers Paid to enable arbitrary recipients. See [Email setup](../../guide/email/domains.md#your-own-cloudflare-account).

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

@@ -0,0 +1,116 @@
+---
+outline: deep
+---
+
+# Code Generation {#code-generation}
+
+## `void gen model` {#void-gen-model}
+
+```
+void gen model <name> [columns...]
+```
+
+Scaffold a Drizzle table, list and create routes, and a route to fetch one row by ID.
+
+```sh
+void gen model posts title:string body:text published:boolean
+```
+
+Creates:
+
+- `db/schema/posts.ts`: a table with `id`, `createdAt`, `updatedAt`, and your columns
+- An export from `db/schema.ts`
+- `routes/api/posts/index.ts`: `GET` for list and `POST` for insert with validation
+- `routes/api/posts/[id].ts`: `GET` by id with `404` handling
+- Regenerated `.void/db.d.ts`
+
+The generated routes automatically detect your validation library from `package.json` (`valibot`, `zod`, or `arktype`). If none is found, you will be prompted to choose one or skip validation. Run `void db push` to apply the schema locally, or `void db generate` to create migrations before deploying.
+
+Column format: `name:type` or `name:type?` (nullable). Types: `string`, `text`, `datetime`, `integer`, `boolean`, `real`, `blob`.
+
+Model names must be lowercase alphanumeric with underscores (e.g. `posts`, `user_roles`). Existing files are never overwritten.
+
+## `void gen migration` {#void-gen-migration}
+
+```
+void gen migration <name>
+```
+
+Create an empty migration file with a timestamp prefix (`YYYYMMDDHHMMSS`).
+
+```sh
+void gen migration add_avatar_to_users
+# → db/migrations/20260410161500_add_avatar_to_users.sql
+```
+
+Existing projects using the old numeric prefix (`0001_`, `0002_`, ...) can rename with `void db rename-migrations`.
+
+## `void gen route` {#void-gen-route}
+
+```
+void gen route <path> [--methods get,post,...]
+```
+
+Create a route file with `defineHandler` exports. Defaults to GET.
+
+```sh
+void gen route api/health
+void gen route api/users --methods get,post,delete
+```
+
+Creates `routes/<path>.ts` with an exported handler for each method. Supported methods: `get`, `post`, `put`, `patch`, `delete`.
+
+## `void gen middleware` {#void-gen-middleware}
+
+```
+void gen middleware <name>
+```
+
+Create a numbered middleware file with `defineMiddleware` default export.
+
+```sh
+void gen middleware auth
+# → middleware/01.auth.ts (or 02, 03, etc.)
+```
+
+The prefix is auto-detected from existing middleware files.
+
+## `void gen ssr` {#void-gen-ssr}
+
+```
+void gen ssr [--react | --vue | --svelte | --solid]
+```
+
+Scaffold SSR entry points and a minimal App component for your framework.
+
+Creates three files:
+
+- `src/main.ssr.{tsx,ts}`: server entry with `defineRender`
+- `src/main.client.{tsx,ts}`: client entry with hydration
+- `src/App.{tsx,vue,svelte}`: minimal interactive component
+
+If no flag is provided, the framework is auto-detected from `package.json` dependencies.
+
+## `void gen cron` {#void-gen-cron}
+
+```
+void gen cron <name>
+```
+
+Create a cron job file in `crons/` with `defineScheduled` and a placeholder cron expression.
+
+```sh
+void gen cron hourly-sync
+```
+
+## `void gen queue` {#void-gen-queue}
+
+```
+void gen queue <name>
+```
+
+Create a queue consumer file in `queues/` with `defineQueue`, a `Message` interface, and commented-out batch options.
+
+```sh
+void gen queue emails
+```