What
The full-build call-resolution path (resolveFallbackTargets in src/domain/graph/builder/stages/build-edges.ts, decomposed into named helpers in the phase-11 grind/forge pass) has a same-class bare-call fallback strategy (resolveSameClassBareCallFallback): for class-scoped languages (non-JS/TS), a bare call with no receiver that fails global resolution retries qualified as <CallerClass>.<callName> — this is how e.g. C# static sibling calls (IsValidEmail() inside Validators.ValidateUser → Validators.IsValidEmail) get resolved.
src/domain/graph/builder/incremental.ts's applyThisReceiverFallbacks only implements two strategies:
- same-class
this.method() fallback (resolveThisSameClassTarget)
Object.defineProperty accessor fallback (resolveDefinePropertyTarget)
There is no bare-call (non-this, class-scoped) fallback anywhere in incremental.ts, and it doesn't even import isModuleScopedLanguage. This means: a C# (or other class-scoped-bare-call language) static sibling call that resolves correctly on a full codegraph build will silently fail to resolve (or resolve differently) after an incremental single-file rebuild (watch mode).
Where
src/domain/graph/builder/stages/build-edges.ts — resolveSameClassBareCallFallback (full-build path, has the strategy)
src/domain/graph/builder/incremental.ts — applyThisReceiverFallbacks (incremental path, missing the strategy)
Suggested fix
Add a bare-call fallback branch to applyThisReceiverFallbacks (or its call site) that mirrors resolveSameClassBareCallFallback, using the same resolveSameClassQualifiedMethod-shaped lookup, guarded by isModuleScopedLanguage(relPath).
Found during
Titan grind phase 11 (adopting forge's build-edges.ts decomposition) — codebase-wide duplicate-logic scan surfaced this while comparing the newly-named resolveSameClassQualifiedMethod/resolveSameClassThisFallback/resolveSameClassBareCallFallback trio against incremental.ts's pre-existing resolveThisSameClassTarget.
What
The full-build call-resolution path (
resolveFallbackTargetsinsrc/domain/graph/builder/stages/build-edges.ts, decomposed into named helpers in the phase-11 grind/forge pass) has a same-class bare-call fallback strategy (resolveSameClassBareCallFallback): for class-scoped languages (non-JS/TS), a bare call with no receiver that fails global resolution retries qualified as<CallerClass>.<callName>— this is how e.g. C# static sibling calls (IsValidEmail()insideValidators.ValidateUser→Validators.IsValidEmail) get resolved.src/domain/graph/builder/incremental.ts'sapplyThisReceiverFallbacksonly implements two strategies:this.method()fallback (resolveThisSameClassTarget)Object.definePropertyaccessor fallback (resolveDefinePropertyTarget)There is no bare-call (non-
this, class-scoped) fallback anywhere inincremental.ts, and it doesn't even importisModuleScopedLanguage. This means: a C# (or other class-scoped-bare-call language) static sibling call that resolves correctly on a fullcodegraph buildwill silently fail to resolve (or resolve differently) after an incremental single-file rebuild (watch mode).Where
src/domain/graph/builder/stages/build-edges.ts—resolveSameClassBareCallFallback(full-build path, has the strategy)src/domain/graph/builder/incremental.ts—applyThisReceiverFallbacks(incremental path, missing the strategy)Suggested fix
Add a bare-call fallback branch to
applyThisReceiverFallbacks(or its call site) that mirrorsresolveSameClassBareCallFallback, using the sameresolveSameClassQualifiedMethod-shaped lookup, guarded byisModuleScopedLanguage(relPath).Found during
Titan grind phase 11 (adopting forge's
build-edges.tsdecomposition) — codebase-wide duplicate-logic scan surfaced this while comparing the newly-namedresolveSameClassQualifiedMethod/resolveSameClassThisFallback/resolveSameClassBareCallFallbacktrio against incremental.ts's pre-existingresolveThisSameClassTarget.