Extractor gaps found during a real run on a large polyglot repo: TS path aliases, Python in-function imports, memo() components, unhandled file types

Extractor gaps found on a large real-world run

Ran /understand --full against a large polyglot repo (~12,988 analyzable files: Python backend + TS web client + shell/CI config). The run completed with 100% node coverage (2,657/2,657 in scoped analysis), but the final report flagged three extractor bugs that cost real graph fidelity until the analyzer agents repaired them from source. Details below, all reproducible from that run.

1. TypeScript @/ path aliases unresolved

61 of 70 files under web/src had a completely empty import map — every import x from '@/lib/foo' specifier failed alias resolution, so intra-client dependency edges were all missing.

• Expected: tsconfig paths (at least @/*) honored during import extraction.
• Workaround used in-run: resolved all 293 specifiers deterministically against tsconfig and injected 269 edges.

2. Python in-function (lazy) imports invisible

Python codebases that late-import inside functions (common for avoiding cycles / expensive imports) were badly underconnected: assemble-reviewer measured only 11.7% import coverage on the Python tree before repair. An AST pass over the 1,693 in-scope .py files recovered 5,076 edges (+18%), which fixed 51 modules that had read as dead code (no incoming edges).

• Expected: import ast-based walk of ast.Import / ast.ImportFrom at all nesting levels, not just module level. Module-level-only extraction systematically makes lazy-imported modules look orphaned.

3. Missed constructs and file types

• React components defined as memo(() => ...) or plain arrow functions assigned to exports were not extracted as components.
• GitHub Actions workflow steps were not extracted (the CI job subgraph was nearly empty until agents rebuilt it from the YAML).
• No parser for .ps1, .html, .nix, .service, dotfiles, and extensionless files (e.g. s6-rc.d/**/run shell scripts). Agents recovered all of these from source, so no file was lost — but the extractor silently produced nothing for them, which reads as "no content" rather than "unsupported type".

Related mid-run repairs (possibly same root causes)

• 38 nodes emitted with an invented step node type (would have failed schema validation / been dropped, taking the CI subgraph with them).
• One node whose ID prefix contradicted its type field, silently dropping 3 edges.
• 2 factually wrong summaries caught against source.

Environment

• Plugin version: 2.9.7 (installed via claude plugin marketplace add)
• Platform: Claude Code CLI 2.1.273, Linux, Node 26
• Run mode: print mode (claude -p), all-Sonnet

Happy to provide the run's intermediate artifacts (fingerprints.json, batch outputs) or a minimized repro if useful. The analyzer-agent repair path worked well — but these feel all fixable deterministically in packages/core extraction.