Back to home@a1141171521

dsh-plugin-conflict-guard

1.安装新插件前检测是否和现有插件存在冲突 2.检测已安装的插件是否存在冲突

Stars
2
Language
JavaScript
Created
Aug 20, 2026
Updated
Aug 20, 2026
GitHub repo

Introduction

dsh-plugin-conflict-guard

🛡️ DSH (DeepSeek Harness) 动态插件:安装前检测插件间功能冲突,由用户决定是否继续安装。

在 DSH 中安装新插件(cordis_define)或激活插件(cordis_run)之前,本插件会静态分析新插件声明的能力,与已安装插件登记表当前实时运行时对比,发现重复占用时弹出询问窗口,点名冲突双方,由你决定"继续安装"或"取消安装"。

语言: English | 中文

中文

为什么需要它

DSH 插件(Cordis 动态插件)可以提供服务、注册工具、注入槽位、注册命令/技能/设置命名空间等能力。当多个插件修改同一个功能时,会导致功能冲突甚至不可用。本插件把"冲突检测"提前到安装动作发生之前,而不是装完才发现问题。

功能

  • 安装前检测:在 tools/pre-execute 瀑布流中拦截 cordis_define / cordis_run,在任何插件被创建或激活之前介入。
  • 能力声明提取:静态分析新插件源码,提取其声明的能力:
    • 服务(ctx.provide)、工具(harness.registerTool 等)、槽位(slots.inject / slots.register
    • 设置命名空间(settings.register)、命令(commands.register)、技能(skills.register
    • 语言包(locale.register)、主题(theme.overrideTokens / theme.register
  • 双重对比
    • 登记表:通过 cordis/dynamic-package / cordis/dynamic-retract 事件跟踪已安装插件及其声明,冲突来源显示为 插件「名字」
    • 实时运行时:叠加 tools.schemas()commands.list()settings.describe()skills.list() 等实时快照,冲突来源显示为 现有运行时/其他插件
  • 用户决定:发现冲突时通过 userQuestions.ask() 弹出询问(普通问答 UI,不经过审批服务),列出每处冲突及占用方;选"取消安装"则拒绝该次安装(deny),选"继续安装"才放行。
  • 冲突分级:服务/工具/设置/命令/技能为 hard(可能直接导致不可用);槽位/主题/语言包为 soft(可能共存);事件监听不拦截(多监听器是正常且可叠加的)。
  • 设置页设置 → 插件 → 插件冲突检测 页签,列出已安装插件的能力声明 chips,并可"立即扫描全部插件冲突"。
  • 自我保护:不拦截自身的更新;对守卫启用前已存在的插件(无声明记录)安全放行;所有守卫错误均 fail-open(放行并记日志),绝不误伤正常安装。

安装

在 DSH Web GUI 会话中,作为动态插件加载:

  1. cordis_defineplugin: { kind: 'new', idPrefix: 'conf' }code.hostsrc/host.js 的内容,code.clientsrc/client.js 的内容(均为纯 JS 函数体,无 import/JSX/TS)。
  2. cordis_run:激活返回的 pluginId / packageId,在 Run 卡片上允许授权。
  3. 浏览器端激活后,设置 → 插件 → 插件冲突检测 即可使用。

已知限制(诚实说明)

  • 静态分析:能力提取基于源码正则,属于尽力而为;动态注册(运行期才决定名字)无法覆盖,可能有误报——因此最终决定权始终交给用户。
  • 登记表是内存态:守卫自身更新重启后,之前已运行插件的声明记录会丢失(退化为"无声明",新安装的插件不受影响)。
  • 不持久化:进程重启后登记表清空。
  • 对守卫启用前安装的插件没有声明记录,只能靠实时注册表兜底。

测试与验证

  1. 安装插件 A(声明服务 demo-feature)→ 无冲突,静默放行。
  2. 尝试安装插件 B(声明同一服务)→ 弹出询问,点名 插件「A」;选"取消安装"则定义被拒绝。
  3. 设置页 → "立即扫描全部插件冲突":列出已安装插件之间的重复声明。
  4. ⚠️ 实测发现:两个插件真实注册同名服务时,运行会直接失败(service already registered)——正是本守卫要拦截的冲突类型。

License

MIT


English

Why

DSH plugins (Cordis dynamic plugins) can provide services, register tools, inject slots, register commands/skills/settings namespaces, and more. When multiple plugins touch the same capability, features can conflict or silently break. This plugin moves conflict detection before the install action happens, instead of discovering problems after installation.

Features

  • Pre-install gate: intercepts cordis_define / cordis_run in the tools/pre-execute waterfall, before any plugin is created or activated.
  • Claim extraction: statically analyzes plugin source for declared capabilities (services, tools, slots, settings, commands, skills, locales, themes).
  • Two-layer comparison: a recorded registry (fed by cordis/dynamic-package / cordis/dynamic-retract) plus live runtime snapshots (tools.schemas(), commands.list(), settings.describe(), skills.list()).
  • User decides: on conflict, asks via userQuestions.ask() (plain question UI, independent of the approval service), listing each conflict and its owner; "cancel" denies the install, "continue" allows it.
  • Severity tiers: services/tools/settings/commands/skills = hard; slots/themes/locales = soft; event listeners never block.
  • Settings page: Settings → Plugins → Plugin Conflict Detection tab with installed-plugin claims and a one-click full scan.
  • Self-protection: never gates its own updates; unknown pre-existing plugins pass; all guard errors fail open (log + allow).

Install

Load as a dynamic plugin in a DSH Web session:

  1. cordis_define with plugin: { kind: 'new', idPrefix: 'conf' }; code.host = contents of src/host.js, code.client = contents of src/client.js.
  2. cordis_run the returned pluginId / packageId and approve on the Run card.
  3. After the browser half activates, use Settings → Plugins → Plugin Conflict Detection.

Known limitations

  • Static analysis is best-effort regex-based; dynamic registration is not covered and false positives are possible — the final decision always belongs to the user.
  • The registry is in-memory: updating the guard itself loses claims recorded before the restart (new installs are unaffected).
  • No persistence across process restarts.

License

MIT