v1.108.295 — What the guard could not see
Four items, three of them a check that could not observe the thing it claimed to check.
_build, the third spelling of a build tree
We excluded build and .build from indexing and not the underscore spelling — which is what Elixir/Mix, Sphinx and Dune use. mix copies dependency sources into _build, so an Elixir project indexed here got every dependency symbol twice, with the copies competing against the originals in ranking. That is the v1.108.234 duplicate-source-tree defect wearing a third name; the only reason it survived is that nobody wrote down the third spelling.
Bounded by gitignore, and listed anyway: build/ is in that same .gitignore and has been excluded since the beginning.
A strict deny now requires a target the hook can resolve (#541)
_bash_targets_outside_roots reads path tokens out of the raw command string, so grep ~/x.md was allowed and grep $HOME/x.md was denied — same destination, opposite verdicts. A deny now requires a resolvable target, which is the caution already applied to find, to pipelines, and to ../. It downgrades to a nudge, never to silence: a wrong nudge is a sentence of text, a wrong deny is blocked work.
The detector is deliberately not a bare \$. A trailing $ is a regex end-anchor and grep "foo$" src/ is idiomatic, so suppressing on any $ would have quietly weakened the enforcement a strict user opted into.
A second blindness surfaced from that test: the token regex matched only POSIX roots, so /c/Users/j/x.md was seen and C:/Users/j/x.md was not — a strict deny on a path outside every indexed root, on the platform most of this project's users are on, with the verdict depending on how the drive was spelled. That one is genuinely resolvable, so it got a real fix rather than a downgrade.
Only JCODEMUNCH_ENFORCE=strict was affected; advisory, the default, got one extra nudge.
A cache hit-rate that counted key-presence as validity
analyze_perf published hit_rate bare, where a hit is key-presence in the 256-entry session LRU — how often the cache answered, not whether the answer still described the index. arXiv:2608.20280 measured raw rates of 51–60% falling to 1.1–2.2% once validity was checked.
The system already knew the difference and the metric did not: #377 item 3 revalidates cached absences, #404 re-annotates row freshness. The raw rate is kept and stamped hit_rate_basis, with hits_validated_fresh / hits_validated_stale / hits_unvalidated beside it. hit_rate_revalidated is None rather than 0.0 when nothing was validated — a could-not-establish must not render as a measurement.
Docs
The mcp_toolset default_config defer path for Anthropic tool search, and the vendor's 30–50 tools selection-degradation threshold recorded against our 91 beside the catalog moratorium — with explicit guards against reading a token figure as an accuracy result.
Verification
Local 8264 passed / 17 skipped / 0 failed; the 3.13 reproduce is identical, same 8281 total and the same skip split. All 9 CI jobs green on the released SHA before anything shipped.
Correction, added 2026-08-24 after publication. One of the guards referred to above was wrong, and the record should say so. It claimed the vendor's tool-selection accuracy claim "carries no number." That is true of the tool search docs page and false of the Advanced tool use post it links from, which reports selection accuracy going 49% → 74% on Opus 4 and 79.5% → 88.1% on Opus 4.5 with tool search enabled.
The moratorium verdict is unchanged, and the reason is now the accurate one: their number measures the model's selection accuracy with a retrieval layer available, not our router's rank-1 accuracy on agent wording — which is what our exit conditions gate, and which sits at chance.
Nothing in the shipped code is affected; this corrects a claim made about a third party's published work. Details in the
[Unreleased]CHANGELOG entry.