Please bump @earendil-works/pi-ai to 0.84.x — model picker missing GLM-5.3

[Tommy00748]

What happened?

The model picker in the Web GUI gets its catalog from the bundled @earendil-works/pi-ai provider data. The currently pinned version only lists GLM models up to glm-5.2, so newly released models such as glm-5.3 and glm-5.2-highspeed cannot be selected from the picker.

Details

• DSH version: 0.1.0-rc.7
• @deepseek-ai/dsh-llm-pi-ai@0.1.0-rc.7 pins @earendil-works/pi-ai: ^0.82.1
• pi-ai 0.84.2 adds glm-5.3 and glm-5.2-highspeed to zai.json / zai-coding-cn.json
• The web frontend itself has no hardcoded model IDs — the list is fully driven by the pi-ai provider data loaded server-side

Suggested fix

Bump the @earendil-works/pi-ai dependency to 0.84.x so the model catalog includes the latest Z.AI GLM releases. Verified locally via an npm overrides to 0.84.2: after restarting dsh web, the picker shows GLM-5.3 correctly.

[tianhao8687]

确认当前 master 的 dsh-llm-pi-ai/package.json 仍是 @earendil-works/pi-ai: ^0.82.1；由于 0.x caret 规则，该范围不会升级到 0.84。npm 当前最新版为 0.84.2，所以报告中的 catalog 缺失仍然成立。

建议把最低版本直接提升为 ^0.84.2，并更新 lockfile，而不是在 DSH 里硬编码 GLM-5.3。模型选择器本来就是 provider catalog 驱动，保持单一来源更合理。

升级前后应跑这些有针对性的检查：

• llm-pi-ai 的 catalog/discovery/config/convert/adapter 测试；
• 对 Z.AI 与 Z.AI Coding CN 两个 provider 断言能发现 glm-5.3 和 glm-5.2-highspeed；
• 用 mock stream 验证 pi-ai 0.84 的事件、tool call、reasoning 与 replay 字段没有破坏当前转换；
• build/hygiene/publint，确保发布包实际携带新依赖范围。

用户侧 pnpm.overrides 锁到 0.84.2 是合理临时方案，但需要注明它会影响所有共享 pi-ai 的路径；若出现流协议回归，应能一键撤销。最终修复应随下一组 DSH 包统一发布，避免主包和内部包再次落在不同 dependency train。

[weijiafu14]

报告和 @tianhao8687 的核实都成立。我这边有两件可能有用的：一份来自实际运行的升级信号，和一条关于版本范围本身的意见。

一、我们已经在 0.84.1 上跑了一段时间了

我维护 pi2dsh（把 Pi 生态插件翻译成 DSH 原生插件的兼容层）。它的依赖里钉着：

"@earendil-works/pi-ai": "0.84.1",
"@earendil-works/pi-coding-agent": "0.84.1",
"@deepseek-ai/dsh-llm-pi-ai": "0.1.1-rc.2",

也就是说：pi-ai 0.84.1 和 DSH 的 llm-pi-ai 装在同一棵依赖树里，我们的契约测试和真机端到端 example 全部在这个组合上跑绿。

这直接对上 @tianhao8687 检查清单里的第 3 条（"用 mock stream 验证 pi-ai 0.84 的事件、tool call、reasoning 与 replay 字段没有破坏当前转换"）：在我们覆盖到的范围内，0.82 → 0.84 没有出现流事件、工具调用、reasoning 或 replay 形状上的破坏性变化。

边界必须说清，否则这条证据会被高估：

• 我们跑的是我们自己翻译时用到的那些 Pi 侧面，不等于 dsh-llm-pi-ai 内部用到的每一条路径——它可能碰到我们碰不到的 API；
• 我们的 E2E 是真实端点、真实模型、真实工具循环（不是 mock），但场景集是我们的 example，不是 DSH 的全量回归；
• 我们钉的是 0.84.1，不是报告里说的 0.84.2。那两个补丁版之间我没有对比过。

所以这不是"升级安全"的结论，是一份来自另一个消费者的、覆盖面有限但真实的运行信号——比"没人试过"强，比"跑完 DSH 全量回归"弱。

二、^0.84.2 会把同一个陷阱往前挪一格

@tianhao8687 建议"把最低版本直接提升为 ^0.84.2"。方向对，但我想指出：caret 在 0.x 上的行为，正是造成这个 bug 的原因——^0.82.1 永远到不了 0.84，所以目录卡在 GLM-5.2。改成 ^0.84.2 之后，同样的事会在 0.85 发布时再发生一次，而且症状一样隐蔽：没人报错，只是模型选择器里缺了新模型。

我们为此立过一条明确的规矩，理由不是"我们更保守"，而是这件事没法自动发现：

Pi 兼容面钉死单一上游版本（当前 0.84.1）。规则、vendored 源码、类型快照只对这个版本负责，上游发新版不自动跟。理由：追上游"发现新接口"这一环纯靠人、没有自动提醒——与其带着无声漂移跑，不如显式锁死。升级是一次显式决策：重盘上游声明 diff、逐条归类新面、更新规则与文档，一次做完。

对 DSH 这条路，我觉得关键区别在于：pi-ai 对 DSH 而言主要是一份数据（模型目录），而数据是会持续变的。 一个"只在有人记得时才会动"的版本范围，对代码依赖也许够用，对目录必然过期——而过期的表现不是报错，是用户看不到新模型，也就是这个帖子。

所以我建议在提案里把选择摆成两条，各自成立：

1. 精确钉住 + 显式升级仪式（我们走的这条）："0.84.2" 不带 caret，配一个"新模型上线时跟进"的流程。好处是漂移永远是显式的；代价是需要有人管。
2. 让范围真的会动：既然目录是数据，就用一个真的会跟随的范围（>=0.84.2 <1）配上 lockfile 与升级测试。好处是新模型自动到位；代价是流协议回归可能随时进来——所以 @tianhao8687 那份检查清单必须变成 CI 门禁，而不是升级时手跑一次。

现在这个 ^0.82.1 是两者中间最差的位置：既不会自动跟随，也没有人在管——所以它一路卡到了两个大版本之后才被用户发现。

三、一个给现在需要 GLM-5.3 的人的提醒

报告里的 pnpm.overrides 锁到 0.84.2 是可行的（@tianhao8687 也确认了），补一句实操上的坑：overrides 是全局的，它会影响依赖树里所有共享 pi-ai 的路径。如果你同时装了其它也依赖 pi-ai 的第三方插件（这类插件不止一个），它们会被一起顶到 0.84.2 —— 多数情况下没问题，但出问题时症状会出现在一个和你的改动看起来无关的地方。所以建议改完之后留个记录，回归时第一个怀疑它。

边界与利益相关

我们不修 DSH 自家组件——dsh-llm-pi-ai 的依赖范围、模型目录都在 DSH 里。第一节是我们自己依赖树的事实与有限的运行信号，第二节是版本策略意见。

利益相关：我维护 pi2dsh，它也依赖 pi-ai，所以 DSH 升不升级会影响我们这边的依赖树是否需要装两份——这一点先说在前面。这条不推销：你要的是官方 bump 一个依赖范围，装我们的东西对此毫无帮助。