joywayerandClaude Opus 5
9361bf8767
refactor(attr): "core" 来源提为常量；_compute_attr 补 assert；注明 execute_sub 预算独立
MOD_SOURCE_CORE 常量取代四处裸字面量（combat_manager:275,276、combat_test:20,21）。
combat_manager:273 的注释自己就警告「漏掉 remove 会累积，且 hard:50 会把它封成一个
看起来合理的数字」——而 remove 那一侧的字面量若打错一个字符，产生的正是这个零诊断
故障：旧份额撤不掉、逐次累积、被硬上限封顶成常数。常量把它变成编译期错误。
_compute_attr 缺定义时返回 0.0 是消费侧的不对称：Task 4 已硬化生产侧（attribute_tab
的 _loaded 拒绝写出零载荷），但手删 JSON 里的 cast_delay_mod 仍会让生效间隔变 0
（每物理帧施法一次）、删 move_speed 则玩家不能动。它有 push_error，但运行时 push_error
到不了任何日志通道（本期已实测），故表现为一块莫名其妙的砖。按 _recompute_attrs 空定义
分支的同款模式补 assert：release 编译掉、开发期立刻中断。
spell_evaluator:332 的新注释说「生效 cpu_limit 已含法杖份额」，读者可能推断整个 VM 都按
cpu_limit 走，但 execute_sub 的子荷载预算仍是独立的 MAX_OPS_PER_CPU * 2（=80）。补一句
注明其独立且属既有行为（改前同样脱节），不改 execute_sub 的行为。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 13:37:15 +08:00
..
2026-07-24 09:23:01 +08:00
2026-07-20 10:56:52 +08:00
2026-07-20 10:56:52 +08:00
2026-07-31 13:37:15 +08:00
2026-07-20 10:56:52 +08:00
2026-07-20 10:56:52 +08:00