docs: 订正 wand_fast 饱和点 0.05→0.0667；roadmap 关闭已决定项并澄清移速表述

【订正】wand_fast(0.25s) 的饱和点按公式 (1/60)/0.25 = 0.0667，不是 0.05。
numerical_design:21 的标注与它自己上一句的公式直接矛盾，spec/plan 另有三处同源
错误标注——均派生自一句口头转述，实测表里记的 0.0667 一直是对的。

结论也随之改对，不只是改数字：hard=0.05 使 wand_basic(饱和 0.0333) 与
circuit_fork(0.0278) 无无效区间，但 wand_fast 仍剩 [0.05, 0.0667) 这段买不到东西
（较原 hard:0.01 的 6.7 倍缩至 1.33 倍）。仍取 0.05 的理由：饱和点 = (1/60)/法杖
基准间隔，随杖而异，不存在对所有杖都最优的单一 hard——取 0.0667 让 wand_fast 干净
会使另两把杖够不到自己的饱和点，反而制造新的不可达区间。hard 数值不变。

顺带说明实测表里 wand_fast@0.0667 读到 2 帧的原因：采样点比真实边界 1/15 高 3.3e-5
(T 上高 8.3e-6 s)，再叠加整帧倍数多花一帧的浮点余量效应，故实际 1 帧上界略低于
0.0667。数据没错，是标签错了。

【roadmap】E3-① 下的 cast_delay_mod 条目仍记为「待人定」并指向两个选项，而该决定
已在 ba7c885 关闭——roadmap 是查「E3 还剩什么」的索引，留着会把已关闭的决定重新打开。
改为已处理，并注明彻底消除需让 hard 逐杖化（挪进 cores.json），属独立立项。

【roadmap】「实测 200→300 px/s」读起来像发版移速由 200 改成 300，与同批改动里
numerical_design 的订正（发版是 200，300 是从未被读过的纸面值）直接冲突。改写为
「发版基准仍是 200；实测手段是临时挂 +50% 加成使生效值变 300」。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/design/numerical_design.md

@@ -18,7 +18,7 @@
 | `hp_max` | 最大生命 | 100 | 2000 | - | |
 | `mana_max` | 最大魔力 | 100 | 1000 | - | 全局蓝条上限，法杖也有自己的上限，取 Min 值 |
 | `move_speed` | 移动速度 | **200** | 600 | 800 | 像素/秒。⚠️ **2026-07-31 订正**：原写 300 从未被任何代码读取过，是纸面孤值；实际实现自 S0 起即为 200（`player_manager.gd` 的 `const MOVE_SPEED`，现已改为读 `data/attributes.json`），20 波内容、Boss 弹幕密度、无敌帧 0.5 s 均按此值调校。此处以既成事实为准 —— 改回 300 等于用未经验证的数字推翻一整轮已调校的内容。理由详见 `docs_dev/specs/2026-07-31-player-attributes-design.md` §2.2。 |
-| `cast_delay_mod` | 施法延迟修正 | 1.0 (100%) | 0.1 | **0.05** | 越低越快，乘算系数。⚠️ **2026-07-31 由 0.01 上调至 0.05**：`player_manager._handle_auto_cast` 用 `if` 而非 `while`，**每物理帧至多施法一次**，故本属性存在**饱和点** = `(1/60) / 法杖基准间隔` —— `wand_basic`(0.5 s) ≈ 0.033、`wand_fast`(0.25 s) ≈ 0.05。原 `0.01` 在两把主力杖上都深深落在饱和区内，即玩家买到 0.033 以下**再也换不到任何射速**，属"承诺了循环交付不了的东西"。取 0.05 使 `wand_fast` 恰好在硬上限处饱和、`wand_basic` 全程无无效区间。实测数据（可达档位是台阶而非曲线、周期恒为 `ceil(T×60)`）见 `docs_dev/specs/2026-07-31-player-attributes-design.md` §2.2b。 |
+| `cast_delay_mod` | 施法延迟修正 | 1.0 (100%) | 0.1 | **0.05** | 越低越快，乘算系数。⚠️ **2026-07-31 由 0.01 上调至 0.05**：`player_manager._handle_auto_cast` 用 `if` 而非 `while`，**每物理帧至多施法一次**，故本属性存在**饱和点** = `(1/60) / 法杖基准间隔` —— `wand_basic`(0.5 s) ≈ **0.0333**、`wand_fast`(0.25 s) ≈ **0.0667**、`circuit_fork`(0.6 s) ≈ 0.0278。**饱和点随杖而异，故不存在对所有杖都最优的单一 `hard`**：要让 `wand_fast` 无无效区间需 `hard ≥ 0.0667`，但那会让 `wand_basic` 够不到自己的 0.0333，反而制造新的不可达区间。取 `0.05` 是折中 —— `wand_basic` 与 `circuit_fork` 无无效区间，`wand_fast` 仍剩 `[0.05, 0.0667)` 这一小段买不到东西；相对原 `0.01`（两把主力杖都深陷饱和区、从 0.0333 一路买到 0.01 射速纹丝不动）是大幅改进。实测数据（可达档位是台阶而非曲线、周期恒为 `ceil(T×60)`）见 `docs_dev/specs/2026-07-31-player-attributes-design.md` §2.2b。 |
 | `recharge_speed_mod` | 充能速度修正 | 1.0 (100%) | 5.0 | - | 越低越快 |
 | `luck` | 幸运 | 0 | 100 | - | 影响高阶法术掉率、暴击率 |
 | `cpu_limit` | 运算力上限 | **0**（玩家侧） | 20 | 50 | `SpellEvaluator` 实际 MAX_OPS = `生效 cpu_limit × 40`，与 `implementation_plan.md §2.2` 的 `MAX_OPS_PER_CPU = 40` 常量对应。**生效值 = 玩家侧基准 0 + 法杖份额（`cores.json` 逐杖 3–8，以 `source="core"` 的加成来源接入）+ 未来的玩家加成**；`hard`(50) 作用于**加总后的生效值**，故法杖份额也受硬上限约束。玩家侧基准取 0 而非 5 是刻意的：生效值已含法杖的 3–8，取 0 使小木法杖仍为 5 → 200 步（现有平衡零改动），取 5 会让所有法杖的执行预算翻倍；语义上玩家属性是"全局加成"，基准 0 正是纯加成语义。 ✅ **2026-07-31 已修复**（原 ⚠️「代码硬编码 MAX_OPS = 40×5 = 200，从不读 cpu_limit」现已失效）：`spell_evaluator.gd` 改读 `MAX_OPS_PER_CPU * maxi(PlayerStats.cpu_limit, 1)`，`cores.json` 逐杖配置的运算力自此生效（高速法杖 3 → 120 步、小木 5 → 200、矩阵板 8 → 320，运行时实测）。设计见 `docs_dev/specs/2026-07-31-player-attributes-design.md` §2.2。 |