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
502 Commits 10 Branches 90 Tags
190c2d23d6011d1887bd6c3c6df3aea618fc35de
Commit Graph

502 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
JianFeeeee
190c2d23d6 docs: 补 MIT LICENSE 与许可声明（G-Star 申报要求明确的许可证） 2026-10-27 10:14:23 +08:00
JianFeeeee
1ae9558547 docs: HANDOFF 加注（渠道能力已于 v3.0.2 移除） 2026-10-27 09:27:18 +08:00
JianFeeeee
b09d19d8f4 chore(gui): 版本号 3.0.2（合规清理：移除私有协议适配器与渠道插件） 2026-10-27 09:25:58 +08:00
JianFeeeee
8f2c5572e7 chore!: 移除厂商私有协议适配器与渠道业务插件（合规清理） 
G-Star 合规要求下，把"模拟官方客户端、复刻私有协议、自动领取平台额度"这一类
能力整体移出仓库。这些实现依赖各平台未公开的端点、签名算法与官方 client id，
属于绕过客户端校验获取额度，风险高于普通协议适配。

移除（93 个文件）：
- 适配器：opencodezen（伪装 UA 取免费池）、trae、buddy、kimicode
- 插件：channels.lua（12 个平台登录/领额度/签到）、quota.lua（厂商额度探针）
- 随之删除的 78 个渠道/额度专用测试与 3 份渠道文档

同时修掉的既有问题：
- **硬编码第三方 OAuth client_secret**（Google Cloud Code 的 GOCSPX-…，两处）
  随 channels.lua 一起消失。
- `deploy.sh` 的 `sync_plugins` 整段删除：它仍按"内置插件是发行物"的旧前提
  把插件复制/覆盖进 plugin_dir，与"插件属运维资产、网关不安装不覆盖"的契约
  冲突。现在部署脚本只同步适配器与二进制/配置。
- 适配器清单去掉已移除项；e2e 配置改用显式 `auto:` 链（`models.priority` 早已
  移除，该测试此前已失效）。

保留（公开协议）：openai / anthropic / gemini / deepseek / github / groq /
mistral / ollama / qwen38 / sensenova = 10 个适配器；插件示例 billing / usage。

验证：go build -tags luajit ./... OK；internal/lua 21.4s、provider、core 51s、
gateway 122.8s、e2e 9.0s 全绿。
 2026-10-27 09:25:58 +08:00
JianFeeeee
449e59dd52 chore(gui): 版本号 3.0.1（与内核同版本） 
v3.0.1 修的是发布包缺陷（unit 路径、core-dist 无 nfpm、桌面包内嵌核心未 strip），
桌面端版本号必须跟内核一致：升级判断与插件目录维护都读这个字段。
 2026-10-27 00:51:13 +08:00
JianFeeeee
c0d7c79d0d fix(gui-win): docker 内联编译也加 -s -w 
上一提交只改了 prepare-core.js（npm run core:win 路径），而 docker 构建走的是
dist-win-docker.sh 里的内联 go build，产物里的内嵌核心仍是 17.8MB 带调试符号。

两处必须同步，否则"用哪种方式构建"会决定包大小：现在 Linux 与 Windows 的内嵌
核心都剥符号。
 2026-10-27 00:51:13 +08:00
JianFeeeee
1496255488 fix(gui): Windows 构建链改用 modelrouter 命名 + 内嵌核心 strip 
改名在桌面打包链上漏了两处，都是"构建能过、产物不可用"的类型：

1. `dist-win-docker.sh` 仍交叉编译到 `bin/llmsproxy.exe` 并构建
   `./cmd/llmsproxy`，而 package.json 的 extraResources 已指向
   `bin/modelrouter.exe` —— Windows 包装完会缺内嵌核心。
   同时把 npmmirror 的 electron / electron-builder-binaries 镜像传进容器：
   首次构建需在容器内下载数百 MB，直连会卡满 600s 请求超时（Linux 侧已实测）。

2. `prepare-core.js` 只带 `-trimpath`，内嵌核心保留调试符号（14.4MB）。
   补 `-ldflags "-s -w"`，与 `packaging/core-dist.sh` 一致，各平台安装包少约 4MB。
 2026-10-27 00:51:13 +08:00
JianFeeeee
e2ced5ed66 fix(packaging): 包内 unit 指向 /usr/bin；core-dist 支持无 nfpm 打包 
两个都是发布链上的真缺陷，构建 v3.0.0 产物时才暴露：

1. **unit 与包内二进制路径不一致**：deb/rpm 把二进制装到 `/usr/bin/modelrouter`，
   而 `modelrouter.service` 的 `ExecStart` 写 `/usr/local/bin/modelrouter`。
   装包后 `systemctl start` 只会给 203/EXEC，看起来像"装好了但起不来"。
   - 包内 unit 改 `/usr/bin/modelrouter`（FHS，装包即用）
   - 源码部署仍用 `/usr/local/bin`，`deploy.sh` 增加校验：unit 的 ExecStart
     指向不存在的文件时**中止**并说明两种布局的区别
   - docs/deployment.md 同步说明

2. **core-dist 硬依赖 nfpm**：构建机离线（GOPROXY 不可达）时装不上 nfpm，
   发布直接被堵死。现在 nfpm 优先，缺失时回退 dpkg-deb + rpmbuild，
   两者产出同一套文件布局，并继续由末尾的 archive-content 门禁校验。
   - rpm 回退踩到的坑：postinst/prerm 末尾无换行时，`%preun` 会粘在
     `exit 0` 后面，整个 `%files` 段被吞，rpmbuild 报
     "Installed (but unpackaged) file(s) found"。
   - `%dir /etc/modelrouter` 要求 buildroot 里存在该目录，否则
     "Directory not found"。

验证：`./packaging/core-dist.sh 3.0.0` 产出 deb(4220KB)/rpm(4229KB)/tar(4145KB)；
包内 unit `ExecStart=/usr/bin/modelrouter`，`systemd-analyze verify --root` 通过；
deb/rpm 均不含 `plugins/`，adapters=14。
 2026-10-27 00:51:12 +08:00
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