[youngslin]

方向调整：改为 #1916 公共自动恢复

此 PR 原来基于 #1900 的弹窗方案。现已移除奇想盒专有 WebSocket 弹窗、前端常驻订阅和用户选择，改由 #1916 的统一后端入口执行健康性检查、备份、自动重试及可验证回滚。原生 GUI 配置/修复入口仍可打开，但不会因此绕过自动任务的安装保护。

具体实现

• 正常更新：只读下载/准备完成后，通过 run_managed_script_install 创建旧版快照并运行官方 pip wheel 安装；安装结果由公共层汇总。
• 已有跨任务备份：优先恢复公共事务；下次先检查真实 pip/包入口和版本，确认上次已成功则清理备份，否则重试，只有进程全部停写且原快照通过完整性校验才允许回滚。
• 老版本留下的 .mas-update-pending：无可信更新前快照，只能走公共 auto_recover_script_install 的健康核验或强制重装，不能虚构可回滚旧版。
• 任务末尾错误汇总交给 脚本更新：新增统一自动恢复与持久备份回滚机制 #1916；不再使用脚本自带的弹窗服务。
• 保留 skip_pending_installation 的依赖完整性检查作为公共 acknowledge 所用的专项安全操作。
• 原前端 modal / websocket / 语言包以及旧弹窗测试已删除，补了公共恢复路径与残留标记回归测试。

必须注意的合并顺序

本分支已通过双父提交显式叠加 #1916 的实现，因此合并顺序必须为 #1916 先进入 dev，本 PR 后合并。在公共 PR 合并前，这个 PR 的差异会暂时显示公共文件；不能单独将本 PR 作为独立功能合并，也不能因为公共回归测试存在就认定真实 pip 安装端到端通过。

最新 CI 以 PR 最新提交为准。

[jinghero]

总体结论：修改后合并

AUTO-MAS-Project/AUTO-MAS #1905

宝宝，奇想盒这次按 wheel/pip 的安装方式处理恢复，没有把 BetterGI 的安装逻辑硬套过来。重试、跳过、取消和目标标识都接上了，但把同一门槛放到原生配置入口前，会挡住原本用来修环境的官方 GUI。这处产品边界需要先处理喵。

规范

[规范与行为 · P2] 未完成后端安装不应堵住原生 GUI 修复出口

位置：manager.py:186–198，影响后面的 ScriptConfig 分支:216–224。

项目的奇想盒专项约定明确保留了一个区别：配置会话只要求 whimbox_app.exe，后端未初始化也应能打开官方 app 修环境。现有 check() 和 ScriptConfigTask 也确实这样实现，配置会话只是启动官方壳，不是启动一条龙。

现在只要有 .mas-update-pending，配置会话也必须先完成恢复。安装中断后依赖损坏、自动重试又因下载失败等原因无法完成时，“跳过”会被健康检查拒绝，“取消”直接结束任务，官方 GUI 始终打不开。用户只能离开 MAS 另找程序启动，原有修复出口被收窄了。

PR 正文确实写了“打开界面之前统一检测”，所以这不是实现漏按正文做，而是新行为与已有专项规范冲突。请为配置会话保留明确的“打开官方 app 修复”路径，继续持有必要的进程和安装互斥，不清除失败标记，也不启动自动任务；或者先由维护者明确调整这项产品约定。恢复流程不能要求用户先修好，才让他打开修复工具呀。

其他规范未确认新增阻断项：App.vue 为 256→259 行，新弹窗 133 行；沿用 Ant Design Vue、共享标题栏避让和三语言词条。遥测复用现有任务终态，名称与目录没有加入埋点。

规格

按本 PR 正文核对，未确认其他新增 P1/P2：

• 有标记时 updater 不依赖残留包版本，走完整校验与强制重装；关闭接管仍可单次重试，恢复后不会再自动更新一遍。
• skip 在检查前后核对进程和同一份标记；清标记后的复核失败或取消会尝试恢复记录。没有主界面、超时或取消不会默认放行。
• 弹窗明确显示托管与目录，选择按请求 ID 关联，断线清除旧选择。

有一个表述边界请顺手说准确：find_spec 只证明模块入口可定位，pip check 检查已安装发行包的依赖关系，不等于真正导入主模块或验证所有文件。界面已提示这项完整性风险，dot酱没有将它重复记作缺陷。

验证

当前提交的 Windows pytest、Ubuntu pytest、前端格式/typecheck/测试和 Windows 验证包构建均通过，已读取相关日志。新增用例覆盖 skip、失败保留标记、关闭接管重试及提示目标，但没有覆盖上述 ScriptConfig 修复出口。

本轮仅静态审查与读取既有 CI，未运行项目、测试、真实安装器或 Electron 界面。CI 不能代替真实 Windows 安装恢复、弹窗排队和断线交互验证。规范轴 1 项 P2，规格轴未确认其他阻断项。

—— dot酱给修复入口留条路敬上 🐾

[jinghero]

总体结论：可以合并

AUTO-MAS-Project/AUTO-MAS #1905 · 修复复审

宝宝，官方 app 的修复入口这次留住啦，而且没有顺手清掉安装保护。审查中补到的主动重连清理也已纳入最新代码，dot酱核对后没有确认的必须修改项喵。这个结论是代码审查建议，最新提交的 CI 尚未跑完，合并前仍需确认门禁结果。

规范

前次 P2 已修复。manager.py L191–233 只在 ScriptConfig 提供“打开官方 app 修复”，选择后保留标记、沿用安装锁并进入真实 ScriptConfigTask，随后直接返回，不落入自动任务。后端接收动作时和 manager 都会核对模式，原生 GUI 修环境的出口与安装保护可以同时保留啦。

恢复服务 L54–59 现在也在 onConnected 清空旧询问与 pending，退出时成对注销。已沿真实 connection.onopen 核对：清理回调同步执行，之后才处理新连接的消息，覆盖了主动换连接不触发 disconnected、关闭帧又丢失的情况。

App.vue 为 256→259 行，恢复弹窗从 133 增至 140 行，未超限；新按钮有中英日词条，继续沿用官方启动入口，没有另做一套修复器。

规格

未确认剩余阻断项。重试、跳过仍受安装状态检查约束；repair_gui 只允许配置会话打开官方 app，不会把“打开界面”记成安装已修复。后续自动任务仍须处理保留的标记，这处界限没有放松喵。

验证情况

仅静态审查并读取已有 CI，没有运行项目、官方 app 或真实 UI。前一版已有日志显示 Windows pytest 1815 通过、Ubuntu 1776 通过，前端 56 个文件共 299 项测试通过，格式、类型与验证包构建通过。之后新增了重连回归测试并调整格式，不能把前一版结果当作最新版通过，还需等本次 CI 完成；真实 Windows GUI/UAC 修复流程仍未取得 E2E 证据。

新增测试调用真实恢复服务、仅替换传输边界，覆盖旧请求被清理及新请求仍能操作；GUI 分支测试替换了 spawn，只证明派发和标记保留，不证明真实程序已启动。

规范轴 0 项确认问题，规格轴 0 项确认问题。这轮把修复出口和旧弹窗都处理清楚了，拍拍爪喵。

—— dot酱核过修复出口敬上 🐾

[jinghero]

总体结论：修改后合并

AUTO-MAS-Project/AUTO-MAS #1905 · 自动恢复改版复审

宝宝，这版已把人工弹窗换成公共自动恢复，官方 app 的修复入口也保留了。可是实际入口多拿了一次同一把锁，任务还没走到恢复逻辑就会退出。dot酱先把这处拦下来喵，另外还有准备失败和下载缓存清理的两处回归要一起补上。

Whimbox manager 负责安排更新与账号任务，适配器提供 pip 安装、进程和版本检查，公共层负责快照、重试、回滚与队列末尾汇总。当前 PR 包含叠加的公共实现，已核对它与 #1916 已审代码一致；以下问题来自 Whimbox 接入部分。

规格与功能

1. [逻辑 · P1] 实际入口重复取得非重入安装锁，自动任务和配置会话都无法启动

位置：manager.py:187–189、update.py:125–129。

main_task 先进入 Whimbox 的 installation_access(root)，它内部已经取得公共 script_install.installation_access(root)；同一行又单独进入一次公共锁。公共实现每次打开新句柄，以非阻塞方式取得同一目录的排他锁，没有重入机制，因此第二次会立即抛出 InstallUnsafeError。任何通过 check/prepare 的 AutoProxy、ScriptConfig 都到不了 _run_prepared，连打开官方 app 修环境也受影响。

这里不需要增加锁管理啦，去掉 manager 多出来的那次公共取锁，保留原包装器及其完整生命周期即可。请用真实 main_task 入口守护这一点；现有新增测试直接调用 _run_prepared，绕开了出错位置。

2. [兼容 · P2] 更新准备失败会中断健康旧版任务，原有安全回退被删掉

位置：manager.py:241–249。

修好上面的锁后，无旧事务、无 pending 标记且开启运行前更新时，release 查询、下载或只读依赖准备一旦因网络失败，prepare_update 的异常直接传出。此时还没进入后面的公共安装事务，run_script_update 也只负责调用，不会替它恢复旧版，整批账号因此停止。

目标分支原本会先排除取消和未确认停写等不安全情况，再调用 confirm_usable_installation；确认旧安装健康后告警继续。本次同时删掉了这段逻辑和 test_preparation_failure_warns_and_continues。自动恢复想减少人工操作，别让一次下载故障反而挡住还能用的旧版呀。

请在“尚未开始安装写盘”的准备边界恢复这项能力。可复用已经引入的公共安全回退入口，明确区分可回退的下载失败，验证旧安装并加入任务末尾汇总。取消、后台停写未确认、有残留标记或健康检查失败仍须阻断，不能把安装阶段异常也一概吞掉。

3. [逻辑 · P2] 建立备份失败或取消时，已下载的 wheel 与依赖缓存无人清理

位置：manager.py:244–271。

manager 先把 _update_candidate 清空，再调用公共安装入口，但 discard_update(candidate) 写在 await 成功返回之后。公共层会先检查安装并建立完整备份，随后才调用适配器安装。例如备份磁盘空间不足，或用户在备份期间取消，异常会直接跳过第 271 行；安装回调尚未执行，apply_update 的 finally 也帮不上忙。后续会话清理只能看到 None，已经下载到 download-* 的 wheel 和依赖包就留在磁盘上，反复重试会继续累积。

这里把候选包的使用围在 try/finally 里就好，finally 仍调用既有 discard_update。这个函数已有“写入进程未确认停止时保留缓存”的保护，不必另造一套清理机制。请补“包准备完成、备份失败”和“备份期间取消”的清理断言，别让下载缓存悄悄占满磁盘喵。

规范与验证

专项仍通过官方 app/pip 入口工作，未新增游戏行为推断；恢复决策交给公共层，没有确认需要另做抽象的架构问题。原先 GUI 修复出口的健康门槛已移除，旧 marker 成功测试也已正确模拟清标记，这些不再重复列问题。规范轴未确认新增阻断项，规格轴有以上 1 项 P1、2 项 P2。

本轮仅静态审查并读取既有 CI，没有运行项目、测试或安装器。当前提交的格式、类型检查、前端 57 个文件共 307 项测试及 Windows 验证包构建已通过，Windows/Ubuntu pytest 尚在运行。绿色测试也不能证明绕过 main_task 的用例覆盖了入口锁，建议先补这三条真实失败路径，再确认最终 CI。实际 Windows pip 恢复与官方 GUI 的端到端行为仍无独立执行证据。

—— dot酱看住入口与收尾敬上 🐾

[jinghero]

总体结论：可以合并

AUTO-MAS-Project/AUTO-MAS #1905 · 修复复审

宝宝，入口和收尾这次都补到了实际调用路径，前次 1 项 P1、2 项 P2 已修复。dot酱核对后，没有剩余的运行时阻断项喵。最新提交的 CI 仍在执行，这个结论是代码审查建议，合并前还需确认本轮门禁完成。

manager.py现在只进入一次既有安装锁；准备失败交给公共安全回退，确认没有旧备份事务且原安装健康后才继续；已下载包的清理放进 finally，备份失败和取消也能执行。取消、未确认停写和不安全安装异常仍会上抛，没有为了继续任务而抹掉这些保护。公共自动恢复实现已进入 dev，也已核对本分支叠加的公共代码与它一致。

新增测试这回真正经过 main_task 的文件锁，并检查退出后能再次取锁；准备失败用例经过公共 fallback；备份失败和取消用例检查真实下载缓存已删除。后两类仍替换了健康探针或公共安装回调，只证明相应编排和收尾，不能当作真实 pip 安装验证，边界要说清楚呀。

有一项非阻断类型建议：准备函数返回 PreparedUpdate | str，而公共 run_script_update_with_safe_fallback 的注解仍限定只返回 str。运行时可以透传安装包对象，但签名没有表达这个实际用法。可沿用公共模块已有的 T，让 operation 返回 T、helper 返回 T | str，不必另加封装，也不要用强制类型转换藏掉差异。

规范轴未确认新增阻断项，规格轴的三项旧缺陷均已解除。较早提交的 Ruff 失败已对应调整，不能继续算在当前提交上；最新格式检查已通过，pytest 和验证包任务仍在运行。dot酱仅做静态审查并读取 CI 状态，没有运行项目、测试或真实 Windows GUI/pip 流程，待本轮结果齐了再确认最终绿灯喵。

—— dot酱核过入口与清理敬上 🐾