void 0.10.12 → 0.20.0

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

@@ -1,191 +0,0 @@
-<p align="center">
-  <img src="logo.svg" width="200px" align="center" alt="Zod logo" />
-  <h1 align="center">Zod</h1>
-  <p align="center">
-    TypeScript-first schema validation with static type inference
-    <br/>
-    by <a href="https://x.com/colinhacks">@colinhacks</a>
-  </p>
-</p>
-<br/>
-
-<p align="center">
-<a href="https://github.com/colinhacks/zod/actions?query=branch%3Amain"><img src="https://github.com/colinhacks/zod/actions/workflows/test.yml/badge.svg?event=push&branch=main" alt="Zod CI status" /></a>
-<a href="https://opensource.org/licenses/MIT" rel="nofollow"><img src="https://img.shields.io/github/license/colinhacks/zod" alt="License"></a>
-<a href="https://www.npmjs.com/package/zod" rel="nofollow"><img src="https://img.shields.io/npm/dw/zod.svg" alt="npm"></a>
-<a href="https://discord.gg/KaSRdyX2vc" rel="nofollow"><img src="https://img.shields.io/discord/893487829802418277?label=Discord&logo=discord&logoColor=white" alt="discord server"></a>
-<a href="https://github.com/colinhacks/zod" rel="nofollow"><img src="https://img.shields.io/github/stars/colinhacks/zod" alt="stars"></a>
-</p>
-
-<div align="center">
-  <a href="https://zod.dev/api">Docs</a>
-  <span>&nbsp;&nbsp;•&nbsp;&nbsp;</span>
-  <a href="https://discord.gg/RcG33DQJdf">Discord</a>
-  <span>&nbsp;&nbsp;•&nbsp;&nbsp;</span>
-  <a href="https://twitter.com/colinhacks">𝕏</a>
-  <span>&nbsp;&nbsp;•&nbsp;&nbsp;</span>
-  <a href="https://bsky.app/profile/zod.dev">Bluesky</a>
-  <br />
-</div>
-
-<br/>
-<br/>
-
-### [Read the docs →](https://zod.dev/api)
-
-<br/>
-<br/>
-
-## What is Zod?
-
-Zod is a TypeScript-first validation library. Define a schema and parse some data with it. You'll get back a strongly typed, validated result.
-
-```ts
-import * as z from "zod";
-
-const User = z.object({
-  name: z.string(),
-});
-
-// some untrusted data...
-const input = {
-  /* stuff */
-};
-
-// the parsed result is validated and type safe!
-const data = User.parse(input);
-
-// so you can use it with confidence :)
-console.log(data.name);
-```
-
-<br/>
-
-## Features
-
-- Zero external dependencies
-- Works in Node.js and all modern browsers
-- Tiny: `2kb` core bundle (gzipped)
-- Immutable API: methods return a new instance
-- Concise interface
-- Works with TypeScript and plain JS
-- Built-in JSON Schema conversion
-- Extensive ecosystem
-
-<br/>
-
-## Installation
-
-```sh
-npm install zod
-```
-
-<br/>
-
-## Basic usage
-
-Before you can do anything else, you need to define a schema. For the purposes of this guide, we'll use a simple object schema.
-
-```ts
-import * as z from "zod";
-
-const Player = z.object({
-  username: z.string(),
-  xp: z.number(),
-});
-```
-
-### Parsing data
-
-Given any Zod schema, use `.parse` to validate an input. If it's valid, Zod returns a strongly-typed _deep clone_ of the input.
-
-```ts
-Player.parse({ username: "billie", xp: 100 });
-// => returns { username: "billie", xp: 100 }
-```
-
-**Note** — If your schema uses certain asynchronous APIs like `async` [refinements](https://zod.dev/api#refinements) or [transforms](https://zod.dev/api#transforms), you'll need to use the `.parseAsync()` method instead.
-
-```ts
-const schema = z.string().refine(async (val) => val.length <= 8);
-
-await schema.parseAsync("hello");
-// => "hello"
-```
-
-### Handling errors
-
-When validation fails, the `.parse()` method will throw a `ZodError` instance with granular information about the validation issues.
-
-```ts
-try {
-  Player.parse({ username: 42, xp: "100" });
-} catch (err) {
-  if (err instanceof z.ZodError) {
-    err.issues;
-    /* [
-      {
-        expected: 'string',
-        code: 'invalid_type',
-        path: [ 'username' ],
-        message: 'Invalid input: expected string'
-      },
-      {
-        expected: 'number',
-        code: 'invalid_type',
-        path: [ 'xp' ],
-        message: 'Invalid input: expected number'
-      }
-    ] */
-  }
-}
-```
-
-To avoid a `try/catch` block, you can use the `.safeParse()` method to get back a plain result object containing either the successfully parsed data or a `ZodError`. The result type is a [discriminated union](https://www.typescriptlang.org/docs/handbook/2/narrowing.html#discriminated-unions), so you can handle both cases conveniently.
-
-```ts
-const result = Player.safeParse({ username: 42, xp: "100" });
-if (!result.success) {
-  result.error; // ZodError instance
-} else {
-  result.data; // { username: string; xp: number }
-}
-```
-
-**Note** — If your schema uses certain asynchronous APIs like `async` [refinements](https://zod.dev/api#refinements) or [transforms](https://zod.dev/api#transforms), you'll need to use the `.safeParseAsync()` method instead.
-
-```ts
-const schema = z.string().refine(async (val) => val.length <= 8);
-
-await schema.safeParseAsync("hello");
-// => { success: true; data: "hello" }
-```
-
-### Inferring types
-
-Zod infers a static type from your schema definitions. You can extract this type with the `z.infer<>` utility and use it however you like.
-
-```ts
-const Player = z.object({
-  username: z.string(),
-  xp: z.number(),
-});
-
-// extract the inferred type
-type Player = z.infer<typeof Player>;
-
-// use it in your code
-const player: Player = { username: "billie", xp: 100 };
-```
-
-In some cases, the input & output types of a schema can diverge. For instance, the `.transform()` API can convert the input from one type to another. In these cases, you can extract the input and output types independently:
-
-```ts
-const mySchema = z.string().transform((val) => val.length);
-
-type MySchemaIn = z.input<typeof mySchema>;
-// => string
-
-type MySchemaOut = z.output<typeof mySchema>; // equivalent to z.infer<typeof mySchema>
-// number
-```

package/skills/void/docs/node_modules/void/skills/migrate-vite-cloudflare-to-void/SKILL.md

@@ -1,175 +0,0 @@
----
-name: migrate-cloudflare-to-void
-description: Migrate an existing Vite app using @cloudflare/vite-plugin to Vite + void. Use when a project already runs on Cloudflare Workers but needs Void file-based routes, inferred bindings, and void deploy workflow.
----
-
-# Migrate Vite + Cloudflare Plugin to Void
-
-## When to use
-
-Use this skill when the user has an existing Vite app with `@cloudflare/vite-plugin` and wants to migrate to `void` with minimal breakage.
-
-Do not use this for greenfield apps started via `npm install -D void` + `npx void init`.
-
-## Inputs to gather first
-
-Read these files before editing:
-
-- `package.json`
-- `vite.config.*`
-- `wrangler.jsonc` (if present)
-- Current worker entrypoint (`src/worker.*`, `src/index.*`, etc.)
-- Any existing API handlers and migration SQL files
-
-Confirm:
-
-- existing routes/endpoints and HTTP methods
-- bindings currently used (`DB`, `KV`, `R2`, etc.)
-- whether the app uses framework SSR or only SPA + API
-
-## Migration workflow
-
-1. Update dependencies
-
-- Remove `@cloudflare/vite-plugin` if it is only used for runtime/deploy.
-- Add `void`.
-- Keep existing framework plugins (React/Vue/Svelte/etc.).
-
-2. Update Vite config
-
-- Replace `cloudflare(...)` plugin usage with `voidPlugin()`.
-- Keep plugin order stable unless there is a known conflict.
-- Keep unrelated Vite settings unchanged.
-
-Target shape:
-
-```ts
-import { defineConfig } from 'vite';
-import { voidPlugin } from 'void';
-
-export default defineConfig({
-  plugins: [voidPlugin()],
-});
-```
-
-3. Migrate API surface to file-based routes
-
-- Create `routes/` if missing.
-- Convert each existing endpoint into route files:
-  - `routes/api/users.get.ts`
-  - `routes/api/users.post.ts`
-  - `routes/api/users/[id].get.ts`
-- Use `defineHandler` from `void`.
-- If there is shared logic, move it into regular modules and import from route files.
-
-4. Migrate middleware
-
-- Move request-wide middleware to `middleware/*.ts`.
-- Export with `defineMiddleware`.
-- Preserve behavior order by filename prefix when needed (`01.auth.ts`, `02.logger.ts`).
-
-5. Preserve bindings with Void conventions
-
-- Keep Cloudflare-style uppercase names on `c.env` (`DB`, `KV`, `STORAGE`, etc.).
-- Remove manual binding config from Vite plugin config where Void now infers usage.
-- Ensure route code actually references required bindings so inference can detect them.
-
-6. Migrations
-
-- Place SQL files in `migrations/` (sorted by filename).
-- Keep destructive operations gated by explicit pragma if needed.
-- If old migrations live elsewhere, copy/rename into this directory with stable ordering.
-
-7. Deploy workflow migration
-
-- Replace old deploy instructions with:
-  - `void auth login`
-  - `void deploy`
-- If CI must target a specific project, use:
-  - `void deploy --project <slug>`
-  - or `VOID_PROJECT=<slug> void deploy`
-
-8. Post-migration cleanup (remove obsolete Wrangler wiring)
-
-- If the app no longer uses direct Wrangler workflows, remove `wrangler.jsonc`.
-- Remove direct `wrangler` dependency/devDependency from `package.json` when it is only used for old deploy/dev scripts.
-- Remove or rewrite npm scripts that call `wrangler` directly (for example old deploy/publish scripts).
-- Keep Wrangler only if the project still has explicit non-Void workflows that require it.
-
-## Routing behavior reference (use during file conversion)
-
-Apply these filename rules exactly when mapping old handlers to `routes/`:
-
-1. Extension and suffix parsing order
-
-- Strip extension (`.ts`, `.js`, `.mts`, `.mjs`).
-- Strip env suffix (`.dev`, `.prod`).
-- Strip HTTP method suffix (`.get`, `.post`, `.put`, `.delete`, `.patch`).
-- Strip trailing `index` segment.
-- Remove route group segments `(group-name)` from URL path.
-
-2. Method mapping
-
-- `users.get.ts` matches only `GET /users`.
-- `users.post.ts` matches only `POST /users`.
-- `users.ts` matches all methods.
-- Split multi-method handlers into one file per method when preserving behavior matters.
-
-3. Dynamic and catch-all params
-
-- `[id]` -> `:id`
-- `[...slug]` -> catch-all named param
-- `[...]` -> catch-all unnamed fallback
-- Use folder nesting for multiple params: `routes/api/org/[org]/repo/[repo].get.ts`.
-
-4. Route groups and organization
-
-- Directories like `(internal)` are for code organization only and do not appear in URL.
-- Use them when reorganizing large route sets without changing public paths.
-
-5. Ignored files
-
-- Files or directories starting with `_` are ignored by route scanner.
-- Do not place active handlers under `_legacy`, `_draft`, etc.
-
-6. Middleware behavior
-
-- Middleware files live in `middleware/` and run in filename order.
-- Prefix numerically if order is important (`01.auth.ts`, `02.logger.ts`).
-
-7. Concrete mapping examples
-
-- `src/worker.ts` handling `GET /api/users/:id` -> `routes/api/users/[id].get.ts`
-- single handler switching on method for `/api/users` -> `routes/api/users.get.ts` and `routes/api/users.post.ts`
-- legacy `GET /health` endpoint -> `routes/health.get.ts`
-
-## Verification checklist
-
-Run and validate:
-
-1. `npm run dev` (or project dev command)
-2. Exercise representative API routes locally.
-3. `npm run build`
-4. `void deploy` and verify live URL responds.
-5. Confirm no deploy-critical scripts still depend on `wrangler`.
-
-In the Void deploy output, verify:
-
-- worker modules uploaded
-- static assets uploaded
-- migrations applied (if present)
-
-## Common migration pitfalls
-
-- Importing from the main `void` runtime in worker route files when a lighter handler import is expected by tooling.
-- Forgetting to split method-specific handlers (`GET`/`POST`) into filename suffixes.
-- Keeping old custom worker entry wiring that conflicts with generated route runtime.
-- Binding names changed to lowercase (`db`) instead of expected uppercase (`DB`), breaking inference/provisioning.
-
-## Deliverable format
-
-When applying this migration, produce:
-
-1. A change summary grouped by config/routes/migrations/CI.
-2. A list of moved or newly created route files.
-3. Exact commands to run locally and in CI.

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

@@ -1,76 +0,0 @@
----
-name: void
-description: Void skill for app development and CLI operations. Use this skill to route user requests to the appropriate bundled Void docs.
----
-
-# Void Skill
-
-This skill is a router. Open the minimum relevant docs files under `docs/` and execute.
-
-Docs in this skill are bundled from `docs/` during `void` package build and live at:
-
-- `skills/void/docs/**/*.md`
-
-## Command Naming
-
-Use `void` in examples and commands in this skill. For first-time setup, prefer `void init` followed by `void deploy`; in an empty directory, install `void` first and let `void init` add the matching Pages adapter and starter dependencies with Vite+ as the default scaffold toolchain. In an existing app, `void init` configures Void in place by adding missing Vite scripts and creating or patching `vite.config.*` with `voidPlugin()`. `void init` can also handle auth and project linking interactively.
-
-Use `void` and `@void/*` in code examples and package manifests.
-
-## No-Args Behavior
-
-If invoked without a concrete task, do a brief app status check and report:
-
-1. App type (`void`, `framework`, `spa`, `static`) using `docs/app-types.md` criteria.
-2. Backend feature usage (`routes/`, `pages/`, `middleware/`, `migrations/`, `crons/`, `queues/`, SSR entries).
-3. Runtime signals (`void/db`, `void/kv`, `void/storage`, queue usage).
-4. Auth signals (`void/auth`, `auth` client imports, OAuth env vars).
-5. Project linkage (`.void/project.json`) and config readiness (`void.json`, tsconfig extends).
-6. Optional health checks (`void auth whoami`, `void db status` when relevant).
-
-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`                                       |
-| 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
-
-- For any task involving running `void` commands — including checking status, managing secrets, viewing logs, or deploying — open `docs/reference/cli.md` FIRST. Do not guess command syntax.
-- Never guess or infer `void` CLI command names or flags. Always consult `docs/reference/cli.md` for the exact command before running it.
-- For multi-topic tasks, combine only the needed doc files.
-- If docs and memory differ, follow docs.
-- **Env vars:** When the project has `env.ts`, the canonical access pattern is `import { env } from "void/env"`. Declare every env key in `env.ts` via `defineEnv({...})` so values are typed and validated. Do not introduce ad-hoc `process.env.X` or untyped `c.env.X` access in new code — add the key to `env.ts` first.

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

@@ -1,7 +0,0 @@
-# `/void` Command Flow
-
-1. Open `SKILL.md`.
-2. If no task/arguments are provided, run the brief app status check from `SKILL.md`.
-3. If a task is provided, route to the smallest relevant set of `docs/*.md` files.
-4. For CLI syntax and flags, always use `docs/cli.md`.
-5. Execute, verify, and report concise next actions.

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

@@ -1,85 +0,0 @@
-# `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.