Graph accuracy issues in monorepo with multiple Go modules

[DeusData]

Context

Tested the graph on a monorepo containing two separate Go modules (e.g. service-a/ and service-b/) plus React microfrontends. Index: ~5,600 nodes, ~20,500 edges. Overall the graph is very useful — these are edge cases worth improving.

1. Cross-module CALLS edge ambiguity

Problem: When two Go modules define identically-named functions (e.g. config.Load in service-a/pkg/config/ and service-b/pkg/config/), query_graph and trace_call_path resolve CALLS edges to the wrong target.

Example: Function runSync (in service-a/cmd/main.go) imports and calls service-a/pkg/config.Load, but the Cypher query MATCH (f)-[:CALLS]->(g) WHERE f.name = 'runSync' returned service-b/pkg/config/config.go as the target for Load — the other module's function (higher in_degree: 8 vs 4).

Same issue with Close resolving to a completely unrelated service's method instead of the actual sql.DB.Close() / firestore.Client.Close().

Expected: CALLS edges should respect Go import paths. If a function is in module A and imports module-a/pkg/config, the edge should point to that module's Load, not module B's.

Workaround: Use search_graph with file_pattern to scope results, or use fully qualified names.

2. Route detection misses gin handler method references

Problem: Routes registered via method references like rg.GET("/:id", h.GetItem) are not detected as Route label nodes.

Example: A routes.go file registers 7 routes:

rg.GET("", h.ListItems)
rg.GET("/:id", h.GetItem)
rg.GET("/:id/details", h.GetItemDetails)
rg.GET("/:id/sub-a", h.GetSubResourceA)
rg.GET("/:id/sub-b", h.GetSubResourceB)
rg.GET("/:id/sub-c", h.GetSubResourceC)
rg.GET("/:id/sub-d", h.GetSubResourceD)

None of these appear as Route nodes. The handler functions themselves (ListItems, GetItem, etc.) are correctly indexed as Method nodes, but lack the Route label + HTTP method/path metadata.

Other routes in the same codebase ARE detected — possibly because they use inline handlers or a different registration pattern.

3. Route file_path sometimes points to wrong file

Example: A POST /api/resource/action route has its file_path pointing to a React frontend component that calls the endpoint — not the Go handler that serves it.

Example: Another route's file_path points to a completely unrelated Go file in a different service.

Expected: Route file_path should point to the backend handler definition.

4. trace_call_path picks arbitrary match for ambiguous names

Problem: trace_call_path(function_name="RegisterRoutes") with 9 matches across packages silently picks one (arbitrary package) without indicating ambiguity.

Expected: Either return an ambiguity error (like get_code_snippet does with status='ambiguous'), or scope resolution using the caller's module/package context.

Environment

• codebase-memory-mcp: latest build from source
• Repo structure: monorepo, 2 Go modules (separate go.mod files), multiple React SPAs
• Index mode: full