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

package/.claude-plugin/marketplace.json

@@ -1,17 +1,16 @@
-{
-  "name": "dsh-crew",
-  "owner": {
-    "name": "Ran-sh"
-  },
-  "metadata": {
-    "description": "DSH Crew plugin marketplace (configurable worker dispatch for Claude Code / Codex)"
-  },
-  "plugins": [
-    {
-      "name": "dsh-crew",
-      "version": "0.1.0",
-      "source": ".",
-      "description": "Dispatch subtasks to DeepSeek Harness (DSH) agents as native subagents with live progress"
-    }
-  ]
-}
+{
+  "name": "dsh-crew",
+  "owner": {
+    "name": "Ran-sh"
+  },
+  "metadata": {
+    "description": "DSH Crew plugin marketplace (configurable worker dispatch for Claude Code / Codex)"
+  },
+  "plugins": [
+    {
+      "name": "dsh-crew",
+      "source": ".",
+      "description": "Dispatch subtasks to DeepSeek Harness (DSH) agents as native subagents with live progress"
+    }
+  ]
+}

package/.claude-plugin/plugin.json

@@ -1,8 +1,14 @@
 {
   "name": "dsh-crew",
-  "version": "0.1.0",
+  "version": "1.2.0-rc.4",
   "description": "Dispatch subtasks to DeepSeek Harness (DSH) agents as native subagents with live progress",
   "author": {
     "name": "ZSeven-W"
+  },
+  "mcpServers": {
+    "dsh-crew": {
+      "command": "node",
+      "args": ["${CLAUDE_PLUGIN_ROOT}/src/server.mjs"]
+    }
   }
 }

package/README.md

@@ -1,25 +1,52 @@
 # DSH Crew
 
-An isolated Crew Harness for Codex Desktop, ZCode, and Claude Code. It
-provides Worker/Reviewer dispatch, model priorities, job tracking, and a
-capability-aware safety gate.
+A Crew orchestration plugin for the official DeepSeek Harness. It adds
+Worker/Reviewer dispatch, model priorities, job tracking, and a capability-aware
+safety gate for Codex Desktop, ZCode, and Claude Code.
 
 [简体中文](./README.zh.md)
 
 ## Quick start
 
-Requirements: Node.js and Git.
+Requirements: Windows, Node.js, and Git. Managed 3210 supervision is currently
+supported on Windows; Linux and macOS are not yet production runtime targets.
+The desktop frontend also requires the separately installed official CLI
+(`npm install -g @deepseek-ai/dsh@latest`, providing `dsh.cmd` on PATH).
 
 ```bash
 npm install -g @ran-sh/dsh-crew@latest
 dsh-crew install
-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 3080 console; its official bridge starts
-and owns the isolated 3210 Harness backend.
+DSH Crew is installed as a plugin in a dedicated official DeepSeek Harness
+profile named `dsh-crew`, served on 3210. That profile is the canonical Crew
+control and execution surface.
+
+The desktop launcher opens the official Harness on 3080 and starts Crew on 3210
+with no console window or automatic backend browser tab. Background/login startup
+starts only Crew. The official profile is not modified by the Crew installer;
+normal official application startup manages its own state.
+
+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
+```
+
+The daily page is <http://127.0.0.1:3080/>. The backend settings remain available
+at <http://127.0.0.1:3210/> when explicitly needed. Desktop launch mounts the
+simple Crew panel using a Crew-owned `--patch` overlay, without installing it
+into the official profile. Its button opens 3210; the backend button opens 3080.
+
+Install, update, and rollback also converge the Windows watcher automatically:
+the exact old watcher is handed off, and completion is reported only after the
+new 3210 Crew and DSH versions are verified. No 3080 restart is involved.
+
+```bash
+dsh-crew status
+dsh-crew inspect
+```
 
 Fresh installs contain only the built-in DeepSeek route. Add your own provider
 credentials, model priorities, and optional integrations in the local Settings;
@@ -27,8 +54,8 @@ they are never bundled into this package.
 
 | Surface | Purpose |
 | --- | --- |
-| `3080` | Daily console, Crew settings, integrations, and jobs |
-| `3210` | Isolated Crew Harness, Providers, Harness Models, and low-level settings |
+| `3080` | Daily official Harness `web` frontend; opened by the desktop launcher |
+| `3210` | Hidden Crew backend; explicit advanced configuration via its web page |
 
 In **Settings → DSH Crew**, refresh Harness Models and order the Worker and
 Reviewer model lists. Then ask a host agent:
@@ -66,10 +93,12 @@ 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.
-All production Worker/Reviewer model calls are executed by the isolated 3210
-Crew Harness; 3080 is a control-plane bridge only.
+The dedicated official Harness runtime state is isolated under
+`~/.config/dsh-crew/harness` with `profile: dsh-crew`; DSH Crew itself remains a
+plugin, not a fork or replacement of DeepSeek Harness. The official `web`
+profile is outside Crew ownership and read-only to Crew; in other words, the
+official `web` profile is never mutated. An old 3080 bridge, if present, is
+only reported as a deprecated diagnostic.
 
 ## Legacy launcher migration
 

package/README.zh.md

@@ -1,31 +1,55 @@
 # DSH Crew
 
-为 Codex Desktop、ZCode 和 Claude Code 提供隔离的 Crew Harness，支持
-Worker/Reviewer 调度、模型优先级、任务跟踪和能力感知安全门。
+DSH Crew 是附着在 DeepSeek 官方 Harness 上的 Crew 编排插件，为 Codex Desktop、
+ZCode 和 Claude Code 增加 Worker/Reviewer 调度、模型优先级、任务跟踪和能力感知安全门。
 
 [English](./README.md)
 
 ## 快速开始
 
-需要 Node.js 和 Git。
+需要 Windows、Node.js 和 Git。目前受管 3210 监督仅支持 Windows；Linux 和 macOS
+暂不属于生产运行平台。
+桌面前台还需要单独安装官方 CLI：`npm install -g @deepseek-ai/dsh@latest`，
+并确保 PATH 中能找到 `dsh.cmd`。
 
 ```bash
 npm install -g @ran-sh/dsh-crew@latest
 dsh-crew install
-dsh-crew integrate
-dsh-crew status
 ```
 
-打开 <http://127.0.0.1:3080> 进入日常控制台。Windows 安装会注册当前用户的
-登录启动项，先启动 3080 控制台，再由官方桥接启动并监管隔离的 3210 Harness。
+DSH Crew 安装在 DeepSeek 官方 Harness 的专用 `dsh-crew` profile 中，并由 3210
+提供服务。这个 profile 是 Crew 的 canonical control and execution surface。
+
+桌面启动器打开官方 3080，并在后台隐藏启动 Crew 3210，不自动打开后台网页。
+后台模式和登录启动项只启动 Crew。Crew 安装器不修改官方 profile；官方程序
+正常启动时自行管理它的运行状态。
+
+Windows 安装会注册登录启动项。如需立即启动并打开 Crew 控制台：
+
+```powershell
+& "$env:USERPROFILE\.config\dsh-crew\launchers\start-dsh-crew.cmd" --open
+```
+
+日常使用 <http://127.0.0.1:3080/>；需要后台高级配置时再访问
+<http://127.0.0.1:3210/>。桌面启动通过 Crew 自有目录中的 `--patch` 叠加配置
+挂载简易面板，不写入官方 profile。3080 的按钮打开 3210，3210 的按钮打开 3080。
+
+安装、更新和回滚也会自动收敛 Windows watcher：系统会精确交接旧 watcher，
+并且只有在新的 3210 Crew 与 DSH 版本验证通过后才报告完成；整个过程不涉及
+重启 3080。
+
+```bash
+dsh-crew status
+dsh-crew inspect
+```
 
 全新安装只包含内置 DeepSeek 路由。其他 Provider 凭据、模型优先级和可选集成需要
 在本机设置中自行配置，绝不会打包进发布版本。
 
 | 界面 | 用途 |
 | --- | --- |
-| `3080` | 日常控制台、Crew 设置、集成状态和任务 |
-| `3210` | 隔离的 Crew Harness、Provider、Harness Models 和底层设置 |
+| `3080` | 日常官方 Harness 前台，桌面启动时打开 |
+| `3210` | Crew 后台执行实例，默认隐藏，需要时进入高级配置 |
 
 进入 **设置 → DSH Crew**，刷新 Harness Models，并分别排列 Worker 与 Reviewer
 的模型顺序。然后直接告诉 Codex、ZCode 或 Claude：
@@ -61,9 +85,10 @@ dsh-crew update           # 更新并修复已启用集成
 dsh-crew uninstall        # 移除受管文件，保留配置/备份
 ```
 
-运行时隔离在 `~/.config/dsh-crew/harness`，使用 `profile: dsh-crew`；官方 `web` profile
-只接收 3080 轻量桥接。
-生产 Worker/Reviewer 的模型调用全部由隔离的 3210 Crew Harness 执行，3080 仅作为控制面桥接。
+专用的官方 Harness 运行时状态隔离在 `~/.config/dsh-crew/harness`，使用
+`profile: dsh-crew`；DSH Crew 本身仍然是插件，并非 DeepSeek Harness 的分支或替代品。
+官方 `web` profile 不属于 Crew 且对 Crew 始终只读；旧版 3080 bridge 若仍存在，
+只会作为已弃用诊断项显示。
 
 ## 旧启动器迁移
 

package/agents/ds-flash.md

@@ -4,23 +4,21 @@ description: DEPRECATED alias for ds-worker with a Flash model-class hint. DSH (
 model: haiku
 ---
 
-You are a thin dispatcher. You NEVER do the task yourself.
+Deprecated ds-flash alias; prefer ds-worker/ds-reviewer for new work.
+Thin dispatcher only: do not edit files or perform the delegated task locally.
 
-> Deprecation: this subagent is a compatibility alias. Use `ds-worker` for new
-> work — the backend now resolves the model from the Worker Model Policy, so
-> picking "Flash" here only sets the legacy model-class hint.
+1. Read dsh_worker_config if policy is unknown/changed; honor Auto, Manual and
+   disabled capabilities. Use role "worker", legacy_tier "flash".
+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. Take the task you were given and pass it VERBATIM (plus any file paths / context you were given) to the `dsh_run_worker` tool with:
-   - `role`: `"worker"`
-   - `legacy_tier`: `"flash"` (legacy model-class hint only)
-   - `effort`: omit it entirely (the session/global default applies) unless the task explicitly names an effort level
-   - `cwd`: the current project directory
-2. Wait for the tool to return.
-3. If `status` is `done`: output the worker's `result` verbatim, then one footer line: `[ds-flash (deprecated) | tokens in/out: <input>/<output> | tool calls: <toolCalls>]`.
-4. If `status` is not `done`: report the `error` and `stopReason` clearly, and include whatever partial `result` exists.
-
-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.
-- This alias maps to the worker role. The actual provider/model is decided by the backend.
-
-Do not edit files, run commands, or answer the task from your own knowledge. Your only job is dispatching to the DSH worker and relaying its result faithfully.
+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.

package/agents/ds-pro.md

@@ -4,29 +4,21 @@ description: DEPRECATED alias for ds-worker with a Pro (strong) model-class hint
 model: haiku
 ---
 
-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: this subagent is a compatibility alias. Prefer `ds-worker` for
-> implementation and `ds-reviewer` for independent review — the backend now
-> resolves models from the Model Policy, so picking "Pro" here only sets the
-> legacy strong model-class hint.
+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. Take the task you were given and decide the intended use: a review request
-   (verify / review / check an implementation, "review pipeline") 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 `dsh_run_worker`:
-   - `role`: `"reviewer"` for review requests, otherwise `"worker"`
-   - `legacy_tier`: `"pro"` (legacy model-class hint only)
-   - `effort`: omit it entirely unless the task names one
-   - `cwd`: the current project directory
-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. If `status` is not `done`: 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 the task from your own knowledge. Your only job is dispatching to the DSH worker / reviewer and relaying its result faithfully.
+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.

package/agents/ds-reviewer.md

@@ -4,20 +4,20 @@ description: DSH (DeepSeek Harness) reviewer role - independent review of a comp
 model: haiku
 ---
 
-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. Take the review request you were given and pass it VERBATIM (plus any file paths / context) to the `dsh_run_worker` tool with:
-   - `role`: `"reviewer"`
-   - `effort`: omit it entirely unless the request names one
-   - `cwd`: the current project directory
-2. Wait for the tool to return.
-3. If `status` is `done`: output the reviewer's `result` verbatim (which includes the ## Review Findings / ## Evidence / ## Risks / ## Verdict sections), then one footer line: `[ds-reviewer | tokens in/out: <input>/<output> | tool calls: <toolCalls>]`.
-4. If `status` is not `done`: 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.
-- The reviewer role is Auto when the review workflow is active, or Manual when it runs only on explicit request. The tool refuses disabled roles itself.
-- A reviewer verdict cannot override failing tests: if the report shows tests_status=FAIL, surface that prominently to the user.
-
-Do not edit files, run commands, or answer the review from your own knowledge. Your only job is dispatching to the DSH reviewer and relaying its verdict faithfully.
+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.

package/agents/ds-worker.md

@@ -1,23 +1,23 @@
 ---
 name: ds-worker
-description: DSH (DeepSeek Harness) worker role - executes implementation, fixes, tests, search and analysis. Delegates to dsh_run_worker and returns the worker's auditable result. The default coding role; do NOT pick models yourself.
+description: DSH Worker dispatcher for bounded implementation, fixes, tests and inspection; backend policy selects the model. Return compact evidence, never implement locally.
 model: haiku
 ---
 
-You are a thin dispatcher for the DSH worker role. You NEVER do the task yourself.
+Thin dispatcher only: do not edit files or perform the delegated task locally.
 
-1. Take the task you were given and pass it VERBATIM (plus any file paths / context you were given) to the `dsh_run_worker` tool with:
-   - `role`: `"worker"`
-   - `effort`: omit it entirely (the session/global default applies) unless the task explicitly names an effort level
-   - `cwd`: the current project directory
-   - For an explicitly read-only search or analysis task that must make zero file changes, pass `constraints: { allow_no_changes: true }`. Otherwise omit this 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. If `status` is not `done`: report the `error` and `stopReason` clearly, and include whatever partial `result` exists.
+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 (the orchestrator may delegate automatically) or Manual (only use it when the user explicitly asked for a worker or picked you, the ds-worker subagent). The tool refuses disabled roles itself.
-
-Do not edit files, run commands, or answer the task from your own knowledge. Your only job is dispatching to the DSH worker and relaying its result faithfully.
+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.

package/bin/dsh-crew.mjs

@@ -1,12 +1,16 @@
-#!/usr/bin/env node
-// dsh-crew CLI entry for the packaged npm payload.
-//
-//   npx @ran-sh/dsh-crew@latest install|status|update|uninstall
-//   npm exec --package=@ran-sh/dsh-crew@latest -- dsh-crew status
-//
-// The lifecycle implementation lives in src/install/npx-lifecycle.mjs so the
-// commands are testable in-process; this wrapper only dispatches.
-
-import { runNpxCli } from '../src/install/npx-lifecycle.mjs';
-
-process.exitCode = await runNpxCli();
+#!/usr/bin/env node
+// dsh-crew CLI entry for the packaged npm payload.
+//
+//   npx @ran-sh/dsh-crew@latest install|status|update|uninstall
+//   npm exec --package=@ran-sh/dsh-crew@latest -- dsh-crew status
+//
+// The lifecycle implementation lives in src/install/npx-lifecycle.mjs so the
+// commands are testable in-process; this wrapper only dispatches.
+
+import { runNpxCli } from '../src/install/npx-lifecycle.mjs';
+
+if (process.argv[2] === 'history' && process.argv[3] === 'recover') {
+  const { runProductionHistory } = await import('../src/history/runner.mjs');
+  try { await runProductionHistory({ recover: true }); console.log('History maintenance recovered.'); }
+  catch { console.error('HISTORY_RECOVERY_REQUIRED: recovery did not complete; data and maintenance evidence were retained.'); process.exitCode = 1; }
+} else process.exitCode = await runNpxCli();

package/codex/AGENTS.md

@@ -1,95 +1,47 @@
 # Global capability-aware delegation policy
 
-The main Codex agent owns the user's task from planning through final delivery.
-DSH Crew is an execution and review capability that Codex may use after
-discovering what the current environment actually supports.
+The main Codex agent owns the task through final delivery. DSH Crew is an optional
+execution/review capability, not an automatic replacement for the main agent.
 
-## Discover capabilities before delegation
+## Discover and choose
 
-- Before delegating substantial work, query DSH Crew's authoritative live
-  configuration, capability, and readiness surfaces.
-- Discover capabilities dynamically from the returned contracts. Do not rely
-  on a hard-coded list of roles, models, providers, tools, modes, or optional
-  features; newly added capabilities should be considered automatically.
-- For every relevant capability, respect its reported availability, activation
-  state, invocation mode, constraints, dependencies, and readiness evidence.
-- Treat installed, configured, enabled, and callable as different states. Use a
-  capability only when the complete live execution path is ready.
-- Keep the capability snapshot for the current plan, and refresh it after a
-  relevant configuration change or an availability, routing, credential,
-  compatibility, or activation failure.
-- If discovery is unavailable or evidence is incomplete, fail closed: do not
-  invent capabilities or repeatedly dispatch blind retries. If DSH Crew was
-  selected for the task, apply the operator decision gate below.
+Before substantial delegation, read the live Crew configuration, capability and
+readiness contracts. Discover roles, models, modes and constraints dynamically;
+installed, configured, enabled and callable are different states. Refresh the
+snapshot after relevant configuration or availability changes, not every small step.
 
-## Operator decision gate when DSH Crew is unavailable
-
-- Once Codex has selected DSH Crew for any work unit, any condition that makes
-  the required Crew capability unavailable or non-callable is a mandatory
-  pause point, regardless of cause.
-- At this pause point, do not continue implementation, silently fall back,
-  choose another execution path, or repair/reconfigure DSH Crew without new
-  operator direction. Perform only the read-only diagnosis needed to report
-  the blocker accurately.
-- Report the unavailable capability, bounded reason and evidence, and completed
-  work. Then wait for the operator to choose one direction:
-  1. Repair or restore DSH Crew, then continue through DSH Crew.
-  2. Do not repair DSH Crew; continue with the main Codex agent.
-- Resume only after the operator gives a new instruction. If repair is chosen,
-  verify live capability again before dispatch. If local execution is chosen,
-  state that the affected work is no longer independently delegated.
-- This gate applies only after DSH Crew has been selected or explicitly
-  requested. It does not force a pause when initial planning decides DSH Crew
-  provides no benefit and the task should remain with the main agent.
-
-## Decide what to delegate
-
-- Decompose the request into bounded work units before choosing an executor.
-- Match each unit against discovered capabilities. Use DSH Crew only where it
-  provides a clear execution, isolation, parallelism, specialization, or
-  independent-review benefit.
-- Delegate the smallest coherent unit that can be completed and verified
-  independently. Do not delegate an entire request merely because it is large.
-- Keep ambiguity, dependency ordering, cross-cutting decisions, conflict
-  resolution, external side effects, final integration, and user communication
-  in the main Codex agent.
-- Respect reported concurrency and isolation limits. Parallelize only
-  independent units with explicit, non-overlapping ownership.
-- Simple questions, explanations, small read-only inspections, and genuinely
-  trivial edits should normally remain in the main agent.
-- Explicit user instructions override default routing, but never safety or
-  capability boundaries.
-
-## Execute and verify
+Delegate bounded, independently verifiable units when isolation, specialization,
+parallel work or independent review provides a benefit. Give each unit its objective,
+owned files, workspace, constraints and acceptance evidence. Respect concurrency
+limits and manual/disabled capabilities. Keep ambiguity, integration, external
+effects and final communication in the main agent. Trivial work stays local.
 
-- Give each delegated unit a concrete objective, owned scope, workspace
-  context, constraints, and required validation evidence.
-- Prefer isolated execution for code changes when supported. Review work must
-  remain read-only.
-- Consume compact structured results and canonical events. Do not move
-  unbounded transcripts, raw provider payloads, credentials, or unnecessary
-  patch content between agents.
-- The main agent must validate results, tests, changed scope, unresolved risks,
-  and completion state before accepting delegated work.
-
-## Review policy
-
-- Use available independent review for non-trivial code changes when its live
-  invocation policy permits automatic use or the user requests manual use.
-- Never bypass a manual, disabled, unavailable, or restricted review boundary.
-- Treat requested changes, incomplete structured results, or missing direct
-  evidence as not approved.
-- If selected DSH Crew review cannot run, apply the operator decision gate. The
-  main agent may review locally only after the operator selects that path.
-
-## Authority and completion
+## Operator decision gate when DSH Crew is unavailable
 
-- Delegation does not broaden authority. Publishing, pushing, messaging,
-  credential changes, account actions, destructive operations, and other
-  external effects still require authority from the user's request.
-- Do not present delegated work as complete until validation passes, structured
-  results are complete, integration is checked, and permitted review
-  requirements are satisfied or transparently reported as unavailable.
+Once Crew is selected for a work unit, any required capability becoming unavailable
+or non-callable is a mandatory pause, regardless of cause. Do not implement further,
+repair/reconfigure Crew, silently fall back or switch execution paths. Perform only
+bounded read-only diagnosis, report the evidence and completed work, and wait for
+new operator direction: **repair Crew and continue through Crew**, or **do not repair
+Crew and continue with the main agent**. After repair, verify live readiness again;
+after local authorization, disclose that the affected work is not independently delegated.
+
+This gate does not apply when initial planning chooses local work without selecting
+Crew. A nonterminal wait is not an outage; continue the same workflow without duplicate
+dispatch. Review findings and failing code tests are task results to address, not by
+themselves evidence that Crew is unavailable.
+
+## Verify and finish
+
+Consume compact structured results and canonical events. Check changed scope,
+delivery completeness, tests, risks and the actual review verdict. Use independent
+review for non-trivial code when available and its invocation policy allows it;
+never bypass manual/disabled review. Requested changes or missing evidence are not
+approval. If selected review cannot run, use the operator gate above.
+
+Continue authorized work after a successful subtask; do not stop at its checkpoint.
+Delegation grants no new authority to push, publish, message, change credentials or
+delete data. Do not forward credentials, raw provider payloads or unbounded transcripts.
 
 ## Harness upgrade redlines
 

package/codex/agents/ds-flash.toml

@@ -1,5 +1,5 @@
 # Codex agent role: DEPRECATED alias for ds-worker (Flash model-class hint).
-# Install: copy this file to ~/.codex/agents/ (or <project>/.codex/agents/).
+# Install through dsh-crew; the installer resolves __DSH_CREW_ROOT__.
 # Prefer ds-worker; model selection is now handled by the Worker Model Policy.
 
 name = "ds-flash"
@@ -7,24 +7,28 @@ description = "DEPRECATED alias for ds-worker (DSH worker, Flash model-class hin
 model = "gpt-5.4-mini"
 
 developer_instructions = """
-You are a thin dispatcher. You NEVER do the task yourself.
+Deprecated ds-flash 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. Use ds-worker for new work; the backend resolves the model from the Worker Model Policy.
+1. Read dsh_worker_config if policy is unknown/changed; honor Auto, Manual and
+   disabled capabilities. Use role "worker", legacy_tier "flash".
+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. Pass the task VERBATIM (plus any file paths / context) to the `dsh_run_worker` tool with role "worker", legacy_tier "flash", cwd set to the current workspace, and NO effort argument unless the task names one.
-2. Wait for the tool to return.
-3. If status is "done": output the worker's result verbatim, then one footer line: [ds-flash (deprecated) | tokens in/out: <input>/<output> | tool calls: <toolCalls>].
-4. 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.
-- This alias maps to the worker role; the actual provider/model is decided by the backend.
-
-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