benilla-octo/docs/ADDON_COMPAT.md

# Addon compat — SuperWoW / nampower / UnitXP_SP3 / ClassicAPI / VanillaUtils / VanillaHelpers

This fork has no `WoW.exe` and no DLL injection, so the six client-extension DLLs an OctoWoW install
ships beside the real client (`SuperWoWhook.dll`, `nampower.dll`, `UnitXP_SP3.dll`, `ClassicAPI.dll`,
`VanillaUtils.dll`, `VanillaHelpers.dll`) cannot be loaded. This tracks porting their features —
both the Lua API addons feature-detect and the direct client behaviour changes that aren't
addon-mediated — natively into benilla's own engine and Lua VM, always on, so addons written against
them behave the same here. Every row below is therefore intentionally "beyond 1.12.1" in
`scripts/api-coverage.sh`'s report; that script's "beyond" bucket is expected to be large because of
this file, not a regression.

Status: `todo` not started · `partial` some functions/behaviours land, not all · `done` complete for
what we could confirm. Confidence: `confirmed` from the tool's own public source/docs ·
`inferred` from exported-symbol names and/or related addon call sites, not a confirmed source —
these need checking against real OctoWoW addon behaviour in play, and ideally the OctoWoW team's own
source if this bundle is theirs.

Detection globals/flags flip to "present" only once that tool's functions are actually implemented —
never ahead of the functions themselves, so a feature-detecting addon doesn't find a flag with
nothing behind it.

## SuperWoW — confirmed (public wiki, `balakethelock/SuperWoW`)

| Area | Status | Notes |
|---|---|---|
| Detection (`SUPERWOW_STRING`, `SUPERWOW_VERSION`) | done | `script/compat/superwow.rs`; registered as an intentional beyond-1.12 exception in `script/tests/reference_surface.rs` |
| Unit-id grammar (`owner`, `mark1..8`, raw GUID as unit id) | done | `Model::unit` (`script/model.rs`) plus `superwow_token_recognised` (`script/unit/mod.rs`) gating it past the reference's own token-shape check. GUID scope is currently whatever's reachable by a named token this tick (party/raid/target/mouseover/pet/npc), not every loaded object — SuperWoW's own wider reach needs a per-tick GUID-indexed push from `benilla-app`, not yet built |
| `UnitExists` + GUID | done | second return only when a GUID resolves (`script/unit/bindings.rs`); 16-hex-digit opaque token, round-trips through the grammar above. Exact byte format SuperWoW itself uses is undocumented publicly — ours only needs to agree with itself |
| `UnitBuff`/`UnitDebuff` + id, `GetPlayerBuffID` | done | `script/aura/mod.rs`'s `returns_1121` (+ spell id), `script/aura/player_buff.rs` |
| `CastSpellByName` `"CLICK"` arg | done | `script/spellbook.rs` queues a separate `mouseover_spell_casts`; drained in `ui_spellbook.rs`'s `drain_spell_casts` straight at `"mouseover"`, bypassing the player's own selection. The *other* documented form, `arg2` as a unit **name**, is not built — no name-to-unit index exists here, only tokens |
| `LootSlot` force-loot arg | done | `script/loot.rs`; truthy (Lua truthiness, e.g. `1`) routes to the take queue instead of the confirm queue |
| `SetRaidTarget` `"local"` arg | done | `PartyRequest::SetRaidTarget.local` (`script/party.rs`); the live drain (`ui_party/feed.rs`) applies to `GroupState` directly instead of sending `CMSG`/`MSG_RAID_TARGET_UPDATE` |
| Nameplate `frame:GetName(1)` → GUID | done | `script/object/frame_state.rs`'s shared `GetName`, `NamePlates::guid_for_frame` (`script/nameplate.rs`) |
| `GetWeaponEnchantInfo([unit])` + `GetWeaponEnchantID` | todo, blocked | needs per-unit weapon-enchant tracking (today only `"player"`'s is fed at all) and no item-template data distinguishing an on-use charge slot from an equip/proc slot — would need new app-side state, not a binding tweak |
| `GetContainerItemInfo` charges (negative stack count) | todo, blocked | the raw signed field exists (`ObjectFields::item_spell_charges`, benilla-protocol), but nothing in `benilla-formats`' item template says *which* of an item's five spell-trigger slots (if any) is a consumable charge rather than an equip/proc effect — exposing it without that would be a guess, not a port |
| New functions (`SpellInfo`, `TrackUnit`/`UntrackUnit`, `SetMouseoverUnit`, `Clickthrough`, `SetAutoloot`, `UnitNameplate`, `CanLootUnit`, `CombatLogAdd`, Import/Export/AppendText, map/world coord conversions, `IsSwimming`/`IsMounted`/`isIndoors`/`GetSpeed`, mail/quest-link getters) | todo, blocked | each needs new app-side state, not a binding tweak: `IsSwimming`/`IsMounted`/`isIndoors`/`GetSpeed` need a self-movement snapshot (`move_flags() & SWIMMING`, `unit_mount_display_id()`, `area.rs`'s `indoor` bool, and a `MoveSpeeds` component — none currently reach a `feed_*` system that can push them, and `ui_unit.rs`'s `feed_units` is already at Bevy's 16-param ceiling); **`SpellInfo` is now done** — `compat/superwow.rs`, over `script/spellbook.rs`'s `spell_display`: the player's book first, then the host's `Spell.dbc` probe ([`SpellProbe`], installed by `ui_script::lifecycle::install_spell_probe` on every VM build), so it reaches every shipped spell as the real mod does. The range pair stays nil — `SpellRange.dbc` is not on the probe; the rest (`TrackUnit`, `SetMouseoverUnit`, `Clickthrough`, `SetAutoloot`, `CanLootUnit`, `UnitNameplate`, file I/O, map/world coords, quest links) are each plausible but unstarted. **The two mail link getters are now done**, built for ClassicAPI's own `Mail` namespace (`compat/classic_api/merchant_frame.rs`, see its row below) — SuperWoW specifies the same `GetSendMailItemLink`/`GetInboxItemLink`, so that half of this row is closed |
| `UnitPosition(unitid)`, `CursorPosition()` | done | `UnitState.position` (`script/unit/mod.rs`), fed by `Transform` from `ui_unit.rs`'s `feed_units` (player/target/targettarget/npc) and `ui_tooltip.rs`'s `drive_mouseover_tooltip` (mouseover); functions in `compat/superwow.rs`. Party/raid/pet aren't wired (their own `snapshot()` call sites in `ui_party/feed.rs`/`ui_pet/unit.rs` pass `None` — each needs its own `Entity`→`Transform` lookup threaded through, not attempted this pass). Reading `Transform` broadly past the usual one-frame-stale tolerance raised `game_plugins.rs`'s `UPDATE_ACTIONABLE_CEILING` by 30 (cited there) — `Transform` is written by enough movement/animation/physics systems that `With<Guid>` alone doesn't shrink the ambiguity count |
| `UNIT_CASTEVENT` | done | `crates/benilla-app/src/superwow_events.rs`: a `CastEventFeed` queue the cast handlers push into, drained once per tick by one VM-holding system that fires the event — the pattern `ui_mirror.rs` already uses, and the only way across, since `spell/net.rs`'s `Lifecycle`/`Scene` bundles deliberately hold no `UiScript` (`game_plugins.rs`'s `every_vm_holder_in_update_declares_its_side_of_the_tick` gates that). Edges wired: `START` from `SMSG_SPELL_START` with its wire cast time as `arg5` (an instant raises none — its only edge is `CAST`, which is what the wiki's own START/CAST split means), `CAST` from `SMSG_SPELL_GO`, `FAIL` from `SMSG_SPELL_FAILED_OTHER`, `CHANNEL` from `MSG_CHANNEL_START` with its duration. GUIDs go out in the same 16-hex-digit spelling every other `compat/` surface uses, so `arg1`/`arg2` compare directly against a `UnitExists`/`UnitGUID` return. Not wired: `MAINHAND`/`OFFHAND` — benilla's melee-swing path raises no cast edge at all, so there is nothing to forward. `MSG_CHANNEL_START` names no caster (1.12 sends it for the local player's own channel only), so `CHANNEL`'s `arg1` is self and its `arg2` is 0 |
| `CREATE_CHATBUBBLE`, `RAW_COMBATLOG`, `SUPERWOW_COMBAT_LOG_EVENT` | todo | `CREATE_CHATBUBBLE` needs the chat-bubble creation site in `chat_bubble.rs` (its `push`/`drive_bubbles`); now that `superwow_events.rs` exists with the queue-plus-drain pattern established, this is a small addition rather than new architecture. `RAW_COMBATLOG`'s funnel is `ui_chat/feed.rs`'s `ChatLog::push_combat`, where (almost) every combat line lands as a `combat::PendingCombat` from two call sites in `combat_log/chat.rs` — but that's a *queued* value, not rendered text, and the sentence `arg2` wants is built later at drain time, which this pass didn't trace into. Firing at `push_combat` with the structured fields in place of `arg2` would be a different (arguably more useful, but non-conforming) shape than the wiki's "text with GUID". `SUPERWOW_COMBAT_LOG_EVENT`'s full prefix/suffix param schema is its own sub-project |
| `NameplateRange` | done | one CVar, two readers: `nameplates.rs`'s `NameConfig::range_sq` (the overhead name — introduces a cull where the reference has none at all) and `vplates.rs`'s `VPlateMode::range_sq` (replaces the reference's own hardcoded 20 yd V-key-plate range). Default `80`, the top of the mod's documented 10-80 range — no shipped default is published, so this is the least-restrictive honest choice, not a confirmed number |
| `ChatBubbleRange` | done | `chat_bubble.rs`'s `BubbleConfig::range_sq`, replacing the reference's hardcoded 20 yd. Default `20` (today's exact value) — no shipped default published for this one either, within the mod's documented 10-200 yd range |
| `NameplateMotion`, `NameplateVerticalSpacing` | todo | needs locating whatever (if anything) already staggers overlapping nameplates, not investigated |
| `FoV` | todo, held back | the wiki's only confirmed default (`"1.57"`) doesn't obviously match benilla's existing hardcoded `benilla-world/src/view.rs`'s `CAM_FOVY = FRAC_PI_4` (0.785 rad, 45°) — 1.57 rad is 90°, double. Without confirming whether SuperWoW's `FoV` cvar and `CAM_FOVY` share the same angle convention (vertical half vs. full, radians interpretation) and whether 1.12's true default really is 45°, defaulting to the wiki's literal `1.57` risks a jarring, wrong-looking lens change rather than exposing the existing value as a tunable knob. Left alone rather than guess |
| `LootSparkle` | done, CVar `LootSparkle`, default `1` | `creature_anim/spell_visual.rs`'s `arm_loot_fx` grew a **GameObject** arm beside its unit and corpse ones, hanging the same `"HARDCODED Loot Art"` row (`0x13`) at the same tag. 1.12 sparkles a lootable corpse and nothing else — a chest, a herb, a vein or a quest object is found by eye — and sparkling those arrived in **2.3.0** ("interactable game objects sparkle and display their names"), which is what the mod backports: upstream describes it as "the sparkling effect on lootable treasure". The test takes **two** arms, because "lootable treasure" is neither one alone: the server's own per-viewer `GO_DYNFLAG_LO_ACTIVATE` in `GAMEOBJECT_DYN_FLAGS` (`GameObject::ActivateToQuest`), documented on its field reader as "the sparkle" — but vmangos raises it through `ActivateToQuest`, so on a chest it means *quest* loot and keying on it alone would light up nothing else — **or** `GAMEOBJECT_TYPE_CHEST`, which is exactly chests, herbs and mining nodes, treasure by construction and a type the client reads without the server's help, excluding `GO_FLAG_IN_USE`/`NO_INTERACT` so an emptied or disabled chest stops. Both arms are a judgement about what the mod does, not a trace of it: if only quest objects light up the first is doing all the work, if doors and signs do the second is too wide. Defaulted **on**: upstream publishes no default, and the sparkle is present on this install with SuperWoW loaded, which is what "as if its default config loaded" means here; `SetCVar("LootSparkle", "0")` is stock 1.12. `FxStage` is immaterial for this effect and the row no longer claims otherwise — `Particles\LootFX.m2` (the `"HARDCODED Loot Art"` row's own model, extracted from this install) holds **one** 2400 ms sequence with `flags = 0`, and bit 0 clear is a looping sequence, so `FxAnimLife::arm` repeats it whatever the stage says |
| Healing text, uncap sounds, selection-circle style, outline/shadow text, force-show-auras, XP text | todo | not investigated |
| Macro limit 255→510 | done | `script/macros.rs`'s `MAX_MACRO_BODY`; `ui_script/manifest.rs`'s `install_macro_letters_patch` re-patches the stock FrameXML's `SetMaxLetters`/char-count string at boot, since both come from the player's own install |
| Targeting-circle spells (Blizzard, Flamestrike) no longer refuse movement | done | `cast_target::is_ground_targeted` (`spell/cast_target.rs`) exempts them in `validator::cast_moving_refusal` (`spell/validator.rs`); the real cast-time interrupt-on-move rule (`inflight.rs`) is untouched |
| Ranged abilities (Aimed Shot) firing `SPELLCAST_START` | done | already satisfied — `spell/net.rs`'s `spell_start` already opens the bar on any real `SpellCastTimes.dbc` duration rather than the reference's narrower ranged-spell suppression (see the `has_cast_time` comment there); confirmed by the existing test `a_timed_ranged_cast_opens_the_shot_bar_but_an_instant_shot_does_not` |
| Friendly-player item-visibility range limit removed | todo | not investigated this session — need to find where benilla currently gates item-row/tooltip visibility by range for a friendly player, if it does at all |
| `ShowVKeyCastbar` | **registered, stored only** | pfUI writes `0` at `modules/nameplates.lua:3` ("disable original castbars") under `pcall`, and that write was one of the session log's six `unknown CVar '…' (not host-registered) — ignored` warnings. **Provenance, measured not assumed**: the name appears *nowhere* in this OctoWoW install except that one pfUI line — `grep -rli ShowVKeyCastbar` over the whole tree hits one file, and neither `WoW.exe` nor any of its eighteen DLLs (SuperWoW's included) carries it. So no mod here registers it and **there is no published default to match**; pfUI writes it defensively for whichever client does. Registered in `cvars.rs` as `ours("ShowVKeyCastbar", "0", …)` and **stored, not wired**: benilla's V-key plates have no cast bar to suppress (`benilla-ui`'s `script/nameplate.rs` header says so outright, and `vplates.rs` draws name, level, health bar and raid mark and nothing else), so `0` *is* this client's behaviour rather than a chosen value, shipping `1` would advertise a bar that does not exist, and an observer would give a knob two positions with one picture. If a plate cast bar is ever built this row becomes its switch |

## nampower — **two different mods share this name; this bundle ships the second**

A correction worth stating plainly, because it was wrong here for most of this project's life. The
original research targeted **`namreeb/nampower`**, whose entire effect is one cast-timing rule and
which exposes *no Lua API at all*. That is a real mod and the rule is correctly ported — but it is
not what the OctoWoW bundle runs.

This install ships **pepo's nampower v2**, a much richer fork with a real Lua-facing surface: a
block of `NP_*` CVars and `GetNampowerVersion()`, driven by the bundled `NampowerSettings` addon.
Live addon testing is what surfaced this (the addon asked for `GetNampowerVersion`, which
namreeb's mod has no concept of). Upstream has since moved again: `pepopo978/nampower` now 404s,
and **`brues-code/nampower`** — same author as the ClassicAPI this bundle uses — is its live
continuation and the source of every CVar default below.

One consequence worth flagging: the nameplate-distance feature was attributed to SuperWoW earlier
in this file on the strength of the namreeb research. pepo's v2 has its own
`NP_NameplateDistance`, so **both** mods offer that knob, and both now drive the same reach here.

| Area | Status | Notes |
|---|---|---|
| Cast-ready timing rule (namreeb's, and pepo's simplest case) | done | no Lua surface; `PendingCast::arm` in `crates/benilla-app/src/spell/inflight.rs` opens the guard from the spell's own known cast time at send, not a round trip through `SMSG_SPELL_START`; `SMSG_SPELL_DELAYED` pushback still extends it. This is the always-on version of what pepo's v2 makes configurable — see the stored-only row below for why that configurability is not wired |
| `GetNampowerVersion()` | done | `script/compat/nampower.rs`, reporting `2.8.6`. The number is a claim about *surface*, not about benilla's code (same reasoning as `CLASSIC_API_VERSION`). `NampowerSettings` has exactly one version gate, `HasMinimumVersion(2, 8, 6)`, guarding exactly one setting: `NP_NameplateDistance` — which is also the one nampower CVar wired to real behaviour here. So 2.8.6 is the lowest version that still shows the only knob that genuinely works, and no higher: claiming more would assert the queue/buffer machinery of later releases (upstream documents through 4.5.0) that this client does not implement. The addon prints its own "update available" notice below its latest, which is accurate |
| `NP_NameplateDistance` | **done, live** | the only `NP_*` row with a real engine reader. Drives both nameplate consumers — `nameplates.rs`'s `NameConfig::range_sq` (overhead names) and `vplates.rs`'s `VPlateMode::range_sq` (V-key plates) — i.e. the same knob SuperWoW's `NameplateRange` drives. **Two mods, one knob: last writer wins**, which is what a player moving either slider expects; neither is silently ignored. Each is clamped to the range its own mod documents: nampower 5..200 (the addon's own slider bounds in `settings.lua`), SuperWoW 10..80. Default `80` — upstream publishes *no* fixed default for this one ("Defaults to whatever was set by the game or vanilla tweaks"), so it keeps benilla's existing reach rather than inventing a number |
| The other 22 `NP_*` CVars | **superseded: 20 stored only, 2 live** | registered in `cvars.rs` with the mod's own documented defaults so the settings panel reads, writes and persists correctly — and consumed by nothing. benilla implements no spell-queueing system for them to tune: we carry namreeb's simpler always-on cast rule, not pepo's queue windows, dynamic latency buffer, retry and quickcast machinery. Storing them keeps the addon's UI truthful about what the player chose; claiming they change casting would be a lie the player would feel at the keyboard. They are listed in `cvars.rs`'s `LUA_ONLY` test table (whose rule is "a registered row needs a reader, or a named reason its reader is Lua") with that reason. The rows: the six `NP_Queue*` toggles, the four `*QueueWindowMs`, the four buffer knobs (`NP_MinBufferTimeMs`, `NP_MaxBufferIncreaseMs`, `NP_NonGcdBufferTimeMs`, `NP_OnSwingBufferCooldownMs`), `NP_ChannelLatencyReductionPercentage`, and the seven behaviour toggles (`NP_DoubleCastToEndChannelEarly`, `NP_InterruptChannelsOutsideQueueWindow`, `NP_OptimizeBufferUsingPacketTimings`, `NP_PreventRightClickTargetChange`, `NP_QuickcastTargetingSpells`, `NP_ReplaceMatchingNonGcdCategory`, `NP_RetryServerRejectedSpells`). **Superseded:** `NP_SpellQueueWindowMs` and `NP_QueueSpellsOnCooldown` are now LIVE — they are the explicit queue's own two knobs; see "The queue, and the one verb that needs it" |
| pepo v2's wider surface beyond this addon | todo | upstream's README documents much more than `NampowerSettings` drives — later releases add `NP_SpamProtectionEnabled`, `NP_PreventMountingWhenBuffCapped`, the greater-demon autocast pair, `NP_PreventRightClickPvPAttack`, `NP_QuickcastOnDoubleCast`, and a family of events (`SPELL_START_SELF`/`_OTHER`, `AUTO_ATTACK_SELF`/`_OTHER`, `SPELL_HEAL_BY_SELF`, `AURA_CAST_ON_SELF`…). None is registered, because nothing installed asks for them; add them when an addon does, and raise `GetNampowerVersion` to match only then |
| `GetNampowerVersion()` now reports **4.0.0** — and what the gate that opens actually reaches | **supersedes the `2.8.6` row above, which is now stale as a statement of the code** | `script/compat/nampower.rs`'s `NAMPOWER_VERSION` is `(4, 0, 0)`, set at the maintainer's explicit request; that file carries the full trade. The consequence this row exists to record: the number is not only read by `NampowerSettings`. **pfUI's `libs/libdebuff.lua:38-99` gates its entire debuff pipeline on `>= 3.0.0`** — below it the library prints "Debuff tracking disabled! Please update Nampower to v3.0.0 or higher" and raises `StaticPopup_Show("LIBDEBUFF_NAMPOWER_UPDATE")`, i.e. fails **loudly**. At `4.0.0` the gate passes, so the library enables five `NP_Enable*` CVars and registers `AURA_CAST_ON_SELF`/`_OTHER` and `DEBUFF_ADDED_OTHER`/`DEBUFF_REMOVED_OTHER` — which, before the rows below, were CVars that did not exist and events nothing fired. The version claim converted a loud failure into a silent one. The rows below are the other half of that claim being made good; `GetPlayerGuid`/`IsPlayerGuid` in the ClassicAPI section are the third half |
| The five `NP_Enable*` event switches | **superseded: three live, two stored only** | `cvars.rs`, all five at upstream's own documented `default 0` (`brues-code/nampower`'s `EVENTS.md` states it per row); names taken off the shipped `nampower.dll` (`strings` lists each beside its own "Set <name> to " line). pfUI's `libs/libdebuff.lua:56-88` writes all five at `PLAYER_LOGIN`. **`NP_EnableAuraCastEvents` is LIVE**: a `CvarChanged` observer moves `ui_cast_events.rs`'s `AuraCastFeed::enabled`, and off, the packet path queues nothing at all. `NP_EnableSpellStartEvents`, `NP_EnableSpellGoEvents`, `NP_EnableAutoAttackEvents` and `NP_EnableSpellHealEvents` are **stored only**, in `cvars.rs`'s `LUA_ONLY` table with that reason: benilla emits none of those event classes (see the `todo` row below for what each would need). Registering them is what stops the engine warning; it is *not* a claim that the stream arrived, and the chat line libdebuff prints ("Enabled 5 Nampower CVars") therefore over-reports by four. `NP_EnableSpellEnergizeEvents` and the `NP_EnableUnitEvents*` family exist upstream and are not registered — nothing installed writes them . **Superseded by the rows below and by "The event table, accounted for":** `NP_EnableAuraCastEvents`, `NP_EnableSpellStartEvents` and `NP_EnableSpellGoEvents` are now LIVE, read by `NpCastGates` in `ui_cast_events.rs`; the two unit-event switches stay stored only because nothing produces those events yet |
| `AURA_CAST_ON_SELF` / `AURA_CAST_ON_OTHER` | done, gated on `NP_EnableAuraCastEvents` | `crates/benilla-app/src/ui_cast_events.rs`'s `AuraCastFeed`: a second queue beside the `UNIT_CASTEVENT` one, pushed by `spell/net.rs`'s `on_spell_go` (where `Spell.dbc` is already in hand) and drained by the same VM-holding `drain_cast_edges`, behind the two cast families. Folded out of `SMSG_SPELL_GO`'s caster and **hit list** plus the spell's aura-applying effects: **one event per hit target per effect whose `EffectApplyAuraName` is nonzero**, which is upstream's own rule and the reason libdebuff dedupes inside 100 ms. The nine arguments are upstream's (`int spellId, string casterGuid, string targetGuid, int effect, int effectAuraName, int effectAmplitude, int effectMiscValue, int durationMs, int auraCapStatus`, matching the `%d%s%s%d%d%d%d%d%d` signal format in `nampower.dll`), and the shape was taken from the two live consumers' own destructures — `libs/libdebuff.lua:1105-1113` and `modules/innervatecall.lua:58-67`. **The SELF/OTHER split is by target, not caster.** GUIDs use benilla's own bare 16-hex spelling, as every other `compat/` GUID does. A ground-targeted AoE's GO carries no hit list and raises nothing: inventing the caster as the target would report Blizzard's area aura as landing on the player. `arg9` is computed from the target's `UNIT_FIELD_AURA` occupancy (bit 0 buff half full, bit 1 debuff half) |
| `DEBUFF_ADDED_OTHER` / `DEBUFF_REMOVED_OTHER` | done, ungated (upstream gates neither) | `crates/benilla-app/src/ui_aura.rs`, inside the existing VM-holding `feed_auras` and after it has pushed the aura lists, so a handler that asks `C_UnitAuras` about the unit it was just told about cannot get a contradicting answer. A **delta on the `UNIT_FIELD_AURA` spell-id dwords**, driven off `net::FieldChanged` edges inside that 48-dword span — the same trigger `creature_anim::spell_visual`'s `arm_aura_state_fx` already uses — so a frame with no aura change does no work at all. First sight of a unit **seeds** the memory and fires nothing: an aura that was already on a mob we had never seen was not newly added, the descriptor keeps no caster for it, and a crowd would otherwise cost a burst of Lua dispatch on streaming in. Seven arguments, upstream's and identical across all eight buff/debuff events: `string guid, int luaSlot, int spellId, int stackCount, int auraLevel, int auraSlot, int state` — every column a field of the descriptor benilla already parses, `auraSlot` **0-based** as upstream reports it (pfUI adds 1 at `libdebuff.lua:1350`), `luaSlot` the `UnitDebuff` index through the same hidden-aura filter the aura lists use and `0` for a hidden aura, `state` 0 added / 1 removed. **Removals fire before adds** within one delta, because pfUI keys slot ownership on the raw slot and clears that key on removal (`libdebuff.lua:1507-1512`) — the other order would wipe the entry the add just wrote |
| `durationMs` (`arg8`) for a combo-point or level-scaled `SpellDuration.dbc` row | todo | `ui_cast_events.rs`'s `aura_duration_ms` answers the row's `Duration[0]` when `Duration[1]` is 0, and **`0` otherwise** — including the permanent sentinel and a missing row. `0` is the consumer's own documented "absent" path. Reporting `Duration[0]` for a scaling row would quote 8 s for an 18 s five-point Rupture, and a debuff bar counting down to the wrong moment is worse than one that does not count down. What it would take: settling *which* input the row scales on (caster level vs combo points) per row, and reading the combo points as they stood at the cast rather than after the finisher consumed them. Upstream also promises "includes client modifiers if you are the caster": `spell/mods.rs` stores the server's `SPELLMOD_*` cells but has no duration reader, so this is the unmodified DBC length |
| A stack-count change as a buff/debuff edge (`state` 2) | todo, deliberately | Upstream's legend has `2 = modified (stack change)` and its prose says the events fire "whenever a buff/buff **stack** … is added or removed", which reads as: a stack increase is an ADDED and a decrease a REMOVED, both with `state` 2. Not emitted here. Nothing in the corpus reads `arg7` at all; the watch span is the spell-id dwords alone, so a stack move inside a slot that keeps its spell is not an edge this sees; and under that reading a stack *decrease* would make pfUI clear a live debuff's slot ownership and its timer (`libdebuff.lua:1521-1540`), which is the wrong-timer failure this whole family exists to avoid. Costs nothing for the timers: a refresh's duration comes from `AURA_CAST`, which fires on every `SMSG_SPELL_GO`, and pfUI knows DEBUFF_ADDED does not fire on a refresh (`libdebuff.lua:1427`) |
| `DEBUFF_ADDED_SELF` / `DEBUFF_REMOVED_SELF`, `BUFF_ADDED_*` / `BUFF_REMOVED_*` | **superseded: six of eight built** | The other six of upstream's eight buff/debuff events, same seven arguments. The `*_SELF` pair is the player's own half of the delta `ui_aura.rs` already computes, and the `BUFF_*` pair the positive half of the slot range it already walks past, so all six are small additions to the same loop. Not built because nothing installed registers one: pfUI's libdebuff takes only the two `*_OTHER` names . **Superseded:** all six `*_SELF` names and the two `DEBUFF_*_OTHER` names fire from `ui_aura.rs`; only `BUFF_ADDED_OTHER`/`BUFF_REMOVED_OTHER` are left, and those stay out deliberately — see "The event table, accounted for" |
| `SPELL_START_SELF`/`_OTHER`, `SPELL_GO_SELF`/`_OTHER`, `AUTO_ATTACK_*`, `SPELL_HEAL_*`, `SPELL_CAST_EVENT`, `SPELL_FAILED_OTHER` | **superseded: fired** | `libs/libdebuff.lua:863-869` registers all six families, and its `libdebuff_*_hooks` broadcast surface is what feeds `libs/libpredict.lua` (HoT send tracking), `modules/swingtimer.lua` and `modules/actionbar.lua`'s prowl hook. The start/go pair's packets are already folded into `ui_cast_events.rs`'s `CastEdge::Start`/`Cast`, so most of the data is in hand — but upstream's shapes want `itemId`, `castFlags`, `spellType` and `corpseOwnerGuid` columns this client does not carry, and those consumers key on arguments it would have to guess. `AUTO_ATTACK_*` needs a melee swing edge no path here raises at all (`CastEdge`'s own note). `SPELL_HEAL_*` needs `SMSG_SPELLHEALLOG`'s amount, which nothing reads. Guessing a column here is the same silent-failure shape the four rows above were written to avoid . **Superseded:** `SPELL_START_*`, `SPELL_GO_*`, `SPELL_FAILED_*`, `SPELL_DELAYED_SELF`, `SPELL_CHANNEL_START`/`_UPDATE` fire from `ui_cast_events.rs` and `SPELL_CAST_EVENT` from `ui_self_cast.rs`. Still unfired of this row: `AUTO_ATTACK_*` and `SPELL_HEAL_*`, which are combat-log producers, not cast-queue ones — they belong with the block in "The event table, accounted for" |

## UnitXP_SP3 — confirmed (open source, multiple mirrors)

| Area | Status | Notes |
|---|---|---|
| `UnitXP(command, ...)` dispatcher | done | `compat/unitxp.rs`. No documented detection global for this one — defining `UnitXP` at all is what an addon's `if UnitXP then` finds. **Collision note**: stock 1.12 already has its own single-argument `UnitXP(unit)` (experience points, `PLAYER_XP`); the mod shadows it on a real install exactly as a detour falls through to the original, so this dispatcher's unrecognised-command branch now carries that stock getter's exact behaviour (moved out of `script/unit/bindings.rs`, which no longer registers `UnitXP` itself — only `UnitXPMax` stayed there, untouched) |
| `distanceBetween(unit1, unit2)` | done | player side: `inspect.rs`'s `UnitReach::dist_sq` (works whenever one side is `"player"`). Both-non-player side: `UnitState.position` (player/target/targettarget/npc/mouseover only, same reach as SuperWoW's `UnitPosition`) |
| `target("nearestEnemy")` | done | queues `SelectionRequest::NearestEnemy` (`script/unit/mod.rs`) onto the same selection queue `TargetUnit`/`TargetLastEnemy` use, so a UnitXP target and a stock one commit through one path in call order. Handled by `target::scan::target_nearest_enemy`, which reuses `scan::best_enemy` over the **existing** candidate scan the tab-target and attack-order paths already run — so "nearest" means exactly what it does there (off-centre-plus-distance score, fighting-me bonus, on-screen first), not a second notion of nearest. Its own message+system rather than an arm in the drain: pulling the whole `TargetScan` into that shared system broke a UI-only test harness and cost +16 ambiguity pairs, the same reason `AttackNearestRequest` is already split out |
| `target("nextMarkedEnemyInCycle"/"previousMarkedEnemyInCycle")` | done | `SelectionRequest::MarkCycle { forward }`, handled in the selection drain (`target/click.rs`) off `GroupState::raid_targets`, walked slot-7-to-0 so the order is skull-first as the README documents; steps from whichever marked unit is held, wrapping, and enters at the skull (forward) or star (back) end when nothing marked is held. Only marks on a streamed unit are in the cycle |
| `inSight`, `target` distance-cycles/`worldBoss`/`rangeCone`, `notify` | todo | confirmed from `MarcelineVQ/UnitXP_SP3`'s own `README.md` (the authoritative command reference — more precise than this session's earlier research pass, which guessed at `AoE`/`meleeAutoAttack`/`behind`/`timer` variants this README doesn't mention; treat those as unconfirmed until seen elsewhere). `inSight` needs a real raycast with no current binding-layer access; `nextEnemyConsideringDistance`/`nextEnemyInCycle` (the 41-yd distance-banded cycles) would need a third cycle threaded through `TabHistory`, which is keyed to its own two sides; `worldBoss` needs classification data that doesn't reach here; `rangeCone` tunes the scan's own cone constant, not a Lua-settable knob today; `notify` needs OS-level taskbar-flash/system-sound |
| `modernNameplateDistance` | **built** | The command's name says distance; its own checkbox says what it does — **"Proper Nameplates Occlusion"** (`UnitXP_SP3_Addon.xml:151`), with three sibling options in that panel gated on it ("Need Proper Nameplates Occlusion to be also enabled"). So it is line-of-sight culling, not reach: benilla's reach is `NameplateRange`/`NP_NameplateDistance`, which have their own rows. 1.12 draws a plate for any unit in range whether or not a wall stands between, which is why a pull through a wall shows its whole room. Stored as the new `NameplateOcclusion` CVar rather than as private state, so it persists, appears in `/console`, and reaches the engine through the one `CvarChanged` path every other nameplate knob uses. **Two readers, as the reach CVars have**: `vplates.rs`'s `VPlateMode::occlusion` (V-key plates) and `nameplates.rs`'s `NameConfig::occlusion` (overhead names), sharing one `camera_can_see` — they must agree, because a unit with a plate has no overhead name and vice versa, so culling only one would swap a unit's plate for a floating name instead of hiding it. The ray is cast from the **camera**, not the player: the plate is drawn where the camera projects it, and in third person the two origins disagree often. It aims `OCCLUSION_AIM_LIFT` above the unit's origin (a transform sits at the feet, so a ray aimed there skims the ground and hides every unit on a slope) and stops `OCCLUSION_BACKOFF` short (so the floor under the unit's feet cannot count as the thing hiding it). Against the body layer only, so a unit standing in front of another cannot hide it — geometry occlusion, as the mod's is, not depth sorting. **The return value is part of the fix**: the addon warns "UnitXP_SP3.dll failed to execute" on a falsy result (`UnitXP_SP3_Addon.lua:108-113`), and the dispatcher's fall-through answers the integer 0, which is truthy in Lua — so before this the toggle reported success and changed nothing |

## ClassicAPI — confirmed (open source, `brues-code/ClassicAPI`)

| Area | Status | Notes |
|---|---|---|
| Lua 5.1 syntax (parsing: `#`, hex literals, long brackets, …) | done | free — benilla's VM is mlua/Lua 5.1 already; 1.12 itself is Lua 5.0 |
| Lua 5.1 *stdlib* (`select`, `coroutine`, `string.reverse`/`match`/`gmatch`, `table.maxn`, …) | blocked, needs a maintainer call | `script/lua50.rs` deliberately nils every one of these so a vanilla addon's own `string.gmatch or string.gfind`-style feature test takes 1.12's real branch — that's a fidelity mechanism for *every* addon, not a ClassicAPI concern. Restoring them in `compat/` (always on) would break that test for addons that never asked for ClassicAPI. Documented in `compat/classic_api.rs`'s own header; not resolved here |
| `UnitGUID`, `UnitTokenFromGUID` | done | `compat/classic_api.rs`, reusing SuperWoW's `guid_token`/`Model::unit` plumbing — a GUID from either round-trips through both |
| `Enum` (`PowerType`, `ItemQuality`, `ItemClass`) | partial | `compat/classic_api/enums.rs`, pure const tables. Only the three groups the installed addons index are built; the modern `Enum` has well over a hundred groups and a constant with the wrong number fails silently at whatever consumes it, so the rest are absent rather than guessed. Values are the **modern** ones — that is what ClassicAPI backports and what addons compare against — which for these three is almost free, since the modern numbering preserved 1.12's: `PowerType.Mana`/`Rage`/`Focus`/`Energy` (0–3) compare correctly against this client's own `UnitPowerType`, and the item classes/qualities line up for every value 1.12 has. **One real collision**: power type 4 is Happiness in 1.12 and ComboPoints upstream, so `UnitPowerType("pet") == Enum.PowerType.ComboPoints` is true for a happy pet. Dropping the name would turn a wrong comparison into one against nil, and 1.12 has no combo-point power type to offer instead (combo points are `GetComboPoints()`), so both names map to 4 and a test pins it. Also carries both spellings where the modern enum renamed a value (`ItemQuality.Standard`/`Common`, `Good`/`Uncommon`) |
| `UnitClassBase`, `UnitRaceBase` | done | `compat/classic_api/unit_extra.rs`. The token half of stock `UnitClass`/`UnitRace`, which later clients split into their own verb — `UnitState.class_file`/`race_file`, already fed. Named here because it is the single highest-frequency ClassicAPI call in the installed set: **33 sites in pfUI**, at file scope, so its absence stopped the addon loading outright. Players only: a creature carries no class row, and answering one would make `UnitClassBase(unit)` truthy for every mob |
| `UnitSubName` | done | `compat/classic_api/unit_extra.rs`, over `UnitState.subtitle` — the `<Stable Master>` line the overhead name and tooltip already draw |
| `UnitIsMinion`, `UnitIsFeignDeath` | done | `compat/classic_api/unit_extra.rs`. `UnitIsMinion` is `UnitState.owner != 0`, the same resolution the `"<token>owner"` grammar uses; `UnitIsFeignDeath` reads `dynamic_flags & 0x20`. Both answer `1`/nil, the 1.12 predicate shape |
| `UnitPower`, `UnitPowerMax` | done | `compat/classic_api/unit_extra.rs`. The later-client spelling of `UnitMana`/`UnitManaMax`, plus an optional `powerType` — and that argument is the whole point: it reads a slot the unit is **not currently on**, which is how pfUI draws a shapeshifted druid's mana while the active slot is energy or rage (`api/unitframes.lua:1601`'s own comment names this as the reason it uses the two-argument form). 1.12 exposes no way to ask, so this needed **new state**: `UnitState::powers`/`max_powers`, all five `UNIT_FIELD_POWER1..5`/`MAXPOWER1..5` slots, fed in `ui_unit.rs` through the *same* `unit_shown_power`/`unit_shown_max_power` getters the existing active-slot pair uses — so the `UNIT_DYNFLAG_DEAD` gate and the rage/happiness display divisors apply identically and cannot drift. An out-of-range `powerType` answers the number 0, not nil: `Enum.PowerType.None` is -1 and `HealthCost` is -2, so a negative index is a real call, and pfUI's own `UnitPower(unitstr, powerType) or 0` shows a caller assuming a number. **Fidelity deviation**: `script/unit/tests.rs`'s `power_bindings_read_the_active_type` previously asserted both were nil as 1.12 verbs they are not. Updated with the reason rather than deleted, the same way `reference_surface.rs` records intentional deviations — and the assertion was replaced with a stronger one, that the new pair answers *exactly* what the stock pair does for the active slot, so `UnitMana` stays the source of truth instead of drifting from a parallel read |
| Focus (`FocusUnit`, `ClearFocus`, the `"focus"`/`"focustarget"` tokens, `PLAYER_FOCUS_CHANGED`, `/focus`, `/clearfocus`) | done | the persistent secondary selection, which 1.12 has no verb, no token and no event for. `compat/classic_api/focus.rs` owns the *state*: the focus is a **GUID** in `Model::focus_guid`, the same shape as SuperWoW's `mouseover_override` and for the same reason — the token has to answer the unit's live health, power and auras, not a frozen copy of the tick `/focus` ran on. `Model::unit` resolves both tokens ahead of the fed-token map so a `FocusUnit`/`ClearFocus` in the current frame wins over the last push, and `unit/mod.rs`'s `classic_api_token_recognised` widens the token check by a `"focus"` *prefix* (so `"focustargettarget"` is recognised and answers nil, exactly as the reference's own `"target"` prefix recognises `"targettargettarget"`). The *data* is the app's: `ui_unit.rs`'s `feed_units` pushes both snapshots and fires their `UNIT_*` edges, `ui_aura.rs`'s `feed_auras` pushes both aura lists and fires `UNIT_AURA` per token, `feed_unit_reach` resolves both for `CheckInteractDistance`/UnitXP_SP3's `distanceBetween`. **No new system and no new `SystemParam`**: each feed already holds the `UiScript` and reads the guid back out of it, so the `UPDATE_ACTIONABLE_CEILING` is unchanged at 5,581 (measured). `feed_units`' gate gained the guid as an input, because focusing a unit that is standing still moves nothing else the gate watches. `PLAYER_FOCUS_CHANGED` is argless and fires only on a real change, assign and clear alike. **Deviation, by design**: a recognised token naming nothing (`/focus` with no target) clears the focus, the later clients' own behaviour; an *unrecognised* token raises `Unknown unit name` through the shared check, as every `Unit*` verb does, rather than silently dropping the focus |
| `/focus` argument grammar | partial, inferred | upstream's `docs/API.md` lists `FocusUnit`/`ClearFocus` and **no slash grammar**; pfUI's `modules/focus.lua` is the only evidence the aliases exist at all ("/focus and /clearfocus live in ClassicAPI's SlashCommandsRegistry now"). Bare `/focus` is the later clients' own meaning — focus the current target — and an argument is read as a *unit token*, the only thing this client can resolve, which is also why pfUI ships its own `/focusname` for names. Registered in `benilla-app`'s `ui_script::manifest::install_focus_slash_commands`, not beside the verbs, for a mechanical reason: the stock `ChatFrame.lua:680` **assigns** `SlashCmdList = { }` and `compat/` installs before FrameXML loads, so an entry made there would be dropped — same position and same reason as SuperWoW's macro-letters patch. `SLASH_FOCUS1` and `SLASH_CLEARFOCUS1` are therefore beyond-1.12 globals that the bare-VM surface test cannot see, which is why they are *not* in `reference_surface.rs`'s exception list (`FocusUnit`/`ClearFocus` are) |
| focus as an *app-side* token (`TargetUnit("focus")`, `CastSpellByName(spell, "focus")`, `/target focus`) | todo | `ui_unit.rs`'s `UnitTokens::resolve` is the app's own token resolver and is a plain `SystemParam` with no reach into the VM, where the focus guid lives, so it has no `"focus"` arm and `reach_tokens()` (which documents exactly what that resolver knows) stays unchanged. Nothing installed needs it: pfUI's `/castfocus` and `/swapfocus` both go through `TargetUnit(UnitGUID("focus"))`, a raw GUID — which is its **own** separate gap, since `UnitTokens::resolve` does not read SuperWoW's GUID-as-unit-id grammar either. Giving the resolver a focus arm means moving the guid app-side into a resource, which costs the request-pattern round trip `FocusUnit` is deliberately avoiding (`/swapfocus` is `FocusUnit("target")` then `TargetUnit(oldFocus)` in one Lua call, and a token resolved after that retarget committed would focus the wrong unit) — not guessed at here |
| `UnitInRange`, `UnitInLineOfSight`, `GetUnitSpeed`, `UnitSpellHaste`, `UnitCreatedBySpell`, `UnitCreatureTypeID` | todo | each needs data no feed supplies, and a **wrong** answer here is worse than an absent one because a caller cannot tell it is wrong: `UnitInRange` is a server-authoritative 40yd party check (not a distance calculation — the real client answers from a flag, and party positions aren't even fed, see the `UnitPosition` row); `UnitInLineOfSight` needs the collision raycast UnitXP's `inSight` also waits on; `GetUnitSpeed` needs per-unit movement-state speed, only the player's is known (`self_movement`); `UnitSpellHaste` has no 1.12 analogue to read (no haste stat exists in 1.12's `UNIT_FIELD`s); `UnitCreatedBySpell` needs `UNIT_CREATED_BY_SPELL`, unfed; `UnitCreatureTypeID` needs the numeric id behind `creature_type_name`, which arrives as a localized string only. Call counts in the installed set are 1–3 each, versus `UnitClassBase`'s 33 |
| Detection (`CLASSIC_API_VERSION`, `INTERFACE_VERSION`, `IsAddOnLoaded("!!!ClassicAPI")`) | deliberately not done | tried and reverted this session: a synthetic always-on addon entry is the real mechanism, but it leaked into enable-state file persistence (wrote `"!!!ClassicAPI: enabled"` into the player's own saved file) and inflated `GetNumAddOns()` for every other addon-lister — fixable, but not worth doing *before* a real namespace baseline exists per this file's own stated rule (a flag with nothing behind it is worse than no flag) |
| `Time.C_Timer.After`/`NewTimer`/`NewTicker` | done | `compat/classic_api.rs`'s `timer` submodule; a `PendingTimer` row per call (`script/model.rs`), drained by `UiScript::tick` against `GetTime()`. `NewTimer`/`NewTicker` return a handle table with `:Cancel()`; a `ReloadUI`/relog (a fresh VM) drops every pending one, matching the reference's own `C_Timer` lifetime. The reusable building block (an id'd, cancellable, `GetTime()`-driven callback row) UnitXP_SP3's deferred `timer` command can reuse rather than building its own |
| `RunNextFrame` | done | `compat/classic_api/timer.rs`'s `install_globals`, a zero-delay `C_Timer.After` row through the same queue — one drain, one place for a scheduling bug to live. pfUI uses it 5 times to defer work out of the handler that triggered it, and it is what broke the moment the addon's frames were driven by input. **It also exposed a real pre-existing bug in `tick.rs`'s `drain_timers`**: the drain empties `model.timers` with `mem::take` before iterating, so a timer armed from inside a callback landed in the emptied vec — and the drain then *assigned* its survivors back, discarding it. A self-rescheduling `After` chain fired exactly once and stopped dead, with nothing logged. Now merged; two tests pin it, and both were checked to fail against the old line (the chain test reported `left: 1, right: 4`) |
| `SetShown` on region leaves | done | `compat/classic_api/frame.rs`. It was Frame-only; pfUI calls it on a **FontString** (`f.group:SetShown(...)`, `api/unitframes.lua:582`). Now installed on all three method tables through the same one-line composition, which is sound because a region does have `Show`/`Hide` of its own: `script::REGION_LEAF_SHARED` registers the visibility four onto each leaf separately (Texture `0x79b580`, FontString `0x79cb70`) rather than hoisting them to the Region map, exactly as the reference does. A test pins that the pair the composition needs is actually on the leaf, so a tidying pass that moves them breaks the test rather than pfUI |
| `ObjectPoolMixin`, `CreateObjectPool`, `TexturePoolMixin`, `CreateTexturePool`, `TexturePool_HideAndClearAnchors` | done | `compat/classic_api/pools.rs`, the upstream's own structure as a Lua chunk over the existing `CreateFromMixins`. 1.12 has no pooling at all. **Load-blocking**: pfUI builds its tooltip buff-icon pool at module scope (`modules/tooltip.lua:217`), so the missing global aborted the rest of that module — which is also what left `pfUI.tooltip:Update` undefined and made the tooltip raise on hover. One missing global, two reported errors. The shape worth knowing: `EnumerateActive` returns `pairs(activeObjects)` and that table is keyed **by the object**, so `for icon in pool:EnumerateActive()` binds the object; a version storing objects as array values breaks that loop silently, and a test pins it. `table.getn` not `#` — `#` genuinely does not parse in this VM. `CreateFramePool`/`CreateFontStringPool` unbuilt, nothing calls them |
| `Totem`: slot constants + `GetTotemInfo` | partial (constants **inferred**) | `compat/classic_api/totem.rs`. **This deliberately reverses `misc.rs`'s earlier "not built" decision**, not because totem data appeared but because the absence turned out to cost most of pfUI's UI: it keys a table with the four slot constants at module scope, and `pfUI.lua:391` loops its modules with **no `pcall`**, so `table index is nil` aborted the loop and every later module plus the whole skins pass. `GetTotemInfo` answers **no values** — right for every non-shaman and for a shaman with nothing down, the only answer this client has data for, and all three pfUI call sites already guard it. Still wrong for a shaman with totems out, which is this row. `MAX_TOTEMS`/the four slots are the standard Blizzard values but unverified against ClassicAPI source; blast radius is bounded because `GetTotemInfo` always says "none", so the slot numbers only decide which of four colours an empty bar slot takes. `GetTotemTimeLeft`/`GetTotemDuration`/`TargetTotem` unbuilt — unreachable rather than broken (pfUI calls `TargetTotem` only from a right-click on an always-empty bar) |
| `EventRegistry`, `CallbackRegistryMixin:RegisterFrameEvent`/`RegisterFrameEventAndCallback` | done | `compat/classic_api/callback_registry.rs`. The bridge from real frame events into the callback bus; pfUI's new-item tracker is `EventRegistry:RegisterFrameEventAndCallback("BAG_NEW_ITEMS_UPDATED", ...)` (`modules/newitem.lua:60`). 1.12's `OnEvent` takes **no parameters** — the handler reads the globals `event`/`arg1..arg9` with `this` as the frame — so the forwarder cannot be upstream's `function(_, event, ...)`. It is defined at **chunk scope** on purpose: written as a closure inside `RegisterFrameEvent` it would capture that function's `event` parameter and shadow the per-fire global, making the frame report every event under the name of whichever registered first. A two-event test catches exactly that and was verified to fail against the closure version (`left: (1, 0)` — the wrong callback fired) |
| `GameTooltip_Hide` | done | `compat/classic_api/tooltip.rs`. A later-client FrameXML helper: `reference/1.12-globals.tsv` lists exactly six `GameTooltip_*` functions and this is not among them. Its purpose is to be passed *by name* as an `OnLeave` handler, which is all five of its call sites in the installed set — and nil there is not a no-op, it raised inside `HookScript` and took the rest of the module with it (`modules/friendnotes.lua:90`). Checked at the same time: `SetItemButtonTexture`/`SetItemButtonCount`, also called by the addons, **are** genuine 1.12 FrameXML globals and need nothing |
| `C_Spell.GetSpellReagents` | done | `compat/classic_api/spell.rs`, over new `SpellLookup::reagents` — `Spell.dbc`'s `Reagent[8]`/`ReagentCount[8]`, which `benilla-formats` already parses (`spells/display.rs:122`, with `catalog_tests.rs` pinning Slow Fall's `(17056, 1)`). Empty columns are dropped at the feed, so `reagents[1]` is the first *real* reagent. Returns an empty table for a spell that needs nothing and **nil** for an unknown id — genuinely different answers, both of which pfUI's `if reagents and reagents[1]` reads correctly (`modules/actionbar.lua:1553`). The subtle part: `spellbook.rs`'s `spell_display` resolves a *known* spell from the book, and a book slot carries no reagent columns — so the book arm now takes reagents from the probe while keeping the book's name/rank/icon. Without that, the spells most likely to be asked about (the ones on your bars) would be exactly the ones wrongly reporting no reagents; a test pins it and was verified to fail otherwise |
| **ClassicAPI tail — the measured remainder** | todo | A full sweep of every `C_<Namespace>.<Member>` the installed addons reference, minus everything built, leaves **46 members across 15 namespaces**. Recorded here so the next pass starts from measurement rather than guesswork. Grouped by what each actually needs: **pure algorithms, no client state** — `C_EncodingUtil` (`CompressString`/`DecompressString`/`EncodeBase`/`DecodeBase`/`SerializeJSON`/`DeserializeJSON`/`SerializeCBOR`/`DeserializeCBOR`), self-contained and mechanical. **Needs a live feed** — `C_Spell.UnitCastingInfo`/`UnitChannelInfo`/`ChannelInfo` (per-unit cast state; pfUI's real cast bars and nameplate cast bars depend on these), `C_Spell.IsSpellInRange`/`IsNextMeleeSpell`/`IsRangedAutoAttackSpell`/`ResetsMeleeSwing`/`GetSpellDispelType`. **Needs a 1.12-absent subsystem** — `C_EquipmentSet` (13 members; no equipment sets exist in 1.12 at all), `C_LootHistory` (3), `C_NewItems` (3), `C_PlayerCache` (2). **Small, data-backed** — `C_Item.GetCurrentItemLevel`/`GetItemUniquenessByID`, `C_FriendList.SetFriendNotes`, `C_QuestLog.GetQuestDetails`, `C_PlayerInfo.CanUseItem`, `C_Map.GetMapOverlays`, `C_ChatBubbles.GetAllChatBubbles`. (`C_Button.backdrop` is a field access on an addon's own table, not a namespace — a false positive of the sweep.) |
| `select` is nil, and real addons call it | open question, maintainer's call | Evidence for the standing stdlib-restore question in `lua_ext.rs`/`string_methods.rs`, not a new one. `lua50.rs` keeps `select` nil for 1.12 fidelity, and pfUI calls `select(7, GetTotemInfo(id))` in live handlers (`modules/totems.lua:18`, `:32`) — so on a real OctoWoW install, where ClassicAPI backports the 5.1 stdlib, those work and here they raise. Currently unreachable (the totem bar is always empty, see that row), so it costs nothing *today*; it is logged because it is the same decision as the string-metatable deviation and should be settled once, for the whole corpus, rather than per call site. Also confirmed while working here: **`#` does not parse in this VM at all**, so any chunk written for it must use `table.getn` |
| Lua 5.1 stdlib: `select`, `string.match`, `string.gmatch`, `math.fmod`, `math.modf` | done — **decision taken** | `compat/classic_api/stdlib_backport.rs`. This **resolves** the standing open question above, decided by the maintainer on live evidence (pfUI's `modules/marktracking.lua:300` uses `string.match` to parse a raid-target token and raised 8 times in one session). Scoped by **measurement**, not wholesale: these are the only five members any installed addon calls (12/7/5/2/1 sites). Deliberately still absent — `string.reverse`, `strrev`, `table.maxn`, `math.huge`, the hyperbolics, `coroutine`: nothing calls them, and `table.maxn` would fight `lua50.rs`'s `n`-based table library, which is 5.0 semantics this client needs. **Lives in `compat/`, not `lua50.rs`**: the dialect layer keeps describing 1.12 truthfully and compat re-adds what ClassicAPI adds, so a build that drops `compat/` is still strict 1.12. The restored functions are the **real 5.1 originals**, stashed under `lua50::REG_LUA51_PREFIX` before nil-ing — nothing is reimplemented, because a hand-rolled `string.match` would be a second, subtly different pattern engine, and a test proves the genuine one is in place (position captures, the non-greedy `-` quantifier). **Accepted cost, stated plainly**: an addon writing `if string.gmatch then` now takes the modern branch — which on this server, with ClassicAPI loaded, is the correct answer. Four fidelity gates updated rather than relaxed: `lua50.rs`'s own test now asserts the dialect still lists these on `REMOVED` *and* that they are reachable in the finished VM, so "compat restores it" is not licence for the dialect to stop removing it |
| `SetOwner: unknown anchor 'BOTTOMRIGHT'` | **unexplained — diagnostic added** | 566 occurrences in one live session, the loudest line in the log by 20×, and the cause is **not yet known**. Ruled out: every `SetOwner` call site in every installed addon `.lua` and `.xml` passes a valid `ANCHOR_*` string (verified with a paren-matching scan, after a naive regex truncated nested calls and gave a false reading); `script/tooltip/verbs.rs` does no prefix-stripping, matching the full uppercased name; and it does **not** reproduce under the addon harness, so it needs real in-world hovering. It is a *warning*, not an error — the anchor falls back to `ANCHOR_LEFT` and the tooltip still draws, just anchored wrongly. The warning now names the **owner frame**, which distinguishes an addon caller from the stock FrameXML off the player's patch chain; the next session log should identify it. Note `"ANCHOR_TOP"` (`pfUI/modules/mapreveal.lua:44`) and `"NONE"` (`modules/buffwatch.lua:117`) are separately invalid in 1.12 — the reference has nine anchor modes and neither is among them — so defaulting those to Left matches the reference's own silent behaviour |
| colour getters return a `ColorMixin`, not a tuple | fixed | `C_UnitAuras.GetAuraDispelTypeColor` returned `(r, g, b)`, but pfUI's line is `GetAuraDispelTypeColor(dtype or ""):GetRGBA()` (`api/unitframes.lua:1778`) — upstream's return *is* an object, so a tuple raises rather than merely reading awkwardly. Both it and `C_ClassColor.GetClassColor` now build through the real `CreateColor` (`color_mixin.rs`'s `color_object`), which fetches the global at call time rather than holding a `Function` handle, so install order inside this directory stays irrelevant. `GetClassColor` previously hand-rolled a shell carrying two formatters — enough for the `:WrapTextInColorCode` calls pfUI makes, latent for `:GetRGBA()`. Building a fresh object also settles that shell's own stated objection to a mixin (mutating a shared class colour would edit FrameXML's row): the `r`/`g`/`b` are copies, pinned by test |
| State (bare globals) | partial | `compat/classic_api/state.rs` + new per-tick posture plumbing: `SelfMovement` (`script/model.rs`), `UiScript::set_self_movement` (`script/self_movement.rs`), fed by `ui_unit::feed_self_movement` from the mover's movement flags (swim, fall), the descriptor (mount display id, `UNIT_FIELD_BYTES_2` form byte) and the area pass's own indoor down-ray. 1.12's Lua can reach none of these at all, so this is new engine data, not a wrapper. Done: `IsSwimming`, `IsMounted`, `IsIndoors`, `IsOutdoors`, `IsFalling`, `GetShapeshiftFormID`, and `IsInGroup`/`IsInRaid` (read the party/raid roster, the same authority `GetNumPartyMembers`/`GetNumRaidMembers` answer from — not duplicated into the posture snapshot). Not built, each for a stated reason in that file's header: `IsStealthed`/`GetSheathState`/`IsAssistingRitual` (no engine state tracks any of the three), `GetMirrorTimerInfo`/`GetMirrorTimerProgress` (benilla's mirror timers are event-only — `ui_mirror.rs` fires `MIRROR_TIMER_START`/`_PAUSE`/`_STOP` and keeps no queryable snapshot), `Dismount`/`CancelShapeshiftForm` (actions; vanilla cancels a form by re-casting its spell, and the engine knows the form *index*, not the spell behind it). Cost: `UPDATE_ACTIONABLE_CEILING` +3, cited in `game_plugins.rs`. **This same plumbing unblocks SuperWoW's own lowercase-initial `IsSwimming`/`IsMounted`/`isIndoors` siblings** (its "New functions" row above) — a later pass can wire those to `SelfMovement` directly instead of building anything |
| A **non-player** aura's `duration` / `expirationTime` | done | `crates/benilla-app/src/ui_aura.rs`'s `OtherAuraDurations`: a `(unit guid, spell id)` table stamped by `spell/net.rs`'s `on_spell_go`, joined into every other unit's aura list at the feed. **This was the hole behind "no debuff timers on the target frame".** pfUI-for-ClassicAPI reads its unit-frame timers straight off `C_UnitAuras.UnitAuraBySlot`'s `duration`/`expirationTime` (`api/unitframes.lua:1680,1788`) rather than through libdebuff — its own header says the plumbing "now runs on ClassicAPI's C_UnitAuras (which provides sourceUnit/sourceGUID and **non-player expirationTime**)" and libdebuff's `UnitDebuff`/`UnitOwnDebuff` survive only as adapters over it. So libdebuff could be tracking perfectly (it was: `libdebuff_all_auras` held rows) and the icons still draw no sweep, because the number they read came from us and we answered 0. There is no packet to answer from: `SMSG_UPDATE_AURA_DURATION` is self-only and `SMSG_SET_EXTRA_AURA_INFO`, which carries a caster's durations on others, is a 2.0 opcode. It is learned instead from the GO that applies the aura — which this client sees natively, with the apply instant being the packet's own arrival rather than a combat-log line to parse. Length comes from the same `ui_cast_events::aura_duration_ms` behind nampower's `arg8` and `GetSpellDuration`, so the three cannot disagree, and its `0` (permanent, no row, or a combo-point/level-scaled row — the `todo` row above) stamps nothing, leaving the icon timerless rather than counting to the wrong moment. The join is driven by the unit's own `UNIT_FIELD_AURA`, so a stamp for an aura the target resisted is never read, and a stamp that has run out reports nothing rather than a negative remainder. Not covered, by construction: an aura already on a unit before we streamed it, and one applied out of our range — no GO, no timer, which is what the mods this stands in for also do |
| UnitAuras (`C_UnitAuras`) | done | `compat/classic_api/unit_auras.rs`, modern named-table/slot shape over the same `AuraState` list the stock `UnitBuff`/`UnitDebuff`/`GetPlayerBuff` already read (including this session's SuperWoW spell-id extension). `GetAuraDataByIndex`, `GetBuffDataByIndex`, `GetDebuffDataByIndex`, `GetAuraDataBySlot`, `UnitAuraBySlot`, `GetAuraSlots`, `GetUnitAuras`, `GetUnitAuraBySpellID`, `GetPlayerAuraBySpellID`, `GetAuraDataBySpellName`, `GetAuraDispelTypeColor`, and the positional `UnitAura`/`UnitBuff`/`UnitDebuff` siblings. `RegisterComboDuration`/`RegisterAuraDurationModifierByTrigger` accept and discard: they are addon-side registration hooks with no 1.12 data behind them and nothing here would ever read the registration |
| Spell (`C_Spell`) | partial | `compat/classic_api/spell.rs`, spell-id-first: `DoesSpellExist`, `GetSpellName`, `GetSpellTexture`, `GetSpellSubtext`, `GetSpellInfo` (named table), `IsSpellPassive`, `IsSpellKnown`, `IsCurrentSpell`, `GetSpellCooldown`, `IsSpellUsable`, `GetSchoolString` (+ the seven `SCHOOL_MASK_*` constants), `CanDualWield`, `CastAtCursor`, `CastAtUnit`, `CancelSpellByID`. **The five display getters answer for any shipped spell**, not just the player's own ~200: `script/spellbook.rs`'s `spell_display` reads the book first (it carries the live icon substitutions) and falls back to the host's `Spell.dbc` probe for every other id — the fix for pfUI's `api/unitframes.lua:42`, which keys a predict table on `strlower(GetSpellTexture(774))` at file scope on every class. The probe carries only name/rank/icon, so the predicates below it (`IsSpellPassive`, `IsSpellKnown`, `IsCurrentSpell`, `GetSpellCooldown`, `IsSpellUsable`) still read the book alone, which is the right source for all five. The rest of the namespace's ~30 functions (`GetSpellDescription`, `GetSpellPowerCost`, `GetSpellReagents`, `GetSpellEffectInfo`, the range/harm/helpful predicates, `UnitCastingInfo`/`UnitChannelInfo`, `GetSpellLevelInfo`, …) are unstarted: each needs a `SpellDisplay` column the probe does not carry, and widening `SpellLookup` field by field is the route, with a reason each time |
| Spell — the per-unit cast feed (`C_Spell.UnitCastingInfo`, `UnitChannelInfo`, `CastingInfo`, `ChannelInfo`) | partial — **the feed is built; the `UNIT_SPELLCAST_*` events that drive pfUI's bars are not** | Split out of the `C_Spell` row above rather than folded into it, because this half is a live feed rather than a getter over data already in hand, and because what it does *not* yet reach is worth a row of its own. This closes four of the "ClassicAPI tail" row's 46 measured members — the three it filed under "needs a live feed" for cast state, plus `CastingInfo`, which upstream lists in the same breath (`docs/classic-api-functions.md`, the Spell section) and which is `UnitCastingInfo("player")` exactly. **Built**: `compat/classic_api/spell.rs`'s `cast_info` over `Model::unit_cast`, fed from `benilla-app`'s `ui_cast_events.rs` ([`CastWindows`]), which folds the **same queue of wire edges** that already raises SuperWoW's `UNIT_CASTEVENT` — `SMSG_SPELL_START`, `SMSG_SPELL_GO`, `SMSG_SPELL_FAILED_OTHER`, `MSG_CHANNEL_START`, plus three state-only edges added here (`SMSG_SPELL_DELAYED` pushback, `MSG_CHANNEL_UPDATE`, and `inflight.rs`'s local Esc/move cancel, none of which is one of the wiki's six `UNIT_CASTEVENT` words, so each folds state and fires nothing). One queue, not two: an addon woken by `UNIT_CASTEVENT` polls `C_Spell` for the timing the event does not carry (pfUI, `modules/nameplates.lua:648-656`), and each row's state is pushed to the VM *before* its own event fires so the two cannot contradict each other — `the_event_and_the_window_agree_inside_the_handler_the_event_woke` is that property, and it caught a real one-tick-stale bug on the way in. **Keyed by caster GUID, deliberately not a `UnitState` field**: tokens are a naming layer that moves under units, and a cast carried on `"target"`'s snapshot would hand the next target the old one's half-finished bar. A read folds token -> GUID through `Model::unit`, so every token spelling this client answers (stock, a raw SuperWoW GUID string, `"mark<n>"`, `"<base>owner"`, ClassicAPI's `"focus"`, `nameplate<N>`) reads the right window for free. **Units**: `startMs`/`endMs` are **milliseconds** on `GetTime()`'s clock, stamped at the drain — the same place and frame `ui_cast.rs` stamps the stock bar's `SPELLCAST_START`, so pfUI's bar and `CastingBarFrame` start on the same millisecond. The two verbs are disjoint (a channel answers only `UnitChannelInfo`), and the shapes differ by one field: `castID` exists for a cast and not for a channel, so `spellID` is the 9th return and the 8th respectively — both of pfUI's destructurings (`modules/nameplates.lua:83`/`:86`) are transcribed verbatim as the test, in `script/tests/cast_info.rs`, because a positional shape is only correct relative to the code that reads it. **Not backed, left nil rather than guessed** (each with its reason in `cast_info`'s doc): `isTradeskill` — 1.12 has no tradeskill column in `Spell.dbc` and no wire bit, so pfUI's queued-craft bar merge simply does not engage; `castID` — 1.12 carries no per-cast identifier anywhere; `notInterruptible` — no such flag exists in the client, in `Spell.dbc` or on the wire, and nil reads as false, which is what every 1.12 cast is; return slot 10 of the cast form — upstream puts something there (pfUI skips exactly one slot to reach `delayMs` at 11) and nothing in this tree says what. `text` (slot 2) answers as `name`; the one per-cast string the reference does spell differently is the stock channel bar's `CHANNELING` word, which is an argument of `SPELLCAST_CHANNEL_START` for the local player, not a per-unit field, and no consumer reads slot 2. `delayMs` (slot 11) **is** backed, from the accumulated `SMSG_SPELL_DELAYED` total. **Another unit's channel is not reachable** and is reported as nothing rather than faked: `MSG_CHANNEL_START`/`UPDATE` carry no caster and vmangos sends them to the caster alone, so only the local player's channel has a window. `UNIT_FIELD_CHANNEL_SPELL` (field 144, public) does name *which* spell another unit is channelling, but carries no start and no length, and a bar with an invented timer is worse than no bar — that field plus a `SpellDuration.dbc` column, with the 0 -> id edge as the start and an explicit nothing for a channel already running when the unit streamed in, is the measured route if it is ever wanted. **What this does not finish**: pfUI's cast bars are driven by ClassicAPI's `UNIT_SPELLCAST_*` token events, which benilla fires none of (the row below costs the per-`nameplate<N>` half; the stock `player`/`target`/`focus` half is equally unbuilt). Without them `modules/castbar.lua` stamps a bar only from its `PLAYER_TARGET_CHANGED`/`PLAYER_FOCUS_CHANGED` re-poll (`:340`) — so **a mob already mid-cast when you target it does now show a correct, correctly-timed bar, and one that starts casting while already targeted does not**; the player's own `pfPlayerCastbar` never stamps at all, since `arg1 == "player"` events are its only way in. Nameplates are the same shape: `modules/nameplates.lua:602` seeds `castState[guid]` from `PollCastInfo` at `NAME_PLATE_UNIT_ADDED`, so a plate that spawns on a casting mob draws its bar, while `:655`'s per-cast seed waits on the event. The feed was the blocking half (the row below records that an event with nothing to read behind it "would fire into a handler that learns nothing"); the events are now the whole remainder, and `C_Spell` is no longer what blocks them |
| Spell — the `UNIT_SPELLCAST_*` token events | done | **The other half of the row above, and the half pfUI's cast bars are actually driven by.** The feed answered *what* a unit is casting; nothing told an addon *when*, so `modules/castbar.lua` could only stamp a bar from its `PLAYER_TARGET_CHANGED`/`PLAYER_FOCUS_CHANGED` re-poll and `pfPlayerCastbar` never stamped at all. Built in `benilla-ui`'s new `script/cast_events.rs` (`UiScript::fire_unit_spellcast`, the fan-out and the arguments) plus `benilla-app`'s `ui_cast_events.rs` (`CastEdge::token_events`, which edge raises which event), fired by the existing `drain_cast_edges` off the **same queue of wire edges** that already raises `UNIT_CASTEVENT` and folds the windows — so an addon woken by an event and polling `C_Spell` in that handler cannot be told two different things. **Built: nine events.** `_START` (`SMSG_SPELL_START`), `_CHANNEL_START` (`MSG_CHANNEL_START`), `_SUCCEEDED` + `_STOP` (`SMSG_SPELL_GO`), `_INTERRUPTED` + `_STOP` (`SMSG_SPELL_FAILED_OTHER`, and the local Esc/move abort), `_FAILED` + `_STOP` (a failing `SMSG_CAST_RESULT`), `_DELAYED` (`SMSG_SPELL_DELAYED`), `_CHANNEL_UPDATE` and `_CHANNEL_STOP` (`MSG_CHANNEL_UPDATE`, split on its remaining time at 0). **Each is the stock bar's own word for the same packet** — the mapping is `ui_cast.rs`'s `CastBarEdge` one for one, which is the strongest available statement that `pfPlayerCastbar` and `CastingBarFrame` cannot tell two stories about one cast; `every_token_event_is_the_stock_bars_own_word_for_the_same_packet` is that table. The millisecond claim is the two drains' shared frame clock: both are in `UnitFeed`, both stamp off `script.now()`, and `the_players_bar_walks_start_pushback_and_stop_in_step_with_the_stock_bar` interleaves `SPELLCAST_START@100.000` with pfUI's own `startTime` of `100000` to show it. **`arg1..arg5` are `(unit, castGUID, spellID, name, rank)`**, taken from the consumer's own comment (`modules/castbar.lua:354`) and its reads (`arg5` → the bar's rank label at `:357`/`:102-107`, `arg3` → the craft counter at `:370`; the nameplate module reads `arg1` alone behind `strfind(arg1, "^nameplate")`). `arg2` is **nil** — 1.12 has no per-cast identifier anywhere, the same reason `UnitCastingInfo`'s `castID` is nil, and the two must agree. Name and rank come from the one `spell_display` body `C_Spell.GetSpellName`/`GetSpellSubtext` read, because pfUI *prefers* `arg5` over its own `GetSpellSubtext` fallback and two sources would print two ranks. All five slots are pushed on every fire, nil included: the handler is called positionally too, so a short push is a shorter event to anything reading `...`. **The per-token/per-GUID mismatch, which is the whole design.** A cast is per-GUID; these events are per-token; one mob can be `target` *and* `nameplate3` *and* `focus` at once and each drives a different frame, so a new `Model::tokens_for_guid` answers **every** live token and the fan-out fires once per token — `token_for_guid` (`UnitTokenFromGUID`'s singular) returns whichever the map walk reaches first, and firing under that one leaves whichever bar lost the coin flip permanently blank (`one_cast_fires_once_per_live_token_that_names_its_caster` fails with exactly one token when collapsed). The set is the **pushed token keys** only — `player`, `target`, `targettarget`, the focus pair, `mouseover`, `npc`, party/raid/pet, `nameplate<N>` and its target — deliberately not the derived spellings `Model::unit` also resolves (a raw 16-hex GUID, `mark<n>`, `<base>owner`): those are how a *caller* spells a unit it already holds, nothing registers a handler keyed on one, and fanning every edge across `mark1..8` plus an `owner` form per base would multiply the dispatch for no reader. Tokens resolve at **fire** time, not start time, which is what makes token loss safe: retarget off a casting mob and its `STOP` has no `target` to fire under, so the new target's bar survives the old cast ending. **Nothing fires on token *acquisition*** — pfUI already covers that itself (`castbar.lua:343`'s re-poll, `nameplates.lua:602`'s `NAME_PLATE_UNIT_ADDED` seed), so a synthetic start there would both duplicate it and be an event with no wire edge behind it. **Two orderings are read off the consumer, not guessed.** (1) A failing word always comes **before** its `STOP`: `ClearBar(cb, failed)` paints the cancelled-cast red flash only if `wasActive = cb.endTime ~= nil` (`:25`), and a plain `STOP` first nils `endTime` so the flash never paints — reversing the pair makes `failcolor` nil, verified. Both must fire, because the nameplate module registers `_STOP` and *not* the failing pair (`nameplates.lua:506-507`) and that is its only way to clear `castState[guid]`; without it an interrupted mob's plate bar runs to the cast's original end. (2) Events are **event-major, not token-major**, so when one unit answers two of a consumer's tokens (self-targeted: `player` and `target`, and pfUI's target bar handles both through its `UnitIsUnit(unit, "player")` leg) the failing word reaches that bar before any `STOP`. **Gating: `folded` — the window fold's own return — for every edge**, so events and windows are one state machine. A `START` fires exactly when a window opened, which means `Start { window: false }` (`opens_cast_bar`'s verdict, the *same* body `spell_start` uses for `SPELLCAST_START`) raises no token start, so Auto Shot's mid-Aimed-Shot `SMSG_SPELL_START` neither opens a bar nor reaps one; a terminal fires exactly when a window closed, which de-duplicates the `SMSG_CAST_RESULT`/`SMSG_SPELL_FAILED_OTHER` pair and the abort/FAILED_OTHER pair for free; and a pre-start rejection naming some *other* spell folds nothing, so it cannot reach in and wipe the bar of the cast actually running (pfUI's `ClearBar` has no way to tell which spell an event is about). **Two pre-existing window bugs this surfaced and closed.** (a) A failing `SMSG_CAST_RESULT` pushed no edge at all, so a cast the server killed with nothing but that packet — a mid-cast deselect, vmangos `HandleSetSelectionOpcode` → `Spell::cancel` → `SendCastResult(INTERRUPTED)` — kept reporting as live to its original end: a bar that starts and never ends. Now `CastEdge::ResultFail`, queued inside `cast_result` beside the `CastBarEdge::Failed` it mirrors. It raises **no** `UNIT_CASTEVENT`: that row sources FAIL from `SMSG_SPELL_FAILED_OTHER` alone, both packets reach us for one interrupted cast of our own, and doubling a word an addon counts to answer an unsettled question about the real hook would be worse than leaving it. (b) `prune` ran unconditionally before the rows, and a completed cast's `SMSG_SPELL_GO` lands within a frame of its window's own end *either side of it* (the end is `our START receipt + cast time`, the GO is sent at `server START + cast time`), so the GO found nothing to close and `_STOP` fired on a coin flip. `CastEventFeed::reprieve` now spares a window whose resolution is already in this tick's queue, keyed on the spell id like every other removal here, so the expiry sweep still means exactly what it says — a resolution that never came. **Not built, each with its reason.** `UNIT_SPELLCAST_SENT` — it fires at the client's own send, not off a packet, and no addon in the corpus registers it: a new producer in `cast_send.rs` for no reader. No `_STOP` for a window the expiry sweep *does* take (caster despawned, packet for a unit that left streaming range): both consumers end a bar at its own nominal end with no event (`castbar.lua:286-289`, `nameplates.lua:106`), and such a caster is typically named by no token to fire under anyway. No `_CHANNEL_STOP` when a cast `START` replaces a live channel — pfUI's `START` arm re-stamps and its nameplate arm overwrites, so the transition needs no announcement. `_SUCCEEDED` is fired for conformance, not for an effect that can be shown here: its only consumer is pfUI's craft counter, reachable only through `isTradeskill`, which 1.12 has no column for and the feed answers nil for by design (`merged` is asserted nil in the timing test). One **measured divergence left open**: the stock channel bar applies one gate the window does not (`0x6e7550`, `AttributesEx3 & 0x2000`), and it is unreachable — `benilla-formats`' `spells/display.rs:363-367` records that exactly two spells carry the bit, Blood Siphon 24322/24323, neither player-castable, and `MSG_CHANNEL_START` reaches us for the local player's own channel alone. The other arm of that gate (no `Spell.dbc` row) is invisible rather than divergent: a window whose id nothing can name makes `cast_info` answer nil, so no bar is drawn either way. **This also closes the cast half of the per-`nameplate<N>` row below**, which recorded the cast pair as blocked on `C_Spell.UnitCastingInfo`; that is built, the plate tokens do now receive `_START`/`_CHANNEL_START`/`_STOP`/`_CHANNEL_STOP`, and `a_nameplates_token_gets_the_cast_pair_its_module_registers_and_the_stop_that_clears_it` runs that module's transcribed arms. `UNIT_AURA`/`UNIT_FLAGS` per plate stay as that row leaves them. **Evidence**: `benilla-ui`'s `script/tests/cast_info.rs` for the fan-out and the five arguments, and `ui_cast_events.rs`'s own tests for the sequences — the latter transcribe pfUI's `ClearBar`/`StampBar`/`RefreshBar`/`OnUpdate` and its whole `OnEvent` body (`castbar.lua:24-39`, `:89-144`, `:148-175`, `:250-306`, `:340-420`) verbatim and run them against the real fold with both drains in one app, because an event's contract is only correct relative to the code that handles it. **Ambiguity cost: zero, measured.** `Update (actionable)` is 5581 against a ceiling of 5581, unmoved, and `PostUpdate` 466 — no new system (the work is inside the existing VM-holding `drain_cast_edges`, which `WOW_AMBIGUITY_DUMP=1` on the ratchet test, grepped for `drain_cast_edges`, puts at 0 pairs, being wholly in the VM-only explained bucket), no new `SystemParam` on it (the token set and `spell_display` are both reached through `UiScript`, on the far side of the boundary), and the one new app-side param — `Reply`'s `ResMut<CastEventFeed>` — is on `on_cast_result`, a `net_handler` one-shot that is not in `Update` at all (the same dump greps to 0 for it too). No new `benilla-app` file, so `ui_script_wall`'s game count stays at its pre-existing 43. No new bare Lua globals, so `reference_surface.rs` is untouched; the nine event names are modern and absent from `reference/1.12-events.tsv`, so `event_shape_gate` skips them as it does `UNIT_CASTEVENT` and the `NAME_PLATE_*` three. Harness unchanged at 13/13 load clean, 13/13 session start, 13/13 UI probe, 10/13 survived use — it drives no world, so no cast packet ever arrives and it cannot see this feature at all. |
| SpellBook (`C_SpellBook`) | partial | `compat/classic_api/spellbook.rs`: `FindSpellBookSlotByID`, `GetSpellBookItemInfo` (named table), `GetNumSpellBookSkillLines`, `GetSpellBookSkillLineInfo`, `GetSpellBookItemSkillLineIndex`. The remaining ~14 (`GetSkillLineIndexByID`, `GetSpellBookItemCastCount`, the loss-of-control pair, `IsClassTalentSpellBookItem`, `ContainsAnyDisenchantSpell`, `GetSpellLevelLearned`, `GetCurrentLevelSpells`, `GetPlayerSpellsByAura`, the skill-line name/rank getters, the auto-attack predicates) are unstarted; some have no 1.12 equivalent concept at all (modern "class talent" vs 1.12's talent tabs, loss-of-control as distinct from 1.12's CC) |
| ColorUtil (`C_ColorUtil`) | done | `compat/classic_api/color_util.rs`, all 8. The only namespace here with nothing to wrap: pure colour maths (RGB↔HSV↔HSL, achromatic input answering the upstream's own `h == -1` sentinel) plus the `|cAARRGGBB…|r` escape builders, which is 1.12's own format |
| ClassColor (`C_ClassColor`) | done | `compat/classic_api/class_color.rs`. Reads FrameXML's own `RAID_CLASS_COLORS` (`Fonts.xml`, off the player's chain) at call time rather than carrying a second copy of the nine colours that could drift from it; nil before FrameXML loads and for an unknown token. The returned table is the `r`/`g`/`b` fields every caller reads plus `GenerateHexColor`/`WrapTextInColorCode` — the two `ColorMixin` methods that are pure formatting over those fields. The mutating rest of `ColorMixin` (`SetRGBA`, `IsEqualTo`, …) is deliberately absent: a caller mutating a shared class colour would be editing FrameXML's own table |
| Expansion | done | `compat/classic_api/expansion.rs`: `GetClassicExpansionLevel` (0, `LE_EXPANSION_CLASSIC`) and the two comparisons. Constants by design — a fork targeting a later era changes the one constant, not three functions |
| Input | partial | `compat/classic_api/input.rs`: the six `Is{Left,Right}{Shift,Control,Alt}KeyDown` plus `IsModifierKeyDown`. **Each side of a pair answers the combined bit**: `Model::modifiers` is one `(shift, ctrl, alt)` triple (what the stock sideless `IsShiftKeyDown` family reads) and 1.12 exposes no sided getter, so there is no sided state to report — which is what ClassicAPI itself does on a client that cannot tell them apart, rather than fabricating `false` for one half. Not built: `IsMouseButtonDown` (the only press state is `Model::mouse_down_on`, which the pointer layer fills *only* for a press that landed on a frame — a world press would read as not-down, wrong more often than right) and `GetMouseButtonClicked` (wants the button that triggered the running handler; dispatch passes it to `OnClick` as an argument and keeps no ambient current-event button) |
| Lua | partial, by design | `compat/classic_api/lua_ext.rs`: `table.count`, `Mixin`, `CreateFromMixins`, `strreplace`. Only names 1.12 has in neither library nor global, so nothing `lua50.rs` nils gets un-nilled and no addon's `string.gmatch or string.gfind` feature test changes answer — the stdlib-restore question stays the maintainer's call (that file's header, and this table's own Lua-5.1-stdlib row above). A test in that file asserts `select`/`coroutine`/`string.reverse`/`string.gmatch`/`table.maxn` are all still nil, plus `strrev` — which ClassicAPI does provide, but `tests/stdlib.rs`'s `the_rest_of_the_bare_globals` already pins nil for the same era-feature-detection reason, so adding it is that same maintainer call rather than a separate one — so a later pass can't restore any of them by accident. `strsplit`/`strjoin`/`trim`/`wipe` already exist as benilla globals for unrelated TurtleWoW-FrameXML reasons and are not re-registered |
| Currency (`C_CurrencyInfo`) | done, delegating | `compat/classic_api/misc.rs`. `GetCoinTextureString` is a *FrameXML* function in 1.12 (`MoneyFrame.lua`), loaded off the player's chain after this installs — so the bare global is left to FrameXML (a Rust copy would be both a second source of truth and dead, since FrameXML's would overwrite it) and `C_CurrencyInfo.GetCoinTextureString` reads that global at call time, forwarding the optional font height. Answers nil before FrameXML has loaded |
| Events | partial | `compat/classic_api/misc.rs`. `GetFramesRegisteredForEvent` is real: the registry's own list in registration order, which is also the order `fire_event` walks, and an empty table (never nil) for an unregistered event so `getn` is always safe. `C_EventUtils` exists but is **empty** — `IsEventValid` has no authority to answer from: `RegisterEvent` accepts any string (`script/event.rs`) and the only 1.12 event catalogue is `reference/1.12-events.tsv`, a test fixture that isn't compiled in. Answering `true` for everything would be a lie an addon branches on |
| System | partial | `compat/classic_api/misc.rs`. `GetPhysicalScreenSize` answers the UI screen rect's size, with a stated deviation: modern WoW returns true *device* pixels, where this is the logical rect the host pushes through `set_screen_size` — the two differ under a non-1 UI scale or DPI factor, which this crate cannot see. `CopyToClipboard` not built: `benilla-ui` is deliberately engine-free (no windowing, no OS handles) and a clipboard is an OS capability; the workspace's `arboard` sits behind the app's dev tooling, so reaching it means a new host-callback seam through `Model`, which is plumbing rather than a binding |
| Combat | partial | `compat/classic_api/misc.rs`. `InCombatLockdown()` → always `false`, and that is the honest answer rather than a stub: the lockdown exists on modern clients to refuse secure-frame edits mid-combat and 1.12 has no secure-template system at all, so nothing here is ever locked down. `StartAttack`/`StopAttack` deliberately not added here — they are 1.12's *own* verbs that benilla hasn't built yet, so registering them from `compat/` would put a stock gap in the wrong layer and hide it from the reference-surface accounting |
| Class, Totem, Tracking, Instance | todo, blocked | `FillLocalizedClassList`: the nine localized class names are DBC-resolved app-side (`benilla-app`'s `ui_unit::class_names`) and `benilla-ui` deliberately holds no DBC — the player's own class reaches it through `PlayerRecord`, but not all nine, so this needs a feed like `SelfMovement`'s, not a binding. `Totem` (4 functions): no totem state exists in the model at all; 1.12's own totem bar is unbuilt, so there is nothing to wrap. `Tracking` (3): `Model::tracking` is the one *active* tracking aura (behind the stock `GetTrackingTexture`), not the enumerable list of known tracking spells these index into. `GetInstanceInfo`: `script/instance.rs` feeds only the instance *type*; the modern tuple also wants the instance name, difficulty index and name, and max players — none tracked, and the name would have to be guessed from zone text |
| Hooks (`hooksecurefunc`) | done | `compat/classic_api/hooks.rs`, both documented forms (over a global, over a table field). Pure Lua machinery, no game state. The contract it keeps, each covered by its own test: the original runs first with the caller's arguments; **the original's return values pass through untouched** and the hook's are discarded; a hook that errors has its error recorded (`Model::record_script_error`) and the original's returns still come back, while the *original's* own error still propagates; and hooking twice **chains** in install order rather than replacing. A name holding no function is a silent no-op — the reference raises, but an addon written against a client that has the verb it meant to hook is the common case here and taking its UI down over a missing one would be worse. The original and hook live in the Lua registry, since this crate holds no persistent `Function` handle |
| Frame (widget methods) | partial | `compat/classic_api/frame.rs`. These are **methods, not globals**, written straight into the stock class method tables (`__benilla_frame_methods` and the two region leaves) — `object.rs`'s `frame_meta_for` *links* those tables rather than copying them ("a later write to a table shows through"), so a late install from `compat/` reaches every widget already made and every one made later. Built: `SetShown`, `GetSize`/`SetSize`, `GetRect`, `SetFormattedText` (FontString), `HookScript`, `IsEventRegistered`, `GetEffectiveAlpha`, and `SetAttribute`/`SetAttributeNoHandler`/`GetAttribute`/`ClearAttribute`. The geometry/visibility/text ones are composed from the stock verbs as a Lua chunk, so they reuse the stock resolution exactly instead of duplicating it in Rust — note the chunks return a function rather than reading `...`, since this VM is 1.12's Lua **5.0** where `...` is a parameter-list token only, never an expression. Skipped, each with the reason in that file's header: the **mask** and **atlas** families (benilla's UI quad carries one texture and a UV rect — no mask slot, no atlas registry; needs a render-path feature first), the **secure-template** family (`RegisterStateDriver`, `RegisterUnitWatch`, `SecureCmdOptionParse`, `SecureButton_*`, … — modern restricted execution, which 1.12 has no equivalent of; `SetAttribute`/`GetAttribute` ARE built because stripped of secure semantics they are just a per-frame key/value store, and that much is honest, but the drivers that *watch* attributes are the actual subsystem and are not), the **per-line** text-measurement getters (`GetNumLines`, `GetWrappedWidth`, `IsTruncated`, … — need per-line layout facts the host measurer is not asked for today; `measure.rs` answers one whole-string width/height). **`GetStringHeight` was on that skipped list and has been built**, because the blanket reason did not apply to it: the whole-string height is the other half of the number `GetStringWidth` already reads, so `measure::current_measure` now owns the staleness rule for both and the method is a read, not a new host question. AceGUI-3.0 calls it **unguarded** (`AceGUIWidget-Label.lua:54` `height = label:GetStringHeight()`; `AceGUIWidget-CheckBox.lua:90,210` `self:SetHeight(28 + self.desc:GetStringHeight())`), so a nil method there raises and takes the library's own zero-height fallback with it. **Correction, and it matters:** those are the `Libs/` (Mainline), `2.4.3/` and `3.3.5/` library trees AI_VoiceOver ships — **not** the `1.12/` tree its TOC actually loads, which reads `label:GetHeight()` instead and has had every one-argument `SetPoint` rewritten besides. This method is therefore ClassicAPI **parity surface**, not the fix for anything on this install, and the earlier claim here that it explained "can't see the VoiceOver options" was wrong. That symptom was **ours and elsewhere**: the ScrollFrame child re-anchor replaced the child's whole anchor list where 1.12's `SetPoint` merges one point into it, so AceGUI's `TOPLEFT`/`TOPRIGHT`-authored scroll child lost the half that gave it a width and resolved to no rect — and nothing below it resolved either. Fixed in `layout.rs`'s `set_frame_anchored`; measured through the same probe, which went from every node under the scroll child answering `GetLeft() == nil` to a populated, correctly placed tree. Kept because the blanket "needs per-line layout facts" reason genuinely does not apply to it and a 2.4.3/3.3.5 client of this library would need it; what was learned is that an addon shipping several library copies has to be read through its own TOC chain before any call site in it is evidence. Also in this family, each plausible and untraced this pass: `IsMouseOver`/`GetMouseFoci`/`IsDragging`/`SetResizeBounds`/`RegisterUnitEvent`/`SetColorTexture`/desaturation/rotation/the EditBox cursor-and-highlight getters (plausible, untraced this pass). All 12 new methods are registered in `widget_surface.rs`'s `ALLOWED_BEYOND` with their reasons |
| Container (`C_Container`) | done | `compat/classic_api/container.rs`; almost entirely translation over the stock 1.12 bag verbs' own data (`Model.containers`), not new game logic. `GetContainerItemID/Info`, `HasContainerItem`, `GetContainerItemDurability`, `GetContainerNumFreeSlots`/`GetContainerFreeSlots`, `CalculateTotalNumberOfFreeBagSlots`, `PlayerHasHearthstone`/`UseHearthstone` (scans bags 0-4 for item id 6948), `SwapItems`/`MoveItem`/`AutoStoreItem` (queue the same `ContainerMove`/`BagAutoStore` the stock pickup/place path does), `SortBags`/`SortBankBags` (no-ops — 1.12 has no sort algorithm to run) and the three sort-preference toggle pairs (stored, nothing downstream reads them) are real. Deliberately nil/false, not guessed: `GetContainerItemCharges` (same charge-slot-identity blocker as SuperWoW's), `GetContainerItemRepairCost` (server-only in vanilla), `GetContainerItemQuestInfo`/`GetContainerItemEquipmentSetInfo` (no such tracking exists, and no such feature exists in 1.12 at all for the latter), `IsContainerItemOpenable` (no lockbox flag tracked) |
| CreatureInfo (`C_CreatureInfo`) | partial | `compat/classic_api/creature_info.rs`, the 3 of 9 anything installed actually calls. `GetRaceInfo` and `GetFactionInfo` read a **new app→VM feed of the player's own `ChrRaces.dbc`** (`benilla-formats`' `chr_races.rs` → `benilla-app`'s `chr_races.rs` → `UiScript::set_race_info`), built because this crate holds no DBC and a frozen race table gets a modified realm's names wrong: **OctoWoW's row 10 displays "High Elf" where Blizzard's says "Blood Elf"**, while both keep `clientFileString "BloodElf"` for the art paths — the two columns genuinely disagree, so neither can be derived from the other, and a test pins that. The side on `GetFactionInfo` comes from `ui_unit.rs`'s `race_faction_group`, the same answer `UnitFactionGroup("player")` gives, so the two cannot disagree about a race; a non-playable row carries no side and reads nil rather than a guess. **`GetRaceInfo` answering nil past the last race is load-bearing** — pfUI walks `i = 1, 2, 3…` until nil, so an always-non-nil answer hangs the client at load; its own test says so. `GetCreatureID` decodes the template entry out of bits 24-47 of the 16-hex-digit GUID token the rest of `compat/` passes around, accepting **only** the creature high word so a player or pet GUID answers nil instead of a plausible-looking wrong number (the decode is inlined rather than calling `benilla_protocol::guid::entry` — this crate depends on no protocol or engine crate, and one shift is not worth breaking that boundary for). Not built: `GetCreatureInfoByID`, `RequestLoadCreatureByID`, `GetCreatureFamilyInfo`/`IDs`, `GetCreatureTypeInfo`/`IDs` (each needs a creature/family/type table this VM is not fed, and nothing installed asks) and `GetClassInfo` (the class table exists app-side as `ChrClasses` but has no VM feed yet — the same shape of work this row's race feed just did, if an addon ever wants it). With no install the race table stays empty and every reader answers nil, so an addon's race walk finds none and still loads |
| Item (`C_Item`) | partial | `compat/classic_api/item.rs`, 37 entries. Modern id-first and `ItemLocation`-keyed readers over the same state the stock item verbs read: `Model::item_templates` (the one `ItemTemplateView` cache every item tooltip renders through — a miss records the same `CMSG_ITEM_QUERY` ask the stock `GetItemInfo` does, so a modern caller warms the one shared cache, not a parallel one), `Model::containers` and `Model::inventory_slots`. **`ItemLocation` is accepted as the plain table addons build** (`{bagID=, slotIndex=}` / `{equipmentSlotIndex=}`): modern WoW's mixin is pure Lua sugar over exactly those two fields and every entry point only reads them, so the table *is* the contract; the mixin constructors themselves belong with `Mixin`/`CreateFromMixins` in the `Lua` namespace and are not faked here. Built: the existence/identity trio, `GetItemData`/`GetItemDataByID` (the upstream's kitchen-sink table, including the `isConjured`/`isOpenable`/`isLootable`/`isWrapper` flag bools off the template's raw `flags`), `GetItemInfoInstant`, the by-id and by-location getter pairs (name, quality, max stack, sell price, set id, inventory type, icon), `GetItemLink`, `GetStackCount`, `GetItemCount` (bags + worn, with the `includeBank` and charge-multiplying `includeUses` flags), `GetItemSpell` (the on-use trigger only — triggers 0/5, not an equip or chance-on-hit effect), `IsUsableItem`/`IsConsumableItem`/`IsEquippableItem`/`IsEquippedItem`/`IsItemOpenable`/`IsBound`, the `IsItemDataCached` pair (which deliberately record **no** ask — polling is not asking), the two inventory-slot name getters, and `UseItemByName`/`EquipItemByName` over the stock container-use queue. Not built, each with the reason in that file's header: the **guid** family (`GetItemGUID`, `GetItemLocation`, `IsItemGUIDInInventory`, …) — nothing in the model keys items by instance guid, and the modern `"Item-Server-…"` string has no source here; the **item-level** family (`GetCurrentItemLevel`, `GetDetailedItemLevelInfo`, `GetAverageItemLevel`) — item level is not in `SMSG_ITEM_QUERY_SINGLE_RESPONSE` and 1.12 exposes no such concept to the client; `GetItemStats`/`GetItemStatDelta` — the modern shape is keyed by `ITEM_MOD_*` *string* names resolved app-side, and returning the raw numeric keys under the modern name would silently mismatch; `GetItemUniqueness` (wants a limit-category pair 1.12 has no counterpart for); the `LockItem`/`UnlockItem` family (`ContainerSlot::locked` is a pending-operation flag the app owns, not a lock Lua may set); and `UseAtCursor`/`UseAtUnit`/`PickupItem`/`RequestLoadItemData*` (each needs an app-drained queue that does not exist yet) |
| AddOns (`C_AddOns`) | done | `compat/classic_api/addons.rs`, 10 entries, and deliberately **pure delegation**: every one calls the stock global (`script/addon.rs`) rather than reading `Model::addons` a second time, so the index-or-name parsing, the unknown-name placeholder answers and the load-gate verdicts keep one owner — a caller cannot get a different answer from `C_AddOns.IsAddOnLoaded` than from `IsAddOnLoaded`. `GetAddOnName`/`Title`/`Notes` and `IsAddOnLoadable` are `GetAddOnInfo` returns 1/2/3/5; `IsAddOnLoaded`/`LoadAddOn` pass straight through; `DoesAddOnExist` reads the `"MISSING"` reason rather than "something came back"; `GetAddOnSecurity` maps the stock `SECURE`/`INSECURE` string onto the upstream's `Enum.AddOnSecurityStatus`, answering `NotAvailable` (3) for an absent addon rather than defaulting to insecure (`Banned` (2) is unreachable — it comes from a server addon-banlist this client does not model). `GetAddOnOptionalDependencies` answers **none**, not the required list: 1.12's `.toc` has no optional-dependency directive at all, and returning the required ones would make a caller treat a hard dependency as skippable. `GetAddOnLocalTable` is not built — modern WoW passes each addon file a private table as a load argument and 1.12 passes addon files no arguments, so there is no such table to hand back; inventing an empty one would read as "my locals are empty" rather than "this client has no such feature". A fixture note worth keeping: the addon *index* array stays empty until the server's `SMSG_ADDON_INFO` reply lands, so any by-index read raises before it — faithful to 1.12, and what a test must call `note_addon_info_reply` to exercise |
| GameTooltip (reader methods) | partial | `compat/classic_api/tooltip.rs`, 8 widget **methods** (not globals) on the GameTooltip class table, same linking mechanism `frame.rs` documents. The valuable half of the namespace: addons constantly ask "what is this tooltip showing?" before annotating it. This needed **new state** — `TooltipState::subject` (`widget/kinds/mod.rs`, with a `TooltipSubject` item/spell enum): 1.12 keeps the same facts (the reference holds the item id at `tooltip+0x398`) but exposes no getter, so nothing in this client read them. Recorded at the **two renderers every verb funnels through** — `tooltip_item/render.rs`'s `render_view` (12 call sites, each now passing its own `item_id`, so the compiler enforced coverage) and `tooltip_spell.rs`'s `render_spell` — which is why `SetBagItem`, `SetMerchantItem`, `SetLootItem`, `SetHyperlink` and the rest all answer `GetItem` without each needing its own wiring; cleared with the content, so a `ClearLines` drops it. Built: `GetItem` (name, link, itemID), `GetSpell` (name, rank, spellID), `HasItem`, `HasSpell`, `GetUnit` (over the `unit_token` the stock `SetUnit` already kept), `HasUnit`, `GetOwner` (returns the real frame object through the same `frame_wrapper` `GetParent` uses), `IsEquippedItem`. Each returns *no values* rather than nils when there is no subject, the upstream's documented shape and what `if name then` branches on. Not built, each with the reason: `GetUnitGUID` — the modern getter promises the guid as of when the tooltip was set, and resolving the stored *token* now would be right most of the time and silently wrong exactly when it matters (a `"mouseover"` tooltip outliving its mouseover); `GetGameObject`/`HasGameObject` — no GameObject subject is recorded anywhere and there is no object-template cache keyed like `item_templates`; the `Set*ByID` aliases (`SetItemByID`, `SetSpellByID`, `AddSpellByID`, `SetInventoryItemByID`) — the stock verbs they alias already exist under 1.12 names and each needs its own argument-shape check against them; `SetTalentByID`/`SetEquipmentSet`/`SetTotem` — no backing (`Talent.dbc` unreachable from this crate, no equipment-set feature in 1.12 at all, no totem state). Since built: `SetHyperlinkCompareItem`, which this list had turned down on the grounds that the compare chain needs a shopping-tooltip pair — wrong, because 1.12's own merchant and auction compares drive that pair already (its own row below) |
| Quest (`C_QuestLog`) | partial | `compat/classic_api/quest_log.rs`, questID-keyed over the same log rows the stock verbs index by position — the gap being that 1.12's API never hands Lua a questID at all, so an addon can otherwise only key by an index that shifts when the log changes. Built: `GetInfo`, `GetQuestLogTitle` (the documented positional list, whose third value is `suggestedGroup` where the stock global keeps the tag — both coexist), `GetQuestIDForLogIndex` (0 for a header, nil out of range), `GetLogIndexForQuestID`, `GetHeaderIndexForQuest`, `IsOnQuest` (counts rows folded under a collapsed header, via `hidden_quest_ids`), `IsUnitOnQuest` (answers for `"player"`; false for any other token, since another unit's quest list is not tracked — the same blocker the stock `IsUnitOnQuest` already has), `GetNumQuestObjectives`. Not built: `RequestLoadQuestByID`/`IsQuestDataCachedByID`/`GetTitleForQuestID`/`GetQuestDetails` — all four probe a *standalone* questID-keyed static-info cache fed by `CMSG_QUEST_QUERY`, which benilla has none of (`QuestLogEntryView::detail` is per-log-row, so nothing is knowable about a quest not in the log, and `QUEST_DATA_LOAD_RESULT` has no sender); a cache plus its query is app-side plumbing. The bare `GetQuestLogLeaderBoardID` is also not built: `QuestLogObjectiveView` carries `kind`/`text`/`cur`/`req` but no creature/object/item id, so there is nothing to return — closing it means carrying that id along from the app's template read |
| Faction (`C_Reputation` + 3 bare globals) | partial | `compat/classic_api/faction.rs`. Bare: `GetFactionIDByIndex`, `GetFactionInfoByID` (the same eleven values `GetFactionInfo` returns, keyed by id), `GetFactionParentID`. `C_Reputation`: `GetFactionStandings`, `GetFactionDataByID`/`ByIndex`, `GetWatchedFactionData`, `SetSelectedFactionByID`, `SetWatchedFactionByID`, `ToggleFactionAtWarByID`, `IsFactionActive`/`ByID`, `SetFactionInactiveByID`/`SetFactionActiveByID`. Every setter queues onto the **same** `reputation_sends` queue the stock pane's own toggles use, so an id-keyed call and an index-keyed one are indistinguishable downstream and cannot race; a faction not in the list sends nothing rather than a wrong slot. **One scope limit, stated once in that file's header:** upstream answers for any `Faction.dbc` row including unencountered factions (DBC name + Neutral defaults), and `benilla-ui` holds no DBC, so these answer for a **listed** faction and nil otherwise — narrower reach, identical shape for anything a caller reaches by walking `GetNumFactions()`. Not built: `GetLastStandingChange` — `ReputationState` is a whole-list snapshot with no delta or history to answer from |
| FriendList (`C_FriendList`) | partial | `compat/classic_api/friend_list.rs`, named tables over `Model.social`: `GetNumFriends`, `GetNumOnlineFriends`, `GetFriendInfoByIndex`, `GetFriendInfo` (by name, case-insensitive), `IsIgnored`, `SendWhoQueryByName` (queues the stock `SocialRequest::Who`, so modern and stock `/who` share one request path), `GetNumWhoResults` (both counts), `GetWhoInfo`. Not built: `SetFriendNotes`/`ByIndex` — friend notes are a 2.x feature and `SMSG_FRIEND_LIST` carries no note field, so accepting one would make a notes UI look like it worked; `IsFriend`/`IsIgnoredByGuid` — both key on a GUID and the social lists hold names only (the app resolves guid→name before pushing, keeping no reverse map), while the name-keyed `IsIgnored` sibling is built. `IsWhoQueryPending` answers false always: the app drains the request and pushes the reply as a whole new state, keeping no in-flight marker |
| Gossip (`C_GossipInfo`) | done | `compat/classic_api/gossip.rs`, all 11. Table-per-row where 1.12 returns flat positional runs (`GetGossipOptions` strides by 2). Selection stays **index-keyed**, documented in-file: `gossipOptionID` on a modern client is a server id 1.12 never sends, so `SelectOption`/`SelectOptionByIndex` both take the 1-based position and both queue onto the stock `gossip_selects`; `SelectAvailableQuest`/`SelectActiveQuest` take a per-side position and map it to the whole-list position, the same mapping the stock verbs make. A coded option queues nothing, as the stock binding skips it. Empty tables never nil, so `getn` is always safe |
| MerchantFrame (`C_MerchantFrame`) + Mail link getters | partial | `compat/classic_api/merchant_frame.rs`. Real: `GetItemInfo` (named table over the merchant row), `GetBuybackItemID` (the stock buyback verbs answer name/texture/price but never the id — the whole gap), `GetNumJunkItems` (grey stacks in bags 0-4, real because `ContainerSlot` tracks quality). Honest constants rather than stubs: `IsMerchantItemRefundable` → false (refunds are 4.x; 1.12 has buyback instead, already exposed), `IsSellAllJunkEnabled` → false and `SellAllJunkItems` a no-op (later-era vendor feature, so a UI gating a button on it correctly hides it rather than selling nothing while the caller believes otherwise). **Also closes two SuperWoW rows:** `GetSendMailItemLink` (real per-instance link off the attached cursor item) and `GetInboxItemLink` (the *basic* itemID-only form, which is what upstream specifies here deliberately — built from the row's `item_id`+`item_name`, since the app pushes links for bag/bank/cursor items but not inbox ones). Both take the optional `attachmentIndex` and answer nothing for anything but nil/1, as 1.12 mail holds one attachment |
| CVar (`C_CVar`) | done | `compat/classic_api/cvar.rs`, all 8, over the same registry the stock `GetCVar`/`SetCVar`/`RegisterCVar` drive (`script/cvars.rs`). `GetCVarInfo`'s seven returns; `DoesCVarExist` (true exactly when `GetCVar`/`SetCVar` work, which is upstream's own stated invariant and a test pins it); `AreCVarsLoaded` (always true, as upstream documents and for its reason — settings load before any Lua exists); `GetCVarBool` on upstream's documented coercion table (`"true"` case-insensitive, any non-zero numeric, everything else false, nil for no row so false and absent stay apart); `GetCVarBitfield`/`SetCVarBitfield` as real 1..=64 bit arithmetic routed back through the stock `write_cvar`, so a bit write queues to the host and dirties the config exactly as a `SetCVar` would. `isReadOnly` answers `false`, and that is honest rather than a stub: `write_cvar` refuses only a name with *no row*, never a registered one, so `SetCVar` really does work on every CVar this reports on — a fork that later makes some row refuse writes should flip this to read that. `SetTempCVar`/`RemoveTempCVar` are **fully correct, not just Lua-observable**: a new `CvarSlot::temp_original` remembers the pre-temp value and `UiScript::cvars_snapshot` reports *that* to the saver, so a temp override is live for `GetCVar` yet never written to `config.toml` — which is the whole contract of a temp CVar. Not a 1.12 concept at all (the reference has no temp CVar) |
| NamePlate (`C_NamePlate`) | done | `compat/classic_api/nameplate.rs`, all 4, over the plate pool benilla already drives (`script/nameplate.rs`'s `NamePlates`, fed by `vplates.rs`). The GUID↔frame mapping existed already for SuperWoW's `frame:GetName(1)` (`guid_for_frame`); this adds its two inverses, `NamePlates::live` and `frame_for_guid`. `GetNamePlates`/`GetNamePlateGUIDs` answer in pool order and pair by index (a test walks both lists and matches each frame to its own GUID); `GetNamePlateForUnit` resolves through `Model::unit`, so SuperWoW's extended token grammar (raw GUID, `markN`, `<token>owner`) works as a unit argument here too; `GetNamePlateForGUID` takes the same 16-hex-digit token the rest of `compat/` passes around. One stated deviation: modern WoW hands back a *container* whose `.UnitFrame` child is the plate, because its nameplates are FrameXML-driven — benilla's are engine frames with no wrapper, so these return the plate itself and an addon reaching for `.UnitFrame` finds nil rather than a fake child. `GetNamePlates`' `includeForbidden` argument is accepted and ignored: 1.12 has no protected-frame split to filter on |
| Macro (`C_Macro`) | partial | `compat/classic_api/macro_ext.rs`: `GetMacroIcon`, `CreateMacro`, `EditMacro`, over the same table the stock macro globals drive (`script/macros.rs`). Upstream's stated reason for the namespace only half-applies here — its complaint is that stock's icon argument is an *index* into a list holding no `INV_*` item icons, but benilla's own `icon_path` already took a string or an index, so a string icon was never refused. What these genuinely add is the signature: `CreateMacro`'s fourth argument is `isCharacterMacro` where the stock global's fourth is `localOnly` and per-character is its *fifth*, and `EditMacro` accepts a macro **name** in place of an index. `GetMacroIcon` re-adds the `Interface\Icons\` prefix on read, with the one deviation stated: upstream answers the icon a macro *shows* (the resolved spell's or item's when a `#showtooltip` resolved over a question-mark icon), where this is always the macro's own stored icon — upstream's own documented fallback. Not built, each for a reason in that file's header: `GetMacroSpell`/`GetMacroItem` (both answer for a resolved `#showtooltip`, backed upstream by a spellID cache the editor fills at save time; benilla parses no directive, keeps no such cache, and resolving a body's first `/cast` to `(name, rank, spellID)` needs the rank-aware spellbook lookup `C_Spell`'s row already notes is unbuilt), `StopMacro` (stops the body *running now*, and benilla executes no macro bodies at all — no `RunMacro`, no depth counter, nothing to stop), `C_Macro.SetMacroDisplay` (no per-macro action-button display override is tracked), and the four `Get*MacroIcons` enumerations (they split `loose` on-disk icons against `mpq` archive ones; `Model::macro_icons` is one flat `Vec<String>` with **no provenance**, so that axis cannot be answered at all, and splitting on basename alone would silently under-report whichever source the host did not push) |
| Action (`GetActionInfo`) | done | `compat/classic_api/action.rs`, one bare global, over the same action table the stock `GetActionTexture`/`GetActionCount`/`IsConsumableAction` read (`script/action.rs`'s `Model::actions`). Upstream unpacks a `uint32` type tag and then has to disambiguate its one ambiguous tag (macro-or-bag-item) by walking the macro-slot map; benilla needs none of that, because the host pushes `ActionSlot::kind` already separated into the three `ACTION_KIND_*` bytes — the tag is read, not inferred, and that ambiguity does not exist here. One place this is *better* than upstream: upstream returns `"item", nil` for a bag-instance reference because extracting the id "needs more reversing than we've done", where benilla's slot carries the resolved id for every kind. `subType` is `"spell"` only for a spell action, as upstream documents |
| `GameTooltip:GetUnitGUID` | **done — a deliberate reversal, with a new mechanism** | `compat/classic_api/tooltip.rs`, the 9th reader method. The `GameTooltip (reader methods)` row above lists this as *not built*, and the objection recorded there was and is correct: a unit *token* is resolved against the live snapshots per call, so re-resolving `TooltipState::unit_token` at read time answers for whatever that token names **now** — right most of the time and silently wrong exactly when it matters, because a `"mouseover"` tooltip routinely outlives its mouseover. What changed is not the standard but the mechanism: the guid is now **recorded beside the token at `SetUnit` time** (new `TooltipState::unit_guid`, `widget/kinds/mod.rs`; written by `tooltip_unit.rs`'s `set_live_token`, cleared by `tooltip/mod.rs`'s `clear_content` with the rest of the content). The getter therefore hands back a set-time fact and resolves nothing, which *is* the modern getter's promise — and the stale-token case it used to be wrong about is now the case it is most right about. Shape pinned by the live call site, not by memory: pfUI's `modules/tooltip.lua:81` is `local _, guid = GameTooltip:GetUnitGUID()` feeding `UnitTokenFromGUID`, so it returns `(name, guid)` — `GetUnit()`'s two-value shape with the guid in the token's place, and **no third value**, since nothing pins a third position. The *name* is resolved from the guid (through `Model::unit`'s SuperWoW raw-guid arm), not from the token, so the pair always describes one unit; a guid nothing can reach any more answers the guid with no name, because the identity outlives the snapshot. Nothing at all when `SetUnit` saw guid 0, which leaves `HasUnit()` true and is what pfUI's own `guid and UnitTokenFromGUID(guid)` reads. Built because the absence cost **14 errors in one play session** — that call site is on the tooltip's `OnShow`, so it fires on every unit hover. The test fails against the rejected mechanism, not merely against absence: `get_unit_guid_keeps_answering_for_the_unit_set_unit_saw_after_the_token_moves_on` |
| `INVSLOT_FIRST_EQUIPPED` / `INVSLOT_LAST_EQUIPPED`, `GetInventoryItemDurability` | done | `compat/classic_api/item.rs`'s new `install_globals` — bare globals, which is how upstream's own list spells them (it writes `C_Macro.CreateMacro` in full and leaves these unqualified). The two constants are **1 and 19**, read off this tree rather than a later client's headers: `char_stats.rs`'s `InventorySlots` is documented "0 ammo, 1..=19 equipment, 20..=23 the equipped bags", its `SLOT_INFO` is `PaperDollItemFrame.dbc`'s own table with `HeadSlot` 1 and `TabardSlot` 19, and `item.rs`'s existing `inventory_slot_token` enumerates the same 19. Neither name is 1.12's (`reference/1.12-globals.tsv` has no `INVSLOT_*` row at all — 1.12 spells each slot as `GetInventorySlotInfo("HeadSlot")`), and their absence was a session's **first** error: pfUI uses them as `for` bounds at module scope four times (`modules/panel.lua:414`, `:445`, `modules/itemcount.lua:7`) and a nil bound raises "'for' initial value must be a number", taking the enclosing block with it. The rest of the `INVSLOT_*` family is deliberately left out: nothing installed asks, and 1.12 already answers each slot by name. `GetInventoryItemDurability(slot)` is the one member of the `GetInventoryItem*` family 1.12 lacks — the reference ships the `GetInventoryItemBroken` predicate and never the numbers behind it — and needed **no new feed**: `InvSlotView::durability` already carries `ITEM_FIELD_DURABILITY`/`ITEM_FIELD_MAXDURABILITY` (fed by `ui_char.rs`'s `slot_view`), which the item tooltip's "Durability X / Y" line and the doll's red tint already render. Slot-only, no unit argument, as the modern function and every pfUI call site have it. Three answers kept distinct: **no values** for an empty slot (what `if cur and max then` branches on), the live pair for a damageable item, and **`(0, 0)`** for a worn item with no durability at all — the feed stores that as `None`, so it is unfolded here, because a worn ring is not an empty finger |
| `GetSpellBonusDamage` | done | `script/char_stats.rs`, beside the `UnitDamage` that reads the same wire field. A school's spell power: 1.12 has no character-sheet line for it and no global to ask, which is why it reads as a later-client function — but **the number is already streamed**. A vanilla server folds item spell power into `PLAYER_FIELD_MOD_DAMAGE_DONE_POS`/`_NEG` (`_ApplyItemBonuses` → `ApplySpellDamageBonus`), the very field `UnitDamage` already reports index 0 of as the physical pos/neg pair, so schools `[1..7]` were arriving and being dropped at the feed: `ui_char.rs` read `player_mod_damage_done_pos(0)` alone. The snapshot now carries `damage_bonus_pos`/`_neg` as `[i32; 7]` (the shape `resistance_pos`/`_neg` already use) and `UnitDamage` takes `[0]` of it, so there is one model of the field rather than a scalar and a derived duplicate. **Why it mattered**: pfUI's player module polls schools 2..7 every 0.25s from its throttled `OnUpdate` to draw a "+N SP" readout (`modules/player.lua:92`), so on a caster the missing global raised *per tick* — 433 runtime errors in one logged session on a fresh warlock, the single largest error source in the log, and invisible on a warrior because the readout resolves to 0 and never shows. Schools are 1-based (1 physical … 7 arcane) and anything off that range answers **0, not nil and not a raise**, which is what the call site's own `or 0` assumes. Its sibling `GetSpellBonusHealing` stays **unbuilt and is not approximable**: vanilla has no healing player field at all — 0x40A is `PLAYER_FIELD_BYTES`, the healing-done fields are a 2.0 addition — so there is nothing on the wire to read, and the number would have to be summed from equipped item stats. Nothing installed calls it. `UnitSpellHaste`, which the same pfUI function calls one line earlier, stays `todo` for the reason its own row gives (no haste stat exists in 1.12); it is reached only when that module's haste display is switched on, which this player's config has off |
| `GetAddOnEnableState` (the legacy global) | **deliberately not done — checked, not assumed** | Upstream's own `docs/API.md` AddOns section lists the ten entries above and **not** this one, and keeps 1.12's `GetAddOnInfo` with `enabled` 4th. So the DLL actually loaded on this install does not define it either: adding it here would be a *divergence from the player's own client*, not parity with it. It would also break the one addon that asked for it. `AI_VoiceOver/Compatibility.lua:121` gates **two** definitions on one `if not GetAddOnEnableState` — its own enable-state fallback *and* a modern-shaped `GetAddOnInfo` that drops the `enabled` return. Define the global and VoiceOver keeps 1.12's 8-tuple while reading it at modern offsets, so `VoiceOver.lua:84`'s `select(5, GetAddOnInfo("VoiceOver")) ~= "MISSING"` reads `loadable` where it means `reason`, is true for a folder that is not installed, and raises the "delete your old VoiceOver folder" popup every login — twice, `AI_VoiceOver_112` too. Recorded because this was first diagnosed the other way round: the three `AI_VoiceOverData_*` modules look unloaded in the log and are not. They load inside AI_VoiceOver's own `ADDON_LOADED`, 224 ms of it, before the walk ever reaches their rows — and the walk's `is LoadOnDemand — not loaded (no LoadAddOn() yet)` line used to be printed unconditionally, so it went on saying "not loaded" about addons already in memory. That line is now gated on `UiScript::addon_is_loaded` |
| `C_Item.GetItemInfo` | done, delegating | `compat/classic_api/item.rs`. Calls the **stock 1.12 global** (`script/item_stats.rs`), which owns the template cache and the `CMSG_ITEM_QUERY` warm an uncached id records — so a modern caller feeds the one shared cache and a hook over the stock global is honoured, same discipline as `C_AddOns`. The shape is modern WoW's, by exactly the transform `item_stats.rs`'s own comment already names ("later clients insert `itemLevel` at 4"): returns 1..3 pass through, **position 4 is nil**, stock's 4..9 land at 5..10. Nil rather than a number because item level is not in `SMSG_ITEM_QUERY_SINGLE_RESPONSE` and 1.12 exposes no such concept (the same reason `GetCurrentItemLevel` stays unbuilt) — a fabricated 0 would read as a level-0 item where nil reads as "not known here", which a caller can tell apart. Modern positions and not 1.12's because a live call site against the real DLL pins them: pfUI's `modules/bags.lua:457` reads `local _, _, q, _, _, _, itype` and tests `itype == "Quest"` at `:475`, and position 7 is the subType *string* in the modern run against the stack *count* in 1.12's — forwarding the nine verbatim would have left that test silently never firing. Same evidentiary standard as the `ColorMixin` row below. Stops at 10: modern's 11th onward (sellPrice, classID, subclassID, bindType, …) are facts this client holds, but nothing available pins their *order* and each already has its own `*ByID` entry, so they are left off rather than placed from memory |
| `IsSpellKnown` (bare) | done | `compat/classic_api/spell.rs`'s new `install_globals`, matching upstream's own heading "Spell (`C_Spell`, plus several bare globals)". It hands out **the same function value** `C_Spell.IsSpellKnown` holds, lifted out of that table rather than written twice — so the two spellings cannot drift and there is no second body to maintain (`the_bare_is_spell_known_is_the_very_function_c_spell_holds` asserts the identity, not just the behaviour). Not a 1.12 name: 1.12 asks "do I know this" only by walking the book with `GetSpellName(i, "spell")`, never by id. pfUI's `modules/bags.lua:703` calls it bare, 3 occurrences in one session |
| `GetMacroSpell` (bare) | done — **the "not built" note in `macro_ext.rs` was wrong about this client** | `compat/classic_api/macro_ext.rs`'s `install_globals`. The triage item that produced this said `C_Macro.GetMacroSpell` already existed and only needed exposing; it did not exist anywhere, and that file's header gave a reason — "resolving a body's first `/cast` line needs the rank-aware spellbook lookup `C_Spell`'s row notes is unbuilt". **Both halves do exist and are already load-bearing.** `benilla-app`'s `ui_macro/run.rs` is a traced reimplementation of the reference's own macro→spell derivation (`0x4efe00` writing `[rec+0x564]`, reading the `SLASH_CAST%d` aliases as Lua globals exactly as `0x703bf0` does, plus a `CastSpellByName(` arm) and resolves through `spellbook.rs`'s `resolve_spell_by_name`, the same resolver `CastSpellByName` and `/cast` use; the action bar has been reading its result for a macro slot's cooldown, usability and range all along. So this is **not new derivation** — it is the existing one, fed into the VM as `Model::macro_bound_spells` by the existing `rebind_macro_spells` system (no new system, no new file, no ceiling movement) and read back by id through the same `spell_display` `C_Spell.GetSpellName` uses. Returns `(name, rank)`, two values only: pfUI reads `effect, rank = GetMacroSpell(id)` (`libs/libpredict.lua:1027`) and compares the first to a spell name (`modules/swingtimer.lua:430`), so a bare-spellID return (what the newest clients give) would fail both, and no third value is appended because nothing pins its position. Rank is a string, `""` when rankless, the rule the stock `GetSpellName` already keeps. Only resolved spells cross the feed: `BoundSpell::None` and `BoundSpell::Unresolved` are both "no spell" to Lua, which has one way to say it, while the bar needs them apart. Stated latency: one frame after an in-Lua `EditMacro`, the identical delay the action bar already has, from the identical source. `GetMacroItem` stays unbuilt — the reference's macro record binds a spell and has no item counterpart to derive |
| `GetInventoryItemRepairCost` | todo, blocked | pfUI reaches it in the *hover* arm of the durability panel widget the two `INVSLOT_*` constants above unblocked (`modules/panel.lua:416`), guarded as `(GetInventoryItemRepairCost(id) or 0)` — which does not help, since a nil *global* raises before `or` runs. Deliberately not built, and not stubbed to 0: 1.12 computes repair cost **server-side only** and the client never receives or derives a per-item figure (the same blocker already recorded for `C_Container.GetContainerItemRepairCost`, `container.rs`'s header). `0` would read as "this item repairs free", which is a wrong answer a caller cannot detect, where a nil-call error names the function. The client-side repair numbers that *do* exist are the merchant window's own `CanMerchantRepair`/`GetRepairAllCost`, which are a different fact (the whole-inventory total at an open vendor) and cannot be divided back into per-slot costs |
| `C_Container.GetContainerItemCharges` (restated, measured) | todo, blocked — now the harness's first session error | No change made; recorded because fixing the `INVSLOT_*` `for` bound moved this to the front of the queue. `container.rs` installs it returning nil by the stated decision (`item_spell_charges` is a raw signed field and no item-template column says which of an item's five spell-trigger slots is a consumable charge rather than an equip/proc effect — the same blocker as SuperWoW's charges extension above). pfUI's `modules/bags.lua:452` then does `if charges > 1`, which raises "attempt to compare number with nil" and is now the harness's first session error for pfUI, two lines **above** the `C_Item.GetItemInfo` call this pass fixed. It did not appear in the live session log at all (bag stacks there were not 1, so the guarded block was skipped) — the harness's synthetic bag fixture is what reaches it. Unblocking it needs the item-template charge column, not a change here |
| `SetScript("OnInputLanguageChanged")` refusal | **examined and deliberately kept** | Not a DLL feature and not an addon's call at all: both occurrences in the live session (`errors…18-53-31.log`, world entry and `/reload`) are **stock FrameXML** — `ChatFrameEditBox` in `FloatingChatFrame.xml`, off `ChatFrame.xml:121`'s script slot. `object/events_regions.rs`'s `set_script` raises for real 1.12 script kinds nothing fires, by a stated decision ("an accepted handler that never runs fails silently"), and `OnInputLanguageChanged` is named in that comment. Accept-and-ignore was weighed and rejected: the reference accepts it because the reference has an IME to fire it, benilla has none, and silently installing a handler that can never run is the exact failure that comment exists to prevent. It is already recorded as a **warning**, not an error, and two tests pin it by name — `world_entry_tests.rs`'s `a_clean_world_entry_raises_only_the_warnings_we_have_named` (where it is one of exactly two named deviations) and `script/tests/input.rs`'s `the_unfired_script_kinds_still_raise_rather_than_silently_accepting`. The name leaves that list when something fires it, not to quiet a log line |
| ~60 namespaces, remaining ~515 functions, 50+ events | todo | full per-namespace function list fetched from the upstream repo's own `docs/API.md`: `docs/classic-api-functions.md` at this repo's root — re-fetch upstream before resuming, that file is a point-in-time names-only snapshot. One file per namespace under `compat/classic_api/` (`container.rs` done; `spell.rs`/`spellbook.rs`/`unit_auras.rs`/`state.rs` may be in progress or done by the time this is read — check their own status before re-doing them) |
| `ItemLocation`, `ItemLocationMixin` | done | `compat/classic_api/item_location.rs`, a Lua chunk over the existing `CreateFromMixins`. **The single largest error source measured in a real session: 12,570 lines**, one `attempt to index global 'ItemLocation'` per bag slot per `OnUpdate` pass of pfQuest's quest-item watcher (`database.lua:207` walks five bags, `:216` all 19 equipment slots). `item.rs` was already designed for this — its header states that the mixin is pure sugar over `{bagID, slotIndex}` / `{equipmentSlotIndex}`, that the plain table *is* the contract, and that the constructors "belong with `Mixin`/`CreateFromMixins`"; this is that deferred half, so nothing in `item.rs` changed and a hand-built table still works. Every member has backing and all are built: the two setters, `Clear`, `IsBagAndSlot`/`IsEquipmentSlot`/`HasAnyLocation`, `GetBagAndSlot`/`GetEquipmentSlot`, `IsEqualTo`, and `IsValid` — which is literally `C_Item.DoesItemExist(self)`, so it cannot disagree with the `GetItemName` on the next line. Three shapes are load-bearing and pinned: the constructors are defined with `:` (every installed call site writes `ItemLocation:CreateFromBagAndSlot(...)`, and so does Blizzard's own `ItemLocation.lua`); `IsBagAndSlot` compares against **nil**, not truthiness, because the backpack is bag `0` and pfQuest's loop is `for bag = 4, 0, -1`; and the setters clear the other kind's fields, because `item_loc` tests `equipmentSlotIndex` first and a half-cleared object would resolve to the wrong slot. Not built: `IsEqualToBagAndSlot`/`IsEqualToEquipmentSlot` (nothing calls them, and `IsEqualTo` plus a constructor is the same answer) |
| `C_CreatureInfo.GetClassInfo` + a new `ChrClasses.dbc` feed | done | `compat/classic_api/creature_info.rs`, closing the gap that row's own "Not built" list named. **Costliest absence in the surface by blast radius rather than by count**: pfQuest calls it at *file scope* inside `for id = 1, 32` (`database.lua:408`, building `pfDB.bitclasses`), so the nil call aborted `database.lua` there and **every `pfDatabase` function defined below line 408 was never defined at all** — the session log's separate `GetBitByRace` (`:609`), `AddCustomIcon` (`:1897`) and `GetQuestIDs` (`:1928`) failures were all this one abort, not three gaps, and the addon harness ranked it as one of only two first-load errors in the whole corpus. Built as a feed, not a table: `benilla-formats`' `chr_classes.rs` gains its name block's enUS column (field 5) and the class file token (field 14) beside the three columns it already read, `model.rs` gains `ClassInfo`/`class_info`, `script/class_info.rs` the 19-line `set_class_info`, and `benilla-app`'s new **`ui_chr_classes.rs`** the `PostStartup` push — the `ui_*` name because `ui_script_wall.rs` only lets that family name `UiScript`, and a second file because `chr_classes.rs` loads the same table for three engine readers and must not learn the VM exists. Read rather than carried for `ChrRaces`' reason: a patched realm owns the display name, and `classFile` is an independent column — a test pins both against the shipped DBC and confirms fields 5 and 14 by their nine-rows-with-gaps-at-6-and-10 shape. **Stated rather than glossed**: on this shipped enUS table the two columns *coincide*, `name:upper() == classFile` for all nine rows, and a test asserts that too — so a feed that derived the token from the name would pass every real-data assertion and go wrong only on a renamed or localized realm. That is why the app-side test uses a deliberately renamed row (the class-side shape of `ChrRaces` row 10's "High Elf"/"BloodElf"): without it the property is untested, which the discrimination pass caught. **Nil for a gap is load-bearing**, differently from `GetRaceInfo`'s nil: ids 6 and 10 carry no row in 1.12, pfQuest walks straight through them, and borrowing a neighbour would key `bitclasses[2^5]` to the wrong class rather than leave it empty. No `Update` system, so no `UPDATE_ACTIONABLE_CEILING` change |
| `TableUtil.Execute` | done | `compat/classic_api/table_util.rs`. **Not a ClassicAPI function and not 1.12's** — `docs/classic-api-functions.md` has no `TableUtil` at all; it is Blizzard's own FrameXML helper (`Blizzard_SharedXMLBase/TableUtil.lua`, 58 functions) and this install's pfQuest calls one of them at **file scope** (`map.lua:21`, renaming its minimap pins for Gatherer-compat). Line 21 of a 2000-line file, so the nil index aborted `map.lua` and `pfMap` was never defined — which is the whole of the harness's other first-load error (`pfQuest-octo/patchtable.lua:137`) and the two `pfQuest.ResetAll` failures under input (`quest.lua:616`). One function closes all of it. The body is **upstream's, fetched not remembered** (Gethe/wow-ui-source `live`): it walks `pairs`, not `ipairs`, and the callback takes the **value only**, never the key — two details the one installed caller cannot distinguish (it passes an array and reads one argument), which is exactly why the source was read instead of inferred. Tests pin both against upstream's body rather than against the call site. The other 57 members are not installed: nothing calls one, and several (`CopyTable`, `tInvert`, `tFilter`, `tContains`) collide with names the addon corpus and the stock chain already define |
| `table.wipe` | done | `compat/classic_api/lua_ext.rs`, **aliased** to the bare `wipe` `script/stdlib.rs` already defines — literally the same function value, so the two names cannot drift. That matters because `wipe`'s body is not a `pairs` clear: it walks `tremove` down from `getn` to reset Lua 5.0's *remembered table size*, which a second copy would get wrong and a refilled list would then read holes out of. pfUI's nameplate module calls `table.wipe(plate.cache)` on every plate refresh (`modules/nameplates.lua:1023`) and with only the bare name it raised **2,859 times in one session**, stopping the plate styling mid-refresh — the module was running (the `NAME_PLATE_*` events had just started firing), it simply could not finish. A test asserts identity (`table.wipe == wipe`), not merely presence, and was verified to fail without the alias |
| `UnitCreatureTypeID` | done | `compat/classic_api/unit_extra.rs`, over new `UnitState::creature_type_id` — `SMSG_CREATURE_QUERY_RESPONSE`'s `CreatureType`, which `ui_unit.rs` was already receiving and discarding after converting it to the localized word. Both are carried now: the word is what 1.12's `UnitCreatureType` answers, the number is what this answers, and deriving either from the other would mean a reverse lookup through a localized string — wrong on any non-enUS realm. **The argument is a GUID, not a token**, in its only caller (`pfUI/modules/nameplates.lua:295`), which resolves through the SuperWoW raw-GUID arm so neither form needs a special case. This supersedes the earlier `todo` that listed it as needing data the client lacked; the number was always there. **Why it mattered visually**: the call sits in `TotemPlate` → `CreatureType`, reached from the plate refresh at `:1111` — *above* the whole block that `SetPoint`s and `Show`s `plate.name`/`level`/`health`/`glow`/`guild`. So every refresh aborted before laying its own art out, and the user saw plates that were styled-but-misaligned with wrong colours rather than unstyled. Its own comment is `-- nil retries next call`, so it re-raised per plate per frame: 1,014 times in one session |
| `table.unpack` | n/a — not reached | 5.0's table library has eight members and this is not one, so it is genuinely absent. Left that way: its only call sites are in `pfQuest/toolbox/extractor.lua`, a data-extraction dev tool **not listed in pfQuest's `.toc`**, which never loads in play. Recorded so the next sweep does not re-flag it |
| `PlayerUtil.GetClassFile` | done | `compat/classic_api/player_util.rs`. The **second** of two walls in pfQuest's `database.lua`, found by re-running the harness after the `GetClassInfo` row above cleared the first: the abort moved 478 lines down, from `:408` to `:886`'s module-scope `local isdruid = PlayerUtil.GetClassFile() == "DRUID"`. Both are needed for the measured cascade — with only the first fixed, `GetBitByRace` (`:609`) exists but `AddCustomIcon` (`:1897`) and `GetQuestIDs` (`:1928`) still do not, and `icons.lua` still dies on the first of those. Not a ClassicAPI function either (`PlayerUtil` is Blizzard's own FrameXML helper, absent from `docs/classic-api-functions.md`). **Unlike `TableUtil.Execute`, the body here is not upstream's verbatim** — every path to `PlayerUtil.lua` 404s and `warcraft.wiki.gg`'s FrameXML index lists the name with no signature — so it is built on a *forced* reading rather than a fetched one: the namespace means the player so it takes no argument, "class file" is the engine's own word for the locale-independent token, and this client already answers that exact fact as `UnitClass("player")`'s second return. It reads the same `PlayerRecord::class` pair that binding reads, so the two cannot drift, and a test asserts they agree. nil before the record lands, which is both what `UnitClass` answers then and what the `== "DRUID"` call site needs. The other eleven members are unbuilt: four spec getters plus `CanUseClassTalents` describe a specialization system 1.12 has none of, and the rest would be second spellings of `UnitClass`/`RAID_CLASS_COLORS`/`C_CreatureInfo.GetClassInfo` |
| Map (`C_Map`) | partial | `compat/classic_api/map.rs`, the 3 of upstream's 27 that read data already in this VM, over the world-map catalog `ui_world_map.rs` pushes once at world entry — **no new feed and no second DBC read**, so these cannot disagree with what the map window itself draws. This supersedes the `C_Map.GetMapOverlays` entry in the "ClassicAPI tail" row above. The error count (19) badly understates this one: pfQuest's modified copy has **deleted** its shipped zone-size, subzone-placement and area-trigger tables in favour of these calls (`db/minimap.lua`, `db/zones.lua`, `db/areatrigger.lua` are now stubs saying so), and almost every call site is guarded with `if C_Map and C_Map.X then`, so an absent namespace degraded *silently* into a pfQuest with no zone sizes and no subzone index. Only pfUI's is unguarded (`modules/mapreveal.lua:119`), and that is where the 19 came from. Built: `GetMapWorldSize(areaID)` → the `WorldMapArea` loc rect's two spans in yards, `left - right` across and `top - bottom` down, the same pair `worldmap.rs`'s own `area_grid_cell` un-lerps hovers through and the order pfQuest divides by (`map.lua:1367`); it answers **no values** for a degenerate rect rather than a truthful `0`, because the caller's next line is `mapZoom / mapWidth` and an infinite scale stacks every pin in one place. `GetMapAreaIDs()` → `{ [mapFolder] = areaID }`, the first reader of a `WorldMapZoneView::area_id` column nothing had ever read, keyed by `GetMapInfo()`'s own string because a city or instance map has no zone-dropdown index to look itself up by. `GetMapOverlays([areaID])` → **every** `WorldMapOverlay` row of the zone, explored or not, which is the one thing separating it from the stock `GetNumMapOverlays`/`GetMapOverlayInfo` pair (those are the *revealed* list, gated on `PLAYER_EXPLORED_ZONES_1`) — pfUI diffs the two to find what is still fogged, and a test asserts they disagree on an unexplored zone. That needed two new `WorldMapOverlayView` fields: `texture_name` (the bare DBC leaf, carried rather than split back out of the path so `textureName` and `texturePath` are the same string by construction) and `area_id` (slot 0, the sub-area the overlay *is*, as against `explore_bits`, which is all four slots' reveal bits). Nil, not an empty table, when no zone resolves — a zone with no overlays and no such zone are different facts and both callers branch on it anyway |
| `C_Map.GetAreas`, `C_Map.GetAreaTriggerInfo` | todo — feed shape known | Both are what pfQuest deleted its own tables for, so both are silent functional loss rather than errors, and neither is guessable. `GetAreas()` wants `{ [areaID] = name }` for the **whole** `AreaTable.dbc` (~2700 rows); the model holds only the ~80 rows that have a `WorldMapArea` map, because that is all the map window needs. `AreaTableCatalog::rows` already exists app-side (`benilla-formats/src/area_table.rs`) and `benilla-app`'s `AreaTableRes` is already a live resource, so the work is exactly the `ui_chr_classes.rs` shape this pass just built: one `BTreeMap` feed and a `PostStartup` push. `GetAreaTriggerInfo(id)` wants `AreaTrigger.dbc` **plus a projection**: the caller reads `areaID`, `mapX` and `mapY` (`database.lua:790`), which means resolving the trigger's world position through the `WorldMapArea` rects — `AreaTriggers` is loaded app-side (`area_trigger.rs`) and never reaches the VM, and the projection is `map_proj`'s job, not Lua's. Not built here because each is a new feed and this pass's budget went to the error-producing members; the remaining 22 (nine waypoint members, the layered-art trio, the four-member projection family) are later-era or app-side by nature — except `GetMapInfo` and `GetPlayerMapPosition`, which are 1.12's own globals and already exist bare (`script/worldmap.rs`), so a `C_Map.` spelling of either is an aliasing decision rather than a gap and nothing in the corpus asks for one |
| `C_PlayerInfo.CanUseItem` | done | `compat/classic_api/player_info.rs`, superseding that member's entry in the "ClassicAPI tail" row above. It is the "would the tooltip print this item's requirements in red" gate, and that gate already existed here as exactly one function — `item_stats::item_usable_by_id`, the port of the reference's `0x5ea930` (required level, class, race, proficiency, skill + rank, required spell, honor rank, city rank, reputation standing). So this is the **same function value** `C_Item.IsUsableItem` answers from, under the second name upstream also publishes it under; a test asserts the two agree, because pfUI tints a bag slot from one and its tooltip red lines come from the other, and a second implementation that disagreed would red-tint slots whose tooltip is black. pfUI's own call-site comment (`modules/unusable.lua:18-21`) names the requirements-not-condition split and says it depends on it, which is what `item_usable` already implements. A bad argument answers **false**, not a raise — the hook fires per bag slot — and deliberately not the gate's own "an unpushed player declines to judge, answer usable" default: an unresolved player genuinely cannot be judged and greying the whole bag at login would be worse, but a nonexistent item id is not a judgement call. The namespace's other nine are unbuilt: nothing installed calls one, and the five getters take a modern `PlayerLocation` object whose facts (another player's class by guid, their connected state) are a name cache this VM is not fed |
| `nameplate<N>` / `nameplate<N>target` unit tokens | partial — **recognised, deliberately naming nothing** | `script/unit/mod.rs`'s `classic_api_token_recognised` now takes a `"nameplate"` prefix beside `"focus"`. 206 `Unknown unit name: nameplateNtarget` lines in one session, and the cost was not the lines: pfUI's aggro scanner walks its whole `pfValidUnits` table — which `env/tables.lua:48-49` fills with `nameplate1..40` **and each one's `target`** — calling `UnitExists` on every entry (`api/unitframes.lua:186`), and an unrecognised token raises, which longjmps out of `GetAggroState` entirely. So each of those 206 lines was also an aggro scan that never reached its *party and raid* tokens. Recognition alone fixes that and is the same answer the reference gives for `"raid5"` solo. **Resolution is deliberately not built, and this is the honest half of the row.** Three separate things block it, measured not assumed: (1) `Model::unit` can only turn a GUID into a `UnitState` that some *other* token already names (`unit_by_guid` scans `units_by_lower`), and no feed pushes a snapshot per plate — so `nameplate1` would answer only for a plate that is also your target or a party member, i.e. almost never, and unpredictably; (2) `NamePlates::live()` compacts retired slots out, so its dense rank is **not** slot-stable — a plate's index shifts when an earlier plate dies, and modern WoW's token is slot-bound, so building on `live()` would make `nameplate1` mean a different unit frame to frame; (3) `<token>target` needs the plate unit's `UNIT_FIELD_TARGET`, the same hop the `focustarget` comment in `Model::unit` already records this crate cannot make. A token that names the wrong unit is worse than one that names none, so these name none. What it would take: a per-plate `UnitState` feed (`ui_unit.rs`'s `token_snapshot` is the ready-made builder, but `feed_units` is at Bevy's 16-`SystemParam` ceiling and would need a sub-struct first) and a new `NamePlates` accessor exposing the **pool slot** rather than the dense rank. Note the pool's order is arrival order, not distance: the one sort in the pipeline (`vplates.rs:461`, screen-space distance from a fixed gx point) exists for the overlap solve and is discarded before `sync()` |
| Newly surfaced by the above: `Item`/`ItemMixin`, `GameTooltip:GetGameObject` | todo — measured, not guessed | Both were **masked** before this pass and are reported here so the harness's numbers are readable. Clearing pfQuest's two `database.lua` walls (`:408`, `:886`) moved its abort to `:2241`, `local item = Item:CreateFromItemID(HEARTHSTONE_ITEM_ID)` followed by `item:ContinueOnItemLoad(...)` — modern WoW's `Item` mixin, which pfUI also reaches for (the harness counts `CreateFromItemID` and `ContinueOnItemLoad` at two addons each). **That line is 5 lines from the end of a 2246-line file and no function definition follows it**, so the residual cost is only the locale name-check bootstrap in that last block — every `pfDatabase` function now exists, which is the whole point of the two rows above. Not built because `ContinueOnItemLoad` is an *async* data-load callback and `item.rs`'s header already states why that family is out: `RequestLoadItemData*` needs an app-drained queue that does not exist, and a `ContinueOnItemLoad` that fired synchronously off a cache miss would call back with no data. Separately, `map.lua` now loads, which makes `map.lua:296`'s `GameTooltip:GetGameObject()` reachable for the first time — that is why the harness's pfQuest input-raise count went **2 → 7** while its load errors went 2 → 1: the same one unbuilt method, now hit by a tooltip hook that previously never ran. It is a *widget method* (so `tests/widget_surface.rs`, not the global list) and already carries its reason in `tooltip.rs`: no GameObject subject is recorded at any renderer and there is no object-template cache keyed like `item_templates`. Honest net: pfQuest went from dying at 19% of `database.lua` to dying at 99.8% of it, and from `map.lua` not loading at all to loading and then raising on one tooltip hook |
| `C_Item.GetItemUniquenessByID` | todo — **the fact is here, the signature is not** | Deliberately not built, and not for want of data: 1.12's whole uniqueness story is `ItemTemplateView::max_count`, which `item.rs` already hands out as `maxCount`. What is missing is the **return shape**, and the two candidates are behaviourally different. Upstream publishes `GetItemUniqueness` *and* `GetItemUniquenessByID`, and every other `X`/`XByID` pair in that namespace returns the same thing — which argues the pair is modern WoW's `(limitCategory, limitCount)`, hence `(0, max_count)` here since 1.12 has no `ItemLimitCategory.dbc` at all. But the one installed call site is `C_Item.GetItemUniquenessByID(id) == 1` (`pfUI/modules/itemcount.lua:16`, suppressing stack counts on unique items), which only works if the return is a **single** uniqueness number. Guessing wrong is invisible to the caller in both directions — the pair shape makes that test silently always-false and pfUI prints counts on unique items; the single shape would mislead any modern-shaped caller — which is exactly the failure mode this file's scope rule refuses. Resolving it needs upstream's `docs/API.md`; note the path `docs/classic-api-functions.md` cites now **404s** on `raw.githubusercontent.com` (`brues-code/ClassicAPI` `main`), so re-fetching it is itself a prerequisite task. The compat doc's earlier `GetItemUniqueness` row reached the same "no 1.12 counterpart for the pair" conclusion from the other direction |
| `C_NewItems` (`IsNewItem`/`RemoveNewItem`/`ClearAll`) | todo — reason sharpened, not changed | Left unbuilt, agreeing with the "needs a 1.12-absent subsystem" classification in the tail row above, with the measurement that makes it conclusive: **building it would deliver nothing**. pfUI's module refreshes its glows from `EventRegistry:RegisterFrameEventAndCallback("BAG_NEW_ITEMS_UPDATED", ...)` (`modules/newitem.lua:60`) and benilla fires no such event, so even a perfect `IsNewItem` would never repaint. The tempting cheap version — `IsNewItem` → false, the other two no-ops — is not free either: it is a *positive* claim that a just-looted item is not new, indistinguishable by the caller from a correct one, and it would turn a loud failure into a feature that is permanently and silently off. A real implementation needs app-side state nothing feeds: a container-arrival diff gated on whether the bag UI was open when the item landed, plus the event. Cost of leaving it: an error per bag-slot update while a bag frame is open (`pfUI.newitem:UpdateSlot` is hooked onto `pfUI.bag.UpdateSlot`), which is why the measured count is low — the harness never opens a bag |
| `C_NewItems` (`IsNewItem`/`RemoveNewItem`/`ClearAll`) | done — **floor**, reversing the row below | `compat/classic_api/new_items.rs`. The row below is correct about *function* and is kept: benilla never fires `BAG_NEW_ITEMS_UPDATED`, so the glow would never refresh even with the namespace present, and `IsNewItem → false` is a positive claim about a just-looted slot. What it did not weigh is the cost of the **absence**. `pfUI/modules/newitem.lua:16` indexes `C_NewItems` from inside a bag-slot update that runs on hover, click and drag — so a nil namespace does not skip the glow, it *raises* and takes the rest of that handler with it. Measured the moment every addon began loading cleanly: **7 of 13 addons went dead to the touch on this one name**, against 1 before. "No glow" and "no working bag interaction" are different failures, and this is the same trade the `Totem` row records. `IsNewItem` answers the boolean `false` (not nil — upstream returns a boolean and nil is the one shape a `== false` could tell apart); the two removers are honest no-ops, since there is no marker state they could fail to clear. **Still wrong for a slot that really was just looted** — that is this row. The real feature needs benilla to track bag arrivals across a session and fire the event on the edge; when that lands this file becomes a getter instead of a floor |
| `C_Item.GetItemUniquenessByID` | done — reverses the decline below | `compat/classic_api/item.rs`, one `by_id!` line over `max_count`, whose own doc comment reads "1 prints Unique, N > 1 Unique (N); not the stack size". **The fact was never the problem** — it was declined twice because retail's shape is a `(limitCategory, limitCount)` pair, 1.12 has no limit categories, and upstream's `docs/API.md` truncates before the Item section so reading it settles nothing. What settles it is the **one real caller**: `pfUI/modules/itemcount.lua:16` reads `... or C_Item.GetItemUniquenessByID(id) == 1 then return end`, comparing the *first* return against 1 to mean "unique, draw no count". A limit *category* compared against 1 is meaningless there; the limit *count* is exactly right and answers every case — unique → 1 (skip), unlimited → 0, `Unique (3)` → 3 (draw, since three may be held), all three pinned by test. **One value, not a pair**: inventing a category id for a game with no categories is the part that would actually be wrong. Declining cost 27 raises per session on plain mouseover, the same trade the `Totem` and `C_NewItems` rows record |
| The modern nameplate contract: `NAME_PLATE_CREATED` / `NAME_PLATE_UNIT_ADDED` / `NAME_PLATE_UNIT_REMOVED`, slot-bound `nameplate<N>` and `nameplate<N>target` | done — **this is why pfUI was not styling nameplates at all** | Supersedes the `nameplate<N>` row above, which was right about the symptom and wrong about one of its three blockers. The user-visible fault was total: `pfUI/modules/nameplates.lua` registers these three events (`:498-500`) **and nothing else** — there is no `WorldFrame` child scan anywhere in that 1936-line file — and benilla fired none of them, so pfUI's module never received a single plate and every plate drew as benilla's own. All six of its styling paths are `C_NamePlate.GetNamePlateForUnit(arg1)` over the token those events carry. Built in `benilla-ui`'s `script/nameplate.rs` beside the existing 1.12 widget pool, **not** in a feed system of its own, and that is the central design call: the token, the plate and the event edge are one state machine, and the correct order inside a single tick is (1) fire every removal while its token still names the departing unit *and* its plate is still findable, (2) free those slots, run the widget sync, claim new slots, push every live snapshot, (3) fire `NAME_PLATE_CREATED` then `NAME_PLATE_UNIT_ADDED`. Split across two systems, step 1 lands after the plate is already retired, and pfUI's removal handler is `local plate = GetNamePlateForUnit(arg1) if plate then visiblePlates[plate] = nil end` (`:611`) — a nil plate there leaks that plate into its visible set for the rest of the session, with no event left to take it out. Its own source comment states the dependency ("UnitGUID still resolves inside the handler (the slot is freed after dispatch returns)"). **On blocker (2), slot stability, which the old row called the heart of the problem**: the token slot space is a new `NamePlates::token_slots` (`Vec<Option<u64>>`, guid per slot, lowest-free claim) and is deliberately *not* the widget pool index. A unit keeps its slot for the life of its plate; a slot is freed only after its removal has been dispatched. The pool cannot serve as the token space because the pool recycles a slot in the very tick it is freed — `sync`'s own "retire first, so a departing unit's slot is free for an arriving one", the reference's single free list — which would make one index mean two units inside one dispatch. Nothing an addon can observe ties the two numbers: `GetNamePlateForUnit` is token → GUID → `frame_for_guid`, never token → pool index. `NamePlates::live`'s dense rank is still the wrong answer for the reason the old row gave, and a test proves it — three plates up, the *middle* one dies, and the third must still be `nameplate3`. **On blocker (1), the per-plate snapshot**: `PlateState` became `PlateFeed { state, unit, unit_target }` and `sync_nameplates` takes that. One struct, not two parallel slices, so the plate an addon styles and the unit its token names are the same unit by construction. The snapshots come from `ui_unit.rs`'s own `token_snapshot` body, extracted into `SnapshotCtx::full` and now shared with `vplates.rs` — one body for `"targettarget"`, `"npc"`, `"focus"`/`"focustarget"` and the plate pair, so no two of them can come to disagree about one unit. Built in `drive_vplates`' own gate loop rather than a second system, because a second system re-deriving the plate set would be a second gate: the first time the two disagreed, a token would name a unit with no plate. **On blocker (3), `<token>target`: the old row was wrong — it is reachable and is built.** `UNIT_FIELD_TARGET` is a plain descriptor field (`unit_target()`), and the app has made exactly this hop for `"targettarget"` since that token existed; what the `focustarget` comment in `Model::unit` records is that *benilla-ui* cannot make it, which is a statement about the VM crate, not about the client. pfUI needs it: its aggro scanner walks every `nameplate<N>`/`<N>target` pair in `pfValidUnits` with `UnitExists`/`UnitIsUnit`/`UnitCanAttack` (`api/unitframes.lua:186`), which is how a nameplate drives the aggro glow on a unit frame. `nameplate<N>targettarget` is **not** built: it is one more hop for a third snapshot per plate (120 a frame at 40 plates) and the one scanner that reads it already scores through `<N>target`. **Prefer absent over wrong, three places.** A plate whose unit the app could not snapshot names *nothing*, not a blank unit — `UnitExists` answering true for a token with no GUID, no name and no health is undetectable by the caller, and a zero GUID would additionally make `Model::unit`'s raw-GUID fallback resolve `"0000000000000000"` to it. `UNIT_FIELD_TARGET`'s zero ("targeting nothing") is rejected before the object-manager lookup rather than after. And a free slot's token names nothing rather than the last unit that held it. **`NAME_PLATE_CREATED`'s `arg1` is a frame**, the one event in this client whose argument is a widget, so `ScriptValue` gained a `Frame(u32)` variant carrying the arena id — still plain data, no mlua handle, so the no-persistent-`Function`-handles rule (`LUAI_MAXCSTACK`) is untouched. It resolves through the cached wrapper (`0x701bd0`), because pfUI guards on `registry[arg1]` object identity and parents its whole overlay to that table; a fresh table per fire would build a second overlay per plate and lose it. **Not built, deliberately**: `UNIT_AURA`, `UNIT_FLAGS` and `UNIT_SPELLCAST_*` do not fire *for* `nameplate<N>` tokens, though pfUI's module has arms for all of them (`:628`, `:651`, `:665`, `:681`). Those are field-transition events and would mean running `ui_unit.rs`'s `fire_transitions` 40× a frame; without them pfUI falls back to its own throttled `OnUpdate`, which it has and which is its no-ClassicAPI path, so the module works — it just refreshes on a throttle instead of on an edge. Tracked as its own item, not folded in here. **Harness: unchanged at 11/13 load clean, 10/13 session start, 10/13 survived use — and that is the honest reading, because `examples/addon_harness.rs` drives no world, no camera and therefore no plate, so it cannot see this feature at all** (it never calls `sync_nameplates`; `grep` finds no `nameplate` in it). The end-to-end check it cannot make is instead a test: `script/tests/nameplate_tokens.rs`'s `pfuis_own_oncreate_body_runs_on_the_frame_the_created_event_hands_it` transcribes pfUI's `OnCreate` (`:756-897`) — `parent:GetChildren()` positionally, the six regions by index against its own `NAMEPLATE_OBJECTORDER`, `DisableObject` on each, `HookScript("OnValueChanged")` on the health bar, the raid icon reparented onto its own frame, `SetScript("OnUpdate", nil)` — and then its `_UNIT_ADDED` body, and asserts the module reaches the end on every plate. **Ambiguity cost: zero, measured.** `Update (actionable)` is 5581 against a ceiling of 5581, unmoved, so `UPDATE_ACTIONABLE_CEILING` is untouched. No new system (the work is inside the existing VM-holding `drive_vplates`, so `every_vm_holder_in_update_declares_its_side_of_the_tick` sees no new holder), and the four new `PlateWorld` fields are all read-only (`Res<GuidIndex>`, `Res<ChrClassTable>`, one `Query<(&ObjectStore, Option<&Transform>), With<Guid>>`), which Bevy does not count against another reader; `WOW_AMBIGUITY_DUMP=1 … | grep drive_vplates` gives 48 pairs, every one a `Transform`/visual writer the plate loop's pre-existing queries already paired with, and none naming `GuidIndex` or `ChrClassTable`. No new benilla-app file, so `ui_script_wall`'s game-file count stays at its pre-existing 43. No new bare Lua globals (`C_NamePlate` already existed) and no new widget methods, so neither `reference_surface.rs` nor `widget_surface.rs` changes; the three event names are modern, absent from `reference/1.12-events.tsv`, so `event_shape_gate` skips them as it does `UNIT_CASTEVENT` |
| Per-`nameplate<N>` field events (`UNIT_AURA`, `UNIT_FLAGS`, `UNIT_SPELLCAST_*`) and `nameplate<N>targettarget` | todo — reachable, costed, deferred | Split out of the row above rather than folded in, because these are the measurable remainder of that feature and nothing else blocks them. pfUI's nameplate module has an arm for each (`modules/nameplates.lua:628` `UNIT_FLAGS`, `:651`/`:665` the cast pair, `:681` `UNIT_AURA`), each guarded by `strfind(arg1, "^nameplate")`, and each only sets a dirty flag that bypasses its own throttle — so their absence costs *latency*, not function: the module falls back to the throttled central `OnUpdate` it keeps for exactly the no-ClassicAPI case, which is why the plates style correctly without them. The work is not a binding: `UNIT_AURA` and `UNIT_FLAGS` come from `ui_unit.rs`'s `fire_transitions`, which diffs a token's previous snapshot against its current one, and running that per plate means 40 snapshot diffs and 40 memo entries a frame on top of the 40 builds the token feed already does — a real per-frame cost for an earlier repaint, which wants measuring against a live session rather than guessing. The cast pair additionally needs `C_Spell.UnitCastingInfo` / `UnitChannelInfo`, which the "ClassicAPI tail" row above still lists as unbuilt (pfUI's `PollCastInfo` calls both), so a cast event with no way to read the cast behind it would fire into a handler that learns nothing. `nameplate<N>targettarget` is one more descriptor hop for a *third* snapshot per plate (120 a frame at 40 plates); the only caller is pfUI's aggro scanner, which reads it as the second of two terms and already scores through the first (`nameplate<N>target`, built), so the token currently names nothing — recognised, as the prefix rule has made it since the earlier pass |
| `IconDataProviderExtraType` | todo — the constant is the smallest part | Not built, because installing it fixes nothing and the values are unverifiable. pfUI only ever passes it *through*: `CreateIconPicker(name, parent, extraType, ...)` hands it straight to `CreateAndInitFromMixin(IconDataProviderMixin, extraType)` (`api/ui-widgets.lua:1288`), and the picker then calls `provider:GetNumIcons()`, `:GetIconByIndex(i)`, `:SetIconTypes({ IconDataProviderIconType.Spell })` and `:Release()`. So `IconDataProviderMixin`, `IconDataProviderIconType` and `CreateAndInitFromMixin` are all absent too (the harness lists `CreateAndInitFromMixin` among its missing globals), and the mixin itself needs an **icon catalog** — an enumeration of every `Interface\Icons` texture in the patch chain — which this VM has no feed for at all. Installing the enum alone moves the raise from module scope into `EnsureProvider`. And the values cannot be taken from the one call site, which only reads `.Spellbook` and `.Equipment` as opaque seeds: modern WoW builds this through `EnumUtil.MakeEnum` (1-based) where a plain table literal would be 0-based, and nothing available here distinguishes them. Two call sites, `modules/macroicons.lua:36` and `modules/equipmentmanager.lua:388`; both lose an icon picker, neither loses anything else |
| `C_Map.GetMapOverlays` — the `tiles` array | done — the shape the caller actually reads | Supersedes the `Map (C_Map)` row above on this one member. The function existed and was returning every field *except* the one pfUI's reveal pass walks: `modules/mapreveal.lua:151` is an unguarded `for _, tile in ipairs(overlay.tiles) do`, so "reveal unexplored map" raised `bad argument #1 to 'ipairs'` on the first row and drew nothing. Each cell now carries `file`/`width`/`height`/`texCoordX`/`texCoordY`/`offsetX`/`offsetY` — exactly the seven the call site hands `SetTexture`/`SetSize`/`SetTexCoord`/`SetPoint`, and no others. **The grid is the reference's own**, `WorldMapFrame.lua:112-159` off the player's chain: 256-px cells, row-major numbering from 1, the remainder cell on the last row and column. **The file sizes are measured, not predicted**, through the `TextureSizeProbe` `ui_script/lifecycle.rs` already installs — and that is the whole reason the member needed work rather than a rename, because this install's art is **not** the reference's: every `Interface\WorldMap\<Zone>\` overlay is re-exported at 2x. Measured over the whole table: **684 of 707 rows ship tile files whose dimensions are exactly 2x what the stock loop assumes, and not one matches 1x**. The stock loop survives that only because its `span / assumedPad` fraction is scale-invariant; it shears the moment a shipped pad is not the assumed one times that factor, which is what pfUI's own comment warns about and names (`Icepoint/KANEQNUUN`). So the per-overlay factor is read off tile 1 and every fraction is taken against the real denominator. Verified on real art, not a fixture: `world_map_tests.rs`'s `pfuis_reveal_body_tiles_the_real_alterac_overlays_rects_exactly` runs the addon's loop over Alterac's 16 shipped rows with the live probe and pins `GALLOWSCORNER` at the rect's 183x185 with a 366/512 crop — 183/512 if the factor is missed. **What this still cannot do**, stated because a caller cannot tell: the grid *shape* comes from the DBC rect, because a power-of-two pad bounds its content without determining it — a 1-wide/2-tall row (`Alterac/CORRAHNSDAGGER`) and a 2-wide/1-tall one ship indistinguishable pad sequences, so fitting the grid to the files alone misreads it. 23 of the 707 rows have art that disagrees with their rect, in three shapes: 6 ship **fewer** files than the grid asks for (those cells are **omitted** rather than listed, so a caller never acquires a texture for a file that is not there), 3 ship **more** (ignored — and 121 further rows ship extras past a grid that otherwise matches exactly, so appended files are ordinary in this data rather than a signal), and 14 ship the right *number* of files at the wrong *sizes* — `KANEQNUUN` among them, which has a sliver column the rect rounds away entirely and whose own tiles are trimmed on the other axis too, so no consistent grid fits it at all. Those 14 keep the rect's geometry with the measured denominator, which is undistorted-and-clipped rather than stretched, and is as close as a pad that bounds its content can get. Cost: one texel probe per tile per zone, memoised by path in the existing probe (~20-40 ms on the first open of a zone with overlays, nothing after); a probe-less VM (a bare `UiScript`, the addon survey) gets an empty `tiles` array, which is still an array |
| `C_Container.GetContainerItemCharges` (third entry) — **and why pfUI's bag loop is not the bug it looks like** | done — a reversal, and the earlier reason was looking in the wrong place | Supersedes the two `todo, blocked` rows above. The recorded reason was that nothing in **`benilla-formats`'** item template says which of an item's five spell-trigger slots is a consumable charge pool — true, and irrelevant: item templates do not come from a DBC here, they come over the wire. `benilla-protocol`'s `ItemSpellEntry` carries all five blocks with their own signed `SpellCharges`, so "which block is the pool" is answered by the block itself, and `ui_items/feed.rs` was **already** making exactly that choice — the tooltip's "N Charges" line has been printed off it all along (`charges_count`, the port of the builder's `0x52d8a0` gate). All that was missing was carrying the *instance's* countdown of the chosen block onto `ContainerSlot`. Now `charge_pool` returns the block and the two readers take different halves of it (the tooltip the template's full pool, the bag verb the live `ITEM_FIELD_SPELL_CHARGES + index`), so they cannot come to disagree about which block an item's charges live in. **The second half of this row is the fault that was reported as separate.** `pfUI/modules/bags.lua:210` raising `attempt to index field '?'` while looping `for bag = -2,11` over `pfUI.bags[bag].slots` is **not** an independent bug and needs no client-side special case: `pfUI.BACKPACK` and `pfUI.BANK` union to exactly `{-2..11}`, `CreateBags` creates a frame for every id in its list **unconditionally** (`:313`, before any `GetContainerNumSlots` read), and both calls run from one `PLAYER_ENTERING_WORLD` handler (`:133`, `:136`). So nothing about a real client's `GetContainerNumSlots`, its keyring at bag -2 or its bank bags answers differently — the loop is safe there because the table is complete. It was incomplete *here* because `:452`'s `if charges > 1` raised **inside** `CreateBags`' own `UpdateSlot` call (`:322`), aborting the handler before line 136 ever ran and leaving `pfUI.bags[-1]` and `[5..11]` absent for the next `BAG_UPDATE`. One nil return, two reported faults; the cascade is visible in `logs/errors_2026-10-07_16-40-25.log:327-339`. Hence the shape rule here: a **number for every `(bag, slot)`**, 0 for an item with no pool, an empty slot or an absent bag — the same 0-not-nil choice `GetContainerNumFreeSlots` already takes, and all three are true statements. **What is chosen rather than confirmed**: the arithmetic. "Uses left" is the member's documented meaning, but the other plausible candidate is `stackCount x usesPerItem`, and the two differ for a *stack* of charged items. That is safe here and the safety is checked rather than assumed — pfUI reaches the verb only inside `if count == 1`, where the candidates coincide, and only ever tests `> 1` (`container.rs`'s `container_item_charges_answers_a_number_for_every_slot_so_pfuis_bag_loop_cannot_raise` transcribes that block). SuperWoW's own `GetContainerItemInfo` negative-stack-count row above is blocked on the *same* mistaken reason and should be re-read next to this one |
| `GameTooltip:GetGameObject` / `HasGameObject` | done — a deliberate reversal, same mechanism as `GetUnitGUID`, 17x the cost | The `Newly surfaced by the above` row records this as `todo` with two reasons. One was right and is now fixed the way `GetUnitGUID`'s was; the other was simply wrong. **Right**: nothing recorded a GameObject *subject*, and re-deriving one at read time would answer about whatever the pointer is over *now*, where the getter promises the object the plate on screen is describing. Fixed by recording it at build time — a third `TooltipSubject::GameObject { object_id, name }` variant written by `world_tooltip_gameobject` and dropped by `clear_content` with the lines it described, exactly the `TooltipState::unit_guid` shape. **Wrong**: "there is no object-template cache keyed like `item_templates`". `benilla-app`'s `GameObjectTemplates` is a `QueryCache<u32, GoTemplate>` keyed by precisely that entry, and `ui_tooltip/mod.rs` was already holding the resolved template *and* the guid in hand when it called over to build the plate — only the id was being dropped at the seam. Built because the absence cost **236 raises in one play session**, seventeen times the 14 that justified `GetUnitGUID`, and for the same structural reason: pfQuest hangs its reader on a frame **parented to** `GameTooltip` (`map.lua:253`), so every tooltip that becomes visible fires it — unit plates, item plates, pfUI's xp bar, pfQuest's own tracker rows. Shape pinned by the live call site, not by memory: `map.lua:296` is `local _, oid = GameTooltip:GetGameObject()` feeding `pfMap.tooltips_object[oid]`, so it is `GetUnit`'s two-value `(name, id)` with the entry in the token's place and **no third value**, nothing pinning one. The id is `OBJECT_FIELD_ENTRY` and deliberately not the guid: that is what the caller's own comment at `:294` asks for ("sourced from the spawn-packet template field rather than parsed out of a GUID") and the only thing a static node index can be keyed by — a per-spawn guid matches nothing. The corpse plate borrows the same builder for its one gold line and records **no** subject, so `HasGameObject()` stays false there. The test fails against three rejected designs, not merely against absence: `tooltip_anchor_tests.rs`'s `pfquests_own_tooltip_hook_reads_the_object_entry_off_the_plate_the_world_hover_built` transcribes the addon's `OnShow` body, and a missing method raises at the call, a name-only return leaves `oid` nil so the index is never reached, and a guid in the id's place matches nothing. Widget method, so `tests/widget_surface.rs`'s `ALLOWED_BEYOND`, not the global list. **Honest correction to that earlier row's framing**: these 236 raises were *not* why pfQuest showed no tracker and no icons. `script/event.rs` records a handler error rather than re-raising it (`:157-171`), so the raise only truncates the tail of pfQuest's own `OnShow` — it costs the addon its GameObject tooltip annotations and 236 log lines, nothing more. The icons had a different cause; see the `GetQuestLogLeaderBoardID` row below |
| `GetQuestLogLeaderBoardID` + `C_QuestLog.GetQuestDetails` — **this is why pfQuest drew no tracker and no map or minimap icons** | done — two reversals, one of them the actual blocker | `compat/classic_api/quest_log.rs`. Both were refused in that file's header for reasons that have to be separated, because only one of them was about data. **`GetQuestLogLeaderBoardID`**: the stated reason was that `QuestLogObjectiveView` carries `kind`, `text` and the `cur`/`req` pair but no creature/object/item id, "so there is nothing to return". True of the view and untrue of what fed it — `ui_quest_log.rs`'s two line builders had `ReqCreatureOrGOId` and `ReqItemId` in hand when they formatted the sentence and were discarding them. The view now carries `QuestLogObjectiveView::id`, with the wire's `0x80000000` GameObject marker **stripped** (the bit is what `kind` already says; leaving it in would make every object id a nonsense 2-billion number). **Why this matters far more than its 0 logged raises suggest.** `pfQuest/database.lua:1470` calls it *unguarded*, inside `pfDatabase:SearchQuestID` — the one function that turns each quest in the log into map and minimap nodes — in a `for i = 1, GetNumQuestLeaderBoards(qlogid)` loop that this client's own objective count makes non-empty. So for any quest in the log with objectives the nil global raised and `SearchQuestID` returned before it handed back its map table: no pins, no minimap icons, and a tracker with nothing to list. It did not appear in the error log because the loop only runs once a quest with objectives is in the log; the 236 `GetGameObject` lines were the loud symptom of a different, harmless gap. The id is the function's whole point — pfQuest sorts by it into `parse_obj["U"]`/`["O"]`/`["I"]` — so the test transcribes that scan (`pfquests_node_builder_scan_sorts_real_objective_ids_into_its_unit_and_item_tables`) and fails against a nil global, a 0 id and an unstripped marker alike. Argument order is the stock verb's on purpose: the addon calls the two side by side on the same pair (`database.lua:1469-1470`, `map.lua:366-367`). **`C_QuestLog.GetQuestDetails`**: refused as one of four probes of a standalone `CMSG_QUEST_QUERY` cache. That classification is right for the other three and wrong for this one — both live call sites ask only about quests they already walked out of the log by an id `GetQuestIDForLogIndex` gave them (pfUI `modules/questitem.lua:5`, pfQuest `database.lua:732`), so the honest subset is the whole of what is asked, and nil off the log is a branch both callers already take. Shape from the call sites, the only specification available: `title`, `level`, `objectives` (the objective **paragraph**, because `GetQuestText(id, "O")`'s other branch is one shipped locale string and a list there would be the wrong type), `description`, and `requirements`, an `ipairs` array of `{ kind, id, count }` plus the `have`/`finished`/`text` the row already knows. The `id` is what makes pfUI's module do anything at all — it gates on `req.kind == "item" and req.id and req.id > 0` — so without the feed change above it would have been a verb that never fired. 4 raises for `GetQuestDetails`, and pfQuest's own quest-text reader stops falling back to its shipped locale table for quests in the log. `RequestLoadQuestByID`, `IsQuestDataCachedByID` and `GetTitleForQuestID` stay unbuilt for the original reason, unchanged |
| `UnitCanAssist` | done | `script/unit/bindings.rs`, beside `UnitCanAttack`/`UnitIsFriend`/`UnitCanCooperate` — **not** in `compat/`, because it is a real 1.12 verb (`reference/1.12-globals.tsv:18496`, `0x516bb0`, registered at `.data 0x8504c8`) and so needs no `allowed_beyond_1_12` entry; adding one would fail `the_exception_list_has_no_dead_entries`. It was simply never installed, and the cost was **649 raises in one session, the largest single count in the log**: `pfUI/modules/nameplates.lua:14` captures it as a file-scope upvalue, so the local stays nil for the module's life, and `:214` is an early-out inside the per-plate combat-tint path — every raise aborted one plate's styling partway. `libs/libpredict.lua` uses it three more times as the heal-prediction self-cast switch. All four call sites read a single value for truthiness with no destructuring, so `flag(bool)` (1 or nil, never a Lua boolean) is the whole contract. The predicate is `CanAssist`'s own three terms (`0x6066f0`), spelled the same way `benilla-app`'s port of the same engine function already spells them (`target/relations.rs`'s `can_assist`, which gates `UnitBuff` visibility) so the Lua verdict and the engine's cannot disagree about one unit: `UNIT_FLAG_NOT_SELECTABLE` clear, a reaction of at least `UnitReaction`'s 1-based 5 — the same cut `UnitIsFriend` takes, and the internal `>= 4` the engine applies plus the 1 it adds at `0x51683e` — and, for a unit that is not player-controlled, its PvP bit. That third term is the one a reaction-only stand-in gets wrong, and it is why a priest cannot heal a quest giver; a test enumerates all three. Two narrowings, each inherited from what `UnitState` carries rather than chosen: `IsPvP` reads the *owner's* flag first (`0x5ee5a0`) and the snapshot carries `owner` as a guid with no flags beside it, so a hostile minion that is not itself player-controlled reads its own bit (a player's pet carries `UNIT_FLAG_PLAYER_CONTROLLED` and takes the arm above, which is the case that matters); and the reference's player-controlled arm reads an unnamed `[obj+0xe68]` record that is not ported app-side either, so such a unit passes. `CanAssist(P, P)` is true in the reference (`0x6061e0` answers 5 for a unit toward itself) but every feed site holds the reaction *toward* the player, leaving the player's own snapshot at 0 "not fed", so a guid compare restores that one answer instead of leaving it silently nil |
| `MouselookStart` / `MouselookStop` / `IsMouselooking` | partial — `IsMouselooking` is real, the pair are documented no-ops | `script/pointer.rs`, beside `GetCursorPosition`/`GetMouseFocus`; all three are 1.12 engine verbs (`reference/1.12-globals.tsv:11821`, `:11822`, `:10611`), so no surface exception. `IsMouselooking()` is **backed by the real camera rig**: `CameraControl::mouselooking` — the reference's own `[cam+0x90] & 1` (set `0x50fe41`, cleared `0x50fddd`), which is `freelook`, a right-held turn or a both-button run and deliberately **not** a left-button orbit — pushed each tick as a new `SelfMovement::mouselooking` field. That rode into `ui_unit.rs`'s existing `feed_self_movement`, a system that already holds the VM, for **zero measured ambiguity cost**: `WOW_AMBIGUITY_DUMP=1` shows three new pairs naming `feed_self_movement` and the actionable total stays at 5581, so `UPDATE_ACTIONABLE_CEILING` is untouched. **The pair do not start or stop a look session, and that is a behavioural deviation rather than an absent value, so it is stated plainly.** benilla's mouse-look is not a mode the engine can be put into from outside: it is latched per frame from the buttons *the world owns* (`player/camera.rs`'s `latch_world_mouse` then `run_look_session`), the session begins on a world press and ends when that press is released, and a press captured by a frame is dropped before the latch sees it. A Lua `MouselookStart()` has no press behind it and therefore no release edge either, so forcing the flag on would leave the camera turning with nothing able to stop it — worse than doing nothing, and not what the reference does, where the call joins a session the hardwired `BUTTON2` binding owns and that binding's release ends. `bindings/commands.rs` records the same fact from the other side (`TURNORACTION` declared absent, "right-button mouse-look is hardwired, not routed through a binding"). The one corpus caller is pfUI's nameplate right-click emulator (`modules/nameplates.lua:1899-1934`), which calls `MouselookStart()` on a plate's `OnMouseDown`, polls `IsMouselooking()` to tell a drag-look from a click, and synthesises the click once the poll says no look is running. The nil global aborted that handler **before** it armed the poll, which is why right-clicking a pfUI nameplate did nothing at all; with these installed the poll runs and reads false, which is the truth, because the press that armed it was captured by the plate frame and so is a press the world never owned. 2 raises, and a feature back. Making the pair real needs a look session the VM can open and close — a camera state-machine change, not a binding. `script/tests/input.rs`'s `pfuis_nameplate_right_click_emulator_arms_and_then_synthesises_the_click` transcribes the emulator and fails against the absent global |
| `C_PlayerCache` (`RememberPlayer`, `GetPlayerInfoByName`, the four enable toggles) | done — the store's writer and its reader are the same addon | `compat/classic_api/player_cache.rs`, superseding this member's entry in the "ClassicAPI tail" row above, which classified it as needing a 1.12-absent subsystem. It needs no feed at all, and the reason is worth stating because it is the thing that makes the one unverifiable part unverifiable-but-safe: pfUI **fills** the cache itself from every roster, inspect and whisper scan it already runs (`libs/libunitscan.lua:42-47`, `RememberPlayer(guid, name, class, UnitRace(unit), UnitSex(unit))`) and **reads it back** by name to colour a player link in chat (`modules/chat.lua:830`). So every value here is the caller's own, round-tripped — nothing derived, inferred or invented. The one thing that could be wrong is which return slot carries the class token, and it cannot be, because that slot carries exactly the argument the caller named `classToken`. Return order is `GetPlayerInfoByGUID`'s and is pinned by that call site's destructuring rather than by memory: `local _, class, _, raceKey, sex = ...`, five values with the class token second and the race key and sex fourth and fifth. The two slots the store has nothing for answer **nil rather than a guess** — slot 1 is the *localized* class name and slot 4 the *English* race key, where `RememberPlayer` is handed a class token and `UnitRace`'s localized first return, and faking the other spelling of either means a reverse lookup through a localized string, wrong on any non-enUS realm. A miss answers **no values at all**, which is what lets the caller's `if not class then class = GetUnitInfo(real) end` fall through to its own scan instead of colouring with an empty string. The honest limits: benilla's `names::NameCache` is guid→name only, so a player this session never scanned is absent even if they are standing in front of you, and nothing persists across a logout where upstream's hooks the client's own cache and does. The four toggles are preference state with nothing downstream, exactly as `container.rs`'s bag-sort pair is (upstream's gate the DLL's background name scan; this client runs none), both defaulting **on** so an addon that gates on `IsEnabled()` is not told the store it can write to is closed. 7 raises. `GetPlayerInfoByGUID` and `UnitNameFromGUID`, the two bare siblings, stay unbuilt — neither is called, and a guid-keyed class/race lookup genuinely has no backing here |
| `C_Item.GetItemUniquenessByID` (restated) — the 404 was a wrong branch | todo — reason sharpened to something actionable | No change to the decision; the row above is still right that the *fact* is here (`ItemTemplateView::max_count`) and the **return shape** is not, and that guessing is invisible to the caller in both directions. What is new is that the prerequisite it named is half done. Upstream's `docs/API.md` does not 404 because it is gone — it 404s because the path cited there is on `main` and the repository's default branch is **`master`**. `brues-code/ClassicAPI` is public, its tree is readable, and the two files that answer this question outright are `src/item/Uniqueness.cpp` and (for the charges row above) `src/item/Charges.cpp`. It is still `todo` because the fetcher available in this pass could not read them honestly: `docs/API.md` resolves on `master` but is **truncated before the Item section**, and the summariser demonstrably confabulates past the cut — asked for the source tree it invented directories (`src/romance`, `src/witch`, `src/worship`) that cannot exist in a WoW API DLL. Anything it "quoted" past the truncation is therefore unusable as a signature, which is exactly the standard this row was written to protect. Next pass: read those two files directly (a git clone or an authenticated API read, not a summarising fetch) and the shape falls out of the `Push*` calls and the `return N`. One raise, `pfUI/modules/itemcount.lua:16` |
| `C_NewItems` (restated) — re-verified, unchanged | todo — the objection survives new information | Re-read against the live log rather than re-decided, and the two reasons the row above gives both hold. (1) benilla fires no `BAG_NEW_ITEMS_UPDATED`, and pfUI's module refreshes its glows from `EventRegistry:RegisterFrameEventAndCallback` on exactly that event (`modules/newitem.lua:60`), so a perfect `IsNewItem` would still never repaint. (2) The cheap version is a *positive* claim that a just-looted item is not new, indistinguishable by the caller from a correct one, which turns a loud failure into a feature that is permanently and silently off — the same objection that keeps `GetItemUniquenessByID` out. What the upstream tree would add, for whoever builds it: `src/item/NewItems.cpp` is the file to read, on `master`, and the event is upstream's own to fire — so firing it is part of the job, not an excuse not to do it. 3 raises, and they are low because the harness never opens a bag |
| `IconDataProviderExtraType` (restated) — re-verified, unchanged | todo — still fixes nothing on its own | Checked against the current surface rather than re-argued: the row above's claim still holds in full. `IconDataProviderMixin`, `IconDataProviderIconType` and `CreateAndInitFromMixin` are all still absent (the addon survey still lists `CreateAndInitFromMixin` among its missing globals), pfUI still only passes the constant *through* `CreateIconPicker` into `CreateAndInitFromMixin(IconDataProviderMixin, extraType)` (`api/ui-widgets.lua:1288`), and the mixin still needs an enumeration of every `Interface\Icons` texture in the patch chain that no feed provides. Installing the enum alone moves the raise from module scope into `EnsureProvider`, which is not a fix, and the values are still unavailable from the one call site, which reads `.Spellbook` and `.Equipment` as opaque seeds. 2 raises, both an icon picker neither call site can show anyway |
| `HEARTHSTONE_ITEM_ID` — **this, not the quest verbs, is why pfQuest's tracker and icons were still blank** | done — one global, and it turns the whole addon on | `compat/classic_api/container.rs`'s `install`, beside `PlayerHasHearthstone`/`UseHearthstone`, which is where modern FrameXML declares it; `reference/1.12-globals.tsv` has no row for it. **The seven stock quest-log verbs were never the problem.** Measured with the harness read-back probe (`--probe pfQuest --eval …`), which is the only instrument that could see this: `GetNumQuestLogEntries()` answered `3, 2` for the seated log, `GetQuestLogTitle(2)` answered `The Fargodeep Mine, 10, nil, nil, nil, nil`, and forcing `pfDatabase.localized = true` by hand made `pfQuest:UpdateQuestlog()` return `change=true` and fill `pfQuest.questlog` with `62=The Fargodeep Mine/2 176=Kobold Candles/3` — the whole chain below the gate was already correct. The gate: `database.lua:2215-2246`, the last block of the last file of pfQuest's `<Include>`, decides whether the server's locale matches its shipped databases by comparing the Hearthstone's live name against `pfDB["items"][loc][HEARTHSTONE_ITEM_ID]` — and `pfDatabase.localized = true` is set *inside* that comparison's `if`. With the global nil, `C_Item.IsItemDataCachedByID(nil)` is false, `Item:CreateFromItemID(nil)` builds an **empty** item whose `ContinueOnItemLoad` poll can never resolve, and the flag stays nil for the session. `quest.lua:352` — `if not pfDatabase.localized then return end` — is the first statement of pfQuest's `OnUpdate`, so every frame returned before `UpdateQuestlog`, before `SearchQuests`, before the queue drain that calls `SearchQuestID`: no tracker rows, no map pins, no minimap icons, for the whole session. **Silent by construction**, which is why it outlasted two earlier passes: reading `t[nil]` is legal Lua, a callback that never fires raises nothing, and `nil == nil` in pfUI's two comparison sites (`libs/libbagsort.lua:19`, `modules/itemcount.lua:16`) is a branch that is simply never taken. The value is not from memory — `container.rs` already held the same const for its two hearthstone verbs, and pfQuest's own shipped table is `[6948] = "Hearthstone"` (`db/enUS/items.lua:5642`), indexed *by* this global, so a wrong id would miss the key and leave the flag nil just as surely. The test transcribes that block whole (`pfquests_locale_check_sets_its_run_gate_from_the_hearthstone_the_bags_hold`) and fails against a nil global and a wrong id alike. **A note on the instrument**: the harness *survey* is blind to this entire class of fault and its table is byte-identical before and after the fix — 13/13 load, 13/13 session, 13/13 UI probe, 10/13 survived use, and the missing-globals ranking never listed `HEARTHSTONE_ITEM_ID` because the scan ranks names that are *called or indexed*, and this one is only ever compared or used as a table key. Only `--probe`'s read-back found it |
| `C_CreatureInfo` reaches every VM, not just the boot one | fixed | `ui_chr_races.rs`/`ui_chr_classes.rs` fed their tables from a **`PostStartup`** system — once, at app boot — so the VM that existed then got them and no other. World entry and `/reload` each build a *fresh* VM, which saw an empty `C_CreatureInfo`. Not cosmetic: pfQuest builds its race and class bitmasks at **file scope** (`database.lua:402-413`) and `GetBitByClass` has no fallback (unlike `GetBitByRace`), so an empty table made it answer nil and `bit.band(…, nil)` raise in `QuestFilter` (`database.lua:1707`) **every frame** — 380 raises in one real session, with `SearchQuests` aborting before its queue drain. That is the FPS collapse the user reported, the missing map icons, and the tracker that only filled when some other path happened to populate it. Each feed's body is now a `seed_*` function the VM-construction path in `ui_script/lifecycle.rs` calls directly — seeded **there** rather than by moving the systems to `Update`, because pfQuest reads the tables at file scope, so a push one frame later is a push too late. A test transcribes pfQuest's own file-scope loop and was verified to report an empty bitmask (`left: 0, right: 1`) without the seeding |
| Harness fixture: `C_CreatureInfo`'s race/class tables, the Hearthstone's item template, and a zone | done — three states the live client always has and the harness never did | `addon_harness/mod.rs`'s `seat_a_session`. Not client code; recorded here because each one was hiding a feature the harness therefore could not reach, and two of them looked like client faults. **Race/class tables**: the live client pushes them once in `PostStartup` off the player's own `ChrRaces.dbc`/`ChrClasses.dbc` (`ui_chr_races.rs`, `ui_chr_classes.rs`); the harness seated none, so pfQuest's `for id = 1, 32` walk (`database.lua:402-412`) built empty `pfDB.bitraces`/`bitclasses`, and `GetBitByClass` — which unlike `GetBitByRace` has **no fallback** — answered nil, which reached `bit.band(…, nil)` in `QuestFilter` (`:1707`). That raise aborts `SearchQuests` at `quest.lua:383`, which runs *before* the queue drain in the same `OnUpdate`, so it also cost every `SearchQuestID` map node, and `updateQuestGivers` is only cleared after the call, so it re-raised every frame. Seated from this crate's own `ui_unit::race_names`/`class_names`/`race_faction_group` rather than a second copy, so the fixture cannot disagree with its own `UnitRace`/`UnitClass`; the 1.12 class gaps at ids 6 and 10 stay gaps. **Item template for 6948**: a live bag push is itself what queries each slot's template (`ui_items/feed.rs` calls `items.template(entry, …)` per slot), so a logged-in character always has it; the harness held a Hearthstone in bag 0 with no template behind it, which made `IsItemDataCachedByID` take the 600-tick poll arm that a ten-tick session start never finishes. **A zone**: `area.rs` pushes four host globals on every area change, and pfQuest's default `trackingmethod` 5 matches a quest's log header against `pfMap:GetCurrentZone()`, whose fallback is `GetRealZoneText()` (`map.lua:678`) — with no zone its tracker lists nothing however full the log is. Elwynn Forest, to agree with the seated log's header row. With all three in place the probe now walks the whole feature end to end: `localized=true`, `questlog=2`, `nodes=194`, `trackerrows=2 [The Fargodeep Mine, Kobold Candles]`. The survey table is unchanged by all of it |
| Quest-watch persistence (`Model::quest_log_watched`) | todo — **buildable, but the reference behaviour is the unconfirmed part, not the plumbing** | The set lives only in the VM (`script/model.rs:977`); nothing in `crates/` reads or writes it to disk, so a relog or `/reload` — which rebuilds the VM — drops every tracked quest. Two facts are settled and worth recording so the next pass does not re-derive them. **It is client-side**: `reference/1.12-message-catalog.tsv` has no quest-watch opcode at all, and `reference/1.12-shapes.tsv` lists `AddQuestWatch` (`0x4e1930`), `RemoveQuestWatch` (`0x4e1970`), `IsQuestWatched` (`0x4e1890`) and `GetNumQuestWatches` (`0x4e1860`) as engine globals on one vtable (`0x84b0f0`), so no server round trip is involved either way. **And the implementation is cheap and safe**, correcting an earlier worry: `quest_log_watched` is a `Vec<u32>` of **quest ids**, not log indices (`script/quest_log.rs`'s `watch_id_at` resolves the index to `QuestLogEntryView::quest_id` on the way in), so persisting it restores the right quests even when the log order changes — a `benilla-config/` file through `local_state.rs` plus a resolve once the log lands. What is **not** established is whether the reference 1.12 client persists the array at all: nothing in this tree says so either way (`AUTO_QUEST_WATCH` is the auto-track CVar's label, not the list), and the only claim to that effect was an investigation note with no source. Building it on that would be a silent fidelity deviation in whichever direction the guess went, which this file's own rule ranks below an absence. Not the pfQuest symptom in any case — that tracker's inclusion is not gated on watch state (`tracker.lua:524` uses `watched` for ordering and styling only) |
| `QUEST_TURNED_IN` | **built** | `quest.lua:261` registers it and `:310` uses `arg1` as the questID to stamp `pfQuest_history[arg1]`, the authoritative turn-in record that keeps the questlog REMOVE path from having to guess turn-in vs. abandon by name. Not a 1.12 event — `reference/1.12-events.tsv` has no row for it — so it is declared in `reference_ui.rs`'s `ALLOWED_BEYOND` with its reason, beside SuperWoW's `UNIT_CASTEVENT` and the `DEBUFF_*_OTHER` pair. **The earlier note here turned it down on the grounds that the questID was not available at the moment of the turn-in. That was wrong**: `SMSG_QUESTGIVER_QUEST_COMPLETE` carries `quest_id`, `xp` and `money`, `messages/quest/giver.rs` already parses all three, and `ui_quest/net.rs`'s `quest_complete` already had the struct in hand to build its chat lines — the fact was sitting unused one field away. Queued there (`QuestGiver::push_turned_in`, since a net handler has no VM) and drained in `feed_quest` before the snapshot's early-out, so it fires even though the reward click has already closed the panel. Measured cost of its absence: a quest already handed in kept its map and minimap markers. The old note claimed `pfQuest-octo`'s addon-message sync covered this; it does not — that sync **replaces** `pfQuest_history` wholesale with whatever arrives inside a 3-second window (`patchtable.lua:196-219`), so a slow or absent reply empties the history rather than filling it, which makes `/db query` a way to lose the record, not restore it |
| `ItemMixin:ContinueOnItemLoad` — the wait now **asks** | done — a one-line correction to a function already built | `compat/classic_api/item_mixin.rs`. Found while closing `HEARTHSTONE_ITEM_ID` above and worth its own row because it is a second, independent way for the same pfQuest feature to stay off. Upstream's `Item:CreateFromItemID(id) … :ContinueOnItemLoad(cb)` is how a caller *requests* an item's data — `RequestLoadItemDataByID` is the same namespace's bare spelling of the same act — and this port implemented only the waiting half: a `C_Timer` poll on `IsItemDataCached`, because 1.12 has no `GET_ITEM_INFO_RECEIVED` edge. But `C_Item.IsItemDataCachedByID` records no ask *on purpose* (its own registration says so: a caller polling "is it here yet?" should not trigger the query), so the poll only ever resolved for ids something else happened to read, and ran its full 600-tick bound to no effect otherwise. Concretely: a character whose Hearthstone sits in the bank has no bag slot reading template 6948, so nothing asks, so pfQuest's locale check never completes and the addon is off for that character even with the global present. The fix is one read through the `*ByID` family, whose shared `template()` helper puts a miss into `Model::item_stat_asks` for `ui_items/feed.rs` to drain — one source of truth for item data, unchanged, and no new plumbing. Once is enough: the app's pending set keeps an unresolved id across frames. The test drives the whole arm — ask recorded, nothing fired while the answer is absent, callback on the first tick after `set_item_template` — and fails on the first assertion with the line removed |
| `C_Map.GetAreas` — **this is why pfQuest drew map icons but no minimap icons** | done — one member, and it is the whole of the minimap half | `compat/classic_api/map.rs`, fed by `ui_world_map::seed_area_names` over the `AreaTableRes` the map catalog is already built from; supersedes the `GetAreas` half of the `C_Map.GetAreas`, `C_Map.GetAreaTriggerInfo` todo row above, which still stands for the trigger member. **The asymmetry was the whole clue and it is not in the minimap code at all** — pfQuest's two passes resolve the player's zone *differently*. `UpdateNodes` (world map) takes `GetMapZones()`'s name and, on a miss, `customids[GetMapInfo()]`, a table built at file scope from `C_Map.GetMapAreaIDs` (`map.lua:632-660`), which has shipped here since that member landed. `UpdateMinimap` has no such fallback: one line, `pfMap:GetMapIDByName(GetRealZoneText())` (`map.lua:1365`), over `pfDB.zones.revloc` — and this install's pfQuest has **deleted** its shipped name table (`db/<locale>/zones.lua` is a five-line stub saying the names now come from `C_Map.GetAreas`), so with the member absent `pfDB.zones.loc` was empty, `revloc` was nil, the name lookup answered nil, and the pin loop's own gate `if data[mapID] and minimap_sizes[mapID] …` (`map.lua:1383`) indexed by nil and skipped. **Silent by construction**: `data[nil]` is a legal read, so there is no raise, no log line and no missing-global the harness survey can rank — the name is only ever a table key here, the same blind spot `HEARTHSTONE_ITEM_ID` sat in. Measured with the read-back probe before and after (`--probe pfQuest --eval`): `pfDB.zones.loc` 0 entries → 1,480, `revloc` nil → built, and `pfMap:GetMapIDByName(GetRealZoneText())` nil → **12**, the same id the world-map pass already reached through `GetMapAreaIDs`, which is why the two passes now agree on the key pfQuest's node tables are built under. Two further silent losses close with it: `GetMapNameByID` (the browser's and the tracker's zone labels, `UNKNOWN` for every row) and `GetZoneIndex`, which walks the keys of `pfDB.zones.loc` as the zones to ask `C_Map.GetMapOverlays` for (`database.lua:1104`) — with no keys the subzone index was empty and `SearchZoneID` returned early for every subzone-placed objective. **The shape is pfQuest's own generator, not a guess**: `toolbox/extractor.lua:2084-2104` writes `pfDB["zones"][locale][id] = name` straight out of `SELECT * FROM AreaTable ORDER BY id ASC`, so the answer is the **whole** table (1,480 rows here, 1,400 of them subzone rows with no `WorldMapArea` map — the catalog keeps only the ~80 that have one) keyed by id, ascending. What it cannot fix, said plainly: the caller's reverse `name → id` index keeps the *first* id it meets for a name (`database.lua:285-287`) and 70 of the 1,480 names are carried by more than one row (`Westfall` by both 40 and 206, both top-level), so those names resolve by Lua's own table order. That ambiguity is the shipped table's too and nothing in the DBC says which row a name means; picking one here would be this file inventing a fact. **One correction rode along, and it was forced**: `GetMapOverlays`'s `tiles` array is now resolved on **first read** through a per-VM row metatable instead of being built eagerly (`overlay_row_meta`). A cell is measured by *decoding* its file (`benilla-assets::sprite_dimensions`), and until this member landed nothing ever walked every zone's overlays — `GetZoneIndex` now does, and it reads only `areaID` and the four `hitRect*`. Measured on this install: **1,019 tile files across 707 overlay rows, 1.5 s**, which eager tiles would have spent inside pfQuest's `OnUpdate` at the first quest search. pfUI's reveal is the only reader of `tiles` and is itself gated on `C.appearance.worldmap.mapreveal`, so a player with reveal off now pays none of it; a read of `overlay.tiles` answers the same array it always did and is cached on the row after the first. Also seated in the survey fixture (`addon_harness/mod.rs`), beside the race/class tables and the zone globals and for the same reason: an in-world session with an empty `AreaTable` is a state only the harness reaches, and without it the harness is blind to this whole fault class. Tests: `pfquests_minimap_gate_opens_on_the_zone_the_area_name_table_names` transcribes `database.lua:283-289`, `map.lua:583-595`, the `minimap_sizes` metatable and the `map.lua:1383` gate, and asserts the gate is **shut** on an empty table and open on a fed one; `the_whole_area_name_column_reaches_the_vm_including_the_unmapped_rows` fails a feed narrowed to mapped rows; `an_overlay_rows_tiles_are_measured_on_first_read_and_cached_after` counts probe calls and fails an eager build. **One interaction left standing, with the reason.** pfQuest-octo knows about the duplicate names and dedups them — `overwrites.lua:922-963` deletes 16 "phantom" ids whose names collide with a functional zone's, its own comment naming the exact mechanism ("GetMapIDByName scans the locale table with pairs() (non-deterministic order), so it may return a phantom ID instead of the functional one, causing quests and minimap nodes to not appear inside those dungeons"). That deletion lands on `pfDB.zones.<locale>-turtle`, which `patchtable.lua:92` merges into `pfDB.zones.<locale>` — and then `patchtable.lua:150` calls `pfDatabase:Reload()`, which **re-points** `pfDB.zones.loc` at this call's table and drops the merged copy entirely. So the dedup no longer applies, and those seven dungeon names resolve by table order again. Left alone on purpose: which id a name "means" there is a fact about *pfQuest's database* (which rows carry NPC and object references — the fork says so in as many words), not about `AreaTable.dbc`, and the client has no way to know it. It is also not a regression in either direction — an empty `loc` resolved **every** name to nil, so all seven were already dead — and the custom zones the deleted `-turtle` names existed to supply are in this install's own `AreaTable.dbc` anyway (Dragonmaw Retreat 5600/5601, Hateforge Quarry 5098/5103, Gilneas City, Frostmane Hollow, The Rock of Desolation), which is the whole reason the fork deleted its shipped tables for this call |
| 3D unit portraits on an addon's own `PlayerModel` pane (`CreateFrame("PlayerModel", …)` + `:SetUnit`) | todo — **genuinely not built, not a bug**; the 2D path beside it works | What pfUI asks for: `api/unitframes.lua:1455-1456` creates one pane per unit frame (`pfPortraitModel<label><id>`, plus an off-screen `next` pane for change detection) and its `OnUpdate` drives `:SetUnit(unit)` then `:SetCamera(0)` (`:1222-1226`), with `:SetModelScale`/`:SetPosition`/`:SetModel` on the not-visible leg (`:2030-2033`). Every one of those verbs exists and raises nothing (`script/modelframe.rs`; probed: the pane is a live `PlayerModel` named `pfPortraitModelplayer`, `SetUnit` + `SetCamera` return clean, and `GetModel()` stays nil after `SetUnit` as it does for every unit pane here). **What is missing is on the app side and it is a feature, not a line.** A `<Model>` pane with a `SetModel` *path* renders generically — `ui_models/mod.rs` says so in its own first line, "to an addon's `CreateFrame("Model")"` — but a pane with a *unit* is routed instead to a pre-built **booth**, and the routing key is the pane's **global name**: `portrait::MODEL_PANE_BOOTHS` is a seven-entry table of the stock files' own names (`CharacterModelFrame`, `TabardModel`, `PetModelFrame`, `InspectModelFrame`, `PetStableModel`, `DressUpModel`, `AuctionDressUpModel`) whose doc says "A pane not in this table draws nothing", and the extract's unit leg is literally `let Some(slot) = name.and_then(model_pane_booth) else { return; }` (`ui_script/extract/mod.rs`). An existing test already states the behaviour with an addon-shaped fixture: `a_named_model_pane_samples_its_booth_and_an_unclaimed_one_draws_nothing`. So the pane is created, sized, shown and asked for a unit, and the app draws nothing — which is exactly "the frame is there and empty", with no error anywhere. **What it would take**, named so the next pass can cost it: a *pooled dynamic booth*, keyed by the pane's `FrameHandle` rather than by a name. Each live unit pane needs a render layer, a camera, a dressed `StageRig` for the unit and a bake target of its own — the four things `portrait::sync_portraits` builds today for each of the nine fixed `SLOTS`, which it walks as a `const` array with a layer per slot off `PORTRAIT_LAYER_BASE` and a block of `const _: () = assert!(…)` keeping every booth layer distinct. The precedent for the pooled shape is in the same file: `UI_MODEL_CAM_LAYERS = 8` already caps how many *file* panes get a perspective camera at once ("a ninth draws nothing"), so a unit-pane block alongside it, capped the same way, is the shape — pfUI alone would want up to ~48 panes (player, target, targettarget, pet, party1-4, raid1-40) and only the shown ones need a booth. The framing is already settled and already written down: a `<PlayerModel>` renders through the model's raw `cameras[1]` frozen at load (`portrait/framing.rs::body_frame`, `0x505890`), lit by `BoothLight::pane` with no glow. **Not faked in the meantime**, and the tempting fake is worth naming: an unclaimed unit pane could be pointed at the round 64² bust bake that `SetPortraitTexture` already produces for the nine slots, and it would look plausible in pfUI's square portrait box — but a `<PlayerModel>` is a live model through a model camera, not a circular bust, and a caller cannot tell a stand-in from the thing. **The 2D path is not broken**, which is the other half of the answer: `SetPortraitTexture(region, unit)` works for all nine round slots (`extract/mod.rs`'s `portrait_unit` arm, honouring the `SetTexCoord` crop pfUI applies), so a player can have 2D portraits today by ticking pfUI's "Always Use 2D Portraits" (`C.unitframes.always2dportrait`). It is off by default — pfUI ships `always2dportrait = "0"` with `portraittexture = "1"` (`api/config.lua:224-225`), and that second flag is only the *fallback* leg, taken when `not UnitIsVisible(unit)` or `not UnitIsConnected(unit)` — so for a visible target the 3D leg is what pfUI asks for and what the empty box is. A raid or party slot past the nine has no round bake either, so the 2D fallback is itself blank there; that is the same fixed-`SLOTS` limit and would close with the same pooled booth |
| 3D unit portraits on an addon's own `PlayerModel` pane — **built**: a pooled dynamic booth keyed by the pane's `FrameHandle` | done — supersedes the `todo` row above, which costed it exactly right | **This is the empty 3D portrait box in pfUI.** The row above was correct in every particular: the pane was created, sized, shown and asked for a unit, and the app drew nothing because `portrait::MODEL_PANE_BOOTHS` routed a unit pane by the pane's *global name* and `pfPortraitModelplayer` is not one of the seven stock names. Built as that row specified. **The pool** (`portrait::UnitPaneBooths`): eight dynamic booths, each a `Booths` entry like any other — render layer (`UNIT_PANE_LAYER_BASE`, a new block on top of the `UI_MODEL_CAM_LAYER_BASE` ladder), camera, root and 256² target, all spawned at `setup_booths` because a camera spawned mid-frame misses the render world's extract. Keying by `FrameHandle` rather than by name is the whole point: `pfPortraitModelplayer` and an anonymous `CreateFrame("PlayerModel")` are the same kind of caller. **Claim and release** are the UI extract's, in `convert_entry`'s `ModelPane` arm through the new `BoothBridge::model_pane_slot`: the stock seven-entry table is tried first and unconditionally, so **no stock pane changed behaviour**, and only a pane outside it claims a pooled slot. The liveness sweep (`sweep_begin`/`sweep_end`) runs on the extract's **full-conversion** path alone, the one pass that sees every drawn pane — so `QuadContent::ModelPane` carrying a unit is now **unspliceable** (`splice_simple`), exactly as a `portrait_unit` texture already was, and for the same reason: an entry whose side channel decides which booth renders must be seen by the pass that rebuilds the whole map. **Only a pane the extract actually draws** can claim, which is what keeps pfUI's cost at one booth per unit frame rather than two: `api/unitframes.lua:1456` also creates a parentless, size-less `model.next` as a `SetUnit` change detector, and probing it in the harness gives `shown=1` but `GetLeft()==nil` — no resolved rect, so the extract's `let Some(r) = eq.rect else { return }` drops it and it never costs a slot. **Past the cap a pane draws nothing**, the same answer `UI_MODEL_CAM_LAYERS`'s ninth perspective file pane gets, and deliberately **not** the round 2D bust bake the `todo` row named as the tempting fake. A slot freed by a pane that stopped drawing reaches a pane the cap refused through one extra full conversion (`UnitPaneBooths::take_handover`), gated on a slot actually freeing so that nine permanently drawn panes cannot pin the full-conversion path on. **`SetCamera` is honoured, and it is the difference between a portrait and a full body.** A `<PlayerModel>`'s camera could not ride `ModelState::camera`, which resolves against the path-keyed `ModelFileFacts` a unit's model never enters, so `camera_pending` would never clear; the new `ModelState::unit_camera` is that slot. `SetUnit`'s load installs the model's raw index 1 (`0x505890`, the characterinfo camera the paper doll frames through) and `SetCamera` overwrites the same `+0x31c` slot — so pfUI's `SetUnit(unit)` then `SetCamera(0)` (`api/unitframes.lua:1223-1224`) ends on index 0, the model's **authored portrait camera**, a bust. `framing::pane_frame_at` picks `PortraitAnchors::camera` for 0 and `pane_camera` for 1; any other index falls to the fixed rig rather than to the other authored camera (the reference installs the NULL camera there and draws orthographic, which no `<PlayerModel>` here does). Through index 1 a 36×36 pfUI portrait box — the probed size of `pfPortraitModelplayer` — would hold a whole figure a few pixels tall. **`SetModelScale` and `SetPosition` are ignored**, exactly as the four stock body panes already ignore them, and the reason is the reference's own: an authored camera is published through the same scaled model root (`0x71439b` → `0x718960`), so both cancel — that is why `framing::pane_root_scale_at` returns 1.0 wherever the installed index names an authored camera. pfUI agrees in practice: it calls neither on the unit leg, only on the *file* leg (`:2030-2033`), which `ui_models` already serves. The unauthored-camera branch, where they would **not** cancel, is not built; see the `todo` row below. **Deviation, taken for cost (`PaneLife::Still`)**: the reference's `<PlayerModel>` is live, but it drew one in the main pass with no second view, where a unit frame's portrait is on screen for the whole session and there can be eight. A pooled booth bakes a **still**, frozen at Stand with no item emitters, re-baked on the same `SnapKey` edges the body panes re-snapshot on (`SnapKey` gained the camera index, so a `SetCamera` re-aims); between bakes `gate_booth_cameras` sleeps the camera and parks the rig, and the target keeps the last render. The four stock window panes keep `PaneLife::Live`. **Measured** (release, Ryzen 7 7800X3D / RX 7900 XTX, 2560×1440): steady state, 8 live panes cost **9.0 µs of CPU a frame** (1.13 µs a pane — one descendants walk and one `SnapKey` per pane, no render); one bake costs **7.7 µs of CPU** (33-draw look, teardown plus respawn, commands applied) plus **one 256² pass for the 4-frame settle window** — eight pool cameras forced active measure **+0.11 ms a frame** over the same build with the pool not spawned (5.548 → 5.660 ms mean of 3×500 frames), and they are active only during a settle. **Ambiguity cost: zero.** `portrait::sync_paperdoll`/`sync_inspect_booth`/`sync_petdoll_booth`/`sync_stable_booth` were four identical wrappers around one `sync_body_booth` call, each paying its own ~130 `Transform` pairs; they are now one `sync_body_booths` that drives the pool too, and `UPDATE_ACTIONABLE_CEILING` **fell 5,581 → 5,194**. `UnitPaneBooths` names only pairs `PortraitImages`/`BoothPanes` already made, and `net::GuidIndex` names none. Tests: `a_named_pane_keeps_its_window_booth_while_addon_panes_fill_the_pool_and_the_first_past_the_cap_draws_nothing` (replacing the row above's `a_named_model_pane_samples_its_booth_and_an_unclaimed_one_draws_nothing`), `a_hidden_unit_pane_frees_its_pooled_booth_for_the_pane_the_cap_refused`, `a_pane_frames_through_the_raw_camera_index_set_camera_installed`, `a_unit_panes_camera_is_set_cameras_index_over_set_units_default`, `a_unit_pane_extracts_the_guid_it_pinned_or_rereads_a_token_that_named_nothing`. Image evidence: `WOW_PORTRAIT_TEST` now bakes into `UNIT_PANE_SLOTS[0]` through camera 0 beside the paper doll's camera 1, so `WOW_BOOTH_DUMP=unitpane0:<png>:6` dumps the two side by side — a bust and a full body off one model |
| 3D unit portraits on an addon's own `PlayerModel` pane — **animated**: the pool spends a shared render *rate* | done — supersedes the `PaneLife::Still` deviation the row above took, which is now withdrawn | **The row above shipped them frozen and said so**; this closes that deviation. A `<PlayerModel>` is a live model (`0x76d680`) and the reference's never stopped moving, so a still is visibly the wrong thing in a unit frame. Every pane booth now bakes `BoothMotion::Loop` (`portrait::PaneLife::motion`, which no longer has a frozen arm) and the nine round portraits keep their still, because a round portrait *is* a still (`0x524f60`). **What the still was bought with, measured rather than assumed.** The cost of a live pane here is not the draw the reference paid: every pane is its own off-screen camera, and bevy's `check_visibility` sweeps the whole visible population once per *active* view before the render world extracts, queues and encodes a pass for it. Measured at 256² against the `ui-unitframes` capture's 14.9 k-entity outdoor scene (release, Ryzen 7 7800X3D / RX 7900 XTX, `WOW_FPS_PROBE=3000` + `WOW_FPS_JOURNAL`, nine content booth cameras forced active against the same build with none): **+38 µs of GPU, ~0.4 ms of process CPU across all threads, ~60-90 µs of main-thread CPU and ~0.1 ms of wall frame time, per camera-frame**. The GPU figure is tight (0.570 → 0.910 ms, every repetition); the CPU figures scatter ±25-50 % run to run. Eight of those every frame — what `PaneLife::Live` for the pool would mean — is **~0.8 ms of frame time and ~3.2 ms of process CPU a frame at any frame rate**, and it grows with the frame rate, which is the wrong direction for a 36-point portrait box. **So the pool spends a rate, not a camera per pane per frame** (`PaneLife::Paced`): `boothPaneRate`, benilla's own CVar, is **60 pane renders a second shared between the panes actually drawn** — one portrait up animates at 60 Hz, the usual player+target pair at 30 Hz each, four at 15, the full eight at 7.5, and a pane can never render faster than the client draws frames. The whole feature therefore costs the same at 20 fps as at 300 and the same with one portrait up as with eight: **2.3 ms of GPU, ~24 ms of process CPU and ~4.5 ms of main-thread CPU a second**, which at 144 fps is **+0.016 ms GPU, +0.17 ms process CPU and +31 µs of main thread a frame** — about a twentieth of what full-rate live would have cost there. `boothPaneRate 0` freezes the pool back to the still. **Between renders the camera sleeps and the rig parks**, and that is what makes a coarse cadence look like animation rather than slow motion: `AnimParked` holds the *pose* while the sequence clock keeps running (`benilla_world::rig_anim`, whose `parked_rig_freezes_bones_only` is exactly this property), so each wake lands on the pose the absolute clock says. The clip plays at the rate the artist authored; only the sampling is coarse. The park and the wake are the same edge `gate_booth_cameras` already drove, so no second system and no new resource: **ambiguity cost zero**, `UPDATE_ACTIONABLE_CEILING` unmoved at 5,194. **The eight ticks are staggered** by each drawn pane's rank in the cadence (`portrait::pool_pace_phases`) — rank and not slot index, because the period shrinks with the pane count, so a fixed eighth-of-a-period offset would land three panes' renders inside one frame and idle the next five. Above the budget's own rate no frame ever wakes more than one booth camera. **Item emitters stay off a paced pane** (only `PaneLife::Live` spawns them): a booth that renders one frame at a time has its emitters frozen in between, so a weapon glow would crawl instead of running, and through the camera-0 bust a unit frame asks for it is out of frame anyway. The four stock window panes keep `PaneLife::Live` with their emitters. Tests: `eight_pooled_portraits_spend_the_same_render_budget_as_one_at_any_frame_rate` (the budget, the even split and the stagger, over 20/60/144/300 fps × 1-8 panes), `a_pooled_unit_pane_animates_at_the_pools_rate_where_a_window_pane_runs_live` (the policy: pooled ⇒ paced ⇒ looping and emitter-less; stock ⇒ live), `a_zero_pane_rate_freezes_the_pool_instead_of_running_it_slowly`, `a_stalled_frame_owes_the_pool_one_render_and_not_the_whole_backlog` (phase-locked, so a hitch is not paid back as a burst), and `cvars::tests::registered_defaults_mirror_the_code_truths` welds `boothPaneRate`'s registered 60 to `PaneRate::default()`. Image evidence: `WOW_PORTRAIT_TEST` now bakes its two *pane* slots looping, as both are live panes in production, so `WOW_BOOTH_DUMP=unitpane0:<png>:<secs>` at 6 s and at 12 s are two different poses of the same model (MAE 34.6 over the 256² target, 54 % of pixels moved) where before they were identical |
| A unit pane's `SetModelScale`/`SetPosition` on a display with **fewer than two cameras** | todo — the branch where the factors do not cancel | Named by the row above rather than guessed at. Where the installed camera index names an authored camera the reference publishes it through the same scaled root (`0x718960`), so `SetModelScale` and `SetPosition` cancel and ignoring them is exact. Where it does not — a display with no `cameras[1]`, or any index past the file's table — the fixed pane rig (`0x7ac930`) sits *outside* the model and would see both; `framing::pane_root_scale_at` already applies `pane_model_scale(display_aspect)` there, and the two Lua factors would multiply into it. Not built because nothing in the bundle exercises it: pfUI calls neither verb on the unit leg (only on the file leg, `api/unitframes.lua:2030-2033`, which `ui_models` serves), the four stock body panes call neither, and `SetPosition`'s unit ladder for a booth (`0x76d1a0`'s `pos · layoutScale`, in model units) is only written down for the *ortho* leg — adopting it for a perspective booth with no caller to check against would be a guess that looks like a feature. The place is `framing::pane_root_scale_at` plus a root translation in `sync_body_booth`'s pose block |
| `GetPlayerGuid()` / `IsPlayerGuid(guid)` | done | `compat/classic_api/unit.rs`, beside `UnitGUID`, off the same `Model::unit("player")` read so the three cannot disagree. **Not DLL exports**: ClassicAPI ships them as two lines of its own embedded Lua, which `strings ClassicAPI.dll` quotes verbatim — `function GetPlayerGuid() return UnitGUID("player") end` and `function IsPlayerGuid(guid) return guid == GetPlayerGuid() end`. Built in Rust rather than as a Lua chunk, since `benilla-ui` holds no persistent Lua `Function` handles (`LUAI_MAXCSTACK`). **Found by firing nampower's aura events into pfUI**: every handler of `AURA_CAST_ON_*` and `DEBUFF_*_OTHER` in this install calls one of them *unguarded* on the line it needs a caster — `libs/libdebuff.lua:1143`, `:1256`, `:1407` and `modules/innervatecall.lua:66` — so with these nil each event raised a Lua error and the handler's whole body was skipped. A dead feature made noisy instead of working is the same mistake in the other direction; the discrimination test for this renames `GetPlayerGuid` and watches the debuff-event transcription go silent. A unit *token* answers false from `IsPlayerGuid`, as upstream's `==` against a GUID string does |
| `GetInventoryItemRepairCost` (restated) — **built; the earlier decline rested on a false premise** | done | The row above declined it because "1.12 computes repair cost **server-side only** and the client never receives or derives a per-item figure". That is wrong twice over, and the second refutation is in the reference itself. (1) This tree already had the arithmetic: `ui_merchant::item_repair_cost` is the reference's `0x4faf30` over `benilla_formats::DurabilityTables` (`DurabilityCosts.dbc` × `DurabilityQuality.dbc`), and `repair_all_cost` already summed it across the equipped slots and the bags for `GetRepairAllCost`. (2) **`GameTooltip:SetInventoryItem(unit, slot)` returns the per-item repair cost as its third value in stock 1.12** (`0x532ee0`), and stock `PaperDollFrame.lua` prints the "Repair Cost" line off that return under `InRepairMode()` — no packet is involved at any point. What 1.12 lacks is only a *slot-keyed getter*; the figure itself was always client-side, and benilla's own third return had been hard-wired to 0 on the same mistaken belief (now live, so that stock line works too). Upstream confirms the shape and the one-helper design: ClassicAPI's `src/item/RepairCost.cpp` says in as many words "Matches the third return value of `GameTooltip:SetInventoryItem`", and the same helper backs `C_Container.GetContainerItemRepairCost` and the engine's `RepairAllCost` (`0x4fbd60`). **Shape:** one number, always — `0` for an empty slot, an item with no durability, a fully repaired one, or anything neither weapon nor armor, because upstream forwards 0 "because the caller asked 'what's the repair cost' and 0 is a meaningful answer". Deliberately *not* `GetInventoryItemDurability`'s three-case discipline: that one answers **nothing** for an empty slot because its callers branch on `if cur and max then`, where this one's callers *sum* (`pfUI/modules/panel.lua:417` adds `(GetInventoryItemRepairCost(id) or 0)` across the band). A non-number raises the usage error upstream raises; a slot below 1 answers 0. **Feed:** a new `InvSlotView::repair_cost`, computed in `ui_char.rs`'s `slot_view` by calling `item_repair_cost` itself rather than copying the arithmetic — a quote that disagreed with the vendor's bill would be a bug no caller could detect. **Cost:** nothing per frame. `feed_char` is edge-gated and a slot's cost can only move when its item, its template or the discount does; measured at **+2.0 µs per gate opening** in the worst case (12.9 µs vs 10.8 µs for a whole `feed_char` with all 19 slots worn and damaged, release). Outside the gate the only new work is the discount, which short-circuits on `MerchantOpen::vendor` being `None`. **Ambiguity: zero** — the one new pair (`feed_char` ↔ `close_npc_session_out_of_range<MerchantOpen>` on `MerchantOpen`) is declared away with `.after`, which is also the right order: walking out of a vendor's range must put the list price back in the frame the window shuts. **Discount:** the fed number carries the open merchant's price discount (`0x4faf8a`) and the full list price with none open — not a fallback but `0x4faf30`'s own behaviour, which takes a discount only once it resolves the merchant guid, and which upstream states for this very function ("outside a vendor interaction the engine short-circuits the discount path and we get the raw base cost"). So pfUI's panel tooltip, read away from a vendor, quotes the full price; read at a repair vendor the player is Honored with, it quotes the 10% less that vendor will actually charge, and the merchant window's own rows and `GetRepairAllCost` move with it because all three are this one number. The player is never under-quoted — a discount only ever takes money off — and the figure never disagrees with the bill. Not built alongside: `C_Container.GetContainerItemRepairCost`, which is now unblocked for the same reason and needs only the same field on `ContainerSlot` (it would feed `GameTooltip:SetBagItem`'s third return too, still 0) |
| `IconDataProviderMixin` + `IconDataProviderExtraType` + `IconDataProviderIconType` + the four `Get*MacroIcons` mutators + `CreateAndInitFromMixin` (restated twice as todo) — **built; the enumeration was reachable and cheap, and the enum values were readable** | done | The two rows above were right that the constant alone fixes nothing and wrong on both blockers behind it. **Blocker 1, "the mixin needs an icon catalog this VM has no feed for at all":** it has had one all along — `Model::macro_icons`, loaded once per VM by `ui_macro::load_icon_catalog` from `benilla_formats::load_macro_icons`, which walks the chain's `(listfile)` union. **Measured on this install:** the walk is 102,144 names in **471 ms** (release) and is *already paid* for 1.12's own `GetNumMacroIcons` chooser; classifying all three lists out of it is **1.4 ms**. The only half that was missing is the `INV_*` item bucket 1.12's `BuildMacroIconList` filter throws away — **2,384** entries against **670** spell ones, about **100 KB** resident and **~1 ms** of already-done I/O, in the same single walk (`load_macro_icon_catalog`). A picker therefore shows **3,054** icons on this install (1 question mark + 669 spell + 2,384 item), verified end to end against the real catalog: constructing the provider is **447 µs**. **One real cost had to be fixed, and it is upstream's own shape, not ours.** pfUI's search box re-walks the whole catalog per keystroke, calling `GetNumIcons` *and* `GetIconByIndex` per icon, and the mixin calls `table.getn` on both buckets inside each — where 1.12's `table.getn` is `luaL_getn` (`0x6f5050`, faithfully reimplemented in `lua50/table_size.rs`), which **counts `rawgeti` from 1 to the first nil** when no size is remembered. Measured: **95 µs** per `getn` on the 2,384-entry bucket, so a keystroke cost **315 ms** — about eight frames. The four mutators now record 5.0's remembered size with `table.setn` after appending, which is what 5.0's own `table.insert` does on every append and what `luaL_setn` exists for, so `getn` takes its first branch: the same keystroke is **3.0 ms**, a 103× drop, with the mixin's body unchanged and nothing visible added to the caller's table (the size goes to 5.0's weak registry store). `each_enumeration_records_the_remembered_size_so_getn_is_not_a_walk` pins it as a mechanism, not a duration — a stored size wins over the walk, so blanking the last slot must not change `getn`. **Blocker 2, "the values cannot be taken from the one call site":** true of the call site, but upstream publishes the file — ClassicAPI ships `IconDataProviderMixin` as *addon Lua*, `AddOns/!!!ClassicAPI/Util/IconDataProvider.lua`, whose own comment states `EnumUtil.MakeEnum("Spell", "Item")` is `{ Spell = 1, Item = 2 }` and which spells `IconDataProviderExtraType` as `{ Spellbook = 1, Equipment = 2, None = 3 }`. **Blocker 3, the `loose`/`mpq` axis** `macro_ext.rs` called unanswerable: answered rather than dodged. benilla reads only the archive chain and has no loose-file icon scan anywhere, so `loose` is empty **by construction**, not by under-reporting — and the one consumer cannot tell either way, because the mixin calls all four and concatenates (upstream's own note records that its tags were once inverted and nobody noticed for exactly that reason). All of it lives in `compat/classic_api/macro_icons.rs`: the four mutators in Rust over two new `Model` buckets, and the mixin as a Lua chunk over the existing `CreateFromMixins`, as `item_location.rs`, `item_mixin.rs` and `pools.rs` already do. **Shape, which a test caught:** bucket entries are **uppercase basenames** with no `Interface\Icons\` prefix and no extension (`"INV_SWORD_25"`), because the mixin concatenates `INTERFACE\ICONS\` itself — deliberately *not* 1.12's `GetMacroIconInfo` shape, which is the full path. And the bucket key strips at the **first** dot (upstream's `NormalizeIconKey`) where 1.12's chooser strips at the last: the first pass of this work got that wrong and `Ability_Druid_Mangle.tga.blp` came out as `ABILITY_DRUID_MANGLE.TGA`, which `the_icon_picker_buckets_are_bare_uppercase_stems_that_all_resolve` failed on. That test also checks every entry resolves through `benilla_assets::sprite_candidates`, so no grid cell draws as a white square. **Two deliberate deviations**, both documented in the file: the question-mark seed upstream hooks into 1.12's *engine* list is not copied (1.12's own `BuildMacroIconList` does not have it, and the mixin puts the question mark at index 1 itself), and the `Equipment` extras are the **worn** items via `GetInventoryItemTexture("player", slot)` — which is what upstream's own file header describes the type as — rather than upstream's broader `GetInventoryItemsForSlot` walk, which needs an `InventoryType`→slot mask, the `SMSG_SET_PROFICIENCY` table benilla does not track and packed `ItemLocation` keys. The extras are a deduped seed prepended to the full list, so the narrower set costs a caller nothing it cannot reach by scrolling, where the alternative was the Equipment branch raising on a nil global — the half-feature this row was declined twice to avoid. **Cosmetic gap, not built:** `CreateIconPicker` labels its filter dropdown with `ICON_FILTER_ALL`/`ICON_FILTER_SPELL`/`ICON_FILTER_ITEM` and `ICON_SELECTION_TITLE_CURRENT`, later-client GlobalStrings nothing here defines; they read nil, so those three labels draw blank and nothing raises. Inventing English for them is a GlobalStrings question, not this one |

## VanillaUtils.dll — inferred (bespoke OctoWoW build), lineage now partly confirmed

| Area | Status | Notes |
|---|---|---|
| `vanilla1121_*` function family | inferred, upgraded | `Vanilla1121_functions.cpp`/`.h` is a REAL file in the open-source `MarcelineVQ/UnitXP_SP3` repo — `vanilla1121_getVisiableObject`, `vanilla1121_inCombat` and others really exist there under those exact names, not a VanillaUtils-only invention. But in that repo they're native C++ helpers the hook calls internally (no `lua_register`/`luaL_Reg` for them found in its `dllmain.cpp`), not confirmed as Lua-callable globals there. This install's own export table showed a Lua-registration wrapper set (`lua_pushnumber`/`luaL_openlib`, …) alongside these names, which is still the best evidence they *are* exposed to Lua on this specific build — a different/extended fork from the mirror checked. Net: the names and rough purpose are now confirmed real; whether they're Lua globals here, and their exact argument order, are not |
| `UnitGUID(name)` | todo, inferred | directly exported in the mirror too, name→GUID; behaviour (what "name" matches — a currently-visible unit, a roster entry, something else) still unconfirmed |

## VanillaHelpers.dll (this build) — inferred (differs from upstream `isfir/VanillaHelpers`)

| Area | Status | Notes |
|---|---|---|
| `SetUnitBlip(unit[, texture[, scale]])` | done | `compat/vanilla_helpers.rs` queues a `BlipOverrideRequest` keyed by the unit's resolved GUID (so SuperWoW's raw-GUID and `markN` tokens work here too); `minimap::blips::drain_blip_overrides` folds it into the `BlipOverrides` resource, loading the named texture once through `minimap::blip_texture_path` (FrameXML-style `Interface\…` spelling → an `mpq://…blp` asset path); `emit_party_dots` draws the override's whole texture at its own scale instead of the party atlas cell. A one-argument call clears the override. 1.12 has no generic per-unit minimap blip at all — only party members, tracked/quest dots and landmarks — so party dots are the only unit blip there is to retarget |
| `SetObjectTypeBlip(type[, texture[, scale]])` | partial | the Lua side is built and queues an `ObjectType(u32)` override keyed by `AreaPOI` icon id (the only per-landmark key this client carries), and the override map stores it — but `emit_landmarks` does not read it yet, so the call is currently inert. What "type" actually indexes in the real DLL is unpublished (plausibly its own landmark-category enum, not `AreaPOI.icon`); wiring the draw site to a key whose meaning is a guess would make a wrong override silently paint the wrong landmarks, so the read is deliberately left for a pass that can check it against the real mod |

## Minimalist-AutoLogin-Plus (`Stormhand-dev/Minimalist-AutoLogin-Plus`) — a GlueXML addon, rebuilt natively

Not a DLL, and the reason it is in this document at all is the same as theirs: **it cannot be
installed.** It is Lua under `Interface\GlueXML\`, and this client runs no glue Lua. The login,
character-select and character-create screens are Rust (`login/`, `char_select/`, `char_create/`);
the only glue files read are read as *data*, not script (`glue_strings.rs` text-parses
`GlueStrings.lua`, `challenges.rs` text-parses `ChallengeList.lua`). There is no glue VM, no
`GlueXML.toc` loader and no glue widget surface to build frames against, so dropping the mod's
files into `Data/Interface/GlueXML/` leaves them inert — nothing opens them. Its behaviour is
rebuilt in `autologin.rs` instead.

| Area | Status | Notes |
|---|---|---|
| Remember the password | done | `autologin.rs` holds the store; `login::enter_login` fills both boxes when the screen comes up. **Fill only — deliberately not automatic.** The mod submits the form and enters the world for you; both halves of that were built here and then cut on the player's own call. An auto-login that lands you in the world is a client you cannot get a screen out of without knowing a trick, and the saving over a filled box is one click. The fill is gated on the tick as well as on the stored text, so unticking stops it in the same frame rather than waiting on the secret being cleared |
| Credential storage | **superseded: encrypted** | `benilla-config/autologin.toml`, written `0600` by `local_state::write_atomic_private` (asserted, including that it tightens a file that was already world-readable). Plaintext is the mod's own behaviour and its README's own warning; `0600` protects it from other users on the machine and from nothing else — anything running as this user can read it, and it lands in any backup of the folder. Its own file rather than a key in `config.toml`, because that is the file a player pastes into a bug report. Written **on the roster**, not at submit: a roster is the proof the credential was accepted, so a typo is never persisted and refilled on every later launch. Unticking the box **clears the password**, since that is the only way to get it off disk from inside the game. **Superseded at the player's explicit request:** the box now writes `password_encrypted`, the authenticated blob of `crate::credential`, through `AutoLogin::remember`; `migrate_plaintext` upgrades an existing plaintext file in place on the next launch, and `effective_password` still reads the old field so a file written by an older build logs in once before it is upgraded. What changed is the file; what did not is the threat model — see the credential section below for what the blob answers and what it cannot |
| Remember the last character | done, **selects only** | `char_select::apply_roster_policy`. The roster is always shown — nothing enters the world for the player. Remembered by **name**, and it outranks 1.12's own `lastCharacter` CVar, which is not a preference but a correctness fix: that CVar is a row *index*, and this screen now lets the player reorder rows, so after a reorder the index names whoever moved into that slot. A name survives reordering; an index does not. A remembered character who is gone (deleted, or another realm) falls back to the stock row. Recorded in `select_input` — the path that means *the player chose* — so a reconnect's re-pick and the env fast paths cannot rewrite it |
| Login screen cleanup | done | `cleanLoginScreen` (CVar, default **1**) drops the Blizzard logo, the `BLIZZ_DISCLAIMER` line and the version string. That is the whole of what this screen had left to hide: the rest of the mod's list — the Turtle website/armory/forum/Discord/Reddit buttons, Credits, Cinematics, Terms of Use, ESRB, Manage Account, Community Site, server news — **this screen never drew**, because `login/` keeps only what logging in needs (its module doc says so, and predates this work). Read once in `enter_login` and latched on `LoginForm`, not read per frame where it is used: the latter measured at six undeclared orders against every writer of the registry, for a value that cannot change while the screen is up (there is no console at the login screen to write it from) |
| Character row reordering | done | The mod's per-realm `order` + `char_buttons_locked`. `autologin::apply_order` is a permutation by construction: saved names first in their saved order, anything unmentioned keeping its server order on the end, so a character created since the order was saved appears at the bottom rather than vanishing and one deleted elsewhere is skipped rather than leaving a hole. Applied in `apply_roster_policy` *before* anything indexes a row, because the remembered-row CVar, `select_created_by_name` and `WOW_CHARSELECT_PICK` all mean rows as the player sees them. The arrows fold into `refresh_list`'s existing row loop (they are `Button`s carrying a `SelectAction`, so that query already walked past them) rather than a second `Visibility` writer. A move keeps the selection on the *character*, not the row — swapping rows under a highlighted name would silently re-aim Enter World at its neighbour |
| The button's label | deviation | The mod labels it `Unlock Characters` always and greys the caption while unlocked. Here it is **`Reorder Characters`**: a greyed caption is this screen's own word for *disabled* (`glue_hilights` greys exactly that way), and a fixed label is wrong in one of its two states. Naming the mode is accurate in both and needs no retitling — which would mean rewriting the caption's outline copies too. The arrows appearing on the rows are the state readout |
| Multi-account manager | not built | The account button column, per-account labels, autocomplete-by-letter on the username field, add/remove/reorder of accounts, and the per-account character memory that goes with them. One account is what the store holds; the rest is a second screen's worth of UI. Scoped out deliberately, not blocked |
| The mod's own persistence | n/a | It stores through SuperWoW's `ImportFile`/`ExportFile`, which are themselves unbuilt here (the SuperWoW "new functions" row above). This writes its own file instead, so the dependency never arises |


## pfUI-for-ClassicAPI — the measured gap, and what of it actually fires

This pfUI build is written **against ClassicAPI**, so "1.12 does not have it" is not by itself a
reason to decline a function: the realm ships that DLL and the addon is entitled to the surface.
Three earlier declines were wrong on exactly that ground and are now built (`UnitSpellHaste`,
`Item:CreateFromItemLink`, `C_ChatBubbles`).

**Method.** Every `C_<Namespace>.<Member>` and bare `Upper(` call across the installed AddOns
(1,784 candidates) was extracted statically and then resolved against a **loaded** VM — so what is
left is what an addon can actually reach and find missing, not what a grep imagines. 37 of the
misses are `C_*`, and **all 37 are in ClassicAPI's own surface** (`docs/classic-api-functions.md`;
`C_EncodingUtil` spells its pair `EncodeBase`/`DecodeBase`, which is why a naive match drops it).

**Reachability is the thing that matters, and most of the 37 are unreachable.** pfQuest guards
every one of its ClassicAPI calls (`if not (C_TaxiMap and C_TaxiMap.GetTaxiNodesForMap) then`,
and likewise for `C_SpellBook.GetSkillLineRank`, `C_Map.GetAreaTriggerInfo`,
`C_Item.RequestLoadItemDataByID`). Two whole pfUI modules gate themselves off at load and so can
never reach the members they would otherwise call: `equipmentmanager` returns at its first line on
`if not C_EquipmentSet`, and `loothistory` only runs `FullUpdate` while its frame is shown, which
needs `LOOT_HISTORY_FULL_UPDATE`/`ROLL_CHANGED`/`ROLL_COMPLETE` — three events this client does not
fire. **A note in an earlier revision of this file claimed `Item:CreateFromItemLink` "will raise on
a loot roll"; it does not, because that module never runs.** The call path was never checked.

| Area | Status | Notes |
|---|---|---|
| `C_ChatBubbles.GetAllChatBubbles` | done, **empty list** | The one genuinely hot absence the sweep found, and reproducible: `pfUI.bubbles:ScanBubbles()` raised `attempt to index global 'C_ChatBubbles'`, and pfUI runs it the frame after **every** `CHAT_MSG_SAY`/`YELL`/`MONSTER_SAY`/`MONSTER_YELL` within earshot. Answers an empty list, which is the truthful count rather than a stub: bubbles here are drawn natively by `chat_bubble.rs` as a 2-D world overlay, exactly as the reference's own `CGChatBubbleFrame` is, so there are no Lua frames to hand over and no regions a script can repaint. The cost is that bubbles keep this client's look instead of pfUI's; making them addressable (a frame + texture + `FontString` per live bubble, kept in step with the native spawn/stack/expiry rules) is the real fix and is not built |
| `C_Spell.GetSpellDispelType` | done | The other hot one: `libs/libdebuff.lua:379` calls it once per debuff while walking aura slots 33-48, so it runs for every debuff on every scanned unit — continuously, in combat, which is when the debuff display matters. Backed by widening [`SpellLookup`] with `Spell.dbc`'s `Dispel` column, the route this file already named for the `C_Spell` predicates; `SpellDisplay` carried it already, so nothing new had to be parsed. Answers the **raw id**, not `SpellDispelType.dbc`'s localized name, because the caller keys its own `dispelTypeMap` on the number and a name would make a localized realm answer something that table cannot match. `0` ("no dispel class") answers **nil**, which the call site's `if dispelId and dispelId > 0` already reads the same way. The book arm takes it from the probe alongside `reagents` — a spellbook slot carries neither column |
| `Item:CreateFromItemLink` | done | Keyed on the id inside the link, which is the same object here: every `ItemMixin` getter reads a `C_Item.*ByID`, and a 1.12 link carries nothing per-item beyond the id — no bonus ids, no modifiers, no scaling — so the link and id forms cannot disagree about anything the mixin exposes. A link naming no item (nil, a spell or quest link, a malformed string) yields an **empty** item rather than raising, which is what the call site's own `if item and not item:IsItemEmpty()` expects. Built for correctness, not for a live error: its only caller is the loot-history module, which never runs |
| `UnitSpellHaste` | done, **0** | 0 is the *answer*, not a stub: 1.12 has no haste stat anywhere — not a `UNIT_FIELD`, not an item mod, not a spell modifier — so every unit genuinely has 0% spell haste and the real DLL has nothing else to read either. pfUI's player module calls it unguarded into a `string.format("%.1f%%")` (`modules/player.lua:87`) whenever its haste readout is on, so the absence raised once per 0.25s tick and took the neighbouring "+N SP" line down with it |
| `C_EquipmentSet` (13 members) | not built, **unreachable** | 1.12 has no equipment sets at all. pfUI's manager is a backport of the 4.3.4 `GearManagerDialog` and gates itself off at its first line (`if not C_EquipmentSet or not C_EquipmentSet.CanUseEquipmentSets() then return end`), so the module never loads and none of the 13 is ever called — verified in a loaded VM (`pfUI.equipmentmanager` is nil). Building the read half to answer "no sets" would load a manager that can only ever show an empty list; building the write half means a persisted set store and an equip sequencer, which is a feature, not a compat shim |
| `C_LootHistory` (4 members) | not built, **unreachable** | Needs the three `LOOT_HISTORY_*` events as well as the namespace — the module's `FullUpdate` returns unless its frame is shown, and only those events show it. The data is on the wire and already parsed (`LootStartRoll`/`LootRoll`/`LootRollWon` carry the roll key, the roller, the dice value, the vote and the winner), so a real history is buildable: accumulate per `(looted_target, item_slot)`, resolve roller GUIDs to name/class, fire the three events. A feature worth doing on its own, not an error to patch |
| `C_TaxiMap.GetTaxiNodesForMap` — **the flight-master layer** | done | `compat/classic_api/taxi_map.rs` over a new feed, `ui_taxi/map_nodes.rs`; supersedes this member in the "not built" row below, which stands for the rest of its list. The guard that row cites is exactly why it mattered: pfQuest *is* guarded, so the absence produced no error at all — `pfDatabase:SearchFlightNodes` returned an empty table, the user's "flight masters" option stayed ticked, and nothing was ever drawn. Same silent-by-construction shape as `C_Map.GetAreas` above, and the same consumer. This install's pfQuest has **deleted** its shipped `pfDB.meta.flight` table for this call (`db/meta.lua:181` is a stub whose comment says the data "always comes live from the client (ClassicAPI)"), so there is no fallback behind it. **The contract is half read off the DLL and half off the caller**, and the file says which is which: `C_TaxiMap`, `GetTaxiNodesForMap`, `nodeID`, `faction`, `reachable`, `state` and the `FlightPathFaction`/`FlightPathState` enum names are all in the bundled `ClassicAPI.dll`'s string pool; the `areaID`/`mapX`/`mapY` triple is **not** separately visible there (the pool holds one copy of each string and `C_Map.GetAreaTriggerInfo` already uses all three), so for those the authority is `SearchFlightNodes` itself — it reads all six fields, gates on `if show and node.areaID and node.mapX and node.mapY`, and feeds the pair into `pfMap:AddNode` as `meta.x`/`meta.y`, which `UpdateNodes` divides by 100, so they are **percentages of the zone rect**. Faction comes from the two `MountCreatureID` columns, which is the reference's own gate (the taxi window asks for the mount of the player's half, `0x4a2650`): one column filled is that faction, both is neutral. A row with **neither** is reported neutral rather than dropped, deliberately and with the reason in the code — OctoWoW ships custom flight points and a custom row with unfilled mount columns is still a flight master standing in the world, so a stray icon is the cheaper mistake than a missing feature; the seed logs that count so the choice stays visible. Zone and percentage come from `WorldMapUiData::zone_at`, which asks `map_proj::zone_uv` for containment rather than comparing rects itself, so a node is only ever attributed to a zone whose own map the window would place it inside; where rects nest (every city sits inside its parent zone) the **smallest** wins, because a flight master in Ironforge belongs on the Ironforge map, which is also the map the player is looking at while standing there. 1.12 has no verb that asks this question, so that choice is ours and is labelled as such. **Seeded before the interface loads**, beside the world-map catalog and after it (it reads those rects), and the deadline is tighter than file scope: pfQuest replays its saved tracking selections once on `PLAYER_ENTERING_WORLD` and then calls `this:UnregisterAllEvents()` (`database.lua:131-151`), so a push one frame later is a push after the only read and the layer stays empty for the session. **Not built, each for the same reason**: `GetTaxiRoute`, `GetTaxiPaths` and `GetTaxiPathWaypoints` are `TaxiPath`/`TaxiPathNode` data, which `ui_taxi/routing.rs` loads for the window's own route search and has never pushed into the VM, and nothing in the corpus calls them; `GetAllTaxiNodes` is in the pool with no caller to read its shape against, and guessing it would be inventing a contract rather than matching one. Also absent from each node, with the reason stated in the file: `reachable` and `state`, which are session facts the open window owns (`model.taxi`, which exists only while a flight master has the frame up) — answering `reachable = false` for all 60 nodes because no window is open would be a confident wrong answer, where an absent field is a truthful "this build does not say" |
| `C_EncodingUtil` (8), `C_FriendList.SetFriendNotes`, `C_Item.GetCurrentItemLevel`, `C_Map.GetAreaTriggerInfo`, `C_SpellBook.GetSkillLineRank`, `C_TaxiMap.GetTaxiNodesForMap`, `C_Spell.IsSpellInRange`/`IsNextMeleeSpell`/`IsRangedAutoAttackSpell`/`ResetsMeleeSwing`, `C_Item.RequestLoadItemDataByID`, `C_LootHistory.*` | not built | Each either guarded by its caller (all of pfQuest's) or behind a user action not yet taken: `SetFriendNotes` on editing a friend note, `SerializeJSON` on sharing a config, `GetCurrentItemLevel` behind `if ShaguScore` (an addon not installed), the hunter range pair on a hunter's bar. None raises in ordinary play as installed |


## The offline UI-load harness — why 349 tests were failing, and what is fixed

Found while answering "is anything broken?": `cargo test` with `WOW_DATA` set had **349 failures**
that had been invisible, because every data-backed test silently *skips* without that variable and
no routine run set it. None was a product fault — the live client's own log has no loader errors at
all — but they meant a large slice of the integration suite was not actually exercising anything.

Two of the four causes are fixed, **349 → 286**.

| Cause | Count | Status |
|---|---|---|
| A harness loads one XML on its own, so a template an earlier TOC entry defines is simply absent. The loader only **warns** and builds the frame without its art, so the test passes against a different, artless frame than the client draws — a silent wrong answer, not a failure | 120 (`StaticPopup.xml` ← `MoneyInputFrameTemplate`, `ItemButtonTemplate`) + 52 (`PaperDollFrame.xml` ← `UIDropDownMenu_Initialize`) | **fixed** — `test_ui.rs`'s new `PREREQS` table, with the reference TOC's own line numbers as the proof of order, and a per-VM ledger so a prerequisite seated once is not built twice (these files are not virtual-only; each builds concrete frames too) |
| The realm's own FrameXML reads a **player at file scope** — `Turtle_ShopUI.lua:28` and `Turtle_TransmogUI.lua:17` both run `strlower(UnitRace("player"))` in their main chunk, which raises on nil and takes the file with it, leaving every `*_OnLoad` it defines undefined and each of its frames failing in turn. Six errors from one missing unit | 32 | **fixed** — `load_default_ui` seats a minimal `PlayerRecord`. Not a fiction: that function is only ever reached offline (tests and `addon_harness`), and in the live client FrameXML loads *on entering the world*, where a player always exists. The offline load was the one diverging from the running client |
| `FloatingChatFrame.xml` needs a deep chain — `ChatFrame`, `GameTooltip` (for `TOOLTIP_DEFAULT_COLOR`, which lives there, not in `Globals.lua`), `UIDropDownMenu`, `UIMenu`, `UIPanelTemplates`, `UIParent.lua`, `GlobalStrings.lua` for the `EMOTE<n>_TOKEN` sort | 137 | **not fixed.** The chain was walked to the end and *does* make the file load clean in isolation — but auto-seating it inside every harness made the suite **worse** (286 → 363): these are heavy files that build frames, and harnesses which deliberately use a minimal VM then fail different assertions (`SetFont` with a nil font). Reverted. The fix is per-harness seating, not a global table |
| Reference-vs-OctoWoW data assertions (`ChrRaces.dbc` row count, `AUTH_BANNED` not patched by `Localize()`, chooser catalog size) and knock-ons | the rest | **not fixed**, and arguably not bugs: the tests pin a stock chain, this install is a modified realm |

**The lesson worth keeping**: a loader that *warns* on a missing template rather than failing turns a
harness gap into a passing test that measures the wrong frame. `load_ui_strict` exists precisely to
catch that — the 120 were tests that already used it, which is why they showed up at all once the
suite was actually run with data.


## `AttackTarget` and the OctoWoW radio

| Area | Status | Notes |
|---|---|---|
| `AttackTarget()` | done | A **stock 1.12 engine global** (`0x489b50`, `reference/1.12-globals.tsv`), not a ClassicAPI backport — it was simply never built. pfUI's nameplates call it on a click that targets a hostile (`modules/nameplates.lua:1930`), so every such click raised: 48 in one logged session. Queued as `SelectionRequest::AttackTarget` and handed to **the binding's own system** rather than acted on where it lands — the reference reaches one body from both this global and the Attack action (`0x612df0`), and that body is `ui_action::drain::attack_target_binding`, which already owns the attack-actor refusals, the engaged/not-engaged toggle and the "no target, acquire the nearest" arm. A second copy beside it would be a second opinion about when a swing is legal |
| OctoWoW radio — the minimap button | done | The realm bakes **two** files into its FrameXML that benilla's manifest did not carry: `EverlookBroadcastingCo.xml` (its TOC 129) builds the `EBC_Minimap` boombox button, and `OctoRadioPlaceholder.lua` (146) hangs the station menu off it. The order is load-bearing, not cosmetic: the radio file's first line is `if not EBC_Minimap then return end`, so with only the second one the UI silently does nothing. Both added in the chain's own order; verified in a loaded VM that the button exists, is shown, and that the radio hooked its `OnClick` |
| OctoWoW radio — the audio | done | `sound/http_stream.rs`. The fetch is a **plain socket**, not an HTTP crate: the endpoint was probed first and answers `200`, `Content-Type: audio/mpeg`, `Connection: close`, no redirect, no chunked encoding, body a bare MPEG frame stream over plain `http://` — a dozen lines of `TcpStream` against a client that otherwise makes no network calls and has no HTTP dependency to reuse. `Icy-MetaData: 0` is sent so the server does not splice title metadata between frames, which would decode as a click every few seconds and look like a decode bug. **kira's own symphonia decoder cannot carry this**: it reads `n_frames` out of the codec parameters and fails `UnknownSampleRate` when absent (`streaming/decoder/symphonia.rs:45`), which is what a live stream reports — so `RadioDecoder` implements kira's public `Decoder` trait instead, keeping the sample rate (MP3 carries it per frame header) and answering the duration itself as a day at the stream's own rate. No kira patch. Verified against the live station end to end: 44.1 kHz, 46,080 real frames decoded, peak amplitude 0.486. Deliberately absent, each a named failure rather than a wrong stream: TLS (the `https://` DBC rows have plain-http twins), redirects, chunked bodies, reconnect-on-drop. One cost worth knowing: the connect is spent on the **main thread**, because kira probes the source while building the sound — bounded at 2s so a dead station is one stutter, not a freeze |
| OctoWoW radio — the Off button | done, **a deviation** | Off is a bare `StopMusic()` (`OctoRadioPlaceholder.lua`'s `TurnOff`). The reference's `0x460450` never touches the zone track `[0xb06cc4]` on its NULL arm, and ordinarily neither does this — a `StopMusic` must not silence zone music. But the radio arrives as `SMSG_PLAY_MUSIC`, which lands on *that* slot here, so Off stopped a slot the radio was not in. **Where the reference puts server-pushed music is recorded in `zone.rs`'s own header as untraced**, so the slot it lands on is this client's assumption rather than a transcribed fact, and the realm's addon is the evidence against it: its comment says zone music "stays on and resumes", which only holds if `StopMusic` reaches the radio and nothing else. Narrowed to a *live stream* on the slot, so an ordinary event track — which no Off button exists for — is untouched, and the zone pump is rearmed so zone music comes back. Both halves pinned by tests; reverting the narrowing fails the first and not the second |
| ~~OctoWoW radio — the audio~~ (superseded) | — | A station click sends `.radio <n>` as a SAY chat command; the server answers with `SMSG_PLAY_MUSIC` naming a `SoundEntries.dbc` row whose *file* is a live HTTP stream URL. Confirmed against the real DBC rather than taken from the addon's comment: seven of them, e.g. `http://radio.octowow.st/listen/booty_bay_pirate_radio/radio.mp3`. `SMSG_PLAY_MUSIC` is already handled and the mixer already decodes MP3 (kira's `mp3` feature, exercised by `mixer.rs`'s own test against a real chain file) — what is missing is only the *fetch*: every kit path today resolves inside the MPQ chain (`Sound\Music\...`), and nothing recognises an `http(s)://` file or streams one. Needs an HTTP client dependency and a progressive feed into the music slot, since a live stream has no end to read to |


## pfUI's options panel, and two more coercion gaps

Both of the panel's "it applied but it does not look applied" complaints were the same shape: a
1.12 binding where the reference **coerces** and this client did not. Neither lost a setting —
the values round-tripped correctly the whole time, which is what made them look like persistence
bugs rather than display ones.

| Area | Status | Notes |
|---|---|---|
| `CheckButton:SetChecked()` with **no argument** | fixed | The reference reads its argument through `0x6f1c10` with a **default of 1** (`0x799c77`), so a bare call *checks*. Ours unchecked — and `button.rs`'s own comment already said so ("here a missing argument unchecks… where the reference checks for a missing one"), a known divergence nothing had reached until pfUI's config panel did. It restores every ticked box with exactly that call (`modules/gui.lua:336`), so every setting the player had on showed as off after a reload, which then invites re-ticking, which sets pfUI's `settingChanged` and demands another `/rl`. mlua folds an absent argument and an explicit `nil` into one `Value::Nil`, so the binding now reads **arity** via `MultiValue`: `SetChecked()` checks, `SetChecked(nil)` still unchecks (FrameXML passes conditions that way). Both halves tested |
| `Texture:SetTexture("r","g","b","a")` | fixed | `lua_isnumber` is the reference's gate between the path and colour forms, and in 5.0 it is **true for a numeric string**. Ours matched only `Value::Number`/`Integer` on the first argument, so a numeric string fell into the path arm and loaded nothing — every colour swatch in pfUI's panel was black until clicked, the click being the one path that passes real numbers. The swatch stores a colour as `"0.05,0.15,0.15,0.75"` and hands `SetTexture` what `strsplit` returns, which is four strings (`modules/gui.lua:188`). The trailing channels already coerced (`coerced_opt_number`) — the inconsistency was the first argument alone. A numeric second argument is required too, so a one-argument path that happens to look numeric stays a path |
| Guild "N online" before the guild pane is opened | **deviation** | Not a bug: 1.12's FrameXML never asks for the roster at login. Its only unprompted `GuildRoster()` is on a `GUILD_ROSTER_UPDATE` *while the guild pane is visible* (`FriendsFrame.lua:705-711`), so a panel addon reads 0 until something opens that pane or its own poll comes round — 60 seconds for pfUI (`modules/panel.lua:396`). Faithful, and also a minute of wrong number on every login for a count the server answers immediately if asked. Now asked **once**, on the `GE_MOTD` that vmangos sends before any roster (`CharacterHandler.cpp:558`), through the same 10 s throttle every other request takes. Armed only when no roster is held, so a mid-session MOTD edit does not re-ask |


## Minimap player arrow scale, and ColorPickerPlus's TOC

| Area | Status | Notes |
|---|---|---|
| `Minimap` player-arrow scale | fixed | The arrow is engine child 9 (`minimapPlayerModel`, `0x4ee260`), a `Model` an addon can reach and scale — pfUI's minimap module finds it by walking `Minimap:GetChildren()` for the unnamed `Model` whose model names `MinimapArrow`, then calls `SetScale` (`modules/minimap.lua:41-54`). The search worked here; what did not is that **this client draws the arrow itself**, sizing its quad from the map's side length and two constants, and never reading that child. So the setting moved nothing. The factor now rides [`QuadContent::Minimap`] as `arrow_scale`, **relative to the map's own scale** so the map is counted once, and `minimap::player_arrow_geometry` applies it to both the quad and its authored centre offset — the offset too, or the art drifts off centre as it grows. Tested on both sides of the seam: the extract carries it, and the geometry applies it |
| `ColorPickerPlus`: two "not found" warnings | **not a bug** | `ColorPickerPlus.toc`'s `## Notes:` wraps onto two unprefixed continuation lines, and a TOC line that does not start with `#` is a file entry. The reference's parser does the same thing and fails to find them just as silently; the addon loads and runs regardless (`ColorPickerPlus.lua ran`). A malformed TOC in the addon, not a loader fault — worth leaving loud rather than teaching the parser to guess which unprefixed lines are prose |


## A wgpu validation error no longer ends the session

A `pbr_prepass_pipeline` failed shader-interface validation 42 minutes into a session, right
after a `/reload` queued a burst of live pipeline specialization, and **killed the client** —
wgpu's uncaptured-error handler panics by default. One bad pipeline out of 1,635.

`gpu_errors.rs` replaces that handler: the error is logged at `ERROR` with its full text, the
resource fails, and the draw that wanted it is skipped. A missing shadow instead of a lost
session — which on a hardcore realm is the difference between a graphical glitch and a dead
character. `WOW_WGPU_FATAL=1` restores the panic for a session spent hunting one.

Distinct errors are each reported once and then tallied on a widening scale (1, 2, 4, 8…), so a
per-frame repeat neither scrolls the log away nor disappears from it. That is the one property
of the fatal handler worth keeping: you noticed.

**The underlying mismatch is not fixed and is not yet diagnosable.** The failing variant is
unidentified because our pipeline watcher logs each pipeline the frame after it first appears,
and this one was queued and failed its async compile inside the same frame — the last one
recorded is `[1634]`, the failure is `[1635]` or later. A frame-based watcher always loses that
race. With the handler non-fatal the next occurrence logs the error text itself, which names the
pipeline label and the mismatched location; that is the missing half.


## `/cal` and the keyring toggle

| Area | Status | Notes |
|---|---|---|
| `/cal` (OctoCalendar) | fixed | Another pair of **baked FrameXML components our manifest did not carry**, the same shape as the radio: `OctoCalendar\*` (7 files, which define `/cal`, `/calendar` and `/octocal` at `OctoCalendar.lua:925-928`) and **AIO** (6 files, the realm's client↔server transport), in the chain's own order — the calendar registers an AIO handler at load and queues its guild-permission request until AIO is up (`:919-920`), so AIO has to come first. Verified in a loaded VM: the slash handler exists, `AIO` is non-nil, and invoking `/cal` opens the frame without raising. Harness 15/15 clean |
| pfUI's keyring show/hide button | fixed, **two bugs** | pfUI's bag module is `GetContainerNumSlots(-2)` slots normally and `GetKeyRingSize()` when showing (`modules/bags.lua:202-203`), so hiding is exactly "the container API reports nothing for the keyring". The feed reported a real count, both arms agreed, and the button did nothing. **`num_slots` is now 0** — nothing in stock FrameXML ever calls `GetContainerNumSlots(KEYRING_CONTAINER)`, because the keyring is sized by `GetKeyRingSize`'s scan everywhere, which is only worth writing if the container API does not answer for it. **And every addressable slot is now fed**, where the old code fed only as many as a level ladder allowed: `GetKeyRingSize` is FrameXML and it *scans* — 32 `GetContainerItemInfo` calls for the highest filled slot, rounded up to a multiple of four (`ContainerFrame.lua:816-844`) — so a key in a high slot was invisible to it. The ladder itself was removed: its doc claimed stock `GetKeyRingSize` reads `UnitLevel`, and **`UnitLevel` appears nowhere in `ContainerFrame.lua`** |

**Still missing from the manifest** after this, measured by diffing the realm's `FrameXML.toc`
against ours: 27 entries across `Turtle_ArenaUI` (5), `Turtle_GuildBankUI` (2),
`Turtle_BarbershopUI` (1), `OctoToolReqTip` (2), `OctoLocale` (5, non-enUS), and one file each for
`OctoChallengeTip`, `OctoGhostGate`, `OctoRestedTooltip`, `OctoWarModeOffer`,
`OctoWowWarModeConfirm`, `RestoreBugCommand`, plus six stock-ish ones (`Globals.lua`,
`Overrides.lua`, `Hooks.lua`, `StatsFrame.xml`, `ChronoboonTimers.lua`, `SpellChatLinks.lua`).
Each is a feature that is simply absent rather than broken, and they are worth adding as a batch
with the load checked after each.


## Video settings: the Apply that never committed, and the missing resolution row

| Area | Status | Notes |
|---|---|---|
| Graphics settings not persisting | fixed | `OptionsPage_Apply` wrote each pending row's CVar and stopped. For a **latched** row — `gxVSync`, `gxResolution`, `gxWindow` — that write is *staged* in `Row::pending` and only lands on `Cvars::commit_latched`, which runs on `RestartGx` (`video.rs`). Nothing in the options window ever called it, so a latched change stayed pending for the whole session, never reached the live value, and so was never written to `config.toml` either — vertical sync looked accepted and was back on after a relaunch. `OptionsPage_Apply` now calls `RestartGx()`, which is what the reference's own video options do on Apply |
| No resolution row in the options window | fixed | The CVar, the three verbs (`GetScreenResolutions`, `GetCurrentResolution`, `SetScreenResolution`) and the monitor enumeration all existed; the window simply had no row, so there was no way to resize from inside the game. Added between Display Mode and Vertical Sync, built from the real list at `OnLoad` and backed by the **index** verbs rather than `gxResolution` directly — `GetCurrentResolution` reports the live window where the CVar is the windowed size, and in borderless fullscreen those differ |
| "benilla is running at 1080p" | **not a fault** | It was already at the monitor's full 2560x1440: `video: BorderlessFullscreen(Primary), 2560x1440 logical / 2560x1440 physical (scale 1) [wayland]`. Worth recording because the absent resolution row made it impossible to confirm from inside the game, which is how it came to be doubted |
| World tooltip rebuild raises `OnShow` | **fixed** | A rebuild for a new subject ran `clear_content` — wiping every line, an addon's appended ones included — and then `show_or_hide_empty`, which is a **no-op on an already-shown frame**. So the addon was never told to put its lines back. The reference never meets this because 1.12's plates publish no tooltip; benilla's do (`target/hover.rs` feeds `Hovered` from a V-key plate, as the reference's plate `OnEnter` `0x7cb850` publishes the mouseover), so moving between a mob and **its own nameplate** rebuilds over a tooltip that never hid. Diagnosed from the player's own report that hovering from empty sky worked while mob ↔ nameplate did not — the sky case hides the tooltip first, which is exactly the missing transition. `world_tooltip_unit` now hides before rebuilding; it is already gated once-per-subject-change by `ui_tooltip`'s driver, so this is one hide/show pair per new subject and both land before the frame paints. Consumers: pfQuest's objective annotation (`pfQuest/map.lua:253`) and pfUI's `GetUnitGUID` reader (`modules/tooltip.lua:81`) both hang off `OnShow` |
| `GameTooltip:GetUnitGUID` on a **world hover** | **fixed** | The getter was built earlier and worked from a Lua `SetUnit`, but returned *no values at all* for the unit under the cursor — the case that matters, since every consumer is on the tooltip's own show. Cause: the mouseover snapshot carried `guid == 0`. `SnapshotCtx::full` assigns `s.guid`, but the world-hover path (`ui_tooltip/mod.rs`) builds its snapshot the long way — `snapshot()` then `enrich_unit()` — and `enrich_unit` **took a guid and never stored it**. `tooltip_unit.rs`'s `render_unit` records the guid only when non-zero, so the tooltip's `unit_guid` stayed `None` and the getter answered nothing. Assigned in `enrich_unit` rather than at the call site, so the two snapshot paths cannot disagree again. **Blast radius beyond the tooltip**: `UnitGUID("mouseover")` filters on `guid != 0` too, so it was nil for every hovered unit. Measured consequence: pfQuest's objective annotation (`pfQuest/map.lua:253-290` — a frame parented to GameTooltip whose `OnShow` keys on this getter's first return) silently never ran, so a hovered mob never showed which quest it counts for. Found only by instrumenting the live handler: it fired 3 times with the getter empty, which is also what made `tostring(GameTooltip:GetUnitGUID())` raise "value expected" |
| Secure-attribute click dispatch (`type1`/`type2`/click-cast) | **built** | `SetAttribute`/`GetAttribute` were built as a bare key/value store, with this file's own header calling that "honest" about not claiming modern WoW's restricted-execution subsystem. The line was in the wrong place: a frame that stores attributes and does nothing when clicked is not a documented limitation, it is an inert frame. **pfUI drives every one of its unit frames this way whenever Clique is absent** — which is the default — setting `type1="target"`, `type2="menu"` and `EnableClickCast()` and installing **no `OnClick` script at all** (`api/unitframes.lua:1320-1326`). So the player frame could not be clicked to target, right-clicked for its menu, or used for click-casting, and neither could any other unit frame. Dispatched in `frame.rs`'s `dispatch_attribute_click`, called from `button.rs` **after** the `OnClick` handler for the same reason the nameplate selection is — a frame may have both and a raising hook must not eat the action. Handles `target`, `menu` (through `ClassicAPI_ToggleUnitMenu`, the same entry pfUI's own Lua path calls, so the two routes open one menu), `focus`, `spell` (cast on the frame's `unit`, which is what click-casting means) and `macro`/`macrotext`, with `shift-`/`ctrl-`/`alt-` prefixes falling back to the unmodified binding as the reference's lookup does. **What is dispatched is the action, not the security model**: no taint, no protected call, no combat lockdown — none of which 1.12 has |
| nampower's `*_SELF` aura edges | **built** | `BUFF_ADDED_SELF`/`BUFF_REMOVED_SELF`/`DEBUFF_ADDED_SELF`/`DEBUFF_REMOVED_SELF`, over the diff that already produced the `*_OTHER` pair — the player was **explicitly skipped** there, with a comment saying this half was unbuilt. Its helpful half is diffed separately because the halves fire different events. Why it matters: DoiteAuras reads the whole aura block **once**, at `PLAYER_ENTERING_WORLD`, and then relies entirely on these four (`UpdateAuras` is called nowhere else), so with none fired its table froze at login and every buff gained afterwards read as missing. Upstream has **eight**; the `BUFF_*_OTHER` pair is deliberately not produced — it would mean diffing the helpful half of every streamed unit on every edge for no reader — and `AuraEdge`'s three variants say so rather than leaving a dead arm firing events the gate must then allow. **Gate note**: routing the names through a `&str` parameter compiled and left `reference_ui.rs`'s event walker blind (it reads the literal at the call site), including to the two `*_OTHER` names already declared; the literals are back at the fire sites for that reason |
| Aura feed ordered before the `PLAYER_ENTERING_WORLD` fire | **fixed** | `feed_auras` and `feed_units` both sat in `UnitFeed` with **no ordering between them**, and `feed_units` is what fires `PLAYER_ENTERING_WORLD`. Whether an addon reading the aura block in that handler saw it was down to Bevy's ambiguous order — which is why DoiteAuras worked on a fresh login and broke after a `/reload`. A new `UnitFeedDispatch` set wraps `feed_units` alone so a sibling feed can order itself ahead of the fire; `feed_auras` now does. Same reasoning `feed_units` already applied internally to the XP pair ("ahead of the `PLAYER_ENTERING_WORLD` fire so its first update reads it") |
| `PlaySoundFile` on an addon's `.ogg` | **built** (decoder) | Not an API gap — the binding and the loose-file read were already right; kira was built without the `ogg` container and `vorbis` codec features, so `sfx_from_bytes` returned an error for every Vorbis file and `sound/ui.rs` logged it at `debug!`. Silent alerts with nothing in the log. **75 `.ogg` files on this install**: DoiteAuras (57), BigWigs (11), unitscan (3), HCWarn (2), TWThreat and Cleanup — so every one of those addons' alerts was dead, including HCWarn's hardcore death warnings. AI_VoiceOver ships `.mp3` and always worked, which is what made it look like an addon-specific problem. Stock 1.12 plays wav and mp3 only; the Turtle/OctoWoW client these addons are written for plays ogg, which is why they ship it — the deviation is from 1.12, toward the client the player actually runs. Covered by `sound::mixer::tests::an_addons_ogg_decodes`, gated on the player's own addon folder the way the chain tests are gated on a WoW install |
| `LOCALIZED_CLASS_NAMES_MALE` / `_FEMALE` | **built** | Published by `script/class_info.rs` whenever the app feeds the class table, from the same two `ChrClasses` columns `C_CreatureInfo.GetClassInfo` answers from: keyed by `classFile` (`WARRIOR`), valued by the display name (`Warrior`). Half of this pair was already here and the other half missing — `ClassInfo::class_file`'s own doc names these tables as what FrameXML keys on, and `compat/classic_api/lua_ext.rs`'s `tInvert` exists *because* pfUI flips this one (`pfUI.lua:227`). With the table absent that flip inverted nil, so `pfUI.env.L["class"]` was **empty** (measured: 0 entries against the live chain) and every lookup through it silently found no class — the guild roster's name colours and class icons (`modules/socialmod.lua:18`), the friends list's, and `modules/panel.lua:359`. Nothing raised, because the module tests `if class then` and skips, which is why it read as "pfUI just doesn't colour those lists here". Both tables carry the same string: 1.12's `ChrClasses.dbc` has one name column, so the gendered pair later clients ship cannot be derived — publishing `_FEMALE` as a copy is what this data honestly supports, and omitting it would hand a caller nil where its sibling answers. Absent, not empty, on a run that never fed the table |
| `C_Spell.GetSpellMechanicByID` / `GetSpellEffectMechanics` / `GetSpellPowerCost` | **built** | One probe for all three (`SpellDbcExtras`): same `Spell.dbc` row, same install site, and a caller asking for either has already paid the lookup. Its own probe rather than columns on `SpellLookup`, which has eleven construction sites with no answer for them. **`GetSpellMechanicByID` is three-way** and the consumer spells it out: nothing for an id no spell owns, `0` for a real spell with no mechanic, the id otherwise — it replaces a hand-kept spellID → mechanic table, so collapsing "unknown" into "none" would reclassify crowd control as plain damage. The enUS name is the second return, from `SpellMechanic.dbc` (which this tree already parsed). **`GetSpellEffectMechanics` is the per-effect sibling**, `EffectMechanic[3]` as `{m1, m2, m3}`, and it is not the same question: vanilla puts some mechanics on an effect rather than on the spell, so Rake's bleed answers `{0, 15, 0}` where `GetSpellMechanicByID` answers 0 — a macro conditional asking whether its target is bleeding gets the wrong answer from the spell-level column alone. Same three-way shape (nothing for an unknown id, three zeros for a spell with no mechanic anywhere). `SpellDisplay` already parsed the column for the cast-immunity scan, so this cost a field on the probe payload and nothing else. Its absence was one raise a session from `SuperCleveRoidMacros/ClassicAPI.lua:267`, which calls it unguarded. **`GetSpellPowerCost` answers a LIST** (`costs[1].cost`), one row, since 1.12 has a single cost per spell; it is the flat `manaCost` column **without** the reference's per-level and percentage terms (`GetPowerCost` `0x6e31b0`), which need the caster's level and max power — stated because it is the base cost a macro reader wants, not what a scaling spell would actually spend |
| nampower `GetUnitField` / `GetSpellRecField`, version 4.1.3 | **built** | `GetUnitField(unit, field)` is nampower v3+'s window onto the raw `UNIT_FIELD_AURA` block, and the reason it exists is that its slots are **stable**: every 1.12 aura getter walks the *compacted* list, so each index shifts the moment an earlier aura drops and nothing can be keyed on it across frames. Two fields: `"aura"` → slot → spell id, `"auraApplications"` → slot → **stacks minus one** (the wire's own encoding; pfUI reads it back as `(apps[slot] or 0) + 1`, so returning `stacks` would show every debuff one stack high). **Slots are reported 1-based** — debuffs 33..48, which both consumers loop literally — over benilla's 0-based wire index. Needed new state: `AuraState::slot`, since the VM's aura list was compacted and had dropped the raw index; filled at both app-side builders. Accepts a token or a raw GUID (pfUI passes `GetDebuffSlotMap(guid)`, DoiteAuras passes `"player"`), folding a guid back through `token_for_guid`. Reads the same filtered list every other getter does — hidden-from-aura-bar and tracking auras are already gone, which is what a debuff tracker wants, and the slot keying is unaffected because a dropped aura reads nil at its slot rather than shifting its neighbours. `GetSpellRecField(spellID, field)` is **partial on purpose**: `name` and `rank` are answered, `stackAmount`/`manaCost`/`spellIconID` are **nil rather than a plausible zero** — this client reaches no other column of that row, and a fabricated `manaCost` of 0 reads as "free", which is exactly the test DoiteAuras' Clearcasting rule turns on. `spellIconID` is not derivable at all: the icon is carried as an MPQ path, not as the numeric id that names it. With all three in place `GetNampowerVersion` moves 4.0.0 → **4.1.3**, which is the gate DoiteAuras gates on — bumped only *after* the machinery existed, per that constant's own standing rule not to claim what is absent. Measured: DoiteAuras goes from refusing to open to **0 load / 0 session errors**; pfUI's `libs/libdebuff.lua` ("GetUnitField Edition") stops falling back to manual slot shifting |
| nampower's six spellbook/duration verbs | **built** | `GetSpellNameAndRankForId(id)`, `GetSpellIdForName(name)`, `GetSpellSlotTypeIdForName(name)` → `slot, bookType`, `IsPassiveSpell(index, bookType)`, `GetSpellDuration(id[, ignoreModifiers])` → ms, and `GetPlayerAuraDuration(auraSlot)` → `spellID, durationMs, expirationTimeMs` (`script/compat/nampower.rs`). Signatures are **not inferred**: `SuperCleveRoidMacros/NampowerAPI.lua` is a shipped, documented wrapper over this whole surface and states each one's arguments, returns and units, which is what these were built against. Why they matter beyond a missing-global warning: DoiteAuras takes each as a *fast path* and otherwise falls back to a 200-slot `GetSpellName` scan **per lookup, per tracked aura, per condition evaluation**. None is expressible in 1.12: that client walks a book by index and reads a name, but has no id for what it finds and no way back from a name to either, and it exposes a running aura's remaining time (`GetPlayerBuffTimeLeft`) but no way to ask a spell how long its aura lasts *before* casting it. The two name→X verbs answer the **highest rank known**, as `CastSpellByName` does. **The two slot conventions deliberately disagree**: `GetUnitField` is 1-based (debuffs 33..48) and `GetPlayerAuraDuration` is raw 0-based (0..31 buffs, 32..47 debuffs) — each is what its own consumers loop over, and matching them to each other would break both. `GetSpellDuration` reads `SpellDuration.dbc` through the same `ui_cast_events::aura_duration_ms` that answers nampower's `SPELL_START_*` `arg7`, so the event and the query cannot disagree; it keeps upstream's three-way answer (nil for no such spell, 0 for a spell whose length this client will not state, ms otherwise) because a consumer treats 0 as absent and falls back, while a number it trusts and draws as a timer. `ignoreModifiers` is accepted and ignored: it asks for the base duration, and the base is all this client has (`spell/mods.rs` stores the server's `SPELLMOD_DURATION` cells but has no reader) |
| nampower `GetSpellIconTexture` / `GetItemSpell` / `IsSpellInRange` / `IsSpellUsable` / `GetAmmo` | **built** — this row replaces the `todo` it was written as | The last five of DoiteAuras' eleven probes, so all eleven now answer. `IsSpellUsable(id|name)` -> `usable, oom` and `IsSpellInRange(id|name[, unit])` read a live per-spell map `ui_action::state` pushes over the player's **whole book**, computed by the reference's own usable walk (`0x6e3d60`) and range verdict (`0x4e56f0`) — the same computation the action bar greys its buttons with, so a spell on a bar and the same spell asked for here cannot disagree. That feed is the reason these are not a forward of `IsUsableAction`, which is keyed by *action-bar slot*: a spell the player knows but has not placed on a bar has no slot to ask through. Swept at ~10 Hz (a cooldown-generation change jumps the queue) because a book is ~150 spells and the walk reads equipment and reagents per spell. Range is measured against the **current target**, as the bar's own light is, so naming any other unit answers nil rather than quoting the target's distance under another unit's name. `IsSpellUsable`'s absence was the one with teeth: DoiteAuras' `_SafeSpellUsable` returns `1, 0` without it, so every usability condition passed and an aura gated on one showed **always**. `GetSpellIconTexture(spellIconID)` needed the pair's other half built first — `SpellDisplay` now keeps `icon_id` beside the path it resolves to, and the catalog keeps `SpellIcon.dbc` itself, so `GetSpellRecField(id, "spellIconID")` answers a real row id and this resolves it back (verified end to end: spell 6673 -> icon 456 -> `Interface\Icons\Ability_Warrior_BattleShout`). `GetItemSpell(itemID)` answers the **Use:** spell only (wire triggers 0 and 5), never an equip or proc one, or every stat trinket would read as an activatable. `GetAmmo()` is the doll's slot 0, whose count the app already sums across quivers for the low-ammo alert. Signatures throughout are **not inferred**: `SuperCleveRoidMacros/NampowerAPI.lua` is a shipped wrapper documenting each one's arguments, returns and units |
| `SetPortraitToTexture(region, path)` — the region form, and a nil path | **built** | It took only a texture *name* string, because both stock callers pass one (`ContainerFrame.lua:419`, `MailFrame.lua:174`) and this file's own comment recorded the object form as "untraced". OctoWoW's shop settled it: `Turtle_ShopUI.lua:893` passes the region and works on the real client. Refusing it raised **inside the shop's entry loop**, which aborted after the first card — and because the page count is written *before* that loop, the window read "Page 1/2" with one item and seven empty cells, which is the whole of the "can't see half the items" report. A nil path now clears rather than raising on argument #2: the same caller takes its texture from `GetItemInfo`, which answers nothing for an item the client has not cached |
| `OnHyperlinkEnter` / `OnHyperlinkLeave` | **built** | Fired by `pointer::update_hyperlink_hover` off the same rasterized link spans the click path reads, so a hover and a click can never disagree about where a link is. Not 1.12's — that client routes a link only on release (`OnHyperlinkClick`) — but TurtleWoW's adds them, and `SetScript` used to *raise* on the name under the standing rule that an accepted handler nothing fires is worse than a refused one. `ChatSuey-ItemLinkHover` is two handlers and nothing else, so the raise took the addon with it. The span is keyed by its markup, not its rect: a chat frame scrolls its lines under a still cursor, and re-entering the same link at a new y is not a new hover |
| A `<Script file=>` naming itself from the install root | **fixed** | Joining the value onto the including document's directory is benilla's own deviation (the reference uses it verbatim), written on the premise that nothing exists at the raw path. An addon's own `Interface\AddOns\<Name>\…` is exactly where that premise fails: the join doubled it into `Interface/AddOns/X/Interface/AddOns/X/…`. RoleplayingHelper writes all 22 of its locale files that way, so its entire word list was empty. A root-relative value that the provider can answer verbatim now wins; everything else still joins |
| The auction class tree at VM setup | **fixed** | `GetAuctionItemClasses`/`SubClasses` are fed by `feed_auction`, whose own comment notes the stock `AuctionFrameBrowse_OnLoad` reads them as the addon loads — but a system's first run is a frame *after* the addons, and an addon reading them at **file scope** is already past. Seeded in `lifecycle` beside `C_CreatureInfo`, which is there for the same reason. Tmog is the casualty: `Localization.lua` builds its whole locale table out of `GetAuctionItemSubClasses(1)`/`(2)`, so empty answers left every key nil and the next file died on `[L["Leather"]] = 1` — "table index is nil" — taking the addon with it, which is why `TmogTooltip` was nil on every hover afterwards |
| A tooltip for the player's **own** character | **reverted** — the ask was the unit frame, not the body | Built, then removed the same day: the request was for pfUI's *unit frame*, and 1.12's own behaviour on the 3D body (no tooltip, because your body is not a selectable pick) is the right one. `Hovered` is back to its original shape, so the self pick, the slot and the tooltip fallback are all gone. The unit-frame half is an addon patch, not a client change: upstream pfUI sets no `OnEnter` on its unit frames and never calls `GameTooltip:SetUnit` anywhere, so no pfUI unit frame has ever shown one — `pfUI.uf.OnEnter`/`OnLeave` now do what stock `UnitFrame_OnEnter` does, taking the unit from the frame's own label/id pair |
| `PlayerModel:SetUnit(<creature display id>)` | **built** | 1.12's `SetUnit` takes a unit token; a **number** is the realm's extension, meaning a `CreatureDisplayInfo` id. OctoWoW's shop draws every mount, companion and illusion card with it (`model:SetUnit(entry.modelid)`), and dropping the argument left those tabs showing empty cards while the texture-backed ones — skins, gameplay, miscellaneous — drew fine, which is exactly the split reported. **The skins load through the asset server, not inline.** The first cut resolved them with `WorldAssets::sprite_texture`, which locks the MPQ chain and decodes the BLP *on the calling thread* — and every UI path's calling thread is the main one. Measured at 6–10 ms per skin, a mounts tab of eight displays at up to three skins each spent a quarter of a second of main thread inside one frame, with the GPU idle at 3.9 ms through it: the client stopped dead while every meter reported a healthy 95 fps either side of it. The world's own `resolve_skin` always loaded these asynchronously; this now does the same, and a skin landing a frame late is what the reference does anyway. `WOW_SPRITE_TRACE=1` names any decode costing 2 ms or more, which is how this was found. The id resolves through a `CreatureDisplayInfo` → `CreatureModelData` map installed on the VM **with the display's three skin variations beside the path** — a creature M2 names no texture for its skin slots, so the first cut of this drew every mount and companion as a white silhouette; the skins now ride `ModelState` → `QuadContent::ModelPane` → `TileRequest` into `build_tile`, which applies the same rule the world path does (`entities::display::resolve_skin`): the batch's own texture when it names one, else the display's variation for its slot. The map (owned, not borrowed: the probe outlives the system run that builds it) and lands in the same `path` slot `SetModel` writes, through the same `set_file` + implicit-rect steps, so the loader, booth and camera are untouched. It returns before the dress-up redress, which would otherwise overwrite the creature with the player's own body. The fourth tab, Fashion, is a different path — `SetUnit("player")` + `TryOn`, gated on `GetItemInfo` answering an equip slot, which fills asynchronously after the scan tooltip's query round-trips |
| The dynamic unit-pane pool, 8 → 24 | **fixed** | `portrait::UNIT_PANE_SLOTS` sizes the pool of booths a `PlayerModel:SetUnit(<token>)` pane can claim. At 8 it covered unit-frame portraits and nothing else — Tmog browses transmog with a page of **15** `DressUpModel` cells (`Tmog.itemsPerPage`) plus its own full-body pane, so its grid drew a few models and then a page of empty squares. The engine said so plainly once per session and it was in the log the whole time: *"all 8 dynamic unit-pane booths are taken — a further PlayerModel:SetUnit pane draws nothing until one frees"*. Confirmed against the reference client side by side: there every cell holds a little dwarf wearing the item. The ceiling is the `RenderLayers` word (base 29, so 34 is the most that fits, and the existing assert holds the line); an unclaimed slot costs its render target and no per-frame work, since the booths are spawned inactive — 24 × 256² ≈ 12 MB of VRAM for grids that fill |
| A persistent item cache (`item_persist.rs`), the reference's `itemcache.wdb` | **built** | The reference writes every `SMSG_ITEM_QUERY_SINGLE_RESPONSE` to disk and reads it back at login, so `GetItemInfo` answers a known item **immediately**; benilla re-asked the server every session. One missing file, three symptoms that looked unrelated: OctoWoW's shop draws an icon from `GetItemInfo` (cold → the frame with no icon); its model cards branch on the same call (`elseif loc and loc ~= ""`), so an uncached item runs **neither** branch and the pane keeps the previous category's model — the Fashion tab showing companions; and Tmog queues a page of item ids and spins in an `OnUpdate` until every one answers, calling `EnableMouse(false)` on every preview button and re-showing its "Loading" overlay **each frame** while it waits (`Tmog.lua:1446-1481`), which on a cold cache reads exactly as the window flashing and going unresponsive. Measured first, not guessed: `WOW_UI_HANDLERS` showed 75–170 fps and 0.3–2.6 ms/f of Lua with Tmog open, and the flash tracer found **no** frame toggling — so it was never a renderer or a handler storm. Shaped on `name_persist.rs` (benilla's `creaturecache.wdb`): realm-scoped under `benilla-config/cache/` because the install is read-only and another realm may hold a different template under the same entry, written on a 10 s debounce and again at exit. The record is the parsed `ItemInfo` as JSON, not the reference's raw response block — the wire reader is the only parser, so re-encoding by hand would be a second copy of 52 fields free to drift from it. Both systems run in `Last`: in `Update` they added 78 undeclared orders against everything that reads `Items`, and neither is frame-critical |
| Per-pane dressing rooms | **built** (the state half; the booth half is the `todo` below) | `DressUpIntent` now carries **the pane it was called on**, and `ui_dressup` keeps a `DressUpRoom` per pane instead of one shared one. 1.12 has exactly one `DressUpModel`, so a single room was the whole model; Tmog draws a page of **15** preview cells (`Tmog.itemsPerPage`) and OctoWoW's shop a Fashion tab of them, and every one of their try-ons landed in the same room. The room's close rule changed with it: it used to read the two stock *windows* by name (`DressUpFrame`, `AuctionDressUpFrame`), which is the right test for the stock panes — each lives inside one — but an addon's pane is inside neither, so the rule closed its room on every frame it was being filled. **That fill-and-wipe fight, sixty times a second, is what made both windows flash.** Asking the pane's own visibility covers the stock panes identically (they are children of those windows) and ends the fight. Each open room now resolves to its own look, published per pane for the booth work below |
| A page of previews still shows one character | todo, and the last piece | With the rooms split, each pane has its *own* look — but a pooled unit-pane booth still **mirrors the live player's spawned tree** (`DressedLook`'s queries over the unit's children) rather than assembling a dressed one, so fifteen panes render fifteen copies of whatever the player is actually wearing. The dress-up booth knows how to assemble a look from scratch (`build_dressup_preview` → `DressUpBake` → `sync_dressup_booth`), but that path is built for **one** booth: a single `DressUpBake` resource, `Local` bake state keyed to nothing, and a hard-wired `DRESSUP_SLOT`. Finishing it means making the bake per pane, giving `sync_dressup_booth` per-slot state so it can write into a pane's claimed pooled slot, and skipping the mirror for slots that have a look. It is real renderer work — fifteen character assemblies, each with its own skin composite and item displays — and it can regress the paper doll, the inspect pane, the glue screens and the pooled portraits, all of which share that machinery, so it wants its own pass rather than a tired one |
| `Model:SetPosition`'s first argument is **depth**, not a screen offset | todo, root cause confirmed | The shop's mount cards draw far too close and cropped where the reference shows the whole mount with room around it. `SetPosition(a, b, c)` is stored verbatim and `ui_models` then reads `a`/`b` as a *screen* offset and `c` as depth. The convention is the other way round and three addons agree on it: the shop writes `SetPosition(entry.posz, entry.posx, entry.posy)`, Tmog writes `SetPosition(Z, X, Y)` from variables it names, and — the decisive one — Tmog's **mouse-wheel** handler changes only the first component (`Z = Z + 1`), which is zoom. So the first argument moves the model along the view axis and must change its apparent size; benilla shifts it sideways instead and never scales. Fixing it is two parts: the axis mapping, and making depth actually scale, which the orthographic leg (`camera: None`, every shipped pane) does not do at all. The second part needs the reference's own distance constants measured, not guessed — a half fix that only swaps the axes would shove every card sideways by its zoom |
| `GetActiveLevel` / `GetAvailableLevel` | **built** | 1.12's own greeting-row getters, which stock `QuestFrame.lua` prints beside each title. The level already rides the wire beside the title (`QuestOption::level`) and was parsed and then dropped, so both globals were simply absent — and a missing global is a **raise**, not a nil read. `_LazyPig` calls `GetActiveLevel` for every row of a quest giver's greeting list, so opening one spammed the error through `xpcall` and left the gossip window misbehaving, which is the "messed up quest ui" report. An index past the list answers **0, never nil**: the caller concatenates it straight into a string, so a nil would raise exactly the way the missing global did |
| `ClassicAPI_ToggleUnitMenu` opened nothing | **fixed** | Its initialiser passed `UIDROPDOWNMENU_OPEN_MENU` to `UnitPopup_ShowMenu`, which **indexes** its first argument — and in 1.12 that global holds a frame *name string*, which is why every stock initialiser wanting the frame writes `getglobal(UIDROPDOWNMENU_INIT_MENU)`. It raised at `UnitPopup.lua:136`, so right-clicking any pfUI unit frame did nothing at all. The closure already had the frame |
| `GameTooltip:SetUnitAura` | **built** | Raised on **every buff hover**: pfUI's raid and group frames tooltip each buff icon through it (`api/unitframes.lua:67`), so it repeated for as long as the pointer moved over a frame. The modern spelling of 1.12's own `SetUnitBuff`/`SetUnitDebuff` pair, choosing the list by its `filter` argument rather than by the verb's name, and forwarding through the same method table so those two stay the single implementation — a rename, not a second mechanism. `HARMFUL` **as a substring** selects debuffs (so the composite spellings a raid frame composes, `"HARMFUL|RAID"` and friends, land on the right list where an equality test would silently answer with a buff); everything else, an absent filter included, is helpful, which is modern's own default. Note it is not in `docs/classic-api-functions.md`'s GameTooltip list, so it is either newer than that capture or the list is partial; built anyway because the mapping onto two existing verbs is exact and the cost of leaving it was a raise per hover |
| `GameTooltip:SetHyperlinkCompareItem` | **built** | 12 raises in one session, from pfUI's equipment-compare tooltips (`modules/eqcompare.lua:21,24,72`). Not 1.12 — it is in ClassicAPI's surface, so the same family as `UnitSpellHaste` and `C_ChatBubbles`. The earlier note here guessed at a shim (`GetItemInfo`'s `itemEquipLoc` → `GetInventorySlotInfo` → `SetInventoryItem`) and called the equip-location table "real work" — but **that table already existed**: `tooltip_item/mod.rs`'s `equip_slots_for` was written for 1.12's own `SetMerchantCompareItem`/`SetAuctionCompareItem`, and its two-seat rows (finger → 11,12; trinket → 13,14; one-hand → 16,17) are exactly what `index` is for. So the verb is `compare_against_worn` — the same shopping-tooltip body, the same `CURRENTLY_EQUIPPED` latch — reached from a link rather than a list row, registered in `compat/classic_api/tooltip.rs`. `index` is 1-based over the *candidate* slots, so an empty second seat is not a candidate and index 2 answers nothing. Arguments 3 and 4 (`shift`, `comparisonTooltip`) are accepted and ignored: that module has already made the shift decision before calling (its merchant path passes `1` with no key held) and does its own `SetOwner`/`SetPoint` for the anchoring |
| SuperWoW's `LootSparkle` sparkled nothing | **fixed** — the decision was right, the switch feeding it was never on | Reported from play: *"Loot sparkle not working on a mining ore I'm looking at"*, with the unit arm visibly working on lootable mobs — which is the shape of the bug, since only the GameObject arm reads the switch. `LootSparkleMode` derived `Default`, so it booted `false` while its row registered `"1"`. A boot fires `CvarChanged` only for rows `config.toml` actually carries, and writing `"1"` over a value already `"1"` is a no-op that fires nothing either, so **nothing could ever tell the resource its real default** — not the boot, not the player toggling it. `vplates.rs`'s `VPlateMode::default` carries that warning in as many words, from `NameplateOcclusion` shipping inert the same way, and this is the same mistake one feature later. Fixed with a hand-written `Default` and the twin test `the_loot_sparkle_default_agrees_with_its_registered_cvar`, which reads the registered row rather than restating it. Swept the rest: of the 32 resources a `CvarChanged` observer writes, 6 derive `Default` (`AssistAttack`, `AuraCastFeed`, `AutoSelfCast`, `BlockTrades`, `FpsJournalSetting`, `GuildMemberNotify`) and **every one of their rows registers `"0"`**, so `LootSparkle` was the only one of this shape |
| `PlayerModel:SetUnit` tracked the token instead of holding the unit | **fixed** | unitscan's alert reads `SetUnit'target'` on the rare it just found by name, and the addon restores the player's own target on the next line — so a pane that re-resolved `"target"` per paint showed the card for one frame and then emptied. Reported the moment the by-name targeting stopped leaving the target on the rare: *"unitscan is not targetting anymore, very nice, but now it only shows the 3d model when I do target"*. The reference resolves the token in `SetUnit`'s own rebuild worker (`0x505b50`, the one `RefreshUnit` also runs) and nothing re-resolves it per paint — which is why FrameXML re-issues `SetUnit` from `PaperDollFrame_OnShow` and on `UNIT_MODEL_CHANGED`, and why pfUI can detect a portrait change with **no event at all** by pinning a scratch pane and comparing `GetModel` against the shown one (`api/unitframes.lua:2069`), a test that only says anything if a pane holds what it was given. `ModelState::unit_guid` is that pin, resolved at the call and read by one helper (`Model::unit_pane_subject`) for both the paint gate and the extract. A pane seated **before** its unit streamed in keeps re-reading its token, since our subject arrives asynchronously where the reference's is already in the object manager; `RefreshUnit` re-pins, as its worker does. Test: `a_unit_pane_keeps_the_unit_it_was_given_when_the_token_moves_on`. Still true and still not built: `GetModel()` answers nil on a unit pane here, so pfUI's eventless detection leg can never fire — its event leg does, and that is what draws its portraits |
| An item tooltip's rebuild was silent, so an addon's lines lasted one refresh | **fixed** | Reported from play with a video: hovering a bag item draws the enhanced tooltip — MasterTradeSkills' recipe block, AdvancedTradeSkillWindow2's `Bags/Bank/Total` — for about nine frames of sixty, and then the plate reverts to the bare one and stays bare while the cursor sits still. The loop behind it is stock: `ContainerFrameItemButton_OnUpdate` re-enters `..._OnEnter` every `TOOLTIP_UPDATE_TIME` (`ContainerFrame.lua:693` in the player's own `patch-4.mpq`, and pfUI's bag slots are `ContainerFrameItemButtonTemplate`, so they run it too), and each turn is `SetOwner` + `SetBagItem` — a clear that wipes every line an addon appended. What puts them back in the reference is a **hide/show pair**: the `SetOwner` binding hides the plate before it even reads the owner argument (`0x531179` zeroes the content gate at `+0xd0`, `0x531183` calls `[vtable+0x84]` = `0x530a60`, which is the `SetOwner(NULL)` core plus the base hide `0x76ad50`), and the content `Set*` re-shows it through the tooltip's own Show override (`0x530a80`), so every rebuild raises `OnHide` then `OnShow`. Ours cleared in place, and the base show early-outs on an already-visible frame (`0x76ae3b`), so the plate never hid and the `OnShow` never came. `LibItemTooltip-1.0` — the tooltip contract of MasterTradeSkills and Gromissingcrafts — hangs entirely on a scratch child frame of `GameTooltip` listening for `OnShow`, which is why exactly those two addons' lines vanished while pfUI's `ItemID` and sell-price lines, hooked on the `Set*` methods themselves, survived every refresh. All addresses read off the player's own `WoW.exe` |
| The object sparkle was armed but buried inside the object | **fixed** — the placement is ours | *"ore vein is still not sparkling"*, after the switch fix. Reproduced offline in the `fxview` GameObject lane (`WOW_CAPTURE=fxview WOW_FX_GO=310 WOW_FX_GO_TYPE=3`, a copper mining node): the gate fires, `attach_spell_fx` spawns the instance (`kit spawn … Particles\LootFX.mdl`), and `WOW_PARTICLE_CENSUS` lists all four of `LootFX`'s emitters at the node's own position, live and ungated — while the captured frame is **byte-identical** to one taken with the sparkle gated off. The attach cascade's last rung is the host's origin, which for a unit is right (`0x13` is attachment 19, Base, the ground point under its feet, and this is a ground twinkle); a 1.12 **GameObject** model authors no attachment points at all (`copper_Miningnode_01.m2`: 0), so the effect sat at the node's pivot, inside the rock — that model's own vertices run y ∈ [-3.83, +2.73]. A host with no attachment points now seats the effect at the top centre of its own box, and the capture differs; the same sparkle on a peacebloom, whose model is small, already showed at the pivot. The placement is ours and no more: SuperWoW publishes no source and the reference has no object arm to copy. It is also **subtle by design** — `SpellVisualEffectName` row 14 scales 1.0 and `Particles\LootFX.m2` is four emitters of 0.06–0.14 yd particles with ~0.9 yd of reach — so it reads as a few twinkles over the node rather than a beacon |
| A frame left in saved variables came back as a bag of its fields | **fixed** | `attempt to call method 'AddMessage' (a nil value)` at `Decursive.lua:1393`, every login. Decursive keeps its output window in its own saved table (`Dcr_OutputWindow = DEFAULT_CHAT_FRAME`) and guards the reload with `if Dcr_Saved.Dcr_OutputWindow == nil or not ...` (`:1245`) — which a non-nil **data** table passes. Our writer walked the frame like any other table and wrote ChatFrame1's own fields (`buttonSide`, `channelList`, `editBox`, …), doubling the file (2217 bytes against his real client's 1108) and losing every method. The reference tests the value's `T[0]` identity first — `lua_rawgeti(v, 0)` then `lua_touserdata` at `0x704613`-`0x704628`, the lightuserdata `0x701bd0` wrote — and never walks a widget: a **named** one writes as its bare global name, a Lua expression, so the reloaded chunk's own lookup hands the live object back, and an anonymous one as `nil --[[ unnamed object ]]` (`0x872e0c`). His own real-client file is the proof: `["Dcr_OutputWindow"] = ChatFrame1,`. Deviation: a name that is no Lua identifier writes as an anonymous object, where the reference writes it raw (`%s`) and can leave a file that will not parse. Tests: `a_saved_frame_comes_back_as_the_frame_not_a_copy_of_its_fields`, `an_anonymous_frame_saves_as_the_references_unnamed_object` |
| `SetScript("OnMessageScrollChanged")` raised, aborting the builder around it | **fixed** | WIM sets it on every window it builds — the history frame at load and then one per correspondent (6 whisper windows in one session of his log, each `WIM_msgFrame<Name>ScrollingMessageFrame`) — so refusing the name by raise killed the rest of that builder function every time, not just the handler. It was on the deliberate "real 1.12 kinds nothing fires, so raise rather than silently accept" list (`object/events_regions.rs`), which is the right rule and the wrong side of it here: the slot now **fires**, from the ScrollingMessageFrame's own scroll verbs when a scroll actually moves the view (`messageframe::scrolling::scroll`), which is what a chat addon hangs its scroll-down arrow on. A scroll refused at either end moves nothing and says nothing; whether the reference also fires one there is untraced. Test: `a_scroll_that_moves_the_view_fires_the_frames_scroll_script`, and the raise list's own test keeps its rule (`the_unfired_script_kinds_still_raise_rather_than_silently_accepting`) |
| nampower's equipment and item-cache getters (`GetEquippedItem`, `GetEquippedItems`, `GetItemLevel`, `GetItemStats`, `GetItemStatsField`) | **built** | *"then we gotta fix bettercharacterpanel, that one is driving me nuts"*. BetterCharacterPanel is built on all five: `GetEquippedItem` was 8 raises in one session (`BetterCharacterPanel-lib.lua:93`, `:193`, `-paperdoll.lua:179`) and the other four failed inside the addon's own `pcall`s, so the panel's item-level column, its quality colours, its missing-enchant warning and its two-hand test were all dead at once. DoiteAuras reads the same getter in six places. **The spec is the installed `nampower.dll`'s own string pool, not inference**: its usage strings give the signatures (`GetEquippedItem(unitStr, slot) or GetEquippedItem(guid, slot)`), its validation message **"Slot must be a number between 1 and 19"** gives the band — 1.12's own `GetInventoryItemLink` numbering, so `NampowerAPI.lua`'s `slot - 1` in `IsItemInSlot` is that shim's bug and not the contract — and the key names are its pooled strings in order: `itemId`, `permanentEnchantId`, `tempEnchantId`, `randomPropertiesId`, `stackCount`, `duration`, `spellChargesRemaining`, `flags`, `durability`, `maxDurability`, `tempEnchantmentTimeLeftMs`, `tempEnchantmentCharges` for an item, and `class`/`subclass`/`displayInfoID`/`quality`/`buyPrice`/`sellPrice`/`itemLevel`/… for a cache row. Its miss, **"Item not found in DBCache"**, is a raise, which is why the addon `pcall`s exactly these three and calls `GetEquippedItem` bare — ours raises the same string and records the template ask, so the call after the query's answer succeeds. `itemLevel` is the field 1.12 cannot reach at all: `GetItemInfo`'s fourth value is the *required* level (`0x48e070` pushes nine values; later clients are the ones that insert `itemLevel` at 4), so the item-level column had no possible source before this. Left absent rather than guessed: `duration` (the descriptor's seconds, where this client holds a display countdown in ms), the `resistances` array (six scalars here, index base in nampower's table untraced), the five-slot `spell*` block, and `ammoType`/`rangedModRange`/`languageID`/`pageMaterial`/`material`/`sheatheType`/`area`/`bagFamily`/`bonusStat`/`bonusAmount` — nothing installed reads any of them. An inspected unit answers from `PLAYER_VISIBLE_ITEM_*`, which carries the item and its two enchant slots and nothing else; nampower's own limit there is the same ("Cannot inspect unit"). Tests: `the_character_panels_four_item_reads_all_answer`, `an_uncached_item_raises_the_dlls_own_miss_and_asks_for_the_row`, `the_slot_band_is_the_dlls_own_one_to_nineteen` |

## The client's own patches, read off `WoW.exe` — all 39 hook sites accounted for

The realm patches its client, and it leaves the patches **in PE sections it names after them**. The
launcher keeps that file current (it replaced it on 2026-10-23), so this is a first-class source
rather than a last resort: scan `.text` for a `jmp`/`call` whose target lands in one of those
sections and you have every entry point. There were 39, in two sections. Recipe and worked example:
`benilla-octo-exe-patches-are-readable` (the project memory) and
`FIELD_PLAYER_QUEST_LOG_21_1`'s doc comment.

`.octoql` (10 sites, VA `0xd26000`) is **one feature**: the extended quest log. Nine of the ten are
register shims calling one eight-instruction routine; the tenth detours
`GetNumQuestLogEntries`. Ported — `PLAYER_QUEST_LOG_SLOTS` is 25 and
`player_quest_log_field` holds both blocks.

`.tdata` (29 sites, VA `0xd06000`) is TurtleWoW's loader patch set. Its strings name it:
`twloader.dll`, `HARDCORE`, `GetSelectedChallengeModes`.

| Hook(s) | What the patch does | Status |
|---|---|---|
| `0x515c14` | a unit token spelled `0x` + 16 hex digits resolves as a raw GUID (parser at `0xd06650`, uppercase only; the `"Unknown unit name: %s"` arm is what it jumps ahead of) | **had the grammar, had the spelling wrong — fixed.** `unit::guid_token` wrote 16 lowercase digits and no prefix. Same number, wrong string: every addon that decides "is this a GUID" with `string.sub(g, 1, 2) == "0x"` (BigWigs `MageTools.lua:963`) read ours as a unit *name*, and every `sub(3, …)` field read came out two characters off. It now writes `0x` + 16 upper-case digits, the form the formatter at `0xd06500` lays down and AI_VoiceOver's own `format("0x%04X%06X%06X", …)` mints. Carried by `UNIT_CASTEVENT` and the aura events, so it was wrong where it mattered most; both spellings and either case are accepted on the way in |
| `0x51601b` | `UnitExists(unit)` returns the GUID as a second value | done |
| `0x51962e`, `0x519703` / `0x5199cd`, `0x519aec`, `0x519b14` | `UnitBuff` / `UnitDebuff` append the aura's spell id | done (`script/aura/mod.rs`) |
| `0x4e9223`, `0x4e924e`, `0x4e926e` | `GetLootMethod` appends the master looter's roster index (helper `0xd06720` scans the party/raid table at `0xb712a8` for the GUID at `0xbc7608`) | done (`PartyState::master_looter`) |
| `0x48bafd` | `CheckInteractDistance` type **4** compares against the float at `0xd06868`, which is `1600.0` | **fixed**: `INTERACT_DIST_SQ[3]` was stock 1.12's `900.0` (30 yd), now 40 yd |
| `0x49f7aa`, `0x49b193` | chat type `0x5E` is `CHAT_MSG_HARDCORE` | done |
| `0x5aad29` | appends the challenge mask to `CMSG_CHAR_CREATE` | done (`messages::client::char_create`) |
| `0x46abc4`, `0x46acf4` | registers / unregisters `GetSelectedChallengeModes` and `SetSelectedChallengeModes` as Lua globals (table at `0xd062a8`, registrar `0x704120`) | **nothing to do, and worth knowing why**: the realm's own `GlueXML/ChallengeList.lua:15-23` defines both in pure Lua `if type(…) ~= "function"`, for exactly our case. Its header says so. We already read the mask it sets |
| `0x5176d0`, `0x517726` / `0x517840`, `0x517886` | `UnitMana` / `UnitManaMax` append a second value read from `[unit+0x110]+0x44` / `+0x5c`, gated on a byte global being `0x0B` — on the evidence, a druid's real mana pool while shapeshifted. The `+0x60` hook of each pair exists only to preserve the unit pointer for the `+0xb6`/`+0xa6` one, which checks the first is installed by reading its own `jmp` opcode back | read, not ported: **nothing in the corpus reads a second return from either**, and the gating byte is a runtime value this static read cannot name. Port it when an addon asks |
| `0x48e2fe` | `GetItemInfo` appends one number, `[item+0x28]` | read, not ported: the field is unnamed and no addon reads an 11th return |
| `0x4ce715`, `0x4ce75d` | `GetAuctionSellItemInfo` appends a number (`[rec+0x60]`) and a string (`0x52ae00`), with the empty-slot arm padding to the same arity | read, not ported: same — unnamed fields, no consumer |
| `0x4f161a`, `0x4f1986` | `CreateMacro` arg 2 / `EditMacro` arg 3 take a branch when a type test passes, bypassing the stock handling | read, not ported: our `CreateMacro` already takes a numeric icon index (its own usage string's shape), and which *other* type this admits is not decidable from the branch alone |
| `0x505e19` | `Model:SetUnit` accepts a number (`lua_type == 3`) and clears three fields at `[frame+0x3e0/0x3e4/0x3f0]` | read, not ported: a GUID-as-model-unit, which nothing installed calls |
| `0x404100` | `LoadLibraryA("twloader.dll")` + `GetProcAddress("func1")` (helper `0xd06228`) | not applicable: benilla loads no DLLs, and that one is not even in the folder |
| `0x42a341` | raises an internal buffer bound (a global set to the section's own last byte) | not applicable |
| `0x5e8a71` | wraps an assert in `Player_C.cpp` with a GUID format | not applicable |

## Asking the DLLs what they publish — `scripts/dll-surface.py`

The same question for the six injected DLLs, which is harder: every one of them exports a single
`DllMain`/`Load` and registers with the client at runtime, so the export table says nothing.

**They do point at every name they register.** A DLL publishing a Lua function hands the registrar
a `const char*`, so the name is a NUL-delimited string in its data and the image holds a
little-endian pointer to it. Collecting identifier-shaped NUL-delimited strings, converting each to
its virtual address through the section headers, and keeping the ones the file points at is what
makes this usable: on `ClassicAPI.dll` it cuts 2,872 CamelCase candidates to 706. The script then
subtracts `reference/1.12-globals.tsv` (the client's own), Lua 5.0's keywords and standard library,
and benilla's real surface via `dump_globals` — and flags what the addon corpus actually calls.

It is a **candidate list, not a specification**: any pointed-at string survives, so statically
linked libraries contribute theirs (freetype's `BlueValues`, the CRT's `FlsAlloc`). Treat a name as
real when something else agrees — an addon calling it, or the mod's own docs. `UnitXP_SP3.dll` and
`fmod.dll` yield nothing at all, so the technique has a floor as well as a ceiling.

What it found that this file did not already have: **38 names in `nampower.dll` that grom's addons
call**, on top of the families the nampower section above already tracks. Unported, and listed
rather than guessed at — `CancelPlayerAuraSlot`, `CancelPlayerAuraSpellId`, `ChannelStopCastingNextTick`, `CombatLogFlush`, `CustomFileExists`, `EncryptPassword`, `EncryptedServerLogin`, `ExecuteCustomLuaFile`, `ExportFile`,
`CastSpellByNameNoQueue`, `CastSpellNoQueue`, `ChannelStopCastingNextTick`, `CombatLogFlush`,
`CustomFileExists`, `EncryptPassword`, `ExecuteCustomLuaFile`, `FindPlayerItemSlot`, `GetBagItem`,
`GetCastInfo`, `GetCurrentCastingInfo`, `GetItemIconTexture`, `GetItemIdCooldown`,
`GetSpellModifiers`, `GetSpellRangeData`, `GetTrinketCooldown`, `GetTrinkets`, `GetUnitData`,
`IsAuraHidden`, `LearnTalentRank`, `PlayerIsRooted`, `PlayerIsSwimming`, `QueueScript`,
`QueueSpellByName`, `UseItemIdOrName`, `WriteCustomFile`, the six `NP_EnableUnitEvents*` CVars, and
the events `SPELL_FAILED_SELF`, `SPELL_QUEUE_EVENT`, `UNIT_DIED`, `UNIT_HEALTH_GUID`. A name being
called is not proof an addon needs it — most sit behind an `if GetTrinkets then` — so the next step
is reading each call site, not implementing the list.

## The registration table — a complete list, where the pointer filter gives a candidate list

`scripts/dll-surface.py` above answers "what might this DLL publish". For `nampower.dll` there is a
**better** question available, and it has an exact answer: the names it registers sit **contiguously
in the string pool, in registration order, bracketed by the DLL's own log lines**.

```
$ strings -a -t x nampower.dll | awk '{a=strtonum("0x" $1); if (a>=0x7c6a8 && a<=0x7cb50) print}'
  7c6a8 Registering Custom Lua functions
  7c6cc QueueSpellByName
  7c6e0 CastSpellByNameNoQueue
  ...
  7cad0 ExecuteCustomLuaFile
  7cae8 GetQuestLogQuestIds
  7cafc GetQuestDialogQuestId
  7cb14 Registering Glue Lua functions
  7cb34 EncryptPassword
  7cb44 EncryptedServerLogin
```

That is the whole Lua surface: **60 functions plus 2 glue-screen ones**, no inference. Immediately
before it, the same way, is the **event** table (`0x7c198`–`0x7c658`, after the `Added custom event
code:` line): 59 names, from `SPELL_QUEUE_EVENT` to `SPELL_DISPEL_BY_OTHER`. Immediately before
*that*, after `Registering/Loading CVars`, the CVar names.

Why this works where the pointer filter only narrows: a compiler emits one string literal per
`lua_register(L, "<name>", fn)` call and pools them in source order, so a single registration
function's worth of names lands in one contiguous run. The log line that opens the run is the
giveaway — it is the literal immediately before the first name, because it is printed immediately
before the first call. **Look for the log line, then read forward until the strings stop looking
like identifiers.** Nothing else was needed, and it is strictly better evidence than "the image
points at this string": a statically linked library's `BlueValues` cannot land inside the run.

Two other things fall out of the same pool, and both corrected code that was already written:

- **Usage strings are the argument contract.** `strings -a nampower.dll | grep '^Usage:'` returns 44
  of them, each the exact spelling the DLL prints when a call's arguments are wrong — e.g. `Usage:
  GetSpellModifiers(spellId, modifierType) - modifierType: 0=DAMAGE, 1=DURATION, …` enumerates all
  26 modifier constants, and `Usage: GetSpellRangeData(rangeIndex)` says that verb takes a
  `SpellRange.dbc` **row index** and not a spell id, which this file previously had wrong.
- **`GetItemIconTexture` took the wrong argument here, and the usage string is how that was found.**
  `Usage: GetItemIconTexture(displayInfoId)` — an `ItemDisplayInfo` row id, the exact sibling of
  `GetSpellIconTexture(spellIconId)`. Ours resolved an *item* id through the cache to its display id
  first, which is a different function: upstream's addon layer keeps that hop in a wrapper of its
  own (`NampowerAPI.lua:2648` is the pass-through, `:2665` is `GetItemIconTextureByItemId`). Fixed,
  with the test now pinning that an item id answers **nothing**.

Three of the four field-name blocks are in the pool too, in table order, which is how
`GetCastInfo`'s ten fields and the cooldown table's twenty were read without guessing: `castId`,
`spellId`, `guid`, `castType`, `castStartS`, `castEndS`, `castRemainingMs`, `castDurationMs`,
`gcdEndS`, `gcdRemainingMs` at `0xa8854`, then `isOnCooldown` … `isOnGcdCategoryCooldown` at
`0xa88d4`.

## The DLL work list, name by name — `scripts/dll-surface.py`'s output, worked

The script above enumerates what the DLLs publish; this is what came of reading each name's call
sites in grom's own corpus. **The single most useful thing found was not a missing function.**
`SuperCleveRoidMacros/NampowerAPI.lua` is a capability registry: a `VERSION_REQUIREMENTS` table
naming every nampower function with its minimum version, reached through `API.HasFeature`, which
checks the version **and** `_G[name] ~= nil` (`:448-465`). So nothing on this list was *broken*, and
raising `GetNampowerVersion` would not have helped — the only honest way to make one of these live
is to define the global. Read a call site before implementing: the first pass of the script flagged
25 names as "unguarded" that were doc comments and table keys inside that registry, and pfUI's
`GetCastInfo` is its own file-local function (`modules/nameplates.lua:105`), not nampower's.

**Done (22 as of the round that wrote this, and the Built row below is the live count).** `PlayerIsMoving`, `PlayerIsRooted`, `PlayerIsSwimming`, `IsAuraHidden`,
`GetItemIconTexture`, `GetTrinkets`, `FindPlayerItemSlot`, `GetBagItem`, `GetItemIdCooldown`,
`UseItemIdOrName`, `CancelPlayerAuraSpellId`, `CancelPlayerAuraSlot`, `CastSpellNoQueue`,
`CastSpellByNameNoQueue` (nampower), `GetQuestIDForLogIndex`, `GetQuestLinkForLogIndex` (SuperWoW).
Plus the six `NP_EnableUnitEventsX` CVars, registered stored-only. Each has its row in
`reference_surface.rs`'s `allowed_beyond_1_12` saying why 1.12 has no spelling to prefer.

**Already present, counted as missing by the script.** `IsSwimming`, `IsMounted`, `IsIndoors`,
`SpellInfo`, `SetAutoloot`, `GetPlayerBuffID`, `SetMouseoverUnit`, `UnitExists`'s GUID return,
`UnitBuff`/`UnitDebuff`'s aura ids, `GetLootMethod`'s master looter, `UNIT_CASTEVENT`,
`RAW_COMBATLOG`. The script compares against `dump_globals` on a **bare** VM, so a verb installed
later and an *event* (never a global at all) both read as absent. Subtract those before counting.

**The nine file and credential functions — built, on grom's explicit say-so.** They were withheld
for a round and the reason recorded ("the right default for a client that did not have them
yesterday is not to grow them silently"); he said yes to all nine. Both halves of that decision
stay here, because the reasoning is what makes the second half a decision rather than a drift.

| Name | Where it lands |
|---|---|
| `ReadCustomFile`, `ImportFile` | one operation under two names (upstream registers both); the file's **bytes** as a Lua string, so a binary file round-trips |
| `WriteCustomFile`, `ExportFile` | `mode` `"a"`/`"append"` adds, anything else replaces; `ExportFile` has no mode and always replaces. Both answer `1` or nil, so a caller can report a failure the player can fix |
| `CustomFileExists` | `1` or nil, and `is_file` rather than `exists` — a directory of that name is not a file this family can read |
| `ExecuteCustomLuaFile` | loads and runs the chunk at global scope, named `@<filename>` so a traceback points at the player's file. A missing file is nil; a **broken** one raises, because that is the distinction worth the most on a file edited by hand |
| `StartItemExport` | writes the item cache as TSV to `ItemExport.txt`. **Deviation**: upstream's name implies a server sweep; this exports the rows the session already saw. A sweep is a few thousand `CMSG_ITEM_QUERY_SINGLE`s at the realm, which is not something a Lua call should start |
| `EncryptPassword` | the blob, from `benilla-app`'s `credential.rs` |
| `EncryptedServerLogin` | **upstream logs in; this remembers** — see below |

**The fence is app-side, and it is not a `..` scan.** `local_state::custom_file_path` admits one
relative name whose every component is an ordinary name, inside `benilla-config/CustomFiles/`, and
refuses a leaf that is already a **symlink**. The escapes a string check misses, each with its own
rule: an absolute path (`join` *replaces* the base rather than appending), a Windows prefix
(`C:\…`, `\\server\share`), a `..` nested inside a longer path, and a planted symlink — which is
the one that no amount of sanitising the string will catch. nampower writes relative to the
client's working directory, the install root, which is read-only here; a *subdirectory* of the
config folder rather than its root, because a verb that could create `config.toml` or
`autologin.toml` by name would let an addon rewrite the client's own settings. That is a different
power from "keep a file of your own", and it is not the one being granted.

**The credential pair's deviation is forced, not chosen.** Both are registered by nampower under
"Registering *Glue* Lua functions" — the login screen's VM — and this client has **no glue Lua VM
at all**: login, character-select and character-create are Rust (`autologin.rs`'s header sets that
out at length). `EncryptPassword` is a pure function and works the same wherever it is defined.
`EncryptedServerLogin` cannot mean "submit the login form" in the only VM there is, because in it
you are already in the world. What the pair is *for* is a password on disk as a blob rather than as
itself, so it stores the credential for the next login instead: `enabled` on, the plaintext field
**cleared**, the blob kept, and `AutoLogin::effective_password` reads it back at the next refill.

What that protects: an `autologin.toml` or a SavedVariables file read by someone else or pasted into
a forum. The blob is authenticated and keyed on 32 random bytes in a **different file**
(`benilla-config/credential.key`, mode `0600`). What it does not protect: anything running as this
user, which can read the key as easily as the blob — there is no user secret in the chain and there
cannot be, because the point is logging in without typing one. The construction is encrypt-then-MAC
with HMAC-SHA1 as the PRF for both halves, from the two primitives this tree already had; the HMAC
is tested against RFC 2202's own vectors, because a hand-written one still round-trips with itself
when it is wrong.

**Not wire-compatible with nampower's blobs**, and it cannot be: that scheme is undocumented and a
key file generated here would not decrypt one made there whatever the cipher. A blob copied from a
real install answers nil, which the drain reports rather than storing — a stored credential that
cannot be read back is a login box that silently refills empty.

**The tick-box now writes the blob** — asked for explicitly, a round after the machinery landed.
Storing the password in plaintext had been grom's own choice when the alternatives were a keyring
or nothing, so the round that built these two verbs left that path alone and said what switching
it would cost; this is the switch, not a side effect of the port. `AutoLogin::remember` is the one
write path, `migrate_plaintext` upgrades a file written by an older build, and the plaintext field
stays *readable* so that upgrade cannot lock anyone out of their own store.

**It cost grom his stored password once, and that is worth writing down.** While this was being
built, two unit tests ran concurrently: one redirected the config directory through
`BENILLA_HOME`, which is process-wide, and the other stood up `LoginPlugin`, whose `build` now
called `migrate_plaintext`. So his real `autologin.toml` was upgraded against a key file that was
not the one beside it — the plaintext was cleared and the blob it was replaced with does not
decrypt. He has to type the password once more; `remember` then stores it correctly, because a
blob that answers empty does not match and is re-sealed.

Two fixes, and the second is the one that matters: the migration is now `#[cfg(not(test))]`, so a
test cannot write to the player's own config at all; and **`sealed` encrypts and then reads the
blob back, refusing to clear the plaintext unless the round trip holds**. The second would have
prevented it on its own. The general shape of the mistake is the one `credential.rs` already
carries a note about — a scheme that round-trips with *itself* while being wrong — one level up:
here the cipher was right and the *key* was the thing that disagreed, and the only copy of the
password was thrown away before anyone checked.

Two decisions inside it worth naming, because both are places a convenient answer is the wrong
one. **A password that cannot be encrypted is not stored at all** — no fallback to the clear
field: the player cannot see the difference between a box that stored a blob and one that quietly
stored plaintext, so a silent downgrade is worse than a box that visibly did not take. And **a
stale plaintext field beside a blob is cleared rather than encrypted**: `effective_password` never
read it, so encrypting it would promote a password the player has already replaced.

**Everything below this line is the reasoning of earlier rounds, kept rather than deleted.** Each
section records what was missing *then*, what it would have taken, and — where a later round built
it — which of those reasons turned out to be wrong. That is the point of keeping them: three of the
"needs a feed" rows were answerable with data the tree already had, and a list of only the final
answers would hide that the first reading was the expensive mistake.

### The cast feed — `GetCurrentCastingInfo`, `GetCastInfo` and `SPELL_CAST_EVENT`

**Built**, and the reason this pair came first is measurement rather than taste: they are the
most-called nampower functions in grom's corpus (25 and 20 sites outside `NampowerAPI.lua`), and
one of those sites calls `GetCurrentCastingInfo` with **no existence guard at all** —
`local _,_,_,_,_,_,autoattack = GetCurrentCastingInfo()` (`SuperCleveRoidMacros/Core.lua:94`), in
the deferred-stop frame that keeps clearing the target while an autoattack is queued. On a client
without the function that line raises.

What the earlier "needs a feed" row said was true of `PendingCast` and wrong about the client as a
whole: this tree already folds a **cast window per caster** off the same packets (`UnitCastState`
in `ui_cast_events.rs`, behind `C_Spell.UnitCastingInfo`), with a start, an end, a channel bit and
the accumulated pushback. What was genuinely missing was the *caster's own machinery* — the
reference's cast globals — and the GCD, which `spell/cooldowns.rs` has run correctly all along and
never published.

| Piece | Where |
|---|---|
| `SelfCast`, eleven columns: the inflight spell `0xceca88`, the bar's spell `0xceac48`, the auto-repeat key `0xceac30`, four flags, the cast counter, the cast type, the target, and the GCD's start/end on the `GetTime()` clock | `benilla-ui`'s `script/model.rs` + `script/self_cast.rs` |
| The per-tick push, and `SPELL_CAST_EVENT` fired off the same commit | `benilla-app`'s `ui_self_cast.rs`, in `UnitFeed` after the cast-window drain so the two halves of `GetCastInfo`'s table cannot describe different casts |
| `Cooldowns::gcd` — the running global cooldown as one timer | `spell/cooldowns.rs`, the longest running GCD leg, which is the one a player is waiting on; `info` still answers the per-category question every cooldown swirl asks |
| `PendingCast`'s cast counter | `spell/inflight.rs`; the one place every class of commit passes through, which is why it is there and not in the send path |
| The commit rows (`castType`, target, item) | `spell/cast_send.rs`, at the two commits — the plain send and the targeting-cursor click, which is the only arm that produces `TARGETING`/`TARGETING_NON_GCD` |

Three decisions worth having written down, because each had a tempting wrong answer:

- **`GetCastInfo` is nil when nothing is casting, and an instant's GCD does not count.** The
  shortcut is to answer a table whenever the GCD is up, so the consumer's fast path always hits.
  But `API.IsCasting()` *is* `GetCastInfo() ~= nil` (`NampowerAPI.lua:1888`), and `[casting]` is a
  macro conditional players gate abilities on — a table there would make it true for a second and
  a half after every instant. The wrapper's own fallback comment says what to do instead
  ("`GetSpellIdCooldown` … works for instant casts").
- **`castId` means two different numbers under one upstream name.** In `GetCastInfo`'s table it is
  a counter, beside a separate `spellId` column. In `GetCurrentCastingInfo`'s returns it is a
  *spell id*, which is how both of its readers treat it (`Init.lua:89` stores it as
  `castingSpellId`; `Core.lua:5427` hands it to `C_Spell.GetSpellName`). Both are implemented as
  what their own consumers read.
- **`SPELL_CAST_EVENT` fires for commits, not for refusals.** Upstream's `success` column can be
  0; this client's local refusals all funnel through `CastErrors`, which carries a spell id and a
  reason byte and neither a cast type nor a target, so a row from there would invent two of five
  fields. Nothing in the corpus reads the failing branch — `Core.lua:5177` is one
  `if success == 1 then` with no else.

### nampower's cast events — the ten off the one queue

**Built.** All ten ride `ui_cast_events.rs`'s existing `CastEventFeed` rows — the same rows
`UNIT_CASTEVENT` and the cast windows are folded from — with `NpCastColumns` carrying the fields
nampower's shapes want and SuperWoW's word has no place for. One row per packet, folded once, which
is this file's own rule: an addon woken by one of these and then asking a getter must not be able
to get a contradicting answer, and a parallel queue reading the same packets is exactly how that
happens.

`NP_EnableSpellStartEvents` and `NP_EnableSpellGoEvents` are now **live** (they were stored-only),
gating the START and GO pairs; the other five have no switch in the DLL's own CVar table and fire
unconditionally, as upstream's do. Both are written to `"1"` at login by `NampowerAPI.lua:2894-2902`
and by pfUI's `libs/libdebuff.lua:56-88`.

The stored-only rows claimed their shapes wanted "itemId/spellType/corpseOwnerGuid columns this
client does not carry". Two of those three turned out to be a `Spell.dbc` lookup and a guid hop the
item-cooldown path already made:

| Column | Where it comes from |
|---|---|
| `itemId` (`arg1` of START and GO) | the cast item's guid through the same two hops `item_cooldown` makes (the guid index, then `OBJECT_FIELD_ENTRY`), now one shared `item_entry` helper. `SMSG_SPELL_START` carries the guid and `SessionEvent::SpellStart` was dropping it; it carries it now, as the GO's always did |
| `spellType` (`arg8` of START: 0 normal, 1 channel, 2 autorepeat) | the spell's own attributes — `AttributesEx & 0x44` for a channel, the auto-repeat bit for a shot. The wire says nothing about either |
| `channel_ms` (`arg7` of START) | `SpellDuration.dbc`, under exactly the conditions `aura_duration_ms` will answer one at all. Not on the wire: a channeled spell's START carries `cast_time_ms` 0 and the length arrives a round trip later in `MSG_CHANNEL_START` — which is the case pfUI's reader names ("only for true channels like Blizzard where arg6 is 0/nil") |
| `numTargetsHit`/`numTargetsMissed` (`arg6`/`arg7` of GO) | the packet's own two lists, capped at 255 because the server writes both counts as `u8`s |
| `spellResult` (`arg2` of `SPELL_FAILED_SELF`) | the failing `SMSG_CAST_RESULT`'s reason byte — the number 1.12 turns into a red line and discards |
| `corpseOwnerGuid` | **not sent**, and this is the one that really is absent. A trailing nil in Lua is indistinguishable from an absent return, and upstream sends nil for every cast without a corpse target. For the handful that have one the gap is bounded: `read_spell_cast_targets` reads the corpse guid and drops it, and the *owner* is a further hop through that corpse object's `CORPSE_FIELD_OWNER`. Nothing in grom's corpus reads the column |

Two subtleties worth having written down:

- **A channel's START is queued although its wire cast time is 0, and `UNIT_CASTEVENT`'s START is
  still suppressed for it.** Without the row, `SPELL_START_SELF` would never fire for Mind Flay or
  Blizzard; with the word, every cast-tracking addon on this realm would get a SuperWoW START whose
  `arg5` is 0 — a cast bar told to run for no time. The suppression moved from the producer
  (`cast_time_ms > 0`) to the fire, so SuperWoW's word behaves exactly as it did before the row
  existed. An instant is the other zero case, and the wiki's own START/CAST split says its only
  edge is the CAST.
- **The `_SELF`/`_OTHER` split is by caster here, and by *target* for the aura family next door.**
  Neither is a guess: upstream's wording for the aura pair is "casts that land on the active
  player", and for this one pfUI handles both names in a single arm and then reads `arg3` to learn
  the caster — which only makes sense if the name already settled it.

**A gate hole closed on the way past.** `AURA_CAST_ON_SELF`/`_OTHER` were fired through one `&str`
variable, and `reference_ui.rs`'s beyond-1.12 event gate reads the string literal *at the call* — so
it had been blind to that pair for as long as they had existed. Both fire sites are literals now,
with their rows; verified by probe (renaming either row makes the gate name it).

### The bag, modifier and cooldown group — and two more shapes the string pool corrected

**Built: `GetBagItems`, `GetSpellModifiers`, `GetSpellIdCooldown`.** Plus two fixes to verbs that
already existed and had the wrong *shape*, both found the same way as `GetItemIconTexture`'s wrong
argument — by comparing what we answer against the DLL's own string pool.

| Verb | What it needed |
|---|---|
| `GetBagItems()` | every occupied bag slot as `{ [bagIndex] = { [slot] = row } }`. DoiteAuras asks seven times over and walks both levels with `pairs`, reading `itemInfo.itemId` and `itemInfo.stackCount` — it is how that addon answers "do I have this item" without 100 `GetContainerItemInfo` calls per condition evaluation. Empty slots and empty bags are **absent**, because a nil value in a Lua table *is* absence and `pairs` is how both levels are read |
| `GetSpellModifiers(spellId, modifierType)` | `flat, percent, hasModifier`, where `percent` is the **final multiplier** (90 means 90% of the original) — the consumer says so in its own words and multiplies by `percent / 100`. The 26 modifier types come from the DLL's usage string. The fold is `spell/mods.rs`' existing reader, reached through a new `Model::spell_modifier_probe` the lifecycle **reinstalls** whenever the wire moves the tables: a VM-side reimplementation of a four-gate 64-bit fold would be free to drift from the mana cost the action bar greys a button on |
| `GetSpellIdCooldown(spellId)` | the twenty-key cooldown table, from a new `Cooldowns::legs` — `info`'s three legs kept apart, same walk and same arms, so the folded number a swirl draws and the legs an addon reads cannot describe different timers. Fed beside the folded triple by the spellbook, the pet book and the bag feeds |

**`GetBagItem`'s row had the wrong key names.** It answered `bag`, `slot`, `count`, `texture`,
`quality`, `link`, `locked` — this client's own `GetContainerItemInfo` spellings. nampower's row is
`itemId, permanentEnchantId, tempEnchantId, randomPropertiesId, stackCount, duration,
spellChargesRemaining, flags, durability, maxDurability, tempEnchantmentTimeLeftMs,
tempEnchantmentCharges`, plus `bagIndex`/`slotIndex` — contiguous at `0xa8a68`, and the same block
`GetEquippedItem` already used. So a caller reading `.stackCount` got nil and no error. Now one
`bag_slot_table` serves `GetBagItem` and `GetBagItems`, with three columns **absent rather than
zeroed**: this client resolves a bag slot's enchants to `SpellItemEnchantment` *names* at the app
boundary and keeps no random-properties id for a container slot, so `permanentEnchantId`,
`tempEnchantId` and `randomPropertiesId` are not there. A zeroed enchant id would be a claim.

**`GetItemIdCooldown` returned the wrong *kind* of value.** It answered `start, duration, enable` —
the stock triple. At the version we report it is a table, and the addon layer is what settles it:
`API.GetItemCooldownInfo` and `API.GetSpellCooldownInfo` **return these calls' results directly**
(`NampowerAPI.lua:1950`, `:2035`) and their callers index them. `cd.gcdCategoryRemainingMs` is the
primary path of `API.GetGCDRemainingMs`, which the `[gcd]` and `[nogcd]` macro conditionals divide
by 1000 — against a triple that is `(0.0).gcdCategoryRemainingMs`, which raises. Nothing in the
corpus calls those two wrappers today, so the bug was latent rather than live; it was still wrong.

Two decisions written down at the code:

- **Every `*RemainingMs` is derived in the binding, from `GetTime()` and the leg's absolute
  start.** A remainder is the one column that changes every frame, and pushing it would churn the
  spellbook diff sixty times a second — the feed's own note says the absolute start is what keeps a
  running cooldown out of that diff.
- **The reach is the player's book, pet book and bags, which is narrower than upstream's.** It
  reads the client's whole `SpellHistory`; this reads the per-slot legs those feeds already carry.
  For a spell the player has not learnt the answer is the same either way, and the one live
  consumer asks about a book spell by construction (`API.GetGCDRemainingMs` probes with
  `GetSpellName(1, BOOKTYPE_SPELL)`).

**One count the earlier sweep got wrong, worth correcting here**: `GetSpellPower`'s "7 call sites"
are `BetterCharacterStats`' own method `BCS:GetSpellPower(school)`, not nampower's global. Nothing
in the corpus calls the global at all — the only mention is a comment in
`SuperCleveRoidMacros/ClassicAPI.lua:272` saying it reads the same client field. A bare name match
is not a call site.

### The `Spell.dbc` row — `GetSpellRec` and seven columns `GetSpellRecField` answered nil for

**Built**, and this one is a measured gap rather than a completeness exercise. Counting what the
corpus actually asks `GetSpellRecField` for: `name` (4 sites), `school` (3), `stackAmount` (2),
`spellIconID` (2), then one each of `rank`, `rangeIndex`, `mechanic`, `manaCost`,
`effectMechanic`, `effectApplyAuraName`. **Seven of those ten answered nil** — the binding knew
three names. DoiteAuras caps its stack display on `stackAmount` (`DoitePlayerAuras.lua:539`) and
`SuperCleveRoidMacros` classifies a crowd-control effect off the two arrays
(`Utility.lua:7776-7794`), so each nil was a feature quietly off.

The names are the DLL's own, read off its pool in `Spell.dbc` column order (`0x91d68`–`0x92460`):
eighty of them. The mapping to `benilla_formats::SpellDisplay` lives in
`benilla-app`'s `ui_script/spell_rec.rs` — beside the struct it reads, because a copy on the VM side
would be free to drift — and `GetSpellRec(spellId)` is that same field list walked through that
same per-field reader, so the two verbs cannot answer differently for one name. A test asserts
exactly that, key by key, over one row.

**The array columns are a 1-based table of three, which is measured and not guessed.**
`SuperCleveRoidMacros` walks `GetSpellRecField(spellID, "effectMechanic")` as
`for i = 1, 3 do local em = effectMechanics[i]`. `totem`, `reagent` and `reagentCount` take the
same shape, two and eight long.

One new DBC column: `StackAmount`, column **39**, bracketed by two constants this tree already had
(38 `ModalNextSpell`, 40 `Totem[0]`). It is the only one added — fifteen further names upstream
answers are left nil rather than putting fifteen unused `u32`s on a struct the spell catalog holds
one of per row. They are listed at `FIELDS` with that reason, so the gap is a decision and not an
omission: `attributesEx4`, `targetCreatureType`, `procFlags`, `procCharges`,
`manaPerSecondPerLevel`, `maxTargetLevel`, `maxAffectedTargets`, `dmgClass`, `spellPriority`,
`spellVisual2`, `minFactionId`, `minReputation`, `requiredAuraVision`,
`effectPointsPerComboPoint`, `dmgMultiplier`.

`GetSpellRecField`'s three string columns keep the spellbook fallback the verb had before the
probe: a VM with a book and no catalog — a capture, or the boot VM before `ui_action`'s loader
runs — still answers a learnt spell's name and rank, which is what `GetSpellNameAndRankForId`
beside it does from the same `spell_display`. Every other column is a DBC row and has nowhere else
to come from.

### The trinket cooldown — and a stock verb that had been answering "cold" since it was written

**Built: `GetTrinketCooldown`, `UseTrinket`, `GetSpellRangeData`, `SetLocalRaidTargetIndex`,
`GetQuestLogQuestIds`, `GetQuestDialogQuestId`, `CombatLogFlush`.**

The find on the way through is not a nampower verb. **`GetInventoryItemCooldown` is a stock 1.12
verb and it answered `(0, 0, 1)` unconditionally** — the shape was right and the number was always
"cold", so nothing errored and no worn trinket ever drew its cooldown swirl on the character pane.
Stock `PaperDollFrame.lua:691` calls it on every slot update. Feeding an equipped slot's cooldown
for `GetTrinketCooldown` fixes that one too, off the same column, and the test runs
`CooldownFrame_SetTimer`'s own arithmetic against it.

The feed is `ui_char::slot_view`, keyed on the (use spell, item entry) pair exactly as the bag
feed's is — `Cooldowns::info` matches an item record on both — so one trinket reads the same
cooldown from the doll and from a bag.

**The risk in that change was the gate, and the first test for it was vacuous.** `feed_char` is
behind a change gate, and no descriptor moves when a cooldown is armed, so `Cooldowns::feed_epoch`
had to become a gate input or the swirl would appear only on the next frame something unrelated
changed. The first test passed with that input deleted: `run_system_once` builds a fresh system
each call, so the gate's `Local` memo resets and `vm_reset` opens the gate every time. A test for a
gate input has to run the system through the schedule (`add_systems` + `update`), or it proves
nothing. Rewritten that way, it fails with the input removed — verified by probe.

Two also worth recording:

- **`GetSpellRangeData(rangeIndex)` answers three values, not a table.** Every table-returning verb
  in this DLL has its key names in the string pool; this row's are not there, so a flat row is what
  it answers. `flags` bit 0 is the melee family, where the engine takes the combat-reach sum
  instead of the authored pair — a caller that ignores the bit reads 0..5 for every melee ability,
  which is why the binding says so.
- **`CombatLogFlush()` is a no-op, deliberately defined.** Upstream buffers its combat-log writes
  and this empties the buffer, so what an addon asks for is "my lines are on disk now".
  `ui_chat/logging.rs` writes each line to an **unbuffered** `std::fs::File` as the window shows
  it, so that postcondition already holds at all times. Defining it is the honest answer: the
  capability is present, and a missing global makes `HasFeature` report it absent when it is not.

**The four measured-out names — built too, on grom's "62/62".** Each had a reason for being out;
each reason turned out to be answerable, and where it was not the deviation is stated.

| Name | What it took, and what it cost |
|---|---|
| `GetSpellPower(school)` | **delegated to `GetSpellBonusDamage`**, which this client already answered. They are one number under two mods' names — `SuperCleveRoidMacros` says so itself ("Reads the same client field nampower's `GetSpellPower` does") — and delegating is the only way to guarantee they cannot drift. The earlier "needs a descriptor band fed" was wrong: it was already fed |
| `GetRaidTargets()` | the 8-slot **board**, now pushed beside the party roster. The earlier reason — "a scan over named tokens would silently omit a marked unit" — was right about the scan and wrong about the alternative: `GroupState::raid_targets` is the reference's own table and copying it costs eight words a push. A mark with nothing on it is **absent**, because a zero GUID is a string that passes `if t[4]` |
| `LearnTalentRank(page, index, rank)` | one `LearnTalent` press per missing rank, which is what a player clicking the button does. The earlier reason — the burst cannot be checked before it is sent — is true and is not a reason to withhold it: the check that matters is the server's and the client has never had another. What *can* be checked locally is, so a rank already held queues nothing and one past the maximum is clamped rather than sending presses the server will refuse |
| `GetUnitData(unitToken, [copy])` | the whole descriptor, from a new raw block on `UnitState` (`ui_script/unit_rec.rs`). The earlier reason — "a decision about which fields" — is now a table of seventy columns under the DLL's own names, and `GetUnitField`'s scalar half reads the same block, so the two cannot answer differently for one name |

**The indices for `GetUnitData` are derived, and the derivation is checked.** Only thirteen
`FIELD_UNIT_*` constants existed in this tree; the rest come from 1.12's `UnitFields` block sizes.
Those thirteen are spread from index 22 to 147, and every one lands exactly where the layout puts
it — thirteen independent confirmations, run as a test rather than asserted in a comment, alongside
one that no two columns overlap and one that nothing falls inside the aura blocks' 47..=124.

Three decisions at that mapping:

- **An unstreamed column is absent, not zero.** `at()` is `get_raw`'s strictness rather than
  `get_u32`'s absent-is-zero convenience: `health = 0` for a unit whose health has not arrived is a
  number a caller divides by, and nil is what their own guard already tests.
- **`aura` and `auraApplications` come from the filtered per-unit aura list**, not the raw slots —
  the same place `GetUnitField` has always answered them from. The two verbs must not disagree
  about which auras a unit has, and the filter drops exactly the ones a tracker does not want.
- **`status` and `zoneId` are left out** of nampower's seven computed columns. Nothing in the
  string pool or the corpus says what `status` is a status *of*, and a zone is only knowable for
  the player. The other five (`guid`, `posX`, `posY`, `power`, `maxPower`) are filled by the
  caller, which knows them.

### The queue, and the one verb that needs it — 62/62

**Built**, on grom's "62/62": `QueueSpellByName`, `QueueScript`, `ChannelStopCastingNextTick` and
`DisenchantAll`.

> **Superseded by "The press-interception half, built" below.** The paragraph that stood here said
> the press half was deliberately unbuilt and its twenty CVars stored-only. It is built now, on
> grom's say-so and with a live test to follow; the slots are still the ones described in this
> section, because upstream has one queue.

**Upstream's queue has two halves, and both are built now.** The Lua surface — "remember this spell
and send it when the client will accept it" — is `spell/queue.rs`, below. The half that intercepts
**every ordinary press** is `spell/np_press.rs`, and the section after this one covers it. They
share the three slots and the one `SPELL_QUEUE_EVENT`: upstream has one queue, and a second set of
slots beside it would be a different feature wearing the same name.

**Three slots, because upstream has three and its own event says so.** `SPELL_QUEUE_EVENT`'s first
argument is `0`/`1` on-swing queued/popped, `2`/`3` normal, `4`/`5` non-GCD — so the queue is keyed
by what *kind* of cast a spell is, and the kind comes off its own `Spell.dbc` row through the same
three tests the send path makes. Each slot pops on its own condition: non-GCD and on-swing as soon
as no cast guards (neither uses the global cooldown), normal when the GCD has run out too.

Three decisions at the queue:

- **A replacement raises no popped event.** A second queue of one kind replaces the first — which
  is upstream's own behaviour, its log line being `Replacing queued nonGcd spell X with Y` — and the
  replaced entry was never sent. A consumer counting pops against queues would otherwise see one
  too many.
- **An expiry raises nothing either.** `*_POPPED` means "this spell was sent"; a timed-out entry
  was not, and upstream has no code for one.
- **The expiry is measured from the end of the cast in flight**, not from the moment of queueing,
  so a player who queues early during a three-second cast is not punished for it. A lapsed
  deadline cannot shorten the window below a fresh queue's.

**`DisenchantAll` is specified completely by the DLL's own strings**, which is why it is built the
way it is rather than designed here. `0x93087`–`0x932d0` carries the argument note
(`includeSoulbound: optional number - pass 1 to include soulbound items (defaults to 0)`), the
precondition (`You do not have the Disenchant spell`), the three quality keywords (`greens`,
`blues`, `purples`), every stop reason, and the three chat lines — one of them as a Lua chunk that
builds the item link with `GetContainerItemLink`.

**"move during cast to cancel" is the abort, and it needed nothing new.** Moving already cancels a
cast here (`inflight.rs`'s `local_self_cancel`), the cast then fails, and a failed cast stops the
run — so the one piece of machinery a sequencer usually needs is the client's own, and the player's
way out is the one upstream documents.

**How a step's outcome is read: the item is gone, or it is not.** There is no "disenchant
succeeded" packet; what happens is the item leaves the bag. Each step remembers the guid it cast at
and waits for it to vanish, with a ten-second deadline. Gone is success and the run continues;
still there past the deadline is a failure and the run stops with upstream's own line. An
observable test with no new wire plumbing — right for the same reason the cast bar's own edges are,
that the thing the player sees is the thing the client keys on.

### The whole registered list, accounted for

With the registration table read (the section above), the surface is no longer a count of what a
heuristic flagged. It is **62 names**, every one of which is now in exactly one of these buckets.
`comm -23` against `dump_globals` is the check, and it is reproducible:

```
strings -a -t x nampower.dll \
  | awk '{a=strtonum("0x" $1); if (a>=0x7c6cc && a<=0x7cb50) {$1=""; print substr($0,2)}}' \
  | grep -E '^[A-Za-z_][A-Za-z0-9_]*$' | sort -u > /tmp/np
cargo run -q -p benilla-ui --example dump_globals | cut -f1 | sort -u > /tmp/ours
comm -23 /tmp/np /tmp/ours
```

| Bucket | Count | Names |
|---|---|---|
| **Built** | **62** | `CancelPlayerAuraSlot`, `CancelPlayerAuraSpellId`, `CastSpellByNameNoQueue`, `CastSpellNoQueue`, `ChannelStopCastingNextTick`, `CombatLogFlush`, `CustomFileExists`, `DisenchantAll`, `EncryptPassword`, `EncryptedServerLogin`, `ExecuteCustomLuaFile`, `ExportFile`, `FindPlayerItemSlot`, `GetBagItem`, `GetBagItems`, `GetCastInfo`, `GetCurrentCastingInfo`, `GetEquippedItem`, `GetEquippedItems`, `GetItemIconTexture`, `GetItemIdCooldown`, `GetItemLevel`, `GetItemStats`, `GetItemStatsField`, `GetNampowerVersion`, `GetPlayerAuraDuration`, `GetQuestDialogQuestId`, `GetQuestLogQuestIds`, `GetRaidTargets`, `GetSpellDuration`, `GetSpellIconTexture`, `GetSpellIdCooldown`, `GetSpellIdForName`, `GetSpellModifiers`, `GetSpellNameAndRankForId`, `GetSpellPower`, `GetSpellRangeData`, `GetSpellRec`, `GetSpellRecField`, `GetSpellSlotTypeIdForName`, `GetTrinketCooldown`, `GetTrinkets`, `GetUnitData`, `GetUnitField`, `GetUnitGUID`, `ImportFile`, `IsAuraHidden`, `IsSpellInRange`, `IsSpellUsable`, `LearnTalentRank`, `PlayerIsMoving`, `PlayerIsRooted`, `PlayerIsSwimming`, `QueueScript`, `QueueSpellByName`, `ReadCustomFile`, `SetLocalRaidTargetIndex`, `SetMouseoverUnit`, `StartItemExport`, `UseItemIdOrName`, `UseTrinket`, `WriteCustomFile` |


**62 of 62.** The `comm -23` above is the check, and it prints nothing.

`CastSpellNoQueue` and `CastSpellByNameNoQueue` became meaningful with the press half: they take
the ladder entry that skips the queue (`CastLadder::send_now`), so a macro that has already decided
*when* to cast is not held by the client deciding to cast later instead. Before the press half they
were the plain cast, which was the honest mapping at the time and is no longer the whole story.

### The press-interception half, built

`spell/np_press.rs`. A press that the client would refuse for a **timing** reason is held in the
same slot an explicit `QueueSpellByName` would use, and the drain sends it the moment the guard
clears. No packet, no global cooldown, no error line while it waits.

**Where the rung sits, and the one deviation that comes of it.** Five rungs stay above it — the
profession opener, the auto-repeat re-press, the dead caster, the targeting cursor's clear and the
on-swing re-press — because each is what the press *means* whatever is in flight, and holding them
would change the meaning. Everything below it is a real refusal the player should read: no reagent,
no weapon, out of range, no power, stunned, moving, wrong form. Upstream hooks the client's cast
entry and so holds presses that would fail for those reasons too, which means its error arrives
when the entry pops, a second later, about something the player has stopped doing. Refusing them
immediately is the deviation, and it is the better half of the trade.

**What a window measures.** Upstream publishes four and no sentence saying. Two readings fit the
names: how long an entry survives, or how close to the guard's end a press must land. This takes
the first, for three reasons — `spell/queue.rs` already reads `NP_SpellQueueWindowMs` that way, and
one number meaning two things in one client is a trap nobody finds twice; upstream's own `Replacing
queued nonGcd spell X with Y` means the last press wins, so holding every press costs nothing in
staleness; and the admission reading would make the 250 ms cooldown window refuse almost every
press made during a global cooldown, which is the exact complaint nampower exists to answer.

Two rows do read a window as a threshold on remaining time, and both say so themselves:
`NP_InterruptChannelsOutsideQueueWindow`, whose name states one, and `NP_CooldownQueueWindowMs`,
which has to be one. A cast or a global cooldown ends in a second or two; a spell's own cooldown can
be half an hour. Holding that press means either firing it half an hour later or swallowing it with
no error line, and a Hearthstone pressed on cooldown has to still say "Item is not ready yet" — so
a quarter of a second, which is what the row defaults to, is an allowance for pressing a touch early
rather than a queue.

**The guard reopens early, and that is the headline.** `PendingCast` now keeps two timestamps where
it kept one. The **guard** reopens at the cast's own already-known length plus
`NP_MinBufferTimeMs`; the **record** still lives for the cast plus two seconds, so a `SMSG_SPELL_GO`
or `SMSG_CAST_RESULT` arriving a round trip later is still recognised as the answer to that cast.
Splitting them is not tidiness: the `modalNextSpell` chain that starts a hunter's Auto Shot reads the
record, and a record that died with the guard would break shooting.

The buffer is **not** a latency figure, which is why upstream's default is 55 ms and not a ping. Our
packet reaches the server about half a trip after the send; the server starts its cast then and
finishes half a trip after our own cast time elapses. A next cast sent at exactly `cast_time`
therefore arrives just as the server frees up, and the latency cancels out of the arithmetic
entirely. The buffer is jitter margin on top. `NP_NonGcdBufferTimeMs` is wider (100 ms) because a
non-GCD spell has nothing *but* the guard between two presses.

**`NP_RetryServerRejectedSpells` is the mitigation for that early guard**, and that is why upstream
defaults it on. If the margin is ever wrong — jitter, or a server cast time that differs from ours —
the server refuses the next cast and without a retry the press is simply gone. It goes back in its
slot **once**, held a buffer's worth, on exactly two reason codes: `0x3c` not-ready and `0x61`
another-action, the two an early guard can cause. Every other refusal is the server telling the
player something true, and re-sending one would be a packet a second that never succeeds. Upstream's
own set is not published and its log line (`" spell queued + ignored code "`) hints at a wider one;
a narrower set is the safe direction to be wrong in.

| Row | State | Note |
|---|---|---|
| `NP_QueueCastTimeSpells` | **LIVE** | Holds a press of a spell with a cast bar. Also the addon's presence probe |
| `NP_QueueInstantSpells` | **LIVE** | The same for an instant |
| `NP_QueueChannelingSpells` | **LIVE** | Whether a press made while a channel runs is held |
| `NP_QueueTargetingSpells` | **LIVE** | The terrain-cursor class, named by `cast_target::wants_terrain_click` — implicit target 16, or a location word with no unit bit. Deliberately *not* the item/locked/GameObject cursors, which want a click on a thing rather than a patch of ground |
| `NP_QueueOnSwingSpells` | **LIVE** | Default 0, as upstream's is "changed with 1.17.2 due to changes to on swing spells" |
| `NP_SpellQueueWindowMs` / `ChannelQueueWindowMs` / `CooldownQueueWindowMs` / `TargetingQueueWindowMs` | **LIVE** | See "What a window measures" above. The general one covers both a cast in flight and a global cooldown, which is what its unqualified name can mean |
| `NP_MinBufferTimeMs`, `NP_NonGcdBufferTimeMs` | **LIVE** | The guard's reopening margin |
| `NP_InterruptChannelsOutsideQueueWindow` | **LIVE** | A press while a channel has more than `NP_ChannelQueueWindowMs` left ends the channel instead of being held. Off by default |
| `NP_ReplaceMatchingNonGcdCategory` | **LIVE** | On, a non-GCD press takes a held slot only when the two share a `Spell.dbc` category — and a category of 0 means "no shared cooldown", so two of those do not match. Off by default, which is the plain always-replace |
| `NP_RetryServerRejectedSpells` | **LIVE** | Above |
| `NP_MaxBufferIncreaseMs`, `NP_OptimizeBufferUsingPacketTimings` | stored | Upstream's *dynamic* tuning of the buffer from observed packet timings. **Off in its own defaults**, so nothing changes by not having it; building it means a model of this realm's jitter, which is measurement rather than a binding |
| `NP_OnSwingBufferCooldownMs` | stored | A rate limit on re-queueing an on-swing strike. The slot is live; what is missing is anything to rate-limit, since a re-press of the queued strike already takes the reference's own silent bail (`6e4d43`) and so cannot queue twice |
| `NP_ChannelLatencyReductionPercentage` | **LIVE** | How much of the measured round trip comes off a channel's named end before the queue stops treating it as a guard, so a press held through a channel is not sent a round trip late. The arithmetic is the cast buffer's again, and worth writing down because "send early" sounds reckless: the server starts the channel at `T` and ends it at `T + duration`, we learn of it half a trip later, so our own end is already half a trip *after* the server is free — trimming 75 % of `L` puts a packet at the server a quarter of a trip after its own end. The named end, not the slack-inflated one, for the same reason. With no pong measured yet nothing is trimmed |

**A held entry's window is measured from the guard's *live* end, not the one stamped when the
press was made.** A fixed deadline reads right and has a hole in it: a cast pushed back twice
(`SMSG_SPELL_DELAYED`) ends after the window a press made at its start was given, so the entry
would time out while the thing it is waiting for is still running — and the press would vanish with
no packet and no error line, which is the one failure mode a player cannot describe. The same hole
swallows a press held through a cast whose global cooldown then outlasts the window. So the base
ratchets forward while anything still guards, and only ever forward.

**One behaviour worth knowing before testing.** Pressing a spell during a long cast holds it for the
whole cast and fires it at the end — the last press wins, so pressing three different spells during
a Pyroblast fires the third. That is upstream's `Replacing queued nonGcd spell X with Y` applied to
presses, and it is what "queue the next spell" means in practice. What it is *not* is a queue of
several casts in a row.

### The event table, accounted for

The same read gives **59 event names** (`0x7c198`–`0x7c658`). Their argument lists are upstream's
`EVENTS.md`, and for the cast family pfUI's `libs/libdebuff.lua:909-945` corroborates every column
from the consumer side — it destructures `arg2`=spellId, `arg3`=casterGuid, `arg4`=targetGuid,
`arg6`=castTime, `arg7`=channel duration, which is exactly the documented order.

| Bucket | Names |
|---|---|
| **Fired** | the aura eight — `BUFF_ADDED_SELF`, `BUFF_REMOVED_SELF`, `DEBUFF_ADDED_SELF`, `DEBUFF_REMOVED_SELF`, `DEBUFF_ADDED_OTHER`, `DEBUFF_REMOVED_OTHER`, `AURA_CAST_ON_SELF`, `AURA_CAST_ON_OTHER` (`ui_aura.rs`, `ui_cast_events.rs`) — the cast ten: `SPELL_START_SELF`/`_OTHER`, `SPELL_GO_SELF`/`_OTHER`, `SPELL_FAILED_SELF`/`_OTHER`, `SPELL_DELAYED_SELF`, `SPELL_CHANNEL_START`, `SPELL_CHANNEL_UPDATE` (`ui_cast_events.rs`), `SPELL_CAST_EVENT` (`ui_self_cast.rs`), and `SPELL_QUEUE_EVENT` (`ui_spellbook.rs`, off `spell/queue.rs`'s own rows — every mutation of the queue goes through `queue`/`pop`, so a code cannot be dropped by a caller that forgets to emit one) |
| **Deliberately absent** | `BUFF_ADDED_OTHER`/`BUFF_REMOVED_OTHER` — diffing the helpful half of every streamed unit, which nothing registers (the `AuraEdge` doc says so at the enum); `SPELL_DELAYED_OTHER` — upstream's own note is that the server only sends the packet to the affected player, so it never fires there either |

| **To fire, needs its own producer** | `KEY_DOWN`/`KEY_UP`, and nothing else — see "nampower's combat-log family" below for the other thirty-five, which are now fired. The pair needs the client's own numeric `KEY_*` enum, which is a table in `WoW.exe` this round did not read: the DLL's strings publish four of its values (`KEY_NONE=-1`, `KEY_SHIFT=0`, `KEY_A=65`, `KEY_ESCAPE=512`, `KEY_F1=768`), enough to see the shape — ASCII in bank 0, specials at `0x200`, function keys at `0x300` — and not enough to name a key in bank 2 past the first. A guessed code is worse than no event: an addon switching on `arg1` would silently never match. They are also nampower's **keyboard hook**, the same hook the press-interception queue uses, so they belong with that decision rather than ahead of it |


### nampower's combat-log family — 35 events off a decode that was already there

The whole of the "needs its own producer" bucket above, bar two keys. `ui_np_events.rs`.

**Why it was cheap, and why the earlier reasons were wrong.** The rows above said
`AUTO_ATTACK_*` needed "a melee-swing edge no path here raises" and `SPELL_HEAL_*` needed "the
heal amount off `SMSG_SPELLHEALLOG`, which nothing reads yet". Both were about the **cast** path,
and both were false about the tree: `combat_log/` has parsed `SMSG_ATTACKERSTATEUPDATE`,
`SMSG_SPELLHEALLOG`, `SMSG_SPELLENERGIZELOG`, `SMSG_SPELLLOGMISS`, `SMSG_SPELLDISPELLOG`,
`SMSG_SPELLDAMAGESHIELD`, `SMSG_ENVIRONMENTALDAMAGELOG` and `SMSG_PERIODICAURALOG` since it was
written — that is where the chat lines come from. This module is a second consumer of the same
`SessionEvent`, which is also what stops its arguments drifting from the chat log's.

That is the general lesson of the last three rounds, now three for three: of the reasons written
down for why a nampower feature was not built, the ones that turned out to be wrong were wrong in
the same way — they described what one subsystem could not do, when the answer was in a different
subsystem that already did it.

| Event | Source | Note |
|---|---|---|
| `SPELL_DAMAGE_EVENT_SELF`/`_OTHER` | `SpellDamageLog`, and a `PERIODIC_DAMAGE` tick | `arg5` is upstream's comma-joined `absorb,block,resist`; `arg8` its `effect1,effect2,effect3,auraType` off `Spell.dbc` |
| `AUTO_ATTACK_SELF`/`_OTHER` | `AttackerState` | `sub_damage_count` was added to the struct for `arg6`: vmangos writes one block, a server splitting a swing across schools writes more |
| `SPELL_HEAL_BY_SELF`/`_BY_OTHER`/`_ON_SELF` | `SpellHealLog`, `PERIODIC_HEAL` | A self-heal fires **two**, which is the only reading under which all three names mean something |
| `SPELL_ENERGIZE_BY_SELF`/`_BY_OTHER`/`_ON_SELF` | `SpellEnergizeLog`, `PERIODIC_ENERGIZE` | Same two-of-three shape |
| `SPELL_MISS_SELF`/`_OTHER` | `SpellLogMiss` | One event per row of the packet's own miss list |
| `DAMAGE_SHIELD_SELF`/`_OTHER` | `DamageShield` | `arg1` is the shield's **bearer**, which is the packet's first guid — nampower passes a packet's fields in wire order, which is what makes these argument lists checkable rather than guessed |
| `ENVIRONMENTAL_DMG_SELF`/`_OTHER` | `EnvironmentalDamageLog` | |
| `SPELL_DISPEL_BY_SELF`/`_OTHER` | `SpellDispelLog` | One per aura removed |
| `UNIT_DIED` | a `UNIT_FIELD_HEALTH` edge to zero | **The edge, not the dead flag**: the flag is also set by a create of an already-dead corpse, and `FieldChanged` deliberately raises nothing for a create — so the edge is what keeps "died" meaning died rather than "was first seen dead" |
| `BUFF_UPDATE_DURATION_SELF` / `DEBUFF_UPDATE_DURATION_SELF` | `SMSG_UPDATE_AURA_DURATION` | The packet carries a slot and a time; the spell id comes from the player's own aura block and the half from the slot, at the same 32 the block splits at. `arg3` is `GetTime()`×1000, **not** the reference's `GetTickCount` — that counter is unreachable from Lua, so an addon can only compare against `GetTime`, and the difference the argument is used for (`expiration − duration` = now) is the same either way |
| the thirteen `UNIT_*_GUID` / `PLAYER_GUILD_UPDATE_GUID` | `net::FieldChanged` | One shared producer over the descriptor-edge stream, one field to one name. `UNIT_NAME_UPDATE_GUID` is the exception: a name is not a descriptor field here, it arrives from `SMSG_NAME_QUERY_RESPONSE`, so it has its own handler on that packet |
| `UNIT_COMBAT_GUID` | `UnitCombatFeedback` | The same stream 1.12's own `UNIT_COMBAT` drains, so the action word is the reference's own classification rather than a second reading of the hit bits. Stock fires only for the tokens naming a unit, which is why the GUID form exists |

**A registration is the switch.** Upstream's README calls every `NP_Enable*Events` CVar
*deprecated* — "registering the event is preferred" — so `refresh_listeners` reads the VM's own
registration table (the same one `GetFramesRegisteredForEvent` reads) and a family is wanted when
its CVar is set **or** something is listening. Without that, three of the eleven families have no
CVar at all and would be unreachable for every addon, and `SPELL_ENERGIZE_*` unreachable for all
of them, since nothing installed writes its switch. It is also what keeps the cost honest: with
nobody registered, a damage packet queues nothing rather than building eight arguments and two
formatted strings for a fire that reaches no frame.

**The descriptor indices are written out and then cross-checked**, against `unit_rec::FIELDS`
(derived from 1.12's own block sizes) and the `FIELD_UNIT_*` constants `benilla-protocol` exports.
A hand-written descriptor index is exactly the number that is plausibly wrong and silently so: the
event simply never fires, which no amount of play distinguishes from "the server never sent one".

**Nothing installed registers one of the thirty-five.** They are built because the surface is the
deliverable, not because an addon here is waiting — so this round changes nothing visible in play,
and that is the honest expectation to set before testing it.

### The CVar table, 49/49

`strings nampower.dll | grep -oE '\bNP_[A-Za-z]+\b'` is the DLL's whole CVar table, and
`comm -23` against `cvars.rs`'s own rows now prints nothing. Fifteen names were missing, and the
reason is the same mistake the function list started from: the first pass took the list off
`NampowerSettings`' own writes rather than off the binary.

| Row | State | Note |
|---|---|---|
| `NP_ChatBubbleDistance` | **LIVE** | Writes the same `BubbleConfig::range_sq` SuperWoW's `ChatBubbleRange` writes — not a conflict to resolve, since both DLLs hook one cull and the last write wins there too. Ships **20** yd, the reference's own cull, not upstream's 60: a default is what a player who never touched the setting gets, and tripling the distance bubbles appear at is a visible change nobody asked for |
| `NP_ChatBubblesWhisper` / `Raid` / `Battleground` | **LIVE** | Three kinds the reference bubbles never. `Raid` is the raid-**leader** and **warning** kinds, which is upstream's own wording — reading it as "raid chat" would bubble every `/raid` line |
| `NP_EnableLocalSetRaidTarget` | **LIVE** | Solo, the wire leg marks nothing at all: the server answers by echoing to a group that is not there. This switch routes it to the local board instead — the path SuperWoW's `"local"` argument already built |
| `NP_EnableSpellEnergizeEvents` | **LIVE** | The seventh `NP_Enable*`; nothing installed writes it, which is why it was missed |
| `NP_SpamProtectionEnabled` | **LIVE** | A repeat press of the cast already in flight is swallowed rather than held — which is also the reference's own silent bail (`6e4d43`), so the two agree. Off, such a press may replace itself in its slot |
| `NP_QuickcastOnDoubleCast`, `NP_QuickcastTargetingSpells`, `NP_DoubleCastToEndChannelEarly` | stored | The double-press family, **all three off in upstream's own defaults**. Each needs the world point under the mouse *at press time*, which this client resolves in the click path (`spell/targeting/world.rs`) and not in the cast path, so wiring them means handing the ladder a camera ray — a real change whose feel wants its own test |
| `NP_PreventRightClickPvPAttack` | stored | Needs a hook in the right-click interact path, which decides target, interact and attack in one pass; its sibling `NP_PreventRightClickTargetChange` is stored for the same reason |
| `NP_PreventMountingWhenBuffCapped` | **live** | A mount press with all 32 positive aura slots taken is refused above the commit, so neither the packet nor the global cooldown is spent — `spell/np_press.rs`'s `mount_refusal`. The aura number (`SPELL_AURA_MOUNTED` = 78) is asserted against this realm's own `Spell.dbc` for three mount spells rather than taken from mangos' header, because a wrong one would make the refusal silently never fire. **One deliberate deviation, and upstream names the bug itself**: its settings label reads "Preventing mounting due to buff cap (breaks dismount)" — in 1.12 you dismount by re-casting the mount — so a press while `UNIT_FIELD_MOUNTDISPLAYID` is live is exempt here. Refused **silently**, as upstream's own report is a line in its debug log and 1.12's `SpellCastResult` has no code for "too many auras" |
| `NP_EnableEnhancedTooltips` | stored | Authored content rather than a binding: the numbers are in `Spell.dbc` columns this client reads, but what the lines say and where they sit is upstream's design, and guessing it produces a tooltip that is neither ours nor theirs |
| `NP_PreserveGreaterDemonAutocast` + the three `*AutocastData` | stored | Needs pet-autocast state keyed by demon rather than by the live pet guid. The three data rows are not settings at all — upstream's README calls them "managed automatically" — so they are registered to round-trip a write and nothing here will read one |

**Two upstream documents disagree** about the six `NP_EnableUnitEvents*` defaults: `EVENTS.md`
says 0, the README says 1. Those rows keep 0, and the disagreement costs nothing here, because a
default is not a behaviour under the registration rule above — every addon that wants the stream
either writes the CVar or registers the event.


**ClassicAPI's 70** are the remaining bulk and are tracked in `docs/classic-api-functions.md`
rather than here. The same caution applies twice over: its 999 pointed-at names include a great deal
that is not Lua surface at all, and the corpus intersection is the only part worth reading.