void 0.10.10 → 0.10.11

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

@@ -0,0 +1,183 @@
+# proper-lockfile
+
+[![NPM version][npm-image]][npm-url] [![Downloads][downloads-image]][npm-url] [![Build Status][travis-image]][travis-url] [![Coverage Status][codecov-image]][codecov-url] [![Dependency status][david-dm-image]][david-dm-url] [![Dev Dependency status][david-dm-dev-image]][david-dm-dev-url]
+
+[npm-url]:https://npmjs.org/package/proper-lockfile
+[downloads-image]:https://img.shields.io/npm/dm/proper-lockfile.svg
+[npm-image]:https://img.shields.io/npm/v/proper-lockfile.svg
+[travis-url]:https://travis-ci.org/moxystudio/node-proper-lockfile
+[travis-image]:https://img.shields.io/travis/moxystudio/node-proper-lockfile/master.svg
+[codecov-url]:https://codecov.io/gh/moxystudio/node-proper-lockfile
+[codecov-image]:https://img.shields.io/codecov/c/github/moxystudio/node-proper-lockfile/master.svg
+[david-dm-url]:https://david-dm.org/moxystudio/node-proper-lockfile
+[david-dm-image]:https://img.shields.io/david/moxystudio/node-proper-lockfile.svg
+[david-dm-dev-url]:https://david-dm.org/moxystudio/node-proper-lockfile?type=dev
+[david-dm-dev-image]:https://img.shields.io/david/dev/moxystudio/node-proper-lockfile.svg
+
+An inter-process and inter-machine lockfile utility that works on a local or network file system.
+
+
+## Installation
+
+`$ npm install proper-lockfile`
+
+
+## Design
+
+There are various ways to achieve [file locking](http://en.wikipedia.org/wiki/File_locking).
+
+This library utilizes the `mkdir` strategy which works atomically on any kind of file system, even network based ones.
+The lockfile path is based on the file path you are trying to lock by suffixing it with `.lock`.
+
+When a lock is successfully acquired, the lockfile's `mtime` (modified time) is periodically updated to prevent staleness. This allows to effectively check if a lock is stale by checking its `mtime` against a stale threshold. If the update of the mtime fails several times, the lock might be compromised. The `mtime` is [supported](http://en.wikipedia.org/wiki/Comparison_of_file_systems) in almost every `filesystem`.
+
+
+### Comparison
+
+This library is similar to [lockfile](https://github.com/isaacs/lockfile) but the latter has some drawbacks:
+
+- It relies on `open` with `O_EXCL` flag which has problems in network file systems. `proper-lockfile` uses `mkdir` which doesn't have this issue.
+
+> O_EXCL is broken on NFS file systems; programs which rely on it for performing locking tasks will contain a race condition.
+
+- The lockfile staleness check is done via `ctime` (creation time) which is unsuitable for long running processes. `proper-lockfile` constantly updates lockfiles `mtime` to do proper staleness check.
+
+- It does not check if the lockfile was compromised which can lead to undesirable situations. `proper-lockfile` checks the lockfile when updating the `mtime`.
+
+- It has a default value of `0` for the stale option which isn't good because any crash or process kill that the package can't handle gracefully will leave the lock active forever.
+
+
+### Compromised
+
+`proper-lockfile` does not detect cases in which:
+
+- A `lockfile` is manually removed and someone else acquires the lock right after
+- Different `stale`/`update` values are being used for the same file, possibly causing two locks to be acquired on the same file
+
+`proper-lockfile` detects cases in which:
+
+- Updates to the `lockfile` fail
+- Updates take longer than expected, possibly causing the lock to become stale for a certain amount of time
+
+
+As you see, the first two are a consequence of bad usage. Technically, it was possible to detect the first two but it would introduce complexity and eventual race conditions.
+
+
+## Usage
+
+### .lock(file, [options])
+
+Tries to acquire a lock on `file` or rejects the promise on error.
+
+If the lock succeeds, a `release` function is provided that should be called when you want to release the lock. The `release` function also rejects the promise on error (e.g. when the lock was already compromised).
+
+Available options:
+
+- `stale`: Duration in milliseconds in which the lock is considered stale, defaults to `10000` (minimum value is `5000`)
+- `update`: The interval in milliseconds in which the lockfile's `mtime` will be updated, defaults to `stale/2` (minimum value is `1000`, maximum value is `stale/2`)
+- `retries`: The number of retries or a [retry](https://www.npmjs.org/package/retry) options object, defaults to `0`
+- `realpath`: Resolve symlinks using realpath, defaults to `true` (note that if `true`, the `file` must exist previously)
+- `fs`: A custom fs to use, defaults to `graceful-fs`
+- `onCompromised`: Called if the lock gets compromised, defaults to a function that simply throws the error which will probably cause the process to die
+- `lockfilePath`: Custom lockfile path. e.g.: If you want to lock a directory and create the lock file inside it, you can pass `file` as `<dir path>` and `options.lockfilePath` as `<dir path>/dir.lock`
+
+
+```js
+const lockfile = require('proper-lockfile');
+
+lockfile.lock('some/file')
+.then((release) => {
+    // Do something while the file is locked
+
+    // Call the provided release function when you're done,
+    // which will also return a promise
+    return release();
+})
+.catch((e) => {
+    // either lock could not be acquired
+    // or releasing it failed
+    console.error(e)
+});
+
+// Alternatively, you may use lockfile('some/file') directly.
+```
+
+
+### .unlock(file, [options])
+
+Releases a previously acquired lock on `file` or rejects the promise on error.
+
+Whenever possible you should use the `release` function instead (as exemplified above). Still there are cases in which it's hard to keep a reference to it around code. In those cases `unlock()` might be handy.
+
+Available options:
+
+- `realpath`: Resolve symlinks using realpath, defaults to `true` (note that if `true`, the `file` must exist previously)
+- `fs`: A custom fs to use, defaults to `graceful-fs`
+- `lockfilePath`: Custom lockfile path. e.g.: If you want to lock a directory and create the lock file inside it, you can pass `file` as `<dir path>` and `options.lockfilePath` as `<dir path>/dir.lock`
+
+
+```js
+const lockfile = require('proper-lockfile');
+
+lockfile.lock('some/file')
+.then(() => {
+    // Do something while the file is locked
+
+    // Later..
+    return lockfile.unlock('some/file');
+});
+```
+
+### .check(file, [options])
+
+Check if the file is locked and its lockfile is not stale, rejects the promise on error.
+
+Available options:
+
+- `stale`: Duration in milliseconds in which the lock is considered stale, defaults to `10000` (minimum value is `5000`)
+- `realpath`: Resolve symlinks using realpath, defaults to `true` (note that if `true`, the `file` must exist previously)
+- `fs`: A custom fs to use, defaults to `graceful-fs`
+- `lockfilePath`: Custom lockfile path. e.g.: If you want to lock a directory and create the lock file inside it, you can pass `file` as `<dir path>` and `options.lockfilePath` as `<dir path>/dir.lock`
+
+
+```js
+const lockfile = require('proper-lockfile');
+
+lockfile.check('some/file')
+.then((isLocked) => {
+    // isLocked will be true if 'some/file' is locked, false otherwise
+});
+```
+
+### .lockSync(file, [options])
+
+Sync version of `.lock()`.   
+Returns the `release` function or throws on error.
+
+### .unlockSync(file, [options])
+
+Sync version of `.unlock()`.   
+Throws on error.
+
+### .checkSync(file, [options])
+
+Sync version of `.check()`.
+Returns a boolean or throws on error.
+
+
+## Graceful exit
+
+`proper-lockfile` automatically removes locks if the process exits, except if the process is killed with SIGKILL or it crashes due to a VM fatal error (e.g.: out of memory).
+
+
+## Tests
+
+`$ npm test`   
+`$ npm test -- --watch` during development
+
+The test suite is very extensive. There's even a stress test to guarantee exclusiveness of locks.
+
+
+## License
+
+Released under the [MIT License](https://www.opensource.org/licenses/mit-license.php).

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

@@ -32,39 +32,40 @@ Then ask what to do next.
 
 ## Task Routing
 
-| User intent                               | Docs file(s)                                                                              |
-| ----------------------------------------- | ----------------------------------------------------------------------------------------- |
-| CLI command syntax, flags, env vars       | `docs/reference/cli.md`                                                                   |
-| Initial setup, onboarding, first app      | `docs/guide/quickstart.md`, `docs/reference/cli.md`                                       |
-| App type detection and mode behavior      | `docs/guide/app-types.md`, `docs/reference/config.md`                                     |
-| Server/API routing and middleware         | `docs/guide/server-routing.md`, `docs/integrations/hono.md`                               |
-| Pages mode, loader/action, forms, layouts | `docs/guide/pages-routing/*.md`, `docs/guide/type-safety.md`                              |
-| Database and migrations                   | `docs/guide/database.md`, `docs/guide/type-safety.md`                                     |
-| Typed fetch and end-to-end typing         | `docs/guide/typed-fetch.md`, `docs/guide/type-safety.md`                                  |
-| Authentication                            | `docs/guide/auth.md`, `docs/guide/env-vars.md`                                            |
-| Cloudflare runtime bindings and config    | `docs/integrations/cloudflare.md`, `docs/reference/config.md`, `docs/guide/env-vars.md`   |
-| AI inference (Workers AI, providers)      | `docs/guide/ai.md`                                                                        |
-| KV / storage / queues / cron jobs         | `docs/guide/kv.md`, `docs/guide/storage.md`, `docs/guide/queues.md`, `docs/guide/jobs.md` |
-| SSR and caching                           | `docs/guide/ssr.md`, `docs/guide/edge/*.md`                                               |
-| Rewrites, redirects, fallbacks            | `docs/guide/edge/rewrites.md`, `docs/guide/edge/redirects.md`, `docs/reference/config.md` |
-| Static site generation                    | `docs/guide/ssg.md`                                                                       |
-| Deployment and CI                         | `docs/guide/deployment.md`, `docs/reference/cli.md`                                       |
-| Project status, deployment history        | `docs/reference/cli.md`                                                                   |
-| Cache purging                             | `docs/reference/cli.md`                                                                   |
-| Project logs, runtime errors              | `docs/reference/cli.md`                                                                   |
-| Secrets management (put/sync/delete)      | `docs/reference/cli.md`, `docs/guide/env-vars.md`                                         |
-| Typed env vars (`defineEnv`, `env.ts`)    | `docs/guide/env-vars.md`                                                                  |
-| Custom domain setup                       | `docs/reference/cli.md`                                                                   |
-| Database status, reset, seed, export      | `docs/reference/cli.md`, `docs/guide/database.md`                                         |
-| Auth login/logout/whoami                  | `docs/reference/cli.md`                                                                   |
-| Overview / introduction                   | `docs/guide/index.md`                                                                     |
-| API surface details                       | `docs/reference/api.md`                                                                   |
-| Meta framework integration                | `docs/integrations/frameworks/*.md`                                                       |
-| Coding agent setup                        | `docs/integrations/agents.md`                                                             |
-| Node.js / Bun / Deno targets              | `docs/integrations/nodejs-bun-deno.md`                                                    |
-| ORMs and external databases               | `docs/integrations/orms-and-external-dbs.md`                                              |
-| Project structure and conventions         | `docs/reference/structure.md`                                                             |
-| Resource/binding inference                | `docs/reference/resource-inference.md`                                                    |
+| User intent                                | Docs file(s)                                                                              |
+| ------------------------------------------ | ----------------------------------------------------------------------------------------- |
+| CLI command syntax, flags, env vars        | `docs/reference/cli.md`                                                                   |
+| Initial setup, onboarding, first app       | `docs/guide/quickstart.md`, `docs/reference/cli.md`                                       |
+| App type detection and mode behavior       | `docs/guide/app-types.md`, `docs/reference/config.md`                                     |
+| Server/API routing and middleware          | `docs/guide/server-routing.md`, `docs/integrations/hono.md`                               |
+| Pages mode, loader/action, forms, layouts  | `docs/guide/pages-routing/*.md`, `docs/guide/type-safety.md`                              |
+| Database and migrations                    | `docs/guide/database.md`, `docs/guide/type-safety.md`                                     |
+| Typed fetch and end-to-end typing          | `docs/guide/typed-fetch.md`, `docs/guide/type-safety.md`                                  |
+| Authentication                             | `docs/guide/auth.md`, `docs/guide/env-vars.md`                                            |
+| Cloudflare runtime bindings and config     | `docs/integrations/cloudflare.md`, `docs/reference/config.md`, `docs/guide/env-vars.md`   |
+| AI inference (Workers AI, providers)       | `docs/guide/ai.md`                                                                        |
+| KV / storage / queues / cron jobs          | `docs/guide/kv.md`, `docs/guide/storage.md`, `docs/guide/queues.md`, `docs/guide/jobs.md` |
+| SSR and caching                            | `docs/guide/ssr.md`, `docs/guide/edge/*.md`                                               |
+| Rewrites, redirects, fallbacks             | `docs/guide/edge/rewrites.md`, `docs/guide/edge/redirects.md`, `docs/reference/config.md` |
+| Static site generation                     | `docs/guide/ssg.md`                                                                       |
+| Deployment and CI                          | `docs/guide/deployment.md`, `docs/reference/cli.md`                                       |
+| Self-host deploy to own Cloudflare account | `docs/integrations/cloudflare.md`, `docs/reference/cli.md`                                |
+| Project status, deployment history         | `docs/reference/cli.md`                                                                   |
+| Cache purging                              | `docs/reference/cli.md`                                                                   |
+| Project logs, runtime errors               | `docs/reference/cli.md`                                                                   |
+| Secrets management (put/sync/delete)       | `docs/reference/cli.md`, `docs/guide/env-vars.md`                                         |
+| Typed env vars (`defineEnv`, `env.ts`)     | `docs/guide/env-vars.md`                                                                  |
+| Custom domain setup                        | `docs/reference/cli.md`                                                                   |
+| Database status, reset, seed, export       | `docs/reference/cli.md`, `docs/guide/database.md`                                         |
+| Auth login/logout/whoami                   | `docs/reference/cli.md`                                                                   |
+| Overview / introduction                    | `docs/guide/index.md`                                                                     |
+| API surface details                        | `docs/reference/api.md`                                                                   |
+| Meta framework integration                 | `docs/integrations/frameworks/*.md`                                                       |
+| Coding agent setup                         | `docs/integrations/agents.md`                                                             |
+| Node.js / Bun / Deno targets               | `docs/integrations/nodejs-bun-deno.md`                                                    |
+| ORMs and external databases                | `docs/integrations/orms-and-external-dbs.md`                                              |
+| Project structure and conventions          | `docs/reference/structure.md`                                                             |
+| Resource/binding inference                 | `docs/reference/resource-inference.md`                                                    |
 
 ## Working Rules
 

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

@@ -0,0 +1,85 @@
+# `packages/void/test/e2e`
+
+Gated live-account end-to-end tests. These run REAL Cloudflare operations against a REAL account, so
+they **skip unless credentials are present**. Locally that means exporting the env vars below; in CI
+they run on **pushes to `main`** (see [In CI](#in-ci)).
+
+## `cloudflare-deploy-live.test.ts`
+
+Deploys `playground/spa` (D1 + KV + cron) to the target account via `void deploy --backend cloudflare`,
+verifies the live worker answers HTTP 200, then deletes the worker and every resource it created.
+
+It does **not** drive `--provision`: that path fails closed in non-interactive shells by design (a
+spawned CLI has no TTY, and CI cannot commit back the ids a create would mint). So the test plays the
+provisioner's role itself — it creates the id-bearing D1 + KV directly with `wrangler … create`,
+writes their real ids into the app's root config exactly as `--provision` would, then runs the
+CI-safe `void deploy --backend cloudflare` (no `--provision`). That exercises the real
+build → tamper-guard → remote-migrations → `wrangler deploy` pipeline end to end.
+
+### Prerequisites
+
+The suite is skipped unless BOTH env vars are set:
+
+| Env var                  | Purpose                                                                    |
+| ------------------------ | -------------------------------------------------------------------------- |
+| `VOID_E2E_CF_TOKEN`      | Cloudflare API token that can create + delete Workers Scripts, D1, and KV. |
+| `VOID_E2E_CF_ACCOUNT_ID` | Cloudflare account id to deploy into.                                      |
+
+The token needs, on that account, **Workers Scripts: Edit**, **D1: Edit**, and **Workers KV Storage:
+Edit** (Edit implies read, covering the ownership/teardown list calls). Cron triggers ride along with
+the worker deploy — no extra permission.
+
+The account must also have a **workers.dev subdomain** already registered (with its wildcard TLS cert
+provisioned). Without one, `wrangler deploy` uploads the worker but cannot publish a public URL, and
+the HTTP-200 assertion has nothing to hit. Opening the Workers & Pages dashboard once registers a
+subdomain automatically; a freshly-registered subdomain takes a few minutes for its cert to go live,
+during which the first run may see a TLS handshake failure — rerun once the cert is ready.
+
+With no env vars the suite SKIPS cleanly (0 run, N skipped).
+
+### Running it
+
+```sh
+# Ensure the CLI is built first (dist/cli/cli.mjs):
+vp run build:core
+
+VOID_E2E_CF_TOKEN=... VOID_E2E_CF_ACCOUNT_ID=... vp test run packages/void/test/e2e
+```
+
+### In CI
+
+`VOID_E2E_CF_TOKEN` and `VOID_E2E_CF_ACCOUNT_ID` are **environment secrets** on the `cloudflare-e2e`
+GitHub Environment (not repo secrets), and a dedicated `live-e2e` job in `.github/workflows/ci.yml`
+consumes them — the main `test` job carries no creds at all. Two layers keep the account token off
+untrusted code:
+
+- The `live-e2e` job runs only on a direct push to `main` (`github.event_name == 'push' && github.ref
+== 'refs/heads/main'`), so `pull_request` runs, tag pushes, and `workflow_call` (release) skip it.
+- The `cloudflare-e2e` environment's deployment branch policy allows `main` **only**, enforced by
+  GitHub server-side on the run's ref. A `pull_request` run's ref is `refs/pull/<n>/merge`, so it can
+  never reach the secret **even if a PR edits this workflow** — the expression-level gate alone would
+  be bypassable that way; the environment ref-check is the real boundary.
+
+So the credentialed live deploy runs on every merge to `main`; everywhere else the creds are empty and
+the suite SKIPS (the `test` job still imports the file and skips it). The `live-e2e` job itself is
+fail-closed — a preflight step errors if either credential is empty (a missing, deleted, or
+not-yet-rotated secret), so a misconfigured gate is loud instead of a silent green skip. Each
+`live-e2e` run also gets `VOID_E2E_RUN_ID = <run-id>-<attempt>` for the unique per-run resource names
+below.
+
+### Resource naming & cleanup
+
+Each run derives a UNIQUE resource name — `void-e2e-cf-deploy-<suffix>` — so overlapping runs never
+collide on remote resources. The suffix is `VOID_E2E_RUN_ID` (CI: `<run-id>-<attempt>`) or, locally, a
+timestamp + random. Derived names mirror the provisioner: `<name>-db` (D1), `<name>-kv` (KV). The
+shared `void-e2e-cf-deploy-` prefix keeps every resource greppable, so an orphan from a hard-killed run
+is easy to find and `wrangler delete`. A pre-run ownership gate refuses to start if the run's names
+already exist (failing closed on any lookup it cannot confirm), so the test never adopts or deletes a
+resource it does not own. Teardown runs even when the deploy or an assertion fails.
+
+> **Local concurrency:** unique names isolate _remote_ resources, but a run also snapshots and
+> overwrites the shared `playground/spa/wrangler.jsonc` and builds in place. Do **not** run two live
+> e2e invocations against the same checkout at once — they would race that file. CI is unaffected (each
+> runner is an isolated checkout, and only the single `main`-push `live-e2e` job deploys). The deploy
+> test also asserts the returned host's worker label equals this run's `WORKER_NAME`, so a clobbered
+> overlay fails loudly instead of validating another run's worker.

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

@@ -32,6 +32,7 @@ Use this page as a command reference. If you are setting up a project for the fi
 | `void auth login`                 | Authenticate with Void                                              |
 | `void project link`               | Link directory to a project                                         |
 | `void project logs`               | Show runtime logs from deployed project                             |
+| `void project requests`           | Show request-level traffic (status, method, timing)                 |
 | `void project rollback`           | Roll back to a previous deployment                                  |
 | `void project cancel`             | Cancel an active deployment                                         |
 | `void project purge-cache`        | Purge all cached pages                                              |
@@ -162,12 +163,12 @@ void project logs [--level <level>] [--filter <text>] [--range <duration>] [--de
 
 Show runtime logs from the deployed project. Uses the linked project from `.void/project.json`.
 
-| Flag                 | Purpose                                                                                                                                                 | Default |
-| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
-| `--range <duration>` | How far back to look. Format: `<number><unit>` (m/h/d). Max 7d.                                                                                         | `1h`    |
-| `--level <level>`    | Filter by log level. One of `error`, `warn`, `info`, `log`, `debug`, `all`. `error` also includes uncaught exceptions and non-`ok` requests.            | `all`   |
-| `--filter <text>`    | Case-insensitive **substring** match against log message text and exception name/message — not a level filter. Shows the full request entry on any hit. | none    |
-| `--deployment <id>`  | Filter logs to a specific deployment ID.                                                                                                                | none    |
+| Flag                 | Purpose                                                                                                                                                                                                         | Default |
+| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
+| `--range <duration>` | How far back to look. Format: `<number><unit>` (m/h/d). Max 7d.                                                                                                                                                 | `1h`    |
+| `--level <level>`    | Filter by log level. One of `error`, `warn`, `info`, `log`, `debug`, `all`. `error` also includes uncaught exceptions, non-`ok` outcomes, and any 5xx response — even when the worker neither threw nor logged. | `all`   |
+| `--filter <text>`    | Case-insensitive **substring** match against log message text and exception name/message — not a level filter. Shows the full request entry on any hit.                                                         | none    |
+| `--deployment <id>`  | Filter logs to a specific deployment ID.                                                                                                                                                                        | none    |
 
 Output shows one line per request (`HH:MM:SS METHOD URL STATUS`) with indented console log and exception lines beneath. Errors and exceptions are colored red, warnings yellow.
 
@@ -178,7 +179,32 @@ void project logs --level error --range 12h
 void project logs --level error --filter websocket
 ```
 
-Tip: `void project logs` only sees what Cloudflare Tail captures — top-level `console.*` calls and uncaught throws. Application errors caught and persisted to your own DB are invisible to tail. Surface them via `console.error(...)` or `void/log`'s `logger.error(...)` so they show up under `--level error`.
+Tip: `void project logs` only sees what Cloudflare Tail captures — top-level `console.*` calls and uncaught throws. Application errors caught and persisted to your own DB are invisible to tail. Surface them via `console.error(...)` or `void/log`'s `logger.error(...)` so they show up under `--level error`. For 5xx that never reach your worker at all (edge-router errors, static/SPA projects), use `void project requests --status 5xx`.
+
+### `void project requests`
+
+```
+void project requests [--status <filter>] [--range <duration>]
+```
+
+Show request-level traffic recorded at the edge for the linked project: one line per request with time, method, HTTP status, request type, and server timing. Unlike `void project logs` (which only has rows for invoked user workers), this reads the edge request-metering data, so it also surfaces:
+
+- **5xx the edge router generated itself** — missing deployment manifest, static-asset read timeouts, SSR dispatch timeouts — which never invoke your worker and so never appear in logs.
+- **Requests to static/SPA projects**, which are served directly from storage and never run a worker.
+
+| Flag                 | Purpose                                                                                       | Default |
+| -------------------- | --------------------------------------------------------------------------------------------- | ------- |
+| `--status <filter>`  | Filter by status: a class (`2xx`, `3xx`, `4xx`, `5xx`) or an exact 3-digit code (e.g. `500`). | none    |
+| `--range <duration>` | How far back to look. Format: `<number><unit>` (m/h/d). Max 7d.                               | `1h`    |
+
+Output shows one line per request (`HH:MM:SS METHOD STATUS TYPE DURATION`). 5xx are colored red, 4xx yellow. Note: request paths are not recorded, so this view shows status and type rather than URLs — use `void project logs` for per-URL, per-log detail on requests that do reach your worker.
+
+Examples:
+
+```
+void project requests --status 5xx
+void project requests --range 24h
+```
 
 ### `void project rollback [deployId]`
 
@@ -226,19 +252,22 @@ If `--project` is provided, purges that project's cache instead of the linked pr
 
 ```
 void deploy [--project <name>] [--dir <path>] [--spa] [--skip-build] [--debug]
+void deploy --backend cloudflare [--provision]
 ```
 
 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.
 
 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                                                                      |
-| ------------------ | ---------------------------------------------------------------------------- |
-| `--project <name>` | Target a specific project by slug                                            |
-| `--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 (use existing build output)                              |
-| `--debug`          | Mirror the structured deploy log to stderr (also written to `~/.void/logs/`) |
+| Flag                   | Purpose                                                                                      |
+| ---------------------- | -------------------------------------------------------------------------------------------- |
+| `--project <name>`     | Target a specific project by slug; not supported with `--backend cloudflare`                 |
+| `--dir <path>`         | Deploy a pre-built static directory (skips build); not supported with `--backend cloudflare` |
+| `--spa`                | Use SPA mode instead of SSG for static deploys; not supported with `--backend cloudflare`    |
+| `--skip-build`         | Skip the build step (use existing build output); not supported with `--backend cloudflare`   |
+| `--backend cloudflare` | Deploy to your own Cloudflare account instead of the Void platform                           |
+| `--provision`          | Create missing bindings (D1/KV/R2/Queues/Hyperdrive); requires `--backend cloudflare`        |
+| `--debug`              | Mirror the structured deploy log to stderr (also written to `~/.void/logs/`)                 |
 
 Every deploy writes a structured JSONL trace to `~/.void/logs/deploy-<timestamp>.jsonl` regardless of `--debug`. On failure the path is printed at the end of the error message so you can attach it when reporting platform issues. `VOID_DEPLOY_DEBUG=1` is accepted as an alternate trigger for stderr mirroring.
 
@@ -252,6 +281,37 @@ If no project is linked and no override is provided, CLI prompts to link or crea
 
 That fallback is mainly for projects that skipped Void project setup during `void init`.
 
+### `void deploy --backend cloudflare`
+
+Deploy the built worker straight to **your own** Cloudflare account instead of the Void platform. This path uses your local `wrangler` auth and your root `wrangler.jsonc` — no Void login or linked project is involved.
+
+```
+void deploy --backend cloudflare              # deploy using resources already in wrangler.jsonc
+void deploy --backend cloudflare --provision  # create any missing resources first, then deploy
+```
+
+Prerequisites:
+
+- A Cloudflare account must be **pinned**: 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.
+- Authenticate wrangler (`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 for an existing config over the Cloudflare REST API, which OAuth cannot authenticate. Without a token, `--provision` stops before touching your account. Alternatively create the Hyperdrive config yourself and put its id in `wrangler.jsonc` — deploying an already-provisioned Hyperdrive app needs no token.
+- `--skip-build` is **not supported** with `--backend cloudflare`: this backend validates the artifact the build emits (worker `vars` in `dist/ssr/wrangler.json`, the generated auth schema), so there is nothing to check without a fresh build.
+- `--project`, `--dir` and `--spa` are **not supported** with `--backend cloudflare` either, and are rejected rather than ignored: no Void project is resolved on this path, and it uploads the worker your build emits rather than a static directory.
+- Local Docker is required to build apps that use the sandbox.
+
+What it does, in order: settles the app class before any account op (v1 supports **full Void apps on the Cloudflare Workers target** -- worker-bearing apps running Void's routing, with D1/KV/R2/Queues/Hyperdrive and, on D1/SQLite, auth + ISR; framework SSR of every kind, static/SPA/SSG apps, node/bun/deno targets, and PostgreSQL apps with auth or with checked-in migrations all fail closed with guidance), pins the account and checks auth, provisions or drift-checks resources, **builds**, then gates on the artifact the build emitted — production secrets checked against the build's effective mode/envDir, the auth schema, and migration validation — then applies remote D1 migrations for SQLite apps (verifying the applied set equals the validated set and none remain pending), and finally runs `wrangler deploy` on exactly the verified artifact. Auth apps must ship checked-in migrations that produce the Better Auth schema — the managed platform's runtime auth-migration step does not run on this backend.
+
+The build deliberately comes **before** the secret, auth-schema, and migration gates, because those gates inspect the real emitted worker rather than a prediction of it. A missing secret or a bad migration surfaces after the build has run — relevant when a build is expensive or has side effects. Remote D1 migrations run only once every gate has passed, so a failed gate mutates nothing remote.
+
+`--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** — re-running creates nothing that already exists (it reads existing ids first). Notes:
+
+- **Provision is a single-operator, dev-machine action.** The lock that guards it is per local config path only; it does not coordinate across machines. Two people provisioning the same account at once could create duplicate resources. `--provision` also **fails closed in CI / non-interactive shells** unless your committed `wrangler.jsonc` already covers every resource (a provable no-op). Provision locally, commit the updated `wrangler.jsonc`, then let CI run `void deploy --backend cloudflare`.
+- **Your `wrangler.jsonc` is rewritten.** When wrangler writes the new ids, it preserves your comments but normalizes the whole file's indentation — expect that in the diff.
+- **Your `.env*` values ship as plaintext.** All four of `.env`, `.env.local`, `.env.production` and `.env.production.local` are loaded by this backend and baked into the worker's `vars` — the `.local` files included, unlike managed `void deploy`. A value also present in the shell environment is stripped back out. Move real secrets to `wrangler secret put <NAME>` so they are not committed into `wrangler.json`. Deploy warns on likely-plaintext secrets and hard-blocks on missing required secrets.
+- **First deploy of a not-yet-deployed worker:** its remote secrets can't be listed yet, so the secret gate prints the required key names and the `wrangler secret put <NAME>` commands to bootstrap them on the draft worker before deploying (or add a value to `.env` / `.env.production` and rerun).
+
+See the [Cloudflare integration guide](../integrations/cloudflare.md#deploy-to-your-own-cloudflare-account) for the full walk-through.
+
 ## Database
 
 ### `void db push`