Product problem
Flat file trees hide the relationships that make a codebase understandable.
A useful code map needed to reveal semantic structure without turning the main graph into a wall of labels. It also needed to remain local, preserve the established scanner, keep spatial context during selection, and move detailed source information into secondary surfaces.
Interaction requirements
Orientation and progressive detail were acceptance criteria.
- Operate offline and keep source analysis local.
- Cluster by semantic role rather than file location alone.
- Show relationships and orphans without overwhelming the primary graph.
- Fit the initial graph to the available view.
- Preserve camera position and perspective during selection.
- Move detailed source information into detachable or secondary panels.
- Keep diagnostic fallback rendering outside the main product experience.
- Preserve the .NET scanner as the authority while exploring an Obsidian companion.
Architecture & tradeoffs
Semantic scan first; 3D navigation and detail surfaces second.
Local source scan
The established scanner extracts bounded structural and semantic relationships without sending source to a cloud service.
3D relationship graph
Role-based hierarchy, clusters, orphans, and links create a navigable system view.
Stable camera
Selection preserves spatial orientation rather than forcing the user to rediscover the graph.
Source detail surfaces
Secondary panels carry the dense information that would otherwise clutter the primary view.
What Shayne owned
Product direction, interaction requirements, and acceptance review.
AI role
Human product direction with AI-assisted implementation.
Agents contributed implementation, analysis, design iteration, and supporting tools. Shayne directed product and interaction requirements, established local/offline constraints, and reviewed behavior through user acceptance testing.
Recorded evidence
A meaningful historical semantic graph.
Result & next stage
A substantial developer-tools record with a clear continuation path.
The record supports product direction, interaction design, local/offline requirements, UAT, and a nontrivial semantic scan. The next validation stage is a fresh build and runtime review followed by the planned Obsidian companion work.