113 lines
9.5 KiB
Markdown
113 lines
9.5 KiB
Markdown
# 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`，再调整本清单。
|