feat: Interactive Heatmap Visualization for Batch Assessments

[jeremyeder]

Summary

Adds interactive heatmap visualization for batch repository assessments, enabling visual analysis of attribute compliance across multiple repositories.

Features

Core Visualization

• Interactive Plotly heatmap with zoom, pan, and hover tooltips
• Repository sorting by overall score (descending)
• Attribute sorting by tier (1-4), then alphabetically
• Color-coded scores:
  • Gray: Not applicable
  • Red: 0-39 (Needs Improvement)
  • Yellow: 40-59 (Bronze)
  • Green: 60-89 (Silver/Gold)
  • Dark Green: 90-100 (Platinum)
• Certification badges (💎🥇🥈🥉⚠️) with overall scores
• Standalone HTML (5MB, no external dependencies)

CLI Integration

# Generate heatmap with batch assessment
agentready assess-batch --repos-file repos.txt --generate-heatmap

# Custom output path
agentready assess-batch --repos-file repos.txt \
  --generate-heatmap \
  --heatmap-output /path/to/custom-heatmap.html

Output saved to: .agentready/batch/reports-*/heatmap.html

Implementation Details

1. Extended AttributeAnalyzer

• Added analyze_batch() method for BatchAssessment objects
• Added analyze_batch_from_json() for dict-based analysis (cache workaround)
• DataFrame transformation with pandas for matrix data structure
• Custom colorscale with -1 sentinel value for NaN (gray squares)

2. Duplicate Attribute Deduplication

Problem: Three attributes appeared twice per repository:

• one_command_setup
• architecture_decisions
• issue_pr_templates

Second occurrence was always not_applicable, overwriting real assessments and creating erroneous gray squares (108 total across 36 repos).

Solution: Deduplication logic in DataFrame preparation:

• Track seen attributes with set()
• Skip duplicate IDs, keep first occurrence only
• Reduces 31 attributes → 28 real attributes

3. Cache Deserialization Workaround

Problem: AssessmentCache._deserialize_assessment() raises NotImplementedError, preventing cache usage on re-runs.

Solution: Added JSON-based analysis methods:

• analyze_batch_from_json() - works directly with dict data
• _prepare_batch_dataframe_from_json() - bypasses object deserialization
• Enables heatmap regeneration without fixing cache implementation

4. Repository Manager Fix

Removed --no-hooks flag from git clone command (not supported in older Git versions).

Utility Scripts

Three scripts added to scripts/ directory:

1. extract_repo_urls.py - Extract repository URLs from filtered JSON for batch assessment input
2. fix_heatmap_data.py - Remove duplicate attributes from all-assessments.json (108 duplicates removed)
3. regenerate_heatmap.py - Regenerate heatmap from fixed JSON data using analyze_batch_from_json()

Testing

Validated with 36 OpenDataHub repositories:

• Success rate: 100% on initial run
• Average score: 40.1/100 (Bronze certification)
• Heatmap size: 5.1 MB (36 repos × 28 attributes)
• Duplicate removal: Eliminated 108 erroneous gray cells

Files Changed

• src/agentready/cli/assess_batch.py - Added CLI flags
• src/agentready/services/attribute_analyzer.py - Core heatmap implementation
• src/agentready/services/repository_manager.py - Removed --no-hooks flag
• src/agentready/templates/multi_report.html.j2 - Template fix for Jinja2 scoping
• scripts/extract_repo_urls.py - URL extraction utility (NEW)
• scripts/fix_heatmap_data.py - Duplicate removal utility (NEW)
• scripts/regenerate_heatmap.py - Heatmap regeneration utility (NEW)

Example Output

![Heatmap visualization showing 36 repositories × 28 attributes with color-coded scores]

Future Enhancements

• Fix _deserialize_assessment() to enable cache on re-runs
• Investigate root cause of duplicate attribute registration bug
• Add filtering/search to heatmap UI
• Add attribute statistics (pass rate, average score) to heatmap
• Export heatmap data to CSV for further analysis

Related Issues

Addresses the need for visual analysis of batch assessment results across multiple repositories.

[github-actions]

🤖 AgentReady Assessment Report

Repository: agentready
Path: /home/runner/work/agentready/agentready
Branch: HEAD | Commit: 61219a73
Assessed: November 24, 2025 at 9:17 PM
AgentReady Version: 2.6.0
Run by: runner@runnervmg1sw1

---

📊 Summary

Metric	Value
Overall Score	70.3/100
Certification Level	Silver
Attributes Assessed	19/31
Attributes Not Assessed	12
Assessment Duration	1.4s

Languages Detected

• Python: 134 files
• Markdown: 98 files
• YAML: 20 files
• JSON: 9 files
• Shell: 6 files

Repository Stats

• Total Files: 312
• Total Lines: 174,053

🎖️ Certification Ladder

• 💎 Platinum (90-100)
• 🥇 Gold (75-89)
• 🥈 Silver (60-74) → YOUR LEVEL ←
• 🥉 Bronze (40-59)
• ⚠️ Needs Improvement (0-39)

📋 Detailed Findings

API Documentation

Attribute	Tier	Status	Score
OpenAPI/Swagger Specifications	T3	⊘ not_applicable	—

Build & Development

Attribute	Tier	Status	Score
One-Command Build/Setup	T2	✅ pass	100
One-Command Build/Setup	T2	⊘ not_applicable	—
Container/Virtualization Setup	T4	⊘ not_applicable	—

Code Organization

Attribute	Tier	Status	Score
Separation of Concerns	T2	✅ pass	98

Code Quality

Attribute	Tier	Status	Score
Type Annotations	T1	❌ fail	39
Cyclomatic Complexity Thresholds	T3	✅ pass	100
Semantic Naming	T3	✅ pass	100
Structured Logging	T3	❌ fail	0
Code Smell Elimination	T4	⊘ not_applicable	—

❌ Type Annotations

Measured: 31.6% (Threshold: ≥80%)

Evidence:

• Typed functions: 423/1340
• Coverage: 31.6%

📝 Remediation Steps

Add type annotations to function signatures

1. For Python: Add type hints to function parameters and return types
2. For TypeScript: Enable strict mode in tsconfig.json
3. Use mypy or pyright for Python type checking
4. Use tsc --strict for TypeScript
5. Add type annotations gradually to existing code

Commands:

# Python
pip install mypy
mypy --strict src/

# TypeScript
npm install --save-dev typescript
echo '{"compilerOptions": {"strict": true}}' > tsconfig.json

Examples:

# Python - Before
def calculate(x, y):
    return x + y

# Python - After
def calculate(x: float, y: float) -> float:
    return x + y

// TypeScript - tsconfig.json
{
  "compilerOptions": {
    "strict": true,
    "noImplicitAny": true,
    "strictNullChecks": true
  }
}

❌ Structured Logging

Measured: not configured (Threshold: structured logging library)

Evidence:

• No structured logging library found
• Checked files: pyproject.toml
• Using built-in logging module (unstructured)

📝 Remediation Steps

Add structured logging library for machine-parseable logs

1. Choose structured logging library (structlog for Python, winston for Node.js)
2. Install library and configure JSON formatter
3. Add standard fields: timestamp, level, message, context
4. Include request context: request_id, user_id, session_id
5. Use consistent field naming (snake_case for Python)
6. Never log sensitive data (passwords, tokens, PII)
7. Configure different formats for dev (pretty) and prod (JSON)

Commands:

# Install structlog
pip install structlog

# Configure structlog
# See examples for configuration

Examples:

# Python with structlog
import structlog

# Configure structlog
structlog.configure(
    processors=[
        structlog.stdlib.add_log_level,
        structlog.processors.TimeStamper(fmt="iso"),
        structlog.processors.JSONRenderer()
    ]
)

logger = structlog.get_logger()

# Good: Structured logging
logger.info(
    "user_login",
    user_id="123",
    email="user@example.com",
    ip_address="192.168.1.1"
)

# Bad: Unstructured logging
logger.info(f"User {user_id} logged in from {ip}")

Context Window Optimization

Attribute	Tier	Status	Score
CLAUDE.md Configuration Files	T1	✅ pass	100
File Size Limits	T2	⊘ not_applicable	—

Dependency Management

Attribute	Tier	Status	Score
Lock Files for Reproducibility	T1	❌ fail	0
Dependency Freshness & Security	T2	⊘ not_applicable	—

❌ Lock Files for Reproducibility

Measured: none (Threshold: at least one lock file)

Evidence:

• No lock files found

📝 Remediation Steps

Add lock file for dependency reproducibility

1. Use npm install, poetry lock, or equivalent to generate lock file

Commands:

npm install  # generates package-lock.json

Documentation

Attribute	Tier	Status	Score
Concise Documentation	T2	❌ fail	70
Inline Documentation	T2	✅ pass	100

❌ Concise Documentation

Measured: 276 lines, 40 headings, 38 bullets (Threshold: <500 lines, structured format)

Evidence:

• README length: 276 lines (excellent)
• Heading density: 14.5 per 100 lines (target: 3-5)
• 1 paragraphs exceed 10 lines (walls of text)

📝 Remediation Steps

Make documentation more concise and structured

1. Break long README into multiple documents (docs/ directory)
2. Add clear Markdown headings (##, ###) for structure
3. Convert prose paragraphs to bullet points where possible
4. Add table of contents for documents >100 lines
5. Use code blocks instead of describing commands in prose
6. Move detailed content to wiki or docs/, keep README focused

Commands:

# Check README length
wc -l README.md

# Count headings
grep -c '^#' README.md

Examples:

# Good: Concise with structure

## Quick Start
```bash
pip install -e .
agentready assess .

Features

• Fast repository scanning
• HTML and Markdown reports
• 25 agent-ready attributes

Documentation

See docs/ for detailed guides.

Bad: Verbose prose

This project is a tool that helps you assess your repository
against best practices for AI-assisted development. It works by
scanning your codebase and checking for various attributes that
make repositories more effective when working with AI coding
assistants like Claude Code...

[Many more paragraphs of prose...]

</details>

### Documentation Standards

| Attribute | Tier | Status | Score |
|-----------|------|--------|-------|
| README Structure | T1 | ✅ pass | 100 |
| Architecture Decision Records (ADRs) | T3 | ❌ fail | 0 |
| Architecture Decision Records | T3 | ⊘ not_applicable | — |

#### ❌ Architecture Decision Records (ADRs)

**Measured**: no ADR directory (Threshold: ADR directory with decisions)

**Evidence**:
- No ADR directory found (checked docs/adr/, .adr/, adr/, docs/decisions/)

<details><summary><strong>📝 Remediation Steps</strong></summary>


Create Architecture Decision Records (ADRs) directory and document key decisions

1. Create docs/adr/ directory in repository root
2. Use Michael Nygard ADR template or MADR format
3. Document each significant architectural decision
4. Number ADRs sequentially (0001-*.md, 0002-*.md)
5. Include Status, Context, Decision, and Consequences sections
6. Update ADR status when decisions are revised (Superseded, Deprecated)

**Commands**:

```bash
# Create ADR directory
mkdir -p docs/adr

# Create first ADR using template
cat > docs/adr/0001-use-architecture-decision-records.md << 'EOF'
# 1. Use Architecture Decision Records

Date: 2025-11-22

## Status
Accepted

## Context
We need to record architectural decisions made in this project.

## Decision
We will use Architecture Decision Records (ADRs) as described by Michael Nygard.

## Consequences
- Decisions are documented with context
- Future contributors understand rationale
- ADRs are lightweight and version-controlled
EOF

Examples:

# Example ADR Structure

```markdown
# 2. Use PostgreSQL for Database

Date: 2025-11-22

## Status
Accepted

## Context
We need a relational database for complex queries and ACID transactions.
Team has PostgreSQL experience. Need full-text search capabilities.

## Decision
Use PostgreSQL 15+ as primary database.

## Consequences
- Positive: Robust ACID, full-text search, team familiarity
- Negative: Higher resource usage than SQLite
- Neutral: Need to manage migrations, backups

</details>

### Git & Version Control

| Attribute | Tier | Status | Score |
|-----------|------|--------|-------|
| Conventional Commit Messages | T2 | ❌ fail | 0 |
| .gitignore Completeness | T2 | ✅ pass | 100 |
| Branch Protection Rules | T4 | ⊘ not_applicable | — |
| Issue & Pull Request Templates | T4 | ⊘ not_applicable | — |

#### ❌ Conventional Commit Messages

**Measured**: not configured (Threshold: configured)

**Evidence**:
- No commitlint or husky configuration

<details><summary><strong>📝 Remediation Steps</strong></summary>


Configure conventional commits with commitlint

1. Install commitlint
2. Configure husky for commit-msg hook

**Commands**:

```bash
npm install --save-dev @commitlint/cli @commitlint/config-conventional husky

Performance

Attribute	Tier	Status	Score
Performance Benchmarks	T4	⊘ not_applicable	—

Repository Structure

Attribute	Tier	Status	Score
Standard Project Layouts	T1	✅ pass	100
Issue & Pull Request Templates	T3	✅ pass	100
Separation of Concerns	T2	⊘ not_applicable	—

Security

Attribute	Tier	Status	Score
Security Scanning Automation	T4	⊘ not_applicable	—

Testing & CI/CD

Attribute	Tier	Status	Score
Test Coverage Requirements	T2	✅ pass	100
Pre-commit Hooks & CI/CD Linting	T2	✅ pass	100
CI/CD Pipeline Visibility	T3	✅ pass	80

🎯 Next Steps

Priority Improvements (highest impact first):

1. Lock Files for Reproducibility (Tier 1) - +10.0 points potential
   • Add lock file for dependency reproducibility
2. Type Annotations (Tier 1) - +10.0 points potential
   • Add type annotations to function signatures
3. Conventional Commit Messages (Tier 2) - +3.0 points potential
   • Configure conventional commits with commitlint
4. Concise Documentation (Tier 2) - +3.0 points potential
   • Make documentation more concise and structured
5. Architecture Decision Records (ADRs) (Tier 3) - +1.5 points potential
   • Create Architecture Decision Records (ADRs) directory and document key decisions

---

📝 Assessment Metadata

• Tool Version: AgentReady v1.0.0
• Research Report: Bundled version
• Repository Snapshot: 61219a7
• Assessment Duration: 1.4s

🤖 Generated with Claude Code

[github-actions]

🎉 This PR is included in version 2.7.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀