[youngslin]

仅保留 #1916 公共自动恢复入口

本 PR 不再提供人工确认弹窗或自定义恢复 WebSocket。MAA 安装失败状态经统一公共入口接收、健康检查、恢复执行以及任务末尾异常汇总。

MAA 本体官方安装失败： 经官方已发布版本代码核对，pending-update-failure.txt 存在时，启动 MAA 会先清空 UpdatePackage。MAS 单独写入包路径再拉起 MAA.exe 并不能完成官方内部的重新登记流程。因此本 PR 不再虚假执行自动本体重试。只要官方失败标记尚未安全消除且无法证明已完成新版本，就阻止脚本任务继续，保留失败标记和原始包，明确提示用户先在 MAA 官方界面完成原生修复。也不擅自清理上游失败标记。

MAS 资源半更新： .automas-resource-update.json 继续经 #1916 自动重新获取完整资源、核验下载与身份，然后重新合并；不能通过旧资源时钟直接跳过。资源中断及官方本体失败同时存在时优先阻断本体，避免错误地完成部分资源更新。

保留 PE 检查、原生事务/进程锁和标记变化保护。新增使用真实 manager、adapter、公共恢复入口的测试，证明官方本体失败与完整包待处理时不会空转或误删原文件；资源单独失败仍自动重试。真实 MAA 官方 UI 修复的端到端验证尚未执行。

已废弃的 #1912 资源恢复弹窗逻辑没有保留。

[jinghero]

总体结论：修改后合并

AUTO-MAS-Project/AUTO-MAS #1909

宝宝，失败标记归档前保留原始内容、资源写入中断不允许跳过，这两处保护很认真喵。不过主程序损坏时还有两条路没接好：空文件能被当作已修复，主程序缺失时又会给出实际上无法完成的重试。

这里由 MAA 管理器持有安装目录锁并安排恢复，恢复模块检查标记、等待选择，前端只负责询问；本体安装和资源合并继续交给原有更新链，职责没有另起一套。

必须处理

1. [逻辑 · P2] 跳过失败时没有验证 MAA.exe，空文件也能解除失败门禁

位置：install_recovery.py:155–199；software_update.py:248–269。

静态推演：目录里保留官方失败标记，MAA.dll 的版本和 PE 头正常、资源版本正常，没有待安装包或运行中的更新器，但 MAA.exe 是零字节文件。用户勾选确认后，_check_current_install() 对 MAA.exe 只检查 is_file()；随后调用的 read_installed_release() 实际只读取 MAA.dll。因此两次检查都会通过，失败标记被移走并返回“沿用手动修复”的成功结果。

后续的软件检查同样没有检查 EXE 内容，直到真正启动才会失败，此时原来的失败门禁已被解除。风险确认可以接受无法全面判断安装健康的限制，但已经明显不能执行的主程序不该被当作修好了呀。请在归档前复用现有 PE 识别能力检查 MAA.exe，至少拒绝空文件、截断文件和不可识别的可执行文件；补一条保留真实 EXE 检查、而非仅 mock DLL 版本读取的回归测试。

2. [逻辑 · P2] MAA.exe 缺失时仍开放重试，但重试入口正是这个缺失文件

位置：manager.py:310–317、541–548；install_recovery.py:81–85；UpdateMAA.py:133–136。

本次新增分支允许“MAA.exe 已丢失，但有官方失败标记”的安装进入恢复。只要配置中登记的待安装包还在，弹窗就启用重试。实际路径却是 _install_pending_software_update() → update_maa() → ProcessRunner.run_process(MAA.exe)，没有另一个能执行修复的入口。于是用户点重试后无法启动官方安装，失败标记继续存在，再点仍然失败。

这里不必为了修复弹窗自行接管官方安装喵。最小改法是让恢复模块按实际可用的官方入口决定 canRetry，主程序缺失时明确要求先手动修复；若确有受支持的独立恢复入口，再接入它。补上“EXE 缺失＋有效待安装包”的完整调用链用例，避免只 mock 掉安装函数后得到假成功。

非阻断问题

[规范 · P3] 未知版本会在英文、日文界面显示中文。 后端发送非空的“未知”，前端的 value || t(...Unknown) 就不会使用翻译。可以让后端返回空值，由界面负责本地化。这点不单独阻止合并。

验证情况

dot酱做的是静态调用链核对，没有运行项目代码或测试。已读取现有 CI 日志：Ubuntu 为 1775 passed、40 skipped；前端 57 个文件、307 项测试通过，格式检查和 Windows 验证包构建也通过。Windows pytest 仍有 1 项失败：test_wakeup_launcher_preserves_literal_install_paths 的 PowerShell 子进程等待 10 秒超时，其余 1813 项通过、2 项跳过。不能据此认定是偶发或与本 PR 无关，合并前还需确认它恢复通过。

现有测试覆盖了标记变化、无前端、超时、取消和关闭托管后的资源重试，但不能替代上面两条真实主程序状态检查；Windows 官方更新器和桌面交互的端到端效果也尚未验证。把这两个入口补严实，再看绿灯就踏实多啦。

—— dot酱拍拍爪敬上 🐾

[jinghero]

总体结论：修改后合并

AUTO-MAS-Project/AUTO-MAS #1909 · 配置入口交互补充

宝宝，继续沿账号配置按钮核对，dot酱找到了一处之前漏掉的界面问题：后端正在等恢复选择，前端却把这些按钮盖住了。上一条的两个后端 P2 仍适用，这里只补新增证据，不把旧账再抄一遍喵。

[兼容 · P2，阻断] 账号配置会话的遮罩挡住安装恢复询问

选择共享或独立配置来源时，账号页的“打开配置界面”会调用 handleMAAConfig，经 startConfiguration 保存编辑后启动会话。useNativeGuiSession:159–171 收到任务受理返回的 taskId 就显示遮罩，不等原生窗口真正启动。

安装目录有官方失败标记或资源中断标记时，manager.py:579–584 在 prepare 后先等待恢复选择，尚未执行 ScriptConfigTask。与此同时，账号页使用的 GuiSessionMask 已传送到 body，固定全屏、z-index 1000；新 MAAInstallRecoveryModal:38 则只有 900。两者同在 body 层，恢复弹窗被配置遮罩盖住，用户无法用鼠标点击重试、跳过或停止，只能结束会话或等恢复询问超时。

请让这项恢复询问显示在原生会话等待遮罩之上，并保留现有标题栏预留区域。用“正常账号配置入口 → 安装目录有残留标记 → 两层同时出现 → 能点击恢复选择”的小场景验收即可，别只测后端收得到选择，却把真正的按钮留在下面啦。

这条结论不依赖 Scripts 列表页的局部 z9999 遮罩，也不影响已有安装锁或失败保护的职责。规范侧无新增问题，规格侧新增 1 项必须修复的 P2。上一轮两个后端问题及非阻断词条问题仍待处理。

发布前 CI 状态未变：Windows pytest 仍有上一条提到的超时失败，其他 7 项检查通过。dot酱只做静态源码、调用顺序和层级核对，未运行项目或真实 Electron 界面；已有单测通过不代表这条交互已验证。

—— dot酱给恢复按钮腾出位置敬上 🐾

[jinghero]

总体结论：修改后合并

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

宝宝，MAA.exe 的基础 PE 检查已补上，单独本体失败时也不再向缺失主程序的安装提供重试，前次的 Windows 测试失败这轮也已通过啦。不过两个失败标记同时存在时，重试判断还有一条绕过路径；配置会话的遮罩问题也仍在。dot酱把剩下两处说清楚喵。

[逻辑 · P2，阻断] 同时存在本体与资源标记时，资源分支仍会绕过官方重试入口检查

位置：install_recovery.py:85–91、manager.py:541–555。

can_retry 使用“存在 resource 标记，或者有 ZIP 且 EXE 可识别”。当安装同时保留 pending-update-failure.txt 与 .automas-resource-update.json 时，左边直接为真，右边的 EXE 检查不会执行。若官方待安装包还在、MAA.exe 已缺失，弹窗仍会启用重试；manager 却优先处理本体失败，先调用 _install_pending_software_update，最终仍尝试启动不存在的 MAA.exe，资源修复也走不到。两个独立标记没有互斥约束，例如资源合并中断后再从官方程序更新失败，就会留下这个组合。

所以前次第二项是部分修复，不能只测单独的 software 标记呀。请让“存在 software 标记”时始终要求待安装包与官方启动入口可用，仅在没有本体失败时允许资源标记独立提供重试。给现有“EXE 缺失＋待安装包”用例再加 resource 标记，确认 canRetry 仍为 false；有可用 EXE 和包的组合仍应允许。无需自行接管官方安装。

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

本次没有改前端层级。恢复弹窗仍为 z-index 900，账号配置使用的 GuiSessionMask 传送到 body 后为 1000。后端等待恢复选择时按钮仍被挡住。请协调询问与原生会话遮罩的显示顺序或层级，保留标题栏区域；完整入口证据见前次交互补充，不再重复整条调用链啦。

前次“空 EXE 能解除失败标记”的 P2 已按既有 PE 识别能力修复。它证明基础格式可识别，不保证完整程序可启动或资源完整；新夹具也只是 PE 头。规范侧“未知”未本地化的 P3 仍非阻断。

已读取本次 CI：8 项全部成功，Windows 1844 passed、2 skipped，Ubuntu 1805 passed、40 skipped，前端 57 个文件、307 项测试通过。新用例只覆盖单独本体标记，尚未覆盖上述组合。dot酱未运行项目、测试或真实 Windows 更新器/UI，以上为静态调用链复核。把组合条件和被遮住的按钮补好，再放它们过去喵。

—— dot酱核对组合恢复路径敬上 🐾

[jinghero]

总体结论：修改后合并

AUTO-MAS-Project/AUTO-MAS #1909

宝宝，两个标记同时存在时，现在也会先检查官方包和可执行入口，前次的组合绕过已补上；恢复弹窗移除后，遮罩和词条问题也不再适用啦。不过 dot酱继续查了已发布 MAA 的真实启动顺序，发现“有失败标记时重新启动 MAA 安装”还走不通，不能只看回调被调用就算重试成功喵。

manager 负责持锁并调用公共恢复入口，adapter 判断本体与资源状态；本体仍交给官方程序，资源继续走原有摘要校验和合并。公共接口已与当前目标分支核对，下面的问题在官方程序实际收到这次启动之后。

[逻辑 · P2，阻断] 保留官方失败标记重启 MAA，会先清空包登记，实际安装不会开始

位置：managed_recovery.py L105–122、manager.py L536–537。

触发条件是本 PR 要恢复的正常失败现场：pending-update-failure.txt 还在，待更新包也在，MAA.exe 可识别，当前版本还没达到更新目标。这里通过前置检查后调用 _install_pending_software_update，再由 UpdateMAA.py L104–134 写入包登记并直接启动 MAA.exe，没有经过官方的重新登记修复流程。

但已发布的 MAA v6.22.0 会按以下顺序启动：

• Bootstrapper L482–484 先处理上次更新结果，再尝试应用更新包。
• 发现失败标记后，TryReadDelegatedUpdateFailure L407–425 保留标记，却先调用 ClearPendingUpdatePackageState，清空 UpdatePackage。
• 后面的安装入口看到空包登记，就不会执行安装。MAS 收尾时仍看到失败标记，在 manager.py L882–885 抛错；资源恢复和 adapter 后面的确认都走不到。

这是源码调用顺序证明，未在 Windows 实机运行。prepare 中恢复旧包登记、以及进程结束后的临时配置还原，都改变不了上游这次启动先清登记的顺序。原流程要求用户在 MAA 内修复；这次新增的自动重试路径仍无法完成这一步，不是说已有正常更新流程都坏了。

请按已核实的官方修复或重新登记契约接入。上游自己的 RegisterPendingUpdatePackage 会把登记和处理旧失败状态放在同一个流程里，单独写配置并不等价。若没有可供 MAS 无人值守调用的受支持入口，就明确提示先完成原生修复，并收窄自动恢复的支持范围。不要为绕过此检查直接删失败标记，也无需再扩一套 PE 完整性判定。

验收请保留真实 manager、adapter 和更新回调，用“失败标记 + 有效完整包 + 较旧安装”确认官方安装确实开始、达到目标且失败状态解除；只 mock 公共入口返回 reinstalled，抓不到这条断点呀。

现有 CI 已全部通过，读取的日志为 Windows 1841 passed、2 skipped，Ubuntu 1802 passed、40 skipped，前端 57 个文件、307 项测试通过；格式、类型和 Windows 验证包也成功。这些结果没有覆盖上游启动顺序。dot酱未执行项目或上游程序。取消等待、目录访问锁、资源摘要复核和公共结果报告已静态核对，未确认其他新增阻断项。

另请顺手把 PR 描述和更新日志中的“弹窗／用户选择”改成当前自动恢复行为，免得使用者还在找已经不存在的按钮啦。

—— dot酱追到原生启动入口敬上 🐾

[jinghero]

总体结论：可以合并

AUTO-MAS-Project/AUTO-MAS #1909

宝宝，这次把“能自动修的”和“必须交回官方的”分清楚啦。未确认成功的 MAA 本体失败现在会保留标记和更新包，明确提示先做官方修复，不再空转一次启动冒充重试。前次 P2 已通过收窄支持范围消除，dot酱这轮没有确认新的必须修改项喵。当前提交的 CI 还在运行，这份结论不替代剩余检查。

manager 仍负责持锁和安排恢复，adapter 提供安装状态与资源修复回调，公共层负责确认结果。两个失败标记同时存在时先阻断本体失败；只有安装健康、达到登记目标、没有待执行包和资源中断时，才允许归档已完成更新的旧失败标记。单独的 MAS 资源半更新仍复用原有下载、摘要校验和合并，不需要再造一套安装器。

新增本体失败测试保留了真实 manager → 公共恢复 → adapter，检查原始标记、包和未完成状态都保留，也确实没有调用本体安装入口。这个断言终于对着之前那条断路了，拍拍爪。资源测试只证明回调仍会执行，校验器和实际合并被替换了，不能把它当作真实资源恢复或官方 UI 修复的端到端证据。

最后一笔仅修正测试格式，生产代码未再变化。发布前双平台 pytest、格式检查和 Windows 验证包仍在运行，日志碎片、依赖锁和回退检查已通过。dot酱只做静态复审并读取现有检查，没有运行项目、上游程序或真实 Windows 更新流程；让剩余 CI 跑完，再按仓库条件合并就好啦。

—— dot酱确认恢复边界敬上 🐾