[ricobl]

Motivation

Using codegraph on a Ruby / Rails project has been a bit of a hit and miss for me, references are often not found via callers, callees and other commands, leaving agents to fallback to grep.

Summary

• Ruby call nodes use receiver + method fields rather than a function field, causing two common patterns to produce unresolvable references: obj = SomeClass.new(...); obj.method emitted obj.method, and SomeClass.new(...).method emitted only the method name — neither could be matched by the resolver, so codegraph_callers and codegraph_callees both returned incomplete results.
• Added handling in tree-sitter.ts for call nodes that use a method field: chained receivers (class/namespace) emit the class name; bare method receivers emit receiver.method; complex receivers (e.g. a chained call) emit just the method name.
• Added a buildLocalScope hook to LanguageExtractor that lets a language pre-scan a function body and return a var → "ClassName::" prefix map. The engine uses this during call extraction to resolve var.method to ClassName::method. Ruby implements it by scanning var = ClassName.new(...) assignments. The hook is separator-agnostic so other languages can adopt it without engine changes.

Test plan

• npx vitest run __tests__/extraction.test.ts -t "Ruby calls" — 5 tests covering bare .new, namespaced .new, chained .new(...).method, local var assignment with simple class, and local var assignment with namespaced class
• npx vitest run — full suite, no new regressions
  • there seems to be a failing MCP PPID watchdog test: shuts down when its parent is SIGKILL'd and stdin stays open

[colbymchenry]

Thanks for this, @ricobl, and for the clear write-up of both gaps: bang and question methods on a receiver, and methods called straight on Foo.new(...), linked nothing. We landed a fix in #3049, which records Foo.new(...).bar as a call on Foo in both of our extractors, resolves the class the way Ruby's constant lookup does (inherited methods included), and links nothing for a class from outside your project. It was reimplemented independently with new tests, and you're credited in the changelog. Closing this in favor of #3049; it ships in the next release.