bug(setup): Effect 预发布版本漂移导致 npm 安装失败（ETARGET rc.114）

[qwertvgty]

想完成什么？

在干净环境中安装 OpenPI 打包产物，并完成 CI 的 Smoke-test packed Web CLI with locked Pi host 验证。

哪里不顺手？

2026-09-11，PR #492 的 Node 22.19.0 CI 在上述步骤执行 npm 安装时失败：

npm error code ETARGET
npm error notarget No matching version found for effect@^4.0.0-rc.114.

失败源码为 4f5b0f3b00652032fe946e0dc7ed16d3867b05c8。

当时的依赖声明中，effect、@effect/platform-node 和开发依赖 @effect/vitest 使用 ^4.0.0-beta.99；bun.lock 实际锁定为 4.0.0-beta.103。

打包产物的 npm 安装不会使用 bun.lock。检查 npm registry 时发现：

• @effect/platform-node@4.0.0-rc.114 已发布，要求 effect@^4.0.0-rc.114。
• effect 当时最高 RC 为 4.0.0-rc.113。
• @effect/platform-node-shared 同样存在允许后续预发布版本的依赖范围。

因此，锁定依赖的开发环境能够工作，但全新 npm 安装可能解析到不完整的预发布依赖组合。可按关联 CI 步骤执行 npm pack，再在干净目录中安装 tarball 和锁定版本的 Pi host 复现；具体错误受 registry 后续发布情况影响。

希望怎样表现？

发布产物在干净环境中能够安装，Effect 依赖组合与经过验证的版本保持一致。

建议通过独立依赖 PR 处理，避免混入 #492 的 Web admission 修复。候选方案是固定 Effect 预发布版本，并同时约束 platform-node-shared，补充防漂移检查和打包安装验证。

本地候选修复将相关包固定到 4.0.0-beta.103 后，干净目录 npm 安装成功，打包 Web CLI 能启动，首页及三个静态资源均返回 200。该结果不代表全量 CI 已通过。

截图或参考

[失败的 CI Job](https://github.com/openpi-dev/openpi/actions/runs/34573716389/job/103181326891?pr=492)

关联 PR：#492。该依赖修复已从其分支移除，拟独立跟踪。

运行环境

• CI：GitHub Actions，Ubuntu，Node 22.19.0。
• 本地候选修复验证：Windows，Node 24.18.0，npm 11.16.0。
• OpenPI manifest：0.8.1；Pi host：0.85.1。
• 安装方式：npm pack 后在干净目录安装 tarball。

---

[ooiuuii]

Confirmed: this also blocks #532 and #534 on unchanged package/lock/CI files.

• test(model-info): cover cache usage observation boundaries #532 (b409b2b): CI run. Node 22.19.0/24/26 check and complete tests, Web E2E and Windows tests pass; all three Linux jobs fail at the packed Web CLI/locked-host install.
• fix(web): keep mobile sidebar keyboard focus in the visible drawer #534 (fed8270): CI run. The same code/test gates pass, including all 15 Web E2E cases and Windows tests; the packed install fails with the same ETARGET effect@^4.0.0-rc.114.
• Fresh official-registry checks on 2026-09-11 still return 404 for effect/4.0.0-rc.114, while @effect/platform-node and @effect/platform-node-shared rc.114 exist and require effect@^4.0.0-rc.114. Our frozen Bun installation uses the beta.103 cohort. There is no registry-recovery evidence to justify simply rerunning these failures yet.

This appears to need the standalone package-install correction already described here, rather than changes to the cache tests or sidebar behavior. Could you link the candidate branch or planned dependency PR mentioned in the report? Is pinning the tested beta.103 cohort, including platform-node-shared, the intended short-term maintainer direction? That would let the affected PRs pick up the shared fix once accepted, while keeping their original scopes intact.

No checks have been skipped or marked successful, and neither feature PR changes the dependency policy.

[627150795]

我来处理这个问题，范围限定在仓库的 Effect 预发布依赖一致性与打包安装验证：核对 package.json/lockfile 中 effect、@effect/platform-node 与 @effect/platform-node-shared 的版本 cohort，补充防漂移校验和 packed-install 回归验证，保持业务功能范围不变。先在独立 worktree 基于最新 main 复现；完成本地验证后再提交 PR。