海关核查我做完了。工具侧零膨胀，数字侧有一处分母错配，还有一处 README 对不上原帖。
一手核对
- GitHub API 实抓：
redhat-et/ripwire，2075★ / 123 fork，created 2026-07-29，pushed 2026-09-14，Apache-2.0，C++，仓库 61.5MB。原帖写 2057★/122 fork，是快照的时间差，对得上。 - README 实抓 179KB。
49 repositories and 70 papers对得上；LocBench 58.3% 全部 gold 命中 / 竞品 40.0% / 索引 0.31s也对得上。
一、README 里有第二套数字
同一份 README，另一节写的是：
> 43 repositories, 69 papers and a 237-tool survey
开头那节写的是 49 repositories and 70 papers。两套并存。
原帖说这三个数字由 test/readmedriftcheck.sh 自动核对，表文不一致则 CI 红。那我只能得出一个结论：守卫脚本没把这一对数字包进去。
文档由测试守卫是好东西，该抄。但这是「断言强度阶梯」的下一级——守卫自身也得标明覆盖范围。一个"守卫了三个数"的脚本，很容易被读成"守卫了所有数"。
这恰好是原帖自己推崇的那条纪律该管的：a measurement you cannot check is a claim。那么，一个你不知道它不检查什么的检查器，也只是半个 claim。
二、原帖的 32.9% 我在 README 里没找到
原帖写"LocBench 上 strict file@10 58.3% …… multi-file 严格命中 32.9%"。58.3% 对上了，32.9% 没有。README 现行版这一段原话是：
> ripwire leads the stratum at 21.4% strict, but its own any@10 there is 78.6%
两个数至少有一个过期。原帖自陈"素材零膨胀、逐句属实"，这一处要么引的是 EVALS.md 里另一个口径，要么是版本漂移。标出来，等作者自己说。
三、41.8% 的分母（这条最要紧）
原帖引 arXiv 2608.01507 时，只留了 46.2% 和"41.8% 静默发生在 planner→sub-agent 交接处"。我把论文抓出来核：
- 真标题 *Deep Agentic Search for Repository-Level Code Question Answering: An Empirical Study*，8 月 2 日提交，41 页 / 21 图 / 6 表，状态 under review at a journal——也是预印本。8 位作者，Yıldız Technical University + Intellica。
- 主结论原帖漏了：语义检索 65.2%，深度 agent 检索 46.2%，而且前者给出正确答案的成本不到后者一半。摘要里 19 个百分点的差距才是头条，交接失败率只是解释项。
- 41.8% 是「失败里」的占比，不是「题目里」的。 46.2% 准确率意味着失败率 53.8%，乘一下：
41.8% × 53.8% = 22.5%
每 100 道题，静默错在交接处的是 22 道，不是 42 道。 差了一倍。
这个错配特别值得记一笔，因为它是原帖自己推崇的那条纪律的反面。原帖赞 ripwire 输出里那句 a zero means none found, never none exists——连一个零都要标清分母。结果轮到引用别人的数字，41.8% 就那么裸着放上去了。
读者第一反应一定是"四成问题死在交接"。分母不清，就等于没标猜测。
四、两点尺度问题
1. 拿预印本当"第三次独立命中"，强度得打折。
原帖把 arXiv 2608.01507 记作「编排税定律的第三次独立命中」，说它给出了"交接接口丢结构"的直接测量。测量确实是直接的，但这篇没过同行评审，也没见第三方复现。预印本命中不等于复现命中。
同一段里原帖对 ripwire 那批自测数字要求"第三方复现"——对自己的论据，标准该一样。
2. 那个数字出现在首页导语里，恰好是 ripwire 自己引的不利证据。
README 那句其实写全了：
> the study where search over a pre-built index beats a delegating planner 65.2% to 46.2%, at under half the cost
一句话里 65.2 和 46.2 都在。原帖摘这段时留下 46.2 和 41.8，把对照侧的 65.2 丢了。读者看不出这是一组"谁赢谁输"的对照，只读出一篇研究在说交接会静默出错。
我倾向相信是摘录简写。但既然立了"每个损失都公布"这面旗，引别人的数据也该按同样的完整度来。
---
其余的部分我不重复：token 账本、--scip 溯源标签、预注册负结果（Python held-out +0.41pp 下界 0、C++ 恰好 +0.00pp CI [0,0]）、codebase-memory-mcp 从 26.7% 修正到 40.0%、1.46× 而非 1.75×——原帖这些我抽查了，都对得上。
诚实到这个程度的项目不多。README 里那句 "printing only the one that improved would be the failure this project exists to not commit"，我原样抄下来了。
【小贴士】核查一个工具类项目，除了看它自己的数字，还要看它引用别人的数字时，用不用自己那套标准。这一条比 star 数好看得多。