规范类命名

docs/CodeX-TODO.md

@@ -8,8 +8,8 @@
 
 和上一版相比，仓库已经把 Run 相关基础件进一步接到了 `ProcedureMain`，因此这份清单不再把重点放在“有没有 Run 模型”，而是聚焦下面这几个真实阻塞项：
 
-- 已有 `ProcedureMain + NodeMapForm` 的临时 Run 推进闭环，正式节点面板骨架已经接入流程。
-- 固定 10 节点顺序已经开始驱动战斗 / 事件 / 商店入口，但节点事件上下文仍然是空载版本。
+- 已有 `ProcedureMenu + MenuForm -> ProcedureMain + NodeMapForm` 的主入口链路，正式节点面板骨架已经接入流程。
+- 固定 10 节点顺序已经开始驱动战斗 / 事件 / 商店入口，节点事件也已带上基础 Run 上下文字段。
 - 出战入口已有“至少有参战塔”的最小校验，但还没收口成严格的最终合法性约束。
 - 品质 / Tag / 耐久仍然停留在部分实现状态，尚未和 M1 范围完全对齐。
 
@@ -30,13 +30,13 @@
 ### 2. 战斗结算、掉落与奖励选择已有基础实现
 
 - 敌人被击败后已能发放 coin / gold / 组件掉落。
-- `CombatInRunResourceManager` 维护局内资源与奖励背包快照。
+- `CombatRunResourceStore` 维护局内资源与奖励背包快照。
 - 结算链已包含奖励计算、奖励选择 UI、FinishForm 返回等基础骨架。
 
 关键文件：
-- `Assets/GameMain/Scripts/CustomComponent/CombatNode/CombatScheduler/CombatInRunResourceManager.cs`
+- `Assets/GameMain/Scripts/CustomComponent/CombatNode/CombatScheduler/CombatRunResourceStore.cs`
 - `Assets/GameMain/Scripts/CustomComponent/CombatNode/CombatScheduler/EnemyDrop/EnemyDropResolver.cs`
-- `Assets/GameMain/Scripts/CustomComponent/CombatNode/CombatScheduler/CombatSettlementFlowService.cs`
+- `Assets/GameMain/Scripts/CustomComponent/CombatNode/CombatScheduler/CombatSettlementService.cs`
 - `Assets/GameMain/Scripts/UI/Combat/`
 
 ### 3. 背包、参战区与组装基础能力已经存在
@@ -107,6 +107,19 @@
 - `Assets/GameMain/Scripts/UI/Game/View/NodeItem.cs`
 - `Assets/GameMain/Scripts/Event/Game/NodeMapNodeEnterRequestedEventArgs.cs`
 
+### 8. 菜单入口已切回独立 Menu 流程
+
+- `ProcedureMenu` 当前只负责菜单入口，不再承载主流程 Hub 与节点推进逻辑。
+- `MenuForm` 已按五层结构补齐 `RawData / UseCase / Controller / Context / View`。
+- `Start` 按钮现在会驱动 `ProcedureMenu` 切场景，并在主场景加载完成后进入 `ProcedureMain`。
+- `Settings` 仍保留 `TODO` 占位，`Exit` 会直接退出游戏。
+
+关键文件：
+- `Assets/GameMain/Scripts/Procedure/ProcedureMenu.cs`
+- `Assets/GameMain/Scripts/Procedure/Base/ProcedureChangeScene.cs`
+- `Assets/GameMain/Scripts/UI/Menu/Controller/MenuFormController.cs`
+- `Assets/GameMain/Scripts/UI/Menu/View/MenuForm.cs`
+
 ## 当前未完成
 
 ### 1. Run 主流程已经形成基于 `NodeMapForm` 的临时闭环，但还没完全收口
@@ -127,14 +140,14 @@
 - `Assets/GameMain/Scripts/UI/Game/View/NodeMapForm.cs`
 - `Assets/GameMain/Scripts/UI/Game/Controller/NodeMapFormController.cs`
 
-### 2. 固定 10 节点序列已开始驱动真实流程，但上下文仍不完整
+### 2. 固定 10 节点序列已开始驱动真实流程，但正式上下文系统仍不完整
 
 - `FixedRunNodeSequenceBuilder` 已定义固定顺序和 Boss 终点。
 - `ProcedureMain` 已开始用当前 `RunNodeState.LinkedLevelId` 驱动战斗入口。
 - `EventNodeComponent` 和 `ShopNodeComponent` 已能进入并完成当前节点。
 - `EventNodeComponent` 的 UI 生命周期也已统一走 `UIRouter`。
-- 但 `NodeEnter / NodeComplete` 仍是默认空载事件，没有附带当前 Run 节点信息。
-- 因此“固定 10 节点序列”已经在驱动流程，但还没有形成可观测、可追踪的正式节点上下文系统。
+- `NodeEnter / NodeComplete` 已带 `runId / nodeId / nodeType / sequenceIndex` 等基础字段，`NodeComplete` 也会回传成功状态与库存快照。
+- 当前缺的不是“有没有上下文字段”，而是更系统化的节点追踪、展示与统一收口能力。
 
 关键文件：
 - `Assets/GameMain/Scripts/Procedure/FixedRunNodeSequenceBuilder.cs`
@@ -144,7 +157,7 @@
 - `Assets/GameMain/Scripts/Event/Game/NodeEnterEventArgs.cs`
 - `Assets/GameMain/Scripts/Event/Game/NodeCompleteEventArgs.cs`
 
-### 3. 商店节点已纳入临时 Run 推进闭环，但回流目标仍是测试 Hub
+### 3. 商店节点已纳入临时 Run 推进闭环，但回流目标仍是 MVP Hub
 
 - 现在可以单独打开商店、随机生成组件、购买并退出。
 - 商店结束后已能通过 `ProcedureMain` 推进当前 `RunState`。
@@ -201,7 +214,7 @@
 结合静态代码检查，当前更接近下面这个状态：
 
 - `P0-04`：基础模型已完成，并已接入 `ProcedureMain + NodeMapForm` 的临时 Run 闭环。
-- `P0-05`：固定 10 节点序列已由 builder + `ProcedureMain + NodeMapForm` 驱动实际流程，但缺完整事件上下文与地图表现层。
+- `P0-05`：固定 10 节点序列已由 builder + `ProcedureMain + NodeMapForm` 驱动实际流程，基础事件上下文字段已接入，但缺更完整的地图表现层与正式上下文系统。
 - `P0-06`：节点进入、完成、失败后回 `NodeMapForm` 的临时闭环已存在，但正式地图表现与正式结算仍未完成。
 - `P0-10`：未完成。
 - `P0-11`：未完成。
@@ -216,9 +229,9 @@
    - 继续以 `NodeMapForm` 为基础补正式节点地图表现
    - 至少补上节点连线、Boss 视觉强调、当前节点说明和完成态反馈
 
-2. 再把节点事件改成带上下文的真实推进
-   - `NodeEnterEventArgs` 和 `NodeCompleteEventArgs` 传递 `runId / nodeId / nodeType / sequenceIndex`
-   - 节点完成后由流程层调用 `RunStateAdvanceService`
+2. 再补齐节点上下文的消费、追踪与统一推进
+   - 继续沿用 `NodeEnterEventArgs` 和 `NodeCompleteEventArgs` 现有的 `runId / nodeId / nodeType / sequenceIndex`
+   - 节点完成后统一由流程层调用 `RunStateAdvanceService`
    - 节点失败时明确是否停局、重试或返回菜单
 
 3. 然后继续收口战斗关卡选择
@@ -236,6 +249,7 @@
 ## 当前做变更时要记住的约束
 
 - 不要再把 Hub 退回 `TestMenuForm` 语义。
+- 不要把菜单入口和主流程 Hub 混回同一个 Procedure；保持 `ProcedureMenu -> ProcedureMain` 的职责边界。
 - 优先补“临时闭环 -> 正式节点 UI / 正式上下文”的收口，不要继续只加单点功能。
 - 商店已经接入 Run，下一步重点不是继续扩商店，而是把 Hub/UI 做正式。
 - 若 M1 最终不做完整耐久 / 红色品质，要先同步文档再改代码目标。

docs/CombatNodeArchitecture.md

@@ -68,8 +68,8 @@
 - 上述状态类可以作为 `CombatScheduler` 的嵌套类实现，也可以拆成独立文件；但必须只服务于 `CombatScheduler` 状态机，不形成独立业务边界。
 - 共享数据与共享服务统一收口到 `CombatScheduler` 内部持有的运行时承载体，不允许散落在各状态类中。
 - 若 `CombatScheduler` 体量过大，允许在其内部实现中继续拆出：
-  - `CombatSchedulerRuntimeContext`：承载共享运行时字段与共享服务引用
-  - `CombatSchedulerFlowCoordinator`：承载多个状态共用的流程辅助方法
+  - `CombatSchedulerRuntime`：承载共享运行时字段与共享服务引用
+  - `CombatSchedulerCoordinator`：承载多个状态共用的流程辅助方法
 - 上述拆分只属于 `CombatScheduler` 的内部实现细化，不改变 `CombatScheduler` 作为唯一状态机边界的职责。
 - 所有状态切换只能通过 `CombatScheduler.ChangeState(...)` 完成。
 - 状态类不能彼此直接操控。
@@ -213,7 +213,23 @@
 
 ## 4. 共享服务与推荐命名
 
-### 4.1 CombatLoadSession
+### 4.1 命名后缀词典
+
+- `Scheduler`：只用于状态机边界或阶段推进总控，例如 `CombatScheduler`。
+- `Manager`：只用于子域 Facade/聚合入口，例如 `EnemyManager`。
+- `Coordinator`：只用于跨状态、跨服务的流程编排，不持有独立业务真值。
+- `Service`：只用于聚焦业务行为，不承担框架事件桥接或异步句柄跟踪。
+- `Session`：只用于一次加载/交互过程的生命周期对象。
+- `Bridge`：只用于框架边界适配器。
+- `Runtime`：只用于运行时可变状态承载。
+- `Context`：只用于被动数据包或共享上下文。
+- `Result`：只用于动作输出或结算产出；若外围服务名已表达动作语义，不再重复动作前缀。
+- `Flags`：只用于聚合布尔控制项，不承载流程编排逻辑。
+- `Resolver`：只用于映射、查找、判定、解析职责。
+- `Tracker`：只用于跟踪运行中的实体或事实真值。
+- `Port`：只用于向内部状态或 use case 暴露的受限宿主接口。
+
+### 4.2 CombatLoadSession
 
 文件：`Assets/GameMain/Scripts/CustomComponent/CombatNode/CombatScheduler/CombatLoadSession.cs`
 
@@ -227,20 +243,20 @@
 - 跟踪加载成功/失败状态。
 - 对外提供 `CurrentMap` 与 `IsReady`。
 
-### 4.1.x CombatSchedulerRuntimeContext / CombatSchedulerFlowCoordinator（实现细化）
+### 4.2.x CombatSchedulerRuntime / CombatSchedulerCoordinator（实现细化）
 
 当前实现允许：
-- 用 `CombatSchedulerRuntimeContext` 承载所有状态共享的运行时字段与共享服务引用。
-- 用 `CombatSchedulerFlowCoordinator` 承载多个状态共用的流程辅助逻辑。
+- 用 `CombatSchedulerRuntime` 承载所有状态共享的运行时字段与共享服务引用。
+- 用 `CombatSchedulerCoordinator` 承载多个状态共用的流程辅助逻辑。
 
 约束：
 - 两者都必须由 `CombatScheduler` 持有并统一管理生命周期。
 - 两者都不替代 `CombatScheduler` 对外暴露状态机边界。
-- `RuntimeContext` 不负责状态切换。
-- `FlowCoordinator` 不持有独立业务真值，只能围绕共享运行时做编排辅助。
-- 状态类只允许通过 `RuntimeContext + FlowCoordinator` 访问共享状态与共享流程，不应再直接耦合其他状态实现细节。
+- `Runtime` 不负责状态切换。
+- `Coordinator` 不持有独立业务真值，只能围绕共享运行时做编排辅助。
+- 状态类只允许通过 `Runtime + Coordinator` 访问共享状态与共享流程，不应再直接耦合其他状态实现细节。
 
-### 4.2 PhaseLoopRuntime
+### 4.3 PhaseLoopRuntime
 
 文件：`Assets/GameMain/Scripts/CustomComponent/CombatNode/CombatScheduler/PhaseLoopRuntime.cs`
 
@@ -257,9 +273,9 @@
 约束：
 - 只做 phase 运行时数据管理，不直接切状态。
 
-### 4.3 CombatInRunResourceManager（推荐命名）
+### 4.4 CombatRunResourceStore
 
-当前相关文件：`Assets/GameMain/Scripts/CustomComponent/CombatNode/CombatScheduler/CombatResourceManager.cs`
+文件：`Assets/GameMain/Scripts/CustomComponent/CombatNode/CombatScheduler/CombatRunResourceStore.cs`
 
 目标职责：
 - 持有本局 `Coin` 真值。
@@ -280,9 +296,9 @@
 - `Coin / BaseHp` 变化事件同时携带“当前值”和“变化量”。
 - `Gold` 只是结算累计值，不要求战斗内实时事件驱动。
 
-### 4.4 EnemyDropResolver（推荐命名）
+### 4.5 EnemyDropResolver
 
-当前相关文件：`Assets/GameMain/Scripts/CustomComponent/CombatNode/CombatScheduler/CombatResourceManager.cs`
+文件：`Assets/GameMain/Scripts/CustomComponent/CombatNode/CombatScheduler/EnemyDrop/EnemyDropResolver.cs`
 
 目标职责：
 - 只负责敌人死亡后的掉落判定。
@@ -297,7 +313,7 @@
 - 不直接修改资源状态。
 - 不直接读取 `CombatNodeComponent`、`MapEntity`、`EnemyManager` 内部状态。
 
-### 4.5 IPhaseEndCondition（推荐命名）
+### 4.6 IPhaseEndCondition
 
 目标职责：
 - 作为 `PhaseEndType` 判定接口。
@@ -334,9 +350,9 @@
 生命周期：
 - 由 `CombatRunningPhaseState` 在状态进入/退出时初始化与重置。
 
-### 5.2 SpawnerResolver
+### 5.2 EnemySpawnPathResolver
 
-文件：`Assets/GameMain/Scripts/CustomComponent/CombatNode/EnemyManager/SpawnerResolver.cs`
+文件：`Assets/GameMain/Scripts/CustomComponent/CombatNode/EnemyManager/EnemySpawnPathResolver.cs`
 
 职责：
 - 缓存当前地图可用 `Spawner`。
@@ -356,9 +372,9 @@ Boss 识别规则：
 - Boss 身份由 `DRLevelSpawnEntry.EntryType == Boss` 决定。
 - 不由 `DREnemy` 自身类型决定。
 
-### 5.4 EnemyConfigService
+### 5.4 EnemyConfigProvider
 
-文件：`Assets/GameMain/Scripts/CustomComponent/CombatNode/EnemyManager/EnemyConfigService.cs`
+文件：`Assets/GameMain/Scripts/CustomComponent/CombatNode/EnemyManager/EnemyConfigProvider.cs`
 
 职责：
 - 读取 `DREnemy`。
@@ -436,6 +452,9 @@ Boss 识别规则：
 - 是否进入过奖励选择
 - `FinishForm` 所需摘要数据
 
+命名约束：
+- 结算上下文中的布尔控制项统一收口到 `Flags`，不再使用 `Flow` 命名。
+
 奖励选择约束：
 - 满血奖励选择结果只写入结算上下文。
 - 不直接写入局内资源管理器。
@@ -447,7 +466,7 @@ Boss 识别规则：
 
 1. `CombatScheduler` 只做状态机管理与共享运行时收口，不继续吸收具体业务细节。
 2. `CombatNodeComponent` 不再持有战斗内资源真值。
-3. 局内 `Coin / Gold / BaseHp / Loot Backpack / BuildTowerSnapshots` 以 `CombatInRunResourceManager` 为唯一真值来源。
+3. 局内 `Coin / Gold / BaseHp / Loot Backpack / BuildTowerSnapshots` 以 `CombatRunResourceStore` 为唯一真值来源。
 4. 敌人死亡掉落判定以 `EnemyDropResolver` 为唯一判定入口。
 5. 存活敌人数与 `HasAliveBoss` 以 `EnemyLifecycleTracker` 为唯一真值来源。
 6. Phase 运行时信息与统一结束标记以 `PhaseLoopRuntime` 为唯一真值来源。
@@ -483,7 +502,7 @@ Boss 识别规则：
 
 ### 10.4 新增战斗内资源或建塔快照规则
 
-优先改 `CombatInRunResourceManager`，不要回流到 `CombatNodeComponent`。
+优先改 `CombatRunResourceStore`，不要回流到 `CombatNodeComponent`。
 
 ### 10.5 新增地图/战斗基础 UI 加载规则