Skip to content
OBSERVE. QUESTION. VERIFY.
04CASE FILE
Dependency evidence

Which version is actually in the room?

A documentation example and a local dependency may describe different APIs. Before changing application code, establish which version the project declares, which version the lockfile resolves, and what the failing environment actually loads. Those answers can differ.

Compare the three records

Read the package manifest and lockfile, then inspect the installed resolution using the project tooling. In a workspace, check which package owns the dependency and whether multiple versions coexist. Record the runtime version too. A transitive dependency can explain behavior even when the direct package declaration looks unchanged.

Match the source to the version

Consult official documentation or source for the resolved version. Find the specific symbol, argument, or return value involved in the failure. An upgrade is a proposed intervention, not evidence of the cause. First determine whether the mismatch comes from code, installation state, or an incompatible dependency constraint.

Should the lockfile be regenerated immediately?

Preserve the failing state first. Regenerating it can change many resolutions and remove the evidence needed to explain why the environment differed.

A question for your assistant

Read only. Identify the declared, locked, and installed versions relevant to [error]. Locate the API contract for the actual resolved version. Explain any mismatch with evidence. Do not install, upgrade, or regenerate dependency files.
CONTINUE THE INVESTIGATIONTest a theory