[youngslin]

方向：#1916 公共恢复，无人工弹窗

旧恢复询问、skip journal、专用 WebSocket 及前端常驻弹窗已删除。本 PR 合并旧 #1914 的 native work/backup/journal 符号链接防护。M7A/SRA 路径锁由 HSR manager 持有；原生 rollback_pending 失败后由 auto_recover_script_install 统一再次确认和重试原生回滚；未确认删除 journal/释放备份时绝不放行，不提供用户跳过按钮。

专项仅提供 PE 基础校验（M7A）、SRA CLI 版本探针、SRA GUI 进程停写检查。成功恢复的单引擎本轮不重复更新，其他引擎照常处理；异常由队列末尾汇总。此处动作是原生事务回滚，不是保证重新下载安装。

#1914 已关闭，以本 PR 为唯一 HSR 实现。最新 CI 与审查均已通过，但不宣称真实安装恢复 E2E。

[sentry]

Bug: ask_install_recovery emits HSR_INSTALL_PROMPT_CLOSED before caller validation finishes, closing the modal prematurely if post-decision checks in manager.py fail.
_{Severity: LOW}

Suggested Fix

Delay closing the recovery modal until post-decision actions and validations in manager.py complete successfully, or allow error statuses to be communicated back to the active prompt modal before dismissing it.

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/HSR/tools/update/install_recovery.py#L138-L149

Potential issue: In `ask_install_recovery`, the `finally` block sends
`HSR_INSTALL_PROMPT_CLOSED` as soon as the prompt function returns or raises. However,
post-decision validations such as `skip_stale_journal` or a subsequent
`rollback_pending` retry occur in `manager.py` after the prompt is already closed. If
validation fails (e.g., active processes, unreadable version, or rollback issues), an
exception halts the task with no error details surfaced to the recovery modal or option
to retry.

Also affects:

• app/task/HSR/manager.py:331~338

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

[jinghero]

总体结论：修改后合并

AUTO-MAS-Project/AUTO-MAS #1915

宝宝，把旧日志归档到独立目录、保留 backup/stage 时禁止跳过，这两个选择是有用的喵。不过“已修好才能跳过”还缺程序和进程两道检查，正常的大事务记录也可能在提示前就被拒绝。另有已失败的格式 CI，需要一起补齐。

管理器仍先自动回滚，专项模块负责用户确认与归档；只有明确恢复成功的引擎才跳过本轮自动升级，另一引擎照常处理。以下是静态证据，不是实装复现。

规格

[逻辑 · P2，阻断] M7A 的版本文本可读，不代表主程序可用

skip_stale_journal:163–175仅检查 EXE 是文件，再读取版本。M7A 的版本读取实际上只读 assets/config/version.txt。

所以损坏 journal、无 backup/stage、EXE 已截断为零字节但版本文本仍在时，用户确认会通过检查，日志被归档并移除，该引擎还会被标记为本轮不再更新。之后 M7ARunner执行的正是这个损坏 EXE，仍然启动失败。前面的 manager.check 同样只检查存在性，没有补上这道检查。

请在移除标记前验证实际启动 EXE 的基本有效性，可复用已有 PE 头读取能力，不必扩成整包哈希系统。成功测试里的 b"manual repair" 不是有效 EXE，应换成有效夹具，并加“正常版本文本＋损坏 EXE”仍保留 journal 的用例。SRA 使用 CLI 的 --version 探针，这项不要机械扩到 SRA。

[逻辑 · P2，阻断] 无法读取 SRA GUI 路径时，新增空闲检查仍放行

_assert_idle:35–48想阻止“名称可读但 exe 路径不可读”的相关进程，却遗漏了 SRA.exe。原 check_no_process_running明确包括这个 GUI，但遇到 exe 为空会跳过；新名单只有 M7A、SRA-cli 和 SRA-server，第二次检查也不会拦它。

当 SRA GUI 仍运行、因权限原因读不到镜像路径时，不能确认它已退出，skip 却可能继续归档并移除 journal。这违反本入口“相关进程停止才能跳过”的前提，不意味着已经证实数据损坏。把 sra.exe 补进这份无法确认时拒绝的名单，并从进程枚举边界覆盖该场景即可。路径可读时原守卫已经正确处理，不需要重做进程管理啦。

[兼容 · P2，阻断] 64 KiB 限制不匹配已有事务文件规模

install_recovery.py:78–80在发送提示前拒绝较大 journal，第 62 行还有相同限制。但原 事务写入器会把每个变更文件写入 entries，写盘没有这个上限，安装器接受的包可达 100000 项。

例如 2000 个常规资源路径各带 rel/action，序列化后已经超过 64 KiB。这不是要求构造恶意文件，较大完整更新就属于现有安装器支持的输入。若随后因占用或 I/O 错误使自动回滚失败，新入口会直接报“记录异常”，用户连重试都点不到。自动回滚成功的情况不受影响。

请统一读写端支持的范围，或用流式摘要保存确认身份，保留原始记录、防替换和备份检查。加一份由现有写入器生成的大事务用例，不要只用几字节坏日志测试恢复入口喵。

规范与 CI

必须修复的门禁： 现有格式检查在 Python Ruff 步骤失败，涉及 install_recovery.py 和 test_hsr_update_before_run.py。后续前端尺寸、lint、类型、格式、单测、词表及 E2E 契约检查都被跳过。按仓库格式调整后，请让后续步骤完整执行。

[规范 · P3，非阻断] 第 117 行发送非空中文“未知”，英文和日文界面不会使用现有兜底翻译。传空值交给前端即可。

已有 CI 的 Windows pytest 为 1812 passed、2 skipped，Ubuntu 为 1773 passed、40 skipped，Windows 验证包构建通过。已静态核对路径锁、先归档再删标记、按引擎跳过二次更新和重连丢弃旧请求；没有确认新增黑箱边界或职责归属问题。弹窗结束后的失败仍会经任务状态与 TASK_NOTICE 告知，不能只因弹窗先关闭就判定错误丢失。

dot酱没有运行项目代码、测试或真实 Windows M7A/SRA/Electron 流程。规格侧 3 个必须修复的 P2，规范侧 1 个非阻断 P3，另需修复格式门禁。把“允许继续”的条件查实，恢复提示才能让人放心点下去。

—— dot酱认真守住恢复条件敬上 🐾

[jinghero]

总体结论：可以合并

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

宝宝，前次三处缺口这次都补上了，dot酱核对后没有剩余的必须修改项喵。程序基础格式、无法确认退出的 SRA GUI，以及正常大小的事务记录，现在都走到了对应检查。

install_recovery.py已按前次建议复用公共 PE 头读取能力，零字节或非 PE 的 M7A 主程序不会再仅凭 version.txt 被放行；SRA.exe 加进了路径不可读时的拒绝名单；读取与复核事务记录两处统一采用 128 MiB 上限。备份/暂存目录存在时禁止跳过、原字节一致性、先归档再删除旧记录等保护都还在，没有顺手放宽它们。

新增测试覆盖了原先的损坏 EXE、SRA GUI 路径不可读及超过 64 KiB 的快照，并检查内容变化仍被拒绝。这里要把证据说准：PE 夹具只是可解析的文件头，不是真实可启动程序；大记录用例只检查快照 helper，没有跑完整提示到归档流程。基础 PE 识别也不等于证明整个程序和资源完整，仍须保留用户确认已手工修复的前提，别把这层检查夸大啦。

规格轴原 3 项 P2 已解除，未确认新的功能或架构阻断。规范轴原有“未知”未本地化的 P3 仍非阻断，不重复展开。

已读取当前 CI 日志：Windows 1843 passed、2 skipped，Ubuntu 1804 passed、40 skipped；前端 57 个文件共 307 项测试通过，8 项检查全部成功，包含格式和 Windows 验证包构建。本轮仅静态复核与读取已有 CI，未运行项目或真实 Windows M7A/SRA/Electron 流程。前次建议的最小修复已经到位，拍拍爪喵。

—— dot酱核过恢复条件敬上 🐾

[jinghero]

总体结论：可以合并

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

宝宝，这版把人工跳过和恢复弹窗一起移除了，改由公共入口安排失败后的再次回滚与结果汇总。dot酱沿着回滚、复核和取消路径检查后，没有发现新的必须修改项喵。

manager 的接入仍先调用原有 rollback_pending；失败后才进入公共恢复，重试结束必须确认 journal 已消失，随后由公共层再次检查安装健康。外部路径锁覆盖整个过程，回滚线程结束前不会因取消而提前释放。

健康检查明确保持 updated_confirmed=False，不会仅凭版本文本跳过未完成事务。M7A 基础 PE 识别、SRA GUI 路径不可读时拒绝恢复，以及新增的事务目录符号链接保护都保留了。取消继续向上传播，恢复成功的单个引擎本轮也不重复更新，另一引擎照常处理。这几处没有为了“自动”而放宽原有保护，拍拍爪啦。

有一个范围要说清：这里的恢复动作是再次回滚原有事务，不是重新下载安装。journal 损坏或占用持续存在时仍会阻断并保留现场。PR 正文和更新日志还写着用户确认、手工跳过和弹窗，请同步成当前行为，免得使用者期待已经移除的入口。

已有 CI 的 8 项检查全部成功：Windows 1838 passed、2 skipped，Ubuntu 1799 passed、40 skipped；前端 57 个文件、307 项测试通过，格式、类型检查和 Windows 验证包构建通过。新增测试保留损坏 M7A 程序、无法确认 SRA GUI 退出、pending journal 不自动放行等检查。manager 的公共入口测试使用替身，不能当作真实安装恢复 E2E；本轮没有运行项目或上游程序，结论来自静态集成核对与已有 CI。

旧版手动跳过相关意见随那条路径删除而不再适用，不再要求把它加回来喵。

—— dot酱核好回滚再摇尾巴敬上 🐾