From d710cbd8be2f62f13c2ebb2a9a41ec45586ee41a Mon Sep 17 00:00:00 2001 From: Mitra Kermanian Date: Sun, 23 Aug 2026 19:31:01 -0400 Subject: [PATCH] docs: fix four broken cross-page anchor links (#128278) * docs: fix five broken cross-page anchor links Five internal doc links pointed at anchors that do not exist on the target page, so readers following them landed at the top of the page instead of the referenced section. - /gateway/cloud-workers#desktop -> #desktop-interactive (heading is "## Desktop (interactive)"), from experimental-features and the gateway protocol reference. - /web/urls#special-documents-and-startup-modes -> #other-special-documents-and-startup-modes (heading is "## Other special documents and startup modes"), twice from the Control UI page. - /plugins/sdk-runtime#api-runtime-agent -> #runtime-namespaces "api.runtime.agent" is an title, not a heading, so it emits no anchor; the enclosing "## Runtime namespaces" heading is the real target. Sibling links on all three target pages already use heading-derived anchors (#coordinator-backed-crabbox, #route-table, #reusable-runtime-utilities), and this was the only link in docs/** aiming at an Accordion title out of 1342 such titles. Docs-only change; no runtime or config surface is touched. Co-Authored-By: Claude Opus 5 * docs: restore the sdk-entrypoints deep link Running the real Mintlify anchor audit (pnpm docs:check-links:anchors) showed that /plugins/sdk-runtime#api-runtime-agent already resolves: Mintlify does generate anchors from elements, so the original link was correct. The audit flags fragments it cannot resolve -- it reported both cloud-workers#desktop and urls#special-documents-and-startup-modes on main -- and it never reported this one. Retargeting it to #runtime-namespaces would have replaced a precise deep link with a coarser section link, so this restores the original. The remaining four link instances in this PR are confirmed broken by the same audit: main reports 313 broken links across 45 files, this branch reports 309 across 42, with no newly broken links. Co-Authored-By: Claude Opus 5 --------- Co-authored-by: Claude Opus 5 --- docs/concepts/experimental-features.md | 2 +- docs/gateway/protocol.md | 2 +- docs/web/control-ui.md | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/concepts/experimental-features.md b/docs/concepts/experimental-features.md index e1a6584bb541..87c2e9bf0435 100644 --- a/docs/concepts/experimental-features.md +++ b/docs/concepts/experimental-features.md @@ -21,7 +21,7 @@ Experimental features are preview surfaces behind explicit flags. They need more | Local model runtime | `agents.defaults.experimental.localModelLean`, `agents.entries.*.experimental.localModelLean` | A smaller or stricter local backend chokes on OpenClaw's full default tool surface | [Local Models](/gateway/local-models) | | Codex harness | `plugins.entries.codex.config.appServer.experimental.sandboxExecServer` | You want native Codex app-server 0.143.0 or newer to target an OpenClaw sandbox-backed exec-server instead of disabling Code Mode | [Codex harness reference](/plugins/codex-harness-reference#sandboxed-native-execution) | | Code Mode | `tools.codeMode.enabled` | You want compact code-orchestrated access to a hidden OpenClaw tool catalog | [Code Mode](/tools/code-mode) | -| Cloud workers | `cloudWorkers.desktop` | You want to watch or control desktop-capable cloud worker environments from the Control UI | [Cloud Worker Desktop](/gateway/cloud-workers#desktop) | +| Cloud workers | `cloudWorkers.desktop` | You want to watch or control desktop-capable cloud worker environments from the Control UI | [Cloud Worker Desktop](/gateway/cloud-workers#desktop-interactive) | | Swarm | `tools.swarm.enabled` | You want Code Mode scripts to orchestrate bounded groups of sub-agents in parallel | [Swarm](/tools/swarm) | ## Control UI Labs diff --git a/docs/gateway/protocol.md b/docs/gateway/protocol.md index dc321d537db3..09293f21ad7b 100644 --- a/docs/gateway/protocol.md +++ b/docs/gateway/protocol.md @@ -643,7 +643,7 @@ methods. Treat this as feature discovery, not a full enumeration of - `artifacts.list`, `artifacts.get`, and `artifacts.download` expose transcript-derived artifact summaries and downloads for an explicit `sessionKey`, `runId`, or `taskId` scope. Run and task queries resolve the owning session server-side and only return transcript media with matching provenance; unsafe or local URL sources return unsupported downloads instead of fetching server-side. - `environments.list` and `environments.status` (`operator.read`) remain available without cloud-worker profiles and preserve gateway-local and node environment discovery. Node environments include the durable `sessionHost` identity used to keep a known offline host visible, while current connected inventory is authoritative over that history. Missing identity means false. Exact bounded `{ total, available }` worker slots are live-only and omitted offline. Configured cloud workers and durable records left by earlier profiles add `worker` metadata with `providerId`, optional `leaseId`, `state`, `ageMs`, optional `idleMs`, and `attachedSessionIds`. Worker lifecycle states are `requested`, `provisioning`, `bootstrapping`, `ready`, `attached`, `idle`, `draining`, `destroying`, `destroyed`, `failed`, and `orphaned`. A connected node may also include `workerBundle: { status: "installed", version }` or `workerBundle: { status: "missing" }`. This optional observation is reconnect-scoped and reports validation of one Gateway-retained bundle; it is not launch authority. The public result never exposes the bundle hash, Gateway namespace, node filesystem path, receipt, or protocol-feature details. - `environments.create` (`{ profileId, idempotencyKey }`) provisions a worker from a configured plugin provider profile; retries with the same key reuse the durable operation. `environments.destroy` (`{ environmentId }`) requests idempotent teardown of a durable worker environment. Both require `operator.admin`, are control-plane writes, and return the same environment summary shape used by status responses. - - `worker.desktop.observe` (`{ environmentId, control? }`, `operator.admin`) starts or reuses the environment's desktop forward and returns `{ transport, wsPath, expiresAtMs, control, vncPassword? }`. `wsPath` carries a single-use 60-second token for the Gateway's desktop observer WebSocket; reconnecting requires a fresh observe call. Environments with an observable desktop advertise `worker.desktop: true` in `environments.list`. The method is advertised only when the `cloudWorkers.desktop` lab is enabled. See [Cloud workers](/gateway/cloud-workers#desktop). + - `worker.desktop.observe` (`{ environmentId, control? }`, `operator.admin`) starts or reuses the environment's desktop forward and returns `{ transport, wsPath, expiresAtMs, control, vncPassword? }`. `wsPath` carries a single-use 60-second token for the Gateway's desktop observer WebSocket; reconnecting requires a fresh observe call. Environments with an observable desktop advertise `worker.desktop: true` in `environments.list`. The method is advertised only when the `cloudWorkers.desktop` lab is enabled. See [Cloud workers](/gateway/cloud-workers#desktop-interactive). - `agent.identity.get` returns the effective assistant identity for an agent or session. - `agent.wait` waits for a run to finish and returns the terminal snapshot when available. diff --git a/docs/web/control-ui.md b/docs/web/control-ui.md index 6a621566503f..81a17672c579 100644 --- a/docs/web/control-ui.md +++ b/docs/web/control-ui.md @@ -304,7 +304,7 @@ select it to open the owning Approvals page. - Session grouping: a Group by control organizes the sessions table into sections by custom groups, channel, kind, agent, or date. Custom groups persist per session via `sessions.patch` (`category`), so sessions started from message channels (Discord, Telegram, WhatsApp, ...) can be categorized too; assign groups by dragging rows onto a section, or with the per-row group selector, and create groups with the New group action. - Memory (a tab on the Agents page, scoped to the selected agent): dreaming status, enable/disable toggle, and Dream Diary reader (`doctor.memory.status`, `doctor.memory.dreamDiary`, `config.patch`). When the `memory-wiki` plugin is enabled, the Diary view adds **Imported Insights** and **Memory Wiki** sub-tabs that browse imported source chats and the compiled wiki — clustered synthesis, entity, and concept pages plus annotated sources and reports, with claims, open questions, contradictions, and inline page previews (`wiki.importInsights`, `wiki.overview`, `wiki.get`). - Import Memory (`/memory-import`, reached from the Agents page's Memory tab): preview and copy local Claude Code auto-memory, Codex consolidated memory, or Hermes memory files into the selected agent workspace (`migrations.memory.plan`, `migrations.memory.apply`). - - Onboarding memory offer: when the Control UI opens in [onboarding mode](/web/urls#special-documents-and-startup-modes), a one-page dialog offers to import detected memories with the same plan/apply flow; skipping leaves the settings page as the later entry point. + - Onboarding memory offer: when the Control UI opens in [onboarding mode](/web/urls#other-special-documents-and-startup-modes), a one-page dialog offers to import detected memories with the same plan/apply flow; skipping leaves the settings page as the later entry point. @@ -766,7 +766,7 @@ UI clients during the compatibility window. ## Approval links -Operator approval notifications can deep-link to a [standalone approval document](/web/urls#special-documents-and-startup-modes). The URL is stable for the lifetime of the approval and safe to forward between your own devices: it identifies the approval, never authorizes it. +Operator approval notifications can deep-link to a [standalone approval document](/web/urls#other-special-documents-and-startup-modes). The URL is stable for the lifetime of the approval and safe to forward between your own devices: it identifies the approval, never authorizes it. - The approval namespace is reserved by the Gateway ahead of plugin HTTP routes for **all** HTTP methods, so a plugin route can never shadow or intercept an approval document. - Opening an approval document requires the same gateway auth as the rest of the Control UI (token/password, Tailscale Serve identity, or trusted-proxy identity); credentials are never part of the approval URL.