fix(events): snapshot cadence follow-ups (history doubling, open counts, deferred checks)

[vv7r]

Follow-ups to co-l#401, as discussed in the thread: fixes 1–3, one commit each, each with its own test (written first, failing before the fix). co-l#4 comes later, once the sub-agent compaction fix lands.

Commit	Problem	Fix
keep one history entry per compaction across snapshots	takeSnapshot() builds from combineEventsWithSnapshot(), whose stubs replay the previous snapshot's contextWindows / formatRetries just before it; the fold reseeds from the snapshot on top of them, so each snapshot doubles the history (1 → 2 → 4 → 8 over four flush()es at a662baed; seen live: 7 compactions as 2.3M entries, a 433 MB snapshot)	When the fold seeds from a snapshot, keep one entry per (windows or attempt, timestamp), the only fields the stubs carry. This also shrinks a snapshot already inflated this way at the next snapshot
count open messages and pending tool calls as sets	A successful compaction starts its summary message twice and closes it once: starts minus dones left one message open for good, so the cadence never snapshotted again in that turn	Count the ids started and not done in the tail (and tool calls without a result), as you suggested. A done or result whose start is before the tail can no longer hide another open message or pending call. Same covering index (session_id, event_type, seq): 30 ms on a 48 MB tail, 64 ms on 100 MB, 269 ms on 400 MB, mostly the byte sum
snapshot at the next quiet point once a check was deferred	A check that found the turn busy still reset lastCheckAt, so a sub-agent that is nearly always busy usually missed the next 30 s check too	Once deferred, the next quiet point (message.done / tool.result) checks again, at most every 5 s

Verified: lint, typecheck, format, duplicate and the full suite (unit and e2e) pass on each commit, through the pre-commit hook.

AI-Enhanced Development

• AI Models: Claude Opus 5.5 (Claude Code); live tests with a local Qwen3-based model on llama.cpp

Cache Impact

• No. Snapshot persistence and the event log only; the requests sent to the model are unchanged.

---

🤖 Generated with Claude Code

[mossaab]

One defensive nit on the new set-based counts: the NOT IN (SELECT ...) subquery is NULL-fragile. If a single message.done (or tool.result) in the tail had a NULL id, x NOT IN (..., NULL, ...) evaluates to NULL for every row, so openMessages / pendingToolCalls would silently read 0 — and the cadence would then treat the turn as at rest and snapshot mid-stream. I checked my session DB and found no NULL ids, so it's purely theoretical, but an IS NOT NULL in the subquery (or NOT EXISTS) removes the footgun for one line.

[vv7r]

Good catch, fixed in 72d614e: the NOT IN subqueries now skip NULL ids, with a test where an id-less message.done and tool.result used to read both counts as 0.

[mossaab]

Reviewed 72d614eb and verified it independently: with store.ts reverted to 542a8330 and your new test in place, it fails exactly as you described (expected +0 to be 1 for both counts). The four commits are merged fast-forward onto fix/event-log-saturation — linear history, no merge commit, your authorship and your one-commit-per-fix split intact. GitHub marked this PR as merged with 72d614eb as the merge commit.

Full suite on the resulting tip, on my side: 443 files / 5,994 unit tests and 49 files / 357 e2e passing, plus tsc --noEmit, ESLint, Prettier and jscpd clean.

One nit, same class as the one I reported and purely theoretical: the IS NOT NULL guard sits only on the done/result subquery, so a message.start with a NULL id can never be counted — NULL NOT IN (…) is not true. The typed append() API cannot produce one (you had to cast as never to force the case in the test), but a symmetric test would close the class rather than the instance.

co-l#4 is tracked in #2. Thanks again — still the most useful review this PR got.