fix(#260): normalize Rust panic stops from 'breakpoint' to 'exception'

[debugmcpdev]

Summary

Fixes #260. A Rust panic! pause arrived with lastStop.reason: 'breakpoint' because CodeLLDB implements the rust_panic filter as an internal breakpoint. Callers following the documented crash-diagnosis contract (lastStop.reason === 'exception') missed panic pauses entirely. The normalizeStopReason policy hook added in #270 is exactly the seam this needed.

The discriminator (live-capture driven)

Live capture on Windows/GNU (CodeLLDB 1.11.8) killed the obvious approach: the panic stopped body is only

{"allThreadsStopped":true,"hitBreakpointIds":[2],"reason":"breakpoint","threadId":…}

— no description/text to pattern-match. But the capture also showed the internal filter breakpoint takes the next free DAP breakpoint id after user breakpoints, so the discriminator is id-based:

Stop	body	verdict
user breakpoint hit	hitBreakpointIds ∩ user ids ≠ ∅	stays 'breakpoint'
step landing on a multi-location bp line (mislabeled, #255 trace)	carries the user bp id	stays 'breakpoint'
true step completion	no hitBreakpointIds	untouched
panic (rust_panic internal bp)	ids disjoint from user set	→ 'exception' (rawReason: 'breakpoint' preserved)

Both sides must be known: the session manager passes userBreakpointIds only when every user breakpoint has a known adapterId; missing hit ids or incomplete bookkeeping keeps the raw reason. The asymmetry is deliberate — a missed panic keeps a cosmetic 'breakpoint' label, a false 'exception' would mislead agents.

exceptionInfo enrichment guard

After normalization the #243 enrichment would have fired (CodeLLDB advertises supportsExceptionInfoRequest), and live it answers about the internal breakpoint — {exceptionId: "Breakpoint", description: "breakpoint 1.1"} — misleading, not enriching. Enrichment is now additionally gated on the adapter's raw reason being 'exception'. The panic message itself is available via get_output stderr (thread 'main' panicked at …), which the e2e asserts.

Also

• Policy comment documenting the Rust: panic pause reports lastStop.reason 'breakpoint' instead of 'exception'; CodeLLDB no longer advertises rust_panic #260 advertisement drift (CodeLLDB 1.11.8 advertises only cpp_throw/cpp_catch; rust_panic still works via legacy acceptance; the [FEATURE] Capture adapter initialize capabilities + best-effort exceptionInfo enrichment on exception stops #243 drift warning stays as the early alarm).
• New examples/rust/panic_example + Rust launch trio in the break-on-exceptions e2e: default (pause at panic, panic frame in stack, message in output, continue → exit 101), explicit 'uncaught', and 'none' opt-out (run to termination, exit 101).
• skills/debugging/references/rust.md updated: panic pauses now report 'exception'.

Testing

• Policy unit tests: 26/26 (7 new discriminator cases incl. the Rust/Windows: continue_execution re-stops at the same breakpoint (never advances without a step_over) #255 mislabeled-step guard)
• SessionManager unit tests: 71/71 (5 new, incl. enrichment suppression + incomplete-bookkeeping guard)
• New Rust e2e trio: 3/3 locally (Windows/GNU)
• Live dev-proxy verification: start_debugging now reports reason: "exception", lastStop = {reason: 'exception', rawReason: 'breakpoint'}
• Full pre-push suite: green

Note for review: the Linux leg of the capture is delegated to ubuntu CI — if Linux CodeLLDB reported panics natively as 'exception' the hook no-ops and the e2e still passes; if it reported 'breakpoint' without ids the e2e would fail visibly here.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!