I've solved most of my problems by following these guidelines: one worktree for each code domain, using git sparse-checkout to limit the context (e.g. one worktree for the Rust core, one for Swift macOS, one for Swift iOS, etc.), and putting all the rules in claude.md (or agents.md). This way I get "containerization", lower context, and faster search across the codebase. After that, I only install the skills that actually matter for the context.
Maybe it's just conservation of angular momentum: if you look closely, you can see that the spin axis and the way she applies the force aren't perfectly tangential to the object's axis, so the lower point of the T-shape is "bouncing" between many positions. If I'm not mistaken, this is explained by the "intermediate axis theorem".
Ah ok, the lazy construction part is what I was missing, if you basically never build the full key, there's nothing to cache. Makes sense now why the LRU didn't help. I'll think about it over the nextdays.
Probably a naive question, but: couldn't you precompute some vector representation of the string once, and reduce collation to a vector comparison? Basically move the cost upfront and get back to the "fast" byte-comparison case?
Emacs is powerful, but the complexity overhead of managing a custom trust layer could easily become a major maintenance bottleneck for average users. Worth considering, but the friction point is significant.