fix(explore): surface a named method's buried signature type (#1064) (#1069)

* fix(explore): surface a named method's buried signature type (change surface) (#1064)

#1064: a natural-language query like "what do I need to change if I add a new
parameter to NewClient" dropped the file the answer lives in (grpc-go's
dialoptions.go, which defines NewClient's DialOption) and surfaced lexical
namesakes instead, so the agent fell back to grep.

Root cause (instrumented on grpc-go): the answer file is lexically dissimilar
to the query and reachable only structurally, so it scores ~0 on every text
and centrality signal and never renders.

Two-part fix, both bounded and validated to not perturb flow queries:

1. Change surface — read each named method's signature-type edges from the full
   graph and, ONLY when the type's file is genuinely BURIED (≈0 graph mass AND
   no term hits), inject + rank + gate-keep + tier it. A well-connected type
   file is left to rank on its own merit, so this never displaces a flow file.

2. Tier de-noise by centrality — still seed every <=3-def name (RWR/flow ranking
   unchanged), but the named-first tier admits only the most-substantive def
   plus co-named defs of comparable centrality (>=25% of the top def's caller
   count). This keeps real overloads/wrappers (excalidraw's `mutateElement` in
   three files, callers 74/58/40) while dropping vastly-less-central namesakes
   (Go's `NewClient`: real 492 callers vs xds-pool 11, test-fake 3) that would
   otherwise crowd the answer file out of the tier.

Validation:
- Deterministic probe: dialoptions.go goes from dropped to surfaced (with the
  full option field set via defaultDialOptions).
- Broader-repo regression check (Alamofire, excalidraw, axios): 5/6 control
  flow queries byte-identical to baseline; the 1 shift (Alamofire "how a request
  gets validated": Validation.swift -> DataRequest.swift) is lateral —
  DataRequest defines validate() and is a directly-relevant answer.
- grpc-go agent A/B (n=2, sonnet): grep fallback eliminated (0 vs baseline 4,2).
- 1845 unit tests pass.

* docs(changelog): note explore signature-type surfacing (#1064)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Colby Mchenry
2026-06-29 20:29:30 -05:00
committed by GitHub
co-authored by Claude Opus 4.8
parent 575d960bb4
commit 2b256b93e5
2 changed files with 85 additions and 1 deletions
+4
View File
@@ -9,6 +9,10 @@ and adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
## [Unreleased]
### Fixes
- `codegraph_explore` now surfaces the options/config type behind a function when you ask, in plain language, what to change to add a parameter to it. A question like "what do I need to change to add a new parameter to X" shares no words with the file that actually defines X's options — for example a functional-options struct and its `With…` builders living in a separate `options.go`, reachable only through X's signature — so that file scored near-zero on every text and connectivity signal and got dropped: explore returned X itself but not the file you'd edit, and the agent fell back to grep. Explore now follows a named function's parameter and return types and pulls in the file that defines them when ranking would otherwise bury it, so the options/config file shows up with its fields. Well-connected types that already rank are left untouched, so ordinary "how does X work" flow questions are unchanged. (The separate tools `codegraph_search`/`codegraph_impact`/`codegraph_node` remain available via `CODEGRAPH_MCP_TOOLS` for anyone who prefers driving each step explicitly.) Thanks @wauxhall for the detailed investigation. (#1064)
## [1.1.4] - 2026-06-29