<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>{{TITLE}}</title>
<!-- Inline PWA manifest via data URI keeps the single-file SPA
self-contained. iOS/Android browsers prompt "Add to Home
Screen" on this signal; the inline Service Worker registration
in the boot script delivers offline support so the dashboard
works on a plane / air-gap. -->
<link rel="manifest" href='data:application/json,{"name":"CodeLore","short_name":"CodeLore","description":"Behavioral code analysis dashboard","display":"standalone","start_url":"./","theme_color":"%231a1a1a","background_color":"%231a1a1a","icons":[]}'/>
<meta name="theme-color" content="#1a1a1a"/>
<meta name="apple-mobile-web-app-capable" content="yes"/>
<meta name="apple-mobile-web-app-status-bar-style" content="black"/>
<!-- Anti-flash-of-wrong-theme guard. Runs BEFORE any CSS or markup
is parsed below, so the `data-theme` attribute is in place by
the time the rest of the document is styled.
- If the user has an explicit saved preference (Alpine $persist
writes to localStorage keys prefixed with `_x_`), restore it
here so first paint matches.
- If not, leave `data-theme` unset and rely on the DaisyUI
`--prefersdark` config in `tailwind-src/input.css` to apply
the OS-level `prefers-color-scheme` via CSS.
- Migration: a previous version persisted theme under the
`codelore-theme` key with string values 'light' / 'dark'.
If found, translate to the new boolean-stringified key and
delete the old entry so legacy preferences are honoured. -->
<script>
(function () {
try {
var legacy = localStorage.getItem('codelore-theme');
if (legacy && localStorage.getItem('_x_codelore_theme_is_dark') === null) {
localStorage.setItem('_x_codelore_theme_is_dark', JSON.stringify(legacy === 'dark'));
localStorage.removeItem('codelore-theme');
}
var stored = localStorage.getItem('_x_codelore_theme_is_dark');
if (stored === 'true') document.documentElement.setAttribute('data-theme', 'dark');
else if (stored === 'false') document.documentElement.setAttribute('data-theme', 'light');
/* else: no preference saved → DaisyUI --default + --prefersdark
handles first paint via CSS media query. */
} catch (e) { /* localStorage blocked: fall through to CSS default. */ }
})();
</script>
<!-- Precompiled Tailwind v4 + DaisyUI 5 bundle.
Rebuild via `tailwindcss -i tailwind-src/input.css -o tailwind.daisyui.min.css --minify`
(see `tailwind-src/README.md`). The hand-rolled `<style>` block
below carries inline CSS that pre-dates the DaisyUI conversion;
the two co-exist so legacy widget classes keep working while
DaisyUI tokens are available to new widgets. -->
<style>{{TAILWIND_DAISY_CSS}}</style>
<style>
:root {
--bg: #0f0f0f;
--bg-elev: #1a1a1a;
--bg-elev-2: #232323;
--fg: #e6e6e6;
--fg-dim: #8a8a8a;
--accent: #2ea44f;
--accent-warn: #f59e0b;
--accent-danger: #e0584e;
--border: #2a2a2a;
/* X-Ray sunburst container-ring fills. The two outer rings sit
on the elevated card background; the third (leaf) ring is the
heatmap (yellow→red) that widgets.js paints inline based on
cognitive complexity. Ring colors here only style the
containers, not the leaves. Dark-theme defaults — light-theme
overrides below.
The leaf label sits on top of saturated heatmap colors, so it
needs to remain dark-on-light regardless of theme to clear
WCAG AA contrast (~4.5:1 against the yellow end of the
ramp). Hence the leaf label color is the same across themes;
only the container-ring fills swap. */
--xray-ring-1: #1f3f29;
--xray-ring-2: #2c5d3a;
--xray-ring-label: #ffffff;
--xray-leaf-label: #1a1a1a;
/* Per-widget chart palette tokens. Previously these hex
literals were inlined in `widgets.js` (sankey label color,
treemap label-on-saturated, friction calendar 5-band ramp,
15-color author palette), so light-theme rendering used the
dark-mode palette and the calendar-heatmap "low" band was
barely visible against the white card. Each token has a
light-theme override in `[data-theme="light"]` below. */
--label-on-dark: #e6e6e6;
--label-on-saturated: #ffffff;
/* Friction calendar 5-band ramp (low → high). Tuned for dark
backgrounds. */
--heatmap-1: #1a4a2c;
--heatmap-2: #2ea44f;
--heatmap-3: #7dd87a;
--heatmap-4: #f59e0b;
--heatmap-5: #e0584e;
/* 15-color categorical palette for the author / knowledge-map
widget. Same hex set previously inlined in JS. */
--chart-palette-1: #5fa472;
--chart-palette-2: #2ea44f;
--chart-palette-3: #7dd87a;
--chart-palette-4: #f59e0b;
--chart-palette-5: #e0584e;
--chart-palette-6: #c47ddb;
--chart-palette-7: #8ab4ff;
--chart-palette-8: #5bcdd5;
--chart-palette-9: #d4953b;
--chart-palette-10: #a8a8a8;
--chart-palette-11: #b53935;
--chart-palette-12: #3d7d4f;
--chart-palette-13: #c97600;
--chart-palette-14: #6a6aef;
--chart-palette-15: #ce62a6;
}
* { box-sizing: border-box; }
body {
margin: 0;
background: var(--bg);
color: var(--fg);
font: 14px -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, sans-serif;
line-height: 1.5;
}
header {
padding: 20px 28px;
background: var(--bg-elev);
border-bottom: 1px solid var(--border);
display: flex;
align-items: baseline;
gap: 20px;
}
header h1 {
margin: 0;
font-size: 18px;
font-weight: 600;
}
header .meta {
color: var(--fg-dim);
font-size: 12px;
}
/* `main` itself carries no grid layout — each dashboard section
(`.dash-group`) owns its own grid (`.dash-group-grid`, below).
`main` only centers the page and caps its width via
`.dashboard-main`. */
.widget {
/* DaisyUI's `card bg-base-200 shadow-lg` classes on the
section provide elevation, fill, and rounded corners.
`padding` stays since DaisyUI's bare `.card` expects a
`.card-body` child for padding, which we don't restructure
to. `position: relative` is the anchor for any tooltip
we `appendTo` the section (Kamei delivery-risk widget) —
without it, `top: 4; right: 4` would fall through to the
viewport instead of pinning to the panel's top-right
corner. `min-width: 0` overrides the grid item's default
automatic minimum size (its content's min-content width) —
without it, a repo with a wide hotspot/DSM table blows the
widget past its column and past `<main>` itself, making the
whole page scroll sideways. With it, that intrinsic-width
content is contained by its own `.table-container` / chart
host, which scrolls internally (`overflow-x: auto`) as the
responsive rules require. */
padding: 20px;
position: relative;
min-width: 0;
/* `view-transition-name: match-element` (Chrome 147+) auto-
assigns a stable transition identity to every `.widget` so
theme toggles, layout swaps, and 'Show all' expansions
crossfade per-widget instead of as one document-wide
repaint. Falls through harmlessly on older browsers — the
transition still runs document-scoped. */
view-transition-name: match-element;
}
/* Per-row transitions on hotspot table — `match-element` assigns a
stable identity so sort, filter, and 'Show all' expansion animate
row-by-row rather than as one full-table crossfade. CSS Containment
caps the cost: each row's transition is independent of its siblings.
*/
.hotspot-row {
view-transition-name: match-element;
contain: layout style;
}
/* Keyboard-focus affordance for table rows that act as buttons
(hotspot table, knowledge-islands table). `wireRowKbActivation`
in widgets.js promotes each `<tr>` to `tabindex="0"` +
`role="button"`; this rule paints a visible focus ring so
keyboard users can see which row is about to be activated by
Enter/Space. `:focus-visible` (not bare `:focus`) keeps mouse
clicks from drawing the ring — same UA heuristic native
buttons use. WCAG 2.4.7. */
tr.hotspot-row:focus-visible,
tr.ki-row:focus-visible {
outline: 2px solid var(--accent);
outline-offset: -2px;
}
/* Respect the OS "reduce motion" preference. The JS
`startViewTransition` guard only covers the programmatic
crossfade path; CSS transitions/animations and the document-wide
`view-transition-name` crossfades still animate without this.
Near-zero (not 0) durations keep transitionend / animationend
listeners firing so nothing that waits on them stalls, while
opting every widget + hotspot row out of the per-element
view-transition so theme/layout swaps repaint instantly for users
who asked for no motion. WCAG 2.3.3. */
@media (prefers-reduced-motion: reduce) {
*, *::before, *::after {
transition-duration: 0.01ms !important;
animation-duration: 0.01ms !important;
}
.widget, .hotspot-row {
view-transition-name: none;
}
}
.widget h3 {
margin: 0 0 4px 0;
font-size: 14px;
font-weight: 600;
}
.widget .subtitle {
color: var(--fg-dim);
font-size: 12px;
margin-bottom: 12px;
}
/* Progressive-disclosure pattern: the inline subtitle stays
terse (one line, scannable), and a native `<details>` element
expands a deeper explanation on demand (what it measures, how
to read it, what to look for, recommended action, citation).
Uses semantic HTML so it's keyboard-accessible and works
without JS; no Alpine binding needed. */
.widget .learn-more {
font-size: 12px;
color: var(--fg-dim);
margin-bottom: 16px;
border-left: 2px solid var(--border);
padding-left: 10px;
}
.widget .learn-more > summary {
cursor: pointer;
list-style: none;
color: var(--fg-dim);
font-weight: 500;
padding: 2px 0;
user-select: none;
}
.widget .learn-more > summary::-webkit-details-marker { display: none; }
.widget .learn-more > summary::before {
content: '▸ ';
display: inline-block;
transition: transform 120ms ease;
}
.widget .learn-more[open] > summary::before {
content: '▾ ';
}
.widget .learn-more > summary:hover { color: var(--fg); }
.widget .learn-more-content {
padding-top: 8px;
line-height: 1.55;
}
.widget .learn-more-content p {
margin: 0 0 8px 0;
}
.widget .learn-more-content p:last-child { margin-bottom: 0; }
.widget .learn-more-content strong {
color: var(--fg);
font-weight: 600;
}
.widget .learn-more-content cite {
color: var(--fg-dim);
font-style: normal;
font-size: 11px;
}
.widget-body {
width: 100%;
height: 600px;
}
/* Low-content widgets escape the chart-sized fixed height; each mount
keeps its own inline min-height floor. */
.widget-body.auto-height {
height: auto;
}
.widget .empty {
color: var(--fg-dim);
padding: 40px;
text-align: center;
}
.table-controls {
display: flex;
align-items: center;
gap: 12px;
margin-bottom: 12px;
font-size: 12px;
flex-wrap: wrap;
}
.table-controls input[type="text"] {
flex: 0 0 280px;
background: var(--bg-elev-2);
color: var(--fg);
border: 1px solid var(--border);
border-radius: 4px;
padding: 6px 8px;
font-size: 12px;
font-family: inherit;
}
.table-controls input[type="text"]:focus {
outline: none;
border-color: var(--accent);
}
.table-summary { color: var(--fg-dim); }
.table-actions { margin-left: auto; display: flex; gap: 8px; }
.table-actions button {
background: var(--bg-elev-2);
color: var(--fg);
border: 1px solid var(--border);
border-radius: 4px;
padding: 4px 10px;
cursor: pointer;
font-size: 12px;
font-family: inherit;
}
.table-actions button:hover { border-color: var(--accent); }
.table-actions button:disabled { opacity: 0.4; cursor: default; }
.table-container {
overflow-x: auto;
max-height: 60vh;
border: 1px solid var(--border);
border-radius: 4px;
}
.table-container table {
width: 100%;
border-collapse: collapse;
font-size: 12px;
font-variant-numeric: tabular-nums;
}
.table-container thead {
position: sticky;
top: 0;
background: var(--bg-elev-2);
z-index: 1;
}
.table-container th {
padding: 8px 12px;
text-align: left;
font-weight: 600;
color: var(--fg);
border-bottom: 1px solid var(--border);
cursor: pointer;
user-select: none;
white-space: nowrap;
}
.table-container th:hover { color: var(--accent); }
.table-container th .sort-indicator {
display: inline-block;
width: 10px;
color: var(--fg-dim);
}
.table-container th.active .sort-indicator { color: var(--accent); }
.table-container td {
padding: 6px 12px;
border-bottom: 1px solid var(--bg-elev-2);
color: var(--fg);
}
.table-container tr:hover td { background: var(--bg-elev-2); }
.table-container .num { text-align: right; font-variant-numeric: tabular-nums; }
.table-container .path { font-family: ui-monospace, "SF Mono", Menlo, Consolas, monospace; }
/* ── Factor header ──────────────────────────────────────────── */
.factor-tiles {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));
gap: 16px;
padding: 4px 0;
}
.factor-tile {
display: flex;
flex-direction: column;
gap: 4px;
}
/* Jump-link tiles (Code / Architecture / Knowledge / Delivery — see
FACTOR_TILE_TARGETS in the widget-render script) share the sticky
nav's scroll path. `:focus-visible` mirrors the existing
keyboard-focus convention for other custom `role`-carrying rows
(`tr.hotspot-row:focus-visible` above). WCAG 2.4.7. */
.factor-tile[data-target] {
cursor: pointer;
}
.factor-tile[data-target]:focus-visible {
outline: 2px solid var(--accent);
outline-offset: 2px;
}
.factor-name {
font-size: 0.75rem;
font-weight: 600;
text-transform: uppercase;
letter-spacing: 0.05em;
opacity: 0.7;
}
.factor-headline {
font-size: 1.75rem;
font-weight: 700;
line-height: 1;
}
.factor-attention-chip {
display: inline-block;
font-size: 0.65rem;
font-weight: 600;
text-transform: uppercase;
letter-spacing: 0.05em;
padding: 1px 6px;
border-radius: 9999px;
background: oklch(var(--wa));
color: oklch(var(--wac));
margin-bottom: 2px;
}
.factor-bullet-wrap {
display: flex;
align-items: center;
gap: 6px;
}
.factor-bullet-track {
flex: 1;
position: relative;
height: 8px;
background: oklch(var(--b3));
border-radius: 4px;
overflow: visible;
}
.factor-bullet-fill {
height: 100%;
border-radius: 4px;
transition: width 0.3s ease;
}
.factor-bullet-mean-tick {
position: absolute;
top: -2px;
width: 2px;
height: 12px;
background: oklch(var(--bc) / 0.4);
border-radius: 1px;
transform: translateX(-50%);
}
.factor-bullet-label {
font-size: 0.7rem;
font-weight: 600;
min-width: 2.5rem;
text-align: right;
}
.factor-sparkline {
height: 60px;
width: 100%;
}
.factor-detail {
font-size: 0.7rem;
opacity: 0.6;
line-height: 1.3;
}
/* ── Share bars + effort dot strip (A.5) ────────────────────── */
.share-bars-container {
display: flex;
flex-direction: column;
gap: 6px;
padding: 4px 0;
}
.share-bar-row {
display: flex;
align-items: center;
gap: 8px;
}
.share-bar-axis-label {
font-size: 0.7rem;
font-weight: 600;
text-transform: uppercase;
letter-spacing: 0.05em;
opacity: 0.6;
min-width: 2.8rem;
text-align: right;
}
.share-bar-track {
flex: 1;
display: flex;
height: 22px;
border-radius: 4px;
overflow: hidden;
}
.share-bar-segment {
display: flex;
align-items: center;
justify-content: center;
overflow: hidden;
transition: width 0.3s ease;
}
.share-bar-label {
font-size: 0.65rem;
font-weight: 600;
color: #fff;
text-shadow: 0 1px 2px rgba(0,0,0,0.4);
white-space: nowrap;
padding: 0 4px;
}
.effort-dot-strip-wrap {
display: flex;
align-items: center;
gap: 8px;
}
.effort-dot-strip {
display: flex;
flex-wrap: wrap;
gap: 4px;
padding: 4px 0;
}
.effort-dot {
display: inline-block;
width: 12px;
height: 12px;
border-radius: 50%;
}
.share-bars-caption {
font-size: 0.78rem;
opacity: 0.75;
margin-top: 2px;
}
/* ── Guided tour stepper ─────────────────────────────────────── */
.tour-nav {
display: flex;
align-items: center;
gap: 12px;
flex-wrap: wrap;
}
.tour-chips {
display: flex;
gap: 6px;
align-items: center;
}
.tour-chip {
display: inline-flex;
align-items: center;
justify-content: center;
width: 28px;
height: 28px;
border-radius: 50%;
font-size: 0.8rem;
font-weight: 600;
border: 2px solid var(--color-base-content, currentColor);
background: transparent;
color: var(--color-base-content, currentColor);
opacity: 0.45;
cursor: pointer;
transition: opacity 0.15s, background 0.15s;
}
.tour-chip:hover { opacity: 0.75; }
.tour-chip-active { opacity: 1; background: var(--color-primary, oklch(0.588 0.218 270)); color: var(--color-primary-content, #fff); border-color: var(--color-primary, oklch(0.588 0.218 270)); }
.tour-chip-done { opacity: 0.65; background: var(--color-base-300, oklch(0.85 0 0)); }
.tour-buttons {
display: flex;
gap: 6px;
margin-left: auto;
}
.tour-btn {
padding: 4px 14px;
border-radius: 6px;
font-size: 0.82rem;
font-weight: 500;
border: 1px solid var(--color-base-content, currentColor);
background: transparent;
cursor: pointer;
opacity: 0.85;
}
.tour-btn:disabled { opacity: 0.3; cursor: default; }
.tour-btn-primary { background: var(--color-primary, oklch(0.588 0.218 270)); color: var(--color-primary-content, #fff); border-color: var(--color-primary, oklch(0.588 0.218 270)); opacity: 1; }
.tour-btn-ghost { border-color: transparent; opacity: 0.6; }
.tour-note {
margin-top: 8px;
padding: 8px 12px;
border-radius: 6px;
background: var(--color-base-300, oklch(0.85 0 0));
font-size: 0.82rem;
line-height: 1.5;
transition: opacity 0.2s;
}
.tour-note-title { font-weight: 600; }
/* ── KPI grid ────────────────────────────────────────────────── */
.kpi-grid {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(180px, 1fr));
gap: 12px;
}
.kpi-tile {
/* DaisyUI's `stat` class (added by
widgets.js::renderKpiTiles) provides background, border,
border-radius, and padding. The empty rule + selector is
kept rather than deleted so any future polish has a
targeted home. */
}
.kpi-tile .kpi-label {
color: var(--fg-dim);
font-size: 11px;
text-transform: uppercase;
letter-spacing: 0.04em;
margin-bottom: 4px;
}
.kpi-tile .kpi-value {
font-size: 22px;
font-weight: 600;
font-variant-numeric: tabular-nums;
color: var(--fg);
}
.kpi-tile .kpi-sub {
color: var(--fg-dim);
font-size: 11px;
margin-top: 2px;
}
/* "?" provenance tooltips. CSS-only show/hide via :hover and
:focus-within so keyboard users get tooltips for free and we
don't add JS listeners that could leak (F71 lesson).
The popup is positioned absolutely relative to the trigger's
parent element — callers should give the parent
`position: relative` (kpi-label and th.col-with-tooltip
already do). */
.tooltip-trigger {
display: inline-block;
/* 24×24 to meet WCAG 2.5.5 Target Size (Minimum). The glyph is
visually small (12px font on a 24×24 button) so the trigger
doesn't look heavy next to dense table headers, but the full
24×24 click/tap area is reachable for coarse pointers — same
pattern WCAG suggests for inline help affordances. */
width: 24px;
height: 24px;
margin-left: 4px;
padding: 0;
border: 1px solid var(--border);
border-radius: 50%;
background: transparent;
color: var(--fg-dim);
font-size: 12px;
font-weight: bold;
line-height: 22px;
vertical-align: -7px;
cursor: help;
font-family: inherit;
text-transform: none;
letter-spacing: 0;
/* Anchor name binds this element as the reference point for any
`.tooltip-popup` inside the same `.tooltip-host` — the popup's
`position-anchor: --tooltip-trigger` resolves against it via
CSS anchor positioning (Chrome 125+, Firefox 147+, Safari 26).
The fallback `position: absolute` on `.tooltip-popup` keeps
older browsers rendering against `.tooltip-host { position:
relative }` exactly as before. */
anchor-name: --tooltip-trigger;
}
.tooltip-trigger:hover,
.tooltip-trigger:focus-visible {
border-color: var(--accent);
color: var(--accent);
outline: none;
}
.tooltip-host {
/* `position: relative` is the legacy fallback anchor — Chromium
<125 / Firefox <147 / Safari <26 ignore `anchor-name` /
`position-anchor` and fall back to absolute-against-relative
positioning. The popup's `position: absolute` resolves to this
element on those browsers; new browsers prefer the
`anchor()`-driven coordinates below. */
position: relative;
display: inline;
}
/* `.tooltip-host` defaults to `display: inline` to support inline-text
usage (kpi-label, table headers). When the host is a tab button we
must preserve its flex layout so the label + ? trigger sit on one
baseline. Same override applies to any button that wears the
convention. */
button.tooltip-host,
.tab.tooltip-host {
display: inline-flex;
align-items: center;
gap: 4px;
}
.tooltip-popup {
display: none;
position: absolute;
left: 0;
top: 100%;
z-index: 50;
margin-top: 6px;
width: max-content;
max-width: 340px;
padding: 10px 12px;
background: var(--bg-elev-2);
border: 1px solid var(--border);
border-radius: 6px;
box-shadow: 0 4px 14px rgba(0, 0, 0, 0.25);
color: var(--fg);
font-size: 12px;
font-weight: normal;
text-transform: none;
letter-spacing: 0;
line-height: 1.5;
white-space: normal;
text-align: left;
/* CSS anchor positioning (Baseline 2026 newly available — Chrome
125+, Firefox 147+, Safari 26). When the browser supports
`anchor()`, the popup pins itself to the `.tooltip-trigger`
(anchor-name: --tooltip-trigger) regardless of where in the DOM
the popup lives — viewport-resize and scroll tracking are
handled by the browser, retiring the `position: relative` hack
on the host element. `top` + `left` declared via `anchor()`
take precedence over the fallback `left/top: 100%/0` above.
Older browsers ignore these declarations and use the legacy
path; `@supports` would be redundant since `anchor()` is
self-rejecting on unsupported engines.
Spec: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_anchor_positioning/Using */
position-anchor: --tooltip-trigger;
top: calc(anchor(bottom) + 6px);
left: anchor(center);
translate: -50% 0;
/* `@position-try-fallbacks` lists alternate placements the
browser tries when the primary placement would overflow the
viewport. The browser walks the list and picks the first that
fits. Mirror above / below / right / left so the popup never
clips off-screen at table edges or fullscreen-mode panels. */
position-try-fallbacks: --tooltip-above, --tooltip-right, --tooltip-left;
}
@position-try --tooltip-above {
top: auto;
bottom: calc(anchor(top) + 6px);
left: anchor(center);
translate: -50% 0;
}
@position-try --tooltip-right {
top: anchor(center);
left: calc(anchor(right) + 6px);
translate: 0 -50%;
}
@position-try --tooltip-left {
top: anchor(center);
left: auto;
right: calc(100% - anchor(left) + 6px);
translate: 0 -50%;
}
.tooltip-host:hover .tooltip-popup,
.tooltip-host:focus-within .tooltip-popup {
display: block;
}
.tooltip-popup strong { color: var(--fg); }
.tooltip-popup code {
font-family: ui-monospace, "SF Mono", Menlo, Consolas, monospace;
font-size: 11px;
padding: 1px 4px;
border-radius: 3px;
background: rgba(127, 127, 127, 0.15);
}
.tooltip-popup .tooltip-formula {
margin-top: 4px;
font-family: ui-monospace, "SF Mono", Menlo, Consolas, monospace;
font-size: 11px;
color: var(--fg);
}
.tooltip-popup .tooltip-citation {
margin-top: 8px;
padding-top: 6px;
border-top: 1px solid var(--border);
font-size: 11px;
color: var(--fg-dim);
}
.tooltip-popup .tooltip-citation a {
color: var(--accent);
text-decoration: none;
}
.tooltip-popup .tooltip-citation a:hover { text-decoration: underline; }
.widget.differentiator {
border-color: rgba(46, 164, 79, 0.35);
box-shadow: 0 0 0 1px rgba(46, 164, 79, 0.15) inset;
}
/* Fullscreen toggle button injected into every widget by
widgets.js. Native HTML5 Fullscreen API drives the actual
expand/collapse; the button is just a click target rendered
in the panel's top-right corner. `:fullscreen` pseudo-class
restyles the section so it fills the viewport with a sensible
padding + scroll. ECharts charts inside get a `resize()` call
on fullscreenchange so they re-layout to the new size. */
.widget-fullscreen-btn,
.widget-reset-zoom-btn {
position: absolute;
top: 10px;
width: 26px;
height: 26px;
padding: 0;
background: transparent;
border: 1px solid var(--border);
border-radius: 4px;
color: var(--fg-dim);
cursor: pointer;
display: inline-flex;
align-items: center;
justify-content: center;
z-index: 50;
transition: color 120ms ease, border-color 120ms ease;
}
.widget-fullscreen-btn { right: 10px; }
/* Reset-zoom button sits to the LEFT of the fullscreen button
(26 px button + 6 px gap = 32 px offset) so the two corner
controls cluster together. Only attached to widgets that
wear `[data-supports-zoom]`. */
.widget-reset-zoom-btn { right: 42px; }
.widget-fullscreen-btn:hover,
.widget-fullscreen-btn:focus-visible,
.widget-reset-zoom-btn:hover,
.widget-reset-zoom-btn:focus-visible {
color: var(--fg);
border-color: var(--accent);
outline: none;
}
.widget-fullscreen-btn svg,
.widget-reset-zoom-btn svg { display: block; }
/* Fullscreen panel: dark fill, generous padding, charts grow. */
.widget:fullscreen {
background: var(--bg);
padding: 40px;
overflow: auto;
}
.widget:fullscreen .widget-body {
height: calc(100vh - 220px) !important;
min-height: 400px;
}
.widget:fullscreen .table-container {
max-height: calc(100vh - 220px);
overflow: auto;
}
/* Knowledge-loss flag in the keyboard-accessible file list.
Reacts to `$store.scenario.departed` via the Alpine binding
in the template. Hand-written here because the inlined
Tailwind bundle is pre-built; arbitrary semantic-colour classes
added after the last `tailwindcss` run won't be in the
inlined stylesheet. */
.ki-row-departed {
border-left: 3px solid var(--color-error, #e0584e);
padding-left: 6px;
background: rgba(224, 88, 78, 0.10);
}
/* Hotspot table row flagged as knowledge-loss under the active
off-boarding scenario. The first `<td>` gets the left border;
the row gets a faint red wash so it stands out at a glance
without distorting column alignment (a per-row border-left
would shift `border-collapse` widths). */
.hotspot-row-departed { background: rgba(224, 88, 78, 0.08); }
.hotspot-row-departed td:first-child {
box-shadow: inset 3px 0 0 var(--color-error, #e0584e);
}
/* Hotspot table row inside the active bivariate quadrant brush. A SET
emphasis distinct from the single-selection `!bg-base-300` (neutral)
and the off-boarding `.hotspot-row-departed` (red): a faint blue wash
+ info-blue left accent on the first cell (same alignment-safe
box-shadow trick as .hotspot-row-departed, so no column-width shift).
A row can carry this AND the selection background simultaneously. */
.hotspot-row-brushed { background: rgba(59, 130, 246, 0.06); }
.hotspot-row-brushed td:first-child {
box-shadow: inset 3px 0 0 var(--color-info, #3b82f6);
}
/* Visually-hidden but screen-reader-available. The Tailwind bundle is
pre-built so `sr-only` isn't in it; this is the hand-rolled equivalent
used by the cross-widget selection live-region announcer. */
.sr-only {
position: absolute;
width: 1px; height: 1px;
padding: 0; margin: -1px;
overflow: hidden; clip: rect(0, 0, 0, 0);
white-space: nowrap; border: 0;
}
.ki-knowledge-loss-badge {
flex-shrink: 0;
display: inline-block;
padding: 2px 8px;
font-size: 10px;
line-height: 14px;
font-weight: 600;
color: #fff;
background: var(--color-error, #e0584e);
border-radius: 4px;
letter-spacing: 0.02em;
}
/* Boot-failure banner. Written into <main> by the widget script when
the embedded data block is missing or unparseable, in place of the
empty-but-fully-chromed dashboard that is otherwise indistinguishable
from "no findings". Hand-written here (not a DaisyUI `alert`) because
the inlined Tailwind bundle is pre-built and semantic-colour alert
classes added after the last `tailwindcss` run aren't in it. */
.codelore-boot-error {
margin: 24px auto;
max-width: 640px;
padding: 16px 20px;
border-left: 4px solid var(--color-error, #e0584e);
background: rgba(224, 88, 78, 0.10);
border-radius: 6px;
color: var(--color-base-content, currentColor);
}
.codelore-boot-error-title {
display: block;
font-weight: 700;
margin-bottom: 6px;
}
.codelore-boot-error p { margin: 4px 0 0 0; }
.codelore-boot-error-remedy { opacity: 0.85; font-size: 0.9em; }
/* Drawer enhancement lists — coupling partners, top contributors,
functions. Tighter density than the default <ul>; .drawer-author
provides the secondary metadata greyed-out so the primary
identifier (file path / function / author name) reads first. */
.drawer-partners {
list-style: none;
margin: 4px 0 12px 0;
padding: 0;
}
.drawer-partners > li {
padding: 4px 8px;
font-size: 12px;
line-height: 1.4;
border-radius: 4px;
}
.drawer-partners > li + li { margin-top: 2px; }
.drawer-partners .drawer-author {
color: var(--fg-dim);
font-size: 11px;
}
.drawer-partners .drawer-partner-departed {
background: rgba(224, 88, 78, 0.10);
border-left: 3px solid var(--color-error, #e0584e);
padding-left: 5px;
}
/* Wide-screen support. Hand-written here because the inlined
Tailwind bundle is pre-built; arbitrary `max-w-[…]` classes
added after the last `tailwindcss -i ... -o ...` run won't
be in the inlined stylesheet. A single rule lifts the
horizontal cap from 1600 px to 2400 px so ultra-wide / 4K
displays don't leave huge whitespace sidebars. Beyond
2400 px the dashboard centres itself with `mx-auto`. */
.dashboard-main {
max-width: 2400px;
}
/* Section grouping. Hand-written (the pre-built utility bundle is frozen);
single column below 1280px, two columns above — wide cards span both.
`scroll-margin-top` offsets `scrollIntoView` targets by the sticky
nav's height so a jumped-to section's heading isn't hidden under the
bar — `scrollToDashSection` (00_setup_boot.js) does no offset math
of its own. */
.dash-group { margin-bottom: 2.5rem; scroll-margin-top: 3.25rem; }
.dash-group-title { font-size: 1.35rem; font-weight: 700; margin: 0; }
/* align-items: start (not the grid default `stretch`) — without it
every widget stretches to match its tallest row-mate, voiding
narrower cards with empty space below their content. */
.dash-group-grid { display: grid; grid-template-columns: 1fr; gap: 1.75rem; align-items: start; }
@media (min-width: 1280px) {
.dash-group-grid { grid-template-columns: repeat(2, minmax(0, 1fr)); }
}
/* Collapsible sections. The chevron button sits beside the `<h2>` in
a flex header row; `initDashCollapse` (00_setup_boot.js) toggles
`.dash-collapsed` on the `.dash-group` ancestor on click, which
hides `.dash-group-grid` (hand-written — the frozen bundle has no
collapse utility) and rotates the chevron. Never persisted —
sections always render expanded at load so ECharts instances
never initialize inside a hidden container; expanding re-runs the
existing `resizeAllEchartsIn` sweep over the section so any chart
that resized while hidden recovers correct layout. */
.dash-group-head {
display: flex;
align-items: center;
gap: 0.5rem;
margin: 0 0 1rem 0.25rem;
}
.dash-collapse {
display: inline-flex;
align-items: center;
justify-content: center;
width: 24px;
height: 24px;
padding: 0;
background: transparent;
border: 1px solid var(--border);
border-radius: 4px;
color: var(--fg-dim);
cursor: pointer;
transition: color 120ms ease, border-color 120ms ease;
}
.dash-collapse:hover,
.dash-collapse:focus-visible {
color: var(--fg);
border-color: var(--accent);
outline: none;
}
.dash-collapse svg { display: block; transition: transform 160ms ease; }
.dash-collapsed .dash-collapse svg { transform: rotate(-90deg); }
.dash-collapsed .dash-group-grid { display: none; }
/* Sticky section nav. `btn btn-xs btn-ghost` (DaisyUI, confirmed
present in the frozen bundle) style the chip buttons themselves;
only the bar chrome and the active-chip highlight are hand-written
here, since `top-*` / `z-*` utilities are NOT in the bundle. */
#dash-nav {
position: sticky;
top: 0;
z-index: 30;
display: flex;
gap: 0.5rem;
flex-wrap: wrap;
padding: 0.5rem 1.75rem;
backdrop-filter: blur(6px);
background: color-mix(in oklab, var(--bg-elev) 88%, transparent);
border-bottom: 1px solid var(--border);
}
.dash-nav-chip.dash-active {
background: var(--color-primary, oklch(0.588 0.218 270));
color: var(--color-primary-content, #fff);
border-color: var(--color-primary, oklch(0.588 0.218 270));
}
/* Back-to-top. `btn btn-sm btn-ghost` supplies hover/focus chrome;
`btn-circle` is NOT in the frozen bundle, so the round shape is
hand-written (fixed size + full radius + zeroed padding override
the DaisyUI rectangular defaults). Hidden until `initDashNav`'s
scroll listener adds `.dash-visible` past 600px of scroll. */
#dash-top-btn {
position: fixed;
right: 1.25rem;
bottom: 1.25rem;
z-index: 30;
display: none;
width: 2.5rem;
height: 2.5rem;
padding: 0;
border-radius: 50%;
}
#dash-top-btn.dash-visible {
display: inline-flex;
align-items: center;
justify-content: center;
}
/* Layout only — no color/background/border here. This unlayered legacy
rule sits above DaisyUI's `@layer`ed styles, so per CSS Cascade 5 any
property it declares beats DaisyUI's `badge-error` / `badge-warning` /
`badge-success` regardless of specificity or source order. Every badge
in this dashboard is rendered with a DaisyUI color/semantic modifier
class alongside the plain `badge` class (see template.html / js/), so
letting DaisyUI's `--badge-color` indirection paint color/background/
border here is what makes those modifiers visually distinct instead of
every badge rendering identically green. */
.badge {
display: inline-block;
margin-left: 6px;
padding: 2px 6px;
font-size: 10px;
font-weight: 500;
letter-spacing: 0.02em;
border-radius: 3px;
vertical-align: 1px;
}
.detail-drawer {
position: fixed;
top: 0;
right: 0;
bottom: 0;
/* Explicitly clear the browser-default <dialog> `left: 0` and
`margin: auto` — without these, the over-constrained
`left + right + width` resolves by keeping `left: 0` and
ignoring `right`, which painted the drawer at the
top-LEFT corner instead of the intended right-side panel. */
left: auto;
margin: 0;
width: min(440px, 90vw);
background: var(--bg-elev);
border-left: 1px solid var(--border);
box-shadow: -8px 0 24px rgba(0, 0, 0, 0.4);
z-index: 100;
display: flex;
flex-direction: column;
}
.detail-drawer[hidden] { display: none; }
/* DaisyUI's `.modal-box` ships `opacity: 0` and only fades to 1 via a
`.modal.modal-open` / `.modal[open]` ancestor. This drawer deliberately
drops the `.modal` class (see the <dialog> note below) to fix
positioning, so nothing ever set the content opaque — it rendered fully
transparent, i.e. a blank popup (black in dark mode) even though the DOM
was populated. The slide-in panel is `.detail-drawer` itself, so force
its content visible and clear any DaisyUI open/close transform. */
.detail-drawer .modal-box { opacity: 1; transform: none; }
/* Suppress flash-of-visible-drawer before Alpine.js's
`x-show="$store.detail.open"` runs. Alpine sets `x-cloak`
attributes pre-init; this rule hides them until Alpine
removes the attribute on first render. */
[x-cloak] { display: none !important; }
.drawer-header {
padding: 14px 20px;
border-bottom: 1px solid var(--border);
display: flex;
align-items: center;
gap: 12px;
}
.drawer-header h3 {
margin: 0;
font-size: 13px;
font-weight: 600;
flex: 1;
word-break: break-all;
font-family: ui-monospace, "SF Mono", Menlo, Consolas, monospace;
}
.drawer-close {
/* DaisyUI's `btn btn-ghost btn-sm` classes on the drawer
markup provide background / border / color / border-radius
and the hover state. The sizing tokens stay for click-target
consistency with the drawer-close affordance. */
width: 28px;
height: 28px;
font-size: 18px;
line-height: 1;
}
.drawer-body {
padding: 20px;
overflow-y: auto;
flex: 1;
font-size: 13px;
}
.drawer-body h4 {
margin: 20px 0 8px 0;
font-size: 11px;
text-transform: uppercase;
letter-spacing: 0.04em;
color: var(--fg-dim);
}
.drawer-body h4:first-child { margin-top: 0; }
.drawer-body dl {
display: grid;
grid-template-columns: max-content 1fr;
gap: 4px 12px;
margin: 0;
}
.drawer-body dt { color: var(--fg-dim); }
.drawer-body dd { margin: 0; font-variant-numeric: tabular-nums; }
.drawer-body ul { margin: 0; padding-left: 18px; }
.drawer-body code {
font-family: ui-monospace, "SF Mono", Menlo, Consolas, monospace;
font-size: 11px;
background: var(--bg-elev-2);
padding: 2px 4px;
border-radius: 3px;
}
.widget-toolbar {
display: flex;
gap: 6px;
margin-bottom: 12px;
flex-wrap: wrap;
}
.widget-toolbar .wt-btn {
background: var(--bg-elev-2);
color: var(--fg-dim);
border: 1px solid var(--border);
border-radius: 4px;
padding: 4px 12px;
cursor: pointer;
font-size: 12px;
font-family: inherit;
}
.widget-toolbar .wt-btn:hover { border-color: var(--accent); color: var(--fg); }
.widget-toolbar .wt-btn.active {
background: rgba(46, 164, 79, 0.12);
color: var(--accent);
border-color: var(--accent);
}
/* Theme toggle styling now comes from DaisyUI (`btn btn-ghost`
+ `swap swap-rotate`); only the navbar push-right behaviour
is preserved here so the label still sits at the far end. */
header label.swap { margin-left: auto; }
/* Light mode — applied when `data-theme="light"` is set on <html>. */
html[data-theme="light"] {
--bg: #fafafa;
--bg-elev: #ffffff;
--bg-elev-2: #f1f1f1;
--fg: #1a1a1a;
--fg-dim: #6a6a6a;
--accent: #2ea44f;
--accent-warn: #c97600;
--accent-danger: #b53935;
--border: #e0e0e0;
/* Light-theme sunburst rings: lift the saturated dark-greens
off the elevated card so they're still distinguishable on a
light background. Leaf-label color held constant — the leaf
fill is the heatmap (yellow→red), not the theme. */
--xray-ring-1: #5c8a6a;
--xray-ring-2: #8fb59c;
--xray-ring-label: #1a1a1a;
/* Sankey labels and treemap leaf labels need to be readable on
dark / saturated chart fills regardless of theme. Sankey
labels stay light (dark theme keeps `#e6e6e6`-equivalent
contrast; light-theme labels darken to match the rendered
text on adjacent cards). Treemap labels stay white — the
tile fill is saturated heat-ramp orange/red where dark text
falls below WCAG AA. */
--label-on-dark: #1a1a1a;
--label-on-saturated: #ffffff;
/* Friction calendar ramp re-tuned for light backgrounds — the
dark-mode `#1a4a2c` low end disappeared against `#fafafa`.
The new low end is a desaturated mint that reads as
"present but cool"; the high end mirrors the dark-mode red
(saturation high enough to read on white). */
--heatmap-1: #c8e6c9;
--heatmap-2: #66bb6a;
--heatmap-3: #43a047;
--heatmap-4: #ef6c00;
--heatmap-5: #c62828;
/* Author palette: same hue family as dark mode, slightly
deepened so colors don't wash out on a white background. */
--chart-palette-1: #3d7d4f;
--chart-palette-2: #2ea44f;
--chart-palette-3: #4caf50;
--chart-palette-4: #ef6c00;
--chart-palette-5: #c62828;
--chart-palette-6: #8e24aa;
--chart-palette-7: #1976d2;
--chart-palette-8: #0097a7;
--chart-palette-9: #a36500;
--chart-palette-10: #757575;
--chart-palette-11: #b71c1c;
--chart-palette-12: #2e7d32;
--chart-palette-13: #6a4a00;
--chart-palette-14: #303f9f;
--chart-palette-15: #ad1457;
}
/* Health-trend: the overlay chart host needs an explicit height so
ECharts doesn't render into a 0px container (the parent widget
min-height does not propagate into block children). */
#ht-charts { height: 320px; }
/* Split-view small-multiple panels. Taller than the old 130px so
y-axis labels and the title don't overlap the plot area. */
.ht-sm { height: 180px; margin-bottom: 4px; }
footer {
padding: 20px 28px;
color: var(--fg-dim);
font-size: 12px;
text-align: center;
border-top: 1px solid var(--border);
}
footer a {
color: var(--accent);
text-decoration: none;
}
.delivery-table { width: 100%; border-collapse: collapse; font-size: 13px; }
.delivery-table td { padding: 4px 8px; vertical-align: top; }
.delivery-table td:first-child { color: var(--fg-dim); white-space: nowrap; }
.delivery-value { font-variant-numeric: tabular-nums; text-align: right; }
.delivery-caveat { color: var(--fg-dim); font-size: 11px; }
.delivery-friction-header { margin-top: 8px; font-size: 12px; color: var(--fg-dim); }
.delivery-friction-list { margin: 4px 0 0 16px; font-size: 12px; }
.delivery-disclaimer { margin-top: 8px; font-size: 11px; color: var(--fg-dim); font-style: italic; }
</style>
</head>
<body x-data>
<!-- `x-data` (empty) on <body> scopes the entire page as one Alpine
component so every descendant directive (x-text / x-show /
x-for / x-if / x-model) sees the global stores. Alpine 3
processes directives only inside an x-data root; without this,
the keyboard-accessible file list, off-boarding dropdown, and
theme bindings are silently inert. Empty value = no local
reactive data, just a scope marker. -->
<!-- DaisyUI `navbar` provides the horizontal flex layout + spacing
tokens; the existing semantic `header { ... }` block in the
inline <style> still wins on background-color / border-color
for stylistic continuity. -->
<header class="navbar">
<h1>{{TITLE}}</h1>
<div class="meta">
<span>{{REPO_PATH}}</span>
·
<span>generated {{GENERATED_AT}}</span>
</div>
<!-- DaisyUI `swap-rotate` between a sun and a moon. The hidden
checkbox is the actual control — Alpine `x-model` binds its
`checked` state to the persisted `$store.theme.isDark`
boolean. An `Alpine.effect` in the store registration script
syncs the boolean to the document's `data-theme` attribute,
which DaisyUI's CSS reads to swap palette variables.
Aria label substitutes for the previous on-screen text. -->
<label class="swap swap-rotate btn btn-ghost btn-sm"
title="Toggle light / dark theme"
aria-label="Toggle dark theme">
<!-- `class="theme-controller" value="dark"` engages DaisyUI's
CSS-only theme swap via `:has(.theme-controller[value=dark]:checked)`
so the theme flips visually even if Alpine fails to load —
defense in depth around the `Alpine.effect` that also sets
`data-theme` reactively. -->
<input type="checkbox" class="theme-controller" value="dark"
x-data x-model="$store.theme.isDark">
<!-- swap-on: rendered when checked (dark mode active) → moon -->
<svg class="swap-on h-4 w-4" xmlns="http://www.w3.org/2000/svg"
viewBox="0 0 24 24" fill="none" stroke="currentColor"
stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
<path d="M21 12.79A9 9 0 1 1 11.21 3 7 7 0 0 0 21 12.79z"/>
</svg>
<!-- swap-off: rendered when unchecked (light mode active) → sun -->
<svg class="swap-off h-4 w-4" xmlns="http://www.w3.org/2000/svg"
viewBox="0 0 24 24" fill="none" stroke="currentColor"
stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
<circle cx="12" cy="12" r="4"/>
<path d="M12 2v2M12 20v2M4.93 4.93l1.41 1.41M17.66 17.66l1.41 1.41M2 12h2M20 12h2M4.93 19.07l1.41-1.41M17.66 6.34l1.41-1.41"/>
</svg>
</label>
</header>
<!-- Sticky section nav. One chip per `.dash-group` below; a click
scrolls its target into view (`scrollToDashSection`,
00_setup_boot.js) honoring `prefers-reduced-motion`, and NEVER
touches `location.hash` — the SPA owns the hash as its state
serializer (see `readUrlIntoStores`/`writeStoresToUrl` further
down). `initDashNav` (called once at boot end) wires the clicks
and runs a single `IntersectionObserver` over the six sections to
highlight the chip of whichever one is currently in view. Sits as
a sibling of `<header>`, not inside `<main>`, so it stays
full-width and independent of the dashboard grid. -->
<nav id="dash-nav" aria-label="Dashboard sections">
<button type="button" class="dash-nav-chip btn btn-xs btn-ghost dash-active" data-target="group-overview">Overview</button>
<button type="button" class="dash-nav-chip btn btn-xs btn-ghost" data-target="group-hotspots">Hotspots & Risk</button>
<button type="button" class="dash-nav-chip btn btn-xs btn-ghost" data-target="group-code-health">Code Health</button>
<button type="button" class="dash-nav-chip btn btn-xs btn-ghost" data-target="group-architecture">Architecture</button>
<button type="button" class="dash-nav-chip btn btn-xs btn-ghost" data-target="group-knowledge">Knowledge</button>
<button type="button" class="dash-nav-chip btn btn-xs btn-ghost" data-target="group-delivery">Delivery</button>
</nav>
<!-- Dashboard layout: six titled sections (`.dash-group`), each
with its own grid (`.dash-group-grid`), replacing the old flat
widget wall. Below 1280px every widget spans the full row —
one chart per line, which is what laptop widths need most.
At 1280px and above each section's grid becomes two columns;
the bundled `xl:col-span-2` utility makes wide cards span
both, while the remaining widgets pair up within their
section. `.dash-group-grid` is hand-written (see the CSS
block above) since the pre-built Tailwind bundle is frozen —
no CSS rebuild is needed for layout changes. Each heading row
(`.dash-group-head`) carries a `.dash-collapse` chevron button
(`aria-controls` pointing at the section's grid id) that
`initDashCollapse` (00_setup_boot.js) wires to toggle the
section closed/open; sections always render expanded. -->
<main class="mx-auto p-7 dashboard-main">
<section id="group-overview" class="dash-group" aria-labelledby="group-overview-h">
<div class="dash-group-head">
<h2 id="group-overview-h" class="dash-group-title">Overview</h2>
<button type="button" class="dash-collapse" aria-expanded="true" aria-controls="group-overview-grid" aria-label="Toggle Overview section">
<svg viewBox="0 0 24 24" width="16" height="16" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M6 9l6 6 6-6"/></svg>
</button>
</div>
<div class="dash-group-grid" id="group-overview-grid">
<!-- Four-factor header: Code / Architecture / Knowledge / Delivery.
Spans the full dashboard width (xl:col-span-2). Hidden via CSS
when empty (JS sets display:none on the container when
data.factors is absent or empty). -->
<section class="widget card bg-base-200 shadow-lg xl:col-span-2 wide-widget" id="widget-factor-header">
<h3>Quality dimensions</h3>
<div class="subtitle">
Four headline scores (0–100, higher = healthier) summarising the
repo's Code, Architecture, Knowledge, and Delivery dimensions.
The bullet bar shows the current score against the healthy (green)
and warning (yellow) thresholds. The sparkline shows the sampled
historical trend. The "Attention" chip appears when the
Shewhart XmR chart signals a statistical excursion or sustained run.
</div>
<div id="widget-factor-header-body" class="widget-body auto-height" style="min-height: 80px;"></div>
</section>
<section class="widget card bg-base-200 shadow-lg xl:col-span-2" id="widget-kpi-tiles">
<h3>Codebase at a glance</h3>
<div class="subtitle">
Summary metrics across the repo. KPI cards are computed at
ingest time using deterministic published formulas — click
any value to inspect its derivation in the report sidecar.
</div>
<details class="learn-more">
<summary>Learn more — how to read this panel</summary>
<div class="learn-more-content">
<p><strong>What it measures.</strong> Top-line repo health metrics computed at ingest from the full git history and HEAD-time code scans: file count, contributor count, total churn, complexity peaks, and a handful of composite indicators. Every number is deterministic and reproducible from the commit SHA — no sampling, no estimation.</p>
<p><strong>How to read it.</strong> Each tile is one metric with the current value and a short qualifier. KPIs are snapshots, not trends — for trends, scroll to the Trends, Commit activity, or Delivery risk panels below.</p>
<p><strong>What to watch for.</strong> Disproportions: high churn with very few contributors hints at bus-factor risk. Many files but low complexity peaks usually means small, single-purpose modules (good). A small number of files with extreme complexity = monolith risk.</p>
<p><strong>Suggested action.</strong> Use the tiles as orientation. Any anomalous value is a breadcrumb into the deeper panels — pull the thread there.</p>
</div>
</details>
<div id="widget-kpi-tiles-body" class="kpi-grid"></div>
</section>
<section class="widget card bg-base-200 shadow-lg xl:col-span-2 wide-widget" id="widget-guided-tour" aria-label="Guided analysis tour">
<h3>Guided tour</h3>
<div class="subtitle">
A 4-step walk through the hero map — from code health to refactoring targets.
Each step sets the circle-pack colour lens and brushes the relevant files.
</div>
<details class="learn-more">
<summary>Learn more</summary>
<p><strong>What it does.</strong> The martini-glass tour narrows focus progressively: start with the full health picture, then zoom into hotspots, then find where effort is wasted, then surface the top refactoring candidates.</p>
<p><strong>How to use it.</strong> Click <em>Start tour</em> to begin. Use <em>Next</em> / <em>Prev</em> or the numbered chips to navigate. The circle-pack colour mode and brush update automatically at each step (entering the tour clears any active brush). Click <em>Exit</em> or finish the last step to return to free-form exploration.</p>
<p><strong>Colour modes used.</strong> Steps 1 and 4 use the <em>Code health</em> lens; step 2 uses <em>Cognitive complexity</em>; step 3 uses the <em>Friction</em> heat-ramp. Step 4 additionally brushes the top-10 hotspot files across all widgets.</p>
</details>
<div id="widget-guided-tour-body" class="widget-body auto-height" style="min-height: 48px;"></div>
</section>
<section class="widget card bg-base-200 shadow-lg xl:col-span-2 wide-widget" id="widget-hotspot-circle-pack">
<h3>Hotspots</h3>
<div class="subtitle">
Files sized by churn (revisions). Toggle the colour mapping
across the behavioural lenses: <b>complexity</b> (cognitive
yellow→red), <b>code health</b> (DaisyUI 3-band), <b>tech-debt
friction</b> (Tornhill 2018 score), <b>knowledge map</b>
(primary author), <b>AI attribution</b>, and <b>clones</b>
(Type-1/Type-2 structural duplication). Files in the top
quartile of hotspot score wear a yellow ring overlay.
</div>
<details class="learn-more">
<summary>Learn more — how to read this panel</summary>
<div class="learn-more-content">
<p><strong>What it measures.</strong> Behavioural pressure across the codebase. Circle size encodes <em>churn</em> (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.</p>
<p><strong>How to read it.</strong> 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.</p>
<p><strong>What to watch for.</strong> 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 <em>Knowledge loss</em> mode after picking off-boarders to see which circles turn red under attrition.</p>
<p><strong>Suggested action.</strong> 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.</p>
<p><cite>A. Tornhill 2018, <em>Software Design X-Rays</em>; cognitive complexity per SonarSource 2018.</cite></p>
</div>
</details>
<!-- Offboarding scenario picker. DaisyUI `dropdown`
+ native `<details>` for keyboard-accessible
open/close (no JS needed). Multi-select via
per-author checkboxes bound to `$store.scenario`.
Empty `available` list (no entity_ownership data,
older fixtures) collapses to a helpful message instead
of an empty menu. -->
<div class="flex flex-wrap gap-2 items-center mb-2">
<details class="dropdown">
<summary class="btn btn-sm btn-outline" aria-haspopup="listbox">
Simulate off-boarding
<span class="badge badge-sm badge-warning ml-1"
x-show="$store.scenario.departed.length > 0"
x-text="$store.scenario.departed.length"></span>
</summary>
<div class="dropdown-content menu menu-sm bg-base-100 rounded-box shadow-md p-2 z-10 max-h-80 overflow-y-auto w-72"
role="listbox" aria-multiselectable="true">
<template x-if="$store.scenario.available.length === 0">
<li><span class="opacity-60 px-2 py-1 text-xs">No author data available.</span></li>
</template>
<template x-for="author in $store.scenario.available" :key="author">
<li>
<label class="flex items-center gap-2 px-2 py-1 cursor-pointer">
<input type="checkbox" class="checkbox checkbox-sm"
:checked="$store.scenario.isDeparted(author)"
@change="$store.scenario.toggle(author)" />
<span class="truncate" x-text="author"></span>
</label>
</li>
</template>
</div>
</details>
<!-- Clear-scenario button lifted OUT of the dropdown so the
list height stays stable as users tick / untick authors
(previously the conditional Clear link appearing in the
dropdown footer shifted the layout each time). Sits
next to the "Simulate off-boarding" button as a small
ghost button, only visible when there are actual
departures to clear. -->
<button type="button" class="btn btn-sm btn-ghost"
x-show="$store.scenario.departed.length > 0"
@click="$store.scenario.clear()"
aria-label="Clear off-boarding scenario">
✕ Clear
</button>
</div>
<!-- Ownership-cap note. The entity-ownership embed is capped to the
top-N hotspot files to bound the report size; when that cap drops a
displayable file's ownership the knowledge-map lens, off-boarding
picker, and drawer contributor lists cover only the retained files.
Populated at boot from data.entity_ownership_cap — hidden when the
full set fit. -->
<p id="ownership-cap-note" class="text-xs opacity-60 mb-2" hidden></p>
<!-- DaisyUI `tabs tabs-boxed` accommodates the `health` /
`friction` / `knowledge-loss` modes cleanly and theme-
adapts automatically via DaisyUI's `--color-base-*`
tokens. Tailwind v4 sees every variant literal here so the
`@source` scanner keeps `tab` / `tab-active` in the
bundle. -->
<!-- Tabs use the existing `tooltip-host` / `tooltip-trigger` /
`tooltip-popup` convention (see CSS block above). The
`?` trigger is a `<span>` (not a button) because nested
buttons are invalid HTML — the parent `.tab` is the
clickable element. -->
<div role="tablist" class="tabs tabs-boxed" id="hotspot-color-toggles">
<button type="button" role="tab" data-mode="bivariate" class="tab tab-active tooltip-host" aria-selected="true">
<span aria-hidden="true">▦</span> Health×Activity
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Bivariate map: code-health band (green→red) × development activity (low→high) in one glyph. The darkest cells are unhealthy AND churning — refactor there first. No lens swap needed.</span>
</button>
<button type="button" role="tab" data-mode="cognitive" class="tab tooltip-host" aria-selected="false">
Complexity
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Cognitive complexity per file: yellow (low) → red (high). Counts nested decisions and control-flow breaks — how hard the code is to reason about.</span>
</button>
<button type="button" role="tab" data-mode="health" class="tab tooltip-host" aria-selected="false">
Code health
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">3-band code-health score: green ≥71 (healthy), yellow 41–70 (warning), red ≤40 (critical). Composite of complexity, duplication, and structural smells.</span>
</button>
<button type="button" role="tab" data-mode="friction" class="tab tooltip-host" aria-selected="false">
Tech-debt friction
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Tornhill 2018 tech-debt friction: how expensive each file is to change, weighted by churn × complexity × low-coverage proxies.</span>
</button>
<button type="button" role="tab" data-mode="author" class="tab tooltip-host" aria-selected="false">
Knowledge map
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Each file coloured by its primary author. Large monochrome regions = single-developer ownership (silo risk).</span>
</button>
<button type="button" role="tab" data-mode="ai" class="tab tooltip-host" aria-selected="false">
AI attribution
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Files with substantial AI-authored commits (Copilot / Claude / ChatGPT / Cursor — inferred from commit metadata + author patterns).</span>
</button>
<!-- Knowledge-loss mode: blue = current team, red =
code by departed authors per the offboarding scenario
dropdown above. Auto-pinged from the dropdown when the
user toggles their first author. -->
<button type="button" role="tab" data-mode="knowledge-loss" class="tab tooltip-host" aria-selected="false">
Knowledge loss
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Knowledge loss under your off-boarding scenario: blue = code owned by the current team; red = code primarily authored by the departed authors selected above.</span>
</button>
<!-- Clones overlay: yellow→red ramp on files that appear in
≥ 1 clone family. Files with zero clone groups render
neutral grey, so structural-duplication hotspots pop
visually against the rest of the codebase. -->
<button type="button" role="tab" data-mode="clones" class="tab tooltip-host" aria-selected="false">
Clones
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Structural duplication: yellow→red ramp on files appearing in at least one Type-1 / Type-2 clone family. Grey = no detected clones.</span>
</button>
</div>
<div id="bivariate-legend" class="mt-2" aria-label="Bivariate health × activity legend"></div>
<div id="widget-hotspot-circle-pack-body" class="widget-body"></div>
<!-- Parallel DOM tree — keyboard-accessible alternative for the
canvas circle-pack above. Per WAI-ARIA treeview, canvas
charts have no conformant aria-overlay path; the conformant
pattern is a real DOM tree whose treeitems share the same
activation handler as the canvas click. Collapsed by
default to keep the visual layout clean for mouse users —
opens via `<summary>` (native toggle, no JS), keyboard
activation respects Enter/Space per platform convention. -->
<details class="collapse collapse-arrow bg-base-300 mt-3">
<summary class="collapse-title text-sm font-medium tooltip-host">
Keyboard-accessible file list
(<span x-text="$store.dashboard.hotspots.length"></span>)
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">A screen-reader-friendly textual alternative to the canvas circle-pack above. Same top-50 hotspot files, browsable with arrow keys and selectable with Enter / Space. Useful for WAI-ARIA accessibility and for users who prefer scanning a list to clicking circles. Each row shows the path plus a colour-coded composite code-health badge — the same red/yellow/green bands as the health-lens map above.</span>
</summary>
<div class="collapse-content">
<menu role="tree" aria-label="Hotspot files"
class="menu menu-sm menu-vertical w-full">
<template x-if="$store.dashboard.hotspots.length === 0">
<li><span class="opacity-60 px-2 py-1">No hotspot data loaded.</span></li>
</template>
<template x-for="(file, fileIdx) in $store.dashboard.hotspots" :key="file.path">
<li role="none">
<a role="treeitem" :tabindex="fileIdx === 0 ? '0' : '-1'"
class="flex items-center justify-between gap-2 ki-row-link"
:class="file.primary_author && $store.scenario.departed.includes(file.primary_author)
? 'ki-row-departed'
: ''"
@click="window._codeloreShowDetail && window._codeloreShowDetail(file.path)"
@keydown.enter.prevent="window._codeloreShowDetail && window._codeloreShowDetail(file.path)"
@keydown.space.prevent="window._codeloreShowDetail && window._codeloreShowDetail(file.path)">
<span class="truncate" x-text="file.path"></span>
<!-- Knowledge-loss flag — appears reactively when the
file's primary author is in `$store.scenario.departed`.
Mirrors the canvas circle-pack's red tint under
the off-boarding scenario so the keyboard surface
carries the same signal. Uses hand-written CSS
classes (.ki-row-departed, .ki-knowledge-loss-badge)
since arbitrary Tailwind classes added after the
last `tailwindcss` run aren't in the inlined bundle. -->
<span x-show="file.primary_author && $store.scenario.departed.includes(file.primary_author)"
class="ki-knowledge-loss-badge">
knowledge-loss
</span>
<!-- Composite code-health badge — coloured by the file's
code-health band (red/yellow/green) from
data.code_health, the SAME source the canvas health
lens and bivariate legend key off, so this keyboard
surface tells the identical story rather than the
over-optimistic one the [60,100]-bounded
cognitive_health proxy gave. Badge text is the composite
health score (0-100), pairing colour and number from
one source the way the detail drawer does. DaisyUI
semantic classes are complete literals so Tailwind v4
@source sees them; a path with no composite row badges
as "no data". -->
<span class="badge badge-sm flex-shrink-0"
:class="file.code_health_band == null ? 'badge-ghost'
: file.code_health_band === 'red' ? 'badge-error'
: file.code_health_band === 'yellow' ? 'badge-warning'
: 'badge-success'"
x-text="file.code_health_score != null ? file.code_health_score.toFixed(0) : '?'">
</span>
</a>
</li>
</template>
</menu>
</div>
</details>
</section>
</div>
</section>
<section id="group-hotspots" class="dash-group" aria-labelledby="group-hotspots-h">
<div class="dash-group-head">
<h2 id="group-hotspots-h" class="dash-group-title">Hotspots & Risk</h2>
<button type="button" class="dash-collapse" aria-expanded="true" aria-controls="group-hotspots-grid" aria-label="Toggle Hotspots & Risk section">
<svg viewBox="0 0 24 24" width="16" height="16" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M6 9l6 6 6-6"/></svg>
</button>
</div>
<div class="dash-group-grid" id="group-hotspots-grid">
<section class="widget card bg-base-200 shadow-lg xl:col-span-2 wide-widget" id="widget-hotspot-table">
<h3>Hotspot table</h3>
<div class="subtitle">
Sortable drill-down view of every hotspot row. Click a column
header to sort. Type to filter by path.
</div>
<details class="learn-more">
<summary>Learn more — how to read this panel</summary>
<div class="learn-more-content">
<p><strong>What it measures.</strong> The full hotspot list as a sortable, filterable table. One row per file with every behavioural metric the dashboard computes — revisions, cognitive complexity, cognitive health, hotspot score, primary author, AI attribution, MI rank, contributors.</p>
<p><strong>How to read it.</strong> 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.</p>
<p><strong>What to watch for.</strong> 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.</p>
<p><strong>Suggested action.</strong> Sort by hotspot score descending, copy the top-N paths into your sprint board, and refactor by priority.</p>
</div>
</details>
<div class="table-controls">
<input
type="text"
id="hotspot-table-filter"
class="input input-bordered input-sm"
placeholder="filter paths…"
autocomplete="off"
spellcheck="false"
aria-label="Filter hotspots by path">
<span class="table-summary" id="hotspot-table-summary" role="status" aria-live="polite"></span>
<span class="table-actions" id="hotspot-table-actions"></span>
</div>
<div id="widget-hotspot-table-body" class="table-container"></div>
</section>
<!-- Treemap alternative view to the circle-pack. Same
`hotspots` data, rendered as nested rectangles. Strict
area encoding (cognitive complexity × revisions); useful
when size differences need to read exactly rather than
perceptually-via-circle-area. -->
<section class="widget card bg-base-200 shadow-lg xl:col-span-2 wide-widget" id="widget-hotspot-treemap">
<h3>Hotspots — treemap view</h3>
<div class="subtitle">
Same data as the circle-pack above, rendered as nested
rectangles for strict area-comparison readability.
</div>
<details class="learn-more">
<summary>Learn more — how to read this panel</summary>
<div class="learn-more-content">
<p><strong>What it measures.</strong> The same hotspot data as the circle-pack above, rendered as nested rectangles. Area encodes cognitive complexity × revisions; colour encodes the active hotspot lens.</p>
<p><strong>How to read it.</strong> 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 <em>compare</em> sizes precisely.</p>
<p><strong>What to watch for.</strong> 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.</p>
<p><strong>Suggested action.</strong> 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.</p>
</div>
</details>
<div id="widget-hotspot-treemap-body" class="widget-body" style="height: 320px;"></div>
</section>
<section class="widget card bg-base-200 shadow-lg xl:col-span-2 wide-widget" id="widget-xray-sunburst">
<h3>Function X-Ray</h3>
<div class="subtitle">
Function-level cognitive complexity. Inner ring = top-level
path segment; outer = function. Click any wedge to drill down.
Top 500 functions by cognitive complexity.
</div>
<details class="learn-more">
<summary>Learn more — how to read this panel</summary>
<div class="learn-more-content">
<p><strong>What it measures.</strong> 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.</p>
<p><strong>How to read it.</strong> 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.</p>
<p><strong>What to watch for.</strong> 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 <em>and</em> the same file appearing high in the Hotspot list (frequent churn on a complex function).</p>
<p><strong>Suggested action.</strong> 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.</p>
</div>
</details>
<div id="widget-xray-sunburst-body" class="widget-body"></div>
</section>
</div>
</section>
<section id="group-code-health" class="dash-group" aria-labelledby="group-code-health-h">
<div class="dash-group-head">
<h2 id="group-code-health-h" class="dash-group-title">Code Health</h2>
<button type="button" class="dash-collapse" aria-expanded="true" aria-controls="group-code-health-grid" aria-label="Toggle Code Health section">
<svg viewBox="0 0 24 24" width="16" height="16" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M6 9l6 6 6-6"/></svg>
</button>
</div>
<div class="dash-group-grid" id="group-code-health-grid">
<section class="widget card bg-base-200 shadow-lg xl:col-span-2 wide-widget" id="widget-health-trend">
<h3>Repo health timeline</h3>
<div class="subtitle">
Combined, architectural, and code health (0–100) recomputed at
sampled historical commits. Shows whether overall repo health is
improving or degrading over time.
</div>
<details class="learn-more">
<summary>Learn more — how to read this panel</summary>
<div class="learn-more-content">
<p><strong>What it measures.</strong> 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.</p>
<p><strong>How to read it.</strong> 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.</p>
<p><strong>What to watch for.</strong> 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.</p>
<p><strong>Suggested action.</strong> If architectural health is declining, run <code>--analysis dependency-cycles</code> to find the tangles introduced at the inflection point. If code health is declining, the Hotspot table will show which files are driving it.</p>
</div>
</details>
<div id="widget-health-trend-body" class="widget-body" style="min-height: 340px;"></div>
</section>
<section class="widget card bg-base-200 shadow-lg xl:col-span-2 wide-widget" id="widget-trends">
<h3>Trends</h3>
<div class="subtitle">
Monthly revision counts for the top-10 hotspot files.
Pattern shows where churn is intensifying or cooling off.
</div>
<details class="learn-more">
<summary>Learn more — how to read this panel</summary>
<div class="learn-more-content">
<p><strong>What it measures.</strong> 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).</p>
<p><strong>How to read it.</strong> 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.</p>
<p><strong>What to watch for.</strong> 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.</p>
<p><strong>Suggested action.</strong> Cross-reference a high-churn file against the <em>Code health</em> and <em>Complexity</em> colour modes in the Hotspot circle-pack — high churn + high complexity is the classic hotspot signature.</p>
</div>
</details>
<!-- Top-N selector: picks how many of the highest-pressure
files render as polylines. Persisted via
`$store.layout.trendsTopN`; backend sends up to 50 so
the user can widen without a re-run. -->
<div role="tablist" class="tabs tabs-boxed mb-2" aria-label="Trends top N files">
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.trendsTopN === 5 && 'tab-active'"
:aria-selected="$store.layout.trendsTopN === 5 ? 'true' : 'false'"
@click="$store.layout.trendsTopN = 5">
5
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Render only the top-5 hotspot files. Cleanest signal — useful when you want to see the dominant trajectories without polyline soup.</span>
</button>
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.trendsTopN === 10 && 'tab-active'"
:aria-selected="$store.layout.trendsTopN === 10 ? 'true' : 'false'"
@click="$store.layout.trendsTopN = 10">
10
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Default — top-10 hotspot files. Best balance of coverage and readability for most repos.</span>
</button>
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.trendsTopN === 20 && 'tab-active'"
:aria-selected="$store.layout.trendsTopN === 20 ? 'true' : 'false'"
@click="$store.layout.trendsTopN = 20">
20
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Top-20 — more breadth but lines start to overlap; lean on hover-to-isolate to read individual files.</span>
</button>
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.trendsTopN === 'all' && 'tab-active'"
:aria-selected="$store.layout.trendsTopN === 'all' ? 'true' : 'false'"
@click="$store.layout.trendsTopN = 'all'">
All
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">All 50 paths the backend sent — busy, but legend-click-to-isolate makes it scannable. Use for triage when you don't yet know which files to focus on.</span>
</button>
</div>
<div id="widget-trends-body" class="widget-body"></div>
</section>
<!-- Code Health share bars + effort dot strip (A.5).
Two 100%-stacked horizontal bars: LOC share and churn share per
code-health band; plus a 20-dot effort strip (each dot = 5%
churn). Pure HTML/CSS — no ECharts. Driven by effort_exposure. -->
<section class="widget card bg-base-200 shadow-lg xl:col-span-2 wide-widget" id="widget-share-bars">
<h3>Code Health — effort distribution</h3>
<div class="subtitle">
Where engineering effort lands across red / yellow / green health
bands. A team with most churn in red code is in reactive mode;
most churn in green means proactive maintenance.
</div>
<details class="learn-more">
<summary>Learn more — how to read this panel</summary>
<div class="learn-more-content">
<p><strong>What it measures.</strong> 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.</p>
<p><strong>How to read it.</strong> 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.</p>
<p><strong>What to watch for.</strong> Red churn share consistently above 40% indicates a reactive maintenance pattern. Improving = churn shifting toward green over successive sprints.</p>
<p><strong>Suggested action.</strong> Prioritise the top hotspots with red health for refactoring investment to reduce the cost of future changes there.</p>
</div>
</details>
<div id="widget-share-bars-body" class="widget-body auto-height" style="min-height: 80px;"></div>
</section>
<!-- Improvements feed: recent band transitions (regressions ↓ /
improvements ↑) surfaced from the per-file health series. Each
entry is a clickable path for linked-brushing into the drawer. -->
<section class="widget card bg-base-200 shadow-lg" id="widget-improvements-feed">
<h3>Health improvements & regressions</h3>
<div class="subtitle">
Signal-bearing code-health band transitions detected across sampled
historical commits. Click any file to open its detail drawer.
</div>
<div id="widget-improvements-feed-body" class="widget-body auto-height" style="min-height: 120px;"></div>
</section>
<!-- Boxplot of cognitive complexity distribution across all
files. Quartiles + outliers in one glance — answers "how
lopsided is the cognitive tail?". -->
<section class="widget card bg-base-200 shadow-lg" id="widget-cognitive-boxplot">
<h3>Cognitive distribution</h3>
<div class="subtitle">
How hard each file is to reason about, across the whole
codebase. Cognitive complexity counts nested decisions and
control-flow disruptions — lower = easier to read.
Box-and-whisker shows median + middle 50%; outlier count and
max sit in the top-right corner.
</div>
<details class="learn-more">
<summary>Learn more — how to read this panel</summary>
<div class="learn-more-content">
<p><strong>What it measures.</strong> The distribution of cognitive complexity across every file with a measured score. Cognitive complexity counts nested decisions, breaks, and control-flow disruptions — it tracks "how hard is this to reason about" more faithfully than cyclomatic complexity does.</p>
<p><strong>How to read it.</strong> The box spans Q1 to Q3 (the middle 50% of files). The line inside the box is the median. Whiskers extend to ±1.5 × IQR; the y-axis is clipped to that range so the box dominates the chart. The "+N outliers · max V" annotation in the top-right tells you how many files exceed the upper whisker and what the worst case is.</p>
<p><strong>What to watch for.</strong> A short box with a high outlier count is a long-tail problem: most files are fine but a handful are pathological. The bigger the gap between the upper whisker and the annotated max, the more lopsided your complexity tail is.</p>
<p><strong>Suggested action.</strong> Open the Hotspot table sorted by cognitive descending. The first five to ten rows usually own most of the right-tail; refactoring those alone moves the median significantly.</p>
<p><cite>G. A. Campbell, <em>Cognitive Complexity — A new way of measuring understandability</em>, SonarSource white paper 2018.</cite></p>
</div>
</details>
<div id="widget-cognitive-boxplot-body" class="widget-body" style="height: 220px;"></div>
</section>
<!-- Parallel coordinates over the top-20 hotspots. Each file
is one polyline crossing 5 axes: revisions / cognitive /
cognitive-health / hotspot-score / MI. Hover a polyline to see
the file path; drag-select on any axis to filter the
visible set (ECharts native). Power-user analytical tool —
surfaces files that are outliers on multiple axes
simultaneously. -->
<section class="widget card bg-base-200 shadow-lg xl:col-span-2 wide-widget" id="widget-parallel-coords">
<h3>Multi-metric comparison</h3>
<div class="subtitle">
Top-20 hotspots across five behavioural axes. Drag on any
axis to filter — useful for "files high on cognitive AND
low on MI" cross-cuts.
</div>
<details class="learn-more">
<summary>Learn more — how to read this panel</summary>
<div class="learn-more-content">
<p><strong>What it measures.</strong> The top-20 hotspot files plotted simultaneously across five axes: <strong>Revisions</strong>, <strong>Cognitive</strong> complexity, <strong>Cognitive health</strong>, <strong>Hotspot score</strong> (composite), and <strong>MI rank</strong> (maintainability percentile). Each polyline is one file.</p>
<p><strong>How to read it.</strong> 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.</p>
<p><strong>What to watch for.</strong> Files that are outliers on <em>multiple</em> 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.</p>
<p><strong>Suggested action.</strong> 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.</p>
<p><cite>A. Inselberg 1985, <em>The plane with parallel coordinates</em>.</cite></p>
</div>
</details>
<!-- Top-N selector: how many hotspots to render as polylines.
Persisted via `$store.layout.parallelTopN`. -->
<div role="tablist" class="tabs tabs-boxed mb-2" aria-label="Multi-metric top N hotspots">
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.parallelTopN === 10 && 'tab-active'"
:aria-selected="$store.layout.parallelTopN === 10 ? 'true' : 'false'"
@click="$store.layout.parallelTopN = 10">
10
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Top-10 — the highest-pressure files only. Easiest to spot multi-axis outliers when the polyline soup is thin.</span>
</button>
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.parallelTopN === 20 && 'tab-active'"
:aria-selected="$store.layout.parallelTopN === 20 ? 'true' : 'false'"
@click="$store.layout.parallelTopN = 20">
20
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Default — top-20 hotspots. Covers most "files high on cognitive AND low on MI" cross-cuts without crowding.</span>
</button>
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.parallelTopN === 50 && 'tab-active'"
:aria-selected="$store.layout.parallelTopN === 50 ? 'true' : 'false'"
@click="$store.layout.parallelTopN = 50">
50
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Top-50 — broad view; use drag-select on individual axes to filter visually.</span>
</button>
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.parallelTopN === 'all' && 'tab-active'"
:aria-selected="$store.layout.parallelTopN === 'all' ? 'true' : 'false'"
@click="$store.layout.parallelTopN = 'all'">
All
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">All hotspot rows. Heavy; the chart works but you'll definitely want axis-drag filtering to extract signal.</span>
</button>
</div>
<div id="widget-parallel-coords-body" class="widget-body" style="height: 320px;"></div>
</section>
</div>
</section>
<section id="group-architecture" class="dash-group" aria-labelledby="group-architecture-h">
<div class="dash-group-head">
<h2 id="group-architecture-h" class="dash-group-title">Architecture</h2>
<button type="button" class="dash-collapse" aria-expanded="true" aria-controls="group-architecture-grid" aria-label="Toggle Architecture section">
<svg viewBox="0 0 24 24" width="16" height="16" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M6 9l6 6 6-6"/></svg>
</button>
</div>
<div class="dash-group-grid" id="group-architecture-grid">
<!-- Architecture force-graph from the resolved import edges.
Shows the actual structural dependency graph alongside the
behavioural coupling sankey above — disagreement between
the two signals is itself signal. -->
<section class="widget card bg-base-200 shadow-lg xl:col-span-2 wide-widget" id="widget-arch-graph">
<h3>Architecture graph</h3>
<div class="subtitle">
Force-directed import graph (Rust + Python + JS/TS) fused with
git history. Nodes are coloured by <em>architectural role</em>
(core / control / shared / periphery); <strong>diamonds</strong>
are unstable interfaces; <strong>ringed</strong> nodes sit in a
dependency cycle. <strong>Solid</strong> edges are imports;
<strong>dashed</strong> edges are <em>modularity violations</em>
(co-change with no import). The title reports the system
<em>propagation cost</em>.
</div>
<details class="learn-more">
<summary>Learn more — how to read this panel</summary>
<div class="learn-more-content">
<p><strong>What it measures.</strong> The structural import graph as resolved from source: Rust <code>use</code>, Python <code>import</code>, JS/TS <code>import</code>. The depth selector below controls how aggressively paths are rolled up into "modules" — <em>Auto</em> deepens until at least 8 distinct nodes surface, fixed numbers force a specific roll-up depth.</p>
<p><strong>How to read it.</strong> Force-directed layout: modules that import each other settle next to each other. <strong>Node colour = architectural role</strong> (Baldwin & MacCormack "hidden structure", from transitive reachability): <em>core</em> = the dominant dependency cycle; <em>shared</em> = depended on as widely as the core but depends on little (utilities); <em>control</em> = the inverse (orchestrators); <em>periphery</em> = the healthy leaf bulk. <strong>Diamonds</strong> = unstable interfaces; a <strong>ring</strong> = the module sits in a dependency cycle. <strong>Solid</strong> edges are imports; <strong>dashed</strong> edges are modularity violations (Fisher-significant co-change with <em>no</em> import edge). The title shows <em>propagation cost</em> — the share of the system a random change can reach.</p>
<p><strong>What to watch for.</strong> A large red <em>core</em> means a big tangle everything routes through (hard to change in isolation) — confirm with <code>--analysis dependency-cycles</code>. 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.</p>
<p><strong>Suggested action.</strong> Compare against the Module coupling chord above. <em>Agreement</em> (modules that import each other also change together) = healthy modularity. <em>Disagreement</em> = behaviour bleeds across structural boundaries; root-cause is usually a shared mutable state, a leaky framework, or a contract violated through string-typed APIs.</p>
</div>
</details>
<!-- Aggregation-depth selector. 'Auto' triggers the adaptive
loop (deepens until ≥8 distinct nodes); the numeric
buttons pin a fixed depth. Persisted via Alpine.$persist
on `$store.layout.archGraphDepth`. Mirrors the chord
control above for consistent UX. -->
<div role="tablist" class="tabs tabs-boxed mb-2" aria-label="Architecture graph depth">
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.archGraphDepth === 'auto' && 'tab-active'"
:aria-selected="$store.layout.archGraphDepth === 'auto' ? 'true' : 'false'"
@click="$store.layout.archGraphDepth = 'auto'">
Auto
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Adaptive: deepen until at least 8 nodes surface. Default — keeps the force layout informative for small and large repos alike.</span>
</button>
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.archGraphDepth === 2 && 'tab-active'"
:aria-selected="$store.layout.archGraphDepth === 2 ? 'true' : 'false'"
@click="$store.layout.archGraphDepth = 2">
2
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Aggregate to 2 path segments (e.g. <code>app/services</code>). Coarse architectural view.</span>
</button>
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.archGraphDepth === 3 && 'tab-active'"
:aria-selected="$store.layout.archGraphDepth === 3 ? 'true' : 'false'"
@click="$store.layout.archGraphDepth = 3">
3
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Aggregate to 3 path segments (e.g. <code>app/services/clients</code>). Feature-area level.</span>
</button>
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.archGraphDepth === 4 && 'tab-active'"
:aria-selected="$store.layout.archGraphDepth === 4 ? 'true' : 'false'"
@click="$store.layout.archGraphDepth = 4">
4
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Aggregate to 4 path segments. Subsystem level — usually the deepest still-readable view.</span>
</button>
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.archGraphDepth === 5 && 'tab-active'"
:aria-selected="$store.layout.archGraphDepth === 5 ? 'true' : 'false'"
@click="$store.layout.archGraphDepth = 5">
5
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Aggregate to 5 path segments. Near file level — many small nodes, useful for fine-grained import audits.</span>
</button>
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.archGraphDepth === 6 && 'tab-active'"
:aria-selected="$store.layout.archGraphDepth === 6 ? 'true' : 'false'"
@click="$store.layout.archGraphDepth = 6">
6
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Aggregate to 6 path segments. Maximum granularity — close to per-file imports.</span>
</button>
</div>
<!-- Layout toggle. 'Force' is the physics layout (good for small
graphs); 'Layered' stacks modules in topological bands so
forward deps flow downward and back-edges (cycles) run back
up — de-hairballs medium graphs. Persisted on
`$store.layout.archGraphLayout`. -->
<div role="tablist" class="tabs tabs-boxed mb-2" aria-label="Architecture graph layout">
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.archGraphLayout === 'force' && 'tab-active'"
:aria-selected="$store.layout.archGraphLayout === 'force' ? 'true' : 'false'"
@click="$store.layout.archGraphLayout = 'force'">
Force
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Physics layout — nodes repel, edges pull. Best for small graphs; large ones hairball.</span>
</button>
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.archGraphLayout === 'layered' && 'tab-active'"
:aria-selected="$store.layout.archGraphLayout === 'layered' ? 'true' : 'false'"
@click="$store.layout.archGraphLayout = 'layered'">
Layered
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Topological bands by architectural level. Forward dependencies flow downward (arrows); back-edges that run upward are dependency cycles / layering violations.</span>
</button>
</div>
<div id="widget-arch-graph-body" class="widget-body" style="height: 380px;"></div>
</section>
<!-- Dependency Structure Matrix: the scalable, layer-ordered view
of the same import graph. Modules ordered by architectural
layer (architecture-roles' topological level); cells = inter-
module imports; below-diagonal red cells = back-edges
(dependency cycles / layering violations). Shares the depth
selector with the force graph above. -->
<section class="widget card bg-base-200 shadow-lg xl:col-span-2 wide-widget" id="widget-arch-matrix">
<h3>Dependency structure matrix</h3>
<div class="subtitle">
The same import graph as a layer-ordered matrix — it scales
where the force graph hairballs. Rows import columns; cells
<strong>below the diagonal (red)</strong> are <em>back-edges</em>:
dependency cycles and layering violations. A clean, acyclic
architecture is a triangular, all-blue matrix. The
<strong>Fusion</strong> toggle (top of the panel) reclassifies
each cell by structure×history agreement against the change-
coupling data — a legend row explains the added colours.
</div>
<details class="learn-more">
<summary>Learn more — how to read this panel</summary>
<div class="learn-more-content">
<p><strong>What it measures.</strong> 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 <code>--analysis architecture-roles</code>.</p>
<p><strong>How to read it (Structure mode, the default).</strong> Each cell <code>(row, col)</code> means "row imports col"; blue intensity = number of imports. Because modules are layer-ordered, healthy forward dependencies fall <em>above</em> the diagonal. A cell <em>below</em> the diagonal is <strong>red</strong> — 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.</p>
<p><strong>Fusion mode.</strong> Click the <strong>Fusion</strong> button to reclassify each above-diagonal cell against change-coupling data (aggregated to the same module depth): <em>agree</em> cells import <em>and</em> co-change (blue, opacity graded by co-change strength); <em>structural only</em> cells import but never co-change (dimmed); <em>co-change only</em> 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.</p>
<p><strong>What to watch for.</strong> Red cells below the diagonal are your cycles / layering violations — cross-reference <code>--analysis dependency-cycles</code>. 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.</p>
</div>
</details>
<div id="widget-arch-matrix-body" class="widget-body" style="height: 460px;"></div>
</section>
<!-- Architecture decay trend: structural-health metrics recomputed
at sampled historical revisions. The HEAD metrics (graph / matrix
above) say how tangled the code is NOW; this says whether it's
getting worse and roughly when it started. -->
<section class="widget card bg-base-200 shadow-lg xl:col-span-2 wide-widget" id="widget-arch-trend">
<h3>Architecture trend</h3>
<div class="subtitle">
Structural health over time — <strong>propagation cost</strong>
(blue, left) and <strong>dependency cycles</strong> (red, right)
recomputed at sampled historical commits. Rising lines mean the
architecture is decaying; a step up in cycles marks when a tangle
first formed.
</div>
<details class="learn-more">
<summary>Learn more — how to read this panel</summary>
<div class="learn-more-content">
<p><strong>What it measures.</strong> 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 (<code>--analysis architecture-trend</code>).</p>
<p><strong>How to read it.</strong> 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.</p>
<p><strong>What to watch for.</strong> Sustained upward drift in either line is architectural decay. Cross-reference the commit dates with the <code>dependency-cycles</code> and <code>architecture-metrics</code> analyses to find the change that introduced a tangle. The final point matches the current HEAD metrics by construction.</p>
</div>
</details>
<div id="widget-arch-trend-body" class="widget-body" style="height: 340px;"></div>
</section>
<!-- Module-to-module chord diagram from the coupling pairs
aggregated by top-level directory. Surfaces cross-module
Conway's-law structure. -->
<section class="widget card bg-base-200 shadow-lg xl:col-span-2" id="widget-module-chord">
<h3>Module coupling</h3>
<div class="subtitle">
Inter-module change-coupling rolled up from the file-pair
graph by top-level directory.
</div>
<details class="learn-more">
<summary>Learn more — how to read this panel</summary>
<div class="learn-more-content">
<p><strong>What it measures.</strong> Change-coupling rolled up to the module level (first N path segments controlled by the depth selector below). Modules A and B are coupled when files in A frequently change in the same commits as files in B. Infrastructure files (lock files, <code>.env*</code>, docs, build manifests) are filtered out — they cluster with every release commit and would otherwise dominate the picture.</p>
<p><strong>How to read it.</strong> Each node on the circle is one module. Chords (curved bands between nodes) represent cross-module change-coupling; thicker bands = stronger historical coupling. Hover a node to highlight its adjacent chords. Use the depth selector below to widen / narrow the aggregation: <em>2</em> = broad architectural modules, <em>6</em> = near file-level subsystems.</p>
<p><strong>What to watch for.</strong> Strong chords between modules that should not be tightly coupled — that is the structural smell. Compare to the Architecture graph below: if two modules are change-coupled but don't import each other, the coupling is implicit (shared utilities, leaky abstractions, contract violations through a third party).</p>
<p><strong>Suggested action.</strong> For each unexpected strong chord, open the Change-coupling sankey to find the top file pair driving it, then ask: is there a missing shared abstraction, or is a contract being violated?</p>
<p><cite>H. Gall, K. Hajek, M. Jazayeri 1998, <em>Detection of logical coupling based on product release history</em>.</cite></p>
</div>
</details>
<!-- Aggregation-depth selector. 'Auto' triggers the adaptive
loop (deepens until ≥6 distinct modules); the numeric
buttons pin a fixed depth. Persisted via Alpine.$persist
on `$store.layout.chordDepth`. The reactive effect in the
inline store-init script fires the rerenderer list when
this changes, so the chord re-paints with the new
aggregation level. Buttons use the same DaisyUI
`tabs tabs-boxed` pattern as the hotspot color modes for
a consistent feel. -->
<div role="tablist" class="tabs tabs-boxed mb-2" aria-label="Module coupling depth">
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.chordDepth === 'auto' && 'tab-active'"
:aria-selected="$store.layout.chordDepth === 'auto' ? 'true' : 'false'"
@click="$store.layout.chordDepth = 'auto'">
Auto
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Adaptive: deepen until at least 6 modules surface. The default — works well for most repos.</span>
</button>
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.chordDepth === 2 && 'tab-active'"
:aria-selected="$store.layout.chordDepth === 2 ? 'true' : 'false'"
@click="$store.layout.chordDepth = 2">
2
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Aggregate to 2 path segments (e.g. <code>app/services</code>). Broad architectural modules.</span>
</button>
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.chordDepth === 3 && 'tab-active'"
:aria-selected="$store.layout.chordDepth === 3 ? 'true' : 'false'"
@click="$store.layout.chordDepth = 3">
3
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Aggregate to 3 path segments (e.g. <code>app/services/clients</code>). Feature-area level.</span>
</button>
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.chordDepth === 4 && 'tab-active'"
:aria-selected="$store.layout.chordDepth === 4 ? 'true' : 'false'"
@click="$store.layout.chordDepth = 4">
4
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Aggregate to 4 path segments. Subsystem level — usually the deepest still-readable view.</span>
</button>
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.chordDepth === 5 && 'tab-active'"
:aria-selected="$store.layout.chordDepth === 5 ? 'true' : 'false'"
@click="$store.layout.chordDepth = 5">
5
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Aggregate to 5 path segments. Near file level — labels start to get long.</span>
</button>
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.chordDepth === 6 && 'tab-active'"
:aria-selected="$store.layout.chordDepth === 6 ? 'true' : 'false'"
@click="$store.layout.chordDepth = 6">
6
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Aggregate to 6 path segments. Granular — file-pair-like view.</span>
</button>
</div>
<div id="widget-module-chord-body" class="widget-body" style="height: 320px;"></div>
</section>
<section class="widget card bg-base-200 shadow-lg xl:col-span-2 wide-widget" id="widget-coupling-sankey">
<h3>Change coupling</h3>
<div class="subtitle">
Files that change together at Fisher-significant rates. Wider
bands = stronger historical coupling. Top 30 pairs by combined
score.
</div>
<!-- Aggregation depth for the sankey. 'Files' is the canonical
file-pair view; numeric depths collapse each pair to N
path segments before re-aggregating, then top-30 the
strongest module-pair edges. Persisted on
`$store.layout.sankeyDepth`. Same convention as the chord
and arch-graph selectors. -->
<div role="tablist" class="tabs tabs-boxed mb-2" aria-label="Change coupling depth">
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.sankeyDepth === 'files' && 'tab-active'"
:aria-selected="$store.layout.sankeyDepth === 'files' ? 'true' : 'false'"
@click="$store.layout.sankeyDepth = 'files'">
Files
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Canonical view: top-30 file-pair couplings, no aggregation. Use when you want the exact file pairs driving co-change.</span>
</button>
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.sankeyDepth === 2 && 'tab-active'"
:aria-selected="$store.layout.sankeyDepth === 2 ? 'true' : 'false'"
@click="$store.layout.sankeyDepth = 2">
2
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Collapse each file pair to its 2-segment module pair (e.g. <code>app/services ↔ app/core</code>), then top-30 by combined <code>shared_revs</code>.</span>
</button>
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.sankeyDepth === 3 && 'tab-active'"
:aria-selected="$store.layout.sankeyDepth === 3 ? 'true' : 'false'"
@click="$store.layout.sankeyDepth = 3">
3
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">3-segment module pairs (e.g. <code>app/services/clients ↔ app/core/db</code>). Feature-area coupling.</span>
</button>
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.sankeyDepth === 4 && 'tab-active'"
:aria-selected="$store.layout.sankeyDepth === 4 ? 'true' : 'false'"
@click="$store.layout.sankeyDepth = 4">
4
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">4-segment subsystem-pair coupling — the deepest still-readable aggregate view.</span>
</button>
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.sankeyDepth === 5 && 'tab-active'"
:aria-selected="$store.layout.sankeyDepth === 5 ? 'true' : 'false'"
@click="$store.layout.sankeyDepth = 5">
5
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">5-segment pairs — close to per-file but with sibling collapse.</span>
</button>
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.sankeyDepth === 6 && 'tab-active'"
:aria-selected="$store.layout.sankeyDepth === 6 ? 'true' : 'false'"
@click="$store.layout.sankeyDepth = 6">
6
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">6-segment pairs — maximum granularity, near file-pair level.</span>
</button>
</div>
<details class="learn-more">
<summary>Learn more — how to read this panel</summary>
<div class="learn-more-content">
<p><strong>What it measures.</strong> 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).</p>
<p><strong>How to read it.</strong> Sankey diagram: source files on the left, target files on the right; each band is one file pair. Band width = strength of the coupling.</p>
<p><strong>What to watch for.</strong> Wide bands between files that <em>don't</em> 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.</p>
<p><strong>Suggested action.</strong> 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.</p>
<p><cite>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, <em>Your Code as a Crime Scene</em>.</cite></p>
</div>
</details>
<div id="widget-coupling-sankey-body" class="widget-body"></div>
</section>
</div>
</section>
<section id="group-knowledge" class="dash-group" aria-labelledby="group-knowledge-h">
<div class="dash-group-head">
<h2 id="group-knowledge-h" class="dash-group-title">Knowledge</h2>
<button type="button" class="dash-collapse" aria-expanded="true" aria-controls="group-knowledge-grid" aria-label="Toggle Knowledge section">
<svg viewBox="0 0 24 24" width="16" height="16" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M6 9l6 6 6-6"/></svg>
</button>
</div>
<div class="dash-group-grid" id="group-knowledge-grid">
<section class="widget card bg-base-200 shadow-lg" id="widget-knowledge-surfaces">
<h3>Knowledge surfaces</h3>
<div class="subtitle">
Team familiarity, knowledge islands ratio, tenure mix, and the
files with the highest coordination overhead — from one
behavioural scan, no manual tagging.
</div>
<details class="learn-more">
<summary>Learn more — how to read this panel</summary>
<div class="learn-more-content">
<p><strong>Familiarity.</strong> Mean team familiarity across active files: the fraction of each file's weighted change history that active authors "own" — averaged over all files touched in the window. Green ≥ 70 %, yellow 40–70 %, red < 40 %.</p>
<p><strong>Islands.</strong> Fraction of active files with no active owner (primary author inactive + no successor). Lower is better. Green ≤ 20 %, yellow 20–40 %, red > 40 %.</p>
<p><strong>Team composition.</strong> Commit share split by tenure bucket: <em>onboarded</em> (< 90 days), <em>experienced</em> (90–364 days), <em>veteran</em> (≥ 365 days). A healthy team shows some onboarding throughput without veteran over-concentration.</p>
<p><strong>Coordination needs.</strong> Top files by co-change coupling tier and entropy. <em>High</em>-tier files are frequently changed together by multiple authors with high authorship interleaving — the strongest coordination signal.</p>
<p><cite>Methodology: knowledge-shares materialized view + coordination-needs entropy; see <code>analyses/code_familiarity.rs</code>, <code>analyses/coordination_needs.rs</code>.</cite></p>
</div>
</details>
<div id="widget-knowledge-surfaces-body"></div>
</section>
<section class="widget card bg-base-200 shadow-lg" id="widget-knowledge-islands">
<h3>Knowledge islands</h3>
<div class="subtitle">
Files whose primary author has departed and where no
substantial other owner exists — auto-detected, no manual
ex-developer marking. CodeScene requires you to mark
ex-developers manually; CodeLore detects them from commit
history + co-change intensity.
</div>
<details class="learn-more">
<summary>Learn more — how to read this panel</summary>
<div class="learn-more-content">
<p><strong>What it measures.</strong> Files whose primary author (typically ≥80% of historical line-changes) has stopped committing <em>and</em> where no other developer has substantial backup ownership. Detection is purely behavioural — there's no manual "ex-developer" tagging required.</p>
<p><strong>How to read it.</strong> One row per orphaned file. The risk score combines code health, complexity, and downstream coupling — the higher the score, the more painful the orphan is.</p>
<p><strong>What to watch for.</strong> Concentration: multiple orphaned files in the same module = an entire subsystem with no clear owner. Critical-path orphans (high hotspot score, low health) at the top of the list are the immediate priorities.</p>
<p><strong>Suggested action.</strong> Pair-program new contributors with the top files; promote the orphan files to the next sprint's documentation push; assign succession owners explicitly so the names move out of this list.</p>
<p><cite>Detection: primary-author share + commit-recency decay + co-change intensity heuristic; see <code>analyses/knowledge_islands.rs</code>.</cite></p>
</div>
</details>
<div id="widget-knowledge-islands-body" class="table-container"></div>
</section>
</div>
</section>
<section id="group-delivery" class="dash-group" aria-labelledby="group-delivery-h">
<div class="dash-group-head">
<h2 id="group-delivery-h" class="dash-group-title">Delivery</h2>
<button type="button" class="dash-collapse" aria-expanded="true" aria-controls="group-delivery-grid" aria-label="Toggle Delivery section">
<svg viewBox="0 0 24 24" width="16" height="16" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M6 9l6 6 6-6"/></svg>
</button>
</div>
<div class="dash-group-grid" id="group-delivery-grid">
<!-- Delivery card: compact KPI card for delivery-metrics, release-cadence,
and delivery-friction. Degrades gracefully when data is absent (no tags,
no merges). Populated by renderDeliveryCard in 30_coupling_trends.js. -->
<section class="widget card bg-base-200 shadow-lg" id="widget-delivery-card">
<h3>Delivery</h3>
<div class="subtitle">
Git-only delivery proxies: rework rate, branch duration, lead-time proxy,
release cadence, and top friction files. Run with
<code>--include-merges</code> and release tags matching
<code>--release-tag-glob</code> to populate.
</div>
<div id="widget-delivery-card-body" class="widget-body auto-height" style="min-height: 80px;"></div>
</section>
<!-- Delivery Risk Sparkline. Per-commit risk bars over the last
30 non-merge commits, decomposed into peer-reviewed Kamei
JIT-SDP dimensions (size / spread / concurrency /
inexperience / entropy) in the tooltip. Beyond CodeScene:
their delivery-risk score is opaque; ours is citable
(Kamei et al. 2013, Hassan 2009). -->
<section class="widget card bg-base-200 shadow-lg xl:col-span-2 wide-widget" id="widget-kamei-risk">
<h3>Delivery risk · last 30 commits</h3>
<div class="subtitle">
Per-commit risk score composited from Kamei's JIT-SDP feature
vector (la, ld, nf, ndev, exp, entropy). Hover any bar to see
which dimension dominates that commit's risk.
Citations: Kamei et al. 2013 · Hassan 2009.
</div>
<details class="learn-more">
<summary>Learn more — how to read this panel</summary>
<div class="learn-more-content">
<p><strong>What it measures.</strong> A per-commit risk score derived from Kamei's Just-In-Time defect-prediction (JIT-SDP) feature vector. Each commit is scored on <strong>size</strong> (lines added/deleted), <strong>spread</strong> (number of files), <strong>concurrency</strong> (other contributors recently touching the same files), <strong>experience</strong> (the author's familiarity with the touched files), and <strong>entropy</strong> (how diffuse the change is across modules).</p>
<p><strong>How to read it.</strong> 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.</p>
<p><strong>What to watch for.</strong> Streaks of high-risk commits without proportionate review investment. <em>Size</em> dominance = big diff; <em>entropy</em> = scattered changes; <em>concurrency</em> = simultaneous editors fighting over the same files; <em>inexp</em> = an unfamiliar author for the touched files. Each tells a different story.</p>
<p><strong>Suggested action.</strong> 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?".</p>
<p><cite>Y. Kamei et al. 2013, <em>A large-scale empirical study of just-in-time quality assurance</em>; A. E. Hassan 2009, <em>Predicting faults using the complexity of code changes</em>.</cite></p>
</div>
</details>
<!-- Window selector: how many of the most recent non-merge
commits to score. Persisted via
`$store.layout.kameiWindow`; backend sends up to 100. -->
<div role="tablist" class="tabs tabs-boxed mb-2" aria-label="Delivery risk window">
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.kameiWindow === 10 && 'tab-active'"
:aria-selected="$store.layout.kameiWindow === 10 ? 'true' : 'false'"
@click="$store.layout.kameiWindow = 10">
10
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Last 10 commits — tight focus on what just shipped. Best for "what risk did this morning's merges introduce?".</span>
</button>
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.kameiWindow === 30 && 'tab-active'"
:aria-selected="$store.layout.kameiWindow === 30 ? 'true' : 'false'"
@click="$store.layout.kameiWindow = 30">
30
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Default — last 30 commits. Roughly a sprint's worth on active repos; good for "what's our delivery posture this iteration?".</span>
</button>
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.kameiWindow === 60 && 'tab-active'"
:aria-selected="$store.layout.kameiWindow === 60 ? 'true' : 'false'"
@click="$store.layout.kameiWindow = 60">
60
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Last 60 commits — two sprints. Better baseline for spotting trend reversals (calming-down vs heating-up).</span>
</button>
<button type="button" role="tab" class="tab tooltip-host"
:class="$store.layout.kameiWindow === 'all' && 'tab-active'"
:aria-selected="$store.layout.kameiWindow === 'all' ? 'true' : 'false'"
@click="$store.layout.kameiWindow = 'all'">
All
<span class="tooltip-trigger" aria-hidden="true">?</span>
<span class="tooltip-popup" role="tooltip">Full window the backend sent (up to 100). Bars get narrow; useful when you're chasing a multi-week incident retrospective.</span>
</button>
</div>
<!-- 280 px — taller than the original 220 (the per-day risk
pattern needs vertical breathing room), but trimmed from
the earlier 360 which left the panel feeling unbalanced
relative to the calendar heatmap below. -->
<div id="widget-kamei-risk-body" class="widget-body" style="height: 280px;"></div>
</section>
<section class="widget card bg-base-200 shadow-lg xl:col-span-2 wide-widget" id="widget-calendar-heatmap">
<h3>Commit activity</h3>
<div class="subtitle">
Per-day commit volume across the analysed history.
</div>
<details class="learn-more">
<summary>Learn more — how to read this panel</summary>
<div class="learn-more-content">
<p><strong>What it measures.</strong> Per-day commit volume across the entire analysed history. GitHub-style heatmap; one cell per day, one calendar block per year.</p>
<p><strong>How to read it.</strong> 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.</p>
<p><strong>What to watch for.</strong> 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.</p>
<p><strong>Suggested action.</strong> 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.</p>
</div>
</details>
<div id="widget-calendar-heatmap-body" class="widget-body" style="height: 260px;"></div>
</section>
</div>
</section>
</main>
<!-- Back-to-top. Fixed-position singleton, independent of any widget.
`initDashNav` (00_setup_boot.js) toggles the `.dash-visible` class
once the user has scrolled past 600px and wires the click to
scroll to the document top — no `location.hash` involved. -->
<button type="button" id="dash-top-btn" class="btn btn-sm btn-ghost"
aria-label="Back to top" title="Back to top">↑</button>
<!-- Detail drawer: open/close state driven by Alpine `$store.detail`
(declared in the inline script below the persist plugin load).
`x-show` toggles display; `x-transition.opacity` adds a 200 ms
fade. `x-cloak` keeps the drawer hidden before Alpine
initialises so there's no flash-of-visible-content.
`@keydown.escape.window` listens at the document level — Escape
closes the drawer regardless of focus. -->
<!-- Native `<dialog>` element backs the file-detail drawer. Gives
free focus-trap, free Escape-closes, free `::backdrop`.
Alpine.store('detail') calls `.showModal()` / `.close()`
directly; no `x-show`/`x-cloak`/`x-transition` markup. Native
modal management is strictly better for a11y (focus
restoration, screen-reader announcement). -->
<!-- Dropped the DaisyUI `.modal` class: it ships `inset: 0` which
over-constrained the .detail-drawer (left: 0 + right: 0 + width:
440px → CSS spec resolves by ignoring `right`, putting the
drawer at the top-left corner). `.detail-drawer` alone gives
the right-side slide-in correctly. -->
<dialog class="detail-drawer" id="file-detail-drawer"
aria-labelledby="drawer-title" hidden>
<div class="modal-box max-w-2xl">
<div class="drawer-header flex items-center justify-between mb-2">
<h3 id="drawer-title" class="text-lg font-semibold">File details</h3>
<form method="dialog" class="m-0">
<button type="submit"
class="drawer-close btn btn-ghost btn-sm"
id="drawer-close"
aria-label="Close">×</button>
</form>
</div>
<div class="drawer-body" id="drawer-body"></div>
</div>
<!-- Dropped the DaisyUI `modal-backdrop` form (with its
bottom-left "close" button) — that backdrop was for
the modal mode we no longer use (showModal); the
single × button in the drawer header is now the
canonical close affordance, alongside the native
Escape-to-close. -->
</dialog>
<!-- DaisyUI `footer footer-center` provides centred horizontal
layout; the existing semantic `footer { ... }` rule in the
inline <style> keeps the background + padding for visual
continuity. -->
<footer class="footer footer-center">
Generated by
<a href="https://github.com/emrecdr/codelore" rel="noopener" class="link">CodeLore</a>
— the behavioral-code-analysis CLI with published deterministic formulas.
</footer>
<script type="application/json" id="codelore-data">
{{DATA_JSON}}
</script>
<!-- Vendored libraries, SHA-pinned at build time. See crates/codelore-lib/build.rs. -->
<script>{{ECHARTS_JS}}</script>
<script>{{D3_HIERARCHY_JS}}</script>
<!-- Alpine.js + Alpine persist plugin: HTML-attribute reactivity
for cross-widget filter state.
=== Script-load order is load-bearing for correctness ===
Alpine's `cdn.min.js` build auto-starts (`Alpine.start()`)
immediately when `document.readyState !== 'loading'` — which
is ALWAYS the case for inline scripts placed at the end of
`<body>` (the body has children, parsing is past the `loading`
phase). `Alpine.start()` synchronously dispatches the
`alpine:init` event before walking the DOM to bind `x-data` /
`x-show` etc. Any `document.addEventListener('alpine:init',
...)` listener registered AFTER the Alpine core script tag is
too late — the event has already fired and the listener never
runs.
Naive core → persist → store-init order surfaces `Cannot read
properties of undefined (reading 'isDark')` on
`input.theme-controller` because the store was never
registered. The correct order:
1. Persist plugin script — registers ITS own `alpine:init`
listener (uses `Alpine.plugin(persist)` inside the
listener, so the call happens after Alpine is loaded).
2. Our inline store-init script — registers a second
`alpine:init` listener (uses `Alpine.$persist`, which
requires the persist plugin's listener to have run first;
DOM listeners fire in registration order, so persist must
register FIRST).
3. Alpine core script LAST — fires `alpine:init`; both
listeners run in registration order, stores end up wired
before Alpine walks the DOM and evaluates `x-show`.
No `defer` attribute: per the HTML5 spec, `defer` is ignored
on inline scripts (only changes behaviour for `<script src>`).
Position-based ordering is what carries here.
Three stores wired:
- `detail` — file-detail drawer open/close state. Consumed by
the aside markup (`x-show="$store.detail.open"`); written
by `widgets.js::showFileDetailDrawer` via
`Alpine.store('detail').show()`. Closed via the aside's
`@keydown.escape.window="$store.detail.hide()"` and the
close button's `@click="$store.detail.hide()"`.
- `filter` — cross-widget filter text. Only the hotspot table
is wired as a writer today; future widgets subscribe via
`Alpine.effect(() => Alpine.store('filter').text)`.
Persisted via the Alpine persist plugin (`$persist` magic)
so the filter survives a page reload.
- `theme` — light / dark toggle. Initial value seeded from
the OS `prefers-color-scheme` so a user with no saved
preference gets a sensible default. Persisted via
`$persist` so the pre-paint script in `<head>` can read
the same key and apply the `data-theme` attribute before
first paint (no flash of wrong theme). `Alpine.effect`
keeps `data-theme` in sync with the boolean reactively,
and triggers ECharts re-renders via the
`_codeloreRerenderers` registry — ECharts caches resolved
colours at `setOption` time, so a CSS-variable change
alone doesn't refresh the chart. -->
<!-- Step 1: persist plugin script — registers its own alpine:init listener. -->
<script>{{ALPINE_PERSIST_JS}}</script>
<!-- Step 2: our store-init listener — registers AFTER persist's, so it
runs second on alpine:init dispatch (DOM listeners fire in
registration order). -->
<script>
document.addEventListener('alpine:init', () => {
Alpine.store('detail', {
// Drawer is backed by a native <dialog> opened in NON-MODAL
// mode (`.show()`), so the platform gives no focus trap and no
// backdrop. Focus management is wired by hand here: `show()`
// records the trigger and moves focus into the drawer; the
// dialog `close` listener below restores focus to the trigger.
// Keeping `open` for backwards-compat with any widget that
// still queries it (e.g. an Alpine.effect bridge), but the
// canonical source of truth is the dialog's .open property.
open: false,
// Element focused immediately before the drawer opened, so
// focus can be returned there on close. Null when the drawer
// is closed or the trigger was lost (e.g. re-rendered away).
_trigger: null,
show() {
this.open = true;
const d = document.getElementById('file-detail-drawer');
if (!d) return;
// Capture the trigger BEFORE moving focus, but only on a
// fresh open — clicking another row while the drawer is
// already open (the non-modal use case) must not overwrite
// the original trigger with an in-drawer element.
if (!d.open) {
const active = document.activeElement;
this._trigger = (active && active !== document.body) ? active : null;
}
d.removeAttribute('hidden');
// Non-modal `.show()` instead of `.showModal()`: the drawer
// floats on top of the page WITHOUT a backdrop that blocks
// clicks, so the user can click another row in any panel
// and the drawer's content swaps in place. Modal mode was
// forcing the user to close the drawer before selecting a
// new file — and the modal backdrop also interacted badly
// with our right-side fixed positioning.
if (typeof d.show === 'function' && !d.open) {
d.show();
}
// Move focus into the drawer so keyboard / screen-reader
// users land on the revealed content instead of the now-
// occluded trigger row. The close button is the simplest
// stable target and lets Escape-then-Enter dismiss quickly.
const closeBtn = document.getElementById('drawer-close');
if (closeBtn) closeBtn.focus();
},
hide() {
this.open = false;
const d = document.getElementById('file-detail-drawer');
if (!d) return;
if (typeof d.close === 'function' && d.open) {
d.close();
}
// Re-add [hidden] so the `.detail-drawer { position: fixed }`
// CSS rule doesn't keep showing the closed dialog as a
// visible sidebar.
d.setAttribute('hidden', '');
},
});
// The drawer's × button is a <form method="dialog"> submit
// (plus the backdrop close + Escape-key close), which calls
// dialog.close() natively but BYPASSES the Alpine store.hide()
// method. Listen for the dialog's `close` event and re-add
// [hidden] + sync the store's `open` flag so the
// `.detail-drawer { position: fixed }` CSS rule doesn't keep
// the closed dialog showing as a sidebar.
const detailDialog = document.getElementById('file-detail-drawer');
if (detailDialog) {
detailDialog.addEventListener('close', function () {
detailDialog.setAttribute('hidden', '');
const store = Alpine.store('detail');
if (store) {
store.open = false;
// Restore focus to the element that opened the drawer so
// keyboard users resume where they left off. Guard for a
// trigger that's been detached from the document (e.g. its
// table re-rendered while the drawer was open) — focusing a
// detached node throws / silently no-ops, so fall back to
// doing nothing rather than stranding focus on <body>.
const trigger = store._trigger;
store._trigger = null;
if (trigger && document.contains(trigger) &&
typeof trigger.focus === 'function') {
trigger.focus();
}
}
// Clear the cross-widget selection so the trends /
// parallel-coords highlights fade back to neutral when
// the drawer is dismissed.
if (Alpine.store('selection')) {
Alpine.store('selection').clear();
}
});
}
Alpine.store('filter', {
text: Alpine.$persist('').as('codelore_filter_text'),
set(value) { this.text = value; },
clear() { this.text = ''; },
});
// Offboarding scenario state. head_sha is not yet exposed in
// the SpaDashboard payload, so cross-repo persistence is not
// attempted — the user clears the list manually when switching
// repos.
// Dashboard data exposed to Alpine for the parallel DOM tree
// (keyboard-accessible alternative to the canvas circle-pack).
// Populated by widgets.js after data load. The WAI-ARIA
// treeview pattern has no conformant canvas fallback, so the
// keyboard-accessible surface IS this DOM tree, parented to
// the same data the chart shows.
Alpine.store('dashboard', {
hotspots: [], // [{path, hotspot_score, primary_author, code_health_band, code_health_score}], top-N sorted
});
// Cross-widget selection: tracks the currently focused file
// path so the trends chart, parallel-coords, and any other
// path-aware widget can light it up in sync. Set by
// `_codeloreShowDetail` on drawer-open; cleared by the
// dialog `close` event listener (× button, Escape, backdrop).
// Listeners registered in widgets.js via
// `window._codeloreSelectionListeners.push(fn)` are fired by
// the reactive `Alpine.effect` below.
Alpine.store('selection', {
path: null,
set(p) { this.path = p || null; },
clear() { this.path = null; },
});
// Cross-widget SET brush: the bivariate legend publishes the set of
// file paths in a clicked health×activity quadrant here. Deliberately
// SEPARATE from `selection` (a single focused path): brush = context
// (many files), selection = focus (one file); a file can be in the
// brushed set AND the single focus at once. `cell` is null or
// [healthBucket, activityBucket]; `paths` is the quadrant's path list.
// Listeners registered in widgets.js via _codeloreRegisterBrushListener
// fire from the Alpine.effect below.
Alpine.store('brush', {
cell: null,
paths: [],
set(cell, paths) { this.cell = cell || null; this.paths = paths || []; },
clear() { this.cell = null; this.paths = []; },
isActive(hb, ab) {
return !!this.cell && this.cell[0] === hb && this.cell[1] === ab;
},
});
// Per-widget layout settings. Module-coupling chord and
// architecture force-graph aggregate file paths to N path
// segments before rolling up; 'auto' lets the adaptive loop
// pick the smallest depth that produces ≥ MIN_NODES_FOR_*,
// an integer 2-6 forces a specific depth. Persisted across
// reloads so a chosen view sticks. The reactive effect below
// re-fires every widget renderer when these change, so the
// chord / arch graph re-paint with the new aggregation.
Alpine.store('layout', {
chordDepth: Alpine.$persist('auto').as('codelore_chord_depth'),
archGraphDepth: Alpine.$persist('auto').as('codelore_arch_graph_depth'),
// Architecture-graph layout: 'force' (physics) or 'layered'
// (topological bands). Persisted across reloads.
archGraphLayout: Alpine.$persist('force').as('codelore_arch_graph_layout'),
// DSM cell-mode: 'structure' (today's import-only rendering) or
// 'fusion' (structure×history agreement classes). Persisted
// across reloads; the toggle button lives inside the matrix
// widget's own render function, not a static template control.
archMatrixMode: Alpine.$persist('structure').as('codelore_arch_matrix_mode'),
// Sankey 'files' = no aggregation (top-30 file pairs, the
// canonical view). Integer 2-6 collapses each pair's
// entities to N path segments and re-tops the aggregated
// pairs by combined `shared_revs`.
sankeyDepth: Alpine.$persist('files').as('codelore_sankey_depth'),
// Top-N selectors for widgets with implicit row limits.
// 'all' = no limit. Renderers honour these on every paint
// via the reactive effect below.
trendsTopN: Alpine.$persist(10).as('codelore_trends_top_n'),
parallelTopN: Alpine.$persist(20).as('codelore_parallel_top_n'),
kameiWindow: Alpine.$persist(30).as('codelore_kamei_window'),
});
Alpine.store('scenario', {
departed: Alpine.$persist([]).as('codelore_offboard_v1'),
// Populated by widgets.js at boot from data.entity_ownership;
// not persisted (recomputed per-load against the live dataset).
available: [],
toggle(author) {
const i = this.departed.indexOf(author);
if (i >= 0) this.departed.splice(i, 1);
else this.departed.push(author);
// UX: when the user adds their first departed author and
// the circle-pack isn't already in knowledge-loss mode,
// auto-switch so the colour change becomes immediately
// visible. Subsequent toggles inside the mode don't
// re-trigger the click (we check tab-active state first).
if (this.departed.length > 0) {
const tab = document.querySelector('button[data-mode="knowledge-loss"]');
if (tab && !tab.classList.contains('tab-active')) tab.click();
}
},
clear() { this.departed.splice(0, this.departed.length); },
isDeparted(author) { return this.departed.indexOf(author) >= 0; },
});
const initialDark = (window.matchMedia
&& window.matchMedia('(prefers-color-scheme: dark)').matches) || false;
Alpine.store('theme', {
isDark: Alpine.$persist(initialDark).as('codelore_theme_is_dark'),
});
// ─── URL state persistence ─────────────────────────────────
// Bidirectional sync between Alpine stores and the URL hash so
// any view (scenario picks, depth selectors, Top-N tunables)
// is shareable via copy-paste link. `$persist` still backs
// each store with localStorage; the URL takes precedence on
// initial load (a pasted link reproduces the exact view its
// creator was looking at, overriding the local cache).
//
// Loop guard: `writeStoresToUrl` uses `history.replaceState`
// which DOES NOT fire `hashchange` (per HTML spec), so the
// effect can write to URL without re-firing `readUrlIntoStores`.
function readUrlIntoStores() {
const raw = window.location.hash.slice(1);
if (!raw) return;
const params = new URLSearchParams(raw);
if (params.has('departed')) {
const arr = params.get('departed').split(',').filter(Boolean);
const dep = Alpine.store('scenario').departed;
dep.splice(0, dep.length);
arr.forEach(function (a) { dep.push(a); });
}
const layout = Alpine.store('layout');
const keys = ['chordDepth', 'archGraphDepth', 'sankeyDepth',
'trendsTopN', 'parallelTopN', 'kameiWindow'];
keys.forEach(function (k) {
if (!params.has(k)) return;
const v = params.get(k);
if (v === 'auto' || v === 'files' || v === 'all') {
layout[k] = v;
} else {
const n = Number(v);
if (isFinite(n)) layout[k] = n;
}
});
}
function writeStoresToUrl() {
const params = new URLSearchParams();
const dep = Alpine.store('scenario').departed;
if (dep.length) params.set('departed', dep.join(','));
const layout = Alpine.store('layout');
// Only emit non-default values — keeps the URL short and the
// "shared link" semantics clear (anything in the URL is an
// explicit override of the dashboard's defaults).
if (layout.chordDepth !== 'auto') params.set('chordDepth', String(layout.chordDepth));
if (layout.archGraphDepth !== 'auto') params.set('archGraphDepth', String(layout.archGraphDepth));
if (layout.sankeyDepth !== 'files') params.set('sankeyDepth', String(layout.sankeyDepth));
if (layout.trendsTopN !== 10) params.set('trendsTopN', String(layout.trendsTopN));
if (layout.parallelTopN !== 20) params.set('parallelTopN', String(layout.parallelTopN));
if (layout.kameiWindow !== 30) params.set('kameiWindow', String(layout.kameiWindow));
const newHash = params.toString();
const cur = window.location.hash.slice(1);
if (newHash !== cur) {
history.replaceState(null, '',
newHash ? '#' + newHash : window.location.pathname + window.location.search);
}
}
// 1. URL → stores ONCE on init (so a pasted link overrides
// the localStorage-restored defaults).
readUrlIntoStores();
// 2. Stores → URL whenever any persisted store field changes.
Alpine.effect(writeStoresToUrl);
// 3. URL → stores on back/forward (`hashchange` only fires for
// user navigation, never for our own replaceState writes).
window.addEventListener('hashchange', readUrlIntoStores);
// Theme bridge: reads only store.theme.isDark so the data-theme
// attribute update and ECharts palette re-renders fire in isolation
// from layout-depth or offboarding changes. Cooperative scheduling
// preserved: yields between re-renderers so user input stays
// responsive during the theme-change cascade.
Alpine.effect(() => {
const dark = Alpine.store('theme').isDark;
document.documentElement.setAttribute('data-theme', dark ? 'dark' : 'light');
// Fire registered re-renderers so ECharts widgets pick up the
// new resolved palette. Wrapped in try/catch per-renderer so
// one broken widget doesn't break the rest.
const rerenderers = window._codeloreRerenderers || [];
(async function runRerenderers() {
for (let i = 0; i < rerenderers.length; i++) {
try { rerenderers[i](); } catch (e) { console.warn('rerender failed:', e); }
if (i + 1 < rerenderers.length && typeof window._codeloreYieldToMain === 'function') {
await window._codeloreYieldToMain();
}
}
})();
});
// Layout and offboarding bridge: re-renders registered widgets when
// the user changes an aggregation depth or the offboarding scenario.
// Kept separate from the theme effect so a depth-tab click does not
// also trigger a CSS-token invalidation pass across all renderers.
// No cooperative yield — these are explicit single user actions, not
// the full-dashboard repaint a theme switch triggers.
Alpine.effect(() => {
void Alpine.store('scenario').departed.length;
void Alpine.store('layout').chordDepth;
void Alpine.store('layout').archGraphDepth;
void Alpine.store('layout').archGraphLayout;
void Alpine.store('layout').sankeyDepth;
void Alpine.store('layout').trendsTopN;
void Alpine.store('layout').parallelTopN;
void Alpine.store('layout').kameiWindow;
const rerenderers = window._codeloreRerenderers || [];
for (let i = 0; i < rerenderers.length; i++) {
try { rerenderers[i](); } catch (e) { console.warn('rerender failed:', e); }
}
});
// Cross-widget selection bridge: fire listeners registered by
// path-aware widgets whenever `$store.selection.path` changes.
// Each listener is responsible for its own
// dispatchAction({type:'highlight'/'downplay'}) on its chart.
Alpine.effect(() => {
const path = Alpine.store('selection').path;
const listeners = window._codeloreSelectionListeners || [];
for (let i = 0; i < listeners.length; i++) {
try { listeners[i](path); } catch (e) { console.warn('selection listener failed:', e); }
}
});
// Cross-widget brush bridge: fire listeners registered by quadrant-
// aware widgets whenever `$store.brush.cell` changes. Reads both
// `cell` and `paths` so either mutation re-fires.
Alpine.effect(() => {
const cell = Alpine.store('brush').cell;
const paths = Alpine.store('brush').paths;
void (cell && cell.length);
void paths.length;
const listeners = window._codeloreBrushListeners || [];
for (let i = 0; i < listeners.length; i++) {
try { listeners[i](cell, paths); } catch (e) { console.warn('brush listener failed:', e); }
}
});
// Hotspot-table knowledge-loss bridge: when `scenario.departed`
// changes, toggle `.hotspot-row-departed` on every `<tr>` whose
// `data-primary-author` is in the departed set. Walks the live
// DOM each fire — cheap (one querySelectorAll, single class
// toggle per row) and immune to the table's infinite-scroll
// re-render (new rows pick up the class on next effect tick
// because Alpine reads `.departed` reactively).
Alpine.effect(() => {
const departed = Alpine.store('scenario').departed;
const departedSet = new Set(departed);
const rows = document.querySelectorAll('tr.hotspot-row[data-primary-author]');
for (let i = 0; i < rows.length; i++) {
const author = rows[i].getAttribute('data-primary-author');
if (author && departedSet.has(author)) {
rows[i].classList.add('hotspot-row-departed');
} else {
rows[i].classList.remove('hotspot-row-departed');
}
}
});
});
</script>
<!-- Step 3: Alpine core LAST — auto-starts; fires alpine:init; both
listeners above run in registration order, stores are wired
before Alpine walks the DOM. -->
<script>{{ALPINE_JS}}</script>
<!-- Widget render logic. Runs after Alpine has bound, so any
`Alpine.store(...)` access from widgets sees the registered
stores. -->
<script>{{WIDGETS_JS}}</script>
</body>
</html>