@@ -199,7 +199,7 @@ Since the 2026-10-13 run the fork's one weak spot has closed: a one-file sync in
 
 The fork starts its resolver pool at or above 150,000 pending references. Below that, it can start the pool part-way through if at least 20,000 unresolved references remain and the estimated main-thread work is at least 0.4 s. An explicit `CODEGRAPH_PARALLEL_RESOLVE_MIN` replaces both gates. Against a pre-change baseline build, five tested corpora indexed 11-48% faster at 56-132% more peak memory with identical graphs ([measurements](docs/benchmarks/adaptive-pool-engage-2026-10-15.md)).
 
-A [2026-10-15 mid-size comparison](docs/benchmarks/midsize-sweep-2026-10-15.md) includes that change and #488/#489, comparing fork `f405d86b` with upstream `c71a3d03` on Node 24.22.0. Across ten corpora, three runs per engine plus three identical-build fork controls found no clear wall-time change on four and longer fork times outside the declared noise range on six. Ktor fills the previously unmeasured interval at 144,028 processed references; its median was 13.90 s for the fork versus 7.69 s upstream. Exposed was 9.81 s versus 6.07 s. A later change to the Kotlin companion check cut a full index of ktor by 22% and of Exposed by 19% against the fork at `d161ef74` just before it, with identical graphs (2026-10-17, three alternating runs per build; the figures are in the changelog and #515). Both still take longer than upstream `e8ec7fd8` did in the same runs. All ten produced different graphs across engines, so these exploratory observations do not establish equivalent-work performance. Windows load observation, complete cgroup counters and observer calibration are missing; ranges, CPU, memory, outputs and all four rejected attempts are disclosed in the report. The [2026-10-12 sweep and its statistical caveat](docs/benchmarks/fork-vs-upstream-node-bun-2026-10-12.md#mid-size-projects-and-the-resolver-pool) remain historical; no old cell met its predeclared p-value rule.
+A [2026-10-15 mid-size comparison](docs/benchmarks/midsize-sweep-2026-10-15.md) includes that change and #488/#489, comparing fork `f405d86b` with upstream `c71a3d03` on Node 24.22.0. Across ten corpora, three runs per engine plus three identical-build fork controls found no clear wall-time change on four and longer fork times outside the declared noise range on six. Ktor fills the previously unmeasured interval at 144,028 processed references; its median was 13.90 s for the fork versus 7.69 s upstream. Exposed was 9.81 s versus 6.07 s. Three later changes, a cheaper Kotlin companion check (#515), one compiled-pattern cache shared by the resolver threads (#517) and no checkpoints inside the resolution commits of a fresh index (#518), bring a full index at `5b5ac434` to 9.91 s on ktor and 6.95 s on Exposed: 26% and 27% faster than the fork at `d161ef74` just before them (13.46 s and 9.55 s), at 19% and 17% lower peak memory (1,996 and 2,022 MiB against 2,479 and 2,427 MiB), with identical graphs (2026-10-17, three alternating runs per build, each change outside the spread of two identical builds; the figures are in #522). Both still take longer than upstream `e8ec7fd8` in the same runs (7.62 s and 5.71 s), and both now peak lower than it (2,636 and 2,133 MiB). All ten produced different graphs across engines, so these exploratory observations do not establish equivalent-work performance. Windows load observation, complete cgroup counters and observer calibration are missing; ranges, CPU, memory, outputs and all four rejected attempts are disclosed in the report. The [2026-10-12 sweep and its statistical caveat](docs/benchmarks/fork-vs-upstream-node-bun-2026-10-12.md#mid-size-projects-and-the-resolver-pool) remain historical; no old cell met its predeclared p-value rule.
 
 **Full index** (`codegraph init`), time and peak memory: