v1.108.298 — A campaign that saw nothing
Two fixes and a language.
refresh certified indexes it re-parsed zero files of
The pre-stamp discovery check asked only whether the corpus had GROWN, and for its whole life could not see the opposite failure. When a source root goes away — moved, renamed, unmounted, a removed worktree, a cleaned scratch dir — discovery returns an empty list, so nothing drifts, no batch errors, and the campaign stamps the target generation having re-parsed nothing.
The damage is unrepairable, which is what lifts it above a wrong number. A stamp equal to the constant is indistinguishable from a genuine one, so the index is exempt from every future upgrade — the exact bucket v1.108.297 bumped PARSER_GENERATION to drain. The tool built to prevent that bucket was filling it, and the way in was running the documented command.
Now refuses on corpus_unreadable, and on index_unreadable when the index cannot be read at all — unknown blocks, same rule as has_any(). The test is empty-vs-non-empty rather than a shrink threshold, because a repo may legitimately lose most of its files and a percentage nobody measured is a magic number; the partial case is disclosed as indexed_files_not_reparsed instead.
Racket support, with its ceiling measured
Thanks to @otherjoel (#548). .rkt / .rktl / .rktd are now indexed by a custom head-symbol walker, because the tree-sitter grammar is fully homoiconic — there are no named define or struct nodes. The first Lisp here with import edges and call references.
The measurement is the point of that PR. benchmarks/racket_fidelity/ scores the extractor against Racket own expander over 211 files and 3,526 definitions:
extra |
0 | nothing emitted is a name Racket does not know |
wrong_span |
0 | every definition falls inside the bytes returned |
missing |
485 | 86.2% found; 152 of 211 files completely clean |
callable_unknowable |
212 | a ceiling, not a bar |
Those first two buckets are gated in CI off frozen oracle data, so the check runs on machines with no Racket installed. The rest are reported rather than gated, because neither is reachable by parsing more carefully.
No PARSER_GENERATION bump is needed: that counter re-parses files already in an index, and .rkt was wrong_extension everywhere, so Racket arrives through discovery.
The published benchmark reference had drifted for 22 days
Captured 2026-08-03 on v1.108.233, before every parser change v1.108.297 bumped the counter for. Re-measured at the same pinned commits — and our side moved against us:
| before | after | |
|---|---|---|
| jMunch total | 23,805 | 24,249 |
| vs grep-top-3 | 27.9x | 27.4x |
| vs read-all | 237.3x | 233.4x |
Two independent causes that should not be conflated. gin is the clean parser signal: identical file count, identical baseline, +81 symbols from #428 Go constants. express and fastapi each gained 4 files at the same commit, which is a coverage change — a property of the installation, never of the repo.
Eight artifacts mirror one benchmark run, not the four our notes claimed. Both sync tests passed with five still on August-3 figures, including a table whose grand total and per-repo rows were 22 days apart.
Tests: 8379 passed, 17 skipped, 0 failed (8396 total, +64) + ruff clean; 3.13 CI-env reproduce at the same total and skip split.
