index/kv.js:437:9B-459 and :206-229: find re-lists the STAGE, re-walks the igno
tree and re-opens the kv lane per call, nothing memoized on ctx.rev (unlike
idx.laneOf/TIPS). On /src/linux 700 ms (kv.find is 815/760 ms warm, of which
candidates is stageOf 270 ms over 94851 entries + the walk);
strace: 13124 getdents64 and 12440 open, 5808 of them ENOENT — one
.gitignore probe per directory — all to index nine .md files carrying 0
pairs. The board does one find per registered repo per run and bee http
per request; the openKv/close pair also re-runs idx.sweep's
readdir+unlink each time. Found in the 2026-09-18 index review.
Memoize sweepIn's {files, blocks} on (root, ctx.rev) — cache.js supplies
the witness, a CLI run (rev null) keeps today's path — and take the lane
through idx.laneOf.
sweptIn holds { rev, s } per worktree root and hands the
WHOLE sweep back, rec too: the board reads files/rows,
and a repeated rec on a rev that stands is the same record.
A test hook (_hash, _crashAfter) neither reads nor feeds the
memo, so the rows leg still drives the raw sweep.
idx.laneOf keys LANES on the worktree root alone and the door
already parks the wh128 lane there, so a kv64 lane under that
key would be handed to door.js laneUp as an index. index.js
is off limits this round, so kvCtx asks under root+"\0kv",
a root no path can spell. The proper fix is a lane KEY arg on
laneOf (laneOf(ctx, kind, open)); gritzko's call.