pnpm 注入本地库时 workspace 相对路径找错目录：检查声明方基准

应用依赖两个本地库，其中一个库再通过 workspace:../lib-a 依赖另一个。开启 injectWorkspacePackages: true 后，pnpm 却去应用旁边找 lib-a，报 Could not install from，即使库目录明明存在。

pnpm 12.15.0 的这一条件出现在嵌套相对 workspace 依赖的注入解析。它与根配置 overrides 中的相对路径改写是两条路径；根 override 已能正确重定位，不表示库内部清单的相对选择器也被覆盖。

先把每条边的声明目录画清楚

例如已有目录是：

repo/
  apps/main/
  libs/lib-a/
  libs/lib-b/

应用依赖 lib-a、lib-b，而 libs/lib-b/package.json 内写：

{
  "dependencies": {
    "lib-a": "workspace:../lib-a"
  }
}

这条路径应相对 lib-b 的清单目录，即 libs/lib-a。受影响解析可能沿用消费方 apps/main，于是寻找 apps/lib-a。不要因为错误里少一个目录就真去那里复制一份库，那会制造第二份来源。

先核对所有目标都在实际 workspace 成员范围内、包名正确，再对照失败路径与声明位置。成员根本没被收集，或本地包名与依赖键不一致，不属于这个基准问题。

目标包名唯一时，评估具名 workspace 引用

若两个库确实都是当前工作区成员，且目标名唯一、版本约束允许，可在 lib-b 的清单中改用按包名查找：

{
  "dependencies": {
    "lib-a": "workspace:*"
  }
}

保留原来的注入配置，用实际包名替换示例。原先有明确版本约束时，应写出相应的 workspace 版本范围，不能为了绕过路径把约束全部放宽。具名引用不依赖这条相对路径基准，但它也明确要求目标属于 workspace；不是用来任意指向工作区外目录。

将相同路径改成 file: 可以走另一条声明方目录处理，已有对照表明它能绕开这次错基准。但 file: 与 workspace 在链接、交付和本地包语义上并非任意等价，尤其涉及 peer 依赖或发布流程时，不应把它作为无条件替换。

验收注入后的实际消费入口

保存清单、workspace 配置与锁文件，按原流程重新解析，审查锁文件中库及它的嵌套依赖来源，再从 apps/main 的真实入口导入 lib-b，让它实际加载 lib-a。只检查 lib-b 自己目录能导入，不代表应用的注入副本也正确。

覆盖干净安装与后续本地库变更后的流程，确认注入更新仍符合项目约定。无需关闭全部注入或清空共享 store。12.15.0 正式解析器仍只对相应 file: 子选择器改写声明方基准；后续升级须用同一嵌套结构回归，不能只复查根 override 的既有用例。