169 lines
14 KiB
Markdown
169 lines
14 KiB
Markdown
# CodeX TODO
|
||
|
||
最后更新：2026-03-09
|
||
|
||
> 目标：基于当前仓库现状，为 `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` | 当前实现、目标状态、未完成项三者口径一致 |
|
||
| [x] | S1-02 | 收口 `ProcedureMain` 的 Run 推进主链路 | `Assets/GameMain/Scripts/Procedure/` | 从开始游戏到 Boss 结算可稳定走完整条链 |
|
||
| [x] | S1-03 | 收口节点进入、完成、失败后的统一回流 | `Assets/GameMain/Scripts/Procedure/`<br>`Assets/GameMain/Scripts/Event/` | 战斗 / 事件 / 商店都能统一推进当前 Run |
|
||
| [x] | S1-04 | 收口 Run 完成后的正式结束态 | `Assets/GameMain/Scripts/Procedure/`<br>`Assets/GameMain/Scripts/UI/Game/` | 10 节点完成后有明确的结束表现与收尾逻辑 |
|
||
|
||
## S1 验收清单
|
||
|
||
### 手工流程验收
|
||
|
||
- [x] 从主菜单进入游戏后，能进入 `ProcedureMain`，并看到 `NodeMapForm + MainForm`。
|
||
- [x] 当前节点可进入，非当前节点不可进入。
|
||
- [x] 普通战斗节点胜利后，会返回节点地图；当前节点变 `Completed`，下一节点变可进入。
|
||
- [x] 普通战斗节点在正常非胜利结算后（例如基地血量归零），会返回节点地图；当前节点仍按 `Completed` 处理，并推进到下一节点。
|
||
- [x] 战斗节点只在出现异常回退时，才会返回节点地图并把当前节点标记为 `Exception`；不会错误推进到下一节点。
|
||
- [x] 事件节点完成后，会返回节点地图，并推进到下一节点。
|
||
- [x] 商店节点退出后，会返回节点地图，并推进到下一节点。
|
||
- [x] 连续完成到第 10 个 Boss 节点后，不会再回普通 `NodeMapForm`。
|
||
- [x] Boss 完成后，会弹出正式结束对话框，而不是只停在流程内部状态。
|
||
- [x] 点击结束对话框确认后，会切回 `Menu` 场景并重新进入主菜单。
|
||
- [x] 回到主菜单后，不残留 `NodeMapForm`、`MainForm`、`DialogForm`。
|
||
|
||
### 运行时状态验收
|
||
|
||
- [x] `Hub` 阶段下，只允许当前节点进入。
|
||
- [x] `NodeActive` 阶段下，Hub UI 已关闭，不能重复从节点地图进入节点。
|
||
- [x] 普通节点成功后，会回到 `Hub`。
|
||
- [x] 节点发生异常回退后，会回到 `Hub`，但不会推进下一节点。
|
||
- [x] Boss 成功完成后，会进入 `RunCompletedPendingFinish`，并由正式结束态接管。
|
||
- [x] 正式结束态确认后，会走 `ProcedureChangeScene -> ProcedureMenu` 的回菜单链路。
|
||
|
||
### 回归测试验收
|
||
|
||
- [x] Unity Test Runner 的 `Assets/Tests/EditMode` 全部通过。
|
||
- [x] `RunState` 创建、固定序列、成功推进、异常标记相关测试全部通过。
|
||
- [x] `NodeCompleteEventArgs` 正常完成、正常非胜利、异常回退三种语义与库存快照 clone 测试全部通过。
|
||
- [x] `ProcedureMainRunFlowService` 的成功推进、异常回退、`RunCompleted`、`NoChange` 分支测试已补齐并全部通过。
|
||
- [x] `ProcedureMainRunCompletionService` 的“只弹一次结束对话框”和“只在完成态允许回菜单”测试已补齐并全部通过。
|
||
|
||
> 2026-03-09 更新：已补 `NodeCompleteEventArgs` 三种语义测试，以及 `ProcedureMain` 当前节点匹配守卫测试；你已确认本轮在 Unity Test Runner 中重新实跑 `Assets/Tests/EditMode` 且全部通过。
|
||
|
||
### S1 通过标准
|
||
|
||
- [x] 从主菜单开始，一条 Run 可以稳定经历“节点进入 -> 节点完成 / 异常回流 -> Boss 完成 -> 正式结束态 -> 返回主菜单”，且过程中不会出现错误推进、重复进入、Boss 后回到普通 Hub、或 UI 残留。
|
||
|
||
## 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 所需的节点流程界面；M1 不额外要求节点地图选择 UI 或表现层打磨。
|
||
- 战斗 / 事件 / 商店都需要统一节点进入、完成、失败后的回流方式，避免每类节点各走一套。
|
||
- 出战合法性需要从“至少有参战塔”收口为“满足完整三组件条件才可出战”。
|
||
|
||
### 仍未完成
|
||
|
||
- 出战合法性仍停留在“参与区至少有 1 座塔”的最低门槛，尚未收口为“三组件完整合法参战”。
|
||
- 品质 / Tag / 耐久在代码里已有局部实现，但还没有统一规则入口，因此仍应视为未收口项，而不是 M1 已完成项。
|
||
|
||
## 阶段 S2 - 对齐节点流程 UI 的 MVP 口径
|
||
|
||
| 状态 | ID | 任务 | 交付物路径 | 验收标准 |
|
||
|-----|-------|--------------------------------|------------------------------------|------------------------|
|
||
| [x] | S2-01 | 确认 `NodeMapForm` 已满足 M1 所需的节点流程界面 | `docs/CodeX-TODO.md`<br>`docs/TODO.md` | 不再把“正式节点地图表现”视为 M1 阻塞项 |
|
||
| [x] | S2-02 | 明确 M1 不扩展节点地图选择 UI 与表现层打磨 | `docs/CodeX-TODO.md`<br>`docs/MVP-Scope.md` | 与 `MVP-Scope.md` 的范围口径一致 |
|
||
|
||
## 阶段 S3 - 收口出战合法性
|
||
|
||
| 状态 | ID | 任务 | 交付物路径 | 验收标准 |
|
||
|-----|-------|------------------|--------------------------------------------------------------------------------------------------|--------------------|
|
||
| [x] | S3-01 | 定义“合法参战塔”的最终判定口径 | `docs/CodeX-TODO.md`<br>`Assets/GameMain/Scripts/Definition/` | 流程层与 UI 层共用同一套判定口径 |
|
||
| [x] | 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/` | 玩家知道为什么不能出战 |
|
||
|
||
### S3-01 判定口径
|
||
|
||
- `S3-01` 只收口 M1 所需的最小合法参战规则：塔实例存在，且能解析到枪口 / 轴承 / 底座三个组件实例。
|
||
- 当前阶段不把品质、Tag、耐久、属性强度纳入“合法参战塔”定义；这些仍分别留在 `S4`、`S5` 收口。
|
||
- 流程层、库存层、UI 层后续都必须共用同一个判定入口，不能再分别维护“至少有塔”“参战区非空”“组件看起来完整”这类分散判断。
|
||
- 判定结果不能只返回 `bool`，还要能区分至少以下失败原因：塔不存在、缺枪口、缺轴承、缺底座。
|
||
- 批量校验参战区时，需要同时给出“合法参战塔列表”“非法参战塔及原因”“是否至少存在一座合法参战塔”三个结果，供 `S3-02 ~ S3-04` 直接复用。
|
||
|
||
> 2026-03-09 更新：`CombatParticipantTowerValidationService`、`CombatParticipantTowerValidationResult`、`CombatParticipantTowerValidationSummary` 已落地；Unity Test Runner 已确认相关 EditMode 测试通过。
|
||
|
||
### S3-02 当前落地状态
|
||
|
||
- 参战分配链路已统一改为返回结果对象，而不是只返回 `bool`。
|
||
- `RepoFormUseCase`、`PlayerInventoryComponent`、`PlayerInventoryTowerRosterService`、`InventoryParticipantUtility` 已接入 `S3-01` 的统一合法性校验入口。
|
||
- 当前可稳定区分以下分配失败原因：塔不存在、塔缺少三组件之一、已在参战区、参战区已满。
|
||
- 组装区 / 参战区 UI 仍保持“失败时静默拦截”的当前策略，但日志链路已经能拿到明确失败原因，后续 `S3-04` 可直接复用。
|
||
- 当前阶段仍未在战斗入口做最终出战前二次校验，这部分继续归 `S3-03`。
|
||
|
||
> 2026-03-09 更新：你已在 Unity Test Runner 中确认 `Assets/Tests/EditMode` 全部通过，其中包含 `CombatParticipantTowerValidationServiceTests` 与 `ParticipantTowerAssignResultTests`。
|
||
|
||
## 阶段 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` 不再作为 M1 阻塞项。
|
||
3. 接下来优先做 `S3`，补齐出战合法性，解决 `P0-10`。
|
||
4. 再做 `S4`，统一品质 / Tag 的规则口径，解决 `P0-11`。
|
||
5. 最后做 `S5`，决定耐久是完整收口还是同步缩范围，解决 `P0-12`。
|
||
6. 全部完成后做 `S6`，补测试并同步文档状态。
|
||
|
||
## 本周建议开工顺序
|
||
|
||
1. `S1` 与 `S2` 已完成口径收口，可直接进入规则侧收尾
|
||
2. `S3-01`、`S3-02` 已完成，接下来先收 `S3-03`、`S3-04`
|
||
3. 再决定 `S4` 和 `S5` 是完整实现还是同步缩范围
|
||
4. 最后补 `S6-01 ~ S6-04`
|
||
|
||
## 备注
|
||
|
||
- 这份清单只规划补充顺序，不试图在文档里展开所有实现细节。
|
||
- 如果后续确认 M1 不做完整品质 / Tag / 耐久闭环，应先改 `docs/TODO.md`，再调整本清单。
|