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.