Name a dependency API only where the package supplies the name; reach the file that calls it

[patchstackdave]

The invocation inventory made two claims per record — a package and an API name — and only the first
was ever established by evidence. Tracing a value to a package does not make the name it is known by
part of that package's surface, and four shapes exploited that gap:

written in the app	recorded before	recorded now
loadConfig(), a local function re-exported from ./config whose body returns JSON5.parse(...)	json5.loadConfig	nothing here — json5.parse, from config.js
const log = createLogger(); log(...)	winston.log	nothing (winston.createLogger is still recorded)
const { pick: choose } = require("lodash"); choose(...)	lodash.choose	lodash.pick
const JSON5 = require("json5"); JSON5.parse(x)	json5.JSON5.parse	json5.parse

Each invents a name the package does not export. That is worse than recording nothing: a consumer
comparing the inventory against an advisory's affected functions finds a name no advisory contains,
and takes the absence of the real name as evidence about the real call.

The last row is the one that mattered most in practice — the app's alias for a module object appeared
in every symbol for a CommonJS default require, so the inventory's most common shape was also its
least matchable.

The commits, in the order they are meant to be read

1. Root a receiver chain through a new expression. function getDb() { return new Pool() }
   called as getDb().query() rooted at nothing, so the receiver came back untraceable — and
   untraceable is reported exactly like app code. A construction is a chain link like any other.
2. Report an API name only where the name came from the package. A trace now carries whether the
   name is the package's own; only a named trace produces a record. For a pass-through re-export the
   name comes from the module that imported it, since an intermediate module may have renamed it.
   Calls we can trace but cannot name are counted ambiguous — not as records, and not as correct
   local exclusions.
3. Report a receiver only where the package supplies its name. A named member keeps its exported
   name (promises.readFile for node:fs); a module object, a factory result and a re-export all
   yield the method alone.
4. Collect invocations from the local modules an entry file imports. One hop, entry files only,
   invocations only — no endpoints, no sinks, no recursion. This is where the removed records are
   replaced by the real ones: json5.parse is now read from the file that writes it, with a site
   pointing at that file. The bound is structural (reachable from an entry by a relative import) and
   asserted in both directions.

Method calls on dependency-derived values are deliberately untouched and now pinned by a test:
getDb().query() is still pg.query, because the method name comes from the package's surface even
when the receiver's name does not.

Verification

The first commit in this branch is a five-app reachability-ladder harness — one fixture app per rung
(reachable / api-called / imported / not-a-code-question / unknown) asserting what the map says
about a dependency, which is the input a consumer grades into a verdict. It reproduced this defect,
and the api-called rung goes green here: 33/33.

Each behavioural rule was mutation-checked — removed, and the suite confirmed to fail — so no test in
this branch passes for reasons other than the rule it names. Full suite 1100/1100, typecheck clean.

[coderbuds]

Implements one-hop module parsing and precise API naming to avoid spurious dependency calls.

🎯 Quality: 86% Excellent · 📦 Size: Extra Large — strongly consider breaking this down

🛡️ 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 77th PR — above team average · Averaging Good

_{See how your team is trending →}

[patchstackdave]

/review