0.3.3 —— 回滚兜底真正生效（0.3.2 的兜底从未触发）、暂停落盘、恢复指引修订

⚠️ 0.2.0 – 0.3.2 用户请先读：升级失败可致 dsh 无法启动，0.3.3 才是修复版

0.3.2 的 release notes 曾宣布这个问题已修——实测没有：它的 per-package pnpm add 兜底会拒掉 ^ range（^ 是 cmd 转义符，进 spec 黑名单），github: 源则整个跳过，而 pnpm 存的依赖几乎不是前者就是后者——兜底在真实 profile 上一次也没触发过。此前两起事故靠手动恢复成功，纯属手敲的 spec 恰好是精确版本号。受影响范围因此是 0.2.0 – 0.3.2。

症状：更新已装插件时若走到回滚（最常见：目标插件带构建脚本、停在批准卡），dsh web 报 cannot resolve profile bundle "…" 直接退出。

如果 dsh 已起不来——照 profile package.json 里原本的写法把包装回去，然后 dsh web（详见 README「升级后 dsh 起不来？」）：

# <profile> = %USERPROFILE%\.dsh\profiles\web 或 ~/.dsh/profiles/web
# npm 包 —— 照 package.json 里的写法，例如 "dsh-better-sidebar": "^0.13.1"
pnpm --dir <profile> add "dsh-better-sidebar@^0.13.1" --ignore-scripts
# GitHub 源 —— 例如 "dsh-at-file": "github:omdsh-dev/dsh-at-file"
pnpm --dir <profile> add "github:omdsh-dev/dsh-at-file" --ignore-scripts

手动恢复不依赖本插件的任何代码，是最可靠的一条路。恢复后升级到 0.3.3——此后同类故障 dsh-plugin-guard recover 确实能自动修（兜底已真正生效）。

修复清单

修复	说明
回滚兜底真正生效	兜底不再透传 spec，改钉 lockfile：^ range 解析到 lockfile 里 pinned 的版本，github: 解析到 lockfile 记录的 commit tarball——装回的一定是「原来有的那个」。裸 github spec 是移动目标（HEAD），直通会把 fail-closed 变成 fail-open：装回用户正要回滚掉的新版本、清掉证据、静默跑在被拒绝的版本上。取不到 lockfile 条目即 fail-closed，保留证据
暂停状态落盘	needsApproval 暂停此前只存在于控制台输出，marker 里没有痕迹。用户放弃批准后重启 dsh，脚本从未批准的新版本只要静态校验过得去就会被提交。现在暂停写入 marker（metadata.paused），两个恢复提交点——普通启动的 recoverProfile 与 guard launch 的缓刑提交——一律先查它，存在即回滚到安装前
任务面板	被未了结事务挡住的失败，重启后从面板撤掉（它的报错描述的是已经消失的状况）；暂停中的插件按「事务开始前」展示，更新场景不再把话说反
回滚可观测	成功的回滚此前完全静默——profile 是谁救回来的看不出来。现在回滚路径有日志
恢复指引修订	按安装源拆分、双语；主路径改为手动 pnpm add，并写明 0.3.2 的 guard recover 为何无效

升级

dsh plugin --profile web add "@1e0zj/dsh-plugin-mall@0.3.3"

pnpm 11 的 24 小时供应链策略会静默降级裸名安装，请务必带精确版本号。

0.3.2 —— 更新链路修复三连（0.2.0–0.3.1 升级失败可致 dsh 无法启动，附恢复指引）

⚠️ 2026-08-19 更正：本版的回滚修复没有生效，受影响范围实际是 0.2.0 – 0.3.2，修复随 v0.3.3 发布。

下文声称的「per-package pnpm add 兜底」在真实 profile 上从未触发过：它会拒掉 ^ range（^ 是 cmd 转义符，进了 spec 黑名单）、跳过 github: 源，而 pnpm 存的依赖几乎不是前者就是后者。因此下文「npm 包——guard recover 能自动修」不成立，0.3.2 的 guard recover 对这个故障只会 fail-closed。

若 dsh 起不来，恢复请用手动 pnpm add：照 profile package.json 里原本的写法把包装回去（npm 包带版本 range、GitHub 源用 github:owner/repo），加 --ignore-scripts，然后 dsh web。详见 README「升级后 dsh 起不来？」。0.3.3 起兜底已真正生效，guard recover 恢复可用。

---

⚠️ 0.2.0 – 0.3.1 用户请先读：升级失败可能让 dsh 无法启动

这两个版本存在一个已在 0.3.2 修复的缺陷：更新已安装的插件时，若安装走到失败回滚（最常见：目标插件带构建脚本、流程停在批准卡），回滚中「离线重建旧版本」的一步会被 pnpm 的 "Already up to date" 空转骗过——插件从 node_modules 消失而 bundles 声明还在，dsh web 报 cannot resolve profile bundle "…" 直接起不来。新装、卸载不受影响。

如果 dsh 已起不来——恢复方式取决于出问题的插件是什么安装源（看 profile package.json 里它的依赖写法）：

npm 包（"名字": "^1.2.3"）——guard recover 能自动修，也可直接装回：

# Windows PowerShell
npx -p @1e0zj/dsh-plugin-mall@0.3.2 dsh-plugin-guard recover "$env:USERPROFILE\.dsh\profiles\web"
# 或直接装回（一步恢复 + 升级；npmmirror 未同步时加 --registry=https://registry.npmjs.org）
pnpm --dir "$env:USERPROFILE\.dsh\profiles\web" add "@1e0zj/dsh-plugin-mall@0.3.2" --ignore-scripts

# Linux / macOS
npx -p @1e0zj/dsh-plugin-mall@0.3.2 dsh-plugin-guard recover ~/.dsh/profiles/web
pnpm --dir ~/.dsh/profiles/web add "@1e0zj/dsh-plugin-mall@0.3.2" --ignore-scripts

GitHub 源（"名字": "github:owner/repo"）——回滚重建不覆盖 git 依赖；若 guard recover 没能自动修复，手动联网装回：

pnpm --dir "$env:USERPROFILE\.dsh\profiles\web" add "github:owner/repo" --ignore-scripts

pnpm --dir ~/.dsh/profiles/web add "github:owner/repo" --ignore-scripts

然后 dsh web。详见 README 的「升级后 dsh 起不来？」小节。

修复清单

• 回滚重建带 per-package pnpm add 兜底：pnpm 11 的 headless 短路（--force 也绕不开）曾让「恢复旧版」静默空转，两度把 profile 留在缺包状态。兜底仅离线可用形态（semver range 与 file:/link:），仍 fail-closed。
• needsApproval 是暂停不是失败：批准等待期不再回滚（旧版回滚会造成现场漂移，approval token 的 digest 比对必死——invalid approval token: preflight report changed 的根因）；带 token 重试接管同一事务、复用原快照。
• 任务面板跨重挂载存活：安装收尾写 cordis.patch.yml 会令 dsh 重放装配树、市场 UI 整体重挂载，此前 React state 全丢——更新完成没有提醒、批准后任务消失。现在后端提供恢复通道（jobs 端点 + 日志全量累积），sessionStorage 镜像消除闪空，批准「允许并继续」由重试任务原子接管（日志连续），宿主重启后已兑现的记录自动清理。
• 此前 0.3.1 已包含：Windows 下 pnpm .cmd 路径含空格被 cmd 截断（'D:\Program' 不是内部或外部命令）的修复、spec 黑名单三处对齐补 %。

升级

dsh plugin --profile web add "@1e0zj/dsh-plugin-mall@0.3.2"

pnpm 11 的 24 小时供应链策略会静默降级裸名安装，请务必带精确版本号。