dsh plugins meaning: package, entry, instance layers

dsh plugins is a phrase that gets used for at least four different things, and most confusion starts when two of them are swapped in the same sentence. A package name, a hub listing and a loaded runtime object can all be called "the plugin" even though each answers a different question. Separating those layers makes installation problems, market searches and "it does nothing" reports much easier to reason about.

What a dsh plugin means before you install it

At the conceptual layer, a dsh plugin is a described capability rather than a file you can install.

Documentation, README files and category pages speak in this register. They explain that a plugin adds a desktop pet, a tool bridge or a custom panel, and they usually stop before naming a version. That is appropriate for discovery, because a reader is deciding whether the capability fits a workflow, not yet which artifact to fetch. Treating that description as a promise about your installed copy is where trouble begins.

The concept layer is also where naming gets loose. Two authors may both advertise a "workspace search" plugin, while one wraps an external binary and the other is pure UI. Neither listing is wrong, but the words alone cannot tell you what will run on your machine. The useful move is to leave this layer with a requirement, such as "search files from the command palette", and then look for the package that actually implements it.

Why a DSH plugin package and its market entry differ

A DSH plugin package is an identity, while a hub entry is a presentation, and the two are allowed to disagree.

The package name is what npm resolves, what a lockfile records and what an install command consumes. The entry name is what a reader sees in the DSH Plugin Hub, often with a friendlier title and a category chosen for browsing. An author can rename the display title without republishing the package, and a package can appear under more than one editorial description. When names diverge, trust the package for installation and the entry for discovery.

This split explains a common support question: someone installs what the market page calls the plugin and then cannot find that string in dsh plugin list. The list reports packages, so the display title is absent by design. Copying the package identifier from the entry detail, rather than the headline, prevents the mismatch. It also makes version comparisons meaningful, because only the package has a version that npm can resolve.

How a dsh plugin becomes a running instance

An installed DSH plugin package does nothing until a profile loads it as a runtime instance.

The profile decides which packages are enabled, and loading creates an object with its own configuration and state. That object is what the interface actually talks to, which is why the same package can behave differently in a web profile and a desktop profile. In a plugin list, the package may be present while the instance is pending, failed or disabled. Installation is therefore a prerequisite, not proof of effect.

Profiles also explain why one machine can appear to have two copies of the same plugin. Each enabled profile can hold its own instance, with separate settings and separate startup timing. When a user says a plugin is "installed twice", they are often looking at two instances of one package. Checking the profile name alongside the package name resolves the ambiguity faster than reinstalling anything.

Reading a dsh plugin problem across all four layers

Most dsh plugin complaints become tractable once you name the layer that produced the evidence.

A version number belongs to the package layer, a profile name belongs to the instance layer, and a category belongs to the concept layer. Mixing them produces conclusions that cannot be tested, such as "the plugin is broken" after seeing a stale hub page. The practical habit is to write down one artifact per layer before forming a theory. Then the missing or contradictory artifact tells you where to look next.

Suppose a DeepSeek Harness plugin is listed in the hub, installed from npm and still idle. Read the trail in this order:

1. The hub entry proves discovery, but it does not prove that npm can resolve the package.
2. The npm package proves availability, but it does not prove that the local machine installed it.
3. The local plugin list proves installation, but it does not prove that a profile loaded the package.
4. The profile state is the only artifact that proves the instance is running.

None of the first three closes that gap, which is also why DSH plugins should be discussed with their package names in bug reports: a display title gives a responder nothing to reproduce.

Keeping dsh plugins straight in daily conversation

Precision about layers is less pedantic than it sounds, because it changes the next action.

Saying "the package is installed but the instance is not active" points to a profile check. Saying "the entry exists but npm cannot resolve the version" points to publishing or registry access. Both sentences are short, yet they route the work differently. The extra noun is usually worth more than another round of reinstalling.

The four layers will keep overlapping in casual speech, and that is fine as long as the evidence stays separate. A concept explains intent, a package carries identity, an entry supports discovery and an instance decides behavior. Once those roles are clear, even a vague report can be turned into a specific check. That is the practical value of the model: not a taxonomy to memorize, but a way to ask the next question.

Sources: your first plugin, DSH Plugin Hub plugin entry, npm @deepseek-ai/dsh.