fix(BetterGI): 修复执行层排序/超时/日常连坐，修正幽境参数并恢复 MCP 初始化 - #631
Open
TCddddd wants to merge 79 commits into
Open
Conversation
BetterGI 鐢ㄦ埛缂栬緫椤电殑涓€鏉￠緳閰嶇疆鍖洪噸鏋勪负鍙鍖栭槦鍒楋細 - 宸︽爮闃熷垪鏀寔鎷栨嫿鎺掑簭銆佸惎鐢ㄥ紑鍏炽€佸彸閿Щ鍑轰笌涓€閿竻绌?- 娣诲姞閰嶇疆缁勬敮鎸佸€欓€夌偣鍑?鍒嗗彿鎵归噺杈撳叆锛屽彲閲嶅鍔犲叆锛堟瘡琛岀嫭绔嬪疄渚嬶級 - 鏂板銆屼綋鍔涗綔鎴樸€嶄笓椤归」锛氬惎鐢ㄦ椂鑷姩鍏抽棴骞跺喕缁撳埛鍙栫被瀹樻柟缁勶紝鍏抽棴鍚庢寜璁板繂鎭㈠ - 鍐呯疆/浣撳姏/鑷畾涔夐厤缃粍浠ャ€岄粯璁?涓撻」/鑷畾涔夈€嶅墠缂€ tag 鍖哄垎
…to feat/bettergi-adapter-resin-battle
- 队列行/详情/候选 tag 统一配色（默认=灰、专项=紫、自定义&JS=蓝、路径=绿，浅底深字） - 队列多选修复：Shift 区间选择以 uid 锚点，普通点击保留锚点 - 默认一条龙顺序调整并同步模板 TaskOrder/后端单一来源 - 体力作战冻结名单补充「自动幽境危战」 - 添加配置组弹窗输入改为标签输入（彩色气泡+回车/分号提交+未知名称拼写检查） - 新增任务设置：右栏按 BGI 一条龙 JSON 字段分组展示/编辑并写回 per-user 副本（含设置读写 API）
- yarn openapi 生成 BetterGIOneDragonSettingsIn/Out 模型与 BetterGiService 的类型化 get/save 方法 - 手写 settings composable 改为调用生成的 BetterGiService，消除旁路
- 自动秘境补 SundayEverySelectedValue / SundayWeeklySelectedValue（每日/每周模式的选择序号） - 每条内置龙右栏追加公共「完成后操作」CompletionAction（BGI 为全局卡，非任务专属） - 依据 BGI OneDragonFlowPage.xaml 核对字段归属（领奖树脂/分解圣遗物/奖励识别属 BGI 全局 config，不在一条龙 JSON，暂不接入）
- 首领讨伐「选择首领」改为二级连列弹窗（地区 → 首领 Boss）， 首领候选按 BetterGI AutoBossData.CountryToBosses 分组（41 个，无至冬） - 「选择战斗策略」复用已有策略弹窗：顶部通用策略与右栏字段共用一套候选 - 讨伐目标字段顺序调整为：选择首领 → 切换队伍 → 战斗策略 - 设置面板支持 strategy/boss 字段类型（点击输入框弹窗单选） - 首领候选展示「首领名称-地区」，value 保持首领名语义
- 基于 BGI 全局 config.json 物化/还原幽境危战刷取策略与树脂次数设置 - 队列行启停开关、批量操作与标签展示细化 - 同步 res/version.json changelog
解决冲突： - frontend/src/i18n/locales/zh-CN.ts：4 处 BetterGI 文案保留本分支的可视化队列/独立配置新文案 - res/version.json：保留双方 changelog 条目
…into feat/bettergi-onedragon-config
- 新增 OneDragon.Queue 持久化可视化队列（顺序/成员/同名重复实例），运行时按队列重建一条龙 TaskOrder，为空时保持旧行为 - 前端队列拖拽/添加/移除/清空落库，加载时优先恢复持久化队列 - per-user 接口统一校验 userId 归属（UUID + UserData）与 configName 路径边界，防越权与目录穿越 - 任务收尾关闭游戏改为直接强制结束，失败原因落日志并推送调度台（拒绝访问时给出权限指引） - 每周秘境数据源文档与实现对齐（仅官方 tp.json） - PR changelog 合并为一条，移除误提交的本地草稿文件
- 按最新后端 openapi 重新生成 src/api：OneDragon 模型新增 Queue 持久化队列字段 - BetterGI 部分接口 userId 改为必填（带默认值），秘境/配置组接口描述与实现对齐 - 新建用户默认表单补 Queue，与后端默认值一致（空队列回退旧顺序行为）
## 摘要 - MAA 自动代理接管配置时，官服/B 服开始唤醒的账号切换开关强制写为开：MAA 内已存为关闭时不再出现只写账号名却不切号的问题；用户未填写账号时 MAA 传空账号名仍不会实际切号。 - res/version.json 在 v5.5.0-beta.3 程序优化节补一条记录。
启动等待画面上的「查看日志」点开是一片空白，后端启动失败后这个入口又整个消失；日志文件打不开时也不会有任何提示。
- **日志窗改为落在前端日志**。日志页默认选中
`debug/app.log`，而启动这一程后端还没起来，这个文件不存在或停在上一轮；启动过程的记录都在主进程写的
`debug/frontend.log` 里。`createLogWindow(file)` 支持 `#/logs?file=frontend`
落地，窗口已经开着时由主进程推送 `log:selectFile` 换文件（只 focus
的话，之前停在后端日志的窗口再点一次仍然是空的）；`openLaunchLogWindow()` 固定传
`frontend`，不带参数打开时默认不变。日志为空时给一句提示，不再是空白的 Monaco。
- **后端启动失败那一屏补上「查看日志」**。`buildRuntimeStartFailure` 不带
`logPath`，`RUNTIME_NOT_FOUND` 这类 spawn 之前的失败连日志正文都没有，`hasDetails` 为
false，整屏只剩「重试」和「查看排障文档」。沿用等待态同一个入口，`LaunchFailure` 未改动。
- **失败态正文改为上下居中**。`.failure-body` 原先是 `align-self: flex-start`，被
`.launch-page` 的 `place-items: center` 撑满高度后一直贴顶。用 `margin-block: auto`
而不是 `align-items: center`——后者在内容超过窗口高度时会裁掉顶部、滚不上去。
- **两处让日志打不开还不提示的问题**。其一，`initializeLogger()` 把 `frontend.log` 写到
`dirname(app.getPath('exe'))`（源码运行下是
`node_modules/electron/dist/`），而日志窗读的是
`getAppRoot()`，`initializationHandlers` 的 `fallbackLogPath`
同一处口径不一致，两处统一到 `getAppRoot()`，打包版路径不变。其二，`shell.openPath()` 失败时是 resolve
一条错误信息而不是 reject，`open-file` handler 丢掉了这个返回值，调用方 `catch`
不到——「打开日志失败」的提示从来没出现过，历史记录页还会照常弹「日志文件已打开」；改为按相邻 `open-url` 的约定返回 `{
success, error }`，两处调用方跟着判断。
本地验证（在 `frontend/`）：`yarn typecheck`、`yarn build:main`、`yarn lint`
均无输出；`yarn test` 402 通过。剩下 3
个失败（`electron/services/runtimeInitializationService.test.ts`
×2、`electron/services/backendService.test.ts` ×1）在 dev 上就是红的——本 PR 动了
`frontend/electron/`，所以把 electron 侧改动整体还原后单独重跑了这两个套件，失败项完全一致。
另外用 `vite build` + `electron .`
起了一次真实窗口核对失败态：`AUTO_MAS_RUNTIME_MODE=managed` 且没有 Runtime 时落在
`RUNTIME_NOT_FOUND` 失败屏，文字块上下、左右均居中；点「打开日志」正常拉起
`<appRoot>/debug/frontend.log`（这个文件本身就是上面路径口径修复的产物，改之前源码运行下不会存在）。
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
## 问题 脚本侧的守卫（如 MaaEnd 分辨率不达标时的强停）会调 `PostStop` 停掉整个 tasker。强停是由 pipeline 里的动作节点触发的，那个节点自身返回成功，MaaFW 于是把入口回报成 `Tasker.Task.Succeeded`；runner 只看 `job.failed`，把一件没做的事记成「任务完成」，还继续投递剩余任务，每个重复一遍。 实际现场（2026-09-07 04:00，MaaEnd 12 个任务）：11 个被记成完成，只因为其中一次投递恰好撞上 tasker 正在 stopping、报了 `task_id=0` 才暴露。**否则整轮会被报成全部成功。** ## 判据为什么不用事件 第一版想监听 `MaaTaskerPostStop` 事件，但它比 `job.wait()` 返回晚约 19ms： ``` [04:00:31.772] 任务完成: 🤝拜访好友 [04:00:31.791] [MaaFW Tasker] 开始: MaaTaskerPostStop ``` 光靠事件会漏掉当前这个任务，正好是要修的那个。改用同步查询 `MaaTaskerStopping`——`post_stop` 因果上必然早于 `wait()` 返回，此刻 `stopping` 一定还是 true。事件标志降级为兜底，覆盖两个任务之间到达的强停；`_stop_requested` 排除 MAS 自己发起的停止。 命中后：当前任务按失败记录、不计入 `completedTasks`，剩余任务不再投递。`task_id=0` 那条也一并收编，它本来就是「投递撞上 stopping」的表现。 ## 本地验证 在本分支的 `.venv`（Python 3.12）实跑： | 检查 | 结果 | | --- | --- | | `python -m pytest tests` | 484 passed, 3 skipped | | `python -m pytest tests --collect-only -q` | 487 collected，退出 0 | | `ruff check` / `ruff format --check` | 通过 | | 回归测试 7 例（边界测试，按 `tests/AGENTS.md` 未提交） | 7 passed | 回归测试含一条敏感性检查：把新判据短路成恒 `False`，断言旧行为下 3 个任务全被记成「完成」——确认这组用例确实能捕获该 bug，而不是修复前后都绿。 ## 残留风险 判据是「tasker 被停 → 当前任务算失败」。如果某个项目把 `PostStop` 当**正常收尾**用，它的末尾任务会从「完成」变成「失败」。MaaEnd 里 `PostStop` 只挂在 `__SceneCheckAbortPipeline` 一个节点上，是纯 abort 用法；其他项目未逐一核查。 🤖 Generated with [Claude Code](https://claude.com/claude-code) ## Sourcery 总结 防止由脚本触发的 tasker 停止操作被报告为成功任务，并阻止剩余任务继续运行。 Bug 修复： - 将脚本触发的 MaaFramework 停止操作视为任务失败，而不是成功完成，从而避免将未完成的任务计为成功，或提交后续任务。 增强功能： - 通过检查 tasker 的停止状态同步检测外部停止操作，并保留事件通知作为后备机制，同时排除由 MAS 自身发起的停止操作。 <details> <summary>Original summary in English</summary> ## Sourcery 摘要 防止由脚本触发的 tasker 停止被报告为成功任务，并阻止剩余任务队列继续执行。 Bug 修复： - 将由脚本触发的 MaaFramework tasker 停止视为任务失败，而不是成功完成，从而避免将未完成的工作记录为已完成，或提交后续任务。 改进： - 通过 tasker 状态同步检测外部触发的停止，并以基于事件的方式进行回退，同时区分由 MAS 发起的停止。 日常维护： - 更新应用程序版本元数据。 <details> <summary>Original summary in English</summary> ## Summary by Sourcery Prevent script-triggered tasker stops from being reported as successful tasks and from allowing the remaining task queue to continue. Bug Fixes: - Treats script-triggered MaaFramework tasker stops as task failures instead of successful completions, preventing unfinished work from being recorded as completed or subsequent tasks from being submitted. Enhancements: - Detects externally triggered stops synchronously through tasker state with event-based fallback, while distinguishing MAS-initiated stops. Chores: - Updates the application version metadata. </details> </details> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
- 首页快速启动支持一次选择并启动多个任务。 - 记住上次选择，下次进入首页时自动恢复。 - 本地验证：yarn test src/views/home/homeQuickStartTasks.test.ts src/views/home/components/HomeCommandCard.test.ts；yarn typecheck；yarn lint。 ## Sourcery 总结 支持从主页快速启动多个任务，并在用户再次访问时记住其有效选择。 新功能： - 支持一次操作选择并启动多个主页快速启动任务，并分别反馈每个任务的成功或失败结果。 - 持久化所选快速启动任务 ID，并在返回主页时恢复有效选择。 增强功能： - 过滤无效、占位、重复和不可用的快速启动选择，同时保留选择顺序。 - 当单个快速启动任务失败时，继续启动其余任务。 测试： - 增加对多选渲染、选择规范化、不可用任务过滤以及批量启动结果的覆盖。 维护： - 为批量启动结果添加本地化消息，并重新格式化受影响的语言环境条目。 <details> <summary>Original summary in English</summary> ## Sourcery 摘要 支持多任务主页快速启动，并持久化、验证所选任务，同时提供各任务的启动反馈。 新功能： - 支持在单次操作中选择并启动多个主页快速启动任务。 - 持久化所选快速启动任务的 ID，并在重新访问主页时恢复这些选择。 Bug 修复： - 在显示或启动任务之前，过滤持久化选择中的无效、占位、重复和不可用任务。 - 当某个快速启动任务失败时，继续启动其余任务。 增强功能： - 报告批量启动的任务数量，并使用本地化消息提供单个失败任务的详细信息，同时保留选择顺序。 测试： - 增加对多选渲染、选择规范化、不可用任务过滤和批量启动结果的覆盖。 杂项： - 重新格式化受影响的语言环境条目，并添加本地化的批量启动消息。 <details> <summary>Original summary in English</summary> ## Sourcery 摘要 支持从主页持久化启动多个任务，同时验证选择内容并报告每个任务的启动结果。 新功能： - 支持通过单次操作选择并启动多个主页快速启动任务。 - 持久化快速启动选择，并在返回主页时恢复有效选项。 错误修复： - 在显示或启动前，过滤无效、占位、重复以及不可用的持久化选择。 - 当某个快速启动任务失败时，继续启动其余任务。 增强功能： - 保留选择顺序，并为批量启动提供本地化的汇总成功反馈和逐任务失败反馈。 测试： - 增加对多选渲染、选择规范化、不可用任务过滤以及批量启动结果的覆盖。 杂项： - 重新格式化受影响的语言环境条目，并添加本地化的批量启动消息。 <details> <summary>Original summary in English</summary> ## Sourcery 摘要 支持从主页持久化启动多个任务，同时验证选择内容并报告每个任务的启动结果。 新功能： - 支持在一次操作中选择并启动多个主页快速启动任务。 - 持久化所选快速启动任务的 ID，并在返回主页时恢复有效的选择。 错误修复： - 在显示或启动快速启动任务之前，过滤无效、占位、重复和不可用的选择。 - 即使某个快速启动任务失败，也继续启动其余任务。 增强功能： - 提供按顺序排列的批量启动结果，包括本地化的成功数量和每个任务的失败详情。 测试： - 增加对多选渲染、选择规范化、不可用任务过滤以及批量启动结果的覆盖。 维护： - 添加本地化的批量启动反馈，并重新格式化受影响的语言环境条目。 <details> <summary>Original summary in English</summary> ## Sourcery 摘要 支持从主页可靠地快速启动多个任务，同时保留用户选择并报告启动结果。 新功能： - 支持一次操作选择并启动多个主页快速启动任务。 - 持久化快速启动选择，并在返回主页时恢复有效选项。 Bug 修复： - 在显示或启动前，过滤无效、占位、重复及不可用的快速启动选项。 - 当单个快速启动任务失败时，继续启动其余任务。 改进： - 提供有序的批量启动结果，包括本地化的成功数量和每个任务的失败详情。 测试： - 增加对多选渲染、选择规范化、不可用任务过滤及批量启动结果的覆盖。 杂项： - 添加本地化的批量启动反馈，并重新格式化受影响的语言环境条目。 <details> <summary>Original summary in English</summary> ## Sourcery 摘要 支持从主页可靠地快速启动多个任务，同时保留有效的用户选择并报告启动结果。 新功能： - 支持在一次操作中选择并启动多个主页快速启动任务。 - 持久化所选快速启动任务 ID，并在返回主页时恢复有效的选择。 错误修复： - 在显示或启动前，过滤无效、占位、重复和不可用的快速启动选项。 - 当单个任务失败时，继续启动其余任务。 增强功能： - 提供按顺序排列的批量启动结果，包括本地化的成功数量和每个任务的失败详情。 测试： - 增加对多选渲染、选择规范化、不可用任务过滤和批量启动结果的覆盖。 杂项： - 添加本地化的批量启动反馈消息，并重新格式化受影响的语言环境条目。 <details> <summary>Original summary in English</summary> ## Sourcery 总结 支持从主页可靠地快速启动多个任务，同时保留有效的用户选择并报告启动结果。 新功能： - 支持在一次操作中选择并启动多个主页快速启动任务。 - 持久化所选快速启动任务 ID，并在返回主页时恢复有效选择。 错误修复： - 在显示或启动任务之前，过滤无效、占位、重复和不可用的选择。 - 当单个快速启动任务失败时，继续启动其余任务。 增强功能： - 提供有序的批量启动反馈，包括本地化的成功数量和每个任务的失败详情。 测试： - 增加对多选渲染、选择规范化、不可用任务过滤和批量启动结果的测试覆盖。 维护： - 添加本地化的批量启动消息，并重新格式化受影响的语言环境条目。 <details> <summary>Original summary in English</summary> ## Sourcery 总结 支持从主页可靠地快速启动多个任务，同时保留有效的选择并报告启动结果。 新功能： - 支持在一次操作中选择并启动多个主页快速启动任务。 - 持久化所选任务 ID，并在返回主页时恢复有效的选择。 错误修复： - 在显示或启动前，过滤无效、占位、重复以及不可用的快速启动选择。 - 当某个任务启动失败时，继续启动其余任务。 增强功能： - 提供有序的批量启动反馈，包括本地化的成功数量和每个任务的失败详情。 测试： - 增加对多选渲染、选择规范化、不可用任务过滤以及批量启动结果的测试覆盖。 维护： - 添加本地化的批量启动消息，并重新格式化受影响的语言环境条目。 <details> <summary>Original summary in English</summary> ## Sourcery 摘要 支持从主页可靠地快速启动多个任务，同时保留有效选择并报告启动结果。 新功能： - 支持在一次操作中选择并启动多个主页快速启动任务。 - 持久化选中的快速启动任务 ID，并在返回主页时恢复有效选择。 错误修复： - 在显示或启动任务之前，过滤无效、占位、重复和不可用的选择。 - 当单个快速启动任务失败时，继续启动其余任务。 增强功能： - 提供有序的批量启动反馈，包括本地化的成功数量和每个任务的失败详情。 测试： - 增加对多选渲染、选择规范化、不可用任务过滤和批量启动结果的覆盖。 维护工作： - 添加本地化的批量启动消息，并重新格式化受影响的语言环境条目。 <details> <summary>Original summary in English</summary> ## Summary by Sourcery Support reliable multi-task quick starts from the home page while preserving valid selections and reporting launch results. New Features: - Enable selecting and launching multiple home quick-start tasks in one action. - Persist selected quick-start task IDs and restore valid selections when returning to the home page. Bug Fixes: - Filter invalid, placeholder, duplicate, and unavailable selections before displaying or launching tasks. - Continue launching remaining tasks when an individual quick-start task fails. Enhancements: - Provide ordered batch launch feedback with localized success counts and per-task failure details. Tests: - Add coverage for multi-select rendering, selection normalization, unavailable-task filtering, and batch launch outcomes. Chores: - Add localized batch-launch messages and reformat affected locale entries. </details> </details> </details> </details> </details> </details> </details> </details> </details>
…lan 鐨?weeklyDomain/weeklyLeyLine 宓屽骞跺洖鏄捐繕鍘燂紙鍓嶇闆舵敼鍔級锛宮ain.js 鎸夊綋澶╂槦鏈熷彇鍊肩洿浼狅紝绉樺褰撳ぉ鏃犻厤缃垯璺宠繃锛涗慨澶嶇┖ Plan 鎴栦粎鏈?weekly 鏃?merge 涓㈠け鏁版嵁鐨?bug
## 问题 Runtime 自 `5deb1d8` 起会为 `uv.download` 发真实字节百分比，且下载器在写入末块时**必定**强制回报一次 100。桥接层原样透传，`useInitializationFlow` 见到 `>= 100` 就把当前段标成完成——**uv 下载完末字节的瞬间「安装 Python」就显示完成**，而 SHA-256 校验、解压、`uv --version` 实测都还没跑；紧接着 `python.*` 的事件没有 percent，进度又被压回段起始值 10。 `repair` 与 `environment ensure` 链路中间没有 workspace 段隔开，`python.*` 直接落回同一段，所以这个倒退会停满整个 Python 重装（受限网络下是 20.9 MiB 的下载时长）。镜像轮换让下载从 0 重来时，界面还会出现可见的百分比倒退。 ## 改动 - running 的百分比钳在 `[10, 99]`，100 只由段收口发出——一个界面段里装着好几个 Runtime stage，段没结束就不能让渲染层看到 100 - 段内记录已发出的最高进度，保证只增不减 - 段开始时带着真实百分比仍照发（AUTO-MAS-Project#570 起的既有行为），只是同样受上限约束 只改桥接层与它的测试，渲染层未动。 ## 本地验证 `D:\...\frontend`，corepack yarn 4.9.1 / vitest 4.1.9： - `corepack yarn test`：44 文件 / 414 用例，413 通过 - `corepack yarn typecheck`：exit 0 - `corepack yarn lint`：exit 0 新增三条桥接层用例（末块 100 不提前收口、repair 顺序不倒退、镜像轮换不倒退），在改实现前均为红。 两点需要说明： 1. **另对齐了两条既有期望值**：`repository started` 的 `progress` 10 → 43、`dependency started` 的 `toEqual` 补 `indeterminate: true`。这两条自 AUTO-MAS-Project#570 起就与实现不符、**在 dev 基线上本来就是红的**，本次未改变任何行为。 2. **`backendService.test.ts > managed 模式 > 不传 --repo…` 5 秒超时是基线 `48ed4ccc` 上的既有失败**：把本 PR 改动的两个文件临时换回 dev 原版复跑，仍然红。本 PR 不处理。 未做：没有真机跑过带真实字节进度的 Runtime 初始化看界面表现，结论来自单元测试与渲染层代码路径。 🤖 Generated with [Claude Code](https://claude.com/claude-code) ## Sourcery 总结 通过将 100% 保留给已完成的阶段，并防止阶段内的进度回退，确保运行时引导进度准确。 Bug 修复： - 防止运行时下载完成百分比过早将 Python 安装进度阶段标记为已完成。 - 在下载重试以及后续不带百分比的事件发生时，保持每个引导阶段内的进度单调递增。 增强功能： - 将进行中的进度保持在 100% 以下，并仅将 100% 保留给阶段完成，同时保留实际的起始百分比。 测试： - 添加桥接测试，覆盖下载完成处理、修复进度单调性和镜像轮换重试。 维护： - 根据当前行为调整现有进度桥接测试的预期。 <details> <summary>Original summary in English</summary> ## Summary by Sourcery Keep runtime bootstrap progress accurate by reserving 100% for completed segments and preventing progress regressions within a segment. Bug Fixes: - Prevent runtime download completion percentages from prematurely marking the Python installation progress segment as complete. - Preserve monotonic progress within each bootstrap segment across download retries and subsequent events without percentages. Enhancements: - Keep running progress below 100 and reserve 100 exclusively for segment completion while preserving real starting percentages. Tests: - Add bridge tests covering download completion handling, repair progress monotonicity, and mirror-rotation retries. Chores: - Align existing progress bridge test expectations with current behavior. </details> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
## 问题
MAA 卡死后不会被判定为超时，任务一直挂着。
## 根因
`is_log_stalled` 只用 `latest_time` 判断"有没有推进"。MAA 卡死时每隔提醒间隔（默认 30 分钟）会往
`gui.log` 写一条停滞提示，这条"没有推进"的提示反而刷新了 `latest_time`，把计时反复重置。
`AutoProxyTask.prepare()` 的 `except_logs` 本来就防了这一手，但它只匹配旧版 MAA
`TaskTimeoutWarning` 的中文文案；MAA 后来把该功能重写为
`TaskStallWarning`、文案全换，豁免静默失效——没有报错，只是超时不再触发。
只有超时阈值大于提醒间隔的模式受影响：剿灭 `AnnihilationTimeLimit` 默认 40 分钟、命中热更新时放宽到
`GameUpdateTimeLimit` 默认 60 分钟，都永远判不出超时；日常 `RoutineTimeLimit` 默认 10
分钟，第一条提示还没来就先超时了，不受影响。
实测日志（MAA v6.17.2，剿灭模式）：`17:10:38` 最后一条正常行，之后 4 小时 25 分只剩每 30
分钟一条停滞提示，全程无超时判定。
## 改动
`except_logs` 换成模块级常量 `_MAA_STALL_NOTICE_MARKERS`，收录
`TaskStallWarning`（现行）与 `TaskTimeoutWarning`（旧版）× 简中 / 繁中 / 英 / 日 / 韩共
10 条不含 `{0}`/`{1}`
变量的固定片段。韩文旧文案句中有换行，换行后那半是无时间戳的独立行、本就进不了时间戳解析，只取带时间戳那半行的结尾。
10 条片段均已拿到两代 MAA 的全部 5 个 `Localizations/*.xaml`
里核对：每条恰好命中目标那一条本地化字符串，跨版本互不误伤，也不误伤其它消息——片段若误伤正常日志行会造成假阳性超时，比漏判更糟。
## 本地验证
环境：本工作树 `.venv`（Python 3.12.13），基线 `dev@48ed4cc`
```
python -m pytest tests → 493 passed, 3 skipped, 107 subtests passed
python -m pytest tests --collect-only -q → 496 collected, exit 0
ruff check app/task/MAA/AutoProxy.py → All checks passed
```
（基线为 489 passed / 97 subtests，增量来自下述本地测试。）
按 `tests/AGENTS.md`，bug 边界测试仅本地运行、未提交。该测试不自己拼 `except_logs`，而是 patch 掉
`LogMonitor` 后跑真实的 `prepare()` 捕获实参。反向验证：把 `except_logs` 改回修复前那一行，10
个用例失败，唯一仍通过的是
`TaskTimeoutWarning/zh-cn`——正是修复前就在豁免列表里的那一条。端到端用例按实测日志序列（每 30 分钟一条提示、40
分钟阈值）跑出 `[False, False, True, True]`，55 分钟处开始报超时。
## 遗留
判据形态本身仍与 MAA 的文案原文耦合，MAA
下次改这段文案还会同样静默失效（这已是第二次）。根治需要换判据（例如只认任务链推进类日志），不在本 PR 范围内。
🤖 Generated with [Claude Code](https://claude.com/claude-code)
## Sourcery 总结
确保当重复的停滞通知是后续唯一日志输出时，MAA 任务能够超时。
错误修复：
- 防止 MAA 停滞通知刷新日志活动时间戳，使真正停滞的任务能够达到超时阈值。
- 在支持的语言中识别当前和旧版 MAA 的停滞警告消息，同时保持与旧版 MAA 的兼容性。
<details>
<summary>Original summary in English</summary>
## Summary by Sourcery
Ensure MAA tasks can time out when repeated stall notices are the only
subsequent log output.
Bug Fixes:
- Prevent MAA stall notices from refreshing log activity timestamps so
genuinely stalled tasks can reach the timeout threshold.
- Recognize current and legacy MAA stall-warning messages across
supported languages while preserving compatibility with older MAA
versions.
</details>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
统一公共任务报告的社区摘要、按渠道格式化及兼容旧通知入口。
Closes AUTO-MAS-Project#613 ## 问题 AUTO-MAS-Project#295（`a671fdd1`，2026-08-28）删除了 `Config.send_websocket_message`，98 处调用当时全部迁到 `Publisher`。但 BetterGI 专项 AUTO-MAS-Project#410（`a2c78cfe`，09-01）与 ZZZ-OD 专项 AUTO-MAS-Project#593（`f735b547`，09-08）都在 AUTO-MAS-Project#295 之前拉出分支、之后合入，合并时没跟随这次迁移，dev 上因此留下 **18 处调用、0 处定义**。 `AppConfig` 没有 `__getattr__`，所以这些路径运行时必抛 `AttributeError`，并把真实的出错原因整个盖掉——Sentry 上看到的就是 `BetterGI任务出现异常: 'AppConfig' object has no attribute 'send_websocket_message'`，而不是「配置检查为什么没过」。 ## 改动 18 处全部按 `app/task/MAA` 的既有写法迁移： ```python # 之前 await Config.send_websocket_message( id=self.task_info.task_id, type="Info", data={"Error": msg} ) # 之后 await Publisher.send( id=self.task_info.task_id, type=protocol.TASK_NOTICE, data=WSTaskNoticeData(level="error", message=msg), ) ``` 18 处原本形态完全一致（`type="Info"` + `data={"Error": ...}`），所以是一一对应的机械迁移，**没有改动任何触发条件、状态赋值或控制流**。`BetterGI/ScriptConfig.py` 与 `ZzzOd/ScriptConfig.py` 迁移后不再用到 `Config`，顺带去掉了该 import。 分布：`BetterGI/manager.py` 4、`BetterGI/AutoProxy.py` 1、`BetterGI/ScriptConfig.py` 1、`ZzzOd/manager.py` 9、`ZzzOd/AutoProxy.py` 2、`ZzzOd/ScriptConfig.py` 1。 ZZZ-OD 模块目前整体没过 `ruff format`，本 PR **没有**顺手格式化，以免把无关重排混进来。 ## 本地验证 ``` .venv/Scripts/python.exe -m pytest tests -q 682 passed, 3 skipped, 1 warning, 151 subtests passed in 7.65s .venv/Scripts/python.exe -m pytest tests --collect-only -q # 685 collected, 退出码 0 .venv/Scripts/python.exe -m ruff check app/task/BetterGI app/task/ZzzOd # All checks passed grep -rn "send_websocket_message" app/ # 0 处残留 ``` 未做真机手测：触发这些分支需要装 BetterGI / ZZZ-OD 并造出「检查不通过」的场景，本地没有环境。迁移是形态一致的机械替换，`Publisher.send` 与旧方法签名相同（`id` / `type` / `data`），风险集中在提示能否正常送达前端，建议合并前由专项作者跑一次能触发提示的路径。 ## 请审阅 @TCddddd BetterGI 专项部分，@AthenaHibou ZZZ-OD 专项部分。确认没问题后**请你们自行合并**，我不代合。 ## Summary by Sourcery 将 BetterGI 和 ZZZ-OD 的错误通知迁移到 Publisher，恢复真实任务错误信息向前端的正常传递。 Bug Fixes: - 修复 BetterGI 和 ZZZ-OD 任务错误提示因使用已移除的 WebSocket 配置接口而无法发送，导致前端显示无关的属性错误。 Enhancements: - 统一将 BetterGI 和 ZZZ-OD 的任务通知迁移到现行 Publisher WebSocket 出口，并使用标准化任务通知格式。 <details> <summary>Original summary in English</summary> ## Summary by Sourcery 将 BetterGI 和 ZZZ-OD 的错误通知迁移到 Publisher，恢复真实任务错误信息向前端的正常传递。 Bug Fixes: - 修复 BetterGI 和 ZZZ-OD 任务错误提示因使用已移除的 WebSocket 配置接口而无法发送，导致前端显示无关的属性错误。 Enhancements: - 统一将 BetterGI 和 ZZZ-OD 的任务通知迁移到现行 Publisher WebSocket 出口，并使用标准化任务通知格式。 </details> <details> <summary>Original summary in English</summary> </details> <details> <summary>Original summary in English</summary> </details> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: AthenaHibou <13084046220@163.com>
- 执行层排序支持队列条目 planUid 精确绑定 Plan 实例，同名多实例（自动秘境×3）的左栏拖拽顺序可逐实例生效；队列解析保留 planUid - 执行层超时改为空闲超时（日志静默 300s 判卡死），移除固定 900s 墙钟，多实例长任务不再被误杀 - 执行层失败不再中止任务：记录警告并继续一条龙日常，避免战斗异常连坐吞掉日常收益 - MAS_PLAN_FAIL / MAS_STEP_FAIL 纳入失败判定，执行层 JS 失败不再被「配置组执行结束」误判为成功 - 幽境危战按 BGI 官方 Param 源码修正：移除无效的 maxArtifactStar 透传（前端面板/后端白名单与映射/执行层），策略改为直接调用 setCombatStrategyPath（副作用写入 CombatScriptBagPath），改用无参构造保留全局默认策略 - 组开关保存失败时回滚本地状态并提示，消除界面与后端静默脱节
fastapi_mcp 的 resolve_schema_references 对互相 $ref 引用的模型会无限展开 （A→B→A…），递归约 1000 层即 RecursionError，导致整个后台初始化失败 （MainTimer / 通知管理器等后续服务全部跳过）。 - 加载 fastapi_mcp 后替换为带深度上限（96 层）的同逻辑实现， 超限的 $ref 原样保留，仅影响 MCP 工具 schema 展示完整度 - 同时替换 utils 与 convert 两处按名绑定的函数引用 - 移除启动脚本中的 AUTO_MAS_ENABLE_MCP=0，恢复 MCP 默认开启
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Sorry @TCddddd, your pull request is larger than the review limit of 150,000 diff characters
Closes AUTO-MAS-Project#584 - MAA 计划表模式下不再强制关闭「库存保持」：开启后每天先按库存目标消耗当日自然回复理智（不吃药不碎石），再按计划表刷图 - 固定关卡模式行为不变；库存保持的物品与目标清单仍在用户编辑页配置 ## Sourcery 摘要 让 MAA 计划表模式支持库存保持，同时保留固定关卡模式的既有行为。 新功能： - 允许 MAA 计划表模式启用库存保持，并在每日计划作战前执行库存目标消耗自然回复理智。 改进： - 统一固定关卡与计划表模式的库存保持配置和用户编辑体验。 文档： - 更新变更日志，说明计划表模式库存保持行为及升级后的配置影响。 测试： - 更新库存保持摘要测试，以覆盖固定关卡与计划表模式下的统一行为。 杂项： - 更新项目版本信息。 Co-authored-by: HarcoChen <HarcourtC@stu.xjtu.edu.cn>
…O-MAS-Project#626) ### 摘要 - 修复任务运行期间脚本日志按天滚动（跨零点）后，零点前的运行日志历史与任务报告中采集到的节点详情丢失的问题：日志监控（LogMonitor）与日志采集（log_box）在检测到日志轮转时不再清空已读内容，并会在同目录按 inode 找回被重命名的旧日志、从中断位置续读未读部分 - 通用日志采集（log_box）新增 `rotated_name` 参数：日期式滚动命名（如 zzz-od 的 `log.txt.YYYY-MM-DD`、OK 系的 `ok-script.YYYY-MM-DD.log`）由各专项声明 strftime 模板，文件系统不提供 inode 时这是唯一兜底；zzz-od / OK-WW / OK-NTE 专项已接入 - 更新专项适配 Skill：新增「日志轮转补偿」约定——接入前确认脚本滚动方式（重命名式 / 日期式 / 删除重建式），并同步 get_collect 参数说明与常见坑 ## Sourcery 摘要 修复跨零点日志轮转导致的运行日志和节点详情丢失，并完善不同轮转命名方式的日志采集补偿支持。 新功能： - 为通用日志采集增加 `rotated_name` 配置，支持按日期模板定位轮转日志。 Bug 修复： - 修复跨零点日志轮转后 LogMonitor 丢失历史日志、log_box 丢失未读内容及任务报告节点详情的问题。 增强功能： - 统一通过 inode 找回被重命名的旧日志并从原偏移续读，同时保留轮转前的监控历史。 - 为 ZZZ-OD、OK-WW 和 OK-NTE 专项声明日期式日志轮转命名模板。 文档： - 补充专项适配指南和 log_box API 中关于日志轮转方式、补偿策略及 `rotated_name` 的接入说明。 <details> <summary>Original summary in English</summary> ## Sourcery 摘要 防止跨午夜日志轮换导致运行时历史记录丢失，以及已收集的节点详细信息丢失。 新功能： - 添加可配置的日期模式回退支持，用于在不提供 inode 信息的文件系统上定位轮换后的日志。 错误修复： - 保留午夜前的日志历史记录，并在脚本日志轮换期间恢复未读取的日志内容和任务报告中的节点详细信息。 增强功能： - 统一基于 inode 匹配和偏移量续读的轮换日志恢复机制，同时记录轮换要求和集成指南。 文档： - 记录日志轮换补偿行为、`rotated_name` 的用法、支持的轮换模式，以及适配器集成中的常见问题。 <details> <summary>Original summary in English</summary> ## Sourcery 摘要 在午夜日志轮换期间保留运行时日志历史记录和已收集的节点详细信息，同时扩展对基于日期的轮换名称的恢复支持。 新功能： - 添加可配置的日期模式回退支持，用于在不提供 inode 信息的文件系统上定位轮换后的日志。 错误修复： - 保留午夜前的 LogMonitor 历史记录，并恢复未读取的轮换日志内容，以确保日志轮换后任务报告仍包含完整的节点详细信息。 增强功能： - 统一基于 inode 匹配和基于偏移量的续读机制进行轮换日志恢复，并安全处理不支持的删除或截断轮换模式。 文档： - 记录日志轮换补偿要求、rotated_name 的使用方式、支持的轮换模式以及适配器集成指南。 <details> <summary>Original summary in English</summary> ## Summary by Sourcery 保留跨零点日志轮转期间的运行日志和节点详情，并完善不同文件系统与命名方式下的轮转日志恢复支持。 New Features: - 为通用日志采集增加 `rotated_name` 配置，支持在无 inode 文件系统上按日期模板定位轮转日志。 Bug Fixes: - 修复跨零点日志轮转后 LogMonitor 历史日志、未读日志内容及任务报告节点详情丢失的问题。 Enhancements: - 统一通过 inode 定位重命名的旧日志并从原偏移续读，同时保留轮转前的监控历史。 - 为 ZZZ-OD、OK-WW 和 OK-NTE 日志采集接入日期式轮转命名支持。 Documentation: - 补充日志轮转补偿策略、`rotated_name` 用法及专项适配注意事项。 <details> <summary>Original summary in English</summary> ## Summary by Sourcery 保留跨零点日志轮转期间的运行日志和节点详情，并完善不同文件系统与命名方式下的轮转日志恢复支持。 New Features: - 为通用日志采集增加 `rotated_name` 配置，支持在无 inode 文件系统上按日期模板定位轮转日志。 Bug Fixes: - 修复跨零点日志轮转后 LogMonitor 历史日志、未读日志内容及任务报告节点详情丢失的问题。 Enhancements: - 统一通过 inode 定位重命名的旧日志并从原偏移续读，同时保留轮转前的监控历史。 - 为 ZZZ-OD、OK-WW 和 OK-NTE 日志采集接入日期式轮转命名支持。 Documentation: - 补充日志轮转补偿策略、`rotated_name` 用法及专项适配注意事项。 </details> </details> </details> </details> <details> <summary>Original summary in English</summary> </details>
署名机器人跑的是 main 上的旧脚本（见 AUTO-MAS-Project#629），把 AUTO-MAS-Project#622 的分类改名当成新增条目， 给 56 条历史条目追加了 by [@qiyinxi]，AUTO-MAS-Project#625 又把这批误签抄进了 CHANGELOG.md。 本提交按 AUTO-MAS-Project#622 合入时的状态还原，并按各条改动实际提交/PR 的作者补齐空缺署名。 Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
## 摘要 - Emulator 2.0 的带包启动此前只在冷启动时把包名交给厂商 CLI，模拟器已经在跑时 `open()` 直接返回、包名整条被吞；而 MAS 里模拟器常常是上一个用户留下来的，于是它偏偏在最需要的场景不生效。改成两步：先只开模拟器，再单独把应用拉起来并确认真的进了前台，冷热两条路都覆盖。 - 拉应用改为三路齐发（厂商 CLI + `monkey` + `am start`）。实测明日方舟：雷电 14 的镜像里根本没有 `monkey`（返回码 127），MuMu 6 三条都通；任何「以某一条为主、其余兜底」的排法都会在另一家先白等一轮超时。三条是同一个 LAUNCHER 意图，Android 会归并成把已有任务提到前台，实测齐发只产生一个 task。 - 一并挡住 `emulator-NNNN` 被别家模拟器顶包：该别名归属于占住回环 `5554+2N` 端口的进程。实测 MuMu 除自己的 16384 外还绑 `127.0.0.1:5555`，正好是雷电 0 号的端口，而雷电绑 `0.0.0.0:5555`，回环流量因此进了 MuMu；归属取决于两家的启动顺序，`resolve_serial` 两种情况都标「核对通过」。现在核对到别家标志包时不再发出该地址，改为记一条可照做的警告并让启动步骤明确失败，而不是静默操作另一台模拟器。 - 顺带修正 `pm path` 的判据：没装的包是「返回码 1 + 输出为空」，设备掉线是「返回码 1 + 错误文本」；原先按返回码 0 判，导致该分支在真机上从未触发。 改动全部落在 `app/utils/emulator2/` 内，`app/utils/emulator/`（1.0）未改动。 ## 本地验证 真机（明日方舟）： | | 旧 `open(idx, 包名)` | 新 `open(idx, 包名)` | | --- | --- | --- | | MuMu 6 实例 0 | 游戏不在前台 | 在前台，0.55s | | 雷电 14 实例 0 | 游戏不在前台 | 在前台，0.14s | 不给包名时两家都只开模拟器、不碰应用，行为与原来一致；冷启动路径亦覆盖。 各启动方式单独实测：厂商 CLI MuMu 0.06s / 雷电 0.06s；`monkey` MuMu 0.05s / 雷电返回码 127 不存在；`am start` MuMu 0.03s / 雷电 0.06s；齐发两家均只产生一个 task。 顶包检测两个方向都验过：MuMu 先起占住 5554 时，`getInfo` 返回空 ADB 地址、`launch_app` 返回 `no-adb` 且不误操作 MuMu，警告按序列号缓存只记一条；MuMu 关闭后雷电恢复正常并成功启动游戏。 自动化：`python -m pytest tests` 731 passed / 3 skipped（新增 21 个纯逻辑用例 + 12 subtests）；收集门槛 `--collect-only` 734 条退出码 0；`ruff format --check` 与 `ruff check` 对改动文件无问题；`python scripts/changelog.py check` 退出码 0。 ## 备注 `res/version.json` 中三条 `by [@AthenaHibou]` 的移除并非本 PR 有意为之：署名机器人只把它们写进了生成物、未写回 `CHANGELOG.md`，因此按文档执行 `python scripts/changelog.py sync` 会一并剥掉。此问题在本 PR 之外，另行处理。 🤖 Generated with [Claude Code](https://claude.com/claude-code) ## Sourcery 摘要 修复 Emulator 2.0 的带包启动可靠性，并阻止跨模拟器 ADB 序列号误绑定。 新功能： - 为 Emulator 2.0 增加独立的带包启动流程，支持模拟器已运行和冷启动场景。 - 提供在已在线模拟器上单独启动应用的管理接口，并返回明确的启动结果。 错误修复： - 修复模拟器已运行时应用包名被吞导致应用未启动的问题。 - 修复雷电与 MuMu 竞争回环 ADB 序列号时误操作另一台模拟器的问题。 - 修正未安装应用与设备掉线的 `pm path` 判定逻辑。 改进： - 应用启动改为厂商 CLI、monkey 和 am start 三路并发，并在确认应用进入前台后完成。 - 扩展前台 Activity 识别以兼容不同 Android 版本的 dumpsys 输出格式。 文档： - 更新 Emulator 2.0 变更记录。 测试： - 新增应用前台识别、包安装状态、启动组件解析及多路径启动编排的自动化测试。 <details> <summary>Original summary in English</summary> ## Sourcery 摘要 提升 Emulator 2.0 带包启动的可靠性，并防止跨模拟器 ADB 序列号误绑定。 新功能： - 为 Emulator 2.0 增加可独立调用的应用启动流程，覆盖模拟器已运行和冷启动场景，并返回明确的启动结果。 问题修复： - 修复模拟器已运行时带包启动未能打开应用的问题。 - 阻止雷电与 MuMu 竞争 ADB 序列号时误操作另一台模拟器。 - 修正未安装应用与设备掉线的包安装状态判定。 改进： - 将应用启动调整为厂商 CLI、monkey 和 am start 三路并发，并通过前台 Activity 确认启动结果。 - 扩展前台 Activity 识别，以兼容不同 Android 版本的 dumpsys 输出。 文档： - 更新 Emulator 2.0 变更记录。 测试： - 新增应用前台识别、包安装状态、启动组件解析及多路径启动编排测试。 <details> <summary>Original summary in English</summary> ## Summary by Sourcery 提升 Emulator 2.0 带包启动的可靠性，并防止跨模拟器 ADB 序列号误绑定。 New Features: - 为 Emulator 2.0 增加可独立调用的应用启动流程，覆盖模拟器已运行和冷启动场景，并返回明确的启动结果。 Bug Fixes: - 修复模拟器已运行时带包启动未能打开应用的问题。 - 阻止雷电与 MuMu 竞争 ADB 序列号时误操作另一台模拟器。 - 修正未安装应用与设备掉线的包安装状态判定。 Enhancements: - 将应用启动调整为厂商 CLI、monkey 和 am start 三路并发，并通过前台 Activity 确认启动结果。 - 扩展前台 Activity 识别以兼容不同 Android 版本的 dumpsys 输出。 Documentation: - 更新 Emulator 2.0 变更记录。 Tests: - 新增应用前台识别、包安装状态、启动组件解析及多路径启动编排测试。 </details> </details> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
署名机器人只把 by [@qiyinxi] 写进了 res/version.json（main 上跑的仍是旧脚本， 见 AUTO-MAS-Project#629），CHANGELOG.md 没有同步，dev 上的 changelog check 因此退出 1。 Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
MaaFramework 把 `debug/maafw.log` 写到一定大小就整体挪成 `debug/maafw.bak.<时间戳>.log` 再开新的，但从不回收旧的。实测一个每天跑的 MaaEnd 项目四天堆了 15 个备份、385 MB，而这些内容每次运行都已经另存进历史记录的 `*.maafw.log`，原地那份是纯冗余。 - 新增 `clean_maafw_native_debug_logs()`，随启动清理一并执行，保留时长沿用 `Function/HistoryRetentionTime`，与旁边的 `clean_debug_diagnostics` 同一口径；设为「永久保留」时整轮弃权 - 只删 `maafw.bak.*.log`，正在写的 `maafw.log`、`go-service.log`、`debug/record/` 都不动；单个文件删失败只记 warning 不中断 ## 本地验证 | 命令 | 结果 | | --- | --- | | `python -m pytest tests/core tests/task -q` | 376 passed, 68 subtests | | `python -m pytest tests --collect-only -q` | 退出码 0，737 collected | | `ruff check` / `ruff format --check`（本 PR 新增的代码） | All checks passed / already formatted | `main.py` 的 I001 与 `app/core/config.py` 的 format 差异在本分支基点上就已存在（拿 `git show HEAD:` 的原始文件复核过），且格式化涉及的最后一处在第 2948 行、本 PR 代码在 4293 行，未受影响，因此没有顺带格式化。 按 `tests/AGENTS.md`，对应的边界测试只在本地运行，未随 PR 提交。 🤖 Generated with [Claude Code](https://claude.com/claude-code) ## Sourcery 摘要 通过在启动维护中加入基于保留策略的清理机制，防止 MaaFramework 原生调试日志备份无限累积。 改进： - 根据配置的历史记录保留期限清理已过期的 MaaFramework 原生日志备份，同时保留活动日志和无关的调试文件。 杂项： - 更新日志清理变更的变更日志和版本元数据。 <details> <summary>Original summary in English</summary> ## Summary by Sourcery Prevent MaaFramework native debug log backups from accumulating indefinitely by including their retention-based cleanup in startup maintenance. Enhancements: - Clean expired MaaFramework native log backups according to the configured history retention period while preserving active logs and unrelated debug files. Chores: - Update the changelog and version metadata for the log cleanup change. </details> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
系统 ANSI 代码页不是中文时（复现环境 en-GB / cp1252），M7A 每个模块跑完都会崩在 `utils/console.py` 的「按任意键继续」——中文写不进 stdout。此时任务正文早已完成，MAS 却按非零退出码判成失败并整轮重跑；实测一次差分宇宙已经打到 18000/18000，仍被从头再刷一遍。 - 子进程带上 `MARCH7TH_GUI_STARTED`（M7A 自己的图形界面拉起 CLI 用的就是它），`should_skip_pause()` 放行全部四处暂停，进程正常走到 `sys.exit(0)`；`ProcessManager.open_process` 相应新增 `env` 形参 - `has_failure_output` 原本要求日志里出现 `EOF when reading a line` 才放行这类收尾崩溃，锚的是症状；改为锚崩溃位置 `pause_on_success`（正文已跑完的判别式），`pause_on_error` 那条仍要求 EOF，避免把真失败洗成成功 补充两条实测结论：`PYTHONIOENCODING` / `PYTHONUTF8` 对 PyInstaller 冻结的 M7A 完全无效（stdout 编码始终是 ANSI 代码页），所以没走环境编码这条路；`pause_on_error()` 后面是无条件 `sys.exit(1)`，跳过暂停不会让真失败变成成功。 ## 本地验证 | 命令 | 结果 | | --- | --- | | `python -m pytest tests/task tests/platform -q` | 338 passed, 3 skipped, 65 subtests | | `python -m pytest tests --collect-only -q` | 退出码 0，741 collected | | `ruff check` / `ruff format --check`（本 PR 触及的文件） | All checks passed / already formatted | 另用触发该问题的真实历史日志回放两版判据，三个模块的结论全部翻转： ``` 模块 完成标记 旧判据 新判据 体力与培养目标 True 失败 成功 日常与奖励 True 失败 成功 差分宇宙 True 失败 成功 ``` 按 `tests/AGENTS.md`，对应的边界测试只在本地运行，未随 PR 提交。 🤖 Generated with [Claude Code](https://claude.com/claude-code) ## Sourcery 摘要 防止 3 月 7 日助手完成时发生的崩溃，导致已完成的《崩坏：星穹铁道》任务被重新运行。 Bug 修复： - 防止在非中文系统区域设置下，已完成的《崩坏：星穹铁道》3 月 7 日助手模块被错误标记为失败并重新运行。 - 将成功后的暂停阶段崩溃识别为成功完成，同时继续将错误后的暂停阶段崩溃视为失败。 功能增强： - 允许受管理的子进程接收自定义环境变量，并以非交互式 GUI 模式运行 3 月 7 日助手。 杂项： - 更新变更日志和项目版本，以应用此修复。 <details> <summary>Original summary in English</summary> ## Summary by Sourcery Prevent March 7th Assistant completion crashes from causing already-finished Honkai: Star Rail tasks to be rerun. Bug Fixes: - Prevent completed Honkai: Star Rail March 7th Assistant modules from being incorrectly marked as failed and rerun on non-Chinese system locales. - Recognize post-success pause crashes as successful completion while continuing to treat post-error pause crashes as failures. Enhancements: - Allow managed subprocesses to receive custom environment variables and run March 7th Assistant in non-interactive GUI mode. Chores: - Update the changelog and project version for the fix. </details> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
主页卫星的脚本类型清单是手工维护的，和 `SCRIPT_LOGOS` 平行存在。它是普通数组，少一个不报错；末尾还有一句 `.filter(module => module.iconUrl !== '')`，图标文件名写错就静默丢掉，连日志都没有。 因此漏过三次： ``` 4fb31ef hotfix: 补充NTE新主页入口，补充HSR和NTE的卫星图 a5cfad2 fix(home): 首页卫星补上 MaaFW，否则它跑起来首页没有反馈 ``` 改成从 `SCRIPT_LOGOS` 取图标。它声明成 `Record<ScriptType, string>`，新增脚本类型时不补图标会当场 typecheck 报错，漏不掉。 原有的轨道排列顺序保留，但它降级成纯观感项、不再是白名单——没列进顺序表的类型排在后面，所以下一个新脚本不动这里也会自动上轨。 通用脚本仍然不上轨道，理由写进了注释：它在 `SCRIPT_LOGOS` 里用的就是 `AUTO-MAS.ico`，也就是卫星圈的中心图标，放上去会出现一颗和中心一模一样的卫星。 测试从「只断言 Okww 存在」改成钉住「除显式排除的以外，每个脚本类型都有卫星」。 **用户可见行为不变**：仍是同样 10 颗卫星、同样顺序，所以 changelog 记在「开发流程」。 ## 验证 | 检查 | 结果 | | --- | --- | | `yarn vitest run src/composables/satellite-config.test.ts` | 5 passed | | `yarn typecheck` | exit 0 | | `yarn lint` | exit 0 | 🤖 Generated with [Claude Code](https://claude.com/claude-code) ## Sourcery 摘要 从集中式脚本图标注册表中获取首页卫星图标，确保新脚本类型不会被悄然遗漏。 错误修复： - 确保除明确排除的通用脚本外，每种脚本类型都作为首页卫星显示，并且具有非空图标。 增强功能： - 使用集中式脚本图标注册表提供首页卫星图标，同时保留现有的轨道顺序，并自动将新添加的类型排列在之后。 - 强化卫星配置测试，以检测缺失的脚本覆盖范围和无效图标。 测试： - 更新卫星配置测试，以验证完整的脚本覆盖范围、图标可用性、排除项和排序。 <details> <summary>Original summary in English</summary> ## Summary by Sourcery Source homepage satellite icons from the centralized script icon registry so new script types cannot be silently omitted. Bug Fixes: - Ensure every script type except the explicitly excluded general script appears as a homepage satellite with a non-empty icon. Enhancements: - Use the centralized script icon registry for homepage satellite icons while preserving the existing orbit order and automatically placing newly added types afterward. - Strengthen satellite configuration tests to detect missing script coverage and invalid icons. Tests: - Update satellite configuration tests to validate complete script coverage, icon availability, exclusions, and ordering. </details> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
全局设置的「虚拟显示器」说明里写着「需先自行安装 Parsec
虚拟显示驱动」，但下载入口只出现在驱动检测不通过时的那条告警里，已经装好驱动的人反而无处可点。现在那句话本身就是链接，点击用系统默认浏览器打开。
顺带把原来钉在 `v0.45.1` 的安装包直链换成 `releases/latest`：直链会随上游发版失效，点下去也是直接落一个
exe，用户没机会先看清自己在装什么。
中英日三套词表都改成 `{driverLink}` 占位符（句中位置与标点各语言不同，用 `<i18n-t>`
而非拼接多段词条）。本地起前后端逐语言看过渲染与点击目标，`yarn typecheck` / `yarn lint` 均退出 0。
🤖 Generated with [Claude Code](https://claude.com/claude-code)
## Sourcery 总结
将虚拟显示驱动程序要求改为指向 GitHub 最新版本发布页面的本地化链接。
新功能：
- 在中文、英文和日文的全局设置说明中，使 Parsec 虚拟显示驱动程序要求可直接点击。
- 打开最新的 Parsec 虚拟显示驱动程序发布页面，而不是固定版本的安装程序下载链接。
错误修复：
- 确保已安装驱动程序的用户仍可通过虚拟显示说明访问驱动程序下载。
文档：
- 在更新日志中记录新的虚拟显示驱动程序下载入口。
<details>
<summary>Original summary in English</summary>
## Summary by Sourcery
Make the virtual display driver requirement a localized link to the
latest GitHub release page.
New Features:
- Make the Parsec virtual display driver requirement in the global
settings description directly clickable in Chinese, English, and
Japanese.
- Open the latest Parsec virtual display driver release page instead of
a version-pinned installer download.
Bug Fixes:
- Ensure users who already have the driver installed can still access
the driver download from the virtual display description.
Documentation:
- Document the new virtual display driver download entry in the
changelog.
</details>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
## 摘要 - MFW 用 Adb controller 时只开模拟器，游戏要等脚本自己那套流程冷启动。现在启动模拟器时可一并把游戏拉起来，接上 AUTO-MAS-Project#635 的模拟器带包启动能力。 - 包名默认从项目里自动识别：`interface.json` 中并没有包名字段（ProjectInterface 规格里就没有这一项），真正的包名写在 pipeline 节点的 `StartApp` 动作参数里。M9A 的九个服各自在 `resource/<服>/pipeline/startup.json` 覆盖同一个节点，靠 `resource[].path` 顺序叠加；MaaEnd 则放在 option 的 `pipeline_override` 里、取决于所选 `ClientVersion`。两种放法都已覆盖。 - 这是约定而非契约，因此识别不出、或识别到多个互相矛盾的包名时一律不猜，回落到手动填写并在运行日志中说明原因。配置只新增 `Game.PackageName` 一项：填了即手动覆盖，留空即自动识别，同一概念不让用户选两次。 - 顺带修正任务前后脚本的触发次数：此前前脚本在重试循环内、后脚本在每次尝试的 `finally` 内，一个用户重试三次就各跑三遍；现改为每用户各一次。后脚本仍保留在 `finally`，成功、重试全败与中途取消都会跑到。 ## 本地验证 包名识别对着两个真实项目逐项实跑： | 项目 | 结果 | | --- | --- | | M9A 九个服（官服 / B 服 / OPPO / 小米 / 华为 / EN / JP / KR / 港澳台） | 各自得到正确包名，含 `base + global_jp + global_en` 这类三层叠加 | | MaaEnd 五个 option case（CN / Bilibili / Global / VN / Cloud） | 各自得到正确包名 | | 顺序敏感性 | 颠倒 `resource[].path` 顺序会得到上一层的包名，符合覆盖语义 | | 冲突与空输入 | 分别得到 `ambiguous`（附候选列表）与 `not-found`，均不猜测 | 前后脚本改动实跑 `main_task` 三条路径对照： | 场景 | 改动前 | 改动后 | | --- | --- | --- | | 第一次即成功 | 前 1 次 / 后 1 次 | 前 1 次 / 后 1 次 | | 重试 3 次全失败 | 前 3 次 / 后 3 次 | 前 1 次 / 后 1 次 | | 首次尝试时取消 | 前 1 次 / 后 1 次 | 前 1 次 / 后 1 次，`CancelledError` 仍正常外抛 | 自动化：`python -m pytest tests` 744 passed / 3 skipped（新增 13 个纯逻辑用例 + 8 subtests，并更新既有 `test_maafw_config` 的字段数量断言）；收集门槛 `--collect-only` 747 条退出码 0；`ruff format --check` 与 `ruff check` 对改动文件无问题；`python scripts/changelog.py check` 退出码 0。前端 `yarn typecheck`、`yarn lint` 无问题，OpenAPI 由生成器更新（生成物为 CRLF，已按仓库行尾归一化，净差异仅 `MaaFWConfig_Game.ts` 一个文件）。 ## 已知问题（均非本 PR 引入） - `frontend/electron/services/backendService.test.ts` 有一个用例稳定超时失败；本 PR 未改动 `frontend/electron/` 下任何文件。 - 后端 `tests/task/test_maafw_embedded_prepare_cancel.py` 的三个用例在仅按 `uv sync --group dev` 建立的环境下失败，原因是 `dev` 依赖组未包含 `pytest-asyncio`；补装后全部通过，上述 744 即为补装后的结果。 - 任务前后脚本的触发口径在各专项间并不一致（MAA 与 HSR 为每用户一次，其余七个在重试循环内；取消时跑收尾脚本的此前仅 MaaFW 一家）。本 PR 只调整 MaaFW，统一其余专项宜另行处理。 🤖 Generated with [Claude Code](https://claude.com/claude-code) ## Sourcery 摘要 允许 MFW 模拟器运行自动启动已配置的游戏，并执行按用户划分的生命周期脚本，同时避免重试导致脚本重复执行。 新功能： - 启用 MFW ADB 模拟器启动时同时启动关联的 Android 游戏，支持使用手动配置的软件包名称，或通过基于项目的安全自动检测来确定软件包名称。 - 添加 `Game.PackageName` 设置及相应的界面、API 模型和本地化说明，以支持手动覆盖或在必要时回退到自动检测。 错误修复： - 防止 MFW 任务前置脚本和任务后置脚本在每次重试时重复运行，改为每个用户仅执行一次，同时保留在成功、失败和取消情况下执行任务后置脚本的行为。 增强功能： - 从分层资源管道和任务管道覆盖配置中检测游戏软件包；当未找到软件包或发现冲突的软件包时拒绝猜测，并在任务日志中报告检测结果。 文档： - 在变更日志中记录新的 MFW 模拟器游戏启动行为以及按用户执行脚本的语义。 测试： - 增加对软件包规范化、管道提取、资源分层、任务覆盖、歧义处理、数据缺失和无法读取的管道文件的测试覆盖。 - 更新 MFW 配置清单预期，以包含新的游戏软件包设置。 <details> <summary>Original summary in English</summary> ## Sourcery 摘要 允许 MFW 模拟器会话自动启动游戏，同时使生命周期脚本按每位用户执行一次，而不是每次重试执行一次。 新功能： - 支持 MFW ADB 模拟器运行在启动模拟器的同时启动已配置的 Android 游戏，可使用手动指定的包名或基于项目的安全自动检测。 - 在后端、API 模型、前端配置和本地化 UI 中新增 `Game.PackageName` 设置。 错误修复： - 确保 MFW 的每用户 before-task 和 after-task 脚本按每位用户执行一次，而不是在重试时重复执行，同时保留 after-task 脚本在成功、失败和取消情况下的执行。 增强功能： - 从分层资源管道和选定的任务覆盖设置中检测游戏包，并在候选项缺失或冲突时报告问题，而不是进行猜测。 文档： - 在更新日志中记录新的 MFW 模拟器游戏启动行为以及按用户执行一次的生命周期脚本语义。 测试： - 增加对包名规范化、管道提取、分层资源和任务覆盖解析、歧义处理、数据缺失以及无法读取管道文件的测试覆盖。 - 更新 MFW 配置清单预期，以包含新的游戏包设置。 <details> <summary>Original summary in English</summary> ## Summary by Sourcery Allow MFW emulator sessions to launch their game automatically while making lifecycle scripts execute once per user rather than once per retry. New Features: - Enable MFW ADB emulator runs to launch the configured Android game alongside the emulator, using a manual package name or safe project-based auto-detection. - Add the Game.PackageName setting across backend, API models, frontend configuration, and localized UI. Bug Fixes: - Ensure MFW per-user before-task and after-task scripts execute once per user instead of repeating on retries, while preserving after-task execution on success, failure, and cancellation. Enhancements: - Detect game packages from layered resource pipelines and selected task overrides, reporting missing or conflicting candidates without guessing. Documentation: - Document the new MFW emulator game-launch behavior and per-user lifecycle script semantics in the changelog. Tests: - Add coverage for package normalization, pipeline extraction, layered resource and task override resolution, ambiguity handling, missing data, and unreadable pipeline files. - Update MFW configuration inventory expectations for the new game package setting. </details> </details> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
…TO-MAS-Project#641) 对 dev 做了一轮全量静态审计（主页 / M9A / MFW / HSR），这个 PR 收的是其中已经核实、且改动自洽的那批。每条都在正文里给了触发路径，不是「看着像」。 ## 需要留意的两处行为变更 **HSR 周标记的翻页时刻后移四小时。** 原先按东八区自然周算，实际游戏在服务器时间周一 04:00 才重置。改用 UTC+4（其零点正是重置时刻）后，存量用户的「本周已完成」状态会有一次跳变：周一 00:00~04:00 这个窗口内，标记从「新一周」变回「上一周」。这正是要修的东西——原先这个窗口里跑的那轮，会把上一周已完成的结果写成新一周的完成态，等游戏真重置后整周都不再尝试。 **MFW 的控制方式不再被残留的模拟器选择覆盖。** 那些「选了 Win32 但一直在按 ADB 运行且没察觉」的存量脚本，行为会当场变成按 Win32 跑。 ## MFW - **worker 跑的是安装包自带的旧引擎代码。** 受 Runtime 监督时后端工作目录是 `<app-root>`、源码在 `<app-root>/repo/`，而 `<app-root>` 下还有安装包自带的那棵源码树（只随整包安装更新）。worker 以 `python -m` 启动，cwd 被插到 `sys.path[0]` 且排在 `PYTHONPATH` 之前，于是导入旧那份。现场实测：后端跑 beta.3、worker 跑 beta.2，仅 `app/task/MaaFW` 子树就差 41 个 `.py`（含 `runner/environment.py`、`interface/loader.py`、`task_config.py`）。不报错，但 MFW 引擎侧的修复永远等不到热更新生效。改为 `SOURCE_ROOT` + `PYTHONSAFEPATH=1`；worker 的 cwd 保持不变，因为运行池、更新缓存等用户数据都按它解析。`PYTHONSAFEPATH` 不透传给项目 Python agent——agent 靠脚本目录进 `sys.path[0]` 才能 import 同级模块。 - **模拟器的「最大等待时间」对 MFW 从未生效。** `MaaFWDeviceConfig` 有两份同名类，`models` 那份有 `adbReadyTimeout`、`runner` 那份没有；宿主按前者序列化 job、worker 按后者反序列化，pydantic 默认 `extra="ignore"` 静默丢掉，等 ADB 就绪一直用常量 180 秒。删掉重复定义统一从 `models` 导入。 - **项目跑过一次后，Mirror 酱的增量更新永远校验失败。** 指纹把 `debug/`、`config/maa_option.json`、`__pycache__` 算进哈希，而 runner 每次启动都会写它们；基线对不上又没有回退全量包的分支，于是再也装不上更新。新增 `FINGERPRINT_IGNORED_*` 单独排除，没动 `RESERVED_PROJECT_DIRS`——那个还用于拒绝更新包写入保留路径，塞进去会让本来就带 `config/` 的合法包装不上。 - **选了 Win32 仍按 ADB 运行。** 运行时把「配了模拟器」排在用户显式选的 controller 前面；而 Win32 分支下模拟器下拉被隐藏，用户没有入口清掉旧的 `Emulator.Id`。改为显式选择优先，并在前端切到非 ADB 时清空模拟器选择。 ## HSR - **周常与历战余响的「本周已完成」提前四小时翻页**（见上）。三处改用 UTC+4 并抽出 `_server_day_clock` 统一换算，注入的时刻一并归一——标记是那个瞬间的属性，与调用方时区无关。用户列表标签和用户页的「标记完成 / 重置」按钮同步改口径，否则页面显示和实际跑不跑对不上。 - **多个用户共用一套 M7A 时，差分宇宙与货币战争从第二个用户起永远记不到完成。** M7A 的周常时间戳按安装目录存、不按游戏账号存：上一个用户打满后写进共享的 `config.yaml`，下一个用户的 patch 以它为底合并，M7A 就跳过积分复核、不再打印 MAS 唯一认的完成 marker，于是天天重跑。把两个时间戳归零，并同时加入 patch 白名单（否则 `merge_whitelist` 会丢掉）和 `M7A_MANAGED_STAGE_KEYS`（否则 `_apply_managed_patch` 会用 native 值覆盖回去）——与日常 patch 处理 `echo_of_war_timestamp` 是同一口径。 ## M9A - **未配置任务队列的用户运行时抛 Python 异常。** 代码给只读 property `UserItem.result` 赋值，`AttributeError` 顶掉了本该显示的「未配置任务队列或队列为空」。`Task_Queue` 默认就是 `[]` 且 `check()` 不校验队列，新建用户不加任务直接跑就必中。 - **配置模板每次运行都被删掉。** `prepare()` 的注释写「仅保留 default.json」，实际 `glob("*.json")` 把它一起删了，而它正是 `build_config` 的模板：每轮第一个用户必然落到「使用最小默认配置」，后续用户读到的是 MAS 自己刚写的那份——用户在 M9A 里设的实例级选项从未生效。 ## 主页 - **重返未来 1999 的倒计时整体提前一个时区偏移量。** epoch 毫秒转成 `toISOString().slice(0, 19)`，切掉 `Z` 后消费端 `new Date()` 按本机时区解析（东八区偏 8 小时）。保留 `Z` 即可；被 AUTO-MAS-Project#497 删掉的后端接口输出的也是带偏移的时间。 ## 发布流程 - **发版后 CNB 上缺当版发行分支。** `build-app.yml` 用 `secrets.GITHUB_TOKEN` 推发行版分支和 tag，而 GITHUB_TOKEN 造成的 push / create 不触发其它工作流，`sync-cnb.yml` 因此不会为发版跑一次。tag 还能靠后续任意一次同步的 `PLUGIN_PUSH_TAGS` 补上，分支没这个待遇。而 beta.3 是第一个捆绑 Runtime 的版本、打包安装默认走 managed 链路，首次克隆受管工作区按 `[cnb, github]` 找这个分支——国内用户在 cnb 上找不到又连不上 github，初始化直接卡死。给 `sync-cnb.yml` 加 `workflow_dispatch`（该触发器是上述限制的明确例外），并在推完分支后 `gh workflow run` 一次。**注意这一步要等本改动进入默认分支后才真正生效**；在那之前 dispatch 会被拒，所以该步骤带 `continue-on-error`，不会阻断发版。已发布的 beta.3 由维护者手动补过同步，CNB 上现已有该分支。 - **Runtime 调用失败只留一句错误码。** `details` 里每次尝试的来源与失败种类被丢掉，于是 cnb 缺分支、github 超时两件事最终只显示后者，真根因被盖住。现在一并写进日志。 ## 验证 均在 `.venv` 下实跑： | 检查 | 结果 | | --- | --- | | `python -m pytest tests` | 738 passed, 3 skipped, 163 subtests | | `python -m pytest tests --collect-only -q` | 741 collected，exit 0 | | `python -m ruff check app tests` | 无本次引入的问题（剩余 I001 已逐个比对确认是 dev 上既存的） | | `yarn typecheck` | exit 0 | | `yarn lint` | exit 0 | | `yarn test` | 418 passed，1 failed | 前端那条失败是 `backendService.test.ts > managed 模式` 超时，**在 dev 上就是红的**：我把改动过的 `backendService.ts` 换回 dev 原版单跑该文件，同样失败。 `yarn format` 会顺带重排十几个本次无关的文件（dev 上本来就没格式化过），已逐个还原，diff 里只有本次真正改到的文件。 另按 `tests/AGENTS.md`「功能边界或 bug 边界的测试不提交」，本轮写的三个回归测试只在本地跑、不进版本库，覆盖 `build_runner_environment` 的源码解析路径与 `PYTHONSAFEPATH`、HSR 日/周标记在服务器换日边界两侧的取值、以及项目指纹对运行期产物（含带标记的 `maafw/` 覆盖层）的排除：**共 11 个用例，本地全部通过**。 ## 没有收进来的 - Runtime 侧不接受用户配置的代理（`HTTPS_PROXY` 没有透传给子进程）——那在 AUTO-MAS-Runtime 仓，不能和这个 PR 一起提。 - 审计里另外几条需要设计决定的，例如 HSR 的差分宇宙与货币战争共用一个 `WeeklyCompletedThisWeek`（要加配置字段和迁移）、MFW 更新事务中断后没有恢复入口。 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
- 路径 B 下把队列里出现的战斗组从原生一条龙副本剔除，队列开关同时管住执行层与原生一条龙两侧 - 原生副本已无启用任务时跳过启动原生一条龙的阶段，避免 BetterGI 空跑不退出、任务一直结束不了 - 保存用户配置时按队列清理 Plan 中不再被引用的战斗实例 - res/version.json 的 BetterGI 条目收敛为一条
…gon-config # Conflicts: # app/api/scripts.py # app/models/schema.py # app/task/BetterGI/ScriptConfig.py # frontend/src/api/services/Service.ts # frontend/src/i18n/locales/en-US.ts # frontend/src/i18n/locales/ja-JP.ts # frontend/src/i18n/locales/zh-CN.ts # res/version.json
- 合并 upstream/dev 时冲突区被 dev 的 ZZZ-OD 端点占据，补回 /bettergi/one-dragon/settings、/bettergi/one-dragon/plan/step-enabled、/bettergi/global-domain/settings、/bettergi/global-stygian/settings、/bettergi/domain-catalog、/bettergi/script-group/save - 前端 src/api 由 openapi 生成器基于本地后端重新生成，未手改生成文件
- /user/update 恢复「队列为唯一真相源」逻辑：保存队列时同步清理 Plan 中不再被引用的战斗实例 - /bettergi/one-dragon/custom-groups 恢复 userId 参数，用户独立配置下按 per-user 副本读取自定义组 - 前端对齐重新生成后的接口：修正一条龙步骤启用接口名、补齐 OneDragon 的 Plan 与 UseExecutionLayer 默认值 - src/api 由 openapi 生成器重新生成
CHANGELOG.md 是唯一手写来源，res/version.json 等由它生成。此前该条目被直接手改进 version.json，导致 CI「检查 CHANGELOG.md 与生成物一致」失败。现把条目补回 CHANGELOG.md 的 v5.5.0-beta.3 新增分类，并运行 scripts/changelog.py sync 重新生成 version.json，使检查通过。
BetterGI 用户配置面板（一条龙队列可视化、配置组设置、秘境选择器、方案配置） 在 frontend 中新增了一批 edit.bettergi* 翻译键，但三个语言包（zh-CN / en-US / ja-JP）此前均未补，导致界面直接显示原始 key 字符串。 - 补全 93 个缺失的 bettergi* 键（覆盖 BetterGIUserEdit / BettergiGroupProjectBody / BettergiDragonGroupSettings 三处组件用到的全部 edit.* 键，已验证三语言包均 0 缺失） - 修正英文值中一处未转义的单引号（bettergiDuplicateTip），避免 TS 语法错误 验证方式：脚本扫描三个 BetterGI 组件的全部 edit.* 键，三语言包均 0 缺失， 三个语言包括号配平正常。
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
概述
本轮针对 BetterGI 一条龙执行层的实机排障（BGI 0.64.1-alpha.1），修复执行层排序、超时与日常任务连坐问题，并按 BGI 官方 d.ts / C# 源码修正幽境危战参数透传。
主要改动
执行层排序：支持同名多实例定向排序
planUid字段（持久化于OneDragon.Queue），与 Plan 步骤 uid 精确绑定build_combat_steps匹配优先级：planUid 精确 > 名称精确 > 同基名 FIFO执行层超时：空闲超时替代固定墙钟
on_log每收到日志即续期，日志静默 300s 才判定卡死，不设总时长上限执行层失败不再中止任务
失败判定修正
MAS_PLAN_FAIL/MAS_STEP_FAIL纳入失败标记：执行层 JS 抛异常后 BGI 仍会打印「配置组 … 执行结束」，仅靠该结束标记会把失败误判为成功幽境危战参数按 BGI 官方源码修正
AutoStygianOnslaughtParam无maxArtifactStar/combatStrategyPath属性（源码已核实），直接赋值会抛no suitable property or field并中断整个执行层maxArtifactStar透传（前端面板 / 后端白名单与映射 / 执行层脚本）setCombatStrategyPath()（副作用写入CombatScriptBagPath），改用无参构造保留 BGI 全局默认策略组开关保存失败可见化
toggleGroup/applyGroupsPatch保存失败时回滚本地状态并提示，消除「界面开着、后端没有」的静默脱节MCP 后台初始化恢复可用
fastapi_mcp的resolve_schema_references对互相$ref引用的模型无限展开（~1000 层 RecursionError），导致整个后台初始化失败（MainTimer / 通知管理器等全部跳过）$ref原样保留；同时移除启动脚本中的AUTO_MAS_ENABLE_MCP=0测试情况
实机（BGI 0.64.1-alpha.1 + 本分支）验证：
MAS_STEP_DONE（幽境危战、地脉花×2、秘境×3），无MAS_PLAN_FAILMAS_PROP_UNSUPPORTED守卫按预期跳过 BGI 未暴露的属性