[youngslin]

摘要

• 修复 脚本更新：新增统一自动恢复与持久备份回滚机制 #1916 在 release 旧调度器中的会话接线：旧基类直接执行 _run_main_task，原来放在 main_task 的绑定不会生效。改在真实执行入口绑定并覆盖子任务收尾，正常完成和手动停止均只通过既有 TASK_NOTICE 汇总一次。
• 保留 BetterGI 正式版公告、灰度和资源就绪门槛；对有效 MAS 残留目标记录，允许主程序缺失、损坏或版本资源不可读后重新执行经校验的官方完整安装器。拒绝目标降级、记录损坏或变化，以及下载期间原生升级后的覆盖；安装后复核版本和 PE 架构再清除标记。下载准备失败仍沿用既有健康检查后继续任务的 release 行为。
• 修复 HSR 恢复状态未初始化，以及本轮原生回滚或公共恢复成功后再次更新同一引擎的问题；保留旧调度、路径锁和原生回滚，不引入新调度器。
• 逐项补回 奇想盒：使用统一自动恢复取代安装失败弹窗 #1905、SRC：接入公共自动恢复，核验原生安装器状态 #1906、BAAH：统一自动修复损坏安装并恢复安装事务 #1908、MAA：自动恢复资源更新中断并安全报告本体更新失败 #1909、MaaEnd：接入统一自动恢复，处理 MXU 安装事务与官方修复 #1913、HSR：通过公共入口自动恢复 M7A/SRA 更新事务，不再弹窗 #1915 缺失的恢复回归，适配 release 的日志与锁接口；专用验证工作流增加本目标分支的 PR 触发及三平台接口类型检查。整个 PR 只有一个更新日志碎片，不修改前端或版本号。

验证

提交：fc68ce88035fc206deeabe59851286d1459dba7b；基线：606c7ebd9231888519b0decad085c249b17c554a。Windows、Python 3.12.13、uv.lock 锁定依赖。

• uv run --no-sync python -m pytest tests -q --tb=short：1614 passed、2 skipped、15 subtests passed，174.47 秒；保留现有 Pydantic 弃用提示。基线全量为 1554 passed、2 skipped。
• 同一故障场景修复前后对照：BetterGI 损坏/缺失程序、非法或变化的安装记录、目标降级与下载期间原生升级；HSR 公共恢复后的 AttributeError 和重复更新；真实旧任务正常结束/停止时的恢复汇总。修复前均复现，修复后对应检查通过。
• 变更 Python 文件 Ruff 检查、全仓 Ruff 格式、compileall、Windows/Linux/macOS 平台接口 mypy、uv lock --check、更新日志规则和 git diff --check 均通过。外部 CI action/container 引用均固定到提交或摘要。
• 本 PR 的远端 Windows/Ubuntu 全量、格式、依赖与构建检查以 Checks 最新结果为准。

已合并 PR	本轮保留或补回的关键恢复覆盖
#1905 奇想盒	遗留标记走公共入口，健康复核，备份失败/取消清理候选
#1906 SRC	Git 目标不能替代原生依赖安装完成证据，完成记录跨适配器重建
#1908 BAAH	损坏/缺失程序可信修复、回执变化拒绝、旧事务验证、取消保留目录锁
#1909 MAA	本体失败不伪造重试，资源半更新恢复，原始包与失败现场保留
#1913 MaaEnd	原生事务、ready 阶段故障注入、可信身份修复、精确版本恢复与配置保护
#1915 HSR	损坏程序、未知进程路径、真实 journal 恢复要求、恢复后不重复更新

排除与验证边界

• 不迁移 refactor(scheduler)!: 迁移四级调度与任务运行树 #1845 新四级调度/运行树，也不迁移 任务调度：恢复预下载并在日志末尾显示进度 #1862 依赖新调度和前端的进度展示；保留 release 原有预下载架构。
• 不新增 dev 的 current.recovery_summary 历史字段或前端消费，恢复结果仍使用 release 现有任务提示和后端日志。
• BetterGI 未接入通用快照自动回滚；有效残留事务通过官方完整安装器重试，缺少可信记录、资源未就绪或仍有写入者时继续阻断，不仅凭 EXE 版本清除失败记录。
• MAA 官方本体更新失败的无人值守重试继续排除：现有上游启动流程会清空待安装包登记，仍需官方界面完成原生修复；MAS 自有资源半更新可自动重试。
• 未运行真实游戏、账号、模拟器或上游官方安装器 E2E。自动化使用真实文件/事务与 MAS 入口，并在网络、原生进程和安装器边界隔离；不能据此声称实机安装已验收。
• 后续实机验收可在已配置脚本和账号的作者环境运行 cd frontend; yarn e2e:real:all --only BetterGIConfig,HSRConfig,MaaConfig,MaaEndConfig,BAAHConfig,SrcConfig,WhimboxConfig，产出各场景报告和 real-e2e-summary.json。

目标仅为 release-v5.8.0-backport-verify；不直接修改或合并该分支及 release/v5.8.0。

[jinghero]

总体结论：可以合并

AUTO-MAS-Project/AUTO-MAS #1923

宝宝，这次没有把新调度器硬塞回旧版，而是把恢复会话接到真正执行的入口，HSR 也补齐了恢复后的本轮去重。dot酱沿着正常结束、手动停止和安装失败路径核对过，审查范围内没有确认的必须修改项，可以合并喵。

调度器负责收集恢复事件并在结束时发一份现有 TASK_NOTICE；专项 manager 持有安装目录锁、决定何时更新，安装模块负责校验与执行。这个分工保留住了，没有再加一套通知或恢复状态。

• 旧调度生命周期： 会话绑定移到 _execute_task 后，子任务和独立收尾任务能继承它，结束时也会 reset。新增测试走真实 Task.execute 和取消入口，检查恢复提示只发一次、先于终态通知，不只是直接调用汇总函数，这处补得扎实啦。
• BetterGI： 缺失或损坏的程序只有带合法 MAS 安装目标记录才能重试；下载期间记录变化、目标降级及外部升级会被拒绝，安装后还要核对版本、PE 架构和记录。原有官方分发门槛与安装器退出确认仍在，没有为了修复把半安装当健康旧版放行。
• HSR： 原生回滚与公共恢复成功都会登记到当前 manager 的集合，后续只跳过已恢复的引擎，另一个引擎仍正常处理；预下载候选沿用原来的收尾回收，不会因此留给下一轮。

验证范围

静态检查覆盖三处生产改动、相关调用链、七类专项的恢复回归与验证工作流。已独立读取本次 CI实际日志：Windows 为 1614 passed / 2 skipped，Ubuntu 为 1589 passed / 27 skipped，两者均有 15 subtests passed；三平台接口 mypy、格式和依赖锁检查通过，Windows 构建也已成功。

这些证据支持 MAS 的接线与受控恢复行为，不等于真实游戏或官方安装器已验收。dot酱没有执行项目代码或测试，也没有把正文自报的修复前后对照当成独立复现。现有回归里的网络、进程与安装器隔离边界仍需保留，实机验收按正文列出的范围继续就好，别让绿色 CI 替它打包票呀。

—— dot酱拍拍爪敬上 🐾