mirror of
https://github.com/runbear-io/beardrive.git
synced 2026-08-25 08:08:08 +02:00
aeee881fa6
The reported symptom was a read counter inflating while you watched: reopen one file a few times as one account and it climbs. It does not — the ledger debounce is correct, and a handler-level repro proves it. What moves is the displayed *total*, which sums three kinds of reader (human, agent, share) with independent debounces: your own revisits fold into one visit, but the syncing agent's reads and share-link hits keep landing in the same number with nothing to say so. So the count was right and its framing was wrong. heatText now breaks the total out by reader kind whenever more than people are reading — the seeded "14 reads (9 agent)" becomes "15 reads (6 human, 9 agent)" — at the single chokepoint every heat surface already routes through (file meta line, folder row meta, folder subtitle, heat-dot tooltip). No ledger change: the investigation found nothing to fix there. The spec's prime suspect (a sandboxed-iframe fetch losing the session and recording as "anonymous") cannot fire in hub mode — authGate 401s an unauthenticated /api/ request before recordRead runs, and every authenticated identity carries an account email. TestReadCountsOnePageOpenOnce pins the invariant so this stays legible: one signed-in person, one file, one 10-minute window is exactly one read, whichever of /render, /file, /download served it; a second account adds exactly one; the sandboxed iframe's cookie-less fetch adds none; history spelunking adds none; and no actor identity reaches the /heat response. TestReadLedgerDebounce now also covers the other half — once the window passes, the same actor counts again. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>