feat: add DSH plugin marketplace and shared MCP

GoodBuddy could share Skills across runtimes, but custom MCP remained limited and DeepSeek Harness could not manage third-party extensions. The app now provides a default-off DSH npm marketplace with managed installation, configuration, failure isolation, and packaged npm support, while assigned custom MCP is available to managed OpenCode, Continue Agent, and DeepSeek Harness in Execute.

Third-party DSH install scripts, initialization, and tools run with the current user's permissions. Ask remains read-only at dispatch, and turning off the marketplace hides management without disabling installed plugins.

Release note: 新增默认关闭的 DSH 插件市场,并让自定义 MCP 可分配给 OpenCode、Continue 和 DeepSeek Harness;安装第三方插件前会明确提示当前用户权限边界。
This commit is contained in:
mesalogo
2026-08-16 11:47:11 +08:00
parent 9e6f664e06
commit ff61b5f81d
67 changed files with 9337 additions and 443 deletions
+41
View File
@@ -90,6 +90,47 @@ Keep Electron security boundaries intact:
- Do not show the same event both inline and as an application notification.
Preserve user input and actionable error context when an operation fails.
## Commit Messages and Release Notes
Release notes are derived in part from commit history, so commits for
user-visible changes must record product intent rather than only the
implementation mechanism.
- Classify the commit by the user-visible behavior. Use `feat` only for a
capability users did not previously have. Use `fix` when restoring intended
behavior, removing inconsistency, or making two existing entry points reflect
the same underlying setting, even if the implementation adds new
synchronization logic.
- Keep the subject concise, then add a commit body for non-trivial user-visible
changes. State the previous user-facing problem, the resulting behavior, and
the affected surface or workflow. Include permissions, migration,
compatibility, cost, data, preview-status, or other usage caveats when
relevant.
- Describe the user outcome precisely. Do not promote an internal refactor,
synchronization mechanism, schema change, or newly added implementation code
to a product feature unless it creates a genuinely new user capability.
- When a change is release-note worthy, include a short `Release note:` line in
the commit body written in user-facing language. Prefer a concrete usage
scenario and benefit over technical implementation terminology.
- Treat commit messages as evidence, not as the sole source of truth. Before
drafting release notes, verify the diff and resulting behavior, correct any
inaccurate `feat` or `fix` classification, and include actionable usage
notes where the change affects defaults, synchronized settings, permissions,
resource usage, compatibility, or user data.
Example:
```text
fix: unify project settings across channel entry points
The top-left project settings and the project settings shown under messaging
channels could present or save inconsistent values. They now edit the same
project configuration for the project name, description, Runtime, and work
mode.
Release note: 修复左上角项目设置与消息通道项目设置不一致的问题;现在从任一入口修改后,另一处会同步显示相同配置。
```
## Release Packaging
- `.github/workflows/packages.yml` is the canonical cross-platform packaging