[youngslin]

方向：#1916 公共自动恢复，去掉人工弹窗

把 #1911 合法大事务校验与旧版本回执复核收进本 PR；关闭旧弹窗、前端订阅和专用 WS。BAAH 以原生完整包作为修复手段，由 auto_recover_script_install、run_managed_script_install 和公共下载安全回退决定重试、备份、健康核验、回滚与队列末尾报告。

进程未停写、目录尚存 previous/ready、损坏原生事务、身份回执不可信时禁止错误放行；只允许完成经过 PE、版本与原始文件回执确认的旧事务归档。首次新安装由公共快照保留旧版。没有可靠身份时不猜测架构、不强制下载安装。
本 PR 替代 #1911 与旧 #1900 弹窗，所有最终结论以最新 CI 和审查为准；真实 Windows 官方安装器待 E2E。

[sentry]

Bug: Incorrect constant names imported in baahInstallRecovery.ts prevent recovery dialog websocket events from being received or handled.
_{Severity: HIGH}

Suggested Fix

Update the imports and usage in frontend/src/services/baahInstallRecovery.ts to use WS_BAAH_INSTALL_PROMPT, WS_BAAH_INSTALL_PROMPT_CLOSED, and WS_BAAH_INSTALL_DECISION as defined in types.ts.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: frontend/src/services/baahInstallRecovery.ts#L7-L13

Potential issue: In `baahInstallRecovery.ts`, non-existent constants
`WS_BETTERGI_INSTALL_PROMPT`, `WS_BETTERGI_INSTALL_PROMPT_CLOSED`, and
`WS_BETTERGI_INSTALL_DECISION` are imported from `@/services/websocket/types`. Because
`types.ts` defines these constants as `WS_BAAH_INSTALL_PROMPT`,
`WS_BAAH_INSTALL_PROMPT_CLOSED`, and `WS_BAAH_INSTALL_DECISION`, the imported values
will be undefined at runtime. This causes websocket listeners to register on `undefined`
event types, preventing the frontend from ever receiving recovery prompt notifications
and leaving the backend to time out after 120 seconds.

Also affects:

• frontend/src/services/baahInstallRecovery.ts:35~35
• frontend/src/services/baahInstallRecovery.ts:46~46
• frontend/src/services/baahInstallRecovery.ts:65~65

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[sentry]

Bug: manager.py treats process busy or access errors as installation corruption, prompting unneeded recovery that subsequently fails.
_{Severity: MEDIUM}

Suggested Fix

Distinguish InstallUnsafeError resulting from running processes or permission failures from actual corruption errors. Allow busy errors to propagate or handle them separately rather than invoking ask_install_recovery.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: app/task/BAAH/manager.py#L140-L181

Potential issue: `confirm_current_install` calls `assert_idle`, which raises
`InstallUnsafeError` if BAAH or its updater is running or if process inspection yields
`AccessDenied`. The exception handler in `manager.py` catches `InstallUnsafeError`
alongside corruption errors and directly triggers `ask_install_recovery`. Users are
presented with a false report that the installation is corrupted and offered a repair,
which will immediately fail again during update execution because the process is still
running.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[jinghero]

总体结论：可以合并

AUTO-MAS-Project/AUTO-MAS #1908

宝宝，这版把修复入口放在原有安装事务恢复之后，损坏本体可以经确认重新安装，也没有给未知事务开“跳过”通道。dot酱核对了停写、取消和再次检查的链路，没有确认的合并阻断项喵；有一处低影响的翻译遗漏，顺手补上会更完整。

BAAH manager 持有安装锁并决定是否询问，恢复模块收集当前请求的选择，program_update 继续调用公共包校验与目录切换。弹窗只负责展示和发送选择，没有替后端决定安装是否安全。

规范

[规范 · P3，非阻断] 英语和日语界面的修复来源仍显示中文

install_recovery.py L31–34 和 L64–65 把“未知”“官方通道最新完整包”作为非空展示值发送，弹窗 L55–59 直接显示。切到英语或日语后，修复来源仍是中文；版本读取失败时，也用不到已经翻译好的 Unknown 词条。

这里让未知版本传空值、修复来源在前端用词条展示就够了，不必增加一套翻译协议。按钮和风险说明已经翻译，操作与安全校验不受影响，因此不阻止合并。

其余已核对的边界没有新增阻断问题。App.vue 为 256 → 258 行，新弹窗 120 行；订阅在主连接前注册，断线与主动重连都会清掉旧请求。安装结果沿用现有逐脚本终态统计，没有把点击“修复”当作安装成功，也没有上报安装路径。

规格

未确认新增缺陷。事务恢复失败会直接停止，不会进入人工放行；关闭接管仍检查安装，明确选择修复才会下载。缺失 EXE 的修复保留回执与目录身份复核、官方包大小和 SHA256 校验、原目录备份及配置保护，已知版本也不会被自动降级。

现有两条机器人意见已对照最新代码核实：前端使用的是正确的 BAAH 事件常量；进程占用检查已经移到损坏恢复的捕获块之外，不再将通常的占用失败当成损坏询问。

验证情况

读取了当前提交的 CI 日志：Windows pytest 1808 通过、2 跳过，Ubuntu 1769 通过、40 跳过；前端 57 个文件、300 项测试通过，包含重连用例。格式、类型检查和 Windows 验证包构建通过。lint 退出成功，但仍报告 QueueDeleteButton.vue 的 1 条警告，不称作零告警。

新增后端测试实际经过完整包修复和回执变化拒绝，前端测试调用真实恢复服务、替换传输边界。目标分支随后合入的 Runtime 初始化改动已做静态兼容检查，上述 CI 并未重新验证这一组合。dot酱没有自行运行项目，也没有做真实 Windows BAAH 安装、弹窗交互或深浅色验收。

规范轴 1 项非阻断 P3，规格轴 0 项确认问题。修复主线可以合，翻译这只小尾巴记得补好啦。

—— dot酱核过安装保护敬上 🐾

[jinghero]

总体结论：修改后合并

AUTO-MAS-Project/AUTO-MAS #1908

宝宝，这版已经改走公共自动恢复入口，原先弹窗的翻译意见也随删除而不再适用啦。dot酱沿着“更新、取消、下次重试、回滚”查了一圈，仍有两处会把本来能运行的安装挡住，先补好再合喵。

manager 负责持有安装锁和选择恢复入口，BAAH adapter 提供状态检查及安装回调，公共层决定重试或恢复目录。完整包校验和原生目录切换仍由 script_install 执行；问题出在这几层对“旧安装已经恢复”的判断没有完全对齐。

安装恢复

[逻辑 · P2，阻断] 回滚旧目录时没有一同还原 MAS 外置安装收据

位置：managed_recovery.py L106–109、program_update.py L287–300。

这条是静态追踪确认的可达路径，不是实机复现：

1. 更新开始切换目录后，用户取消任务。script_install 按既有保护继续确认新目录、写新版 installed.json 并清理原生 journal，随后 run_worker 才传播取消。因此 apply_update 后面的 baah-version.json 尚未写入，公共备份保留为 timed_out。
2. 下次运行从保留的 software_config 读到旧版本，不能确认新版本已经完成，于是重新安装。如果此时下载失败，公共层恢复更新前的目录。
3. 公共备份只保存 root 下的文件。installed.json 和 baah-version.json 位于 MAS 数据目录，未随旧目录恢复。after_rollback 直接调用 confirm_current_install，用新版收据校验旧文件，必然不匹配。
4. 此时公共事务已到 restored。以后只重复恢复后的检查，不再进入安装重试；网络恢复也不能自动解除阻断。

底层证据见 外置记录位置、取消后仍完成切换确认，以及目标分支的 目录备份 和 回滚检查。

这里请让 BAAH 的事务备份同时保存自己的安装、版本收据及原先不存在的状态，恢复旧目录时经身份检查一同还原，再做完整性确认。别靠跳过收据检查放行呀。补一条经过真实公共层与 adapter 的“切换后取消 → 下次离线 → 旧版恢复”用例，才能守住这个闭环。

[兼容 · P2，阻断] 健康安装的只读启动检查也拒绝内置 ADB server

位置：manager.py L188；同类检查还出现在 adapter.inspect L32–36。

只要 tools/adb/adb.exe 的 server 仍在运行，即使没有未完成事务、没有公共备份、安装健康且关闭更新接管，这里也会先调用严格 assert_idle，抛出“BAAH 或其更新器仍在运行”，后续账号任务无法开始。此前只读确认允许这个后台 server；当前 confirm_current_install 和 现有测试 L267–283 也保留了这一区别。

请让不写安装目录的健康确认继续使用 allow_background_adb=True，把严格停写要求留在真正的备份、安装和回滚边界。下载失败时检查能否沿用旧版，也不要被同一个只读检查误挡住。补 manager 层“接管关闭 + 已有内置 ADB server”的用例即可，不需要放宽真实目录切换的保护喵。

验证与复审

发布前的新提交已经补上残留 journal 测试的工作目录创建。dot酱读过上一轮 Windows、Ubuntu 日志，两边原先都在该测试写 marker 时失败，还未走到断言；这处夹具问题不再列作待修项。新提交的 Ubuntu pytest、格式检查和 Windows 验证包已通过，Windows pytest 尚在运行，不能宣称全部通过。

已核对完整改动、当前规范、原生事务、公共备份与恢复、相关调用者和测试。结果报告及统计沿用公共更新入口，没有再增加一套采集。未自行执行项目代码，也没有真实 Windows BAAH 安装验收。上面两项生产问题是新增接入路径带来的回归，补好后再看新 CI，恢复流程才算走完整啦。

—— dot酱守着回滚出口敬上 🐾

[jinghero]

总体结论：修改后合并

AUTO-MAS-Project/AUTO-MAS #1908 · 外置收据恢复复审

宝宝，目录回滚时把 installed.json 和 baah-version.json 一起恢复，这次补上了前轮的身份不匹配；只读检查也重新允许内置 ADB 常驻，原两项问题可以撤下啦。不过新加的文件线程还没有接入取消收尾保护，旧任务结束后仍可能删掉下一次更新的恢复资料，这里再补一处喵。

[逻辑 · P2，阻断] 收据线程在取消后继续运行，旧清理可能删除新事务的备份

位置：manager.py:207、215、269–285、managed_recovery.py:113–117、265–271。

新增的收据快照、恢复和清理都直接 await asyncio.to_thread。取消这个等待不会停止已经运行的文件线程；而 final_task:392–399 随后会关闭安装访问并释放目录锁。现有安装锁只会为已登记的 worker 延迟释放，这些新线程没有登记。

一个可按源码核对的时序是：

1. 更新 A 已完成公共事务结算，公共备份记录已清理。A 的 cleanup 读完、核验了旧收据快照，在第 271 行 unlink 前尚未执行。
2. 此时取消 A，等待立即结束、锁释放，但该文件线程继续存在。任务 B 可以进入同一目录，先清理 A 的残留收据快照，再建立 B 的快照并开始更新。
3. A 的旧线程恢复执行，按同一个固定路径 unlink，把 B 刚建立的收据快照删掉。若 B 后续更新失败需要回滚，程序目录虽能从公共备份恢复，after_rollback 却因外置收据备份缺失而失败，自动恢复会持续受阻。

这是取消与线程交错的静态推演，未执行故障注入。ensure_idle 检查的是外部程序是否停写，无法证明 Python 文件线程已经结束；写文件的原子替换也不能保证旧 cleanup 删除的仍是自己的事务。不是让每个 helper 都再加一把锁呀，仓库已经有对应能力。

最小修改： 让这些收据磁盘操作复用 script_install.run_worker 的登记与取消收尾，适配其取消参数，使安装访问在真实线程结束前持续保留。补一个受控阻塞收据操作、取消任务、再尝试进入同一安装的用例，确认旧线程不能在下一笔事务开始后继续写入或删除资料；保留真实公共事务和收据逻辑，别把整段恢复替换成 mock 啦。

本轮验证

正常回滚的收据恢复顺序、成功结算后的清理，以及“只读检查可留 ADB、真正换目录仍须空闲”的区分已核对。当前 8 项 CI 全绿：Windows 1838 passed、2 skipped，Ubuntu 1799 passed、40 skipped；前端 57 个文件、307 项测试通过。最新这两次提交没有增加收据线程取消场景的覆盖。

目标分支新增的 ModAVD 改动及 Runtime 版本调整已静态检查，与这条收据生命周期无直接交叉；上述 CI 早于目标分支更新，不当作新组合的运行证明。dot酱未运行项目或真实官方安装流程。把线程真正结束与锁释放的先后关系守住，刚补好的回滚资料才不会被旧任务碰掉喵。

—— dot酱替回滚资料看好门 🐾

[jinghero]

总体结论：修改后合并

AUTO-MAS-Project/AUTO-MAS #1908 · 收据线程取消复审

宝宝，这次把收据快照、恢复和清理的五处调用都接到了 run_worker，原先“任务已结束，旧线程还会碰下一轮收据”的 P2 可以撤下啦。dot酱核对了实际安装访问链：普通取消会等待线程；即使任务清理期限已到、调用协程先返回，安装锁也会保留到真实 worker 结束。恢复两份收据时不在中途响应取消，这个处理也保住了恢复顺序喵。

[规范 · P3，阻断] 新测试文件未通过仓库格式检查

位置：test_baah_program_update.py:396–418。

本次格式 CI 日志已明确报错：测试函数前少一行空行，创建 pending 的表达式应由固定版本 ruff 收成一行，最终以退出码 1 结束。这不是运行逻辑缺陷，不过必需检查还没过，先把这一小处整理好。

按仓库锁定环境运行 uv run --no-sync ruff format tests/task/test_baah_program_update.py，确认只调整本次测试，再让格式检查通过即可；不用为它改恢复逻辑或放宽检查。

新增测试保留了真实收据函数和安装访问机制，能检查线程存活时拒绝重入、取消后保留收据、线程结束后再次清理。它直接调用 worker，尚未覆盖 manager 的五处接线；同进程重入断言也不等于实测跨进程锁，这些是覆盖范围，不再另列阻断项。

已读 Ubuntu CI 日志：1800 项通过、40 项跳过；发布前 Windows 测试仍在运行，不能把本轮说成全绿。其余已完成检查通过。没有确认新的生产缺陷，本次未运行项目代码、测试或真实安装流程。把格式门槛补齐，再等 Windows 结果，收据取消这条问题就可以收尾啦。

—— dot酱收好爪印敬上 🐾

[jinghero]

总体结论：可以合并

AUTO-MAS-Project/AUTO-MAS #1908 · 格式修复复审

宝宝，刚才卡住 CI 的两处格式已经按 ruff 的输出改好了，最新 CI 的“检查 Python 格式”步骤也已通过。原 P3 可以撤下，dot酱没有新的必须修改项啦。

这次仅调整测试空行和表达式换行，没有修改生产代码或测试行为。前轮确认的收据 worker 登记、取消等待及安装锁延迟释放都保持有效，不需要再改恢复逻辑喵。目标分支新合入的其他专项恢复没有改动这条公共安装保护链。

最新一轮完整格式任务、Python 测试和构建发布前仍在进行，不能拿已通过的一个步骤代替整轮结果。上一版相同运行逻辑的 CI 为 Windows 1839 项通过、2 项跳过，Ubuntu 1800 项通过、40 项跳过；这些数字不是新提交的运行结果。按已核对的改动可以合并，仍需等仓库要求的当前 CI 完成。

本轮只做静态差异与现有 CI 核对，没有自行运行项目或真实安装流程。

—— dot酱拍拍爪敬上 🐾