Plugin sources: index, repo and update source

"Plugin source" means at least three layers: index source, distribution source, and update source. Mixing them produces "cannot find it," "cannot install it," and "update does nothing," which look unrelated.

Three layers are not one

Separate them before configuring.

The index controls discovery. It affects search and categories, not installation; missing from search does not mean missing from npm.

Distribution controls installation. npm, GitHub, and local are the three forms; they install the same kind of plugin with different build and authorization flows.

Update controls upgrades. The source is recorded in profile dependencies; changing it changes update behavior.

Index source: what the Hub indexed

Hub search comes from an index, not live crawling. There is a delay between a repository appearing and being indexed (source).

1. Search the plugin and check result count and categories.
2. Try Chinese, English, and package-name spellings.
3. If all fail, check the GitHub topic or npm package name.
4. Repository exists but market missing means indexing lag or non-inclusion.
5. To install immediately, use custom install or the CLI.

The index does not need frequent switching. The default covers most plugins; switching changes search scope and adds duplicate entries.

Index lag is not a failure. Use the distribution source when in a hurry.

Distribution source: npm, GitHub, local

Distribution decides the install method, each with prerequisites.

1. npm: published with build output, one add command; easiest.
2. GitHub: installs source, requires a prepare script and user build authorization; for unreleased plugins.
3. Local directory: add ./directory links source into the profile, for editing.
4. Tarball: for internal distribution and offline installs; version-controlled but manually managed.

GitHub is most likely to fail at build. pnpm refuses build scripts by default, so the package name must be allowed; otherwise it installs without output (source).

A local directory is a link, not a copy. Source changes apply after a restart; dependency changes need another add.

Update source: what the profile records

Upgrading is not reinstalling; it fetches a new version from the recorded source.

1. Check the source and version recorded in profile dependencies.
2. Confirm the source is the one you intend.
3. Run the update and see which version arrives.
4. Verify the version and function afterward.
5. Pin a version when you need reproducibility.

Source and version are two pieces of information. The source determines where, the version determines what; changing only one can behave unexpectedly.

Changing sources requires re-recording. Move from npm to GitHub and the profile still points at npm for updates.

Switching and priority

Switch distribution first, then update, then the index last.

1. Confirm distribution works: install a known plugin.
2. Confirm the update source: profile source and version are as expected.
3. Consider the index last: it affects discovery, not installed plugins.
4. Change one layer at a time.
5. Compare after change: search, install, and update the same plugin.

The index has the lowest priority. It does not change installed behavior; checking it first sends diagnosis the wrong way.

Multiple index sources duplicate results. Keep one primary source.

Failure diagnosis

Four failures, layer by layer.

1. Not found: index lag or non-inclusion; check repository and npm.
2. Install fails: unreachable source, wrong package name, blocked build; read the install stage.
3. No update offered: mirror lag, old update source, or a pinned version.
4. Update reverts: the source latest tag lags or the profile pins an old version.

Read the log stage first. Download, extraction, build, and write failures have different causes; "failed" alone is not enough.

Mirrors are not universal. They accelerate download only; indexing and version discovery still depend on the source.

Security boundaries

Changing sources changes the trust chain.

1. Verify the source: align package name, owner, and version.
2. Use trusted mirrors: official registry or internal mirror; avoid unknown mirrors.
3. Authorize builds carefully: GitHub builds execute code; only allow trusted plugins.

More sources widen the attack surface. Use one when possible; verify that a mirror syncs unchanged.

Next steps

Separate layers, switch one at a time, read logs. For three install sources, read Where to install DeepSeek Harness plugins. For local directories, read How to install a local plugin directory. For market counts, read How many DeepSeek Harness plugins are there.

Sources: DSH Plugin Hub 2.2.5 screenshot index, dsh CLI README, DeepSeek Harness docs - Packaging plugins