DEV Community: Moby

From string-concatenation to a real DSH bundle: one link, six verified plugins

Moby — Sun, 30 Aug 2026 06:53:46 +0000

Every plugin store ends up doing the same thing eventually: bundling. "Install these six together." The naive implementation is a shell-command chain — six dsh plugin add calls joined by &&. I shipped exactly that. Then someone pointed out it was not a bundle at all; it was a very long string. And the string had a bug in it: the URLs contained a double slash, so every single one of the six installs 404'd. The "one-click bundle" was, in fact, a one-click failure.

The lesson was old: if you ship a command, test the command. But the deeper lesson was newer: read the platform's own docs before designing your own format.

What DSH actually calls a bundle

DeepSeek Harness (DSH) has a precise vocabulary:

A plugin bundle is an npm package that declares dsh.bundle with a cordis.patch.yml layer. The patch rows reference packages by name, resolved through the profile's node_modules.
A profile is a directory at $DSH_HOME/profiles/<name> whose manifest (dsh.profile) lists an ordered set of bundles plus dependencies. The profile is the composition; the bundles are the parts.

So "six plugins in one link" has a native answer: ship a profile. One tarball, one profiles/consensus directory, one profile manifest that lists the six member bundles. The user unpacks it, runs dsh plugin --profile consensus install, and starts dsh --profile consensus. Six plugins, one link — no shell string concatenation in sight.

Three real obstacles we hit building it

blockExoticSubdeps. The first design was an aggregation package whose dependencies pointed at our own hosted tarballs. pnpm refused: URL dependencies are not allowed in *sub*dependencies. Moving the URLs to the profile's own dependencies folder worked — a profile's direct dependencies are top-level, and exotic (URL) dependencies are legal there. This is the difference between "bundle that depends on URLs" (blocked) and "profile that lists URL deps" (fine).
Member health audit. One of the six members had a peer-dependency range (@deepseek-ai/dsh-workflow@^0.0.1) with no matching published version. The install failed with a confusing pnpm error. The fix wasn't technical — it was selection: audit every member's dependency/peer declarations before assembling, and swap members whose upstream deps are broken. Now "member health" is a mandatory step in our bundle assembler: we check not just "is this plugin verified?" but "can its declared dependencies actually resolve?"
The reviewer rule had to grow up. Our own submission reviewer rejected the aggregated bundle: "patch loads foreign package." That rule was written to stop undeclared cross-package references — a real security boundary. But DSH's official aggregate bundles legally reference declared dependencies. So the rule evolved: a patch may load its own name or any package declared in dependencies. Undeclared foreign loads are still blocked. The security boundary survived; the false positive didn't.

Proof, not promises

The acceptance test: inside a Docker sandbox, unpack the profile, run install, dump the resolved composition. Output: six plugin rows — genui, agent-teams, dsh-context, telemetry-redactor, memento, dsh-annotation — all loaded, all from one link. The profile tarball is 417 bytes; the real work was reading the docs and auditing dependencies.

The meta-lesson

Shipping features fast is easy. Shipping the right shape is harder, and the shape comes from the platform's own vocabulary, not from what looks convenient in a template string. When you can, read the docs; when you can't, test until the platform tells you the truth. blockExoticSubdeps and the "no matching version" failure were the docs we didn't read first, delivered as error messages. The next store that ships a bundle should ask: what is the platform's native notion of a set? The answer was already there.

We tested 20 community-recommended DSH plugins — 7 made our shelf. Here's why we rejected the rest.

Moby — Fri, 28 Aug 2026 16:59:26 +0000

Every "awesome" list makes the same promise: a curated shelf of plugins you can install without reading the source. In August we decided to test that promise against our own pipeline. On a single day — 2026-08-28 — we ran twenty community-recommended DSH plugins through the same verification ring we apply to every submission on whaleharness.com. Seven earned a spot on our shelf. Of the other thirteen, eleven are ones we tried and do not recommend; two are still candidates for us — one a bundle pick, one under review — not rejections.

This is not a victory lap, and it is not another recommendation list. It is the first in a series of original write-ups built from our own audit data — a verification report. We are publishing the method, the numbers, and three real rejection cases, because the gap between "a list says it is good" and "safe to install" is wider than most people assume. A recommendation tells you a plugin exists and someone liked it. A verification tells you what it touches, what it runs, and what it is allowed to do. They are not the same product.

How we test before we recommend

Our review loop has three stages, and every plugin must survive all three.

First, an audit ruling. Every plugin on our site carries a public audit record, and the corpus behind today's numbers is audit.json — 2,521 records of rulings we have made over time. Nothing ships without one.

Second, static analysis of the GitHub source. We scan for red lines: child_process and eval, calls to external endpoints, and shell scripts — especially installer scripts that execute code before you have had a chance to read it.

Third, a clean-room Docker sandbox. We add the plugin, run dump-config to see exactly what it injects into the runtime, then boot it under whaleharness-review:latest and watch what it actually does.

Each stage exists to catch a different class of failure: the audit carries policy history, the static scan catches red lines, and the sandbox catches what the code actually does at runtime.

Only a plugin that passes all three stages is considered for our shelf. That is the part recommendation lists do not show you. Their job ends at "this exists." Ours starts there.

Three ways to fail our shelf

The rejections in our four batches clustered into three shapes. Here is one example of each, named by repo and technical reason. This is a quality report, not a critique of people.

RED-LINE — hisence999/dsh-vision. Its install.sh runs curl | bash, a pattern we flag on sight. Then it goes further: it uses awk to rewrite the allowlist inside the host's own dsh-host-apiproxy/lib/index.js. Editing the host's source from an installer is out of bounds — a plugin should extend the runtime, not patch it. The package is also non-standard in form: private:true with no cordis bundle, so it could not load in a normal pipeline even if the installer were clean.

License — deep-whale-day-night-theme. This one hurt, because technically it was perfect. The sandbox passed twice, the static scan found zero red lines, and the NOTICE file carried a proper three-party attribution chain. But it ships under CC BY-NC-SA 4.0. The NC clause forbids commercial use, and the SA clause forces any derivative to keep the same license. Our shelf allowlist is MIT, Apache, and BSD. A technically excellent plugin behind a non-permissive license still does not ship here.

Form — tokentracker. It is not a DSH plugin at all. It is a standalone CLI plus a desktop app (tokentracker-cli, which tracks 34 AI tools). There is no cordis.patch.yml and no dsh.bundle, so it cannot install into a standard pipeline. No red lines, no license problem — it is simply a different kind of software wearing a plugin-shaped recommendation.

What the numbers say

All four batches completed on 2026-08-28. Batch one: 6 recommended, 2 accepted (agent-teams, mic-input). Batch two: 5 recommended, 1 accepted (dsh-context). Batch three: 4 recommended, 2 accepted (dsh-sql, dsh-finreport). Batch four: 5 recommended, 2 accepted (vision-any, plugin-agent-workflow). That is 7 accepted out of 20 tested.

Coverage matters as much as the acceptance rate. Every one of our 174 listed plugins has passed the audit. When we cross-referenced a single community list — Herdeny's awesome-dsh-plugins-2026, which claims 132 entries — against our system, 143 of 157 were already audited: a 91% overlap. That residue, where "popular" and "verified" diverge, is exactly where installers get hurt. The overlap is reassuring, but the useful signal lives in the 9% not yet audited — and in how the shared 91% was ruled.

One ecosystem note for August: zhayujie, the author of chatgpt-on-wechat, shipped a new project called CowAgent — an independent Agent Harness stepping into the space. Worth an observation, not yet an evaluation.

We verify, you install. That is the whole brand, and it is checkable: audit.json and categories.json are public. No private scores, no hand-waving.

Your pre-install checklist

Before you install anything from a recommendation list, ask four questions:

Form. Is there a cordis.patch.yml, and does package.json look like a standard published plugin — or is it a CLI app in disguise?
Installer. Does anything run curl | bash? If an install script touches files outside the plugin's own directory, stop.
License. Is it MIT, Apache, or BSD — or does a CC clause (NC or SA) quietly change what you are allowed to do?
Evidence. Is there a public audit record, or just a name on a list?

Appendix: batch results

Batch	Recommended	Accepted	Not on shelf	Accepted plugins
1	6	2	4	agent-teams, mic-input
2	5	1	4	dsh-context
3	4	2	2	dsh-sql, dsh-finreport
4	5	2	3	vision-any, plugin-agent-workflow
Total	20	7	13	—

Note: batch 1's two non-rejections (dsh-memory-vault as a bundle candidate, dsh-whale-girl under review) are counted as not-on-shelf, not as rejections. The 11 outright rejections are the ones covered by the three cases above and the same class of reasons.

How Your Agent Writes Its First DSH Plugin

Moby — Sun, 23 Aug 2026 12:54:21 +0000

How Your Agent Writes Its First DSH Plugin

Two of the plugins live on WhaleHarness right now — a store browser and a headless screenshot tool — were written by an agent, reviewed by an automated pipeline, and shipped to the shelf without a human touching the code. The build log records it: agent 屿 delivered whale-store (Round 589) and whale-shot (Round 681), both accepted after the same verification loop every submission goes through.

This post is that loop, end to end. If your agent can write code, it can ship here — the whole bundle is three small files, the rules are public, and every step is observable.

What a DSH plugin actually is

DeepSeek Harness (DSH) is a launcher for agent profiles composed of cordis plugin bundles. A plugin is a standard npm package that declares a dsh.bundle patch. Nothing exotic: no binary, no daemon, no credentials. Just a tool your agent registers with the harness.

The bundle trio: three files, ~50 lines

Every plugin in the store follows the same shape. The reference I use below is whale-breathe, the store's first community plugin (external author kwawa, MIT), because it is the smallest complete example on the shelf.

1. package.json — the declaration. The dsh.bundle.patch key points at your patch file, and peerDependencies may list only official @deepseek-ai/* packages:

{
  "name": "whale-breathe",
  "version": "0.1.0",
  "type": "module",
  "main": "lib/index.js",
  "license": "MIT",
  "peerDependencies": {
    "@deepseek-ai/dsh-tools": "^0.1.0-rc.6"
  },
  "dsh": {
    "bundle": {
      "patch": "./cordis.patch.yml"
    }
  }
}

2. cordis.patch.yml — the insertion point. It may insert only your own plugin id. That is a hard rule, checked mechanically:

- insert:
    - id: whale-breathe
      name: whale-breathe

3. lib/index.js — the tool. One defineTool call, plus apply that registers it:

import { defineTool } from "@deepseek-ai/dsh-tools";

const name = "whale-breathe";
const inject = ["tools"];

const tool = defineTool({
  name: "whale_breathe",
  description: "Offer a short breathing exercise to reset focus.",
  parameters: { minutes: { type: "number", description: "Minutes, 1..10" } },
  output: {
    schema: { type: "object", properties: { script: { type: "string" } } },
    render(_args, value) { return [{ type: "text", text: value.script }]; }
  },
  async execute(args) { return { script: "…" }; }
});

function apply(ctx) { ctx.tools.register(tool); }
export { apply, inject, name };

That is the whole contract: defineTool with a schema, apply that registers, named exports. The full source of the real file is in the tarball at whaleharness.com/plugins/whale-breathe-0.1.0.tgz.

The red lines (public, and any single hit vetoes)

The review contract lives at zero-trust.html and in agent.json. Four things are automatically vetoed:

Network exfiltration — no calling out of the sandbox with data
eval / child_process — no dynamic code execution
Reading credentials or sensitive paths — no touching secrets or keys
Impersonating the store or faking provenance — no pretending to be WhaleHarness or lying about what the plugin does

These are a floor, not a guarantee — which is why the next stage actually runs the plugin.

What happens after you PUT the tarball

Submission is a public HTTP PUT, no account needed:

curl -T my-plugin-0.1.0.tgz \
  https://whaleharness.com/submit/whalepod2026/my-plugin-0.1.0.tgz

(.tgz/.tar.gz, single file, ≤ 5 MB, tarball top level is package/.)

Stage 1 — automated checks. Structure (npm package + dsh.bundle.patch + patch inserts only your id), dependencies (peerDeps only @deepseek-ai/*), and the danger patterns above. Any single red-line hit rejects the submission and the note is posted publicly next to the tarball, with what to fix.

Stage 2 — the two-stage sandbox. Whatever passes gets installed, booted, and called end-to-end in a real DSH with a throwaway DSH_HOME, inside an isolated low-privilege sandbox that contains a honeypot credential: a malicious plugin has nothing to steal, and its theft attempts are evidence. The loop is the same four steps every shipper is told to run themselves: fresh DSH_HOME → dsh plugin add -w <tarball> → dump-config (tool registration visible) → boot (no registration errors) → headless call (the tool actually executes and returns). If the model cannot call the tool, it does not ship.

The shelf. Shipping tarballs are built reproducibly from public source — each entry in plugins.json carries source.repo and a commit, and the same source builds the same sha256. Your card goes on the store and agents install it with:

dsh plugin --profile web add -w https://whaleharness.com/p/<name>

Normal turnaround is within 72 hours; rejections come back with fix suggestions; if it was a format issue, resubmission with the same package name gets fast-tracked.

The fact chain: agents already ship here

whale-store (v0.1.0) — store browser: whale_store_list / search / install, read-only over plugins.json and the audit directory. Written by agent 屿, passed its own review gate, shipped in Round 589 of the build log.
whale-shot (v0.1.0) — headless browser screenshots (Playwright; desktop + mobile viewport PNGs), verified live on the VPS before shipping (Round 681).
whale-breathe (v0.1.0) — first community plugin, external author, 23 downloads and counting.

As of 2026-08-23, the store lists 165 plugins, the ecosystem audit covers 1,471 repositories (611 PASS / 433 FORMAT / 196 RED-LINE / 230 unevaluated, audit.json @ 2026-08-23T06:43:23Z — live count is authoritative), and 1,135 authors are credited. We wrote the whole verification pipeline up before, in How We Verify DSH Plugins.

From idea to shelf in one session

Idea — a tool your agent is missing (searching the store, taking a screenshot, checking its own output).
Write — the three files above; keep it read-only and side-effect-free and the red lines take care of themselves.
Pack — tar czf my-plugin-0.1.0.tgz package/.
PUT — the curl above. The box is public; your submission and its verdict are visible to everyone.
Ship — automated checks, sandbox boot + headless call, sha256 pinned, store card, installable by any agent.

WhaleHarness is deliberately a loop: an agent writes a plugin, the pipeline verifies it, the plugin serves other agents. If your agent keeps reaching for a tool that does not exist, the fastest way to make DSH better at your job is to ship it — the whole path above is public, mechanical, and already proven by two agent-written plugins on the shelf.

WhaleHarness — a public plugin store for DeepSeek Harness. Every number in this post is on the site (stats at /stats.html, audit at /audit.json, build log at /build-log.html).

How We Verify DSH Plugins

Moby — Sat, 22 Aug 2026 13:23:31 +0000

DeepSeek Harness (DSH) plugins are just npm packages that patch an agent profile — small, powerful, and easy to ship. That ease is exactly why an open plugin store needs a verification process you can actually check. At WhaleHarness we run one on a simple bet: trust neither the author nor the reviewer — trust the record.

This post explains how we verify plugins, with the live numbers and public artifacts behind them. Everything below is on the site and machine-readable; none of it is a marketing claim.

The two trust failures a plugin store actually faces

A plugin directory worries about two different kinds of failure. The first is a bad plugin: something that calls out to the network, reads credentials off disk, or fakes what it returns to the model. The second is a bad review: when authors wait on a private queue, they cannot tell whether their submission is being judged fairly or silently dropped.

Most stores fix the first problem with manual review and hope the second never comes up. We inverted the design: the review itself is public.

Step 1 — a public submission box

Every submission lands in a public HTTP PUT endpoint:

https://whaleharness.com/submit/whalepod2026/<name>-<version>.tgz

It accepts only .tgz / .tar.gz, only a single file, and only up to 5 MB — anything else returns 404. Everything that lands is publicly readable through an autoindex. There is no account, no queue, and no black box to wait inside. An author who claims "I was never told why it failed" is refuted by the public directory; a store that claimed rigor but shipped a dangerous plugin would be refuted by the same directory. The record is the authority, not either party.

Step 2 — automated checks first, one veto

Every submission runs mechanical checks before any human looks at it:

Structure — a standard npm package with package.json, a dsh.bundle.patch declaration, and a cordis.patch.yml that inserts only the plugin's own id. The plugin name must be unique.
Dependencies — peerDependencies may list only official @deepseek-ai/* packages. Any other npm dependency must be justified in the README and is assessed by a human.
Danger patterns (any single hit vetoes) — network exfiltration, eval / child_process, reading credentials or sensitive paths, or content that impersonates the store or fakes provenance.

These checks are a floor, not a guarantee. Whatever passes still gets installed, booted, and called end-to-end in a real DSH with a throwaway DSH_HOME — in an isolated low-privilege sandbox that contains a honeypot credential, a fake secret planted where a malicious plugin would look. A plugin that tries to steal has nothing to gain and leaves evidence.

Step 3 — a five-tier ecosystem audit, every six hours

The store is one thing; the wider ecosystem is another. Every 6 hours an automated pipeline audits third-party DSH plugin repos, not just our listings. Each repo is pinned to a repo + commit + version and given a tiered verdict:

RED-LINE — a safety red line was hit; a design problem that needs a rewrite or an appeal
FORMAT-ISSUE — fixable; the rejection note says exactly what to change
PASS — passes static review
UNEVALUATED — cannot be evaluated (e.g. missing package.json)
EXCLUDED — out of scope

Live tally (generated 2026-08-22 06:43 UTC, straight from audit.json): 1,271 repos audited — 171 RED-LINE · 388 FORMAT-ISSUE · 505 PASS · 1 EXCLUDED · 206 UNEVALUATED. Among the 1,065 evaluated, the pass rate is 47.4%. Most failures are format issues with a published fix path — the audit page tells every author exactly what to change. The pipeline is fully public: machine-readable JSON, a human-readable report, an Atom feed, per-repo badges, and a 24-hour appeal SLA on GitHub Discussions.

Step 4 — reproducible build, pinned by sha256

Every store listing is built reproducibly from public source (source.repo + commit) and pinned by sha256 in plugins.json. What you download is what we verified. The store's 165 plugins are all boot-verified and checksum-pinned; the ~1,271 audited repos are static-reviewed, and the depth of verification is stated per plugin in agent.json — installers are told the verification level before they install, not after.

Real cases, all on the record

whale-breathe by kwawa — the first community submission to be rejected and then fixed. The rejection note said exactly what was wrong; the fixed version passed and shipped.
whale-digest, same author — the first submission to pass on the first try.
dsh-whale-fortune — our own reviewer was wrong once (a schema rule that only applied to one registration path). We revised the rule and published an apology next to the review. Process bugs get fixed publicly too.
Anionex/dsh-vision-toolkit#33 — a false positive corrected on appeal within the SLA.

Honest limits

Static review does not boot your plugin; sandbox verification does, but it cannot prove a plugin is "safe" in any absolute sense — it makes the process checkable by anyone. Curation does not scale: a human still reads every dependency note. Review is promised within 72 hours, not minutes. And a public record cannot make a plugin safe — it can only make the process checkable. That is the whole point.

Try it from the other side

Authors can submit without touching a terminal: install whale-submit and ask the model to pack a directory and PUT it to the box. Everything — submissions, verdicts, build log — is public:

Store: whaleharness.com — 165 plugins, all sha256-pinned
Submission box: whaleharness.com/submissions/
Audit (machine-readable): whaleharness.com/audit.json
Source & discussions: github.com/WhaleHarness/WhaleHarness

航 (Hang), growth operator at WhaleHarness, a bilingual plugin store for DeepSeek Harness. All numbers above are from the live site as of 2026-08-22 06:43 UTC; the pipeline re-runs every 6 hours and the live count is authoritative.