Code Map

Navigate your codebase as a dependency graph — every file a node, every import an edge — and switch that same graph between four levels: files, directories, capabilities, and the screen-to-route calls no import edge can show.

How it works

Mapnostics reads every static import in your repository into a file graph, re-computed on each dependency scan. Imports can be circular, so the graph is not acyclic — a pair of files that import each other is drawn as two edges and the layout handles it.

• Nodes — one per file that has at least one import edge, plus any file carrying a finding.
• Edges — directed from importer to imported.
• Layout — left to right by dependency direction. Clicking a file gathers its neighbours around it: importers to the left, imports to the right.
• Color — the bar across the top of each card is its health score (see below).

The tab

Five measured panels sit above the graph itself. Each one states whether its own scan has run, so an unrun scan never reads as a clean result.

The five panels

Each panel is its own scan against the same files the graph draws, and each carries its own scan button. A panel that has never been scanned renders as a prompt rather than as an empty result.

• Ownership — who wrote the code, from GitHub blame. The same scan the Key Person Risk tab runs, so filling it in either place fills both.
• History — how recently each file changed, from commit history.
• Database — the tables and columns your migrations declare, which of them nothing in the code reads, and columns whose names suggest they hold sensitive data.
• Routes — the URLs and methods your file tree exposes, and which of them middleware actually covers.
• Performance patterns — nested loops and awaits inside loops. A structural shape, deliberately not a speed claim, which is why its badge is grey rather than amber.

Four levels

The toggle in the bottom-right switches the same repository between four views. Opening a group from any of them drops back to Files, scoped to that group.

• Files — the dependency graph itself.
• Modules — collapsed by directory. Needs no scan, so it works on every repository, and starts at the shallowest level that actually divides the repo.
• Capabilities — collapsed by what each file's intent says it does. Requires the Intent Map to have run. Because the model names capabilities per file, a repository often arrives with almost one capability per file; the Group similar button folds those into a handful of areas.
• Workflows — which screens call which routes, read from URL literals in the source. This is the one relationship the import graph cannot show: a page and the route it fetches share no import edge.

Navigating the map

Search

The search box resolves a query to any of four things: a file to focus, a filter to switch on, a metric to jump to, or a directory to scope the graph to. Filters answer to plain words — endpoint reaches the API chip, blast radius reaches High impact. Opening the box with no query lists the metric jumps.

Filters

Chips narrow the graph by what has actually been measured: Flagged, Zombie, High impact, API, Lib and UI, plus Loops once the performance scan has run. Chips combine as OR within a group and AND across groups, so Flagged + Zombie widens and Flagged + API narrows. Filtering dims rather than removes, so the shape you filtered stays the shape you were looking at.

The inspector

The expand icon on a card opens the inspector in a column beside the graph — health with its full arithmetic, blast radius, dependencies in both directions, and what every other analysis knows about that file: its intent, owner, last change, secrets and findings. Each of those says whether its scan has run, so an unrun scan never reads as a clean result.

Reading a node

Badges on a card report what has been measured about that file — dead 2, zombie 1, impact 45, intent, and loop patterns where the performance scan has run.

The health score is deliberately narrow: it starts at 100 and deducts 12 per dead-code finding and 8 per zombie finding. That is all it measures. It does not read test coverage, complexity, duplication, file size or coupling, so a file at 100 means nothing is flagged there — not that the file is good. The inspector shows the full arithmetic behind whatever number it displays.

• Green (80–100) — nothing flagged.
• Amber (60–79) — some findings on this file.
• Red (0–59) — heavily flagged.