explore/query relevance: a project-name token in the query inflates lexically-matching frontend class, burying backend symbols (compounds #647 PascalCase bias)

[MiNuo1]

Version: @colbymchenry/codegraph@0.9.9 (latest). Mixed-stack repo: GoFrame backend + a single-file JS frontend SPA.

Symptom: For a backend question, codegraph query (and therefore codegraph_explore, which inherits the ranking) surfaces the frontend SPA file, not the backend route/controller code. The agent then Reads the correct Go files anyway — the same read-back failure mode #564 fought, but driven by cross-stack ranking rather than polymorphic-sibling sizing.

Minimal repro — same query, one token removed, ranking flips stacks:

$ codegraph query "SuperBizAgent backend /api routes registered and bound to controller methods" -l 6 -j
37.4 SuperBizAgentFrontend/app.js toggleModeDropdown
37.4 SuperBizAgentFrontend/app.js toggleToolsMenu
32.3 SuperBizAgentFrontend/app.js constructor
32.3 SuperBizAgentFrontend/app.js initMarkdown
32.3 SuperBizAgentFrontend/app.js initializeElements
32.3 SuperBizAgentFrontend/app.js bindEvents ← all frontend; backend controllers not in top 6
$ codegraph query "backend /api routes registered and bound to controller methods" -l 6 -j
20.8 internal/controller/chat/chat_v1_ai_ops.go AIOps
20.8 internal/controller/chat/chat_v1_chat.go Chat
20.8 internal/controller/chat/chat_v1_chat_stream.go ChatStream
20.8 internal/controller/chat/chat_v1_file_upload.go FileUpload
18.4 internal/controller/chat/chat_new.go ControllerV1
15.1 SuperBizAgentFrontend/app.js toggleModeDropdown ← correct backend now on top
The single token SuperBizAgent (the project name, which users naturally include) ~doubles the score of every SuperBizAgentFrontend/app.js symbol because it lexically matches the frontend class SuperBizAgentApp / path SuperBizAgentFrontend.

Why the backend can't compete: the real route binding is GoFrame-reflective —

s.Group("/api", func(g *ghttp.RouterGroup) { g.Bind(chat.NewV1()) }) // main.go
// + struct tags: g.Meta path:"/chat" method:"post" (api/chat/v1/chat.go)
There is no literal "/api/chat" string and no call-graph edge from path → controller method, so route-registration symbols score low and have nothing to win on. (Analogous to the Zustand/handler-map coverage you added in #647, but for GoFrame route metadata.)

Suggestions (non-prescriptive):

Down-weight query tokens that match the repo/project name or appear in a large fraction of indexed paths (they carry ~no discriminative signal but currently dominate).
Consider excluding the project-name token from the #647 PascalCase-type bias.
Coverage: index GoFrame route metadata (g.Meta path: + RouterGroup.Bind(controller)) as route→method edges, so "where are routes registered/bound" resolves structurally instead of lexically.
Repro condition (general): any repo where the project name is also a substring of a symbol/path on one stack — that stack gets boosted whenever the user mentions the project by name.

[colbymchenry]

Thanks for the precise repro and the score breakdown — that made the dominant cause easy to isolate.

Measuring the components, the biggest single driver of the flip is path relevance over-counting: the query word SuperBizAgent splits into superbizagent / super / biz / agent, and all four match the SuperBizAgentFrontend directory → +5 each = +20 for one concept (vs +5 for the backend's controller match). That alone roughly doubled every frontend symbol's score.

Shipped in #745: path relevance now scores per original query word rather than per sub-token — a word counts once per path level (filename / dir / path), while still being split so it matches across naming conventions (getUserName still matches get_user_name.go). On your repro the backend controllers go from absent in the top 6 to interleaved at parity with the frontend.

This is intentionally the contained, low-risk part. It does not fully top the backend yet — the project name still gives the frontend a residual dir match (+5) and an FTS match against the class name SuperBizAgentApp. Fully flipping that needs down-weighting the project-name token itself (your suggestions #1/#2), which touches the scorer for every query and wants a benchmark A/B before merge — tracked in #746. Your suggestion #3 (GoFrame g.Meta / RouterGroup.Bind route→method coverage) is tracked in #747.

Leaving this open until #746 lands, since your top-6 case isn't fully resolved by the path fix alone. The improvement ships in the next release.

[colbymchenry]

Now fully fixed — #748 lands the second half (the project-name down-weighting) on top of the per-word path fix (#745).

CodeGraph derives the project name from go.mod / package.json / the repo directory, and a query word matching it is dropped from path scoring and from codegraph_explore's PascalCase type-disambiguation bias (your suggestions #1 and #2) — unless it's the only term, so a bare project-name search still works. On your repro the backend controllers now top a backend question even with SuperBizAgent in the query:

15.4  internal/controller/chat/chat_v1_ai_ops.go   AIOps
15.4  internal/controller/chat/chat_v1_chat.go     Chat
15.4  internal/controller/chat/...chat_stream.go   ChatStream
15.3  internal/controller/chat/chat_v1_chat.go     NewV1

It's deliberately narrow: the down-weighting fires only when a query word matches the project name, so queries that don't name the project rank exactly as before, a bare project-name search still finds the project's symbols, and normal symbol queries are untouched.

Your suggestion #3 — structural GoFrame route coverage (g.Meta / RouterGroup.Bind → route→method edges) — is the genuinely separate piece, tracked in #747. Thanks again for the precise repro and score breakdown. Ships in the next release.