docs(plan): 订正 Task3 吞血成因——补正提交 900eaea 说明中的失实描述

900eaea 的提交信息照抄了简报里「hp_max 买到 180 后即可复现」的说法，而
Task 3 实测 + 评审独立复现证明该路径不触发：_modifiers 为空时
remove_modifiers_from 提前返回，单次合并的 add_modifier 一步算出最终值，
中间没有可观察的陈旧 hp_max。

真实风险窗口是同进程内二次 apply_run（_modifiers 已有 shop_c 加成时）。
计划里补了三行复现数据与「写回归测试必须用场景 B 前提」的告诫——
按失实说法写的断言恒绿。

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

docs_dev/plans/2026-07-31-shelf-c-attribute-shop.md

@@ -476,7 +476,17 @@ const SCHEMA_VERSION: int = 3  # v3：新增 attr_purchases（货架 C 属性购
 
 - [ ] **Step 3: 回读 —— 顺序至关重要**
 
-`apply_run()`（:63）当前**第一步**就是 `PlayerStats.load_save_data(...)`（设 `hp`）。货架 C 能把 `hp_max` 买到 180 后，若属性加成在此之后才恢复，回读的 `hp=180` 会被尚未加成的 `hp_max=100` 钳掉 —— **静默吞 80 血**（E3-① 在 `player_stats.gd` 注释里记录过这个陷阱）。
+`apply_run()`（:63）当前**第一步**就是 `PlayerStats.load_save_data(...)`（设 `hp`）。若属性加成在此之后才恢复，回读的 `hp` 会被尚未加成的 `hp_max` 钳掉 —— **静默吞血**（E3-① 在 `player_stats.gd` 注释里记录过这个陷阱）。
+
+> 📌 **成因订正（Task 3 实测 + 评审独立复现）**：本步初稿称「全新启动、`hp_max` 买到 180 后即可复现」—— **该路径实际不触发**。`remove_modifiers_from` 在 `_modifiers` 为空时提前返回、不触发 `_recompute_attrs`，随后单次合并的 `add_modifier` 一步算出最终 `hp_max`，中间从未出现「陈旧 `hp_max`」的可观察状态。
+>
+> **真实风险窗口**：同一进程内 `_modifiers` 里**已有**一条 `shop_c` 加成时再次 `apply_run`（如「主菜单 → 继续 → 死亡 → 主菜单 → 再次继续」）。此时 `remove_modifiers_from` 真正命中旧加成、触发一次 `_recompute_attrs`，而 `hp` 已被颠倒的顺序设为 130、`hp_max` 尚未回升 → 钳到 100，吞 30 血。评审复现数据：
+> ```
+> 场景A（无历史加成，即初稿描述）：颠倒顺序 → hp=130 hp_max=133.1   未吞血
+> 场景B（已有一条 shop_c 加成）：  颠倒顺序 → hp=100 hp_max=133.1   吞 30 血
+> 场景B + 实际交付的 apply_run()：           hp=130 hp_max=133.1   正确
+> ```
+> **写回归测试必须用场景 B 的前提**（预置一条同源加成），否则断言恒绿、证明不了任何事。
 
 故 `attr_purchases` 必须在 `load_save_data` **之前**恢复。把 `apply_run` 的前两行改为：
 ```gdscript
@@ -516,7 +526,8 @@ feat(shop): 货架 C 购买次数进局内存档（schema 2→3）
 
 回读顺序：attr_purchases 必须早于 load_save_data。后者设 hp，而重建加成会经
 _recompute_attrs 触发 hp = minf(hp, hp_max)；顺序颠倒会拿未加成的 hp_max 去钳，
-静默吞血（hp_max 可买到 180 后即可复现）。
+静默吞血。触发前提是 _modifiers 里已有同源加成（同进程内二次 apply_run），
+此时 remove_modifiers_from 才真正命中并触发一次中间态重算。
 
 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 EOF