CodeLore Dashboard

What it measures. Behavioural pressure across the codebase. Circle size encodes churn (revision count); the active colour lens encodes one of seven behavioural signals — complexity, code health, tech-debt friction, knowledge map, AI attribution, knowledge loss (under your off-boarding scenario), or clones.

How to read it. Big circles = files changed often. Red / dark fills = high pressure on the selected lens. A yellow ring overlay marks the top quartile of hotspot score (the composite churn × complexity signal). Click any circle to open the file detail drawer — the same file then lights up across the trends and multi-metric panels.

What to watch for. Large RED circles wearing a yellow ring: frequently changed, complex, and in the top-quartile of overall risk. They are the primary refactor candidates. Switch to Knowledge loss mode after picking off-boarders to see which circles turn red under attrition.

Suggested action. Sort the Hotspot table by score and refactor top-down. Use the off-boarding picker to surface bus-factor exposure before it becomes an incident.

A. Tornhill 2018, Software Design X-Rays; cognitive complexity per SonarSource 2018.

What it measures. The full hotspot list as a sortable, filterable table. One row per file with every behavioural metric the dashboard computes — revisions, cognitive complexity, code health, hotspot score, primary author, AI attribution, MI rank, contributors.

How to read it. Click any column header to sort by that column (click again to reverse). Type in the filter box to narrow by path substring; the summary line under the filter shows how many rows match. Click a row to open the file detail drawer — the file then lights up across the trends, parallel-coords, and any other path-aware panel.

What to watch for. Use the table as the drill-down surface for any signal you spotted in a chart. The combination of high revisions + low health + recent activity is the canonical "fix this now" pattern.

Suggested action. Sort by hotspot score descending, copy the top-N paths into your sprint board, and refactor by priority.

What it measures. The same hotspot data as the circle-pack above, rendered as nested rectangles. Area encodes cognitive complexity × revisions; colour encodes the active hotspot lens.

How to read it. Each rectangle is one file (label = abbreviated path). The larger the rectangle, the higher the cognitive × revisions product. Treemaps use strict area encoding — unlike circle area, rectangle area is read accurately by the eye, so this view is the right one when you need to compare sizes precisely.

What to watch for. The two or three rectangles that dominate the layout — they own most of the codebase's pressure. Small, evenly-sized tiles = healthy distribution; one giant tile + many tiny ones = god-class shape.

Suggested action. When you're picking refactor targets by impact, sort by the treemap's largest rectangles. When you're picking by risk lens (complexity, health, friction), the circle-pack's colour ramp is easier to scan — use whichever fits your current question.

What it measures. Function-level cognitive complexity for the top 500 functions in the repository. Sunburst layout: the inner ring is the top-level path segment, the outer rings drill into directories and finally individual functions. Wedge area encodes complexity.

How to read it. Bigger wedge = more complex function. Click any wedge to zoom in (the sunburst re-roots to that subtree); click the centre to zoom back out. Hover for the full module path plus function name.

What to watch for. A single huge outer wedge inside a module = that one function owns most of the module's complexity. The most dangerous pattern is one function dominating and the same file appearing high in the Hotspot list (frequent churn on a complex function).

Suggested action. Refactor the largest wedges first by extracting helpers and simplifying control flow. Even one extraction can drop a wedge by 30–50% of its visual area.

What it measures. Up to 12 commits evenly spaced across history are re-analysed: the import graph and complexity metrics are rebuilt at each revision, then scored as architectural health (propagation cost + cycle penalty, 0–100), code health (mean file health score, 0–100), and combined health (their average). Higher is healthier.

How to read it. The bold line is the combined score; the lighter lines are the two components. The faint background bands mark red (0–40), yellow (40–70), and green (70–100) zones. Use the toggle to switch to a split view showing each component on its own panel.

What to watch for. A declining combined line means the repo is accumulating debt faster than it is being paid down. A divergence between architectural and code health — one rising while the other falls — points to where the primary debt source is. Cross-reference with the Architecture trend panel for cycle and propagation details.

Suggested action. If architectural health is declining, run --analysis dependency-cycles to find the tangles introduced at the inflection point. If code health is declining, the Hotspot table will show which files are driving it.

What it measures. Monthly revision counts for the top-N hotspot files (N chosen with the selector below). Each polyline is one file's churn over time; the legend at the top maps colours to abbreviated paths (hover for full path).

How to read it. X-axis = month bucket. Y-axis = number of commits touching that file in that month. Hover any line to isolate it (others fade to 15%); click a legend entry to toggle that file's series on or off. Selecting a file anywhere else on the dashboard also highlights it here.

What to watch for. Sustained-flat lines at the top = chronic high-churn files (often god classes). Sharp recent spikes = a refactor in progress or a new bug-fix carousel. Cooling lines (descending) = refactors that are working.

Suggested action. Cross-reference a high-churn file against the Code health and Complexity colour modes in the Hotspot circle-pack — high churn + high complexity is the classic hotspot signature.

What it measures. Two 100% stacked bars: the top bar shows the share of total SLOC (source lines of code) in each health band at HEAD; the bottom bar shows the share of trailing-window churn (lines added + deleted) that landed in each band. The dot strip encodes the same churn share as 20 coloured dots — each dot = 5% of window churn.

How to read it. LOC bar = how your codebase is distributed today. Churn bar = where your team is actually spending its energy. If the churn bar has a large red segment while the LOC bar has a small red segment, the team is disproportionately fighting fires in its worst files.

What to watch for. Red churn share consistently above 40% indicates a reactive maintenance pattern. Improving = churn shifting toward green over successive sprints.

Suggested action. Prioritise the top hotspots with red health for refactoring investment to reduce the cost of future changes there.

What it measures. The top-20 hotspot files plotted simultaneously across five axes: Revisions, Cognitive complexity, Code health, Hotspot score (composite), and MI rank (maintainability percentile). Each polyline is one file.

How to read it. Follow a polyline left-to-right to see one file's profile across all five metrics. Drag-select a range on any axis to filter — polylines outside your selection grey out. Hover any polyline to isolate it (others fade to 15%); click to open the file drawer.

What to watch for. Files that are outliers on multiple axes at once — high Revisions AND high Cognitive AND low MI is a triple red flag. Drag-filter the Cognitive axis to "> 200" and the MI axis to "< 5%" simultaneously to see who survives both cuts.

Suggested action. Use this panel when no single metric clearly points to a winner. Multi-axis outliers are the highest-leverage refactor targets — addressing them moves several axes at once.

A. Inselberg 1985, The plane with parallel coordinates.

What it measures. The structural import graph as resolved from source: Rust use, Python import, JS/TS import. The depth selector below controls how aggressively paths are rolled up into "modules" — Auto deepens until at least 8 distinct nodes surface, fixed numbers force a specific roll-up depth.

How to read it. Force-directed layout: modules that import each other settle next to each other. Node colour = architectural role (Baldwin & MacCormack "hidden structure", from transitive reachability): core = the dominant dependency cycle; shared = depended on as widely as the core but depends on little (utilities); control = the inverse (orchestrators); periphery = the healthy leaf bulk. Diamonds = unstable interfaces; a ring = the module sits in a dependency cycle. Solid edges are imports; dashed edges are modularity violations (Fisher-significant co-change with no import edge). The title shows propagation cost — the share of the system a random change can reach.

What to watch for. A large red core means a big tangle everything routes through (hard to change in isolation) — confirm with --analysis dependency-cycles. A high propagation cost means changes ripple widely. Dashed edges are hidden coupling — two modules that change together but don't import each other, coupled through a shared global, a leaky abstraction, or a third party (Kazman & Cai's "implicit cross-module dependency"). Diamonds sitting on many edges are unstable hubs whose churn propagates.

Suggested action. Compare against the Module coupling chord above. Agreement (modules that import each other also change together) = healthy modularity. Disagreement = behaviour bleeds across structural boundaries; root-cause is usually a shared mutable state, a leaky framework, or a contract violated through string-typed APIs.

What it measures. The resolved import graph rolled up to modules (same depth selector as the graph above), rendered as a Dependency Structure Matrix (Steward 1981; Sangal et al. 2005). Modules are ordered by architectural layer — entry points first, foundations last — using the topological level from --analysis architecture-roles.

How to read it (Structure mode, the default). Each cell (row, col) means "row imports col"; blue intensity = number of imports. Because modules are layer-ordered, healthy forward dependencies fall above the diagonal. A cell below the diagonal is red — a back-edge, where a module imports something in its own layer or shallower, which only happens inside a dependency cycle. A perfectly triangular all-blue matrix is an acyclic, cleanly-layered architecture.

Fusion mode. Click the Fusion button to reclassify each above-diagonal cell against change-coupling data (aggregated to the same module depth): agree cells import and co-change (blue, opacity graded by co-change strength); structural only cells import but never co-change (dimmed); co-change only cells — a modularity violation — co-change with no import edge at all, in the same amber the architecture graph uses for its dashed violation edges. Back-edges below the diagonal stay red in both modes. Every cell's tooltip names its class; a legend row lists all four. With no change-coupling data, Fusion mode shows the structure-mode view plus a one-line hint instead of misleading empty classifications.

What to watch for. Red cells below the diagonal are your cycles / layering violations — cross-reference --analysis dependency-cycles. A dense red block straddling the diagonal is a large tangle (the Core). In Fusion mode, amber co-change-only cells are hidden coupling a resolver can't see — the same signal the architecture graph's dashed edges surface. Unlike the force graph, the matrix stays readable as the module count grows — this is the scalable default for big repos.

What it measures. Up to 12 commits evenly spaced across history are re-analysed: the import graph is rebuilt from the source as it existed at each revision, and the same propagation cost + dependency-cycle count the HEAD architecture metrics report are recomputed at each point (--analysis architecture-trend).

How to read it. The blue line is propagation cost (the share of the system a random change can reach, as a percentage); the red stepped line is the number of import-graph cycles. A propagation cost that climbs as the repo grows is healthy dilution turning into entanglement; a red step from 0 to 1 is the commit where the first dependency cycle appeared.

What to watch for. Sustained upward drift in either line is architectural decay. Cross-reference the commit dates with the dependency-cycles and architecture-metrics analyses to find the change that introduced a tangle. The final point matches the current HEAD metrics by construction.

What it measures. File-pair change-coupling at Fisher-significant rates — pairs of files that change together more often than chance would predict. Top 30 pairs by composite score (frequency × significance).

How to read it. Sankey diagram: source files on the left, target files on the right; each band is one file pair. Band width = strength of the coupling.

What to watch for. Wide bands between files that don't obviously belong together. That's the symptom of hidden coupling — shared global state, parallel-mod tax, contract violations through a third party. The Module coupling chord aggregates these to the module level; this panel is the file-level source of truth.

Suggested action. For unexpected strong pairs, look for shared dependencies you can extract or contracts you can formalise so that changes in one file don't have to ripple to the other.

Fisher's exact significance test applied per file pair; change-coupling theory: H. Gall, K. Hajek, M. Jazayeri 1998. Visual technique influenced by A. Tornhill, Your Code as a Crime Scene.

What it measures. A per-commit risk score derived from Kamei's Just-In-Time defect-prediction (JIT-SDP) feature vector. Each commit is scored on size (lines added/deleted), spread (number of files), concurrency (other contributors recently touching the same files), experience (the author's familiarity with the touched files), and entropy (how diffuse the change is across modules).

How to read it. Each bar is one commit, last 30 non-merge commits, chronological order. Bar height = composite risk %. Bar colour tags whether the commit is heuristically a bug-fix vs. a feature. Hover any bar to see the full feature vector and which dimension dominates that commit's risk.

What to watch for. Streaks of high-risk commits without proportionate review investment. Size dominance = big diff; entropy = scattered changes; concurrency = simultaneous editors fighting over the same files; inexp = an unfamiliar author for the touched files. Each tells a different story.

Suggested action. For commits in the 70%+ band, retroactively check whether the review caught the risky aspects. Use the Kamei dimensions as PR-template prompts: "what dominates the risk on this PR?".

Y. Kamei et al. 2013, A large-scale empirical study of just-in-time quality assurance; A. E. Hassan 2009, Predicting faults using the complexity of code changes.

What it measures. Per-day commit volume across the entire analysed history. GitHub-style heatmap; one cell per day, one calendar block per year.

How to read it. Darker cells = more commits that day. The colour bands at the top map cell shade to commit-count buckets. Hover a cell for the exact date and count.

What to watch for. Cadence patterns and gaps. Sustained dark streaks = consistent delivery. Weekend or off-hours commits = potential burnout signal. Long quiet periods aligned with release dates = release-freeze rhythm. Sudden bursts in unusual periods often correlate with incidents.

Suggested action. Compare against the Delivery risk sparkline — activity bursts that coincide with high-risk commits are worth a retro discussion. Long silent days in a "shipping" team are equally worth surfacing.