DeepSeek Harness 桌面端更新失败不会自动回滚：更新与插件包操作在停止 Host 后直接修改当前 profile，失败时保留已修改的文件并报告错误，未完成的操作留下标记供下次启动重试（来源）。
「更新失败」在桌面端有两类：一类是应用自身的更新失败，另一类是更新应用时顺带触发的插件包操作失败。本篇讲这两类失败在桌面端的恢复语义——为什么不回滚、加载页和错误页给什么、重置 Desktop 的代价到底多大。如果你用的是命令行安装方式，失败处理完全不同，见《DSH 更新失败怎么解决》。
DeepSeek Harness 桌面端更新失败为什么不回滚
桌面端不创建 staging 目录、激活日志或回滚副本，它选择「直接改 + 可重试」而不是「改不动就退回」，所以失败的代价是保留现场并等待下一次启动收敛（来源）。
理解这套语义要看五个动作：
停止 Host 后直接改当前 profile — 插件变更不复制到临时目录，而是在当前 profile 上就地执行。预期：改动的就是最终生效的位置，没有「激活」这一步。
失败保留已修改文件并报告错误 — 操作中断时不清理、不还原，错误信息指向失败的那一步。预期：你能看到到底卡在装依赖、链接还是构建。
未完成操作留标记，下次启动重试 — App 启动时会对 profile 运行事务恢复。预期：重新打开应用后，桌面端自动尝试完成或收敛上次的操作，不需要你手动删文件。
没有 staging 目录可回退 — 桌面端不建 staging 目录、不写激活日志、不留回滚副本。预期：界面上找不到「回滚到上一版」的按钮，也别自己手工拼一个来用。
事务锁把并发挡在外面 — 包事务独占持有 $DSH_HOME/profiles/desktop/lock 直到 pnpm 进程退出。预期：另一个进程想改同一个 profile 只能等待，而不是两边同时写坏。
这套「不回滚」与命令行安装方式恰好相反：CLI 侧失败通常靠锁版本或重装收敛，见《DSH 更新失败怎么解决》。桌面端的选择是保留现场，让下一次启动自己收敛。
DeepSeek Harness 桌面端加载页和错误页提供哪些恢复操作
加载页不依赖 Host，所以 Host 起不来它也能显示，并给出重启与重装指导；错误页则给出可用的恢复操作，只有已打包应用的资源支持恢复时，才会提供「禁用插件」和「重置 Desktop」（来源）。
按代价从小到大走这五步：
先重启应用 — 关掉再打开，让启动时的事务恢复有机会处理未完成操作。预期：多数可自愈的失败在这一步就恢复。
读错误页的恢复指引 — 错误页会列出当前可用的恢复动作，照着做。预期：知道下一步该禁用插件还是该重装。
禁用插件自查 — 如果有「禁用插件」，先用它把插件停下再启动，判断是不是某个 DSH plugin 把启动搞挂。预期：能启动 = 问题指向插件；仍失败 = 问题在更底层。
做一次只读体检 — 在终端 ls -l "$DSH_HOME/profiles/desktop" 看目录结构、cat "$DSH_HOME/profiles/desktop/package.json" 看依赖清单是否完整。预期：能分清是依赖缺失还是共享链接失效，再决定下一步动作。
重装应用 — 按加载页的重装指导重新安装桌面端。预期：安装到同一位置后继续使用原有 profile 数据，而不是从零开始。