[Juliusolsson05]

Follow-up to #389 (incident forensics hardening). The multi-agent adversarial review of that PR confirmed 15 findings; this fixes all 6 with behavioral impact plus the load-bearing comment rot. One PR, per "no micro-PRs" convention.

Behavioral fixes

src/main/storage/feedDebugLog.ts — 5 fixes to the per-file cap

1. Pre-existing over-cap files never got a tombstone. Priming tombstoneWritten from startingBytes >= cap routed the first post-upgrade batch into the already-capped short-circuit, which never writes a marker — so the 60–300 MiB pre-cap-era files that motivated the cap (Incident forensics hardening: catch fast heap bursts, cap feed-debug, journal retention, detect prior-run OOMs #388) had their appends dropped with zero on-disk trace. Now primes false; the first batch flows through the cap branch, writes the tombstone, then latches.

2. Tombstone write failure silently latched as "capped". The bare catch {} still set tombstoneWritten = true, so an ENOSPC — disk-full being the exact pressure the cap exists for — produced a file with no marker that the code believed was cleanly marked. Now latches only on success; on failure the next batch retries (one small append attempt per batch).

3. stat() failures failed OPEN at 0 bytes. Any non-ENOENT error (EACCES/EIO/EMFILE — fd exhaustion is likeliest under exactly the load the cap targets) primed the counter at 0 and let an already-300 MiB file grow by another full cap's worth. loadInitialFileBytes now returns null for unknown-size; the caller fails CLOSED — unprimes and returns without advancing the cursor, so the renderer resends and the next batch re-stats.

4. forgetFeedDebugSession racing the stat() await leaked map entries. get → await → set meant a forget firing during the await deleted a not-yet-existing key (no-op), then the continuation inserted cap state for a dead session — a permanent leak since session UUIDs never recur. The placeholder now lands in the map BEFORE the await, and an identity re-check after it detects the forget and bails.

5. On-disk droppedEntriesSoFar froze at the first batch's count while capped sessions kept flooding for hours. A refreshed tombstone row is now appended each time the total doubles since the last row — log-bounded (~20 rows for a million drops), and the last row is always within 2× of the truth.

6. Batch drops were all-or-nothing. A 40 MiB batch whose last bytes crossed the cap discarded all 40 MiB even though most entries fit. Entries are now serialized per-line and the cap cuts within the batch; the admitted prefix is written in the same writeFile append as the tombstone (JSONL prefixes are always valid, so no torn interleaving is possible).

src/main/incident/previousRunClassifier.ts — minidump regression

main_oom_suspected dropped minidumpPath from evidence. V8 fatal aborts raise SIGABRT, so Crashpad almost always writes a minidump for the same crash the diagnostic report describes. The new OOM branch returned before the minidump lookup ran — losing native/minidumpPath for exactly the crash class the branch was added to improve (pre-#389 code surfaced both). The OOM branch now runs findRecentMinidump too.

Comment/structure fixes

• previousRunClassifier.ts — both "trigger is a top-level string" comments were factually wrong (trigger lives under header). Comments now describe the real shape and explicitly warn against "simplifying" the flat regex scan to JSON.parse(prefix).trigger, which returns undefined and would silently kill every OOM classification.
• heapWatchdog.ts — the claim that the ~1.2 GB abort class "was already covered by the ratio" was algebraically false (ratio arm resolves to ~3.0 GiB on the 2026-05-11 host; both old and new trips sit above 1.2 GB). Replaced with an honest coverage note: low-peak aborts are attributed post-hoc via reportOnFatalError + the classifier; polling only buys a pre-crash snapshot for climbs crossing ~1.5 GiB.
• index.ts — setDebugRetentionJournal(appRunJournal) moved BEFORE appRunJournal.start(). start() fires the run's first prune (incident-run-start), and with the sink wired after the await the first prune's journal entry was race-free only by accident (the prune's statfs() I/O losing to the synchronous continuation). Any future await inserted between them would have silently dropped the breadcrumb. Wiring first makes the ordering structural instead of incidental; the old comment (which also misidentified 'startup' as the first prune) is gone.

Verification

Applied to a clean main checkout: tsc -b tsconfig.node.json exit 0, tsc --noEmit -p tsconfig.web.json 0 errors. No new tests per repo convention.

🤖 Generated with Claude Code