void 0.1.6 → 0.7.0

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

@@ -0,0 +1,20 @@
+# Vite ⚡
+
+> Next Generation Frontend Tooling
+
+- 💡 Instant Server Start
+- ⚡️ Lightning Fast HMR
+- 🛠️ Rich Features
+- 📦 Optimized Build
+- 🔩 Universal Plugin Interface
+- 🔑 Fully Typed APIs
+
+Vite (French word for "quick", pronounced [`/viːt/`](https://cdn.jsdelivr.net/gh/vitejs/vite@main/docs/public/vite.mp3), like "veet") is a build tool that aims to provide a faster and leaner development experience for modern web projects. It consists of two major parts:
+
+- A dev server that provides [rich feature enhancements](https://vite.dev/guide/features) over [native ES modules](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules), for example extremely fast [Hot Module Replacement (HMR)](https://vite.dev/guide/features#hot-module-replacement).
+
+- A build command that bundles your code with [Rolldown](https://rolldown.rs), pre-configured to output highly optimized static assets for production.
+
+In addition, Vite is highly extensible via its [Plugin API](https://vite.dev/guide/api-plugin.html) and [JavaScript API](https://vite.dev/guide/api-javascript.html) with full typing support.
+
+[Read the Docs to Learn More](https://vite.dev).

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

@@ -0,0 +1,63 @@
+<h1 align="center"> ⛅️ wrangler </h1>
+<section align="center" id="shieldio-badges">
+<a href="https://www.npmjs.com/package/wrangler"><img alt="npm"  src="https://img.shields.io/npm/dw/wrangler?style=flat-square"></a>
+<img alt="GitHub contributors" src="https://img.shields.io/github/contributors/cloudflare/workers-sdk?style=flat-square">
+<img alt="GitHub commit activity (branch)" src="https://img.shields.io/github/commit-activity/w/cloudflare/workers-sdk/main?style=flat-square">
+<a href="https://discord.cloudflare.com"><img alt="Discord" src="https://img.shields.io/discord/595317990191398933?color=%23F48120&style=flat-square"></a>
+</section>
+
+`wrangler` is a command line tool for building [Cloudflare Workers](https://workers.cloudflare.com/).
+
+## Quick Start
+
+To get started quickly with a Hello World worker, run the command below:
+
+```bash
+npx wrangler init my-worker -y
+```
+
+For more info, visit our [Getting Started](https://developers.cloudflare.com/workers/get-started/guide/) guide.
+
+<details><summary>Wrangler System Requirements</summary>
+
+We support running the Wrangler CLI with the [Current, Active, and Maintenance](https://nodejs.org/en/about/previous-releases) versions of Node.js. Your Worker will always be executed in `workerd`, the open source Cloudflare Workers runtime.
+
+Wrangler is only supported on macOS 13.5+, Windows 11, and Linux distros that support glib 2.35. This follows [`workerd`'s OS support policy](https://github.com/cloudflare/workerd?tab=readme-ov-file#running-workerd).
+
+</details>
+
+## Documentation
+
+For the latest Wrangler documentation, [click here](https://developers.cloudflare.com/workers/wrangler/).
+
+To read more about Workers in general:
+
+- [Getting Started](https://developers.cloudflare.com/workers/get-started/guide/)
+- [How Workers works](https://developers.cloudflare.com/workers/reference/how-workers-works/)
+- [Observability](https://developers.cloudflare.com/workers/observability/)
+- [Platform](https://developers.cloudflare.com/workers/platform/)
+
+## Configuration
+
+Wrangler is configured via a `wrangler.jsonc` (recommended), `wrangler.json` or `wrangler.toml` file in the project root. An example configuration generated by `npx wrangler init` or `npx create cloudflare` is as follows:
+
+```jsonc
+{
+	"$schema": "node_modules/wrangler/config-schema.json",
+	"name": "my-worker",
+	"main": "./src/index.ts",
+	"compatibility_date": "YYYY-MM-DD",
+}
+```
+
+For more detailed information about configuration, refer to the [documentation](https://developers.cloudflare.com/workers/wrangler/configuration/).
+
+## Commands
+
+The `wrangler` CLI offers various commands, the most popular being:
+
+- `wrangler dev` to start a local development server, with live reloading and devtools.
+
+- `wrangler deploy` to deploy a Worker to the Cloudflare's global network.
+
+There are many more commands and options available, for a full list refer to the [official Cloudflare documentation](https://developers.cloudflare.com/workers/wrangler/commands/).

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

@@ -0,0 +1,191 @@
+<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

@@ -0,0 +1,175 @@
+---
+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

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

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