TS workspace and path aliases are never resolved, so impact graphs of aliased modules are empty

[zaebee]

Found while preparing a controlled graph-vs-ablated experiment in agent-dating (pre-registration: docs/experiments/context-graph-v2/). 8 of its 15 tasks are cal.com, and so are all 6 strict graph/ablated pairs in the existing benchmark corpus.

Symptom

On cal.com, get_impact_graph for the most-imported modules in the repository returns the module node alone. packages/lib/hooks/useLocale.ts is called from 318 places, and its impact graph is 1 node, 0 edges — so the Guardian prompt's impact section says nothing about who depends on the change, which is the main thing the graph arm is meant to add.

Root cause

Imports through a workspace package name or a tsconfig path alias are recorded with the alias as the target and never mapped to the module they name:

edges targeting the module node  packages.lib.hooks.useLocale         0
IMPORTS edges targeting          @calcom.lib.hooks.useLocale        256
CALLS edges targeting            packages.lib.hooks.useLocale.useLocale  318

get_impact_graph walks incoming edges from the module node, and the module node has none. The callers exist, but they hang on the function node, which the walk from the module never reaches.

Extent

Share of IMPORTS edges whose target is an internal node, measured on the workspace graphs:

repo	IMPORTS	resolved to an internal node	target still @…
cal.com	6,009	14%	56% — @calcom.* alone is 2,775
grafana	25,304	41%	29%
sentry	108,136	74%	3%

Beyond @calcom/*, cal.com also imports through tsconfig aliases (@lib/*, @components/*). Grafana is partly affected — its @grafana/* packages are workspace packages too — though its impact graphs are not empty.

Repro

uv run python -m cgis.cli ingest .martian-workspace/calcom__cal.com --output /tmp/cal.db
sqlite3 /tmp/cal.db "select count(*) from edges where target='packages.lib.hooks.useLocale'"   # 0
sqlite3 /tmp/cal.db "select count(*) from edges where type='IMPORTS' and target like '@calcom.%'" # 2775

Likely direction

Resolve a TS import target via (1) package.json workspace names → package directory, and (2) tsconfig compilerOptions.paths, before it is written as an edge target. An unresolvable alias should stay visibly unresolved rather than become a plausible FQN — the same principle as language_for in extractors/registry.py.

Also noticed, cosmetic

• Node.language defaults to "python" (core/models.py:103) and TypeScriptExtractor never sets it, so every TS node is stored as python. Nothing reads the field outside the store, and the prompt's code fence comes from the extension (guardian(collector): TypeScript context is silently dropped — .py filter plus the wrong FQN helper #344), so it does not reach the model.
• query/render/mermaid.py derives internal node slugs with the Python file_path_to_module_fqn, so every TS node falls back to _fqn_slug. Labels and edges are unaffected.