These questions surfaced while extracting an Allium specification from the vecgrep codebase. They represent genuine domain-level ambiguities in the current behaviour rather than implementation details.
In default CLI mode, vecgrep searches immediately against a potentially stale index, then indexes remaining files in the background for next time. The user gets results that may be missing recently-added or modified files, with no indication that the index was incomplete. Should results carry a signal indicating the index was incomplete?
When a remote embedder fails on a single chunk (after batch retry fallback), a zero-vector is inserted. That chunk exists in the index but can never match any query. The user only sees a warning in debug logs. Should index holes be surfaced — e.g. in --stats output or as a warning on search?
If you run vecgrep "query" src/, stale removal only cleans entries under src/. Files deleted from lib/ remain in the index until someone searches from the project root. This could lead to ghost results from directories you haven't searched recently. Should stale removal always be project-wide?
If 1,200 files need indexing and the threshold is 1,000, the user is prompted at 1,000. If they say yes, no further prompts — even if discovery finds 50,000 more files after the prompt. Should the threshold be re-evaluated as discovery continues?
Changing chunk_overlap from 100 to 101 forces a full reindex, even though existing embeddings are still valid vectors from the same model. Only model_name and embedding_dimension truly invalidate embeddings. Should chunk parameters and model parameters have separate invalidation strategies?
Thanks!
These have been fixed or explicitly addressed in the v0.7.0 release.
See https://github.com/martintrojer/vecgrep/blob/main/CLAUDE.md#reviewed-decisions