## Circular Dependencies (Medium)

### Trigger Signals

- `import A` where module A also `import`s the current file (direct cycle)
- Dependency chain A→B→C→A exists between modules (indirect cycle)
- Dynamic imports (`import()` dynamic import) break the cycle but indicate architectural issues

### Judgment Process

1. **Build dependency graph**: `Read` extracts `import`/`require` statements from changed files, marking dependency relationships
2. **Detect direct cycles**: `find_references` checks whether imported modules import the current file
3. **Detect indirect cycles**: recursively check imports of imported modules (up to 3 levels), build dependency chains, and detect cycles
4. **Assess impact**: `Read` confirms the actual impact of circular dependencies:
   - Whether it causes undefined at runtime (module referenced before initialization completes)
   - Whether dynamic imports have been used as a temporary workaround
5. **Identify coupling issues**: even without cycles, `Read` identifies excessive coupling:
   - Utility modules imported by business modules (should be one-way dependency)
   - Low-level modules referencing high-level modules (dependency inversion violation)

### Evidence Construction

After confirming a defect, the output must include:
- Circular dependency chain (complete path A → B → ... → A)
- Impact assessment (runtime error/undefined risk/architectural issue)
- Recommended solution (extract common module, dependency injection, event decoupling, dynamic import)

### Exclusions

- Cycle already broken through dynamic imports (`import()`)
- Mutual references between type declaration files (`*.d.ts` mutually importing via `import type` does not affect runtime)
- Tightly coupled modules in the same directory (e.g., `index.ts` re-exports)
- Framework conventions (e.g., Next.js page/layout mutual references)
- Dependency chains involving third-party packages (third-party dependencies are not visible, cannot confirm internal package reference relationships)
