[youngslin]

方向：仅采用 #1916 公共恢复

整合旧 #1910 的可信 program-identity.json、官方完整包下载与校验；以及 #1913 的原生 transaction.json/previous/ready 安全性检查。删除所有恢复弹窗、专用 WS 及“用户确认跳过”。恢复由 auto_recover_script_install 接收健康检查、原生回滚和官方完整包修复回调，主流程保持安装锁及原生 MXU 清理机制。

只有确认原生进程停止、完整发行文件和回执一致、且没有尚可回滚的 previous/ready，才允许归档过期事务。不可读架构、缺少 MAS 自有身份时绝不猜测官方安装目标。关闭托管的自定义构建遵守既有 MXU 行为，不强行覆盖。自动恢复结果交公共队列末尾汇总。

本轮补充：安装器复制 ready 后、写入 transaction.json 前失败或取消时，在没有 journal/previous、确认停写和持有安装锁的条件下可清理未提交暂存。若原安装健康，核验收据后清理；若 EXE 损坏或因 MXU 独立升级导致旧收据失效，仅允许 AutoProxy + 开启托管 + MAS 可信 program-identity.json 的修复请求清理暂存，随后必须由 #1916 公共入口执行官方完整包重装与最终健康复核。身份缺失、previous 或 journal 存在时继续保留现场并阻断，不能把清理暂存当作恢复成功。回归测试包含真实安装器的 ready 阶段故障注入、两类受控自动修复，以及缺乏可信身份时拒绝清理。

本 PR 取代 #1910；未运行真实 MXU/Electron E2E，CI 以最新提交为准。

[sentry]

Bug: Recovery path sets self._program_update_prepared = True, bypassing discard_obsolete_mxu_packages and risking MXU overwriting the current install with a stale pending package.
_{Severity: LOW}

Suggested Fix

On the recovery path, bypass only the download and apply steps rather than marking the entire update preparation complete, ensuring discard_obsolete_mxu_packages is still executed.

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/MaaEnd/manager.py#L529-L530

Potential issue: After recovering an install in `main_task`,
`self._program_update_prepared` is set to `True`, causing subsequent calls to
`_prepare_program_update` to return early. This skips `discard_obsolete_mxu_packages`,
which is required to run after install verification and before MXU launches. If an
interrupted update or manual repair leaves an obsolete package in the cache alongside a
stale pending record, MXU may overwrite the current installation upon launch.

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

[sentry]

Bug: skip_stale_transaction unconditionally validates installed.json without checking takeover_enabled, blocking skips when an install was manually repaired with takeover disabled.
_{Severity: MEDIUM}

Suggested Fix

Pass takeover_enabled into skip_stale_transaction and only enforce receipt verification via verify_installed_files and confirm_current_install(verify_receipt=...) when takeover is enabled.

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/MaaEnd/tools/install_recovery.py#L151-L157

Potential issue: `skip_stale_transaction` unconditionally verifies the MAS receipt if
`installed.json` exists via `verify_installed_files` and `confirm_current_install(root,
verify_receipt=True)`. Unlike other paths such as retry and non-takeover flows, it does
not check `config.Update.TakeoverEnabled`. If a user repairs or upgrades an installation
using MXU or manual methods and disables takeover, the receipt check fails, rolling back
the archived marker and preventing the user from skipping the stale transaction.

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

[jinghero]

总体结论：修改后合并

AUTO-MAS-Project/AUTO-MAS #1913

宝宝，关闭托管时不再拿旧回执卡住人工修复，恢复后也保留了原有资源刷新，这两处处理得很实在喵。不过还有两处会让用户走不到恢复按钮：正常事务文件可能超过新上限，原生配置会话的遮罩也会挡住弹窗。先补好这两条入口再合。

管理器继续先尝试通用事务恢复；专项模块只负责询问、核验和归档旧记录，目录切换仍由原安装器承担，没有读取 MXU 私有 pending 数据。下面两项是静态调用链确认的问题，并非真实安装复现。

规格

[逻辑 · P2，阻断] 正常安装器生成的事务文件会被 64 KiB 上限拒绝

install_recovery.py:58–60在发送提示前直接拒绝较大的事务文件，确认时第 40 行又拒绝一次。但现有 script_install.py:602–608记录的是三套文件路径与 SHA256，且完整目录快照包含保留的配置、日志。这不是一个只有几项字段的小标记。MaaEnd v3.0.0 固定源码树内有 2375 个资源图片文件，官方发行构建器会把 assets 复制进安装包；仅一套图片哈希字符已达 152000 字节，还没算路径和另外两套清单。这是源码与打包流程核算，未下载或运行发行包。

例如安装器已写回执、删完 previous，但尚未删 journal时中断，用户随后从原生程序运行或修复，日志、配置发生变化；下次全目录快照不匹配，便需要本 PR 的人工确认。即使程序和分发文件仍完好，且没有 previous/ready，过大的原始 journal 也会在弹窗前被拒绝，重试和跳过都用不了。

请让新增恢复模块兼容现有 事务写入器 的真实输出，移除没有对应写入约束的 64 KiB 限制，或使用能覆盖正常大小的流式摘要与快照身份核验，保留原有防替换和备份检查。测试请用现有 事务写入器 生成包含正常资源、日志规模的大记录，别只用几字节的假标记啦。

[兼容 · P2，阻断] 原生配置会话的等待遮罩盖住恢复选择

新 MaaEndInstallRecoveryModal.vue:38使用 z-index 900。账号配置入口拿到任务 ID 后，既有会话工具马上显示传送到 body、z-index 1000 的 GuiSessionMask。脚本级配置页也有直接传送到 body 的 z-index 9999 遮罩，同样在受理后就打开。与此同时，manager.py:500–514对 ScriptConfig 也先等恢复选择，尚未启动原生窗口。

因此安装事务恢复失败时，用户看到的是配置会话遮罩，下面的重试、风险勾选和取消都点不到，只能结束会话或等 120 秒超时。自动代理入口没有这个遮罩，不能据此认定配置入口也可用。请协调恢复询问与原生会话遮罩的显示时机或层级，兼顾这两个配置入口，而非只改到 1001；保留窗口标题栏可用，并补一个从配置入口触发事务失败的交互验证。

规范

[规范 · P3，非阻断] install_recovery.py:70把读取失败的版本写成非空中文“未知”，英文、日文弹窗的兜底翻译不会生效。这里返回空值，交给前端现有词条就好喵。

没有确认新增职责或黑箱边界违规；主动重连会清掉旧询问，取消、超时和无主连接保留事务。已有任务终态观察可以继续复用，无需为辅助询问再做一套统计。

验证情况

已读取现有 CI：8 项检查通过，Windows pytest 1812 passed、2 skipped，Ubuntu 1773 passed、40 skipped，前端 57 个测试文件、307 个测试通过，Windows 验证包构建通过。这些结果没有覆盖上述大事务文件与配置遮罩场景，不能替代对应验证。

dot酱没有运行项目代码、测试或真实 Windows MaaEnd/Electron 流程。规格侧 2 个必须修复的 P2，规范侧 1 个非阻断 P3；把用户真正能选到恢复动作这一步补齐，就离目标更近啦。

—— dot酱替恢复按钮留条路敬上 🐾

[jinghero]

总体结论：修改后合并

AUTO-MAS-Project/AUTO-MAS #1913 · 容量修复复审

宝宝，事务文件的两处限制已一起放宽到 128 MiB，前次正常资源清单超过 64 KiB 就被拒绝的 P2 已修复啦。不过配置会话仍会把恢复弹窗盖住，这一项还不能放行喵。

[兼容 · P2，阻断] 原生配置会话遮罩仍挡住恢复按钮。 当前 恢复弹窗仍为 z-index 900；账号配置的 GuiSessionMask 传送到 body 后为 1000，脚本配置页传送到 body 的遮罩为 9999。本次只改了后端容量常量，两个配置入口等待恢复选择时的层级关系没有变化。

请协调这两个配置会话遮罩与恢复询问的显示时机或层级，并保留窗口标题栏可用。仅改到 1001 还不足以覆盖脚本配置页。完整触发链见前次评论的第二项，dot酱就不把整段再贴一遍啦。

规格轴现剩 1 项阻断 P2；规范轴“未知”未本地化的 P3 仍是非阻断项。容量调整未改变标记一致性、备份存在、停写与安装回执保护，没有确认其他新增问题。

当前 CI 8 项成功，已读日志：Windows 1812 passed、2 skipped，Ubuntu 1773 passed、40 skipped，前端 57 个文件、307 项测试通过。此次仍是静态审查与读取既有 CI，未运行项目或真实 UI；现有通过结果没有覆盖配置遮罩场景。容量这关过了，再让用户真正点得到恢复按钮就好喵。

—— dot酱继续看着恢复按钮敬上 🐾

[jinghero]

总体结论：修改后合并

AUTO-MAS-Project/AUTO-MAS #1913

宝宝，旧恢复弹窗已经删除，遮罩和未知版本词条的问题随之不再适用；大事务记录的容量保护也保留了。恢复后继续刷新资源、清理过期 MXU 包这条线没有漏掉喵。不过新接入把“安装必须健康”的检查放到了修复之前，原本能靠更新接管修好的目录，现在反而到不了修复入口。

manager 负责持锁和安排恢复，adapter 提供原生事务检查及官方包修复回调，真正的下载、校验和目录切换仍复用原实现。公共层决定是否调用这些回调，下面两道检查必须一起对齐。

[逻辑 · P2，阻断] 无残留 journal 的损坏安装会提前退出，新的完整包修复回调也不会被公共层调用

位置：manager.py L505–533、managed_recovery.py L88–96。

静态可核对的场景：开启更新接管的 AutoProxy，之前已成功安装并留下 MAS 身份与安装收据，没有未完成的 transaction.json，后来 MaaEnd.exe 或发行资源损坏。main_task 先无条件调用 retry_native。它恢复原生事务之后，马上调用严格的 confirm_current_install；损坏 EXE 或收据哈希不匹配都会抛 InstallUnsafeError。manager 发现没有 journal，就直接重新抛出，后面的可信身份修复和 _prepare_program_update 都执行不到，已经预下载的修复包也用不上。

这也是对原有行为的回归。原入口只先恢复事务，再让更新准备按已有 program-identity 修复；现有测试 L511–521也明确支持按记录架构重装损坏 EXE。MXU 独立升级后旧收据失效时，同一道提前检查还会挡住原有的精确版本官方包重新校验流程。

还不能只把这道检查往后挪呀。新身份修复分支明确要求 not state.healthy and not state.pending，但当前目标分支的 reconcile_installation L110–111 对 pending=False 立即返回 no_pending，不会调用 reinstall。按当前 adapter 状态，repair_program 仍然不会执行，却会被 manager 记录成“自动修复”。

最小修改是把“恢复原生事务”和“修复完成后的健康确认”分开，让有可信身份的损坏安装能进入既有修复链；同时按公共入口实际支持的状态契约表达这种无 journal 的待修复状态，成功后再确认安装健康。保留停写、架构身份、回执和下载期间身份变化检查，不要靠放宽最终校验让它通过。

请补经过真实 manager、adapter 和公共恢复层的用例：无 journal、有可信身份、损坏 EXE／资源时确实调用完整包修复并恢复健康；再覆盖 MXU 原生升级造成旧收据失效的情况。当前新增测试主要直接检查 adapter 的残留 journal，已有重装测试又直接调用更新函数，都绕开了出问题的入口顺序。

现有 CI 全部成功，日志为 Windows 1837 passed、2 skipped，Ubuntu 1798 passed、40 skipped，前端 57 个文件、307 项测试通过，格式、类型和 Windows 验证包也通过。dot酱未运行项目或真实 MXU/Electron 流程，以上结论来自固定源码、真实公共接口和调用顺序核对。取消收尾与安装锁仍沿用底层保护，关闭接管时容忍原生修复后的旧收据也按既定设计保留，不要求它改回强制覆盖。

最后顺手把更新日志中的“人工确认恢复入口”换成当前自动恢复行为，别让使用者还去找旧按钮啦。先把这条修复入口真正接通，再合就稳妥了喵。

—— dot酱检查修复入口敬上 🐾

[jinghero]

总体结论：修改后合并

AUTO-MAS-Project/AUTO-MAS #1913

宝宝，上次挡住修复的两道门这回接通啦：先恢复原生事务，再把可信损坏安装交给公共恢复入口；可识别的 MXU 新版本也保留了精确官方包校验，没有拿旧收据强行降级。新增测试还走到了真实 manager、adapter 和公共层，这点补得好喵。不过新的 pending 判断又挡住了另一种正常恢复场景，另有一处格式检查需要修好。

[逻辑 · P2，阻断] 更新在目录切换前取消后，遗留 ready 会让之后的任务一直无法启动

位置：manager.py L537–542、managed_recovery.py L28–36。

静态可核对的场景：用户曾成功托管安装，已有 program-identity，随后更新到更高版本。安装器 L566先创建 ready 暂存目录，到 L608 才写 transaction.json；中间复制或资源处理失败、响应取消，都会留下 ready，此时原安装还没有被替换。

下一轮 recover_native 调用的 recover_install L454–458发现没有 journal、也没有 previous，正常返回。可 adapter 只要看见 ready 就报告 pending=True、healthy=False，新 manager 随即抛出“尚有未完成原生事务”。于是，即使原安装完好，也进不了正常更新，更到不了安装器 L555–558已有的暂存清理与重试。重启也不会移除磁盘上的 ready。上一版仍会进入正常更新，这次新增的拒绝分支才把这条路封住了。

请区分“没有 journal/previous 的未提交暂存”和真正已经开始切换的事务，让前者在持锁、停写和当前安装核验下复用安装层的安全清理或重试，别把 previous/journal 的保护一起放松呀。验收可在真实安装器创建 ready 后、写 journal 前注入取消或失败，再走一次 manager，确认能继续恢复。现有重试测试在 verify_archive 就失败，新增两条 manager 测试也没有暂存残留，尚未覆盖这一步。

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

格式 CI执行 ruff format --check 后以 exit 1 结束，定位到 tests/task/test_maaend_program_update.py 的长断言和末尾空行。按仓库格式化规则处理该文件，再让此项通过就好，不用改断言语义喵。

本轮是固定源码复核与读取已有 CI，dot酱没有运行项目代码或真实 MXU/Electron 流程。发布前 Ubuntu pytest 已通过，Windows pytest 仍在运行，Windows 验证包及其余已完成检查成功；绿色结果也不能代替上面的暂存残留场景。先给取消后的重试留条路，这次修复才不会修着修着又把用户挡在门外啦。

—— dot酱替重试留路敬上 🐾

[jinghero]

总体结论：修改后合并

AUTO-MAS-Project/AUTO-MAS #1913 · 暂存清理复审

宝宝，健康旧安装留下 ready 的那条路已经打通了，真实安装器故障注入也补上了，格式检查这次通过啦。不过还差“本来就在修复坏安装”的情况：新清理要求原安装先健康，结果修复中断一次，下一轮又进不了修复。dot酱把剩下这个场景单独说明，不重复上一条的完整调用链喵。

[逻辑 · P2，阻断] 损坏安装或失效旧收据的修复中断后，仍无法再次进入官方重装

位置：managed_recovery.py L43–49、manager.py L505–511。

静态可核对的输入是已有可信 program-identity、开启接管，EXE 已损坏；或者 MXU 正常升级后，旧 MAS 收据已经不匹配。这两条正是本 PR 已支持、也新增了真实 manager 测试的修复入口。

首次修复走到安装器，复制 ready 后、写 transaction.json 前异常或取消，原目录仍保留修复前的不健康状态。下一轮 recover_native 先执行新增清理：坏 EXE 在 read_install 处抛错，失效旧收据在 verify_installed_files 处被拒绝。没有 journal，manager 直接退出，后面的 inspect_repair → repair_program 根本到不了；反复运行仍会卡住。

请让有可信身份、允许接管的这类安装继续走既有官方重装。保留 journal/previous、路径安全、停写和持锁保护，最终健康仍由重装后的检查确认，不能放行损坏程序。已有安装器暂存清理可以复用；若选择保留暂存，也要给这类状态安排可达的重装路径，只吞掉清理异常还不够，后面的 ready/pending 判断仍会拦截呀。

新正向测试从健康安装出发，只证明该场景能重试；invalid-original 测试则只断言拒绝清理，没有证明还能修复。把已有损坏 EXE／原生升级旧收据的 manager 测试与这次 ready 后故障注入组合起来，再启动下一轮，检查最终健康和原配置保留，就能直接守住这个缺口，不用扩大成真实游戏测试啦。

dot酱未运行项目或上游程序。已读取当前格式 CI，Python 格式及前端 307 项测试通过；发布前 Windows 验证包已通过，双平台 pytest 仍在运行。上一轮的 P2 现在只剩上述修复中断场景，健康旧版清理的改进是有效的。

—— dot酱继续替修复留路敬上 🐾

[jinghero]

总体结论：可以合并

AUTO-MAS-Project/AUTO-MAS #1913 · 修复中断复审

宝宝，这次损坏安装的重试终于走通啦。上轮 P2 已修复：未提交的暂存可以先清理，原安装仍须经过官方重装和最终健康检查，不能靠删掉 ready 就算成功。dot酱核对了这两步之间的调用链，这轮没有确认必须修改的新问题喵。

manager 的入口只给 AutoProxy 且开启接管的任务开放损坏修复；清理函数还要求可信 MAS 安装身份，并保留 journal、previous、链接、停写和取消检查。清理后重新检查安装，再由公共恢复入口调用官方包修复。缺少身份时仍保留现场，配置会话和非接管模式也没有被顺带放宽，这条边界守住了。

新增回归这次抓到了出问题的时机：真实安装器完成 ready 复制后注入失败，再从真实 manager、adapter 和公共层重跑。损坏 EXE 用例检查恢复后的版本、回执和用户配置；MXU 高版本旧收据用例检查精确版本重装，没有退回旧版本。健康旧版的暂存清理及缺少身份时拒绝清理也继续覆盖，不用再为这个场景加一套恢复框架啦。

dot酱做的是静态复审与读取已有 CI，没有运行项目或真实 MXU/Electron 流程。当前 Ubuntu 为 1835 passed、40 skipped；格式检查通过，前端 57 个文件、307 项测试通过，Windows 验证包通过。Windows pytest 尚在运行，最终合并仍需等它完成。资源刷新、过期 MXU 包清理、安装线程与锁的收尾继续沿用既有链路；本轮可以撤掉上次的 P2 阻断喵。

—— dot酱给重试拍拍爪敬上 🐾