Opening the local map
Run Iris Code: Open Code Map from the command palette in VS Code or from Find Action in JetBrains IDEs, or select Open Code Map in the Workspace tab. Each file in the Workspace tab’s Ranked lists has a map button beside it, which opens the map with that file in view. Selecting the file name itself still opens the file. Folders can be expanded and collapsed. Selecting a file opens it in the editor. Each row has ten separate health-score markers and a numeric score. Green is healthy, amber needs attention, and red is failing. A folder score is the ordinary average of its measured files, matching the workspace score. Line count is shown as context, not used as a score weight.Files that Iris Code cannot measure are labelled Not measured. They are not shown as failing, because the absence of a score is not evidence that code is unhealthy.
Files below the minimum
An average can hide the file that fails. Ten files at 98 and one at 60 average 94, so the folder reads as healthy, while the gate blocks the push on the file at 60. Code Map keeps the folder average and marks the failing files separately. A red caution badge appears beside any file that would fail the gate’s score rule, showing how many points it is short. Each folder above it shows a badge with the number of failing files inside it. Hovering a folder’s badge lists those files, furthest below first, with each one’s score against its minimum; hovering a file’s badge shows its score, the minimum and the shortfall. The header shows the total for the whole map, and hovering it lists every failing file. The minimum is the one the gate uses:minHealthScore from .irisconfig.json, or 70 when it is not set. With gateBaselineMode on, each file is compared against its own locked baseline, so a file scoring 90 carries the badge if its baseline is 95.
Scores are rounded down before the comparison, as they are in the gate, so 69.9 is below a minimum of 70. Files that are not measured never carry the badge.
The caution appears in the local map in VS Code and JetBrains, and in the cloud map. The cloud map uses the minimum that audit was scored against, which may come from a fallback preset or your account or team standard rather than the repository’s own config.
Audits run before the cloud map could record a minimum show a note saying failing files are not marked; running a new audit adds them.
The import graph
The tree shows where health is weak. Graph shows how files depend on each other, which is what you need before changing one: the files that import it are the ones a change can break. Switch the map from Tree to Graph. The workspace scan that scores the tree also maps the imports, so there is nothing separate to build. Each line is an import. Selecting one lists the import lines it came from and opens them in the editor, and cycles are marked.
The app folder of a Next.js project in Folder scope, exported from the Graph. Folders outside the scope show how many imports reach them.
iris_check with import impact.
A direct importer is a file with an import edge to the checked file, or to the package that contains it: in Go, and for a C# using, a Java wildcard import or a Python namespace package, the import names the package, and it reaches every file in that folder.
Focusing a file in the Graph draws those importers pointing at the file. Pro also counts files that reach it through a chain, stopping at 500+ and terminating on cycles. iris check --changed and --staged include impact in their JSON reports and pretty output.
These counts help choose what to re-check; they do not alter the gate.
An import Iris Code cannot resolve is not guessed at. It is listed under unresolved with a reason, such as missing-file for a path no file matches, or ambiguous-target when two files declare the same Java class.
The graph draws imports, and only imports. Files in the same Go or Java package, C# namespace or Rust module can use each other without one, so those uses are not drawn. A Java project with every class in one package can show few lines for that reason.
iris graph.
Exporting the map
A map is most useful when the people who need to see it do not have to open an editor. Export, in the top bar of both views, saves exactly what is on screen: the current scope, filters and expanded folders.
Mermaid and Markdown also have Copy, which puts the text on the clipboard ready to paste. GitHub stops drawing Mermaid diagrams past about 500 connections, so a larger graph keeps its most-used imports and says in a comment how many it left out.
Pictures, Mermaid and Markdown end with a short “Made with Iris Code” line naming the project and the scan date. CSV has none, because an extra line breaks spreadsheet imports. The cloud map’s exports also name the branch and commit, in the file name and in the picture.
An export contains what you can see and nothing more, so a Free export includes scores for the focused folder only, and says so.
Scan states
Code Map always shows which result it is displaying:- Not scanned yet: the repository structure is visible and the map provides a Scan button.
- Scanning: the current workspace scan is in progress.
- Scanned: scores come from the last completed scan.
- Stale: the saved scan is more than a day old. Run a new scan before treating it as a current picture of the repository.