Proactive hint anchor can land in a file the student isn't working in — revisit anchor selection

[Predixx]

Observation

During a live proactive-intervention run, a delivered active hint anchored to a file the student was not working in.

• Student was editing src/asd/MergeSort.java (a stub performSort doing Collections.shuffle(input)).
• The delivered hint anchored to src/asd/Client.java:12, with inline text Missing required top-level types (asd.*) and the full message referring to missing top-level types asd.SortStrategy / asd.Context / asd.Policy (confidence 0.86).

So the anchor pointed at a different file/line than the student's current focus.

Extension side is fine

The extension surfaces and navigates to an off-file anchor correctly, so this is not an extension bug:

• A persistent status-bar jump lamp (→ Iris: Client.java:12) appears and flashes amber precisely because the anchor is off-screen / in another file (interventionService.ts showJump → _flash when !_isAnchorInView).
• The banner's Show me action and clicking the jump lamp both open the anchored file and reveal/scroll to the line (revealJumpTarget / handleClick → _openAnchor: openTextDocument + showTextDocument with the selection at the clamped anchor line, focus moves there). Missing file / past-EOF line is handled without throwing.

The actual question (anchor selection, likely Pyris-side)

The concern is anchor selection quality: the anchor is chosen from the failure/context (here: missing required types referenced in Client.java), not biased toward the file the student is actively editing. This can feel disorienting ("the hint is somewhere I'm not").

Worth deciding:

• Is anchoring to the most-failure-relevant location (even in another file) the intended behavior, with the jump affordance being the mitigation? Or
• Should anchor selection prefer / tie-break toward the file the student currently has open (or recently edited), when the failure is plausibly reachable from there?
• If an anchor lands outside the active file, is the current signposting (flashing jump lamp + "Show me") discoverable enough, or should there be a stronger in-editor cue?

Root cause is most likely the Pyris anchor-selection step (anchor_file / anchor_line in the struggle-intervention result), so any fix is probably Pyris-side; filing here to track the observation and the product decision.

Repro context

Local stack, course "TEST Kurs", exercise "bubble test", proactive level = More. The anchor came through as anchor_file=src/asd/Client.java, anchor_line=12 in the action=active decision.