map: inventory every imported package, and mark the ones we cannot model

[patchstackdave]

Why

A sink is only recorded for the few API families the extractor models, and only inside a recognized handler. That makes the sink list the wrong instrument for the question a vulnerability correlator actually asks — does this app use package P, and can input reach it? — because P may be used heavily through an API we have no recognizer for, or from a file with no entry point in it.

Answering from the sink list yields "no flow", which reads as not reachable and closes a real vulnerability. That is the worst direction to be wrong in, and it is silent.

What

Two additions, both additive on schema v3 — a v3 reader that ignores them stays correct, and bumping would make every existing consumer (including the Pulse ingest gate) reject the document instead.

SiteInputMap.imports — every package the app imports, from all source files rather than only the ones holding an entry point, because an AI-built app keeps its data layer in a file with no handler in it. Per package: the specifiers as written (so a subpath-scoped advisory like lodash/merge stays matchable), the bound names where the file was parsed, capped import sites, and a total count.

Files with no entry-point signal are not parsed — they are scanned with TypeScript's own pre-processor. Token-accurate (a specifier inside a comment or string is not an import) and cheap enough to run over every file. The mixed fidelity is reported as namesComplete rather than smoothed over: a partial name set must never be read as proof a name is absent.

ImportedPackage.recognizedSinkKinds — which sink families the extractor can model for that package. Empty means the map cannot answer a dataflow question about it at all. A vulnerability in such a package stays "needs review"; it can never be closed as unreachable on the strength of this map.

Path aliases are excluded. Every AI-built app maps @/* to ./src/*, and those entries would otherwise land in the unmodelled bucket and inflate exactly the number a reviewer acts on. Read from tsconfig/jsconfig paths — tolerantly, since those files ship with comments and trailing commas — with an npm-name check as the backstop when there is no config to consult (@app/* is indistinguishable from a real scoped package by name alone, which is why the config is read rather than guessed).

The CLI summary now reports both counts, since a reader who only sees flows would never learn how much of the dependency surface the map cannot speak to:

patchstack: 4 entry point(s), 4 input(s), 7 sink(s), 4 proven input→sink flow(s) [tanstack-start].
patchstack: 66 file(s) found — 6 analysed, 60 skipped (no server entry point). …
patchstack: 53 package(s) imported — 52 with no recognized sink family, so a vulnerability in
those cannot be judged reachable or unreachable from this map.

Verification

• 14 new tests; 964 passing, typecheck clean.
• The guard case is explicit: an endpoint that reads an input and calls into an unmodelled package produces no sink — and the test asserts that this is exactly why recognizedSinkKinds has to exist.
• Run against the real Lovable reference app: 53 packages, 52 unmodelled, aliases correctly excluded, inventory ~12KB of a ~19KB document.

[coderbuds]

Comprehensive import inventory feature with detailed reporting and strong tests.

🎯 Quality: 96% Elite · 📦 Size: Large — consider splitting if possible

🛡️ Standards: no pre-flight fit check ran for this change — wire assess-change-fit into your coding agents to catch size before opening.

📈 This month: Your 57th PR — above team average · Averaging Excellent

_{See how your team is trending →}

[patchstackdave]

/review