dsh-advisor

dsh-advisor

English | 中文

A standalone dsh (DeepSeek Harness) plugin bundle porting the omp "advisor" subsystem: a per-session independent reviewer model that observes the primary transcript, reviews each stepped turn with an explicitly configured model (provider + model are required), and injects severity-ranked advice (nit / concern / blocker) back into the session. After each completed turn it can also predict your likely next prompt and show it as a one-click suggestion tip below the web composer (web GUI only). Neither surface pollutes or recursively reviews itself.

Advisory only. The advisor never approves or rejects the primary agent's actions, and never issues commands as if it were the primary agent. Every delivered message is self-described advisory content, and a misbehaving reviewer is bounded end to end (emission guard, immuneTurns cooldown, failure policy) so it can never stall or pollute the primary loop.

Works in both dsh front ends: the web profile (sidebar → Plugins → dsh-advisor → Advisor card) and the dsh-tui terminal profile (/advisor + /advisor config). Quick start Install Web / Desktop (Plugins page)

In the dsh web client or the desktop app, open the sidebar Plugins page, use Add plugin, enter the package name dsh-advisor, press Install, then Enable now. dsh CLI

Same plugin, either front end — the only difference is the --profile flag. Pin a version with @ (e.g. dsh-advisor@0.1.0). A registry install fetches the published tarball, which ships the built artifacts (lib/ + cordis.patch.yml) — nothing builds on the target machine, and runtime dependencies (@deepseek-ai/cordis, @deepseek-ai/schemastery, @deepseek-ai/dsh-* peers) resolve through the dsh installation's flat profile module fallback — no extra install step. Registry / git / tarball / local-directory variants (local-dir from a built checkout: dsh plugin --profile web add . or dsh plugin --profile dsh-tui add .), web Settings exposure, uninstall, and --dump-config verification → docs/install.md. Configuration

Edit the config of the advisor row in your profile's patch layer (~/.dsh/profiles/ /cordis.patch.yml). All nine fields are schema-volatile live fields (dsh ≥ 0.1.7-rc.1): the web card and the TUI /settings screen write this same entry config — persisted in the profile patch, committed without a remount. (A pre-0.1.7 $DSH_HOME/settings.yaml advisor: section no longer exists: dsh imports it into the active profile once and renames the file .imported.) Breaking change (2026-09-26): the enabled config key was removed. The plugin-row enable/disable toggle in the host UI is the master switch — a running row is enabled, and there is nothing left to configure for it. A stored profile still carrying an enabled: line keeps working: the line is silently ignored (accepted, never read, never re-persisted — 2026-09-27 ruling, no manual deletion needed); the key is deprecated and the write paths no longer persist it.

provider and model are mandatory: either missing or empty is a hard gate — the advisor never starts a model call and reports a disabled-with-reason status; unknown config keys are rejected.

There is no model-side token budget (2026-10-18 user ruling): on OpenAI-compatible APIs max_tokens caps reasoning + content together, so with thinking models the old maxTokens budget intermittently starved the final content (empty reply → EMPTY_RESPONSE → silent delta drops). The advisor call sends no maxTokens at all; output is bounded at extraction by ADVISOR_NOTE_MAX_CHARS (768 chars) and latency by the 60 s call deadline. A maxTokens: line still present in a stored profile is tolerated and silently dropped, like the removed enabled key.

If the advisor is enabled and its runtime looks healthy but it never speaks, check /advisor status: a non-zero Dropped: line names the class — empty replies mean the model returned a completed response with no content, unparsed replies mean prose without a JSON frame is being dropped (enable pr