Start with the ID scheme, because it is the part that already got the design right. Function nodes in the graph are keyed as `function:${op.filePath}:${op.functionName}`, built at `src/graph/index.ts:452` [5]. That makes `getOrder` in `src/handler.ts` and `getOrder` in `experiments/handler.ts` two distinct nodes with two distinct sets of outgoing edges [5]. The graph knows they are different. The lookup then threw that away by matching on `n.name` alone, so which node came back depended on the order the AST scan happened to walk the file tree [6].
The blast radius is not the lookup. It is what the caller does next. `analyze_function` is the tool an assistant is supposed to call before writing a handler, and it reports which tables the function queries, how it queries them, which permissions the role is missing, and the trigger's event shape [4]. The author's worked example: the scratch file in `experiments/` queries `public.users`, while the real handler scans `public.orders` and carries a high-severity finding attached to that scan [7]. The assistant gets `found: true`, a real path, real table accesses, real findings [7]. It concludes the function it is editing touches `users`, has no scan problem, and needs no index work [8]. Every downstream decision is coherent and built on the wrong file [8].
Now the argument I think is correct. Unread and stale are conditions [2][3][9]. You can attach metadata to a condition: a per-source status, a read timestamp and an age [2][3]. Wrong-candidate resolution is a property of the function signature [10]. A lookup that returns one thing when two things matched has already destroyed the evidence that a choice was made, and no metadata bolted onto the response can reconstruct it [10]. This is why the two shipped fixes are silent here. Both report, correctly, that everything worked [9].
Count the failure classes the author now has open and note the asymmetry: three issues, #101, #102, #103 [2][3][9], and only the third produces a response in which every field is a real value read from a real source seconds ago [9]. Two out of three are instrumentable at the transport layer. The third is only fixable at the call site, by making the resolver return candidates and forcing the caller to disambiguate or refuse.
For transfer to your own tool, the condition is narrow and checkable. You need two things to be true at once: a namespace where the same name legitimately appears more than once, and a resolver that collapses that namespace to a scalar. Monorepos with `experiments/`, vendored copies, generated clients, and fixture directories all satisfy the first. Any `.find()` on a name satisfies the second. The author found the same shape a second time in the AST scanner, issue #44, where resolving an identifier to its string value did a file-wide search for a variable name and returned the first declaration regardless of the call site's scope [11].
The reason this survives review is that it never looks like a bug. A permissions error is annoying and honest: you retry, you fix the role, you move on [12]. A well-formed answer about the wrong file is worse than an error, because nothing in the workflow is designed to catch it, and nobody double-checks a response that looks perfectly correct [12]. The one grim detail is that the author learned about it from a comment describing the same bug in a tool he did not build, on an MCP codebase-intelligence server, which answered with a file path, a definition, and a list of references, all well-formed, all about the shadow definition [1].
