basil
/
geometry-tower-defense
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
geometry-tower-defense/docs/CodeX-TODO.md

296 lines
32 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# CodeX TODO
最后更新：2026-03-10
> 目标：基于当前仓库现状，为 `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/` | 不合法塔不能进入参战区 |
| [x] | S3-03 | 在战斗入口补齐最终出战校验 | `Assets/GameMain/Scripts/Procedure/` | 不满足完整条件时无法进入战斗节点 |
| [x] | 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-02` 直接进入战斗。
- 战斗入口校验失败时，`ProcedureMain` 现在会同时写明失败日志，并弹出 `DialogForm` 给出明确原因；空参战区会提示“至少需要 1 座完整装配了枪口、轴承、底座的塔”，脏数据则会列出具体缺失组件。
> 2026-03-09 更新：你已在 Unity Test Runner 中确认 `Assets/Tests/EditMode` 全部通过，其中包含 `CombatParticipantTowerValidationServiceTests` 与 `ParticipantTowerAssignResultTests`。
>
> 2026-03-09 更新：`ProcedureMainCombatEntryValidationService` 与战斗入口拦截已落地；你已确认 Unity Test Runner 全部通过，并手工验证了“空参战区开始战斗”会被拦截且弹出明确提示。
## 阶段 S4 - 收口品质 / Tag 规则
| 状态 | ID | 任务 | 交付物路径 | 验收标准 |
|-----|-------|-------------------------|--------------------------------------------------------------------------------------------------------------------------------------|-----------------------------|
| [x] | S4-01 | 先确定 M1 需要的品质 / Tag 规则边界 | `docs/CodeX-TODO.md`<br>`docs/TODO.md` | 文档先对齐，再落代码 |
| [x] | S4-02 | 把品质计算整理成单一入口 | `Assets/GameMain/Scripts/Definition/`<br>`Assets/GameMain/Scripts/CustomComponent/PlayerInventory/` | 组装、掉落、商店使用一致结果 |
| [x] | S4-03 | 先固化 Tag 系统设计与首发范围 | `docs/TagSystemDesign.md`<br>`docs/CodeX-TODO.md` | Tag 的来源、汇总、生效与首发集合口径固定 |
| [x] | S4-04 | 实现组件实例 Tag 的统一生成入口 | `Assets/GameMain/Scripts/Definition/`<br>`Assets/GameMain/Scripts/CustomComponent/PlayerInventory/` | 掉落、商店、初始种子、事件奖励共用同一生成结果 |
| [x] | S4-05 | 实现组塔后的 Tag 汇总与展示入口 | `Assets/GameMain/Scripts/Definition/`<br>`Assets/GameMain/Scripts/CustomComponent/PlayerInventory/`<br>`Assets/GameMain/Scripts/UI/` | 组件 Tag 可汇总为塔级结果，且 UI 展示口径一致 |
| [x] | S4-06 | 实现首批基础 Tag 的战斗生效 | `Assets/GameMain/Scripts/Entity/`<br>`Assets/GameMain/Scripts/Components/`<br>`Assets/GameMain/Scripts/Definition/` | 首发 6~8 个基础 Tag 至少完成一批可验证效果，且战斗入口与状态运行时结构可继续扩展 |
| [~] | S4-07 | 补齐 Tag 规则与数据表的映射关系 | `Assets/GameMain/Scripts/DataTable/`<br>`Assets/GameMain/Scripts/Definition/` | 表字段不是只存在而未被消费，Tag 参数可配置可解释 |
> 2026-03-09 更新：`InventoryRarityRuleService` 已落地；塔品质计算与组件品质归一化已统一收口，`PlayerInventoryTowerAssemblyService`、`ShopFormUseCase`、`EnemyDropResolver`、`InventorySeedUtility` 已接入同一规则入口。你已确认 Unity Test Runner 中 `Assets/Tests/EditMode` 全部通过，其中包含新增的 `InventoryRarityRuleServiceTests`。
>
> 2026-03-09 更新：`S4-03` 文档口径已冻结；`TagSystemDesign.md` 已明确组件实例生成、塔级 `Stack` 汇总、四段触发阶段、`Tag.txt + TagRule` 双表方向，以及 MVP 正式首发 7 个 Tag：`Fire`、`Ice`、`Crit`、`Execution`、`Shatter`、`Inferno`、`AbsoluteZero`。`BurnSpread` 已明确后移。
>
> 2026-03-09 更新：`S4-04` 已落地 `ComponentTagGenerationService` 与 `InventoryTagSourceType`；组件实例 Tag 现在统一按 `PossibleTag + Tag.txt.MinRarity + 品质预算` 生成，并只保留当前正式首发 7 个 Tag。`ShopFormUseCase`、`EnemyDropResolver`、`InventorySeedUtility` 已接入该入口，样例库存的组件与塔展示 Tag 已同步为统一结果；同时新增 `ComponentTagGenerationServiceTests`。当前 CLI 下 `dotnet build GeometryTD.sln` 仍因本机缺少 Unity 引用和 `Unity.SourceGenerators*.dll` 失败，未能替代 Unity Test Runner 完成最终验证。
>
> 2026-03-09 更新：`S4-05` 已新增 `TagRuntimeData` 与 `TowerTagAggregationService`；组塔与样例塔现在统一生成塔级 `TagRuntimes`，并保留兼容 `Tags` 投影。`RepoForm`、`CombatFinishForm`、`ItemDescForm` 的塔展示已切到聚合结果，重复 Tag 以 `xN` 文本显示；组件展示仍沿用组件实例 `Tags`。同时新增 `TowerTagAggregationServiceTests`；本轮改动后的最终验证仍以 Unity Test Runner 实跑结果为准。
>
> 2026-03-10 更新：`S4-06` 已完成第一段落地。战斗链现在已从旧的 `damage + AttackPropertyType` 入口提升为携带 `TagRuntimeData[]` 的命中载荷；`AttackPayload`、`HitContext`、`TagEffectResolver`、`EnemyTagStatusRuntime` 已接入主命中链。当前已实际生效的基础 Tag 为 `Fire`、`Ice`、`Crit`、`Execution`：其中 `Fire` 已改为独立 DOT 公式，并按 `EnemyEntity` 每帧提供的 `deltaTime` 连续结算；`Ice` 已有独立减速状态；`Crit` 与 `Execution` 已进入命中前数值修正。状态类 Tag 已按“每个 Tag 各自配置文件、状态文件、效果文件”的方式拆开，`EnemyTagStatusRuntime` 只负责按激活 Tag 动态 Tick，不再持有具体 Tag 字段。
>
> 2026-03-10 更新：`S4-06` 已补齐首发剩余 3 个 Tag。`Shatter` 已接入命中前数值修正链，并按“目标已减速”口径增伤；`Inferno` 与 `AbsoluteZero` 已按首发方案作为 `Fire` / `Ice` 的强化 Tag 落地，分别增强 DOT 时长/伤害与减速时长/强度；对应 EditMode 测试已同步补齐。`BurnSpread`、`IgniteBurst`、`FreezeMask`、`Pierce`、`Overpenetrate` 仍保持分类与占位路由，没有实际战斗效果，因此仍属于后续扩展，不计入 `S4-06` 当前完成标准。
>
> 2026-03-10 更新：`S4-07` 仍未开始正式收口。当前 Tag 参数仍主要承载在代码侧 `TagDefinitionRegistry` 与各 Tag 配置类中，`Tag.txt` / DataTable 仍只提供基础字典与 `MinRarity` 输入；文档中约定的 `TagRule` 表、触发阶段、权重、效果参数等尚未形成 DataRow 与运行时消费闭环。因此 `S4-07` 继续保持未完成状态。
>
> 2026-03-11 更新：`S4-07` 已进入第一阶段实现。当前已新增 `TagConfig.txt` 与 `DRTagConfig`，`ProcedurePreload` 会在加载 `TagConfig` 表后驱动 `TagDefinitionRegistry.LoadFromRows(...)`，把 `TriggerPhase`、`Description` 以及首发 7 个 Tag 的配置参数从表覆盖到运行时强类型 `TagConfig`。`ItemDescForm` 也已开始消费该配置说明；塔详情会优先使用 `TagRuntimes` 构建 `Ice x2` 这类叠层展示。因此 `S4-07` 不再是“完全未开始”，但当前仍只完成了 `TagConfig` 级别的参数映射与 UI 消费，尚未把文档中的完整 `TagRule`（如权重、生成规则等）全部收口。
>
> 2026-03-11 更新：`S4-07` 已继续推进到第二阶段。当前 `Tag.txt -> DRTag -> TagGenerationRuleRegistry` 已形成组件 Tag 生成规则闭环，`ComponentTagGenerationService` 不再主要依赖内部 `MinRarity` 硬编码，而是统一消费 `DRTag` 提供的 `MinRarity + Weight`；`ShopFormUseCase`、`EnemyDropResolver`、`InventorySeedUtility` 也已切回这一统一入口。现阶段的职责边界明确为：`Tag.txt` 负责基础字典与生成规则，`TagConfig.txt` 负责触发阶段、描述与效果参数。
>
> 2026-03-11 补充验证：已通过手工扩充组件 `PossibleTag` 候选池并调整 `Weight` 验证生成权重实际生效；同时把所有 Tag 的 `MinRarity` 提升到 `Red` 后，低品质组件不再生成任何 Tag，说明 `Tag.txt` 中的 `MinRarity` 与 `Weight` 均已进入统一生成链。
### S4-01 边界结论
- `S4-01` 只收口 M1 所需的最小规则闭环：先统一“品质如何算、Tag 如何生成/过滤、哪些链路必须共用同一结果”，当前阶段不要求 Tag 立即产生战斗效果。
- 品质在当前仓库中不是空白功能：组件实例已有 `Rarity` 字段，掉落、商店、初始种子都已能给组件实例赋品质；塔组装时也已有“三组件品质取平均并四舍五入”的现有实现。
- M1 对品质的目标口径是：塔品质必须由枪口 / 轴承 / 底座三个组件品质决定，且结果在组装、掉落、商店、展示、事件条件筛选等链路中可复现、可解释、口径一致。
- M1 当前不把“品质决定配件槽位数量”视为阻塞项；配件系统本体尚未进入主链路，这部分仍保留在后续深度阶段，而不是作为 `S4-01` 当下必须落地的规则。
- Tag 在当前仓库中也不是空白功能：组件表已有 `PossibleTag`，实例数据与展示链路也已有 `Tags` 字段与名称展示，但现在更接近“静态拷贝 + 展示消费”，还没有统一生成 / 过滤入口。
- M1 对 Tag 的目标口径是：Tag 结果必须有统一来源，且在组装、掉落、商店、展示链路中可复现、可解释；不能再继续分散为“哪边方便哪边直接复制 `PossibleTag`”。
- `Tag.txt` 的 `MinRarity` 与三张组件表的 `PossibleTag` 都应视为 `S4-03 ~ S4-04` 的规则输入，而不是已经被完整消费的既成事实；当前文档必须明确这一点，避免误判为“表字段已落地”。
- 设计稿中的深度规则暂不纳入 M1 必收口范围：不要求现在就实现按品质随机 Tag 数量、不要求实现 Tag 等级成长，也不要求实现 Tag 的战斗数值效果。
### S4 拆分方案
- `S4-02` 只处理品质入口统一，不与 Tag 生成细节耦合；目标是把“塔品质计算、组件品质输入、展示品质”都收口到统一规则服务。
- `S4-03` 对应 `docs/TagSystemDesign.md` 的文档收口阶段：固定 Tag 的候选池、实例生成时机、组塔汇总方式、战斗触发阶段、以及 MVP 正式首发 7 个基础 Tag 的集合。
- `S4-04` 是 Tag 系统的第一段代码落地：为组件实例引入统一的 Tag 生成入口，不再直接复制 `PossibleTag` 全量候选；掉落、商店、初始种子、事件奖励必须共用同一套生成逻辑与随机口径。
- `S4-05` 负责把三组件 Tag 汇总为塔级结果，并统一背包、组装、商店、详情面板的展示口径；此阶段不要求完成全部战斗效果，但不能再停留在“简单并集去重”的临时实现上。
- `S4-06` 只落首批基础 Tag 的战斗效果，不一次展开全部 12 个 Tag；优先级按 `TagSystemDesign.md` 收口为状态类和数值修正类，例如 `Fire`、`Ice`、`Crit`、`Execution`、`Shatter`、`Inferno`、`AbsoluteZero`。
- `S4-07` 负责把 Tag 设计真正映射回数据表与 DataRow，不再只保留 `MinRarity` 与 `PossibleTag` 两个弱约束字段；至少要支持权重、触发阶段、说明或效果参数中的一部分配置化消费。
### S4-03 首发范围结论
- MVP 首发 Tag 总量仍受 `docs/MVP-Scope.md` 的 `6~8` 个约束，但当前正式首发集合已固定为 7 个。
- 首批优先做状态类与数值修正类，不优先做穿透、传播、爆炸、多命中等高侵入效果。
- 当前正式首发基础集合为：`Fire`、`Ice`、`Crit`、`Execution`、`Shatter`、`Inferno`、`AbsoluteZero`。
- `BurnSpread`、`Pierce`、`Overpenetrate`、`FreezeMask`、`IgniteBurst` 默认放到后续扩展阶段，不作为 `S4` 当前完成标准。
### S4 当前进度结论（2026-03-10）
- `S4-02 ~ S4-05` 已完成，品质、组件实例 Tag 生成、塔级 `TagRuntimeData` 汇总、以及 UI 展示口径都已收口。
- `S4-06` 已完成：战斗链已支持 Tag 透传与统一结算，正式首发 7 个 Tag `Fire`、`Ice`、`Crit`、`Execution`、`Shatter`、`Inferno`、`AbsoluteZero` 均已有可验证效果。
- `Shatter` 已接入命中前数值修正链；`Inferno`、`AbsoluteZero` 已按“强化现有 `Fire` / `Ice` 状态”的首发口径落地，状态类 Tag 的内部结构继续保持注册式运行时。
- `BurnSpread`、`IgniteBurst`、`FreezeMask`、`Pierce`、`Overpenetrate` 已进入分类与配置骨架，但仍属于后续扩展，不计入当前 `S4` 的完成标准。
- `S4-07` 已进入第一阶段实现。当前仓库已具备 `TagConfig.txt -> DRTagConfig -> TagDefinitionRegistry -> ItemDescForm` 的消费闭环，首发 7 个 Tag 的触发阶段、描述与核心参数已可由表覆盖。
- `S4-07` 已推进到第二阶段。当前仓库同时具备 `Tag.txt -> DRTag -> TagGenerationRuleRegistry -> ComponentTagGenerationService` 与 `TagConfig.txt -> DRTagConfig -> TagDefinitionRegistry -> ItemDescForm` 两条消费闭环，首发 7 个 Tag 的生成规则、触发阶段、描述与核心参数都已开始由表驱动。
- `S4-07` 已推进到第三阶段。当前仓库新增 `RarityTagBudget.txt -> DRRarityTagBudget -> RarityTagBudgetRuleRegistry -> ComponentTagGenerationService`，组件 Tag 数量预算不再写死在 `ResolveRarityTagBudget(...)` 的 `switch` 中，而是按品质从表驱动；至此生成链的候选过滤、权重抽取、数量预算三段都已进入 DataTable 消费闭环。
- `S4-07` 仍未完成最终收口。当前采用的是 `Tag.txt + RarityTagBudget.txt + TagConfig.txt` 的分层方案，而不是文档原方案里的单独 `TagRule`；更深的元数据字段与完整命名口径仍待后续决定是否继续统一。
### S4-06 当前代码状态
- 命中链路已统一为 `AttackPayload -> HitContext -> TagEffectResolver`，子弹命中时不再只传裸 `damage`。
- `Tower` 侧的 `TagRuntimes` 已能透传到战斗，且保留了旧 `Tags -> TagRuntimes` 的兼容入口，避免旧塔或旧展示数据在战斗中完全失效。
- 状态类 Tag 现在按职责目录拆分：
- `Metadata/Config`：每个 Tag 一个配置类
- `Combat/States`：每个状态类 Tag 一个运行时状态类
- `Combat/StatusEffects`：每个状态类 Tag 一个效果类
- `EnemyTagStatusRuntime` 已不再硬编码 `burn/slow` 字段，而是按激活的状态类 Tag 动态调度 Tick。
- `Fire` 已改为独立 DOT 公式：当前使用独立 `BurnDamagePerSecondPerStack`，并按敌人实体每帧提供的 `deltaTime` 连续结算，不再依赖命中伤害或内部 `TickInterval`。
- `Ice` 仍是独立减速状态，移速倍率通过状态运行时聚合得到。
- `Crit`、`Execution`、`Shatter` 已通过数值修正链路生效；`Shatter` 当前按“目标已减速时增伤”收口。
- `Inferno` 与 `AbsoluteZero` 已不再是独立状态效果，而是分别在 `Fire` / `Ice` 生效时读取同次命中的强化 Tag 层数，增强 DOT 时长/伤害与减速时长/强度。
### S4 后续执行计划
1. 继续推进 `S4-07`：在现有 `Tag.txt + RarityTagBudget.txt + TagConfig.txt` 分层方案基础上，决定是否补成文档中的完整 `TagRule`，或明确当前三表就是本阶段的等价收口方案。
2. `S4-07` 完成标准仍以“表字段被实际消费、参数可解释、运行时与文档口径一致”为准；当前已完成首发 7 个 Tag 的生成规则、数量预算、参数和说明配置化，后续重点转向是否还要继续配置化更深层的元数据字段。
3. `BurnSpread`、`IgniteBurst`、`FreezeMask`、`Pierce`、`Overpenetrate` 继续留在后续扩展阶段，不因为 `S4-06` 完成而提前进入当前迭代。
## 阶段 S5 - 收口耐久规则
| 状态 | ID | 任务 | 交付物路径 | 验收标准 |
|-----|-------|-----------------------|-------------------------------------------------------------------------------------------------|----------------|
| [x] | S5-01 | 先确认 M1 是否保留完整耐久闭环 | `docs/CodeX-TODO.md`<br>`docs/TODO.md` | 已明确按“最小耐久闭环”推进，不扩展维修/折价/自动销毁 |
| [x] | S5-02 | 若保留，定义耐久对属性/出战资格的影响方式 | `Assets/GameMain/Scripts/Definition/`<br>`Assets/GameMain/Scripts/Entity/` | 已统一为“归零失效、不可参战、非归零不衰减” |
| [x] | S5-03 | 实现耐久扣减后的实际生效 | `Assets/GameMain/Scripts/CustomComponent/PlayerInventory/`<br>`Assets/GameMain/Scripts/Entity/` | 已按“每场固定扣 1、仅扣本场参战塔”接进主链 |
| [x] | S5-04 | 实现 `0` 耐久失效闭环 | `Assets/GameMain/Scripts/CustomComponent/PlayerInventory/`<br>`Assets/GameMain/Scripts/UI/` | 已实现失效不可参战、仓库提示、节点结束后自动踢出参战区 |
### S5 规划结论
- `S5` 当前按“最小耐久闭环”推进，不展开维修、折价、复杂恢复、耐久与 Tag 联动等后续深度系统。
- M1 保留耐久规则，但当前目标只收口到“战斗后真实扣减 + 归零后真实失效 + UI 可解释”，不要求一并实现完整维修玩法。
- 本阶段优先保证耐久从展示字段变成实际规则入口，而不是继续增加额外经济系统或复杂数值衰减。
- `S5-01 ~ S5-04` 当前代码口径已完成：战斗后会真实扣减本场参战塔耐久，`0` 耐久会拦截参战与战斗入口，仓库详情会显示损坏状态，节点结束后会自动把损坏塔移出参战区并弹提示。
### S5-01 范围结论
- `S5-01` 建议明确保留耐久闭环，但只做组件实例级耐久，不新开修理站、维修货币、商店修复等额外系统。
- 当前阶段只处理战斗节点的耐久消耗；事件、商店、其他特殊节点暂不引入额外耐久变更。
- `0` 耐久当前建议先按“失效但不立即销毁实例”收口，避免在本阶段同时引入背包移除、组装解绑、自动清空参战区等高耦合逻辑。
### S5-02 推荐规则口径
- 耐久数据仍挂在组件实例上，塔本身不额外维护独立耐久池。
- 一座塔只要已装配的枪口 / 轴承 / 底座中任意一个组件耐久 `<= 0`，就视为损坏塔。
- 损坏塔不能进入参战区，也不能通过战斗入口最终校验。
- 当前阶段不实现“耐久越低属性越差”的连续衰减；在 `> 0` 耐久时，组件与塔仍按当前属性正常工作。
- 当前阶段不把耐久纳入品质、Tag、掉落或商店价格公式，避免把 `S5` 扩成新的综合规则层。
### S5-03 推荐实现口径
- 每次战斗节点结算后，对本场实际参战塔所装配的三个组件各扣 `1` 点耐久。
- 扣减结果必须真实回写到库存快照 / 当前 Run 库存，而不是只改战斗内临时对象。
- 参战合法性统一复用现有校验入口扩展，不额外再造一套“耐久专用判断链”。
- 战斗入口仍需要保留最终二次校验，避免旧快照或外部改动绕过组装区 / 参战区限制。
- 当前仓库实现已经按此口径落地：不再沿用旧的“低血量才扣耐久、且扣全库存塔”的逻辑。
### S5-04 推荐闭环口径
- 组件耐久归零后，当前版本按“失效不可参战”收口，不立即自动销毁实例。
- 装配了 `0` 耐久组件的塔在 UI 上需要给出明确提示，例如“组件已损坏”或“耐久为 0，无法参战”。
- 若塔已在参战区且组件在上一场战斗后归零，需要在后续刷新中把该塔视为非法参战塔，并通过统一校验入口阻止再次进入战斗。
- “自动销毁组件”与“自动拆塔”保留到后续阶段再决定，当前不作为 `S5` 通过标准。
- 当前仓库实现已经进一步收口：节点结束时会自动检查损坏参战塔，将其移出 `ParticipantTowerInstanceIds`，并通过 `DialogForm` 明确提示玩家。
- Boss 完成导致 Run 正式结束时，仍会执行损坏塔清理；但当前不会额外插入第二个耐久提示弹窗去覆盖“Run 完成”弹窗。
### S5 当前结论
1. `S5-01 ~ S5-04` 已按当前 M1 口径完成，不再作为 `P0-12` 的主阻塞项。
2. 当前未实现的是长期设计里的维修、自动销毁、耐久折价、连续属性衰减，这些后续若要恢复，应作为新的增强项重新拆分，而不是回滚当前 MVP 口径。
## 阶段 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`。其中当前优先级已经收口为：`S4-06` 已完成，下一步转入 `S4-07` 的数据表映射。
5. `S5` 已按当前 M1 口径完成，后续重点转入 `S6` 的测试补强与文档收尾。
6. 在 `S6` 收尾后，再决定是否把维修、自动销毁、耐久折价等长期设计拆成新的增强阶段。
## 本周建议开工顺序
1. `S1` 与 `S2` 已完成口径收口，可直接进入规则侧收尾
2. `S3-01 ~ S3-04` 已完成，当前可转入 `S4`
3. 当前先完成 `S4-07` 的三表口径收口，并把 `Tag.txt` / `TagConfig.txt` / `RarityTagBudget.txt` 的实际消费链稳定下来
4. `S5-01 ~ S5-04` 已按“最小耐久闭环”落地，当前无需再按旧 TODO 继续拆这部分
5. 最后补 `S6-01 ~ S6-04`
## 备注
- 这份清单只规划补充顺序，不试图在文档里展开所有实现细节。
- 如果后续确认 M1 不做完整品质 / Tag / 耐久闭环，应先改 `docs/TODO.md`，再调整本清单。
Reference in New Issue View Git Blame Copy Permalink