Update Healer Man server

docs/BALANCE_LAB.md

@@ -23,10 +23,11 @@ npm run balance:lab
 The prompt selects:
 
 1. one random party, five manual members, or an automatic multi-party sweep;
-2. a WoW, CoA, or RoM party catalog; automatic mode can select all three;
+2. a WoW, CoA, or RoM party catalog; automatic mode only uses entries marked
+   Ready (plus Beta when explicitly enabled);
 3. a level from 1 through 80;
-4. random parties, guaranteed coverage of all class/spec builds, or a
-   searchable selection of specific class/spec builds;
+4. random Ready parties, guaranteed coverage of all Ready class/spec builds,
+   or a searchable targeted selection that may include Needs Testing builds;
 5. how many unique 1-tank/1-healer/3-damage configurations to generate per
    source when random selection is used;
 6. all bosses, WoW bosses, RoM bosses, or a searchable multi-boss selection;
@@ -39,9 +40,10 @@ Automatic class/spec selection has three strategies:
   to the requested number of unique parties per source. If a Ready/Beta pool
   can form fewer unique 1/1/3 rosters, Balance Lab runs each available roster
   once and reports the cap instead of failing or duplicating identical data.
-- **All specs** creates the minimum deterministic set of valid parties needed
-  to include every available class/spec build for the selected WoW, CoA, or
-  RoM source at least once.
+- **All Ready specs** creates the minimum deterministic set of valid parties
+  needed to include every Ready build for the selected source at least once.
+  At present this is the five certified WoW specs; CoA and RoM have no Ready
+  entries and therefore do not participate in automatic runs.
 - **Specific specs** treats each selected build as required coverage and fills
   the remaining tank, healer, and damage slots with distinct compatible builds.
   When alternatives exist, required builds are not reused as fillers.
@@ -269,6 +271,12 @@ normalized slightly above the best compatible same-level item in the authored
 WotLK-derived loot catalog. The saved catalog and heirloom summary make that
 resolved loadout explicit for each local run.
 
+Damage and healer heirloom profiles include both critical-strike rating and
+haste rating. The WotLK stat resolver converts those ratings at the simulated
+character level into the appropriate melee, ranged, or spell percentages.
+Protection tank heirlooms intentionally spend that budget on defense,
+avoidance, block, stamina, and expertise instead.
+
 Run selected brackets as a companion-only seat audit:
 
 ```powershell
@@ -295,8 +303,10 @@ unless `--cooldown-policy` points to a JSON policy file.
 
 ## Companion specialization readiness
 
-The shared revisioned readiness policy classifies all 31 WoW specializations
-as Ready, Beta, or Needs Testing. Shipped defaults certify only Protection
+The readiness catalog shows every WoW and CoA specialization plus each RoM
+class/role profile as Ready, Beta, or Needs Testing. The revisioned GM policy
+currently publishes the 31 WoW specialization statuses; all CoA and RoM entries
+are fixed at Needs Testing until their certification work begins. Shipped defaults certify only Protection
 Warrior/Aldren, Discipline Priest/Quorin, Marksmanship Hunter/Liora, Fire
 Mage/Xavian, and Assassination Rogue/Orin. The main menu, Dungeon setup, and
 Balance Lab link to the full Companion Readiness catalog. Players can inspect
@@ -304,19 +314,26 @@ it; authenticated GMs can edit and atomically publish the complete policy.
 Published policies must retain at least one Ready tank, one Ready healer, and
 three distinct Ready damage specializations.
 
-Random and all-eligible WoW runs use Ready specs by default. **Include Beta
-Specs** adds Beta specs and is saved per device; explicit targeted runs may
-still select a Needs Testing spec, but their filler seats come only from the
-eligible Ready/Beta pool. CoA and RoM Balance Lab catalogs are unchanged.
+Random and all-eligible runs use Ready specs by default across every source.
+Because no CoA or RoM entry is currently Ready, those catalogs contribute no
+automatic parties. **Include Beta Specs** adds Beta specs and is saved per
+device; explicit targeted diagnostics may still select a Needs Testing spec,
+but `--ready-only` rejects those targets for certification and regression runs.
+Filler seats always come from the eligible Ready/Beta pool.
 Server jobs snapshot the published policy and beta choice. Local GUI runs use
 the revisioned loopback policy saved under
 `artifacts/balance-lab-gui-runtime`; corrupt or missing policy files fall back
 to shipped defaults.
 
-CLI parity is available through `--include-beta-specs` and
+CLI parity is available through `--ready-only`, `--include-beta-specs`, and
 `--companion-readiness-policy <json>`. The JSON may be the published envelope
 or its policy config.
 
+The standard bracket, regression, and NPC-audit npm commands pass
+`--ready-only`. For focused code validation use `npm run test:ready-five`; do
+not use a full-repository or all-class balance sweep unless the project owner
+explicitly expands the certification scope.
+
 List exact party build IDs at a level:
 
 ```powershell
@@ -348,7 +365,8 @@ python scripts/balance_lab.py `
   --boss-category all
 ```
 
-Generate ten parties for each of WoW, CoA, and RoM, but test only RoM bosses:
+Run every currently Ready source against only RoM bosses. Until a CoA or RoM
+build is promoted, `--source all` still produces only the five Ready WoW specs:
 
 ```powershell
 python scripts/balance_lab.py `
@@ -498,10 +516,12 @@ change when the problem is confined to particular encounters.
 ## Coverage and limitations
 
 The selectable roster includes every authored WoW and CoA specialization plus
-every supported RoM class-role pair. Existing generated party talent plans are
-used when available. Missing WoW plans are legally allocated through their
-matching live talent tree; CoA builds allocate the chosen specialization tree
-and class tree through the live essence/prerequisite rules.
+every supported RoM class-role pair, but automatic certification is Ready-only.
+Needs Testing entries remain selectable solely for an intentional targeted
+diagnostic. Existing generated party talent plans are used when available.
+Missing WoW plans are legally allocated through their matching live talent
+tree; CoA builds allocate the chosen specialization tree and class tree through
+the live essence/prerequisite rules.
 
 Headless simulation executes combat-store boss attacks and their authored
 damage, healing, control, aura, summon, threat, and timing effects. It does not
@@ -604,7 +624,7 @@ python -m py_compile scripts/balance_lab_brackets.py
 python -m unittest scripts.test_balance_lab scripts.test_balance_lab_brackets
 node --test server/local-balance-lab-api.test.mjs server/balance-lab-jobs.test.mjs server/server.test.mjs
 python scripts/balance_lab.py --source wow --level 20 --party-mode automatic --party-configurations 2 --boss "gundrak/entry-29932" --simulations-per-party 1 --duration 5 --output-dir artifacts/balance-lab-smoke
-npm test -- --run src/game/benchmark src/game/partyStore.test.ts src/game/partyRuntime.test.ts
+npm run test:ready-five
 npm run build
 npm run balance:lab:playtest
 npm run release:check

docs/BALANCE_TUNING.md

@@ -0,0 +1,67 @@
+# Ability and Talent Tuning
+
+The main-menu **GM Menu** exposes **Ability & Talent Tuning** to authenticated
+GMs. It is a full-screen DOM tool intended for fast local combat iteration. The
+catalog can be searched and filtered by class, and the selected entry exposes
+its source values beside editable runtime percentages.
+
+## Ability overrides
+
+Ability overrides are keyed by stable ability ID. Each field is expressed as a
+percentage of the source catalog value: `100` preserves the source, `50` halves
+it, and `200` doubles it. The editor supports:
+
+- cooldown;
+- cast or channel time;
+- resource cost;
+- direct, periodic, finisher, and summon damage;
+- direct, periodic, and absorb healing;
+- aura, control, summon, and periodic duration;
+- area radius, chain reach, and ground reach.
+
+`src/game/balanceTuning.ts` normalizes and applies the policy.
+`src/game/abilityCatalog.ts` retains the authored catalog separately and
+rebuilds its live definitions whenever the GM applies a draft. This prevents
+percentage changes from compounding when the editor is opened repeatedly.
+
+## Talent overrides
+
+Talent overrides can scale every supported passive modifier parsed from a
+talent tooltip. They can also add a signed percentage-point modifier per learned
+rank for damage, healing, critical chance, haste, costs, cooldowns, durations,
+range, threat, attributes, defenses, or resources.
+
+On-use talents are not passive modifiers. Inner Focus is explicitly excluded
+from passive tooltip parsing. Activating its ability grants a temporary aura;
+the next direct single-target or area heal costs no resource, gains 25
+percentage points of critical chance, keeps its ordinary cast time, and consumes
+the aura. Tune its cooldown and aura duration from the Abilities tab.
+
+## Persistence and scope
+
+The normalized policy is stored per device under
+`healer-man:balance-tuning:v1`. Applying it updates player abilities, NPC
+companion abilities, and client-side test runs that use the live browser
+catalog. **Reset ability**, **Reset talent**, and **Reset all** remove overrides
+without changing authored or generated source data.
+
+This first editor is intentionally a local sandbox. Server Balance Lab jobs run
+in a separate process and do not read browser local storage; permanent balance
+changes should still be moved into authored source data after local validation.
+
+## Heirloom ratings
+
+Virtual heirlooms include specialization-aware critical-strike and haste
+ratings for strength, agility, ranged, spell-damage, and healer profiles.
+Protection tank gear instead prioritizes defense, avoidance, block, stamina,
+and expertise. `src/game/wotlkStats.ts` converts the ratings at the character's
+level into melee, ranged, and spell critical/haste percentages. Both player and
+party heirlooms continue to cap at item level 79.
+
+## Validation
+
+```powershell
+npx vitest run src/game/balanceTuning.test.ts src/game/talentModifiers.test.ts src/game/combatStore.test.ts src/game/heirloomEquipment.test.ts
+npm run build
+npm run release:check
+```

docs/COMBAT_ROTATION_MATRIX.md

@@ -79,9 +79,12 @@ Active abilities fall into one of three audit buckets:
 The shared WoW NPC policy begins with Protection Warrior (Aldren), Discipline
 Priest (Quorin), Marksmanship Hunter (Liora), Fire Mage (Xavian), and
 Assassination Rogue (Orin) as Ready. Every other WoW specialization begins as
-Needs Testing; Beta is an explicit GM-published opt-in. Readiness filters only
-NPC seats. Player character choices, RoM parties, and CoA/RoM Balance Lab
-catalogs are unrestricted.
+Needs Testing; Beta is an explicit GM-published opt-in. Every CoA specialization
+and RoM class/role profile is also shown as Needs Testing. Automatic balance,
+bracket, regression, and seat-audit scopes exclude Needs Testing entries.
+Player character choices remain unrestricted, and an explicit targeted
+diagnostic can still inspect a Needs Testing build without adding it to the
+certified pool.
 
 Ready is a certification result, not a tuning label. Its profile must resolve a
 legal Playerbots-derived talent allocation and learned ability ranks at each
@@ -99,7 +102,9 @@ Power Word: Shield as named absorb capacity, and Renew on moderately injured
 targets without replacing a pending HoT. Inner Focus is reserved for an ally
 at or below 40% health or at least two allies at or below 60%, then empowers
 the next direct single-target or area heal with a free cost and 25 percentage
-points of critical chance. Protection Revenge is enabled for a
+points of critical chance. Player Inner Focus uses the same one-heal aura and
+retains the chosen heal's normal cast time; its activation tooltip is excluded
+from permanent passive talent parsing. Protection Revenge is enabled for a
 five-second window after an authoritative incoming dodge, parry, or block.
 Untargeted cooldown resets affect other abilities only, so Readiness cannot
 reset itself and monopolize the Hunter rotation. Blink and Disengage create

docs/DUNGEON_REPORT_TRIAGE.md

@@ -186,8 +186,8 @@ Run focused tests while iterating, then use the relevant final checks:
 # Required after authored dungeon mechanics change
 npm run dungeon:catalog
 
-# Combat or shared runtime changes
-npm test
+# Combat or shared runtime changes (current certified companion scope)
+npm run test:ready-five
 
 # Report API/server changes
 npm run server:test