overlord_event_system/mechanics/

balance.rs

//!
//! Functions and constants here mirror the original `balance.yaml` script,
//! which contained the project's fundamental combat and economic balance
//! formulas. Content-dependent lookups (item rarity quality, ability
//! rarity effectiveness, fixed-power items) are sourced from
//! [`ContentLookups`], which is populated at engine init time by reading
//! the `content_raw` module's data maps.

use std::collections::BTreeMap;

use configs::game_config::GameConfig;
use essences::abilities::{Ability, EquippedAbilities};
use essences::items::Item;
use essences::pets::Pet;
use event_system::script::random::GameRng;
use uuid::Uuid;

use crate::game_config_helpers::GameConfigLookup;
use crate::mechanics::content_lookups::ContentLookups;

/// Ordered attribute accumulator used by [`power_from_attrs`] /
/// [`character_power`].
///
/// only ever does keyed reads (`get_attr` on fixed attribute names) — it never
/// iterates the map — so the only behaviour that must be preserved is the
/// per-key float accumulation order. We accumulate in source order
/// (`*entry += value`), which is byte-identical to the old
/// `Dynamic::from_float(cur + value)` insert. A `BTreeMap<String, f64>` routes
pub type AttrMap = BTreeMap<String, f64>;

/// Add `value` to the running sum for `key`, mirroring the old
/// `let cur = collected.get(key)...; collected.insert(key, cur + value)`.
fn accumulate(map: &mut AttrMap, key: &str, value: f64) {
    *map.entry(key.to_string()).or_insert(0.0) += value;
}

pub const FIGHT_DURATION: f64 = 8.333;
pub const BASE_HP: f64 = 3000.0;
pub const BASE_ATTACK: f64 = 600.0;
pub const DMG_K: f64 = 0.1;
pub const BASE_CRIT_CHANCE: f64 = 0.0;
pub const BASE_CRIT_MOD: f64 = 2.0;
pub const BASE_POWER: i64 = 1000;
pub const BASE_SPEED: f64 = 1.0;
pub const COUNTERATTACK_POWER: f64 = 2.0;
pub const BASE_SPELL_EFF: f64 = 1.0;
pub const MAIN_ATTRS_QUANTITY: i64 = 3;
pub const SPELL_QUANTITY: i64 = 6;
pub const ATTR_DEVIATION: f64 = 0.1;
pub const AUX_ATTR_IMPACT: f64 = 0.05;
pub const AOE_COEF: f64 = 0.6;
pub const OT_COEF: f64 = 1.2;
pub const HEAL_COEF: f64 = 1.2;
pub const BUFF_EFF: f64 = 1.5;
pub const BRAVERY_BUFF_QUANTITY: i64 = 2;
pub const BRAVERY_BUFF_DURATION: f64 = 1.0;
pub const DECEIT_DEBUFF_QUANTITY: i64 = 2;
pub const DECEIT_DEBUFF_DURATION: f64 = 1.0;
pub const CASTS_PER_SEC: f64 = 2.0;
pub const ATTACKS_PER_SEC: f64 = CASTS_PER_SEC * 1.1;

// --- Balance v2: P = DPS × EHP, diminishing-returns curves R/(R+K) ----------
// Avoidance/mitigation use the DR curve `rating/(rating+K)`: it asymptotes
// below 100%, so no single defensive stat dominates and there is no cliff.
// These replace the legacy linear `1 - armor/10000` (which hit 0 mitigation at
// armor=10000 and went NEGATIVE — healing the target — beyond it) and the
// linear `evasion/10000` dodge. Seed values from the model (§1/§5); the final
// numbers come from the bot-sim, not the formula.
pub const K_ARMOR: f64 = 2000.0;
pub const K_DODGE: f64 = 1500.0;
/// Default cap on per-tick combat regen, as a fraction of max HP (seed; final
/// from the bot-sim). The `Regeneration_rate` effect fires ~1×/s over an ~8.3s
/// `FIGHT_DURATION` (~8 ticks), so this bounds a fight's combat regen to
/// ≈0.16×HP ⇒ ≈×1.16 EHP. The power scalar's regen-as-EHP is **derived from this
/// same value** (`power_from_attrs`, SC-1 fix) so display/matchmaking can't over-
/// rate what combat delivers — there is no separate scalar regen cap any more.
pub const REGEN_TICK_MAX_PCT: f64 = 0.02;
/// Per-tick caps for HoT/DoT effects, as a fraction of max HP — safety so a
/// mis-tuned ability effect can't out-heal all damage (HoT) or one-shot (DoT).
/// Generous (these are ability-derived, already bounded by ability balance); the
/// cap only catches pathological values. Seed; sim-calibrated.
pub const HOT_TICK_MAX_PCT: f64 = 0.25;
pub const DOT_TICK_MAX_PCT: f64 = 0.50;
/// Minimum `received_damage` multiplier (in /10000 units) so heavy mitigation
/// (e.g. stacked `protection`) can't reach ≤0 → unkillable. 100 ⇒ ≤99% reduction.
pub const MIN_RECEIVED_DAMAGE_K: f64 = 100.0;
/// Floor on a stat's `.mod` multiplier in `get_entity_stat`, so a stacking
/// `.mod` debuff (e.g. `weakness` on attack, `protection` on received_damage)
/// can't drive a stat to ≤0 (zero-damage / unkillable). 0.05 ⇒ ≤95% debuff.
/// Only bites at mod ≤ −9500; no-mod / buff stats are unaffected.
pub const MIN_STAT_MOD_MULT: f64 = 0.05;

/// Power-scalar normalisation. Anchors a reference character
/// (attack=`BASE_ATTACK`, hp=`BASE_HP`, neutral elsewhere) at `BASE_POWER`, so
/// the displayed Combat-Power integer stays on the established scale while the
/// formula underneath is `P = DPS × EHP`. = 600·3000/1000 = 1800.
pub const POWER_NORM: f64 = BASE_ATTACK * BASE_HP / BASE_POWER as f64;

// --- Balance v2: the sim-tunable knob surface --------------------------------
// All the v2 balance "knobs" in one place so a balance change is a one-field
// edit and the bot-sim can SWEEP them with **zero recompile / zero deploy**:
// set the matching `OVERLORD_BAL_*` env var and restart the (cached) monolith.
// Defaults equal the constants above/below, so behaviour is unchanged unless an
// override is provided. Read everywhere via `tuning()`; initialised once at
// process start by `init_tuning` (the binary calls
// `init_tuning(BalanceTuning::from_env())`). Tests don't init → defaults.
#[derive(Clone, Copy, Debug, PartialEq)]
pub struct BalanceTuning {
    /// DR knob for armor mitigation `K/(armor+K)`. Env: `OVERLORD_BAL_K_ARMOR`.
    pub k_armor: f64,
    /// DR knob for dodge/evasion `ev/(ev+K)`. Env: `OVERLORD_BAL_K_DODGE`.
    pub k_dodge: f64,
    /// Power-scalar normaliser. Env: `OVERLORD_BAL_POWER_NORM`.
    pub power_norm: f64,
    /// Last hand-made campaign chapter (formula curve starts above it). Env: `OVERLORD_BAL_ENEMY_ANCHOR_CHAPTER`.
    pub enemy_curve_anchor_chapter: i64,
    /// Enemy power at the anchor chapter. Env: `OVERLORD_BAL_ENEMY_ANCHOR_POWER`.
    pub enemy_curve_anchor_power: f64,
    /// Enemy power geometric step per chapter — the progression gate. Env: `OVERLORD_BAL_ENEMY_STEP`.
    pub chapter_power_step: f64,
    /// Late-game enemy step floor. Past `enemy_step_taper_start` the per-chapter
    /// step decays smoothly from `chapter_power_step` toward this value, so the
    /// difficulty gate tracks the player's DECELERATING late power growth
    /// (~1.12×/ch) instead of staying at the early 1.30 — which out-paced late
    /// power and produced multi-day chapter stalls / a hard wall. With `>=
    /// chapter_power_step` the taper is OFF (closed-form, unchanged). Env:
    /// `OVERLORD_BAL_ENEMY_STEP_LATE`.
    pub enemy_step_late: f64,
    /// Chapter at which the late-step taper begins. Env: `OVERLORD_BAL_ENEMY_STEP_TAPER_START`.
    pub enemy_step_taper_start: i64,
    /// Item sale-price exponent on `eff` (income growth shape). Env: `OVERLORD_BAL_SELL_EXP`.
    pub sell_price_exp: f64,
    /// Item sale-price coefficient. Env: `OVERLORD_BAL_SELL_COEF`.
    pub sell_price_coef: f64,
    /// Soft 3-cycle class-counter swing (PvP). Env: `OVERLORD_BAL_CLASS_SWING`.
    pub class_counter_swing: f64,
    /// Max per-tick combat regen heal as a fraction of max HP — bounds regen in
    /// *combat* (the scalar bound is separate) so high regen can't out-heal all
    /// damage / instant-full a tank. Env: `OVERLORD_BAL_REGEN_TICK_PCT`.
    pub regen_tick_max_pct: f64,
    /// Max per-tick HoT heal as a fraction of max HP. Env: `OVERLORD_BAL_HOT_TICK_PCT`.
    pub hot_tick_max_pct: f64,
    /// Max per-tick DoT damage as a fraction of max HP. Env: `OVERLORD_BAL_DOT_TICK_PCT`.
    pub dot_tick_max_pct: f64,
    /// Early-game stat-check bump strength applied at ch3 (tapering ch4/ch5),
    /// so the first gear conversions are forced. ch2 is left untouched (it is
    /// resource-capped by the 20 starter cookies — a bump there DEADLOCKS, sim-
    /// confirmed). `1.0` = off. Env: `OVERLORD_BAL_ENEMY_EARLY_BUMP`.
    pub enemy_early_bump: f64,
    /// Mid-game boss-only bump applied at ch7–15 to enforce the gear-engagement gate.
    /// Applied exclusively to `CampaignBossFight` in `enemy_power_scalar`; wave fights
    /// are unaffected so the global `enemy_power_for_chapter` curve stays monotone.
    /// At 8.0: a frozen player (stopped at ch5, power ~2121) faces P/E ≈ 0.34 at the
    /// ch7 boss → ~7% first-try win rate; combined with `stop_on_lose=true` on bosses
    /// and the lazy bot not retrying, this creates the hard wall. Engaged players
    /// open more chests between attempts and eventually clear the boss. Tapers to 1.0
    /// at ch16 (one past ability-slot unlock at ch15). `1.0` = off.
    /// Env: `OVERLORD_BAL_ENEMY_MID_BUMP`.
    pub enemy_mid_bump: f64,
    /// `eff_by_level` early-branch (L ≤ 130) coefficient. Env: `OVERLORD_BAL_EFF_A1`.
    pub eff_a1: f64,
    /// `eff_by_level` early-branch exponent — THE early-power shape knob (lower =
    /// flatter early growth, decouples power from level/clock). Env: `OVERLORD_BAL_EFF_B1`.
    pub eff_b1: f64,
    /// `eff_by_level` late-branch (L > 130) coefficient. Env: `OVERLORD_BAL_EFF_A2`.
    pub eff_a2: f64,
    /// `eff_by_level` late-branch exponent (raise above 0.1 so late power keeps
    /// growing instead of plateauing). Env: `OVERLORD_BAL_EFF_B2`.
    pub eff_b2: f64,
    /// `eff_by_level` late-branch offset (re-fit for continuity at L=130). Env: `OVERLORD_BAL_EFF_C2`.
    pub eff_c2: f64,
}

/// Tuning with every knob at its constant default.
pub const BALANCE_TUNING_DEFAULT: BalanceTuning = BalanceTuning {
    k_armor: K_ARMOR,
    k_dodge: K_DODGE,
    power_norm: POWER_NORM,
    enemy_curve_anchor_chapter: ENEMY_CURVE_ANCHOR_CHAPTER,
    enemy_curve_anchor_power: ENEMY_CURVE_ANCHOR_POWER,
    chapter_power_step: CHAPTER_POWER_STEP,
    enemy_step_late: ENEMY_STEP_LATE,
    enemy_step_taper_start: ENEMY_STEP_TAPER_START,
    sell_price_exp: SELL_PRICE_EXP,
    sell_price_coef: SELL_PRICE_COEF,
    class_counter_swing: CLASS_COUNTER_SWING,
    regen_tick_max_pct: REGEN_TICK_MAX_PCT,
    hot_tick_max_pct: HOT_TICK_MAX_PCT,
    dot_tick_max_pct: DOT_TICK_MAX_PCT,
    enemy_early_bump: ENEMY_EARLY_BUMP,
    enemy_mid_bump: ENEMY_MID_BUMP,
    eff_a1: EFF_A1,
    eff_b1: EFF_B1,
    eff_a2: EFF_A2,
    eff_b2: EFF_B2,
    eff_c2: EFF_C2,
};

static BALANCE_TUNING: std::sync::OnceLock<BalanceTuning> = std::sync::OnceLock::new();

/// The process-wide balance tuning (defaults until [`init_tuning`] is called).
/// Hot-path safe — an atomic load of a `&'static`.
#[inline]
pub fn tuning() -> &'static BalanceTuning {
    BALANCE_TUNING.get().unwrap_or(&BALANCE_TUNING_DEFAULT)
}

/// Set the process-wide balance tuning once at startup (first call wins).
pub fn init_tuning(t: BalanceTuning) {
    let _ = BALANCE_TUNING.set(t);
}

impl BalanceTuning {
    /// Defaults, with any `OVERLORD_BAL_*` env var that parses applied on top.
    /// This is the sim-sweep entry point — no recompile, no deploy.
    pub fn from_env() -> Self {
        fn ovr_f(name: &str, cur: f64) -> f64 {
            std::env::var(name)
                .ok()
                .and_then(|v| v.parse().ok())
                .unwrap_or(cur)
        }
        fn ovr_i(name: &str, cur: i64) -> i64 {
            std::env::var(name)
                .ok()
                .and_then(|v| v.parse().ok())
                .unwrap_or(cur)
        }
        let d = BALANCE_TUNING_DEFAULT;
        BalanceTuning {
            // The DR denominators (`K/(R+K)`, `1 − ev/(ev+K)`) and the power
            // normaliser are divisors: a swept value of 0 yields a divide-by-zero
            // (+inf power, i64::MAX, 100%-dodge unkillable) or a 0/0 NaN. The
            // model requires K > 0 for the DR curve to be well-defined, so floor
            // these knobs at a small positive — a sweep then produces a measurable
            // result, never inf/NaN. Defaults (1500/2000/1800) are unaffected.
            k_armor: ovr_f("OVERLORD_BAL_K_ARMOR", d.k_armor).max(1.0),
            k_dodge: ovr_f("OVERLORD_BAL_K_DODGE", d.k_dodge).max(1.0),
            power_norm: ovr_f("OVERLORD_BAL_POWER_NORM", d.power_norm).max(1.0),
            enemy_curve_anchor_chapter: ovr_i(
                "OVERLORD_BAL_ENEMY_ANCHOR_CHAPTER",
                d.enemy_curve_anchor_chapter,
            ),
            enemy_curve_anchor_power: ovr_f(
                "OVERLORD_BAL_ENEMY_ANCHOR_POWER",
                d.enemy_curve_anchor_power,
            ),
            chapter_power_step: ovr_f("OVERLORD_BAL_ENEMY_STEP", d.chapter_power_step),
            enemy_step_late: ovr_f("OVERLORD_BAL_ENEMY_STEP_LATE", d.enemy_step_late),
            enemy_step_taper_start: ovr_i(
                "OVERLORD_BAL_ENEMY_STEP_TAPER_START",
                d.enemy_step_taper_start,
            ),
            sell_price_exp: ovr_f("OVERLORD_BAL_SELL_EXP", d.sell_price_exp),
            sell_price_coef: ovr_f("OVERLORD_BAL_SELL_COEF", d.sell_price_coef),
            class_counter_swing: ovr_f("OVERLORD_BAL_CLASS_SWING", d.class_counter_swing),
            regen_tick_max_pct: ovr_f("OVERLORD_BAL_REGEN_TICK_PCT", d.regen_tick_max_pct),
            hot_tick_max_pct: ovr_f("OVERLORD_BAL_HOT_TICK_PCT", d.hot_tick_max_pct),
            dot_tick_max_pct: ovr_f("OVERLORD_BAL_DOT_TICK_PCT", d.dot_tick_max_pct),
            enemy_early_bump: ovr_f("OVERLORD_BAL_ENEMY_EARLY_BUMP", d.enemy_early_bump),
            enemy_mid_bump: ovr_f("OVERLORD_BAL_ENEMY_MID_BUMP", d.enemy_mid_bump),
            eff_a1: ovr_f("OVERLORD_BAL_EFF_A1", d.eff_a1),
            eff_b1: ovr_f("OVERLORD_BAL_EFF_B1", d.eff_b1),
            eff_a2: ovr_f("OVERLORD_BAL_EFF_A2", d.eff_a2),
            eff_b2: ovr_f("OVERLORD_BAL_EFF_B2", d.eff_b2),
            eff_c2: ovr_f("OVERLORD_BAL_EFF_C2", d.eff_c2),
        }
    }
}

// --- Balance v2: enemy power curve (replaces the inline ad-hoc curve) --------
// Campaign enemy power past the hand-made chapters follows a clean geometric
// curve. Constants live here so the bot-sim can calibrate difficulty (Phase 2)
// without touching `spawn_wave`. The old code floored this and then did an
// *integer* division by `BASE_POWER` for `CampaignFight` (truncating e.g.
// 2268/1000 → 2 instead of 2.268) plus a hand cliff at chapter 44 — both
// removed in v2; difficulty now comes from the curve alone.
//
// Early-game difficulty — smooth ramp redesign (2026-06-30):
//
// PROBLEM (baseline sim, run_1782816662_3050_19844):
//   ch0 (1-1): player=28, enemy=35 (HANDMADE), P/E=0.81 → 50% win rate (must be trivial!)
//   ch4-ch6 (1-5..1-7): P/E=3.5–5.0 → coast-through (inertia / no gear pressure)
//   ch1→ch2 cliff: P/E drops from 2.15 to 0.93 (formula kicks in abruptly at ch2)
//
// FIX: extend the hand-authored region from ch1 to ch6 (chapters 1-1..1-7),
// hand-authoring a SMOOTH taut ramp that:
//   • keeps ch0 (1-1) trivially easy (P/E ~3.5 for a zero-gear fresh player),
//   • brings P/E into the 1.4–2.2 taut band through ch1–ch6, forcing gear engagement,
//   • stays byte-identical to the previous formula for ch7+ (ch10=1509, ch20=20803, ch43=8552484).
//
// ANCHOR MATH: moving the anchor from ch1 to ch6 multiplies anchor_power by 1.30^5.
//   new_anchor_power = 142.3 × 1.30^5 = 528.35
//   The formula for ch > anchor_ch is `anchor_power × STEP^(ch − anchor_ch)`.
//   At ch7: 528.35 × 1.30 = 686 (identical to old formula(7) = 142.3 × 1.30^6 = 686). ✓
//   ch10: 1509, ch20: 20803, ch43: 8552484 — all unchanged.
//
// HAND-AUTHORED RAMP (wave fight power / boss fight power — both set in YAML):
//   ch0 (1-1): wave=8,  boss=10  — trivial (P/E wave≈3.5 / boss≈2.8)
//   ch1 (1-2): wave=60, boss=75  — gentle  (P/E wave≈2.15/ boss≈1.72)
//   ch2 (1-3): wave=100,boss=130 — taut    (P/E wave≈1.84/ boss≈1.42)
//   ch3 (1-4): wave=240,boss=320 — taut    (P/E wave≈1.81/ boss≈1.36)
//   ch4 (1-5): wave=700,boss=900 — taut    (P/E wave≈1.66/ boss≈1.29)
//   ch5 (1-6): wave=1100,boss=1500— taut   (P/E wave≈1.79/ boss≈1.31)
//   ch6 (1-7): wave=1600,boss=2200— taut   (P/E wave≈1.80/ boss≈1.31)
//   ch7 (1-8): first formula chapter; wave=686, boss=6265 (mid-bump gate) — unchanged.
//
// EARLY_BUMP remains 1.0 (off). MID_BUMP at ch7-15 is unchanged at 8.0.
pub const ENEMY_CURVE_ANCHOR_CHAPTER: i64 = 6;
pub const ENEMY_CURVE_ANCHOR_POWER: f64 = 528.35;
// Balance v2 / resource-gate rebalance (2026-06-23): enemy power per chapter —
// the progression gate. It's a race between two geometric curves (enemy power vs
// the bot's gear-driven power). At the old 1.40 step the enemy badly OUTPACED
// the player's late power growth (~1.05–1.08×/ch past ch20), producing a HARD
// wall at ch42-43 where progress stopped dead. The resource-gate model wants
// progress to *never fully stop* — it should slow and become gold/cookie-gated
// (run dry → idle funds the next case upgrade → push on), not slam a power wall.
// Lowering the step to 1.30 keeps the enemy close enough to the (now flatter,
// EFF_B1=1.40) player power that the player keeps creeping forward by upgrading,
// while remaining a real gate (NOT trivial). Sim sweep (`free`, 7d, EFF_B1=1.40):
//   step 1.40 → walls ~ch38   1.30 → reaches ch43-49 (still climbing)   1.28 → ch45-52
// 1.30 + EARLY_BUMP=1.6 lands a firm early game (ch3-5 forced gear) and a smooth,
// never-stuck deceleration. Tunable via `OVERLORD_BAL_ENEMY_STEP`. The free/paid
// gradient now comes more from idle-wait time-skips than raw content depth (per
// the resource-gate design). Re-tune if the player power curve changes.
pub const CHAPTER_POWER_STEP: f64 = 1.30;
// Late-game step taper (2026-06-24, "every returning day must progress"): a
// CONSTANT 1.30 step still out-paces the player's decelerating late power growth
// (~1.12×/ch measured 30-day), so chapters stall multiple days and eventually a
// soft wall forms. Past ENEMY_STEP_TAPER_START the per-chapter step decays
// smoothly toward ENEMY_STEP_LATE so the gate tracks late power → the player
// advances ~daily (power still decelerates, but progress never stops). Defaults
// keep the taper OFF (late == base) so existing curves/tests are unchanged; the
// live values are calibrated by the 30-day sim sweep and baked below.
// SWEEP (free, 30d): no-taper walls ch62 (item-case stuck L11, 6-day hard wall);
// late=1.13→ch83 / 1.10→ch82 / 1.08→ch87, all power-growing EVERY day, item-case
// L18-20, max stall ≤2-3 days (was 6+). Taper begins at ch42 (early game and the
// firm honeymoon are untouched; the decay reaches the floor ~ch67).
// SOFT-PLATEAU TUNE (2026-06-24): lowered 1.12 → 1.10. At 1.12 a CONTINUOUS all-day
// session deep-plateaued — chapters held flat ~2h at the deep wall while only power
// crept (+16%) and cookies drained to 0 (the late step just out-paced the in-session
// power creep). 1.10 lets that slow power-creep keep clearing chapters at the deep
// wall (~1 ch/15min crawl, cookies STILL scarce → "slow progress, few cookies") while
// the real jump still comes next day from AFK (continuous A/B: deep tail 0 → ~5 ch/hr
// nonzero, next-day AFK +79%). Normal 20-min-session cadence barely moves (30-d sweep
// 1.12→ch81 vs 1.10→ch82). Tracks ≈ the player's late power growth ~1.10×/ch.
pub const ENEMY_STEP_LATE: f64 = 1.10;
pub const ENEMY_STEP_TAPER_START: i64 = 42;
/// Mid-game enemy bump — **applied only to CampaignBossFight** (ch7–15).
/// Applied via `OVERLORD_BAL_ENEMY_MID_BUMP`. At 8.0 the boss at ch7 has effective
/// power `687 × STEP^0.5 × 8 ≈ 6265` vs a frozen player's ~2121 (P/E ≈ 0.34 →
/// ~7% first-try win rate), while an engaged player (power ~3274) has P/E ≈ 0.52 —
/// with `stop_on_lose=true` and boss-stop-on-loss retries, even a 50% single-shot
/// rate means the free bot quickly clears it via quest-funded chest opens between attempts,
/// while the lazy bot has no path to more power. Combined with `stop_on_lose=true` on
/// campaign boss fights and the lazy-bot strategy not retrying boss fights, this creates
/// the hard engagement gate: freeze at 1-6, wall at the ch7 boss.
/// Wave fights are unaffected (the bump is applied in `enemy_power_scalar`, not in
/// `enemy_power_for_chapter`), so the global power curve stays monotone.
pub const ENEMY_MID_BUMP: f64 = 8.0;

/// Early-game stat-check bump strength. `1.0` = OFF (current). Was 1.6 (2026-06-23,
/// "too easy early, full HP") but playtest (2026-06-29) found the bump created the
/// opposite problem: stages 1-3..1-5 felt hard and punishing ("cleared by luck",
/// "barely scraped through"), while 1-7+ felt fine. The sim confirmed ch2 (=stage
/// 1-3) already hits P/E=1.24 with min-HP 13% from the hand-made→formula transition
/// alone, and the ch3=1.6x bump pushed ch3 (=stage 1-4) from the clean 1.30x step
/// to a 2.09x step — creating an anomalous hump. Disabled (1.0) so the geometric
/// 1.30x step runs cleanly through early chapters. Tune via `OVERLORD_BAL_ENEMY_EARLY_BUMP`.
pub const ENEMY_EARLY_BUMP: f64 = 1.0;

/// Early-game stat-check bump (playtester: "no pressure until 2-1"). The
/// resource-capped early chapters (the player can only gear so far on the
/// starter + first-quest cookies) get a MODEST lift on top of the geometric
/// line so the first gear conversions are *forced* — a uniform lift instead
/// DEADLOCKED ch2 (sim: enemy×2 → 0% win, the player can't gear past it with
/// 20 starter cookies). Tapers to 1.0 by ch5 so ch6+/ch10+/the validated wall
/// stay byte-identical to the 1.40 curve. Started conservative (the player
/// scalar undercounts true combat power ~4-7×, so the ch2 ceiling is uncertain
/// ~250-400 nominal); climb in-sim only while ch2 win-rate stays > 0.
fn enemy_early_chapter_mult(chapter: i64) -> f64 {
    let bump = tuning().enemy_early_bump;
    if bump <= 1.0 {
        return 1.0;
    }
    // First check at ch3 (quest cookies have unlocked headroom there), tapering
    // to 1.0 by ch6. ch2 stays untouched — it is hard resource-capped by the 20
    // starter cookies and a bump there deadlocks (sim-confirmed).
    match chapter {
        3 => bump,
        4 => 1.0 + (bump - 1.0) * 0.66,
        5 => 1.0 + (bump - 1.0) * 0.33,
        _ => 1.0,
    }
}

/// Mid-game **boss-only** gear-engagement gate (ch7–15). Applied in
/// [`enemy_power_scalar`] only for `CampaignBossFight` (not wave fights), so
/// normal wave progression is unaffected while the boss is the hard gate.
///
/// Why boss-only: applying the bump to wave fights too causes global monotonicity
/// violations in `enemy_power_for_chapter` for any bump > STEP (1.30) — the taper
/// endpoint has mult(last_ch) > 1.0 while the next chapter returns 1.0, creating a
/// downstep. Restricting the bump to bosses avoids that problem entirely.
///
/// With `stop_on_lose=true` on campaign bosses and the lazy bot strategy not retrying
/// (`_retry_boss_if_needed` removed from the frozen action list), one loss = permanent
/// wall. The bump must be large enough that the first-try win probability is low for
/// a frozen player (≤ 10-15%). At bump=8 with STEP=1.30 the boss power at ch7
/// becomes `enemy(7) × STEP^0.5 × 8 = 687 × 1.14 × 8 = 6265` vs lazy power ~2121,
/// P/E ≈ 0.34 → ~7% first-try win rate → ~93% of lazy bots wall on first encounter.
///
/// Tapers linearly from `enemy_mid_bump` at ch7 to 1.0 at ch16. ch6 and below:
/// 1.0 (respects "don't make ch1-5 harder" hard constraint). ch16+: 1.0 (ability-slot
/// system takes over as the engagement lever). 1.0 = off (mid_bump ≤ 1.0 = no gate).
pub(crate) fn enemy_mid_chapter_mult(chapter: i64) -> f64 {
    let bump = tuning().enemy_mid_bump;
    if bump <= 1.0 {
        return 1.0;
    }
    // boss-only bump, ch7-15 (exclusive upper bound ch16 so the taper step
    // within the bumped range is (bump-1)/9, purely internal to boss fights;
    // the monotonicity test for `enemy_power_for_chapter` is unaffected because
    // this function is no longer called from there).
    if !(7..16).contains(&chapter) {
        return 1.0;
    }
    let frac = (16 - chapter) as f64 / (16 - 7) as f64;
    1.0 + (bump - 1.0) * frac
}

/// Absolute enemy power at `chapter`: `ANCHOR · ∏ step(c)`, where the per-chapter
/// step is the constant `chapter_power_step` until `enemy_step_taper_start`, then
/// decays smoothly toward `enemy_step_late` so late-game difficulty tracks the
/// player's decelerating power (no multi-day stalls). With the taper OFF
/// (`enemy_step_late >= chapter_power_step`) this is the original closed form
/// `ANCHOR · STEP^(chapter − ANCHOR_CH)`. A tapering early-chapter bump
/// (see [`enemy_early_chapter_mult`]) multiplies the result.
///
/// Note: the mid-game bump ([`enemy_mid_chapter_mult`]) is NOT applied here — it
/// is applied only to `CampaignBossFight` in [`enemy_power_scalar`], so wave
/// fights and the global power curve remain unaffected (avoids monotonicity
/// violations for large bump values).
pub fn enemy_power_for_chapter(chapter: i64) -> f64 {
    let t = tuning();
    let exp = (chapter - t.enemy_curve_anchor_chapter).max(0);
    let growth = if t.enemy_step_late >= t.chapter_power_step {
        // Taper OFF — closed form (unchanged, preserves all pinned curves/tests).
        t.chapter_power_step.powi(exp as i32)
    } else {
        // Taper ON — cumulative product. step(c) decays from the base step toward
        // the late floor with a fixed half-life past `enemy_step_taper_start`.
        const TAPER_DECAY: f64 = 0.9; // ~base→late over ~25 chapters
        let mut g = 1.0_f64;
        for i in 1..=exp {
            let c = t.enemy_curve_anchor_chapter + i;
            let over = (c - t.enemy_step_taper_start).max(0) as f64;
            let step = t.enemy_step_late
                + (t.chapter_power_step - t.enemy_step_late) * TAPER_DECAY.powf(over);
            g *= step;
        }
        g
    };
    (t.enemy_curve_anchor_power * growth * enemy_early_chapter_mult(chapter)).floor()
}

// --- Balance v2 (Phase 2): gold faucet shaping ------------------------------
// The dominant gold faucet is selling items, priced from an item's effectiveness
// `eff` (which grows ~level^1.58). Left linear in `eff` (the legacy `eff·100`),
// sale income outran the geometric chest-upgrade sink mid/late game, leaving
// gold in runaway surplus so the cost curve never *bound* progression. v2 prices
// items as `eff^SELL_PRICE_EXP · SELL_PRICE_COEF`, flattening the faucet so the
// geometric chest-upgrade sink can bind — `COEF` anchors low-`eff` (early,
// honeymoon) sales at ≈ the legacy value.
// EXP calibrated by the bot-sim (Phase 20): for a `free` bot, gold sink/faucet
// ratio (chest-upgrade spend ÷ sell income) vs EXP — 0.65→0.55, 0.55→0.65,
// 0.45→0.79. 0.45 lands free in the 0.7–1.1 "sink binds" band (gold ~spent, not
// hoarded) with progression intact (still walls ~ch40, ~4M power); lower risks
// faucet < sink → starvation. The whale still front-loads (real-money gold), so
// its surplus is benign per the model ("soft currency in surplus, engineer the
// sink"). Tunable via `OVERLORD_BAL_SELL_EXP`.
pub const SELL_PRICE_EXP: f64 = 0.45;
pub const SELL_PRICE_COEF: f64 = 87.0;

/// Item sale price (sell-currency units) from an item's effectiveness `eff`:
/// `floor(eff^sell_price_exp · sell_price_coef)`. Sub-linear (`exp < 1`) so gold
/// income grows ~linearly with item level and the geometric chest sink can bind
/// (Phase 2). Pure + sim-tunable via [`tuning()`]; the call site is
/// `behaviors::items::item_price`.
pub fn sell_price(eff: f64) -> i64 {
    let t = tuning();
    (eff.max(0.0).powf(t.sell_price_exp) * t.sell_price_coef).floor() as i64
}

/// Per-tick heal/damage cap: `amount` bounded above by `pct × max_hp`. Used by
/// the regen / HoT / DoT combat ticks so a mis-tuned effect can't out-heal all
/// incoming damage (regen/HoT) or one-shot (DoT). Pure + testable; `pct` comes
/// from the matching [`tuning()`] knob (`regen|hot|dot_tick_max_pct`).
pub fn cap_per_tick(amount: f64, max_hp: f64, pct: f64) -> f64 {
    amount.min(max_hp * pct)
}

/// Multiplicative buff/debuff factor from a proc chance `p` (0..1): a buff of
/// strength [`BUFF_EFF`] held for a mean uptime, stacked `quantity` times.
/// Shared by bravery (offensive) and deceit (defensive); preserves the legacy
/// `(1 + (BUFF_EFF−1)·uptime)^quantity` shape exactly.
pub fn buff_uptime_mult(p: f64, quantity: i64, duration: f64) -> f64 {
    if p <= 0.0 {
        return 1.0;
    }
    let uptime = (CASTS_PER_SEC * p * duration / quantity as f64).min(1.0);
    (1.0 + (BUFF_EFF - 1.0) * uptime).powi(quantity as i32)
}

// --- Balance v2 (Phase 5): soft 3-cycle class counter -----------------------
// A soft rock-paper-scissors among the three combat classes —
// Warrior > Rogue > Mage > Warrior — with Priest and Citizen NEUTRAL (the
// model's §11 design: don't force a 4-way cycle). The counter is a ±swing
// damage multiplier in a matchup; it is PvP-only *by construction* because PvE
// mobs carry no class (→ neutral). `±0.15` is a SEED ("soft" per the model,
// vs ≥±0.25–0.40 "strong"); the final per-mode value comes from a per-class
// bot-sim against the 45–55% win-rate corridor (which the current single-class
// bot harness cannot yet measure). Roles are derived from the class's
// `main_attribute` code, so no new config field is needed:
//   block → Warrior, crit_chance → Rogue, multicast_chance → Mage,
//   regeneration_rate (Priest) / hp (Citizen) / anything else → neutral.
pub const CLASS_COUNTER_SWING: f64 = 0.15;

/// 3-cycle combat role from a class's `main_attribute` code.
/// 0 = Warrior, 1 = Rogue, 2 = Mage, -1 = neutral.
pub fn class_counter_role_from_code(main_attr_code: &str) -> i8 {
    match main_attr_code {
        "block" => 0,
        "crit_chance" => 1,
        "multicast_chance" => 2,
        _ => -1,
    }
}

/// Soft 3-cycle damage multiplier for an `attacker` class hitting a `defender`
/// class (both `Option`, resolved via `lookups.class_counter_role`). Returns
/// `1 + CLASS_COUNTER_SWING` when the attacker's role beats the defender's,
/// `1 - CLASS_COUNTER_SWING` when it is beaten, and `1.0` otherwise (same role,
/// either neutral, or a classless PvE mob).
pub fn class_counter_multiplier(
    lookups: &ContentLookups,
    attacker: Option<Uuid>,
    defender: Option<Uuid>,
) -> f64 {
    let (Some(a), Some(d)) = (attacker, defender) else {
        return 1.0;
    };
    let ra = lookups.class_counter_role.get(&a).copied().unwrap_or(-1);
    let rd = lookups.class_counter_role.get(&d).copied().unwrap_or(-1);
    if ra < 0 || rd < 0 || ra == rd {
        return 1.0;
    }
    let swing = tuning().class_counter_swing;
    if rd == (ra + 1) % 3 {
        1.0 + swing // attacker beats defender
    } else if ra == (rd + 1) % 3 {
        1.0 - swing // attacker is countered
    } else {
        1.0
    }
}

/// Pure: stochastic round of a non-integer value.
pub fn rand_round_f64(value: f64, random: &GameRng) -> i64 {
    let base = value.floor();
    let prob = value - base;
    if prob > 0.0 && random.random_f64() < prob {
        return base as i64 + 1;
    }
    base as i64
}

pub fn effect_cost(duration: f64) -> f64 {
    (BUFF_EFF - 1.0) * (SPELL_QUANTITY - 1) as f64 * duration * BASE_SPELL_EFF
}

pub fn effect_duration(cost: f64) -> f64 {
    cost / ((BUFF_EFF - 1.0) * (SPELL_QUANTITY - 1) as f64 * BASE_SPELL_EFF)
}

fn buff_p_from_eff(eff: f64, cast_rate: f64, duration: f64, effects_quantity: i64) -> f64 {
    let uptime_max = (cast_rate * duration / effects_quantity as f64).min(1.0);
    let eff_max = (1.0 + (BUFF_EFF - 1.0) * uptime_max).powi(effects_quantity as i32);
    if eff >= eff_max {
        return 1.0;
    }
    let effect_eff = eff.powf(1.0 / effects_quantity as f64);
    let effect_uptime = ((effect_eff - 1.0) / (BUFF_EFF - 1.0)).max(0.0);
    let p = effect_uptime * effects_quantity as f64 / (cast_rate * duration);
    p.clamp(0.0, 1.0)
}

pub fn bravery_p_from_eff(eff: f64) -> f64 {
    buff_p_from_eff(
        eff,
        CASTS_PER_SEC,
        BRAVERY_BUFF_DURATION,
        BRAVERY_BUFF_QUANTITY,
    )
}

pub fn deceit_p_from_eff(eff: f64) -> f64 {
    buff_p_from_eff(
        eff,
        CASTS_PER_SEC,
        DECEIT_DEBUFF_DURATION,
        DECEIT_DEBUFF_QUANTITY,
    )
}

pub fn attr_spread_random(random: &GameRng) -> f64 {
    1.0 + ATTR_DEVIATION * (2.0 * random.random_f64() - 1.0)
}

pub fn hp_k_for_level(level: f64) -> f64 {
    const ALL_SPELLS_LEVEL: f64 = 30.0;
    if level > ALL_SPELLS_LEVEL {
        return 1.0;
    }
    ((level - 1.0) / (ALL_SPELLS_LEVEL - 1.0) * (SPELL_QUANTITY - 1) as f64 + 1.0)
        / SPELL_QUANTITY as f64
}

// `eff_by_level` curve constants (item effectiveness vs item level). Two
// branches joined at L=130: a steep early power-law and a flat late power-law.
// Promoted to module consts + the `tuning()` surface so the bot-sim can sweep
// the early-power SHAPE (`EFF_B1`) without a recompile — the keystone of the
// resource-gate rebalance (item level tracks the level/clock, so this curve,
// not the economy, sets how fast power grows early). Defaults below reproduce
// the legacy curve byte-for-byte. The L>130 branch must stay continuous with
// the L≤130 branch at L=130 (value + slope) when these are re-tuned.
// Resource-gate rebalance (2026-06-23): the early exponent B1 is lowered
// 1.5833 → 1.40 to FLATTEN early power growth (item level tracks the level/clock,
// so this curve — not the economy — sets how fast power grows early). With the
// gear-eff→power exponent k≈1 (each item's attack & hp scale as eff^0.5, so
// P=DPS·EHP ∝ eff^1; the quadratic S² is the separate SPELL axis), dropping B1
// maps ~1:1 into power. Sim: ch10 power 37k → ~16k (target 12-18k), killing the
// "tens of thousands of power in the first 10 min" complaint. A1 is UNCHANGED so
// eff drops at every L>2 (no mid-curve bulge). The late branch (A2,B2,C2) is
// re-fit for value+slope continuity at L=130 with B2 raised 0.1 → 0.40 so late
// power keeps climbing (no far-late plateau / "fighting never stops"). Closed
// form (verified): V=A1·129^B1+1=98.52, S=A1·B1·129^(B1-1)=1.0583,
// A2=S·130^(1-B2)/B2=49.08, C2=V-A2·130^B2=-245.40. All sim-tunable via
// OVERLORD_BAL_EFF_*; re-derive A2/C2 if B1 or B2 move.
pub const EFF_MIDGAME_LEVEL: f64 = 130.0;
pub const EFF_A1: f64 = 0.1082166549;
pub const EFF_B1: f64 = 1.40;
pub const EFF_C1: f64 = 1.0;
pub const EFF_A2: f64 = 49.08;
pub const EFF_B2: f64 = 0.40;
pub const EFF_C2: f64 = -245.40;

pub fn eff_by_level(level: f64) -> f64 {
    let t = tuning();
    if level <= EFF_MIDGAME_LEVEL {
        t.eff_a1 * (level - 1.0).powf(t.eff_b1) + EFF_C1
    } else {
        t.eff_a2 * level.powf(t.eff_b2) + t.eff_c2
    }
}

pub fn item_q_by_day(day: f64) -> f64 {
    const A: f64 = 1.369248467;
    const B: f64 = 1.986;
    const C: f64 = 1.00;
    A * (B * day + 1.0).ln() + C
}

pub fn day_by_level(level: f64) -> f64 {
    const A1: f64 = 13.95171732;
    const A2: f64 = 0.5784426942;
    const A3: f64 = 1.00;
    ((level - A3) / A1).powf(1.0 / A2)
}

pub fn level_by_day(day: f64) -> f64 {
    const A1: f64 = 13.95171732;
    const A2: f64 = 0.5784426942;
    const A3: f64 = 1.00;
    A1 * day.powf(A2) + A3
}

pub fn eff_spell_by_level(level: f64) -> f64 {
    const S1: f64 = 0.36536535;
    const S2: f64 = 0.525009219;
    const S3: f64 = 1.0;
    let day = day_by_level(level);
    S1 * day.powf(S2) + S3
}

pub fn armor_k(armor: f64) -> f64 {
    // Balance v2: fraction of incoming damage that PASSES the target's armor,
    // via the DR curve `K_ARMOR/(armor+K_ARMOR)`. Always in (0, 1] for
    // armor ≥ 0. Replaces the old linear `1 - armor/10000`, which reached 0 at
    // armor=10000 and went negative beyond it (a real shipped bug).
    let k = tuning().k_armor;
    k / (armor.max(0.0) + k)
}

/// Enemy "power" scalar for a fight — the value `spawn_wave` feeds into the
/// HP/attack curve, and the apples-to-apples counterpart of the player's
/// `character.power` (both normalized to [`BASE_POWER`]). For campaign fights:
/// at/below the anchor chapter it is the hand-authored `FightTemplate.power`
/// (`base_power`); above it the rebalanced geometric curve
/// ([`enemy_power_for_chapter`], which carries the sweepable anchor/step + the
/// early-chapter bump), with a boss bump. For DUNGEON fights it is always the
/// authored per-difficulty `base_power` (see below). Shared so the battle-end
/// analytics report exactly the value the fight spawned.
pub fn enemy_power_scalar(
    base_power: f64,
    current_chapter: i64,
    fight_type: &str,
    is_dungeon: bool,
) -> f64 {
    let t = tuning();
    // Dungeons are a self-contained difficulty LADDER: enemy power is the
    // authored per-difficulty `base_power` (the chosen difficulty's
    // `FightTemplate.power`, ramping e.g. 1500 → 600M across the levels), NOT the
    // campaign chapter curve. Dungeon fights are tagged `CampaignBossFight` (for
    // boss talents/visuals), so without this guard they fall into the chapter-curve
    // branch below — collapsing every difficulty to one power keyed to the player's
    // campaign chapter (the regression where the ladder does nothing and difficulty
    // 1 is a full-chapter boss → "losing to the dungeon at unlock"). Honor the
    // authored ladder so low difficulties are an easy first clear and the player
    // climbs as their power grows.
    if is_dungeon {
        return base_power;
    }
    if (fight_type == "CampaignFight" || fight_type == "CampaignBossFight")
        && current_chapter > t.enemy_curve_anchor_chapter
    {
        let power = enemy_power_for_chapter(current_chapter);
        if fight_type == "CampaignBossFight" {
            // Boss bump: the standard ×STEP^0.5 difficulty lift, plus the mid-game
            // gear-engagement gate (ch7–15) that forces frozen players to wall here.
            // The mid-gate is BOSS-ONLY so wave fights stay unaffected and the global
            // `enemy_power_for_chapter` curve stays monotone (no mid-mult there).
            power * t.chapter_power_step.powf(0.5) * enemy_mid_chapter_mult(current_chapter)
        } else {
            power
        }
    } else {
        base_power
    }
}

pub fn hp_k_for_chapter(config: &GameConfig, chapter: i64) -> f64 {
    let mut reached: Vec<_> = config
        .ability_slots_levels
        .iter()
        .filter(|item| chapter >= item.from_chapter_level)
        .collect();
    reached.sort_by_key(|b| std::cmp::Reverse(b.from_chapter_level));

    if reached.is_empty() {
        return 1.0 / SPELL_QUANTITY as f64;
    }
    let current = reached[0];
    if current.ability_slots == (SPELL_QUANTITY - 1) as u64 {
        return 1.0;
    }
    let mut unreached: Vec<_> = config
        .ability_slots_levels
        .iter()
        .filter(|item| chapter < item.from_chapter_level)
        .collect();
    unreached.sort_by_key(|a| a.from_chapter_level);
    if unreached.is_empty() {
        return 1.0;
    }
    let next = unreached[0];
    let mean_ability_slots = current.ability_slots as f64
        + (chapter - current.from_chapter_level) as f64
            / (next.from_chapter_level - current.from_chapter_level) as f64
        + 1.0;
    mean_ability_slots / SPELL_QUANTITY as f64
}

/// `attrs.get_attr(name)`: read the composed attribute value from an attribute map.
/// Returns `(base + bonus) * (1 + bonus / 10000.0)`.
///
/// of `mod` in the multiplier. We preserve the original behaviour byte-for-byte
/// so power calculations stay consistent with the current production config.
///
/// `attrs.get_attr(...)` method (registered for scripts that still pass a
pub fn get_attr_from_attrs(attrs: &AttrMap, attr: &str) -> f64 {
    let base = attrs.get(attr).copied().unwrap_or(0.0);
    let bonus = attrs.get(&format!("{attr}.bonus")).copied().unwrap_or(0.0);
    // Balance v2: match combat's `get_entity_stat` — additive `.bonus`, then the
    // `.mod` multiplier `(1 + mod/10000)`. The old code used `.bonus` in the
    // multiplier too (a self-multiply bug) and ignored `.mod` entirely, so the
    // power scalar disagreed with combat (e.g. `attack.mod`/`hp.mod` from
    // class-levels never affected displayed/matchmaking power). (Base-value —
    // e.g. received_damage's 10000 — is still combat-only: the scalar has no
    // `lookups` here; tracked as a remaining scalar↔combat gap.)
    let mod_v = attrs.get(&format!("{attr}.mod")).copied().unwrap_or(0.0) / 10000.0 + 1.0;
    (base + bonus) * mod_v
}

pub fn ability_eff(lookups: &ContentLookups, rarity_id: Uuid, level: i64) -> f64 {
    let rarity_eff = lookups
        .ability_rarity_eff
        .get(&rarity_id)
        .copied()
        .unwrap_or(1.0);
    let level_eff = 1.0 + 0.05 * (level - 1) as f64;
    rarity_eff * level_eff
}

pub fn ability_damage_from_rarity(
    lookups: &ContentLookups,
    rarity_id: Uuid,
    cooldown_ms: i64,
    level: i64,
) -> f64 {
    let eff = ability_eff(lookups, rarity_id, level);
    let cd = cooldown_ms as f64 / 1000.0;
    let k = FIGHT_DURATION / (FIGHT_DURATION + cd);
    eff * k * BASE_SPELL_EFF * cd
}

pub fn ability_damage_from_id(
    config: &GameConfig,
    lookups: &ContentLookups,
    ability_id: Uuid,
    level: i64,
) -> Result<f64, String> {
    let ability = config
        .ability_template(ability_id)
        .ok_or_else(|| format!("balance::ability_damage: unknown ability id {ability_id}"))?;
    Ok(ability_damage_from_rarity(
        lookups,
        ability.rarity_id,
        ability.cooldown as i64,
        level,
    ))
}

pub fn mean_fight_duration(config: &GameConfig, ability_id: Uuid) -> Result<f64, String> {
    let ability = config
        .ability_template(ability_id)
        .ok_or_else(|| format!("balance::mean_fight_duration: unknown ability id {ability_id}"))?;
    let cooldown = ability.cooldown as f64 / 1000.0;
    let mut time = cooldown;
    let mut sum_remaining = 0.0;
    let mut casts = 0.0;
    while time <= FIGHT_DURATION {
        sum_remaining += FIGHT_DURATION - time;
        casts += 1.0;
        time += cooldown;
    }
    if casts == 0.0 {
        return Ok(FIGHT_DURATION);
    }
    Ok(sum_remaining / casts)
}

pub fn eff_item_with_config(
    config: &GameConfig,
    lookups: &ContentLookups,
    item_template_id: Uuid,
    level: f64,
) -> f64 {
    let rarity_q = config
        .item_template(item_template_id)
        .and_then(|tpl| lookups.item_rarity_q.get(&tpl.rarity_id).copied())
        .unwrap_or(1.0);
    eff_by_level(level) * rarity_q
}

pub fn attr_spread_for_item(
    config: &GameConfig,
    lookups: &ContentLookups,
    random: &GameRng,
    template_id: Uuid,
    level: f64,
) -> f64 {
    if let Some(fp) = lookups.item_fixed_power.get(&template_id) {
        return *fp;
    }
    if (level - 1.0).abs() < f64::EPSILON {
        return 0.65;
    }
    if level <= 25.0 {
        return attr_spread_random(random);
    }

    let side = random.random_f64();
    let u = random.random_f64();
    let fake_level = if side < 0.5625 {
        level - u.powi(2)
    } else {
        level + 3.0 * u.powi(6)
    };
    let fake_eff = eff_item_with_config(config, lookups, template_id, fake_level);
    let real_eff = eff_item_with_config(config, lookups, template_id, level);
    if real_eff == 0.0 {
        return 1.0;
    }
    fake_eff / real_eff
}

pub fn aux_attr_eff(base_eff: f64, random: &GameRng) -> f64 {
    let rand_mod = attr_spread_random(random);
    (base_eff * rand_mod).powf(AUX_ATTR_IMPACT)
}

pub fn aux_attr_eff_for_item(
    config: &GameConfig,
    lookups: &ContentLookups,
    base_eff: f64,
    random: &GameRng,
    template_id: Uuid,
    level: f64,
) -> f64 {
    let rand_mod = attr_spread_for_item(config, lookups, random, template_id, level);
    (base_eff * rand_mod).powf(AUX_ATTR_IMPACT)
}

/// Compute character power from a composed [`AttrMap`] as **P = DPS × EHP**
/// (balance v2). `DPS` is the offensive product (attack · rate · crit ·
/// multicast · bravery · counterattack); `EHP` the survivability product
/// (hp ÷ the damage that gets through), where armor and dodge use the
/// diminishing-returns curves [`armor_k`] and `ev/(ev+K_DODGE)`. Normalised by
/// [`POWER_NORM`] so a reference character (attack=`BASE_ATTACK`, hp=`BASE_HP`,
/// neutral elsewhere) anchors at [`BASE_POWER`]. Replaces the legacy opaque
/// `S²`-style formula; every factor maps 1:1 to the old one except armor and
/// evasion, which move from a linear cap to a DR curve.
///
/// **Float-accumulation order is load-bearing** (see [`character_attrs_power`]):
/// the per-attribute reads happen in a fixed order so the floored result is
/// deterministic.
pub fn power_from_attrs(attrs: &AttrMap) -> i64 {
    const BASE_POINT: f64 = 10000.0; // attribute basis points: 10000 == 1.0 / 100%

    // ---- offensive: DPS ----
    let attack = get_attr_from_attrs(attrs, "attack");
    // speed → cast rate, mirroring combat's `scale_cooldown_for_speed` (cooldown ∝
    // baseline/speed ⇒ rate ∝ speed/baseline, baseline_speed = BASE_POINT). Combat treats
    // `speed ≤ 0` as the baseline (`speed_or_baseline`), so the scalar must too — else a
    // speed-less build reads as 0 DPS here while combat still attacks at the baseline rate.
    let speed = get_attr_from_attrs(attrs, "speed");
    let atk_rate = if speed > 0.0 { speed / BASE_POINT } else { 1.0 };
    // Probability stats are clamped to [0,1] — a chance can't exceed 100%.
    // Without this, large (e.g. class-level) grants overflow the basis-point
    // cap and break the formula (e.g. block>1 → `1−0.5·block` negative → power
    // goes negative). Combat's `stat_throw` already saturates a proc at 100%.
    let crit_chance = (get_attr_from_attrs(attrs, "crit_chance") / BASE_POINT).clamp(0.0, 1.0);
    let crit_damage_mod = BASE_CRIT_MOD + get_attr_from_attrs(attrs, "crit_modifier") / BASE_POINT;
    let crit_factor = 1.0 + crit_chance * (crit_damage_mod - 1.0);
    let multicast_factor =
        1.0 + (get_attr_from_attrs(attrs, "multicast_chance") / BASE_POINT).clamp(0.0, 1.0);
    let bravery_factor = buff_uptime_mult(
        get_attr_from_attrs(attrs, "bravery") / BASE_POINT,
        BRAVERY_BUFF_QUANTITY,
        BRAVERY_BUFF_DURATION,
    );

    let mut dps = attack * atk_rate * crit_factor * multicast_factor * bravery_factor;

    // counterattack: retaliatory damage relative to a fight's baseline output
    // (same additive shape as the legacy formula).
    let counterattack_chance =
        (get_attr_from_attrs(attrs, "counterattack_chance") / BASE_POINT).clamp(0.0, 1.0);
    let counterattack_dmg =
        FIGHT_DURATION * ATTACKS_PER_SEC * COUNTERATTACK_POWER * counterattack_chance;
    let baseline_dmg =
        FIGHT_DURATION * SPELL_QUANTITY as f64 / armor_k(get_attr_from_attrs(attrs, "armor"));
    if baseline_dmg > 0.0 {
        dps *= (baseline_dmg + counterattack_dmg) / baseline_dmg;
    }

    // ---- defensive: EHP = hp ÷ (fraction of damage that gets through) ----
    // Via get_attr_from_attrs so hp.bonus/hp.mod count (consistent with combat),
    // not the raw value the old scalar read.
    let hp = get_attr_from_attrs(attrs, "hp");
    let mut ehp = hp;
    // armor mitigation (DR via `armor_k`): divide by the damage-through fraction.
    ehp /= armor_k(get_attr_from_attrs(attrs, "armor"));
    // dodge (evasion rating) via DR: avoid prob = ev/(ev+K_DODGE), asymptote < 1.
    let evasion = get_attr_from_attrs(attrs, "evasion").max(0.0);
    ehp /= 1.0 - evasion / (evasion + tuning().k_dodge);
    // block: halves damage on proc → expected damage multiplier (1 − 0.5·p),
    // p clamped to [0,1] (max ×2 EHP at always-block).
    let block_chance = (get_attr_from_attrs(attrs, "block") / BASE_POINT).clamp(0.0, 1.0);
    ehp /= 1.0 - 0.5 * block_chance;
    // received_damage: a damage-taken multiplier (base BASE_POINT = 100% taken); combat
    // applies it in `damage_entity`, so the scalar must too or it under-counts mitigation
    // EHP (a build with persistent `received_damage` reduction reads weaker than it fights).
    // The scalar has no `lookups` for the base, so BASE_POINT is added explicitly here;
    // floored like combat (`MIN_RECEIVED_DAMAGE_K`) so it can't reach ≤0. Neutral → ×1.
    let received_damage =
        (BASE_POINT + get_attr_from_attrs(attrs, "received_damage")).max(MIN_RECEIVED_DAMAGE_K);
    ehp *= BASE_POINT / received_damage;
    // regen-as-EHP, derived to MATCH combat (SC-1 fix). Combat heals at most
    // `regen_tick_max_pct × max_hp` per ~1s tick (`regeneration_tick`), so over a fight it
    // delivers `FIGHT_DURATION × min(regen_rate, regen_tick_max_pct × hp)`. The old
    // independent `≤1×hp` cap let the scalar credit up to ×2 EHP while combat delivers only
    // ~×1.16 — over-rating high-regen builds' displayed/matchmaking power by ~70%. Uses the
    // SAME `tuning().regen_tick_max_pct` knob as combat, so the two can never desync.
    // (This also makes regen structurally weaker EHP than block — a real combat-balance fact
    // the old scalar hid; closing the Priest-competitiveness gap is a separate sim/design pass.)
    let regen_per_sec = get_attr_from_attrs(attrs, "regeneration_rate")
        .min(hp.max(0.0) * tuning().regen_tick_max_pct);
    let regen_per_fight = regen_per_sec * FIGHT_DURATION;
    if hp != 0.0 {
        ehp *= (hp + regen_per_fight) / hp;
    }
    // deceit: debuffs the enemy → effective survivability gain (legacy shape).
    ehp *= buff_uptime_mult(
        get_attr_from_attrs(attrs, "deceit") / BASE_POINT,
        DECEIT_DEBUFF_QUANTITY,
        DECEIT_DEBUFF_DURATION,
    );

    ((dps * ehp) / tuning().power_norm).floor() as i64
}

///
/// references. The previous version accepted either real essences structs (the
/// into these typed inputs and then calls this exact function — so results are
/// byte-identical on both paths.
///
/// **Accumulation order is load-bearing** (per-key float sums): char-level
/// attributes, then inventory items (each item's attributes in order), then
/// pets (in the given slice order, each pet's stats in order). Abilities are
/// summed slotted-then-unslotted, matching the original.
pub fn character_power(
    config: &GameConfig,
    lookups: &ContentLookups,
    level: i64,
    inventory: &[Item],
    abilities: &EquippedAbilities,
    pets: &[Pet],
) -> Result<i64, String> {
    let attrs_power = character_attrs_power(config, level, inventory, pets)?;

    // Abilities: slotted (BTreeMap value order) then unslotted, matching the
    // original `.slotted.into_values()` / `.unslotted` iteration order.
    let mut ability_eff_sum = 0.0;
    for ability in abilities.slotted.values().chain(abilities.unslotted.iter()) {
        let Ability {
            template_id, level, ..
        } = ability;
        if let Some(tpl) = config.ability_template(*template_id) {
            ability_eff_sum += ability_eff(lookups, tpl.rarity_id, *level);
        }
    }

    Ok((attrs_power as f64 * ability_eff_sum).floor() as i64)
}

/// Combat-power scalar from an already-composed [`AttrMap`] plus equipped
/// abilities — `floor(power_from_attrs(attrs) × Σ ability_eff)`.
///
/// Balance v2 (Phase 4 fix): lets the display / matchmaking / gating path feed
/// the **full** multi-source aggregation
/// (`attributes::calculate_player_entity_stats_with_zeroes` — char-level, items,
/// class, pets, talents, statue, class-levels) through the same formula, so the
/// power scalar reflects every combat source. [`character_power`] keeps the
/// items+pets subset for *marginal* gear-compare, where the constant
/// class/talent/statue baseline cancels in the with-minus-without difference.
pub fn character_power_from_attrs(
    config: &GameConfig,
    lookups: &ContentLookups,
    attrs: &AttrMap,
    abilities: &EquippedAbilities,
) -> i64 {
    let attrs_power = power_from_attrs(attrs);
    let mut ability_eff_sum = 0.0;
    for ability in abilities.slotted.values().chain(abilities.unslotted.iter()) {
        if let Some(tpl) = config.ability_template(ability.template_id) {
            ability_eff_sum += ability_eff(lookups, tpl.rarity_id, ability.level);
        }
    }
    (attrs_power as f64 * ability_eff_sum).floor() as i64
}

/// The `attrs_power` term of [`character_power`]: char-level attributes,
/// inventory items and pet stats composed into an [`AttrMap`] and run through
/// [`power_from_attrs`] — WITHOUT the trailing `* ability_eff_sum` multiplier.
///
/// **Accumulation order is load-bearing** (per-key float sums): char-level
/// attributes, then inventory items (each item's attributes in order), then
/// pets (in the given slice order, each pet's stats in order) — exactly the
/// order the original used; [`character_power`] delegates here so both paths
/// stay byte-identical.
///
/// For callers comparing loadouts that carry no abilities of their own (e.g.
/// ranking pets for fast-equip), where [`character_power`]'s ability factor
/// would multiply every score by 0.
pub fn character_attrs_power(
    config: &GameConfig,
    level: i64,
    inventory: &[Item],
    pets: &[Pet],
) -> Result<i64, String> {
    let mut collected: AttrMap = AttrMap::new();

    let Some(char_level_tpl) = config.character_level(level) else {
        return Err(format!(
            "balance::character_power: missing character_level {level}"
        ));
    };

    for attr in &char_level_tpl.attributes {
        if let Some(a) = config.attribute(attr.attribute_id) {
            // Original: `collected.insert(code, value)` — an unconditional
            // overwrite (NOT accumulate). If two char-level entries share a
            // code, the later one wins. Preserve that exactly with `insert`.
            collected.insert(a.code.as_str().to_string(), attr.value as f64);
        }
    }

    // Sum the per-item power jitter alongside attribute accumulation. Items that
    // were rolled before the jitter feature (or arena bots) carry power_bonus=0,
    // so they are unaffected by this sum.
    let mut total_power_bonus: i64 = 0;

    for item in inventory {
        for item_attr in &item.attributes {
            if let Some(a) = config.attribute(item_attr.attr_id) {
                accumulate(&mut collected, a.code.as_str(), item_attr.value as f64);
            }
        }
        total_power_bonus += item.power_bonus as i64;
    }

    for pet in pets {
        for stat in &pet.stats {
            if let Some(a) = config.attribute(stat.attribute_id) {
                accumulate(&mut collected, a.code.as_str(), stat.value as f64);
            }
        }
    }

    Ok(power_from_attrs(&collected) + total_power_bonus)
}

#[cfg(test)]
mod attr_spread_tests {
    //! Deterministic equivalence tests for the branchy `attr_spread_for_item`
    //! (the RNG-driven primitive behind every item-attribute calc). Driven by
    //! `GameRng::from_values` so they prove formula + *draw count* without
    //! any sim entropy. Draw count is load-bearing for determinism — the random
    //! seed advances per draw — so each branch asserts how many draws it consumes.

    use super::*;

    /// A template id that is NOT in `item_fixed_power`, so the fixed-power early
    /// return never fires.
    fn non_fixed_template() -> Uuid {
        Uuid::from_u128(0x0194d64e_2100_7569_91be_a3d34c967544)
    }

    /// Count of `f64` draws a recording RNG sees after one `attr_spread_for_item`.
    fn draws_for(level: f64) -> usize {
        let cfg = configs::tests_game_config::generate_game_config_for_tests();
        let lk = ContentLookups::default();
        let rng = GameRng::from_entropy_recording();
        let _ = attr_spread_for_item(&cfg, &lk, &rng, non_fixed_template(), level);
        rng.recorded().len()
    }

    #[test]
    fn level_one_is_constant_065_and_draws_nothing() {
        let cfg = configs::tests_game_config::generate_game_config_for_tests();
        let lk = ContentLookups::default();
        let rng = GameRng::from_values(vec![0.5]);
        let v = attr_spread_for_item(&cfg, &lk, &rng, non_fixed_template(), 1.0);
        assert_eq!(v, 0.65);
        assert_eq!(draws_for(1.0), 0, "level==1 must consume no RNG draws");
    }

    #[test]
    fn level_le_25_uses_one_draw_via_attr_spread_random() {
        let cfg = configs::tests_game_config::generate_game_config_for_tests();
        let lk = ContentLookups::default();
        // attr_spread_random(r) = 1 + ATTR_DEVIATION*(2*r - 1). r=0.5 -> 1.0.
        let rng = GameRng::from_values(vec![0.5]);
        let v = attr_spread_for_item(&cfg, &lk, &rng, non_fixed_template(), 25.0);
        assert!((v - 1.0).abs() < 1e-12, "expected 1.0, got {v}");
        // r=0.0 -> 1 - ATTR_DEVIATION; r=1.0 -> 1 + ATTR_DEVIATION.
        let rng = GameRng::from_values(vec![0.0]);
        let v = attr_spread_for_item(&cfg, &lk, &rng, non_fixed_template(), 10.0);
        assert!((v - (1.0 - ATTR_DEVIATION)).abs() < 1e-12);
        assert_eq!(
            draws_for(25.0),
            1,
            "level<=25 must consume exactly one draw"
        );
    }

    #[test]
    fn level_gt_25_uses_two_draws_lower_branch() {
        // side < 0.5625 -> fake_level = level - u^2 (lower branch).
        let cfg = configs::tests_game_config::generate_game_config_for_tests();
        let lk = ContentLookups::default();
        let level = 100.0;
        let side = 0.1; // < 0.5625
        let u = 0.3;
        let rng = GameRng::from_values(vec![side, u]);
        let v = attr_spread_for_item(&cfg, &lk, &rng, non_fixed_template(), level);

        // Reproduce the expected ratio with the same default config (rarity_q=1).
        let fake_level = level - u.powi(2);
        let fake_eff = eff_item_with_config(&cfg, &lk, non_fixed_template(), fake_level);
        let real_eff = eff_item_with_config(&cfg, &lk, non_fixed_template(), level);
        let expected = fake_eff / real_eff;
        assert!((v - expected).abs() < 1e-12, "expected {expected}, got {v}");
        assert_eq!(
            draws_for(level),
            2,
            "level>25 must consume exactly two draws"
        );
    }

    #[test]
    fn level_gt_25_uses_two_draws_upper_branch() {
        // side >= 0.5625 -> fake_level = level + 3*u^6 (upper branch).
        let cfg = configs::tests_game_config::generate_game_config_for_tests();
        let lk = ContentLookups::default();
        let level = 100.0;
        let side = 0.9; // >= 0.5625
        let u = 0.4;
        let rng = GameRng::from_values(vec![side, u]);
        let v = attr_spread_for_item(&cfg, &lk, &rng, non_fixed_template(), level);

        let fake_level = level + 3.0 * u.powi(6);
        let fake_eff = eff_item_with_config(&cfg, &lk, non_fixed_template(), fake_level);
        let real_eff = eff_item_with_config(&cfg, &lk, non_fixed_template(), level);
        let expected = fake_eff / real_eff;
        assert!((v - expected).abs() < 1e-12, "expected {expected}, got {v}");
    }

    #[test]
    fn fixed_power_short_circuits_and_draws_nothing() {
        let cfg = configs::tests_game_config::generate_game_config_for_tests();
        let mut lk = ContentLookups::default();
        let tpl = non_fixed_template();
        lk.item_fixed_power.insert(tpl, 1.23);
        let rng = GameRng::from_entropy_recording();
        let v = attr_spread_for_item(&cfg, &lk, &rng, tpl, 100.0);
        assert_eq!(v, 1.23);
        assert_eq!(
            rng.recorded().len(),
            0,
            "fixed-power path must not draw RNG"
        );
    }
}

#[cfg(test)]
mod class_counter_tests {
    //! The soft 3-cycle class counter (Warrior>Rogue>Mage>Warrior, Priest/Citizen
    //! neutral). Roles are stored on `ContentLookups`; here we build them by hand.
    use super::*;
    use std::collections::HashMap;

    fn lookups_with_roles() -> (ContentLookups, Uuid, Uuid, Uuid, Uuid) {
        let (w, r, m, p) = (
            Uuid::from_u128(1),
            Uuid::from_u128(2),
            Uuid::from_u128(3),
            Uuid::from_u128(4),
        );
        let lk = ContentLookups {
            class_counter_role: HashMap::from([(w, 0i8), (r, 1), (m, 2), (p, -1)]),
            ..Default::default()
        };
        (lk, w, r, m, p)
    }

    #[test]
    fn role_from_main_attribute_code() {
        assert_eq!(class_counter_role_from_code("block"), 0); // Warrior
        assert_eq!(class_counter_role_from_code("crit_chance"), 1); // Rogue
        assert_eq!(class_counter_role_from_code("multicast_chance"), 2); // Mage
        assert_eq!(class_counter_role_from_code("regeneration_rate"), -1); // Priest
        assert_eq!(class_counter_role_from_code("hp"), -1); // Citizen
    }

    #[test]
    fn three_cycle_swings() {
        let (lk, w, r, m, _p) = lookups_with_roles();
        let up = 1.0 + CLASS_COUNTER_SWING;
        let down = 1.0 - CLASS_COUNTER_SWING;
        // W>R>M>W
        assert!((class_counter_multiplier(&lk, Some(w), Some(r)) - up).abs() < 1e-9);
        assert!((class_counter_multiplier(&lk, Some(r), Some(m)) - up).abs() < 1e-9);
        assert!((class_counter_multiplier(&lk, Some(m), Some(w)) - up).abs() < 1e-9);
        // reverse direction is countered
        assert!((class_counter_multiplier(&lk, Some(r), Some(w)) - down).abs() < 1e-9);
        assert!((class_counter_multiplier(&lk, Some(m), Some(r)) - down).abs() < 1e-9);
        assert!((class_counter_multiplier(&lk, Some(w), Some(m)) - down).abs() < 1e-9);
    }

    #[test]
    fn neutral_and_pve_are_unity() {
        let (lk, w, _r, _m, p) = lookups_with_roles();
        // Priest is neutral both ways.
        assert_eq!(class_counter_multiplier(&lk, Some(p), Some(w)), 1.0);
        assert_eq!(class_counter_multiplier(&lk, Some(w), Some(p)), 1.0);
        // Same class → no swing.
        assert_eq!(class_counter_multiplier(&lk, Some(w), Some(w)), 1.0);
        // PvE: a classless mob (None) → no swing in either slot.
        assert_eq!(class_counter_multiplier(&lk, Some(w), None), 1.0);
        assert_eq!(class_counter_multiplier(&lk, None, Some(w)), 1.0);
        // Unknown class id (not in the map) → neutral.
        assert_eq!(
            class_counter_multiplier(&lk, Some(Uuid::from_u128(99)), Some(w)),
            1.0
        );
    }
}

#[cfg(test)]
mod power_formula_tests {
    //! Pins `power_from_attrs` to the **v2 P = DPS × EHP** formula with DR
    //! curves, so a regression to the legacy opaque `S²` formula FAILS here
    //! (the two give different numbers for the same loadout). This is the proof
    //! that the new combat-power formula is the one actually running.
    use super::*;

    #[test]
    fn power_is_dps_times_ehp_with_dr() {
        let mut a = AttrMap::new();
        a.insert("hp".into(), 3000.0);
        a.insert("attack".into(), 600.0);
        a.insert("speed".into(), 10000.0); // attack rate 1.0
        a.insert("armor".into(), 2000.0); // armor_k = K/(armor+K) = 2000/4000 = 0.5
        a.insert("evasion".into(), 1500.0); // dodge = 1500/(1500+1500) = 0.5
        // crit / multicast / bravery / block / regen / deceit / counterattack absent → 0.
        //
        // DPS = attack(600) · rate(1.0) · crit(1) · multicast(1) · bravery(1) · counter(1) = 600
        // EHP = hp(3000) ÷ armor_k(0.5) ÷ (1 − dodge 0.5) = 3000 / 0.5 / 0.5 = 12000
        // power = floor(DPS·EHP / POWER_NORM) = floor(600·12000 / 1800) = 4000
        //
        // The legacy S² formula gives 1470 for the same attrs (armor 1/0.8=1.25,
        // evasion 1/(1−0.15)=1.176, ×BASE_POWER 1000) — so this asserts the v2 path.
        assert_eq!(power_from_attrs(&a), 4000);
    }

    #[test]
    fn armor_k_is_dr_not_linear() {
        // DR curve: always in (0,1], never negative — the legacy `1 - armor/10000`
        // hit 0 at armor=10000 and went negative beyond (the shipped bug).
        assert!((armor_k(0.0) - 1.0).abs() < 1e-9);
        assert!((armor_k(K_ARMOR) - 0.5).abs() < 1e-9); // rating == K → 50% through
        assert!(armor_k(50_000.0) > 0.0); // huge armor: still positive (no heal-the-target bug)
        assert!(armor_k(50_000.0) < 0.05);
    }

    #[test]
    fn probability_stats_clamp_at_100pct() {
        // crit / multicast / counterattack chances over the basis-point cap
        // (e.g. an over-generous class-level grant) must clamp to 100% — power
        // can't keep scaling past a certain chance. Guards the `.clamp(0,1)`s.
        let base = || {
            let mut a = AttrMap::new();
            a.insert("hp".into(), 3000.0);
            a.insert("attack".into(), 600.0);
            a.insert("speed".into(), 10000.0);
            a
        };
        let with = |stat: &str, v: f64| {
            let mut a = base();
            a.insert(stat.into(), v);
            power_from_attrs(&a)
        };
        for stat in ["crit_chance", "multicast_chance", "counterattack_chance"] {
            assert_eq!(
                with(stat, 10000.0),
                with(stat, 5_000_000.0),
                "{stat} must clamp at 100% (no power growth past the cap)"
            );
        }
    }

    #[test]
    fn scalar_matches_combat_on_received_damage_and_speed_baseline() {
        // received_damage: combat applies it; the scalar must too. A −5000 mod (10000−5000 =
        // 5000 = 50% damage taken) ⇒ ×2 EHP ⇒ double power; neutral (absent) ⇒ ×1 (no change).
        let mut neutral = AttrMap::new();
        neutral.insert("hp".into(), 3000.0);
        neutral.insert("attack".into(), 600.0);
        neutral.insert("speed".into(), 10000.0);
        assert_eq!(
            power_from_attrs(&neutral),
            1000,
            "neutral baseline = DPS·EHP/NORM"
        );
        let mut reduced = neutral.clone();
        reduced.insert("received_damage".into(), -5000.0);
        assert_eq!(
            power_from_attrs(&reduced),
            2000,
            "50% received_damage must double EHP/power (scalar matches combat)"
        );

        // speed ≤ 0 falls back to the baseline cast rate (like combat's `speed_or_baseline`),
        // NOT 0 DPS — a build with no speed stat must still have positive power.
        let mut no_speed = AttrMap::new();
        no_speed.insert("hp".into(), 3000.0);
        no_speed.insert("attack".into(), 600.0); // no "speed" key ⇒ composed speed 0
        assert_eq!(
            power_from_attrs(&no_speed),
            1000,
            "speed≤0 must use baseline rate (1.0), not 0 DPS"
        );
    }
}

#[cfg(test)]
mod v2_helper_tests {
    //! Pins the v2 sim-tunable helpers: enemy-curve anchor+monotonicity (the
    //! progression gate), the sub-linear gold faucet (the cost-curve bind), and
    //! the per-tick heal/damage cap (anti out-heal / one-shot).
    use super::*;

    #[test]
    fn enemy_curve_anchored_and_monotonic() {
        // Anchored exactly at the last hand-made chapter.
        assert_eq!(
            enemy_power_for_chapter(ENEMY_CURVE_ANCHOR_CHAPTER),
            ENEMY_CURVE_ANCHOR_POWER.floor()
        );
        // Strictly increasing past the anchor — content must gate progression.
        let mut prev = enemy_power_for_chapter(ENEMY_CURVE_ANCHOR_CHAPTER);
        for ch in (ENEMY_CURVE_ANCHOR_CHAPTER + 1)..=70 {
            let p = enemy_power_for_chapter(ch);
            assert!(
                p > prev,
                "enemy power must strictly increase: ch{ch} → {p} ≤ {prev}"
            );
            prev = p;
        }
    }

    #[test]
    fn dungeon_uses_authored_base_power_not_chapter_curve() {
        // A dungeon fight is tagged CampaignBossFight but must use its authored
        // per-difficulty `base_power` (the difficulty ladder), NOT the campaign
        // chapter curve — otherwise every difficulty collapses to one power keyed
        // to the player's campaign chapter ("losing to the dungeon at unlock").
        let ch = 20;
        // Campaign boss at ch20 ignores base_power and rides the (large) curve.
        let campaign = enemy_power_scalar(1500.0, ch, "CampaignBossFight", false);
        assert!(
            campaign > 10_000.0,
            "campaign boss must use the chapter curve at ch20, got {campaign}"
        );
        // Same template AS A DUNGEON returns the authored base_power verbatim —
        // difficulty 1 (1500) is a trivial first clear vs a ch20 player (~20k).
        assert_eq!(
            enemy_power_scalar(1500.0, ch, "CampaignBossFight", true),
            1500.0
        );
        // The ladder is honored across difficulties and is chapter-independent:
        // diff 5 (50k) and diff 10 (8.5M) pass through unchanged at any chapter.
        assert_eq!(
            enemy_power_scalar(50_000.0, ch, "CampaignBossFight", true),
            50_000.0
        );
        assert_eq!(
            enemy_power_scalar(8_500_000.0, 80, "CampaignBossFight", true),
            8_500_000.0
        );
    }

    #[test]
    fn sell_price_is_sublinear() {
        // Sub-linear (exp < 1): doubling `eff` less-than-doubles price, so the
        // geometric chest-upgrade sink can outgrow the gold faucet and bind
        // progression. The ratio check below fails if exp ever reaches ≥ 1.
        let p1 = sell_price(1000.0) as f64;
        let p2 = sell_price(2000.0) as f64;
        assert!(p2 > p1, "price must increase with eff");
        assert!(
            p2 < 2.0 * p1,
            "sub-linear: doubling eff must less-than-double price ({p1} → {p2})"
        );
        assert_eq!(sell_price(-5.0), 0, "negative eff floored to 0");
    }

    #[test]
    fn cap_per_tick_binds_and_passes_through() {
        // Over-cap clamps to pct×max_hp; under-cap passes through unchanged.
        assert_eq!(cap_per_tick(1_000_000.0, 1000.0, 0.02), 20.0);
        assert_eq!(cap_per_tick(5.0, 1000.0, 0.02), 5.0);
        assert_eq!(cap_per_tick(0.0, 1000.0, 0.5), 0.0);
    }
}

#[cfg(test)]
mod class_balance_tests {
    //! The four combat classes are differentiated by `class_levels` grants
    //! (Warrior→block, Rogue→crit, Mage→multicast, Priest→regen) but must remain
    //! POWER-balanced under `P=DPS×EHP`. Their grants overflow the basis-point
    //! cap, so this also guards the clamp/regen-cap robustness fixes: without
    //! them block>1 gave NEGATIVE power and regen exploded EHP ~40×.
    use super::*;

    fn profile(stat: &str, value: f64) -> AttrMap {
        let mut a = AttrMap::new();
        a.insert("attack".into(), 600.0);
        a.insert("hp".into(), 3000.0);
        a.insert("speed".into(), 10000.0);
        a.insert(stat.into(), value);
        a
    }

    #[test]
    fn class_power_offensive_trio_equal_regen_honestly_lower() {
        // The block class (Warrior, ×2 EHP) and the two ×2-DPS classes (Rogue crit,
        // Mage multicast) are power-balanced — symmetric ×2 mechanisms → equal power.
        let warrior = power_from_attrs(&profile("block", 38800.0)); // 3.88 → clamp 1.0 → ×2 EHP
        let rogue = power_from_attrs(&profile("crit_chance", 19400.0)); // 1.94 → clamp → ×2 DPS
        let mage = power_from_attrs(&profile("multicast_chance", 19400.0)); // → ×2 DPS
        let priest = power_from_attrs(&profile("regeneration_rate", 19400.0));
        assert!(
            warrior > 0,
            "block>1 must NOT produce negative power (clamp)"
        );
        assert_eq!(warrior, rogue, "Warrior vs Rogue imbalance");
        assert_eq!(rogue, mage, "Rogue vs Mage imbalance");
        // SC-1: Priest's regen is now honestly capped to what COMBAT delivers
        // (≈×1.16 EHP), which is structurally below block's ×2 — so the scalar shows
        // Priest LOWER (the old scalar falsely showed parity by crediting ×2 EHP that
        // combat never delivers). This is a real combat-balance fact, not a formula
        // bug; closing it (raise `regen_tick_max_pct` or compensate the Priest grant)
        // is a sim/design pass, not a scalar tweak.
        assert!(priest > 0, "Priest power must stay positive");
        assert!(
            priest < warrior,
            "honest regen EHP (≈×1.16) is below block's ×2 — Priest is structurally lower"
        );
    }

    #[test]
    fn regen_is_bounded() {
        // Absurd regen must not explode EHP: the scalar applies the SAME per-tick cap as
        // combat (`regen_tick_max_pct × hp`), so regen above the cap adds no extra power.
        let huge = power_from_attrs(&profile("regeneration_rate", 1_000_000.0));
        let capped = power_from_attrs(&profile("regeneration_rate", 19400.0));
        assert_eq!(huge, capped, "regen beyond the cap must not increase power");
    }
}