[youngslin]

问题

BetterGI 的 GitHub Release 与 Kachina/Steambird 官方 DFS2 资源不是同时发布。MAS 只检查 Release 上的版本和安装器后便开始托管更新，在发布窗口内可能触发安装器失败并留下未完成安装记录。

改动（仅后端，可用于 release/v5.8.0 热更）

• 对 GitHub 来源的 stable 正式版新升级，先按 BetterGI 官方 Build/kachina.config.json 里的 DFS2 源请求 ?with_metadata=1，校验元数据、非空文件索引和元数据版本等于准备安装的 Release 版本。
• DFS2 尚未发布、版本仍是旧版、接口失败或超时：不下载、不运行安装器、不写 bgi-install.json，返回「跳过本轮更新、沿用旧版」。下次任务启动时会重新检查。
• 如果已有 bgi-install.json，仍保持安全阻断，不能通过资源检查绕过未确认安装。
• MirrorChyan（含用户设置 CDK）走自己受信的 SHA256 / 版本校验，不受 DFS2 状态影响；公测通道也不额外检查正式版源；本地版本已是最新时不额外联网。
• 增加资源就绪、版本滞后、索引缺失、HTTP 错误、网络错误、跳过不写标记、已有标记不放行等 Python 回归测试。

设计边界

Kachina 的官方完整安装器含内嵌文件和本地元数据，在 DFS2 失败时有可能仍能离线安装。因此本检查是保守的自动更新发布门禁，并不是声称 DFS2 不可用时安装器必然失败。DFS2 接口失联也会使本次自动升级延后，但不会更改已安装版本。仅适用于 stable + GitHub，无需新增前端协议。

与 #1900 的关系

这是单独的纯后端预检查 PR，不包含 #1900 的安装残留弹窗及用户恢复交互。核对 #1900 差异后，其中没有此 DFS2 资源就绪逻辑，因此暂不需要从 #1900 删除任何预检查功能。

测试

本地对 DFS2 只读探测做了 10 项隔离模拟测试通过。仓库完整 pytest / Windows 行为和 CI 以 GitHub 检查结果为准。

[jinghero]

总体结论：无法判定

AUTO-MAS-Project/AUTO-MAS #1903

宝宝，这版把范围收在 DFS2 分发就绪探测，逻辑上没有发现确定性的新缺陷；但发布分支的前置条件和执行证据还没闭合，dot酱暂不放行喵。

合并前还缺什么

• 仓库规则 要求修复先进 dev，再回移 release。当前 dev 尚无这份探测实现。这里又与 #1901 / #1902 解决同一问题，但策略不同：那版同时等待公告全量推送，这版只看 DFS2；这版只拦新升级，同版本未确认安装仍走原有重装流程。请先明确采用哪份方案，让最终实现进入 dev 后再回移，不要把两份当成应顺次叠加的独立修复。
• 正文提到本地隔离模拟通过，但尚缺可核对到当前提交的命令、系统与完整结果，也没有证明经理层和安装标记回归测试已执行。当前绿勾包含构建、日志碎片、锁文件、标签及 Seer 审查，没有 pytest；Python Tests 仅匹配 dev。请在锁定环境补 uv run --no-sync python -m pytest tests/task/test_bettergi_program_update.py tests/task/test_bettergi_resource_readiness.py -q 的结果，不能只等这个 release PR 自动跑出 Windows/Ubuntu 测试。

静态检查结果

• 全部 5 个改动文件仅含 Python 后端、测试与一个碎片，无前端或依赖变更；release 的经理层仍完整等待更新，明确重抛安装不安全异常。
• 新探测 使用公开 DFS2 GET 元数据契约，字段与上游结构 匹配。网络、HTTP、JSON 和版本不匹配都保守暂缓，不输出响应体或凭据；不会吞掉任务取消。
• 调用处 仅对 stable、无 CDK、目标高于当前版本启用。暂缓发生在下载与标记写入之前；已有标记时不能沿用旧安装继续运行。Mirror、公测和同版本重装保留原路径，安装后的版本确认仍在。
• 这只是保守发布门禁，不保证后续下载安装成功。原有任务终态观察继续复用，不新增独立安装完成统计。

dot酱没有运行项目、测试、安装器或生产联网安装；上述是静态结论和已读取的 CI 状态。把最终方案与发布分支测试证据补齐，再复核合并条件就好喵。

—— dot酱留好复核书签敬上 🐾