# CodeX TODO

最后更新：2026-03-08

> 目标：基于当前仓库现状，为 `docs/TODO.md` 的 M1 收口补一份更可执行的补充顺序。
> 原则：先收主流程，再补硬规则，最后统一文档与验收口径。

## 执行规则

1. 优先完成会阻塞 M1 验收的内容，不提前展开 M2 深度功能。
2. 每一项先收“流程可走通”，再收“规则完整”，最后再做表现层补齐。
3. `ProcedureMain + NodeMapForm + PlayerInventory + CombatNode` 视为当前主链路，后续补充都围绕这条链路推进。

## 阶段 S1 - 收口主流程

| 状态  | ID    | 任务                             | 交付物路径                                                                      | 验收标准                     |
|-----|-------|--------------------------------|----------------------------------------------------------------------------|--------------------------|
| [x] | S1-01 | 统一梳理 M1 当前状态与文档口径              | `docs/CodeX-TODO.md`<br>`docs/TODO.md`                                     | 当前实现、目标状态、未完成项三者口径一致     |
| [ ] | S1-02 | 收口 `ProcedureMain` 的 Run 推进主链路 | `Assets/GameMain/Scripts/Procedure/`                                       | 从开始游戏到 Boss 结算可稳定走完整条链   |
| [ ] | S1-03 | 收口节点进入、完成、失败后的统一回流             | `Assets/GameMain/Scripts/Procedure/`<br>`Assets/GameMain/Scripts/Event/`   | 战斗 / 事件 / 商店都能统一推进当前 Run |
| [ ] | S1-04 | 收口 Run 完成后的正式结束态               | `Assets/GameMain/Scripts/Procedure/`<br>`Assets/GameMain/Scripts/UI/Game/` | 10 节点完成后有明确的结束表现与收尾逻辑    |

## S1-01 对齐结论

### 当前实现

- `ProcedureMain + NodeMapForm` 已能创建固定 10 节点 Run，并驱动战斗 / 事件 / 商店三类节点的临时入口。
- `RunState`、`FixedRunNodeSequenceBuilder`、`RunStateAdvanceService` 与对应 Editor 测试已存在，说明 Run 模型、固定序列、节点推进基础能力已经落地。
- 战斗节点已有结算、奖励选择、失败返回；事件和商店节点也会发出 `NodeEnterEventArgs / NodeCompleteEventArgs`，但主流程仍属于“临时闭环”。
- `P0-10 ~ P0-12` 不是纯空白：
  - 出战前已有“参与区至少有 1 座塔”的最低门槛；
  - 品质 / Tag 已在组装、商店、展示链路中分散使用；
  - 耐久已有字段、展示与扣减入口。

### M1 目标状态

- M1 验收口径应以“从开始游戏到 Boss 节点结算结束，当前 Run 能稳定走完整条链”为准。
- `NodeMapForm` 在 M1 里应被视为正式节点地图入口，而不是只靠临时面板勉强串流程。
- 战斗 / 事件 / 商店都需要统一节点进入、完成、失败后的回流方式，避免每类节点各走一套。
- 出战合法性需要从“至少有参战塔”收口为“满足完整三组件条件才可出战”。

### 仍未完成

- Run 完成后的正式结束态、Boss 后收尾表现、统一的主流程回流仍未收口。
- 节点地图表现仍缺正式状态表达、说明文案与反馈，不应把这部分误记为已完成。
- 品质 / Tag / 耐久在代码里已有局部实现，但还没有统一规则入口，因此仍应视为未收口项，而不是 M1 已完成项。

## 阶段 S2 - 收口节点地图表现

| 状态  | ID    | 任务                             | 交付物路径                              | 验收标准                   |
|-----|-------|--------------------------------|------------------------------------|------------------------|
| [ ] | S2-01 | 把 `NodeMapForm` 从临时面板收口成正式节点地图 | `Assets/GameMain/Scripts/UI/Game/` | 节点地图不再只是临时占位面板         |
| [ ] | S2-02 | 补齐节点状态、当前节点、完成态、Boss 节点表现      | `Assets/GameMain/Scripts/UI/Game/` | 玩家能一眼读懂当前 Run 进度       |
| [ ] | S2-03 | 补齐节点说明、反馈、回流提示                 | `Assets/GameMain/Scripts/UI/Game/` | 节点点击、进入、完成、失败均有明确反馈    |
| [ ] | S2-04 | 统一节点地图与主 HUD / MainForm 的职责边界  | `Assets/GameMain/Scripts/UI/Game/` | Hub UI 职责清晰，不再重复表达同类信息 |

## 阶段 S3 - 收口出战合法性

| 状态  | ID    | 任务               | 交付物路径                                                                                            | 验收标准               |
|-----|-------|------------------|--------------------------------------------------------------------------------------------------|--------------------|
| [ ] | S3-01 | 定义“合法参战塔”的最终判定口径 | `docs/CodeX-TODO.md`<br>`Assets/GameMain/Scripts/Definition/`                                    | 流程层与 UI 层共用同一套判定口径 |
| [ ] | S3-02 | 收口组装区与参战区的合法性校验  | `Assets/GameMain/Scripts/UI/Game/`<br>`Assets/GameMain/Scripts/CustomComponent/PlayerInventory/` | 不合法塔不能进入参战区        |
| [ ] | S3-03 | 在战斗入口补齐最终出战校验    | `Assets/GameMain/Scripts/Procedure/`                                                             | 不满足完整条件时无法进入战斗节点   |
| [ ] | S3-04 | 给出 UI / 日志层明确反馈  | `Assets/GameMain/Scripts/UI/Game/`<br>`Assets/GameMain/Scripts/Procedure/`                       | 玩家知道为什么不能出战        |

## 阶段 S4 - 收口品质 / Tag 规则

| 状态  | ID    | 任务                      | 交付物路径                                                                                               | 验收标准           |
|-----|-------|-------------------------|-----------------------------------------------------------------------------------------------------|----------------|
| [ ] | S4-01 | 先确定 M1 需要的品质 / Tag 规则边界 | `docs/CodeX-TODO.md`<br>`docs/TODO.md`                                                              | 文档先对齐，再落代码     |
| [ ] | S4-02 | 把品质计算整理成单一入口            | `Assets/GameMain/Scripts/Definition/`<br>`Assets/GameMain/Scripts/CustomComponent/PlayerInventory/` | 组装、掉落、商店使用一致结果 |
| [ ] | S4-03 | 把 Tag 生成与过滤整理成单一入口      | `Assets/GameMain/Scripts/Definition/`<br>`Assets/GameMain/Scripts/CustomComponent/PlayerInventory/` | Tag 结果可复现且可解释  |
| [ ] | S4-04 | 补齐与数据表规则的映射关系           | `Assets/GameMain/Scripts/DataTable/`<br>`Assets/GameMain/Scripts/Definition/`                       | 表字段不是只存在而未被消费  |

## 阶段 S5 - 收口耐久规则

| 状态  | ID    | 任务                    | 交付物路径                                                                                           | 验收标准           |
|-----|-------|-----------------------|-------------------------------------------------------------------------------------------------|----------------|
| [ ] | S5-01 | 先确认 M1 是否保留完整耐久闭环     | `docs/CodeX-TODO.md`<br>`docs/TODO.md`                                                          | 范围先明确，避免边做边改目标 |
| [ ] | S5-02 | 若保留，定义耐久对属性/出战资格的影响方式 | `Assets/GameMain/Scripts/Definition/`<br>`Assets/GameMain/Scripts/Entity/`                      | 规则口径清晰且可测试     |
| [ ] | S5-03 | 实现耐久扣减后的实际生效          | `Assets/GameMain/Scripts/CustomComponent/PlayerInventory/`<br>`Assets/GameMain/Scripts/Entity/` | 耐久不再只是展示字段     |
| [ ] | S5-04 | 实现 `0` 耐久销毁或失效闭环      | `Assets/GameMain/Scripts/CustomComponent/PlayerInventory/`<br>`Assets/GameMain/Scripts/UI/`     | 归零后行为符合最终口径    |

## 阶段 S6 - 回归与文档收尾

| 状态  | ID    | 任务                      | 交付物路径                                 | 验收标准                     |
|-----|-------|-------------------------|---------------------------------------|--------------------------|
| [ ] | S6-01 | 补主链路回归测试                | `Assets/GameMain/Tests/`              | Run 推进、节点回流、Boss 完成可回归验证 |
| [ ] | S6-02 | 补规则侧测试                  | `Assets/GameMain/Tests/`              | 合法性、品质、Tag、耐久关键公式可验证     |
| [ ] | S6-03 | 回写 `docs/TODO.md` 的真实状态 | `docs/TODO.md`                        | 文档状态与仓库现状一致              |
| [ ] | S6-04 | 清理临时描述、过期 TODO、命名偏差     | `docs/`<br>`Assets/GameMain/Scripts/` | 后续推进时不再被旧口径误导            |

## 推荐执行顺序

1. 先做 `S1`，把主流程真正收成一条稳定可验收的链。
2. 再做 `S2`，把当前临时 `NodeMapForm` 收成正式节点地图表现。
3. 然后做 `S3`，补齐出战合法性，解决 `P0-10`。
4. 再做 `S4`，统一品质 / Tag 的规则口径，解决 `P0-11`。
5. 最后做 `S5`，决定耐久是完整收口还是同步缩范围，解决 `P0-12`。
6. 全部完成后做 `S6`，补测试并同步文档状态。

## 本周建议开工顺序

1. 先收 `S1-02 ~ S1-04`
2. 再收 `S2-01 ~ S2-03`
3. 然后收 `S3-01 ~ S3-04`
4. 最后再决定 `S4` 和 `S5` 是完整实现还是同步缩范围

## 备注

- 这份清单只规划补充顺序，不试图在文档里展开所有实现细节。
- 如果后续确认 M1 不做完整品质 / Tag / 耐久闭环，应先改 `docs/TODO.md`，再调整本清单。