dsh-herdr-site
适用于 Herdr（终端工作区管理器）的 DeepSeek Harness 自定义集成：通过 `pane report-agent` 报告代理生命周期状态，使 Herdr 将 dsh/cc-tui 窗格作为一等代理进行跟踪。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:WuJiaoJue/dsh-herdr-site#d6a7db48f60724577e2eac5f0b0677e3600522bbHerdr Site 以 dsh-herdr-site 发布，当前版本为 0.1.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
点击下方 Badge 复制 Markdown，粘贴到 README 即可。
验证 package.json 声明的 GitHub 仓库，即可管理这个公开页面。认领后，Hub 会优先安排当前版本的安全扫描，并在通过后公开展示结果。
认领这个 Plugin →Reports dsh/cc-tui agent state to Herdr.
English | 简体中文
v0.1.0 · MIT · DSH profile plugin
Herdr is a terminal workspace manager for AI coding agents. It only recognizes
agents found by its built-in detectors (opencode, claude, codex, ...);
dsh/cc-tui is not on that list, so a dsh pane shows up in Herdr as a plain
terminal process — no state, no panel jump, no --wait support.
This plugin reports the dsh agent's state to Herdr over the official
custom-integration protocol (pane report-agent / pane release-agent):
working while a turn is runningidle when no driver is activeblocked when the model is parked on an ask_user_question, waiting for inputdsh itself only reports running/idle, so the blocked state is the main reason
to use this plugin: the moment the model waits on you shows up in Herdr instead
of looking like it's busy. It is derived from the session event stream
(ask_user_question tool/call / tool/result), keyed by callId, so
replayed or out-of-order events stay consistent.
With state reported this way, Herdr's panel jump and --wait also work for dsh
panes. An optional blockMessage can be attached to the blocked report to
show why the agent is waiting.
Lifecycle recording (captured with asciinema): the
pane shows working while a turn runs, flips to blocked when the model stops
on an ask_user_question, and recovers once the answer is given.
| dsh signal | Herdr state |
|---|---|
agent/status = running (turn in progress) | working |
agent/status = idle (no active driver) | idle |
ask_user_question pending (model waits for input) | blocked |
State reports go through Herdr's custom integration protocol:
"$HERDR_BIN_PATH" pane report-agent "$HERDR_PANE_ID" \
--source custom:dsh-herdr-site --agent cc-tui --state <working|idle|blocked> \
[--message …] [--seq N]
pane release-agent is called when the fiber is disposed, so no stale entries
remain. Reports carry a monotonic sequence number and repeated states are
deduplicated. Outside a Herdr pane the plugin is a no-op: nothing is spawned,
nothing is read.
pane report-agent / pane release-agent works.cc-tui and dsh-tui profiles — the plugin
only hooks the session event bus and is independent of the surface.Known edges:
dsh-tui profile does not ship the ask_user_question tool, so the
blocked state never fires there (working/idle reporting is
unaffected).cc-tui.Prerequisites: a working dsh
installation with the dsh-cc-tui/dsh-base profile. The plugin declares the
profile's packages (@deepseek-ai/cordis at ^4, dsh-session,
dsh-agent) as peer dependencies, supplied by the host profile.
dsh plugin --profile cc-tui add github:WuJiaoJue/dsh-herdr-site
The package ships a dsh.bundle.patch manifest, so the installer adds it to
the profile's bundle layer stack automatically, and cordis.patch.yml inserts
the plugin into every surface the profile boots. Repeat for any other profile
you use (e.g. dsh-tui).
Verify:
dsh --profile cc-tui --dump-config | grep -A2 herdr-site
Installing from a local checkout also works:
dsh plugin --profile cc-tui add /path/to/dsh-herdr-site
Optional blockMessage, sent with the blocked report:
# in the profile's cordis.patch.yml, or a --patch overlay
- id: herdr-site
config:
blockMessage: '模型等待你的回答'
npm install # dev: @types/node
npm run build # emits lib/
npm test # behavioral assertions against a stub herdr CLI
npx tsc --noEmit # type check
Git installs need no build step: lib/ is committed. pnpm blocks prepare
scripts by default, so relying on an install-time build would break installs
out of the box.
test/smoke.mjs runs the compiled plugin through the full lifecycle on a real
cordis context — working/blocked/idle transitions, dedup, seq ordering,
unrelated tool results, release-on-dispose — asserting every emitted CLI
invocation against a stub herdr binary.
Developing against a live profile with a plain file: dependency has two
gotchas (both encountered in practice):
A file: dep copies content at install time — re-run pnpm install in the
profile after every rebuild, or the profile keeps running the stale copy.
With the dependency installed as a bundle layer and a manual insert row,
bare-name activation was silently skipped; pointing the insert row's
name: at the absolute lib/index.js path is the reliable dev-only wiring:
- insert:
- id: herdr-site
name: '/absolute/path/to/dsh-herdr-site/lib/index.js'
config: {}
If you take this route, also remove the package from the profile's
dsh.profile.bundles list so the two inserts don't conflict.
Neither applies to the standard dsh plugin add flow described under Install,
which resolves the bundled patch's bare package name correctly.
--agent-session-id reference is not wired, so Herdr's
pane/agent APIs don't expose the linked dsh session id. Automatic session
restore would additionally require Herdr to know how to launch dsh, which is
out of scope here. State reporting works regardless.