pnpm 冻结安装成功，新加的 workspace 命令却找不到

CI 的 pnpm install --frozen-lockfile 提示锁文件已是最新，接着执行新命令却退出 127。若刚切到给 workspace 包新增 bin 的分支，先比较依赖方 node_modules/.bin 与该工作区包的 package.json。

pnpm 12.15.0 的明确条件是：已有安装结果、工作区包增加一个 bin 入口、依赖版本和锁文件都没变化。旧命令仍存在，新命令没有被重新链接。仅关闭 optimistic repeat install 也不能保证触发这次链接。

bin 文件存在，不代表依赖方已经有命令入口

例如成员包原清单只有：

{ "name": "a", "version": "1.0.0", "bin": { "a-one": "one.js" } }

随后新增 "a-two": "two.js"。依赖方仍通过 "a": "workspace:*" 使用它，package version 没变，新增文件也已经检出；但复用 node_modules 的安装可能只保留 a-one。

先确认工作区成员确实被 pnpm-workspace.yaml 包含，bin 目标存在、路径相对成员包正确，脚本具有合适的 shebang。若命令链接已经存在而执行报解释器错误，应查入口文件与运行环境；那不是“漏链接”。

重建链接时保留依赖约束

保留原清单、锁文件与安装日志，在项目允许执行依赖构建脚本的受控环境中，可以评估已有的 rebuild 入口：

pnpm rebuild

这条命令会重建包，并不是只读检查。该故障条件下，重建能够重新处理链接；项目的构建许可、环境依赖和生命周期脚本仍须遵守原约束。不能为了补一个 bin 放开所有未获准的脚本。

执行后直接检查依赖方的 .bin 是否包含两个命令，再通过原 CI 脚本执行 a-two。只在成员包目录运行 node two.js，没有覆盖依赖方的命令查找路径。

也可以在不复用旧 node_modules 的独立构建目录，以审定锁文件进行正常冻结安装，确认新入口在完整安装中存在。不要为了强迫锁文件变化而随意升级成员版本，也不要删掉整份锁文件重新解析所有依赖。

手动删除内部工作区状态文件虽可改变重复安装判断，却依赖 pnpm 的内部缓存格式；直接在 .bin 创建软链则无法证明下一次安装仍可重建。它们都不适合作为长期的团队安装流程。

用跨分支复用条件复查

验收应保留“上一分支已安装、下一分支只增加 bin、锁文件不变”的条件，确认安装或受控重建后新旧命令都能执行，锁文件没有产生未审查的依赖变化。还要检查下一次重复冻结安装，避免仅当前机器靠手工状态暂时正常。

本处理针对 12.15.0 的这条工作区变化检测路径，不承诺所有 command not found 都由它引起。后续正式修复后，再用原分支切换流程验证能否省去临时 rebuild。回退时恢复配套包版本、配置和安装产物，不在共享 store 中作范围不明的清理。