debug-pattern-analysis

Defect Pattern Analysis

The goal is to find systemic issues — not just individual bugs, but patterns that reveal structural, process, or architectural problems. Individual bugs are symptoms; patterns are root causes at a higher level.

Step 1: Historical Analysis

Commit History

Run git log --oneline -50 and look for:

• Files that appear repeatedly in commit messages (hotspots)
• Commit messages containing "fix", "revert", "hotfix", "emergency" — these signal instability
• Revert commits — strong signal of code that wasn't ready
• Back-to-back fixes to the same file — whack-a-mole pattern

Bug Pattern Review

If the user can describe recent bugs, analyze them for:

• Common symptoms (same error type, same component)
• Recurring locations (same file, class, or function)
• Similar root causes (same category of mistake)
• Timing correlation (bugs that appear together suggest a shared cause)

Step 2: Code Pattern Detection

Anti-Patterns

Read high-change files and look for:

• God objects/functions — classes or functions with too much responsibility (>200 lines, >10 methods doing unrelated things)
• Copy-paste code — identical or near-identical logic in multiple places (DRY violations)
• Dead code — unreachable branches, unused functions, unused imports
• Complex conditionals — deeply nested if/else, cyclomatic complexity >15
• Long parameter lists — functions taking >4 parameters (especially untyped)
• Tight coupling — classes that know too much about each other's internals

Vulnerability Patterns

Scan for common reliability/security issues:

• Input validation gaps (user input used without sanitization)
• Error handling inconsistencies (some paths handle errors, others don't)
• Resource leak patterns (files/connections opened without guaranteed close)
• Race condition indicators (shared state accessed from multiple contexts without locking)

Step 3: Architectural Pattern Analysis

Dependency Issues

• Circular dependencies (A imports B imports A)
• Components that import from too many other components (high fan-in)
• Missing abstractions (concrete implementations used where interfaces should be)
• Version conflicts between dependencies

Design Smells

• SOLID principle violations
• Patterns applied incorrectly (e.g., Singleton causing hidden global state)
• Over-engineering (abstractions with only one implementation)
• Technical debt accumulation (TODO/FIXME/HACK comments as a metric)

Step 4: Team/Process Pattern Analysis

Review commit metadata and code patterns for:

• Rush commits — large commits late in a sprint or release cycle with poor message quality
• Incomplete implementations — TODO/FIXME markers in shipped code
• Missing tests on bug fixes — fix commits without corresponding test commits
• Documentation gaps — public APIs without documentation
• Knowledge silos — files with only one author who's touched them repeatedly

Step 5: Correlation

Group findings by:

• Component or module (which areas have the most issues?)
• Category (is it all data validation? all concurrency? all configuration?)
• Time period (did issues accelerate recently? did a release trigger a pattern?)

Identify root patterns — the issues that cause other issues.

Output Format

# Defect Pattern Analysis Report

**Date:** [today]
**Scope:** [what was analyzed]

## Executive Summary
[2-3 sentences: key findings, most critical patterns]

## Critical Patterns Found

### Pattern: [Name]
**Type:** [Anti-pattern / Vulnerability / Architectural / Process]
**Frequency:** [N occurrences]
**Locations:** [file:function or component]
**Description:** [what the pattern is]
**Impact:** [why it matters]
**Recommendation:** [how to address]

[repeat for each significant pattern]

## Hotspot Analysis

### High-Change / High-Risk Files
1. [file] — [N commits], [N bugs linked], [risk assessment]
2. ...

## Systemic Issues
[Issues that span multiple patterns or suggest deeper structural problems]

## Trend Analysis
- **Improving:** [areas getting better]
- **Degrading:** [areas getting worse]
- **Stable problems:** [persistent issues not improving]

## Recommendations

### Immediate (this sprint)
1. [quick win]

### Short-term (next 1-2 sprints)
1. [process or code changes]

### Long-term (architectural)
1. [structural improvements]

## Prevention Checklist
- [ ] [specific action to prevent top pattern]
- [ ] [linting rule / pre-commit hook suggestion]
- [ ] [test coverage improvement]