perf: an appended file leaving the window stays incremental (#99) - #114

Builds on #113 — its commit is the first of the two here, so please take #113 first and this will shrink to the second commit. Same profiling session as #109/#111/#112.

What is left after #113

#113 stopped the window's ordinary drift from forcing a full rebuild: full rebuilds went from 136 of 140 refreshes to 3 of 53. The ones that remained still cost 50-120 s each, and they had a single cause — the file that is appended to in the very refresh where one of its own events leaves the window.

Its stored aggregate still counts the expired event, so a tail read cannot serve it: the file genuinely has to be re-read in full. Until now that made it indistinguishable from a mid-file edit — it was planned as 'source', which rejects the fast path and re-reads every body. On a machine running several agents the pairing is routine, because sessions append constantly and on a long history the window is always drifting past something.

Worth noting how invisible this was from the source: such a file is classified in the needsAnalysisBody branch, which runs before the append/rebuild classification below it, and both produce a kind: 'rebuild' plan. Only a debug run made it visible that one plan was being turned into 683.

Why this is safe

Such a file only grew. It keeps every UUID it owned and can gain only new ones — the same shape as a plain append. So it is planned as 'window', allowed on the fast path, and put through the same ownership probe after parsing that a plain append gets: if one of its appended lines carries a UUID owned by a later file, the full rebuild still happens.

A genuine mid-file edit stays 'source': the append prefix and boundary checks are exactly what tell the two apart, and they are what grewOnly evaluates.

The same reason covers the other shape of the pairing, where the cheap rebase succeeds but changes the payload — that append was already being downgraded to a rebuild, and it is a window rebuild too, not a source edit.

Test

a file that is appended to while losing an event to the window stays incremental — it fails on the parent commit with "an appended file losing an event re-read the whole corpus: 8 bodies", and it asserts contentAnalysis equals what the full loader produces, so agreement is checked alongside the speed.

Measured

Same machine and history as #113, one hour of ordinary work with several agents appending:

One of those three is the legitimate cold start, so the remaining full rebuilds went from roughly one every three minutes to one every half hour. I have not chased what causes the last two, and this change does not claim to.

Full test run matches main on my machine: the same 8 pre-existing failures (Windows symlink and file-locking tests), plus the new test.

🤖 Generated with Claude Code