The workspace sync windows its walk from the newest cached timestamp minus one minute, and creating any item (an issue, a comment, a close) inserts its commit into the cache directly at that moment. A git commit whose committer date is more than a minute older than the next created item is then outside every future window and never ingested: merge a branch, comment on its issue within the minute, and the merged commits never reach the cache or the TUI. Diagnosed 2026-09-29: main commits from #commit:c9cebd3a8983 through #commit:b52cdd047a69 were missing while every gitmsg item showed, because each overnight merge was followed by a close comment while the full tier had aged the merged commits four minutes past the window.
The window must come from a real walk watermark (recorded when a walk finalizes), not from MAX(timestamp), which direct inserts advance. Needs a design note: it changes core/fetch and what core_sync_tips records. Repair for an already-starved cache: delete the workspace row from core_sync_tips and the next sync re-walks in full.
↩ Max Rakhimov · 2026-09-30
Fixed on main by #commit:ee5a6ec846ae: the walk windows by ancestry (git log --all excluding the previous tips), never by a clock, with three guards: the tip advances only when every current non-merge tip commit is cached, an unmarked tip row from the old code yields one full backfilling walk, and a reset repository rebuilds in full. Seven invariants are pinned as tests. Two review rounds shaped it; both rounds' findings are triaged in the commit body. Already-starved caches heal on their first sync after this change.