Deferred from PR #1085 review.
Original reviewer comment: #1085 (comment)
Context: The backfill guard in src/domain/graph/builder/pipeline.ts skips backfill on incrementals when removedCount === 0 && changedCount === 0. PR #1085 broadens the trigger to changedCount > 0 to cover most incrementals, but a residual gap remains: when a developer adds a brand-new file with an extension outside Rust's file_collector (e.g. .hcl, .scala, .swift on a current binary) and there is no other file activity, both removedCount and changedCount are 0 and the new file silently does not appear in the graph until the next full rebuild.
Why deferred: Closing this fully requires either (a) tracking an explicit "newly observed file" signal from the JS-side change detector before the orchestrator runs, or (b) accepting the ~45ms backfill cost on every incremental again. Both are architectural decisions beyond the scope of the perf tuning PR. The narrowed gap ("new unsupported file added with zero Rust-side activity") is rare; the perf win on the common case (no-op / 1-file rebuild) is significant.
Suggested fix direction: detect added-but-unsupported files at the JS layer (the file walker can see them; the Rust collector cannot) and force a backfill in that case.
Deferred from PR #1085 review.
Original reviewer comment: #1085 (comment)
Context: The backfill guard in
src/domain/graph/builder/pipeline.tsskips backfill on incrementals whenremovedCount === 0 && changedCount === 0. PR #1085 broadens the trigger tochangedCount > 0to cover most incrementals, but a residual gap remains: when a developer adds a brand-new file with an extension outside Rust'sfile_collector(e.g..hcl,.scala,.swifton a current binary) and there is no other file activity, bothremovedCountandchangedCountare 0 and the new file silently does not appear in the graph until the next full rebuild.Why deferred: Closing this fully requires either (a) tracking an explicit "newly observed file" signal from the JS-side change detector before the orchestrator runs, or (b) accepting the ~45ms backfill cost on every incremental again. Both are architectural decisions beyond the scope of the perf tuning PR. The narrowed gap ("new unsupported file added with zero Rust-side activity") is rare; the perf win on the common case (no-op / 1-file rebuild) is significant.
Suggested fix direction: detect added-but-unsupported files at the JS layer (the file walker can see them; the Rust collector cannot) and force a backfill in that case.