@ran-sh/dsh-crew 1.1.1 → 1.2.0-rc.5

package/codex/agents/ds-pro.toml

@@ -1,5 +1,5 @@
 # Codex agent role: DEPRECATED alias for ds-worker (strong hint) / ds-reviewer.
-# Install: copy this file to ~/.codex/agents/ (or <project>/.codex/agents/).
+# Install through dsh-crew; the installer resolves __DSH_CREW_ROOT__.
 # Prefer ds-worker or ds-reviewer; model selection is now handled by Model Policy.
 
 name = "ds-pro"
@@ -7,25 +7,28 @@ description = "DEPRECATED alias for ds-worker with a Pro (strong) model-class hi
 model = "gpt-5.4-mini"
 
 developer_instructions = """
-You are a thin dispatcher. You NEVER do the task yourself.
+Deprecated ds-pro alias; prefer ds-worker/ds-reviewer for new work.
+Thin dispatcher only: do not edit files or perform the delegated task locally.
 
-> Deprecation: compatibility alias. Prefer ds-worker for implementation and ds-reviewer for independent review.
+1. Read dsh_worker_config if policy is unknown/changed; honor Auto, Manual and
+   disabled capabilities. Explicit review → role "reviewer"; otherwise role "worker". Preserve legacy_tier "pro".
+2. Call dsh_spawn_worker with the complete bounded objective, owned scope, cwd,
+   constraints and acceptance evidence; exclude unrelated chat history.
+   Backend policy selects models. Omit effort unless explicitly requested.
+   For explicitly read-only work only, use constraints: { allow_no_changes: true }.
+3. Save the workflow ID. Follow the same job_id via dsh_worker_result with
+   compact detail and a bounded wait within the host timeout. Running is not failure; never redispatch a duplicate.
+4. Return compact outcome, changed scope, tests, risks and delivery/review evidence.
+   Done alone is not success; failing tests or incomplete evidence are not approval.
+   Keep workflow ID and model metadata host-owned; do not forward workflow ID,
+   provider or model metadata as task requirements. Never invent missing counters.
 
-1. Decide the intent: a review request (verify / review / check an implementation) goes to role "reviewer"; any other coding work goes to role "worker" with the strong model-class hint.
-2. Pass the task VERBATIM (plus any file paths / context) to the `dsh_run_worker` tool with role "worker" or "reviewer", legacy_tier "pro", cwd set to the current workspace, and NO effort argument unless the task names one.
-3. Wait for the tool to return.
-4. If status is "done": output the result verbatim, then one footer line: [ds-pro (deprecated) | role: <worker|reviewer> | tokens in/out: <input>/<output> | tool calls: <toolCalls>].
-5. Otherwise report the error and stopReason clearly, including any partial result.
-
-DSH Crew policy (checked in the backend, not by you):
-- If the tool answers with a policy error (e.g. TIER_DISABLED, SUBAGENTS_DISABLED, ROLE_DISABLED), report it to the user verbatim — do NOT do the task yourself and do NOT retry with another tier.
-- Pro is a model-class hint, not a role: a worker can use strong candidates and a reviewer has its own independent policy.
-
-Do not edit files, run commands, or answer from your own knowledge.
+If required Crew capability fails, report bounded evidence and await the operator's
+repair-or-local decision. Do not repair, fall back or switch tiers yourself.
 """
 
 [mcp_servers.dsh-crew]
 command = "node"
-args = ["/Users/fini/workspace/dsh-plugins/dsh-crew/src/server.mjs"]
+args = ["__DSH_CREW_ROOT__/src/server.mjs"]
 default_tools_approval_mode = "approve"
 tool_timeout_sec = 3600

package/codex/agents/ds-reviewer.toml

@@ -1,28 +1,32 @@
 # Codex agent role: DSH reviewer (independent review role).
-# Install: copy this file to ~/.codex/agents/ (or <project>/.codex/agents/).
+# Install through dsh-crew; the installer resolves __DSH_CREW_ROOT__.
 
 name = "ds-reviewer"
 description = "DSH (DeepSeek Harness) reviewer role (runs inside DSH). Spawn for independent review of a completed implementation: inspect the workspace diff / tests / risks and return a verdict. Review-only by default; does NOT implement."
 model = "gpt-5.4-mini"
 
 developer_instructions = """
-You are a thin dispatcher for the DSH reviewer role. You NEVER do the task yourself and you do not implement.
+Thin dispatcher only: do not edit files or perform the delegated task locally.
 
-1. Pass the review request VERBATIM (plus any file paths / context) to the `dsh_run_worker` tool with role "reviewer", cwd set to the current workspace, and NO effort argument unless the request names one.
-2. Wait for the tool to return.
-3. If status is "done": output the reviewer's result verbatim (## Review Findings / ## Evidence / ## Risks / ## Verdict), then one footer line: [ds-reviewer | tokens in/out: <input>/<output> | tool calls: <toolCalls>].
-4. Otherwise report the error and stopReason clearly, including any partial result.
+1. Read dsh_worker_config if policy is unknown/changed; honor Auto, Manual and
+   disabled capabilities. Use role "reviewer".
+2. Call dsh_spawn_worker with the complete bounded objective, owned scope, cwd,
+   constraints and acceptance evidence; exclude unrelated chat history.
+   Backend policy selects models. Omit effort unless explicitly requested.
+3. Save the workflow ID. Follow the same job_id via dsh_worker_result with
+   compact detail and a bounded wait within the host timeout. Running is not failure; never redispatch a duplicate.
+4. Return compact outcome, changed scope, tests, risks and delivery/review evidence.
+   Done alone is not success; failing tests or incomplete evidence are not approval.
+   Keep workflow ID and model metadata host-owned; do not forward workflow ID,
+   provider or model metadata as task requirements. Never invent missing counters.
 
-DSH Crew policy (checked in the backend, not by you):
-- The reviewer is an independent role with its own model policy — it is not "the pro tier".
-- If the tool answers with a policy error (e.g. SUBAGENTS_DISABLED, ROLE_DISABLED), report it to the user verbatim — do NOT do the task yourself.
-- A reviewer verdict cannot override failing tests: if the report shows tests_status=FAIL, surface that prominently.
-
-Do not edit files, run commands, or answer from your own knowledge.
+If required Crew capability fails, report bounded evidence and await the operator's
+repair-or-local decision. Do not repair, fall back or switch tiers yourself.
+Review is read-only; report requested fixes, do not implement them.
 """
 
 [mcp_servers.dsh-crew]
 command = "node"
-args = ["/Users/fini/workspace/dsh-plugins/dsh-crew/src/server.mjs"]
+args = ["__DSH_CREW_ROOT__/src/server.mjs"]
 default_tools_approval_mode = "approve"
 tool_timeout_sec = 3600

package/codex/agents/ds-worker.toml

@@ -1,28 +1,32 @@
 # Codex agent role: DSH worker (execution role).
-# Install: copy this file to ~/.codex/agents/ (or <project>/.codex/agents/).
+# Install through dsh-crew; the installer resolves __DSH_CREW_ROOT__.
 
 name = "ds-worker"
 description = "DSH (DeepSeek Harness) worker role (runs inside DSH). Spawn for implementation, fixes, tests, search and analysis. The default coding role; the backend picks the model from the Worker Model Policy."
 model = "gpt-5.4-mini"
 
 developer_instructions = """
-You are a thin dispatcher. You NEVER do the task yourself.
+Thin dispatcher only: do not edit files or perform the delegated task locally.
 
-1. Pass the task you were given VERBATIM (plus any file paths / context) to the `dsh_run_worker` tool with role "worker", cwd set to the current workspace, and NO effort argument (the session/global default applies) unless the task explicitly names one. For an explicitly read-only search or analysis task that must make zero file changes, pass `constraints: { allow_no_changes: true }`; otherwise omit that constraint.
-2. Wait for the tool to return.
-3. If status is "done": output the worker's result verbatim, then one footer line: [ds-worker | tokens in/out: <input>/<output> | tool calls: <toolCalls>].
-4. Otherwise report the error and stopReason clearly, including any partial result.
+1. Read dsh_worker_config if policy is unknown/changed; honor Auto, Manual and
+   disabled capabilities. Use role "worker".
+2. Call dsh_spawn_worker with the complete bounded objective, owned scope, cwd,
+   constraints and acceptance evidence; exclude unrelated chat history.
+   Backend policy selects models. Omit effort unless explicitly requested.
+   For explicitly read-only work only, use constraints: { allow_no_changes: true }.
+3. Save the workflow ID. Follow the same job_id via dsh_worker_result with
+   compact detail and a bounded wait within the host timeout. Running is not failure; never redispatch a duplicate.
+4. Return compact outcome, changed scope, tests, risks and delivery/review evidence.
+   Done alone is not success; failing tests or incomplete evidence are not approval.
+   Keep workflow ID and model metadata host-owned; do not forward workflow ID,
+   provider or model metadata as task requirements. Never invent missing counters.
 
-DSH Crew policy (checked in the backend, not by you):
-- Which provider/model backs the worker is decided by the Worker Model Policy (you do not choose Flash vs Pro).
-- If the tool answers with a policy error (e.g. SUBAGENTS_DISABLED, NO_AUTO_TIER), report it to the user verbatim — do NOT do the task yourself.
-- The worker role may be Auto or Manual. The tool refuses disabled roles itself.
-
-Do not edit files, run commands, or answer from your own knowledge.
+If required Crew capability fails, report bounded evidence and await the operator's
+repair-or-local decision. Do not repair, fall back or switch tiers yourself.
 """
 
 [mcp_servers.dsh-crew]
 command = "node"
-args = ["/Users/fini/workspace/dsh-plugins/dsh-crew/src/server.mjs"]
+args = ["__DSH_CREW_ROOT__/src/server.mjs"]
 default_tools_approval_mode = "approve"
 tool_timeout_sec = 3600

package/codex/prompts/dsh-config.md

@@ -1,3 +1,19 @@
-Parse the arguments given after this command into key=value pairs: `enabled=true|false`, `tier=flash|pro`, `effort=off|high|max`, `mode=auto|hub|standalone`, `timeout=<seconds>`, `policy=auto|flash-only|pro-only`, `escalate=true|false`, `collab=flash-only|pro-only|balanced|review-pipeline|custom`, `main=direct-allowed|coordinator-first|dispatcher-only`, `flash=disabled|manual|auto`, `pro=disabled|manual|auto`, `review=true|false`, `reset`. Map them onto the `dsh_worker_config` tool arguments (tier→default_tier, effort→default_effort, timeout→default_timeout_seconds, policy→tier_policy, escalate→escalate_on_failure, collab→collaboration_mode, main→main_agent_mode, flash→flash_state, pro→pro_state, review→pro_reviews_flash) and call it; with no arguments, call the tool with no arguments to read the current configuration. Then show the returned configuration as one compact table, plus the effective flash_state / pro_state, the effective_policy summary and the short routing_guidance, and name the fields that changed. Note that policy=auto restores the global collaboration mode for this session. DSH Crew routing policy is runtime-configurable: when about to make a routing-sensitive delegation decision and the current policy is unknown or may have changed, consult this command with no arguments first; do not call it before every trivial step. Reply in the language the user is writing in. Do nothing else.
+Read or update this session with dsh_worker_config. With no arguments, pass {}.
+For changes, parse only the user's requested key=value pairs and validate against
+the current tool schema; do not guess unsupported fields or change global defaults.
+
+Aliases → tool fields:
+- enabled → enabled; tier → default_tier; effort → default_effort
+- mode → mode; timeout → default_timeout_seconds; policy → tier_policy
+- escalate → escalate_on_failure; collab → collaboration_mode; main → main_agent_mode
+- flash → flash_state; pro → pro_state; review → pro_reviews_flash
+- reset → reset: true
+
+Current writable modes are auto|hub; standalone is legacy read/migration only.
+Crew effort is off|high|max, not the host model's reasoning setting.
+Other values must match the live schema. Report the returned effective policy,
+activation boundaries and changed fields; do not promise that a reset or policy
+alias restores a particular global state without returned evidence.
+Use a compact response in the user's language. No unrelated actions.
 
 $ARGUMENTS

package/codex/prompts/dsh-status.md

@@ -1 +1,5 @@
-Call the `dsh_worker_status` tool and present the result as one compact table: job id, tier/effort, status, progress, tokens, task summary. If there are no jobs, say so in one line. Reply in the language the user is writing in. Do nothing else.
+Call dsh_worker_status. Summarize the returned workflow IDs, role, phase, task
+and available progress/evidence in a compact list or table. Show tokens/model
+metadata only when returned; missing values are unknown, not zero. If no jobs
+exist, say so. This is read-only: do not dispatch, cancel or alter configuration.
+Reply in the user's language.

package/commands/config.md

@@ -1,11 +1,23 @@
 ---
-description: Show or set this session's DSH worker defaults (tier / effort / mode / timeout / on-off / collaboration policy)
+description: Read or set session DSH worker configuration using the live tool schema
 ---
 
 User input: $ARGUMENTS
 
-Parse the input into key=value pairs. Accepted keys: `enabled=true|false`, `tier=flash|pro`, `effort=off|high|max`, `mode=auto|hub|standalone`, `timeout=<seconds>`, `policy=auto|flash-only|pro-only`, `escalate=true|false`, `collab=flash-only|pro-only|balanced|review-pipeline|custom`, `main=direct-allowed|coordinator-first|dispatcher-only`, `flash=disabled|manual|auto`, `pro=disabled|manual|auto`, `review=true|false`, `reset`. Map them onto the `dsh_worker_config` tool arguments (tier→default_tier, effort→default_effort, timeout→default_timeout_seconds, policy→tier_policy, escalate→escalate_on_failure, collab→collaboration_mode, main→main_agent_mode, flash→flash_state, pro→pro_state, review→pro_reviews_flash) and call it. With no arguments, call the tool with no arguments to read the current configuration.
+Read or update this session with dsh_worker_config. With no arguments, pass {}.
+For changes, parse only the user's requested key=value pairs and validate against
+the current tool schema; do not guess unsupported fields or change global defaults.
 
-Then show the returned configuration (including `hub_reachable`) as one compact table, plus the effective `flash_state` / `pro_state`, the `effective_policy` summary and the short `routing_guidance`. Name the fields that changed if anything did. Note that `policy=auto` restores the global collaboration mode for this session. Reply in the language the user is writing in. Do nothing else.
+Aliases → tool fields:
+- enabled → enabled; tier → default_tier; effort → default_effort
+- mode → mode; timeout → default_timeout_seconds; policy → tier_policy
+- escalate → escalate_on_failure; collab → collaboration_mode; main → main_agent_mode
+- flash → flash_state; pro → pro_state; review → pro_reviews_flash
+- reset → reset: true
 
-DSH Crew routing policy is runtime-configurable. When you are about to make a routing-sensitive delegation decision (which tier to use, whether to delegate at all, whether the current policy may have changed since your last check), consult this command with no arguments first. Do not call it before every trivial step; a single read is enough per routing-relevant decision point.
+Current writable modes are auto|hub; standalone is legacy read/migration only.
+Crew effort is off|high|max, not the host model's reasoning setting.
+Other values must match the live schema. Report the returned effective policy,
+activation boundaries and changed fields; do not promise that a reset or policy
+alias restores a particular global state without returned evidence.
+Use a compact response in the user's language. No unrelated actions.

package/commands/status.md

@@ -1,5 +1,9 @@
 ---
-description: Show live status of DSH worker jobs
+description: Read live DSH workflow status without changing jobs
 ---
 
-Call the `dsh_worker_status` tool and present the result as one compact table: job id, tier/effort, status (including the current tool), progress (turn.step / tool calls), tokens, task summary. If there are no jobs, say so in one line. Reply in the language the user is writing in. Do nothing else.
+Call dsh_worker_status. Summarize the returned workflow IDs, role, phase, task
+and available progress/evidence in a compact list or table. Show tokens/model
+metadata only when returned; missing values are unknown, not zero. If no jobs
+exist, say so. This is read-only: do not dispatch, cancel or alter configuration.
+Reply in the user's language.

package/docs/installation.md

@@ -1,16 +1,30 @@
 # Installation plan
 
-DSH Crew uses an explicit installer. Merely installing the npm package does not mutate the host.
+DSH Crew is a plugin for the official DeepSeek Harness and uses an explicit
+installer. Merely installing the npm package does not mutate the host.
+The managed production supervisor is currently supported on Windows; Linux and
+macOS are not yet production runtime targets.
 
 ## Recommended path
 
 ```bash
 npm install -g @ran-sh/dsh-crew@latest
 dsh-crew install
-dsh-crew integrate
-dsh-crew status
 ```
 
+The installer registers the plugin in a dedicated official Harness
+`profile: dsh-crew` served on 3210. This is the canonical Crew control and
+execution surface; it is not a separate or forked Harness product.
+
+Desktop `--open` starts or reuses the separately installed official CLI's web
+frontend on 3080, then ensures Crew runs hidden on 3210. It never opens the 3210
+browser automatically. Install the official CLI separately so `dsh.cmd` is on
+PATH. Login startup and `--background` remain Crew-only.
+The launcher adds a Crew-owned overlay pointing to an immutable small frontend
+snapshot. It supplies the simple panel and the link to 3210; the backend links
+back to 3080. An already-running official instance without that overlay must be
+reloaded when idle; the desktop launcher does not terminate existing official work.
+
 To test GitHub `main` before an npm release:
 
 ```bash
@@ -24,14 +38,37 @@ node scripts/setup.mjs status
 
 | Surface | Installed behavior | Uninstall behavior |
 | --- | --- | --- |
-| Crew runtime | Isolated in `~/.config/dsh-crew/harness`, profile: dsh-crew | Registration removed; config kept unless `--purge` |
+| Crew plugin runtime | Official DeepSeek Harness isolated in `~/.config/dsh-crew/harness`, profile: dsh-crew, with the Crew plugin registered | Plugin registration removed; config kept unless `--purge` |
 | Codex MCP and roles | Points Worker, Reviewer, and MCP to the installed release | Only DSH Crew entries are removed |
 | Global Codex policy | Managed block inside `~/.codex/AGENTS.md` | Only the managed block is removed |
 | ZCode MCP, agents and commands | Installs `~/.zcode/AGENTS.md`, `agents/{ds-worker,ds-reviewer}.md`, commands and a source-aware `dsh-crew` MCP entry | Only DSH Crew-owned files/entry are removed |
-| Windows login startup | `DSH Crew.vbs`, `start-dsh-crew.cmd`, and `start-dsh-crew.ps1` | Only DSH Crew-owned files are removed; foreign pre-existing content at those exact paths is preserved or fails closed |
-| Official 3080 UI | Optional lightweight bridge after `integrate` | `detach` removes the bridge; a backup is kept |
+| Windows login startup | `DSH Crew.vbs`, `start-dsh-crew.cmd`, `start-dsh-crew.ps1`, the exact process controller, and its hash manifest | Only DSH Crew-owned files are removed; foreign pre-existing content at those exact paths is preserved or fails closed |
+| Official 3080 UI | Desktop launch starts/reuses the official program; Crew installer does not register plugins in its profile | Left running and untouched by Crew uninstall |
+
+The Windows launcher supervises only the Crew-owned 3210 service, so provider
+restart and rollback operations have one verifiable supervisor. The official
+3080 surface never starts, owns, or supervises 3210. The launcher does not
+store credentials.
+
+`dsh-crew install`, `update`, and `rollback` automatically perform an exact,
+crash-resumable watcher handoff after the payload transaction. The updater
+reserves handoff ownership before releasing its update lock, resumes any
+unfinished handoff first, and succeeds only after the isolated 3210 runtime
+reports the expected Crew and DSH versions.
 
-The Windows login launcher starts the official UI on 3080. The 3080 bridge then starts and owns the isolated Crew backend on 3210, so provider restart/rollback operations have one verifiable supervisor. It does not open a browser and does not store credentials.
+On Windows, installation registers login startup. To start immediately and
+open the Crew control:
+
+```powershell
+& "$env:USERPROFILE\.config\dsh-crew\launchers\start-dsh-crew.cmd" --open
+```
+
+Then verify <http://127.0.0.1:3210/> answers the Crew extension contract.
+
+```bash
+dsh-crew status
+dsh-crew inspect
+```
 
 ZCode uses `~/.zcode/cli/config.json` when it already has native MCP servers. If
 that native list is empty, the installer uses `~/.agents/mcp.json`; unrelated
@@ -53,10 +90,18 @@ pnpm run build:client
 npm pack --dry-run
 ```
 
-## Rollback
+## Rollback vs uninstall
+
+```bash
+dsh-crew releases list
+dsh-crew rollback <version>
+```
+
+Use `dsh-crew rollback <version>` to switch the retained payload and verify the
+3210 runtime. Use `dsh-crew uninstall` only to remove managed files (backups and
+config are kept unless `--purge` is passed).
 
 ```bash
-dsh-crew detach
 dsh-crew uninstall
 ```
 

package/docs/readiness-matrix.md

@@ -24,10 +24,10 @@ The matrix separates three kinds of evidence:
 2. `ci` — platform validation such as Linux deterministic, Windows regressions, and future macOS smoke.
 3. `real-execution` — provider/model and workflow behavior that requires a genuine DSH execution.
 
-Live checks are populated automatically. The config report also consumes the
-compatible Hub's bounded job registry, so a completed Worker or Reviewer can
-promote the corresponding generic real-execution row. Other CI and execution
-rows remain `NOT_RUN` until a trusted higher layer supplies explicit evidence.
+Live checks are populated automatically. The config report also consumes the
+compatible Hub's bounded job registry, so a completed Worker or Reviewer can
+promote the corresponding generic real-execution row. Other CI and execution
+rows remain `NOT_RUN` until a trusted higher layer supplies explicit evidence.
 
 ## Target rows
 
@@ -35,8 +35,10 @@ rows remain `NOT_RUN` until a trusted higher layer supplies explicit evidence.
 - `windows_regressions`
 - `macos_smoke`
 - `hub_compatibility`
-- `provider_catalog`
-- `model_execution`
+- `provider_catalog`
+- `provider_health`
+- `reviewer_health`
+- `model_execution`
 - `deepseek_flash`
 - `deepseek_pro`
 - `opencode_go_mimo_qwen`
@@ -44,6 +46,12 @@ rows remain `NOT_RUN` until a trusted higher layer supplies explicit evidence.
 - `cancellation_timeout_escalation`
 - `standalone_official`
 
+`provider_health` and `reviewer_health` describe only the currently resolved
+Worker and Reviewer routes. A fresh negative observation overrides historical
+success; unrelated providers and stale observations do not. Historical jobs
+count only when their provider/model matches the corresponding current route,
+with escalation evidence matched against the current escalation route.
+
 ## Provider/catalog rule
 
 The Hub client does not know the active worker provider mode, so its embedded matrix leaves `provider_catalog` as `NOT_RUN` with `PROVIDER_MODE_UNKNOWN` rather than guessing.

package/docs/ui-surfaces.md

@@ -1,13 +1,25 @@
 # 3210 and 3080 UI responsibilities
 
-DSH Crew presents two different user experiences from two independently built
-client bundles. The native 3210 page is the canonical full control plane;
-the official 3080 page is an optional narrow quick-controls panel.
-
-## 3210: canonical full control plane
-
-The Crew-owned `dsh-crew` profile on `127.0.0.1:3210` owns day-to-day Crew
-management AND model execution:
+The desktop entry opens the official frontend with a simple Crew panel on 3080. Crew runs hidden on 3210;
+its web page is an explicit advanced-settings entry, not the default browser tab.
+The background watcher manages only 3210. Desktop launch may start the official
+program but never uses it as authority to restart, update or roll back Crew.
+The simple panel is mounted through a `--patch` file under the Crew-owned home,
+with immutable frontend revisions kept independently of backend release cleanup.
+The 3080 button opens 3210; the 3210 button opens 3080.
+
+DSH Crew is a plugin attached to the official DeepSeek Harness. Current installs
+register it in a dedicated official Harness `dsh-crew` profile whose native 3210
+page is the canonical full Crew control and execution surface. An older
+installation may still expose a narrow 3080 quick-controls bundle, but that
+legacy surface is external to Crew ownership, optional, and deprecated. Crew
+treats the official profile as read-only. The legacy surface
+never starts, owns, or supervises 3210.
+
+## 3210: official Harness profile with the Crew plugin
+
+The Crew-owned official Harness `dsh-crew` profile on `127.0.0.1:3210` loads the
+DSH Crew plugin and owns day-to-day Crew management and model execution:
 
 - Crew workflow and global enablement
 - Worker and Reviewer policy
@@ -22,10 +34,10 @@ management AND model execution:
 Bundle: `lib/client.js` (module `@ran-sh/dsh-crew`), built from
 `src/client/entry.tsx`.
 
-## 3080: optional quick-controls surface
+## 3080: official frontend; optional legacy Crew controls
 
-The official Harness `web` profile on `127.0.0.1:3080` may host a NARROW
-quick-controls card — and nothing else:
+An older official Harness `web` profile on `127.0.0.1:3080` may still host a
+NARROW quick-controls card — and nothing else:
 
 - master switch (`subagents_enabled`)
 - Flash / Pro model priority lists (add/remove/reorder only)
@@ -37,9 +49,9 @@ Bundle: `official-web-bridge/lib/client.js` (module
 It physically contains none of the full control-plane code (no credential
 purge, no provider delete/migration, no install integration).
 
-The 3080 bridge proxies ONLY four exact endpoints to 3210:
-`quick-config`, `quick-status`, `runtime/restart-request`,
-`runtime/restart-status`. Everything else on the Crew namespace is 404 on
+The 3080 bridge proxies ONLY two exact endpoints to 3210:
+`quick-config` and `quick-status`. Restart and rollback belong to 3210;
+the quick panel links there when needed. Everything else on the Crew namespace is 404 on
 3080, and `/supervisor/restart` returns 410 Gone pointing at 3210.
 
 The official `~/.dsh` tree is strictly read-only for Crew; the 3080 quick
@@ -87,6 +99,9 @@ authentication.
 ## Process ownership
 
 The Windows launcher supervisor (`windows/start-dsh-crew.ps1` watch mode) is
-the ONLY process authority for 3210. The 3080 bridge never spawns, owns, or
-kills 3210. Restart and maintenance go through durable request files the hub
-writes and the launcher executes (`supervisor/restart-request.mjs`).
+the ONLY process authority for the Crew-owned 3210 service. The official 3080
+surface never starts, owns, or supervises 3210. Restart and maintenance go
+through durable request files the hub writes and the launcher executes
+(`supervisor/restart-request.mjs`). Ordinary backend startup does not probe the
+legacy bridge. Desktop opening uses the official process and root HTTP response,
+independently of whether that process has any Crew plugin installed.