9.5 KiB
9.5 KiB
CodeX TODO
最后更新：2026-03-08
目标：基于当前仓库现状，为
docs/TODO.md的 M1 收口补一份更可执行的补充顺序。 原则：先收主流程，再补硬规则，最后统一文档与验收口径。
执行规则
- 优先完成会阻塞 M1 验收的内容，不提前展开 M2 深度功能。
- 每一项先收“流程可走通”，再收“规则完整”，最后再做表现层补齐。
ProcedureMain + NodeMapForm + PlayerInventory + CombatNode视为当前主链路，后续补充都围绕这条链路推进。
阶段 S1 - 收口主流程
| 状态 | ID | 任务 | 交付物路径 | 验收标准 |
|---|---|---|---|---|
| [x] | S1-01 | 统一梳理 M1 当前状态与文档口径 | docs/CodeX-TODO.mddocs/TODO.md |
当前实现、目标状态、未完成项三者口径一致 |
| [ ] | S1-02 | 收口 ProcedureMain 的 Run 推进主链路 |
Assets/GameMain/Scripts/Procedure/ |
从开始游戏到 Boss 结算可稳定走完整条链 |
| [ ] | S1-03 | 收口节点进入、完成、失败后的统一回流 | Assets/GameMain/Scripts/Procedure/Assets/GameMain/Scripts/Event/ |
战斗 / 事件 / 商店都能统一推进当前 Run |
| [ ] | S1-04 | 收口 Run 完成后的正式结束态 | Assets/GameMain/Scripts/Procedure/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.mdAssets/GameMain/Scripts/Definition/ |
流程层与 UI 层共用同一套判定口径 |
| [ ] | S3-02 | 收口组装区与参战区的合法性校验 | Assets/GameMain/Scripts/UI/Game/Assets/GameMain/Scripts/CustomComponent/PlayerInventory/ |
不合法塔不能进入参战区 |
| [ ] | S3-03 | 在战斗入口补齐最终出战校验 | Assets/GameMain/Scripts/Procedure/ |
不满足完整条件时无法进入战斗节点 |
| [ ] | S3-04 | 给出 UI / 日志层明确反馈 | Assets/GameMain/Scripts/UI/Game/Assets/GameMain/Scripts/Procedure/ |
玩家知道为什么不能出战 |
阶段 S4 - 收口品质 / Tag 规则
| 状态 | ID | 任务 | 交付物路径 | 验收标准 |
|---|---|---|---|---|
| [ ] | S4-01 | 先确定 M1 需要的品质 / Tag 规则边界 | docs/CodeX-TODO.mddocs/TODO.md |
文档先对齐，再落代码 |
| [ ] | S4-02 | 把品质计算整理成单一入口 | Assets/GameMain/Scripts/Definition/Assets/GameMain/Scripts/CustomComponent/PlayerInventory/ |
组装、掉落、商店使用一致结果 |
| [ ] | S4-03 | 把 Tag 生成与过滤整理成单一入口 | Assets/GameMain/Scripts/Definition/Assets/GameMain/Scripts/CustomComponent/PlayerInventory/ |
Tag 结果可复现且可解释 |
| [ ] | S4-04 | 补齐与数据表规则的映射关系 | Assets/GameMain/Scripts/DataTable/Assets/GameMain/Scripts/Definition/ |
表字段不是只存在而未被消费 |
阶段 S5 - 收口耐久规则
| 状态 | ID | 任务 | 交付物路径 | 验收标准 |
|---|---|---|---|---|
| [ ] | S5-01 | 先确认 M1 是否保留完整耐久闭环 | docs/CodeX-TODO.mddocs/TODO.md |
范围先明确，避免边做边改目标 |
| [ ] | S5-02 | 若保留，定义耐久对属性/出战资格的影响方式 | Assets/GameMain/Scripts/Definition/Assets/GameMain/Scripts/Entity/ |
规则口径清晰且可测试 |
| [ ] | S5-03 | 实现耐久扣减后的实际生效 | Assets/GameMain/Scripts/CustomComponent/PlayerInventory/Assets/GameMain/Scripts/Entity/ |
耐久不再只是展示字段 |
| [ ] | S5-04 | 实现 0 耐久销毁或失效闭环 |
Assets/GameMain/Scripts/CustomComponent/PlayerInventory/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/Assets/GameMain/Scripts/ |
后续推进时不再被旧口径误导 |
推荐执行顺序
- 先做
S1，把主流程真正收成一条稳定可验收的链。 - 再做
S2，把当前临时NodeMapForm收成正式节点地图表现。 - 然后做
S3，补齐出战合法性，解决P0-10。 - 再做
S4，统一品质 / Tag 的规则口径，解决P0-11。 - 最后做
S5，决定耐久是完整收口还是同步缩范围，解决P0-12。 - 全部完成后做
S6，补测试并同步文档状态。
本周建议开工顺序
- 先收
S1-02 ~ S1-04 - 再收
S2-01 ~ S2-03 - 然后收
S3-01 ~ S3-04 - 最后再决定
S4和S5是完整实现还是同步缩范围
备注
- 这份清单只规划补充顺序，不试图在文档里展开所有实现细节。
- 如果后续确认 M1 不做完整品质 / Tag / 耐久闭环，应先改
docs/TODO.md，再调整本清单。