Multi-Language Support via CLI Analyzers

# Multi-Language Support via CLI Analyzers

## Problem
CodeBunny only supports JavaScript/TypeScript. Projects using Python, Go, Rust, or other languages miss out on language-specific code review insights and pattern detection.

## Goals
- 🌍 Support any programming language
- 🚀 Enable community-contributed analyzers
- 📦 Allow independent analyzer distribution
- 🔌 Zero core changes needed for new languages

---

## Proposed Solution: CLI-Based Analyzer System

Make language analyzers standalone executables that communicate via JSON. CodeBunny orchestrates them.

### How It Works

Each analyzer is a simple CLI (e.g., `bunny-py`, `bunny-go`) following a standard interface:

```bash
# Discover capabilities
$ bunny-py --register
{
"name": "Python Analyzer",
"language": "Python",
"extensions": [".py", ".pyi"],
"version": "1.0.0"
}

# Analyze files
$ bunny-py --analyze api/main.py api/routes.py
{
"frameworks": ["FastAPI"],
"patterns": [
{"type": "endpoint", "pattern": "FastAPI route", "count": 5},
{"type": "async", "pattern": "async function", "count": 3}
],
"conventions": {
"naming": {"functions": "snake_case", "classes": "PascalCase"}
}
}
```

CodeBunny parses the JSON and includes it in review prompts.

### User Experience

```yaml
# Install analyzer (any distribution method)
- run: npm install -g codebunny-python-analyzer
# or: pip install codebunny-python-analyzer
# or: go install github.com/user/bunny-go@latest

# Register with CodeBunny
- run: codebunny register bunny-py

# Reviews automatically include Python analysis
- uses: bdougie/codebunny@main
```

---

## Why This Approach?

✅ **Native Language Tools** - Python analyzer uses Python's `ast`, Go uses `go/ast`
✅ **Community-Driven** - Anyone can publish analyzers independently
✅ **No Core Changes** - Add languages without touching CodeBunny
✅ **Independent Evolution** - Analyzers version/release separately
✅ **Private Languages** - Enterprises can build internal analyzers

---

## Implementation Plan

### Phase 1: Specification & Infrastructure
- [ ] Define CLI analyzer spec (commands, JSON schema)
- [ ] Create TypeScript wrapper for external CLIs
- [ ] Build registry system (`.codebunny/analyzers.json`)
- [ ] Add `codebunny register` CLI command

### Phase 2: Reference Implementation
- [ ] Build `bunny-py` as proof-of-concept
- [ ] Publish to npm/PyPI for easy distribution
- [ ] Document analyzer creation process

### Phase 3: Community Enablement
- [ ] Create analyzer template repository
- [ ] Write "Building Your Own Analyzer" guide
- [ ] Set up analyzer registry/marketplace (optional)

---

## Alternative Approaches

Option 2: Embedded TypeScript Plugins

Write all analyzers as TypeScript classes in CodeBunny core.

**Pros:** Faster (~100ms vs ~500ms), simpler setup, single deployment
**Cons:** Limited to TypeScript, requires PRs for new languages, can't use native language tools

Option 3: Hybrid

Ship JS/Python as built-in TypeScript plugins + support external CLIs for additional languages.

**Pros:** Best of both worlds - fast defaults, community extensibility
**Cons:** More complexity to maintain both systems

---

## Open Questions
- Should analyzers be auto-discovered from PATH or explicitly registered?
- What's the right timeout for external CLI calls? (currently thinking 60s)
- Should we provide an official analyzer template/generator?
- Registry: local JSON file or support for remote registries later?
- Performance acceptable? (~500ms overhead for CLI spawn vs in-process)

Thoughts on this approach?