I installed 7 plugins in DeepSeek Harness. Then I built a control hub for them.

DeepSeek Harness (dsh) went open source in August and blew past 130K stars in
weeks. Its architecture pitch is one line: everything is a plugin — a
deliberately thin core, capabilities arriving as .dsh.bundle plugins and
hot-loaded skills.

That means the ecosystem explodes fast. It also means that at plugin #7 you hit
every plugin platform's classic problem — except this time nobody solved it for
you.

The four pains nobody warns you about

Installing is easy: dsh plugin --profile desktop add <pkg> with HMR mounting
it live. The pain starts after:

1. Entries are scattered. Turn rewind lives in the Web UI, long-term memory is a hindsight_* tool plus a Python service on port 8888, the failure-experience library speaks MCP, skill cards sit under the input box. Even the agent isn't sure which tool is called what — let alone the user.
2. Status is uncertain. "Is this plugin usable right now?" A loaded plugin is not a running service. hindsight can load fine while port 8888 is down — and the call fake-succeeds.
3. Trust needs managing. Dozens of community plugins appeared within weeks. Installing an unknown SKILL.md means wiring a natural-language program into your agent. Did you scan what files it wants to read and what it runs?
4. Nobody keeps the manifest. What did you install last week, which version, why did you remove it? Two weeks later: gone.

The fix: a hub skill + three disciplines

I built the governance layer itself as a skill: dsh-plugin-hub (open source,
MIT).

One routing table. The SKILL.md is a table: user intent → which tool →
current state. The agent stops guessing from training data and starts looking
things up.

One status command. status.ps1 checks everything in one shot: profile
plugins, tool files on disk, services up/down, where the skill junctions point.
The skill has a hard rule baked in: confirm status before dispatching; if it's
down, say so — never pretend a call succeeded.

One junction trick. All my skills live in one directory (easy to back up and
sync), junctioned into %USERPROFILE%\.dsh\skills so DSH hot-loads them. New
skills never touch .dsh; git manages the unified directory.

One manifest (PROVENANCE). Every install/remove updates a table: version,
source, license, how it was verified. The routing table may only claim what this
file confirms. The table is not allowed to lie — that's the most important
rule of the whole design.

Bugs I hit so you don't have to

• Version compatibility: after 0.2.0 → 0.2.1-rc.2, turn-rewind 0.3.9 broke; 0.3.10 + one missing dependency fixed it. Check peer deps before upgrading the harness.
• Startup order: hindsight calls an external model API on boot — no egress, instant Application startup failed. Network first, service second.
• Some plugins you just don't install: safety-policy-bypass plugins and third-party account pools. Compliance and credential risk are both too high. The manifest records the refusal with the reason — refusals are knowledge too.
• Scan before install: Cisco's skill-scanner runs locally. No findings ≠ safe, but it catches the low-effort malicious stuff — then a human reads the scripts.
• Windows PowerShell 5.1 parses UTF-8 scripts as ANSI unless they have a BOM. My first "generic" config broke on any non-ASCII path because of this. One byte at the start of the file; hours of confusion saved.

The result

"Remember this" routes to hindsight. "Undo that edit" routes to turn-rewind.
"Can I install this skill?" goes through skill-scanner first. One table owns all
entries, one command owns all status, one manifest owns all trust.

Repo: Charles950311/dsh-plugin-hub (MIT), install.ps1 and you're in. Stars/PRs welcome.
I'm building a skills factory and security-audit pipeline on the same pattern —
follow if that's your kind of thing.

---