Plugin Markets & Managers

Smart-DSH-Market

wsifan31-bit/Smart-DSH-Market · ★ 2

wsifan31-bit

A verified DSH plugin marketplace with project-stage-aware recommendations: understands which stage your project is in and tells you why you should install a plugin.

License
MIT
Added
2026-08-16
Maintenance
active
Install kind
github
Manifest details
Manifest status
Declared
Manifest path
package.json#dsh
Manifest checked
2026-08-19
Lifecycle scripts
None found

Static manifest checks report declarations only; they are not compatibility or security review.

安装

dsh plugin --profile web add github:wsifan31-bit/Smart-DSH-Market

GitHub 源码安装:首次需按提示配置 allowBuilds 构建授权后重试

For install and environment setup, plus plugin development tutorials, see DSH community docs ↗

README

Source README · body: en · Read Chinese README

Table of contents
  1. Smart DSH Suite v2.0
  2. 🌟 Key Breakthroughs (v2.0)
  3. Quick Start
  4. Option A: 1-Click Fast Deployment (Recommended)
  5. Option B: Install via DSH CLI
  6. Launch & Run
  7. 3. Open the marketplace
  8. Installation modes
  9. Manual command install
  10. Guided-install Agent
  11. Installed plugin management
  12. Install location, Agent workspace, and conflict diagnostics
  13. How the Registry works
  14. Registry files
  15. Custom Registry
  16. Automated scans and PAT usage
  17. Security and validation
  18. Development
  19. License

Smart DSH Suite v2.0

Unified Dual-Engine Plugin Discovery (12,000+ Plugins), Project-Stage Intelligence, and 26px Nano HUD for DeepSeek Harness

Version Plugins Architecture License DSH Web & Desktop

简体中文 · English

An industrial-grade evolution and consolidation of YELEBAI/dsh-plugin-marketplace (MIT): keeping the rigorous upstream audit and sandbox installation pipelines, while merging dsh-plugin-smart-recommend and dynamically attaching the local DSH Desktop full cache to index over 12,435 plugins with a 26px Nano HUD dock.

🌟 Key Breakthroughs (v2.0)

  • 12,435+ Massive Catalog Index (Dual-Engine Discovery): Dynamically connects and normalizes local DSH Desktop cache (list-cache/dsh.json), breaking the 2,786-plugin historical ceiling to provide full-text real-time search across the entire community ecosystem.
  • Dual-Track Safety Architecture:
    • Verified Tier (2,786 plugins): Commit-pinned SHAs with zero-trust static audits; retains seamless 1-Click silent auto-install.
    • Community Tier (9,649 plugins): Automatically routed through guided Agent sandboxed installation (mode: 'guided'), preventing supply-chain attacks and untrusted lifecycle scripts from compromising your host system.
  • 26px Nano HUD Dock: Mounted seamlessly onto the conversation.input.dock slot, this ultra-lightweight 26px status bar inspects your local Git repo (branch, dirty status, commit velocity) and infers project lifecycle stages, offering context-aware plugin bubbles without obstructing conversation flow.
  • Project Lifecycle Inference: 6-step offline heuristic classifier (Architecture / Prototype / Implementation / Testing / Polish / Maintenance) with explainable MMR ranking and 3 intervention modes (Auto / Confirm / Manual).
  • Zero Cloud Uploads: 100% offline local-first scoring and stage analysis. No external LLM token fees or telemetry leaks.

Quick Start

Windows (Desktop & Web Profile Auto-Linking)

Double-click install.bat in the repository root, or run in PowerShell:

powershell -ExecutionPolicy Bypass -File scripts/install-desktop.ps1
Linux / macOS

Run in your terminal:

bash install.sh

Option B: Install via DSH CLI

dsh plugin --profile web add github:wsifan31-bit/smart-dsh-market
# Desktop profile also supported:
dsh plugin --profile desktop add github:wsifan31-bit/smart-dsh-market

Launch & Run

# Start Web client:
dsh --profile web

# Or launch DeepSeek Harness Desktop from your system applications / shortcut.

3. Open the marketplace

Go to Settings → Plugins → Plugin Marketplace.

The marketplace has three pages:

  • Plugin Marketplace — search, filter, sort, inspect validation details, and install plugins.
  • Installed Plugins — filter, check for updates, update, uninstall, enable, or disable plugins in the active Profile.
  • Management & diagnostics — manually install a command, choose plugin storage, and diagnose conflicts.

Installation modes

Mode When it is used Marketplace behavior
One-click install An exact GitHub commit or npm version passes every check Installs through the official DSH plugin command
Manual command install The user supplies an official DSH GitHub install command Parses it, pins a commit, validates the bundle and conflicts, then installs safely
Agent install A build approval, lifecycle script, extra configuration, or further verification is required Creates a DSH Agent session bound to Registry evidence
Installation guide The active Profile is incompatible, identity is uncertain, or no safe executable path exists Runs nothing and opens the author's instructions

Automatic installs always use an exact GitHub commit or npm version verified by the Registry. Mutable main, latest, and Release download URLs are never passed directly to the package manager.

Manual command install

Under Management & diagnostics → Manual command install, paste:

dsh plugin --profile web add github:owner/repo#ref

You may also enter only github:owner/repo#ref. The input is never passed to a shell. The marketplace accepts one GitHub command for the active Profile and rejects extra arguments, pipes, multiple commands, and unsafe refs. A tag, branch, or omitted ref is first resolved to an exact commit, after which the manifest, bundle patch, and conflicts are validated. Lifecycle scripts stay disabled. A successful install joins the Profile bundle stack and appears under Installed Plugins.

Guided-install Agent

Plugins that still require guided installation show Install with Agent. Installed plugins with a guided update show Update with Agent.

Every Agent task is pinned to:

  • the Registry-verified repository, package name, version, and unique commit;
  • the active Profile, bundle patch, and the scanner's classification reason;
  • the absolute path of the dedicated plugin-marketplace Agent workspace;
  • a security boundary that treats README files, issues, scripts, and dependencies as untrusted input;
  • acceptance checks for Profile dependencies, bundle layers, and enabled state.

Every guided task starts by loading the bundled install-dsh-plugin Skill. It selects the shortest safe route: use an exact commit with scripts disabled when complete runtime artifacts already exist; build in an isolated temporary checkout when artifacts are missing; or stop when a Release tarball lacks a trusted digest, identity differs, bundle/runtime files are absent, or conflicts exist. Its read-only inspector verifies Git HEAD, package identity, bundle patch, Host/Client entries, lifecycle scripts, and Bundle ID/Cordis service conflicts against the active Profile.

The Agent inspects the exact commit in read-only mode first. Before running installation, build, prepare, postinstall, or other third-party code, it must request approval through DSH's native approval layer. The marketplace never grants approval on the user's behalf. Updates preserve configuration, bundle order, and enabled state while retaining the previous exact source for rollback. If the Agent cannot prove the install source, package identity, Profile compatibility, or runtime artifacts, it stops and explains what evidence is missing.

After a successful install, the Agent's final response must include How to start, covering:

  1. which Profile should be used to start DSH;
  2. whether a restart is required;
  3. whether the plugin loads automatically with DSH;
  4. which configuration values are still required;
  5. the Web entry point or actual invocation method.

[!NOTE] Agents default to $DSH_HOME/marketplace/agent-workspace and never inherit the current or recent project workspace. Select an existing directory under Management & diagnostics → Agent install and update workspace to override it. After the Agent is created, close Settings to follow its progress and respond to approval requests.

Installed plugin management

Action Behavior
Update Checks the Registry and uses the corresponding automatic or guided update flow
Enable / disable Updates dsh.profile.bundles without removing dependencies; takes effect after restart
Uninstall Removes the plugin dependency and matching bundle from the active Profile
Restart DSH Waits for active plugin jobs, then restarts with the same arguments and Profile
Marketplace self-update Reads the version from this repository, then pins the install source to an exact commit

The package includes the built lib/ files and a Registry snapshot from the release. If the remote Registry is temporarily unavailable, the marketplace can continue using the bundled snapshot.

Install location, Agent workspace, and conflict diagnostics

By default, plugin entities are installed by pnpm directly into the current Profile's node_modules, and every pnpm job reuses the store the Profile is bound to, avoiding ERR_PNPM_UNEXPECTED_STORE.

The install-location panel can switch subsequent installs to a custom directory through DSH's directory picker:

  • plugins in a custom directory are linked to the Profile with a file: dependency, and their runtime entry is linked back into the Profile's node_modules;
  • missing Host peer dependencies (e.g. cordis → @deepseek-ai/cordis) are linked automatically;
  • switching directories only affects future installs; existing plugins stay in place and remain updateable and removable;
  • directories that contain a plugin not linked to the Profile are marked separately and get no Profile operations.

The Agent-workspace panel separately controls guided install and update sessions. The default directory is created automatically; a custom directory must already exist and be readable and writable. On first use, the marketplace registers it as a DSH Workspace and binds only future installer Agents to it. Existing Agent sessions and other project Workspaces are not moved or changed.

The conflict panel runs heuristic static diagnostics over enabled bundles: duplicate bundle ids and common Cordis service registration forms (ctx.provide(...), super(ctx, ...), ctx['x'] = ..., ctx.x = ...). Results are a pre-flight guard against startup crashes — JavaScript is not executed and false positives are possible (for example when an entry bundle inlines another plugin's code); install, update, and enable operations only block conflicts that are newly introduced.

How the Registry works

flowchart LR
    A["GitHub topic: dsh-plugin"] --> B["Incremental scan every two hours"]
    B --> C["Resolve default branch to a 40-character commit SHA"]
    C --> D["Statically validate manifests, patches, entries, and npm tarballs"]
    D -->|"Valid"| E["registry/plugins.json"]
    D -->|"Insufficient evidence"| F["Guided-install audit"]
    D -->|"Invalid structure"| G["registry/rejected.json"]
    E --> H["DSH Plugin Marketplace"]
    F --> H

The scanner never installs dependencies, executes third-party code, or evaluates !!js values in YAML. Temporary network failures preserve the last valid result instead of removing large numbers of entries from the marketplace.

Registry files

File Purpose
registry/plugins.json Verified plugins and install policies in the public v2 format
registry/discovery.json Categories and seven-day Star growth
registry/guided-audit.json Per-scan verification of every guided-install entry
registry/install-review.json Evidence for commands, Profiles, lifecycle scripts, and runtime artifacts
registry/rejected.json Structurally invalid candidates and rejection reasons
registry/state.json Incremental scan state and daily Star baselines
registry/schema.json JSON Schema for the core Registry

Unchanged GitHub sources already approved for automatic installation reuse their previous results. Guided entries and npm sources are rechecked every two hours. If a plugin later publishes a valid exact npm version, the next scan automatically promotes it to one-click installation.

Custom Registry

The default central Registry is:

https://raw.githubusercontent.com/YELEBAI/dsh-plugin-marketplace/main/registry/plugins.json

Override it with an environment variable:

$env:DSH_PLUGIN_REGISTRY_URL = 'https://raw.githubusercontent.com/OWNER/REPOSITORY/main/registry/plugins.json'
dsh --profile web

You may also set registryUrl in the plugin configuration. Remote content is cached in memory for 15 minutes and supports ETag. A refresh failure first uses the most recent valid response and then falls back to the bundled snapshot. Configure the cache and timeout with registryCacheMinutes and registryRequestTimeoutMs.

A custom Registry may omit discovery.json and guided-audit.json:

  • without discovery.json, search and installation still work, but entries use the “Other” category and report zero Star growth;
  • without guided-audit.json, the Agent still performs read-only verification against the exact commit in the core Registry, but scanner-provided audit context is unavailable.

Automated scans and PAT usage

The Registry Scan workflow runs at minute 17 every two hours and can also be started manually from GitHub Actions.

Scans prefer the read-only PAT stored in the REGISTRY_GITHUB_TOKEN Actions Secret and fall back to the repository-provided GITHUB_TOKEN. The PAT is used only for GitHub API reads and never for Registry commits; writes continue to use the credential provided by Actions checkout.

Add REGISTRY_GITHUB_TOKEN under Settings → Secrets and variables → Actions. Never place a token in a workflow, README, or commit.

[!TIP] Standard GitHub-hosted runners are generally free for public repositories. Private repositories consume the Actions minutes included in the account plan and may incur charges after the allowance is exhausted. See GitHub Actions billing.

Generate the Registry locally for the first time:

corepack enable
pnpm install
$env:GITHUB_TOKEN = gh auth token
pnpm registry:test
pnpm registry:scan
pnpm registry:audit

The scanner automatically partitions GitHub Search results beyond the 1,000-result limit and continues after rate-limit resets. Read limits are:

  • package.json: 256 KiB
  • bundle patch: 64 KiB
  • npm archive: 50 MiB
  • extracted npm content: 150 MiB

Security and validation

A candidate repository must meet these baseline requirements:

  • package.json is valid JSON with a valid lowercase npm package name and semantic version;
  • dsh.bundle.patch points to a safe repository-relative path;
  • a declared dsh.client uses the web platform and exports ./client;
  • the bundle patch is a valid YAML operation array;
  • the patch inserts at least one loader entry whose name equals the npm package name;
  • every published field and exact commit passes the Registry Schema.

The Registry never decides automatic installation from a single keyword. It cross-checks:

  • host/client entries and the optional dsh.marketplace declaration in package.json;
  • whether the Git tree contains the runtime artifacts for every declared entry;
  • whether the README provides dsh plugin --profile ... add github:...;
  • whether an old owner or repository alias in the README resolves to the same GitHub repository ID;
  • placeholders such as <profile>, your-profile, and my-profile, which are not treated as real Profile names;
  • Web client plugins, which map only to web, and host-only plugins, which default to headless and web;
  • pnpm options such as -w / --workspace-root, while still requiring DSH CLI's --profile;
  • preinstall, install, postinstall, and prepare lifecycle scripts;
  • conflicts between README Profiles and manifest declarations;
  • the Registry URL, SHA-512 integrity, package identity, bundle patch, and runtime entries of same-name, same-version npm releases;
  • whether an npm package contains preinstall / install / postinstall or a root-level binding.gyp.

Any GitHub source containing preinstall, install, postinstall, or prepare always requires build approval and remains guided; committed runtime artifacts do not suppress that lifecycle warning. An exact npm tarball does not execute prepare when installed as a dependency, so a release that contains all runtime artifacts and passes static validation may still be automatic.

An incorrect migration URL in a README is retained as audit information but does not block a complete, installable exact commit in the current repository. Missing or contradictory evidence keeps the plugin guided; the scanner never guesses its way to one-click installation.

Plugin authors may provide more explicit marketplace metadata in package.json:

{
  "dsh": {
    "marketplace": {
      "profiles": ["web"],
      "requiresBuildApproval": false,
      "requiresRestart": true,
      "manualSteps": false
    }
  }
}

The central Registry may also use policy/install-overrides.json to add Profile or installation metadata for manually reviewed repositories.

[!WARNING] Registry validation filters incorrect topics, ordinary repositories, and structurally incomplete pseudo-plugins. It cannot prove that third-party code is harmless. A plugin receives local process permissions after DSH restarts, so verify its source and read every approval request before installing it.

Development

Requirements: Node.js, pnpm, and an available DSH checkout. Builds use D:/DSH/deepseek-harness by default; set DSH_CHECKOUT to use another location.

pnpm install
pnpm registry:test
pnpm registry:discovery
pnpm discovery:test
pnpm profile:test
pnpm restart:test
pnpm self-update:test
pnpm guided-agent:test
pnpm build
pnpm verify
pnpm exec tsc --noEmit

Before a release, update the version, regenerate the Registry, rebuild lib/, commit the generated artifacts, and create a version tag.

[!NOTE] The marketplace Remote method is named marketplace/installPlugin. Do not rename it to marketplace/install: install is an internal lifecycle method of the DSH Remote namespace service and would conflict with the client API.

License

MIT © YELEBAI