Code Smell Analysis

You are performing a code smell review. Produce a structured report with concrete fix suggestions and accurate file:line references.

Smell Categories

Analyze code across these four categories. For each finding, classify it as:

• NEW: The finding is within lines that were added or modified (i.e., in + hunks of the diff)
• PRE-EXISTING: The finding is in unchanged code outside the diff hunks

If there is no diff context (e.g., analyzing files directly), omit the NEW/PRE-EXISTING classification.

Category A: Dead/Unreachable Code

• Unused imports (imported but never referenced in the file)
• Unused variables, constants, or functions (declared but never used)
• Commented-out code blocks (3+ lines of commented code, not doc comments)
• TODO/FIXME/HACK markers
• Unreachable code after return, throw, break, continue
• Unused type definitions or interfaces

Category B: Debugging Artifacts

• console.log, console.debug, console.warn, console.error in non-test application code
• debugger statements
• Hardcoded test values (e.g., hardcoded IDs, URLs to localhost, dummy data outside test files)
• Temporary workaround comments (e.g., "// temporary", "// workaround", "// hack")

Category C: Over-Engineering

• Pass-through wrapper functions that add no logic
• Types/interfaces used by only one consumer that could be inlined
• Generic type parameters that are only ever instantiated with one concrete type
• Single-implementation abstractions (interface with one implementing class)
• Unnecessary indirection layers

Category D: Copy-Paste / Duplication

• Near-identical code blocks (3+ lines) within the same file
• Similar patterns across different changed files (e.g., same fetch-then-transform logic)
• Repeated conditional structures that could be consolidated

Project Convention Exceptions — Do NOT Flag These

These patterns are NOT smells:

• Arrow functions as component definitions or handlers — project style
• Barrel exports (index.ts re-exporting from siblings) — intentional
• NestJS decorators (@Injectable(), @Module(), etc.) — framework convention
• React hooks patterns (useEffect, useMemo, useCallback) — standard React
• _-prefixed parameters (e.g., _event, _unused) — intentional unused marker
• Styled-components / Stitches / theme tokens — design system patterns
• GraphQL fragment/query definitions that appear "unused" in the file but are used via codegen
• Type re-exports from generated code

Relaxed Rules for Test Files

For files matching *.test.*, *.spec.*, *.stories.*, *.mock.*, or paths containing __tests__/, __mocks__/:

• console.log and hardcoded values are acceptable — do NOT flag them
• Still flag dead code (unused imports/variables) and duplication

Reporting Guidelines

• Precision over recall: If you're unsure whether something is a smell, note your uncertainty rather than asserting it as a finding. Prefer fewer, high-confidence findings over many marginal ones.
• No style suggestions: Do not flag formatting, naming conventions, or anything ESLint/Prettier handles. This is about structural code smells only.
• Accurate line numbers: Always reference the current file line number, not the diff line number.
• Actionable suggestions: Each finding must have a concrete "Suggestion" that says what to do.

Report Format

Use this exact format:

## Code Smell Report

**Branch**: `<current-branch>` vs `<base-branch>`
**Files analyzed**: N (K skipped: generated/non-code)
**Deleted files skipped**: M (only if M > 0)
**Findings**: X NEW, Y PRE-EXISTING

---

### NEW Findings

**[A1]** Dead Code | `<file-path>:<line>`
> <Description of the smell>
> **Suggestion**: <What to do>

**[B1]** Debugging Artifact | `<file-path>:<line>`
> <Description of the smell>
> **Suggestion**: <What to do>

(Continue with sequential IDs per category: A1, A2, B1, C1, D1, etc.)

---

### PRE-EXISTING Findings

(Same format as above. Omit this entire section if --new-only flag is set.)

---

### Summary Table

| Category | NEW | PRE-EXISTING | Total |
|---|---|---|---|
| A: Dead/Unreachable Code | 0 | 0 | 0 |
| B: Debugging Artifacts | 0 | 0 | 0 |
| C: Over-Engineering | 0 | 0 | 0 |
| D: Duplication | 0 | 0 | 0 |
| **Total** | **0** | **0** | **0** |

If there are zero findings in a section, write "No findings." under that heading.

After the report, add:

---
To fix a specific finding, say: "fix finding A1" (or any ID from above)