Deekseep Harness需要一个包（插件）管理器来避免冲突

[kirk0830]

插件装多了就变得乱七八糟了，甚至可能需要能设置hook的先后顺序才行

[Mieluoxxx]

我们需要设计一个类似于cargo的包管理器，用于解决依赖的问题

[shifenhutu]

https://github.com/dsh-market/dsh-market 看看这个是否 符合需求

[Mieluoxxx]

1. 社区遇到的问题

① 同 id / 同类型插件冲突，装完就崩

• 两个插件同 id 导致启动错误：#1479 两个不同插件拥有同一个id，导致dsh web启动错误
• 同类插件解析到重复的 @deepseek-ai/dsh-tools 副本，工具调度器崩溃：#1337
• dsh plugin add 把同一个 entry id 重复插入导致 boot 崩溃：#1404
• 这类问题多到被合并去重：#1923 同类问题已有讨论

② 启动即崩、且没有诊断

• 一个悬空引用拖垮整个 profile，报错不指明是哪一行：#1197、#880
• 社区已把这批问题汇总成给官方的通告：#1496 Advisory: the plugin-install path needs guardrails（结论：安装路径 "fragile by install"）

③ 标准缺失：没有 Manifest、没有规范、没有单一 schema

• Manifest 缺失：版本管理、包名规范、依赖声明、权限声明全都没有：#777 DSH Plugin 缺少Manifest设计
• 没有官方模板，作者只能反推 turtle-ui 示例：#1629 RFC: official plugin scaffold
• 生态各自定义 dsh 字段，市场/工具各写各的，已经出现多套互不兼容的约定（#2276 评论区已有人预警）

④ 官方机制的现状

官方保证"同一 service 在同一隔离域只能有一个 provider，重复提供会报错"——这是运行时保护，不是装前诊断。用户装两个同类型插件时，往往是启动那一刻才看到错误，然后手动二选一、改源码或放弃。

[Mieluoxxx]

2. 为什么需要「插件开发标准 + 静态检查器」

两个必须配套，缺一不可：

• 标准是检查器的依据：检查器要能判断"谁和谁冲突"，前提是插件声明了自己"提供什么、替代谁、和谁互斥"。没有标准，检查器只能靠猜（特征扫描），而特征扫描看的是文件形态、不是作者意图（#2269 的 install.ps1 劫持案例就是教训）。
• 检查器是标准的执行者：标准写进文档没人看，写成 schema 由工具校验才有人遵守。装前/发布前跑一次检查，把"运行时才炸"提前到"装前发现"。

三个层面的必要性：

层面	现状问题	标准和检查器解决什么
时间成本	装一个崩一个，排障靠猜，"能加载≠能用"（#1693）	装前报告"哪个插件和哪个插件冲突、怎么解决"
生态成本	多套 dsh 字段约定、多个市场/工具无法互通（#2276）	单一权威 JSON Schema，市场/CLI/检查器统一消费
信任成本	用户"不太敢装别人开发的插件"（#1115 评论区）	声明透明化：依赖、权限、冲突关系可查

这正是 Cargo / Nix / K8s 共同的做法：声明（Cargo.toml / overlay / spec）+ 静态检查（cargo 解析 / 校验 / admission controller）+ 准入控制三位一体。DSH 缺的就是这三位一体里的后两位。

[Mieluoxxx]

3. 一个可行方案 demo

3.1 插件声明标准：dsh.plugin 字段（挂载到官方已有 dsh.* 命名空间）

{
  "name": "dsh-shell-remote",
  "version": "0.1.0",
  "dsh": {
    "plugin": {
      "schema": 1,
      "provides": [{ "kind": "service", "name": "shell" }],
      "consumes": [{ "kind": "service", "name": "fs", "optional": false }],
      "conflicts": [{ "with": "dsh-bash-sandbox", "reason": "Both provide ctx.shell in the same realm." }],
      "replaces": ["dsh-shell-local"]
    }
  }
}

含义：占用 ctx.shell 槽位（provider）；依赖 fs；与 sandbox 互斥；可替代 local 实现。老插件不声明 → 标记 unverified，不误报。

3.2 检查器 demo：零依赖脚本，直接可跑

node demo-conflict-check.mjs <profile-dir>

检查规则：

• R1 同一 service + 同一 realm 多个 provider → fail
• R2 conflicts 双方同时存在 → fail
• R3 replaces 目标同时激活（未解析）→ fail（解析器应在挂载前禁用被替代方）
• R5 无声明 → warn（unverified）

// demo-conflict-check.mjs（核心逻辑，完整可运行版约 100 行）
import { readFileSync, readdirSync, existsSync } from 'node:fs'
import { join } from 'node:path'

const profileDir = process.argv[2] || '.'
const plugins = []

for (const name of readdirSync(profileDir)) {
  const pkgPath = join(profileDir, name, 'package.json')
  if (!existsSync(pkgPath)) continue
  let pkg
  try { pkg = JSON.parse(readFileSync(pkgPath, 'utf8')) } catch { continue }
  plugins.push({ name, pkg, declared: Boolean(pkg.dsh?.plugin) })
}

const checks = []

// R1: 同一 service + 同一 realm 多个 provider
const providers = new Map()
for (const p of plugins) {
  if (!p.declared) continue
  for (const prov of p.pkg.dsh.plugin.provides ?? []) {
    const realm = prov.realm ?? p.pkg.dsh.plugin.realm ?? 'default'
    const key = `${prov.name}@${realm}`
    if (!providers.has(key)) providers.set(key, [])
    providers.get(key).push(p.name)
  }
}
for (const [key, list] of providers) {
  if (list.length > 1) checks.push({
    name: `conflict.service.${key}`, status: 'fail',
    detail: `${list.join(' 与 ')} 都提供 service "${key}"。建议：只启用一个，或用 group+isolate 分到不同 realm。`,
  })
}

// R3: replaces 未解析（被替代方同时激活）
for (const p of plugins) {
  if (!p.declared) continue
  for (const t of p.pkg.dsh.plugin.replaces ?? []) {
    if (plugins.some((q) => q.name === t)) checks.push({
      name: `conflict.replaces.${p.name}`, status: 'fail',
      detail: `${p.name} 声明替代 ${t}，但两者同时激活。解析器应在挂载前禁用 ${t}。`,
    })
  }
}

// R5: 无声明 → unverified
for (const p of plugins) {
  if (!p.declared) checks.push({
    name: `unverified.${p.name}`, status: 'warn',
    detail: `${p.name} 没有 dsh.plugin 声明，无法静态检查（unverified，不误报）。`,
  })
}

const summary = { pass: 0, warn: 0, fail: 0 }
for (const c of checks) summary[c.status]++
const failed = summary.fail > 0
console.log(JSON.stringify({
  schema: 'dsh-doctor/v1', tool: 'demo-conflict-check', profile: profileDir,
  exitCode: failed ? 1 : 0, summary, ok: !failed, checks,
}, null, 2))
process.exitCode = failed ? 1 : 0

对三个 fixture 插件（dsh-shell-local 提供 shell、dsh-shell-remote 提供 shell 且 replaces local、dsh-tool-a 无声明）的实际运行输出：

{
  "schema": "dsh-doctor/v1",
  "tool": "demo-conflict-check",
  "profile": "demo-fixtures/profile",
  "exitCode": 1,
  "summary": { "pass": 0, "warn": 1, "fail": 2 },
  "ok": false,
  "checks": [
    { "name": "conflict.service.shell@default", "status": "fail",
      "detail": "dsh-shell-local 与 dsh-shell-remote 都提供 service \"shell@default\"。建议：只启用一个，或用 group+isolate 分到不同 realm。" },
    { "name": "conflict.replaces.dsh-shell-remote", "status": "fail",
      "detail": "dsh-shell-remote 声明替代 dsh-shell-local，但两者同时激活。解析器应在挂载前禁用 dsh-shell-local。" },
    { "name": "unverified.dsh-tool-a", "status": "warn",
      "detail": "dsh-tool-a 没有 dsh.plugin 声明，无法静态检查（unverified，不误报）。" }
  ]
}

输出格式与社区已统一的 dsh-doctor/v1 envelope 对齐（#1814 三方已对齐），退出码 0/1 可直接接 CI。

[Mieluoxxx]

由 deepseek-v4-flash 生成