Repository navigation
Kotlin interface nodes get label Class; companion-object members and TS re-export aliases produce no nodes #1557
Description
Environment: v0.10.2, Windows 11, --mode full. Kotlin + TypeScript monorepo.
Three related fidelity gaps that make label/name-based queries lie on Kotlin-heavy codebases:
1. Kotlin interface gets label Class
interface OrganizacaoRepository (a plain Kotlin domain port) is stored with label Class. All 199 Interface-labeled nodes in our graph are TypeScript. Consequence: search_graph(label="Interface") on the Kotlin side returns nothing while interfaces exist everywhere — an agent that trusts the label concludes "no interfaces here". (The INHERITS edges themselves are fine and correctly link implementations to these Class-labeled interfaces.)
2. companion object members produce no Method node
TipoLogradouro declares create(...) and rehydrate(...) inside companion object. Neither exists as a node; DEFINES_METHOD for the class omits them, and call sites (TipoLogradouro.create(...) from other modules) resolve to a class-level USAGE only. Method-level queries ("who calls create?") return zero.
3. TS re-export aliases produce no node
export { diaCivilNo as hojeNaClinica } from './datas' — searching hojeNaClinica yields zero hits with no pointer to diaCivilNo, although the alias is what the rest of the codebase imports.
All three are "absence that isn't absence": the graph's answer is empty while the code isn't. A node for the alias/companion member (or at minimum a documented limitation list echoed on empty results) would prevent false negative conclusions.
Activity
DeusData commentedon Aug 13, 2026
@PsyTech-Rob, thank you for the concrete graph-level examples. These are three independent extraction contracts and need separate issues so they can be reproduced and fixed without coupling unrelated language paths.
Current
mainsupports that split: Kotlin declarations are classified through the generic class-label path, companion objects have their own Kotlin extraction/recovery handling, and TypeScript re-export resolution is a separate import/export path that explicitly fails closed when the exported alias name is unavailable.Please split this into:
interfacedeclarations labeled asClass.One small public fixture per issue is enough; link each new issue back here and we will route them independently. We can keep this report open as the index until the split is complete. Thank you again for identifying false absences rather than treating an empty graph answer as proof.
DeusData commentedon Oct 19, 2026
Thank you again for detailing the Kotlin interface, companion-object, and TypeScript alias cases. The earlier request for separate small fixtures and linked issues still gives each language contract its own review path. I have no new implementation result to add here.
DeusData commentedon Oct 25, 2026
Thank you for separating the Kotlin and TypeScript gaps. Please link the small standalone fixtures and focused issues requested above so each extraction contract can be handled independently.
github-actions commentedon Oct 25, 2026
Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:
codebase-memory-mcp --versionyou're onOnce that's here we'll pick it straight back up. Heads-up: issues left
awaiting-reporterare automatically closed after a few weeks of silence, but a comment reopens the door anytime.