dsh-meta-orchestrator

1. 安装并启动 DeepSeek Harness：npx @deepseek-ai/dsh web
2. 在终端执行上面的安装命令（CLI 会解析插件并核验来源）
3. 用 dsh plugins list 确认已安装，必要时重启 Harness 生效

插件以当前 dsh 进程的权限运行，安装时可能执行代码。请先通读仓库源码与许可证，确认无破坏性命令与越权访问；本站只做索引，不对第三方插件安全性作担保。

事实信息来自公开插件目录快照（2026-10-03），介绍文案由本站再加工。

以下为插件仓库 README 全文（原始内容，由公开目录抓取整理）。

[图片: dsh-meta-orchestrator — The model is the orchestrator]

[![CI](https://github.com/jiruidai/dsh-meta-orchestrator/actions/workflows/ci.yml/badge.svg)](https://github.com/jiruidai/dsh-meta-orchestrator/actions/workflows/ci.yml)
[![npm](https://img.shields.io/npm/v/dsh-meta-orchestrator.svg)](https://www.npmjs.com/package/dsh-meta-orchestrator)
[![Tests](https://img.shields.io/badge/tests-46%20passing-2ea44f.svg)](tests)
[![License: MIT](https://img.shields.io/badge/license-MIT-blue.svg)](LICENSE)
[![DeepSeek Harness](https://img.shields.io/badge/DSH-0.1.0--rc.6%20verified-0e7490.svg)](https://github.com/deepseek-ai/deepseek-harness)

A [DeepSeek Harness](https://github.com/deepseek-ai/deepseek-harness) plugin that teaches the agent to **synthesize a task-specific workflow at runtime** — instead of hard-coding pipelines or fixed agent topologies. For anyone running multi-step work in DSH who wants the plan the agent follows to be explicit, versioned, and durable rather than implicit.

---

## 🧭 How it works

Normally an agent just starts working on your request. With this plugin, it **plans first, then works the plan** — and the workflow is dynamic: written by the model itself, per request:

1. **Analyze** — the agent reads the request; if it is genuinely ambiguous, it asks before doing anything.
2. **Pick a pattern** — it chooses one of five proven ways to organize the work: ⛓️ steps in order (`prompt-chaining`), ⚡ fan out independent parts (`parallel-workers`), 🔀 classify, then dispatch (`router`), 🎯 delegate and review (`supervisor`), 🔁 draft → score → improve (`evaluation-loop`). Each pattern's detailed playbook is loaded only when picked.
3. **Write the plan down** — it calls `orchestrate` with the stages, the roles it will delegate, and verifiable success criteria. The plugin validates the structure and saves it durably. That is *all* the plugin ever does: it records plans, it never executes them.
4. **Do the work with DSH's own tools** — subagents, todos, workflow scripts, plan mode. The plugin adds no runtime of its own.
5. **Adapt or close** — if reality diverges, `adapt_workflow` revises the plan (every revision is versioned); when the work is done, `complete_workflow` records how each success criterion turned out.

Simple requests skip all of this — the agent is explicitly told not to orchestrate for orchestration's sake.

```mermaid
flowchart LR
    A["1 · Analyze"] --> P["2 · Pick a pattern"] --> W["3 · Write the plan
orchestrate"] --> E["4 · Do the work
DSH primitives"] --> M["watch progress"]
    M -- "reality diverged" --> AD["revise the plan
adapt_workflow"] --> E
    M -- "work finished" --> D["5 · close it out
complete_workflow"]
```

All of this behavior comes from one short instruction block the plugin adds to the agent's system prompt — no extra model calls, no background processes.

### What gets installed

| Added to your agent | What it is |
|---|---|
| An instruction block (~330 words) | Teaches the plan-first protocol above; sits in the system prompt of every session |
| Five pattern playbooks | Skills in the catalog; cost nothing until the model loads one |
| `orchestrate` / `adapt_workflow` / `complete_workflow` | The three recording tools: save the plan, revise it, close it |

## 🧩 Why it's built this way

- **The model is the planner** — no hard-coded pipeline and no fixed agent topology decides how your task runs; the model picks and composes per request, and may deviate when the task demands it.
- **Recording, not executing** — the plugin holds no runtime, no scheduler, no message bus. Execution stays on the harness's battle-tested primitives, so there is nothing extra to break.
- **Plans survive restarts** — every plan lives in DSH's storage domain as an append-only `create → adapt* → complete` chain, fenced per session lifecycle. No custom session event types, so orchestrated sessions always resume cleanly.
- **Built to track a fast-moving harness** — only stable public plugin surfaces are used; nothing is pinned to harness internals.

```mermaid
flowchart TB
    subgraph P["🧭 dsh-meta-orchestrator"]
        direction LR
        PS["policy section"]
        SK["5 pattern skills"]
        TL["orchestrate · adapt_workflow · complete_workflow"]
    end
    subgraph H["🐋 DeepSeek Harness"]
        direction LR
        SYS["system prompt"]
        CAT["skill catalog"]
        REG["tool registry"]
        DOM[("storage domain")]
    end
    PS --> SYS
    SK --> CAT
    TL --> REG
    TL --> DOM
    H --> EX["subagent · workflow · todo · goals · plan mode"]
```

How it compares to other DSH orchestration plugins

| | dsh-meta-orchestrator | workflow-capsule engines | agent-team plugins |
|---|---|---|---|
| Who plans | The model, per request, at runtime | A generated script in a bundled sandbox runtime | A fixed lead + specialists topology |
| Pattern choice | Selected and composed from five canonical patterns | Baked into capsule scripts | One topology for every task |
| Execution | Harness-native primitives only | Own QuickJS/WASM runtime + run store | Own mailbox/wake-up machinery |
| Re-planning | `adapt_workflow` re-plans the pattern itself, versioned | Pause/resume/rerun of the same script | Re-brief within the fixed topology |
| DSH coupling | Public plugin surface only | Pinned to a harness snapshot | Patches harness dependencies |

## ✅ Compatibility

| | |
|---|---|
| DSH packages | peer range `@deepseek-ai/*@^0.1.0-rc.5` — **verified against `0.1.0-rc.6`**, the current npm release |
| Mainline | [`47f9438`](https://github.com/deepseek-ai/deepseek-harness/commit/47f9438) (2026-08-13) |
| Last verified | **2026-08-14** — real npm install, 46/46 tests, live `web` profile session |
| Node | `^22.19.0 \|\| >=24.0.0` |
| Profile | needs the storage stack, shipped by the `@deepseek-ai/dsh-web-app` bundle (the standard `web` profile). The stock `headless` profile does **not** ship it — see [Troubleshooting](#-troubleshooting). |
| Platforms | Windows 11 (dev), Ubuntu (CI) |

Only public plugin surfaces are used — `systemPrompt`, `skills`, `tools`, `storageDomain`, `agent/pre-step` — so ordinary harness churn rarely bites. But the harness is pre-1.0, and a semver caret does not span prerelease lines: `^0.1.0-rc.5` matches `0.1.0-rc.6`, not a future `0.1.1-rc.1`. When a new rc line lands, the peer range here needs a bump — [open an issue](https://github.com/jiruidai/dsh-meta-orchestrator/issues) if you get there first.

## 📦 Install

Requires a profile with the storage stack — the standard web profile (`dsh-web-app` bundle) ships it (see [Compatibility](#-compatibility)).

```sh
dsh plugin --profile web add dsh-meta-orchestrator                           # from npm
dsh plugin --profile web add github:jiruidai/dsh-meta-orchestrator#v0.2.0    # from git, pinned
```

`dsh plugin` forwards to pnpm inside the profile directory, so every pnpm verb works. **Restart `dsh` after an `add` or `remove`** — the bundle layer list is read at boot; only the `cordis.patch.yml` layers hot-reload.

A git install builds via the package's `prepare` script, so pnpm asks you to allowlist it once in the profile's `pnpm-workspace.yaml` (`allowBuilds: { dsh-meta-orchestrator: true }`).

### Upgrade

```sh
dsh plugin --profile web update dsh-meta-orchestrator                        # within the installed range
dsh plugin --profile web add dsh-meta-orchestrator@latest                    # across ranges
dsh plugin --profile web add github:jiruidai/dsh-meta-orchestrator#v0.3.0    # git installs: re-add the new ref
```

### Disable without removing

The profile's own patch layer applies after every bundle layer and hot-reloads — this takes effect on the next request, no restart, no reinstall. In `$DSH_HOME/profiles/web/cordis.patch.yml` (`$DSH_HOME` defaults to `~/.dsh`):

```yaml
- id: meta-orchestrator
  disabled: true
```

Delete those two lines to switch it back on. Recorded workflows are untouched either way.

### Uninstall

```sh
dsh plugin --profile web remove dsh-meta-orchestrator   # drops the dependency and the bundle layer
```

Restart `dsh`. For a *complete* removal, the leftovers the CLI does not touch:

| Leftover | What to do |
|---|---|
| `$DSH_HOME/storages/meta_orchestrator.json` | Every workflow the plugin recorded. Delete the file to erase them — nothing else reads it. |
| `allowBuilds` entry in `$DSH_HOME/profiles/web/pnpm-workspace.yaml` | Remove it if you added one for a git install. |
| `meta-orchestrator` row in `$DSH_HOME/profiles/web/cordis.patch.yml` | Remove it if you used the dev-install route below. |
| Past sessions' `session.jsonl` | Sessions keep the `orchestrate` calls that already happened — ordinary session history, not the plugin's to rewrite. |

Dev install (local checkout)

Build with `pnpm build`, then add an absolute-path row to `$DSH_HOME/profiles//cordis.patch.yml`:

```yaml
- insert:
    - id: meta-orchestrator
      name: file:////lib/index.js
      config:
        autoTrigger: false
```

The web profile hot-reloads its patch layer — the plugin is live on the next request, no restart.

## 🚀 Quick start

No configuration needed — the defaults are the intended setup. Install into the `web` profile, restart `dsh`, and hand the agent something genuinely multi-part:

> Audit this repo's error handling, then write a short report with concrete fixes ranked by risk.

What you should see, in order:

1. The agent names its pattern in a sentence — *"this is a chain: audit → rank → write."*
2. A `skill` call loading that pattern's playbook.
3. An `orchestrate` call whose result reads back:

   ```text
   workflow "wf-3f2a91c4" recorded (v1)
   pattern: prompt-chaining
   stages: 4
   success criteria: 3
   Execute it with the harness's native primitives and report the final result against the success criteria.
   ```

4. Then ordinary DSH work — todos, subagents, tools. **The plugin runs none of it**: it recorded the plan and got out of the way.
5. At the end, a `complete_workflow` call — `workflow "wf-3f2a91c4" completed (achieved, v1)`.

Proof it was persisted, not just narrated (the file appears with the first recorded workflow):

```sh
cat $DSH_HOME/storages/meta_orchestrator.json   # $DSH_HOME defaults to ~/.dsh
```

One entry per session id, holding the append-only `create → adapt* → complete` chain with a full spec snapshot at every step.

Ask something simple instead — *"what's in this folder?"* — and the agent skips `orchestrate` entirely. That is the protocol working, not failing.

## ⚙️ Configuration

One key, no environment variables, nothing sensitive:

| Key | Default | Meaning |
|---|---|---|
| `autoTrigger` | `false` | Append a one-time protocol reminder inside the **first** request of a session (delivered by composing the `agent/pre-step` decision). Off by default: the policy section alone drives the protocol at zero extra token cost. |

## 🔐 Permissions & data

| | |
|---|---|
| Network | none — no requests, no extra model calls |
| Filesystem | none directly — one Node builtin, `crypto.randomUUID` |
| Credentials / env vars | none read, none stored |
| Subprocesses | none |
| Durable storage | DSH storage domain `meta_orchestrator`, table `workflows`, keyed by session id — `$DSH_HOME/storages/meta_orchestrator.json` on the stock JSON backend |

Worth knowing what lands in that file: every mutation stores a **full spec snapshot** — the model's written analysis of your request, stage names and details, the briefs it would hand to subagents, success criteria, and the completion report. That is a paraphrase of your task, in plaintext, per session, on your machine. It never leaves the machine, and deleting the file is the entire erase story.

Scope note: this is a **host-plane** plugin. The ~330-word policy section and the three tools register globally, so every session in the profile carries them — that is the design (see [What gets installed](#what-gets-installed)), not a leak. With `autoTrigger: true`, one reminder message is appended to the first request of each session, once.

## 🩺 Troubleshooting

**Boot fails: `meta-orchestrator: pending (waiting for services: storageDomain)`**
The profile has no storage stack. Only the `dsh-web-app` bundle ships `storage` / `storage-json` / `storage-domain`; the stock `headless` profile does not. Install into the `web` profile — or insert those three rows into your profile's patch layer above this plugin.

**No `orchestrate` tool — the plugin seems absent**
Check whether the row actually composed: `dsh --profile web --dump-config` and look for the `dsh-meta-orchestrator` layer. Missing → the package isn't installed (re-run `dsh plugin … add`, then **restart `dsh`**). Present but `disabled: true` → a patch layer turned it off.

**First `add` from git fails on a blocked build script**
pnpm ≥ 10 refuses a git dependency's `prepare` script until allowlisted. Copy the exact key pnpm prints into `$DSH_HOME/profiles/web/pnpm-workspace.yaml` under `allowBuilds:` and re-run. That allowance means running package code at install time — pin a tag or sha.

**The model answers without orchestrating**
Intended for simple requests. If you want a nudge at the start of every session, set `autoTrigger: true`.

**`orchestrate rejected the spec: …`**
A structurally invalid spec (no stages, no success criteria, unknown pattern). The error lists every problem and the model normally fixes it on the next call. Nothing is persisted from a rejected call.

**`… could not record the spec (storage write failed)`**
The backend rejected the write — check that `$DSH_HOME/storages/` is writable. A failed write leaves the recorded chain exactly as it was; it never half-records.

**Where to look**

| | |
|---|---|
| Boot and plugin errors | stderr of the `dsh` process |
| What actually happened | `$DSH_HOME/sessions///session.jsonl` — tool calls and results are ordinary session events |
| The durable record | `$DSH_HOME/storages/meta_orchestrator.json` |

**Rollback**, fastest first: `disabled: true` in the profile patch layer (live on the next request), or `dsh plugin --profile web remove dsh-meta-orchestrator` plus a restart. Neither deletes recorded workflows.

## 🛠️ Development

```sh
pnpm install      # normal checkout: installs the published @deepseek-ai/* packages
pnpm build        # clean + tsc → lib/
pnpm typecheck    # src + tests
pnpm test         # vitest — 46 unit + mount-integration tests
```

Issues and PRs are welcome — `pnpm typecheck && pnpm test` must be green. CI runs install → build → typecheck → test on Node 22 and 24, `--frozen-lockfile` against the committed `pnpm-lock.yaml` (generated against `registry.npmjs.org`).

The maintainer's local checkout instead resolves `@deepseek-ai/*` from a sibling harness checkout through a hand-built junction tree (see the comments in `pnpm-workspace.yaml`) — in that setup `pnpm install` is never run.

Token & KV-cache behavior

- Fixed cost per request: the policy section + three tool schemas; pattern bodies only when loaded via `skill`.
- The prefix stays cache-stable while section, tools, and skill catalog are unchanged; enabling the plugin mid-session invalidates reuse from the first changed catalog token.
- Tool results are small structured summaries (id, version, pattern, counts).

## 🚧 Limitations

- Prompt discipline is the primary enforcement — a model may skip `orchestrate` entirely.
- Specs are per session lifecycle by design; a reused session id never inherits a stale workflow.
- No client UI yet — workflow state is visible in conversation, tool results, and the storage domain.

## 📄 License & security

[MIT](LICENSE).

**Reporting a vulnerability** — please don't open a public issue. Use GitHub's [private vulnerability reporting](https://github.com/jiruidai/dsh-meta-orchestrator/security/advisories/new) for this repo; see [SECURITY.md](SECURITY.md). Surface-wise there is little to hold: the plugin executes nothing, opens no sockets, and reads no credentials — the realistic concerns are the policy text it injects and the task paraphrases it stores locally (see [Permissions & data](#-permissions--data)).