The stale-minimap report needs one fact: did the selection follow the player
into the new zone? Everything map-derived rests on it, because
`GetPlayerMapPosition` projects onto the **displayed** map — a selection left a
zone behind seats pfQuest's minimap pins against the wrong rect, and plausibly
rather than obviously wrong wherever two rects overlap, as Ironforge's does
inside Dun Morogh's.
The `zone:` line could not answer it even after it started printing both pairs,
because the pairs disagree constantly and mostly correctly: for a frame or two
after every crossing, since this feed publishes the new zone and the
`ZONE_CHANGED*` an addon answers by reselecting fires after it; and for as long
as the map is open on another zone, which is what browsing is. A marker on that
line would have cried wolf on both.
So the rule is its own thing, `SelectionLag::step`: an episode starts only on a
frame where the *player* moved to a zone the map is not on, and only an episode
outliving a 1 s grace is reported — once, at WARN, with the catch-up line when
something finally reselects. A selection that wanders under a standing player is
never an episode. Five tests, including the 600-frame browse that must stay
silent.
The line also forks the cause, which is the part that saves a round trip:
`UiScript::world_map_resolver_calls` counts Lua's `SetMapToCurrentZone` calls, so
the report can say whether the UI never asked to follow — the event did not reach
the addon — or asked and still landed wrong, which is the verb reading a zone the
feed had not published. Same symptom, different fixes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SgstFWtn1RxEJ5kVrpgYwn
gromandClaude Opus 5
9e13856cfd