Language support: Protocol Buffers (.proto) — the contract layer gRPC codebases break on

[Apologiz]

Adding this to the pile in #648, but I think it sits a bit differently from the other entries there, so bear with me.

Protobuf isn't really a programming language request. In a gRPC codebase the .proto file is the interface between services — the Go, Dart and TS on either side of it is generated. So the boundary that matters most is the one part of the repo codegraph can't see.

What this looks like in practice. I run a Go microservice backend: 13 services, each owning its contracts in its own repo and pulling the ones it consumes through buf. 38 hand-written .proto files, 661 counting the vendored copies of other services' contracts.

Codegraph is genuinely good on the Go side — query Authorize gives me the definition in the staff service and every consumer in oms and pro-bff in one shot, which used to be a grep expedition. But ask it about the contract itself and it goes quiet:

• query PlaceOrderRequest returns two Go signatures that mention the type. The message definition, its fields, and the RPC that takes it aren't in the graph at all.
• There's no way to get from a proto service definition to the Go method implementing it, or the other direction.

So a cross-service flow traces cleanly right up to the service boundary, then stops — and that's the hop where I actually needed help. It's the "partial coverage is worse than none" problem in CLAUDE.md, except the missing piece isn't dynamic dispatch, it's a whole file format.

What I think would be worth having, roughly in order of value:

1. service → rpc → request/response message → field as nodes and edges.
2. An edge from the generated symbol back to its proto definition, so the Go/Dart edges that already exist connect through the contract instead of dead-ending at it. This is the one that makes it worth doing at all — without it you get an isolated island of proto nodes next to the real graph.
3. import edges between proto files, which in a buf setup is what tells you which services depend on whose contracts.

Mature tree-sitter grammars for proto exist, and the shape is small and declarative — closer to the HCL/Terraform extractor than to a real language.

Two questions before I put work into a PR, because I couldn't answer them from the repo:

1. Which layer should a new language target now? src/extraction/languages/*.ts still has 29 extractors, but the R7a/R7b work (Native extraction kernel: Rust parse+extract for TS/JS/Java/Python/Go, byte-identical, default-on (R1-R6) #1326, R7a: C/C++ extraction kernel — walker, preParse hoist, gate ladder, default routing #1346, and the walker series in July) moved a good chunk into codegraph-kernel. I'd rather not write the TS one and find out it's the layer being retired.
2. Is there a current on-ramp doc? Support for SQL #85 and Tracking: language support requests (post-1.0 roadmap) #648 both point at docs/ADDING-A-LANGUAGE.md and an /add-lang workflow, but the file 404s on main, docs: cookbook for adding a new language extractor #97 was closed unmerged, and there's no .claude/commands/. CLAUDE.md covers the architecture and the validation methodology, so I can work from that — just want to check I'm not missing something newer.

Happy to do the validation work the methodology asks for (small/medium/large repos, ≥3 flow prompts, A/B with ≥2 runs per arm on sonnet). I have a real proto-heavy codebase to test against, which I suspect is the harder thing to come by.