void 0.10.10 → 0.10.12

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

@@ -73,6 +73,48 @@ At the edge, the resolution order is:
 
 **Deploy:** `void deploy` or `void deploy --dir <path>` uploads static files directly. Assets are served from the edge with automatic caching.
 
+## Adding a backend to a static site
+
+A static site generator plus a few API routes is a Void app, not a static site. Auto-detection sees the SSG dependency first (priority 2 below), so if you leave `inference.appType` unset, `void deploy` refuses rather than deploying the site and silently dropping `routes/`. Tell it which you meant.
+
+To deploy the site **and** the backend, run both builds from one command and let Void's build fold the generated site into its client output:
+
+```json
+// void.json
+{
+  "inference": {
+    "appType": "void",
+    "build": "vitepress build && vite build"
+  }
+}
+```
+
+```ts
+// vite.config.ts
+import { defineConfig } from 'vite';
+import { voidPlugin } from 'void';
+
+export default defineConfig({
+  plugins: [voidPlugin()],
+  // The SSG's output becomes the static assets of the Void build.
+  publicDir: '.vitepress/dist',
+});
+```
+
+`vitepress build` emits the site, then `vite build` copies `publicDir` into `dist/client` and emits the worker into `dist/ssr`. Keep `voidPlugin()` in the **root** `vite.config.ts` only — not in the generator's own config (e.g. `.vitepress/config.ts`).
+
+Because the worker now owns unmatched requests, add [`routing.notFound`](../reference/config.md#routing-notfound) if you want the generator's `404.html` instead of the SPA-style `index.html` fallback:
+
+```json
+{ "routing": { "notFound": "404-page" } }
+```
+
+To deploy the static output only and **not** the backend, say so explicitly:
+
+```json
+{ "inference": { "appType": "static" } }
+```
+
 ## Auto-Detection
 
 When running `void deploy` and no `inference.appType` is set in `void.json`, the detection logic runs in this order:
@@ -81,6 +123,7 @@ When running `void deploy` and no `inference.appType` is set in `void.json`, the
 | -------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------- |
 | 1        | `--dir` flag                                                                                                    | Static (or SPA with `--spa`)                |
 | 2        | Known SSG in dependencies (`vitepress`, `@docusaurus/core`)                                                     | Static, builds with SSG CLI                 |
+| 2a       | ...and backend files also exist                                                                                 | Refused — set `inference.appType` yourself  |
 | 3        | `@tanstack/react-start`, `@react-router/dev`, `@sveltejs/kit`, `nuxt`, `@analogjs/platform`, or `astro` in deps | Framework                                   |
 | 4        | Backend files exist (`routes/`, `pages/`, `middleware/`, `crons/`, `queues/`, SSR entry)                        | Void app                                    |
 | 5        | `vite` or `vite-plus` in dependencies, no backend files                                                         | SPA, builds with `vite build` or `vp build` |

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

@@ -249,6 +249,14 @@ Void manages Better Auth migrations as part of the normal Void migration flow:
 - deploy runs auth migrations together with app migrations
 - users do not run a separate Better Auth CLI path
 
+This applies to `void deploy` (the managed platform), which creates the Better Auth
+tables at runtime after dispatch. Deploying to your own Cloudflare account with
+[`--backend cloudflare`](/integrations/cloudflare) does **not** run that step: there,
+your checked-in `db/migrations/*.sql` must already produce the Better Auth schema, and
+deploy fails closed if they do not. Define the tables in `db/schema.ts` and run
+`void db generate` — Drizzle's `.unique()` and `.references()` are opt-in, and the
+constraints are verified too. See [#274](https://github.com/voidzero-dev/void/issues/274).
+
 ## Unsupported Modes
 
 Void-managed Better Auth is supported only for Cloudflare Void apps in v1.

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

@@ -106,6 +106,6 @@ Connect the repository to your project once with `void github connect <project>
 
 ## Other Targets
 
-If you prefer to deploy directly to your own Cloudflare account instead of using Void's managed platform, see the [Cloudflare integration guide](../integrations/cloudflare.md).
+If you prefer to deploy directly to your own Cloudflare account instead of using Void's managed platform, run `void deploy --backend cloudflare` (add `--provision` on the first deploy to create the D1/KV/R2/Queues/Hyperdrive resources your app needs). This uses your local wrangler auth and root `wrangler.jsonc` -- pin an account (`account_id` or `CLOUDFLARE_ACCOUNT_ID`) and keep real secrets in `wrangler secret put` rather than `.env`. `wrangler login` is enough to authenticate, with one exception: provisioning a **Hyperdrive** config for the first time needs `CLOUDFLARE_API_TOKEN`, because wrangler exposes no machine-readable Hyperdrive list for Void to check against (an already-provisioned Hyperdrive app deploys fine under `wrangler login`). In v1 it deploys **full Void apps on the Cloudflare Workers target** (D1/KV/R2/Queues/Hyperdrive; auth and ISR on D1/SQLite); framework SSR (TanStack Start, React Router, vinext, SvelteKit, Nuxt, Analog, Astro), static/SPA/SSG apps (including `output: "static"`), WebSocket/Durable Object apps (`*.ws.ts`), a custom `migrations_pattern`, `--skip-build`, `node`/`bun`/`deno` targets, and PostgreSQL apps with auth all fail closed with guidance. Auth apps must ship checked-in migrations that produce the Better Auth schema. Provision is a single-operator, dev-machine step and is disabled in CI. See the [Cloudflare integration guide](../integrations/cloudflare.md#deploy-to-your-own-cloudflare-account) for the full walk-through and scope.
 
 To deploy to Node.js, Bun, or Deno instead of Cloudflare, set [`target`](../reference/config.md) in `void.json`. This builds a standalone server you can run anywhere, including Docker, Railway, and Fly.io. These targets do not have access to Void platform features such as D1, KV, R2, built-in auth, Workers AI, or cron scheduling. See the [Node.js, Bun, and Deno guide](../integrations/nodejs-bun-deno.md).

package/skills/void/docs/guide/edge/static-assets.md

@@ -97,6 +97,29 @@ This is the path needed for preview auth and other middleware. Cloudflare's plat
 
 For Void apps with only `/api` routes, Void keeps the platform SPA fallback and scopes `run_worker_first` to `/api` and `/api/*`. Static assets and non-API SPA navigations stay on the asset platform. API requests, including browser document navigations such as OAuth callbacks, reach the worker instead of being rewritten to `index.html`.
 
+### Unmatched requests
+
+`not_found_handling` decides what the asset layer does with a request that matched no asset and no worker route. Void infers it:
+
+| App shape                                         | Inferred value                   | Result for an unknown URL        |
+| ------------------------------------------------- | -------------------------------- | -------------------------------- |
+| Pages or SSR                                      | `none`                           | The worker's own 404             |
+| Worker owns HTML, no `pages/`, no SSR entry       | `none` + worker fallback         | `index.html` with status **200** |
+| Asset-first (only `/api` routes, or none)         | `single-page-application`        | `index.html` with status **200** |
+| Framework deploy (SvelteKit, Nuxt, Analog, Astro) | `none` — pinned, not overridable | The framework worker's own 404   |
+
+The middle row is a worker with `middleware/`, a route outside `/api`, a document websocket, or Live, but no `pages/` and no SSR entry. `run_worker_first: ['/**']` sends everything to the worker, which bypasses the platform's SPA switch, so the generated worker does that fallback itself for HTML navigations — after your middleware has run, so auth gates and OAuth callbacks still see the request first.
+
+The SPA fallback is right for a single-page app, where deep links must boot the client router. It is wrong for a site whose HTML was generated per page: unknown URLs return 200 instead of 404, and the generator's `404.html` is never served. Nothing in a built asset tree distinguishes the two, so Void does not guess — override it with [`routing.notFound`](../../reference/config.md#routing-notfound):
+
+```json
+{ "routing": { "notFound": "404-page" } }
+```
+
+Accepted values are `"single-page-application"`, `"404-page"`, and `"none"`. `run_worker_first` keeps its inferred value, so API routes, auth, and `/__void/*` still reach the worker first. Setting anything other than `"single-page-application"` also turns off the worker-side `index.html` fallback described above — otherwise it would answer the request before `not_found_handling` was ever consulted. With `"404-page"` the worker serves whatever the asset binding returns for the unmatched path, which is Cloudflare's nearest `404.html` — but only for HTML navigations (requests whose `Accept` includes `text/html`), so an API route that deliberately returns a 404 keeps its own body, status and headers. If the build has no `404.html`, the worker's own 404 is kept.
+
+The last row is the exception: `routing.notFound` is **ignored** for SvelteKit, Nuxt, Analog, and Astro deploys, and `void deploy` warns when you set it. Those deploys emit no `run_worker_first`, so the asset layer already answers first and real prerendered files win — `not_found_handling` would only change what the framework's own `env.ASSETS.fetch()` delegation returns, where `"single-page-application"` turns genuine 404s into the prerendered home page at 200 and `"404-page"` takes the 404 away from the framework's own error route. TanStack Start and React Router deploys are not affected; they follow the rows above.
+
 ### Generated config
 
 Void owns the generated asset routing policy during dev and build. If a root `wrangler.jsonc` contains stale `not_found_handling` or `run_worker_first` values, Void replaces those fields so generated config cannot accidentally change which layer sees a request first.

package/skills/void/docs/guide/env-vars.md

@@ -109,15 +109,23 @@ In practice `env.ts` should only import schema helpers from `void/env` and — a
 
 Void uses Vite's standard `.env` convention to populate the schema:
 
-| File                    | Loaded in dev | Shipped on deploy  |
-| ----------------------- | ------------- | ------------------ |
-| `.env`                  | yes           | yes (`plain_text`) |
-| `.env.local`            | yes           | no                 |
-| `.env.production`       | yes           | yes (`plain_text`) |
-| `.env.production.local` | yes           | no                 |
+Whether a file's values ship depends on which deploy path you use:
+
+| File                    | Loaded in dev | Shipped by `void deploy` | Shipped by `--backend cloudflare` |
+| ----------------------- | ------------- | ------------------------ | --------------------------------- |
+| `.env`                  | yes           | yes (`plain_text`)       | yes (worker `vars`)               |
+| `.env.local`            | yes           | no                       | **yes** (worker `vars`)           |
+| `.env.production`       | yes           | yes (`plain_text`)       | yes (worker `vars`)               |
+| `.env.production.local` | yes           | no                       | **yes** (worker `vars`)           |
 
 `.local` files are gitignored by convention — use them for secrets you don't want in source control.
 
+::: warning `.local` files are not deploy-excluded on `--backend cloudflare`
+Managed `void deploy` reads only `.env` and `.env.production`, so a `.local` file keeps secrets off the platform. The self-host `void deploy --backend cloudflare` path instead runs Vite's production env loading, which reads all four files and bakes them into the worker's `vars` as plaintext. A value that is also `export`ed in the shell with the same value is stripped back out, so this bites hardest in CI, where the variable usually only exists in the file.
+
+On that path, keep real secrets out of every `.env*` file and use `wrangler secret put <NAME>` instead. See [Cloudflare deploy](/integrations/cloudflare).
+:::
+
 ### Dotenv variable expansion
 
 Values can reference other keys defined in the same (or earlier-precedence) `.env` file using `${VAR}` or `$VAR`:

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

@@ -10,6 +10,10 @@ Void supports Cloudflare Queues for asynchronous message processing from a top-l
 
 Create files in `queues/**/*.ts`; `.mts`, `.js`, and `.mjs` also work. The queue name is inferred from the filename. For example, `queues/emails.ts` creates a queue named `"emails"`, and `queues/order/notifications.ts` creates `"order/notifications"`.
 
+::: warning Nested files produce a name that cannot be deployed
+Cloudflare queue names allow only letters, digits and `-`, so a name containing `/` is rejected when the queue is provisioned — on both the managed platform and a self-hosted `--backend cloudflare` deploy. Nested files work in local development, but keep queue files flat (`queues/order-notifications.ts` → `"order-notifications"`) for any app you intend to deploy.
+:::
+
 Each queue file should export a default handler wrapped with [`defineQueue`](../reference/api.md#definequeuet-handler). The generic `<T>` parameter defines the message body type. That is the type of each `msg.body` in the batch, and it is also used by the typed `queues` proxy for `send()` calls.
 
 ```ts

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

@@ -214,9 +214,68 @@ When deploying via `void deploy` (to the Void platform), the `wrangler.json` in
 
 ## Deploy to your own Cloudflare account
 
-Void's default deployment path is `void deploy`, which uploads to the Void platform. But the generated worker is a standard Cloudflare Worker -- you can deploy it directly to your own account with `wrangler deploy`.
+Void's default deployment path is `void deploy`, which uploads to the Void platform. But the generated worker is a standard Cloudflare Worker -- you can deploy it directly to your own account. Two paths get you there:
 
-### 1. Create your resources
+- **[`void deploy --backend cloudflare`](#one-command-void-deploy-backend-cloudflare)** -- a first-class flow that provisions bindings, applies remote migrations, checks secrets, builds, and runs `wrangler deploy` for you.
+- **[Manual `vite build && wrangler deploy`](#manual-build-and-deploy-with-wrangler)** -- create resources and edit `wrangler.jsonc` yourself, then build and deploy with wrangler directly.
+
+Either way, the [Local development](#local-development), [AI](#ai-self-host), and [ISR](#isr-self-host) notes below apply.
+
+### One command: `void deploy --backend cloudflare`
+
+`void deploy --backend cloudflare` deploys the built worker to **your own** Cloudflare account. It uses your local wrangler auth and your root `wrangler.jsonc` -- there is no Void login or linked project.
+
+```bash
+# Deploy using the resources already declared in wrangler.jsonc
+void deploy --backend cloudflare
+
+# Create any missing resources first, then deploy
+void deploy --backend cloudflare --provision
+```
+
+**Prerequisites**
+
+- **Pin an account.** Set `account_id` in your root `wrangler.jsonc`, or export `CLOUDFLARE_ACCOUNT_ID`. A multi-account token otherwise makes wrangler prompt (or error in CI), which Void cannot intercept -- so the account must be pinned first.
+- **Authenticate wrangler.** Run `wrangler login`, or set `CLOUDFLARE_API_TOKEN`. Deploy needs a token with `Workers Scripts:Edit` plus read on the resources you bind. `--provision` additionally needs per-product `*:Edit` (D1, KV, R2, Queues, Hyperdrive).
+- **`CLOUDFLARE_API_TOKEN` is required to provision a Hyperdrive config for the first time.** `wrangler login` covers every other resource, but wrangler exposes no machine-readable Hyperdrive list, so Void checks whether the config already exists over the Cloudflare REST API -- which an OAuth session cannot authenticate. Without a token `--provision` stops **before** touching your account rather than risk minting a duplicate config. Either export `CLOUDFLARE_API_TOKEN` (with Hyperdrive edit permission), or create the Hyperdrive config yourself and add its id to the `hyperdrive` binding in `wrangler.jsonc` -- deploying an **already-provisioned** Hyperdrive app needs no token and works under `wrangler login` alone.
+- **Docker**, if your app uses the sandbox -- the build needs it locally.
+
+**What it does** (in order): settles the app class (a full Void app on the Cloudflare Workers target -- see [scope](#scope-and-limitations)) before any account operation; pins the account and confirms wrangler auth; provisions or drift-checks resources; **builds**; then, against the artifact the build actually emitted, warns on plaintext vars, gates on missing required secrets, checks the auth schema, and validates migrations; then applies remote D1 migrations for SQLite apps (and verifies none remain pending); then runs `wrangler deploy` on exactly the artifact it verified.
+
+Note that **the build runs before the secret, auth-schema, and migration gates** -- those gates read the real emitted worker, so there has to be one to read. A missing production secret or a bad migration is therefore reported _after_ the build has run, which is worth knowing if your build hooks are slow or have side effects. In exchange, nothing remote is touched until every ground-truth gate has passed: remote D1 migrations are applied only afterwards, so a failed gate leaves your account, your database, and your live worker exactly as they were.
+
+**Trust boundary: the build runs your project's code.** Exactly like the manual `vite build && wrangler deploy` below, this backend runs your project's build -- your config, every Vite plugin, and every build dependency -- with filesystem access before the credentialed deploy. Deploy narrows what that build can quietly change: it runs the build with your Cloudflare credentials scrubbed, verifies the emitted `wrangler.json` against a pre-build snapshot of your account, name, and binding identities, and checks that the wrangler CLI it is about to run with your token was not modified during the build. Those checks catch a build that tampers with the deploy target or the uploader. They do not sandbox the build itself, so a fully-compromised build dependency remains a trust boundary -- the same one you accept running `vite build` by hand. Vet your dependencies as you would for any deploy; stronger build isolation is future work.
+
+Without `--provision`, deploy is a **drift check**: if a binding your source needs is not yet in `wrangler.jsonc` with a real id, deploy stops and names each missing resource, telling you to run `--provision` once. Queues carry no id in the config, so deploy instead checks each one against your account (`wrangler queues info`) at the same point -- a queue that does not exist stops the deploy before anything is built or migrated.
+
+**`--provision`** creates any D1 database, KV namespace, R2 bucket, Queues, Hyperdrive config, and the ISR cache namespace your source needs, then lets wrangler write the real ids into your root `wrangler.jsonc`. It is **idempotent** -- it reads existing ids first, so re-running creates nothing that already exists.
+
+#### Scope and limitations
+
+- **Supported apps (v1): full Void apps on the Cloudflare Workers target only** -- worker-bearing apps that run Void's routing (`routes/` and/or `pages/`), with D1 (SQLite) and/or KV, R2, Queues, and Hyperdrive, plus auth on D1/SQLite and ISR. Everything else fails closed **before** any account operation, with guidance:
+  - **Framework SSR is not supported here (yet).** The whole framework path -- TanStack Start, React Router, vinext (and SvelteKit, Nuxt, Analog, Astro) -- is deferred in v1. Deploy them with `void deploy` (the managed platform) or the framework's own Cloudflare adapter. Framework SSR support for this backend is a follow-up.
+  - **Static-only / SPA / SSG apps are not supported here** -- including unconfigured ones, `output: "static"` in `void.json`, and `--dir` / `--spa` deploys. Deploy those with `void deploy` (the managed platform) or host the built assets on Cloudflare Pages / any static host.
+  - **WebSocket / Durable Object routes (`*.ws.ts`) are not supported here (yet).** A WebSocket route makes the build emit a key-value-backed Durable Object namespace (a `new_classes` migration), which a fresh Cloudflare account -- and every Workers Free account -- refuses to create. Deploy those with `void deploy`. SQLite-backed WebSocket support for this backend is a follow-up.
+  - **Custom `migrations_pattern` is not supported here.** v1 deploys only Void's default migration convention -- `db/migrations/*.sql` with wrangler's default pattern (leave `migrations_pattern` unset). Remove a custom `migrations_pattern` from the D1 binding, or deploy with `void deploy`. Supporting custom patterns is a follow-up.
+  - **Non-Cloudflare targets (`node` / `bun` / `deno`) are not supported here** -- this backend deploys Cloudflare Workers only.
+  - **`--skip-build` is not supported here.** Every check on this path validates the artifact the build emits -- the worker `vars` in `dist/ssr/wrangler.json` and the generated auth schema -- so skipping the build would leave them reading a stale or missing artifact instead of the worker being uploaded. Drop `--skip-build`, or use `void deploy` (the managed platform), which supports it.
+  - **PostgreSQL apps with auth enabled are not supported here.** This backend verifies + applies auth tables through remote D1 (SQLite) migrations only, so it cannot provision or verify the Better Auth schema on Postgres/Hyperdrive. Deploy with `void deploy`, or use D1 for the auth app.
+  - **PostgreSQL apps with checked-in migrations are not supported here.** This backend applies only remote D1 (SQLite) migrations. A PostgreSQL app's `db/migrations/*.sql` are applied over Hyperdrive by the managed platform (`void deploy`) at deploy time; this self-host backend never runs them, so it would deploy against an unmigrated database. Deploy with `void deploy`, or apply the migrations yourself against your Postgres and remove them from `db/migrations/`. (A pg app _without_ auth **and** with an externally-managed schema — no checked-in migrations — still deploys.)
+- **Auth requires checked-in migrations that produce the Better Auth schema.** The managed platform creates the Better Auth tables at runtime after deploy; this self-host backend never runs that step. Deploy reads the required Better Auth schema from the one the build itself generated (`.void/better-auth-schema.ts`, so configured renames and plugin tables are already reflected), then verifies the checked-in `db/migrations/*.sql` produce it by applying them to an in-memory SQLite database. Names alone are not enough: it also checks the constraints that carry correctness -- every auth table's `id` must be uniquely constrained (a `PRIMARY KEY` or a `UNIQUE` constraint/index; SQLite refuses a foreign key whose parent key is not unique, failing at runtime with `foreign key mismatch`), every field the schema marks `unique` must be covered by a unique constraint (a column-level `UNIQUE` or a single-column unique index both count, under any index name), and every field with a `references` target must have a matching foreign key. Column types, non-unique indexes and the exact `ON DELETE` action are deliberately not asserted. If a check fails, deploy fails closed naming the offending `table.column` -- fix the schema in `db/schema.ts` (Drizzle's `.primaryKey()`, `.unique()` and `.references()` are opt-in), run `void db generate`, commit the migration, or deploy with `void deploy`.
+- **Migrations must apply in the same order Void validated.** Deploy checks that the files wrangler will apply to remote D1 (and the order it applies them, by numeric prefix) exactly match Void's `db/migrations/*.sql` set -- no stray files (e.g. `seed.sql`), same content, same order. Zero-pad your migration prefixes (`0001_`, `0002_`, ...) so numeric and lexicographic order agree; deploy fails closed on a mismatch.
+- **Provision is a single-operator, dev-machine action.** The lock guarding it is per local config path only; it does not coordinate across machines or CI hosts. Two people provisioning the same account at once could create duplicate resources.
+- **Provision fails closed in CI.** In non-interactive shells, `--provision` is disabled unless your committed `wrangler.jsonc` already covers every resource (a provable no-op). The workflow is: provision **locally**, commit the updated `wrangler.jsonc`, then let CI run `void deploy --backend cloudflare` (deploy itself is CI-safe).
+- **Your `wrangler.jsonc` is rewritten on provision.** Wrangler preserves your comments but normalizes the whole file's indentation when it writes the new ids -- expect that in the diff.
+- **Your `.env*` values ship as plaintext.** The build bakes them into the worker's `vars`. This backend runs Vite's production env loading, so **all four** of `.env`, `.env.local`, `.env.production` and `.env.production.local` are loaded and shipped -- including the `.local` files, which are gitignored but **not** deploy-excluded here (unlike managed `void deploy`, which reads only `.env` and `.env.production`). The one exception: a value that is also present in the shell environment with the same value is stripped back out, so a var you `export` in CI does not get baked in. Move real secrets to `wrangler secret put <NAME>` so they are never written into `wrangler.json`. Deploy warns on likely-plaintext secrets -- by key name, and by value shape for credential-bearing connection URLs such as `DATABASE_URL` -- and hard-blocks on missing required secrets.
+- **First deploy of a new worker.** A worker that has never been deployed has no remote secrets to list yet, so the secret gate prints the still-unset required key names and the `wrangler secret put <NAME>` commands that bootstrap them on the draft worker (or add a value to `.env` / `.env.production` and rerun).
+
+The manual steps below are the by-hand equivalent -- reach for them when you want to manage resources and `wrangler.jsonc` yourself.
+
+### Manual: build and deploy with wrangler
+
+Prefer to manage everything by hand? Create the resources, write `wrangler.jsonc`, and run `wrangler deploy` yourself.
+
+#### 1. Create your resources
 
 Create whatever bindings your app uses:
 
@@ -231,7 +290,7 @@ wrangler kv namespace create KV
 wrangler r2 bucket create my-app-storage
 ```
 
-### 2. Add a `wrangler.jsonc`
+#### 2. Add a `wrangler.jsonc`
 
 Create `wrangler.jsonc` in your project root with the resource IDs from step 1:
 
@@ -264,7 +323,7 @@ Create `wrangler.jsonc` in your project root with the resource IDs from step 1:
 
 Only include the bindings your app actually uses. You can also add service bindings, custom routes, environment overrides, and any other standard wrangler fields -- they all flow through to the build output. You don't need `main` or `assets` -- those are set by the plugin.
 
-### 3. Run migrations
+#### 3. Run migrations
 
 If your app uses D1, apply migrations before deploying:
 
@@ -274,7 +333,7 @@ wrangler d1 migrations apply my-app-db --remote
 
 This uses the same `db/migrations/` directory that Void uses locally. `my-app-db` is the database name from your `wrangler.jsonc`; using the database name avoids accidentally applying migrations to the wrong binding.
 
-### 4. Build and deploy
+#### 4. Build and deploy
 
 ```bash
 vite build && wrangler deploy

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

@@ -77,6 +77,7 @@ Most configuration is inferred automatically. Use `void.json` to override defaul
 | `routing.prerender`  | Paths to prerender as static HTML at deploy time                                                                                                              |
 | `routing.revalidate` | Default revalidation TTL in seconds for cached responses                                                                                                      |
 | `inference.bindings` | Override inferred bindings. You only need this if auto-detection is not doing what you want. Accepts `true` or a custom binding name such as `"db": "MY_DB"`. |
+| `routing.notFound`   | **Ignored.** SvelteKit, Nuxt, Analog, and Astro pin `not_found_handling` to `"none"` — the framework worker owns unmatched HTML. `void deploy` warns if set.  |
 
 See [Configuration](../../reference/config.md) for the full reference.
 

package/skills/void/docs/node_modules/void/AGENT_PROMPT.md

@@ -12,4 +12,8 @@ Rewrites and redirects: declare static rules in `void.json` under `routing.redir
 
 Logs: surface app-level errors that should show up under `void project logs --level error` via `import { logger } from "void/log"` and `logger.error(msg, fields?)` (also `.warn` / `.info`). Anything caught and only persisted to your own DB is invisible to Cloudflare Tail; route it through `logger.*` or `console.*` so the platform can see it.
 
+Requests: `void project logs` only has rows when a worker actually ran. 5xx generated by the edge router, and every request to a static/SPA project, produce no log line at all. Use `void project requests --status 5xx --range 12h` to see those — it lists status, method, and duration for every request the edge served, whether or not a worker was invoked.
+
+Self-host deploy: `void deploy` targets the Void platform; to deploy to the user's OWN Cloudflare account instead, use `void deploy --backend cloudflare` (add `--provision` on the first deploy to create the D1/KV/R2/Queues/Hyperdrive resources the source needs). It uses local wrangler auth, so pin an account (`account_id` in `wrangler.jsonc` or `CLOUDFLARE_ACCOUNT_ID`) and keep real secrets in `wrangler secret put` — every `.env*` file this backend loads (`.env`, `.env.local`, `.env.production`, `.env.production.local`) ships as plaintext worker vars, `.local` included. Provisioning a Hyperdrive config reads `DATABASE_URL` from the shell, not from `.env*`. v1 supports full Void apps on the Cloudflare Workers target only (D1/KV/R2/Queues/Hyperdrive; auth and ISR on D1/SQLite); framework SSR of every kind (TanStack Start, React Router, vinext, SvelteKit, Nuxt, Analog, Astro), static/SPA/SSG apps (including `output: "static"`), WebSocket/Durable Object apps (`*.ws.ts`), a custom `migrations_pattern`, node/bun/deno targets, and PostgreSQL apps with auth all fail closed with guidance. Auth apps must ship checked-in migrations that produce the Better Auth schema. `--provision` is a single-operator, dev-machine step and is disabled in CI.
+
 Full docs are in `node_modules/void/docs/`. If you have the `void` skill available, use it for a complete API reference covering project structure, routing, pages mode, database, auth, typed fetch, KV, storage, queues, cron jobs, CLI, configuration, and deployment.

package/skills/void/docs/node_modules/void/README.md

@@ -42,7 +42,7 @@ export default defineConfig({
 - `void auth login` — platform auth
 - `void deploy` — build and deploy
 - `void db *` — local DB and migration commands
-- `void project *` — link, status, logs, rollback, delete
+- `void project *` — link, status, logs, requests, rollback, delete
 
 Runtime helpers include:
 

package/skills/void/docs/node_modules/void/node_modules/@types/proper-lockfile/README.md

@@ -0,0 +1,51 @@
+# Installation
+> `npm install --save @types/proper-lockfile`
+
+# Summary
+This package contains type definitions for proper-lockfile (https://github.com/moxystudio/node-proper-lockfile).
+
+# Details
+Files were exported from https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/proper-lockfile.
+## [index.d.ts](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/proper-lockfile/index.d.ts)
+````ts
+import { OperationOptions } from "retry";
+
+export interface LockOptions {
+    stale?: number | undefined; // default: 10000
+    update?: number | undefined; // default: stale/2
+    retries?: number | OperationOptions | undefined; // default: 0
+    realpath?: boolean | undefined; // default: true
+    fs?: any; // default: graceful-fs
+    onCompromised?: ((err: Error) => any) | undefined; // default: (err) => throw err
+    lockfilePath?: string | undefined; // default: `${file}.lock`
+}
+
+export interface UnlockOptions {
+    realpath?: boolean | undefined; // default: true
+    fs?: any; // default: graceful-fs
+    lockfilePath?: string | undefined; // default: `${file}.lock`
+}
+
+export interface CheckOptions {
+    stale?: number | undefined; // default: 10000
+    realpath?: boolean | undefined; // default: true
+    fs?: any; // default: graceful-fs
+    lockfilePath?: string | undefined; // default: `${file}.lock`
+}
+
+export function lock(file: string, options?: LockOptions): Promise<() => Promise<void>>;
+export function unlock(file: string, options?: UnlockOptions): Promise<void>;
+export function check(file: string, options?: CheckOptions): Promise<boolean>;
+
+export function lockSync(file: string, options?: LockOptions): () => void;
+export function unlockSync(file: string, options?: UnlockOptions): void;
+export function checkSync(file: string, options?: CheckOptions): boolean;
+
+````
+
+### Additional Details
+ * Last updated: Tue, 07 Nov 2023 09:09:39 GMT
+ * Dependencies: [@types/retry](https://npmjs.com/package/@types/retry)
+
+# Credits
+These definitions were written by [Nikita Volodin](https://github.com/qlonik), [Linus Unnebäck](https://github.com/LinusU), and [ulrichb](https://github.com/ulrichb).

package/skills/void/docs/node_modules/void/node_modules/@void/md/node_modules/pathslash/README.md

@@ -0,0 +1,64 @@
+# pathslash
+
+> `node:path`, platform-correct, with forward-slash output.
+
+`pathslash` is a tiny wrapper around `node:path` that always outputs forward slashes (`/`) while keeping the correct per-platform semantics. It never reimplements path logic. Every function delegates to `node:path` and only flips the separators in the result.
+
+## Why
+
+- **Forward slashes everywhere.** On Windows, the `win32` functions output `/` instead of `\`, which is what bundlers, route maps, and URLs expect.
+- **Correct semantics for free.** Drive letters, UNC paths, and case-insensitive `relative` behave exactly as in `node:path`, because they _are_ `node:path`.
+- **POSIX-safe.** On POSIX, a backslash is a valid filename character, so it is never rewritten there.
+- **A typed drop-in.** Same API and types as `node:path`.
+
+## Install
+
+```sh
+npm i pathslash
+```
+
+## Usage
+
+The default export and the top-level named exports follow the host platform, exactly like `node:path`:
+
+```ts
+import path, { join } from "pathslash";
+
+join("src", "a.ts"); // 'src/a.ts'
+path.sep; // '/'
+```
+
+To force a specific platform, use the `win32` and `posix` namespaces. They work on any host OS:
+
+```ts
+import { win32, posix } from "pathslash";
+
+win32.join("C:\\a", "b"); // 'C:/a/b'  (forward slashes)
+win32.normalize("C:\\a\\..\\b"); // 'C:/b'
+win32.relative("C:/Foo/Bar", "C:/foo/baz"); // '../baz'  (case-insensitive)
+
+posix.join("a", "b\\c"); // 'a/b\\c'  (backslash kept)
+```
+
+### `toSlash(path)`
+
+Safely normalizes separators to `/`. On Windows it converts `\` to `/`. On POSIX it returns the path unchanged, because a backslash is a valid filename character there and rewriting it would corrupt the path. Use it for paths that come from outside this package, such as `process.cwd()`:
+
+```ts
+import { toSlash } from "pathslash";
+
+toSlash("C:\\a\\b"); // 'C:/a/b' on Windows, unchanged on POSIX
+```
+
+## Notes
+
+- `win32.sep` is `"/"` instead of `"\\"`, and `win32.delimiter` stays `";"`.
+- `\\?\` (extended-length) paths stay verbatim. `toSlash` and every `win32.*` function leave them untouched, because a forward slash is a literal character there, not a separator.
+- `toNamespacedPath` always returns a native, backslash path, since `\\?\` paths are only valid with backslashes.
+- `matchesGlob` mirrors `node:path`. It exists only on Node versions that ship it (22.5+) and is `undefined` on older ones.
+- The types are a drop-in too: `import type { ParsedPath, FormatInputPathObject, PlatformPath } from "pathslash"`.
+- Everything else matches `node:path`, separators aside.
+
+## License
+
+[MIT](./LICENSE)

package/skills/void/docs/node_modules/void/node_modules/pathslash/README.md

@@ -0,0 +1,64 @@
+# pathslash
+
+> `node:path`, platform-correct, with forward-slash output.
+
+`pathslash` is a tiny wrapper around `node:path` that always outputs forward slashes (`/`) while keeping the correct per-platform semantics. It never reimplements path logic. Every function delegates to `node:path` and only flips the separators in the result.
+
+## Why
+
+- **Forward slashes everywhere.** On Windows, the `win32` functions output `/` instead of `\`, which is what bundlers, route maps, and URLs expect.
+- **Correct semantics for free.** Drive letters, UNC paths, and case-insensitive `relative` behave exactly as in `node:path`, because they _are_ `node:path`.
+- **POSIX-safe.** On POSIX, a backslash is a valid filename character, so it is never rewritten there.
+- **A typed drop-in.** Same API and types as `node:path`.
+
+## Install
+
+```sh
+npm i pathslash
+```
+
+## Usage
+
+The default export and the top-level named exports follow the host platform, exactly like `node:path`:
+
+```ts
+import path, { join } from "pathslash";
+
+join("src", "a.ts"); // 'src/a.ts'
+path.sep; // '/'
+```
+
+To force a specific platform, use the `win32` and `posix` namespaces. They work on any host OS:
+
+```ts
+import { win32, posix } from "pathslash";
+
+win32.join("C:\\a", "b"); // 'C:/a/b'  (forward slashes)
+win32.normalize("C:\\a\\..\\b"); // 'C:/b'
+win32.relative("C:/Foo/Bar", "C:/foo/baz"); // '../baz'  (case-insensitive)
+
+posix.join("a", "b\\c"); // 'a/b\\c'  (backslash kept)
+```
+
+### `toSlash(path)`
+
+Safely normalizes separators to `/`. On Windows it converts `\` to `/`. On POSIX it returns the path unchanged, because a backslash is a valid filename character there and rewriting it would corrupt the path. Use it for paths that come from outside this package, such as `process.cwd()`:
+
+```ts
+import { toSlash } from "pathslash";
+
+toSlash("C:\\a\\b"); // 'C:/a/b' on Windows, unchanged on POSIX
+```
+
+## Notes
+
+- `win32.sep` is `"/"` instead of `"\\"`, and `win32.delimiter` stays `";"`.
+- `\\?\` (extended-length) paths stay verbatim. `toSlash` and every `win32.*` function leave them untouched, because a forward slash is a literal character there, not a separator.
+- `toNamespacedPath` always returns a native, backslash path, since `\\?\` paths are only valid with backslashes.
+- `matchesGlob` mirrors `node:path`. It exists only on Node versions that ship it (22.5+) and is `undefined` on older ones.
+- The types are a drop-in too: `import type { ParsedPath, FormatInputPathObject, PlatformPath } from "pathslash"`.
+- Everything else matches `node:path`, separators aside.
+
+## License
+
+[MIT](./LICENSE)

package/skills/void/docs/node_modules/void/node_modules/proper-lockfile/CHANGELOG.md

@@ -0,0 +1,108 @@
+# Change Log
+
+All notable changes to this project will be documented in this file. See [standard-version](https://github.com/conventional-changelog/standard-version) for commit guidelines.
+
+<a name="4.1.2"></a>
+## [4.1.2](https://github.com/moxystudio/node-proper-lockfile/compare/v4.1.1...v4.1.2) (2021-01-25)
+
+
+### Bug Fixes
+
+* fix node 14 updating graceful-fs ([#102](https://github.com/moxystudio/node-proper-lockfile/issues/102)) ([b0d988e](https://github.com/moxystudio/node-proper-lockfile/commit/b0d988e))
+
+
+
+<a name="4.1.1"></a>
+## [4.1.1](https://github.com/moxystudio/node-proper-lockfile/compare/v4.1.0...v4.1.1) (2019-04-03)
+
+
+### Bug Fixes
+
+* fix mtime precision on some filesystems ([#88](https://github.com/moxystudio/node-proper-lockfile/issues/88)) ([f266158](https://github.com/moxystudio/node-proper-lockfile/commit/f266158)), closes [#82](https://github.com/moxystudio/node-proper-lockfile/issues/82) [#87](https://github.com/moxystudio/node-proper-lockfile/issues/87)
+
+
+
+<a name="4.1.0"></a>
+# [4.1.0](https://github.com/moxystudio/node-proper-lockfile/compare/v4.0.0...v4.1.0) (2019-03-18)
+
+
+### Features
+
+* allow second precision in mtime comparison ([#78](https://github.com/moxystudio/node-proper-lockfile/issues/78)) ([b2816a6](https://github.com/moxystudio/node-proper-lockfile/commit/b2816a6))
+
+
+
+<a name="4.0.0"></a>
+# [4.0.0](https://github.com/moxystudio/node-proper-lockfile/compare/v3.2.0...v4.0.0) (2019-03-12)
+
+
+### Bug Fixes
+
+* fix typo in error message ([#68](https://github.com/moxystudio/node-proper-lockfile/issues/68)) ([b91cb55](https://github.com/moxystudio/node-proper-lockfile/commit/b91cb55))
+
+
+### Features
+
+* make staleness check more robust ([#74](https://github.com/moxystudio/node-proper-lockfile/issues/74)) ([9cc0973](https://github.com/moxystudio/node-proper-lockfile/commit/9cc0973)), closes [#71](https://github.com/moxystudio/node-proper-lockfile/issues/71) [/github.com/ipfs/js-ipfs-repo/issues/188#issuecomment-468682971](https://github.com//github.com/ipfs/js-ipfs-repo/issues/188/issues/issuecomment-468682971)
+
+
+### BREAKING CHANGES
+
+* We were marking the lock as compromised when system went into sleep or if the event loop was busy taking too long to run the internals timers, Now we keep track of the mtime updated by the current process, and if we lose some cycles in the update process but recover and the mtime is still ours we do not mark the lock as compromised.
+
+
+
+<a name="3.2.0"></a>
+# [3.2.0](https://github.com/moxystudio/node-proper-lockfile/compare/v3.1.0...v3.2.0) (2018-11-19)
+
+
+### Features
+
+* add lock path option ([#66](https://github.com/moxystudio/node-proper-lockfile/issues/66)) ([32f1b8d](https://github.com/moxystudio/node-proper-lockfile/commit/32f1b8d))
+
+
+
+<a name="3.1.0"></a>
+# [3.1.0](https://github.com/moxystudio/node-proper-lockfile/compare/v3.0.2...v3.1.0) (2018-11-15)
+
+
+### Bug Fixes
+
+* **package:** update retry to version 0.12.0 ([#50](https://github.com/moxystudio/node-proper-lockfile/issues/50)) ([d400b98](https://github.com/moxystudio/node-proper-lockfile/commit/d400b98))
+
+
+### Features
+
+* add signal exit ([#65](https://github.com/moxystudio/node-proper-lockfile/issues/65)) ([f20bc45](https://github.com/moxystudio/node-proper-lockfile/commit/f20bc45))
+
+
+
+<a name="3.0.2"></a>
+## [3.0.2](https://github.com/moxystudio/node-proper-lockfile/compare/v3.0.1...v3.0.2) (2018-01-30)
+
+
+
+<a name="3.0.1"></a>
+## [3.0.1](https://github.com/moxystudio/node-proper-lockfile/compare/v3.0.0...v3.0.1) (2018-01-20)
+
+
+### Bug Fixes
+
+* restore ability to use lockfile() directly ([0ef8fbc](https://github.com/moxystudio/node-proper-lockfile/commit/0ef8fbc))
+
+
+
+<a name="3.0.0"></a>
+# [3.0.0](https://github.com/moxystudio/node-proper-lockfile/compare/v2.0.1...v3.0.0) (2018-01-20)
+
+
+### Chores
+
+* update project to latest node lts ([b1d43e5](https://github.com/moxystudio/node-proper-lockfile/commit/b1d43e5))
+
+
+### BREAKING CHANGES
+
+* remove callback support
+* use of node lts language features such as object spread
+* compromised function in lock() has been moved to an option