Onboarding guide

Phase 1: Dependency Manifest & Leveling

Each distinct type node is assigned a Level by longest-path layering over its first-party dependencies (base/interface, generic constraints, field/property/param/return types, attributes, instantiations, static access). Edges resolved by namespace-aware name matching against the first-party type set; mutually-dependent types are grouped in one SCC and share a level (cycles listed below).

Edge resolution & accuracy

A referenced simple name resolves to a first-party type when that type's declaring namespace is visible to the referencing type, via a file using, an assembly-wide global using, the type's own namespace, or any ancestor namespace (C# allows simple-name references to types in enclosing namespaces without a using). If no namespace-visible candidate exists but the bare name is globally unique among first-party types, the edge is still linked (only one possible target). Names that are neither visible nor unique are dropped as unresolvable without full semantic binding.

• Edges resolved by namespace visibility: 15415 (~96%)
• Edges resolved by globally-unique name (fallback): 589
• References dropped as ambiguous (matched >1 type, none visible): 42
• Sensitivity: 837 / 4257 type levels would change if the globally-unique fallback were excluded; the fallback is retained because a globally-unique first-party name is unambiguous, so excluding it would under-count real dependencies.

Verified non-factors (add zero hidden first-party edges, confirmed by source scan): the …IdentifierType aliases all map to BCL primitives (int/System.Guid); there are no MSBuild <Using> global usings and no first-party using static; the only two first-party alias usings name a target whose bare name already matches (so they resolve regardless).

Level distribution

Cycles (SCC size > 1): 37

Manifest (by level, then assembly)