在流出的desktop exe 0.1.7-rc.2版本中出现如图报错日志，当我装有一个处在release min age期间的插件时，无法正常卸载插件。

[LiBigYe]

在流出的desktop exe版本中出现如图报错日志，当我装有一个处在release min age期间的插件时，无法正常卸载插件。

[LiBigYe]

已确认根因，并且在临时目录里做了可复现验证。问题的根不在 DSH 的卸载逻辑，而在 pnpm 11 的供应链策略 + profile 里失效的豁免写法组合。

---

一、pnpm 日志在哪、哪一次操作失败

DSH 插件管理器的每次操作都留了一份 pnpm 原始输出：

• 失败的那次：<C:\Users\ASUS.dsh\profiles\desktop.plugin-manager\logs\operation-VzHEpO\pnpm.log>（2026-09-25 00:44:42，就是截图里那次）
• 同一错误在 00:33→00:44 之间连续出现 8 次（operation-fbLzhA / 6ITFGl / TOrD4Z / V1c1Av / WXzdTf / pbNuXD / VzHEpO），全是同一句 ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION
• 对照成功日志 operation-U8t9rc（09-24 21:03）末尾写着 Done in 1.6s using pnpm v11.7.0 → DSH 用的是自带 pnpm（resources/runtime/pnpm，11.7.0），不是 PATH 上的 12.5.1

二、日志其实指向了两件独立的事

日志片段	判定
1 lockfile entries failed verification: dsh-codex-connect@0.1.0-alpha.4.47（262 条里只挂 1 条）	致命：整次操作被这一票否决
cutoff (2026-09-23T16:44:42.799Z) 与日志落盘时间 16:44:47 相差 4.2s，正好等于日志里的 4.2s	证明 cutoff = 启动时刻 − 1440 分钟（严格 24h）
[WARN] GET .../undici-types error (UND_ERR_DESTROYED). Will retry in 10 seconds	次要：重解析时的单包请求中断，日志自己说会重试，不是失败原因

三、24 小时策略是 pnpm 11 的默认值（不需要任何配置）

我在 DSH 自带 pnpm 的打包产物里找到了默认值表：

const defaultOptions4 = {
  ...
  "minimum-release-age": 24 * 60,   // 1 day
  "minimum-release-age-ignore-missing-time": true,

文件：...\resources\runtime\pnpm\dist\pnpm.mjs。这就解释了为什么 profile 的 pnpm-workspace.yaml 里根本没有 minimumReleaseAge，却仍然按 24h 卡：pnpm 11 默认开启。你环境里的第三方插件文档也印证了这一点（dsh-better-sidebar/README.md：“装的版本发布不足 24 小时…pnpm 会自动补 minimumReleaseAgeExclude”）。

四、真正的 bug：profile 里的豁免写在“错的位置”，被前一行吃掉了

<C:\Users\ASUS.dsh\profiles\desktop\pnpm-workspace.yaml> 第 10–14 行：

minimumReleaseAgeExclude:
  - dsh-better-sidebar@0.21.1
  - dsh-codex-connect@0.1.0-alpha.4.46   # ← 第 12 行，先匹配到这个
  - dsh-codex-connect@0.1.0-alpha.4.47   # ← 第 13 行，永远不生效

pnpm 的 evaluateVersionPolicy() 是同名只取第一条（first-match-wins），匹配到 .46 就 return ['0.1.0-alpha.4.46']，.47 那条成为死规则 → isExcluded() 返回 false → 校验照样失败。

复现矩阵（把 profile 复制到临时目录，用 DSH 自带的 pnpm 11.7.0 跑，真实 profile 未改动）：

实验	minimumReleaseAgeExclude 内容	结果
C	dsh-codex-connect（只写包名）	✅ 通过
D	.46 在前、.47 在后（=现状）	❌ 失败
E	.47 在前、.46 在后	✅ 通过
F	只写 .47	✅ 通过
I/J	完全不写豁免	❌ 失败（证明默认 24h 生效）

五、完整因果链（对应你截图的“卸载失败”）

1. 你点“卸载 Better Sidebar” → DSH 插件管理器执行的是 pnpm remove <name>（@deepseek-ai/dsh-plugin-manager 的 runProfilePnpm，它先备份 package.json/pnpm-lock.yaml，失败后回滚）。
2. pnpm 在动任何文件之前，先拿 lockfile 的 262 条全量做供应链校验。
3. lockfile 里躺着 dsh-codex-connect@0.1.0-alpha.4.47（发布 2026-09-24T12:08:11Z，当时年龄约 4.6 小时 < 24h）→ 违规。
4. 本该救场的豁免行（.47）被前一行的 .46 吃掉 → 校验失败 → pnpm 退出码 1。
5. DSH 回滚 package.json/pnpm-lock.yaml，把整件事报成“卸载失败”。于是插件仍在列表里显示“已关闭 + 卸载”按钮 —— 与第二张截图完全一致；dsh-codex-connect 显示“异常”也是同一条锁文件记录的连带后果。

六、怎么解（按代价排序）

1. 立刻可做（推荐）：把 <C:\Users\ASUS.dsh\profiles\desktop\pnpm-workspace.yaml:10-14> 里那两行 dsh-codex-connect@... 合并成一行只写包名 —— - dsh-codex-connect，然后重试卸载（实验 C 已验证可通过）。
2. 等 2026-09-25T12:08:11Z（北京时间 20:08）之后重试，版本自然“够龄”，无需改配置。
3. DSH 侧应修：插件管理器写入豁免时不要产出“同包多行版本豁免”（改成包名，或合并为 a || b 单行）；对 ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION 单独识别并提示具体是哪个无关插件阻塞了本次操作，而不是笼统报“卸载失败”。

---

说明：以上复现全部在 %TEMP% 的副本里完成

[liuwenji007]

在0.2.0版本也有

卡片显示 1.66.5，日志里实际是 + dshmarket ^1.66.3，被拒绝的也是 1.66.3；
原因是 profile 设了 minimumReleaseAge: 1440，pnpm 静默回退到了更早的版本，而我们最近两个热修版本不足时间，导致用户卸载更新也不能正常使用；
这个问题之前我们的dsh-market也有过，现在已经修复了。
期望的行为：安装前显示真正会装的版本，或者直接按展示的精确版本安装；失败时说明是 release-age 导致的回退。