Expected behavior
Every relevant provider worktree record observed for a session should eventually contribute to its worktree attribution, subject only to the documented bounded evidence window.
Actual behavior
In LiveWorktreeReconciler.observe, when more than recentRawLimit (500) relevant records arrive BEFORE the first successful refresh() (the Git IPC reply) for that cwd, the evicted records are folded into the baseline via foldRaw (LiveWorktreeReconciler.ts:146-156). foldRaw skips every non-worktree-state record when hasCatalog is false (LiveWorktreeReconciler.ts:380): if (asRecord(raw)?.type !== 'worktree-state' && !hasCatalog) continue. Those records are dropped silently. When the catalog later arrives, project() replays only the retained 500-record window, so the earliest relevant writes never contribute attribution.
Reproduction
A session whose feed buffers more than 500 relevant worktree records before the first Git catalog message resolves (e.g. an agent that opens quickly while Git IPC is slow) loses all but the newest 500 records' attribution for that session.
Impact
Worktree attribution can be missing for the first ~500+ records of relevant evidence in a fast-start session — a data-integrity gap for the work-context projection, not a performance concern.
Environment notes
Pre-existing on main (present before #808's replay-cache optimization; #808 preserved this folding path). Surfaced during independent review of #808; deliberately NOT fixed in that PR. The fix would buffer/fold with a provisional catalog or retain worktree-path-bearing records regardless of catalog presence.
Expected behavior
Every relevant provider worktree record observed for a session should eventually contribute to its worktree attribution, subject only to the documented bounded evidence window.
Actual behavior
In
LiveWorktreeReconciler.observe, when more thanrecentRawLimit(500) relevant records arrive BEFORE the first successfulrefresh()(the Git IPC reply) for that cwd, the evicted records are folded into the baseline viafoldRaw(LiveWorktreeReconciler.ts:146-156).foldRawskips every non-worktree-staterecord whenhasCatalogis false (LiveWorktreeReconciler.ts:380):if (asRecord(raw)?.type !== 'worktree-state' && !hasCatalog) continue. Those records are dropped silently. When the catalog later arrives,project()replays only the retained 500-record window, so the earliest relevant writes never contribute attribution.Reproduction
A session whose feed buffers more than 500 relevant worktree records before the first Git catalog message resolves (e.g. an agent that opens quickly while Git IPC is slow) loses all but the newest 500 records' attribution for that session.
Impact
Worktree attribution can be missing for the first ~500+ records of relevant evidence in a fast-start session — a data-integrity gap for the work-context projection, not a performance concern.
Environment notes
Pre-existing on
main(present before #808's replay-cache optimization; #808 preserved this folding path). Surfaced during independent review of #808; deliberately NOT fixed in that PR. The fix would buffer/fold with a provisional catalog or retain worktree-path-bearing records regardless of catalog presence.