Index staleness: automatic reindex not triggering for merged changes

[alfhen]

Context

During a dogfooding session (2026-02-06), the MCP server was running with an index from 2/5. After merging PR #136 (changes to response-budget.ts), the index remained stale:

• get_files_context on response-budget.ts returned old line numbers (pre-refactor)
• pendingFileCount: 0 reported — the server didn't detect the changes
• lastReindexDurationMs and msSinceLastReindex were null in every tool response

Expected Behavior

Lien has two automatic change detection mechanisms:

1. Git change detection — polls for git state changes (branch switches, new commits)
2. File watching — watches for filesystem changes via chokidar

After pulling/merging new code on main, one of these should trigger a reindex of changed files, and indexInfo should reflect accurate reindex metadata.

Observed Behavior

Neither mechanism triggered. The index stayed on the 2/5 version despite new commits being pulled. lastReindexDurationMs and msSinceLastReindex remain null, suggesting no automatic reindex has ever fired during this server session.

Investigation Areas

• Is the git change handler (createGitChangeHandler) actually firing on git pull?
• Is the file watcher (FileWatcher) picking up changes to files modified by merge?
• Are lastReindexDurationMs / msSinceLastReindex being populated correctly in indexInfo?
• Could there be a race condition where the MCP server starts before the watcher is ready?

Found During

Dogfooding session — .wip/dogfood-report.md has full details.

[alfhen]

This was fixed in PR #146 (61f3d5e), merged 2026-02-07.

Root cause: watchGit() added .git/ paths to the same chokidar instance that had .git/** in its ignored patterns. Chokidar's ignore took precedence over add(), so git change events were silently dropped — meaning neither git pull nor git merge triggered a reindex.

Fix: PR #146 introduced a dedicated chokidar instance for .git watching that isn't subject to the .git ignore patterns.

The lastReindexDurationMs / msSinceLastReindex being null was a symptom (no reindex ever completed), not a separate bug.