[youngslin]

方向：仅保留 #1916 公共自动恢复

旧人工询问、弹窗和 SRC 专用 WS 恢复协议已删除。manager 持有安装互斥锁，使用 auto_recover_script_install / run_managed_script_install；SRC 专项适配器提供 Git HEAD、原生 installer、Python 依赖与进程停写证据。

旧 src-install.json 只有 Git 完成不能自动放行：pip check 不足以证明 requirements 已安装，需执行原生 installer；只有安装器成功后写入的完成记录才能证明本次安装完成。公共备份支持跨任务恢复；更新失败且旧版经健康检查才继续运行，异常由公共队列在任务结束时报告。

不保留旧版确认 UI。无可信安装证据、后台进程未停写或取消时 fail-closed。最新代码和 CI 以本 PR 最新 SHA 为准；未宣称真实 Windows 上游安装器 E2E 已完成。

[sentry]

Bug: Calling assert_idle in _recover_unconfirmed_install before _cleanup_current_src_root raises InstallUnsafeError if stray SRC processes are running, preventing the recovery prompt from being shown.
_{Severity: MEDIUM}

Suggested Fix

Terminate or manage running SRC processes before calling assert_idle in _recover_unconfirmed_install, or reorder _cleanup_current_src_root() so processes in the install root are cleaned up prior to recovery verification.

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/SRC/manager.py#L748-L760

Potential issue: In `main_task`, `_recover_unconfirmed_install()` is invoked immediately
after `check()`, prior to `_cleanup_current_src_root()`. Within
`_recover_unconfirmed_install`, `assert_idle(root)` is called before prompting the user
via `ask_install_recovery`. If a user manually launched `src.exe` or its subprocesses
without a pre-existing MAS process state snapshot, `assert_idle` detects the active
processes and raises an `InstallUnsafeError`. This aborts the task before the recovery
prompt can be displayed, preventing the user from choosing recovery options.

Also affects:

• app/task/SRC/manager.py:832~847

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

[jinghero]

总体结论：修改后合并

AUTO-MAS-Project/AUTO-MAS #1906

宝宝，同一提交重跑原生安装器、跳过前核对 Git 与标记，这两条恢复路径都接上了喵。不过系统唤醒时还有一个弹窗退不出去的问题，先把这处补好再合。

SRC manager 负责安排恢复时机，program_update 保留 Git、原生安装器和安装目录的安全检查；前端常驻服务负责保存询问，弹窗只提交用户选择。这次问题出在询问状态与主连接换代之间。

规范

[规范 · P2] 主动重连后，失效的恢复弹窗可能一直无法关闭

位置：srcInstallRecovery.ts L45–68。

按源码静态推演：恢复弹窗打开时系统睡眠并恢复，useAppLifecycle.ts L798–827 会主动调用 reconnectNow。这个入口先清空旧 socket，旧连接的 close/message 回调随后被过滤，并不会触发这里注册的 onDisconnected 清理，见 connection.ts L480–501 和该文件 L405–422。

如果后端的 120 秒询问在这次换连接期间超时，或任务此时取消，install_recovery.py L98–107 注销处理器后只发送一次关闭帧。这一帧没送达新连接，旧询问就会留在前端。重连后再点任一按钮，发送成功只会设置 pending，后端已没有对应处理器；弹窗没有超时清理，取消、重试和跳过都无法继续操作，遮罩和关闭键也被禁用了。普通断线的清理覆盖不到这条主动重连路径，猫爪子就是在这里被卡住啦。

请让恢复服务在主动换连接时也使旧请求失效，或在重连后与后端核对哪些请求仍有效。补一个“弹窗打开 → 主动重连 → 后端关闭帧丢失 → 新连接成功”的验证，确认旧弹窗能退出且不会永久 pending。这样才符合 mas-frontend-ui 的 Page States 对重连、超时和失败反馈的要求，也不用放宽后端安装保护喵。

规格

未确认另一个必须修改项。按 PR 描述核对了 AutoProxy / ScriptConfig 入口、同提交重试不额外 fetch、标记授权与字节核对、跳过检查以及部署配置恢复。运行进程仍须满足停写条件；没有把严格拒绝未知进程认定成需要自动杀进程的缺陷。

验证情况

以上是静态源码和已有 CI 的核查，dot酱没有运行项目、原生安装器或真实 UI。最新提交的格式检查仍失败，日志明确指向新增 src/services/srcInstallRecovery.ts 的格式，Ruff、前端 lint 和类型检查已过；请一并修好这一门禁。发布时 Windows / Ubuntu pytest 和 Windows 验证包仍在运行，不把它们记成通过。真实 SRC 安装器 E2E 仍未取得执行证据。组件尺寸已核对：App.vue 从 256 行增至 259 行，新弹窗 133 行，均未超限。

规范轴 1 项 P2；规格轴 0 项确认问题。把重连后的旧选择清掉，就不会让用户对着失效弹窗干着急啦。

—— dot酱盯着重连弹窗敬上 🐾

[jinghero]

总体结论：修改后合并

AUTO-MAS-Project/AUTO-MAS #1906 · 重连修复复审

宝宝，前一轮卡住恢复弹窗的 P2 已修复喵。现在剩下的明确阻塞是新增后端测试初始化错误，Ubuntu pytest 已红，先修好夹具再确认最新 CI。

规范

恢复服务 L48–85 新增 onConnected 清空旧询问和 pending，并在 dispose 成对注销。已核对真实 WebSocket 顺序：onopen 同步调用连接成功监听，清理结束后才处理新连接 message，所以不会拿旧选择继续发送，也不会删掉随后到达的新询问。原 P2 撤下，不再重复记问题啦。

规格

未确认新的功能阻断项。此次生产变更只处理恢复询问的生命周期，没有修改 SRC 安装、Git 校验或标记清理条件。重连回归测试调用真实服务、替换传输边界，覆盖失效请求不再可发送以及新请求仍可操作。

尚需修复的验证阻塞

新增测试 L512 给 instance.execution_mode 直接赋值，但它是 legacy.py L347–353 的只读 property，实际从 maintenance 和 task_info.mode 计算。Ubuntu CI 日志 确认抛出 AttributeError，测试还没走到恢复询问断言就结束了：1 失败、1773 通过、40 跳过。

请按真实任务上下文初始化 maintenance 与 task_info.mode，不要给这个只读属性补 setter。修复后重跑两平台 pytest，才能证明新增用例真正检查到了预期行为。这是测试夹具错误，dot酱没有据此把生产恢复路径判成崩溃喵。

同一最新提交的格式、类型检查和 Windows 验证包构建已通过；前端 CI 为 57 个文件、300 项测试通过，包含新增重连用例。Windows pytest 也已完成，同一个新增用例在只读属性赋值处失败：1 失败、1812 通过、2 跳过。未自行运行项目、原生安装器或真实 UI，实机 E2E 仍无执行证据。

规范轴原 P2 已修，规格轴没有新增确认功能问题；剩余这一个测试初始化阻塞修好后再合。

—— dot酱把测试夹具也核一遍敬上 🐾

[jinghero]

总体结论：修改后合并

AUTO-MAS-Project/AUTO-MAS #1906 · 测试修复与配置入口复核

宝宝，只读属性的测试夹具这次修对了，Windows 和 Ubuntu pytest 都已通过，之前那项验证阻塞可以撤下啦。继续核对真实配置入口时，dot酱发现了前两轮没覆盖到的遮罩问题：恢复弹窗已经弹出，却被配置页面挡在后面，仍需要补一处喵。

[兼容 · P2，阻断] 配置／查看会话的遮罩挡住恢复按钮

位置：SrcInstallRecoveryModal.vue:31–40；SRCUserEdit.vue:578–616；GuiSessionMask.vue:51–59。

静态路径：用户在 SRC 账号页打开原生配置或查看会话，启动请求一返回任务 ID，页面就把 showSrcConfigMask 或 showSrcViewMask 设为 true。若有上轮未确认安装，manager.py:833–843 此时会先等恢复选择，还没启动原生配置程序。

两个会话遮罩实际都使用挂到 body、层级 1000 的 GuiSessionMask，本 PR 新恢复 Modal 只有 900。于是重试、跳过及取消按钮被遮住，用户只能结束配置会话或等待恢复询问超时；这不是主动重连问题，那项修复仍然有效。

请在前端协调恢复询问与配置会话遮罩，保证等待选择期间恢复按钮可操作，同时保留标题栏避让。针对“账号配置／查看入口 → 已有安装标记 → 收到恢复询问”验证按钮可点击，不要只测恢复服务的消息队列。自动运行入口没有这个页面遮罩，因此按局部功能阻断记 P2，不扩大为整个恢复功能不可用。

本轮验证

测试夹具现在设置真实的 maintenance 和 task_info.mode，没有给生产属性加 setter。CI 日志确认 Windows 1813 passed、2 skipped，Ubuntu 1774 passed、40 skipped；前端 57 个文件、300 项测试通过，格式、类型检查和 Windows 验证包构建通过。

此次提交只改测试初始化，生产恢复逻辑未变化。目标分支新增的 Runtime 启动能力变更已做静态集成核对，与 SRC 恢复路径无直接交叉；上述 CI 运行早于该目标分支更新，不能当成新组合的执行证明。dot酱没有运行项目代码、安装器或真实 UI。

规范侧原重连问题和测试初始化阻塞已解除；配置入口的这一个规格／集成问题尚待处理。把遮罩的先后关系理顺，这次修好的按钮才真的点得到呀。

—— dot酱认真检查按钮敬上 🐾

[jinghero]

总体结论：修改后合并

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

宝宝，恢复询问和专用 WS 已一起撤掉，前次“按钮被配置遮罩挡住”的问题不再适用啦。现在复用已合并的公共恢复流程，省去了用户在失败现场手动选路；不过 dot酱核对实际回调后，发现一处把没装完当作装好了，另一处又把真正装好的回退了，先把这两处判断理顺喵。

SRC manager 负责进入恢复流程，SRCInstallAdapter 提供安装状态和原生 installer 调用，公共层决定备份、重试、确认及回滚。原有安装锁仍由 manager 持有，下面两项都是新接入的代码契约问题，均为 P2、阻断合并。

1. [逻辑 · P2] 旧标记恢复会把尚未完成的依赖安装自动确认为成功

位置：managed_recovery.py:58–80。

限定场景是只有旧的 src-install.json、还没有公共安装备份。旧更新已经把 Git 快进到目标提交，但在原生 installer 安装依赖前中断，或依赖下载失败。此时 src.exe、installer.py 和 Python 仍在，旧环境里已安装的包也可以彼此兼容，因此 pip check 返回成功。

这个检查不会核对仓库 requirements.txt 所要求的新版本。上游确实有过这样的升级，例如 uiautomator2cache 从 0.3.0.1 升到 0.3.1；原生安装器会比较并安装 requirements.txt，不是仅执行 pip check。

当前 inspect 却据此设置 updated_confirmed=True。manager 走 auto_recover_script_install，公共层调用 acknowledge；后者的 skip_unconfirmed_install 仍只检查 Git、文件存在和 pip check，随后删掉旧标记。再次检查 healthy/pending 也会通过，于是没有完成依赖更新的新代码可以继续启动。上版还要求用户明确确认已经手工修复，这版把该前提撤掉后，原来的检查不足以支持自动确认。

最小修改： 对无法证明原生安装已完成的旧标记，返回“尚未确认”，让公共入口调用已有的同提交 installer 重试路径；以原生安装成功结果完成恢复，不必在 MAS 再实现一套依赖解析。补“Git 已到目标、旧环境 pip check 成功、新 requirements 尚未安装”的回归场景，确保先运行 installer，再清标。自动恢复可以少让用户操心，但不能把检查包之间是否冲突当作安装完成呀。

2. [逻辑 · P2] 跨任务恢复丢失目标提交，成功确认或重试也会回滚

位置：managed_recovery.py:43–57、80。

有公共备份时，manager 创建的是没有 prepared 的 adapter。这种实例的 expected 只从仍存在的 src-install.json 读取；acknowledge 或重试安装成功后，标记都会删除。下一次 inspect 就失去目标提交，updated_confirmed 必为 False。

公共层在确认清标后和安装重试后都会再次核验 updated_confirmed。因此，上次超时但实际已完成的安装，或这次真正重试成功的安装，都会被判为未确认并回滚旧版。若上次已进入 installed 阶段、只剩备份清理失败，下次又无法确认新版，而该阶段也不能直接回滚，恢复会持续受阻。

最小修改： 让经验证的目标提交在清标、重装及后续复核之间保持稳定，并覆盖“标记已删除、公共备份尚未结算时重启”的恢复身份。复用 MAS 自有恢复记录保存所需信息，不要直接放宽公共层的完整性条件。正常首次更新有 prepared，不触发这条缺陷；验收要重建 adapter 后走真实公共恢复入口，不能只测同一实例的正常安装。已经修好的安装，就别再被自己的复核退回去了喵。

验证与旧意见

上述两项均为源码静态推演，未执行项目、上游 installer 或真实 SRC 流程。新增末尾两项恢复测试把整个公共恢复入口替换成 AsyncMock，只证明 manager 发起了调用，没有覆盖“检查 → 清标/重装 → 再检查”的实际链路。

当前 8 项 CI 全部成功：Windows 1840 passed、2 skipped，Ubuntu 1801 passed、40 skipped；前端 57 个文件、307 项测试通过，格式、类型检查及 Windows 验证包构建通过。旧重连、测试初始化和遮罩意见均不再阻断；没有要求恢复已删除的弹窗，也没有另报安装锁或遥测问题。

正文和更新日志还在描述手动“重试/跳过/选择”，请顺手同步成这版的自动恢复行为，免得读者照着已经移除的按钮找入口。公共流程已经接上，补准这两处证据交接就好啦。

—— dot酱替恢复流程再核一遍敬上 🐾

[jinghero]

总体结论：修改后合并

AUTO-MAS-Project/AUTO-MAS #1906 · 安装完成记录复审

宝宝，这次两处生产判断修到点上啦：旧标记不再靠 Git HEAD 和 pip check 自动放行，真正跑完原生 installer 后才留下完成记录；重建 adapter 后也能找回目标提交，公共恢复结算前不会提前删掉证据。前轮两项 P2 可以撤下喵。现在剩下的是新增回归测试在 Windows 上失败，需要把测试的外部环境边界隔离好。

[规范 · P2，阻断] 完成记录测试依赖运行器自己的 Python 包环境

位置：test_src_program_update.py:40–59、500–519；健康检查位于 managed_recovery.py:79–107。

夹具把测试运行器的 sys.executable 写成 SRC 的 Python，transport 只替换 Git 仓库地址，其余命令全部真实执行。因此，重建 adapter 的测试会对运行 pytest 的环境执行 python -m pip check；这个环境不是夹具建立的 SRC 依赖环境，却决定了 healthy 和最终断言。

Windows CI 已在新增用例第 517 行失败：pending=False，已安装提交与目标提交一致，但 healthy=False，所以 updated_confirmed=False。结果为 1 failed、1841 passed、2 skipped。日志没有给出被捕获的命令错误细节，不能据此说真实 SRC 安装失败；但这条新增检查目前确实没有稳定验证到它要守的“完成证据跨 adapter 保留”契约。

请在现有命令边界只隔离外部 pip 健康检查，给这个场景明确的健康结果，同时保留真实的本地 Git、安装器夹具、文件记录和 adapter 判断。另一条“Git 已到目标但 installer 未完成”的用例也应确保 pip check 成功，才不会因无关健康失败而偶然通过。不要 mock 整个 inspect 或公共恢复流程来换绿灯，猫爪子要抓的是目标缺陷呀。修好后确认两平台用例和 CI 通过，不需要新增测试框架或放宽生产保护。

本轮核对

已静态追踪旧标记重装、正常 A→B 更新、备份未清理时重启、失败回滚及完成记录清理。完成记录来自原生安装器退出成功和 Git 目标核验，恢复决策仍由现有公共层负责，没有发现新的生产阻断项。

Ubuntu CI 为 1803 passed、40 skipped；前端 57 个文件、307 项测试通过，格式、类型检查和 Windows 验证包构建通过。dot酱未运行项目、原生安装器或真实 SRC 流程。把这处测试边界补稳，就能让这次修复得到它该有的验证啦。

—— dot酱帮完成记录守好证据 🐾

[jinghero]

总体结论：可以合并

AUTO-MAS-Project/AUTO-MAS #1906 · 测试环境隔离复审

宝宝，这次只在命令边界给 pip check 提供明确的健康结果，真实的本地 Git、安装器夹具、完成记录和 adapter 重建都保留了，没有把要验证的业务判断一起 mock 掉。前轮测试环境 P2 可以撤下啦，dot酱这轮没有发现新的必须修改项。

新增隔离只匹配 python -m pip check，其他命令仍走原来的本地传输入口。生产代码与上一轮一致：原生 installer 成功、Git 目标核对、完成记录持久化及公共恢复结算仍是原来的链路，没有靠放宽生产保护让测试变绿喵。

已读本次 CI 日志：Windows 1842 项通过、2 项跳过，Ubuntu 1803 项通过、40 项跳过；前端 307 项通过，当前 8 项检查全部成功。前轮 Windows 的完成记录用例不再失败。

还有一个非阻断的覆盖细节：相邻“Git 已到目标但 installer 未完成”用例尚未显式固定 pip 健康结果，之后可以复用同一命令边界，避免反例因无关环境失败而偶然通过。本次审查没有把它算成新的生产问题。

上述运行结果来自已有 CI，dot酱没有自行运行项目或真实 SRC 安装流程。按已核对的代码与测试范围，这版可以合啦。

—— 摇着尾巴的 dot酱敬上 🐈