Summary
_LANGUAGE_BUILTIN_GLOBALS (graphify/extractors/base.py:13) and _BUILTIN_NOISE_LABELS (graphify/analyze.py:11) exist specifically to stop language built-ins (String, Promise, str, dict, ...) from becoming false "god nodes" that create phantom bridges between unrelated parts of a graph (per the comment referencing #726: "Without this filter they become god-nodes accumulating spurious edges from every call site").
Both lists cover JavaScript/TypeScript and Python only. Swift/Foundation/SwiftUI types are entirely absent from both, and there is no graphify/extractors/swift.py — Swift extraction still lives in the pre-modular extract.py (5,372 lines) rather than the newer per-language extractors/ layout used by Go, Rust, C#, Dart, Pascal, Objective-C, etc.
Repro
Ran /graphify (full pipeline: AST + LLM-vision semantic extraction) on a ~360k-word Swift codebase (macOS + iOS audio player, SwiftUI + Foundation + AVFoundation). Results:
God Nodes report surfaced framework types, not architecture:
1. Foundation - 105 edges
2. NSLock - 102 edges
3. NirvanaAudioStreamerIOS - 94 edges
4. View - 60 edges
5. NAMNode - 51 edges
6. Data - 49 edges
Foundation, NSLock, View, Data are Swift/Foundation/SwiftUI built-ins, not project abstractions — exactly the class of noise _BUILTIN_NOISE_LABELS is supposed to filter, but it only lists Python names (str, MagicMock, typing, ...).
graphify path between two genuinely unrelated symbols (DesignSystem, a SwiftUI style helper, and playFLACViaAudioUnit(), an audio-streaming method) returned a "shortest path":
DesignSystem <--contains-- DesignSystem.swift --contains--> Theme --implements--> Sendable <--references-- .playFLACViaAudioUnit()
The entire "connection" is two unrelated symbols both touching the Sendable protocol. If Sendable (and Codable, Equatable, Identifiable, Hashable, AnyObject, etc.) were filtered the way Promise/Map/dict/str are, this phantom bridge would not exist.
Where it lives
graphify/extractors/base.py:13-32 — _LANGUAGE_BUILTIN_GLOBALS, used at extract.py:2434 (member-call receiver resolution) and extract.py:5038 (call-target resolution). Zero Swift/Obj-C entries.
graphify/analyze.py:11-21 — _BUILTIN_NOISE_LABELS, used in god_nodes() (analyze.py:113). Zero Swift entries.
- No
graphify/extractors/swift.py exists at all (checked against go.py, rust.py, dart.py, csharp.py, pascal.py, objc.py, elixir.py, apex.py, etc., which do exist).
Suggested fix
- Add a Swift/Objective-C section to
_LANGUAGE_BUILTIN_GLOBALS, at minimum: Sendable, Codable, Decodable, Encodable, Equatable, Hashable, Identifiable, Comparable, CustomStringConvertible, AnyObject, Error, LocalizedError, plus common Foundation/SwiftUI value types (String, Int, Double, Float, Bool, Data, URL, Date, View, Color, Font) that show up as constructor/coercion or protocol-conformance targets from every file.
- Extend
_BUILTIN_NOISE_LABELS with the same set so god_nodes() doesn't rank them.
- Longer term: migrate Swift extraction out of
extract.py into graphify/extractors/swift.py to match the modular per-language pattern already used for Go/Rust/C#/Dart/Pascal/Obj-C, so language-specific builtin/noise lists live next to the extractor that needs them instead of one shared global list.
Happy to share the reproduction corpus details or test further if useful.
Summary
_LANGUAGE_BUILTIN_GLOBALS(graphify/extractors/base.py:13) and_BUILTIN_NOISE_LABELS(graphify/analyze.py:11) exist specifically to stop language built-ins (String,Promise,str,dict, ...) from becoming false "god nodes" that create phantom bridges between unrelated parts of a graph (per the comment referencing #726: "Without this filter they become god-nodes accumulating spurious edges from every call site").Both lists cover JavaScript/TypeScript and Python only. Swift/Foundation/SwiftUI types are entirely absent from both, and there is no
graphify/extractors/swift.py— Swift extraction still lives in the pre-modularextract.py(5,372 lines) rather than the newer per-languageextractors/layout used by Go, Rust, C#, Dart, Pascal, Objective-C, etc.Repro
Ran
/graphify(full pipeline: AST + LLM-vision semantic extraction) on a ~360k-word Swift codebase (macOS + iOS audio player, SwiftUI + Foundation + AVFoundation). Results:God Nodes report surfaced framework types, not architecture:
Foundation,NSLock,View,Dataare Swift/Foundation/SwiftUI built-ins, not project abstractions — exactly the class of noise_BUILTIN_NOISE_LABELSis supposed to filter, but it only lists Python names (str,MagicMock,typing, ...).graphify pathbetween two genuinely unrelated symbols (DesignSystem, a SwiftUI style helper, andplayFLACViaAudioUnit(), an audio-streaming method) returned a "shortest path":The entire "connection" is two unrelated symbols both touching the
Sendableprotocol. IfSendable(andCodable,Equatable,Identifiable,Hashable,AnyObject, etc.) were filtered the wayPromise/Map/dict/strare, this phantom bridge would not exist.Where it lives
graphify/extractors/base.py:13-32—_LANGUAGE_BUILTIN_GLOBALS, used atextract.py:2434(member-call receiver resolution) andextract.py:5038(call-target resolution). Zero Swift/Obj-C entries.graphify/analyze.py:11-21—_BUILTIN_NOISE_LABELS, used ingod_nodes()(analyze.py:113). Zero Swift entries.graphify/extractors/swift.pyexists at all (checked againstgo.py,rust.py,dart.py,csharp.py,pascal.py,objc.py,elixir.py,apex.py, etc., which do exist).Suggested fix
_LANGUAGE_BUILTIN_GLOBALS, at minimum:Sendable,Codable,Decodable,Encodable,Equatable,Hashable,Identifiable,Comparable,CustomStringConvertible,AnyObject,Error,LocalizedError, plus common Foundation/SwiftUI value types (String,Int,Double,Float,Bool,Data,URL,Date,View,Color,Font) that show up as constructor/coercion or protocol-conformance targets from every file._BUILTIN_NOISE_LABELSwith the same set sogod_nodes()doesn't rank them.extract.pyintographify/extractors/swift.pyto match the modular per-language pattern already used for Go/Rust/C#/Dart/Pascal/Obj-C, so language-specific builtin/noise lists live next to the extractor that needs them instead of one shared global list.Happy to share the reproduction corpus details or test further if useful.