DSH plugin market: a 60-second pre-install check

Sixty seconds is roughly how long anyone is actually willing to spend before clicking Install; past that, most people just confirm. So this checklist holds only four things that fit in that window: permission scope, dependency count, build scripts and rollback cost (2.2.5 index). It does not ask you to read source; it asks you to move between the detail page, the install prompt and the source repository inside DSH Plugin Hub. If any of the four is unclear, do not install yet.

First 20 seconds: DSH plugin permission scope and dependency count

The first 20 seconds answer two questions: what does it need to touch, and how much does it pull in? These two decide the blast radius and are also the fastest things to see on a detail page.

1. Work backward from function: a UI-only plugin does not need network access, and a summarizer does not need whole-disk file access.
2. Find the capability declaration in the detail page or install prompt, compare it with the function, and ask the source repository if it is unclear.
3. Check the dependency count, then scan for unfamiliar packages or scopes unrelated to the function.
4. When the dependency tree is clearly larger than peers, open the repository's dependency list instead of trusting the number alone.

Read permissions and dependencies together: broad permissions with few dependencies may mean built-in capability, while many dependencies with narrow permissions may only widen the supply chain. The two risks do not cancel each other.

Middle 20 seconds: DSH plugin build scripts, platform and version

The middle 20 seconds answer whether code runs during installation and whether the result can run at all. Build scripts decide install-time risk; platform and version decide post-install usability.

1. During a source install, watch for a prompt allowing build scripts and only approve repositories whose source you can verify.
2. If unsure, refuse the script and use the npm prebuilt release; refusal usually just means it will not install, which is safer than running an unknown script.
3. Check declared platform limits: whether Windows, macOS and Linux are all supported and whether any native module is required.
4. Check version compatibility: whether the Harness range the plugin requires includes your current version, and do not cross a major version casually.
5. If platform or version does not match, confirm in the detail page or repository instead of hoping it works after install.

Build scripts are the one step that executes before you ever use the plugin. The risk sits at the moment you click Confirm, not at runtime, so this is the one place to be conservative.

Last 20 seconds: leaving a rollback point in dsh plugin market

The last 20 seconds do one thing: prepare how to get out before you get in. A rollback point is not a system backup; it is three artifacts that let you return to the previous state.

1. Record the version of a same-named plugin in the installed list, or record "not installed" if there is none.
2. Back up the current profile's package.json, which holds both the dependency list and the load list.
3. Record the key configuration related to this plugin, especially anything you edited by hand.
4. Locate the uninstall entry: the Uninstall action at the end of an installed row, which confirms before removing.
5. Put all three somewhere you can find later instead of keeping them in your head.

Of version, manifest and configuration, the manifest is the most overlooked and the most useful: it tells you what should have been installed and what should load at startup. A version number alone leaves restoration to guesswork.

Minimal fallback when you have no backup

1. Check the installed list's version record and confirm whether a same-named plugin existed.
2. Check the profile's package.json backup or version control history.
3. If neither exists, uninstall the current version and reinstall the last known good version.
4. Restart and verify the entry, then make a backup this time.

The install confirmation dialog: DSH Plugin Hub's last gate

The confirmation dialog is the final chance to see the source clearly, listing the plugin name, source repository and install command. Before clicking Confirm, all three should match what you concluded earlier.

1. Verify the plugin name is the one you chose, watching for same-name entries from different authors.
2. Verify the source repository matches the detail page and the repository you inspected.
3. Read the command about to run and confirm there is no extra global install or script flag.
4. Click Confirm only when all three line up; otherwise cancel and recheck the detail page.
5. After confirming, do not click repeatedly — wait for progress, and check notifications first if it fails.

The dialog is not ceremony: it puts "what you think you are installing" and "what will actually run" on one screen. Everything decided in the previous 60 seconds gets one final review here.

Three minutes after install: DeepSeek Harness verification and rollback rehearsal

Post-install verification has two steps: prove it works, then prove you know how to remove it. Only after both is the install closed out.

1. Restart DeepSeek Harness and open the menu, command or panel the plugin provides.
2. Invoke the capability once, confirming that more than a UI element appeared.
3. Check the installed list for version, source label and state, then check system logs for activation errors.
4. Open the uninstall confirmation, read what it will remove, and click Cancel — a rollback rehearsal without changing anything.
5. Record the version, source and verification result in your environment notes for the next update.

Change one variable at a time during verification: restart, then check the entry, then read logs. If all three signals pass, the install can stay; if any fails, follow how to read notifications when an install fails instead of uninstalling and reinstalling blindly.

Three cases where you should stop verifying

1. The host crashes repeatedly or cannot enter a session after the plugin starts.
2. The entry appears but throws a permission or path error on every call.
3. System logs show continuous activation failures.

Uninstall first and return to a known-good state before investigating. The permission and dependency judgments here also line up with how to install plugins safely.