void 0.9.2 → 0.10.1

package/skills/void/docs/guide/edge/headers.md

@@ -56,11 +56,18 @@ Define custom response headers in [`void.json`](../../reference/config) using th
 
 ## Scope
 
-Header rules apply to **all responses** served through the dispatch worker, including static assets, SSR pages, and API routes. They do not apply to:
+Header rules apply to **all responses** served through the dispatch worker, including static assets, SSR pages, API routes, and hashed asset responses (which browsers fetch over `GET` from the immutable edge cache). Serving headers on hashed assets is what lets a cross-origin-isolated app attach `Cross-Origin-Embedder-Policy` and `Cross-Origin-Resource-Policy` to its hashed worker and wasm files — without them, a module worker spawned from a `require-corp` document is blocked.
+
+On hashed (content-addressed, immutable) assets, rules are **additive**. You can add headers such as COOP/COEP/CORP or other security headers, but the platform-managed caching, representation, and framing headers are preserved so an immutable asset cannot be mis-cached or corrupted: `Cache-Control`, `Content-Type`, `Content-Encoding`, `Content-Length`, `Content-Range`, `Accept-Ranges`, and `Transfer-Encoding` keep their platform values even if a broad rule tries to overwrite them. (This is the one case where a user `Cache-Control` does not override the default.)
+
+Header rules do not apply to:
 
-- Hashed asset cache hits (these use immutable caching set by the dispatch worker itself)
 - ISR cache responses (these have their own cache-control headers)
 
+### Blocked headers
+
+Two headers can never be set through rules: `Set-Cookie` and `Clear-Site-Data`. On the shared `*.void.app` domain, `void.app` is the registrable domain, so a cookie operation from one project would reach every project's subdomain. Both are dropped from rule output to keep that tenant boundary intact.
+
 ## Framework `_headers` files
 
 Meta-frameworks like SvelteKit, Nuxt, and Astro generate a `_headers` file with cache rules for their hashed asset directories. Void automatically parses this file during deploy and merges the rules into the deploy manifest.
@@ -74,6 +81,6 @@ No configuration is needed. If the framework generates a `_headers` file, it is
 
 1. `void deploy` reads header rules from the framework `_headers` file (if present) and `routing.headers` in `void.json`, then includes them in the deploy manifest.
 2. The platform stores the rules in the KV routing entry for your project.
-3. The dispatch worker applies matching rules to matching responses before returning them. Cacheable responses are cached with the final headers.
+3. The dispatch worker applies matching rules to matching responses before returning them. Most cacheable responses are cached with the final headers; hashed assets are the exception — their rules are applied on every serve (including cache hits), so a later header-rule change takes effect even when the content hash, and thus the cache entry, is unchanged.
 
 Because rules are evaluated at the edge, there is no extra latency cost. Headers are applied inline before the response is returned and cached.

package/skills/void/docs/guide/edge/rewrites.md

@@ -332,14 +332,14 @@ If you use [`routing.revalidate`](./revalidation) on a dispatch rewrite (`routin
 During `vite dev`, every response carries an `X-Void-Routing` header that traces how the request was resolved. Open the Network tab in devtools and inspect the response headers:
 
 ```
-X-Void-Routing: redirect[/old] → /new 301 (_redirects:12)
-X-Void-Routing: rewrite[/api/*] → /backend/:splat (void.json#routing.rewrites)
-X-Void-Routing: fallback[/docs/*] → /docs.html (void.json#routing.fallbacks)
-X-Void-Routing: c.rewrite → /new-path (middleware)
+X-Void-Routing: redirect[/old] -> /new 301 (_redirects:12)
+X-Void-Routing: rewrite[/api/*] -> /backend/:splat (void.json#routing.rewrites)
+X-Void-Routing: fallback[/docs/*] -> /docs.html (void.json#routing.fallbacks)
+X-Void-Routing: c.rewrite -> /new-path (middleware)
 X-Void-Routing: pass-through
 ```
 
-Phases are separated by `→`. The parenthesised source hint points at the exact declaration — a line number for `_redirects`, a config path for `void.json`, or `spa-default` for the synthetic SPA catch-all. The header is **only emitted in dev** — production builds strip both the trace code and the per-rule `origin` metadata from the bundle and manifest.
+Phases are separated by `->` so the diagnostic value stays valid as an HTTP header. The parenthesised source hint points at the exact declaration — a line number for `_redirects`, a config path for `void.json`, or `spa-default` for the synthetic SPA catch-all. The header is **only emitted in dev** — production builds strip both the trace code and the per-rule `origin` metadata from the bundle and manifest.
 
 ::: info What fires in `vite dev`
 `vite dev` applies the full static routing pipeline on every target — `node`, `bun`, `deno`, and the default target alike. `void.json` rules (`routing.redirects` / `routing.rewrites` / `routing.fallbacks` / `routing.headers`) and file-based rules (`public/_redirects`, `public/_headers`) are merged at plugin load and compiled into the Hono middleware your worker runs behind. Editing `_redirects` or `_headers` during a dev session re-runs the merge and reloads the page — no restart needed. `c.rewrite()` calls in middleware work everywhere because they live inside the worker itself, and the `X-Void-Routing` dev header reports every decision on every target.

package/skills/void/docs/guide/pages-routing/layouts.md

@@ -149,7 +149,7 @@ import { useShared, Link } from '@void/solid';
 import type { JSX } from 'solid-js';
 
 export default function Layout(props: { children: JSX.Element }) {
-  const shared = useShared<{ auth: { user: { name: string } | null } }>();
+  const shared = useShared();
   return (
     <>
       <nav>
@@ -307,15 +307,16 @@ Middleware can inject data available on every page via `c.set("shared", {...})`.
 ```ts
 // middleware/01.auth.ts
 import { defineMiddleware } from 'void';
+import { getUser, type AuthUser } from 'void/auth';
 
 declare module 'void' {
   interface CloudContextVariables {
-    shared: { auth: { user: { name: string } | null } };
+    shared: { auth: { user: AuthUser | null } };
   }
 }
 
 export default defineMiddleware(async (c, next) => {
-  const user = await getSessionUser(c);
+  const user = getUser();
   c.set('shared', { auth: { user } });
   await next();
 });
@@ -329,7 +330,7 @@ Access it on the client with `useShared()`. The return type is inferred from you
 import { useShared } from '@void/react';
 
 export default function Page() {
-  const { auth } = useShared(); // { auth: { user: { name: string } | null } }
+  const { auth } = useShared(); // { auth: { user: AuthUser | null } }
   return <p>Hello, {auth?.user?.name}</p>;
 }
 ```
@@ -337,14 +338,14 @@ export default function Page() {
 ```vue [Vue]
 <script setup lang="ts">
 import { useShared } from '@void/vue';
-const { auth } = useShared(); // { auth: { user: { name: string } | null } }
+const { auth } = useShared(); // { auth: { user: AuthUser | null } }
 </script>
 ```
 
 ```svelte [Svelte]
 <script>
   import { useShared } from "@void/svelte";
-  const { auth } = useShared(); // { auth: { user: { name: string } | null } }
+  const { auth } = useShared(); // { auth: { user: AuthUser | null } }
 </script>
 ```
 
@@ -352,7 +353,7 @@ const { auth } = useShared(); // { auth: { user: { name: string } | null } }
 import { useShared } from '@void/solid';
 
 export default function Page() {
-  const shared = useShared(); // { auth: { user: { name: string } | null } }
+  const shared = useShared(); // { auth: { user: AuthUser | null } }
   return <p>Hello, {shared.auth?.user?.name}</p>;
 }
 ```

package/skills/void/docs/guide/pages-routing/loaders.md

@@ -237,7 +237,7 @@ export default function Dashboard(props: Props) {
 
 ### How Streaming Works
 
-On the initial page load (SSR), React uses React 19 streaming SSR and renders the nearest Suspense fallback for deferred props; the other adapters render their loading state. As each deferred function resolves, the server streams an inline `<script>` tag that delivers the data, so no extra HTTP request is needed. On SPA navigation, deferred data streams via NDJSON over the same response.
+On the initial page load (SSR), React uses React 19 streaming SSR and renders the nearest Suspense fallback for deferred props; the other adapters render their loading state. As each deferred function resolves, the server streams an inline `<script>` tag that delivers the data, so no extra HTTP request is needed. Routes with `export const ssr = false` skip server-rendered component HTML but still stream deferred resolution scripts after the client-mounted shell. On SPA navigation, deferred data streams via NDJSON over the same response.
 
 ### Deferred Props After Mutations
 

package/skills/void/docs/guide/pages-routing/overview.md

@@ -100,6 +100,7 @@ Each page can have a companion `.server.ts` file that runs exclusively on the se
 
 - A [**loader**](./loaders), which runs on `GET` and returns the data that becomes the page component's props
 - [**Actions**](./actions-and-forms), which handle mutations from forms and programmatic calls. Export a single `action` or multiple [named actions](./actions-and-forms#named-actions) when a page has several mutations
+- `ssr = false` to opt a route out of server-rendered component HTML while keeping server loaders and client-side routing
 
 File-based routing rules are the same as [server routing](../server-routing.md): `[param]` for dynamic segments, `[...param]` for catch-all, `(group)/` for route groups.
 
@@ -107,14 +108,40 @@ File-based routing rules are the same as [server routing](../server-routing.md):
 
 Pages uses an Inertia-style protocol under the hood:
 
-| Request               | Response                                                              |
-| --------------------- | --------------------------------------------------------------------- |
-| Initial page load     | Full SSR HTML. Client hydrates automatically.                         |
-| Subsequent navigation | JSON with component name + props. Client component swap or re-render. |
-| Form submission       | Runs action, then returns fresh props or a redirect.                  |
+| Request               | Response                                                                                                       |
+| --------------------- | -------------------------------------------------------------------------------------------------------------- |
+| Initial page load     | Full SSR HTML. Client hydrates automatically. Routes with `ssr = false` return a client-mounted shell instead. |
+| Subsequent navigation | JSON with component name + props. Client component swap or re-render.                                          |
+| Form submission       | Runs action, then returns fresh props or a redirect.                                                           |
 
 This means the first page load is server-rendered for SEO and performance, while later navigations stay fast without full page reloads.
 
+To opt a specific route out of server-rendered component HTML, export `ssr = false` from its companion `.server.ts` file:
+
+```ts
+// pages/dashboard.server.ts
+import { defineHandler } from 'void';
+
+export const ssr = false;
+
+export const loader = defineHandler(async () => {
+  return { title: 'Dashboard' };
+});
+```
+
+The loader still runs on the first request, and its props are embedded in the HTML shell. The page component mounts in the browser instead of hydrating server-rendered markup.
+
+Render and prerender flags combine like this:
+
+| Page exports                           | Behavior                                                                  |
+| -------------------------------------- | ------------------------------------------------------------------------- |
+| `ssr` unset or `true`                  | Server-render component HTML on request.                                  |
+| `ssr = false`                          | Return a client-mounted shell on request.                                 |
+| `ssr = false` + `prerender = true`     | Prerender a client-mounted shell with embedded loader data.               |
+| `ssr = false` + `prerender = false`    | Return the client-mounted shell only on request; never prerender it.      |
+| Island page + `ssr = false`            | Invalid. Island pages already use the island renderer.                    |
+| `output: "static"` + `prerender` unset | Auto-prerender pages that have known paths, including client-only shells. |
+
 Use the `Link` component for SPA navigation between pages. It renders an `<a>` tag that intercepts clicks and navigates without a full page reload:
 
 ::: code-group

package/skills/void/docs/guide/server-routing.md

@@ -191,6 +191,34 @@ export default defineMiddleware(async (c, next) => {
 
 `defineMiddleware` uses Hono middleware semantics: `(c, next) => Promise<void> | void`.
 
+For a temporary full-site gate, use the built-in `basicAuth()` middleware with credentials from `void/env`. Void internal endpoints under `/__void` are excluded automatically so deploy migrations and dev tooling continue to work. Wrap `void/env` reads in functions so they are resolved per request after Void has bound the runtime env.
+
+```ts
+// env.ts
+import { defineEnv, string } from 'void/env';
+
+export default defineEnv({
+  BASIC_AUTH_USERNAME: string(),
+  BASIC_AUTH_PASSWORD: string(),
+});
+```
+
+```ts
+// middleware/01.basic-auth.ts
+import { basicAuth } from 'void';
+import { env } from 'void/env';
+
+export default basicAuth({
+  username: () => env.BASIC_AUTH_USERNAME,
+  password: () => env.BASIC_AUTH_PASSWORD,
+  realm: 'Preview',
+});
+```
+
+Set `BASIC_AUTH_USERNAME` and `BASIC_AUTH_PASSWORD` as local environment variables for development and production secrets before deploy.
+
+For app-specific bypasses such as health checks or public webhooks, compose that logic in your own middleware before calling `basicAuth()`.
+
 Middleware can set typed context variables using `c.set()`. Augment the `CloudContextVariables` interface so downstream handlers get full type safety:
 
 ```ts

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

@@ -23,6 +23,7 @@ Non-CF targets disable CF-only bindings (`void/db`, `void/kv`, `void/auth`, `voi
 - `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.
 
@@ -90,20 +91,20 @@ src/
 
 ### Package Exports
 
-| Subpath          | What                                                                                                                    |
-| ---------------- | ----------------------------------------------------------------------------------------------------------------------- |
-| `void`           | `voidPlugin()` named export + `defineHandler` + `defineMiddleware` + `defineHead` + `defineQueue` + `CloudContext` type |
-| `void/handler`   | `defineHandler()`, `defineHandler.withValidator()`, `defineMiddleware()`, `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 — Cloudflare-native `ai.run()`/`ai.stream()`, provider-native `ai.provider().fetch()`, `ai.models()`         |
-| `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    |
+| 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).
 

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

@@ -48,6 +48,7 @@ Runtime helpers include:
 
 - `defineHandler`
 - `defineMiddleware`
+- `basicAuth`
 - `defineScheduled`
 - `defineQueue`
 - `void/db`

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

@@ -118,6 +118,49 @@ export default defineMiddleware(async (c, next) => {
 function defineMiddleware(handler: MiddlewareHandler<CloudEnv>): MiddlewareHandler<CloudEnv>;
 ```
 
+### `basicAuth(options)`
+
+Built-in Basic authentication middleware for temporary site gates and pre-launch protection. Use it from `middleware/` with credentials from `void/env` to protect the whole app, or pass it to `defineHandler()` for a single route.
+
+Void internal endpoints under `/__void` are always excluded so deploy-time migrations, prerendering, cron/queue dispatch, and remote binding helpers still reach Void's own internal-token checks.
+
+When credentials come from `void/env`, wrap the reads in functions so they are resolved per request after Void has bound the runtime env.
+
+For app-specific bypasses such as health checks or public webhooks, compose that logic in your own middleware before calling `basicAuth()`.
+
+```ts
+// env.ts
+import { defineEnv, string } from 'void/env';
+
+export default defineEnv({
+  BASIC_AUTH_USERNAME: string(),
+  BASIC_AUTH_PASSWORD: string(),
+});
+```
+
+```ts
+// middleware/01.basic-auth.ts
+import { basicAuth } from 'void';
+import { env } from 'void/env';
+
+export default basicAuth({
+  username: () => env.BASIC_AUTH_USERNAME,
+  password: () => env.BASIC_AUTH_PASSWORD,
+  realm: 'Preview',
+});
+```
+
+**Signature:**
+
+```ts
+function basicAuth(options: {
+  username: string | (() => string);
+  password: string | (() => string);
+  realm?: string | (() => string);
+  message?: string | (() => string);
+}): MiddlewareHandler<CloudEnv>;
+```
+
 ### `defineScheduled(handler)`
 
 Wraps a Cloudflare [Scheduled handler](https://developers.cloudflare.com/workers/runtime-apis/handlers/scheduled/) with type inference.
@@ -1105,7 +1148,7 @@ This table lists app-facing imports. Exported implementation subpaths such as `v
 | Import path               | Contents                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
 | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
 | `void`                    | `voidPlugin`, handler/type re-exports, `defer`, `Deferred`, `DeferredState`, `InferProps`, `HeadDescriptor`                                                                                                                                                                                                                                                                                                                                                                                                              |
-| `void/handler`            | `defineHandler`, `defineMiddleware`, `defineScheduled`, `defineQueue`, `defineRender`, `defineHead`, types                                                                                                                                                                                                                                                                                                                                                                                                               |
+| `void/handler`            | `defineHandler`, `defineMiddleware`, `basicAuth`, `defineScheduled`, `defineQueue`, `defineRender`, `defineHead`, types                                                                                                                                                                                                                                                                                                                                                                                                  |
 | `void/auth`               | `defineAuth`, `getUser`, `getSession`, `requireAuth`, `AuthUser`, `AuthSession`, `AuthState`                                                                                                                                                                                                                                                                                                                                                                                                                             |
 | `void/client`             | `fetch`, `fetchStream`, `FetchError`, `auth`, `createAuthClient`, `AuthUser`, `AuthSession`, `AuthState`                                                                                                                                                                                                                                                                                                                                                                                                                 |
 | `void/client/{framework}` | Same as `void/client`, with framework-specific Better Auth clients for `react`, `vue`, `svelte`, and `solid`                                                                                                                                                                                                                                                                                                                                                                                                             |

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

@@ -86,7 +86,7 @@ After that, the full interactive flow walks through:
 4. **Skills:** links Void skills using the same detected or selected agent context.
 5. **MCP config:** writes MCP server config using that same agent context.
 6. **Demo code:** for existing non-Pages projects, optionally scaffolds a `db/migrations/` directory plus an API route and typed fetch example.
-7. **GitHub Actions:** optionally creates `.github/workflows/deploy.yml` with the right package manager commands.
+7. **GitHub Actions:** optionally creates `.github/workflows/void-deploy.yml`. The workflow deploys on pushes to `main` and authenticates via [GitHub OIDC](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect) — no long-lived `VOID_TOKEN` secret is stored in the repo. The job requests an OIDC token (audience `void`), exchanges it at `POST $VOID_API_URL/auth/github-oidc` for a short-lived project-scoped deploy token, then runs `void deploy --project <slug>` with the right package manager. The project slug is baked in from your linked project (`.void/project.json`) when known; otherwise the workflow reads a `VOID_PROJECT` repository variable.
 8. **`env.ts` scaffold:** if the project has no `env.ts` but has `.env` / `.env.example` / `.env.local` / `.env.development*` files on disk, generates an `env.ts` pre-populated with their keys. Values get conservative type inference (`boolean`/`url`/`number`/`string`) — the file carries a banner nudging you to tighten anything the heuristic got wrong.
 9. **Project setup:** optionally logs you in, lets you select or create a project, and writes `.void/project.json` so your first deploy can just be `void deploy`.
 
@@ -98,10 +98,12 @@ Use flags to run individual steps without prompts:
 | ------------ | ------------------------------------------------- |
 | `--tsconfig` | Only update `tsconfig.json`                       |
 | `--agents`   | Set up agent instructions, skills, and MCP config |
-| `--github`   | Only create GitHub Actions workflow               |
+| `--github`   | Only create the GitHub Actions deploy workflow    |
 
 Flags can be combined. When any flag is provided, only the specified steps run and interactive prompts are skipped.
 
+The `--github` workflow uses GitHub OIDC: you connect the repository to your Void project once with `void github connect <project> --repo <owner/repo> --executor github_actions` (see the GitHub section below), and pushes to `main` deploy automatically. There is no `VOID_TOKEN` secret to create or rotate. To target staging, set a `VOID_API_URL` repository variable to `https://api.staging.void.cloud`.
+
 For projects that already have `"extends"`, `void init --tsconfig` preserves the existing config and adds `./.void/tsconfig.json`. If the existing config defines `files` or `compilerOptions.paths`, Void also merges its generated declaration files and aliases into the root config because TypeScript replaces those fields across `extends` instead of deeply merging them.
 
 ### `void prepare`
@@ -564,6 +566,67 @@ PORT=3000
 
 See [Environment Variables](../guide/env-vars.md) for the full guide.
 
+## GitHub
+
+Deploy-on-GitHub works from **any** Void login — Google, GitHub, or other SSO. The first time you connect GitHub, Void links your GitHub identity to your current account (a one-time step, independent of how you logged in); it never creates a second account.
+
+### `void github link`
+
+```
+void github link
+```
+
+Link your current Void account to a GitHub identity. Opens your browser to authorize Void on GitHub (a localhost + PKCE handshake, the same mechanics as `void auth login`), then binds that GitHub identity to the logged-in account. Requires an authenticated CLI (`void auth login` first).
+
+You normally don't need to run this directly — `void github install` runs the link automatically when your account has no GitHub identity yet. Run it on its own to link ahead of time, or to link a GitHub identity without installing the App. If that GitHub account is already linked to a different Void account, the command fails and asks you to use a different GitHub account.
+
+### `void github install`
+
+```
+void github install
+```
+
+Open the GitHub App install page in your browser. If your account has no linked GitHub identity yet, `void github install` first runs the GitHub link automatically (browser authorize), then continues. After installing, run `void github connect` to link a repository to your project.
+
+### `void github installations`
+
+```
+void github installations
+```
+
+List all GitHub App installations linked to your account. Each entry includes the `[id: <installation_id>]` needed for `--installation` in non-interactive use.
+
+### `void github connect`
+
+```
+void github connect [project] [options]
+```
+
+Connect a GitHub repository to a Void project for automatic deploys. On every push to the configured branch, Void builds and deploys your project automatically.
+
+**Options**
+
+| Flag                  | Description                                                                     |
+| --------------------- | ------------------------------------------------------------------------------- |
+| `--project <name>`    | Project name (alias for the positional argument)                                |
+| `--installation <id>` | GitHub App installation ID (required when you have multiple installations)      |
+| `--repo <owner/repo>` | Repository full name — required unless the installation grants exactly one repo |
+| `--branch <name>`     | Branch to deploy from — **required in non-interactive mode**                    |
+| `--executor <type>`   | Build executor: `container` (default) or `github_actions`                       |
+
+**Non-interactive use (CI)**
+
+When stdin is not a TTY, `void github connect` never prompts — it fails closed and names any flag it needs. `--branch` is always required. `--project` must be resolvable (positional / `--project` / `VOID_PROJECT` / linked `.void/project.json`). `--installation` is required only when your account has more than one installation; otherwise the sole installation is used. `--repo` is required when the installation grants access to all repos or to more than one selected repo; when it grants exactly one repo that repo is used automatically. Use `void github installations` to discover the `installation_id`.
+
+```
+void github connect my-app \
+  --installation 42 \
+  --repo owner/my-app \
+  --branch main
+```
+
+**Project resolution** follows the same order as deploy: positional / `--project`, `VOID_PROJECT`, linked project (`.void/project.json`).
+
 ## Custom Domains
 
 ### `void domain add`

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

@@ -172,7 +172,7 @@ Output mode. Controls the default rendering strategy for pages.
 
 When set to `"static"`, all pages are prerendered at build time as static HTML files written to `dist/client/`. Individual pages can opt out with `export const prerender = false`. Dynamic pages (with route params) without a `getPrerenderPaths()` export are implicitly not prerendered.
 
-When omitted or set to `"server"`, pages are server-rendered on request. Individual pages can opt into deploy-time prerendering with `export const prerender = true`.
+When omitted or set to `"server"`, pages are server-rendered on request. Individual pages can opt into deploy-time prerendering with `export const prerender = true`, or opt out of server-rendered component HTML with `export const ssr = false`.
 
 ```json
 { "output": "static" }