jianf/ModelRouter
1
0
Fork 0
mirror of https://gitcode.com/JianFeeeee/ModelRouter.git synced 2026-11-07 09:47:23 +00:00
Code Issues Packages Projects Releases Wiki Activity
494 Commits 10 Branches 90 Tags
f67bcf31b0becfc4036c01bc8f407f86a74326d2
Commit Graph

494 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
JianFeeeee
f67bcf31b0 chore(gui): 版本号 3.0.0（与内核同版本） 
改名为 breaking：go module 路径、二进制名、`/etc` 配置目录、`LLMSPROXY_*`
环境变量全部变更，已部署实例必须跑 `packaging/migrate-to-modelrouter.sh`。
因此内核与桌面端一起升到 3.0.0，而不是继续在 v2.0.x 上打 patch。

`Makefile` 的 VERSION 来自 `git describe`，无需另改。
 2026-10-27 00:07:37 +08:00
JianFeeeee
a708eb10c9 docs: 补入 2026-10-19 交接文档 
记录当时的 Git 状态、渠道适配器进度、以及"provider 回归测试存在未完成编辑"
这一未决项。作为历史记录保留，不参与构建。
 2026-10-27 00:07:37 +08:00
JianFeeeee
f32c10d263 fix(opencodezen): UA 升到 1.19.4 并补回 x-opencode-session-id 
- 上游按客户端指纹判定免费层资格：CLI 1.18.29（4 个 x-opencode-* 头）
  稳定 429；CLI 1.19.4（5 个头，含 session-id）200 且任务真实完成。
- 适配器的 UA 与头集合必须**同步**升级：只改 UA 声称的版本、不发对应头，
  指纹反而更不一致，实测重新落回 429。
- 头形状按官方 CLI 抓包校正；`x-opencode-session-id` 与 `x-opencode-session`
  同值，此前被误删。
- live 测试新增 `gatewayBinary()`：优先 `MODELROUTER_BIN`，其次
  `/usr/local/bin/modelrouter`，回退改名前的 `/usr/local/bin/llmsproxy`。

注：本提交是改名/插件整改之外的独立修复，先于 v3.0.0 收口。
 2026-10-27 00:07:37 +08:00
JianFeeeee
9cdf112de4 merge: 回流 release/v2.0.x 到 main（一次性对齐 110 个提交） 
main 与 release/v2.0.x 已分叉 110 个提交：main 上只有回流时产生的冲突修复
（internal/billing 删除补齐、billing.lua 冲突标记清理）与一次中性化提交，
它们的内容在 release 上均有等价提交。逐条 cherry-pick 无法完成对齐，且会让
main 长期停留在缺少 discover/scheduler/channels 修复的状态（实测 main 上
`TestRealMutants` 因 discover.go 版本过旧而报锚点缺失）。

本次用一次 merge 完成对齐：
- 冲突统一取 release/v2.0.x 侧（main 侧只有等价的回流残留修复）；
- `packaging/llmsproxy.service` 随改名删除，由 modelrouter.service 取代；
- 冲突标记扫描为空。

验证（本 worktree，对齐后）：go build -tags luajit ./... OK；
internal/config、internal/lua(63.9s)、internal/gateway(123.2s，含
TestRealMutants)、internal/core(451.6s) 全绿；node 插件测试 4/4。

后续回流纪律不变：发版打 tag 后从 tag cherry-pick 回 main，不再整支 merge。
 2026-10-26 23:59:06 +08:00
JianFeeeee
f7e926ccb7 docs: README 拆分为主题文档 + 中性化竞品表述 
README 从 642 行降到 131 行，只保留简介、核心能力、最小快速开始、文档索引、
改名说明、目录结构与测试入口。其余内容迁到 docs/，中英文索引一一对应：

  docs/features.md       实现与完整特性清单（原 README 的"实现/特性"）
  docs/configuration.md  配置文件、自动探测模型、多密钥与配额
  docs/routing.md        模型路由、AUTO 链、冷却与半冷却、源/适配器、源模板
  docs/performance.md    实测内存占用与调优、thinking 预算
  docs/webui.md          WebUI 使用
  docs/adapters.md       Lua 适配器协议与内置适配器清单
  docs/gui.md            桌面端 Headless/Desktop 两种产物与构建
  docs/development.md    目录职责、开发协作、测试
  docs/deployment.md     部署、发行包、目录权限、llmsproxy 迁移与验证清单

中性化：README / README_EN / GUI 注释里的 `Clash Verge` 类比全部改为
「桌面壳 / desktop shell」，仓库内（源码与文档）已无该表述。
 2026-10-26 22:28:24 +08:00
JianFeeeee
688dce88d1 refactor(rename)!: llmsproxy → modelrouter（module / 二进制 / 路径 / env） 
产品名早已是 ModelRouter，但仓库标识符仍沿用旧名。这次统一，读写两侧都做兼容，
已部署的机器不会因为顺序问题立刻失效。

- go module `llmsproxy` → `modelrouter`；全仓 import 与 `cmd/modelrouter` 同步。
- `Makefile BINARY=modelrouter`；发行包名、systemd unit、/usr/share 资源、
  `/usr/local/bin` 目标全部改为 modelrouter。
- 默认配置目录 `/etc/llmsproxy` → `/etc/modelrouter`。**读取侧回退**：插件与
  `storeDir` 仍会检查旧路径，所以"先换二进制、后改 unit"不会立即失效。
- 环境变量 `LLMSPROXY_*`（PLUGIN_DIR / XDISPLAY_BASE / ARCH / LIVE_ZEN /
  BUILD_DIR）改为 `MODELROUTER_*`；`LLMS_PROXY_MASTER_KEY` →
  `MODELROUTER_MASTER_KEY`。旧名在读取侧继续接受。
- 桌面端内嵌核心 `bin/llmsproxy` → `bin/modelrouter`，并保留旧文件名回退，
  避免升级到一半的 profile 被判成"core binary missing"。
- 新增 `packaging/migrate-to-modelrouter.sh`：**默认 dry-run**，复制而非移动、
  旧目录永不删除、支持 `--rollback`；随 release tar 分发并由 core-dist 校验。
- `deploy.sh` 增加改名保护：发现旧 `/etc/llmsproxy` 而新配置不存在时**中止**，
  否则会部署出一个"能启动但没有 key、没有源"的空实例。
- 临时目录前缀 `/tmp/llmsproxy-*` → `/tmp/modelrouter-*`；清理逻辑同时回收两代。

兼容别名（`__llmsproxy_*` 全局、`llmsproxy` SDK 别名、旧路径/旧 env）刻意保留，
它们是升级路径而非遗留；docs/plugins.md 已标注为废弃。

本提交未包含：`adapters/opencodezen.lua`、`adapter_opencodezen_test.go`、
`adapter_opencodezen_live_test.go`（OpenCode UA/免费池的既有改动，另批提交）。
 2026-10-26 22:28:08 +08:00
JianFeeeee
de7553eaa2 feat(lua)!: 插件只通过 modelrouter SDK 与内核交互，且不再随内核安装 
- 新增唯一公开接口表 `modelrouter`（sdk_version=1.0）：http / secrets /
  kernel / adapters / plugin_dir。成员与内部桥是**同一对象**而非副本 ——
  复制会让凭据保险库分叉（插件写 A、内核读 B）。
- `llmsproxy` 与 `__llmsproxy_*` 降为同对象兼容别名，只为已装插件继续可用。
  仓库内 4 个插件（channels / billing / quota / usage）全部改用
  `modelrouter.*`：此前它们直接依赖内核私有全局，内核无法在不炸插件的前提下
  改实现（重命名、加守卫、换实现都算破坏性变更）。
- 插件不再由网关安装：`SeedBundled()` 变彻底 no-op，`core.New` 不再调用；
  `ReadBundledPlugin` 改为按源文件定位（脱离 cwd），只服务测试与开发工具。
- 桌面端删除 `BUILTIN_PLUGINS` 与 `syncBundledPluginsOnUpgrade`：升级不再
  删除、改名或覆盖用户插件文件。插件是运维资产，不是内核资源。
- `Builtin` 不再靠"源码与仓库示例逐字节相同"推断，插件一律视为外部文件。
- 判据：SDK 存在/版本/形状、别名与内部桥同一张表、适配器 VM 拿不到 SDK、
  经 SDK 真实写读凭据并驱动内核动作、GUI 升级不动插件文件、release 包不含插件。

说明：channels.lua / quota.lua 同时带有此前的渠道与额度改动（含 OpenCode 免费池
监控），与 SDK 改名同处一个文件，无法文件级拆分，故一并纳入。
 2026-10-26 22:27:12 +08:00
root
97e4ab582d docs: 中性化 README 与代码注释中的第三方客户端引用 
- README.md / README_EN.md：桌面 GUI 段落的第三方客户端类比改为中性的「托盘式桌面客户端」，功能说明不变
- cmd/gui 注释、internal/provider 注释：代理示例改为中性的本地 HTTP 代理表述
- internal/lua/plugins/channels.lua、internal/lua/vm.go：注释措辞中性化

仅文案与注释调整，无任何逻辑变更。
 2026-10-26 21:00:24 +08:00
root
3ef918a87a fix: 修复回流 main 时残留的冲突标记（billing.lua / billing_test.go 取 release/v2.0.x 干净版本） 2026-10-20 22:05:19 +08:00
root
a073423867 chore: 补齐 main 的 internal/billing 删除（回流时 modify/delete 冲突遗留） 2026-10-20 19:09:44 +08:00
root
739d5670ba fix(billing): 插件 HTTP 路由按操作拆路径 + 正确解析请求体 
- 内核插件路由冲突仲裁按**路径**判重（不看 method），同一路径挂 4 个 method 会被
  当成 4 个插件抢同一路径 ⇒ 规则 API 不可用。拆成 /rules（GET）、/rules/replace
  （PUT）、/rules/add（POST）、/rules/remove（DELETE）。
- 插件 HTTP 分发交给 handler 的是**整个请求表**（body 是原始字符串），而直调导出
  拿到的是参数表；此前 PUT 把请求信封当成规则写进了 billing.json，规则全丢、价格表
  清空。新增 reqData() 统一解出 JSON 载荷。
- 生产复验：GET 返回 4 条规则；PUT 后 billing.json 保持规则形状；localzen（free）
  请求不计入 unpriced，codearts 未列价模型计入（预期收紧）。

(cherry picked from commit 79bc55cfbe)
 2026-10-20 19:09:27 +08:00
root
6ec12a3751 chore(gui): 版本号 2.0.49（billing 完全沉入插件） 
(cherry picked from commit 4b9fb7b056)
 2026-10-20 19:09:27 +08:00
root
db1cb7182d refactor(billing)!: 计费全部沉入插件，内核零 billing 代码；规则由插件自持 
按维护者要求（issue #1 回复方向）：内核不处理任何 billing 特有逻辑；插件有完整
OS 权限，自己保存配置文件。据此不再保留任何"内核 ↔ billing 插件"的专用对接。

- `internal/billing`（Go 编译器 + 测试）：删除；
- `internal/core` 的 billing 接口/降级应用/规则加载：删除（含 `billingPath`）；
- `internal/gateway` 的 `/api/plugins/billing/rules` 端点与测试：删除；
- `config` 的 `BillingDSL/Profile/Rule/Token/Peak/LongContext` 与校验、
  `billing:`/`billing_file:` 配置段：删除。系统配置里不再有 billing 段。
内核只保留所有插件通用的能力：加载 .lua、插件状态持久化、插件目录
（`__llmsproxy_plugin_dir`）、`plugin.http` 路由、插件可用的 io/os。

- 规则文件移到**插件自己的目录**：`<plugin_dir>/billing.json`，由插件用 io 自己
  读写（tmp + rename 原子替换）；加载插件时自己读文件并编译；
- 规则以**源名** `source` 为键（`url:"*"` 仅表示全局模型价目表）：URL→源名映射
  属于内核配置，插件不为它和内核对接；编辑页在浏览器里取 `/api/sources` 选源名；
- 规则编辑 API 改为插件自己的 `/api/plugins/http/billing/rules`
  （GET/PUT/POST/DELETE，roles=admin），写盘也在插件内完成；
- 计费账目仍在插件状态文件（内核通用持久化）`<plugin_dir>/.billing.state.json`；
- `priceFor` 落地 profile 级 `default` 策略与显式 `mode=unpriced` 的优先级。

生产已迁移：`config.yaml` 的 `billing:` 规则转为 `plugins/billing.json`（按源名
重写），并从系统配置中移除；规则文件与系统配置从此各自独立保存。

- `internal/lua/billing_rules_test.go`：插件自写 billing.json 并重启恢复、
  free/subscription/token/通配符编译语义、1e6+1e6 token = 0.75 端到端、
  非法规则被拒且不覆盖旧文件、reasoning/long_context/peak；
- `internal/lua/billing_test.go`：profile default 策略三态 + 显式 unpriced 优先；
- `internal/lua/billing_ui_test.go`：规则编辑页仍挂在 billing 页内、列宽/列数守卫。

(cherry picked from commit 7941b4110a)
 2026-10-20 19:09:22 +08:00
root
79bc55cfbe fix(billing): 插件 HTTP 路由按操作拆路径 + 正确解析请求体 
- 内核插件路由冲突仲裁按**路径**判重（不看 method），同一路径挂 4 个 method 会被
  当成 4 个插件抢同一路径 ⇒ 规则 API 不可用。拆成 /rules（GET）、/rules/replace
  （PUT）、/rules/add（POST）、/rules/remove（DELETE）。
- 插件 HTTP 分发交给 handler 的是**整个请求表**（body 是原始字符串），而直调导出
  拿到的是参数表；此前 PUT 把请求信封当成规则写进了 billing.json，规则全丢、价格表
  清空。新增 reqData() 统一解出 JSON 载荷。
- 生产复验：GET 返回 4 条规则；PUT 后 billing.json 保持规则形状；localzen（free）
  请求不计入 unpriced，codearts 未列价模型计入（预期收紧）。
v2.0.49 		2026-10-20 18:59:16 +08:00
root
4b9fb7b056 chore(gui): 版本号 2.0.49（billing 完全沉入插件） 2026-10-20 18:57:27 +08:00
root
7941b4110a refactor(billing)!: 计费全部沉入插件，内核零 billing 代码；规则由插件自持 
按维护者要求（issue #1 回复方向）：内核不处理任何 billing 特有逻辑；插件有完整
OS 权限，自己保存配置文件。据此不再保留任何"内核 ↔ billing 插件"的专用对接。

## 内核（删除）
- `internal/billing`（Go 编译器 + 测试）：删除；
- `internal/core` 的 billing 接口/降级应用/规则加载：删除（含 `billingPath`）；
- `internal/gateway` 的 `/api/plugins/billing/rules` 端点与测试：删除；
- `config` 的 `BillingDSL/Profile/Rule/Token/Peak/LongContext` 与校验、
  `billing:`/`billing_file:` 配置段：删除。系统配置里不再有 billing 段。
内核只保留所有插件通用的能力：加载 .lua、插件状态持久化、插件目录
（`__llmsproxy_plugin_dir`）、`plugin.http` 路由、插件可用的 io/os。

## 插件（billing.lua）
- 规则文件移到**插件自己的目录**：`<plugin_dir>/billing.json`，由插件用 io 自己
  读写（tmp + rename 原子替换）；加载插件时自己读文件并编译；
- 规则以**源名** `source` 为键（`url:"*"` 仅表示全局模型价目表）：URL→源名映射
  属于内核配置，插件不为它和内核对接；编辑页在浏览器里取 `/api/sources` 选源名；
- 规则编辑 API 改为插件自己的 `/api/plugins/http/billing/rules`
  （GET/PUT/POST/DELETE，roles=admin），写盘也在插件内完成；
- 计费账目仍在插件状态文件（内核通用持久化）`<plugin_dir>/.billing.state.json`；
- `priceFor` 落地 profile 级 `default` 策略与显式 `mode=unpriced` 的优先级。

## 迁移
生产已迁移：`config.yaml` 的 `billing:` 规则转为 `plugins/billing.json`（按源名
重写），并从系统配置中移除；规则文件与系统配置从此各自独立保存。

## 判据
- `internal/lua/billing_rules_test.go`：插件自写 billing.json 并重启恢复、
  free/subscription/token/通配符编译语义、1e6+1e6 token = 0.75 端到端、
  非法规则被拒且不覆盖旧文件、reasoning/long_context/peak；
- `internal/lua/billing_test.go`：profile default 策略三态 + 显式 unpriced 优先；
- `internal/lua/billing_ui_test.go`：规则编辑页仍挂在 billing 页内、列宽/列数守卫。
 2026-10-20 18:57:23 +08:00
root
5ccf068db3 chore(gui): 版本号 2.0.48（与内核同版本） v2.0.48 2026-10-20 18:33:29 +08:00
root
b4c5f0f0fc refactor(billing): 计费语义下沉到 Lua（内核只解 YAML/传数据）+ 采纳 PR #2 语义 
按 issue #1 的修复方向（维护者评论）：内核不再持有任何计费语义，billing 逻辑
全部在 `plugins/billing.lua`；内核只负责解 config.yaml、校验 schema、把
profile + 源 base_url 作为**数据**交给插件，再把插件算出的价目通过 `prices`
侧车注入。计费账目仍持久化在插件状态文件（`plugin_dir/.billing.state.json`）。

## 变更
- **删除** `internal/billing`（compile.go 359 行 + 其 Go 测试）；
- 新增 `core.compileBillingPrices`：把 profile/sources JSON 化后调用插件导出
  `compile_prices`，返回价目表 + 未匹配规则清单（供错误日志点名 URL）；
- `applyBillingDSL` / 规则编辑器改为走同一个插件编译入口（编辑器 lenient，
  半成品规则可保存、可报告）；
- `billing.lua` 新增 `compile_prices`：URL 归一匹配、首条命中优先、
  free/subscription/unpriced/token、USD/M→per-token、peak 窗口、
  long_context 边际价、reasoning 可选价、default 策略、未匹配清单。
  错误通过载荷 `error` 字段回传（插件导出第二返回值通道不可靠）。

## 与 PR #2（valuelesser）合并后的语义
- **token 规则不产生任何源条目**：未列价的模型落到 unpriced 统计（可见），
  不再"静默计 $0"。比 issue 正文里的 `{per_request:0}` 标记更收口；
- `default: free` 由**编译期**给未匹配源写 `{per_request:0}` 标记；
  `unpriced`/缺省不写。删除无人读取的 `default_mode` 死键；
- 保留 `unmatched_rules` 清单（只用于降级应用时点名过期 URL）。

## 判据（原 Go 单测平移到 Lua + PR #2 的用例）
- `internal/lua/billing_compile_test.go`：通配符不标记源、token 规则无源条目、
  任意源条目不得携带 token 价（根因直防）、free/subscription 保留有意零价、
  reasoning 缺席、long_context 三种形态、peak 形状、URL 归一+首条优先、
  lenient 未匹配清单、硬错误 5 例、default 两态；
- `internal/lua/billing_test.go`：编译输出驱动真实 priceFor 的 A/B 用例
  （旧形状 cost=0 / 新形状 0.75 且 unpriced=0）、default 编译期语义 e2e；
- `internal/gateway`：token 规则断言"无源条目"、模型价 per-token 量级；
- `internal/core`：过期规则 URL 降级应用（有效规则仍生效）。
 2026-10-20 18:33:26 +08:00
root
442fa5e3f6 chore(gui): 版本号 2.0.47（与内核同版本） v2.0.47 2026-10-20 18:05:19 +08:00
root
0caa37ea6a fix(billing): 过期规则 URL 不再让整个 profile 失效（降级应用 + 点名 URL） 
生产现网发现（issue #1 排查）：billing.rules 里一条指向
https://opencode.ai/inference/v1 的规则，在该源 base_url 变成
.../inference/openai/v1 之后匹配不到任何源；严格编译因此让**整个** profile
不生效 —— 账单恒 0、unpriced_reqs 涨到 3.7 万，唯一痕迹是一行启动日志。

- 严格编译失败时降级为 lenient：应用能匹配的规则，其余按 profile default；
- 日志用 ERROR 点名**具体哪条 URL** 写错（新增 billing.UnmatchedRuleURLs），
  并说明未匹配流量的记账去向；
- 判据 TestBillingStaleRuleURLStillAppliesOtherRules：一条过期规则 + 一条有效
  规则 ⇒ 有效规则必须仍然生效。
 2026-10-20 18:04:43 +08:00
root
33cb2bdb06 fix(billing): 源层零价不再覆盖模型价（issue #1）+ default_mode 生效 + 文档/判据补齐 
GitCode issue #1：任何按 `mode: token` 且 URL 非通配符的规则定价的源，计费恒为 0，
且 `unpriced_reqs` 也不增长 —— 完全静默。

## 真因
- `compile.go` 给这类规则写源条目 `{prompt:0, completion:0, per_request:0}`，
  本意只是"标记该源已定价"（同源未列入价目表的模型不算 unpriced）；
- `billing.lua` 的 priceFor() 源层在模型层之后、且 `sp.prompt ~= nil` 即覆盖；
- 两者叠加 ⇒ 模型价被清成 0，而 `out.priced` 仍为 true ⇒ 连未定价计数都不涨。

## 修法
1. `compile.go`：token 规则的源条目只写 `{per_request: 0}`（只是标记，不参与 token
   计价）。`free` / `subscription` 保留全零（那里 0 本身就是语义）。
2. `billing.lua`：
   - `priceFor()` 的 `out` 补 `local`（此前是 VM 级全局变量，跨请求残留）；
   - 实现 `profiles[].default` 的 `free|unpriced` 语义：`free` = 刻意免费（不进
     unpriced），`unpriced`（默认）= 未定价债务。此前 compile.go 写 `default_mode`
     但**无人读**，两种取值运行时完全等价。
3. `core.go`：应用 profile 时把 `unmatched_sources` 打进日志（WARNING 列出没有
   规则命中的源）。该字段此前只写不读，是第二个静默少报点。
4. `docs/plugins.md`：token 价优先级改为与实际实现一致的
   `keys > sources > models > default`，并写明"标记已定价只能用 per_request:0"。

## 判据（都先红后绿）
- `internal/billing`：token 规则的源条目**不含** prompt/completion；free/subscription
  仍保留显式 0。
- `internal/lua`：同源同模型下旧形状 cost=0（缺陷本身）、新形状 cost=0.75 且
  unpriced_reqs=0；未列入价目表的模型仍算"已定价"；default_mode 三态。
- `internal/gateway`：`billing_rules_api_test` 的单位断言原本读
  `cc["models"]`（恒 false，整块被跳过——从未执行过），改为 `prices["models"]`，
  并新增"源条目不得带 token 价"断言。

## 顺带修掉一个"永不执行"的判据
`discover_mutate_test.go` 的变异锚点写成 6 个空格，而 `discover.go` 已是 2 个空格
⇒ 该变异每次都 `anchor not found`，变异 campaign 长期红着。修正锚点后，
"嵌套 metadata 不再读取"这条变异真的被执行并被测试 KILL。
 2026-10-20 17:46:52 +08:00
root
b24b69719d chore(gui): 版本号 2.0.46（与内核同版本） 
(cherry picked from commit 02c01582f1)
 2026-10-20 10:49:46 +08:00
root
24e1dee960 test(retry): 钉住声明式重试判据与流式握手重试语义 
- config：ShouldRetry/DelayDuration 表驱动（nil/次数=1/状态不匹配/body 不匹配/
  空子串/多信号/非法间隔）
- provider：命中策略就重试直到 200、body 不匹配**不许**重试（400 也常用于真错误）、
  流式只重试握手（首帧之后不重试，避免重复输出）

(cherry picked from commit 0ae7d2c8be)
 2026-10-20 10:49:34 +08:00
root
b57b442c0a fix(codearts): 上游限流改为可声明重试（内核通用能力）+ 会话/连接两处真因 
用户连续报「codeart 还是不可用 / empty stream」。把上游原始响应打出来逐条对齐，
三个症状同源，且都不是"模型坏了"：

| 场景 | 上游实际返回 |
|---|---|
| 流式、短时间连续请求 | HTTP **200** + 只带 error 的帧 ⇒ 内核判 `empty stream` |
| 非流式、同一条件 | HTTP 400 `TM.00001041: 并发会话数已达上限(3个)` |
| 突发请求 | HTTP 429 `TPM limit … 500000 tokens per minute` |

实测：最后一个请求结束后约 **44~60 秒**释放；同一账号连续请求 3~4 次即占满。
参考实现（示例插件 llm-adapter.ts）的做法是**每 10s 轮询后重试 chat**（最多 30
分钟），所以用户那边"看起来没事"。

## 我们的改法（内核只做通用机制，厂商知识留在插件）
1. **内核新增声明式重试策略** `source.retry`（纯数据：状态码列表 + 响应体子串 +
   间隔 + 次数）。内核不认识任何厂商；命中即在同一网关请求内每 10s 重试一次。
   流式只在**握手阶段**重试（首帧尚未下发，不会重复输出），非流式整体重试。
2. **插件为 codearts 声明**：400/429 + 命中 `TM.00001041` / `TPM limit` /
   `并发会话数已达上限` → 10s × 最多 18 次（≈3 分钟）。
3. **适配器补两个会话细节**：`Connection: close`（keep-alive 空闲连接会被上游
   计入并发会话）与稳定 `Session-Id`（同一账号恒定，避免每次请求新建会话）。
4. 错误文案补可行动提示（并发会话上限 / TPM 限流，约 1 分钟释放）。

## 验证（生产）
- 连续 6 次**流式**：6/6 成功（撞上限时自动等 10s 再试，客户端只感觉慢）：
  `+0s / +12s / +34s / +86s / +100s / +144s`
- 连续 5 次**非流式**：5/5 成功（`+0 / +11 / +20 / +28 / +38s`）
- 修复前：第 4 个请求起必然 TM.00001041 / empty stream。

> 注：`TM.00001005 无正常可用套餐` 属于账号权益问题（不重试、如实报出），
> 与限流要分开处理。

(cherry picked from commit 6454b094bc)
 2026-10-20 10:49:34 +08:00
root
0ae7d2c8be test(retry): 钉住声明式重试判据与流式握手重试语义 
- config：ShouldRetry/DelayDuration 表驱动（nil/次数=1/状态不匹配/body 不匹配/
  空子串/多信号/非法间隔）
- provider：命中策略就重试直到 200、body 不匹配**不许**重试（400 也常用于真错误）、
  流式只重试握手（首帧之后不重试，避免重复输出）
v2.0.46 		2026-10-20 10:45:56 +08:00
root
02c01582f1 chore(gui): 版本号 2.0.46（与内核同版本） 2026-10-20 10:38:07 +08:00
root
6454b094bc fix(codearts): 上游限流改为可声明重试（内核通用能力）+ 会话/连接两处真因 
用户连续报「codeart 还是不可用 / empty stream」。把上游原始响应打出来逐条对齐，
三个症状同源，且都不是"模型坏了"：

| 场景 | 上游实际返回 |
|---|---|
| 流式、短时间连续请求 | HTTP **200** + 只带 error 的帧 ⇒ 内核判 `empty stream` |
| 非流式、同一条件 | HTTP 400 `TM.00001041: 并发会话数已达上限(3个)` |
| 突发请求 | HTTP 429 `TPM limit … 500000 tokens per minute` |

实测：最后一个请求结束后约 **44~60 秒**释放；同一账号连续请求 3~4 次即占满。
参考实现（示例插件 llm-adapter.ts）的做法是**每 10s 轮询后重试 chat**（最多 30
分钟），所以用户那边"看起来没事"。

## 我们的改法（内核只做通用机制，厂商知识留在插件）
1. **内核新增声明式重试策略** `source.retry`（纯数据：状态码列表 + 响应体子串 +
   间隔 + 次数）。内核不认识任何厂商；命中即在同一网关请求内每 10s 重试一次。
   流式只在**握手阶段**重试（首帧尚未下发，不会重复输出），非流式整体重试。
2. **插件为 codearts 声明**：400/429 + 命中 `TM.00001041` / `TPM limit` /
   `并发会话数已达上限` → 10s × 最多 18 次（≈3 分钟）。
3. **适配器补两个会话细节**：`Connection: close`（keep-alive 空闲连接会被上游
   计入并发会话）与稳定 `Session-Id`（同一账号恒定，避免每次请求新建会话）。
4. 错误文案补可行动提示（并发会话上限 / TPM 限流，约 1 分钟释放）。

## 验证（生产）
- 连续 6 次**流式**：6/6 成功（撞上限时自动等 10s 再试，客户端只感觉慢）：
  `+0s / +12s / +34s / +86s / +100s / +144s`
- 连续 5 次**非流式**：5/5 成功（`+0 / +11 / +20 / +28 / +38s`）
- 修复前：第 4 个请求起必然 TM.00001041 / empty stream。

> 注：`TM.00001005 无正常可用套餐` 属于账号权益问题（不重试、如实报出），
> 与限流要分开处理。
 2026-10-20 10:38:00 +08:00
root
771b95a133 fix(channels): admit_functions 落到 effectiveModels（解析器不承担产品策略） 
上一提交把「本适配器会发的通道」过滤写进了 trae 的目录解析器，导致两个解析器判据
回归：同模型在 solo_agent（有思考档位）与 solo_work_lite（无档位）同时出现时，
整组 solo_agent 被丢弃 ⇒ 档位信息丢光，模型显示"未提供推理等级"。

正确分层：
- **解析器**只负责把目录如实解出来（含跨通道元数据合并、白名单准入）；
- **产品策略**（只暴露适配器能发的通道）放到 effectiveModels，作用在对外
  暴露的 id 列表上。

实现要点：合并会选"更优"的那条（往往不在我们要发的通道里），所以判据不能看
合并后条目的 chan —— 解析时额外记 `chans`（该 id 在哪些通道出现过），策略按
chans 求交集。夹具同步调整：硬性过滤的条目放进 solo_work_lite（生产里适配器
恒发这条通道），inline_chat 仍用于白名单判据。
v2.0.45 		2026-10-20 10:12:51 +08:00
root
441de434f5 chore(gui): 版本号 2.0.45（与内核同版本） 2026-10-20 09:54:06 +08:00
root
9feef8f4cb fix(channels): 渠道卡片 logged_in 改成看账号池（此前所有池接入的平台都显示未登录） 
## 真因：logged_in 判的是旧单账号键
用户报「codearts 还是不可用」。查下来渠道**本身是通的**（9 个模型逐个实测都返回
内容），不可用的是**UI 的登录态判断**：

`list_platforms` 写的是 `credentialOf("channels:" .. platform)` —— 那是**旧版
单账号**的保险库键。现网凭据键是 `channels:<platform>:<accountId>`（一平台多
账号），于是**所有**通过账号池接入的平台都被判成"未登录"：

    修复前（生产）：trae=False minimax=False codearts=False qoder=False zcode=False
                    （只有 buddy=True —— 它还留着一条旧格式凭据）
    修复后：          trae=True  minimax=True  codearts=True qoder=True  zcode=True

UI 据此把渠道卡片渲染成"未接入"，用户看到的就是"渠道不可用"。底层模型完全能用 ——
这是最容易被误判成"上游挂了"的一类假信号。

## 修法
- `list_platforms`：logged_in 改为遍历账号池（`poolList` + 凭据存在 + enabled≠false），
  旧单账号仅作兜底；顺带回 `account_id` / `accounts` 计数，让 UI 能区分同平台多账号；
- `status_page`：`accounts` 同样合并账号池（此前只回旧表，状态页里池接入的平台
  是空的 —— 同一根因的第二个出口）；
- 新增 `__platforms_probe`（`list_platforms` 是 HTTP 路由处理器、不在 exports 里，
  判据走探针，与仓库既有做法一致）；
- 回归判据 `TestPlatformsLoggedInFromAccountPool`：池里有凭据账号 ⇒ logged_in=true，
  且 account_id / account / accounts 回池数据。

## 顺带核实（不是代码缺陷）
- codearts 目录里 4 个模型（`deepseek-v4-flash-0731` / `glm-5.3-flash` /
  `deepseek-v4-pro-0813` / `CodeArts-Pangu`）实测上游 404
  `InferHub.002002009.404: The model is not registered` ⇒ 之前被手工停用是对的，
  已按死模型流程收口（不再回到可选列表）；
- `GLM-5.3` 同样 404，已标失效并自动从源里剔除（日志：
  「模型已失效，已标记 codearts/GLM-5.3」）；
- `deepseek-v4-flash` 早前的 429 是 TPM 限流（我自己连续压测造成），现已恢复 OK。
- 最终 codearts：**9 个模型，9/9 实测返回内容**。
 2026-10-20 09:54:06 +08:00
root
d138ef80a5 chore(gui): 版本号 2.0.44（与内核同版本，桌面插件刷新判据依赖它） 
(cherry picked from commit b5c89fd3d7)
 2026-10-20 09:43:44 +08:00
root
2c278d481d fix(channels): trae 目录用错头族——IDE 端点必须发 IDE 头（此前恒回 2001） 
## 真因：两套头混用
用户报「trae 还是无法从上游拉取，示例插件都可以」。用探针把**原始响应**打出来
才看清：目录端点 HTTP **200**，但 22 个 function 全部
`error_code 2001 "Config detail for function: X not found"` —— 于是远端目录恒空，
插件只能退回兜底表，用户侧表现成「模型不正确 / 渠道不可用」。

根因不是网络、不是账号、不是 body：是**头族用错了**。
- `traeCheckinHeaders` 面向 `api.trae.cn` 的签到/积分：VSCode UA + `X-Market-*`
  + `X-Lscbd-*` + `Vscode-Sessionid` + **派生**的 market device id；
- `traeIdeHeaders` 面向 `trae-api-cn.mchost.guru` 的目录/对话：`Trae/0.1.52` UA
  + `X-App-Id` + `X-Ide-Version(-Code)` + `Request-Traffic-Type` +
  **凭据里登录时的** `device_id`/`machine_id`。

目录刷新当时复用的是签到头（注释还写着"复用更安全"），发到 IDE 端点就被逐
function 判 2001。用 IDE 头直发同一端点：**HTTP 200 + 2.6 MB**、每个 function
都带 `config_info_list`。

修法（全部在插件内，内核零改动）：
1. 新增 `traeIdeHeaders()`，与签到头**明确分开**，注释写清两套头的适用面；
2. 目录刷新（`sign="trae_solo"`）改用它，`Accept: application/json`；
3. 加判据 `__trae_headers_probe` + `TestTraeHeadersKeptSeparate`：钉死两套头的
   键集合互不越界（IDE 头必须有 X-App-Id/X-Machine-Id、不得有 X-Market-*；
   签到头反之）。这类"都能跑、但跑错了"的错只能靠契约钉死。

## 目录拉通后暴露的第二个问题：目录≠可调用
拿到真实目录（22 function / 93 条去重模型）后逐个实测，发现**同一个
config_name 在不同 function 里可用性不同**，而本插件适配器恒发
`solo_work_lite`：
- `kimi-k2.8-preview` / `deepseek-V3` / `glm-4.7` / `code-review-judge` /
  `multimodal_image_kimi-k2.5` → HTTP 200 但 **content 为空**；
- `sagitta` → 自称 Claude、`aquila` → 自称 ChatGPT、`custom_model_gpt-5` →
  自称 GPT-4 系列 ⇒ 这些是**未知 config 时上游悄悄回落默认模型** ——
  这正是"模型不正确"的真实来源。

于是补两道准入（都是**声明式**平台数据，不写死逻辑）：
- `models_remote.admit_functions = { "solo_work_lite" }`：只收本适配器**会发**
  的那条通道里的模型（白名单只说"该通道在本端点可调用"，不等于"适配器会发"）；
- `models_fallback_no_supplement = true`：远端目录可用时**不再补兜底表**
  （兜底表里 sagitta/aquila/glm-5/DeepSeek-V4-Flash 等在上游已无对应配置）。

结果：trae 可选模型 = **20 个**（glm-5.3 / glm-5.3-flash / glm-5.3-flashx /
glm-5.2 / kimi-k3 / kimi-k2.7-code / kimi-k2.6 / minimax-m3 / minimax-m3.1-flash /
qwen3.8-max / qwen-3.7-plus / step-5-preview / mimo-v2.6-{flash,pro} /
deepseek-v4.1-flash / DeepSeek-V4-{Flash,Pro}-Official / Doubao-Seed-2.1-{Pro,Turbo,Evolving}），
**20/20 逐个实测返回非空内容**。

## 回归测试
- `TestTraeHeadersKeptSeparate`（新）：两套头键集合互斥（不联网即可复现该类回归）
- `TestTraeCustomModelSlotsAreNotOffered` / `TestTraeSourceOmitsCustomModelSlots`
  （上一版）：custom_model_* 槽位不进 UI 也不进上游源
- 死模型判据：opencode 的 `has been deprecated` 文案阳/阴性（上一版）

(cherry picked from commit 7f193a997d)
 2026-10-20 09:43:44 +08:00
root
b5c89fd3d7 chore(gui): 版本号 2.0.44（与内核同版本，桌面插件刷新判据依赖它） v2.0.44 2026-10-20 09:39:49 +08:00
root
7f193a997d fix(channels): trae 目录用错头族——IDE 端点必须发 IDE 头（此前恒回 2001） 
## 真因：两套头混用
用户报「trae 还是无法从上游拉取，示例插件都可以」。用探针把**原始响应**打出来
才看清：目录端点 HTTP **200**，但 22 个 function 全部
`error_code 2001 "Config detail for function: X not found"` —— 于是远端目录恒空，
插件只能退回兜底表，用户侧表现成「模型不正确 / 渠道不可用」。

根因不是网络、不是账号、不是 body：是**头族用错了**。
- `traeCheckinHeaders` 面向 `api.trae.cn` 的签到/积分：VSCode UA + `X-Market-*`
  + `X-Lscbd-*` + `Vscode-Sessionid` + **派生**的 market device id；
- `traeIdeHeaders` 面向 `trae-api-cn.mchost.guru` 的目录/对话：`Trae/0.1.52` UA
  + `X-App-Id` + `X-Ide-Version(-Code)` + `Request-Traffic-Type` +
  **凭据里登录时的** `device_id`/`machine_id`。

目录刷新当时复用的是签到头（注释还写着"复用更安全"），发到 IDE 端点就被逐
function 判 2001。用 IDE 头直发同一端点：**HTTP 200 + 2.6 MB**、每个 function
都带 `config_info_list`。

修法（全部在插件内，内核零改动）：
1. 新增 `traeIdeHeaders()`，与签到头**明确分开**，注释写清两套头的适用面；
2. 目录刷新（`sign="trae_solo"`）改用它，`Accept: application/json`；
3. 加判据 `__trae_headers_probe` + `TestTraeHeadersKeptSeparate`：钉死两套头的
   键集合互不越界（IDE 头必须有 X-App-Id/X-Machine-Id、不得有 X-Market-*；
   签到头反之）。这类"都能跑、但跑错了"的错只能靠契约钉死。

## 目录拉通后暴露的第二个问题：目录≠可调用
拿到真实目录（22 function / 93 条去重模型）后逐个实测，发现**同一个
config_name 在不同 function 里可用性不同**，而本插件适配器恒发
`solo_work_lite`：
- `kimi-k2.8-preview` / `deepseek-V3` / `glm-4.7` / `code-review-judge` /
  `multimodal_image_kimi-k2.5` → HTTP 200 但 **content 为空**；
- `sagitta` → 自称 Claude、`aquila` → 自称 ChatGPT、`custom_model_gpt-5` →
  自称 GPT-4 系列 ⇒ 这些是**未知 config 时上游悄悄回落默认模型** ——
  这正是"模型不正确"的真实来源。

于是补两道准入（都是**声明式**平台数据，不写死逻辑）：
- `models_remote.admit_functions = { "solo_work_lite" }`：只收本适配器**会发**
  的那条通道里的模型（白名单只说"该通道在本端点可调用"，不等于"适配器会发"）；
- `models_fallback_no_supplement = true`：远端目录可用时**不再补兜底表**
  （兜底表里 sagitta/aquila/glm-5/DeepSeek-V4-Flash 等在上游已无对应配置）。

结果：trae 可选模型 = **20 个**（glm-5.3 / glm-5.3-flash / glm-5.3-flashx /
glm-5.2 / kimi-k3 / kimi-k2.7-code / kimi-k2.6 / minimax-m3 / minimax-m3.1-flash /
qwen3.8-max / qwen-3.7-plus / step-5-preview / mimo-v2.6-{flash,pro} /
deepseek-v4.1-flash / DeepSeek-V4-{Flash,Pro}-Official / Doubao-Seed-2.1-{Pro,Turbo,Evolving}），
**20/20 逐个实测返回非空内容**。

## 回归测试
- `TestTraeHeadersKeptSeparate`（新）：两套头键集合互斥（不联网即可复现该类回归）
- `TestTraeCustomModelSlotsAreNotOffered` / `TestTraeSourceOmitsCustomModelSlots`
  （上一版）：custom_model_* 槽位不进 UI 也不进上游源
- 死模型判据：opencode 的 `has been deprecated` 文案阳/阴性（上一版）
 2026-10-20 09:38:39 +08:00
root
3944a578c7 chore(gui): 版本号 2.0.43（与内核同版本；桌面插件刷新判据按 app 版本，必须同步） 
桌面壳的「内置插件升级刷新」按 app.getVersion() 打戳：GUI 版本号若与内核脱节，
升级后 channels.lua 不会重新播种，渠道修复又会被静默留在旧版。

(cherry picked from commit 055705c134)
 2026-10-20 09:26:45 +08:00
root
abd0e1d943 fix(channels): trae 模型表去掉不可调用槽位 + opencode 免费模型按实测收敛 
## ① trae：模型选择器里那几个 `custom_model_*` 是**槽位不是模型**
用户报「trae 的模型不正确 / 渠道不可用」。逐个实测（生产）：
`custom_model_kimi` / `custom_model_claude` / `custom_model_1M` 返回 **空
content**（`custom_model_gpt-5` 也答非所问），而真实模型
（glm-5.2 → Z.ai GLM、kimi-k3 → Moonshot、minimax-m3 → MiniMax、
Doubao-Seed-2.1-Pro → 字节）全部正常 —— 所以渠道是通的，问题在**表**。

根因：`custom_model_*` 是 TRAE 的「自定义模型槽位」，上游目录里它们的权威
判据是 `is_custom_model: true`。插件自己的 `trae_batch` 解析器早已按这条
**准入**剔除，但**兜底表**把它们当普通模型列了出来；而远端目录在部分账号
下恒空（企业租户账号实测：22 个 function 全回
`error_code 2001 Config detail for function: X not found`），用户只能看到
兜底表 ⇒ 选中槽位后上游回空 ⇒ 「模型坏了」。

修法（**纯插件**，内核零改动）：
- 新增 `models_unavailable` 一档：声明「本协议下不可调用」的条目，
  **既不进 UI 选择器，也不进上游源**（与 `models_hidden` 区别：后者只是
  不进 UI，内部子 agent 仍可显式调用）；
- trae 的 11 个 `custom_model_*` 移入该档；把 4 个内部子 agent 留在
  `models_hidden`（语义不变）；
- 生产验证：trae 源/选择器从 28 → **17**，逐个实测 17 个全部返回非空内容。

## ② 远端目录「空」要能区分原因
`refresh_models` 此前只会报「远端返回空目录」，把两种完全不同的故障混为一谈：
网络/HTTP 故障 vs 服务端 200 但账号侧没有可下发配置。
现在后者如实报：「远端 200 但无模型配置（账号侧未下发 function config，
企业/租户账号需管理员开启，实测 error_code 2001）」——运维据此知道该找
租户管理员，而不是反复重试网络。
另加 `__trae_catalog_probe`（诊断探针）：原样回传目录端点的 status/body 前
N 字节/解析条数，并在 2001 现场定位时立了大功（这类"上游 200 却空目录"没有
原始响应只能瞎猜）。

## ③ opencode / localzen：免费模型按**实测**收敛
用户报「localzen 也不能用了」。逐项实测（生产）：
- `space-bunny-free` → **410** `Model space-bunny-free has been deprecated.
  Use minimax-m3.1-flash-free instead.`（仍在本地源里 ⇒ 选中必失败）
- `jev-1.13-free` → 400 `Model does not support this protocol.`（非 OpenAI
  chat 协议，本端点永远调不通）
- `beam-free` → 200 但 content 空、无 finish_reason
- 其余 7 个（mimo / nemotron-super-vl / nemotron-lightning / longcat /
  deepseek-v4.1 / glm-5.3-flash / minimax-m3.1-flash）全部正常返回内容

修法：
- `DEAD_GONE_PATTERNS` 补 opencode 的下架文案
  （`Model … has been deprecated`）；配阴/阳性判据（参数/字段被弃用**不算**）；
- opencode 平台把 jev-1.13-free / beam-free 列入 `models_unavailable`，
  并从兜底表与 models_free 里移除；
- 生产 `localzen` 源（手写源，插件不管）按实测刷新为 7 个可用免费模型，
  逐个验证返回内容。

## 纪律
渠道逻辑全部留在插件里（channels.lua / 插件自装适配器）；内核这轮**没有**
新增任何厂商语义 —— 上一轮加进内核的只有通用的 `adapter.hidden` 机制。

(cherry picked from commit 401a7ead27)
 2026-10-20 09:26:44 +08:00
root
055705c134 chore(gui): 版本号 2.0.43（与内核同版本；桌面插件刷新判据按 app 版本，必须同步） 
桌面壳的「内置插件升级刷新」按 app.getVersion() 打戳：GUI 版本号若与内核脱节，
升级后 channels.lua 不会重新播种，渠道修复又会被静默留在旧版。
v2.0.43 		2026-10-20 09:22:16 +08:00
root
401a7ead27 fix(channels): trae 模型表去掉不可调用槽位 + opencode 免费模型按实测收敛 
## ① trae：模型选择器里那几个 `custom_model_*` 是**槽位不是模型**
用户报「trae 的模型不正确 / 渠道不可用」。逐个实测（生产）：
`custom_model_kimi` / `custom_model_claude` / `custom_model_1M` 返回 **空
content**（`custom_model_gpt-5` 也答非所问），而真实模型
（glm-5.2 → Z.ai GLM、kimi-k3 → Moonshot、minimax-m3 → MiniMax、
Doubao-Seed-2.1-Pro → 字节）全部正常 —— 所以渠道是通的，问题在**表**。

根因：`custom_model_*` 是 TRAE 的「自定义模型槽位」，上游目录里它们的权威
判据是 `is_custom_model: true`。插件自己的 `trae_batch` 解析器早已按这条
**准入**剔除，但**兜底表**把它们当普通模型列了出来；而远端目录在部分账号
下恒空（企业租户账号实测：22 个 function 全回
`error_code 2001 Config detail for function: X not found`），用户只能看到
兜底表 ⇒ 选中槽位后上游回空 ⇒ 「模型坏了」。

修法（**纯插件**，内核零改动）：
- 新增 `models_unavailable` 一档：声明「本协议下不可调用」的条目，
  **既不进 UI 选择器，也不进上游源**（与 `models_hidden` 区别：后者只是
  不进 UI，内部子 agent 仍可显式调用）；
- trae 的 11 个 `custom_model_*` 移入该档；把 4 个内部子 agent 留在
  `models_hidden`（语义不变）；
- 生产验证：trae 源/选择器从 28 → **17**，逐个实测 17 个全部返回非空内容。

## ② 远端目录「空」要能区分原因
`refresh_models` 此前只会报「远端返回空目录」，把两种完全不同的故障混为一谈：
网络/HTTP 故障 vs 服务端 200 但账号侧没有可下发配置。
现在后者如实报：「远端 200 但无模型配置（账号侧未下发 function config，
企业/租户账号需管理员开启，实测 error_code 2001）」——运维据此知道该找
租户管理员，而不是反复重试网络。
另加 `__trae_catalog_probe`（诊断探针）：原样回传目录端点的 status/body 前
N 字节/解析条数，并在 2001 现场定位时立了大功（这类"上游 200 却空目录"没有
原始响应只能瞎猜）。

## ③ opencode / localzen：免费模型按**实测**收敛
用户报「localzen 也不能用了」。逐项实测（生产）：
- `space-bunny-free` → **410** `Model space-bunny-free has been deprecated.
  Use minimax-m3.1-flash-free instead.`（仍在本地源里 ⇒ 选中必失败）
- `jev-1.13-free` → 400 `Model does not support this protocol.`（非 OpenAI
  chat 协议，本端点永远调不通）
- `beam-free` → 200 但 content 空、无 finish_reason
- 其余 7 个（mimo / nemotron-super-vl / nemotron-lightning / longcat /
  deepseek-v4.1 / glm-5.3-flash / minimax-m3.1-flash）全部正常返回内容

修法：
- `DEAD_GONE_PATTERNS` 补 opencode 的下架文案
  （`Model … has been deprecated`）；配阴/阳性判据（参数/字段被弃用**不算**）；
- opencode 平台把 jev-1.13-free / beam-free 列入 `models_unavailable`，
  并从兜底表与 models_free 里移除；
- 生产 `localzen` 源（手写源，插件不管）按实测刷新为 7 个可用免费模型，
  逐个验证返回内容。

## 纪律
渠道逻辑全部留在插件里（channels.lua / 插件自装适配器）；内核这轮**没有**
新增任何厂商语义 —— 上一轮加进内核的只有通用的 `adapter.hidden` 机制。
 2026-10-20 09:13:56 +08:00
root
2924da0032 fix(gui): 桌面版真正加载渠道插件 + 外链一律交给默认浏览器 
## ① 桌面版此前**完全没有插件系统**（渠道页根本不存在）
GUI 内嵌内核的 config.yaml 由 main.js 生成，唯独漏了 `plugin_dir` ——
而内核刻意不给它默认值（运维显式开启）。后果：桌面版 `plugin_dir: ""`，
`/api/plugins` 返回空列表，channels 插件（多平台账号登录、凭据保管、自动
领取）在桌面端**完全不可见**。实测复现：同一份配置去掉 plugin_dir 就是
`plugins: []`，加上就有 billing/channels/quota/usage 四个。

修法：
- 新 profile 直接写 `plugin_dir: <profile>/plugins`；
- **老 profile 回填**（用户已有 config.yaml，不写就只有老用户永远没有插件）——
  新增 `ensurePluginDirConfigured()`，只在缺少该键时追加，其余内容不动；
- 插件树由内核 SeedBundled 播种（按文件补齐，用户改过的副本优先保留）。

## ② 升级后渠道修复**下发不到桌面用户**
内核播种规则是「文件缺失才写」，所以桌面用户升级 GUI 后 `channels.lua`
仍是旧版 —— 我们发的渠道修复对桌面用户静默失效。桌面版必须自己处理：
按 app 版本打戳（`.plugin-seed-version`），版本变化时删掉 4 个内置插件文件
让新内核重新播种，旧副本留 `.prev-<旧版本>` 可人工恢复；用户自建插件不碰。
逻辑抽到 `cmd/gui/plugin-sync.js`（无 Electron 依赖），配 6 条 node 单测。

## ③ 登录一律拉起默认浏览器（三条路径都覆盖）
桌面版的内容区是加载内核 WebUI 的 iframe，渠道登录链接是 `target=_blank`。
此前只处理了 `setWindowOpenHandler`，另两条路径仍会把 Electron 窗口带到
第三方页面。现在三条路径统一外抛：
1. `window.open` / target=_blank  → setWindowOpenHandler
2. 顶层同标签跳转               → will-navigate
3. iframe 内导航                → will-frame-navigate
**loopback 例外必须保留**：channels 的服务端浏览器（noVNC）就在
`127.0.0.1:<port>` 的 iframe 里，拦掉它会让 VNC 登录失效。

实测（打包后的 GUI + Xvfb + CDP 驱动真实窗口）：
  [gui] open in default browser: https://example.com/mr-windowopen-probe
  [gui] open in default browser: https://example.com/mr-navigate-probe
  [gui] open in default browser: https://example.com/mr-frame-probe
  [gui] open in default browser: https://xiaohuanxiong.com/login?code=…（真实商汤登录链接）
顶层 URL 保持在内核页面（跳转被拦下），loopback iframe 正常加载。

## ④ 顺手
- GUI 版本号 1.9.7 → 2.0.42（与内核同版本发版；package-lock 里还是 1.9.3，
  一并同步）；
- `make gui-test` 跑桌面壳单测。

验证：打包后的 GUI 启动即 `/api/plugins` 列出 channels（ui.page=channels），
插件目录播种 4 个内置插件；外链四类实测均走默认浏览器。

(cherry picked from commit 411503aea5)
 2026-10-20 08:52:39 +08:00
root
411503aea5 fix(gui): 桌面版真正加载渠道插件 + 外链一律交给默认浏览器 
## ① 桌面版此前**完全没有插件系统**（渠道页根本不存在）
GUI 内嵌内核的 config.yaml 由 main.js 生成，唯独漏了 `plugin_dir` ——
而内核刻意不给它默认值（运维显式开启）。后果：桌面版 `plugin_dir: ""`，
`/api/plugins` 返回空列表，channels 插件（多平台账号登录、凭据保管、自动
领取）在桌面端**完全不可见**。实测复现：同一份配置去掉 plugin_dir 就是
`plugins: []`，加上就有 billing/channels/quota/usage 四个。

修法：
- 新 profile 直接写 `plugin_dir: <profile>/plugins`；
- **老 profile 回填**（用户已有 config.yaml，不写就只有老用户永远没有插件）——
  新增 `ensurePluginDirConfigured()`，只在缺少该键时追加，其余内容不动；
- 插件树由内核 SeedBundled 播种（按文件补齐，用户改过的副本优先保留）。

## ② 升级后渠道修复**下发不到桌面用户**
内核播种规则是「文件缺失才写」，所以桌面用户升级 GUI 后 `channels.lua`
仍是旧版 —— 我们发的渠道修复对桌面用户静默失效。桌面版必须自己处理：
按 app 版本打戳（`.plugin-seed-version`），版本变化时删掉 4 个内置插件文件
让新内核重新播种，旧副本留 `.prev-<旧版本>` 可人工恢复；用户自建插件不碰。
逻辑抽到 `cmd/gui/plugin-sync.js`（无 Electron 依赖），配 6 条 node 单测。

## ③ 登录一律拉起默认浏览器（三条路径都覆盖）
桌面版的内容区是加载内核 WebUI 的 iframe，渠道登录链接是 `target=_blank`。
此前只处理了 `setWindowOpenHandler`，另两条路径仍会把 Electron 窗口带到
第三方页面。现在三条路径统一外抛：
1. `window.open` / target=_blank  → setWindowOpenHandler
2. 顶层同标签跳转               → will-navigate
3. iframe 内导航                → will-frame-navigate
**loopback 例外必须保留**：channels 的服务端浏览器（noVNC）就在
`127.0.0.1:<port>` 的 iframe 里，拦掉它会让 VNC 登录失效。

实测（打包后的 GUI + Xvfb + CDP 驱动真实窗口）：
  [gui] open in default browser: https://example.com/mr-windowopen-probe
  [gui] open in default browser: https://example.com/mr-navigate-probe
  [gui] open in default browser: https://example.com/mr-frame-probe
  [gui] open in default browser: https://xiaohuanxiong.com/login?code=…（真实商汤登录链接）
顶层 URL 保持在内核页面（跳转被拦下），loopback iframe 正常加载。

## ④ 顺手
- GUI 版本号 1.9.7 → 2.0.42（与内核同版本发版；package-lock 里还是 1.9.3，
  一并同步）；
- `make gui-test` 跑桌面壳单测。

验证：打包后的 GUI 启动即 `/api/plugins` 列出 channels（ui.page=channels），
插件目录播种 4 个内置插件；外链四类实测均走默认浏览器。
v2.0.42 		2026-10-20 08:44:07 +08:00
root
9c7b5f8556 fix(channels): 商汤扫码链路重建 + 双区登录 + 凭据过期口径 + 四条老化判据 
① 商汤（Raccoon）扫码「链接无效」——两个真根因
- 登录页 /login/mp 已被站点删除（Next 路由 404，实测只有 404 页）；
- 旧实现本地随机造 qrcode_code，而上游早已不认自造码：旧端点
  /api/web/auth/v1/login_with_qrcode_code 对任意 code 恒回 pending
  （服务端没有该会话）⇒ 扫码永远完不成，账号一直是空凭据。
修法：改为上游现行 IAM 流程（逐行对齐其网页客户端 auth chunk）——
  POST /api/iam/v1/auth/mp/qrcode 建会话 → 链接用
  /login?code=…&appname=…&source=platform（实测 200 + 微信扫码面板）
  → 轮询 /api/iam/v1/auth/mp/qrcode/login（IAM code:"OK" 与旧 code:0 都认）。
  服务端建码失败才退回旧本地码并打 warn。UI 对扫码流程改文案为
  「用微信扫码」（原本文案会让人以为点开就自动登录）。
生产实测：链接 HTTP 200、轮询回 pending（会话真实存在）。

② 双区登录（P7）
- 凭据增加 region（intl|cn，缺省＝历史行为）；start_login 接受 region，
  会话按区域选端点，完成登录写进凭据；
- CodeBuddy：cn=copilot.tencent.com（platform=ide）/
  intl=www.workbuddy.ai（platform=workbuddy-ai，X-Domain、
  X-Product-Code、UA 按区域；实测 auth/state 回 200 信封）；
- Qoder：intl=openapi.qoder.sh+qoder.com（client_id e883ade2-…）/
  cn=openapi.qoder.com.cn+qoder.cn（client_id 不同 732aef47-…，照参考
  QODER_CN）。CN 无公开 chat 端点 ⇒ CN 只做登录/领取；
- UI：buddy/qoder 详情页增加「＋国际区」按钮。

③ 凭据过期时刻的时区口径（P6 真根因）
credentialExpiresAtMs 把 ISO 过期时刻按本地时区解析，而 codearts 给的是
UTC ISO（2026-10-19T16:42:43.06Z）⇒ 本机 +08 下过期时刻虚早 8 小时 ⇒
refresh_creds 每 30 分钟都判"已过期"并对华为云真打一次 STS（token 本还有
23 小时寿命）。改为按声明时区解析（Z / ±hh:mm / 无后缀=UTC 三种形态同一
epoch），补 TestCredentialExpiresAtMsParsesISOAsUTC。

④ 四条老化/假红判据
- TestCreditsPoolReason*：account_add 触发的选号会用构造期默认余额 (0,0)
  先查一次并缓存 60s ⇒ 之后改假上游读不到（"余额 100 却报 exhausted"）。
  harness 改余额后清 TTL 缓存（__ttl_reset_probe，与生产同一实现）。
- TestAccountReorderActually... / TestPoolListOrderIsDeterministic：随
  「一通道一源」失效（按 channels-buddy-<acct> 过滤恒得空）。改写为——
  重排必须切换服务账号（新增 __chosen_account_probe），顺序确定性改为断言
  选号顺序（__rank_accounts_probe）由 id 稳定决定。
- channels.lua 顶层 local 余量：区域表与 5 份适配器源码常量收进 plugin.K
  （TestChannelsLuaHasLocalHeadroom 需要 ≥10 槽位）；ZCode 适配器源码里的
  CLI_PREFIX 必须留在源码内（适配器沙箱没有 plugin 全局）。

⑤ 错误文案
openai_error 增补腾讯 codebuddy 三层嵌套 {error:{data:{code,msg}}}：实测
429 code=14018「额度已用尽」此前落到"不识别"，客户端只看到通用文案。

验证：core 434s 全绿、lua 62s 全绿、provider 全绿；生产已部署并实测
raccoon 链接 200 / trae 非流式 200 / zcode 适配器加载。

(cherry picked from commit 662f8f02b6)
 2026-10-20 08:27:41 +08:00
root
662f8f02b6 fix(channels): 商汤扫码链路重建 + 双区登录 + 凭据过期口径 + 四条老化判据 
① 商汤（Raccoon）扫码「链接无效」——两个真根因
- 登录页 /login/mp 已被站点删除（Next 路由 404，实测只有 404 页）；
- 旧实现本地随机造 qrcode_code，而上游早已不认自造码：旧端点
  /api/web/auth/v1/login_with_qrcode_code 对任意 code 恒回 pending
  （服务端没有该会话）⇒ 扫码永远完不成，账号一直是空凭据。
修法：改为上游现行 IAM 流程（逐行对齐其网页客户端 auth chunk）——
  POST /api/iam/v1/auth/mp/qrcode 建会话 → 链接用
  /login?code=…&appname=…&source=platform（实测 200 + 微信扫码面板）
  → 轮询 /api/iam/v1/auth/mp/qrcode/login（IAM code:"OK" 与旧 code:0 都认）。
  服务端建码失败才退回旧本地码并打 warn。UI 对扫码流程改文案为
  「用微信扫码」（原本文案会让人以为点开就自动登录）。
生产实测：链接 HTTP 200、轮询回 pending（会话真实存在）。

② 双区登录（P7）
- 凭据增加 region（intl|cn，缺省＝历史行为）；start_login 接受 region，
  会话按区域选端点，完成登录写进凭据；
- CodeBuddy：cn=copilot.tencent.com（platform=ide）/
  intl=www.workbuddy.ai（platform=workbuddy-ai，X-Domain、
  X-Product-Code、UA 按区域；实测 auth/state 回 200 信封）；
- Qoder：intl=openapi.qoder.sh+qoder.com（client_id e883ade2-…）/
  cn=openapi.qoder.com.cn+qoder.cn（client_id 不同 732aef47-…，照参考
  QODER_CN）。CN 无公开 chat 端点 ⇒ CN 只做登录/领取；
- UI：buddy/qoder 详情页增加「＋国际区」按钮。

③ 凭据过期时刻的时区口径（P6 真根因）
credentialExpiresAtMs 把 ISO 过期时刻按本地时区解析，而 codearts 给的是
UTC ISO（2026-10-19T16:42:43.06Z）⇒ 本机 +08 下过期时刻虚早 8 小时 ⇒
refresh_creds 每 30 分钟都判"已过期"并对华为云真打一次 STS（token 本还有
23 小时寿命）。改为按声明时区解析（Z / ±hh:mm / 无后缀=UTC 三种形态同一
epoch），补 TestCredentialExpiresAtMsParsesISOAsUTC。

④ 四条老化/假红判据
- TestCreditsPoolReason*：account_add 触发的选号会用构造期默认余额 (0,0)
  先查一次并缓存 60s ⇒ 之后改假上游读不到（"余额 100 却报 exhausted"）。
  harness 改余额后清 TTL 缓存（__ttl_reset_probe，与生产同一实现）。
- TestAccountReorderActually... / TestPoolListOrderIsDeterministic：随
  「一通道一源」失效（按 channels-buddy-<acct> 过滤恒得空）。改写为——
  重排必须切换服务账号（新增 __chosen_account_probe），顺序确定性改为断言
  选号顺序（__rank_accounts_probe）由 id 稳定决定。
- channels.lua 顶层 local 余量：区域表与 5 份适配器源码常量收进 plugin.K
  （TestChannelsLuaHasLocalHeadroom 需要 ≥10 槽位）；ZCode 适配器源码里的
  CLI_PREFIX 必须留在源码内（适配器沙箱没有 plugin 全局）。

⑤ 错误文案
openai_error 增补腾讯 codebuddy 三层嵌套 {error:{data:{code,msg}}}：实测
429 code=14018「额度已用尽」此前落到"不识别"，客户端只看到通用文案。

验证：core 434s 全绿、lua 62s 全绿、provider 全绿；生产已部署并实测
raccoon 链接 200 / trae 非流式 200 / zcode 适配器加载。
 2026-10-20 08:27:28 +08:00
JianFeeeee
b0f33c188f fix: 收口渠道源迁移与测试页合并 
(cherry picked from commit 12bfd53f16)
 2026-10-19 22:36:13 +08:00
root
711ccdeea8 fix(channels): 四渠道修复 —— qoder 裸 token 领取 / trae+buddy 非流式 / opencode 目录 / 隐藏适配器 
生产实测逐渠道排查（2026-10-19）：

* qoder：PKCE 设备码流无 register 第二跳，落库凭据是裸 token 字符串；
  qoderClaim 硬要求结构化 table 导致「缺少凭据对象」（而 account_test
  走 token 路径正常 —— 自相矛盾状态）。改为非空裸 tok 就地包
  {access_token=tok}；补 TestQoderClaimAcceptsBareTokenCredential。

* trae（SOLO 自装适配器）：上游对非流式请求也回 SSE（event: 前缀帧），
  transform_response 不识别 → 整个 body 原样透传 → Go unmarshal 报
  invalid character 'e'。补 aggregate_solo_sse 聚合。

* buddy（CodeBuddy）：上游 400 11101 只支持流式。transform_request 强制
  stream=true；transform_response 补 SSE 聚合（tool_calls 按 index 拼分片）。

* provider 流式：真实 tool-call 片段之后出现 finish_reason=stop 时归一为
  tool_calls（trae 实测如此发）；buddy/trae 不再序列化空 tool_calls 表。

* opencode：远端目录端点改为 /zen/v1/models（裸 /v1/models 回 HTML）；
  兜底目录同步 2026-10-19 实测（space-bunny-free 410 下架等 5 项变化）。
  opencodezen 适配器 v1.1.0：会话亲和（client_session / 首 user 消息指纹
  分桶），保留免费层门禁四要素。

* 内核：适配器可声明 adapter.hidden = true 退出用户可见列表；被源引用的
  隐藏适配器保持可见（源编辑器要回显当前值）。opencodezen 默认隐藏。

* channels UI：切渠道立即清空账号/模型区 + 响应代际校验，修复 qoder 账号
  闪现在 opencode 卡片下的渲染竞态。

* channels request_end hook：挂接丢失的 isModelGone/recordDeadModel ——
  真实 404（如 codearts GLM-5.3 "The model is not registered"）现在会进
  deadModels，不再每轮 404 仍可选中。

(cherry picked from commit 2113bfc125)
 2026-10-19 22:35:47 +08:00
JianFeeeee
ff7051d608 refactor(scheduler)!: 移除 priority 废弃字段 + 一通道一源 + discover 复用凭据 
用户判据：「priority 直接移除」「即使带 key 也没有 /v1/responses」
「channel 插件的问题还没完全解决」「生图和聊天合并到一个导航项」

## 一、删除 priority（它从未参与跨源调度）

`config.Model.Priority` 号称"高者优先参与 AUTO 选源"，**那是错的**：
AUTO 链由 `config.ModelScope.Tier` 驱动（scheduler.Chain），priority 只被
`bestChatModel/bestImageModel` 用于"本源内部该发哪个模型"，与跨源调度无关。
把它当调度依据会让人以为拖个数字就能改顺序，改完毫无效果。

- 删 `config.Model.Priority` 字段与 `bestChatModel/bestImageModel` 的优先级比较
- 删 `seedAuto()`：**AUTO 链为空时网关应直接 503**，不能凭空播种用户没配过的档位
- 删 UI `buildLanes` 的 discovery 回退（按源 priority 自动铺开）与 sourceRows
- 清掉 config.yaml 里 140 行 priority

## 二、一通道 = 一个适配器 = 一个源（channels 插件）

旧设计「一账号一源」(`channels-<平台>-<12位hex>`) 有三个结构性后果：
1. 三个账号 ⇒ 三个源、三份同名模型，用户看到三行无法区分的东西
2. 谁先谁后**取决于注册顺序，不是余额**（rankAccounts 只用于展示，从未接进同步路径）
3. 换号要改源名 ⇒ 用户书签里的 `源:模型` 全部失效

新设计：
- 源名只跟通道绑定：`channels-<平台>`，换号 = 同名 add_source 覆盖 api_key
  （内核 AddSource 是 UpsertSourceInYAML + 内存替换），对客户端完全透明
- `pickAccountForSource()`：凭据可用 → 余额分档（先快作废后永久）→
  跳过已标记失效的号。没有 balance 声明的平台不据此排除（不因"不会查"判死）
- `request_end` 钩子：真实请求失败且是**终态**错误（需充值/封禁/凭据永久失效）
  时给当前账号打 termErr，下次选号跳过；成功则清标记。
  ⚠️ 只认终态 —— 429/超时/抖动都**不**标记（那会把好号一个个废掉）
- `refresh_creds` 每 30 分钟巡检后重新选号（兜底心跳，纯本地判定）
- 迁移：同步时自动清掉旧版按账号拆的源（按已知平台前缀匹配，不用贪婪 match）
- 顺带修：`refresh_creds` 漏认 `refresh_fn` ⇒ codearts 的 DPoP 续期永不触发

## 三、discover 支持用已存凭据（真实缺口）

刷新已有源的模型目录，此前必须让运维**再粘一次明文 key** —— 而库里是
`enc:v1:` 密文，WebUI 也不回显明文。结果就是"想刷新 → 得重新申请 key"，
很多人干脆不刷，源的目录越放越旧（实例：某源 3 个生图模型从未登记）。

- `{"name":"oin"}` ⇒ 从已存源取 base_url + 解密凭据 + adapter
- 安全边界：已要求 admin；只能探测**本网关已配置的**源（不能拿任意 URL+key
  做探测，那就成了 SSRF/密钥外带）；响应不回显 key

## 四、image_models 显式声明（补元数据缺失）

`discoveredModelKind` 只看上游 modality 字段，并刻意**不从模型名推断**
（错误的 kind 会毒死 AUTO 链）。但有些网关的 /v1/models 只返回
`{id,object,created,owned_by}` —— 零 modality，于是生图模型全落成 chat，
生图端点永远 `no image source configured`。

不解这个两难：默认仍完全按元数据（不猜），但允许 `image_models` **显式声明**。
写错的 id 明确报 400，不静默造一个不存在的模型。

## 五、UI：对话与生图合并为一个导航项

两者本是同一件事的两种输入（都选模型、都发请求、都读结果），只是 kind 与端点
不同。合并只发生在**导航层**：模型下拉仍按 kind 分组/禁选（把图片模型选进 chat
会请求到错误端点）。两个面板同时存在于 DOM，切换只改 display —— 来回切不会丢
已输入的文字、对话历史或已生成的图。

## 测试

- `TestUI_ImageModeIsReachableFromChatTab`：改为钉"合并后仍可达"（分段控件、
  切换函数、面板容器、端点），并断言**旧 tab 三件套必须消失**（否则 goTab 会找
  一个不存在的面板）
- 测试夹具显式建 AUTO 链（内核不再 seedAuto）：默认一源一 tier 倒序
  （TestChatAUTO 验优先级）；TestChatAutoChainTierFailover 自己覆盖成同 tier
  （验 tier 内轮转）—— 两者验不同机制，不能共用一个默认
- core 的一批断言从"按账号 id 找源"改为"按平台名找源"

gateway/config/provider 全绿；core 的 channels 用例全绿。
TestRealMutants 需工作树干净后才跑（其自带的变异残留防护）。

BREAKING CHANGE: config.Model.Priority 已删除。旧的 priority 字段会被 YAML
解码静默忽略（内核不校验未知字段），因此既有 config.yaml 仍可加载，但该字段
不再有任何作用 —— 调度顺序请通过 AUTO 链的 tier 表达。

(cherry picked from commit 25970a2135)
 2026-10-19 22:35:47 +08:00
JianFeeeee
efc9b37965 fix(codearts): 识别 InferHub 未注册模型 
(cherry picked from commit c9f34538ec)
 2026-10-19 22:35:47 +08:00
root
2113bfc125 fix(channels): 四渠道修复 —— qoder 裸 token 领取 / trae+buddy 非流式 / opencode 目录 / 隐藏适配器 
生产实测逐渠道排查（2026-10-19）：

* qoder：PKCE 设备码流无 register 第二跳，落库凭据是裸 token 字符串；
  qoderClaim 硬要求结构化 table 导致「缺少凭据对象」（而 account_test
  走 token 路径正常 —— 自相矛盾状态）。改为非空裸 tok 就地包
  {access_token=tok}；补 TestQoderClaimAcceptsBareTokenCredential。

* trae（SOLO 自装适配器）：上游对非流式请求也回 SSE（event: 前缀帧），
  transform_response 不识别 → 整个 body 原样透传 → Go unmarshal 报
  invalid character 'e'。补 aggregate_solo_sse 聚合。

* buddy（CodeBuddy）：上游 400 11101 只支持流式。transform_request 强制
  stream=true；transform_response 补 SSE 聚合（tool_calls 按 index 拼分片）。

* provider 流式：真实 tool-call 片段之后出现 finish_reason=stop 时归一为
  tool_calls（trae 实测如此发）；buddy/trae 不再序列化空 tool_calls 表。

* opencode：远端目录端点改为 /zen/v1/models（裸 /v1/models 回 HTML）；
  兜底目录同步 2026-10-19 实测（space-bunny-free 410 下架等 5 项变化）。
  opencodezen 适配器 v1.1.0：会话亲和（client_session / 首 user 消息指纹
  分桶），保留免费层门禁四要素。

* 内核：适配器可声明 adapter.hidden = true 退出用户可见列表；被源引用的
  隐藏适配器保持可见（源编辑器要回显当前值）。opencodezen 默认隐藏。

* channels UI：切渠道立即清空账号/模型区 + 响应代际校验，修复 qoder 账号
  闪现在 opencode 卡片下的渲染竞态。

* channels request_end hook：挂接丢失的 isModelGone/recordDeadModel ——
  真实 404（如 codearts GLM-5.3 "The model is not registered"）现在会进
  deadModels，不再每轮 404 仍可选中。
v2.0.41 		2026-10-19 22:32:18 +08:00
JianFeeeee
c9f34538ec fix(codearts): 识别 InferHub 未注册模型 2026-10-19 18:02:30 +08:00
JianFeeeee
12bfd53f16 fix: 收口渠道源迁移与测试页合并 2026-10-19 17:21:22 +08:00
JianFeeeee
25970a2135 refactor(scheduler)!: 移除 priority 废弃字段 + 一通道一源 + discover 复用凭据 
用户判据：「priority 直接移除」「即使带 key 也没有 /v1/responses」
「channel 插件的问题还没完全解决」「生图和聊天合并到一个导航项」

## 一、删除 priority（它从未参与跨源调度）

`config.Model.Priority` 号称"高者优先参与 AUTO 选源"，**那是错的**：
AUTO 链由 `config.ModelScope.Tier` 驱动（scheduler.Chain），priority 只被
`bestChatModel/bestImageModel` 用于"本源内部该发哪个模型"，与跨源调度无关。
把它当调度依据会让人以为拖个数字就能改顺序，改完毫无效果。

- 删 `config.Model.Priority` 字段与 `bestChatModel/bestImageModel` 的优先级比较
- 删 `seedAuto()`：**AUTO 链为空时网关应直接 503**，不能凭空播种用户没配过的档位
- 删 UI `buildLanes` 的 discovery 回退（按源 priority 自动铺开）与 sourceRows
- 清掉 config.yaml 里 140 行 priority

## 二、一通道 = 一个适配器 = 一个源（channels 插件）

旧设计「一账号一源」(`channels-<平台>-<12位hex>`) 有三个结构性后果：
1. 三个账号 ⇒ 三个源、三份同名模型，用户看到三行无法区分的东西
2. 谁先谁后**取决于注册顺序，不是余额**（rankAccounts 只用于展示，从未接进同步路径）
3. 换号要改源名 ⇒ 用户书签里的 `源:模型` 全部失效

新设计：
- 源名只跟通道绑定：`channels-<平台>`，换号 = 同名 add_source 覆盖 api_key
  （内核 AddSource 是 UpsertSourceInYAML + 内存替换），对客户端完全透明
- `pickAccountForSource()`：凭据可用 → 余额分档（先快作废后永久）→
  跳过已标记失效的号。没有 balance 声明的平台不据此排除（不因"不会查"判死）
- `request_end` 钩子：真实请求失败且是**终态**错误（需充值/封禁/凭据永久失效）
  时给当前账号打 termErr，下次选号跳过；成功则清标记。
  ⚠️ 只认终态 —— 429/超时/抖动都**不**标记（那会把好号一个个废掉）
- `refresh_creds` 每 30 分钟巡检后重新选号（兜底心跳，纯本地判定）
- 迁移：同步时自动清掉旧版按账号拆的源（按已知平台前缀匹配，不用贪婪 match）
- 顺带修：`refresh_creds` 漏认 `refresh_fn` ⇒ codearts 的 DPoP 续期永不触发

## 三、discover 支持用已存凭据（真实缺口）

刷新已有源的模型目录，此前必须让运维**再粘一次明文 key** —— 而库里是
`enc:v1:` 密文，WebUI 也不回显明文。结果就是"想刷新 → 得重新申请 key"，
很多人干脆不刷，源的目录越放越旧（实例：某源 3 个生图模型从未登记）。

- `{"name":"oin"}` ⇒ 从已存源取 base_url + 解密凭据 + adapter
- 安全边界：已要求 admin；只能探测**本网关已配置的**源（不能拿任意 URL+key
  做探测，那就成了 SSRF/密钥外带）；响应不回显 key

## 四、image_models 显式声明（补元数据缺失）

`discoveredModelKind` 只看上游 modality 字段，并刻意**不从模型名推断**
（错误的 kind 会毒死 AUTO 链）。但有些网关的 /v1/models 只返回
`{id,object,created,owned_by}` —— 零 modality，于是生图模型全落成 chat，
生图端点永远 `no image source configured`。

不解这个两难：默认仍完全按元数据（不猜），但允许 `image_models` **显式声明**。
写错的 id 明确报 400，不静默造一个不存在的模型。

## 五、UI：对话与生图合并为一个导航项

两者本是同一件事的两种输入（都选模型、都发请求、都读结果），只是 kind 与端点
不同。合并只发生在**导航层**：模型下拉仍按 kind 分组/禁选（把图片模型选进 chat
会请求到错误端点）。两个面板同时存在于 DOM，切换只改 display —— 来回切不会丢
已输入的文字、对话历史或已生成的图。

## 测试

- `TestUI_ImageModeIsReachableFromChatTab`：改为钉"合并后仍可达"（分段控件、
  切换函数、面板容器、端点），并断言**旧 tab 三件套必须消失**（否则 goTab 会找
  一个不存在的面板）
- 测试夹具显式建 AUTO 链（内核不再 seedAuto）：默认一源一 tier 倒序
  （TestChatAUTO 验优先级）；TestChatAutoChainTierFailover 自己覆盖成同 tier
  （验 tier 内轮转）—— 两者验不同机制，不能共用一个默认
- core 的一批断言从"按账号 id 找源"改为"按平台名找源"

gateway/config/provider 全绿；core 的 channels 用例全绿。
TestRealMutants 需工作树干净后才跑（其自带的变异残留防护）。

BREAKING CHANGE: config.Model.Priority 已删除。旧的 priority 字段会被 YAML
解码静默忽略（内核不校验未知字段），因此既有 config.yaml 仍可加载，但该字段
不再有任何作用 —— 调度顺序请通过 AUTO 链的 tier 表达。
 2026-10-19 16:26:59 +08:00