Files
benilla-octo/crates
gromandClaude Opus 5 48c27d45bf The three multibar reds were one duplicate load, not a loader defect
`_G["MultiBarBottomLeftButton1NormalTexture"]` really was a different object
from that button's `GetNormalTexture()`, with both answering that same
`GetName()`, so every tint written through the global — the realm's own
`ActionButton_ShowGrid`, and pfUI constantly — landed on a region nothing drew.
I wrote that up as a state-texture publish naming the wrong region at two levels
of template inheritance and left three tests red on it.

It was neither the publish nor the depth. **These tests loaded
`MultiActionBars.xml` twice**: once through `load_action_bar`, where toc order
puts it, and again in each test's own list, left behind when the first was added
— 15 tests. Two loads build two sets of MultiBar buttons, and the two `_G`
publishes disagree about a collision: a frame's is non-overwriting (`0x701bd0`),
so `MultiBarBottomLeftButton1` stayed the *first* set's button, while the
loader's state-texture publish is a plain `globals().set`, so the region name
became the *second* set's texture. Every write through the global reached the
hidden second set.

What rules the loader out is now its own test: `expand`'s merge concatenates
children, and only the base of the real chain declares a `<NormalTexture>` —
`ActionBarButtonTemplate` and `MultiBar1ButtonTemplate` declare only `<Scripts>`,
read off the chain — so there is exactly one declaration at any depth, and a
synthetic three-level chain answers `named == live` at every level, top-level or
child of a named parent.

The other two reds in that file were a misread of the reference, in the same
place twice: `ShapeshiftBar_Update`'s last line is
`UIParent_ManageFramePositions()`, and the pass hides all three shelf strips
under `if ( MultiBarBottomLeft:IsShown() )`. So a form learned while the
bottom-left bar is up shows the middle strip and takes it down again inside one
call — it is never seen across the row, where both tests asserted it would be
"until the next pass".

17/17 in that module now. The publish asymmetry is left alone and written down
where it was found: no single load can reach it, the reference's region-name path
is not disassembled, and matching frames on a guess is not a fix.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SgstFWtn1RxEJ5kVrpgYwn
2026-10-29 15:07:00 -06:00
..