版本状态徽章 idoall/dsh-update-status

DSH Update Status

DeepSeek Harness Web 的版本状态、仅复制升级提示，以及需用户级服务监督的安全重启。

功能 ·安装 ·使用 ·更新检查 ·受监督的重启 ·局域网访问 ·可加载性 ·配置 ·故障排查 ·安全边界 ·卸载 ·发布指南

DSH Update Status 是 DeepSeek Harness 社区插件。它不修改 DSH 核心，不会安装或升级 DSH、回滚 DSH 包、下载 release 或替换 DSH 文件，也绝不会自行安装更新或自行重启 DSH；只有你显式安装并接管了当前 DSH Web 的用户级后台服务后，它才会请求一次受限的安全重启。

插件只把展开侧栏中的品牌名称换成适配 24px 品牌行的 DeepSeek + 版本芯片，官方鱼标保持不变。版本号旁的绿点表示线上没有更新的版本；橙色呼吸圆点表示线上至少有一个更新的版本——无论是稳定版、RC 还是 Alpha。点击芯片即可看到当前运行版本、每个更新版本一张卡片（各带自己的“仅复制”升级命令），以及只有装好用户级监督后才会出现的重启按钮。

功能

- 侧栏版本状态：展开侧栏显示当前 DSH 版本。收起侧栏时不渲染任何入口——DSH 的 sidebar.footer.action 是「设置」上方的一格 36px 位置，第二个注册者会把这一行撑破（实测把相邻插件的入口顶出了屏幕左缘），所以品牌行芯片是唯一入口。
- 安静的更新提示：有新版本时不改变版本 Badge 的背景，只在版本号旁保留一个带小光晕的橙色圆点做放大缩小的呼吸动画（prefers-reduced-motion 下停用动画），让新版本表现为一盏小灯，而不是整条品牌行换色。
- 一眼三态：没有可做的事时，版本号旁是纯绿色小圆圈（取主题 success 色，不再跟随文字色——暗色外壳下不会再出现一个看起来像「熄灭」的深色点）；检查中是中性灰呼吸点；有新版本才是橙色光晕呼吸点。只有更新态会动、会发光，也只有状态读取失败才会把 Badge 重绘成红色。
- 中性版本底框：Badge 在明暗两套主题下都用灰色二级面（浅色 #f1f3f5 / 深色 #353638）配主题常规文字色，所以暗色下是「深灰底 + 白字」，不再是会把橙色光晕吃掉的白框。
- 浅色 / 深色 / 跟随系统，自动适配：插件渲染的每个颜色都是 DSH 语义令牌，Badge、圆点、光晕与面板都按 DSH 当前外观解析。DSH 设为浅色、深色或跟随系统，插件就跟着切换——插件侧没有自己的主题开关，也没有需要同步的媒体查询。hover 在两个方向上都是「抬起」：浅色下压深、深色下提亮（把主题文字色按比例混进底色实现）。
- 一个可升级版本一张卡片：凡是严格新于当前运行版本的已发布版本，各占一张卡片，最新的排在最上面；每张卡片带的是该版本自己的只复制命令。没有任何更新版本时不显示卡片，面板直接说明当前版本最新。
- 只有最新那张卡片被强调：最高版本用琥珀色描边加最新标签突出，其余卡片保持中性。没有手动排序控件：顺序就是版本顺序，只有最上面那张被强调。
- 只有一条发布线、零配置：一次 registry 请求读取 npm 的全部 dist-tags，保留所有比当前运行版本更新的版本——稳定版、RC、Alpha 一视同仁。没有需要关注的通道，也没有需要做的选择。
- 诚实的预发布比较：运行版本与每个候选版本按 SemVer 排序，因此 0.2.1-rc.4 高于 0.2.0-rc.2，而 RC 仍然低于它自己的正式版。
- 按版本给命令，只复制不执行：每张卡片上的命令都钉在该卡片的确切版本上，不用会移动的 dist-tag，插件也从不执行它。
- 不再维护兼容台账：面板不再声称某个 DeepSeek Harness 版本“与本构建一起测过”。能不能加载由 DSH 自己按声明的引擎范围与 @deepseek-ai/dsh-settings peer 范围判定。
- 缓存但不轮询：Host 挂载时检查一次，缓存可设为 30–1,440 分钟并合并并发请求；前端没有轮询，只有“检查更新”按钮绕过缓存。
- 移动端可靠：详情使用浏览器 modal top layer；底部 sheet 可滚动、适配 safe area，并保持在 DSH 抽屉上方。
- 受监督的安全重启：一次性装好后台服务后，面板就能替你重启 DSH——它会先提醒会中断哪些工作，而终端直启或桌面应用托管的 DSH 会被直接拒绝。

安装

要求：

- 带 Web profile 的 DeepSeek Harness
- DeepSeek Harness >=0.1.7-alpha.2 <0.3.0——这是插件在 dsh.engines.dsh 中声明的范围，@deepseek-ai/dsh-settings peer 范围与之相同。超出范围的 bundle 会在 profile 加载时被 DSH 拒绝。没有“已验证发布清单”需要你对照：在范围内，插件不需要等某个版本被“批准”。
- Node.js 20 或更新版本

已经安装 dsh 命令：

dsh plugin --profile web add dsh-update-status@latest

直接使用 DeepSeek Harness 源码：

corepack enable
pnpm install
pnpm dsh plugin --profile web add dsh-update-status@latest

安装后重启原有 DSH 进程，再刷新 Web GUI。不要为本插件启动第二个 Web server。

本地开发 link：

pnpm install --frozen-lockfile
pnpm run build
dsh plugin --profile web add "link:$(pwd)"

使用

1. 打开 DSH 左侧抽屉。官方鱼标仍在；名称行显示 DeepSeek + 当前版本 Badge。
2. 点击 Badge。面板打开时不会触发外层“新建会话”按钮。
3. 看当前运行版本。线上没有更新的版本时，面板会说明当前就是最新版本，并且没有任何卡片可点。
4. 否则每个更新的已发布版本各有一张卡片，最新的在最上面。卡片显示版本号、承载它的 dist-tag（npm 有报告时）、所属发布线和发布时间。
5. 复制你想装的那张卡片上的命令（每条都钉在该卡片的确切版本上），在运行 DSH 的那台电脑的终端中自行执行。
6. 包管理器命令完成后，只有已完成受监督的重启接管时才使用面板里的重启；否则仍由你自行重启 DSH。

全局安装时，卡片上的命令可能长这样：

npm install -g @deepseek-ai/dsh@0.2.1-rc.4

每张卡片只显示一条与检测到的安装方式匹配、并写明该卡片确切版本号的命令，插件不会运行它。当这种安装方式给不出包管理器命令时（例如源码检出），面板只在整块面板上给一次说明，而不是给每张卡片配一个复制按钮去编造命令。

圆点含义

版本号旁那颗圆点承载全部状态，且只有更新态会动：

| 圆点 | 状态 | 含义 |
| 绿色小圆圈 | 已是最新 | 线上没有更新的已发布版本，芯片保持原底色。 |
| 灰点呼吸 | 检查中 | 状态读取正在进行（首次挂载，或点了检查更新）。 |
| 橙色圆点 + 光晕 | 有更新 | 线上至少有一个更新的版本。复制某张卡片的命令、自行执行，然后重启 DSH。 |
| 芯片变红 | 读取失败 | 插件无法判定状态：registry 读取失败，或两个版本无法按 SemVer 比较。 |

芯片本身是中性二级面——两套主题都是灰色，文字用主题常规色——所以橙色光晕始终看得清，而且它绝不会为了宣布更新而改变颜色。

更新检查

插件按缓存周期向 npm registry 请求一次 @deepseek-ai/dsh，收集所有被 dist-tag 指向的已发布版本，保留严格新于当前运行版本的那些，并按从新到旧列出。latest、next、alpha 是 npm 自己的记账方式，不是需要用户做的选择：哪个 tag 上挂着更新的版本，就计入哪个。

- npm 返回的每个 tag 都算，包括插件没听说过的 tag。同一个版本可能带多个 tag，卡片上只显示一个，按 latest、next、alpha、beta、rc、其他的顺序取。
- 按 SemVer 从高到低排列（含预发布）：因此跑到稳定版前面的 alpha 会被列出，而不是被藏起来。
- 比较是精确的：0.2.1-rc.4 比 0.2.0-rc.2 新，两者都低于 0.2.1。
- 列表以当前运行版本为准：升级 DSH 后重新检查，卡片会变少；装回旧版本则会变多。
- npm 网页只在包首页显示 latest 那个 tag，其他 tag 上的版本要到 Versions 页面才看得到。面板不照搬这个简化，它们都会被列出。
- 这里不会安装任何东西，也不会自动应用任何更新。跟随某条通道——以及保存它的 channel 偏好——已在 0.2.0 移除。

受监督的重启

插件没法自己重启 DSH：它就住在那个要被换掉的进程里。所以只有让操作系统来托管这个进程，按钮才有意义——而每个系统本来就自带这个能力。

最短且安全的接管流程是显式在终端执行：

1. 只预览完整的原生服务计划：不写文件，不启动服务。
dsh plugin --profile web exec dsh-update-status-service plan \
--workspace "$PWD" --dry-run

2. 只落盘用户服务定义：仍然不会启动它。
dsh plugin --profile web exec dsh-update-status-service install \
--workspace "$PWD"

3. 由你自己在旧终端停止直启的 dsh web，再激活服务。
dsh plugin --profile web exec dsh-update-status-service activate

activate 发现端口还被占着就停手，绝不去杀进程，所以你正在用的 DSH 不会被突然掐掉；激活之后它还会确认服务真的接管了——一启动就不停失败的服务会被当作失败报出来，而不是假装成功。这之后就交给重启按钮：它先列出正在跑的东西，有东西在跑时再问一次，然后才让 DSH 退出；服务把新的拉起来，页面自己回来。

同一个端口只允许一个启动者。如果别的工具自己拉起了 dsh web——另一个插件的重启助手、nohup 脚本——那个进程会占着端口，而你的服务会一直启动失败。插件会直接问操作系统「这个服务真正拥有的是哪个进程」，所以这种情况下重启按钮会保持禁用，而不是承诺一个做不到的恢复；同时它会给出两条只复制的命令：一条找出谁占着端口，一条把服务交还回去。生成的服务在连续几次启动失败后也会停下来（不再无限重拉），并把原因写进自己的日志。更多细节见用户服务监督说明。

| 平台 | 用户级拥有者 | 启动时机 | 接管后页面重启 | 说明 |
| macOS | launchd LaunchAgent | 用户登录 | 可以 | 已真机验证；不需要管理员。 |
| Linux | systemd --user | 用户登录 | 已实现；请在你自己机器上验证 | 想在登出后继续运行，可自行开启 loginctl enable-linger（本插件不会替你开）。 |
| Windows | 任务计划程序 + 当前用户 wrapper | 用户登录 | 已实现；请在你自己机器上验证 | 不需要管理员。 |

生成的服务文件里只有绝对路径、一条可审计的 PATH，以及没有密钥——不会带上你终端里的 API key、npm token、cookie 或代理凭据。默认情况下，install 会保存执行安装命令的终端 PATH，因此 Homebrew、MacPorts、Nix、asdf、Conda、Cargo 和手工安装走的是同一套规则；--path-source minimal 保留固定环境，--service-path 则使用你明确给出的完整 PATH。plan --dry-run 会在写文件前列出最终值和全部提示。原生文件、日志、状态与卸载见用户服务监督说明；想在 Linux 或 Windows 上自己确认，见跨平台验收步骤。

重启会中断正在跑的工作，且不会保存。如果 DSH 列不出正在跑什么、无法确认当前进程确实由你装的服务拥有，或者它本来就是终端直启、桌面应用托管的，它会直接拒绝重启——网页端说什么都没用。

局域网（非回环页面）访问

较早的 DSH 会把非回环页面的设置表单限制为仅内存状态。DSH 0.2.1-rc.3 及之后的表单快照不再提供该 mode 字段，官方按条目寻址的表单直接调用设置 Remote。不能仅根据页面来源判断当前的持久化或授权行为；写入是否获准由正在运行的 Host 设置策略决定。

从 0.1.2 起，本插件在局域网页面同样可用：

- 版本/更新状态照常读取。早先的版本把整个功能压在 connection.isLoopback === true 上，于是经局域网转发（dsh-bridge、dsh-lan-proxy 等）打开的页面从不发送 POST /api/dsh-update-status.get-status、详情面板打不开，还会把本包构建时所针对的版本当成"当前运行版本"显示。该判断已移除——Connection RPC 本身是已认证的，Host 路由也是本插件自己的路由。
- 偏好设置（sidebarEnabled、cacheTtlMinutes）继续读写 Host 上共享的那一份 dsh-update-status 设置条目，走的是与官方设置表单相同的公开 Remote（settings.describe / settings.mutate）。写入仍受 revision 栅栏保护，被拒时明确提示冲突而不会静默覆盖。直连通道只在官方表单报 unavailable 时才打开，所以回环页面仍走官方路径，不会多发一次线上读取。

局域网转发必须保留 DSH 的已认证传输和 Host 授权策略。本插件不会修改转发配置或授予设置访问权；Host 拒绝访问时，应由部署维护者处理。

可加载性与更新提示

本插件不为任何 DeepSeek Harness 版本背书。能不能加载由 DSH 决定，而 DSH 只看两处声明：dsh.engines.dsh 是 >=0.1.7-alpha.2 <0.3.0，@deepseek-ai/dsh-settings 的 peer 范围与之相同。在这个范围内，你想跑哪个 DSH 版本都行，不需要插件再发一版来“批准”它。

0.5.0 把原来那套机制整个删掉了：没有已验证发布清单、没有 dsh.compatibility 元数据、面板里没有“已验证兼容/尚未验证兼容”标签，也不会因为某个 DSH 版本没被测过而给出提示。插件的职责只有一条——告诉你有更新的版本，以及怎么升级；维护兼容台账本来就不在范围内，而它 13 天里发过六个以兼容声明为标题的版本。

剩下的就是更新提示：每个比当前运行版本新的版本各一张卡片，各带自己的命令。插件对某个版本知道的信息只有 npm 公布的那些——版本号、tag、发布时间——它不对“这个版本对你是否合适”下结论。

下表中 0.5.0 以下的行仍会提到那份已删除的清单，那是历史，现在已经没有版本需要等某个清单收录。

npm 上的插件版本

| 插件版本 | npm 发布状态 | 该版本是什么 |
| 0.5.0 | latest | 一个可升级版本一张卡片、各带自己的只复制命令；已验证发布机制被删除，能否加载只由 DSH 的引擎范围与 peer 范围决定 |
| 0.4.8 | 已发布 | 在当时那份已验证清单中为 DSH 0.2.1-rc.4 追加条目——那套机制已在本次发布删除；功能代码不变 |
| 0.4.7 | 已发布 | 移除重复的设置菜单；安装后默认显示版本与更新提示，详情统一由侧栏版本芯片打开 |
| 0.4.6 | 已发布 | 在当时那份已验证清单中为 DSH 0.2.1-rc.3 追加条目；后台维护和启动中的终端也需重启确认，并恢复重启风暴的原因与恢复指引 |
| 0.4.5 | 已发布 | 在当时那份已验证清单中为 DSH 0.2.1-rc.2 追加条目；功能代码不变 |
| 0.4.4 | 已发布 | 在当时那份已验证清单中为 DSH 0.2.1-alpha.5 追加条目；功能代码不变 |
| 0.4.3 | 已发布 | 在当时那份已验证清单中为 DSH 0.2.1-alpha.4 追加条目；功能代码不变 |
| 0.4.2 | 已发布 | 在当时那份已验证清单中为 DSH 0.2.1-alpha.3 追加条目；功能代码不变 |
| 0.4.1 | 已发布 | 安装服务时保存当时使用的 PATH，不论工具由哪种包管理器安装，受托管后仍能找到 |
| 0.4.0 | 已发布 | 重启变得靠得住：服务连续失败会停下而不是无限重启；按钮要求系统服务真正托管当前进程；禁用时会给出两条可复制的恢复命令 |
| 0.3.2 | 已发布 | 只改文档：版本对照表和历史发布说明都改成人话。功能与 0.3.1 完全一样 |
| 0.3.1 | 已发布 | 小补丁：面板也说明了重启前提，长任务名不再把按钮挤走。 |
| 0.3.0 | 已发布 | 面板新增重启，以及它需要的那条服务安装命令；没装服务时按钮保持禁用并说明原因。 |
| 0.2.1 | 已发布 | 隐藏版本芯片后，品牌行恢复成 DSH 官方的名称与鱼标，而不是变成空白。 |
| 0.2.0 | 已发布 | 从「通道目录」改成「一条发布线」：面板只报 npm 上最新的已发布版本，没有需要配置的东西。 |
| 0.1.12 | 已发布 | 把 DSH 0.2.0-rc.2 加入当时那份已验证清单；代码无改动。 |
| 0.1.11 | 已发布 | 声明 DSH 0.2.0 线并放宽支持范围，避免更新的 DSH 一声不响地把插件丢掉。 |
| 0.1.10 | 已发布 | 收起侧栏的窄轨里不再放按钮——那里放不下，还会把相邻插件的图标挤开。 |
| 0.1.9 | 已发布 | 修复升级 DSH 后插件消失（安装目录里残留的共享库副本会把它带崩）；面板现在会告诉你要删哪个目录。 |
| 0.1.8 | 已发布 | 把 DSH 0.1.7-rc.2 加入当时那份已验证清单；代码无改动。 |
| 0.1.7 | 已发布 | 英文界面不再混入中文：状态提示改由浏览器按自己的语言渲染。 |
| 0.1.6 | 已发布 | 适配 DSH 0.1.7：插件的两个偏好改存成它自己的设置条目。 |
| 0.1.5 | 已发布 | 一颗圆点承载全部状态（绿=最新、灰=检查中、橙=有更新），提示性说明不再重绘芯片。 |
| 0.1.4 | 已发布 | 修复「正在运行的版本」显示成不可选。 |
| 0.1.3 | 已发布 | 带上局域网页面的修复，并在当时的 DSH 0.1.6 上核对过。 |
| 0.1.2 | 未发布 | 去掉「仅回环」的限制，局域网页面也能用。 |
| 0.1.1 | 已发布 | 此前的 npm 最新版；局域网页面上插件不工作。 |
| 0.1.0 | 已发布 | 首个版本。 |

- 哪个版本配哪个 DSH？ 0.1.6–0.1.10 是为 DSH 0.1.7 线构建的；0.1.11 及以后同时接纳 0.2.0 线。DSH 0.1.7 改了插件设置的存储方式，所以在更早的 DSH（含 0.1.6-alpha.2）上请留在插件 0.1.5。
- 能不能加载由 DSH 判定，不看标签。 如果某个 DSH 版本拒绝加载本插件，请禁用或卸载插件，不要去改 DSH 本体——也请顺手反馈。现在已经没有“已测清单”，也没有清单条目可等。
- npm 发布状态 指 dsh plugin --profile web add dsh-update-status@latest 实际会装到的版本；只存在于仓库、尚未发布的版本属于开发状态。

- 需要固定插件版本时显式指定：

dsh plugin --profile web add dsh-update-status@0.5.0
dsh plugin --profile web add dsh-update-status@0.4.8
dsh plugin --profile web add dsh-update-status@0.4.7
dsh plugin --profile web add dsh-update-status@0.4.6
dsh plugin --profile web add dsh-update-status@0.4.5
dsh plugin --profile web add dsh-update-status@0.4.4
dsh plugin --profile web add dsh-update-status@0.4.3
dsh plugin --profile web add dsh-update-status@0.4.2
dsh plugin --profile web add dsh-update-status@0.3.2
dsh plugin --profile web add dsh-update-status@0.2.0
dsh plugin --profile web add dsh-update-status@0.1.12
dsh plugin --profile web add dsh-update-status@0.1.11
dsh plugin --profile web add dsh-update-status@0.1.10
dsh plugin --profile web add dsh-update-status@0.1.9
dsh plugin --profile web add dsh-update-status@0.1.8
dsh plugin --profile web add dsh-update-status@0.1.7
dsh plugin --profile web add dsh-update-status@0.1.6
dsh plugin --profile web add dsh-update-status@0.1.5
dsh plugin --profile web add dsh-update-status@0.1.4
dsh plugin --profile web add dsh-update-status@0.1.0

- 有两处声明决定插件能不能加载，DSH 在 profile 加载时会检查：
- dsh.engines.dsh 与 peerDependencies['@deepseek-ai/dsh-settings'] 都声明 >=0.1.7-alpha.2 <0.3.0。下界特意写成这个 alpha：按 node-semver 默认的预发布规则，>=0.1.6-0 <0.2.0 这样的范围并不接纳 0.1.7-alpha.2。上界在 0.1.11 从 <0.2.0 放宽到 <0.3.0 是同一件事的镜像：DSH 会在 profile 加载时拒绝不兼容的 bundle，而裸的 <0.2.0 恰好排除 0.2.0 正式版——DSH 0.2.0 发布当天插件就会被静默丢弃。DSH 判定时使用 includePrerelease: true，所以 0.2.0-rc.2 本来就在这个范围内。这两个边界只决定能否加载，并不表示范围内的每个版本都被测过。
- @deepseek-ai/schemastery 是 peer，不是普通依赖：DSH 0.1.7 只从运行安装解析 link 插件的 peer 依赖，否则 link: 安装会连 Host 半边都 import 失败。
- 每个版本的中英文详细说明（改了什么、影响谁、需要做什么）手写后直接作为 GitHub Release 正文：v0.5.0 · v0.4.8 · v0.4.7 · v0.4.6 · v0.4.5 · v0.4.4 · v0.4.3 · v0.4.2 · v0.4.1 · v0.4.0 · v0.3.2 · v0.3.1 · v0.3.0 · v0.2.1 · v0.2.0 · v0.1.12 · v0.1.11 · v0.1.10 · v0.1.9 · v0.1.8 · v0.1.7 · v0.1.6 · v0.1.5 · v0.1.4 · v0.1.3（含从未发布的 0.1.2）。

配置

| 选项 | 默认值 | 范围 / 行为 |
| cacheTtlMinutes | 360 | 30–1,440 分钟；仅在下一次按需读取时判断是否到期，绝不启动后台定时器 |
| sidebarEnabled | true | 只隐藏本插件自己的侧栏入口；隐藏期间品牌行恢复为 DSH 官方鱼标与字标 |

插件安装后默认显示版本状态与更新提示。点击侧栏版本芯片即可查看当前版本、检查结论、升级说明并调整缓存时长，不再提供单独的设置 → 版本与更新菜单。已有 profile 中的 sidebarEnabled 配置仍然兼容；若旧配置隐藏了芯片，将其设为 true 或删除该覆盖值即可恢复默认显示。修改缓存时长不会请求网络；只在之后普通读取且缓存已到期时更新，“检查更新”始终是立即手动检查。

缓存偏好只会在你于面板中主动选择时写入。插件没有任何自动写入路径——没有 effect、定时器，也不在挂载时写入，并由 tests/client/entry.spec.ts 挂载真实客户端入口长期守住这一点。在 DSH 0.1.7 上，上面两个偏好就是本插件条目 Config 的 volatile 字段，因此以该条目的 config 落在当前 profile 的 patch 里（~/.dsh/profiles/<profile>/cordis.patch.yml）；要重置某个偏好，直接修改或删除该段即可，DSH 会在下次变更时重新加载 profile。Config 的其余字段只用于部署、不会出现在表单中：cacheTtlHours（默认 6）、timeoutMs（默认 15000）与 autoCheckOnMount（默认 true），同样写在同一份 profile patch 中。

故障排查

胶囊显示的版本不是我刚装的，而且点了没有反应。 这是插件 0.1.1 及更早版本的 connection.isLoopback 门控：在非回环页面（如 dsh-bridge、dsh-lan-proxy 这类局域网转发）上整个插件会失效，胶囊显示的是本包构建时所针对的版本，而不是正在运行的版本。先确认已装版本再升级：

node -p "require(process.env.HOME + '/.dsh/profiles/web/node_modules/dsh-update-status/package.json').version" # 需要 0.1.3 或更新
dsh plugin --profile web add dsh-update-status@latest

升级 DSH 之后芯片变红了。 在 0.1.5 及更新版本上，红色只代表一件事：插件无法判定状态——registry 读取失败，或两个版本无法按 SemVer 比较。0.1.4 及更早版本的判定更宽：客户端把任何警告都当成故障，所以当 DSH 比插件清单更新时，哪怕读取其实成功了，芯片也会被涂红。0.1.5 把两者分开——failure 仍然重绘，提示只留在面板；0.5.0 则把那条提示彻底删除，所以更新的 DSH 版本再也不会产生它：

dsh plugin --profile web add dsh-update-status@latest

明明知道有更新的 DSH，面板却一张卡片都没有。 列表是检查那一刻按 npm 上已发布的版本、与你正在运行的版本比较得出的。点检查更新重新读一次。如果某个版本只存在于插件看不到的 registry，或者你运行的版本已经是已发布的最高版本，那就没有卡片可显示——不显示卡片正是正确答案。

版本一直不变。 Host 会缓存一次 registry 响应，默认 360 分钟，且只有普通读取才会判断到期。点检查更新可立即刷新，或调小 cacheTtlMinutes。检查失败时会保留上一次成功缓存，并在版本号旁显示警告。

完全连不上 npm registry。 插件会报告失败，并仍然显示本地检测到的运行版本。registry 访问只允许 HTTPS 的 registry.npmjs.org；代理或离线环境会给出这条警告，而不是编造一个版本号。

升级之后插件整个消失了，宿主日志里是 volatile is not a function。 0.1.5 及更早版本把 @deepseek-ai/schemastery 声明为普通依赖；从 0.1.6 起它是由 DSH 提供的 peer，而 DSH 给它加的 volatile() 正是把两个偏好变成这个条目设置表单的机制。如果该包的一份旧副本被留在插件自己的安装目录里（用本地目录安装时被一起拷进来的 dev node_modules，pnpm 永远不会清理），Node 就会解析到那份旧副本，缺失的方法在宿主半 import 阶段直接抛错，插件在来得及报告任何信息之前就消失了。新版本改为显式解析平台那份，两种情况都能加载；只找得到旧副本时，面板会给出 stale-schemastery 提示并指出该删除哪个目录。删除残留目录后重启 DSH：

rm -rf ~/.dsh/profiles/<profile>/node_modules/dsh-update-status/node_modules

安全边界

- registry 访问只允许 HTTPS registry.npmjs.org，并拒绝重定向。
- Host 只通过 DSH 已认证的 Connection RPC 返回普通 JSON。
- 不注册公共 Remote Service，也不注册模型 Tool。
- 插件代码不会启动 npm/pnpm 子进程。
- canApplyInPlace 恒为 false。
- 插件不会安装、升级、回滚或替换 DSH 文件。单独、显式执行的服务 CLI 只会落盘当前用户的服务定义，绝不会杀掉占用端口的 DSH。
- 重启只接受 POST 的已认证 Connection RPC，并由服务端同时检查明确的原生服务标记与平台身份；终端直启、桌面版、未知环境或无法完整检查活动工作时均拒绝退出。
- 刷新失败时保留最后一次成功缓存并显示警告；冷启动失败也会保留本地版本信息。

卸载

dsh plugin --profile web remove dsh-update-status

重启 DSH 并刷新 Web GUI。卸载不会删除偏好：要清空偏好，请从当前 profile 的 cordis.patch.yml 中删除 dsh-update-status 条目的 config 段。

开发

pnpm install --frozen-lockfile
pnpm run test
pnpm run build
pnpm pack --dry-run

发布 tag 使用 npm Trusted Publishing 与 GitHub OIDC。请按 docs/RELEASING.md 在 npm 网站一次性绑定 Trusted Publisher，随后推送匹配的 vX.Y.Z tag；仓库不保存长期 npm token。

MIT，详见 LICENSE。