[RFC] 插件市场与dsh profile 设计

[T-Auto]

本文只描述现在存在的问题与一个简单的接口来讨论解决方向，不要求官方必须采用。

1. 快速预览

官方桌面端的插件市场是生态里最权威可信的分发入口，但当前安装器把安装目标固定为正在运行的那个 profile，这意味着，对于必须自己实现profile才能获得预期功能的插件，他们将不被官方桌面端插件市场分发入口认可。

官方桌面端从市场安装时只能落进当前 profile 的设计在产品定位上确实是非常正确的，但 DeepSeek-Harness 采用多 profile 设计无疑是允许社区制作自建 profile 的插件。尽管考虑到多 profile 的插件管理可以轻易由第三方社区管理器实现，但是无法被用户量最大的官方桌面端的官方插件市场和官方插件管理器安装，对于那些必须拉起独立 profile 的插件是极大的打击。

本提案不是要求把desktop app变成一个多 profile 控制台软件，本提案请求补一个接口：让用户在安装时能看到并选择目标 profile —— 或是官方认为的任何更好的解决方案，目的是为那些在设计上必须拉起独立 profile 的插件提供官方桌面端插件市场的分发与下载可行性，从而避免这些插件被排挤出权威插件入口。

2. 背景与证据

2.1 现状：安装与管理都绑定"运行中的 profile"

@deepseek-ai/dsh-plugin-manager 注入 profileContext，并把 this.profile = ctx.profileContext 作为所有操作的落点（packages/boot/plugin-manager/src/index.ts:177,192,209）；安装、移除、列举、开关都写 this.profile.dir（同一文件 :281,303,478,536,543,666,716 等）。就现有代码看，安装操作没有暴露"目标 profile"入参：一次安装必然落在当前宿主的 profile 上。官方桌面端只有一个 profile：$DSH_HOME/profiles/desktop（apps/desktop/src/paths.ts:19），并且由 Electron 独占（同文件 :20 的 lock；CLI 侧另有 rejectElectronProfile 明确拒绝第三方 CLI 触碰它，apps/cli/src/args.ts:83-87）。

2.2 需要独立组合的插件，在市场上没有"归属"

有些插件天生不适合与宿主共用一份组合：

• 它们要改变整个宿主的安全与运行策略，比如沙箱模式、审批策略、会话存储根、模型适配默认值等，而不是只增加一个贡献点；
• 这类取值本来就随界面形态分叉 —— 终端形态与 GUI 形态对沙箱、审批、会话存储的期望不同）；
• 它们的组合层会按 bundle 层序覆盖宿主的行：profile 的 dsh.profile.bundles 是一个有序数组，新选中的 bundle 追加在末尾，后应用的 patch 按 id 覆盖先前的（plugin-manager 的 selectBundle；packages/boot/app-boot/src/profile.ts 的加载顺序）。以社区中一个终端前端插件为例，它的 bundle patch 会覆盖宿主未被官方 web bundle 覆盖的 8 行（system-prompt / llm-deepseek / agent-loop / session-telemetry-otel / plugin-package-inventory-deepseek / sandbox-policy / approval / session-persistence-jsonl）——影响面是整个宿主。

于是从官方市场安装这类插件，只剩三种结果：

1. 装进去不生效：它住进了不属于自己形态的 profile，用户以为装了，实际那个 profile 不是它该运行的宿主形态；
2. 让宿主为它让步：为了能在当前 profile 里工作，它必须覆盖宿主的组合（上一条的 8 行），宿主的安全/存储/模型配置被改写；
3. 被挤出权威入口：插件只能自建通道（自带 bootstrap，在 npm 侧自己跑 dsh plugin --profile X add），而官方安装器出于安全考虑不执行插件脚本，用户被推向手敲 CLI 或手改 profiles/*/package.json。对于相当多的用户，会认为未被收录于官方插件市场的插件是不被官方认可的。

2.3 反证：跨 profile 安装的能力已经存在

• dsh plugin --profile <name> add <pkg> 就是跨 profile 安装：目标 profile 不存在时由 initProfile 初始化（apps/cli/src/plugin.ts:40：PROFILE_TEMPLATES[profile]?.bundles ?? DEFAULT_PROFILE_BUNDLES），随后正常走 pnpm。
• 也就是说，本提案不要求任何新机制：只是把这条已有能力从 CLI 暴露到市场/安装器，并给插件一个声明该需求的位置。

3. 目标 / 非目标

目标

1. 根本目的： 让 “需要独立profile的插件" 拥有一条从官方市场出发的安装路径；从而在社区的认知中和其他插件平等存在，而非现在这样，本质被排挤出了权威入口
2. 目前想到的解决方案： 把 “装到哪个 profile" 的选择权交给用户或者社区插件开发者，以及提供可完全卸载的链路

非目标

• 不请求安装期执行插件脚本
• 不请求把 desktop profile 开放给第三方 CLI 或任意进程
• 不请求官方代为注册终端/全局命令
• 不要求官方必须采用本提案。

[argszero]

The diagnosis matches what the code does, and this is a distribution problem worth solving. I have spent several rounds building plugins that live exactly at the profile boundary, and there are three states a target-profile picker has to keep separate. All facts below are from the tree as it stands today or from reports linked here.

1. The capability exists, but its create path does not validate the target. dsh plugin --profile <name> add is indeed cross-profile (§2.3). The first-use initialisation it relies on is apps/cli/src/plugin.ts:40:

initProfile(dir, PROFILE_TEMPLATES[profile]?.bundles ?? DEFAULT_PROFILE_BUNDLES)

DEFAULT_PROFILE_BUNDLES is ['@deepseek-ai/dsh-base'] (packages/boot/app-boot/src/profile.ts:203), and PROFILE_TEMPLATES (:179-195) has entries for acp, web, headless, sdk, sdk-minimal only. Compare apps/cli/src/profile-boot.ts:110-113, which throws for an unknown profile name and prints the accepted list. So a marketplace picker that accepts a typed name would silently create a new, default-shaped profile on any typo, install into it, and report success — the user's plugin is now in a profile that is not the host shape they meant. If the picker enumerates existing profiles ($DSH_HOME/profiles/*) and routes any explicit "create new" through the validated path, the RFC's goal is met without introducing a new silent state.

2. "Installed" and "selected" are two different writes. Install writes the profile's package.json + node_modules. Selection writes the bundle list — packages/boot/plugin-manager/src/index.ts:732 (manifest.dsh.profile.bundles) and selectBundle. A marketplace flow that lands a bundle-shaped plugin in a profile has still not made it active, and order matters because bundles append and later patches win by row id — the RFC's §2.2 eight-row override is the visible consequence. A confirmation step therefore needs three lines, not one: the target profile, whether the package will also be selected there, and which rows its patch overrides. The patch is a shipped file (dsh.bundle.patch, usually ./cordis.patch.yml), so that preview is mechanically available before anything is committed; without it, §2.2 outcome 2 ("let the host make way") happens without the user ever seeing the eight rows they agreed to.

3. Two profile-local failure modes, both of which hit marketplace-installed plugins first.

• Peer resolution inside the profile. initProfile writes autoInstallPeers: false into the profile's pnpm-workspace.yaml (packages/boot/app-boot/src/profile.ts:233). Since 0.1.7 the half that implemented the fallback this setting assumed was retired, so a plugin installed into a profile whose declared peers live in a shared directory makes every child process of that profile fail ERR_MODULE_NOT_FOUND: Cannot find package '@deepseek-ai/cordis', while the main process keeps running off its in-memory resolution table (discussion [Bug] 0.1.7-rc.1 no longer heals $DSH_HOME/profiles/node_modules (0.1.6 did) — profiles with locally installed plugins break every child process: run_code and voice input die with "subprocess scope exited before its bootstrap consumed the launch request" #7635). So "install succeeded" has to mean "resolvable from the profile directory", not "pnpm exited 0" — we published @argszero/cordis-plugin-profile-fallback-advisor because that check was missing.
• An in-box package declared as a dependency. Inside a profile the linker is nodeLinker: hoisted, so a plugin that lists an in-box @deepseek-ai/dsh-* package in dependencies gets a second physical copy materialised in the profile; the package is then evaluated twice and the first tool call crashes (reading 'prepare') — discussion Duplicate in-box `@deepseek-ai/*` package in a profile silently breaks every tool call #8287. Profile-scoped installation is exactly what makes that second copy likely, and nothing surfaces it until a tool runs. A marketplace install path is the cheapest place to refuse or clearly warn on in-box packages in dependencies (they belong in peerDependencies, which is where the harness's own packages ask for them).

4. On the declaration in §3.2. If a plugin is to declare that it needs its own profile, the declaration has to be readable from the manifest without executing plugin code: the installer reads npm metadata before install, and §非目标 rules out install-time script execution. So it belongs in package.json beside dsh.bundle.patch, where the installer can display it, rather than in a runtime export — a runtime hook can only fail the profile after the fact, which is §2.2 outcome 1 (installed, does nothing) with extra steps.

None of this asks for a new mechanism; it is the three states a picker must distinguish. Both plugins named above are published on npm with public repositories, so if any of this is useful as evidence for the design, the measurements and their reproductions are there — happy to dig further into any of them.

[T-Auto]

还有一种破坏性更低的解法：

提供一个跳转和一个卡片接口，用户点击后可以把安装prompt发送到默认工作区，接下来使用dsh按照prompt的指导走正常npm流程安装