Open CodeGraphy and let it analyze your workspace.
Detection coverage
.gd files:
preload()
load()
extends
class_name references
project.godot:
application/run/main_scene
[autoload]
.tscn and .tres text resources:
[ext_resource ... path="res://..."]
Edge semantics
Scene and resource text references are emitted as normal load edges with type: static.
project.godot resource-bearing settings are also emitted as normal static load edges.
The finer-grained plugin provenance is sourceId: "ext-resource" for .tscn/.tres files and sourceId: "project-settings" for project.godot.
The detector follows Godot's text-loader behavior more closely by accepting relative path= values and preferring a matching uid= target when one is known in the workspace.
This means they participate in the existing load Edge Type Graph Scope settings while still being attributable to Godot text-resource parsing.
That example also now looks like a small real Godot project: it has a valid project.godot, a main.tscn entry scene, an autoloaded GameManager, and concrete player/enemy/UI scenes around the .tscn/.tres fixtures.
Those .tscn/.tres fixtures intentionally use relative path= values, and the scene's resource reference also carries a uid= so the plugin exercises both Godot-style resolution paths.