Collective Memory Dashboard

Pullminder’s Collective Memory tracks which files cause the most trouble across your pull request history. As PRs are merged, the system records per-file trouble counts, churn counts, finding categories, and the authors who touch each file most often. This gives you a data-backed view of where problems cluster — without manual tagging or configuration.

For a conceptual overview of how Collective Memory works, see the Collective Memory guide.

Enabling Collective Memory

Collective Memory is off by default. Enable it per repository from the Settings page:

1. Open Settings from the sidebar.
2. Find the repository in the list.
3. Toggle the Collective Memory switch on.

When you disable Collective Memory for a repository, its stored file-memory rows are purged immediately. Re-enabling it starts fresh — only PRs merged after re-enabling are recorded.

Viewing the analytics

Once enabled, click View memory next to the repository in Settings, or navigate directly to /memory/{repoId}.

The analytics page shows:

• Summary cards at the top: total troubled files, total trouble count, and total churn count across the repository.
• File table with sortable columns:
  • Trouble — highest trouble count first (default).
  • Churn — highest churn count first.
  • Recent — most recently troubled first.

Click any file row to expand a drill-down panel showing:

• Finding categories — the types of findings flagged on this file (e.g. TEST_GAP, SECRET_LEAK) with per-category counts.
• Top authors — who touched this file most often across the recorded history.

The Last trouble PR column links directly to the pull request detail page where the most recent trouble was detected.

Limits

• Up to 100 files are shown per sort view.
• Up to 52 weeks of trend history is available per repository.
• Collective Memory is read-only. It never affects a pull request’s risk score.

Trends

The Trends chart on the repository memory page shows weekly counts of trouble, churn, and finding events stacked over the selected time window. Each bar represents one ISO week, letting you see whether problem areas are getting better or worse over time.

The chart is powered by the append-only memory_events time-series — events are recorded at the moment of capture, so the timeline reflects when signals were detected, not when they were first browsed.

Use the weeks query parameter to adjust the lookback window (default 12, minimum 1, maximum 52).

Org-wide troubled files

The Org Memory page (/memory) lists the most troubled files across all repositories in your organization that have Collective Memory enabled. Each row shows:

• Repository — which repo the file belongs to, linked to that repo’s memory page.
• File path — the file within the repo.
• Trouble count and churn count — aggregate counts from the file_memory rollup.
• Last trouble — when the most recent trouble event was recorded.

Use this view to spot problem files that span repositories, or to find which repos are generating the most signal without clicking through each one individually.