Skip to content

chore(deps): define and enforce the supported Pi baseline #328

Description

@JS-banana

问题

OpenPI 当前同时表达了三种不同的 Pi 兼容边界:

  • README 标注 Pi 0.84.1+
  • package.json 开发依赖使用 ^0.84.1
  • bun.lock 将本地和 CI 实际固定在 0.84.1,而发布包的 Pi peer 依赖为 *

^0.84.1 允许全新安装解析到兼容的新版本,但 frozen lock CI 只验证锁定版本。现在 PR #269 暴露出这两种环境存在真实行为差异:Cursor 只能获得 output-only token delta,不能把它伪装成完整上下文 usage;Pi 0.84.1 对全零 usage 的纯新会话不会进入阈值压缩,而 Pi 上游从 0.84.3 起能够根据完整消息历史估算并触发压缩。

因此,manifest 的允许范围、默认锁定环境、README 支持声明和 CI 验证边界需要形成一个项目级策略,而不应由单个 provider PR 顺带修改。

Related: #269

已验证事实

建议决策

将完整 OpenPI 支持基线提升到 Pi 0.84.3+,并用独立 PR 完成项目级调整:

  1. 将 Pi 开发依赖的最低范围从 ^0.84.1 调整为 ^0.84.3
  2. bun.lock 刷新到当前兼容版本(目前为 0.84.4);
  3. 同步 README 的 Pi 支持声明;
  4. 增加最低支持版本与锁定版本的兼容验证,防止 caret 范围和 frozen lock 再次漂移;
  5. 用一份 proposed Decision / research record 保留事实、边界和替代方案。

PR #269 保持功能 PR 边界:

  • 不携带上述项目级版本升级;
  • 修复 provider 代码对 0.84.1/0.84.4 类型面的兼容;
  • 不伪造 Cursor token usage,不在 provider 内另造压缩生命周期;
  • 使用真实 Pi AgentSession 入口证明在项目支持基线上的行为;
  • 明确真实账号 E2E 与代理 E2E 的未验证边界。

替代方案

  • 保持 0.84.1 为完整支持基线: 必须明确 Cursor 自动压缩在该版本不可用,并把它作为 provider-specific 限制;不应在 provider 内复制或 patch Pi 的 compaction。
  • 只刷新 lock、不调整最低范围: 能修复默认 CI/开发环境,但 README 仍会承诺一个无法提供完整行为的最低版本,需要额外文档和最低版兼容测试。
  • 直接在 feat(ai-providers): add Antigravity and Cursor OAuth providers #269 升级依赖: 不采用;会把项目级兼容决策混入 provider 功能 PR。

验收

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions