index/kv.js:352:9B-356 with :62: killBlock runs only for the SWEEPING
worktree's code, so a worktree that is deleted — the bee fork per-ticket
flow, done.js retirement — leaves its blocks and its MARK row in the shared
lane forever. Confirmed: main sweep 2 blocks; git worktree add + sweep 4
blocks / 2 marks; rm -rf + git worktree prune + sweep still 4 / 2, 0
tombed. :247 readAll scans the whole lane every sweep, so a query's cost
grows with every fork the repo ever had. Found in the 2026-09-18 review.
Tombstone blocks whose wt code names no worktree in git worktree list /
$SRC_ROOT, or GC them on a cold run; consider seeking the marks plus this
worktree's path_hl set instead of a whole-lane scan.
<commondir>/worktrees/*/gitdir plus the
main worktree -- the file git worktree prune unlinks, so
the dir IS git worktree list: no git call (BEE-009's rule)
and no registry read: the lane is per COMMONDIR, so exactly
those checkouts ever wrote a row into it. A set that cannot
be read whole (no commondir, a gitdir that is not
<root>/.git) collects NOTHING: a lane of live blocks must
never die on a failed readdir.(root, rev), so that memo can never go stale behind it;
a GC pass of its own would have had to invalidate it.readAll, kv.js:247:9B). Seeking
the marks plus this worktree's path_hl set cannot see a
block whose FILE is gone -- a dead file is in no candidate
list -- so the deleted-file tombstone at kv.js:352:9B and this
GC both need the scan. Answering it by seek needs a per-wt
DIRECTORY of the path_hls a checkout owns, i.e. a new record
kind: a format change, gritzko's call, not this ticket.