Found while tracing source-owned export linkage for #487 (tracker #416).
Program.resolveImports and loadImportClosureImpl only visit top-level import_decl, not export_decl module references. With an entry-only tsconfig, re-exported files are not loaded/checked. The same invalid leaf is diagnosed when explicitly listed as a root. Repeated import resolution also appends duplicate graph edges instead of rebuilding the current dependency set.
Permanent fair audit: seven ordinary graph forms (imports, named/star/namespace/type-only re-exports, cycles, diamonds), each with entry-only/all-files roots and positive/negative pairs. Negative cases only append a wrong local assignment in the leaf. All compilers receive identical files, roots and strict/noEmit/noLib/skipLibCheck settings. Exact TS 6.0.3 and native TS 7.0.2 both pass 28/28; pre-change Home passes 13/28 (15 failures). Raw log: bench/vs_tsgo/results/reexport-discovery.rFhIvz/audit-before.log; frozen Home is the previous global-consumer.xZ8NXj/home-final binary.
The audit also exposes false TS2305 for locally re-exported imported bindings and false TS2308 when cycles/diamonds re-export the same original declaration. Those require real export-origin resolution, not suppressing ambiguity checks or accepting any duplicate name.
Required: load all static re-export targets; keep graph edges unique/current; preserve include provenance; follow aliases and cycles to actual owning declarations; distinguish same-origin duplicates from genuinely ambiguous exports. Add Program and shared CLI controls, retain all failures, and do not readmit typed graph timings merely because discovery is fixed. Actual generic/metadata linkage remains #487.