INDEXES.mkd rules that every index read rides the SEEK cursor: range/
prefix answer NOTHING for a key a seek finds at a 2^64 bound (the KNOWN
TRAP index/index.js:440:Mw restates). Yet index/resolve.js:38 and :42 —
candidates() — do ix.prefix(q.fn << 24n, 24, ...); fn is a 40-bit text
hashlet, so any filename hashing into the top of that space forms the bound
query and answers zero rows. These are the only two prefix/range reads in the
package. Effect: the partial-path resolve (LITE-011 FSEG) silently misses —
links and permalinks to such files do not open. Found in the 2026-08-21 review.
2026-09-18 index review, re-confirmed at ///bee#8cb69a0: index/resolve.js:38 now
reads ix.range(key, key + 1n) and still misses — over bee's own lane 12 of
1545 sampled keys answer 0 rows from range where seek finds 1-7 (1/281
FSEG, 9/803 LINK, 85/5117 SYM); resolve("logspine/pty.js") -> [] while bare
pty.js resolves. view/log.js:122:Uf cparOf rides the same read: on ~/src/linux
107 of 20000 commits have CPAR rows seek finds and range reports as zero,
so isIndexed() calls them un-indexed and ancestry truncates there.
index/tridex.js:117:zw reads the u32 lane through range/get too; probes found
that lane's range correct ([lo,hi) exclusive, memtable visible, runs
merged), so INDEXES.mkd's "every read rides seek" wants a ruling on whether
the u32 lane is exempt.
Repro first: a fixture filename whose fnHl top bits are all ones (brute-force
a short name), indexed, then resolved — the test shows the miss. Rewrite
candidates() on the seek cursor, galloping as the sibling scans do.
No index format change; resolve output stays identical for all passing names.