DSH Plugin market vs docs vs GitHub: which to trust

When a DSH plugin question comes up, the DSH Plugin market, the official docs and GitHub are not three answers to the same question. The market is a discovery index, the docs describe intended usage, and the repository shows what the code actually does. Most apparent contradictions disappear once you notice that each source was asked something it never promised to answer.

What the DSH plugin market is good for

The DSH plugin market answers whether an entry exists, which version it points at, who published it and when it last changed.

The market is a discovery index built to help you find an entry, compare candidates and reach an install command. Its fields are optimized for recognition rather than for documenting runtime behavior. That makes it excellent for the question "is there a plugin for this" and poor for the question "exactly how does it behave". Confusing those two questions is the root of most disappointment with market descriptions.

Identity fields are the reliable part: package name, publisher, version, update time and category. Capability claims such as supported platforms, performance numbers and permission scope are author-supplied and unevenly validated. A market description can tell you which problem the author intended to solve, but not whether the current release solves it on your machine. Treat capability claims as a shortlist to investigate rather than as evidence.

The practical use is to search, confirm that the package exists, note its version and then leave. Every additional question is better answered somewhere closer to the code. The market earns its place at the start of the process, not at the end.

What official DeepSeek Harness plugin docs answer

Official docs describe the usage and boundaries the project intends for a specific DeepSeek Harness plugin version.

They explain configuration options, call patterns, expected inputs and the Harness range a plugin was built against. That is the contract layer: it states what should happen and which conditions the authors consider supported. A good page also names the limits, such as unsupported platforms or features that require additional setup. Reading it before installation prevents most misuse that looks like a bug.

Documentation is still written by people and can lag the code or target an older Harness release. A page may describe the current major version while your installed client is two minors behind. It may also document a feature that was renamed after the page was last edited. None of that makes the docs useless; it makes the version context essential.

When the docs and your experience diverge, first confirm which version they describe. Use the docs to learn the intended usage and to interpret configuration, not to decide whether a package exists. Existence belongs to the market and npm, while intended behavior belongs to the docs.

What GitHub adds to a DSH plugin question

The repository is the closest source to actual behavior, because tags, code and release notes are what run on your machine.

A tag tells you which snapshot corresponds to a released version, and the diff tells you what changed between two of them. Release notes explain intent, while the code shows the implementation that actually shipped. Issues add the failures other users hit, including platform-specific ones that no documentation page lists. When two sources disagree about behavior, the repository is where the argument ends.

The README is still a document and can be stale, so treat it as a guide rather than as proof. The source tree, the package manifest and the test suite are stronger evidence about dependencies and runtime access. Open issues are especially useful for install failures, because the error text is more specific than any summary. Searching the issue tracker often answers in minutes what a description cannot answer at all.

The repository is a poor discovery tool, though. It assumes you already know the package name and roughly what it does. Use the market to find candidates, then use the repository to settle what those candidates actually do.

When the DSH plugin market and docs disagree

Most conflicts are version conflicts, so align four versions before deciding which source wins.

Write down the market version, the Harness range the documentation applies to, the repository tag and the version reported by dsh plugin list. Putting them side by side usually reveals that one source describes a release you are not running. An apparent contradiction between a market page and a docs page often disappears once the dates and ranges line up. Only after alignment does a real disagreement deserve a decision.

When the sources genuinely conflict, trust the one closest to the code:

1. Repository code and tags, which show what actually runs.
2. Release notes and changelog, which explain what changed between versions.
3. Official documentation, which states intended usage and boundaries.
4. Market entries, which confirm existence and version indexing.
5. Community posts, which only offer leads.

The market remains authoritative for existence and indexing, but its prose ranks lowest as behavioral evidence. That order follows the distance between a claim and the thing that executes.

If the versions differ, you are not looking at a conflict at all. You are looking at two accurate descriptions of two different releases. Decide which release you care about, then re-read only the sources that describe it.

A DSH plugin source order that survives disagreement

Route by the question you are asking, and put popularity last.

For existence and current version, start with the market and confirm on npm. For configuration and intended usage, read the official docs for your Harness range. For actual behavior and recent changes, read the repository's code, tags and release notes. For install failures, read the error output and the issue tracker before any descriptive page.

Popularity is the weakest signal in the set because it accumulates history and lags the current release. Install counts and ratings rarely distinguish a plugin that is actively maintained from one that was popular two years ago. They also say nothing about whether a DeepSeek Harness plugin fits your platform or permission model. Use them to notice candidates, never to settle compatibility.

Teams that maintain DSH plugins benefit from writing the source versions next to every conclusion. A note such as "works with this version, per this tag" survives longer than "the docs say it works". Conclusions age, so re-check the decisive source on the day you rely on it.

Sources: DSH Plugin Hub entry, official documentation, deepseek-harness repository.