His rotation macro never picks Slam. Five of our verbs and feeds stand
between `[noslamclip]` and an answer, and any one of them would read in play
exactly as he describes, so this drives all five on his own 92-addon
interface rather than reasoning about them:
UnitAttackSpeed's (number, nil) shape, which is what isDualWield() asks;
CHAT_MSG_COMBAT_SELF_HITS reaching a registered frame with arg1 as the
composed sentence, which is the only thing SP_SwingTimer resets on;
the GetSpellName spellbook walk;
GameTooltip:SetSpell on a nil-parent scanning tooltip built from
GameTooltipTemplate, read back through getglobal;
and the <OnUpdate> delta arriving as seconds.
All five answer correctly. Measured, the conditional is true at the top of a
swing with a 44.4% window off a scanned 1.5 s cast time — so the cause is not
in this chain, and the test is here to keep that true.
The one asymmetry it does pin down is faithful: before any swing lands,
SP_SwingTimer's ADDON_LOADED arm latches st_timerMax to 0, because
UnitAttackSpeed answers 0 while the stats feed has not pushed and 0 is truthy
in Lua, so its own `if not st_timerMax` guard never fires again.
reference/1.12-shapes.tsv has UnitAttackSpeed returning exactly two values and
never none, so answering 0 is right; the first swing heals it, which the
second half of the test shows.
The scanning-tooltip leg is worth naming on its own: without it the addon
falls back to a 2.5 s constant, and against a 2.70 s swing that is a 7%
window instead of 44% — which would read as "Slam never fires" too.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SgstFWtn1RxEJ5kVrpgYwn
gromandClaude Opus 5
e17d7dff04