@ran-sh/dsh-crew 0.5.5 → 0.5.7

package/README.md

@@ -17,8 +17,9 @@ dsh-crew integrate
 dsh-crew status
 ```
 
-Open <http://127.0.0.1:3080> for the daily console. On Windows, installation
-also registers login startup for the two local services.
+Open <http://127.0.0.1:3080> for the daily console. On Windows, installation
+also registers login startup for the 3080 console; its official bridge starts
+and owns the isolated 3210 Harness backend.
 
 | Surface | Purpose |
 | --- | --- |
@@ -41,14 +42,20 @@ silently falling back.
 ## Useful commands
 
 ```bash
-dsh-crew inspect          # live capabilities and readiness
-dsh-crew jobs list        # jobs and Result Contracts
-dsh-crew update           # update and repair enabled integrations
+dsh-crew inspect          # live capabilities and readiness
+dsh-crew jobs list        # jobs and Result Contracts
+dsh-crew providers list   # 3210 Harness provider inventory (secret-free)
+dsh-crew providers probe <provider-id>
+dsh-crew providers delete-plan <provider-id> --replacement-default <provider-id>
+dsh-crew providers delete <provider-id> --plan <plan-id> --expected-revision <sha256> --confirm
+dsh-crew update           # update and repair enabled integrations
 dsh-crew uninstall        # remove managed files, keep backups/config
 ```
 
-The runtime is isolated under `~/.config/dsh-crew/harness` with `profile: dsh-crew`;
-the official `web` profile receives only the 3080 bridge.
+The runtime is isolated under `~/.config/dsh-crew/harness` with `profile: dsh-crew`;
+the official `web` profile receives only the 3080 bridge.
+All production Worker/Reviewer model calls are executed by the isolated 3210
+Crew Harness; 3080 is a control-plane bridge only.
 
 ## Legacy launcher migration
 

package/README.zh.md

@@ -16,8 +16,8 @@ dsh-crew integrate
 dsh-crew status
 ```
 
-打开 <http://127.0.0.1:3080> 进入日常控制台。Windows 安装会注册当前用户的
-登录启动项，自动启动两个本地服务。
+打开 <http://127.0.0.1:3080> 进入日常控制台。Windows 安装会注册当前用户的
+登录启动项，先启动 3080 控制台，再由官方桥接启动并监管隔离的 3210 Harness。
 
 | 界面 | 用途 |
 | --- | --- |
@@ -38,14 +38,19 @@ dsh-crew status
 ## 常用命令
 
 ```bash
-dsh-crew inspect          # 实时能力与就绪度
-dsh-crew jobs list        # 任务与 Result Contract
-dsh-crew update           # 更新并修复已启用集成
+dsh-crew inspect          # 实时能力与就绪度
+dsh-crew jobs list        # 任务与 Result Contract
+dsh-crew providers list   # 3210 Harness Provider 清单（不含密钥）
+dsh-crew providers probe <provider-id>
+dsh-crew providers delete-plan <provider-id> --replacement-default <provider-id>
+dsh-crew providers delete <provider-id> --plan <plan-id> --expected-revision <sha256> --confirm
+dsh-crew update           # 更新并修复已启用集成
 dsh-crew uninstall        # 移除受管文件，保留配置/备份
 ```
 
-运行时隔离在 `~/.config/dsh-crew/harness`，使用 `profile: dsh-crew`；官方 `web` profile
-只接收 3080 轻量桥接。
+运行时隔离在 `~/.config/dsh-crew/harness`，使用 `profile: dsh-crew`；官方 `web` profile
+只接收 3080 轻量桥接。
+生产 Worker/Reviewer 的模型调用全部由隔离的 3210 Crew Harness 执行，3080 仅作为控制面桥接。
 
 ## 旧启动器迁移
 

package/docs/installation.md

@@ -31,7 +31,7 @@ node scripts/setup.mjs status
 | 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 |
 
-The Windows login launcher starts the official UI on 3080 and the isolated Crew backend on 3210. It does not open a browser and does not store credentials.
+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.
 
 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

package/docs/ui-surfaces.md

@@ -1,46 +1,65 @@
-# 3080 and 3210 UI responsibilities
-
-DSH Crew deliberately presents two different user experiences from one shared
-client build.
-
-## 3080: daily Crew control plane
-
-The official Harness `web` profile on `127.0.0.1:3080` owns day-to-day Crew
-management:
-
-- Crew workflow and global enablement
-- Worker and Reviewer policy
-- model priority, fallback, review, and adaptive routing
-- runtime and activation-boundary information
-- Codex, Claude, and ZCode installation actions and structured readiness
-- task status and bounded model-invocation summaries
-- the link to the underlying 3210 Crew Harness
-
-The lightweight official-web bridge keeps these requests same-origin and
-proxies only the `/_dsh/dsh-crew/*` contract to the isolated backend.
-
-## 3210: isolated native Harness
-
-The Crew-owned `dsh-crew` profile on `127.0.0.1:3210` owns model execution and
-low-level Harness configuration. Its native Harness menus remain the place for
-Providers, Harness Models, Agent presets, and native runtime settings.
-
-The DSH Crew settings entry on this surface is intentionally diagnostics-only:
-it shows bounded runtime identity and a link back to 3080. It does not duplicate
-Worker/Reviewer policy, host integrations, tasks, or orchestration controls.
-
-## Surface detection and failure behavior
-
-The client does not infer responsibility from a hard-coded browser port. It
-uses two same-origin, structured signals:
-
-1. `/_dsh/dsh-crew/bridge-status` identifies the official bridge control plane.
-2. `/_dsh/dsh-crew/runtime` identifies the native Crew-owned runtime.
-
-The bridge signal wins on 3080 because the proxied runtime response correctly
-describes the 3210 backend. If neither contract can be verified, the client
-fails closed to the minimal diagnostics view. Missing evidence never enables
-the full control plane and never becomes `READY`.
-
-The split changes presentation only. Crew state, credentials, routing policy,
-and model execution remain isolated under the Crew-owned home and profile.
+# 3080 and 3210 UI responsibilities
+
+DSH Crew deliberately presents two different user experiences from one shared
+client build.
+
+## 3080: daily Crew control plane
+
+The official Harness `web` profile on `127.0.0.1:3080` owns day-to-day Crew
+management:
+
+- Crew workflow and global enablement
+- Worker and Reviewer policy
+- model priority, fallback, review, and adaptive routing
+- runtime and activation-boundary information
+- Codex, Claude, and ZCode installation actions and structured readiness
+- task status and bounded model-invocation summaries
+- the link to the underlying 3210 Crew Harness
+
+The lightweight official-web bridge keeps these requests same-origin and
+proxies only the `/_dsh/dsh-crew/*` contract to the isolated backend.
+
+## 3210: isolated native Harness
+
+The Crew-owned `dsh-crew` profile on `127.0.0.1:3210` owns model execution and
+low-level Harness configuration. Its native Harness menus remain the place for
+Providers, Harness Models, Agent presets, and native runtime settings.
+
+The DSH Crew settings entry on this surface is intentionally diagnostics-only:
+it shows bounded runtime identity and a link back to 3080. It does not duplicate
+Worker/Reviewer policy, host integrations, tasks, or orchestration controls.
+
+## Surface detection and failure behavior
+
+The client does not infer responsibility from a hard-coded browser port. It
+uses two same-origin, structured signals:
+
+1. `/_dsh/dsh-crew/bridge-status` identifies the official bridge control plane.
+2. `/_dsh/dsh-crew/runtime` identifies the native Crew-owned runtime.
+
+The bridge signal wins on 3080 because the proxied runtime response correctly
+describes the 3210 backend. If neither contract can be verified, the client
+fails closed to the minimal diagnostics view. Missing evidence never enables
+the full control plane and never becomes `READY`.
+
+The split changes presentation only. Crew state, credentials, routing policy,
+and model execution remain isolated under the Crew-owned home and profile.
+
+## Local trust model
+
+Both surfaces listen on loopback only and share one request guard
+(`src/local-request-guard.mjs`). A request is trusted when it proves, in
+order: (1) the TCP peer is a loopback address, (2) the `Host` header names a
+loopback host, (3) browser fetch-metadata (`Sec-Fetch-Site`) is `same-origin`
+or absent/`none`, and (4) when an `Origin` header is present it names a
+loopback host — on the 3080 bridge the `Origin` authority must additionally
+equal the request authority, while the 3210 hub accepts any loopback origin
+because the 3080 panel calls it cross-port.
+
+There is deliberately no bearer token: every process running as the local
+user is inside the trust boundary and may control Crew. The guards keep
+off-machine browsers, DNS-rebinding pages, and cross-machine proxies out;
+they do not authenticate local users. If a deployment ever needs to separate
+local principals, add a per-install random token to state-changing calls and
+inject it server-side in the bridge — do not use browser `Origin` as
+authentication.