The burst counter incremented on any tool call <30s apart regardless of
tool type, so a bulk read of many files produced the same "Rapid-fire"
alert as a rapid-fire editing sequence. The edit-ratio check reported
"possible stuck/spiral" for any session under 10% edits past 30 minutes,
which a read-heavy analysis session satisfies structurally whether or not
the work is productive. Both mechanisms are confirmed in
docs/BRIEF-vurdering-v2.md, verification points 1a and 1b.
tool-tracker.mjs now tracks whether the current burst run consists only
of read tools and suppresses the rapid-fire alert for such runs. A
read-dominant session (>=70% reads) reports its low edit ratio as
context rather than as a stuck/spiral claim, and never as the sole
reason for a warning. Bursts involving Edit/Write/Bash and
non-read-dominant sessions behave exactly as before.
No new data is recorded: the differentiation uses tool_name, which
events.jsonl already logs. The privacy design is untouched.
Tests first (Iron Law): 5 cases in tests/tool-tracker.test.mjs, 3 of
which failed against the previous implementation, 2 of which are
regression guards that passed before and still pass.
Verified: node --test tests/*.test.mjs -> 263 pass, 5 fail. All 5
failures are the perf wall-clock assertions, which fail identically on
HEAD without this change (measured by stashing and re-running) — they
are a pre-existing property of this machine, not a regression.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011wMhJuPFUiWqKLSQjrzCXP
Kjell Tore Guttormsen
2c9e2de00a