feat(intelligence): Phase 5 language-specific enrichment (RAN-162)

[aksOps]

Summary

• Implements Phase 5 of the Repository Intelligence layer: language-specific extractors for Java, TypeScript/JavaScript, Python, and Go
• LanguageExtractor interface + LanguageExtractionResult record in intelligence/extractor/
• LanguageEnricher Spring component auto-discovers extractor beans and runs after LexicalEnricher in EnrichCommand
• JavaLanguageExtractor: CALLS edges via JavaParser MethodCallExpr, type hierarchy hints (extends_type, implements_types)
• TypeScriptLanguageExtractor: import-to-symbol resolution (named + default), JSDoc @param/@returns type hints; also handles .js files via language alias
• PythonLanguageExtractor: from module import X + import X resolution, def fn(x: int) -> str type hint extraction
• GoLanguageExtractor: block/single import resolution, structural interface satisfaction detection
• 36 tests covering positive, negative, confidence assertion, determinism, failure resilience

Test plan

• JavaLanguageExtractorTest — 8 tests: call edges, type hierarchy, wrong language, no registry, determinism, confidence EXACT/PARTIAL
• TypeScriptLanguageExtractorTest — 7 tests: named/default imports, JSDoc hints, empty, confidence, determinism
• PythonLanguageExtractorTest — 8 tests: from/plain imports, type hints, self-param exclusion, null content, confidence, determinism
• GoLanguageExtractorTest — 7 tests: block/single imports, unknown import, null content, confidence, determinism
• LanguageEnricherTest — 6 tests: no extractors, pipeline edges, type hint propagation, failure resilience, JS→TS alias, extension mapping
• EnrichCommandTest — existing 3 tests updated to compile with new constructor
• Full mvn test — all tests pass

🤖 Generated with Claude Code

[aksOps]

Code re-review (RAN-164 fixes)

Original issues A and B are correctly fixed. Found 1 new issue:

1. ** — duplicate IMPORTS edges when file uses both import styles**

   applies IMPORT_SINGLE_RE (lines 82–90) and IMPORT_BLOCK_RE (lines 93–104) independently with no deduplication. A Go file using both styles for the same package (e.g. import "fmt" AND a block import ( "fmt" )) will emit two IMPORTS edges with identical source, target, and kind. GraphBuilder.flush() does not deduplicate edges by (source, target, kind) before persisting to Neo4j. Fix: collect paths into a LinkedHashSet before building edges, or perform a set-union of the two regex results.

   https://github.com/RandomCodeSpace/code-iq/blob/eb049ceae6a375080f9ede7281610c18e4197cbf/src/main/java/io/github/randomcodespace/iq/detector/go/GoLanguageExtractor.java#L80-L106

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[aksOps]

Code review

RAN-164 and RAN-170 fixes verified. Found 3 issues:

1. GoLanguageExtractor.extractInterfaceHints() builds satisfied list by iterating registry.values() (unordered Map) and calls String.join(", ", satisfied) without sorting first — same input produces different satisfies_interfaces hint ordering across JVM runs. (CLAUDE.md says "Determinism is Non-Negotiable: Same input MUST produce same output, every time")

https://github.com/RandomCodeSpace/code-iq/blob/f7390b7be69dcbbfebacaf5a4b6ec49a5c1a557f/src/main/java/io/github/randomcodespace/iq/intelligence/extractor/go/GoLanguageExtractor.java#L138-L153

2. TypeScriptLanguageExtractor.extractImportEdges() collects edges into a plain ArrayList and runs both NAMED_IMPORT and DEFAULT_IMPORT matchers with no deduplication — the same (source, target) pair can be added twice, producing duplicate IMPORTS edges. This is the same class of bug just fixed in Go (RAN-170).

https://github.com/RandomCodeSpace/code-iq/blob/f7390b7be69dcbbfebacaf5a4b6ec49a5c1a557f/src/main/java/io/github/randomcodespace/iq/intelligence/extractor/typescript/TypeScriptLanguageExtractor.java#L74-L111

3. PythonLanguageExtractor.extractImportEdges() handles from module import symbol by discarding the module and looking up the symbol name alone (registry.get(sym)). Common names like join, get, load will match any identically-named node in the registry, producing false-positive IMPORTS edges. JavaLanguageExtractor addressed the same pattern with lookupByLabel() dropping ambiguous multi-match results; Python has no equivalent guard.

https://github.com/RandomCodeSpace/code-iq/blob/f7390b7be69dcbbfebacaf5a4b6ec49a5c1a557f/src/main/java/io/github/randomcodespace/iq/intelligence/extractor/python/PythonLanguageExtractor.java#L74-L94

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[aksOps]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

All three issues from the previous review verified fixed in 00b62f5:

• GoLanguageExtractor determinism: Collections.sort(satisfied) before String.join — guaranteed alphabetical ordering of satisfies_interfaces hint
• TypeScriptLanguageExtractor dedup: LinkedHashSet<String> seen guards both NAMED_IMPORT and DEFAULT_IMPORT paths — duplicate IMPORTS edges impossible
• PythonLanguageExtractor ambiguity guard: lookupUnambiguous() mirrors JavaLanguageExtractor.lookupByLabel() — returns null when multiple nodes share the same label, eliminating false-positive IMPORTS edges for short names like join, get, load

Regression tests for all three cases pass. PR #29 approved for merge.

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[aksOps]

Code review

Found 4 issues:

1. LanguageEnricher iterates nodesByFile (a HashMap) without sorting — non-deterministic edge ordering (CLAUDE.md says "No Set iteration without sorting first (TreeSet or stream().sorted())" and "Same input MUST produce same output, every time")

https://github.com/RandomCodeSpace/code-iq/blob/6003cb82f480bf7091ec175bc2a311f63c35b6bc/src/main/java/io/github/randomcodespace/iq/intelligence/extractor/LanguageEnricher.java#L70-L83

HashMap.entrySet() iteration order is non-deterministic across JVM runs. Files are processed in unpredictable order, so edges are appended to the result list in different order each run. Fix: replace with TreeMap at construction time, or sort entries by key before iterating.

2. GoLanguageExtractor.extractImportEdges uses registry.get(pkgName) with no ambiguity guard — false-positive IMPORTS edges (same class of bug fixed in Java via RAN-164 and Python via RAN-173)

https://github.com/RandomCodeSpace/code-iq/blob/6003cb82f480bf7091ec175bc2a311f63c35b6bc/src/main/java/io/github/randomcodespace/iq/intelligence/extractor/go/GoLanguageExtractor.java#L90-L97

pkgName is the last path segment (e.g. "utils", "http", "config"). A direct registry.get(pkgName) returns an arbitrary match if multiple nodes share that label, creating false-positive edges. Both JavaLanguageExtractor (lookupByLabel) and PythonLanguageExtractor (lookupUnambiguous) guard against this — Go should follow the same pattern.

3. PythonLanguageExtractor.extractImportEdges missing seen dedup set — duplicate IMPORTS edges possible (TypeScript added this guard in RAN-173)

https://github.com/RandomCodeSpace/code-iq/blob/6003cb82f480bf7091ec175bc2a311f63c35b6bc/src/main/java/io/github/randomcodespace/iq/intelligence/extractor/python/PythonLanguageExtractor.java#L68-L105

Both FROM_IMPORT and PLAIN_IMPORT patterns can match the same symbol in the same file (e.g. a file with both from os import path and import path). Without a Set<String> seen guard (like TypeScriptLanguageExtractor added), duplicate IMPORTS edges with the same ID are emitted. lookupUnambiguous does not provide dedup protection across pattern matches.

4. PythonLanguageExtractor silently drops aliased imports (from X import Y as Z) — edges for aliased symbols are never created

https://github.com/RandomCodeSpace/code-iq/blob/6003cb82f480bf7091ec175bc2a311f63c35b6bc/src/main/java/io/github/randomcodespace/iq/intelligence/extractor/python/PythonLanguageExtractor.java#L74-L82

The FROM_IMPORT pattern captures the full text after import, including aliases (e.g. "Path as P"). This string is passed directly to lookupUnambiguous which searches for a node labeled "Path as P" — no such node exists. TypeScriptLanguageExtractor strips aliases before lookup (sym = sym.substring(0, asIdx).trim()); the same fix is needed here.

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[sonarqubecloud]

Quality Gate failed

Failed conditions
2 Security Hotspots

See analysis details on SonarQube Cloud