DeepSeek Harness is in developer preview, which means the runtime changes and plugins have to say what they were built against. That declaration is the dshTarget field, and getting it right is the difference between a plugin that installs everywhere and one that breaks silently.
What a manifest contains
A plugin manifest is the metadata that describes the package to the harness and to directories. In practice it lives in package.json plus a small harness-specific block. The fields that matter:
| Field | Purpose | Notes |
|---|---|---|
| name | Package identity | Must match the published name exactly |
| version | Release version | Follow semver; users pin this |
| type | Module system | module for modern plugins |
| keywords | Discovery | Include dsh-plugin and deepseek-harness |
| dsh.target | Harness compatibility | The version you tested against |
| license | Legal clarity | Required by most directories |
| repository | Source of truth | Directories use it for listing and activity |
Anything a directory cannot read from these fields it will either infer badly or leave blank, which is why the manifest is worth treating as user-facing content rather than build metadata.
How dshTarget works
dshTarget declares the harness release your plugin was built and tested against, for example rc.6. It is a contract, not a guess. Users compare it against their installed harness before installing, and directories use it to filter listings.
Three rules keep it useful:
- Declare the version you actually tested. A plugin tested on
rc.5and never run onrc.6should sayrc.5. - Update it in the same commit that adopts a new runtime capability, not in a separate release people forget.
- Never declare a newer target than you need. Plugins that claim a hypothetical future version keep working users away for no benefit.
Declaring it
In package.json:
{
"name": "dsh-my-plugin",
"version": "0.3.0",
"type": "module",
"keywords": ["dsh-plugin", "deepseek-harness", "web-search"],
"license": "MIT",
"repository": "https://github.com/you/dsh-my-plugin",
"dsh": { "target": "rc.6" }
}In the README, state it in plain language as well, because humans read the README first:
Tested against DSH rc.6. On earlier releases the tool registers but the
streaming status field is unavailable.Describing the failure mode, not just the version, is what turns a compatibility note into something a user can act on.
What happens when a plugin is incompatible
The failure is usually legible: the runtime reports a load error for the plugin while the rest of the session continues. What you want to avoid is a plugin that loads and then misbehaves, because that looks like a harness bug to the user and produces confusing reports.
If your plugin touches a surface you know changes often, such as interface rendering or an event payload shape, add a runtime check at load time and refuse to activate with a clear message. Declining to load is a better user experience than loading badly.
Compatibility as a listing signal
Directories display compatibility because it answers the question users ask before installing: will this work on my harness. On this site, the field appears on every plugin page alongside the verification level and the last update date, so you can judge both whether it runs and whether anyone is still maintaining it.
FAQ
Does dshTarget replace peer dependency declarations?
No. It communicates harness compatibility to users and directories. Dependency ranges still govern package resolution.
How often should I bump it?
Whenever you adopt a new runtime capability or complete a compatibility pass. Not on every release.
Can one plugin support two harness versions?
Not through a single declaration. If a range is required, document it in the README and test against both.
What if I do not declare it at all?
The plugin still installs. Directories will mark compatibility as unknown, which measurably reduces installs because users cannot tell whether it fits.
Next steps
Read the Cordis lifecycle guide for the runtime behaviour behind these fields, then publish your plugin.