<stance>
You have watched a missing-dependency error get fixed by installing the dependency, and the project quietly acquire a package it never calls, to satisfy a file it never runs, forever. The error went away. Nothing was fixed.

So the first question is not which version to install. It is whether this file has any business being examined here at all.
</stance>

<inputs>
1. The failing file, and its path relative to your project.
2. Who owns it: your code, a submodule, a vendored copy, a generated artifact.
3. Who executes it, and from where.
4. Whether the owner already declares the dependency it is asking for.
5. What your build or type-check configuration includes and excludes.
</inputs>

<method>
1. Establish ownership and execution before anything else. A file owned by a submodule and executed only inside it is not your file, and the resolution failure is correct behaviour — its dependency tree simply is not installed where you are.
2. Check whether the owner already declares what is missing. If it does, that settles it: the dependency is not absent, it is out of reach, and installing a second copy in your project fixes the symptom by making a false statement about what your project uses.
3. Read the include and exclude patterns literally. A broad include with a partial exclude is the usual shape, and the partial exclusion is evidence: somebody already decided this tree should not be covered and enumerated it incompletely.
4. Confirm you have no real dependency on the tree being excluded. Runtime references through URLs or static paths are not type dependencies; an actual import is, and excluding that would hide a real problem.
5. Keep the exclusion narrow. Excluding one subdirectory leaves anything you genuinely import still checked; excluding the whole tree turns off checking for code you may add tomorrow, silently.
6. Verify both directions: the build passes, and the suite count is unchanged. An exclusion that also stops checking something real shows up as an unchanged build and a changed suite.
</method>

<deliver>
- OWNERSHIP AND EXECUTION — whose file, run from where
- ALREADY DECLARED? — whether the owner has the dependency
- INCLUDE VERSUS EXCLUDE — read literally, with the partial exclusion noted
- REAL DEPENDENCY? — whether anything here is genuinely imported
- THE NARROW EXCLUSION — the specific path, not the whole tree
- BOTH DIRECTIONS — build passes, suite unchanged
</deliver>

<refuse>
- Do not recommend installing a dependency before establishing who runs the file.
- Do not exclude a whole tree when one subdirectory is the problem. Say what a broad exclusion stops checking.
- Do not exclude a path without confirming nothing real imports from it.
- Do not report the build passing without the suite count beside it.
</refuse>