feat(hsr): 体验整改——直控免导入、修复五个 bug、问题提前到界面 - #569
Merged
qiyinxi merged 11 commits intoSep 5, 2026
Merged
Conversation
口径依据：`.agents/skills/mas-script-specialized-adapter/SKILL.md` 把直控定义为
「直接使用脚本原有配置、由原生 GUI 维护、不回写 MAS 独立配置」，
`references/adapter-code-norms.md` 明确「直控不得为了字段齐全复制脚本全量配置」。
general / Okww / BetterGI 都照此实现，只有 HSR 从早期插件版原样迁来一条
「未导入快照则整个任务预检失败」的硬拦（ad2a4541，无正文、无注释论证），
且快照冻结在导入那一刻，用户之后在 SRA / 三月七助手里的改动 MAS 不跟进。
改法：
- native_control：`Direct.{engine}Config` 为空时走活配置——SRA 把
`--inline run` 直接指向 `resolve_sra_profile` 解析出的真实 profile，M7A 以真实
安装根目录启动 `main`；不建临时目录、不复制文件。有快照时隔离目录行为不变。
两条路日志文案分开，活配置写出实际文件路径。两个 provider 新增
`native_config_path()` 统一原生配置文件定位；`inspect()` 的 `import_ready`
保留原义（原生文件存在即可固定为快照），`direct_run_ready` 新增要求原生
配置文件存在（活配置模式下必须有它）。
- manager.check：删掉「尚未导入快照」硬拦；没有快照时改为校验活的原生配置
文件存在，缺失时给出「请先在脚本中保存一次设置，或为该用户导入配置快照」
的明确提示。脚本路径 / 可执行文件的三道既有检查保留。
- api：新增 `clear_direct_config` 与 `POST /api/scripts/hsr/direct-config/clear`，
与导入端点对称，复用既有 `HSRDirectConfigImportIn/Out` 模型，不改任何
schema 字段形状；只清空 `Direct` 三个字段，不碰外部文件，不需要路径锁。
- 前端 DirectControlSection：默认态改为「使用脚本当前配置（推荐）」的正常态
文案与成功色；导入按钮改为「固定当前配置为快照（可选）」；有快照时显示
固定时间与来源、提示不跟随后续改动，并提供「改回使用脚本当前配置」；
删掉「已启用的脚本必须先导入用户快照」警告。HSRUserEdit 补对称的清除处理，
三份词表同步增删。
- 文档：examples-hsr.md / script-frontend-architectures.md 改为新语义，不再给
「直控＝加密快照」背书。
- res/version.json 增加对应「程序优化」条目。
本地验证（tree venv、--basetemp）：pytest tests 474 passed 3 skipped；
--collect-only 退出码 0；前端 typecheck / lint / test 全绿。功能边界测试
tests/task/test_hsr_direct_live_config.py 按 tests/AGENTS.md 只留本地不提交。
真机拉起 SRA / 三月七助手的直控路径未在本次验证，只做了静态与单测。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
根因：`_on_sra_weekly_success` / `_on_m7a_weekly_success` 只在日志判定 未完成时记 `incomplete`，判定完成时只登记 Data 写回而不记 module result； 随后 `_run_queue_items` 成功分支的兜底对所有不在排除名单里的模块再记一次 `completed`，而 `HSRRuntimeState.record_module_result` 以后写入为准， 于是 `incomplete` 被覆盖成 `completed`。用户看到的是统计通知写「完成」、 用户页周常标签停在「未完成」、下次运行又重跑一遍。 改法照抄历战余响 `_queue_eow_completion_if_confirmed` 的范式，两步缺一不可： 1. 两个 on_success 的完成分支在 `queue_weekly_completion` 之前显式记 `completed`，reason 沿用 `detect_weekly_completion` 的返回值。 2. `_run_queue_items` 的兜底排除名单加入 `DivergentUniverse` / `CurrencyWars`：这几项的最终结果由 on_success 按日志判定并记满两条分支， 兜底再记一次会把「未完成」覆盖成「完成」。 不改 `detect_weekly_completion` 判定、重试策略、Data 写回时机与 `record_module_result` 的后写入为准语义。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
问题一：MAS 管控区顶部的「一键从源配置导入」实际行为是把用户在 MAS 里改过的 全部 Managed.Options 覆盖值清空后重新读原生配置，没有二次确认，成功提示还写成 「已导入」，与直控卡片上真正做导入的同名按钮相互混淆。现改名为「重置为源配置」， 补充副文案说明会清除哪些东西，加 a-popconfirm 二次确认，成功提示改为与真实行为 一致；三份词表同步替换旧 key。 问题二：resolve_sra_managed_options / resolve_managed_options 遇到 Managed.Options 里原生配置已不存在的键或类型不符的值时整体 raise ValueError，api.py 的兜底 except 把该引擎四个模块的表单一起丢掉，运行期 _apply_managed_options / _apply_managed_patch 再次抛错让任务直接失败；用户升级 SRA / 三月七助手或换 profile 后只要一个键对不上 就会撞到，且界面没有任何清理入口。现新增 managed_overlay.overlay_managed_options 统一两个引擎的叠加逻辑：对不上的键逐个丢弃、用原生值兜底，丢弃记录以 DroppedOverride 返回；表单发现侧把它编成 JSON 字串放进 HSRManagedModule.warnings （沿用现有 HSRManagedForm.warnings: list[str] 通道，不改响应模型），运行侧在 MAS 日志里 warning 说明忽略了哪些覆盖。前端 parseHSRDroppedOverrides 还原后在 模块列表打标、在详情面板列出键与原因，并提供带确认的「清除无效覆盖」，只从 Managed.Options 剔掉失效键后保存。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
体验审计里三个「用户被蒙在鼓里」的问题： 一、托管表单字段退化成裸控件 - managed_config.py：_SRA_LABELS 按真实 SRA Default.json（version 4）的键集合 补齐，连被过滤的 enabled/tasklist/redeemCodes 也给了名称；新增 _SRA_DESCRIPTIONS， 货币战争刷开局四个重开条件、策略文件/序号、培养目标、补充次数等按 SRA 源码 （CosmicStrifeTask / RerollStart / TrailblazePowerTask）写清分隔符与前缀含义， 拿不准的指回 SRA 内同名设置；新增 _SRA_RANGES 给次数、序号、活动关卡序号 非负下界，不设没有依据的上界。 - 按 SRA 源码修正下拉：replenish.way 0/1/2 = 后备开拓力/燃料/星琼（原表 0 燃料 1 星琼与源码不符），currencyWars.mode 增加 2 = 刷开局。 - M7A：config.example.yaml 缺失时把原因写进模块级 warnings，前端在表单上方展示； borrow_scroll_times / power_limit 补非负下界。 二、切引擎换掉整套配置却一声不吭 - ManagedTaskSection.vue：引擎切换控件下加说明（配置项按引擎分别保存、不带过去 但保留）；展示表单级 warnings。 - StageConfigSection.vue：新格式下当前引擎名下没有主关卡、而另一引擎名下有副本 时提示重新选择（旧格式的不匹配仍由 nativeEngineMismatch 负责）。 - manager.check()：新增 _precheck_daily_stages，口径与 AutoProxy _resolve_daily_runnable_parts 完全一致：培养目标/活动双倍已开则不拦；只有该引擎下 主关卡和历战余响关卡都没有（体力模块无论哪天都会整个跳过）才返回错误； 「今日不需历战余响」「历战余响到期但未配关卡」两类只写运行日志不阻断。 判定拆成 stage_runtime.resolve_configured_daily_stages 与 AutoProxy.resolve_daily_native_modes 两个纯函数，AutoProxy 与 check() 共用。 三、引擎第四级回落静默发生 - task_mapping.py：新增 resolve_script_assignment 返回 HSRScriptAssignment （requested / script / fallback），describe_script_fallback 生成提示语； get_assigned_script 变成兼容包装，签名与返回不变。 - check() 与 AutoProxy._build_phase_items 把回落写进运行日志； api.build_capabilities（脚本级）与 build_managed_config（用户级）把回落写进 warnings，编辑页顶部与托管区都能看到。 其他：既有公共测试 test_hsr_engine_fallback / test_hsr_account_switch_gate 的 用户夹具补上按引擎分桶的主关卡，让新增预检放行；三份词表新增 edit.hsrEngineSwitchHint / edit.hsrStageMissingForEngine；res/version.json 补两条。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
上一提交把「所指派引擎下既没有体力主关卡也没有历战余响关卡」做成了 check() 的硬拦。但 `TaskSwitch.Daily` 后端默认为 True（app/models/config.py），新建 用户在配好副本之前天然处于这个状态，于是「给第二个号建了用户还没配完」会让 同一脚本下已经配好的其他用户一起跑不了——这正是本轮要消除的那类体验问题。 改为只在任务开始前写一条说明日志。「提前知道」这件事由编辑页那条 「当前引擎下未选择副本」的提示承担，开跑前再复述一次即可，不必把影响面 扩大到整个任务。原先为通过该硬拦而给两份既有公共测试补的关卡夹具一并还原。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
SRA 配置档案可选 - HSRConfig 新增 Info.SRAProfile（空串＝自动），SRAProfileValidator 只放行能直接 拼成文件名的档案 id。 - resolve_sra_profile 尊重该配置：档案存在则用它；配了但不存在回退到原有的 Default → 文件名排序首个逻辑；签名与 (id, path) 返回形状不变。新增 resolve_sra_profile_selection 返回带 fallback / fallback_reason 的完整结果， 能力快照与托管配置的 warnings、运行前检查日志、档案列表端点都据此把回退 说给用户。 - 新增 GET /api/scripts/hsr/sra-profiles 列出 %APPDATA%/SRA/configs 下的档案， 标出配置值、自动模式会选的档案、实际生效档案与是否回退。 - 脚本编辑页 SRA 路径下方新增「SRA 配置档案」下拉，未配 SRA 路径 / 目录不可读 时禁用并说明原因，配置的档案已不存在时显示回退提示。 失效覆盖记录结构化 - HSRManagedForm 新增 dropped_overrides（key / reason / value / message）， warnings 恢复为纯人类可读提示；HSRManagedModule.asdict() 同步输出， DroppedOverride.as_warning() 的 JSON 字串编码移除。 - 前端删掉 parseHSRDroppedOverrides，改为读类型化字段的 getHSRDroppedOverrides， ManagedTaskSection 展示与「清除无效覆盖」行为不变。 OpenAPI 客户端按本分支后端重新生成（frontend/src/api）：新增 HSRManagedDroppedOverride / HSRSRAProfile / HSRSRAProfilesData / HSRSRAProfilesOut 四个模型，HSRConfig_Info、HSRManagedForm、index.ts、HsrService.ts（含本分支此前 未生成的 direct-config/clear）、Service.ts 跟随变化；其余仅换行差异的生成文件 已还原。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`yarn format` 会把 dev 基线上未格式化的 BetterGI 词条一并换行重排。按仓库 规矩，无关格式化改动不得混入修复，这里把三份词表中 61 条「值未变、只是排版 被改」的条目还原成基线写法，只保留本次真正新增或改写的 key。
`HSRAutoProxyTask._append_log` 与 `HSRManager._append_log` 都用 `datetime.now(tz=UTC8)` 打时间戳。全仓只有 HSR 这么做——MaaFW 用 `datetime.now().astimezone()`，通知用 `datetime.now()`——所以非中国时区的 用户看到的 HSR 日志每一行都和自己的墙上时钟对不上（UTC+2 用户差 6 小时）。 改为跟随本机时区。周常重置日、历战余响开始日那几处 `datetime.now(tz=UTC8)` 是游戏服务器日期语义，保持不变；`manager.py` 因此不再需要 UTC8，同步收掉 未使用的导入。历史日志文件名用的 UTC+4 是全仓「游戏日」分桶约定 （MAA / M9A / BetterGI / general / MaaEnd 一致），本次不动。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
真实日志：M7A 体力模块全部成功，MAS 却把它和紧随其后的「日常与奖励」都记成失败。 三个独立缺陷叠在一起： 1. M7A 的 after_finish 没被托管。M7A stop() 在释放 OCR 后，只要 after_finish 不是 字符串 "None" 就走 shutdown()，而 shutdown() 第一步无条件 stop_game()。MAS 给 SRA 写临时配置时把 missionAccomplished 五个收尾动作全关，M7A 这边的强制 patch 只关了 notify_*，after_finish 全仓没写过；用户设成 Shutdown 且未开游戏管理时 还会连整机一起关。现在新增 M7A_FINISH_ACTION_DISABLE_PATCH 把 after_finish 钉成 "None"（字面值取自 assets/config/config.example.yaml），并入 write_m7a_patch 的 patch 与白名单并集，覆盖 Daily / ReceiveRewards / DivergentUniverse / CurrencyWars 全部托管路径；脚本直控（M7ADirectControlSession）不经过该函数，保持原样跑用户配置。 2. 守护循环 TOCTOU。_run_item_with_game_guard 在 sleep(1) 醒来后没有复查 run_task.done() 就去看游戏进程；M7A 收尾顺序是先关游戏再自己退出，这个窗口必然 被踩中，一个已经成功完成的任务被 cancel() 并判失败。现在睡醒后先复查 done()， 已完成直接跳出走正常返回。 3. 游戏已退出仍继续启动下一模块。_run_queue_items 的 HSRRetryableTaskError 分支只 对 StartGame 中止剩余模块，其余一律 continue，于是又去跑「日常与奖励」再失败一次。 新增 HSRGameExitedError（继承 HSRRetryableTaskError，补跑语义不变）由守护循环抛出， 队列按类型识别并中止该用户当前阶段剩余模块；_remaining_items_after 的未执行原因 参数化，游戏退出写「游戏进程已退出，当前阶段剩余模块未执行」，不再沿用 「SRA 登录/切号失败」。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
「失效覆盖记录改为结构化字段」是内部实现，用户感知不到；对应的用户可见 现象已由「单个失效覆盖项不再让整个引擎表单消失、可一键清理」那条覆盖。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
审查者指南此 PR 全面修订了 HSR 配置和执行行为：直接控制现在默认使用实时原生脚本设置，并支持可选快照和可选择的 SRA 配置档案；过时的托管覆盖值会安全降级，并在 UI 中进行清理；执行生命周期和结果处理得到修正；引擎回退、缺失阶段和配置问题会在运行前或运行期间报告。 HSR 直接控制使用实时配置或快照的时序图sequenceDiagram
participant User
participant MAS as HSRManager
participant Provider as NativeControlProvider
participant Script as SRA_or_M7A
participant API as HSR_API
User->>MAS: Enable direct control
MAS->>Provider: has_user_direct_snapshot()
alt Snapshot exists
MAS->>Provider: open_direct_session(snapshot)
Provider->>Provider: Create isolated runtime config
Provider->>Script: Run pinned snapshot
else No snapshot
MAS->>Provider: open_direct_session(empty_config)
Provider->>Provider: Resolve native_config_path()
Provider->>Script: Run current native configuration
end
Script-->>MAS: Runtime result
MAS-->>User: Log execution source and result
opt User changes source
User->>API: clear_direct_config()
API->>MAS: Remove Direct engine snapshot metadata
MAS-->>User: Direct control uses live configuration
end
HSR 受保护的模块执行和游戏退出处理时序图sequenceDiagram
participant MAS as HSRAutoProxyTask
participant Script as ExternalScript
participant Game
participant Queue as ModuleQueue
participant Result as ResultRecorder
MAS->>Script: run_task()
loop Guarded execution
MAS->>MAS: run_task.done()
alt Script completed
MAS->>Script: Await result
else Game process exited
MAS->>Game: is_process_running()
MAS->>Script: Cancel running task
MAS->>Queue: Mark remaining items skipped
Queue-->>MAS: HSRGameExitedError
end
end
alt Game exit error
MAS->>Result: record skipped remaining modules
MAS-->>Queue: Stop current phase
else Successful result
MAS->>Result: record_module_result()
end
HSR 托管配置覆盖和过时覆盖清理流程图flowchart TD
A[Load native SRA or M7A configuration] --> B[Read Managed.Options overrides]
B --> C{Each override matches native field and type?}
C -->|Yes| D[Apply override]
C -->|No| E[Create DroppedOverride record]
E --> F[Use native value]
D --> G[Build managed form]
F --> G
G --> H[Show stale override warning in UI]
H --> I{User chooses cleanup?}
I -->|No| J[Ignore stale override at runtime]
I -->|Yes| K[Clear selected Managed.Options keys]
K --> L[Reload managed configuration]
文件级变更
提示和命令与 Sourcery 交互
自定义你的使用体验访问你的控制面板以：
获取帮助Original review guide in EnglishReviewer's GuideThis PR comprehensively revises HSR configuration and execution behavior: direct control now defaults to live native script settings with optional snapshots and selectable SRA profiles, stale managed overrides degrade safely with UI cleanup, execution lifecycle/result handling is corrected, and engine fallbacks, missing stages, and configuration issues are reported before or during runs. Sequence diagram for HSR direct control with live configuration or snapshotsequenceDiagram
participant User
participant MAS as HSRManager
participant Provider as NativeControlProvider
participant Script as SRA_or_M7A
participant API as HSR_API
User->>MAS: Enable direct control
MAS->>Provider: has_user_direct_snapshot()
alt Snapshot exists
MAS->>Provider: open_direct_session(snapshot)
Provider->>Provider: Create isolated runtime config
Provider->>Script: Run pinned snapshot
else No snapshot
MAS->>Provider: open_direct_session(empty_config)
Provider->>Provider: Resolve native_config_path()
Provider->>Script: Run current native configuration
end
Script-->>MAS: Runtime result
MAS-->>User: Log execution source and result
opt User changes source
User->>API: clear_direct_config()
API->>MAS: Remove Direct engine snapshot metadata
MAS-->>User: Direct control uses live configuration
end
Sequence diagram for HSR guarded module execution and game exit handlingsequenceDiagram
participant MAS as HSRAutoProxyTask
participant Script as ExternalScript
participant Game
participant Queue as ModuleQueue
participant Result as ResultRecorder
MAS->>Script: run_task()
loop Guarded execution
MAS->>MAS: run_task.done()
alt Script completed
MAS->>Script: Await result
else Game process exited
MAS->>Game: is_process_running()
MAS->>Script: Cancel running task
MAS->>Queue: Mark remaining items skipped
Queue-->>MAS: HSRGameExitedError
end
end
alt Game exit error
MAS->>Result: record skipped remaining modules
MAS-->>Queue: Stop current phase
else Successful result
MAS->>Result: record_module_result()
end
Flow diagram for HSR managed configuration overlay and stale override cleanupflowchart TD
A[Load native SRA or M7A configuration] --> B[Read Managed.Options overrides]
B --> C{Each override matches native field and type?}
C -->|Yes| D[Apply override]
C -->|No| E[Create DroppedOverride record]
E --> F[Use native value]
D --> G[Build managed form]
F --> G
G --> H[Show stale override warning in UI]
H --> I{User chooses cleanup?}
I -->|No| J[Ignore stale override at runtime]
I -->|Yes| K[Clear selected Managed.Options keys]
K --> L[Reload managed configuration]
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
**历战余响被标成差分宇宙（英文）**：`edit.divergentUniverse` 这个 key 实际 承载的是「历战余响」，中文是「历战余响」、日文是「歴戦余韻」，只有英文照着 key 名翻成了 "Divergent Universe"。而差分宇宙在同一个用户页上真实存在，英文 用户会看到两个 "Divergent Universe" 却指两件事。同源的 `divergentUniverseStartDay`、`pickDivergentUniverseStage` 与 `startDayIfIt` 的英文正文有同样的错译，一并改正；三个 key 顺带改名为 `echoOfWar` / `echoOfWarStartDay` / `pickEchoOfWarStage`，让下一个翻译的人不会再被带偏。 引用点除 HSR 外还有 SRC 的体力配置区（同样是历战余响，`name="EchoOfWar"`）， 一并更新——SRC 的英文界面此前有同一处错标。SRC 自己的 `pickDivergentUniverseStage2/3` 是另外两个 key，未改动。 **体力配置沿用了明日方舟的译法**：`sanityConfiguration` 英文是 "Sanity configuration"、日文是「理性の設定」，"Sanity"／「理性」都是明日方舟 的理智；星穹铁道对应的是开拓力，改为 "Trailblaze Power" 与「開拓力の設定」。 **侵蚀隧洞英文名复数有误**："Caverns of Corrosion" → "Cavern of Corrosion"， 与游戏内官方名称一致。 这两个 key 都只有 HSR 在用（已 grep 确认），不影响其它专项。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
qiyinxi
added a commit
that referenced
this pull request
Sep 5, 2026
补一个在上一个 PR 合并时掉队的提交。 [#569](#569) 合并时，GitHub 的 PR 对象没有跟上分支的最后一次推送（head 停在倒数第二个提交，`updated_at` 也没动），所以这一条没有进 dev。分支本身当时是完整的，掉的是整个提交，没有掉一半——dev 上组件仍是硬编码中文、也没有引用不存在的 key，所以合并后的状态是自洽的，只是这项改进缺了。 ## 内容 HSR 用户页有一批面向用户的文案从未进过词表，英文和日文用户直接看到中文：页面标题、「用户名」与「剩余天数」两个标签、历战余响与周常的「本周已完成 / 未完成」和「最近完成」、服务器的「官服」、刷取副本下拉的四个副本名、以及 MAS 管控任务列表里的「动态 N 项」「读取自」「周常 / 日常」「三月七」「未读取到原生配置」「已启用 · N 项配置」等。 这几个组件是在上一轮英文化（#487）之后才重做的，所以漏在了外面。仓库的前端 Skill 把「面向用户的文案走词表」列为红线。 新增 17 个 key，三份词表顺序一致；能复用的既有 key 都复用了（`edit.username`、`edit.daysLeft`、`edit.weekly`、`edit.calyxGolden` 等）。英文与日文用游戏官方术语。 ## 刻意没动的中文 按仓库既定口径，**被程序拿去做判断的中文一律不翻**：`StageConfigSection` 里 `categoryKeysByChannel`、`isEowCategory`、`stageTagColor` 拿去和后端返回的 `categoryKey` 比对的那几处，以及 `useHSRPluginApi` 里比对后端 warning 前缀的字串，全部保持原样。日志与报错提示同样按既定口径跳过。下拉选项只翻 `label`，`value` 一个没动。 ## 本地验证 ``` 前端 yarn typecheck / lint 退出码 0 yarn test 40 files / 385 tests passed（含词表 key 一致性与转义校验） 后端 pytest tests 499 passed, 3 skipped pytest --collect-only 502 collected，退出码 0 ``` 🤖 Generated with [Claude Code](https://claude.com/claude-code) ## Sourcery 摘要 为支持的语言本地化 HSR 用户页面中剩余的面向用户的文本。 错误修复： - 将 HSR 用户页面中剩余的硬编码中文文本替换为本地化翻译，以便英语和日语用户能够看到经过翻译的界面内容。 功能增强： - 在适用的情况下复用现有翻译键，并在中文、英语和日语语言文件中添加缺失的 HSR 专用标签、状态、摘要和阶段选择消息。 - 保持面向后端的值和诊断文本不变，仅本地化用户可见的标签和消息。 <details> <summary>Original summary in English</summary> ## Summary by Sourcery Localize the remaining user-facing HSR user-page text across supported languages. Bug Fixes: - Replace remaining hard-coded Chinese text in the HSR user pages with localized translations so English and Japanese users see translated UI content. Enhancements: - Reuse existing translation keys where applicable and add the missing HSR-specific labels, statuses, summaries, and stage-selection messages across Chinese, English, and Japanese locale files. - Keep backend-facing values and diagnostic text unchanged while localizing only user-visible labels and messages. </details> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
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
1 participant
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.
HSR 专项一轮体验整改，修掉 5 个 bug、对齐 1 处违反仓库口径的实现、把 4 类「跑完才知道」的问题提前到界面上。
起因是用户反馈 HSR「很不人性化」，外加一份真实运行日志：那次外部脚本其实全部成功，MAS 却把两个模块都记成了失败。
修的 bug
三月七助手跑完自己把游戏关了，本已成功的模块被判失败、下一个模块再空跑一次。
M7A
tasks/game/__init__.py:250只要after_finish不是"None"就调shutdown()，而module/game/base.py:112的shutdown()第一行是无条件stop_game()（after_finish="Exit"也照杀）。MAS 给 SRA 的临时配置里早就把missionAccomplished五个收尾动作全关了，M7A 这边只关了通知、after_finish全仓没人写过。设成「关机」时 M7A 还会在 60 秒后真的关机。现强制钉成"None"；同时守护循环补run_task.done()复查（原来sleep(1)醒来直接查进程，必然踩中「先关游戏再退出」的窗口），并让「游戏已退出」中止该用户剩余模块而不是接着空跑。差分宇宙 / 货币战争在日志未确认完成时仍被记成「完成」。
两个
on_success只在未完成时记incomplete，随后AutoProxy的兜底又无条件补一条completed，而record_module_result是后写入为准。结果：通知里写「完成」，用户页周常标签停在「未完成」，下次运行重复跑。改法照抄历战余响那套已经正确的范式。体力「补充方式」的选项与 SRA 实际含义错位一格。
SRA
TrailblazePowerTask.replenish()实际是 0=后备开拓力 / 1=燃料 / 2=星琼，MAS 写成 0=燃料 / 1=星琼——选「燃料」实际用的是后备开拓力，而星琼根本选不到。顺带补上缺失的货币战争「刷开局」模式（cw_mode==2）。外部脚本升级后，单个失效的配置项会让该引擎全部任务表单一起消失、运行时任务直接失败。
Managed.Options里只要有一个键在原生配置中不存在或类型不符就整体抛错，api.py的兜底把该引擎四个模块的表单一起丢掉，UI 上还没有清理入口。改为逐项忽略并在界面上列出、可一键清除。英文与日文界面的三处术语错误。
edit.divergentUniverse这个 key 承载的其实是「历战余响」，中文日文都对，只有英文照 key 名翻成了 Divergent Universe——而差分宇宙在同一个页面上真实存在，英文用户会看到两个同名却不同的东西（SRC 专项也有同一处错标）。另外「体力配置」的英文与日文沿用了明日方舟的 Sanity／理性，星铁该是开拓力；「侵蚀隧洞」英文名复数有误。调度台日志每行的时间戳硬编码东八区。
全仓只有 HSR 这么干（MaaFW 用
datetime.now().astimezone()），非中国时区用户看到的每一行都和本机时钟对不上。周常重置日等游戏内日期判定仍按游戏服务器时区，历史日志文件名的 UTC+4 是全仓「游戏日」分桶约定，都不变。对齐仓库口径
脚本直控不再要求先导入配置快照。
SKILL.md:91定义直控＝直接使用脚本原有配置、由原生 GUI 维护，adapter-code-norms.md:64明写「直控不得为了字段齐全复制脚本全量配置」。general / Okww / BetterGI 都照此实现，只有 HSR 要求先导入整份快照才肯跑，且快照冻结在导入那一刻、之后脚本里的改动不跟进、UI 上也没有过期提示。技术上并不需要：SRA 的--inline run本来就接任意 config 路径，M7A 直接以安装根目录启动即可。现在直控零配置可跑；「固定为快照」降级成可选覆盖，只服务同一脚本挂多个游戏账号、各跑一套配置的场景，并可一键改回使用脚本当前配置。
examples-hsr.md/script-frontend-architectures.md里给旧语义背书的描述一并改掉。提前到界面上
新增
SRA 配置档案可选。 SRA 把设置存成
%APPDATA%\SRA\configs下的多份档案，MAS 原先写死取Default.json（没有则取文件名排序第一份），用户无法选。这份档案决定托管表单显示什么、直控按哪份运行、固定快照抄哪份。选中的档案被删或改名时退回自动模式并在脚本页、用户页、端点响应与运行日志四处提示，不闷声换掉。本地验证
功能边界与 bug 边界测试按
tests/AGENTS.md只在本地跑、不提交，共 4 个文件（直控活配置 20 例、失效覆盖丢弃 9 例、SRA 档案选择 8 例、M7A 收尾与守护循环 13 例，另有周常覆盖 9 例与预检 12 例）。周常那条做过反向验证：把补丁 revert 掉重跑，4 条用例变红。frontend/src/api是真跑生成器重新生成的，只有 9 个文件因本次 schema 改动而变。其中Service.ts带了 3 行 BackendHealth 注释更新，是 dev 基线上生成物本身陈旧所致，不手改生成文件就无法拆掉。没验证的部分与已知边界
没有真机跑过 SRA / 三月七助手与游戏，直控的活配置与快照两条路、脚本页新下拉的实际渲染、以及用户日志里那段时序，都只有静态检查与单测覆盖。
三月七助手支持用环境变量
MARCH7TH_AFTER_FINISH覆盖 config.yaml（module/config/config.py:17）。用户如果在系统环境里设了它，本次钉死的"None"不生效。概率极小，没有处理。「游戏进程已退出」会中止该用户当前阶段的剩余模块；但如果外部脚本在游戏被关后自己先以失败退出，仍会继续启动下一个模块——这是基线既有行为，本次没有覆盖。
🤖 Generated with Claude Code