rtk find: 9.4% reduction on ~19.6k tok/call — path lists need common-prefix folding

Summary

rtk find is the one high-volume command family where the reducer barely fires.
On a 30-day sample from a real Claude Code workload it averaged 9.4% reduction
on ~19,558 tokens of raw output per call (n=13) — the largest raw payload of
any tracked family, and the weakest reduction.

The cause is that find output is a path list, and the current filter treats
it as generic lines. Path lists have a cheap structural reduction available that
generic line filtering cannot see: common-prefix folding.

Evidence

Measured via rtk gain, rtk 0.49.0, macOS 15 (Darwin 27.0.0), Apple Silicon:

  #  Command          Count  Saved    Avg%     Impact
 1.  rtk ls -R            2  57.0K   99.0%     ##########
 2.  rtk find            13  23.9K    9.4%     ####......   <-- 19,558 tok/call raw
 3.  rtk git status       2   2.1K   32.5%     ..........
 5.  rtk cargo test -q    7    413   57.4%     ..........
 9.  rtk grep            14    107   19.2%     ..........

rtk ls -R on the same trees reduces 99.0%, so the machinery works — find
specifically is not getting a structural filter.

Raw tokens/call derived as Saved / (Avg% / 100) / Count.

Proposal

Fold sibling files under a shared directory once the count exceeds a threshold:

src/foo/a.rs
src/foo/b.rs
src/foo/c.rs
src/foo/d.rs

becomes

src/foo/  [4 files]

with the elided entries recoverable through the existing rtk recall <hash>
path, exactly as other filters already do. Extensions could be summarised in the
rollup (src/foo/ [4 files: .rs]) when they are homogeneous, since that is
usually the question the caller was actually asking.

This is deliberately framed as command-aware work rather than a generic stream
reducer. A path list is semantic structure; folding it needs to know that / is
a hierarchy separator and that a directory is a meaningful grouping key. A
byte-level or line-level reducer cannot recover that, and building one for this
case would be the wrong tool.

Why it matters for the recall trade

The reduction is only half the story. For a family with E tokens elided per
call and T tokens for an extra round-trip, the break-even recall rate is
r* = E / (E + T). Large E buys tolerance for being wrong; small E does
not. find currently has a huge raw payload and a tiny E, which is the worst
corner of that trade: all of the volume, none of the headroom.

Secondary observation (separate issue if you'd prefer)

filters.ignore_dirs and filters.ignore_files in config.toml are parsed but
do not appear to be consumed by ls / tree / find in 0.49.0. Verified with
sentinel entries ignore_dirs += "ZZCANARYDIR" and ignore_files += "*.zzcanary":
matching paths still appeared in all three commands. The node_modules / target
suppression visible in rtk tree appears to come from a compiled-in noise rule
rather than from config. Happy to open this separately with a reproduction script.

Environment

rtk 0.49.0
macOS Darwin 27.0.0, arm64
retriever.mode = "sqlite"
awareness.level = "default", hook installed via `rtk init -g`

Start by locating the command-aware filter used by rtk find and compare it with the structural reduction used by rtk ls -R. Trace how elided entries are stored and recovered through rtk recall <hash>. Done means sibling paths can be folded with counts, homogeneous extensions may be summarized, and the elided paths remain recoverable.