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.
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
interfacegets labelClassinterface OrganizacaoRepository(a plain Kotlin domain port) is stored with labelClass. All 199Interface-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". (TheINHERITSedges themselves are fine and correctly link implementations to theseClass-labeled interfaces.)2.
companion objectmembers produce no Method nodeTipoLogradourodeclarescreate(...)andrehydrate(...)insidecompanion object. Neither exists as a node;DEFINES_METHODfor the class omits them, and call sites (TipoLogradouro.create(...)from other modules) resolve to a class-levelUSAGEonly. Method-level queries ("who calls create?") return zero.3. TS re-export aliases produce no node
export { diaCivilNo as hojeNaClinica } from './datas'— searchinghojeNaClinicayields zero hits with no pointer todiaCivilNo, 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.