IndexQuery

Answers a predicate using an index where it can and a scan where it cannot.

The narrow reference implementation, and it is kept as one. rabosh-query owns the predicate AST, the planner and execution, and answers anything this does — with more indexes, over more segments, and without materialising a key list. What this is for now is what it was for before that existed: a second, independently written implementation of the same claim over the same readers, which is the instrument this project reaches for whenever a claim is worth more than an assertion. It shares TermExtractor with the planner, so the two are not two definitions of what a path means — only two ways of asking.

One index, one operator, and a whole-store scan for anything else. Reach for QueryEngine instead.

The rule it implements is the whole reason an index here cannot change an answer. Three parts, and every one of them is load-bearing:

1. Candidates, not answers. The index reports that a segment's newest version of a key carried the value. A newer version may live in a shallower segment or a memtable, so every candidate is re-evaluated against the document the snapshot can actually see.

2. Everything uncovered is scanned. A segment with no posting file, a segment too new for this snapshot, and a store with unflushed writes all mean the same thing: the candidate set is not a superset of the answer, so the answer comes from a scan instead.

3. The predicate is evaluated by the same walk that built the index. Recheck runs TermExtractor over the visible document, so "does this document match" is answered by the code that decided what to index. A second, differently-shaped evaluation would be a second definition of what a path means, and the two would eventually disagree about an array or a nested null.