void 0.21.9 → 0.23.0

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

@@ -50,38 +50,15 @@ function namedLayoutItems(ext) {
   ]
 }
 
-function blogLayoutItems(ext) {
-  return [
-    {
-      name: "pages/",
-      children: [
-        {
-          name: "_layouts/",
-          children: [
-            { name: `post${ext}`, description: "sidebar, date, author" },
-          ],
-        },
-        { name: `layout${ext}`, description: "nav + footer" },
-        {
-          name: "blog/",
-          children: [
-            { name: `layout${ext}`, description: "blog sidebar" },
-            { name: "hello.md", description: "layout: post → chain: [root, _layouts/post]" },
-            { name: `archive${ext}`, description: "(no layout) → chain: [root, blog/layout]" },
-          ],
-        },
-      ],
-    },
-  ]
-}
-
 </script>
 
 # Layouts & Shared Data
 
+Use layouts for navigation, headers, and other UI shared by several pages. Layouts nest with your directories and keep their component state as you navigate.
+
 ## Layouts
 
-Place a layout file in any `pages/` directory to wrap all pages in that subtree:
+Place a layout file in a `pages/` directory to wrap its pages:
 
 <FileTree :items="layoutBasicItems" adapter-tabs default-expanded />
 
@@ -169,8 +146,6 @@ When a page renders, the layout wraps it. The page component is injected as the
 
 <img src="./layout-nesting.svg" alt="Layout nesting diagram: pages/layout wraps pages/users/layout wraps pages/users/[id] page component" style="max-width: 520px; width: 100%;" />
 
-Layouts nest automatically and persist across navigations within their subtree, so component state is preserved.
-
 ## Named Layouts
 
 Named layouts let individual pages opt into a different layout without changing the URL structure. Define them in `_layouts/` directories within `pages/`:
@@ -237,68 +212,9 @@ layout: post
 | `"!landing"` | Replace the **entire** chain. Only the named layout wraps the page.            |
 | `false`      | No layout wrapping at all. Page renders standalone.                            |
 
-"Innermost" means the deepest layout in the resolved chain. If the chain is `[root, docs/layout]`, the named layout replaces `docs/layout`. If the chain is only `[root]`, it replaces root.
-
-### Resolution order
-
-When a page specifies `layout: "post"`, the scanner walks up the directory tree to find `_layouts/post`:
-
-```
-pages/guide/intro.md  (layout: post)
-
-1. pages/guide/_layouts/post.vue  → not found
-2. pages/_layouts/post.vue        → found ✓
-```
-
-Closest ancestor wins, same as default layout chain. If no matching named layout is found in any ancestor, the build fails with a clear error.
-
-### Examples
-
-**Blog with shared nav but post-specific layout:**
-
-<FileTree :items="blogLayoutItems" adapter-tabs default-expanded />
-
-`layout: post` on `blog/hello.md` replaces the innermost default layout (`blog/layout`) with `_layouts/post`. The root layout still wraps.
-
-**Fullscreen page with no layout:**
-
-::: code-group
-
-```tsx [React]
-export const layout = false;
-
-export default function Landing() {
-  return (
-    <div className="hero fullscreen">
-      <h1>Welcome</h1>
-    </div>
-  );
-}
-```
-
-```vue [Vue]
-<script>
-export const layout = false;
-</script>
-
-<template>
-  <div class="hero fullscreen"><h1>Welcome</h1></div>
-</template>
-```
-
-:::
-
-**Exclusive layout (skip all ancestors):**
-
-```md
----
-layout: '!landing'
----
+A named layout replaces the deepest default layout: in `[root, docs/layout]`, it replaces `docs/layout`; in `[root]`, it replaces the root.
 
-# Standalone Landing Page
-```
-
-Only `_layouts/landing` wraps this page, and the root layout is skipped entirely.
+Void uses the closest matching `_layouts/` file in the page's directory or an ancestor. A missing named layout fails the build.
 
 ## Shared Data
 
@@ -322,42 +238,4 @@ export default defineMiddleware(async (c, next) => {
 });
 ```
 
-Access it on the client with `useShared()`. The return type is inferred from your augmentation:
-
-::: code-group
-
-```tsx [React]
-import { useShared } from '@void/react';
-
-export default function Page() {
-  const { auth } = useShared(); // { auth: { user: AuthUser | null } }
-  return <p>Hello, {auth?.user?.name}</p>;
-}
-```
-
-```vue [Vue]
-<script setup lang="ts">
-import { useShared } from '@void/vue';
-const { auth } = useShared(); // { auth: { user: AuthUser | null } }
-</script>
-```
-
-```svelte [Svelte]
-<script>
-  import { useShared } from "@void/svelte";
-  const { auth } = useShared(); // { auth: { user: AuthUser | null } }
-</script>
-```
-
-```tsx [Solid]
-import { useShared } from '@void/solid';
-
-export default function Page() {
-  const shared = useShared(); // { auth: { user: AuthUser | null } }
-  return <p>Hello, {shared.auth?.user?.name}</p>;
-}
-```
-
-:::
-
-Shared data is separate from page props. Props come from the loader, while `useShared()` returns global data from middleware. See [Type Safety](../type-safety.md#context-variables) for more on augmenting `CloudContextVariables`.
+Call `useShared()` from your framework adapter, as in the layout examples above. Its return type is inferred from `CloudContextVariables`. Shared data comes from middleware; page props come from the loader. See [Context variables](../type-safety.md#context-variables).

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

@@ -24,17 +24,7 @@ export const loader = defineHandler(async (c) => {
 });
 ```
 
-`InferProps` extracts the return type from a `defineHandler` call, so you don't need to maintain a separate interface. You can also write the interface explicitly if you prefer:
-
-```ts
-export interface Props {
-  users: Array<{ id: number; name: string; email: string }>;
-}
-
-export const loader = defineHandler<Props>(async (c) => {
-  return { users: await db.select().from(users) };
-});
-```
+`InferProps` infers the loader’s return type, so page props stay in sync with the data it returns.
 
 ## Using the Data in Page Components
 
@@ -109,7 +99,7 @@ export default function UsersPage(props: Props) {
 
 ## Deferred Props
 
-Loaders sometimes need to fetch slower data such as analytics, external API responses, or AI inference. `defer()` lets you return a placeholder immediately so the page renders quickly, then streams the real data when it resolves:
+Use `defer()` for slow data. The page renders immediately and receives the result when it is ready:
 
 ```ts
 // pages/dashboard.server.ts
@@ -235,16 +225,10 @@ export default function Dashboard(props: Props) {
 
 :::
 
-### How Streaming Works
-
-On the first request, React renders the nearest Suspense fallback for deferred props; the other adapters render their loading state. As data becomes available, the server sends it in inline scripts on the same response.
-
-A route with `ssr = false` still receives those scripts, even though its component mounts in the browser. During client-side navigation, deferred data arrives as newline-delimited JSON on the navigation response.
-
 ### Deferred Props After Mutations
 
 ::: info
-When a mutation runs, the loader runs again to provide fresh props, but deferred props cannot stream over a mutation response. The client preserves the last resolved value for each deferred prop, so the UI keeps showing the previous data until the next full page load or SPA navigation.
+After an action, deferred props keep their last resolved values until the next page load or client-side navigation. Other loader props refresh immediately.
 :::
 
 ### Grouped Deferred Props

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

@@ -33,9 +33,7 @@ function mdFileItems(ext) {
 
 # Markdown
 
-Markdown pages let you use `.md` files as first-class pages in Void's file-based routing. They compile to static HTML at build time with zero client JavaScript, integrate with the layout chain, and can embed interactive framework components as [islands](./islands).
-
-The `@void/md` package is opt-in as it contains markdown processing and syntax highlighting dependencies that are not necessarily needed in every app.
+Add `.md` files to `pages/` for Markdown routes. Pages inherit layouts and render as HTML, with JavaScript only for [islands](./islands), client scripts, and code-copy buttons.
 
 ## Setup
 
@@ -115,8 +113,6 @@ export default defineConfig({
 
 :::
 
-That's it. Any `.md` file in `pages/` is now a routable page.
-
 ## Page Anatomy
 
 A markdown page has three optional parts: a script block, frontmatter, and the body.
@@ -146,7 +142,7 @@ Welcome to Void. Here's an interactive demo:
 
 ## Client Scripts
 
-The `<script>` block can contain both island imports and regular JavaScript. Island imports (with `{ island }`) go through the SSR + hydration pipeline as usual. Everything else is bundled as a client module and executed when the page loads.
+Use the `<script>` block for island imports and JavaScript that runs when the page loads:
 
 ```md
 <script>
@@ -163,14 +159,7 @@ document.querySelector('.date').textContent = format(new Date(), 'PPP')
 Published: <span class="date"></span>
 ```
 
-In this example:
-
-- `Counter` is an island, so it is SSR'd and hydrated on the client
-- `date-fns` and the `querySelector` call are client code, so they are bundled and run on page load
-
-Each page's client script is code-split into its own chunk via dynamic import, so only the current page's script is loaded. Pages without client code ship zero extra JS.
-
-Client scripts work in both dev (served on-demand, HMR support) and production builds.
+Only the current page's client script loads. Pages without client code need no additional script.
 
 ## File Structure
 
@@ -329,7 +318,7 @@ Users who want full control can skip the import and write their own CSS.
 
 ## Markdown Features
 
-All features produce static HTML at build time with zero client JS (except the copy button).
+Markdown features render as static HTML. Code-copy buttons add a small client script.
 
 ### Containers
 
@@ -378,7 +367,7 @@ Custom titles work too: `::: tip Pro Tip`.
 
 ### Syntax Highlighting
 
-Code blocks are highlighted at build time with [Shiki](https://shiki.style) using dual light and dark themes by default: `github-light` and `github-dark`. No client-side JavaScript is needed because theme switching is pure CSS.
+Code blocks use [Shiki](https://shiki.style) with `github-light` and `github-dark` themes by default.
 
 ### Line Highlighting
 
@@ -408,9 +397,7 @@ export function hello() {
 }
 ```
 
-### Copy Button
-
-Code blocks include a copy button. That is the only feature here that needs client-side JS, and it only adds a roughly 200 byte inline script for the clipboard API. The script is injected only when code blocks are present.
+Code blocks include a copy button.
 
 ### Line Numbers
 
@@ -459,21 +446,9 @@ Add classes, IDs, or attributes to any element:
 Paragraph with attributes. {.note}
 ```
 
-### Heading Anchors
-
-All headings get permalink anchors automatically, enabling direct linking to any section.
-
-### Table of Contents
+### Navigation and Media
 
-Use the `[[toc]]` directive to render an inline table of contents from the page's headings.
-
-### Images
-
-Image paths are normalized automatically. Images are lazy-loaded by default.
-
-### Links
-
-External links automatically get `target="_blank" rel="noreferrer"`. Internal `.md` references resolve to their route paths.
+Headings include permalink anchors. Use `[[toc]]` for a table of contents. Images are lazy-loaded, and `.md` links resolve to page routes.
 
 ## Plugin Options
 
@@ -491,147 +466,14 @@ voidMarkdown({
 | `shiki.themes` | `{ light: string; dark: string}` | `{ light: "github-light", dark: "github-dark" }` | Shiki color themes           |
 | `shiki.langs`  | `string[]`                       | Common web languages                             | Additional languages to load |
 
-## Example: Docs Layout with Sidebar
-
-Here's a full example of a docs layout using `useFrontmatter()` and `@void/md/pages` to build a sidebar:
-
-::: code-group
-
-```tsx [React]
-// pages/docs/layout.island.tsx
-import '@void/md/theme-content.css';
-import { useFrontmatter } from '@void/md';
-import pages from '@void/md/pages';
-import { useRouter } from '@void/react';
-
-const docPages = pages.filter((p) => p.path.startsWith('/docs/'));
+## Building a Sidebar
 
-export default function DocsLayout({ children }) {
-  const fm = useFrontmatter();
-  const { path } = useRouter();
-
-  return (
-    <div className="docs-layout">
-      <aside>
-        <nav>
-          {docPages.map((page) => (
-            <a key={page.path} href={page.path} className={page.path === path ? 'active' : ''}>
-              {page.title}
-            </a>
-          ))}
-        </nav>
-      </aside>
-      <main className="void-md">
-        <h1>{fm.title}</h1>
-        {children}
-      </main>
-    </div>
-  );
-}
-```
+Use `@void/md/pages` to select the pages for your sidebar:
 
-```vue [Vue]
-<!-- pages/docs/layout.island.vue -->
-<script setup>
-import { useFrontmatter } from '@void/md';
-import pages from '@void/md/pages';
-import { useRouter } from '@void/vue';
-
-const fm = useFrontmatter();
-const { path } = useRouter();
-const docPages = pages.filter((p) => p.path.startsWith('/docs/'));
-</script>
-
-<style>
-@import '@void/md/theme-content.css';
-</style>
-
-<template>
-  <div class="docs-layout">
-    <aside>
-      <nav>
-        <a
-          v-for="page in docPages"
-          :key="page.path"
-          :href="page.path"
-          :class="{ active: page.path === path }"
-        >
-          {{ page.title }}
-        </a>
-      </nav>
-    </aside>
-    <main class="void-md">
-      <h1>{{ fm.title }}</h1>
-      <slot />
-    </main>
-  </div>
-</template>
-```
-
-```svelte [Svelte]
-<!-- pages/docs/layout.island.svelte -->
-<script>
-import "@void/md/theme-content.css";
-import { useFrontmatter } from "@void/md";
-import pages from "@void/md/pages";
-import { useRouter } from "@void/svelte";
-
-const fm = useFrontmatter();
-const { path } = useRouter();
-const docPages = pages.filter((p) => p.path.startsWith("/docs/"));
-</script>
-
-<div class="docs-layout">
-  <aside>
-    <nav>
-      {#each docPages as page}
-        <a href={page.path} class:active={page.path === path}>
-          {page.title}
-        </a>
-      {/each}
-    </nav>
-  </aside>
-  <main class="void-md">
-    <h1>{fm.title}</h1>
-    <slot />
-  </main>
-</div>
-```
-
-```tsx [Solid]
-// pages/docs/layout.island.tsx
-import '@void/md/theme-content.css';
-import { useFrontmatter } from '@void/md';
+```ts
 import pages from '@void/md/pages';
-import { useRouter } from '@void/solid';
-import { For } from 'solid-js';
 
-const docPages = pages.filter((p) => p.path.startsWith('/docs/'));
-
-export default function DocsLayout(props) {
-  const fm = useFrontmatter();
-  const { path } = useRouter();
-
-  return (
-    <div class="docs-layout">
-      <aside>
-        <nav>
-          <For each={docPages}>
-            {(page) => (
-              <a href={page.path} classList={{ active: page.path === path() }}>
-                {page.title}
-              </a>
-            )}
-          </For>
-        </nav>
-      </aside>
-      <main class="void-md">
-        <h1>{fm.title}</h1>
-        {props.children}
-      </main>
-    </div>
-  );
-}
+const docPages = pages.filter((page) => page.path.startsWith('/docs/'));
 ```
 
-:::
+Render a link with `page.path` and `page.title` for each entry. Use `useFrontmatter()` in the layout to display the current page's metadata, and wrap its content in `.void-md` when using the provided theme.

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

@@ -86,9 +86,7 @@ export default defineConfig({
 
 :::
 
-The adapter generates the server entry, client entry, and hydration code.
-
-Each adapter plugin includes the framework's Vite plugin (`@vitejs/plugin-react`, `@vitejs/plugin-vue`, `@sveltejs/vite-plugin-svelte`, `vite-plugin-solid`) so you don't need to install or configure it separately. Pass framework plugin options via `voidReact({ react: { ... } })`, `voidVue({ vue: { ... } })`, `voidSvelte({ svelte: { ... } })`, or `voidSolid({ solid: { ... } })` if needed.
+Each adapter includes its framework's Vite plugin. Pass framework plugin options via `voidReact({ react: { ... } })`, `voidVue({ vue: { ... } })`, `voidSvelte({ svelte: { ... } })`, or `voidSolid({ solid: { ... } })` if needed.
 
 ## Directory Structure
 
@@ -106,15 +104,7 @@ File-based routing rules are the same as [server routing](../server-routing.md):
 
 ## How Navigation Works
 
-The first page load and later navigations use the same server loaders:
-
-| Request               | Response                                                                                                       |
-| --------------------- | -------------------------------------------------------------------------------------------------------------- |
-| Initial page load     | Full SSR HTML. Client hydrates automatically. Routes with `ssr = false` return a client-mounted shell instead. |
-| Subsequent navigation | JSON with component name + props. Client component swap or re-render.                                          |
-| Form submission       | Runs action, then returns fresh props or a redirect.                                                           |
-
-The first request receives rendered HTML. Later navigations load page data and update the UI without reloading the whole document.
+The first request receives rendered HTML. Later navigations run the loader and update the page without reloading the document. Form submissions run an action, then refresh page props or redirect.
 
 To opt a specific route out of server-rendered component HTML, export `ssr = false` from its companion `.server.ts` file:
 
@@ -182,7 +172,7 @@ import { Link } from "@void/solid";
 
 :::
 
-The `Link` components also support query data, history replacement, document navigation, and cancellable client-side navigation:
+`Link` also supports query data, history replacement, full-page navigation, and cancellation:
 
 ```tsx
 <Link href="/users" data={{ page: 2, tag: ['active', 'new'] }}>
@@ -209,7 +199,7 @@ The `Link` components also support query data, history replacement, document nav
 </Link>
 ```
 
-`prefetch` and `reloadDocument` are GET-only. Passing either prop to a mutation link throws. GET `data` is merged into the rendered `href` query string; arrays become repeated keys, `null` and `undefined` are omitted, and nested objects throw.
+`prefetch` and `reloadDocument` work only with GET links. GET `data` becomes query parameters; use scalar values or arrays.
 
 For programmatic navigation, use `useRouter()`:
 
@@ -235,13 +225,13 @@ export default function PostPage() {
 
 ## Scroll Restoration
 
-The Void Router automatically saves and restores scroll position during client-side navigation:
+Client-side navigation manages scroll position automatically:
 
 - **Back/forward navigation** restores the exact scroll position you were at before navigating away.
-- **Forward navigation** scrolls to the top of the page.
+- **New navigation** scrolls to the top of the page.
 - **Hash links** (`/docs#api`) scroll to the target element. Same-page hash links (`#section`) skip the server fetch entirely.
 
-This works out of the box with no configuration. If you need to opt out for a specific navigation, pass `preserveScroll: true`:
+To keep the current scroll position, pass `preserveScroll: true`:
 
 ```ts
 router.visit('/users', { preserveScroll: true });

package/skills/void/docs/guide/pages-routing/view-transitions.md

@@ -4,7 +4,7 @@ outline: deep
 
 # View Transitions
 
-Pages mode supports the browser's native [View Transition API](https://developer.mozilla.org/en-US/docs/Web/API/View_Transition_API) for animated page transitions. When enabled, navigations are wrapped in `document.startViewTransition()`, which gives you a smooth cross-fade between pages by default. You can customize the effect entirely with CSS.
+Add animated page transitions with the browser’s [View Transition API](https://developer.mozilla.org/en-US/docs/Web/API/View_Transition_API). Pages cross-fade by default; use CSS to customize the animation.
 
 ## Enabling View Transitions
 

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

@@ -30,10 +30,7 @@ the company sign-in before Void login. Interactive Access authentication uses a
 locally installed `cloudflared` and saves its short-lived credential in your
 system keychain for that platform origin. You do not need to copy browser cookies.
 
-For CI, Access credentials do not replace Void deployment credentials. A project
-owner creates the latter with `void project token create`; it is independently
-revocable, expires within 90 days, and authorizes only that project's deploy
-workflow. Human and operator tokens cannot be renewed by Access service proof.
+For CI, use a [project deploy token](/guide/platform/installation/first-deployment) alongside your Access credentials. An Access service token does not authorize a Void deployment.
 
 Store Access credentials in origin-keyed `VOID_ACCESS_CREDENTIALS`. A deploy
 that uses prerendering or remote bindings needs entries for both the exact API

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

@@ -6,7 +6,26 @@ outline: deep
 
 ## Managing Email
 
-These commands apply to a platform that enables email. Every project can send from and receive at `<slug>+tag@<mail domain>` on the platform's shared mail domain; the [email guide](/guide/email) describes what applications do with that.
+These commands apply to a platform that enables email. Every project can send from `<slug>+tag@<mail domain>` on the platform’s shared mail domain. Deploying an app with `email/` handlers sets up receiving at that address once its recipient rule is ready; the [email guide](/guide/email) describes what applications do with that.
+
+Shared inbound mail uses one exact routing rule per receiving project and enables Cloudflare’s per-zone plus addressing. Creating a project or deploying an app that only sends mail consumes no inbound rule. Existing rules and the apex catch-all remain in place. Cloudflare normally allows [200 routing rules per domain](https://developers.cloudflare.com/email-service/platform/limits/); remove unused rules or request a higher limit if the shared domain reaches capacity. An unrelated rule for a project’s base address or a plus address blocks its setup until that conflict is removed.
+
+If recipient creation is interrupted, inspect its retained intent:
+
+```sh
+void platform email shared-recipients --project my-app
+void platform email shared-recipient-resolve <recipient-id> --ended --outcome not-applied --reason "Provider audit confirms the request did not create a rule" --plan
+```
+
+Wait until the reported recovery time, confirm the original execution ended,
+and inspect the exact provider resource shown in the plan. Use `applied` when
+the exact owned rule exists, or `not-applied` only when the provider audit
+establishes that creation did not occur. Absence alone does not establish the
+outcome. Run the same command with `--yes` after inspection. Recovery records
+the decision in platform events without creating or deleting rules. Normal
+reconciliation verifies delivery afterward; a deleting project stays closed
+and its deletion can be retried. See [operator email commands](../../../reference/cli/platform-email.md#operator-email)
+for the recovery requirements.
 
 ### Deciding who mail may reach
 
@@ -19,7 +38,15 @@ void platform email policy-set any
 void platform email policy-set verified
 ```
 
-`domains` lets every project mail any address on the listed domains in addition to its verified recipients; `any` lifts the check. Cloudflare still refuses a recipient it has not verified until your mail domain is onboarded for Email Sending, which needs Workers Paid on the platform's account. Until then such sends come back as `UNVERIFIED_DESTINATION` for that recipient, whatever the policy says. Two things the policy never changes: sends from a project's own custom domain, and mail to any address on the platform's own mail domain — those stay verified-recipient-only, so no project reaches another project's inbox without its consent. A tightening applies to new send admissions as soon as it commits; previously admitted attempts may finish. The same setting is on the admin UI's **Email** page.
+Choose a policy in the admin UI's **Email** page or with the commands above:
+
+- `verified`: only each project's verified recipients.
+- `domains`: verified recipients plus any address on the listed domains.
+- `any`: any recipient.
+
+Unverified recipients still require Cloudflare Email Sending onboarding and [Workers Paid](https://dash.cloudflare.com/?to=/:account/workers/plans). Otherwise those sends return `UNVERIFIED_DESTINATION`. Mail from a project's custom domain, and mail to the platform's own mail domain, always requires recipient verification.
+
+Policy changes apply to new sends; admitted attempts may finish.
 
 ### Project caps
 
@@ -75,16 +102,16 @@ void platform email settings-set --domains admin
 Then register a domain for a project. The zone must be in the platform's Cloudflare account; the platform's own credential does the setup, and no Cloudflare credential is stored per domain:
 
 ```sh
-void platform email domain-add mail.example.com --project hr-portal
-void platform email domain-status mail.example.com
-void platform email domain-rotate-secret mail.example.com
+void platform email domain-add example.com --project hr-portal
+void platform email domain-status example.com
+void platform email domain-rotate-secret example.com
 void platform email domains
 ```
 
-Name the exact mail domain: a subdomain such as `mail.example.com` when the apex already receives mail, otherwise the apex itself. `domain-status` reports inbound, outbound, and management readiness separately. Follow any required DNS or Cloudflare dashboard step, then use `domain-sync` to reconcile. Use `domain-rotate-secret` when you need to replace the zone ingress credential explicitly. Email Sending onboarding needs Workers Paid; after upgrading, `domain-sync` re-attempts it. For a zone in another Cloudflare account, pipe an API token for that account on standard input:
+Use the apex of the selected Cloudflare zone. Platform-managed custom inbound email uses its catch-all, which does not cover subdomains; choose an apex without another mail provider or use the platform’s shared mail address. `domain-status` reports inbound, outbound, and management readiness separately. Follow any required DNS or Cloudflare dashboard step, then use `domain-sync` to reconcile. Use `domain-rotate-secret` when you need to replace the zone ingress credential explicitly. Email Sending onboarding needs Workers Paid; after upgrading, `domain-sync` re-attempts it. For a zone in another Cloudflare account, pipe an API token for that account on standard input:
 
 ```sh
-void platform email domain-add mail.other.example --project hr-portal --token-stdin --yes < token.txt
+void platform email domain-add other.example --project hr-portal --token-stdin --yes < token.txt
 ```
 
 Project owners see administrator-registered domains in `void email domain list` and `status`; `status` names the `void platform email` command for any step they cannot take themselves, and `sync` and `remove` point them at `domain-sync` and `domain-remove`. A domain an owner registered before you switched to `admin` stays theirs to renew, sync and remove. The runtime token needs the email permissions listed in the [self-hosting guide](/guide/platform/installation/credentials#runtime-token-permissions) for this to work.
@@ -97,7 +124,7 @@ to finish the retained cleanup. If its token has expired or been revoked, provid
 a replacement scoped to the same account and zone:
 
 ```sh
-void platform email domain-remove mail.other.example --token-stdin --yes < token.txt
+void platform email domain-remove other.example --token-stdin --yes < token.txt
 ```
 
 This recovery is available only after project deletion has begun and no other