void 0.22.0 → 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

@@ -8,8 +8,6 @@ Project Zero Trust puts Cloudflare Access in front of the hostnames of projects
 
 This is separate from the Access login and protection for the platform API. Projects deployed directly to Cloudflare are not affected.
 
-The steps below set it up. [How Protection Works](#how-protection-works) explains what visitors see, which Access applications Void creates, and what happens while settings change.
-
 ## 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.
@@ -71,26 +69,11 @@ 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.
 
-Uninstalling the platform does not remove these applications. `void platform uninstall` refuses to start while Zero Trust is enabled, a change is still running, or some Void-managed Access applications are left. Its error lists their names. Disable Zero Trust first, then uninstall. Once the uninstall starts turning the platform off, Zero Trust changes and deployments are refused. If it stops after that point, run it again, or bring the platform back with `void platform enable` or `void platform repair`. If a project's applications could not be removed, Void retries every hour while the platform is enabled. If the error says a project deletion stopped partway, run `void project delete` for that project again to remove them.
+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
 
-Every request to a protected project passes two checks before your code runs:
-
-```text
-Visitor
-  │
-  ▼
-Cloudflare Access ─── not signed in ─────────▶ sign-in page
-  │ signed in and allowed by your policies
-  ▼
-Void checks the Access token ─── rejected ───▶ 403 page
-  │ token is valid for this hostname
-  ▼
-Your project: routes, pages, assets, WebSockets
-```
-
-A public project skips both. Access lets every visitor through, and Void does not look for a token.
+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
 
@@ -108,7 +91,7 @@ Void only covers the `workers.dev` testing URLs of this installation. Other Work
 
 #### The 403 Page
 
-Void answers `403 Cloudflare Access authentication required` when a request reaches a protected project without a valid Access token for it. Page requests get a short HTML error page. Requests under `/api`, requests for files, requests that are not `GET` or `HEAD`, and requests that do not accept HTML get the same message as plain text. The response is never cached.
+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:
 
@@ -122,29 +105,13 @@ Protection applies to the whole hostname. There are no path exceptions. `/api/*`
 
 #### Webhooks and Other Non-Browser Clients
 
-Void only accepts policies that match people by identity. It rejects Bypass and Service Auth policies, and rules that allow Everyone or any service token. So a machine cannot pass on its own. Payment and Git webhooks, CI jobs, uptime checks, and plain `curl` calls get the sign-in page or the 403 response.
+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.
 
-### Two Checks on Every Request
-
-Cloudflare Access is the first check. It runs at Cloudflare's edge, shows the sign-in page, and applies your policies. Only visitors your policies allow get an Access token for the project.
-
-Void is the second check. Before a protected project runs, Void confirms that the request carries an Access token that:
-
-- was issued by your Zero Trust team;
-- belongs to one of the Access applications Void created for this project's hostname;
-- has not expired.
-
-If any of this fails, the visitor gets the [403 page](#the-403-page). Your routes, assets, and caches are never reached.
-
-This gives you one guarantee: **deleting a Void-managed Access application, or changing its hostnames, cannot make a protected project public.** If someone deletes Void's application, or points it at other hostnames, visitors are refused instead of let in. Loosening the policies of Void's application in the dashboard does widen who can sign in, until the next update puts Void's policies back.
-
-The second check does not look at your policies again. Who may sign in is decided only by the policies in Cloudflare Access. If you loosen a selected policy, the change applies to every protected project.
-
 ### Access Applications Void Creates
 
 Void creates and owns these self-hosted applications in your Zero Trust organization:
@@ -168,147 +135,51 @@ Use 1 instead of 2 on an installation without a domain. For example, 40 projects
 
 #### Recognizing Void's Applications
 
-Void adds no tags. Its application names follow this pattern:
-
-```text
-void-<installation>-<code>-<random>-project-zero-trust     shared project application
-void-<installation>-<code>-<random>-public-<project-id>    public exception
-void-<installation>-<code>-<random>-protected-<project-id> custom domain application
-void-<installation>-<code>-<random>-platform-health        health check exception
-```
-
-- `<installation>` is the start of your installation ID, which begins with your installation name.
-- `<code>` is 16 characters. It is the same for every application of one installation.
-- `<random>` is 32 random characters.
-- `<project-id>` is the project ID, such as `proj_abc123def456`. The project slug is not part of the name.
-
-To see the exact names Void recorded, run `void platform zero-trust status` for the shared application and the health check exception, and `void platform zero-trust project-status <project-id>` for a project's applications. There, the public exception is listed as `bypass application name` and the custom domain application as `protected application name`.
+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
 
-Do not edit, rename, or delete Void's applications in the Cloudflare dashboard. Change the identity providers and policies with `void platform zero-trust configure` instead. See [Enable Zero Trust](#enable-zero-trust).
-
-You can still edit the rules inside a selected reusable policy. Void's applications use your policies as they are. Void checks them again during `void platform zero-trust configure` and `void platform zero-trust reconcile`, which stop with an error, and during `status --check`, which reports `present: false`. A policy fails this check when it now allows Everyone or any service token, or uses a Bypass or Service Auth decision.
-
-#### What Happens If You Do
-
-Void writes an application when it updates it: during platform `configure` or `reconcile`, during a project's `protect`, `public`, or `reconcile`, when a custom domain is added to or removed from that project, and while it retries a project that is not settled. Scheduled maintenance does not look for dashboard changes on settled projects. Until one of these runs, your change stays in effect.
+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.
 
-| Change in the dashboard                                | Effect                                                                                                                                                                                                | Repair                                              |
-| ------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------- |
-| Edit hostnames, policies, providers, or session length | Your change stays until the next update, which puts Void's settings back.                                                                                                                             | Run the reconcile command for that application      |
-| Delete the shared project application                  | Protected projects answer 403 on `<slug>.<your domain>` and `workers.dev` URLs. Their custom domains and public projects keep working.                                                                | `void platform zero-trust reconcile`                |
-| Delete a public exception                              | Visitors of that public project are asked to sign in, because the shared application now covers it.                                                                                                   | `void project zero-trust reconcile` in that project |
-| Delete a custom domain application                     | That protected project answers 403 on its custom domains.                                                                                                                                             | `void project zero-trust reconcile` in that project |
-| Delete the health check exception                      | Platform health checks fail with a redirect to sign-in, so the admin dashboard shows `dispatch` as unhealthy and `void platform upgrade` and `repair` stop at their health check.                     | `void platform zero-trust reconcile`                |
-| Rename an application                                  | Void stops updating or deleting it. Reconcile fails with `The recorded Access application no longer has its Void-owned name.` For the shared application, platform status then shows `error`.         | Rename it back to the recorded name, then reconcile |
-| Copy an application with the same name                 | Void ignores the copy while the original exists, and `disable` does not remove it. If the original is later deleted, reconcile fails with `Multiple Cloudflare Access applications are named <name>.` | Delete the copy, then reconcile                     |
-
-When Void recreates a deleted shared project application, the new application issues different Access tokens. Void then moves each protected project to it. On large installations this runs in steps, and protected projects answer 403 until Void reaches them.
-
-#### Checking for Changes
+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
 ```
 
-This compares the shared project application and the health check exception with the saved settings, and checks your selected identity providers and policies again. The output includes:
-
-```text
-checked: true
-live:
-  present: true
-  drifted: false
-```
-
-- `drifted: true` means the shared application or the health check exception no longer matches. Run `void platform zero-trust reconcile`.
-- `present: false` means Void could not read it. The application may be deleted, a selected identity provider or policy may be gone or no longer allowed, or the token may not work. Check the token and selections, then run `void platform zero-trust reconcile`.
+- `drifted: true`: run `void platform zero-trust reconcile`.
+- `present: false`: check the token, application, identity providers, and policies, then reconcile.
 
-`--check` only reads. It changes nothing. It does not check public exceptions or custom domain applications. If you think one was changed, run a reconcile command.
+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                                                   | Rewrites                                                                                     | Who can run it                               |
-| --------------------------------------------------------- | -------------------------------------------------------------------------------------------- | -------------------------------------------- |
-| `void platform zero-trust reconcile`                      | The shared project application, the health check exception, and every project's applications | Installation administrators                  |
-| `void platform zero-trust project-reconcile <project-id>` | One project's applications                                                                   | Installation administrators                  |
-| `void project zero-trust reconcile`                       | The linked project's applications, or pass `--project <slug>`                                | The project owner and project administrators |
+| 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 |
 
-The two project commands work only when platform status is `ready`. While a platform change runs, or after it fails, run `void platform zero-trust reconcile` first.
+Project reconciliation requires platform status `ready`. Otherwise, reconcile the platform first.
 
-### What Happens During Changes
-
-Void orders every change so that a protected project never becomes public by mistake. If a step fails, the project keeps its protection, or refuses visitors with the 403 page, until the change can finish.
-
-Void's router can keep a project's previous setting for up to about a minute. During that time, some visitors may see the 403 page instead of the sign-in page.
-
-#### Protecting or Making a Project Public
-
-`void project zero-trust protect` and `void project zero-trust public` usually finish before the command returns.
-
-- **Protect.** Void covers the custom domains first, then turns on its own check, then removes the public exception. Visitors may see the 403 page for a moment before Access starts asking them to sign in.
-- **Public.** Void adds the public exception first, then turns off its own check, then removes the custom domain application. Visitors may see the 403 page for a moment before the project opens.
-
-If the command prints `Zero Trust update is still in progress`, run `void project zero-trust reconcile` to continue, or wait for the hourly maintenance. If it fails with `Cloudflare Access could not be updated. Protection remains fail closed.`, fix the cause, then run `void project zero-trust reconcile`. Until then, a project that was protected stays protected. A project you were protecting may already ask for sign-in, or answer with the 403 page, but it is never more open than before. A project you were making public may already be open on some hostnames.
-
-Run `void project zero-trust status` to follow a change. `State:` shows `reconciling` while it runs, `error` when it needs attention, and `protected` or `public` when it is done. `Last error:` explains a failure.
-
-#### Enabling and Disabling Zero Trust
-
-Large changes run in steps. Platform status shows `configuring` or `disabling`, and project owners see `Available: no`. Scheduled maintenance continues within a few minutes.
-
-When you **enable** Zero Trust:
-
-1. Void adds the public exception for each project that stays public. These projects never ask visitors to sign in.
-2. Void creates the health check exception, then the shared project application. From here, the `<slug>.<your domain>` and `workers.dev` URLs of protected projects require sign-in.
-3. Void goes through the protected projects and covers their custom domains. A project's custom domains stay open until Void reaches it.
-
-If Void cannot add a project's public exception, the project shows `error`, and its visitors are asked to sign in until the next retry succeeds. Void retries every hour, or run `void project zero-trust reconcile` once platform status is `ready`.
+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.
 
-When you **disable** Zero Trust:
-
-1. Void turns off its own check for each protected project and removes its custom domain application. Custom domains open here.
-2. Void deletes the shared project application, then the health check exception. `<slug>.<your domain>` and `workers.dev` URLs open here.
-3. Void deletes the public exceptions. Public projects stay open the whole time.
-
-#### Custom Domains
-
-A custom domain on a protected project goes live only after Void adds it to the project's custom domain application. If Access cannot be updated, the domain stays pending and is not reachable. Void tries again each time it checks the domain.
-
-When you remove a custom domain, Void removes it from the project first, then from the Access application. If the Access update fails, the project shows `reconciling` or `error` and Void retries every hour. A protected project can have up to 100 custom domains. Custom domains on public projects need no Access change.
-
-#### New Projects
-
-A new project starts protected or public based on the default for new projects. If Void cannot set up its protection, creating the project still succeeds with a warning. See [Recovery](#recovery).
-
-#### Deploys and Rollbacks
+### What Happens During Changes
 
-Deploys and rollbacks wait while a project's protection is not settled, so a deploy cannot publish a project before its protection is in place. They are refused with `Zero Trust protection for this project is not ready`, followed by the reason:
+Protection changes can temporarily return a 403. If a step fails, a protected project stays protected or refuses visitors until the change finishes.
 
-- `Project Zero Trust is still being initialized.`
-- `The project public exception is still reconciling.`
-- `Project Zero Trust is still reconciling.`
+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`.
 
-If the saved platform configuration is invalid, they are refused with `The platform Zero Trust configuration is invalid.` instead. Ask a platform administrator to repair it.
+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 project that is already protected can still deploy during a platform-wide change. While it is being made public, deploys wait until that finishes. See [Project Overrides](#project-overrides) for what to do when a deploy is refused.
+A new custom domain becomes reachable only after its project’s protection is ready.
 
 ### Caching
 
-Responses for signed-in visitors are never shared between visitors. Void skips its shared caches for every request that carries an Access token: [ISR](/guide/edge/revalidation#cache-bypass) and the [static asset edge cache](/guide/edge/static-assets#non-hashed-assets). Each visitor gets a response made for their request.
-
-On a protected project, this means:
-
-- pages render on every request, and ISR never serves a cached page;
-- static files and hashed assets skip the edge cache;
-- the project handles more requests and may respond more slowly than a public project.
-
-Public projects keep using the shared caches as usual.
+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
 
-A project never becomes public by mistake while a change is in progress. See [What Happens During Changes](#what-happens-during-changes).
-
 - **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.

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}