[提案] provider 配置的 profile 作用域缺少可见性：doctor 检出孤儿配置并给出迁移指引

[linletian]

现象

dsh 的 patch 组合按 profile 隔离，同一台机器上的多个 profile 各自持有一份配置。我在 web profile 的 cordis.patch.yml 里定义了 4 个自定义 provider（其中 2 个带自定义 baseURL 端点），而 dsh-tui profile 的 patch 仍是 dsh 生成的空模板。启动 dsh-tui 时，模型列表只出现 deepseek-official 路由下的默认模型，另外 4 个 provider 完全不出现。

没有任何提示说明「这些配置存在于另一个 profile」，也没有任何命令可以把它们取过来。/provider 只能从零新建，不会读取已有定义。用户只能自己逐个 profile 翻文件比对。

现场证据

① 两个 profile 的 patch 层对比（217 B 是 dsh 为新建 profile 生成的默认空模板）：

$ for p in dsh-tui headless; do printf -- "--- %s ---\n" "$p"; wc -c ~/.dsh/profiles/$p/cordis.patch.yml; done
--- dsh-tui ---
217 /home/…/.dsh/profiles/dsh-tui/cordis.patch.yml
--- headless ---
217 /home/…/.dsh/profiles/headless/cordis.patch.yml

$ diff ~/.dsh/profiles/dsh-tui/cordis.patch.yml ~/.dsh/profiles/headless/cordis.patch.yml && echo identical
identical

→ dsh-tui profile 的补丁层与一个从未配置过的 profile 逐字节相同，即 dsh-tui 从未改写过它。这排除了「dsh-tui 清空/覆盖了用户配置」的可能。

② tui profile 组合出的 llm-pi-ai 行没有任何 config.providers：

$ dsh --profile dsh-tui --dump-config | grep -A2 '^- id: llm-pi-ai'
- id: llm-pi-ai
  name: '@deepseek-ai/dsh-llm-pi-ai'
# == @deepseek-ai/dsh-base, patched by @deepseek-harness-tui/dsh-tui

→ 该行紧接着就进入下一层，连 config: 块都没有。而 web profile 的同一行带着完整的 config.providers。

③ 全局层当前为空，只剩迁移残留：

$ ls -la ~/.dsh/cordis.patch.yml
ls: cannot access '/home/…/.dsh/cordis.patch.yml': No such file or directory
$ ls -la ~/.dsh/settings.yaml.imported
-rw-rw-r--  72 …  ~/.dsh/settings.yaml.imported

→ home 层补丁（跨 profile 叠加的那一层）不存在；settings.yaml.imported 是 DSH 升级时改名留下的残留，目前处于无人认领状态，也没有工具提示这一点。

这不是 TUI 的过滤

模型选择器按 model.provider 分组渲染，没有任何硬编码的 provider 白名单：

// lib/types/screens/Chat.js:425
return models.filter(model => model.provider === activeModelGroup);
// lib/types/screens/Onboarding.js:32
return listed.filter(model => model.provider === group).length;

guide configuration.md 也只说明 provider 缺省回落 deepseek-official —— 是默认值，不是限制。配置补上就会显示。所以这不是「TUI 只支持 DeepSeek」的产品限制，是配置可见性问题。

期望行为

1. dsh-tui doctor 增加一条检查：当前 profile 无自定义 provider 配置时，检测 $DSH_HOME 下是否存在孤儿 provider 配置（其他 profile 的 patch，或 settings.yaml.imported 残留），报出具体路径并给出迁移指引。doctor 的定位本就是启动前环境诊断（feat(cli): dsh-tui doctor——启动前环境诊断（#509 ③/3） #516），这在其职责范围内。
2. 引导页提示：只列出默认路由模型、且检测到上述孤儿配置时，给出一次提示，指明配置在哪个 profile。
3. 文档补充：guide 明确写出 provider 配置是 profile 作用域，以及 home 层补丁是跨 profile 共享的手段。

我认为不应当做的

• 不应自动把其他 profile 的配置搬进当前 profile。 profile 隔离是设计前提，自动迁移等于静默改写用户覆盖层。
• 不应静默改写任何 profile / home 覆盖层（与 [Bug] /update 更新 profile 后仍加载旧全局 cordis.patch.yml #1204 的验收范围一致）。
• 迁移若要做，必须由用户显式触发，并在写入前完整展示将要写入的内容。

分析

已验证

1. dsh-tui profile 的 cordis.patch.yml 与另一 profile 逐字节相同 → dsh 默认空模板，dsh-tui 未改写（证据①）。
2. tui profile 组合结果里 llm-pi-ai 行无 config.providers（证据②）。
3. 模型选择器无 provider 过滤逻辑，仅按 model.provider 分组。
4. $DSH_HOME/cordis.patch.yml 不存在；settings.yaml.imported 存在且无人认领（证据③）。
5. guide 全文未说明 provider 配置是 profile 作用域，也未提及 home 层补丁。

未验证

1. 把 provider 定义搬到 home 层之后，dsh-tui 是否确实显示这 4 个 provider —— 尚未实测，本提案不依赖该结论。
2. 本现象是否只在多 profile 场景出现 —— 未做单 profile 对照实验（代码路径推断应不出现，未验证）。

相关

• [Bug] 全局 settings.yaml 首次由其他 profile 导入后，TUI 偏好留在 .imported 中 #1037 全局 settings.yaml 被其他 profile 导入后，余下配置留在 .imported 中无人认领 —— 同一类「跨 profile 配置断点」的不同切面。
• [Bug] /update 更新 profile 后仍加载旧全局 cordis.patch.yml #1204 /update 后实际生效的 cordis.patch.yml 不一定是用户以为的那一份 —— 任何涉及补丁层的诊断都应以实际组合结果为准。

（迁移代码属于 DSH core，其 GitHub 仓库目前关闭了 Issues，故记在此处。）