[jinghero]

摘要

• 修复回退旧版后再次升级时因配置迁移冲突而无法启动的问题：旧数据库对应的七份 JSON 齐全、上一轮迁移已全部完成时，按当前 JSON 重新迁移。
• 逐文件完成转换和临时文件校验后，才清理过期 JSON 归档并直接替换旧 YAML，不额外备份 YAML。该项转换失败时保留原 YAML 和归档；替换失败及归档后的进度提交中断均可重试。

关联 CNB #252。

验证

当前提交：2a63eb86c4ff530e611ab3d5414f8d8bf667f444。Windows / Python 3.12.10，使用 uv.lock 锁定依赖。

• 迁移入口共 7 个回归场景，覆盖真实模拟器集合中合法 JSON 的 instances 非列表、目标替换失败时保留 YAML、归档后进度写入失败的重试，以及既有重迁与拒绝路径。评审版本 e6cb667493a156bc01914599d12227e5ef8448aa 为 2 failed、5 passed；当前版本 7 passed。
• uv run --no-sync --python .venv/Scripts/python.exe python -m pytest tests/core/test_config_json_remigration.py tests/core/test_config_initialization.py tests/core/test_config_paths.py -q --tb=short：10 passed。Ruff 全仓格式、改动文件 lint、三平台类型、锁文件、更新日志和 diff 检查通过。
• 全量后端本轮为 1721 passed、1 failed、2 skipped、17 subtests passed。失败为 tests/task/test_baah_program_update.py::test_prepare_can_run_while_installation_is_reserved_then_apply_preserves_configs 的临时目录清理断言；该 BAAH 文件在评审基线和当前版本单独运行均为 10 passed，与迁移测试合跑 17 passed。本次未修改 BAAH，尚未确定全量中这次失败的原因。
• 提供的现场副本自动迁移及重复迁移通过，5 个托管、5 个账号、4 个队列及 17 个队列项的身份完整保留。原始目录与账号数据未进入提交。

启动结果复用现有 backend_start_finished 观察边界，不新增逐文件迁移事件。未执行对方电脑的实际启动或真实游戏任务。

[jinghero]

总体结论：修改后合并

AUTO-MAS-Project/AUTO-MAS #1889

宝宝，回退旧版后重新升级这条路接通啦，重迁记录也能让文件占用后的重试继续往下走。不过还有一处删除顺序需要调一下：JSON 能读出来，不代表它能转换成功；现在转换失败时，对应的旧 YAML 已经被删掉了。先把替代文件准备好再动旧文件，这一步不能省喵。

启动层按数据库版本决定是否迁移，升级模块负责转换和逐文件进度，配置框架负责后续激活与保存。正常新版数据库不会因为 JSON 再出现就重新导入，这个边界保留得对。

[逻辑 · P2] 来源尚未确认可转换，就删除了现有 YAML

位置：重迁预检、删除目标及归档、稍后才进行转换。

静态可核对的场景是：数据库仍为 v1.11，上轮迁移记录及七项均已完成，七份 JSON 都存在，但 EmulatorConfig.json 的内容为 {"instances":"bad"}。这是合法 JSON，根节点也是字典，所以新增预检通过。启动入口只对主设置提前做模型转换，没有提前校验模拟器集合。

进入模拟器文件这一项后，代码先删除 emulators.yaml 和 legacy-json/EmulatorConfig.json，随后 convert_legacy 才因集合索引不是列表而抛错。启动虽然会停止，但原来可用的 YAML 和对应归档已经消失，新的 YAML 尚未生成。重试仍会对同一份不可转换的 JSON 失败，进度记录无法恢复已删除的 YAML。已有 pre-upgrade 只保留 JSON，且不覆盖之前的备份，不是这份 YAML 的保护。

这不是要求改变“当前旧版 JSON 优先、不额外备份 YAML”的取舍。问题在于尚无可用替代结果就删了旧文件；原实现会在目标或来源冲突处拒绝并保留 YAML。最小修复请留在升级模块，复用现有转换和临时文件校验，确认成功后再清理旧归档、替换目标，不必另造备份或事务框架。补一条真实 ConfigCollection 的结构损坏回归：合法 JSON 中 instances 非列表，迁移报错后该项原 YAML 仍在。现有损坏用例只写入无法解析的 {，还抓不到这条路径啦。

验证说明：dot酱只做了静态源码、调用链和测试审查，没有运行项目代码或测试。已读取当前提交 CI 日志，Windows / Ubuntu 完整 Python Tests 分别为 1720 / 1693 项通过，格式和三平台类型检查通过；Windows 验证包因官方 winCodeSign 下载连续 HTTP 504 失败，与本次迁移代码无关，但整轮 CI 尚不能算通过。上述通过结果也不能证明结构损坏时的保留行为。

—— dot酱敬上 🐾

[jinghero]

总体结论：可以合并

AUTO-MAS-Project/AUTO-MAS #1889

宝宝，这次把替换顺序改对啦：先完成转换和临时文件校验，再替换旧 YAML。合法 JSON 但集合结构错误时，原 YAML 与对应归档都会保留；dot酱上次按住的那处数据保留问题已经解决喵。

复审核对了替换失败、归档后进度提交中断的续跑，以及重迁完成后不再覆盖已修改 YAML 的路径，未发现新的必须修改项。“当前旧版 JSON 优先、不额外备份 YAML”的取舍也保持不变，没有为修这一步扩大迁移范围。

新增回归使用真实 ConfigCollection 覆盖 instances 非列表，并补了替换和进度提交失败场景，正好守住这次修复。已读取当前提交 CI 日志：Windows 完整测试 1733 项通过、Ubuntu 1706 项通过，三平台类型检查及构建工作流成功。dot酱本轮只做静态复核，没有独立运行项目代码，也没有把作者的现场副本验证当作实机启动复现。

—— dot酱拍拍爪敬上 🐾