mirror of
https://github.com/mksglu/context-mode.git
synced 2026-10-02 04:14:38 +08:00
Mert Koseoglu
320ed3e563
bytes_retrieved (the "With context-mode" half of kept_out_pct) was 0 across all 124,454 prod events — the dashboard's Context Savings card showed "Retrieval signal pending" forever. Root cause: PostToolUse never fires for the plugin's OWN MCP tools, so the hook-side extractMcpToolCall path never observes ctx_search / ctx_fetch_and_index. Their response bytes are measured only server-side (in tool_calls), which never reaches the forward stream. Bridge the two processes through a tmp marker keyed by the session DB basename (the one id both the server and the hook resolve reliably — CLAUDE_SESSION_ID is not guaranteed in the server env). The server appends each retrieval's response byte count; the next ordinary-tool PostToolUse consumes the marker (consume-once) and emits a forwardable event carrying bytes_retrieved, which session-loaders already stamps onto the platform payload. Mirrors the existing redirect / latency marker handshake. This is a server-emit fix, not a hook-extract fix: releasing the existing hook-based code would NOT have populated the field, since the hook never sees these calls. RGR: new retrieval-marker module (append/consume round-trip, accumulate, consume-once, phantom-event guard) — 4 tests. Forward stamping already covered by platform-bridge-wire. tsc clean; 31 related tests green. Verified end-to-end against the live session DB path: 100279+3009 → 103288 consumed.