升级到release: dsh@0.1.2-alpha.1 后，不支持第三方模型了，添加提供方没有响应

[osd-wang]

之前配置的第三方模型可获取不到。

[liyangbing]

先不要删除 $DSH_HOME、settings.yaml 或 .credentials.yaml。从 alpha.1 的官方文档和测试看，第三方 provider 功能仍在：llm-pi-ai 的动态配置测试会通过 Settings 注册新 route、列出 model，并完成一次请求。因此目前这条信息还不足以证明 alpha.1 “不支持第三方模型”。

这次升级有一个值得先排除的边界：Models 页的 Client/Host Remote 调用从 rc.2 的单个 llm.providers({})，变成 alpha.1 的 listProviders() + listConfigurableProviders()，Settings/Credentials 的调用形状也一起迁移了。旧进程、旧页面、源码仓库的旧前端 bundle，或者混装的包闭包，都可能让点击在读取 provider 配置之前失败。

建议按以下顺序做一次无损排查：

dsh --version
dsh --profile web --dump-config > web-effective-config.txt
dsh plugin --profile web list --depth 0

然后：

1. 停掉所有旧的 DSH 进程，确认 shell 实际命中的 dsh 可执行文件；
2. 用同一个 web profile 重启，再对页面做一次硬刷新；
3. 如果是源码运行，先对当前 commit 执行官方要求的完整 build。alpha.1 CLI 文档明确说明源码启动不会检查已有前端 bundle 是否过期；
4. 点击 Add provider 时，同时记录浏览器 Console、失败的 /api 请求响应和 Host stderr；
5. 只检查 settings.yaml 中 llm-pi-ai 的 provider/model ID，不要公开 .credentials.yaml 或密钥值。

可以用第一个失败点快速定位：

• 点击后连草稿都不出现：优先看浏览器 bundle / Remote 兼容；
• 草稿出现但按钮不可用：检查 provider ID、base URL、protocol，以及是否至少有一个 model；
• Apply 后失败：保留 Settings mutation 的响应；
• 配置已保存但 picker 没 model：看 route 注册或 catalog 错误；
• model 可选但请求失败：再查 endpoint、credential ref 和网络。

如果方便补充 dsh --version、安装/升级方式、启动命令、浏览器 Console 错误、失败请求响应和对应 Host stderr（全部脱敏），就能把问题定位到具体层，而不是猜测配置损坏。

我把 alpha.1 源码差异、无损恢复步骤和完整验收条件整理在这里：
https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/getting-started/model-providers.md#recover-providers-after-an-alpha1-upgrade

补充：最近的源码生成物、第三方 Bundle、provider Settings、Session event 与 route/history 问题已经整理成 rc.2→alpha.1 五层 preflight，可在升级生产 profile 前逐项验证：
https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/getting-started/upgrade-and-rollback.md#rc2--alpha1-preflight-test-the-seams-that-actually-moved

[argszero]

Independent source verification of the provider-registry split (alpha.1, HEAD cd5ef81) — it supports the direction in the reply above and adds two concrete pointers:

1. The registry layer is not the regression. llm-pi-ai still declares its configurable-provider directory at the same settings namespace as before (NS = settingsNamespace('llm-pi-ai'), packages/llm/llm-pi-ai/src/index.ts:91); directory entries are derived from the same profiles() settings source, so a third-party provider configured under rc.2 (settingsPath ['providers', '<name>']) survives the upgrade. The directory is registered in a dormant posture — entries appear even before any route exists (packages/llm/llm/src/index.ts:534) — and is replaced atomically on change, so no upgrade step can blank the Models page.

2. The RPC surface really did change, and the new client hard-fails visibly. llm.providers({}) no longer exists anywhere in the client/api/sdk trees; the Models page now calls llm/listProviders + llm/listConfigurableProviders in parallel (packages/client/ui-settings-models/src/client/store.ts:215), and the store sets status = 'error' with an error banner if either RPC fails. A stale rc.2 frontend bundle that still calls the old llm.providers remote method would get a dead method and fail exactly as the report describes — click, nothing happens, no draft, no button.

3. Consequence for triage: if the Models page renders at all, both registry RPCs already succeeded (a failure would surface an error banner, not a silent no-op). So "Add provider → no response" most strongly implicates the served frontend bundle / host process being a different version than the alpha.1 server — checking which dsh executable is actually on PATH, confirming the served bundle is from the current build, and a hard refresh is the fastest way to confirm, per the diagnostics above.

[osd-wang]

用dsh分析了一下，使用flash模型、耗时15分钟、花费6元人民币。按dsh建议修改settings.yaml配置、这个问题解决了。

下面是DSH分析的原因和修改过建议：

1. 「添加提供方」没响应 + 已有第三方模型读不到 —— 根因
   触发点：settings.yaml 里 llm-pi-ai 分节中有一条 opencode 提供方配置，它列出的模型（如 ling-3.0-flash-free、gemini-3.5-flash-lite 等 6 个）都不在已安装的 pi-ai 0.84.2 内置目录中，而且该路由既没声明 api 协议、也没声明 baseURL。llm-pi-ai 的 resolveProfiles 对这种路由会直接抛错：

llm-pi-ai: provider "opencode" model "ling-3.0-flash-free" needs an api; the installed catalog does not describe it…

传播链（为什么一条坏配置能拖垮整个页面）：

llm-pi-ai 挂载时通过 installSettingsSection 注册 llm-pi-ai 设置命名空间，注册时会对已存分节执行 owner 校验 assertServiceable。
SettingsProvider.register() 解析存量分节并跑校验时不捕获异常——校验一抛，整个命名空间的注册就失败（这是该版本沿用的既有设计，有专门测试锁定）。
注册失败连锁导致：
llm-pi-ai 命名空间从 settings.describe 里整个消失 → Models 页读不到任何 pi-ai 提供方（minimax-cn、nvidia、agnes 全部"读不出来"，同时这些模型实际也无法使用）；
「添加提供方」卡片渲染需要命名空间视图（state.namespaces.get(addTarget.settingsNs)），命名空间没了 → 点击按钮后卡片无法渲染 → 看起来就是"点击没反应"。
验证（用你真实的 settings.yaml 脱敏后启动真实组合）：

修复前：llm-pi-ai 命名空间 MISSING、目录只剩 39 条休眠 catalog 条目、你的 4 个提供方全不在列；浏览器 e2e 中页面不显示任何已配置行、添加按钮点击无反应。
去掉 opencode 后：一切恢复正常。

2. DSH给出的修改建议：
   建议在 packages/settings/settings/src/index.ts：

新增私有方法 resolveStored()：把 schema 解析与 owner 校验分开。schema 拒绝的存量分节仍照旧失败注册（文档损坏要响亮失败）；owner 校验拒绝的（schema 合法但无法服务）分节，改为以组合值注册命名空间并记 warn 告警——与重载路径"保留最后好值"的行为一致。
register() 改用 resolveStored()。这样一条坏路由只会让该命名空间退化为空目录（Models 页保留、添加流程可用），不再拖垮整个命名空间。

[argszero]

Thanks for the root cause — I verified it against the alpha.1 tree and it corrects my earlier hypothesis: this is a server-side route-validation failure, not a stale client bundle. And the "no response" symptom is not a contradiction of my "if the page renders, the registry RPCs succeeded" note — the failure happens one layer earlier and is silently contained.

The exact mechanism (confirmed at source, HEAD cd5ef81).

1. A pi-ai route whose models are not described by the installed catalog and which declares no api/baseURL fails in resolveModelProfile-style validation: catalog.ts:853-861 (model "..." needs an api; the installed catalog does not describe it… / needs a baseURL…), via the invalid() throw at catalog.ts:619. An entirely uncatalogued route also fails at catalog.ts:834-837 ("resolves no models…").
2. That validation runs inside resolveProfiles() (config.ts:386+), which is invoked at plugin mount and on every settings change (llm-pi-ai/src/index.ts:160 and the memoized profiles() at :158-169, called eagerly at :169).
3. The throw does not crash the host or fail the RPC: the settings seam keeps a namespace's last good value for a stored section that fails to resolve (documented at index.ts:154-157). So the provider set stays empty (first mount) or frozen at the previous good value. llm.listProviders() and llm.listConfigurableProviders() then return successfully with an empty (or stale) result, the Models store renders it without an error banner, and clicking Add provider has nothing to act on — the exact reported symptom.

So the failure surface is not the wire split at all — it is that a route-validation error during config resolution is contained but invisible: the user had to run a full dsh analysis to learn that one settings.yaml route was the problem. The recovery (edit settings.yaml per the analysis) matches the source: the invalid route must either name its api/baseURL or be removed.

Improvement direction (worth its own discussion if maintainers agree): surface the swallowed validation error instead of a silent empty page. Two options from the current structure:

• The settings seam could expose the last resolve error per namespace to the configuration surface (so the Models page shows "route X is invalid: model Y needs an api").
• Or listConfigurableProviders() entries could carry a per-route validationError/diagnostic field alongside declared, letting the store render the problem inline rather than an empty list.

Either keeps the fail-loud posture the code already has for credentials (MISSING_CREDENTIAL at index.ts:180-192) while making config-time failures visible at the surface that caused them.