DSH Field Guide Checked against the binary

DSH Field Guide

What DeepSeek Harness actually does, claim by claim

An independent guide to dsh, pinned to commit b150a55, where every one of its 45 factual claims carries a badge saying how it was established: run against the shipped binary, read from source, or taken from outside the project. Six claims that circulate widely did not survive the check, and each correction names what replaced it.

Read the field guide View the code on GitHub

MIT licensed*No affiliation with DeepSeek*One HTML file, works offline

AS IT CIRCULATES AS THE GUIDE PUBLISHES IT RUN SOURCE EXTERNAL RUN Same claims. One side tells you which ones were run, and which one failed when it was.

Three explainers, the same numbers, no sources

You read three write-ups of a new agent harness in a week. They agree, which feels like corroboration right up to the moment you notice they agree on the same numbers, in the same order, with the same rounding. None of them says which figures came out of a running process and which were read off a directory listing.

So you clone the repository, boot it, and the count on your screen is not the count in the post. Now you have to work out whether you misconfigured something or whether the post was never checked, and that costs you the afternoon you were trying to save.

That is not a reading problem. Secondary sources compress each other: the second post trusts the first, the third trusts the second, and by the fourth nobody has touched the binary. What survives that chain is whatever was most quotable, not whatever was most true, and a number with no provenance attached is indistinguishable from a number somebody guessed.

How it works

The method is deliberately boring, and all four steps are things you can repeat against the same commit.

  1. Pin a commit before writing anything

    Every claim is checked against b150a55, dated 2026-08-21, with the working checkout at 0.1.1-rc.2. A guide that says "currently" starts rotting the day it ships. A guide that names a commit can be argued with, because you can check that commit out and prove it wrong.

  2. Ask the binary, not the directory listing

    Where a claim is about runtime, it gets settled by running dsh --profile web --dump-default-config against the installed npm artifact rather than by counting folders in the repo. That single habit is the difference between reporting 227 and reporting 104.

  3. Badge every claim with the evidence behind it

    Run means it was executed. Source means the file was read but the behaviour was never run. External means it came from outside the project. The split is 17, 17 and 11, and the two weaker classes are labelled as weaker instead of being blended into the strong one.

  4. Print the gaps at the top

    The binary actually exercised was 0.1.0-rc.7 while the source read was 0.1.1-rc.2. That mismatch is stated in the guide rather than smoothed over, because it is the first thing anyone reproducing the work would hit.

Three things it is for

All three come out of the same 16 sections, because what makes the guide useful for building is the same property that makes it useful for a security review: it tells you which sentences were checked and which were only read.

  • Orient

    Size it before you commit a week

    What dsh is at accurate scale: the plane it occupies, what the presets really are, and the four preset IDs that actually ship rather than the ones the threads list.

  • Build

    Write a plugin that loads first time

    A working plugin sits in this repository at plugins/dsh-plugin-dev/ with a node verify.mjs you can run yourself. The guide walks its three files and the composition traps between them, including the patch behaviour that has no deep merge.

  • Assess

    Judge the security posture honestly

    Network is not in the sandbox policy vocabulary, reads are unrestricted, and the environment scrub is not a credential firewall. The guide says all three in section 11, with the package sources each one came from.

The six claims that did not survive

Each of these is repeated widely, and each is wrong in a way that changes a decision you might make. The key names the subject; the text is what the binary or the source actually says.

misconceptions

Six corrections, with the evidence class each one rests on.

  • presets There is no orchestrator. The IDs are standard, code, minimal and cordis4 IDs Run
  • code mode Changes tool presentation, not the model. The program is ephemeral and never saved Run
  • kernel There is a kernel. Nearly everything above it is a plugin, and nothing above it is privileged Source
  • trajectory A turn-aware event ledger. It cannot attribute every loop action to an owning plugin Source
  • sandbox Containment, not a security boundary. Network is not in the policy vocabulary Source
  • 227 The repository package count. A real web session boots 104 active plugins129 rows Run

The last row is the one worth dwelling on. 227 is a real number, it is just a count of directories in a monorepo rather than a measure of anything that runs. Compose a real web profile and 129 rows resolve to 104 active plugins; the headless profile boots 79. Three numbers, three different questions, and the one in general circulation answers none of them.

45claims badged with how they were checked
17executed against the shipped binary
6widely repeated claims corrected

The diagnostic that settles most of these ships with the product. It prints the fully composed tree without booting it, annotated with which bundle contributed each row and which bundle patched it:

$ dsh --profile web --dump-default-config

# == @deepseek-ai/dsh-base
- id: timer
  name: '@deepseek-ai/cordis-plugin-timer'
# == @deepseek-ai/dsh-base, patched by @deepseek-ai/dsh-web-app
- id: hmr
  name: '@deepseek-ai/cordis-plugin-hmr'
  config:
    root: [.]
  disabled: true

Every correction above is written out in full in section 15, with the command or the file it came from.

Compared with the two things you would otherwise read

The project's own documentation

Authoritative, current, and far more complete than any outside guide will ever be. It is the right place to start and the right place to end up. The boundary is that documentation describes intent as much as behaviour, and a file can describe an intent the running system does not honour. When the two diverge, the docs are not the thing that tells you.

The explainer posts and threads

Fast, readable, and usually first to a new release, which is genuinely valuable when you are deciding whether to look at all. The boundary is that they inherit each other's numbers. Both the 227 figure and the orchestrator preset circulate widely, and neither one survives contact with the binary.

The only real advantage this guide has is that it marks its own weak spots, including the 17 claims it read from source but never executed.

What this is, and what it is not

This is an independent guide written by one person. It is not a vendor document, it was not reviewed by the harness maintainers, and it had no access to anything you could not clone yourself. Where it is wrong, it is wrong in public at a commit you can check out, which is the only form of wrong that is useful to anybody.

The strongest evidence in it is a Run badge and there are 17 of those. The weakest is a Source badge, meaning the file was read but the behaviour was never executed, and there are 17 of those too. Treat the second group as well-founded and unconfirmed, and check it before you depend on it. That instruction is in the guide's own preamble, not buried here.

  • MIT licensed, including the worked plugin example
  • No affiliation with DeepSeek or the harness maintainers
  • One HTML file with no tracking, no analytics and no network calls
  • Pinned to b150a55 so every claim stays checkable
  • The version gap, 0.1.0-rc.7 run against 0.1.1-rc.2 source, is printed in the guide
  • Chinese preset display names are quoted as shipped, not translated away

Frequently asked questions

How is this different from the official DeepSeek Harness documentation?

It is smaller, it is not authoritative, and it should not replace the docs. What it adds is a provenance layer the docs do not carry, because they have no reason to: an official document does not need to tell you which of its sentences were executed, since it is written by the people who wrote the code. An outsider does need to tell you, and the badge on each claim is that admission made structural. Read the guide to calibrate, then read the docs to build.

Is this affiliated with DeepSeek in any way?

No. No sponsorship, no review, no early access, no contact. Everything in it came from the public repository and the published npm artifact, both of which you can fetch yourself. DeepSeek Harness is MIT licensed and so is this guide, which is the whole of the relationship.

The guide says 104 plugins and another post says 227. Which is right?

Both, for different questions. 227 counts packages in the repository. 104 is how many plugins are actually active in a composed web session, resolved from 129 rows; the headless profile boots 79. If the question is "how much machinery runs when I start this", 227 is the wrong answer by more than a factor of two. Run dsh --profile web --dump-default-config and you get the composed tree directly rather than having to trust anyone's count, including this one.

You ran 0.1.0-rc.7 but read 0.1.1-rc.2 source. Does that invalidate the guide?

It weakens specific claims rather than the whole document, and it is stated up front for exactly that reason. Anything carrying a Run badge was executed on 0.1.0-rc.7, so a behaviour changed between the two release candidates would not show up. Anything carrying a Source badge was read at b150a55. The honest position is that the structural claims are pinned tightly and the behavioural ones lag by one release candidate, which is the sort of thing a guide should tell you rather than let you discover.

What exactly does a Source badge mean, and why should I care?

It means the claim was read from the repository but never executed. That is reliable for structure, such as what a file declares or how a tree is laid out, and weaker for behaviour, because a file can describe an intent the running system does not honour. Where a claim in the guide is about behaviour and carries only a Source badge, it is well-founded and unconfirmed, and you should check it before depending on it. Seventeen claims are in that category and they are individually marked.

Can I actually run the plugin example, or is it a listing?

You can run it. It lives at plugins/dsh-plugin-dev/ in this repository, ships two skills, and includes a node verify.mjs that checks it loads. The plugin section walks the three files it is made of and the composition traps around them, the sharpest being that patching a row replaces the entire config rather than deep merging, so any field you want to keep has to be restated.

What happens to this when the harness changes?

It goes stale, and it says so. A guide pinned to a commit is a snapshot by construction, which is a weakness for currency and a strength for arguing: a claim tied to b150a55 can be checked against b150a55 forever, whereas a claim about what the project does "today" cannot be checked at all a month later. The drift section names the parts most likely to move first. If something here is now wrong, open an issue on the repository and it gets corrected in public, in the same way the original six were.

Why should I trust an independent guide over the people who built it?

You should not, on authority. The maintainers know more about their own system than any outside reader ever will. What an outsider can offer is the record of what actually happened when someone with no prior knowledge installed the thing and tried to use it, which is information the maintainers structurally cannot produce about their own work. Trust the badges, not the author: every one of them names a command you can run or a file you can open.