void 0.10.12 → 0.20.0

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

@@ -4,9 +4,9 @@ outline: deep
 
 # Server-Sent Events
 
-Void provides `void/sse` for producing and consuming Server-Sent Events from ordinary route handlers. It handles event formatting, response headers, keepalives, stream closure, request aborts, and browser `EventSource` parsing.
+Use `void/sse` to stream events from a route handler to the browser. Void formats messages, sends keepalives, and closes the stream when the request ends.
 
-Use SSE when one HTTP request owns the producer: AI token streaming, progress updates, command output, deployment logs, or incremental status messages. Use `void/live` or an application-level Durable Object when multiple requests need shared fanout, replay, or subscription state.
+SSE is a good fit for AI tokens, progress updates, or logs produced by one request. If other requests need to publish to connected clients, see [Live Event Streams](./live.md). Store events yourself if clients need to replay them.
 
 ## Server streams
 
@@ -67,7 +67,7 @@ await stream.comment('still connected');
 
 `data` may be a string or JSON-serializable value. Strings are sent as-is; other values are serialized with `JSON.stringify()`. Multi-line strings are split into multiple `data:` lines. Binary data is rejected because SSE is text-only.
 
-`event`, `id`, and `retry` are validated before writing so accidental frame injection is rejected. Writes after close reject with `SseStreamClosedError`.
+Void validates `event`, `id`, and `retry` before writing, so their values can't accidentally introduce extra SSE fields or events. Writing to a closed stream throws `SseStreamClosedError`.
 
 If you already serialized the payload, use `formatSseText()` for lower-level formatting while keeping the same `id`, `event`, and `retry` validation:
 
@@ -184,4 +184,4 @@ Plain SSE is enough when the producer belongs to the same request that opened th
 - Per-request deployment or build logs
 - Incremental status for a long-running action
 
-Use a higher-level realtime primitive when you need cross-request fanout, rooms, replay buffers, subscriptions, database change streams, or multi-region coordination.
+For shared topics and subscriptions, use [Live Event Streams](./live.md). For rooms with two-way communication, use [WebSockets](./websockets.md). Replay and database change streams need an application-level storage or delivery layer.

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

@@ -14,10 +14,10 @@ Set `output: "static"` in `void.json` to prerender all pages at build time:
 
 When `output` is `"static"`:
 
-- All pages default to `prerender = true`, so they are rendered during `vite build` and written as HTML files to `dist/client/`.
+- All pages default to `prerender = true` and are written as HTML files to `dist/client/`. A standalone `vite build` renders them during the build; managed `void deploy` renders immediately afterward in its trusted parent process.
 - Use `export const prerender = false` in a page's `.server.ts` to opt out. That page will be server-rendered on request.
 - Dynamic pages without `getPrerenderPaths()` are implicitly not prerendered (the paths aren't known at build time).
-- The build output is self-contained and works for `wrangler deploy`, self-hosting, or `void deploy`.
+- The build output is self-contained and works for direct Cloudflare deployment, self-hosting, or `void deploy`.
 
 ## How it works
 
@@ -48,10 +48,12 @@ Dynamic pages **without** `getPrerenderPaths()` are not prerendered because the
 | `output` value       | Default prerender | Per-page override                | Prerender timing           |
 | -------------------- | ----------------- | -------------------------------- | -------------------------- |
 | `"server"` (default) | `false`           | `export const prerender = true`  | Deploy-time (platform ISR) |
-| `"static"`           | `true`            | `export const prerender = false` | Build-time (`vite build`)  |
+| `"static"`           | `true`            | `export const prerender = false` | Build or deploy post-build |
 
 When `output` is omitted or set to `"server"`, behavior is unchanged. `export const prerender = true` opts individual pages into deploy-time [edge prerendering](./edge/prerendering.md).
 
+Managed deploy keeps its deployment credential out of project-controlled build scripts and Vite plugins. When static rendering needs remote D1, KV, R2, or AI, the trusted deploy process supplies the built worker with a five-minute credential scoped to that project's binding proxy only.
+
 ## Deployment behavior
 
 When you run `void deploy` with `output: "static"`, Void inspects the build output to decide the optimal deploy strategy:

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

@@ -4,7 +4,7 @@ outline: deep
 
 # Object Storage
 
-Void provides a typed `storage` export for [Cloudflare R2](https://developers.cloudflare.com/r2/). Import it from `void/storage` and use the full R2 API directly.
+Store files in [Cloudflare R2](https://developers.cloudflare.com/r2/) with `storage` from `void/storage`. It gives you the typed R2 API for uploads, downloads, and metadata.
 
 ## Basic Operations
 
@@ -62,6 +62,6 @@ export const GET = defineHandler(async (c) => {
 
 ## How It Works
 
-Unlike the [database](./database.md) and [KV](./kv.md) clients, `storage` doesn't add any abstraction over the underlying API. The R2 API is already well-designed for direct use, so `storage` is simply a lazy reference to `env.STORAGE` that you can import without manually accessing bindings.
+`storage` resolves the `env.STORAGE` binding when you use it. It exposes the R2 API directly, so methods and options work as described in Cloudflare's documentation.
 
 The `createStorage()` factory exists for testing and for frameworks that manage their own routing. It accepts an `R2Bucket` and returns it directly.

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

@@ -5,12 +5,14 @@ outline: deep
 # WebSockets
 
 ::: warning ⚠️ Void Apps Only
-Void-managed WebSockets currently works only for Void apps. Meta-framework mode is not supported yet.
+Typed WebSocket routes currently work in native Void apps. They aren't available in meta-framework mode yet.
 :::
 
-Void supports typed WebSockets from file-based `.ws.ts` routes. Each WebSocket route compiles to a Cloudflare Durable Object, so the feature is currently Cloudflare-only. If you set `target` to `node`, `bun`, or `deno`, builds fail when `.ws.ts` routes are present.
+Create a `.ws.ts` route to add a typed WebSocket endpoint. Void runs each route instance in a Cloudflare Durable Object, which coordinates the clients connected to it. These routes require the Cloudflare target; Node.js, Bun, and Deno builds reject them.
 
-Use WebSockets for chat, presence, collaborative rooms, notifications, AI/live-log streaming, and other realtime flows where one connection target maps cleanly to one route instance.
+New route classes use SQLite-backed Durable Objects on both deployment platforms. Void preserves legacy key-value-backed migration history for existing hosted projects and never reclassifies an already-created class.
+
+For example, a chat route at `/rooms/[id]` gives each room its own instance. Use it for chat, presence, collaborative documents, or notifications.
 
 ## Route files
 
@@ -28,10 +30,13 @@ Filename rules match regular server routes:
 - `[id].ws.ts` becomes `:id`
 - `[...slug].ws.ts` becomes a catch-all
 - route groups like `(marketing)/chat.ws.ts` are ignored in the URL
+- `chat.dev.ws.ts` / `chat.prod.ws.ts` restrict the route to one environment
+
+The environment suffix goes **before** `.ws`. `chat.ws.dev.ts` is not recognised.
 
 ## `defineRoom()`
 
-Use `defineRoom()` when many clients should share one route-scoped room or document.
+Use `defineRoom()` when clients should share a room or document identified by the route.
 
 ```ts
 // routes/chat/[room].ws.ts
@@ -112,7 +117,7 @@ export default defineWebSocket({
 
 ## Typed messages
 
-WebSocket messages are schema-backed in both directions:
+Define schemas for messages sent by the client and server:
 
 - `messages.client` validates what the browser may send
 - `messages.server` validates what the server may send
@@ -179,7 +184,7 @@ socket.send({ type: 'chat.message', text: 'hello' });
 
 ## Constraints
 
-This first release intentionally focuses on the Durable Object sweet spot:
+WebSocket routes currently support:
 
 - Cloudflare-only
 - one route-derived connection target per socket
@@ -187,4 +192,10 @@ This first release intentionally focuses on the Durable Object sweet spot:
 - no global pub/sub abstraction
 - JSON event messages only
 
-That covers most realtime app shapes Void is targeting without exposing Durable Objects directly.
+Each socket connects to one route instance. Applications that need to switch rooms should manage that connection change explicitly.
+
+## Deployment
+
+`void deploy --platform cloudflare` persists the required binding and append-only SQLite class migration in `wrangler.jsonc`, then deploys the generated Worker directly to your account. Commit this migration history and never delete or reorder a step after deployment.
+
+`void deploy --platform void` uses the same shared migration planner in the hosted uploader. Existing hosted WebSocket classes created on legacy storage remain there; only genuinely new classes use SQLite.

package/skills/void/docs/index.md

@@ -23,16 +23,16 @@ features:
     details: Database, KV storage, object storage, AI inference, authentication, queues, and cron jobs. All built-in. Import what you need, skip what you don't.
   - iconify: lucide:wand-sparkles
     title: Your Code is Your Infra
-    details: Void scans your source code, detects what you use, and automatically provisions every resource. No config files. No dashboard clicks. Locally and in the cloud.
+    details: Void detects supported resources from your code and provisions them when you deploy. Use explicit configuration for existing infrastructure and services that need additional setup.
   - iconify: lucide:shield-check
     title: Performant and Reliable
-    details: Built on Cloudflare's battle tested, global network. Fast, secure, and always available from day one.
+    details: Build on Cloudflare Workers with checked migrations, versioned deployments, and tools to inspect and roll back application releases.
   - iconify: lucide:blocks
     title: Your Framework, Your Rendering
     details: React, Vue, Svelte, Solid, Vite-based meta-frameworks. SSR, SSG, ISR, islands with partial hydration, and markdown.
   - iconify: lucide:bot
     title: AI-Native
-    details: Built-in skills, MCP support, and reference prompts let coding agents scaffold and ship full-stack apps in a single prompt.
+    details: Built-in skills and reference prompts let coding agents scaffold and ship full-stack apps in a single prompt.
 
 footer_heading: Deploy at Warp Speed
 footer_subheading: Vite. Optimized. Isomorphic. Deploy.

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

@@ -4,81 +4,23 @@ outline: deep
 
 # Using Void with Coding Agents
 
-Void integrates with coding agents via **skills** (agent instructions and reference docs) and an **MCP server** (tool-based documentation access). Both are set up as part of the default `void init` flow. To run only the agent setup step:
+`void init` gives your coding agent Void instructions and reference docs. To add or refresh just that setup, run:
 
 ```sh
 npx void init --agents
 ```
 
-This detects your coding agent, links skills into its configuration directory, writes MCP config, and injects a Void reference block into your agent instructions file (`CLAUDE.md` or `AGENTS.md`). If auto-detection fails, it asks you to choose from Claude Code, Cursor, Codex, Gemini CLI, or Generic.
+This always creates or updates `AGENTS.md` with four brief bullets covering Void, deployment targets, the development workflow, and where to find the docs. It preserves your existing content outside the versioned Void block and leaves other instruction files untouched. There is no coding-agent selection prompt.
+
+The complete Markdown docs ship with the installed package at `node_modules/void/skills/void/docs/`. Agents can read them directly, even without a linked skill.
 
 ## Skills
 
-Skills give your coding agent structured knowledge about Void, including how to use the CLI, build apps, work with routes, databases, auth, and more. They are symlinked from the `void` package into the agent's skills directory, so they stay version-matched with your installed Void version.
+Skills point your agent to the commands and docs it needs for the task. They link to the installed `void` package, so the guidance matches the version your app uses.
 
 Void ships two skills:
 
 - **`void`:** main development skill. Routes agent requests to the right documentation for CLI commands, routing, pages, database, auth, deployment, and more.
 - **`migrate-vite-cloudflare-to-void`:** migration skill for converting existing `@cloudflare/vite-plugin` apps to Void.
 
-Skills are linked automatically by `void init --agents`. For Claude Code, they are symlinked into `.claude/skills/`. Other agents that support skills will have them linked to their respective directories.
-
-## MCP
-
-Void ships with a built-in [MCP](https://modelcontextprotocol.io/) server that runs locally over stdio. It provides three tools: `list_pages`, `get_page`, and `search_docs`. Together they give your AI agent full access to the Void documentation, version-matched and usable offline.
-
-```sh
-npx void mcp
-```
-
-### Automatic Setup
-
-MCP config is written automatically by `void init --agents`:
-
-- Agents with project-level config support (Claude, Cursor, etc.): writes the config file for you.
-- Agents without project-level config support (Codex, Gemini CLI, etc.): prints the CLI command to register `npx void mcp`.
-- Generic mode: prints MCP JSON you can paste into your agent config.
-
-### Manual Setup
-
-#### Claude Code
-
-```sh
-claude mcp add void -- npx void mcp
-```
-
-#### Codex CLI
-
-```sh
-codex mcp add void -- npx void mcp
-```
-
-#### Cursor
-
-In `.cursor/mcp.json`:
-
-```json
-{
-  "mcpServers": {
-    "void": {
-      "command": "npx",
-      "args": ["void", "mcp"]
-    }
-  }
-}
-```
-
-#### Gemini CLI
-
-In `~/.gemini/settings.json`:
-
-```json
-{
-  "mcpServers": {
-    "void": {
-      "command": "npx",
-      "args": ["void", "mcp"]
-    }
-  }
-}
-```
+Skills are linked automatically by `void init --agents` when it detects a supported agent's configuration. For Claude Code, they are symlinked into `.claude/skills/`. Other detected agents have them linked to their respective directories. If no agent is detected, skill linking is skipped and `AGENTS.md` points directly to the bundled docs.