DoiteAuras reads the whole aura block once at PLAYER_ENTERING_WORLD and from then on keeps its
table purely from nampower's four self-aura events (`Modules/DoitePlayerAuras.lua:403-490`;
`UpdateAuras` is called nowhere else). The arrival loop here seeds a unit's memory and fires
nothing, which is right for a unit streamed in mid-aura — but it only ever seeded the harmful
half, while the comment above it claimed it seeded the player's helpful half too ("without this
its first real edge would be swallowed as a first-time diff, which is one lost BUFF_ADDED_SELF
per login"). The guid was destructured away as `_guid` and `own_buffs_seeded` was set nowhere but
in the edge loop.
So the player's first buff edge of every session reported nothing. That does not heal: a later
cast of a buff that is still running refreshes its slot with the same spell id, which is not an
edge this watch sees at all, so nothing reports the aura again until it drops completely. A
warrior's Battle Shout, re-cast while it still has a minute to run, never drops — grom's rule for
it read "missing" with the buff plainly up, all session.
Every other link was measured clean first: `GetUnitField("player", "aura")` answers a table, the
arg vector matches what the handler reads (arg3 spell id, arg4 stacks, arg6 raw slot, arg7 state),
and all seven ranks of Battle Shout resolve through both `GetSpellRecField(id, "name")` and
`GetSpellNameAndRankForId`.
The pin asserts both halves — the first buff is an add, and a refresh is not an edge — and its
control is worth noting: with the seed removed the first buff reports `[]`, not a wrong value,
which is why no session log ever named this.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SgstFWtn1RxEJ5kVrpgYwn
gromandClaude Opus 5
afc5379911