一句话定位

这是 dsh-market 仓库自带的 e2e 测试夹具，不是面向普通用户安装的插件。它故意与 fixture-a 声明同一个加载器入口 ID，用来在端到端测试里验证 install 流程是否会拦截冲突。

核心能力

• 在 cordis.patch.yml 中声明 id: dshm-fixture-a，与 fixture-a 抢占同一个加载器入口
• 通过宿主注入 webServer，在 $DSH_HOME/e2e-dshm-e2e-fixture-clash.alive 写入时间戳标记文件
• 在插件卸载时删除标记文件，用来证明生命周期 dispose 真的发生过
• 作为 e2e 套件（tests/web/install.e2e.ts）的对抗输入，验证 install 接口会拒绝 ID 冲突

技术实现

• 语言: JavaScript（ESM，type: module）
• 关键依赖: 仅使用 node:fs 与 node:path 内置模块
• 架构模式: 通过 package.json#dsh.bundle.patch 把 cordis.patch.yml 注入到 cordis 加载栈，模块本身以 apply(ctx) 形式挂到宿主
• 入口文件: tests/web/fixtures/fixture-clash/index.js

适用场景

仅在 tests/web/install.e2e.ts 第 127 行的"refuses an install that would duplicate a loader entry id (#122)"用例里被使用，普通用户没有理由直接安装它；它存在的目的是制造一个 install 冲突样本来验证防护逻辑，而不是提供任何业务功能。

前置依赖与兼容性

安装方式

dsh plugin --profile web add github:dsh-market/dsh-market/tests/web/fixtures/fixture-clash

配置项

本插件无需额外配置。

常见问题

Q: 这个插件是给普通用户装的吗？

A: 不是。它是 dsh-market 仓库 tests/web/fixtures/ 下的 e2e 夹具，只在 install.e2e.ts 之类的测试里被使用，不提供任何业务功能。

Q: 它和 fixture-a 是什么关系？

A: 二者故意把 id 字段都声明成 dshm-fixture-a，而 cordis 不允许同一个加载器入口下挂两个实体；只要 install 流程放行这个夹具，宿主下次启动就会拒绝整个 bundle 树。

Q: 把它装进真实 profile 会发生什么？

A: tests/web/install.e2e.ts:127 用例期望 install 返回非 200 状态码，且 installed 列表里不会出现 dshm-e2e-fixture-clash；已经装好的 fixture-a 必须保持 live，证明冲突被拦在了写入 profile 之前。

Q: 标记文件有什么用？

A: 它是 fixture 自证的存活探针：仅当 cordis 解析包、加载模块、跑完 apply()、并满足 webServer 注入时，文件才会出现；卸载时由 ctx.effect 的 dispose 回调负责删除，因此能区分"插件在岗"和"插件已死"。

Q: 文件会一直留在磁盘上吗？

A: 不会。$DSH_HOME/e2e-dshm-e2e-fixture-clash.alive 由 effect 回调在 dispose 时通过 rmSync(..., { force: true }) 删除，插件一旦卸载就清掉。

Q: 它的代码依赖宿主有什么？

A: 只通过 ctx.inject(['webServer'], ...) 拿宿主提供的 webServer 服务，依赖的正是 issue #122 修复前会让 cordis 拒启的同一种 bundle 注入路径。

上手难度

入门 — 因为它本身不是供人配置的插件，使用者只需要把它放进 e2e fixture 列表，无需理解任何业务参数。

已知问题与限制

• 本身就是"已知问题"：fixture-clash 的存在意义就是在 install 路径里制造一个 ID 冲突样本。cordis.patch.yml:1 注释明确说明："cordis refuses to boot a tree with two entries under one id, so an install that lets this through bricks the next start"
• 被 tests/web/install.e2e.ts:127 显式断言拒绝：install 路由必须返回非 200，否则该 e2e 用例失败（对应 issue #122）
• 不应出现在真实用户的 profile 里：该夹具只服务于 dsh-market 自身的回归测试，对外没有功能价值
• private: true：package.json 标了 private，发布链路会拦截它，仅在 monorepo 内部流转

dsh-market

English | 中文

dsh-market is independent of any particular client — it works in any host that speaks the standard DeepSeek Harness protocol. We're currently in discussions with anywhere-labs/deepseek-harness-desktop about future cooperation, and we'll share updates here as they happen. Use dsh-desktop or deepseek-harness-desktop — both ship with this plugin market built in — or another excellent third-party client.

The plugin market inside DeepSeek Harness. Open Settings → Plugin Market → browse, search, one-click install.

One-click themes: install, switch live, no restart.

Install

dsh plugin --profile web add dshmarket

Restart dsh web, then open Settings → Plugin Market.

Requires dsh web 0.1.0-rc.6 or newer. On an older host the market disables itself and says so in the browser console rather than rendering against primitives that are not there — if the Plugin Market entry never appears, that is usually why. Worth checking when a desktop build bundles its own dsh: it may be older than the one npm would give you (#139).

What you get

• Browse & search the full community catalog (1550+ plugins, growing daily) — category filters, star counts, top/new sorting, bilingual descriptions that follow your UI language

• Screenshots — AppStore-style screenshots, auto-carousel when there's more than one, click to preview full-size: author-curated shots show right on the card (zero extra requests); plugins without curated shots fall back to automatic README extraction once you open the install dialog. Images load from GitHub hosting only

• Themes — a dedicated tab for community themes and skins: install → active immediately, switch with one click (themes are mutually exclusive, your choice survives restarts), uninstall to revert

• One-click install — confirm the source, watch live progress; most plugins go live after a page refresh, no restart

• Backup & restore — export your profile's plugin list and configuration as readable JSON, import it on another machine, store it on WebDAV with daily auto-backup, or sync through a private GitHub Gist; restores merge (plugins installed after the backup are kept), validate before writing, and roll back on failure

• Updates — per-plugin update checks (npm version or pinned commit vs HEAD), one-click update, or update everything at once; the market updates itself the same way

• Uninstall — two-step confirm; plugins installed this session are removed live

• Hot disable / enable — toggles write - id: … + disabled: true|false into the profile's cordis.patch.yml (the official patch layer, mechanism ported from dsh-plugin-hub): DSH's HMR re-composes within ~1s, no restart, and the loader re-applies the choice on every boot; hand-edited patch rows show as badges, host-infrastructure plugins are protected from toggling, and a malformed patch file is never made worse

• Restart when needed — changes that cannot hot-load show a one-click restart beside the pending-change banner; the action is restricted to same-origin loopback requests

• Zero jargon — if a component is missing (pnpm), the market detects it and offers a one-click automatic setup

• Log export — one click produces a sanitized plain-text log for bug reports (home paths and credential shapes are masked; nothing is ever sent anywhere). The market's version sits next to the page heading, so a screenshot of a problem already carries it

• Settings card — on dsh 0.1.0-rc.7 and newer the market manages itself from Settings → Plugins → Plugin configuration, next to every other plugin: see the running version, pick a release channel (stable, or beta to try builds still being verified — the market only, never your other plugins; a third dev channel appears once developer mode is switched on, and carries builds published straight off a branch), update, or remove the market — with an opt-in cleanup that also drops the disable rows it wrote, so plugins it switched off start running again rather than staying off with no UI left to switch them back on

• Diagnostics — the plugin load order and conflict surface, one page: bundle stack with official/community badges, duplicate loader entries, dependency version mismatches, multi-version core packages, overrides and invalid config entries. Plain-language terms, problem blocks highlighted, everything collapsible

• Load order — drag community bundles into the order you want, or take the suggested one derived from the plugins' own before/after rules. Nothing is written until a trial composition passes, and the panel tells you what the new order would change (overrides, invalid or duplicate entries) before you apply it

• AI fix — one click copies a diagnostics-driven fix prompt (errors/warnings/order conflicts + conservative scope instructions) to the clipboard; you paste it into a new conversation and decide whether to send

Speed

Installs prefer npm tarballs over full-repo GitHub downloads whenever a plugin publishes to npm (registry-verified against the repo to prevent name squatting). Registry installs are typically seconds; GitHub-only plugins depend on your connection to GitHub.

Security

• Installs are restricted to sources listed in the curated awesome-dsh-plugin registry — anything else is rejected

• Build scripts stay blocked by default (pnpm ≥10); allowing one is your explicit per-package choice

• Terminal/CLI-surface plugins are flagged before you install them into the web profile

• The install endpoint accepts same-origin POST only; the market never phones home

• Backups can contain credentials from your profile config — the UI warns before export and upload; WebDAV sync is https-only, refuses private-network targets, and never stores your password in the browser

• The restart endpoint additionally requires a direct loopback client (forwarded requests are rejected) and relaunches the exact DSH entry, arguments, environment, and working directory

• One-click restart launches a detached replacement. When this host is systemd's own service process the button is hidden automatically — the market would otherwise kill the takeover process along with the unit's cgroup and the service would not come back. The pending-change notice stays visible and says so. Detection requires both a systemd marker AND being the unit's main process, because INVOCATION_ID is inherited by every descendant of a unit (an ordinary terminal included) and hiding the button for those would be the worse bug. pm2 and launchd are not detected, so those deployments need the explicit setting below. Either flip Allow restart off in Settings → Plugins → Plugin configuration, or write it into the profile patch — where it has to sit under config:, because the loader passes only that sub-object to a plugin and a top-level allowRestart: is silently ignored (#227 by @Fantasymax):

  - id: dsh-market
    name: dshmarket
    config:
      allowRestart: false   # NOT at the top level beside `name:`
  

  GET /dsh-market/status reports "restart": false once it has taken effect.

• For terminal-attached launches, the detached replacement keeps running after the original terminal closes

• Listing ≠ endorsement: plugins are third-party code, install sources you trust

Submit your plugin

This repo is the market app, not the catalog. The plugin list comes from the curated awesome-dsh-plugin registry — to get your plugin listed in the market, open a PR there (one entry in the list; the site and this market pick it up automatically, usually within a day). Please don't PR plugin entries against this repo.

Roadmap & feedback

• Bugs go in issues — attaching the market's "Export log" makes diagnosis roughly ten times faster
• Feature ideas go on the Roadmap. Issues are kept for things that are broken, so a proposal filed as an issue gets moved there and closed; the discussion stays where you wrote it either way
• Every roadmap item welcomes community PRs — say so on the item before starting, so two people don't build it twice

Data source

Fetched live on every open from awesome-dsh-plugin.com/plugins.json — curated entries, npm mapping, and star counts refreshed daily by CI, with no stale cache behind it. A failure reports the actual reason and elapsed time, with a Retry button.

There is deliberately no bundled snapshot to fall back on: for a catalog that grows daily, a stale answer is not a degraded one but a wrong one — a plugin published this morning would read as "does not exist".

If that host is unreachable from your network, point the market at a mirror instead. Set DSHM_REGISTRY_URL in the environment dsh runs in, to anything serving the same plugins.json shape:

DSHM_REGISTRY_URL=https://your-mirror.example/plugins.json dsh web

Friends

DSH Desktop (dataelement)

dsh-desktop — a desktop app for DeepSeek Harness: run and manage a local Harness without installing Node.js yourself. Ships with this plugin market preset as the default. dshdesktop.com

DeepSeek Harness Desktop (hairyf)

deepseek-harness-desktop — a native desktop app for DeepSeek Harness built with Tauri (Rust + Web): one-click local install and launch with no Node.js setup required. On first run it offers to install this plugin market as a recommended preset.

DSH Get

DSH Get — a searchable web directory for discovering DeepSeek Harness plugins: category filters, bilingual descriptions, install commands and per-plugin detail pages. Its normalized catalog snapshot is public at bobby-sheng/dshget-data.

modlens

modlens — the first vision plugin for DeepSeek Harness: bolts visual understanding onto text-only models like DeepSeek and GLM. Paste an image, get structured JSON evidence back — OCR, layout, semantics. Available right in this market:

dsh plugin --profile web add @liustack/modlens

License

MIT · dshmarket.com