vm-solid-principles-checker

# SOLID Principles Checker

This skill evaluates source code against the five SOLID design principles. It is language-agnostic and designed for brownfield codebases — it identifies violations in existing code, not just in changed files.

## Brownfield Context

If `docs/codebase-analysis/` exists, read `docs/codebase-analysis/architecture.md` to understand the intended structure before flagging violations. A violation appearing consistently across the entire codebase should be noted as a **systemic issue** in the summary, not repeated as an individual finding on every file. This tells the team to address the root cause architecturally rather than file by file.

---

## Principles Evaluated

### 1 — Single Responsibility Principle (SRP)

**Definition**: A class or module should have one, and only one, reason to change.

**Indicators of violation:**
- Classes or modules with many unrelated public methods
- Files that mix data access, business logic, and UI rendering
- Functions that perform validation AND persistence AND notification in a single body
- "God classes" — large classes that know about and control many unrelated concerns

**Findings format:**
```json
{
  "principle": "SRP",
  "file": "path/to/UserService.ts",
  "line_range": "1-280",
  "description": "Class handles authentication, user profile persistence, and email notification in a single class body",
  "recommendation": "Extract email notification into a NotificationService; extract profile persistence into a UserRepository"
}
```

---

### 2 — Open/Closed Principle (OCP)

**Definition**: Software entities should be open for extension but closed for modification.

**Indicators of violation:**
- Large switch/if-else chains that must be modified each time a new type is added
- Conditional logic that branches on `type`, `kind`, or `category` strings or enums
- Base classes that must be modified when new subtypes need different behavior
- Registration or dispatch logic with a hardcoded list of known implementations

**Findings format:**
```json
{
  "principle": "OCP",
  "file": "path/to/NotificationDispatcher.ts",
  "line_range": "45-80",
  "description": "Switch statement on notification type requires modification each time a new notification channel is added",
  "recommendation": "Introduce a NotificationHandler interface and register handlers by type — new channels are added without modifying the dispatcher"
}
```

---

### 3 — Liskov Substitution Principle (LSP)

**Definition**: Objects of a subclass should be substitutable for objects of their parent class without altering correctness.

**Indicators of violation:**
- Subclasses that throw exceptions or return null for methods they inherit from the base class
- Overridden methods that narrow the accepted input types or widen the return type
- Base class methods that use `instanceof` checks to detect the concrete subtype at runtime
- Subclasses that honor the parent contract only partially or conditionally

**Findings format:**
```js