v0.5.2

修 0.5.0 收缩时删多的三处，并改正更新按钮的通路。

修复

• 更新按钮装不上：0.5.0 让按钮调官方 install()，而 plugin_manager.installBundle 对已安装的包先查已装、直接以 already-installed 拒绝（弹「该插件已安装，如需升级，请卸载后重新安装」）。改回本插件自己的 update（pnpm add name@version），实测 dsh-better-sidebar 0.28.0 → 0.28.2 原地升级成功。
• 恢复「更新全部」：串行逐项升级，失败项留在行内红字（toast 的 overlay 已下线，没人渲染它）。
• 恢复 LLM 更新：每行一个「LLM 更新」+ 顶部「LLM 更新全部（n）」，确认面板与降级提示两个 overlay 一并回来。docs/设计/LLM驱动插件更新-设计方案.md §1.3 写明机械更新是兜底、LLM 更新是主入口——机械更新看不到 peer/依赖风险，还会把 vendor 魔改覆盖回官方版。
• 恢复启动提醒：有新版时启动弹一次（每天一次节流）。

为什么 0.5.0 会删多

只核了「官方有什么」，没读本仓 docs/设计/LLM驱动插件更新-设计方案.md §1.1/§1.3。那份文档写明了机械黑盒的三种事故（浮动版本装崩内核、覆盖 vendor 定制、无决策能力）与「机械更新保留为兜底」的结论。

v0.5.1

补 0.5.0 的遗留：标题栏那个「插件中心」按钮点了没反应。

修复

• 按钮调的是 window.__pluginCenterToggle（quick-toolbar 的内置适配器），而 0.5.0 把这组全局函数连同旧面板一起删了。现在重新暴露这三个键，落点改成打开官方「插件」页并选中「更新」tab。
• 实现是 DOM 驱动（先点侧栏「插件」，再点 [role=tab] 里的「更新」），与 quick-toolbar 驱动侧栏/底栏按钮同一套做法；找不到目标就停在上一级，不抛错。补了两次延时重试，覆盖面板懒渲染。

待定

• 按钮文案仍是「插件中心」。它现在的行为是「跳到更新」，改成「更新」更准确——那要改 quick-toolbar 的适配器，属于另一个包的改动。

v0.5.0

定位收缩：不再自带插件市场、安装、启停与诊断面板，只做官方没有的那件事——更新检测。

Breaking

• 删除设置里的「插件中心」面板、顶栏按钮、遮罩面板与 whats-new 弹窗（settings.section / shell.overlay / conversation.session.header.utilities 的注册全部下线）。
• 删除社区市场、一键安装、逐项启停开关、诊断页。
• __pluginCenterOpen / __pluginCenterToggle / __pluginCenterClose 三个全局控制器一并移除（已核对：本工作区内没有插件读取它们）。

Added

• 官方「插件」页的第三个 tab「更新」：挂在 plugins.tab slot 上（官方 Discover 走同一个），order 排在它之后。
• 行内「更新」按钮把精确的 name@version 交给官方安装对话框，构建批准、失败回滚、bundle 校验都留在官方那条链上；兼容性不符的行标记并禁用按钮。
• dsh.client.inject 补 @deepseek-ai/dsh-client-ui-plugin-manager（信息边，不决定加载顺序）。

保留

• host 侧全部 RPC 端点（listInstalled / checkUpdates / update / llm-update.* / diagnostics 等）不动，LLM 更新流程仍可由 agent 调用；只是它们的 Web UI 入口随旧面板下线。

为什么

• 官方 0.2.x 起内置了插件页（plugin-manager + 清单投影）与「索引源」市场机制，市场浏览/安装/启停全部重叠，且官方更贴近内核（profile 一致性由它保证）。
• 官方 plugin-manager 只有 installBundle / removeBundle，没有 update；已安装清单是只读投影，不比较本地版本与上游。更新检测是唯一没有替代品的部分。
• 旧 UI 与官方页并存时，whats-new 浮层会挡住官方页 tab 的点击（2026-10-29 在隔离 dev 实例里实测到），两套更新入口只会互相干扰。

体积

• client.js 126.9 KB → 37.5 KB：删掉注册后 esbuild 把整块旧 UI 摇掉了。

v0.4.7

修「同一个包在已安装列表里出现两次，而点第二条的开关会关掉第一条」。

变更

• 已安装列表按包归并：同一个包被 Loader 加载多条 entry 时合并成一行。
  ds-harness-remote 0.5.18 的 bundle patch 插了两条 name 相同的子条目
  （常规宿主 + dsh-TUI 专用，disabled 表达式互斥），此前显示两行文字、版本、
  兼容区间完全相同的卡片，无法分辨哪条在跑。
• 开关按 entryId 精确寻址：bundleEntryId() 不再把「bundle 里第一个声明的
  id」当成这个包的 id。此前点第二条的开关，写进 profile patch 的是第一条的 id——
  关掉的是真正在跑的那条，被点的那条本来就停用。
• 不猜：同名多条且无法按 entryId 精确匹配时拒绝写入（nowDisabled 为
  null），不再挑一个 id 去改别的行。

为什么

• 起因是「已安装」里 liguobao/ds-harness-remote 出现两次，版本、描述、需求
  区间完全一致。取证：包里 dsh.bundle.patch 声明两条同名 entry，
  listInstalled() 按 Loader entry 逐条列、不按包名归并；而 bundleEntryId()
  只取第一个 - id:，于是两行读同一个开关位、写同一个 id。
• 影响面：已安装插件里目前只有 ds-harness-remote 是多 entry 包，但机制通用
  ——任何以后这么设计的插件都会踩。

v0.4.6 — 安装段补 profile 选择与自查

本版只动文档：把安装段改成「先选对 profile」的形式，并补上卸载与自查。

变更

• 安装段改为按 DSH 形态选 profile 的对照表：dsh web → profile web，官方桌面应用 → profile desktop。此前只写了「装到你的 profile」，而插件装进哪个 profile 就只有那个 profile 看得见——装错正是最常见的「装了没反应」。
• 补前置条件：内核版本落在 @deepseek-ai/dsh-* peer 范围之外时，插件会被静默跳过——不进 fiber graph，也不出现在「未激活」列表里，界面上不报错。
• 新增卸载段与官方「插件」页的说明，附两条自查命令。

为什么

• 起因是 issue #1「在官方 dsh 应用里安装这个插件直接把原生插件管理干没了」。取证结论与描述不同：原生插件管理没有消失——截图显示侧栏「插件」页仍在、也能打开，只是内容区降级成「本部署没有可管理的 profile，无法安装或启停插件」。那句话的触发条件是宿主缺 pluginManager 服务，而本插件在这条链上没有任何着力点（host 半 inject = ['loader']，cordis.patch.yml 只有一条 insert）。
• 真正的原因是插件装到了与运行实例不同的 profile。文档不准会让用户在这里反复踩，所以按「回源码核对」处理，未改任何代码。

v0.4.5 — dsh peer 改为显式区间，内核 0.2.0-rc.1 下不再被跳过

0.4.5 (2026-09-29)

SSiD 的内嵌内核要从 0.1.7-rc.2 换到 0.2.0-rc.1，而本插件的 dsh peer 声明写成 caret 形式，
在那个内核上会被判为不兼容并跳过。本版修掉声明形态，并顺带把 README 逐条回源码核对了一遍。

修复

• peer 区间在内核次版本进位后失效。内核 app-boot 的 plugin-compatibility.ts 只挑
  peerDependencies 里的 @deepseek-ai/dsh / @deepseek-ai/dsh-* 条目，逐条按标准 semver
  （includePrerelease: true）判。caret 作用在 0.x 上时上界被钉在次版本——^0.1.1-rc.1
  展开即 >=0.1.1-rc.1 <0.2.0-0，对 0.2.0-rc.1 判 false；判定失败时插件被跳过，
  不进 fiber graph，也不出现在「did not activate」列表里。dsh-client-connection 与
  dsh-host-apiproxy 的 peer / dev 声明改为 >=0.1.1-rc.1 <0.3.0：下限保持原值，上界抬到
  0.3.0，下次次版本进位不必再改这一处。非 dsh- 前缀的 @deepseek-ai/cordis 与
  cordis-plugin-loader 不在该函数的检查范围内，未动。

• README 三处与实现不符（判据全部来自源码，不是记忆）：

  • 系列成员清单只列了 14 项，而 shell/profile-template/package.json 的 dependencies 与
    dsh.profile.bundles 里 @max-null/* 共 19 项——补 dsh-allostasis、dsh-skills、
    dsh-ssid-env、dsh-ssid-pwsh-retry、dsh-tone-layer。
  • 社区市场只写了 awesome-dsh-plugin 与 Oh-My-DSH 两个源，实际 src/market.ts 抓三个
    （第三个是 2BingLing/dsh-market），界面上的源选择器也是三项——补上。
  • 删掉 ## Part of the SSID family / SSID 系列成员 这个空标题：ec6ad5d 把该段移到
    标题下第一段之后，标题下已无任何内容。

变更

• 顺带带上两条 v0.4.4 之后未发出的提交：
  • dsh-plugin-upgrade 技能校正——profileDir 拆成「精确 pin」与「link:」两套机制；写明
    link: 形态禁止 pnpm add/update（那会把指向安装目录实体的 junction 变成 profile 自己的
    独立副本，同一插件出现两份实体、版本分叉，而 declared 与 installed 两边都对得上，只有
    重装时才暴露）；决策树 §2 的判据改为去发版基准看该包是版本号还是 file:./vendor/…；
    新增「环境与内核版本」表。
  • release-notes.md 补 0.4.1 / 0.4.2 / 0.4.3 三条条目。

测试

• 真 semver（7.7.4）逐个核对改后的区间：对 0.1.7-rc.2 与 0.2.0-rc.1 均 satisfies = true。
• 全量 77 条通过（7 个文件）；pnpm typecheck 无错。

验证

• pnpm build 重新产出 client.js（119.7kb）；dist/ 与 client.js 重建后与提交产物逐字节
  一致（build 后 git status 无改动）。
• 包内 skill dsh-plugin-upgrade 已核对，无需跟着本次内核升级改动：§环境与内核版本表里
  SSiD 安装版一行本就只写装载形态、不写版本号，fork dev 已记 0.2.0-rc.1，0.1.5-rc.2 与
  0.1.7-rc.2 分别是 web 副本与上游基准的当前值，均不受本次升级影响。

关于发布

npm 上的 @max-null/dsh-plugin-center@0.4.5 由用户手动 npm publish；本 tag 指向的提交
79bff17 即发布源。

关于此前几个 tag

v0.4.1 / v0.4.3 / v0.4.4 有 tag 但没有对应的 Release（Release 列表里目前只有 v0.4.0）。
本版不代补——补出来的说明只能凭 git log 反推，而三个 tag 的 message 已经把当时的情形写清楚了。

v0.4.0 — 包内技能注册为 SkillProvider

0.4.0 (2026-09-21)

本版把包内的 dsh-plugin-upgrade 技能正式注册进 DSH 的技能注册表——此前它只以文件形式
随包发布，等于没有。

修复

• 技能在干净机器上找不到：skill 工具报 dsh-plugin-upgrade is unknown or no longer available。根因是技能文件虽随包发布（files 含 skills），却从未注册成 skill provider
  ——DSH 的技能加载器只扫文件系统上的固定根（项目 .dsh/skills、~/.dsh/skills、bundled
  等），不会翻 node_modules。于是开发机上靠一份手工拷贝到 ~/.dsh/skills 能用，
  任何没拷过的机器上，LLM 更新流程一开始就加载不到 skill。这属于「提示词不自足」：
  不报错，只是永远找不到。
• 修掉 package.json description 里的一处编码残骸（em dash 的 UTF-8 字节被按 GBK 解成
  U+95B3 + ?，npm 页面上显示为乱码）。

变更

• 新增 src/skill-provider.ts：注册 packaged SkillProvider（rank 550，与
  @max-null/dsh-skills 同档——低于用户自己的技能目录，用户永远可覆盖；高于 bundled），
  从包内 skills/ 读取。技能随包走、不写用户目录、无需任何安装步骤。
• skills 服务走 ctx.inject(['skills'], cb)：可选依赖，缺失时插件其余部分照常工作。

测试

• 新增 tests/skill-provider.test.ts（5 条）：依赖声明、服务缺失时降级、候选字段
  （rank / source / provider / invocation / resourceBase）、正文剥离 frontmatter、列举顺序稳定。
• 全量 64 条通过；npm run typecheck 无错。

验证

• 隔离实例实测：Skill 工具一次命中 dsh-plugin-upgrade（2 秒、无绕路），而该实例的
  ~/.dsh/skills 中并无手工拷贝 → 该技能只可能来自新注册的 provider。

关于 git tag

0.3.0 没有对应的 git tag：它的代码状态（09-17 那批 RPC 双路径改动）当时位于工作树中
未提交，版本号本身从未进过任何提交；后来它与 0.4.0 的改动一并提交为 ec3556e，无法还原
0.3.0 的独立状态。给它补一个指向 ec3556e 的 tag 是假精确，故不补；npm 上的 0.3.0 仍然有效，
缺口由来记在此处。