Repository navigation
feat(equipment): 新增meta演习装备配置 - #1304
Merged
Merged
Conversation
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to
|
| Check name | Status | Explanation | Resolution |
|---|---|---|---|
| Docstring Coverage |  |
Docstring coverage is 37.08% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 89 functions across 11 files. (13 skipped… | Write docstrings for the functions missing them to satisfy the coverage threshold. |
-
Check name Status Explanation Description Check Check skipped - CodeRabbit’s high-level summary is enabled. Title check 标题准确概括了本次变更的主要内容：为演习和 META 作战新增装备配置。标题简洁、具体，并与变更范围一致。 Linked Issues check Check skipped because no linked issues were found for this pull request. Out of Scope Changes check Check skipped because no linked issues were found for this pull request.
Full details: Docstring Coverage
-
Explanation
Docstring coverage is 37.08% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 89 functions across 11 files. (13 skipped: 13 unsupported.)
Resolution
Write docstrings for the functions missing them to satisfy the coverage threshold.
✨ Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Comment @coderabbitai help to get the list of available commands.
CI 检查报告
检查结果
导入冒烟测试
|
审阅者指南本 PR 将装备码方案处理整合进通用 Combat 流程，为演习和 META 信标/协助任务增加按舰队站位的战前换装与可靠战后恢复，并通过配置生成、识别资源、文档及离线回归测试完整支持该功能。 战前装备应用与恢复时序图sequenceDiagram
participant Combat
participant EquipmentConfigHandler
participant FleetPage
participant EquipmentCode
participant Battle
Combat->>EquipmentConfigHandler: handle_battle_preparation()
EquipmentConfigHandler->>EquipmentConfigHandler: equipment_config
EquipmentConfigHandler->>FleetPage: ensure_reorganize()
FleetPage-->>EquipmentConfigHandler: FLEET_SAVE visible
EquipmentConfigHandler->>EquipmentCode: _equipment_config_clear()
EquipmentConfigHandler->>EquipmentCode: _equipment_config_apply(code)
EquipmentConfigHandler->>FleetPage: ensure_save()
EquipmentConfigHandler-->>Combat: equipment_handle_before_flag = true
Combat->>Battle: click BATTLE_PREPARATION
Note over Combat,Battle: After combat, the task re-enters preparation
Combat->>EquipmentConfigHandler: equipment_handle_after()
EquipmentConfigHandler->>FleetPage: ensure_reorganize()
EquipmentConfigHandler->>EquipmentCode: _equipment_config_clear()
EquipmentConfigHandler->>EquipmentCode: _equipment_config_apply(after)
EquipmentConfigHandler->>FleetPage: ensure_save()
EquipmentConfigHandler-->>Combat: equipment_handle_before_flag = false
META 在不同入口页面间恢复装备的时序图sequenceDiagram
participant Meta
participant AshCombat
participant MetaPage
participant BattlePreparation
participant EquipmentConfigHandler
Meta->>AshCombat: combat()
AshCombat-->>Meta: equipment_handle_before_flag = true
Meta->>Meta: handle_ash_equipment_after()
alt dossier page is active
Meta->>MetaPage: click ASH_QUIT
else beacon page shows simulation entry
Meta->>MetaPage: click ASH_SIMULATE
Meta->>MetaPage: handle_popup_confirm()
else assist entry is available
Meta->>MetaPage: click BEACON_MY
end
MetaPage-->>Meta: BATTLE_PREPARATION visible
Meta->>EquipmentConfigHandler: equipment_handle_after()
EquipmentConfigHandler-->>Meta: restoration completed
Meta->>MetaPage: return to beacon or assist page
装备任务配置实体关系图erDiagram
TASK ||--o| EQUIPMENT_CONFIG : enables
EQUIPMENT_CONFIG ||--o{ FLEET_POSITION : defines
FLEET_POSITION ||--o| EQUIPMENT_PRESET : before
FLEET_POSITION ||--o| EQUIPMENT_PRESET : after
TASK {
boolean Equipment_Enable
boolean Equipment_ClearBeforeApply
}
EQUIPMENT_CONFIG {
yaml Config
}
FLEET_POSITION {
string position
}
EQUIPMENT_PRESET {
string equipment_code
}
文件变更
提示与命令与 Sourcery 互动
自定义你的体验访问你的控制面板以：
获取帮助Original review guide in EnglishReviewer's Guide本 PR 将装备码方案处理整合进通用 Combat 流程，为演习和 META 信标/协助任务增加按舰队站位的战前换装与可靠战后恢复，并通过配置生成、识别资源、文档及离线回归测试完整支持该功能。 Sequence diagram for pre-battle equipment application and restorationsequenceDiagram
participant Combat
participant EquipmentConfigHandler
participant FleetPage
participant EquipmentCode
participant Battle
Combat->>EquipmentConfigHandler: handle_battle_preparation()
EquipmentConfigHandler->>EquipmentConfigHandler: equipment_config
EquipmentConfigHandler->>FleetPage: ensure_reorganize()
FleetPage-->>EquipmentConfigHandler: FLEET_SAVE visible
EquipmentConfigHandler->>EquipmentCode: _equipment_config_clear()
EquipmentConfigHandler->>EquipmentCode: _equipment_config_apply(code)
EquipmentConfigHandler->>FleetPage: ensure_save()
EquipmentConfigHandler-->>Combat: equipment_handle_before_flag = true
Combat->>Battle: click BATTLE_PREPARATION
Note over Combat,Battle: After combat, the task re-enters preparation
Combat->>EquipmentConfigHandler: equipment_handle_after()
EquipmentConfigHandler->>FleetPage: ensure_reorganize()
EquipmentConfigHandler->>EquipmentCode: _equipment_config_clear()
EquipmentConfigHandler->>EquipmentCode: _equipment_config_apply(after)
EquipmentConfigHandler->>FleetPage: ensure_save()
EquipmentConfigHandler-->>Combat: equipment_handle_before_flag = false
Sequence diagram for META equipment restoration across entry pagessequenceDiagram
participant Meta
participant AshCombat
participant MetaPage
participant BattlePreparation
participant EquipmentConfigHandler
Meta->>AshCombat: combat()
AshCombat-->>Meta: equipment_handle_before_flag = true
Meta->>Meta: handle_ash_equipment_after()
alt dossier page is active
Meta->>MetaPage: click ASH_QUIT
else beacon page shows simulation entry
Meta->>MetaPage: click ASH_SIMULATE
Meta->>MetaPage: handle_popup_confirm()
else assist entry is available
Meta->>MetaPage: click BEACON_MY
end
MetaPage-->>Meta: BATTLE_PREPARATION visible
Meta->>EquipmentConfigHandler: equipment_handle_after()
EquipmentConfigHandler-->>Meta: restoration completed
Meta->>MetaPage: return to beacon or assist page
Entity relationship diagram for equipment task configurationerDiagram
TASK ||--o| EQUIPMENT_CONFIG : enables
EQUIPMENT_CONFIG ||--o{ FLEET_POSITION : defines
FLEET_POSITION ||--o| EQUIPMENT_PRESET : before
FLEET_POSITION ||--o| EQUIPMENT_PRESET : after
TASK {
boolean Equipment_Enable
boolean Equipment_ClearBeforeApply
}
EQUIPMENT_CONFIG {
yaml Config
}
FLEET_POSITION {
string position
}
EQUIPMENT_PRESET {
string equipment_code
}
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
longer-sausage
marked this pull request as ready for review
October 22, 2026 14:51
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
嘿——我发现了 7 个问题
给 AI 智能体的提示
请处理此代码审查中的评论：
## 单条评论
### 评论 1
<location path="module/equipment/equipment_config.py" line_range="139-140" />
<code_context>
+ logger.hr('战前装备配置', level=2)
+ self.ensure_reorganize()
+
+ if self.config.Equipment_ClearBeforeApply:
+ if not self.equipment_clear():
+ raise RequestHumanTakeover('清空装备失败')
+
</code_context>
<issue_to_address>
**舰队装备仍处于部分变更状态**
如果清空、应用或保存操作在之前已有位置发生变更后失败，`equipment_handle_before()` 会在设置 `_equipment_handle_before_flag` 之前抛出异常，因此恢复流程会跳过后续方案，舰队最终处于已清空或只装备了一部分的状态。
请在首次修改舰队之前设置待恢复标志，并且只有在恢复成功后才清除该标志。
另请检查 `module/equipment/equipment_config.py:143-153`。
</issue_to_address>
### 评论 2
<location path="module/os_ash/meta.py" line_range="825" />
<code_context>
if self._meta_category == 'beacon':
self._reset_assist_request_state()
+ if self.ash_combat.equipment_handle_before_flag and not self._check_beacon_point():
+ self.handle_ash_equipment_after()
if not self._meta_category in self._meta_receive:
self._meta_receive.append(self._meta_category)
</code_context>
<issue_to_address>
**META 恢复流程被放弃**
当装备恢复流程找不到可用的准备方案条目，或在超时前无法进入准备页面时，`handle_ash_equipment_after()` 会返回 `False`，但 META 调用方仍会继续完成任务、停止、切换或安排后续任务；下一个任务会因被丢弃的 `ash_combat` 实例而丢失待恢复标志，导致舰队仍处于临时配置。
当 `handle_ash_equipment_after()` 返回 `False` 时，请确保每个调用方都会停止，或以其他方式保留可重试的恢复状态。
另请检查 `module/os_ash/meta.py:342`、`module/os_ash/meta.py:350`、`module/os_ash/meta.py:443`、`module/os_ash/meta.py:454`、`module/os_ash/meta.py:999`。
</issue_to_address>
### 评论 3
<location path="module/exercise/exercise.py" line_range="346-348" />
<code_context>
break
- # self.equipment_take_off_when_finished()
+ if self.equipment_config_enabled and self.equipment_handle_before_flag:
+ self._choose_opponent(0)
+ self.equipment_handle_after()
+ self.ui_back(EXERCISE_CHECK)
</code_context>
<issue_to_address>
**练习被中断时会跳过恢复**
如果在应用战前配置后练习循环被中断，`_exercise_once()` 中发生异常或收到任务停止信号，会导致 `run()` 在到达装备清理代码块之前退出。练习中的舰队会继续使用战前配置，而下一个任务实例没有持久化的待恢复标志来触发恢复。
请通过 `finally` 或中断处理程序执行恢复流程，同时保留原始停止信号。
</issue_to_address>
### 评论 4
<location path="module/os_ash/meta.py" line_range="182-186" />
<code_context>
+ else:
+ self.device.screenshot()
+
+ if self.appear(BATTLE_PREPARATION, offset=(30, 30)):
+ if self.ash_combat.is_dossier:
+ if self.appear(BATTLE_PREPARATION, offset=(30, 30), interval=2):
+ self.device.click(BACK_ARROW)
+ continue
+ break
+ if timeout.reached():
</code_context>
<issue_to_address>
**档案恢复流程会卡住**
如果恢复流程从档案战斗准备页面开始，而点击返回后仍未离开该页面，档案分支会在检查 `timeout` 之前执行 `continue`，因此 `handle_ash_equipment_after()` 永远不会返回超时结果，META 恢复流程会无限循环。
请在档案分支继续执行之前检查超时。
</issue_to_address>
### 评论 5
<location path="tests/test_meta_beacon.py" line_range="15" />
<code_context>
+import module.config.server as server
+
+server.server = 'cn'
+
+from module.base.base import ModuleBase
</code_context>
<issue_to_address>
**测试会泄漏 CN 服务器设置**
当测试套件同时导入此模块和依赖其他服务器设置的测试时，该模块会在导入时修改共享的 `module.config.server.server` 值，却从不恢复它。因此，之后导入的测试会使用 CN 特定的服务器行为，并可能因测试顺序而通过或失败。
请在需要 CN 行为的测试中设置并恢复服务器值，或使用 teardown 恢复其原有值。
</issue_to_address>
### 评论 6
<location path="tests/test_equipment_config.py" line_range="214-218" />
<code_context>
+
+ def test_preparation_gets_new_frame_after_equipping_then_starts_once(self):
+ handler = make_handler(clear=False, cls=Combat)
+ handler.appear = Mock(return_value=True)
+ self.assertTrue(handler.handle_battle_preparation())
+ handler.device.click.assert_not_called()
+ self.assertTrue(handler.handle_battle_preparation())
+ handler.device.click.assert_called_once_with(BATTLE_PREPARATION)
+ handler._code_apply.assert_called_once_with(code=BEFORE_CODE)
+
</code_context>
<issue_to_address>
**没有验证是否获取了新截图**
如果准备循环在应用装备后不再刷新截图，那么在 `test_preparation_gets_new_frame_after_equipping_then_starts_once` 中，`appear` 始终返回 `True`，且测试直接调用了两次 `handle_battle_preparation()`。即使准备循环在装备完成后、下次检查前不再获取新截图，这两个断言仍会通过。
请使用依赖帧内容的外观检测结果来运行准备循环，并断言在下次准备检查之前已经截取了新图。
</issue_to_address>
### 评论 7
<location path="tests/test_equipment_config.py" line_range="57-61" />
<code_context>
+ handler.config.EquipmentCode_Config = yaml.safe_dump({'source': None, 'target': None})
+ handler._code_export = Mock(return_value=BEFORE_CODE)
+ self.assertTrue(handler.code_clear(name='source'))
+ self.assertEqual(yaml.safe_load(handler.config.EquipmentCode_Config)['source'], BEFORE_CODE)
+ self.assertEqual(handler.last_code, BEFORE_CODE)
+ self.assertTrue(handler.code_apply(name='target'))
+ handler._code_apply.assert_called_with(code=BEFORE_CODE)
+ self.assertIsNone(handler.last_code)
+
+ def test_invalid_codes_are_rejected_before_navigation_or_clearing(self):
</code_context>
<issue_to_address>
**没有断言装备是否已清空**
如果 `code_clear()` 跳过应用 `code=None`，却仍返回成功，那么在 `test_combat_named_code_backup_and_transfer_keep_original_behavior` 中，`_code_apply` 默认返回 `True`，但测试从未断言 `code_clear()` 是否以 `code=None` 调用了它。如果 `code_clear()` 仅备份代码却没有清空舰船，仍然报告成功，之后的转移调用会满足 `assert_called_with(code=BEFORE_CODE)`，测试也会通过。
除了之后的转移调用外，还请断言清空时 `_code_apply` 收到了 `code=None`。
</issue_to_address>Original comment in English
Hey - I've found 7 issues
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location path="module/equipment/equipment_config.py" line_range="139-140" />
<code_context>
+ logger.hr('战前装备配置', level=2)
+ self.ensure_reorganize()
+
+ if self.config.Equipment_ClearBeforeApply:
+ if not self.equipment_clear():
+ raise RequestHumanTakeover('清空装备失败')
+
</code_context>
<issue_to_address>
**Fleet remains partly changed**
When a clear, apply, or save operation fails after an earlier position has been changed, `equipment_handle_before()` raises before setting `_equipment_handle_before_flag`, so the recovery path skips the after-plan and the fleet remains cleared or partially equipped.
Set the pending-restore flag before the first fleet mutation and clear it only after restoration succeeds.
Also at `module/equipment/equipment_config.py:143-153`.
</issue_to_address>
### Comment 2
<location path="module/os_ash/meta.py" line_range="825" />
<code_context>
if self._meta_category == 'beacon':
self._reset_assist_request_state()
+ if self.ash_combat.equipment_handle_before_flag and not self._check_beacon_point():
+ self.handle_ash_equipment_after()
if not self._meta_category in self._meta_receive:
self._meta_receive.append(self._meta_category)
</code_context>
<issue_to_address>
**META recovery is abandoned**
When equipment recovery cannot find a usable preparation entry or reach the preparation page before timeout, `handle_ash_equipment_after()` returns `False`, but the META callers continue task completion, stopping, switching, or scheduling; the next task loses the pending flag on the discarded `ash_combat` instance, leaving the fleet in the temporary loadout.
Make every caller stop or otherwise preserve retryable restoration state when `handle_ash_equipment_after()` returns `False`.
Also at `module/os_ash/meta.py:342`, `module/os_ash/meta.py:350`, `module/os_ash/meta.py:443`, `module/os_ash/meta.py:454`, `module/os_ash/meta.py:999`.
</issue_to_address>
### Comment 3
<location path="module/exercise/exercise.py" line_range="346-348" />
<code_context>
break
- # self.equipment_take_off_when_finished()
+ if self.equipment_config_enabled and self.equipment_handle_before_flag:
+ self._choose_opponent(0)
+ self.equipment_handle_after()
+ self.ui_back(EXERCISE_CHECK)
</code_context>
<issue_to_address>
**Interrupted exercise skips restoration**
When the exercise loop is interrupted after the before-configuration has been applied, an exception or task-stop signal during `_exercise_once()` exits `run()` before it reaches the equipment cleanup block. The exercise’s fleet remains on the before-configuration, and the next task instance has no persisted pending flag to trigger restoration.
Run the restoration path from a `finally` or interruption handler while preserving the original stop signal.
</issue_to_address>
### Comment 4
<location path="module/os_ash/meta.py" line_range="182-186" />
<code_context>
+ else:
+ self.device.screenshot()
+
+ if self.appear(BATTLE_PREPARATION, offset=(30, 30)):
+ if self.ash_combat.is_dossier:
+ if self.appear(BATTLE_PREPARATION, offset=(30, 30), interval=2):
+ self.device.click(BACK_ARROW)
+ continue
+ break
+ if timeout.reached():
</code_context>
<issue_to_address>
**Dossier recovery hangs**
When recovery starts on dossier battle preparation and the back click does not leave that page, the dossier branch continues before checking `timeout`, so `handle_ash_equipment_after()` never reaches its timeout return and META recovery loops indefinitely.
Check the timeout before continuing the dossier branch.
</issue_to_address>
### Comment 5
<location path="tests/test_meta_beacon.py" line_range="15" />
<code_context>
+import module.config.server as server
+
+server.server = 'cn'
+
+from module.base.base import ModuleBase
</code_context>
<issue_to_address>
**Tests leak the CN server setting**
When the test suite imports this module alongside tests that depend on another server setting, the module assigns the shared `module.config.server.server` value at import time and never restores it, so tests imported afterward run with CN-specific server behavior and can pass or fail depending on test order.
Set and restore the server value within the tests that require CN behavior, or use a teardown that restores its previous value.
</issue_to_address>
### Comment 6
<location path="tests/test_equipment_config.py" line_range="214-218" />
<code_context>
+
+ def test_preparation_gets_new_frame_after_equipping_then_starts_once(self):
+ handler = make_handler(clear=False, cls=Combat)
+ handler.appear = Mock(return_value=True)
+ self.assertTrue(handler.handle_battle_preparation())
+ handler.device.click.assert_not_called()
+ self.assertTrue(handler.handle_battle_preparation())
+ handler.device.click.assert_called_once_with(BATTLE_PREPARATION)
+ handler._code_apply.assert_called_once_with(code=BEFORE_CODE)
+
</code_context>
<issue_to_address>
**Fresh screenshot is never verified**
When the preparation loop no longer refreshes the screenshot after equipment is applied, in `test_preparation_gets_new_frame_after_equipping_then_starts_once`, `appear` always returns `True` and the test calls `handle_battle_preparation()` twice directly. Both assertions pass even if the preparation loop stops taking a fresh screenshot between equipping and the next check.
Exercise the preparation loop with frame-sensitive appearance results and assert that a screenshot is taken before the next preparation check.
</issue_to_address>
### Comment 7
<location path="tests/test_equipment_config.py" line_range="57-61" />
<code_context>
+ handler.config.EquipmentCode_Config = yaml.safe_dump({'source': None, 'target': None})
+ handler._code_export = Mock(return_value=BEFORE_CODE)
+ self.assertTrue(handler.code_clear(name='source'))
+ self.assertEqual(yaml.safe_load(handler.config.EquipmentCode_Config)['source'], BEFORE_CODE)
+ self.assertEqual(handler.last_code, BEFORE_CODE)
+ self.assertTrue(handler.code_apply(name='target'))
+ handler._code_apply.assert_called_with(code=BEFORE_CODE)
+ self.assertIsNone(handler.last_code)
+
+ def test_invalid_codes_are_rejected_before_navigation_or_clearing(self):
</code_context>
<issue_to_address>
**Equipment clearing is not asserted**
When `code_clear()` skips applying `code=None` but still returns success, in `test_combat_named_code_backup_and_transfer_keep_original_behavior`, `_code_apply` returns `True` by default, but the test never asserts that `code_clear()` calls it with `code=None`. If `code_clear()` reports success after backing up the code without clearing the ship, the later transfer call satisfies `assert_called_with(code=BEFORE_CODE)` and the test passes.
Assert that `_code_apply` receives `code=None` during clearing, in addition to the later transfer call.
</issue_to_address>
Comment on lines
+139
to
+140
| if self.config.Equipment_ClearBeforeApply: | ||
| if not self.equipment_clear(): |
There was a problem hiding this comment.
🟡 中 · 舰队装备仍处于部分变更状态
如果清空、应用或保存操作在之前已有位置发生变更后失败，equipment_handle_before() 会在设置 _equipment_handle_before_flag 之前抛出异常，因此恢复流程会跳过后续方案，舰队最终处于已清空或只装备了一部分的状态。
请在首次修改舰队之前设置待恢复标志，并且只有在恢复成功后才清除该标志。
另请检查 module/equipment/equipment_config.py:143-153。
给 AI 智能体的提示
在 `module/equipment/equipment_config.py` 第 139-140 行：
**舰队装备仍处于部分变更状态**
如果清空、应用或保存操作在之前已有位置发生变更后失败，`equipment_handle_before()` 会在设置 `_equipment_handle_before_flag` 之前抛出异常，因此恢复流程会跳过后续方案，舰队最终处于已清空或只装备了一部分的状态。
请在首次修改舰队之前设置待恢复标志，并且只有在恢复成功后才清除该标志。
另请检查 `module/equipment/equipment_config.py:143-153`。Original comment in English
🟡 Medium · Fleet remains partly changed
When a clear, apply, or save operation fails after an earlier position has been changed, equipment_handle_before() raises before setting _equipment_handle_before_flag, so the recovery path skips the after-plan and the fleet remains cleared or partially equipped.
Set the pending-restore flag before the first fleet mutation and clear it only after restoration succeeds.
Also at module/equipment/equipment_config.py:143-153.
Prompt for AI agents
In `module/equipment/equipment_config.py` at lines 139-140:
**Fleet remains partly changed**
When a clear, apply, or save operation fails after an earlier position has been changed, `equipment_handle_before()` raises before setting `_equipment_handle_before_flag`, so the recovery path skips the after-plan and the fleet remains cleared or partially equipped.
Set the pending-restore flag before the first fleet mutation and clear it only after restoration succeeds.
Also at `module/equipment/equipment_config.py:143-153`.| logger.info("当前服务器暂不支持档案信标和一刀模式，请联系开发者") | ||
| self._ensure_meta_page() | ||
| self._attack_meta() | ||
| self.handle_ash_equipment_after() |
There was a problem hiding this comment.
🟠 高 · META 恢复流程被放弃
当装备恢复流程找不到可用的准备方案条目，或在超时前无法进入准备页面时，handle_ash_equipment_after() 会返回 False，但 META 调用方仍会继续完成任务、停止、切换或安排后续任务；下一个任务会因被丢弃的 ash_combat 实例而丢失待恢复标志，导致舰队仍处于临时配置。
当 handle_ash_equipment_after() 返回 False 时，请确保每个调用方都会停止，或以其他方式保留可重试的恢复状态。
另请检查 module/os_ash/meta.py:342、module/os_ash/meta.py:350、module/os_ash/meta.py:443、module/os_ash/meta.py:454、module/os_ash/meta.py:999。
给 AI 智能体的提示
在 `module/os_ash/meta.py` 第 825 行：
**META 恢复流程被放弃**
当装备恢复流程找不到可用的准备方案条目，或在超时前无法进入准备页面时，`handle_ash_equipment_after()` 会返回 `False`，但 META 调用方仍会继续完成任务、停止、切换或安排后续任务；下一个任务会因被丢弃的 `ash_combat` 实例而丢失待恢复标志，导致舰队仍处于临时配置。
当 `handle_ash_equipment_after()` 返回 `False` 时，请确保每个调用方都会停止，或以其他方式保留可重试的恢复状态。
另请检查 `module/os_ash/meta.py:342`、`module/os_ash/meta.py:350`、`module/os_ash/meta.py:443`、`module/os_ash/meta.py:454`、`module/os_ash/meta.py:999`。Original comment in English
🟠 High · META recovery is abandoned
When equipment recovery cannot find a usable preparation entry or reach the preparation page before timeout, handle_ash_equipment_after() returns False, but the META callers continue task completion, stopping, switching, or scheduling; the next task loses the pending flag on the discarded ash_combat instance, leaving the fleet in the temporary loadout.
Make every caller stop or otherwise preserve retryable restoration state when handle_ash_equipment_after() returns False.
Also at module/os_ash/meta.py:342, module/os_ash/meta.py:350, module/os_ash/meta.py:443, module/os_ash/meta.py:454, module/os_ash/meta.py:999.
Prompt for AI agents
In `module/os_ash/meta.py` at line 825:
**META recovery is abandoned**
When equipment recovery cannot find a usable preparation entry or reach the preparation page before timeout, `handle_ash_equipment_after()` returns `False`, but the META callers continue task completion, stopping, switching, or scheduling; the next task loses the pending flag on the discarded `ash_combat` instance, leaving the fleet in the temporary loadout.
Make every caller stop or otherwise preserve retryable restoration state when `handle_ash_equipment_after()` returns `False`.
Also at `module/os_ash/meta.py:342`, `module/os_ash/meta.py:350`, `module/os_ash/meta.py:443`, `module/os_ash/meta.py:454`, `module/os_ash/meta.py:999`.
Comment on lines
+346
to
+348
| if self.equipment_config_enabled and self.equipment_handle_before_flag: | ||
| self._choose_opponent(0) | ||
| self.equipment_handle_after() |
There was a problem hiding this comment.
🟡 中 · 练习被中断时会跳过恢复
如果在应用战前配置后练习循环被中断，_exercise_once() 中发生异常或收到任务停止信号，会导致 run() 在到达装备清理代码块之前退出。练习中的舰队会继续使用战前配置，而下一个任务实例没有持久化的待恢复标志来触发恢复。
请通过 finally 或中断处理程序执行恢复流程，同时保留原始停止信号。
给 AI 智能体的提示
在 `module/exercise/exercise.py` 第 346-348 行：
**练习被中断时会跳过恢复**
如果在应用战前配置后练习循环被中断，`_exercise_once()` 中发生异常或收到任务停止信号，会导致 `run()` 在到达装备清理代码块之前退出。练习中的舰队会继续使用战前配置，而下一个任务实例没有持久化的待恢复标志来触发恢复。
请通过 `finally` 或中断处理程序执行恢复流程，同时保留原始停止信号。Original comment in English
🟡 Medium · Interrupted exercise skips restoration
When the exercise loop is interrupted after the before-configuration has been applied, an exception or task-stop signal during _exercise_once() exits run() before it reaches the equipment cleanup block. The exercise’s fleet remains on the before-configuration, and the next task instance has no persisted pending flag to trigger restoration.
Run the restoration path from a finally or interruption handler while preserving the original stop signal.
Prompt for AI agents
In `module/exercise/exercise.py` at lines 346-348:
**Interrupted exercise skips restoration**
When the exercise loop is interrupted after the before-configuration has been applied, an exception or task-stop signal during `_exercise_once()` exits `run()` before it reaches the equipment cleanup block. The exercise’s fleet remains on the before-configuration, and the next task instance has no persisted pending flag to trigger restoration.
Run the restoration path from a `finally` or interruption handler while preserving the original stop signal.
Comment on lines
+182
to
+186
| if self.appear(BATTLE_PREPARATION, offset=(30, 30)): | ||
| if self.ash_combat.is_dossier: | ||
| if self.appear(BATTLE_PREPARATION, offset=(30, 30), interval=2): | ||
| self.device.click(BACK_ARROW) | ||
| continue |
There was a problem hiding this comment.
🟡 中 · 档案恢复流程会卡住
如果恢复流程从档案战斗准备页面开始，而点击返回后仍未离开该页面，档案分支会在检查 timeout 之前执行 continue，因此 handle_ash_equipment_after() 永远不会返回超时结果，META 恢复流程会无限循环。
请在档案分支继续执行之前检查超时。
给 AI 智能体的提示
在 `module/os_ash/meta.py` 第 182-186 行：
**档案恢复流程会卡住**
如果恢复流程从档案战斗准备页面开始，而点击返回后仍未离开该页面，档案分支会在检查 `timeout` 之前执行 `continue`，因此 `handle_ash_equipment_after()` 永远不会返回超时结果，META 恢复流程会无限循环。
请在档案分支继续执行之前检查超时。Original comment in English
🟡 Medium · Dossier recovery hangs
When recovery starts on dossier battle preparation and the back click does not leave that page, the dossier branch continues before checking timeout, so handle_ash_equipment_after() never reaches its timeout return and META recovery loops indefinitely.
Check the timeout before continuing the dossier branch.
Prompt for AI agents
In `module/os_ash/meta.py` at lines 182-186:
**Dossier recovery hangs**
When recovery starts on dossier battle preparation and the back click does not leave that page, the dossier branch continues before checking `timeout`, so `handle_ash_equipment_after()` never reaches its timeout return and META recovery loops indefinitely.
Check the timeout before continuing the dossier branch.|
|
||
| import module.config.server as server | ||
|
|
||
| server.server = 'cn' |
There was a problem hiding this comment.
🟡 中 · 测试会泄漏 CN 服务器设置
当测试套件同时导入此模块和依赖其他服务器设置的测试时，该模块会在导入时修改共享的 module.config.server.server 值，却从不恢复它。因此，之后导入的测试会使用 CN 特定的服务器行为，并可能因测试顺序而通过或失败。
请在需要 CN 行为的测试中设置并恢复服务器值，或使用 teardown 恢复其原有值。
给 AI 智能体的提示
在 `tests/test_meta_beacon.py` 第 15 行：
**测试会泄漏 CN 服务器设置**
当测试套件同时导入此模块和依赖其他服务器设置的测试时，该模块会在导入时修改共享的 `module.config.server.server` 值，却从不恢复它。因此，之后导入的测试会使用 CN 特定的服务器行为，并可能因测试顺序而通过或失败。
请在需要 CN 行为的测试中设置并恢复服务器值，或使用 teardown 恢复其原有值。Original comment in English
🟡 Medium · Tests leak the CN server setting
When the test suite imports this module alongside tests that depend on another server setting, the module assigns the shared module.config.server.server value at import time and never restores it, so tests imported afterward run with CN-specific server behavior and can pass or fail depending on test order.
Set and restore the server value within the tests that require CN behavior, or use a teardown that restores its previous value.
Prompt for AI agents
In `tests/test_meta_beacon.py` at line 15:
**Tests leak the CN server setting**
When the test suite imports this module alongside tests that depend on another server setting, the module assigns the shared `module.config.server.server` value at import time and never restores it, so tests imported afterward run with CN-specific server behavior and can pass or fail depending on test order.
Set and restore the server value within the tests that require CN behavior, or use a teardown that restores its previous value.
Comment on lines
+214
to
+218
| handler.appear = Mock(return_value=True) | ||
| self.assertTrue(handler.handle_battle_preparation()) | ||
| handler.device.click.assert_not_called() | ||
| self.assertTrue(handler.handle_battle_preparation()) | ||
| handler.device.click.assert_called_once_with(BATTLE_PREPARATION) |
There was a problem hiding this comment.
🟡 中 · 没有验证是否获取了新截图
如果准备循环在应用装备后不再刷新截图，那么在 test_preparation_gets_new_frame_after_equipping_then_starts_once 中，appear 始终返回 True，且测试直接调用了两次 handle_battle_preparation()。即使准备循环在装备完成后、下次检查前不再获取新截图，这两个断言仍会通过。
请使用依赖帧内容的外观检测结果来运行准备循环，并断言在下次准备检查之前已经截取了新图。
给 AI 智能体的提示
在 `tests/test_equipment_config.py` 第 214-218 行：
**没有验证是否获取了新截图**
如果准备循环在应用装备后不再刷新截图，那么在 `test_preparation_gets_new_frame_after_equipping_then_starts_once` 中，`appear` 始终返回 `True`，且测试直接调用了两次 `handle_battle_preparation()`。即使准备循环在装备完成后、下次检查前不再获取新截图，这两个断言仍会通过。
请使用依赖帧内容的外观检测结果来运行准备循环，并断言在下次准备检查之前已经截取了新图。Original comment in English
🟡 Medium · Fresh screenshot is never verified
When the preparation loop no longer refreshes the screenshot after equipment is applied, in test_preparation_gets_new_frame_after_equipping_then_starts_once, appear always returns True and the test calls handle_battle_preparation() twice directly. Both assertions pass even if the preparation loop stops taking a fresh screenshot between equipping and the next check.
Exercise the preparation loop with frame-sensitive appearance results and assert that a screenshot is taken before the next preparation check.
Prompt for AI agents
In `tests/test_equipment_config.py` at lines 214-218:
**Fresh screenshot is never verified**
When the preparation loop no longer refreshes the screenshot after equipment is applied, in `test_preparation_gets_new_frame_after_equipping_then_starts_once`, `appear` always returns `True` and the test calls `handle_battle_preparation()` twice directly. Both assertions pass even if the preparation loop stops taking a fresh screenshot between equipping and the next check.
Exercise the preparation loop with frame-sensitive appearance results and assert that a screenshot is taken before the next preparation check.
Comment on lines
+57
to
+61
| self.assertEqual(yaml.safe_load(handler.config.EquipmentCode_Config)['source'], BEFORE_CODE) | ||
| self.assertEqual(handler.last_code, BEFORE_CODE) | ||
| self.assertTrue(handler.code_apply(name='target')) | ||
| handler._code_apply.assert_called_with(code=BEFORE_CODE) | ||
| self.assertIsNone(handler.last_code) |
There was a problem hiding this comment.
🟡 中 · 没有断言装备是否已清空
如果 code_clear() 跳过应用 code=None，却仍返回成功，那么在 test_combat_named_code_backup_and_transfer_keep_original_behavior 中，_code_apply 默认返回 True，但测试从未断言 code_clear() 是否以 code=None 调用了它。如果 code_clear() 仅备份代码却没有清空舰船，仍然报告成功，之后的转移调用会满足 assert_called_with(code=BEFORE_CODE)，测试也会通过。
除了之后的转移调用外，还请断言清空时 _code_apply 收到了 code=None。
给 AI 智能体的提示
在 `tests/test_equipment_config.py` 第 57-61 行：
**没有断言装备是否已清空**
如果 `code_clear()` 跳过应用 `code=None`，却仍返回成功，那么在 `test_combat_named_code_backup_and_transfer_keep_original_behavior` 中，`_code_apply` 默认返回 `True`，但测试从未断言 `code_clear()` 是否以 `code=None` 调用了它。如果 `code_clear()` 仅备份代码却没有清空舰船，仍然报告成功，之后的转移调用会满足 `assert_called_with(code=BEFORE_CODE)`，测试也会通过。
除了之后的转移调用外，还请断言清空时 `_code_apply` 收到了 `code=None`。Original comment in English
🟡 Medium · Equipment clearing is not asserted
When code_clear() skips applying code=None but still returns success, in test_combat_named_code_backup_and_transfer_keep_original_behavior, _code_apply returns True by default, but the test never asserts that code_clear() calls it with code=None. If code_clear() reports success after backing up the code without clearing the ship, the later transfer call satisfies assert_called_with(code=BEFORE_CODE) and the test passes.
Assert that _code_apply receives code=None during clearing, in addition to the later transfer call.
Prompt for AI agents
In `tests/test_equipment_config.py` at lines 57-61:
**Equipment clearing is not asserted**
When `code_clear()` skips applying `code=None` but still returns success, in `test_combat_named_code_backup_and_transfer_keep_original_behavior`, `_code_apply` returns `True` by default, but the test never asserts that `code_clear()` calls it with `code=None`. If `code_clear()` reports success after backing up the code without clearing the ship, the later transfer call satisfies `assert_called_with(code=BEFORE_CODE)` and the test passes.
Assert that `_code_apply` receives `code=None` during clearing, in addition to the later transfer call.
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
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.
📋 许可确认
💯 代码质量确认
uv run ruff check . --select E9,F63,F7,F82 --ignore F821,F722npm run typecheck --prefix frontendmodule/config/argument/下的 YAML 源文件，已运行uv run -m module.config.config_updater并提交生成产物🔍 变更类型 (勾选所有适用项)
📄 PR 描述
🔗 相关 Issue
📸 修改效果截图
🛠️ 实现复杂度
📋 实现细节 (可选)
🧪 测试步骤 (可选)
Sourcery 总结
为演习和 META 战斗引入可配置的战前换装与战后恢复流程，并完善相关配置、资源、文档和测试。
新功能：
错误修复：
改进：
构建：
文档：
测试：
杂项：
Original summary in English
Sourcery 总结
为演习和 META 战斗引入可配置的战前换装与可靠的战后装备恢复流程。
新功能：
问题修复：
功能增强：
构建：
文档：
测试：
杂项：
Original summary in English
Sourcery 摘要
为演习和 META 战斗引入可配置的装备预设，并确保战斗结束后能安全恢复装备。
新功能：
错误修复：
增强功能：
构建：
文档：
测试：
杂项：
Original summary in English
Sourcery 摘要
为演习和 META 战斗引入可配置且可可靠恢复的战前与战后装备方案。
新功能：
错误修复：
改进：
构建：
文档：
测试：
杂项：
Original summary in English
Summary by Sourcery
为演习和 META 战斗引入可配置且可可靠恢复的战前与战后装备方案。
New Features:
Bug Fixes:
Enhancements:
Build:
Documentation:
Tests:
Chores:
Summary by CodeRabbit