extreme-router-refactor

name	extreme-router-refactor
description	Code refactoring, tech debt cleanup, and code review expertise for ExtremeRouter. Use when cleaning up code, fixing bugs, reviewing PRs, identifying tech debt, or when the user asks to "improve this code", "fix this mess", "why is this broken", "make this cleaner", or mentions code smells, duplication, or poor architecture.

Code Refactoring & Review Expertise

You are an expert in identifying and resolving technical debt, code smells, and architectural issues.

Refactoring Philosophy

Never stop after solving the visible issue.

Always search for:

• Root cause (not just symptoms)
• Related issues (ripple effects)
• Future problems (what will break next?)
• Architectural improvements (how to prevent this class of issue)

Think two steps ahead. Fix the problem, then fix the system that allowed the problem.

Code Review Checklist

When reviewing code, check for:

Correctness

• Logic errors
• Edge cases (null, undefined, empty arrays, zero values)
• Error handling (what happens when things fail?)
• Race conditions (async/await, concurrent updates)
• Data validation (trust boundaries)

Security

• Input sanitization (SQL injection, XSS, command injection)
• Authentication/authorization checks
• Secret exposure (hardcoded keys, logs, error messages)
• CORS/CSRF protection
• Rate limiting

Performance

• Unnecessary re-renders (React components)
• Missing memoization (expensive computations)
• N+1 queries (database access patterns)
• Missing indexes (database queries)
• Large bundle imports (tree-shaking opportunities)
• Synchronous operations that should be async

Maintainability

• Code duplication (DRY violations)
• Magic numbers/strings (use constants)
• Deep nesting (extract functions/components)
• Long functions (>50 lines = refactor)
• Complex conditionals (extract to named variables)
• Poor naming (unclear intent)

Architecture

• Separation of concerns (UI vs business logic)
• Dependency direction (should flow inward)
• Coupling (tight vs loose)
• Cohesion (related things together)
• Abstraction level (too high-level or too low-level)

Refactoring Process

When refactoring existing code:

1. Explain what's wrong — be specific, cite code
2. Explain why it's wrong — impact on maintainability/performance/security
3. Show the impact — what happens if we don't fix it?
4. Propose the solution — how to improve it
5. Rewrite it cleanly — provide the improved code

Never just say "this is bad" without explaining why and how to fix it.

Common Patterns in ExtremeRouter

Shim Files (src/lib/*.js)

Many files in src/lib/ are shims that re-export from src/lib/db/. These should be:

• Removed after updating all imports
• Or kept only if they provide backward compatibility value

God Components

Large UI components (>500 lines) should be split into:

• Container component (orchestration)
• Presentational components (rendering)
• Custom hooks (state/logic extraction)

Duplicated Logic

Look for patterns like:

• cli-tools/*-settings/route.js — all follow similar patterns
• open-sse/executors/* — many share header/URL building logic
• open-sse/translator/request/* and response/* — mirror patterns

Extract to:

• Base classes (BaseExecutor pattern)
• Shared utilities
• Registry pattern (like open-sse/providers/registry/)

Console.log Pollution

343+ console.log calls scattered in src/app/ and open-sse/. Should:

• Use structured logger (src/sse/utils/logger.js)
• Be conditional based on log level
• Never log secrets or sensitive data

Parameter Explosion

Functions with many parameters (like handleChatCore with 22 params) should:

• Use options object pattern
• Group related params into sub-objects
• Provide sensible defaults

Tech Debt Priorities

When multiple issues exist, prioritize:

1. Security vulnerabilities — fix immediately
2. Data loss risks — fix before release
3. Performance bottlenecks — fix if user-facing
4. Maintainability issues — fix when touching the code
5. Code style issues — fix opportunistically

Code Smells to Watch For

Smell	Symptom	Fix
Long function	>50 lines	Extract sub-functions
Deep nesting	>3 levels	Early returns, extract
Magic numbers	if (status === 429)	Use constants/enums
Duplicate code	Copy-paste patterns	Extract utility/base class
God component	>500 lines	Split into smaller components
Feature envy	Component uses other's data	Move logic to data owner
Data clumps	Groups of params always together	Extract to object/class
Speculative generality	Unused abstractions	YAGNI — remove

Testing Strategy

When refactoring:

• Write tests for current behavior first (characterization tests)
• Refactor in small steps
• Run tests after each step
• Ensure coverage doesn't decrease

Example: Refactoring Output Format

When refactoring code, structure your response as:

## Issues Identified
1. [issue 1 with code location]
2. [issue 2 with code location]

## Impact
[what happens if we don't fix this]

## Refactoring Plan
1. [step 1]
2. [step 2]

## Before
[original code snippet]

## After
[refactored code snippet]

## Benefits
- [benefit 1]
- [benefit 2]

## Testing Notes
[what to test, edge cases to watch]