ripwire

一个 C++23 二进制，把仓库读成一个带排名、结果确定的图谱并打到标准输出，瞄准的正是编码 agent 准备花 token 去翻文件的那一刻。一次串行爬取加上每种语言一个 tree-sitter 查询引擎，喂给一次 Personalized PageRank；所有动词都只是对同一张图的不同读法——改动前用 --callers、--deps、--arch、--impact、--situ，改动后用 --edit-check 与 --quality-delta，而 --for=TASK 或 --pack-task 会按 token 预算给某个具名任务打包一份上下文。同一套计算也通过 MCP 暴露给 agent：33 个动词，用架构文档自己的话说，是「a thin front door onto the same computation and the same renderer as a CLI sibling — one output shape, two surfaces」。构建用 cmake -S . -B build && cmake --build build -j；把它注册成 {"type":"stdio","command":"ripwire","args":["--mcp"]}；skills/install.sh --hook 会装上那些在工具调用前提醒 agent 的路由钩子与技能文件。输出是打在 stdout 上的压缩 XML，同样的仓库两次运行逐字节相同；爬取时丢掉的东西——体积上限、被 git 忽略的文件、没能解析的调用——都会写出来，而不是悄悄消失。

谁做的仓库归 GitHub 组织 redhat-et 所有，这个名字展开是 Red Hat Emerging Technologies。除此之外就没有旁的凭据了：仓库元数据里没有 owner 字段，README 全文（209,734 字符）里也不出现 "Red Hat" 字样——所以这层归属是靠组织名和仓库内部路径间接支持的，而不是靠项目自己说的任何一句话。报告里唯一直接的红帽标记在提交邮箱直方图里：dbrewste@redhat.com 出现在 4,135 次提交中的 1,651 次上。至于它出自红帽内部哪个团队，材料没有覆盖。干活的人高度集中：有关联账号的提交里 joyful-ii-V-I 占 3,554 次；25 人的贡献者名单由 barefootski（346）、quaterniondrift（93）与 lennix1337（33）领衔。

1. 01

   七月底出现，到九月已经发了二十个 release

   仓库建于 2026-07-29，而它最老的一条提交落在 2026-07-31，标题是 import from internal development tree——材料里关于这段代码此前从哪来的唯一说法，就只有这一句。此后它的速度是本档案很少记到的：4,135 次提交，其中 7 月 17 次、8 月 1,294 次、9 月 2,824 次；对应 2,374 个星、151 个 fork、8 个 watcher、58 个待处理 issue，Apache-2.0，语言 C++。它发了 20 个 release，每一个都既不是 prerelease 也不是 draft，从 2026-08-02 的 v0.1.0（标题为 ripwire v0.1.0 — the ripgrep of AI context）到 2026-09-27 的 v0.6.5；其中八个落在 29 小时之内：v0.3.0 在 2026-08-11 的 23:31，v0.3.8 在 2026-08-13 的 04:11。标签列表里有 v0.3.7 而它没有对应的 release，也没有 v0.1.0；标签一共 20 条，和 release 列表一样长。提交里数出 3,205 条共同作者尾注，最多的是 Claude Opus 5 的 1,417 条，其后是 Claude Fable 5 的 698 条与 Claude Fable 5.1 的 543 条，另有 Qwen3.8 Max 的 2 条。三份提交直方图彼此并不一致——joyful-ii-V-I 按作者名算是 3,993 次、按关联账号算是 3,554 次，而邮箱那一栏由 dbrewste@redhat.com 的 1,651 次领先。

2. 02

   五个阶段、没有回边，以及为每一句断言配一道闸

   架构文档把流水线写成五个阶段——ingest → graph → rank → serialize → cli / mcp——并用一句话把规矩定死：「Five stages, in that order, with no back edges. Each stage’s output is a plain data structure, so any stage can be tested in isolation and every verb is a different way of reading the same graph.」第一阶段里有两个选择担着大部分重量。爬取会先把每一个候选路径收齐，按字节字典序排序，然后才分配节点 ID，因为 ID 就是那张有序表的下标；文档说，若按目录顺序来，节点 ID、top-K 截断以及每一个与 diff 相关的动词都会在同一次树上产生抖动。而遍历本身保持串行——它「is the cheap half and is deliberately not parallelized; the parse pool is where the threads are」。抽取是一个查询引擎跑每种语言一份 queries/<language>/tags.scm（树里 23 个），另一条路被点名否掉：「a bespoke AST traversal per language — is forbidden here」。同一套直觉也管着测试：AGENTS.md 把规矩写成「Gate first, code second」，而机制是——新增一个 test/*check.sh 必须在同一次提交里登记进 test/regression.sh，否则 test/manifestcheck.sh 会失败。test/ 有 718 个文件，其中 661 个是 *check.sh 闸门，而这个数字每周都在动：#337 里重建 deck 时是 649 道，#341 是 650 道，一位贡献者引的是 651 道，而某次在负载机器上跑的完整 pargates.py -j 6 返回的是 665 道闸、657 通过、4 个环境跳过、4 个失败。

3. 03

   那个花掉 67 GB 的家目录

   #350 由 KilimcininKorOglu 在 2026-09-27 提出，正是内存守卫存在的理由。当 MCP 服务以 {"type":"stdio","command":"ripwire","args":["--mcp"]} 注册进 Claude Code、而会话开在家目录里时，一次 grep 调用把 --mcp 进程在七小时里推到 67 GB 的 phys_footprint；系统 swap 涨到 28 GB、只剩 458 MB 可用——机器是 Apple M1 Max、64 GB 内存、macOS 27.0。原因写在报告里并被维护者确认：在不是 git 仓库的根目录上无法套用 .gitignore，于是爬取会把该目录下的一切都做成图，而没有任何东西给这块内存设上界。#363 分几层作答。没人主动选过的根会被拒绝——$HOME 本身（即便它是 git 仓库）、文件系统或盘符根、各用户家目录的父目录、以及 /System、/usr、/etc、/proc、/sys、%WINDIR%、Program Files 这类系统树——回一行「no project root: <dir> is a home/system directory; pass a project path」，同一条规则也管到 MCP 请求里的 path=。为了证明它，还需要一个专门的测试接缝：RIPWIRE_TEST_MEMGUARD=hard:N 让第 N 次硬上限读数算作越界，而 B14 这条臂用 hard:1 跑两个极小的根，断言只存在一个 ingest 缓存块、且 stderr 里点名的是「root 1 of 2」。B12 那条臂则关掉 AddressSanitizer 的隔离区来跑，因为隔离区会把这颗被测量的 footprint 抬大。

4. 04

   一条从来没跑通过的健康检查流水线

   2026-09-27，llvm-x86 用 #342 报告「文档里写的 Linux sanitizer 仪式在 main 上根本跑不完」，并在同一分钟里拆出六个子 issue——#343 到 #348。根因是一个库的细节：libstdc++ 把 string_view 的比较算成 size_type 里的 n1 - n2，当一个是另一个的前缀时这个减法会回绕；而 G1 那条线开着 -fsanitize=integer 与 -fno-sanitize-recover=all，于是文档里写的自检会中止在一行「unsigned integer overflow: 4 - 16 cannot be represented in type size_type」上。有五处用裸 < 比较 std::string_view：src/ingest_crawl.h 的 pathInIgnoreSet、src/situ.h 里 --situ 的词典序邻居索引两处、以及 src/mention.h 的 finalizeNamedIdents 两处。修法是把五处统一走 rw::sortutil::svLess；维护者在那条评论里把「坏了什么、没坏什么」说得很准：「The ordering is still correct, so release binaries answer correctly.」另有两个子 issue 与 C++ 无关：两个闸门脚本以 100644 模式提交，而这套测试里其它每一个 *check.sh 都是 100755，直接调用会以 126 退出——而 CI 是隔着 shell 调它们的，所以从来没发现；以及文档里那条 GCC -DRIPWIRE_ASAN=ON 路径根本构建不过，因为一个 constexpr 谓词把一个来自 findByField 的指针喂进了 static_assert。#351 用一次提交关掉了 #342 连同六个子 issue，新加的 #6c 臂在 main 上是红的、打上修复后变绿。

5. 05

   一份报告要长成什么样，才配被信任

   #353 由 toasterbook88 在 2026-09-28 提出，是一份关于报告的报道。对一个 2,077 个文件的 skill 家目录跑 --scan-skills 返回了 156 条发现，其中 107 条是 EXFILTRATE:net-exfil；报告者逐行读了每一条被标出的行，把 107 条按目标地址分了类，并把触发条件收敛到三行。维护者认同这个判断——那条规则是按「a network verb plus any $VAR on the same line」触发的，对变量的值从哪里来一无所知，所以有文档的 API 调用和回环检测被当成 critical 报了出来。真正让这个 issue 值得留下的是第二条评论。报告者用「a single frozen script」重跑了一遍扫描，对它标出的三行逐一手工核对，然后发出更正后的直方图，并写道：第一版「was wrong in two places — one from over-claiming, one from a too-narrow var-trace — and I’d rather correct it explicitly than leave a number standing that a reader can’t reproduce」；更正之后，107 行里大约 89 行是有文档的服务 API 调用。维护者的回复是本档案可以直接引用的标准：「It’s exactly the kind of care that makes a report trustworthy. You withdrew the claims you couldn’t back, froze the classifier, and published the row-level TSV.」后续也走同一条路——#359 在 docs/LINEAGE.md 里给 NVIDIA 的 SkillSpector 补上署名，并且只取它基于代码的那部分检查，理由是「only the code checks come across. The agent’s LLM reads ripwire’s output and does the judging」——而 #360 把同一套推理推到 agent 会加载的指令文件上。

6. 06

   作者把数字连同它们自己的边界一起发出来

   docs/EVALS.md 有 1,132,024 字节，docs/COMMANDS.md 有 720,784 字节——一个项目把「可测量的说法」当成交付物而不是事后补的东西，就长这样。README 里还放着一份现场报告，由 #361 加上，默认折叠在页面靠上的位置，署名是「Claude Fable 5.0, the frontier model orchestrating ~20 coding agents over two days on a ~1,500-file C++/Metal codebase」。它的数字很大，标注也一样明确：审计与研究阶段大约一半的 token 花费，原文称这是「the operator’s whole-phase estimate」；一次 --callers 查询返回了零个生产调用方；--edit-check 标出了文本搜索漏掉的 6 个调用点中的 5 个；以及「a dozen-plus real code-quality defects fixed, not waived」。pull request 正文在同一口气里写明边界——这只是某一次合作、发生在更早的版本上，是「the orchestrating model’s own report and not a controlled measurement」——而报告的全文是一张点击展开的图片 docs/assets/field-report-multi-agent.jpg，1144×1600、567 KB，图下另附一份为无障碍加的纯文本版。README 自己的那些数字也放在同一个框里：建索引 0.25–0.45 秒、strict file@10 为 58.3%（对照 40.0%）、签名比函数体少 74.7% 字节、profile-guided optimisation 带来 14–25% 的提升——全部出自作者，而且 README 自己说这些计时列没有被重新测过。