void 0.10.13 → 0.20.1

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

@@ -1,28 +0,0 @@
-# VitePress 📝💨
-
-[![test](https://github.com/vuejs/vitepress/actions/workflows/test.yml/badge.svg?branch=main)](https://github.com/vuejs/vitepress/actions/workflows/test.yml)
-[![npm](https://img.shields.io/npm/v/vitepress/next)](https://www.npmjs.com/package/vitepress/v/next)
-[![nightly releases](https://img.shields.io/badge/nightly-releases-orange)](https://nightly.akryum.dev/vuejs/vitepress)
-[![chat](https://img.shields.io/badge/chat-discord-blue?logo=discord)](https://chat.vuejs.org)
-
----
-
-VitePress is a Vue-powered static site generator and a spiritual successor to [VuePress](https://vuepress.vuejs.org), built on top of [Vite](https://github.com/vitejs/vite).
-
-## Documentation
-
-To check out docs, visit [vitepress.dev](https://vitepress.dev).
-
-## Changelog
-
-Detailed changes for each release are documented in the [CHANGELOG](https://github.com/vuejs/vitepress/blob/main/CHANGELOG.md).
-
-## Contribution
-
-Please make sure to read the [Contributing Guide](https://github.com/vuejs/vitepress/blob/main/.github/contributing.md) before making a pull request.
-
-## License
-
-[MIT](https://github.com/vuejs/vitepress/blob/main/LICENSE)
-
-Copyright (c) 2019-present, Yuxi (Evan) You

package/skills/void/docs/node_modules/vitepress/template/api-examples.md

@@ -1,49 +0,0 @@
----
-outline: deep
----
-
-# Runtime API Examples
-
-This page demonstrates usage of some of the runtime APIs provided by VitePress.
-
-The main `useData()` API can be used to access site, theme, and page data for the current page. It works in both `.md` and `.vue` files:
-
-```md
-<script setup>
-import { useData } from 'vitepress'
-
-const { theme, page, frontmatter } = useData()
-</script>
-
-## Results
-
-### Theme Data
-<pre>{{ theme }}</pre>
-
-### Page Data
-<pre>{{ page }}</pre>
-
-### Page Frontmatter
-<pre>{{ frontmatter }}</pre>
-```
-
-<script setup>
-import { useData } from 'vitepress'
-
-const { site, theme, page, frontmatter } = useData()
-</script>
-
-## Results
-
-### Theme Data
-<pre>{{ theme }}</pre>
-
-### Page Data
-<pre>{{ page }}</pre>
-
-### Page Frontmatter
-<pre>{{ frontmatter }}</pre>
-
-## More
-
-Check out the documentation for the [full list of runtime APIs](https://vitepress.dev/reference/runtime-api#usedata).

package/skills/void/docs/node_modules/vitepress/template/index.md

@@ -1,28 +0,0 @@
-<% if (defaultTheme) { %>---
-# https://vitepress.dev/reference/default-theme-home-page
-layout: home
-
-hero:
-  name: <%= title %>
-  text: <%= description %>
-  tagline: My great project tagline
-  actions:
-    - theme: brand
-      text: Markdown Examples
-      link: /markdown-examples
-    - theme: alt
-      text: API Examples
-      link: /api-examples
-
-features:
-  - title: Feature A
-    details: Lorem ipsum dolor sit amet, consectetur adipiscing elit
-  - title: Feature B
-    details: Lorem ipsum dolor sit amet, consectetur adipiscing elit
-  - title: Feature C
-    details: Lorem ipsum dolor sit amet, consectetur adipiscing elit
----
-<% } else { %>---
-home: true
----
-<% } %>

package/skills/void/docs/node_modules/vitepress/template/markdown-examples.md

@@ -1,85 +0,0 @@
-# Markdown Extension Examples
-
-This page demonstrates some of the built-in markdown extensions provided by VitePress.
-
-## Syntax Highlighting
-
-VitePress provides Syntax Highlighting powered by [Shiki](https://github.com/shikijs/shiki), with additional features like line-highlighting:
-
-**Input**
-
-````md
-```js{4}
-export default {
-  data () {
-    return {
-      msg: 'Highlighted!'
-    }
-  }
-}
-```
-````
-
-**Output**
-
-```js{4}
-export default {
-  data () {
-    return {
-      msg: 'Highlighted!'
-    }
-  }
-}
-```
-
-## Custom Containers
-
-**Input**
-
-```md
-::: info
-This is an info box.
-:::
-
-::: tip
-This is a tip.
-:::
-
-::: warning
-This is a warning.
-:::
-
-::: danger
-This is a dangerous warning.
-:::
-
-::: details
-This is a details block.
-:::
-```
-
-**Output**
-
-::: info
-This is an info box.
-:::
-
-::: tip
-This is a tip.
-:::
-
-::: warning
-This is a warning.
-:::
-
-::: danger
-This is a dangerous warning.
-:::
-
-::: details
-This is a details block.
-:::
-
-## More
-
-Check out the documentation for the [full list of markdown extensions](https://vitepress.dev/guide/markdown).

package/skills/void/docs/node_modules/vitepress-plugin-group-icons/README.md

@@ -1,101 +0,0 @@
-# vitepress-plugin-group-icons
-
-[![Open on npmx.dev](https://npmx.dev/api/registry/badge/version/vitepress-plugin-group-icons?labelColor=080f12&color=1fa669)](https://npmx.dev/package/vitepress-plugin-group-icons)
-[![Open on npmx.dev](https://npmx.dev/api/registry/badge/license/vitepress-plugin-group-icons?labelColor=080f12&color=1fa669)](https://npmx.dev/package/vitepress-plugin-group-icons)
-[![Open on npmx.dev](https://npmx.dev/api/registry/badge/downloads-month/vitepress-plugin-group-icons?labelColor=080f12&color=1fa669)](https://npmx.dev/package/vitepress-plugin-group-icons)
-
-> Enhance code blocks features for VitePress.
-
-![vitepress-plugin-group-icons preview](https://static.yuy1n.io/vp-plugin-group-icons.png)
-
-<p align='center'>
-<a href="https://vp.yuy1n.io/">
-📜 Documentation
-</a>
-</p>
-
-<p align='center'>
-<a href="https://stackblitz.com/edit/vitepress-plugin-group-icons?file=docs%2Findex.md">
-<img src="https://developer.stackblitz.com/img/open_in_stackblitz.svg" alt="Open in StackBlitz">
-</a>
-</p>
-
-## Usage
-
-### Install
-
-```sh [npm]
-npm install vitepress-plugin-group-icons
-```
-
-```sh [yarn]
-yarn add vitepress-plugin-group-icons
-```
-
-```sh [pnpm]
-pnpm add vitepress-plugin-group-icons
-```
-
-```sh [bun]
-bun add vitepress-plugin-group-icons
-```
-
-### Configuration
-
-```ts
-// .vitepress/config.ts
-import { defineConfig } from 'vitepress'
-import { groupIconMdPlugin, groupIconVitePlugin } from 'vitepress-plugin-group-icons'
-
-export default defineConfig({
-  markdown: {
-    config(md) {
-      md.use(groupIconMdPlugin)
-    },
-  },
-  vite: {
-    plugins: [
-      groupIconVitePlugin()
-    ],
-  }
-})
-```
-
-```ts
-// .vitepress/theme/index.ts
-import Theme from 'vitepress/theme'
-import 'virtual:group-icons.css'
-
-export default Theme
-```
-
-### Usage Example
-````markdown
-::: code-group
-
-```sh [npm]
-npm install vitepress-plugin-group-icons
-```
-
-```sh [yarn]
-yarn add vitepress-plugin-group-icons
-```
-
-```sh [pnpm]
-pnpm add vitepress-plugin-group-icons
-```
-
-```sh [bun]
-bun add vitepress-plugin-group-icons
-```
-
-:::
-````
-
-## Credits
-
-- [Nuxt UI Pro](https://ui.nuxt.com/pro/prose/code-group)
-
-## License
-
-[MIT](./LICENSE) License © 2024-PRESENT [Leo](https://github.com/yuyinws)

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

@@ -1,19 +0,0 @@
-## Void
-
-This project uses [Void](https://void.cloud) — a fullstack Vite plugin + deployment platform for Cloudflare. `voidPlugin()` in `vite.config.ts` gives you file-based API routing on Hono (`routes/`), Inertia-inspired server-rendered pages with co-located loaders/actions (`pages/` + `@void/vue` or `@void/react`), auto-provisioned D1/KV/R2 bindings, first-class Drizzle ORM integration (schema in `db/schema.ts` -> `void/db` Drizzle instance -> typed routes -> typed fetch client), built-in auth, queues, cron jobs, edge caching (ISR), and one-command deploys via `npx void deploy`. For first-time setup, prefer `npx void init`; in an empty directory, install `void` first and let the interactive flow scaffold the starter with Vite+ by default, add the matching framework adapter, configure project files, handle auth, and link or create the deploy project before the first deploy. In an existing app, `void init` configures Void in place by adding missing Vite scripts and creating or patching `vite.config.*` with `voidPlugin()`. Use `void` and `@void/*` package names in source code and package manifests.
-
-Database: define Drizzle tables in `db/schema.ts`, import `db` from `void/db` and tables from `@schema`. Use `void db push` for prototyping, `void db generate` for production migrations. `drizzle-orm` and `drizzle-kit` ship with void (no extra install). Migrations live in `db/migrations/`.
-
-Env: declare every env key in `env.ts` at the project root via `defineEnv({ KEY: string(), ... })` from `void/env`. Read values via `import { env } from "void/env"`. Schema validation runs at dev start (warns) and on `void deploy` (hard error on missing prod secrets). Use `VITE_*` prefix for keys that should be exposed to client code.
-
-CI/editor prep: run `void prepare` to generate `.void/routes.d.ts`, `.void/db.d.ts`, `.void/queues.d.ts`, `.void/env.d.ts`, and `.void/tsconfig.json` without booting Vite. Run it after `npm install` in CI or a fresh clone before typechecking; `vite dev` and `vite build` regenerate these during normal workflows.
-
-Rewrites and redirects: declare static rules in `void.json` under `routing.redirects` / `routing.rewrites` / `routing.fallbacks`, or in a `public/_redirects` file. For dynamic rewrites, call `c.rewrite(path)` in a `defineMiddleware`.
-
-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/CLAUDE.md

@@ -1,221 +0,0 @@
-# void
-
-Core Vite plugin — routing, inference, migrations, CLI.
-
-## Architecture
-
-The main export `voidPlugin()` returns an array of Vite plugins. For the default Cloudflare target, this includes the `cloudflare()` plugin. For non-CF targets (`node`, `bun`, `deno`), it replaces `cloudflare()` with `nodeTargetPlugin()`:
-
-```
-# Cloudflare (default)
-voidPlugin() → [routingPlugin, migrationPlugin, cloudflare({...inferredBindings})]
-
-# Node.js / Bun / Deno
-voidPlugin() → [routingPlugin, prerenderPlugin, nodeTargetPlugin()]
-```
-
-Non-CF targets disable CF-only bindings (`void/db`, `void/kv`, `void/auth`, `void/storage`, `void/ai`, `void/env`, `void/ws`) at compile time. The `nodeTargetPlugin` provides a binding guard (compile-time errors for CF imports), a Vite dev server middleware (SSR-loads the Hono app), and a build entry generator for the target runtime.
-
-### Runtime Framework
-
-**Hono** is used as the runtime framework. The generated virtual module creates a Hono app with file-based routes and middleware. Route handlers receive a Hono `Context` object (`c`) and can use the full Hono API (`c.json()`, `c.text()`, `c.req.param()`, etc.) plus the Hono middleware ecosystem.
-
-- `defineHandler(fn)` — wraps a route handler `(c: CloudContext) => R`, returns `TypedHandler<{}, R>`
-- `defineHandler.withValidator(validators)(fn)` — validates body/query/params via Standard Schema before calling handler, returns `TypedHandler<V, R>` with phantom types for codegen
-- `defineMiddleware(fn)` — wraps Hono middleware `(c, next) => void`
-- `basicAuth(options)` — built-in Basic Auth middleware for temporary site gates; excludes Void internals under `/__void`
-- Handlers can return plain objects/strings (auto-converted via `convertReturnValue`) or use Hono's `c.json()` / `c.text()` directly.
-- Route files use **named HTTP method exports** (`export const GET`, `export const POST`, etc.) — one file per path, multiple methods per file.
-
-### Source Layout
-
-```
-src/
-  index.ts                  # Main export: voidPlugin() → Plugin[]
-  config.ts                 # readConfig(), VoidConfig, convertHeadersConfig(), redirect/header helpers
-  plugin-routing.ts         # Virtual module resolution, file watching, HMR, type codegen
-  plugin-node-target.ts     # Non-CF deploy targets (Node.js, Bun, Deno) — binding guard, dev server, build entry
-  plugin-inference.ts       # Binding inference orchestration (calls walk.ts)
-  plugin-migration.ts       # Local migration runner on dev startup
-  standard-schema.ts        # Inlined Standard Schema V1 types (no @standard-schema/spec dep)
-  routes-stub.ts            # Empty RouteMap/WebSocketRouteMap interfaces (augmented by generated routes.d.ts)
-  router/
-    parse-filename.ts       # Route filename → RouteDefinition (pure function)
-    detect-exports.ts       # Detects named HTTP method exports (GET, POST, etc.) via parseSync
-    websocket.ts            # .ws.ts scanner + DO class metadata extraction
-    scan.ts                 # Filesystem scanner using tinyglobby + export detection
-    compile.ts              # Generates Hono app code + worker entry + websocket wiring
-  codegen/
-    route-types.ts          # Generates .void/routes.d.ts (RouteMap + WebSocketRouteMap)
-    db-types.ts             # (removed — Drizzle schema is now the type source)
-    queue-types.ts          # Generates .void/queues.d.ts (QueueMap with payload types)
-  queues/
-    scan.ts                 # Queue file scanner (queues/ dir, name from filename + consumer options)
-  runtime/
-    handler.ts              # defineHandler(), defineHandler.withValidator(), defineMiddleware(), defineHead(), defineQueue()
-    queues.ts               # QueueMap stub interface + typed `queues` proxy using env.QUEUE_*
-    validator.ts            # runValidation() — Standard Schema body/query/params validation
-    response.ts             # convertReturnValue() — return → Response
-    fetch.ts                # Typed fetch client for void/client
-    fetch-stream.ts         # SSE stream consumer (fetchStream) for void/client
-    ws.ts                   # defineRoom(), defineWebSocket(), typed connect() client
-    ws-server.ts            # DO runtime helpers for generated websocket routes
-    ai.ts                   # AI proxy — auto-detects backend (service binding / HTTPS / direct binding)
-    db.ts                   # Drizzle D1 instance (auto-wired with user schema via virtual module)
-  inference/
-    walk.ts                 # AST walking with vite's parseSync + estree-walker
-  migrations/
-    runner.ts               # Applies pending migrations via drizzle-orm's programmatic migrate()
-    collect.ts              # Reads .sql files from db/migrations/ dir, sorted by filename
-    validate.ts             # Destructive-op detection + pragma enforcement
-  cli/
-    cli.ts                  # CLI entry: `void deploy|link|login`
-    deploy.ts               # Orchestrator: build → collect/validate migrations → package → upload
-    project.ts              # Reads/creates .void/project.json (projectId + slug only)
-    auth.ts                 # Token read/save + runLogin() (local server + browser OAuth)
-    login.ts                # Login command UI (@clack/prompts)
-    package.ts              # Packages dist/ into FormData (worker + assets + migrations + manifest)
-    agents.ts               # Shared agent configs, detection, MCP config targets
-    client.ts               # HTTP client for platform API
-    types.ts                # DeployManifest, MigrationMeta types
-```
-
-### Key Design Decisions
-
-- **Import redirection**: The routing plugin's `resolveId` hook redirects bare `"void"` imports to `void/handler` (the lightweight subpath). Without this, route files pull the entire plugin (vite, @cloudflare/vite-plugin, lightningcss) into the Worker bundle. Uses `import.meta.resolve()` to compute absolute paths at plugin init.
-- **Pre-resolved paths in codegen**: Generated virtual module code uses absolute paths for `hono` and `void/response` (resolved via `import.meta.resolve()`). Virtual modules have no filesystem location, so bare specifiers can't resolve from them.
-- **CF plugin API**: Worker config (`main`, `d1_databases`, `kv_namespaces`, `r2_buckets`) goes inside the `config` option of `cloudflare()`, NOT as top-level properties. `persistState` takes `{ path: string }`, not a raw string. The `config` option uses a **function form** `(resolved: WorkerConfig) => Partial<WorkerConfig>` so that bindings from the user's `wrangler.json` (if present) take precedence over inferred placeholder bindings.
-- **Migration DB path**: Miniflare stores D1 data at a deterministic path computed from the `database_id` using HMAC-SHA256. The `getMiniflareDatabasePath()` function in `migrations/runner.ts` replicates this algorithm so migrations target `<persist-root>/v3/d1/miniflare-D1DatabaseObject/<hash>.sqlite` (for example `.void/v3/...` in default/class-A mode and `.wrangler/state/v3/...` in class-B/C framework mode).
-- **Drizzle-first database**: Schema is defined in `db/schema.ts` (Drizzle table definitions). `void/db` exports a Drizzle D1 instance. `@schema` is an auto-configured alias for `db/schema.ts`. Migrations live in `db/migrations/`. CLI commands: `void db push` (prototype), `void db generate` (create migration files), `void db migrate` (apply locally). `drizzle-orm` and `drizzle-kit` ship with void.
-- **Journal coherence invariant**: `db/migrations/*.sql` and `db/migrations/meta/_journal.json` must stay in sync — every `.sql` file has a matching journal entry (by `tag`) and vice versa. `assertJournalCoherence` in `src/migrations/validate.ts` is the gate, called from `deploy`, `db status`, `db migrate`, and `db reset`. The two CLI commands that mutate migration state — `void gen migration` and `void db rename-migrations` — are responsible for keeping the journal coherent themselves: the first appends a new entry when writing a file (failing loud if the journal is missing — run `drizzle-kit generate` first), the second rewrites `tag` values alongside the file renames and also renames the matching `meta/<prefix>_snapshot.json` (with byte-level rollback on failure). `gen migration` additionally copies the previous `meta/<idx:04d>_snapshot.json` forward to the new idx so drizzle-kit's drop/rollback tooling keeps working on mixed hand-written + drizzle projects; projects without prior snapshots are skipped silently. Drift will fail loudly before touching any remote DB. Motivated by [void-sdk/void#6](https://github.com/void-sdk/void/issues/6), where an orphan scaffolded `.sql` file half-applied against D1 and wedged the deploy.
-
-### Self-Host AI + ISR
-
-Two features need extra wiring on a self-hosted `vite build && wrangler deploy` (no Void platform proxy/dispatch in front of the worker). Both are inert on managed `void deploy`.
-
-- **`ai.gateway` config + `__VOID_AI_GATEWAY` var** — `void.json`'s `ai.gateway` (validated in `config.ts` as `ai?: { gateway?: string }`; non-empty string, `additionalProperties: false`) names a Cloudflare AI Gateway in the user's own account. `mergeBindings` (`index.ts`): (1) injects `{ ai: { binding: 'AI' } }`, but only when `shouldBindWorkersAi()` is true — the app infers `needsAI`, `command === 'build'`, and neither the resolved root wrangler config nor the result already declares an `ai` binding (so it never clobbers a user's own `ai` binding); (2) emits `vars.__VOID_AI_GATEWAY = config.ai.gateway` whenever `config.ai?.gateway` is set. At runtime, `runtime/ai.ts` `resolveBackend()` selects the direct backend (Priority 3) when `env.AI` is present and no `__VOID_PROXY`/`__VOID_TOKEN` exists. `ai.run/stream/image` hit Workers AI directly; `ai.provider().fetch()` routes through the user's own gateway via `directAi.gateway(__VOID_AI_GATEWAY).getUrl(provider)` with the provider key from the user's own secret (`resolveProviderKey` → `env[PROVIDER_KEY_MAP[provider]]`), returning HTTP 501 if `__VOID_AI_GATEWAY` is unset. No cross-tenant metering on this path. The runtime reads `env.AI` **by name** — a custom-named root AI binding is not honored.
-- **Internal-binding leak check permits exactly `__VOID_AI_GATEWAY`** — the integration guard (`test/integration/kitchen-sink-build.test.ts`) that asserts no `__VOID_*` var reaches `dist/ssr/wrangler.json` explicitly excludes `__VOID_AI_GATEWAY`, because it is a legitimate, non-credential runtime var (unlike the credential keys in `INTERNAL_ENV_KEYS`, which are stripped).
-- **`ISR_CACHE` self-host requirement** — self-host ISR (`runtime/isr-cache.ts`, `runtime/isr.ts`) reads `env.ISR_CACHE` (a `KVNamespace`) + `env.__VOID_ISR_DEPLOYMENT_ID`. Unlike D1/KV/R2, `ISR_CACHE` is **not** auto-injected (a KV binding needs a real namespace id), so the user must create the namespace and declare it as `ISR_CACHE` in their root wrangler config. `routing.revalidate` (void.json) and per-page `export const revalidate` are merged by `collectRevalidate` (`isr-config.ts`) and baked as `__VOID_ISR_REVALIDATE`. On-demand `revalidate()` on self-host purges the worker's own KV (global) plus the local-colo `caches.default` edge variants only.
-
-### Package Exports
-
-| Subpath          | What                                                                                                                                  |
-| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
-| `void`           | `voidPlugin()` named export + `defineHandler` + `defineMiddleware` + `basicAuth` + `defineHead` + `defineQueue` + `CloudContext` type |
-| `void/handler`   | `defineHandler()`, `defineHandler.withValidator()`, `defineMiddleware()`, `basicAuth()`, `defineHead()`, types                        |
-| `void/response`  | `convertReturnValue()`                                                                                                                |
-| `void/validator` | `runValidation()`, `ValidatorSlots`, `HandlerInput` types                                                                             |
-| `void/routes`    | Empty `RouteMap` + `WebSocketRouteMap` stubs (augmented by generated `routes.d.ts`)                                                   |
-| `void/client`    | Typed `fetch()` client + `fetchStream()` SSE consumer + `FetchError`                                                                  |
-| `void/ws`        | `defineRoom()`, `defineWebSocket()`, typed `connect()`, and WebSocket context types                                                   |
-| `void/db`        | `db` Drizzle D1 instance (auto-wired with user schema) + `createDb()` for custom D1 bindings                                          |
-| `void/queues`    | `queues` typed proxy + `QueueMap` stub interface (augmented by generated `queues.d.ts`)                                               |
-| `void/ai`        | `ai` proxy — `ai.run()`, `ai.stream()`, `ai.models()` with auto-detected backend (service binding / HTTPS / direct)                   |
-| `void/log`       | `logger.error/warn/info(msg, fields?)` — emits stringified JSON to `console.*` so Cloudflare Tail captures level + msg                |
-| `void/env`       | `defineEnv()`, typed `env` proxy, built-in schema helpers (`string`, `number`, `oneOf`, …) + global Cloudflare types                  |
-
-The CLI binary is at `dist/cli/cli.mjs` (declared in `bin` field of package.json).
-
-### Internal Staging Projects
-
-Internal-only staging is selected per linked project with `.void/project.json`:
-
-```json
-{
-  "projectId": "proj_...",
-  "slug": "my-app",
-  "voidInternalStaging": true
-}
-```
-
-A pre-link file containing only `{ "voidInternalStaging": true }` is valid for Void platform developers who need `void auth login` or `void project link` to target staging before a project is linked.
-
-When `voidInternalStaging` is true:
-
-- **Token**: reads/writes `stagingToken` in `~/.void/config.json` instead of `token`
-- **API URL**: defaults to `https://api.void.cloud` (prod); when staging is active, uses `https://api.staging.void.cloud` (unless overridden by `VOID_API_URL` or `api` config field)
-- **Site domain**: uses `staging.void.app` for generated project URLs
-- **Proxy**: injects staging proxy bindings for local dev AI and prerendering
-
-Build output uses `.mjs` / `.d.mts` extensions (`vp pack` / tsdown default).
-
-### Route Filename Parsing Rules
-
-Applied in order to a path relative to `routes/`:
-
-1. Strip extension (`.ts`, `.js`, `.mts`, `.mjs`)
-2. Strip env suffix (`.dev`, `.prod`) and record it on `RouteDefinition.env`
-3. Strip trailing `index`
-4. Remove route group dirs `(groupname)`
-5. Convert `[param]` → `:param`, `[...param]` → `:param{.+}`, `[...]` → `*`
-6. Prefix with `/`
-
-HTTP methods are determined by **named exports** in each file (detected by `detect-exports.ts` via `parseSync`), not by filename suffixes. Files/dirs starting with `_` are ignored by the scanner.
-
-The recorded `env` is enforced by `isRouteEnabledForEnvironment()`. The scanners take an optional `environment` (`'dev' | 'prod'`); when it is omitted no filtering happens. `dev` is the Vite dev server, `prod` is every build, `void deploy`, and `vite preview`. A dev-only route is absent from the production bundle, types, and generated route/WebSocket config. Two paths do not follow it: `void prepare` boots no Vite, passes no `environment`, and so generates types for both environments; and `inferProjectBindings()` (`plugin-inference.ts`) globs source files without parsing route filenames, so a `void/storage` import in a `.dev.ts` route still emits and provisions an R2 binding in production. Over-emitting is the deliberate safe direction — under-emitting would drop a binding the running code needs — and the environment is not knowable at the `inferProjectBindings()` call site anyway (`index.ts:678`, versus `routeEnvironment` at `index.ts:1324`). The suffix is honoured in `routes/` only, not in `pages/`, `middleware/`, `crons/`, or `queues/`.
-
-## Code Generation (`void gen`)
-
-Rails/Laravel-style scaffolding commands for common boilerplate:
-
-| Command                                            | Creates                                                     |
-| -------------------------------------------------- | ----------------------------------------------------------- |
-| `void gen model <name> [cols...]`                  | Drizzle table in `db/schema/` + barrel export + CRUD routes |
-| `void gen migration <name>`                        | Empty migration file with auto-numbered prefix              |
-| `void gen route <path> [--methods get,post,...]`   | Route file with `defineHandler` exports                     |
-| `void gen middleware <name>`                       | Numbered middleware file with `defineMiddleware`            |
-| `void gen ssr [--react\|--vue\|--svelte\|--solid]` | SSR entry + client entry + App component                    |
-| `void gen cron <name>`                             | Cron job file with `defineScheduled` in `crons/`            |
-| `void gen queue <name>`                            | Queue consumer file with `defineQueue`                      |
-
-Column types for `gen model`: `string`, `text`, `datetime` → `text()`, `integer` → `integer()`, `boolean` → `integer({ mode: "boolean" })`, `real` → `real()`. Append `?` for nullable (omits `.notNull()`).
-
-`gen model` creates Drizzle table definitions in `db/schema/` and updates the `db/schema.ts` barrel export. Auto-detects your validation library (valibot, zod, or arktype) from `package.json`. If none is found, prompts to choose one or skip validation.
-
-Source: `src/cli/gen-args.ts` (arg parsing), `src/cli/gen.ts` (command runner). Tests: `test/unit/gen-args.test.ts`, `test/unit/gen.test.ts`.
-
-## Coding Agent Integration
-
-Void ships with first-class support for coding agents (Claude Code, Cursor, Codex, etc.):
-
-- **`AGENT_PROMPT.md`** — compressed reference prompt shipped in the `void` npm package. Covers project structure, routing, DB, auth, typed fetch, KV/storage/queues/cron, CLI, and deployment.
-- **`skills/`** — Claude Code skills shipped in the npm package:
-  - `void` — unified app + CLI skill covering project architecture, runtime APIs, deployment flows, and CLI operations (deploy, db, gen, secrets, domains, projects) with lazy-loaded reference files.
-  - `migrate-cloudflare-to-void` — guides migration from `@cloudflare/vite-plugin` to `void`.
-- **`docs/`** — all 23 docs markdown files are included in the npm package at `node_modules/void/docs/`.
-- **`void init --agents`** — runs all agent setup steps from a single detection/selection pass: injects Void instructions with versioned markers, symlinks skills from the `void` package, and writes MCP config (or prints manual commands/JSON for unsupported/generic agents).
-- **`void init` in an empty directory** — scaffolds a Pages-mode starter (React, Vue, Svelte, or Solid), then lets you pick D1, PostgreSQL, or Static Pages before running the same setup flow.
-
-Agent instructions use versioned markers (`<!--injected-by-void-v0.0.1-->` / `<!--/injected-by-void-->`) for safe update-in-place across version upgrades.
-
-## Tests
-
-| Test file                                   | Covers                                                         |
-| ------------------------------------------- | -------------------------------------------------------------- |
-| `test/unit/parse-filename.test.ts`          | Route filename parsing (21 tests)                              |
-| `test/unit/scan.test.ts`                    | Filesystem scanning + queue consumers (13 tests)               |
-| `test/unit/detect-exports.test.ts`          | Named HTTP method export detection (8 tests)                   |
-| `test/unit/compile.test.ts`                 | Code generation + queue routes (10 tests)                      |
-| `test/unit/response.test.ts`                | Return value → Response (8 tests)                              |
-| `test/unit/inference.test.ts`               | AST-based binding inference + queues + AI (19 tests)           |
-| `test/unit/fetch-stream.test.ts`            | SSE stream consumer (fetchStream) (5 tests)                    |
-| `test/unit/validate-migrations.test.ts`     | Destructive-op detection + pragma (12 tests)                   |
-| `test/unit/collect-migrations.test.ts`      | Migration file collection (4 tests)                            |
-| `test/unit/validator.test.ts`               | Standard Schema validation runtime (8 tests)                   |
-| `test/unit/validator-real-schemas.test.ts`  | Real schema validation (zod/valibot/arktype) (16 tests)        |
-| `test/unit/define-handler.test.ts`          | defineHandler + middleware composition (18 tests)              |
-| `test/unit/fetch.test.ts`                   | Typed fetch client (9 tests)                                   |
-| `test/unit/ws.test.ts`                      | Typed websocket client (3 tests)                               |
-| `test/unit/route-types.test.ts`             | Route type codegen output (6 tests)                            |
-| `test/unit/route-type-extraction.test.ts`   | Type extraction pipeline (Serialize + ExtractInput) (14 tests) |
-| `test/unit/db.test.ts`                      | Drizzle D1 instance + schema wiring (25 tests)                 |
-| `test/unit/queue-types.test.ts`             | Queue type codegen output (3 tests)                            |
-| `test/unit/plugin-node-target.test.ts`      | Node target plugin — binding guard, plugin creation (5 tests)  |
-| `test/integration/node-target.test.ts`      | Node app playground — dev server + production build (5 tests)  |
-| `test/integration/queue-playground.test.ts` | Queue send → consumer → KV round-trip (1 test)                 |
-
-## Pitfalls / Things That Broke
-
-- **`__VOID_ISR_DEPLOYMENT_ID` must be a compile-time literal.** `router/compile.ts` stringifies `crypto.randomUUID()` once at build time (`export const __VOID_ISR_DEPLOYMENT_ID = "..."`, exactly like `__VOID_BUILD_KEY`) so every isolate of a deployment shares one id. A bare runtime `crypto.randomUUID()` per-isolate in the emitted source would mint a fresh id per isolate, so the edge-cache key (`handleIsr`'s `deploymentId` option) and the KV key (`env.__VOID_ISR_DEPLOYMENT_ID`, also used by the `revalidate()` purge path) would disagree — breaking cache reads and on-demand purge.
-- **Self-host ISR requires a user-declared `ISR_CACHE` KV.** There is no `id: 'local'` injection for it: a placeholder id is fine for miniflare-backed dev but breaks a real `wrangler deploy`, which rejects an unknown namespace id. The user creates the namespace and binds it as `ISR_CACHE`; `readIsrCache`/`writeIsrCache` fail open to a live render when it is absent.
-- **Workers AI binding injection is `command === 'build'`-gated.** `shouldBindWorkersAi()` only injects `{ ai: { binding: 'AI' } }` on build, because dev/miniflare has no local Workers AI emulation — `void dev` AI still routes through the Void proxy (P2 `__VOID_TOKEN` path) and needs `void auth login`.

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

@@ -1,90 +0,0 @@
-# void
-
-Vite plugin and CLI for building and deploying apps on Void.
-
-## What It Covers
-
-- file-based API routes from `routes/`
-- Pages mode from `pages/`
-- typed Drizzle access via `void/db`
-- `crons/` and `queues/`
-- URL redirects, rewrites, and fallbacks (`void.json` / `public/_redirects`, plus `c.rewrite()` from middleware)
-- binding inference for D1, KV, R2, AI, auth, and queues
-- remote bindings for local development
-- deploy packaging for Void-hosted apps, static sites, and supported meta-frameworks
-
-## Quick Start
-
-Install the Void CLI:
-
-```bash
-npm install -D void
-```
-
-If you run `void init` in an empty directory, the scaffold flow adds the matching Pages adapter and Vite+ by default.
-
-Then run `npx void init`. In an empty directory, the full interactive flow can scaffold a starter, configure local project files, log you in, and link or create your Void project so the next step is just `npx void deploy`. In an existing app, it configures Void in place by adding missing Vite scripts and creating or patching `vite.config.*` with `voidPlugin()`.
-
-```ts
-// vite.config.ts
-import { defineConfig } from 'vite';
-import { voidPlugin } from 'void';
-
-export default defineConfig({
-  plugins: [voidPlugin()],
-});
-```
-
-## Core Surfaces
-
-- `voidPlugin()` — Vite integration, routing, pages mode, codegen, migrations, packaging
-- `void prepare` — generate `.void` artifacts for CI, editors, and fresh clones
-- `void auth login` — platform auth
-- `void deploy` — build and deploy
-- `void db *` — local DB and migration commands
-- `void project *` — link, status, logs, requests, rollback, delete
-
-Runtime helpers include:
-
-- `defineHandler`
-- `defineMiddleware`
-- `basicAuth`
-- `defineScheduled`
-- `defineQueue`
-- `void/db`
-- `void/kv`
-- `void/storage`
-- `void/ai`
-- `void/isr`
-- `void/client`
-- `void/auth`
-
-## Supported App Shapes
-
-- native Void apps (`routes/`, `pages/`, `middleware/`, `crons/`, `queues/`)
-- supported meta-framework deploy targets:
-  - TanStack Start
-  - React Router
-  - SvelteKit
-  - Nuxt
-  - Astro
-- static and SPA deploys
-- non-Cloudflare server targets (`node`, `bun`, `deno`)
-
-There is Vinext-specific source in the repo, but it is intentionally on hold and not part of the current public support matrix.
-
-## Database Model
-
-`void/db` is Drizzle-first.
-
-- D1 is the default managed database target
-- framework apps can opt into PostgreSQL mode
-- route types, DB types, and queue types are generated into `.void/*.d.ts`
-
-## Documentation
-
-Full docs live at [void.cloud/guide](https://void.cloud/guide).
-
-## License
-
-MIT