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>

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.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。 |
+| `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。**2026-07-31 补充（货架 C）**：本属性的三个饱和点（`wand_basic` 0.0333 等）**全部低于货架购买软上限 `soft`(0.1)**，故常规购买够不到饱和区，`soft` 才是玩家实际能碰到的约束——运行时实测买到 `soft` 门槛需 22 次购买，此时帧距仍为 3 帧（未饱和），验证见 `docs_dev/specs/2026-07-31-shelf-c-attribute-shop-design.md` §2.3。 |
 | `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。 |
@@ -31,13 +31,18 @@
 
 *   **金币 (Gold)** (代号 `G`)
     *   **来源**: 击杀怪物 (1-5G)，波次结算 (100G + 10%利息)。
-    *   **消耗**: 购买法术 (50-500G)，购买法杖 (200-2000G)，刷新商店 (20G*)。
+    *   **消耗**: 购买法术 (50-500G)，购买法杖 (200-2000G)，刷新商店 (20G*)，购买属性 (60-120G 起，几何递增，见下)。
     *   **利息上限**: 10% 利息计算时，单次波次奖励上限为 **100G**（即持有 1000G 以上部分不再产生额外利息）。防止后期经济失控膨胀。
     *   **膨胀控制**: 商店刷新价格每次增加，波次结束后重置。金币不捡 5 秒后消失，逼迫玩家移动拾取。
         - **刷新价格公式（F11 补充，P6-N23）**：`刷新费用 = 20 + (本波已刷新次数 × 10)`（单位：G）。
           即第 1 次刷新 20G，第 2 次 30G，第 3 次 40G，以此类推；波次结算后重置为 20G。
           设计意图：前 1-2 次刷新成本低，鼓励灵活换货；反复刷新代价指数感，抑制"无脑刷新"。
           实现：`ShopManager` 维护 `_refresh_count: int`（波次内），`WAVE_COMPLETE` 事件后清零。
+        - **属性购买价格公式（货架 C，2026-07-31）**：**购买属性 (60-120G 起，几何递增)**——各属性首购价与成长曲线见
+          `data/attributes.json` 的 `shop` 段（`hp_max` 60×1.15ⁿ / `move_speed` 70×1.15ⁿ / `cast_delay_mod` 90×1.20ⁿ /
+          `cpu_limit` 120×1.30ⁿ，`n` = 已购次数，首购 `n=0`）。**按本局该属性累计购买次数递增，不随波次重置**
+          （与刷新费用相反——刷新的价值每次相同故线性递增即可，属性购买的价值在复利）。上限为各属性的 `soft`
+          （「常规来源可达上限」）。设计依据见 `docs_dev/specs/2026-07-31-shelf-c-attribute-shop-design.md` §2.2。
 
 *   **经验值 (XP)**
     *   **升级曲线（权威公式 P6-N16）**：