Two things, from taking the debugger deeper and validating it end-to-end with a
real GGUF model.
- joule_coded::dap: a minimal Debug Adapter Protocol client (DapSession) that keeps
lldb-dap alive over stdio to walk execution -- set breakpoints, run to a stop, read
live locals, step, continue. A background reader thread feeds a channel so every
read is bounded by a 20s timeout: the session can NEVER hang the daemon. The DAP
handshake is correct; run-to-stop is adapter-dependent (some macOS lldb-dap builds
won't launch the debuggee under the adapter -- breakpoints report verified:false),
in which case it times out cleanly and the caller keeps the verified batch
inspector (inspect_runtime) as the primary path. Wired as an optional deepening,
#[ignore] e2e test tolerant of the adapter limitation.
- joule_core::debugger: skip cargo's roll-up summary lines (`error: test failed, to
rerun ...`, `could not compile`, `aborting due to`) so the real panic/assertion
wins the diagnostic -- surfaced by a live repair run where the summary was
outranking the actual `left: 0, right: 4` assertion.
The live e2e (bonsai-1.7b on a divide-by-zero test) proved the whole loop mechanically:
reproduce -> parse the real assertion -> ground a fix -> generate (253 kJ MEASURED for
the attempt) -> re-verify -> bail on no-progress -> seal the receipt. The weak model
didn't land the fix, but every step and the energy metering worked.
20f4a58617