PR History

The PR History page shows every pull request Radar has analyzed, with scores, gate results, and violation counts. Use it to track team progress, investigate failed PRs, and compare code quality across time.

The PR History Table

The main view is a sortable, paginated table with the following columns:

Column	Description
PR	Pull request number and title, linked to the source (GitHub or GitLab)
Repository	Repository name (for multi-repo projects)
Author	The developer who opened the PR
Debt Score	The debt delta score for the analyzed changes
Violations	Total violation count, broken down as critical / warning / info
Gate Result	A colored badge: green PASS or red FAIL
Date	Timestamp of the most recent analysis for that PR

The table defaults to reverse chronological order (most recent first) and shows 25 rows per page.

Filtering

By Repository

A dropdown at the top of the page lists all connected repositories. Select a repository to show only PRs from that repository. Select All repositories to see the full history.

By Date Range

A date range picker lets you specify a start and end date. Only PRs analyzed within that range are shown. Preset ranges are available: Last 7 days, Last 30 days, Last 90 days, and Custom.

By Gate Result

Toggle buttons let you filter by gate result:

• All --- show all PRs
• PASS --- show only PRs that passed the merge gate
• FAIL --- show only PRs that were blocked

Tip: Filtering to FAIL-only PRs is a fast way to find recurring violation patterns. If the same rule ID appears across multiple failed PRs, consider addressing the root cause rather than fixing each PR individually.

By Author

A text search field filters PRs by author username. Useful for tech leads reviewing a specific developer's PR history during one-on-ones.

PR Detail View

Click any row in the table to open the full analysis report for that PR. The detail view includes:

Summary Section

• Gate result (PASS/FAIL) with the debt delta score
• Total violations by category and severity
• Analysis duration
• Files analyzed count
• Link to the PR on GitHub/GitLab

Violation List

Every violation detected in the PR, with:

• File path and line number
• Rule ID and category
• Severity
• Description and fix instructions
• Code context (the offending lines, syntax-highlighted)

AI Analysis (if enabled)

When AI analysis was included, the detail view shows:

• AI-generated explanations for the top violations
• Cross-file call path traces
• Suggested fixes with code snippets

Diff View

A side-by-side view showing the PR's changed files with violations annotated inline. Violations appear as colored markers in the gutter next to the relevant lines.

Comparing PRs

Select two or more PRs using the checkboxes in the table, then click Compare. The comparison view shows:

• Side-by-side scores --- debt delta, violation count, and gate result for each selected PR
• Category breakdown comparison --- a grouped bar chart showing violations by category for each PR
• Common violations --- rules that appear in multiple selected PRs, indicating patterns

This is useful for measuring improvement: compare this week's PRs against last week's to see if refactoring efforts had an impact.

Export

Click the Export button above the table to download PR history as:

• CSV --- for spreadsheet analysis
• JSON --- for programmatic processing

The export respects the current filters. If you have filtered to a specific repository and date range, only matching PRs are included in the export.

Patterns to Watch For

Improving Trend

When PASS results increase over time and the average debt score decreases, the team is successfully reducing technical debt. Celebrate this --- it means the enforcement is working and developers are adapting.

Persistent Failures

When the same PR fails multiple times before passing, it may indicate that the violation feedback is not clear enough, or that the developer needs guidance on the architecture rules. Review the violation descriptions and consider adding team-specific examples to your radar.yml comments.

Module Hotspots

If failed PRs consistently touch the same module, that module likely has structural issues that make it difficult to change without introducing violations. Consider scheduling dedicated refactoring for that module.

Gate Threshold Tuning

If nearly every PR fails, the gate threshold may be too strict for the current state of the codebase. Consider temporarily raising the debt delta threshold (e.g., from 15 to 25) while the team works down the backlog, then gradually tightening it.

If PRs almost never fail, the threshold may be too lenient. Review the violation counts --- if PRs regularly have 5+ warnings but still pass, consider lowering the threshold or enabling blocking on additional categories.