docs(shop): 货架 C Task 6 运行时验收 + 权威文档补录 + 计划回填
17 条验收标准 + Task 3 遗留的回读顺序风险全部运行时实测通过（FAILS=0）， 无代码改动。发现简报三处脚本不可用并替换/补充：Step 1 阳性对照改用 add_modifier 未知属性守卫；新增 Step 5b 补前序评审「磁盘往返未独立复核」； Step 6/7 原脚本经排查为空断言，改用真实红/绿对照场景。 numerical_design.md §1.1/§1.2 补录属性购买消耗与 cast_delay_mod 的 soft 约束说明；路线图 E3 第 2 项勾除完成。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Claude Opus 5
@@ -96,7 +96,9 @@ E6-a 玩家无敌帧(i-frames) ← 先行小项：Boss 弹幕公平性前置，
|
||||
- `recharge_speed_mod` —— 代码中**不存在充能系统**（全项目 grep `recharge` 零命中），属新增机制而非断线。
|
||||
- 另：`mana_max` 的「与法杖取 Min」语义（权威 §1.1）未迁入框架，现状是核心值直接覆盖玩家值；那是独立设计判断，记为已知遗留。
|
||||
- ✅ **`cast_delay_mod` 的饱和区问题已处理（`hard: 0.01 → 0.05`，提交 `ba7c885`，决定已关闭）**：`_handle_auto_cast` 用 `if` 而非 `while`，每物理帧至多一次施法 → 60 次/秒硬顶，实际速率按**整帧量化**，故饱和点 = `(1/60) / 法杖基准间隔`（`circuit_fork` 0.0278 / `wand_basic` 0.0333 / `wand_fast` 0.0667）。原 `hard: 0.01` 远在所有杖的饱和点之下，从饱和点买到 0.01 射速纹丝不动。因饱和点随杖而异、不存在对所有杖都最优的单一 `hard`，取 0.05 为折中：`wand_basic` / `circuit_fork` 无无效区间，`wand_fast` 仍剩 `[0.05, 0.0667)`（较原来的 6.7 倍缩至 1.33 倍）。完整实测数据集见 `docs_dev/specs/2026-07-31-player-attributes-design.md` §2.2b。若日后要把 `wand_fast` 那段也消掉，正确做法是让 `hard` **逐杖化**（挪进 `cores.json`）而非继续挪这个全局数 —— 属独立立项，**不是本期遗留待办**。
|
||||
2. **货架 C（属性购买）**：商店可购属性词条（消耗金币/以太），叠加到 PlayerStats。S~M。
|
||||
2. ~~**货架 C（属性购买）**~~ ✅ **完成**（2026-07-31，`feat/shelf-c-attribute-shop`；spec/plan `docs_dev/{specs,plans}/2026-07-31-shelf-c-attribute-shop*`）：`PriceFormula` 纯静态定价模块（`geometric`/`linear`/`flat` 三曲线，`class_name` 零依赖，可脱离游戏进程单测，风格对齐 `AttributeFormula`）；`ShopManager` 新增货架 C 状态（`_attr_purchases` 唯一写入点 `_apply_attr_purchases()` 重建加成，来源常量 `MOD_SOURCE_SHOP_C="shop_c"`）；`attributes.json` 逐属性加 `shop` 段（`mode`/`step`/`price_base`/`price_growth`/`curve`）驱动可售集合与定价，**无 `shop` 段即不可售**（数据驱动，加属性零代码，运行时实测：注入无 `shop` 段的合成属性会被正确排除）；`ProfileManager` schema 2→3 新增 `attr_purchases` 持久化，`apply_run()` 顺序为**先 `ShopManager.apply_attr_purchases_save` 后 `PlayerStats.load_save_data`**（颠倒会在"已有历史购买"场景下吞血，运行时实测复现：错误顺序丢 30 HP、正确顺序不丢）；商店 UI 新增「📊 属性」按钮打开独立子面板（原计划设想内联在商店面板，实测面板仅余 18px 放不下，改独立子面板）；设计器「属性」页扩展 `shop` 五字段编辑。
|
||||
- ⚠️ **实际范围**：仅落地 `attributes.json` 现有的 4 个框架内属性（`hp_max`/`move_speed`/`cast_delay_mod`/`cpu_limit`）。E3-① 延后的 B 类 7 个属性（`attunement_*` ×4、`luck`、`recharge_speed_mod`、`mana_max` 的 Min 语义）仍待各自前置（暴击链、充能系统、元素伤害管线等）解除后才有意义可买；届时只需给对应属性加 `shop` 段即可上架，**零代码**（`get_sellable_attrs()` 按 `shop` 段存在性筛选，已运行时验证）。
|
||||
- ✅ **`cast_delay_mod` 的 soft 上限验证**：三个饱和点（`wand_basic` 0.0333 等）全部低于货架购买软上限 `soft`(0.1)，常规购买够不到饱和区。运行时实测买到 `soft` 需 22 次购买，此时帧距仍为 3 帧（未饱和），证明 `soft` 才是玩家实际能碰到的约束。
|
||||
3. **货架 B（核心抽取）**：商店提供 Core 抽取/更换（复用 `_CORE_ROSTER`），与现有换杖打通。S~M。
|
||||
4. **出售退款 G5**：背包内法术/核心可出售，按 `numerical` 退款比例返还货币。S。
|
||||
|
||||
|
||||
@@ -783,13 +783,43 @@ EOF
|
||||
|
||||
**Files:** 无（运行时断言）+ `docs/design/numerical_design.md` + 路线图 + 本计划
|
||||
|
||||
- [ ] **Step 1: 启动战斗场景**
|
||||
> **回填说明（本节全部为 Task 6 实际执行版，2026-08-03）**：简报里的 `ShopManager.buy_attribute("不存在的属性")` 作为阳性对照**不可用**——`buy_attribute` 对未知 id 走的是 `can_buy_attribute` 的字符串「禁用原因」分支（`"该属性不可购买"`），不触发 `push_error`，不会出现在错误通道里，会误判「阳性对照已确认」。改用 `PlayerStats.add_modifier("不存在的属性xyz", "flat", 1.0, "probe_unknown_attr")`，它经 `add_modifier` 的未知 `attr_id` 守卫真实 `push_error`。以下各 Step 均为实测脚本与实测输出，非简报原样照抄。
|
||||
|
||||
Run: godot-mcp-pro `play_scene` → `res://scenes/main/combat_s2.tscn`。
|
||||
- [x] **Step 1: 启动战斗场景**
|
||||
|
||||
⚠️ 工具坑 ①：运行时 `push_error` 不进 `get_output_log` / `get_editor_errors`。读**编辑器 Debugger 的「错误」树**（经 `execute_editor_script` 走 `ScriptEditorDebugger`）。**先做阳性对照** —— 故意触发一次已知报错（如 `ShopManager.buy_attribute("不存在的属性")`），确认它出现在你读的通道里，否则后面的「零报错」结论无意义。
|
||||
Run: godot-mcp-pro `play_scene` → `res://scenes/main/combat_s2.tscn`。实际输出 `{"mode": "res://scenes/main/combat_s2.tscn", "playing": true}`。
|
||||
|
||||
- [ ] **Step 2: 连乘正确性 + 金币序列（验收 7、8）**
|
||||
⚠️ 工具坑 ①：运行时 `push_error` 不进 `get_output_log` / `get_editor_errors`。读**编辑器 Debugger 的「错误」树**（经 `execute_editor_script` 走 `ScriptEditorDebugger`）。**先做阳性对照**——原写「故意触发 `buy_attribute("不存在的属性")`」不可用（见上方回填说明），改用：
|
||||
```gdscript
|
||||
PlayerStats.add_modifier("不存在的属性xyz", "flat", 1.0, "probe_unknown_attr")
|
||||
```
|
||||
随后用下列 `execute_editor_script` 读错误树（对齐 E3-① Task 5 已验证的读法）：
|
||||
```gdscript
|
||||
var dbg: Node = null
|
||||
var stack: Array = [EditorInterface.get_base_control()]
|
||||
while not stack.is_empty():
|
||||
var n: Node = stack.pop_back()
|
||||
if n.get_class() == "ScriptEditorDebugger":
|
||||
dbg = n; break
|
||||
for ch in n.get_children():
|
||||
stack.append(ch)
|
||||
var tree: Tree = null
|
||||
var st: Array = [dbg]
|
||||
while not st.is_empty():
|
||||
var n: Node = st.pop_back()
|
||||
if n is Tree and n.columns == 2 and n.get_parent().name.begins_with("错误"):
|
||||
tree = n; break
|
||||
for ch in n.get_children():
|
||||
st.append(ch)
|
||||
for top in tree.get_root().get_children():
|
||||
var t: String = top.get_text(1)
|
||||
if t.contains("GDScript::reload"):
|
||||
continue # 编译期告警，非运行时
|
||||
_mcp_print(top.get_text(0) + " | " + t)
|
||||
```
|
||||
实际输出：`player_stats.gd:198 @ add_modifier(): PlayerStats: 未知属性「不存在的属性xyz」（来源 probe_unknown_attr），加成已忽略` —— 通道确认存活，后续「零报错」结论才有意义。会话结束前复读同一棵树，全程仅出现本条与 Step 4 的 `add_int` 拒绝各一条，共 2 条，无意外报错。
|
||||
|
||||
- [x] **Step 2: 连乘正确性 + 金币序列（验收 7、8）**
|
||||
|
||||
Run: godot-mcp-pro `execute_game_script`：
|
||||
```gdscript
|
||||
@@ -811,9 +841,9 @@ if ShopManager.get_attr_purchases("hp_max") != 3:
|
||||
fails += 1; log.append("次数 %d 应 3" % ShopManager.get_attr_purchases("hp_max"))
|
||||
_mcp_print("FAILS=%d hp_max=%.4f prices=%s %s" % [fails, PlayerStats.hp_max, str(prices), str(log)])
|
||||
```
|
||||
Expected: `FAILS=0 hp_max=133.1000 prices=[60, 69, 79]`
|
||||
Expected: `FAILS=0 hp_max=133.1000 prices=[60, 69, 79]`。**实际输出**（原样，无偏离）：`FAILS=0 hp_max=133.1000 prices=[60, 69, 79] []`。
|
||||
|
||||
- [ ] **Step 3: `soft` 闸 + `cast_delay_mod` 尚未饱和（验收 9、10）**
|
||||
- [x] **Step 3: `soft` 闸 + `cast_delay_mod` 尚未饱和（验收 9、10）**
|
||||
|
||||
> spec §2.3 自审订正：三个饱和点全部低于 `soft`(0.1)，正常购买够不到，UI 只需 `soft` 一道闸。本步**同时证明**这一点。
|
||||
|
||||
@@ -837,9 +867,11 @@ _mcp_print("FAILS=%d 买了%d次 mod=%.4f 原因=%s 帧距=%d(应>1，证明未
|
||||
```
|
||||
Expected: `FAILS=0`，`帧距=3`（`wand_basic`），`原因=已达上限`。
|
||||
|
||||
> ⚠️ 脚本里的 `0.5` 是 `wand_basic` 的基准间隔。**若开局装备的不是 `wand_basic`，此常数与期望帧距都要改** —— 用 `_equipped_core.cast_interval` 读实际值更稳。断言的实质是「帧距 > 1（未饱和）」，不是「恰好等于 3」。
|
||||
> ⚠️ 脚本里的 `0.5` 是 `wand_basic` 的基准间隔。**若开局装备的不是 `wand_basic`，此常数与期望帧距都要改** —— 用 `_equipped_core.cast_interval` 读实际值更稳。断言的实质是「帧距 > 1（未饱和）」，不是「恰好等于 3」。实测确认开局装备确为 `wand_basic`（`combat_manager.gd:54` `_equipped_core = WandPreset.make_core_by_id("wand_basic")`），故 `0.5` 常数有效。
|
||||
|
||||
- [ ] **Step 4: `cpu_limit` 的 `add_int` 硬约束（验收 11）**
|
||||
**实际输出**：`FAILS=0 买了22次 mod=0.0985 原因=已达上限 帧距=3(应>1，证明未饱和)`。**校准**：到 `soft` 门槛实测需 **22 次购买**（`cast_delay_mod` 每次 `pct` 复利 `step=0.10`，`combine=inverse`，`merged=1-(1-0.10)^n`，`base×(1-merged)`≤`soft`(0.1) 在 `n=22` 时首次成立）——简报未写具体次数，此处补全为确定值，供日后回归对照。
|
||||
|
||||
- [x] **Step 4: `cpu_limit` 的 `add_int` 硬约束（验收 11）**
|
||||
|
||||
Run: godot-mcp-pro `execute_game_script` —— 直接对 `PlayerStats` 施加 `pct` 加成，确认被拒（`shop` 段配的是 `flat`，此处验证的是底层约束仍在）：
|
||||
```gdscript
|
||||
@@ -849,9 +881,9 @@ var after: int = PlayerStats.cpu_limit
|
||||
PlayerStats.remove_modifiers_from("zzzprobe")
|
||||
_mcp_print("FAILS=%d before=%d after=%d（pct 应被 add_int 拒绝，二者相等）" % [(0 if before == after else 1), before, after])
|
||||
```
|
||||
Expected: `FAILS=0`，且 Debugger 错误树中出现 `add_int 属性不接受 pct 加成`。
|
||||
Expected: `FAILS=0`，且 Debugger 错误树中出现 `add_int 属性不接受 pct 加成`。**实际输出**：`FAILS=0 before=5 after=5（pct 应被 add_int 拒绝，二者相等）`；错误树命中 `attribute_formula.gd:45 @ compute(): AttributeFormula: add_int 属性不接受 pct 加成（value=0.500000），已忽略`，原样确认。
|
||||
|
||||
- [ ] **Step 5: 存档往返 + 旧档兼容 + 与 `"core"` 共存（验收 12、14）**
|
||||
- [x] **Step 5: 存档往返（内存 API）+ 旧档兼容 + 与 `"core"` 共存（验收 12、14）**
|
||||
|
||||
Run: godot-mcp-pro `execute_game_script`：
|
||||
```gdscript
|
||||
@@ -877,37 +909,96 @@ _mcp_print("FAILS=%d hp %.2f→清零→%.2f cpu %d" % [fails, hp_before, Player
|
||||
Expected: `FAILS=0`。
|
||||
> `cpu_before` 含法杖的 `"core"` 份额 + 购买的 flat，回读后应完全一致 —— 这同时验证了两个来源互不干扰（验收 14）。
|
||||
|
||||
- [ ] **Step 6: 回读顺序不吞血（Task 3 的核心风险）**
|
||||
**实际输出**：`FAILS=0 hp 133.10→清零→100.00 cpu 7`（`cpu_before=7` = 法杖 `wand_basic` 的 `core` 份额 5 + 购买 `cpu_limit` 两次的 `flat` 份额 2，回读后原样恢复，验证与 `"core"` 来源互不干扰）。
|
||||
|
||||
Run: godot-mcp-pro `execute_game_script` —— 模拟 `apply_run` 的真实顺序：
|
||||
- [x] **Step 5b（新增，补前序评审 ⚠️）：磁盘往返独立复核**
|
||||
|
||||
Task 3 评审记录「磁盘 save_run→load_run 完整往返未被独立复核」（`progress.md` Task 3 minor）。Step 5 用的是内存态 `get_attr_purchases_save`/`apply_attr_purchases_save` 往返，**不经过 JSON 序列化落盘**，不能替代磁盘复核。本步用 `ProfileManager.save_run()`/`load_run()`/`apply_run()` 走真实文件 I/O（`play_scene` 运行时，`execute_editor_script` 会静默拦截 `FileAccess.WRITE`，此步骤只能在游戏运行时里做，工具坑 ⑥）：
|
||||
```gdscript
|
||||
ShopManager.reset()
|
||||
PlayerStats.gold = 9999
|
||||
ShopManager.reset()
|
||||
for i in 3: ShopManager.buy_attribute("hp_max") # hp_max → 133.1
|
||||
for i in 3: ShopManager.buy_attribute("hp_max")
|
||||
for i in 2: ShopManager.buy_attribute("cpu_limit")
|
||||
PlayerStats.hp = 130.0
|
||||
var saved: Dictionary = ShopManager.get_attr_purchases_save()
|
||||
var ps: Dictionary = PlayerStats.get_save_data()
|
||||
# 正确顺序：先恢复加成，再 load_save_data
|
||||
var hp_before: float = PlayerStats.hp
|
||||
var hp_max_before: float = PlayerStats.hp_max
|
||||
var cpu_before: int = PlayerStats.cpu_limit
|
||||
var purchases_before: Dictionary = ShopManager.get_attr_purchases_save()
|
||||
ProfileManager.mark_dirty()
|
||||
ProfileManager.save_run() # 真实写盘（user://run_a.json 或 run_b.json，A/B 槽交替）
|
||||
|
||||
# 模拟"未加载前"的清空态：只清货架 C 购买（真实 apply_run 也不重置 core，core 由 wand 数据自身重建）
|
||||
ShopManager.reset()
|
||||
var loaded: Dictionary = ProfileManager.load_run() # 真实读盘 + JSON.parse_string
|
||||
ProfileManager.apply_run(loaded)
|
||||
|
||||
var fails := 0
|
||||
if abs(PlayerStats.hp - hp_before) > 0.0001: fails += 1
|
||||
if abs(PlayerStats.hp_max - hp_max_before) > 0.0001: fails += 1
|
||||
if PlayerStats.cpu_limit != cpu_before: fails += 1
|
||||
if ShopManager.get_attr_purchases_save() != purchases_before: fails += 1
|
||||
_mcp_print("DISK_ROUNDTRIP FAILS=%d hp=%.4f(应%.4f) hp_max=%.4f(应%.4f) cpu=%d(应%d)" % [
|
||||
fails, PlayerStats.hp, hp_before, PlayerStats.hp_max, hp_max_before, PlayerStats.cpu_limit, cpu_before])
|
||||
ProfileManager.clear_run() # 清理：不留测试存档
|
||||
ShopManager.reset()
|
||||
```
|
||||
**实际输出**：`DISK_ROUNDTRIP FAILS=0 cleared_hp_max=100.00 cleared_cpu=5 loaded_keys=["attr_purchases", "player_stats", "saved_at", "schema_version", "shop_seed", "wand", "wave_num"] attr_purchases={ "cpu_limit": 2.0, "hp_max": 3.0 } hp=130.0000(应130.0000) hp_max=133.1000(应133.1000) cpu=7(应7)`。`attr_purchases` 经 JSON 序列化后数值型变为 `float`（`2.0`/`3.0`），`get_attr_purchases_save()` 内部按 `int(d[k])` 转换，往返后与购买前逐位相等。
|
||||
> **踩坑记录**：第一轮跑此脚本时得到 `FAILS=1`（`cpu=7` 应 `2`），排查后发现是脚本本身的问题——上一段测试脚本的清理代码里手误调了 `PlayerStats.reset_for_run()`（会连带清掉法杖的 `"core"` 加成来源且不会自动重建），污染了本段测试开始前的基线，与被测代码无关。教训：`reset_for_run()` 只应由 `combat_manager` 在真正开局/重开时调用，且必须伴随法杖重新装备（`_rebuild_wand()` 会重建 `"core"` 加成）；手工验收脚本里绝不能单独调它做"清空状态"，否则会污染同会话后续脚本的基线。
|
||||
|
||||
- [x] **Step 6: 回读顺序不吞血（Task 3 的核心风险）**
|
||||
|
||||
⚠️ **回填：简报原脚本是空断言，已替换**。原脚本在**全新会话**（`_modifiers` 本就为空）下跑：`ShopManager.reset()` 之后 `_modifiers` 已空，`apply_attr_purchases_save` 内部 `remove_modifiers_from` 因无可移除项而提前 `return`（不触发 `_recompute_attrs`），单次 `add_modifier` 直接算出最终 `hp_max`，**两种顺序结果一样**——把两行顺序对调，原脚本的 `FAILS` 依然是 0。这正是 Task 3 报告里记录的同一个陷阱（`progress.md` Task 3：「按后者写的回归断言恒绿」），Task 6 沿用简报原脚本会重蹈覆辙，故按 Task 3 报告给出的真实复现场景重写：
|
||||
|
||||
```gdscript
|
||||
ShopManager.reset()
|
||||
PlayerStats.gold = 9999
|
||||
ShopManager.buy_attribute("hp_max") # 1 次既有购买 → hp_max=110，_modifiers 非空
|
||||
var saved: Dictionary = {"hp_max": 3} # 模拟存档目标：3 次购买
|
||||
var ps: Dictionary = {"hp": 130.0, "gold": PlayerStats.gold, "xp": 0, "level": 1}
|
||||
|
||||
# 错误顺序：先 load_save_data，再 apply_attr_purchases_save
|
||||
# （此时 _modifiers 非空，remove_modifiers_from 会真正命中并触发即时 recompute）
|
||||
PlayerStats.load_save_data(ps)
|
||||
ShopManager.apply_attr_purchases_save(saved)
|
||||
# WRONG ORDER 实测: hp=100.00 hp_max=133.10 —— hp 被钳到 100，吞了 30 血
|
||||
|
||||
# 复原到同样的「1 次既有购买」前提，测正确顺序
|
||||
ShopManager.reset(); PlayerStats.gold = 9999; ShopManager.buy_attribute("hp_max")
|
||||
PlayerStats.hp = PlayerStats.hp_max
|
||||
|
||||
# 正确顺序：先 apply_attr_purchases_save，再 load_save_data（= apply_run 实际顺序）
|
||||
ShopManager.apply_attr_purchases_save(saved)
|
||||
PlayerStats.load_save_data(ps)
|
||||
var fails := (0 if abs(PlayerStats.hp - 130.0) < 0.01 else 1)
|
||||
_mcp_print("FAILS=%d hp=%.2f hp_max=%.2f（应 130/133.1，颠倒顺序会被钳到 100）" % [fails, PlayerStats.hp, PlayerStats.hp_max])
|
||||
_mcp_print("CORRECT ORDER FAILS=%d final hp=%.2f hp_max=%.2f（应 130/133.1）" % [fails, PlayerStats.hp, PlayerStats.hp_max])
|
||||
```
|
||||
Expected: `FAILS=0 hp=130.00 hp_max=133.10`
|
||||
**实际输出**（两遍都跑，红/绿对照）：
|
||||
- 错误顺序：`WRONG after load_save_data only: hp=130.00 hp_max=110.00` → `WRONG ORDER final: hp=100.00 hp_max=133.10`（吞 30 血，复现 Task 3 报告的原始发现）。
|
||||
- 正确顺序：`CORRECT ORDER FAILS=0 final hp=130.00 hp_max=133.10`（未被钳，与 `hp_before`=130 完全一致）。
|
||||
|
||||
- [ ] **Step 7: `shop` 段缺失即不上架（验收 16）**
|
||||
这独立复核了 Task 3 的核心风险与其修复，且证明了断言本身非空——删掉 `apply_run` 里的顺序修复会让这条断言真正变红。
|
||||
|
||||
Run: godot-mcp-pro `execute_game_script`：
|
||||
- [x] **Step 7: `shop` 段缺失即不上架（验收 16）**
|
||||
|
||||
⚠️ **回填：简报原脚本对"过滤机制"是空断言，已补充**。原脚本只断言 `get_sellable_attrs().size() == 4`——但 `attributes.json` 目前**恰好 4 个属性且都有 `shop` 段**，若把 `get_sellable_attrs()` 里按 `shop` 段过滤的 `if` 整个删掉（返回全部属性），结果仍是这 4 个，断言依然为绿，不构成对「无 `shop` 段不上架」这条机制的真实检验。补一段直接向 `ShopManager._attr_def` 注入合成属性（无 `shop` 段）的机制测试：
|
||||
```gdscript
|
||||
var ids: Array = ShopManager.get_sellable_attrs()
|
||||
var fails := (0 if ids.size() == 4 else 1)
|
||||
_mcp_print("FAILS=%d sellable=%s（四个都有 shop 段）" % [fails, str(ids)])
|
||||
|
||||
# 机制测试：注入一个无 shop 段的合成属性，验证真被排除（而非仅验证现有 4 个数据事实）
|
||||
ShopManager._attr_def["synthetic_no_shop"] = {"display_name": "合成测试属性", "base": 0.0, "soft": 0.0, "hard": 0.0, "combine": "flat"}
|
||||
var ids_with_synthetic: Array = ShopManager.get_sellable_attrs()
|
||||
var excluded_ok: bool = not ids_with_synthetic.has("synthetic_no_shop")
|
||||
_mcp_print("FAILS=%d ids_with_synthetic=%s excluded_ok=%s" % [(0 if excluded_ok else 1), str(ids_with_synthetic), str(excluded_ok)])
|
||||
ShopManager._attr_def.erase("synthetic_no_shop") # 清理注入，恢复原定义
|
||||
```
|
||||
Expected: `FAILS=0 sellable=["cast_delay_mod", "cpu_limit", "hp_max", "move_speed"]`
|
||||
> 若日后有属性无 `shop` 段，此断言的期望数需随之调整 —— 它守的是「按 `shop` 段筛选」这个机制，不是「恰好 4 个」。
|
||||
|
||||
- [ ] **Step 8: 权威文档补录（spec §2.7）**
|
||||
**实际输出**：数据事实断言 `FAILS=0 sellable=["cast_delay_mod", "cpu_limit", "hp_max", "move_speed"]`（四个都有 shop 段）；机制断言 `FAILS=0 ids_with_synthetic=["cast_delay_mod", "cpu_limit", "hp_max", "move_speed"] excluded_ok=true`（合成属性被正确排除）；清理后 `cleanup_ok=true ids=["cast_delay_mod", "cpu_limit", "hp_max", "move_speed"]`，未污染真实定义。
|
||||
|
||||
- [x] **Step 8: 权威文档补录（spec §2.7）**
|
||||
|
||||
`docs/design/numerical_design.md` §1.2 经济系统的**消耗清单**（现仅「购买法术 50-500G / 购买法杖 200-2000G / 刷新商店 20G*」三项）新增一项：
|
||||
|
||||
@@ -915,14 +1006,24 @@ Expected: `FAILS=0 sellable=["cast_delay_mod", "cpu_limit", "hp_max", "move_spee
|
||||
|
||||
同时在 §1.1 的 `cast_delay_mod` 行补一句：其饱和点（`wand_basic` 0.0333 等）**全部低于 `soft`(0.1)**，故常规购买够不到饱和区，`soft` 才是实际约束。
|
||||
|
||||
- [ ] **Step 9: 路线图勾除**
|
||||
**实际落地**：两处均按简报原样写入 `docs/design/numerical_design.md`（消耗清单新增「购买属性 (60-120G 起，几何递增)...」一句；`cast_delay_mod` 行追加饱和点/`soft` 关系一句，并补上 `soft` 门槛实测 22 次购买、帧距仍为 3（未饱和）的交叉引用），无文字偏离。
|
||||
|
||||
`docs_dev/plans/2026-07-23-missing-features-roadmap.md` 的 E3 切分列表第 2 项「货架 C（属性购买）」标记完成，格式对齐已完成的第 1 项，并注明实际范围（四个框架内属性；B 类 7 个属性待各自前置解除后加 `shop` 段即可，零代码）。
|
||||
- [x] **Step 9: 路线图勾除**
|
||||
|
||||
- [ ] **Step 10: 回填本计划为实际执行版**
|
||||
`docs_dev/plans/2026-07-23-missing-features-roadmap.md` 的 E3 切分列表第 2 项「货架 C（属性购买）」已标记完成，格式对齐已完成的第 1 项：勾除 + 完成摘要（`PriceFormula` 模块、`ShopManager` 状态、`attributes.json` `shop` 段、`ProfileManager` schema 3、UI 子面板、设计器字段）+ 实际范围说明（仅 4 个框架内属性；B 类 7 个属性待各自前置解除后加 `shop` 段即可零代码上架，已用注入合成属性的方式运行时验证该机制）+ `cast_delay_mod` soft 验证摘要。
|
||||
|
||||
- [x] **Step 10: 回填本计划为实际执行版**
|
||||
|
||||
实现过程中若因评审改动了代码或断言，**本计划对应的代码块与脚本必须回填为实际落地的版本**，并勾上各任务复选框（只留 Step 11 未勾）。每处回填旁注明**原写法为何不可用** —— 那是最耐久的价值。归航与 E3-① 两期都踩过「计划里留着过时代码和失效断言」的坑。
|
||||
|
||||
**本步执行记录**：本 Task 6 一节（Step 1–9）已全部回填为实测脚本与实测输出，三处发现简报原脚本不可用并已替换/补充：
|
||||
1. **Step 1 阳性对照**：`ShopManager.buy_attribute("不存在的属性")` 不触发 `push_error`（走禁用原因字符串分支），改用 `PlayerStats.add_modifier` 未知属性守卫。
|
||||
2. **Step 5b（新增）**：Task 3 评审记录磁盘往返未被独立复核，原计划里 Step 5 的"存档往返"实为内存态 API 往返（不落盘），补一段真实 `ProfileManager.save_run()/load_run()/apply_run()` 磁盘往返验证，回应该评审意见。
|
||||
3. **Step 6**：简报原脚本在全新会话（`_modifiers` 为空）下测，`remove_modifiers_from` 因无可移除项提前 return，两种顺序结果相同，是空断言（与 Task 3 报告记录的同一陷阱）。改用 Task 3 报告里给出的真实复现场景（先有一次既有购买，`_modifiers` 非空），红/绿对照跑通。
|
||||
4. **Step 7**：简报原脚本只断言 `ids.size()==4`，对"按 `shop` 段过滤"这一机制是空断言（当前数据恰好 4 个都有 `shop` 段，删掉过滤逻辑结果不变）。补一段注入无 `shop` 段合成属性的机制测试。
|
||||
|
||||
全部 17 条验收标准 + Task 3 遗留的回读顺序风险，逐条有实际运行输出，无空断言（自审要点已核对：删掉对应实现代码，每条断言均会变红）。
|
||||
|
||||
- [ ] **Step 11: 合并决策**
|
||||
|
||||
用 `superpowers:finishing-a-development-branch` 决定分支去向。前五个已完成特性均合并进 `master` 并删分支。
|
||||
@@ -944,7 +1045,7 @@ Expected: `FAILS=0 sellable=["cast_delay_mod", "cpu_limit", "hp_max", "move_spee
|
||||
| 9 | 达 `soft` 后禁用且 API 拒绝 | Task 6 Step 3 | 运行时 |
|
||||
| 10 | `soft` 时尚未饱和（证明 §2.3 订正） | Task 6 Step 3 | 运行时（帧距 >1） |
|
||||
| 11 | `cpu_limit` 拒 `pct` | Task 6 Step 4 | 运行时 + 错误通道 |
|
||||
| 12 | 存档往返 + 旧档兼容 | Task 6 Step 5 | 运行时 |
|
||||
| 12 | 存档往返 + 旧档兼容 | Task 6 Step 5（内存 API）+ Step 5b（真实磁盘 `save_run`/`load_run`，补前序评审 ⚠️） | 运行时 |
|
||||
| 13 | `reset` 后清零 | Task 6 Step 5 | 运行时（`cleared_ok`） |
|
||||
| 14 | 与 `"core"` 来源共存 | Task 6 Step 5 | 运行时（`cpu_before` 含两源） |
|
||||
| 15 | 设计器往返**逐位相等** | Task 5 Step 4 | 绕缓存实例化 |
|
||||
|
||||
Reference in New Issue
Block a user