void 0.21.9 → 0.23.0

package/skills/void/docs/guide/platform/administration/operations.md

@@ -51,6 +51,30 @@ Following waits for the final logs before stopping, including diagnostics writte
 
 ## Checking the Platform
 
+### Migrating older deployment assets
+
+After upgrading the platform, inspect every page of its asset inventory:
+
+```sh
+void platform system asset-migrations --page 1 --limit 100
+void platform deployment migrate-assets <deployment-id> --plan
+void platform deployment migrate-assets <deployment-id> --yes
+```
+
+Migrate every deployment with a nonzero `needsMigration` count, including retained
+rollback targets and stored Worker bundles. Investigate entries marked `invalid`
+before continuing. The command verifies each copied asset, preserves originals,
+and applies successive batches. If interrupted, inspect the result and resume
+with the last successful `nextCursor` using `--cursor`; restarting without a
+cursor also verifies and reuses completed copies.
+
+Run the inventory again across all pages when finished. Existing applications
+continue serving during this migration, and the provider asset mirror remains.
+Legacy reads remain available while older platform runtimes and cached manifests
+can still reference original assets.
+
+### Health checks
+
 Use the overview to see recent activity, or run a health check to test the platform's services and database:
 
 ```sh
@@ -60,7 +84,7 @@ void platform system health
 
 Health checks use the services configured for the selected platform. An unhealthy result exits with a nonzero status, so the same command can be used in a script.
 
-The browser dashboard's **System Status** checks refresh every 30 seconds. Failed checks show an HTTP status or connection error beside the service name. If the dashboard cannot refresh the checks, it reports that status is unavailable instead of displaying stale results.
+The dashboard’s **System Status** page refreshes health checks every 30 seconds and shows errors beside the affected service.
 
 Use `void platform upgrade`, `repair`, `disable`, and `enable` to maintain your platform. See [platform maintenance](/guide/platform/installation/maintenance#resume-repair-recover-and-upgrade).
 
@@ -92,6 +116,4 @@ unset VOID_OPERATOR_TOKEN
 
 Disable shell tracing for the exchange and do not write either token to logs or plaintext files. A full API login session expires after 30 days and can be revoked sooner; renew it through the normal authenticated login flow and update the protected CI secret. A job that runs longer than one hour must repeat the exchange while its full API session is still valid. An expired operator token cannot refresh itself, and Void does not issue permanent service tokens for administrator automation.
 
-`auth login --token-stdin` performs the same elevation and saves the one-hour operator token in the system keychain for interactive use. See [operator authentication](/reference/cli#operator-authentication) for the full command syntax.
-
-An email zone has one connection and ingress Worker shared by its exact domain assignments. Removing one assignment preserves resources used by the others. The Email administration page can explicitly rotate that connection secret; ordinary synchronization does not rotate it. Setup and cleanup outcomes include operation IDs, and uncertain provider writes remain recorded until reconciled.
+`auth login --token-stdin` performs the same elevation and saves the one-hour operator token in the system keychain for interactive use. See [operator authentication](../../../reference/cli/platform.md#operator-authentication) for the full command syntax.

package/skills/void/docs/guide/platform/administration/plans.md

@@ -0,0 +1,126 @@
+---
+outline: deep
+---
+
+# Plans and Limits
+
+Plans define the resource limits you assign to accounts on your platform. They do not bill users or purchase Cloudflare services. Sign in with an administrator account and open **Plans** in the administration dashboard, or use the CLI:
+
+```sh
+void platform auth login
+void platform config plans
+```
+
+Choose a plan to inspect or edit it, copy one into a new plan, or choose the default for new accounts. Existing installations keep their plans, limits, and default until you change them. After upgrading the platform to support plan configuration, these changes require no app or platform redeploy.
+
+Inspection and previews are available immediately after a platform upgrade. Allow 15 minutes before applying changes.
+
+## Use the Dashboard
+
+Open **Plans** to see each plan's stable ID, account count, and signup default. Choose **Add plan** to copy an existing plan, or **Edit** to change its display name, limits, build size, and permission to use short project slugs.
+
+Choose **Review changes** to compare the current and proposed settings and see how many accounts are affected. Review any quota warnings, then choose **Apply changes**. If someone changed the catalog while you were reviewing, open the plan again and create a fresh review.
+
+The edit page also lets you choose the signup default, archive or restore assignments, reset a built-in plan, or remove a plan with an active replacement. Every action has a review step.
+
+Account updates continue automatically on the result page. If you leave the page or an update pauses, open **Plans** and choose **Continue account updates**. Finish pending account updates before changing plans again. Recorded usage and billing periods are preserved.
+
+## Add a Plan
+
+Each plan has a stable ID and an editable display name. Copying a plan copies its limits, build instance size, and permission to use short project slugs:
+
+```sh
+void platform config plans add team --copy pro --name "Team" --plan
+void platform config plans add team --copy pro --name "Team" --yes
+```
+
+Assign it to an existing account or make it the default for new accounts:
+
+```sh
+void platform user plan <user-id> team --yes
+void platform config plans default team --yes
+```
+
+Changing the default does not move existing accounts. Renaming a plan does not change its ID or assignments.
+
+## Edit Limits
+
+The interactive menu lets you change one limit at a time. For scripts or several changes, create a JSON file:
+
+```json
+{
+  "name": "Team",
+  "limits": {
+    "requestsPerMonth": 10000000,
+    "concurrentBuilds": 3,
+    "buildTimeoutMinutes": 15
+  },
+  "buildInstanceType": "standard-4"
+}
+```
+
+Omitted settings keep their current values. Preview, then apply:
+
+```sh
+void platform config plans set team --file team-plan.json --plan
+void platform config plans set team --file team-plan.json --yes
+```
+
+Limits are nonnegative whole numbers; `0` means unlimited by the plan. Build timeouts always have a platform maximum of 60 minutes; `0` uses that maximum. You can configure:
+
+| Setting                         | Limit                                             |
+| ------------------------------- | ------------------------------------------------- |
+| `requestsPerMonth`              | Application requests per account billing month    |
+| `cpuMsPerRequest`               | Default CPU milliseconds per application request  |
+| `maxCpuMsPerRequest`            | Highest CPU limit an application can request      |
+| `subRequestsPerInvocation`      | Subrequests per invocation                        |
+| `deploysPerDay`                 | Deployments per day                               |
+| `aiNeuronsPerMonth`             | AI neurons per account billing month              |
+| `retainedDeployments`           | Retained Worker deployments                       |
+| `sandboxRuntimeSecondsPerMonth` | Sandbox runtime seconds per account billing month |
+| `sandboxMaxConcurrentInstances` | Simultaneous Sandbox instances                    |
+| `concurrentBuilds`              | Simultaneous builds                               |
+| `buildTimeoutMinutes`           | Build timeout in minutes                          |
+
+`cpuMsPerRequest` cannot exceed `maxCpuMsPerRequest`. An unlimited default CPU limit requires an unlimited ceiling. Build instance sizes are `standard-3` (2 vCPU, 8 GiB) and `standard-4` (4 vCPU, 12 GiB). New builds use the new size and timeout; running builds keep their recorded settings.
+
+Advanced files can also set `"allowShortSlugs": true` to permit project slugs of five characters or fewer, or `false` to require longer slugs for future changes. Existing project URLs are preserved. Copying a plan inherits this setting; the built-in `free` plan disables it and the other built-in plans enable it.
+
+Storage figures shown for D1, R2, and KV are informational and cannot be edited as enforced quotas. Static deployments keep their existing retention policy.
+
+The preview shows the affected account count and checks a sample for accounts already above a proposed quota. Lowering a quota can restrict existing apps, including accounts outside that sample. Usage history and billing periods are preserved, so a plan change does not reset usage. Manual administrator suspensions remain in effect.
+
+After the initial platform upgrade, request quota accounting includes unlimited plans too. For an account that was unlimited before that upgrade, its quota counter may not include earlier requests in the current billing period. Historical analytics remain available. When introducing its first cap, allow for the remaining period or wait until its next billing period.
+
+## Archive or Remove a Plan
+
+Archive a plan to stop assigning it to new accounts while preserving its current accounts:
+
+```sh
+void platform config plans archive team --yes
+void platform config plans restore team --yes
+```
+
+Choose another default before archiving the current default. To remove a plan with accounts, choose a replacement and review the changes first:
+
+```sh
+void platform config plans remove team --replacement pro --plan
+void platform config plans remove team --replacement pro --yes
+```
+
+Removing the default also requires a replacement. An unused plan that is not the default can be removed without one. Accounts keep their usage when moved to a replacement plan. Restore the original limits and build size of a built-in plan with `void platform config plans reset <plan-id>`; custom plans have no built-in reset values.
+
+The removal review shows the replacement plan and any changes to its limits, build size, and short-slug permission before you confirm.
+
+## Complete Pending Updates
+
+After applying a change, the CLI continues account updates until complete. If an update fails or stops making progress, the configuration remains saved, the result reports pending work, and the command exits with a nonzero status. Inspect the catalog, then continue:
+
+```sh
+void platform config plans show
+void platform config plans sync --yes
+```
+
+`sync` continues the saved policy's account updates until completion. Finish pending updates before editing the catalog again. If a request loses its connection, inspect the catalog and [operator events](/guide/platform/administration/operations) before retrying it.
+
+All commands accept `--connection <registered-id-or-url>` and `--json`. Scripted changes require `--yes`; use `--plan` for a read-only preview.

package/skills/void/docs/guide/platform/administration/projects.md

@@ -21,7 +21,7 @@ void platform project list --user <user-id>
 void platform project show <project-id>
 ```
 
-Project details include resources, domains, and recent builds and deployments. The [command reference](/reference/cli#operator-commands) also covers suspending and restoring users, deleting projects, and removing accounts.
+Project details include resources, domains, and recent builds and deployments. The [command reference](../../../reference/cli/platform.md#operator-commands) also covers suspending and restoring users, deleting projects, and removing accounts.
 
 In the admin dashboard, open a project to view its team. Search for a platform user and choose a role to add them immediately; an email address is not required. You can also change or remove existing members. Pending invitations created through other project workflows remain visible until accepted or revoked. If email is unavailable for a pending invitation, share its ID so the user can accept it with `void project team accept <invitation-id>`. The owner cannot be removed from the team; transfer ownership first.
 
@@ -38,13 +38,16 @@ The preview shows both owners, their plans and suspension state, blockers, and t
 
 After the transfer, the former owner becomes a project administrator. Existing project-scoped CI deploy credentials are revoked; create replacements as the new owner. The new owner's plan and limits apply immediately. Usage before the transfer remains charged to the former owner; later usage is charged to the new owner. If an apply reports partial convergence, inspect the project and operator event log before repeating it.
 
-New users on a self-hosted installation start with the `custom` profile, which
+By default, new users on a self-hosted installation start with the `custom` profile, which
 does not cap application requests, AI usage, deployment frequency, or retained
 Worker deployments. Named profiles such as `pro` apply the platform's quota and
 retention policies; they do not purchase Cloudflare services or bill your users.
 Storage figures are not a hard storage-quota boundary. Set an operating budget
 and retention policy before opening signup beyond your invited team.
 
+Use [Plans and Limits](/guide/platform/administration/plans) to define your own
+plans, change limits, or choose a different default for new accounts.
+
 The last active administrator cannot be deleted or suspended, including through
 the browser admin UI. Another administrator must still have access. Automatic
 usage limits do not remove administrator access and do not count as a manual

package/skills/void/docs/guide/platform/administration/zero-trust.md

@@ -0,0 +1,189 @@
+---
+outline: deep
+---
+
+# Project Zero Trust
+
+Project Zero Trust puts Cloudflare Access in front of the hostnames of projects deployed to your platform, including custom domains. Visitors sign in with one of your identity providers before they reach a protected project. Each project can still be made public.
+
+This is separate from the Access login and protection for the platform API. Projects deployed directly to Cloudflare are not affected.
+
+## Requirements
+
+- A Cloudflare Zero Trust organization in the account that hosts the platform, with the identity providers and reusable Access policies you want to use. Select at least one Allow policy that matches people by identity. Void rejects Bypass and Service Auth policies, and rules that allow Everyone or any service token.
+- A Cloudflare API token for that account with **Access: Apps and Policies Write** and **Access: Organizations, Identity Providers, and Groups Read**. Void keeps it separate from the platform runtime token, stores it encrypted, and never shows it again.
+- Free Access applications in the account. Cloudflare's default limit is 500 per account. Count the applications you already manage outside Void, then add the ones Void needs, as described in [Access Applications Void Creates](#access-applications-void-creates).
+- Platform API, proxy, and email gateway hostnames outside the project application domain. Configuration is rejected when project protection would cover one of them. Any other hostname under the project application domain also asks for sign-in, except the `/health` path of `void-platform-health.<your domain>`, which Void keeps open for its health checks and never serves from a project. New projects cannot use that name. A project that already uses it keeps every other path, protected or public like any other project.
+
+## Enable Zero Trust
+
+Open **Zero Trust** in the administrator UI, or use the operator CLI:
+
+```sh
+printf '%s' "$ACCESS_API_TOKEN" | void platform zero-trust configure \
+  --identity-providers <id[,id...]> \
+  --policies <id[,id...]> \
+  --existing-projects public \
+  --protect-new-projects \
+  --token-stdin \
+  --yes
+```
+
+- `--existing-projects protected|public` decides what happens to the projects that already exist. It is required when you enable Zero Trust.
+- `--protect-new-projects` protects projects created from now on. Omit it to make new projects public.
+- Use `--plan` instead of `--yes` to check the change without applying it.
+
+To change the identity providers, policies, token, or new-project default later, run the same command without `--existing-projects`. Existing projects keep their protection; use the project overrides below to change one project.
+
+## Check Status
+
+```sh
+void platform zero-trust status
+void platform zero-trust status --check
+```
+
+`status` shows the saved settings, the current operation, and how many projects are protected, public, or waiting. `--check` also compares the settings with Cloudflare Access. In the administrator UI, use **Check with Cloudflare**.
+
+## Project Overrides
+
+Project owners and project administrators can protect a project or make it public. Readers can see its state.
+
+```sh
+void project zero-trust status
+void project zero-trust protect
+void project zero-trust public
+void project zero-trust reconcile
+```
+
+`status` also tells you whether protection can be changed right now. Making a project public does not change the default for new projects.
+
+Installation administrators can do the same from the project page in the administrator UI or with `void platform zero-trust project-status|project-protect|project-public|project-reconcile <project-id>`.
+
+Deploys and rollbacks wait until a project's protection change is finished. If one is refused, run `void project zero-trust status` to see why; the owner or a project administrator can run `void project zero-trust reconcile` before you try again. A protected project can have up to 100 custom domains.
+
+## Disable Zero Trust
+
+```sh
+void platform zero-trust disable
+```
+
+This removes the Access applications Void created and makes all projects public. On large installations it runs in steps; run it again, or check `void platform zero-trust status`, until Zero Trust shows as disabled with no operation running.
+
+Disable Zero Trust and wait for its applications to be removed before [uninstalling the platform](/guide/platform/installation/uninstall). If project deletion stopped partway, retry `void project delete` for that project.
+
+## How Protection Works
+
+Cloudflare Access handles sign-in and applies your policies. Void also verifies the token before serving a protected project. Public projects allow visitors without sign-in.
+
+### What Visitors See
+
+A protected project asks visitors to sign in with one of the identity providers you selected. If you selected exactly one, visitors go straight to it. Otherwise, they pick one of the selected providers. A sign-in lasts 12 hours. After that, Access asks again.
+
+Protection follows the project to every hostname it answers on:
+
+| Hostname                                  | Protected project | Public project |
+| ----------------------------------------- | ----------------- | -------------- |
+| `<slug>.<your domain>`                    | Sign-in required  | Open to anyone |
+| The project's `workers.dev` testing URL   | Sign-in required  | Open to anyone |
+| Custom domains, such as `app.example.com` | Sign-in required  | Open to anyone |
+
+Void only covers the `workers.dev` testing URLs of this installation. Other Workers in the account are not affected. On an installation without a domain, the `workers.dev` testing URL is the only project URL, and the shared project application covers only those URLs.
+
+#### The 403 Page
+
+A request without a valid token receives `403 Cloudflare Access authentication required`. Page requests show an HTML error; API and asset requests receive plain text. These responses are never cached.
+
+Visitors who went through the sign-in page normally never see it. They can see it:
+
+- for a short time while the project is switching between protected and public;
+- while a Zero Trust change is still being applied to the project;
+- when a Void-managed Access application was deleted, or its hostnames were changed, in the Cloudflare dashboard. See [Editing Applications in the Dashboard](#editing-applications-in-the-dashboard).
+
+#### Every Path Is Covered
+
+Protection applies to the whole hostname. There are no path exceptions. `/api/*` routes, static files, hashed assets, `robots.txt`, `favicon.ico`, server-sent events, and WebSockets all require a signed-in visitor.
+
+#### Webhooks and Other Non-Browser Clients
+
+Project protection requires a person’s identity. Webhooks, CI jobs, uptime checks, and unauthenticated `curl` calls receive the sign-in page or a 403.
+
+If a project must accept such requests:
+
+- make the project public with `void project zero-trust public` and check callers in your own code, or
+- move the endpoints that machines call into a separate project, and make only that project public.
+
+### Access Applications Void Creates
+
+Void creates and owns these self-hosted applications in your Zero Trust organization:
+
+| Application                | Covers                                                                    | Policy                                                           | Exists                                                             |
+| -------------------------- | ------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------------ |
+| Shared project application | `*.<your domain>` and this installation's `workers.dev` testing URLs      | Your selected policies and identity providers                    | Once, while Zero Trust is enabled                                  |
+| Public exception           | One public project's `<slug>.<your domain>` and `workers.dev` testing URL | A Bypass policy for Everyone, named `Void project is public`     | One for each public project                                        |
+| Custom domain application  | All custom domains of one protected project                               | Your selected policies and identity providers                    | One for each protected project that has custom domains             |
+| Health check exception     | `void-platform-health.<your domain>/health`                               | A Bypass policy for Everyone, named `Void platform health check` | Once, while Zero Trust is enabled on an installation with a domain |
+
+Custom domains of a public project need no Access application.
+
+The number of applications Void needs is:
+
+```text
+2 + public projects + protected projects that have custom domains
+```
+
+Use 1 instead of 2 on an installation without a domain. For example, 40 projects with 10 public and 5 protected projects that have custom domains need 2 + 10 + 5 = 17 applications. Void stops with an error when the account has more than 500 Access applications.
+
+#### Recognizing Void's Applications
+
+Run `void platform zero-trust status` for the shared and health-check applications, or `void platform zero-trust project-status <project-id>` for a project's applications. These commands show their exact names and IDs.
+
+### Editing Applications in the Dashboard
+
+Manage Void’s applications through `void platform zero-trust configure` and the project commands. Editing or deleting them in Cloudflare can block access until you reconcile. Dashboard edits may be replaced the next time Void updates an application.
+
+You can edit a selected reusable policy’s rules in Cloudflare. Changes affect every project using that policy. Keep an identity-based Allow policy without Everyone or service tokens, then check it with:
+
+```sh
+void platform zero-trust status --check
+```
+
+- `drifted: true`: run `void platform zero-trust reconcile`.
+- `present: false`: check the token, application, identity providers, and policies, then reconcile.
+
+This checks the shared and health-check applications. For a public exception or custom-domain application, use the project's reconcile command.
+
+#### Repair Commands
+
+| Command                                                   | Scope                                 | Who can run it                           |
+| --------------------------------------------------------- | ------------------------------------- | ---------------------------------------- |
+| `void platform zero-trust reconcile`                      | Platform and all projects             | Installation administrators              |
+| `void platform zero-trust project-reconcile <project-id>` | One project                           | Installation administrators              |
+| `void project zero-trust reconcile`                       | Linked project, or `--project <slug>` | Project owner and project administrators |
+
+Project reconciliation requires platform status `ready`. Otherwise, reconcile the platform first.
+
+If an application was renamed, restore its recorded name before reconciling. Remove duplicate copies yourself. Deleting the shared application temporarily blocks protected projects; deleting the health-check exception can block upgrades and repair until it is restored.
+
+### What Happens During Changes
+
+Protection changes can temporarily return a 403. If a step fails, a protected project stays protected or refuses visitors until the change finishes.
+
+Protecting or making a project public usually finishes before the command returns. If it is still running or reports an error, inspect `void project zero-trust status`, fix the reported cause, and run `void project zero-trust reconcile`.
+
+Platform-wide changes run in steps. During initial setup, custom domains stay public until Void reaches their project. During disable, hostnames can become public at different times. Follow progress with `void platform zero-trust status`.
+
+A new custom domain becomes reachable only after its project’s protection is ready.
+
+### Caching
+
+Requests carrying an Access token bypass [ISR](/guide/edge/revalidation#cache-bypass) and the [static asset edge cache](/guide/edge/static-assets#non-hashed-assets). Protected pages render on each request, which can increase latency and request usage. Public projects keep their shared caches.
+
+## Recovery
+
+- **Status stays `configuring` or `disabling`.** Large changes run in steps. Scheduled maintenance continues them within a few minutes, or run `void platform zero-trust reconcile`.
+- **Status shows an error.** Fix the cause shown, such as token permissions or the application limit, then run `void platform zero-trust reconcile`. Otherwise Void retries every hour.
+- **One project shows an error.** The rest of the change still finishes. Void retries the project every hour, or its owner or a project administrator can run `void project zero-trust reconcile`. Until then, a project that was already protected stays protected, and a project being newly protected is never more open than before.
+- **Adding a domain stays pending because of a project.** Void publishes the new domain only after every project is ready for it. Platform status shows an error that names the projects it could not update. Check each one with `void platform zero-trust project-status <project-id>`, fix the cause, then run `void platform zero-trust reconcile` or rerun the domain command. Void also retries every hour. Your `workers.dev` URLs keep working meanwhile.
+- **A new project could not be set up.** Creating the project still succeeds with a warning. Void retries every hour, or run `void project zero-trust reconcile`.
+- **The saved API token expired or was revoked.** Run `void platform zero-trust configure --token-stdin` with a replacement token and the same identity providers, policies, and `--protect-new-projects` choice. Omit `--existing-projects`. Void continues the unfinished change, including an unfinished disable. Finish it before changing other settings.
+- **A selected identity provider or policy was deleted.** Run `void platform zero-trust disable` to stop the unfinished setup and remove its applications. This makes projects public. Then configure Zero Trust again with the new selections.

package/skills/void/docs/guide/platform/development/local.md

@@ -51,7 +51,7 @@ The command disables the optional build containers, so basic API and admin work
 does not require Docker. To develop managed builds, install Docker and run the
 API with containers enabled.
 
-Open `http://localhost:8787/admin/`. Setup writes local development values to the API and dashboard `.dev.vars` files, including the development authentication bypass and local database connection. Those files are ignored by Git. Production installations get separate credentials through the installer.
+Open `http://localhost:8787/admin/`. Setup writes the API's local database connection and development authentication bypass to `platform/packages/api/.dev.vars`. It configures `platform/packages/dashboard/.env` for the separate dashboard. Both files are ignored by Git. Production installations get separate credentials through the installer.
 
 The API's development bypass lets you work on the browser admin UI without setting up OAuth. Operator CLI sessions still require administrator authentication; they do not use the browser bypass.
 
@@ -63,7 +63,7 @@ The dashboard is a separate source app. After API setup, start it in another ter
 vp run --filter @voidcloud/dashboard dev
 ```
 
-Its local `.dev.vars` should point to the API you started:
+Setup points the dashboard's local `.env` at the API you started:
 
 ```dotenv
 API_URL=http://localhost:8787

package/skills/void/docs/guide/platform/development/runtime.md

@@ -52,12 +52,7 @@ If your fork has added managed GitHub builds and Cloudflare Access protects its
 to `/webhooks/github`: GitHub does not present your Access credentials. Do not add
 an Everyone or bypass policy to the API application.
 
-The API source package includes an optional, path-isolated Worker for this case.
-It accepts only `POST /github`, validates GitHub's signature over the raw body,
-and forwards one authenticated internal operation over an API service binding.
-The API independently verifies both that internal proof and GitHub's signature
-before running the normal webhook handler. Installations without perimeter
-protection can continue using the API's direct `/webhooks/github` endpoint.
+Deploy the optional webhook ingress at a separate public hostname. It accepts signed GitHub deliveries at `POST /github` and forwards them to your API through a service binding. Without Access protection, use the API’s `/webhooks/github` endpoint directly.
 
 To deploy the optional ingress:
 
@@ -87,18 +82,13 @@ To deploy the optional ingress:
    ingress URL ending in `/github`. Use GitHub's test delivery and confirm a 2xx
    response before relying on push builds.
 
-The ingress has no login, dashboard, project, operator, proxy, or arbitrary
-forwarding route. It does not make the GitHub integration part of the core
-installer, provision build executors, create a GitHub App, configure Cloudflare
-Access, or manage either Worker's secrets. Its body limit is 25 MiB, based on
-GitHub's [documented 25 MB webhook payload cap](https://docs.github.com/en/webhooks/webhook-events-and-payloads#payload-cap);
-malformed or larger deliveries are rejected before event processing.
+The ingress accepts payloads up to 25 MiB. See [GitHub’s payload limit](https://docs.github.com/en/webhooks/webhook-events-and-payloads#payload-cap).
 
 ## Deploying Source Builds from CI
 
 Build `@void/platform` from your checkout and pass its runtime directory to `install`, `upgrade`, `repair`, `enable`, or `rollback` with `--runtime`. Custom runtimes get the same integrity, migration, health, and rollback checks as packaged releases.
 
-Void records the runtime's manifest digest, whether it was packaged or custom, and its source revision. A build from a Git checkout automatically records `HEAD`, or `<HEAD>-dirty` when the checkout has uncommitted files. Build systems can set `VOID_PLATFORM_SOURCE_REVISION` to override automatic detection.
+Use a clean Git checkout or set `VOID_PLATFORM_SOURCE_REVISION` to identify the revision you deploy.
 
 A fresh CI runner can discover the installation each time. Set `CLOUDFLARE_API_TOKEN` and `VOID_PLATFORM_DATABASE_URL` through its protected environment, then:
 

package/skills/void/docs/guide/platform/development/schema-ci.md

@@ -35,61 +35,3 @@ workflows that call platform CI must grant `deployments: read` alongside
 `contents: read`.
 
 The upstream repository also contains workflows for deploying Void Cloud and publishing the official npm packages. Forks should configure their own release workflow around the built CLI and `platform upgrade --runtime`; the [source-build CI example](/guide/platform/development/runtime#deploying-source-builds-from-ci) shows the required inputs. Keep production credentials in protected environments restricted to the appropriate release refs.
-
-Public releases use matching versions for the CLI, scaffolder, adapters, and
-packaged platform. The publish workflow rejects mismatched versions and previously
-unpublished `void` versions that npm cannot reuse. Stable versions use `latest`;
-prereleases use their named channel, such as `beta` or `rc`. Numeric prereleases
-use `next`. The scaffolder installs its exact matching CLI version, so
-`create-void@beta` cannot silently select the stable CLI. Packaged platform
-runtimes record the release commit as their source revision.
-
-The npm release job uses [trusted publishing](https://docs.npmjs.com/trusted-publishers/)
-from GitHub-hosted runners, with `id-token: write` and no stored npm publishing
-token. Configure a trusted publisher for each public package using this
-repository, `publish.yml`, and the `Release` environment, allowing direct
-`npm publish`. A brand-new package
-needs an initial authenticated publication before its trusted publisher can be
-configured; subsequent releases use OIDC.
-
-The managed build fallback CLI also derives its version from
-`packages/void/package.json`; there are no separate version pins to update.
-Build its image from the repository root with
-`docker build --file platform/packages/api/container/Dockerfile .`.
-The root `.dockerignore` limits that build context to the agent, Dockerfile,
-and public SDK manifest.
-
-Publishing requires both SDK CI and platform CI, including the platform unit and
-API integration suites. Release tags also run the Windows SDK checks; a passing
-SDK-only build cannot publish a changed control plane.
-
-### Retrying a Release
-
-To retry a failed release without moving an existing tag, add `+retry.N` to a
-new Git tag, with `N` starting at `1`. Keep the package versions unchanged:
-
-| Git tag                  | Package version | npm channel |
-| ------------------------ | --------------- | ----------- |
-| `v0.21.0`                | `0.21.0`        | `latest`    |
-| `v0.21.0+retry.1`        | `0.21.0`        | `latest`    |
-| `v0.21.0-beta.1+retry.2` | `0.21.0-beta.1` | `beta`      |
-
-For example, when the packages are at `0.21.0`, commit the release fix and tag
-that commit:
-
-```sh
-git tag -a 'v0.21.0+retry.1' -m 'Retry 0.21.0 publication.'
-git push origin 'refs/tags/v0.21.0+retry.1'
-```
-
-The retry suffix belongs only in the Git tag, not in `package.json`. A `-1`
-suffix is a distinct prerelease version, not a retry. Tag and package versions
-are checked before dependency installation and the full CI jobs; retries still
-run the normal release checks.
-
-Retries publish only package versions that are still missing from npm. They
-cannot replace an already-published version. If an earlier attempt partially
-published the release and you changed its package contents, bump the version
-instead of combining different contents under the same version.
-
-For implementation history, use the design archive at `platform/meta/design-docs/README.md`. Its proposals explain earlier decisions; the source and current guides define the supported behavior.

package/skills/void/docs/guide/platform/installation/credentials.md

@@ -12,11 +12,11 @@ For a domain installation, create two custom tokens using Cloudflare's [API toke
 
 For workers.dev testing with the default API hostname, browser login can authorize installation: you only need to create the runtime token and R2 credentials below. Skip the zone permissions until you add a domain.
 
-Browser login does not grant AI Gateway access. A preview can therefore show **inspect ai-gateway**: Void verifies that resource with the runtime token after you confirm installation, before creating any resources. Include **Account → AI Gateway → Edit** on that token. Other infrastructure continues using your browser login, and a normal API-token installation keeps using its management token when that token already has access.
+Browser login does not grant AI Gateway access. Include **Account → AI Gateway → Edit** on the runtime token so Void can verify and create that resource.
 
 The management token lets your CLI install and maintain the platform. The runtime token is stored as a Worker secret so the platform can deploy apps after you close your terminal. They are separate credentials.
 
-The runtime-token link preselects all required account permissions, including Workers Tail, Hyperdrive, and AI Gateway when needed. Review them against the short summary beside the link before creating the token. If the form differs, use that summary to correct it. For a domain installation, also select the indicated zone. See [Cloudflare's token template documentation](https://developers.cloudflare.com/fundamentals/api/how-to/account-owned-token-template/).
+The installer’s runtime-token link preselects required account permissions. Compare the form with the checklist shown beside the link, and select the indicated zone for a domain installation.
 
 ::: details Permissions to select for each token
 
@@ -57,13 +57,15 @@ void platform upgrade your-installation-id
 
 Set the same two variables before `void platform install` to enable email during a new installation. Void records the pair for later upgrades; an ordinary upgrade cannot replace it.
 
+Before installing, enable [Cloudflare Email Routing](https://developers.cloudflare.com/email-service/get-started/route-emails/) for the exact shared sender domain and confirm that its MX records point to Cloudflare. For a subdomain, add that name under the zone's **Email Routing → Settings → Subdomains**. Cloudflare adds the required MX and SPF records. The installer's shared-mail bootstrap verifies those records; it does not add them. Keep existing mail-provider records on other domain names in place.
+
 Enabling email lets administrators [register email domains for projects](/guide/platform/administration/email#registering-email-domains-for-projects) and lets projects register destination addresses through the runtime token. That needs **Email Routing Addresses: Edit** and **Email Sending: Edit** on the account, plus **Zone: Read**, **Zone Settings: Edit** and **Email Routing Rules: Edit** on the zones that will carry mail. The runtime-token link preselects them when email is enabled. Email Sending onboarding for arbitrary recipients needs Workers Paid.
 
-The installer deploys the email gateway, prepares the shared mail route, and verifies inbound readiness before opening platform traffic. If setup fails, correct the reported permission, mail-zone configuration, or routing conflict, then rerun the same install or upgrade command. A fresh install resumes with `void platform install --resume --name <installation-id>`.
+The installer deploys the email gateway, prepares the shared mail route, and verifies inbound readiness before opening platform traffic. If setup fails, correct the reported permission, exact-domain MX records, or routing conflict, then rerun the same install or upgrade command. A fresh install resumes with `void platform install --resume --name <installation-id>`; it continues the recorded email operation after the configuration is corrected.
 
 ## R2 Upload Credentials
 
-The installer opens the **R2 token creation** form directly, requesting an account token (or a user token if your role cannot create account tokens). Select **Object Read & Write**—the form starts with read-only access—and keep **Apply to all buckets in this account (including newly created buckets)** selected. This lets the token access the buckets Void creates afterward. Create the token and save its **Access Key ID** and **Secret Access Key**. These are different from the management/runtime tokens above. See [R2's token instructions](https://developers.cloudflare.com/r2/api/tokens/).
+In the **R2 token creation** form opened by the installer, select **Object Read & Write** and **Apply to all buckets in this account (including newly created buckets)**. Create an account token, or a user token if your role requires it. Save its **Access Key ID** and **Secret Access Key** in your password manager. These differ from the management and runtime API tokens. See [R2’s token instructions](https://developers.cloudflare.com/r2/api/tokens/).
 
 ## Signing and Encryption Keys {#signing-and-encryption-keys}
 

package/skills/void/docs/guide/platform/installation/domains.md

@@ -15,17 +15,19 @@ void platform domain set example.app
 
 The command selects your installed platform (or offers a picker), finds or creates its zone, sets up DNS and routing, and verifies HTTPS before publishing the new application URLs. Set the management token as described in [installation setup](/guide/platform/installation/setup) when creating DNS or a zone. Grant the existing runtime token **Cache Purge: Purge** on the new zone; Void checks that permission through the running platform without asking you to paste its token again.
 
-If nameservers or certificates are pending, follow the printed guidance and rerun the same command. Your workers.dev app URLs continue working during and after setup. Projects, deployments, secrets, and the platform API URL stay the same, so developers do not reconnect and configured login callbacks do not change. DNS and configuration changes may take time to propagate.
+If nameservers, certificates, or project Zero Trust protection are pending, follow the printed guidance and rerun the same command. Void preserves each project's public or protected setting before making the new URLs available. Your workers.dev app URLs continue working during and after setup. Projects, deployments, secrets, and the platform API URL stay the same, so developers do not reconnect and configured login callbacks do not change. DNS and configuration changes may take time to propagate.
 
 Use `--installation <id>` to select an installation explicitly, `--zone example.com` for an app domain such as `apps.example.com`, or `--dedicated-zone` for catch-all routing on a dedicated zone. Nested domains still need the wildcard certificate described below. This command adds the first domain; replacing an existing application domain is not currently supported. It uses the installed runtime and does not require `--runtime` or an app redeploy.
 
+Choose an application domain whose wildcard leaves existing Worker Custom Domains reachable. Existing more-specific routes covering all requests can preserve those hostnames. If Void reports a conflict, choose another application domain; for a new installation, you can start with `void platform install --workers-dev` and add a suitable domain later.
+
 Browser login sessions are specific to each origin. Apps using their own OAuth providers may need to register their new callback URLs. Void's built-in auth uses the request origin automatically unless the app overrides that configuration.
 
 ### What Changes in Testing Mode?
 
-Each deployed app gets a small forwarding Worker and its own `workers.dev` origin. It forwards requests, including WebSockets and SSE, through the same platform router. Names include installation and project IDs; a later project with the same slug cannot inherit a deleted project's test URL.
+In testing mode, each app gets a `workers.dev` URL. These URLs continue working after you add a domain; new apps then use the domain.
 
-Testing origins use shared ISR storage but bypass the extra edge response cache because you cannot use your zone's purge API for `workers.dev`. Custom-domain requests use the normal edge cache after activation. Existing test URLs and forwarding Workers are retained when you add a domain; new apps then use the domain without creating more forwarding Workers. Like other platform Workers, forwarders are retained for manual cleanup on uninstall; platform disablement and project suspension still apply to their traffic.
+Testing URLs support WebSockets, SSE, and shared ISR storage, but skip the extra edge response cache. Their forwarding Workers remain for manual cleanup after uninstall. Platform disablement and project suspension still block their traffic.
 
 ## Other Domain Options
 
@@ -49,6 +51,32 @@ The management token needs **SSL and Certificates: Read** (or Edit) on that zone
 
 :::
 
+## Optional Dashboard
+
+The API's `/admin/` pages are included in the core installation. You can deploy
+the optional user dashboard separately and configure its HTTPS origin during
+installation with `--dashboard-url https://dash.example.com`.
+
+For an existing installation, preview and apply the configuration with:
+
+```sh
+void platform repair <installation-id> --dashboard-url https://dash.example.com --plan
+void platform repair <installation-id> --dashboard-url https://dash.example.com --yes
+```
+
+The origin must contain no credentials, path, query, or fragment. Void saves it
+for login callbacks and keeps it across upgrades and repairs. The command does
+not create a dashboard Worker or DNS records; deploy that app separately. Omit
+the option to keep the saved origin. The dashboard provides sign-in, linked
+login methods, and sign-out; use the CLI for user project and team management.
+
+If Access protects the platform, its application must cover this dashboard
+origin too. Configure the origin when installing protection. To change it on an
+already protected platform, deliberately remove protection through authentication
+configuration, apply the origin, then enable protection again. Choose a separate
+admission rule first if signup depends on the Access gate. Maintenance stops if
+the configured origin is outside the active coverage.
+
 ## Cloudflare footprint
 
 New platform resources use deterministic `void-<installation-name>-<role>` names where Cloudflare allows them, such as `void-team-api`. Choose an unused installation name in the account; Void stops on an unowned name conflict instead of replacing that resource. Existing installations keep their recorded names, including older names with suffixes.