Does a CodeBuddy session ever report zero friction because CodeBuddy can't, not because none happened?

[mahirhir]

I've been reading dashboard-collector.ts alongside session-collector.ts. isValuable() decides whether a session gets surfaced to the team digest, and it gates on interventionCount above zero, which comes from scanTranscriptStop parsing interrupt and toolReject markers out of the transcript. For CodeBuddy, though, readCodebuddyIndexOnce always returns interrupt 0 and toolReject 0, with a comment saying CodeBuddy transcripts just don't expose those markers. So a CodeBuddy session with real interrupts and rejections looks identical in the digest to one with none, as long as it touches under three distinct tools. Is there a plan to backfill that signal from CodeBuddy some other way, or is friction tracking effectively Claude-Code-only right now?

[jeff-r2026]

You've got it right — there's no backfill for CodeBuddy today, so friction tracking is effectively Claude-Code-only.
We'd welcome a PR if you're up for it.

[m0Nst3r873]

Confirmed — the problem is real, and the root cause is exactly the readCodebuddyIndexOnce limitation this thread points at. Opened #336 to address it.

What was actually happening

readCodebuddyIndexOnce hardcoded interrupt/toolReject/toolError to 0 because index.json is only a skeleton (tokens + prompt list) and carries no tool results. So computeSmartScore — friction-dominated — stayed near zero for CodeBuddy, and the share-learnings hint effectively never fired unless the session happened to hit correction (event-derived, tool-agnostic) or a knowledge-gap bonus. The three highest-signal cases on Claude Code — user interrupt, tool reject, tool-retry — were all silent on CodeBuddy.

What was recoverable, and what wasn't

CodeBuddy stores tool outcomes in the sibling messages/*.json blobs, not in index.json. Reverse-engineering the extension's tool state machine plus inspecting real transcripts settled each signal:

• toolError ✅ — a tool blob's tool-result with isError === true. Clean, structured, unambiguous.
• toolReject ✅ — this was the interesting one. A rejected tool lands on status: "cancelled", but so does an ESC-interrupt residue and system auto-cancels (UNFINISHED TOOL / malformed tool args). Bare cancelled is three-way ambiguous. The disambiguator turned out to be a fixed marker CodeBuddy writes into result.errorMessage on user rejection: "User rejected this command". A real rejection sample confirmed it. Matching on that string is a positive whitelist, so it excludes both interrupt residue and system cancels — it can only under-count, never mis-count.
• interrupt ❌ — no on-disk marker. The session-level stopReason isn't persisted per-message, and the only blob-level trace is heuristic text. Left at 0. Its residual cancelled tools don't carry the rejection string, so they are correctly not miscounted as rejects.

Result

toolReject and toolError are now extracted from the blobs, de-duplicated per callId, with fully defensive parsing (never throws — the Stop hook stays safe) and an IO cap. Nothing downstream changed: weights, threshold, and the Claude/Cursor branches are untouched.

Verified end-to-end: a real rejection session → {interrupt:0, toolReject:1, toolError:2}; 20 ordinary sessions → all 0/0 (no false positives).

So friction tracking is no longer Claude-Code-only. toolReject/toolError now work on CodeBuddy; interrupt remains a genuine platform-data limitation until CodeBuddy persists a marker for it.

[mahirhir]

Looks like #336 answered the invitation before I got to it: toolReject and toolError recovered from the message blobs, with the "User rejected this command" marker as a positive whitelist, so it under-counts rather than mis-counts. That's a cleaner resolution than I expected for bare cancelled being three-way ambiguous. The remaining gap is interrupt, which stays at zero until CodeBuddy persists a per-message marker, so a session can still report less friction than happened, just no longer none of it. That was the core of my question, and it's now a documented platform limitation rather than a silent one. Thanks for the quick confirmation, and to m0Nst3r873 for landing the extraction.

[m0Nst3r873]

Thanks for the original write-up — it was a genuinely sharp piece of reading. You traced the whole chain from isValuable() gating on interventionCount down to readCodebuddyIndexOnce hardcoding the friction signals to zero, and framed exactly the right question: whether a CodeBuddy session reports zero friction because none happened, or because CodeBuddy can't surface it. That precise framing is what made the fix straightforward to scope.

And you've summarized the outcome correctly — toolReject/toolError now recovered, interrupt remaining a documented platform limitation rather than a silent one. Nothing to add on our end. Thanks again for raising it so clearly.