fix(status): see committed-but-unindexed changes without losing the fast path (#1829)

[inth3shadows]

An alternative to #1843 for the same bug — same symptom, same repro, but it keeps the git fast path. @bompus got there first and his diagnosis matches mine exactly; this is offered as a choice of shape, not as a competing claim on the bug. Take whichever you prefer, or take his and treat this as a follow-up.

The difference is what replaces the incomplete candidate set. #1843 drops the fast path and compares the full source inventory on every call. This stamps the commit the index was built at and asks git for the committed diff since that commit, so the candidate set becomes complete without the tree walk.

Why it matters

#1843's own table, on a 14,486-file VS Code checkout:

State	Before	#1843
Clean	50.2 ms	614.2 ms
One uncommitted edit	59.1 ms	676.7 ms
Committed, not indexed	51.1 ms (wrong)	604.4 ms (right)

getChangedFiles is on the hot path — codegraph status, every sync, and the watcher's catch-up all land here — so that cost is paid per call, forever, to catch a case that is rare per call.

Measured here, same checkout, all three arms on one machine

VS Code at 7b7e49c8 — the commit #1843 measured — indexed once (14,137 files, 475,316 nodes) and read by all three builds. Timing getChangedFiles() in-process, excluding CLI startup, as #1843's table does: 2 warm-ups then 10 samples, two passes per state with the arm order reversed on the second, nice -n 10. WSL2/ext4, Node 22.23.2.

State	main @ 3ed73bc	#1843	this PR
Clean	119 ms	1470 ms	132 ms
One uncommitted edit	131 ms	1488 ms	136 ms
Committed, not indexed	122 ms (reports 0 — the bug)	1547 ms	146 ms

Median of 10, both passes within ~1% of each other. Ranges across all samples: main 117–184 ms, #1843 1451–2517 ms, this PR 129–150 ms. Both fixes report modified: 1 in the committed state; main reports nothing.

The absolute numbers are higher than #1843's on every arm — different machine, and this box was busier — but all three arms are measured under the same conditions, so the ratio is the point: the full-inventory walk is ~11× the current cost, the committed diff is ~1.1×.

What it does

The index stamps the commit it was built at (indexed_at_commit), and the git fast path adds git diff --name-status --no-renames <stamp> HEAD to the candidates git status already gives it. One extra git call; the rest of the function is untouched.

This is also the only cheap way to catch a committed modification. A file the index already tracks is invisible to git status once committed, and a DB-side inventory can't see it either without re-hashing the file — which is the walk we are trying to avoid. The committed diff names it directly.

Mechanics worth reviewing:

• The stamp is written by a full index and by every whole-tree sync — a --paths sync absorbs only part of the diff, so it must not stamp. It is captured before change detection runs, so a commit landing mid-sync is never claimed as absorbed.
• Committed lines go through the same classifier as working-tree lines, so an excluded dir stays excluded (Incremental sync (git-status fast path) bypasses the ignore matcher — tracked files in excluded dirs leak back into the index #766, codegraph index wedges indefinitely at "Resolving refs" 94% on a repo with a large *tracked* JS/TS asset dir and there's no way to exclude it #999) and a committed A the index never saw still lands in added.
• --no-renames is deliberate: the index keys files by path, so a rename is a removal plus an add.
• A path reaching the list from both sources — committed, then edited again — is counted once.
• A stamp git cannot resolve (rebase, gc, shallow clone) falls back to the existing full scan, as does an index built before stamping existed. The next sync stamps it and the fast path returns, so an existing index self-heals after one slow call and is never slower than fix(status): detect committed but unindexed changes #1843.
• The exported getGitChangedFiles keeps its contract — a working-tree diff for callers holding no index. The trust decision lives in canTrustGitFastPath, which only the DB-aware caller asks. (git-changed-untracked-dir.test.ts catches this if it regresses; it caught it for me.)

Where #1843 is strictly better

One case, and it is real: a file hidden from git with git update-index --assume-unchanged and then edited. #1843's inventory walk sees it; this does not, because neither git status nor git diff reports it. Verified on all three builds:

base     pending {added: 0, modified: 0}
#1843    pending {added: 0, modified: 1}   <- correct
this PR  pending {added: 0, modified: 0}

If that case matters more than the per-call cost, #1843 is the right fix and this one isn't.

Tests

Nine cases in __tests__/sync.test.ts: committed add, committed modify, committed delete, committed rename, zero-after-sync, the double-source count, the exclusion filter, an unresolvable stamp, and a pre-stamp index upgrading. Six of them fail against pre-fix source.

Validation

Based on upstream 3ed73bc. Linux/WSL2, Node 22.23.2 for the source build (the source tree's Node gate rejects 26; the published bundle carries its own runtime).

• npx tsc --noEmit clean.
• npm test: 13 failures, all of which reproduce on pristine upstream/main @ 3ed73bc in a throwaway worktree against the same index — mcp-callers-truncation, nextjs, object-literal-methods, react-native-bridge, ui-server-api, ui-steps-api, ui-steps-api-servers, ui-steps-cross-tier. No new failures.
• Both repros from status.pendingChanges reports zero for a committed-but-unindexed file — the git fast path never hash-checks what git omits #1829 re-run end to end on a built binary.
• Windows and the viewer build were not re-run for this change.