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
parent 84c10725e2
commit 9361bf8767
4 changed files with 18 additions and 4 deletions
@@ -331,6 +331,8 @@ func execute_compiled(compiled: CompiledDeck, caster_id: int, spawn_pos: Vector2
 	var ops_count:         int = 0
 	# 生效 cpu_limit 已含法杖份额（combat_manager._rebuild_wand 以 source="core" 的加成接入）
 	# 下限 1：注入缺失时不把游戏打成砖（0 会让 while 一步都不走）；该异常由 equip_wand 处报出
+	# 注：仅顶层执行循环。execute_sub 的子荷载预算是独立的 MAX_OPS_PER_CPU * 2（= 80），
+	# 与 cpu_limit 无关——既有行为，改前同样脱节，本次接线未触及
 	var max_ops:           int = MAX_OPS_PER_CPU * maxi(PlayerStats.cpu_limit, 1)
 	var actions_remaining: int = 1  # 初始为 1，由 multicast_count 加成
 	while deck.has_next() and ops_count < max_ops: