ModelRouter

mirror of https://gitcode.com/JianFeeeee/ModelRouter.git synced 2026-11-07 09:47:23 +00:00

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
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	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	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	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	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	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
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
JianFeeeee	dcf327d3c5	fix(plugins): 三个坏渠道 + 三插件图标 + 计费可见性用户报障：「检查一下，同时修复坏渠道，还有插件不是可以自己决定注册哪些渠道吗？你怎么不修一下，还有除了 billing 以外的两个插件都没有正确的图标，而且另外两个插件计费也不正确」 ## 一、坏渠道（都在插件里修，不动内核） ### 1. zcode —— base_url 吞掉了 endpoint 路径（404） `base_url = https://zcode.z.ai/api/v1/zcode-plan/anthropic` `endpoint = /api/v1/zcode-plan/anthropic/v1/messages` 内核 URL = base_url + endpoint（provider.go ChatURL）⇒ 路径拼两遍： `.../anthropic/api/v1/zcode-plan/anthropic/v1/messages` → 404 page not found。修：base_url 只留 host，完整路径进 endpoint。与 v2.0.30 「12 平台 base_url 侵占 endpoint」同族。 ### 2. minimax —— 打到 Web 前端（404「简单指令，无限可能」） base_url 只到 host + adapter=openai ⇒ 请求 /chat/completions，那是 Web 前端。照参考 minimax-product.ts： MINIMAX_INFER_PATH = /mavis/api/v1/llm/v1/messages（Anthropic Messages）实测（2026-10-19）： /mavis/api/v1/llm/v1/messages → 401 invalid access token（路径对）裸 /chat/completions → 404 page not found /mavis/api/v1/chat/completions → 404 修：endpoint 指向真实推理路径 + adapter 改 anthropic（第二层：协议形状）。修后从 404 变 401（凭据问题，不再是路由问题）。 ### 3. codearts —— 只声明"可续期"却没声明"怎么续" `account_refresh` 走 `refreshCredential()`，要求 `plat.refresh.url` 或 `refresh_fn` 存在。codearts 只有 accountView 里硬编码的 `refreshable=true` ⇒ 恒返回「该平台未声明续期方式」，自动续期链空转，日志反复 `模型刷新失败 HTTP 400`。而 STS security_token 只有 1 小时寿命，过期后每个请求都是 `APIG.0602: the security token has expired`。修法（三层，每层都有独立的坑）： a) 加 `refresh_fn` 钩子。华为云 STS 要 DPoP 头（jwk 在凭据里），声明式 REFRESH_STYLES 拿不到私钥 ⇒ 必须用钩子挂已有的 `codeartsRequestToken`。 b) JWK → PEM 重建。`codeartsNewDpop()` 返回 {pem,public,private}，但凭据只持久化了 private(JWK)，pem 是登录临时文件。而 `codeartsDpopSign` 走 openssl 命令行要 `key.pem` 字符串 ⇒ 直接传会报 `bad argument #1 to 'write' (string expected, got nil)`。手工组 SEC1 `EC PRIVATE KEY` 的 DER（INTEGER 1 / OCTET STRING d / [0] OID prime256v1 / [1] BIT STRING 04\|\|X\|\|Y）再 PEM 包装。 c) 绑定放在文件末尾的绑定循环（与 claim_fn 同处）。在 PLATFORMS 表里内联会闭包捕获当时的全局 nil —— 与 trae headers_fn 那次同一坑。 ## 二、插件图标（3 个坏 1 个） billing 有 SVG 但缺 stroke/fill=currentColor（深色主题下不可见）； channels 声明 `icon = ""`（侧边栏空白）；quota 连 icon 字段都没有。统一成 inline SVG + `stroke="currentColor"`（照参考 src/sponsor.js:52 的图标工厂形状）。 ## 三、判据（4 条，全部做过变异验证） - `TestChannelBaseURLDoesNotSwallowEndpoint`：base_url 里的路径段不得在 endpoint 重复出现。走真实加载插件而非正则读源码 —— PLATFORMS 是 Lua 表，有注释/条件拼装/末尾绑定循环，正则会给出假绿。 - `TestMinimaxUsesAnthropicProtocolAndRealInferPath`：路径 + 协议双断言。 - `TestCodeartsDeclaresRefreshHook`：分开报 has_refresh_fn / has_refresh_decl。只看 refreshable 不够 —— 那是"凭据类型可续"，与"平台实现了续期"是两件事。 - `TestCodeartsRebuildsPemFromJwkAndSigns`：必须真签名。DER 结构错、长度错、base64 换行错都得到"非空但无效"的 PEM，只断言非空等于没验。 - `TestB64urlDecodeHandlesLongInput`：补一个真实测漏 —— 我的 b64urlDecode 第一版在输出字节后没清高位（缺 `buf = buf % (2^nbits)`），43 字符的 JWK 字段（32 字节）测出来完全正确，于是 PEM 判据在变异后依然全绿。只有 86 字符的长输入才暴露（double 精度耗尽 → string.char 抛 invalid value）。这条判据就是为"能跑、能返回、产物错"那类缺陷写的。 - `TestEveryPagePluginDeclaresSVGIcon` / `TestIconUsesCurrentColor`：按页面插件清单遍历而不是只覆盖 billing。billing 当年空串的判据只管它自己，于是 channels 空串、quota 缺字段时全绿 —— 同类缺陷换文件复发没有任何东西会响。这条测试还当场咬出了 billing 自己缺 currentColor。变异验证：zcode base_url 回退 ✓ / minimax adapter 回退 ✓ / 删 refresh_fn 绑定 ✓ / 去掉 buf 掩码 ✓ / OID 多套一层 TLV ✓（5/5 全部咬住） ## 四、计费（诊断，未改价）查清"计费不正确"的根因：`prices.models` 只配了 2 条（deepseek-v4.1-flash + 它的 / 前缀形式），而实际在用 193 个模型 ⇒ 112006 次请求里 35672 次（31.8%）成本按 $0 计。其中 28203 次集中在 2026-10-05 一天（历史一次性事件）；当前每天 27~137 次，且渠道模型全部未定价（Doubao-Seed-2.1-Pro / GLM-5.3-Flash / MiniMax-* / qwen3.6-plus / hy3）。调研：参考插件从 models.dev 拉模型目录（含 cost.input/output）。实测 models.dev 覆盖我们 139/193 模型（72%），但不能取中位数 —— 同一模型不同 provider 价差可达数千倍（glm-5.2 从 0 到 1.82）， 0 价多是订阅制/coding plan。按 host 匹配 provider 只覆盖 6/24 源。 ⇒ 价格口径需要用户确认，本轮不动价表。 6 个新探针（仅测试/诊断用）：__platform_def_probe（平台定义真相）、 __codearts_jwk_pem_probe（PEM 重建 + 真签名）、__b64_probe（解码字节）。	2026-10-19 13:43:27 +08:00
JianFeeeee	fc5326402f	fix(channels,provider): 渠道模型不可用 + 额度异常的三个根因 ## 背景用户报三问题：① channel 注册的模型无法使用；② 额度显示依旧异常； ③ 其他渠道应也存在类似问题。三条全部核实并给出结论（③ 见文档）。 ## ① 网关解不开 `源名:模型名` 限定名（internal/provider/registry.go） `ResolvePinned` 用 `strings.IndexAny(model, "-:/")` 找第一个分隔符。而渠道源名形如 `channels-trae-b8dd6b3df30e`（含 `-`），于是 `channels-trae-b8dd6b3df30e:Doubao-Seed-2.1-Pro` 被切成 src="channels"、model="trae-b8dd6b3df30e:Doubao-Seed-2.1-Pro" ⇒ 源名永不匹配 ⇒ `Resolve()` 返回 nil ⇒ 客户端看到 `model "..." is not configured`。为什么这个写法必须支持：本实例有 44 个模型被多源同时提供（`glm-5.2` 由 6 个源提供），WebUI 的模型下拉框用 `源名:模型名` 作为 option value 是有意设计 —— 用户必须能指定"从哪个源调用"。修法：抽 `splitPinned()`，按已知源名做最长前缀匹配（源名是已知集合，这是唯一可靠办法），保留旧 `-:/` 兜底以兼容非源名形态。 `EffectiveModel` 同步修（同一拆分规则，避免两处漂移）。 ## ② trae 适配器三连错（internal/lua/plugins/channels.lua）三个错误逐层叠加，每个都被上一层掩盖： (a) 没有 `build_headers` ⇒ 内核兜底发 `Authorization: Bearer`，而 trae 推理端点要 `Cloud-IDE-JWT` + 设备身份头 ⇒ 401「We're sorry, but we are not able to authenticate you」。 → 与上一轮「额度不可用」是同一根因的两个出口（额度端点修了、推理端点漏了）。教训：修"某一族请求的鉴权"时，必须把该族的所有出口列出来逐个对齐。 (b) header 常量的值是错的（照参考 trae-product.ts 的 TRAE 配置逐项核对）： · `X-App-Id` 抄成 `6eefa6c9`，真实是 `6eefa01c-1036-4c7e-9ca5-d891f63bfcd8` · `app_version_code` 用了 `0.1.52`，真实是日期式 `20260811` ⇒ 上游 `4001 bad request: binding: expr_path=app_version_code, cause=parameter type does not match binding data` (c) 流式转换完全不对：TRAE 是 SOLO 自定义 SSE： event:output → data:{"response":"###","reasoning_content":null,...} 正文在 `response`，推理在 `reasoning_content`。 · 套 `__prelude.openai_stream_chunk` ⇒ 无 `choices` ⇒ `empty stream` · 改成 OpenAI 外壳 `{choices:[{delta}]}` 仍然空 —— 内核 `json.Unmarshal(unified, &UnifiedChunk)` 解的是扁平结构，外壳字段全被丢弃 ⇒ 必须输出扁平 `{content, reasoning_content, usage, done, finish_reason}`。 ⚠️ 内核只把 `data:` 行交给适配器（`event:` 行在 provider.go 被丢弃），因此判别帧类型只能靠内容特征（`response` / `reasoning_content` / `finish_reason` / `prompt_tokens`），拿不到 event 名。 ## ③ 余额恒为 0（同文件 balance.total_fn）读的是 `p.credits_limit`（pack 顶层）—— 该字段根本不存在。真实路径是 `pack.entitlement_base_info.quota.credits_limit` （参考 trae-credits.ts:341）+ `pack.usage.credits_amount`。实测上游：`免费`(无该字段) / `每月登录赠送`(500) / `签到奖励`(100) ⇒ 实际 600。修法：读嵌套路径 + 保留顶层兼容 + `usage_summary.{total,consumed}_amount` 兜底。修后余额 600 → 实测 598.516（真实扣减）。 ## ④ 夹具与生产形状不一致（internal/core/channels_trae_test.go）夹具原先返回扁平 `{"Token":...}`，与生产 `{"Result":{"Token":...}}` 不符 ⇒ 「代码只读顶层」这个缺陷在夹具里恰好是对的，所有 trae 判据都绿。夹具形状错 = 判据必然虚假通过。这是 ExchangeToken 缺陷藏了两轮的原因。 ## 判据（新增，变异 4/4 咬住） - `internal/provider/registry_pinned_name_test.go`（4 用例） - `internal/core/channels_trae_chat_headers_test.go`（3 条） - `internal/core/channels_trae_solo_sse_test.go`（2 条） - `internal/core/channels_trae_credits_hdr_test.go`（1 条） - `internal/core/channels_trae_exchange_shape_test.go`（2 条） ## 文档 `docs/channel-repair-plan.md`：现状快照（生产实测）+ 各渠道缺陷矩阵 + 后续计划（P0-P4）。如实记录：其余 4 个渠道（zcode/cline/gemini/qoder）有同类缺陷风险，但账号数均为 0、无法做生产验证。 ## 生产已实测 - `channels-trae-...:Doubao-Seed-2.1-Pro` → 80 帧，正文 27 + 推理 299 - `channels-trae-...:glm-5.2` / `channels-buddy-...:hy4-preview` → OK - `credits/status` → active:true, dailyCredit:100, todayCheckedIn:true - `credits/balances` → total:598.516 credits	2026-10-17 17:38:58 +08:00
JianFeeeee	56ea269f98	feat(channels): reap_orphan_sources —— 清理 v2.0.28 事故留下的存量孤儿源 ## 发现路径：查"功能都正常了吗"，逐源核对时发现的生产 `config.yaml` 里有 21 个源，其中 `channels-buddy-585b335b64cf` 的账号 `585b335b64cf` 早已删除（v2.0.23/24 的无凭据账号清理），但它的源仍在对外服务： - 独占提供 `hy4-preview-x` ⇒ 实测报 `404 Route Not Found`； - 对 6 个共享模型则排在新源前面先被尝试（config 文件序即注册序） ⇒ 每次都撞 404 再回退，每次白付一次上游往返（实测 hy4-preview 稳定 3.1~3.5s）； - 它的 base_url 还是 v2.0.30 之前的旧口径（`https://copilot.tencent.com/v2/chat/completions`，侵占了 endpoint 路径）。根因：这正是 v2.0.28（`remove_source` 漏声明 ⇒ 撤源全被拒）日记里那句"账号删了、它的源还在对外服务"的存量残骸。 v2.0.28 修了声明，只防新增、不清理存量。发现的一个助力：v2.0.38 刚修好的错误文案让它暴露得更清楚 —— 客户端拿到的是 `404 Route Not Found`（APISIX 原文）而不是 `unknown error`。 ## 修法 1. 立即清理：走内核正式 API `DELETE /api/sources/<name>` 删掉该孤儿源（不手工改配置）。清理前备份配置，三重确认它确无对应账号。 2. 结构性修复：新增 `reap_orphan_sources` 正式入口（`POST channels/reap_orphan_sources`，admin），识别 `channels-<已知平台>-<账号id>` 且账号不在池中的源。 ### 安全性（破坏性操作两条纪律，照 `reap_loopbacks` 先例） - 只删该删的：按已知平台 id 前缀逐个匹配。 ⚠️ 不能用 `name:match("^channels%-(.+)-(.+)$")` —— Lua 的 `-` 是贪婪的，会把 `channels-buddy-buddy-main` 切成 plat="buddy-buddy"/acct="main" （账号 id 含 `-` 就错，而 `buddy-main` 就含）⇒ 孤儿漏杀。运维手工配的源、旧版单账号源 `channels-<平台>` 一律不碰。 - `dry_run` 默认开启：不带 `dry_run=false` 只报告不删。 ## 判据（`channels_orphan_source_test.go`，变异 2/2） - 造出真实形态：`account_add` 建账号 → hidden 探针摘池（保留源），模拟"源留下"这个状态（不走 `account_delete`：那条路径会把源一并撤掉，而我们要的恰恰是它留下的形态）。 - 断言三件事：dry_run 只报告不删、真删后孤儿消失、手工源全程存活。 - 判别性用例：第二个孤儿的账号 id 含 `-`（`dead-acct-1`）。这是唯一能区分"按已知平台前缀匹配"与"贪婪 match"的用例 —— 实测不含 `-` 的 id 两种实现结果相同，咬不住（第一版就栽在这）。 - 变异：① `dry_run` 默认改 false ⇒ 报红；② 改回贪婪 match ⇒ 报红。 ## ★ 过程中踩到的三个坑（都已记进代码注释） 1. `Plugins.Call` 的参数是平铺的，不是 `req.body` —— `bodyOf(req)` 返回空表， `dry_run=false` 被静默丢成默认 true ⇒ "真删"永远没发生。必须同时兜住两种调用形态（HTTP 路由走 body，插件 Call 平铺）。 2. 内核 `add_source` 取 `args["source"]`（嵌套一层），平铺字段被拒（"add_source requires a source table"）。 3. `config.Model` 要求 models 是对象数组 `{id=...}`，传字符串数组被拒。 4. 判据只查 Go 侧 `err` 会静默通过：内核把失败放在返回体里， Go `err` 仍是 nil ⇒ "源根本没注册"看起来像"没有孤儿"。	2026-10-17 08:34:47 +08:00
JianFeeeee	aea1a2c48d	fix(provider): 上游错误文案别再丢 —— 补网关/腾讯错误体形状 + 修误导性日志 ## 发现路径：读生产日志（不是测试报红） ``` unhandled upstream error body (adapter "openai" lacks transform_error): status=404 body={"error_msg":"404 Route Not Found"} unhandled upstream error body (adapter "buddy" lacks transform_error): status=400 body={"code":11101,"msg":"Non-stream chat request is currently not supported",...} ``` ### ★ 缺陷 A：错误体形状漏了「网关」与「腾讯系」两类 `__prelude.openai_error()` 只认 `error.message` / `error`(裸串) / `{code,message}` / `detail` / HTML `<title>` / 裸文本六种，没有 `error_msg`（华为/APISIX 网关）与 `msg`（腾讯系用 msg 而非 message）⇒ 返回 nil ⇒ 客户端只看到 `api error 404: unknown error`，而 body 里明明有可用文案。修法照参考（llm-adapter.ts:524 `errorDetail()` 显式认 `error_code`/`error_msg`； buddy-adapter.ts:576 认 `msg` + `displayMsg.{zh,en}`）： - 新增 `{error_msg}` / `{msg}` / `{error_code,+error_msg}` 三种形状； - 新增 `displayMsg.{zh,en}` 本地化文案，排在最前（参考注释明说"本地化文案最可读"；其早期实现只读 `error.`/`message` ⇒ 全部落空 ⇒ 把 291 字符原始报文糊进错误提示，而服务端早已备好中文说明）。覆盖 7 个用共享前导的适配器：buddy/deepseek/github/groq/kimicode/openai/sensenova。 ### ★ 缺陷 B：内核那句日志会把人带偏措辞是 `adapter %q lacks transform_error`，但 openai.lua:139 与 buddy.lua:166 都明明定义了该钩子* —— 真实原因只是它返回了 nil（认不出那个形状）。我照着这句话去适配器里找"有没有这个函数"，查了几轮才发现函数在、是返回值空。修法：内核直接查事实（`p.vm.HasFn(adapter, "transform_error")`），两种原因分开措辞，不再猜。 ## 判据 `internal/lua/adapter_prelude_error_shapes_test.go`： - 12 个形状子用例（4 个新增 + 6 个回归 + 2 个 displayMsg），装载仓库里真实的 openai.lua（含共享前导），不是自造桩 —— 第一版用空 VM 跑，12 个全 FAIL（`adapter openai not loaded`），那等于什么也没验。 - 配对判据 `...StillReportsUnknownShapes`：真正认不出的形状仍须 `ok=false`，防止"为了让上面通过就把『抽不出』和『没这个钩子』混为一谈"。 - 变异：删掉新增的 error_msg/msg 分支 ⇒ APISIX 用例报红。 ## 备注 `anthropic/gemini/mistral/ollama/opencodezen/qwen38/trae` 有自己写的 `transform_error`，不走共享前导，未获得本次新增形状（各自协议的错误体本就不同）。此处只修共享前导的 7 个。	2026-10-17 00:37:52 +08:00
JianFeeeee	9e5a5f550b	fix(channels): zcode 适配器真正继承 anthropic 基座（此前 9 个函数只有 2 个） ## 缺陷（潜伏，从未被触发） `channels-zcode` 适配器的手法是把 `anthropic.lua` 源码读进来执行、只覆盖 `transform_request`（身份块注入），其余协议转换全部复用基座。但那句读取写在适配器内部。实测： - 适配器运行在另一个沙箱 VM —— 那里 `__llmsproxy_plugin_dir` 与 `LLMSPROXY_PLUGIN_DIR` 都不存在、也没有文件系统访问； - ⇒ `loadAnthropic()` 必然返回 nil，且静默降级：适配器照常装载，但只有它自己定义的 2 个函数，缺 `transform_response` / `transform_stream_chunk` / `serialize_` / `deserialize_request` 共 7* 个。后果：内核 `Transform()` 对缺失函数响亮报错（不是静默透传）⇒ 非流式在响应阶段 502，流式逐帧报错 ⇒ 该渠道完全不可用。为什么一直没暴露：zcode 从来没有凭据（0 账号）⇒ 源未注册 ⇒ 该路径从未被调用过。拿到账号的那一刻才会炸，且报错指向内核而非配置。 ## 修法基座源码改由插件主体读好并内联进适配器源码（插件 VM 有 io，实测可读）。与 v2.0.35 buddy 适配器同一手法。两处必须注意的坑： 1. 不能拼接后 gsub 替换：gsub 的替换串里 `%` 有特殊含义（`%1` 是捕获引用），而适配器源码含 `%s`/`%d` 等格式化串 ⇒ 会破坏语法。改用 `find(ph, 1, true)` + `sub` 的纯字符串替换。 2. 占位符 token 不能在注释里出现字面量（第一版就栽在这：gsub 先命中了解释它的那行注释，替换掉注释、代码里仍留着未定义全局）。 3. 顺带补上插件主体缺失的 `plugin.adaptersDir()` —— 原先这个函数只存在于 zcode 适配器源码内部，插件主体从来没有过。 ## 判据 - `internal/core`（真实路径，会咬变异）： - `TestZcodeAdapterInjectsOfficialIdentityBlocks` - `TestZcodeAdapterKeepsAnthropicProtocolConversion`（工具调用 / 图像块存活） - `TestZcodeAdapterFailsLoudlyWithoutAnthropicBase` —— 语义已随设计更新：基座不可得现在应在安装期失败（新增 `adapters_dir` 测试缝隙把 "基座缺失"从运行期逐帧炸变成安装期一条明确错误） - `internal/lua/adapter_zcode_base_test.go`：验证源码模板 + 合并逻辑，并如实标注边界 —— 它在测试里自己做替换，所以不能证明安装处内联了非空基座（实测：把 `asrc` 换成空串它不报红；那份由上面的 core 判据覆盖）。变异验证：把安装处的 `asrc` 换成空基座 ⇒ core 三条判据全部报红；用重构前的适配器源码 ⇒ `TestZcodeAdapterInheritsAnthropicBase` 报红（缺 7 个）。	2026-10-17 00:01:33 +08:00
JianFeeeee	8a4153d18a	refactor(channels): 纯常量收进 plugin.K，腾出顶层 local 余量（此前余量为 0） ## 问题（实测） `channels.lua` 的主 chunk 顶到 Lua 上限 200 个 local —— 往文件顶部加哪怕 1 个顶层 local 就报： `main function has more than 200 local variables` 实测（LuaJIT 与 luac 5.4 一致，响亮失败，不是静默降级）。后果不是"某个功能出错"，而是整个渠道插件编译失败 ⇒ 全渠道不可用。换句话说：这个文件此前一个顶层 local 都加不了，任何后续改动都会立刻炸。 ## 修法把 20 个纯常量（字符串/数字/自闭合字面量）从裸 `local` 收进 `plugin.K` 表 —— 挂表字段不占 local 槽位。只搬常量，函数一律保留 local：函数之间存在真实的调用顺序依赖（前向引用），搬迁风险与收益不成比例。搬迁是纯机械的，且脚本带长字符串保护：替换时逐行跳过 `[===[ ... ]===]` 区间，绝不改动适配器源码文本（本文件里那 7 段长字符串是适配器代码，误改会直接弄坏适配器）。 ### 实测结果 \| 指标 \| 前 \| 后 \| \|---\|---\|---\| \| 加 1 个顶层 local \| ✗ 编译失败 \| ✓ 通过 \| \| 加 10 / 20 个 \| ✗ \| ✓ 通过 \| \| 字节数 \| 589195 \| 590042 \| ## 判据（2 条 + 变异 2/2） - `TestChannelsLuaHasLocalHeadroom`：注入 1 与 10 个顶层 local 后仍能编译。为什么用 luajit 而不是 `luac`：内核链接 `libluajit-5.1.so.2`，而 luac（Lua 5.4）对同一文件给出不同结论，用错工具会得到假绿。为什么不"数一遍 local"：主 chunk 的 local 数受作用域嵌套影响，静态计数不可靠（同一文件被不同脚本数出 228/232/248 三个数）；而"能不能再加"是决定性的，也正是我们需要的性质。 - `TestChannelsConstantsLiveInPluginK`（配对）：抽样断言这些常量确实在 `plugin.K` 内、且没有变回裸 local —— 否则余量会再次归零。 - 变异：用重构前的文件 → 报红；把常量改回裸 local → 报红。 ## ★ 顺带更正两处我先前的错误说法（本轮实测推翻） 1. 不是静默失败。我先前说"超出的 local 静默退化为全局" —— 错。 LuaJIT 与 luac 都在第 201 个报编译错误。危险度远低于我所说。 2. `adaptersDir` 为 nil 的真实原因不是"local 被顶掉" —— 它定义在 `ZCODE_ADAPTER_SRC` 长字符串内部（适配器源码文本），在适配器沙箱里执行，而那里没有 `__llmsproxy_plugin_dir`、没有文件系统。所以 zcode 的 `loadAnthropic` 必然返回 nil、BASE=nil （它自写了全部转换所以功能没问题，但"复用 anthropic、协议不漂移"的设计意图从未生效）。 ⇒ 教训：读 10000+ 行的 Lua 文件时，先扫出所有长字符串区间；落在里面的"函数定义"只是文本，不属于插件作用域。	2026-10-16 21:49:36 +08:00
JianFeeeee	59902082c6	fix(buddy): 新增内置 buddy 适配器（glm-5.1 的 reasoning_effort + 流式 Accept） ## 真实缺陷 ①：glm-5.1 恒 400（用户报"这个模型不可用"）上游回 `400 {"code":11150,"msg":"the reasoning effort value is not supported by the current model"}`。探针逐字对照实验（body 完全由探针给定）： glm-5.1 裸（无该字段） → 400 11150 ✗ glm-5.1 + reasoning_effort:medium → 200 ✓ glm-5.1 空串 → 400 11150 ✗ 任何非空档位都被接受（low/medium/high/xhigh/max/minimal 逐个 200）；而其余 15 个 buddy 模型裸跑全 200（多带该字段也无害）⇒ 这是 glm-5.1 独有要求。参考 product.ts:237 声明它只有 `['medium']` 一档。 ## 真实缺陷 ②：流式请求缺 Accept: text/event-stream → 空回复不发该头时上游接受请求（200）但只回一帧空内容（completion_tokens=0、 finish_reason 直接 stop），既不报错也不产出正文 —— 表现是"模型不回答"，极易误判成模型坏了或额度不足。同 body 加该头 → 39~43 帧正常 SSE。参考 buddy-adapter.ts 的 send() 固定发它。 ## 实现：内置 `buddy.lua`（不是插件自装）为什么不用插件自装适配器（channels-zcode/qoder/cline 那条路）： `channels.lua` 的主 chunk 已 248 个 local，Lua/LuaJIT 上限是 200 —— 超出的 local 会静默退化为全局（`luac -p` 通过，运行时才 `attempt to call global 'x' (a nil value)`）。实测证据：`adaptersDir` 是第 208 个 ⇒ 调用点拿到 nil ⇒ `loadAnthropic` 静默返回 nil ⇒ zcode 适配器从来没有基座（"复用 anthropic"的意图从未生效，只是它自写了全部转换所以能用）。我第一版就是这么写的，结果适配器装不上（`adapter channels-buddy not loaded`），且 `hy3`/`glm-5.3`/`kimi-k3-1` 全被打成空回复 —— 只有 `glm-5.2` 因多源兜底 "看起来正常"，症状再次指向错误方向。 ⇒ 改走内置适配器（与 trae/sensenova/opencodezen 同性质，`deploy.sh` 自动同步）， `channels.lua` 只改一行 `adapter = "buddy"`，不再触碰那个已贴上限的文件。 ## ★ 排查中发现的沙箱事实（值得记）适配器运行在另一个沙箱 VM：那里 `__llmsproxy_plugin_dir` 与 `LLMSPROXY_PLUGIN_DIR` 都不存在（实测均为 nil），也没有文件系统访问。故任何"在适配器里读兄弟适配器源码"的写法都拿不到基座且静默降级。判据 `TestBuddyAdapterDefinesAllTransforms` 咬住这条。 ## 顺带修：hy4-preview-x 从目录剔除实测它对上游恒回 11102（`model service info not found`，加/不加 reasoning_effort 都一样 ⇒ 与 effort 无关，是后端未开放）。它被服务端 agents 引用，于是 `agentRef` 例外把它放回目录 ⇒ 用户选中必 400 而错误指向模型。参考用白名单重建达到同样效果（其兜底表里没有它）。本仓加等价的精确黑名单（只放实测确认的，不做猜测），并在两处兜底目录里一并剔除。 ## 验证 buddy 15/15 模型全部可用（含 glm-5.1），逐一实测无失败； `hy4-preview-x` 已从源目录消失（16 → 15）。 ## 判据（3 条 + 变异 2/2） - `TestBuddyAdapterEffortAndHeaders`：glm-5.1 补 medium / hy3 不补 / 调用方给的档位被尊重 / Accept 必须是 SSE + 身份头齐备 - `TestBuddyAdapterKeepsOpenAIWire`：协议转换与 openai 一致（只是补两个字段） - `TestBuddyAdapterDefinesAllTransforms`：四个转换函数都存在 —— 咬"静默降级"而非"某模型能回话"（后者会被多源兜底掩盖，本会话已栽两次） - 变异：删 stream_chunk / 不补 effort → 均报红 ## 一起提交的其它独立缺陷（均在本次调查中发现） - buddy 目录过滤（四类判据）与 hy4-preview-x 剔除	2026-10-16 20:47:50 +08:00
JianFeeeee	dda537cda9	fix(channels): 日志截断按字符（中文被切出 U+FFFD）+ 面板排版 ## 真实缺陷（v2.0.33 上线后在截图里看到）日志尾显示成：`能力增强不�` 根因：`tostring(cerr):sub(1, 120)` —— Lua 的 sub 按字节切，而中文占 3 字节 ⇒ 切在字符中间产生替换字符 U+FFFD。一句本来完整的诊断（"…能力增强不可用，已退回兜底表"）看起来像数据损坏，实际只是截断方式错。生产实测复现：该条 120 字节截断后，末尾正好落在"不"字的第 1 字节上， python 侧解码得到 `…能力增强不\ufffd`。修法：`plugin.utf8Clip(s, maxBytes)` 先按字节切、再回退到最后一个完整 UTF-8 序列边界（最多退 2 字节）。三处中文文案截断全部改用它。 ## 判据（1 条静态 + 1 条行为 + 变异 1/1） - `TestLogTruncationIsUTF8Safe`（静态）：助手存在 / 三处中文截断不再用裸 sub / 未超长时原样返回 / 回退逻辑处理孤立首字节 - `TestUtf8ClipBehaviour`（行为，经 `plugin.__utf8_clip_probe` 走真实函数）：对 6 个长度断言 `utf8.ValidString(out)` 且不超字节上限。静态断言看不出 "结果是否真的合法 UTF-8"，所以必须有这一条 —— 实测 n=120 从 `…能力增强不�`（非法）变为 `…能力增强不`（合法） - 变异：把 utf8Clip 换回裸 sub → 报红 ## 排版抛光（截图里可见的三处） - 头部控件原用 `<h2>` + flex，checkbox 被挤到换行且文字竖排 ⇒ 改 `<b>` + 独立 flex 行 + `white-space:nowrap` - 长诊断在窄卡片里被截断（而截断的尾巴正是最该看的部分）⇒ `word-break` - 列表加 `line-height`，可读性 ## 兼容性历史 state 里的 41 条老条目没有 `level` 字段 —— 前端 `e.level \|\| "info"` 已容忍，不需要数据迁移（判据亦未假设字段必然存在）。	2026-10-16 17:44:04 +08:00
JianFeeeee	2d7388ad35	fix(channels): 运行日志加级别/归属/折叠，并从渠道详情移出（C+A） ## 问题（生产实测，非猜测）用户问「为什么 WebUI 默认显示插件全部日志」。用 CDP 打开真实 UI + 读 `/channels/status` 实测，发现是三个问题叠加，而表层症状是"看到的全是噪音"： ### ① 归属错误：全局日志渲染在「单个渠道详情」里 `plugin.state.log` 是单一全局数组（`logEvent` 写入的条目只有 `{at, msg}`，连 platform 字段都没有），但这个 `<ul id="ch-log">` 的 DOM 位于 `#ch-detail`（点开某渠道才显示）⇒ 用户点开 buddy，看到的却是 trae/minimax/qoder 的日志混在一起，无从区分。 ### ② 50 条里 48 条（96%）是周期任务噪音实测分类：`已同步源…` 11×、`模型刷新失败…` 9×、`模型目录已刷新` 9×、 `能力元数据未刷新` 9×、`自动领取…` 9× —— 唯一模式只有 8 种。原因：`refresh_models`(2h) + `auto_claim`(2h) + `refresh_creds`(0.5h) 三个 `first_due_now` 任务每次跑写 3~5 条 ⇒ 约 2 小时就把 50 条环形缓冲冲满，于是真正的用户动作（如「账号删除」）被挤到看不见。 ### ③ 无级别、无去重、无折叠 → 噪音与错误同权重并排 ## 修法（用户选 C+A） C —— 修正归属：把「运行日志」从 `#ch-detail` 移出，成为常驻的独立卡片（`#ch-log-card`）。判据断言它与渠道详情是兄弟节点（div depth=0），不是父子 —— 否则"点 buddy 看到 trae"会以另一种形式回来。 A —— 加级别与过滤： - `logEvent(msg, level, platform)`：level ∈ info\|task\|warn\|error。定时任务的常规结果记 `task`（前端默认折叠），只有异常升为 warn/error。 - 紧邻同文折叠：与 `log[1]` 完全同文时不新增条目，只 `n=n+1` 并刷新时间。 ⚠️ 只对紧邻条目折叠 —— 否则一条每小时出现的消息会不断"跳"到最前，时间线失去意义。前端显示成 `×N`，既保留"重复了多少次"又不刷屏。 - 三个视图开关：级别门槛（全部/警告及以上/仅错误）、显示例行任务、按当前选中渠道过滤（不带 platform 的跨平台汇总只在「全部渠道」出现）。 - `refresh_models` 的失败改为逐平台各记一条（原先 N 个挤成一条汇总，既不属于 trae 也不属于 minimax ⇒ 点进任何单渠道都看不到自己的问题）。 ## 判据（3 条 + 变异 2/2） - `TestChannelsLogEventCarriesLevelAndPlatform`：签名三参 / 条目带两字段 / 紧邻折叠 / 折叠对象必须是 log[1] - `TestChannelsPeriodicTaskLogsAreDowngraded`：逐条咬住具体调用点被降级（而不是"存在 task 这个词"——那样一处就为真，测不出漏降级的噪音源） - `TestChannelsLogPanelHasFilters`：日志卡片与渠道详情是兄弟（div depth=0） - 变异：去掉折叠 / 把卡片放回详情内 → 均报红 ## 顺带修好的环境事故（重要）排查中全量测试突然大批失败（`loopback 未就绪（未取得端口）`）。我一度以为是自己的改动，`git stash` 后在干净版本上复现 → 预先存在，继续追到根因： `/tmp/bisect.py`（另一个 agent 的临时脚本）遮蔽了 Python 标准库的 `bisect` —— 而 `tempfile` → `random` → `bisect`，于是任何 `import tempfile` 都炸，回环接收器（python3）起不来。`sys.path` 含 `/tmp` 就是这个后果。已移走（`/tmp/_shadowed-stdlib-conflicts/`，不删除以免打断那个 agent）， Python 与全部测试立刻恢复。 ⇒ 教训：临时脚本绝不能在 `/tmp` 下用 stdlib 模块名命名；它会让全机 Python 静默失效，而症状（"回环未就绪"）与原因毫无关联。	2026-10-16 17:20:35 +08:00
JianFeeeee	00e59a7e1d	fix(opencodezen): 必须回传 reasoning_content（thinking 模式硬要求） ## 真实缺陷（我自己的会话被它打断过）生产实测（2026-10-16）： provider localzen: api error 400: Upstream request failed: [invalid_request_error] The `reasoning_content` in the thinking mode must be passed back to the API. 审计文件里成串 502，紧跟在一个 prompt_tokens=139330 的成功请求之后。根因：`transform_request` 里写着 `msg.reasoning_content = nil`，注释理由是 "Zen 免费池不接受回传（Go 侧相反）"。该假设方向是反的 —— 上游要的就是它。 ## ★ 为什么这个缺陷极难归因（值得记）失败是交替出现的：只有当上一轮真的产出了 reasoning（thinking 模型 + reasoning_effort 开启 + 长上下文）时，回放那段历史才会被拒；普通回合照常 200。于是"同一个模型同一会话，成功与失败交替"——看起来像上游抖动或限流，而客户端看到的 502 与"上一轮想过"这件事毫无关联。我一开始也走了弯路：用简短的 curl 复现不出来（8/8 成功），因为那些请求的历史里没有"模型自己产出的 reasoning"。必须让上一轮真的产生思考才复现。参考实现的方向一致：`openai-compat.ts` 的 `serializeMessages`（opencode 适配器直接复用）在 assistant 回合携带 reasoning 时就带上该字段： `...reasoning.length > 0 ? { reasoning_content: reasoning } : {}` 即「有就回传」，无额外条件。 ## 修法保留 `reasoning_content`（只把空串丢掉 —— 多余字段部分上游会挑）。不改成"仅当 thinking 开启才回传"：我们无法从请求可靠判定上游是否处于 thinking 模式（真正知道的是上游）。而"有就回传"是零风险方向 —— 上游不需要时忽略即可（实测传与不传同为 200），需要时缺了就是硬 400。 ## ★ 顺带发现的第二处问题提交 `6113924` 的说明声称 "Test: TestOpenCodeGoVsZenReasoning pins the Go-keeps / Zen-strips split" —— 该测试在全仓不存在（`git log -S` 全历史搜索为空）。也就是说这条行为从未被任何判据固定，所以它反了也没人知道。本轮补上真正的判据。 ## 判据（2 条 + 变异 1/1） - `TestOpenCodeZenKeepsAssistantReasoningContent`：assistant 回合带 reasoning 时出站体必须有它。咬住"被剥掉"这个具体行为，而不是"请求成功"—— 后者在非 thinking 回合下永远为真，测不出本缺陷。 - `TestOpenCodeZenDropsEmptyReasoningContent`：空串必须丢掉（配对判据，防"改成无条件保留"这类过度修正）。变异：恢复 `msg.reasoning_content = nil` → 报红。 ## 说明 `opencodezen.lua` 在仓库内，而 `deploy.sh` 的 `sync_adapters` 只覆盖与仓库同名的适配器文件 ⇒ 本修复会自动生效（生产另有 opencodego/opencode/ agentrouter 三个仅存在于线上的文件，不受影响）。	2026-10-16 14:52:13 +08:00
JianFeeeee	c0e08f907a	fix(channels): buddy 目录过滤不可调用模型（照参考 isChatModel 四类判据） ## 真实缺陷 `/v3/config` 的 `data.models` 混着不是对话模型的条目，我们原样全收 ⇒ 生产源里 24 个模型，其中 `nes-gf` / `codewise-completions` / `codewise-rewrite` / `codewise-jump` / `codewise-default-model-v2` / `hunyuan-image-alpha` / `auto` 全部调不通（`glm-5.1` 也 404）。用户选中报错，而错误文案指向模型 ⇒ 极易被误判成"这个模型坏了"。参考实现（buddy.ts `isChatModel` / `isAutoSelectAlias`）逐条给出四类判据，且都有实测依据；本轮逐条移植： ① 自动选择别名 `auto` / `default` ⚠️ 只按这两个字面量过滤，不做前缀匹配 —— 前缀会误伤 `default-model` / `fast-model`（国际版抽象别名，但被 craft agent 引用，是官方推荐入口）。参考注释专门警告过这点。 ② 补全/NES 专用：前缀 `nes-` / `completion-` / `codewise-`，或 `supportsExtra` （参考实测 codewise-default-model-v2 → `code 11102 service info not found`） ③ `maxOutputTokens > 0 且 ≤ 256`（补全用途；对话模型普遍 ≥24000） ④ 带 `text-to-image` 标签（如 hunyuan-image-alpha） ⇒ 故 `models` 先建成 id→meta 映射（③④ 需要元数据），再逐条判定。同时收 `data.agents[].models` 里被 agent 引用的清单并合并 —— 参考据此给 `agentReferenced` 打标（`hy4-preview-f` 只由本端点下发且被 agent 引用，白名单式重建会把它丢掉）。 ## 判据（1 条 + 变异 1/1） `TestBuddyCatalogFilterDropsNonChatModels`：断言四类规则都在源码里（"有人精简掉一条"就会把不可调用模型放回选择器），并反向断言 `default` 没被写成前缀匹配（那会误伤 `default-model`）。变异：删掉 `nes-` 规则 → 报红。 ## 说明这是上一提交（v2.0.30）同一轮的第二个发现：v2.0.30 修掉 URL 拼接后， buddy 通道才真正可达，于是"可达之后目录里哪些真能调"这件事第一次暴露出来。两个缺陷是串联的 —— 不先修 URL，这个目录问题无法被观察到。	2026-10-16 14:06:51 +08:00
JianFeeeee	3ac4b35eb1	fix(channels): 8 个平台 base_url 侵占 endpoint 路径 ⇒ 上游 404 Route Not Found ## 真实缺陷（用户可见）内核的上游 URL 是 `base_url + endpoint`（provider.go ChatURL），而适配器默认 `endpoint = "/chat/completions"`。多个渠道平台把完整路径写进了 `base_url` ⇒ 实际请求变成 https://copilot.tencent.com/v2/chat/completions/chat/completions ⇒ 上游回 `{"error_msg":"404 Route Not Found"}`（APISIX 的措辞，不是模型错误）。受影响 8 个平台：buddy / cline / lobsterai / opencode / qoder / loomy / raccoon （zcode 当时已用 `endpoint` 覆盖，形态正确）。另有 loomy 的第二处错误：host 用了 `loomy.xunfei.cn`（Web 前端/OAuth 回调域），实测该 host 的 /chat/completions 返回 HTML 网页；正确推理域是参考的 `loomyad.xunfei.cn/api/v1`（返回正常 JSON）。 ## ★ 为什么这个缺陷活了很久（最重要的教训）模型名被多个源服务。`deepseek-v4.1-flash` 同时由 4 个源提供（alittokenplan/vela/oin/channels-buddy）⇒ buddy 源失败后网关继续尝试下一个源并成功 ⇒ 用户看到"能回话" ⇒ "buddy 通道是好的"这个结论完全没有证据。本轮我一度正是这么误判的。而 `hy3` 只由 buddy 一个源提供 ⇒ 一调就暴露真因。 ⇒ 判据必须断言源的结构不变量（URL 形态），不能靠"某个模型能调通" —— 后者会被多源冗余掩盖。已按此写判据。 ## 排查手法（可复用）怀疑"某模型不可用"时，先列该模型由几个源服务： 1 个 ⇒ 该模型是那条源的健康探针（用它测） >1 个 ⇒ 它调通不能证明任何单一源可用（换独有模型再测）另：非流式请求会被 buddy 直接 400 拒绝（`{"code":11101,"msg":"Non-stream chat request is currently not supported"}`），我第一次用 stream=false 时四个模型全 400，看不出模型差异，差点把结论下成 "头组合无区别"就收工。 ## 修法 `base_url` 只留 host（或协议公共前缀），路径移入该平台的 `endpoint`。逐平台按参考的 `apiBase` + `chatPath` 取值核对，并实测修正后的 URL： buddy/cline/lobsterai/qoder/raccoon → 401（缺凭据，正确） loomy → 200 `{"code":"100002","desc":"缺少 token"}`（正确） opencode → 500（路由存在；`https://opencode.ai/v1/...` 是 404+HTML，已证伪）测试注入平台也一并对齐（免被当范例复制）。 ## 判据（2 条 + 变异 2/2） - `TestChannelSourceBaseURLHasNoChatPath`：静态扫描全部 `base_url`，不得含 `/chat/completions` `/v1/messages` `/generateContent` `/api/chat`。 - `TestChannelBaseURLJudgeBitesOnBadInput`：用故意坏数据验证判据的判别力（防判据自己写歪成恒真）。变异：把 buddy 恢复成旧形态 → 报红。 ## 顺带修正 `TestUpstreamGapsAreDocumented` 原先钉死 qoder 的整串 URL 字面量 ⇒ 这次纯形态重构（语义未变）把它弄红了 —— 判据在咬自己。改为断言 `base_url` 与 `endpoint` 两半，语义不变但对形态重构免疫。	2026-10-16 13:52:02 +08:00
JianFeeeee	969f3138fd	fix(channels): 撤源失败的诊断必须带真正原因（不再只说"无返回"） ## 我上一版（v2.0.28）自己引入的缺陷内核桥的签名是 `call(name, args) -> (result, nil) \| (nil, err)` —— 失败时第一个返回值是 nil，原因在第二个返回值里。我写成 `local r = call(...)` 再读 `r.ok` ⇒ 恒为 nil ⇒ 日志只说「撤源(重建)失败 channels-buddy-buddy-main: 无返回」。一句不可操作的诊断比没有更糟：它把"权限没授予 / 超时 / 拒删最后一个源" 三种完全不同的原因（对应三种完全不同的处置）压成同一句空话。生产实测已复现这条日志（部署时全量重同步，权限尚未授予）。 ## 修法两个撤源点都改成接两个返回值，日志带上内核给出的原文原因： `kernel action "remove_source" is not granted to plugin "channels"; enable it in the plugin's kernel permissions` 并把"要授予哪个动作、声明在 plugin.kernel"一并写进提示。 ## 判据收紧（旧判据咬不住这个变异）原来只断言日志含"撤源失败"和"remove_source" —— 只接第一个返回值的版本照样通过。新增断言：日志必须含内核给的真实原因（`not granted`）。这是本会话第 9 类判据教训：判据只看"失败了"，不看"为什么失败"，于是它无法区分"诊断可用"与"诊断是空话"。	2026-10-16 10:26:55 +08:00
JianFeeeee	00db19eb77	fix(channels): remove_source 漏声明（删了账号源还在对外服务） ## 真实缺陷（用户可见） `plugin.kernel` 只声明了 5 个内核动作，而插件在 5 处调用 `remove_source` —— 声明与使用漂移。生产按 declared 授予 ⇒ 撤源全部被拒。更坏的是它静默：`Core.AddSource` 是同名 upsert，所以 `syncAccountSource` 里"先 remove 再 add"的 remove 失败看不出来（add 会覆盖同名源）—— 只有纯删除路径才暴露： • `dropAccountSource`（账号停用/删除）→ 账号删了，它的源还在对外服务 • `account_delete` 收尾清旧单账号源 • 两处 `channels-<plat>` 旧源清理我实测确认：只授 add_source 时删账号，其源仍在内核源列表里。 ## 修法 ① 声明补上 `remove_source`（并加注释说明"加动作时同时改这里"）。 ② `dropAccountSource` / `syncAccountSource` 的撤源不再忽略返回值，失败记进事件日志（面板可见，附可操作提示）—— "一个被丢弃的返回值"不该是权限缺失的唯一痕迹。 ③ 判据 `TestChannelsDeclaresEveryKernelActionItCalls`：静态扫描源码里所有 `__llmsproxy_kernel.call("X")`，要求每个 X 都在 `plugin.kernel` 里声明。将来任何人加了内核调用却忘了声明，会在这里报红，而不是等线上静默失效。 ## 判据（3 条 + 变异 3/3） - 授予 remove_source 时：删账号确实撤掉源 - 未授予时：必须可见地失败（事件日志含"撤源失败"） - 声明必须覆盖全部实际调用变异：忽略返回值 → 报红；漏声明 remove_source → 报红。 ## 部署后需补的一次操作生产权限集当前只有 add_source ⇒ 需授予 remove_source（否则既有账号的 "停用/删除"仍撤不掉源）。已在部署后手工授予，并复核 declared == granted。	2026-10-16 10:04:36 +08:00
JianFeeeee	38490690c5	fix(channels): 账号顺序的确定性 + reorder 真正改内核源顺序 ## ① 真实缺陷：同秒创建的账号，顺序不确定 `poolList` 的排序键是 `priority` 降序 + `createdAt` 升序，而 `createdAt` 是秒级（`os.time()`）⇒ 同一秒建的两个账号比较相等 ⇒ 相等时 `table.sort` 的结果取决于 `pairs()` 遍历顺序 —— 不确定。实测：按 a,b,c 顺序建三个账号，`poolList` 回的是 `[a,c,b]`。后果不只是"顺序看着乱"：源注册顺序 = poolList 顺序 = 内核尝试顺序 ⇒ 同秒创建的账号里"先试哪个"是随机的（buddy 15 天窗口下影响先用谁的积分），且可能每次进程重启都变。修法：加 id 作稳定兜底键（唯一且不变）。 ## ② reorder 只改字段、不影响路由 `account_reorder` 只设 `acct.priority`，不重注册源。而一个源一旦注册，顺序就固定了 ⇒ 重排对实际路由毫无影响（"优先账号"并不会先被试）。修法：重排后按新顺序整体重放一遍 `syncAccountSource` （remove+add 会把源移到最后，故必须整体重放，只补被移动的那几个相对顺序仍不对）。 ## 判据（2 条 + 变异 2/2） internal/core/channels_reorder_effect_test.go - reorder 必须真的改变内核 list_sources 的顺序（判据看内核里的真实顺序，不是 pool 里的 priority 字段） - 同优先级 + 同秒创建时，顺序必须由稳定键(id)决定（字典序） ★ 两个判据第一版都不咬变异，原因各异，值得记下： 1. reorder 判据：初始顺序恰好已是目标顺序 ⇒ 无法区分"重排生效"与"本来就对"。改法：显式断言初始顺序、并让目标顺序与之相反。 2. 确定性判据：我直接断言 `account_add` 之后的顺序，而 `account_add` 是直接同步自己那一个账号（源顺序 = add 顺序），走不到排序逻辑 ⇒ 测的其实是 add 顺序。另外多轮 in-process 反复构造也测不出 —— `pairs()` 顺序在同一次进程里是稳定的，只有跨进程/跨分配才变。改法：走批量重注册路径（`__resync_sources_probe`）+ 显式把 priority 拉平构造"排序键完全相同"的场景，再断言字典序。 ## 顺带修的判据自身问题 - `sourceOrder` 原来顺带调了 `__sync_source_probe`（内部 remove+add）⇒ "测之前先动了被测对象"，顺序忽而两个忽而一个。改为只读。 - 探针取内核返回时按 `{sources:[...]}` 取，而 `actionListSources` 返回的是裸数组 ⇒ 恒得空列表。 - 夹具漏授 `add_source` 内核权限 ⇒ 源一个都不出现（内核会明确拒绝，只是我没看返回值）。子测试才能拿到独立的 env 与目录（同函数内 `t.Setenv` 只生效一次）。	2026-10-16 09:36:23 +08:00
JianFeeeee	969c72bfb1	feat(channels): credits_pool_reason —— 区分「真的用尽」与「查不到」 ## 为什么需要（参考同款修复，用户报障 2026-09-29）把两者混成一句"额度都已用尽"会让一次网络抖动伪装成钱花完了 —— 用户于是去解锁永久积分、或白等到明天，而号里其实有钱。两者的正确动作完全相反： exhausted → 等额度重置 unknown → 稍后重试 / 查网络与凭据（不要动永久积分锁定） locked → 可解锁永久积分（同样不是"用尽"）我们此前没有这个出口：`credits_balances` 只报逐账号错误，调用方拿不到 "为什么整池不可用"的结论，只能自己猜。 ## 实现新增 `channels/credits/pool_reason`，返回 `reason` ∈ `no_accounts \| unknown \| usable \| locked \| exhausted` + 可读 detail。判定优先级（顺序即语义）： no_accounts（无启用账号） → unknown（平台未声明余额端点 —— 无法判定 ≠ 用尽） → usable（有可用账号） → unknown（有查询失败 —— 不能当成用尽） → locked（锁定且只剩永久积分） → exhausted（都查到了且确为 0） ## 判据（6 条 + 变异 2/2） internal/core/channels_pool_reason_test.go - 余额确为 0 → exhausted - 查询失败 → unknown（且说明必须点明"查询失败"） - 无启用账号 → no_accounts - 有钱 → usable - 无余额端点 → unknown（不编造用尽） - 锁定且只剩永久积分 → locked，且解锁后同一份余额变 usable （证明 locked ≠ exhausted）变异：查询失败也报 exhausted → 报红；locked 混同 exhausted → 报红。 ## 踩到的坑（都是我的判据/夹具问题，非实现） ① 夹具用扁平 `{"total":100}`，而 buddy 的余额是深层嵌套 `data.Response.Data.Accounts[]`（每包含 Status/CycleCapacityRemain/ DeductionEndTime）—— 夹具形状不对导致全部走 unknown。 ② `addAccount` 写死 platform="buddy"，于是"无余额端点"那条用例在 minimax 上其实没有账号，命中优先级更高的 no_accounts（正确行为）却被判成错。加 `addAccountOn(platform, id)` 修正。 ③ Lua 里嵌套引号：`"（...不是"额度用尽"）"` 语法错 ⇒ 改用中文引号「」。	2026-10-16 09:01:01 +08:00
JianFeeeee	423dd5cf22	feat(trae): batch 模型目录（含参考记录的两个真实缺陷修复 + 元数据）我们此前 trae 的模型列表是纯硬编码（32 项名字），既没有真实元数据，也没打 batch 端点。参考的 parseTraeBatchModelList 记录了两个已修的缺陷，移植时必须一起带上，否则等于把 bug 再引进一遍： ## ① 通道白名单是「准入」而不只是「排序」（issue IKJOZ7） 22 个 function 里有一半在本插件推理端点下不可调用（实测 chat→4023 model unknown、builder→4001、inline_chat→3003）。只把白名单用于"同模型择优" 的旧写法 = "目录声明什么就发什么" ⇒ 用户选中那些模型必然失败，而错误文案指向模型，极易被误判成"这个模型坏了"。现在不在表内的通道整组丢弃。 ## ② 空档位不得覆盖有档位（issue IKI7WT/IKILR7）旧实现无条件"后面的覆盖前面的"，其假设（后面的配置更全）与真实数据相反 —— 上游把空档位的 solo_work_lite/solo_design_remote 排在最后，实测 13 个模型因此丢掉 reasoning_effort_config、全部显示"未提供推理等级"。合并规则（与参考逐条对齐）：空档位不得覆盖有档位；两侧都有档位时按通道优先级取更靠前者；其余保持"后覆盖前"。 ## ③ is_custom_model 是「仅可见但不可调用」的权威判据该标志为 true 的条目被上游以流内 event:error + 4001 拒绝。 ⚠ 判据是标志的值，不是模型名 —— 参考点名这个标志随服务端下发变化，曾据名字把 qwen3.8-flash 误记为应剔除（它其实正常可用）。 ## 附带：远端目录元数据不再丢原来目录只回 id ⇒ 参考能提供的上下文窗口/输出上限/思考档位/消耗倍率全丢。现按参考存下完整条目并在 model_list 以 `remote` 字段报出。 ⚠ contextWindow 取 `context_window_tokens.dev` 而非 `max`：max 需开启 display_config.max_mode 才可用（我们不实现该开关），采信 max 会让上层以为有 1M 窗口、实际被上游拒。 ## 基础设施 - refreshRemoteModels 支持 ep.body（POST 型目录端点）与 ep.sign（复用平台既有的头部构造，不另写一套 —— 否则"chat 能通、目录 401"极难查）。 - trae 走 sign="trae_solo" 复用 traeCheckinHeaders（Cloud-IDE-JWT + 约 20 个客户端头；参考实测简化头会被拒）。 - 新增 __trae_entry_probe（诊断"合并规则选中了哪条"），此前只能靠猜。 ## 判据（3 条 + 变异 3/3） internal/core/channels_trae_catalog_test.go - 白名单准入 + 档位来源（空档位不得覆盖有档位） - 四条硬性过滤（usage/config_switch/is_invisible_to_user/is_custom_model）且 *is_custom_model=false 的 custom_model_ 条目必须保留（判据是标志值） - 请求体必须传全部 22 个 function（与真实 IDE 一致；只传聊天通道会让非聊天通道条目位置错乱甚至被跳过）变异：白名单不做准入 → 报红；无条件后覆盖前 → 报红；不过滤 custom → 报红。 ★ 调试中发现并修掉我自己写的一个静默失效： `declaresEffort` 读 `e.reasoning_effort_config` 而 `parseEntry` 存的是 `e.reasoning` ⇒ 判定恒为 false ⇒ 规则①永不生效（正是它要防的缺陷）。判据当场抓到。教训：跨函数用同一份数据时，字段名必须对齐 —— 这类不一致不会报错，只会让规则静默失效。** 验证：internal/core 369s 全绿。	2026-10-16 08:28:47 +08:00
JianFeeeee	eeba1e49f8	fix(channels): account_clear_credentialless 尊重 dry_run（args=req 回退吃掉 body） ## 真实缺陷（我自己在上一个提交里引入，部署后实测踩到） handler 开头照其它 18 处写了 `if args.platform == nil then args = req end`。但本函数不传 platform 是合法用法（清全部平台）⇒ args.platform 自然为 nil ⇒ args 被换成 HandlerRequest ⇒ 刚解出来的 dry_run 就丢了 ⇒ 传 dry_run=false 却被当成未传，静默只预演。破坏性操作里这是最糟的形态：操作者以为执行了、实际没执行（反过来同样危险）。实测：不带 platform 时 deleted 恒为 nil，池子一个没动。 ## 修法兜底只认「req 本身就是参数表」这种形态（`req.body == nil and req.query == nil`），不再用「某字段为 nil」当判据 —— 那个字段为 nil 可能只是本次调用合法地没用它。 ## ★ 判据为什么第一版没咬住我原来的夹具用 map body 调 Call，而缺陷只在字符串 body（HTTP 真实路径）上暴露 —— `bodyOf` 对 table 直接返回，根本走不到回退那行。补 `TestAccountClearCredentiallessRespectsDryRunViaStringBody`（用 `InvokeHandler` + 字符串 body + 不传 platform）后变异才咬住。教训：夹具的调用形态必须与生产一致 —— 用 map 便捷调用会绕过 body 解析路径。判据 4 条（含本条）+ 变异 3/3。	2026-10-16 07:51:59 +08:00
JianFeeeee	ade9c122eb	feat(channels): 无凭据账号的批量清理能力（dry_run 默认开启） ## 为什么需要 `account_add` 允许不带凭据创建账号（设计如此："未带凭据的等 login 完成"），于是"先建占位、再走登录补齐"是正常用法。但登录没走完时（用户放弃、或历史批量导入）会留下只有元数据、永远不可用的账号：它们占着 provider 的账号计数（面板显示"10 个账号"却全不可用），让"这个平台到底能不能用"难以判断。实测生产：13 个账号里只有 1 个真正可用 —— codearts 10 个 + trae 2 个全是占位（同秒批量创建、nickname=id、凭据库里无对应条目）。 ## 安全性（破坏性操作，两条性质都被变异验证钉住） ① 只删没有凭据的：有凭据的一律不动（哪怕它测试失败 —— 那是"可疑"而非 "空壳"，处置完全不同）； ② dry_run 默认开启：不显式传 dry_run=false 就只回报会删哪些，不真删； ③ 复用 `plugin.account_delete`（同一份删除实现）—— 删除时要顺带做的事（drop source、清旧单账号源、删凭据）不另写一套，否则必然漂移。 ## ★ 踩到 Lua 顶层 local 上限（第 13 次同类） helper 写成顶层 `local function accountHasCredential` 后 `luac -p` 直接报 `too many local variables (limit is 200)`。改为挂在 plugin 表上（`plugin.__hasCredential`） —— 同样只有一份实现，且不占顶层名额。每次给本文件加顶层 local 前必须 luac -p。 ## 判据（3 条 + 变异 2/2） internal/core/channels_clear_credentialless_test.go - 只删空壳、保留有凭据的，且有凭据者的凭据必须仍在（防误删） - 指定 platform 时范围隔离（不动别的平台） - 未知平台必须报错（否则会误删全部平台）变异：无条件全删 → 报红；dry_run 默认改 false → 报红。	2026-10-16 07:46:05 +08:00
JianFeeeee	71cc142615	feat(zcode): 3012 判据/文案/诊断模块（照参考逐行移植，含对抗性审计反例）照参考 zcode-diagnostics.ts 移植，作为两处消费者共用的一份源码文本： ① 插件主体（领取路径 claimZcode）；② channels-zcode 适配器（推理路径）。共用是必须的：3012 有账号冷却惩罚（30 分钟起步，反复触发升级到 24 小时乃至停用），"请勿连续重试"这句话绝不能只在一条路径上（参考为此专门抽成单一份）。 ## 为什么这次移植的不是"锦上添花" 我们原来的领取路径是 `code == 3012 or msg:find("unusual activity")`，而参考用对抗性审计打出了两个方向的真实缺陷（2026-10-05，实测记录在源码注释里）：误判方向（把限流当风控）：两者用户动作完全相反（稍后重试 vs 别重试），且领取路径据此短路、跳过本可领取的 plan。实测反例： `too many requests, retry after 3012 ms` ← 毫秒数被当风控 `<h1>Error 3012</h1>upstream connect timeout` ← HTML 里的数字 `rate limited: request blocked, retry after 3012 ms` ← block 距 14 字符 `temporarily blocked; see error 3012` ← block 距 12 字符 `plan-3012-trust` / `trust_3012` / `x3012y` / `13012` ← 标识符形态漏判方向（真风控被放过）：上游 3012 的 msg 原文 `request has been blocked due to unusual activity.` 不含任何数字（数字在 code 字段里）⇒ "必须有独立词 3012"这条门禁会反过来把它漏掉。 ⇒ 判据以语义短语为主、数字只作兜底且必须与 block 紧邻（≤10 字符）；词边界集必须含 `-`/`_`（参考两版才收全：先只排数字 ⇒ plan-3012 仍命中；再补字母 ⇒ 仍命中，因连字符不属 [0-9A-Za-z]）。另：业务码认纯数字字符串（上游回 {"code":"3012"} 时，只认 number 会让风控码整条丢失 ⇒ 用户看到那句裸上游串）。 ## 一并移植的其它实测教训 - `formatGap`：分钟档必须逐档单独算。参考初版写 `floor(seconds % 60)`， 90 秒被渲染成「30分30秒」（分位取的是秒的余数）——该错误是在真实探针输出里发现的，纯函数单测当时没覆盖 ≥60 秒区间。 - 诊断的「距上条」必须用单独存的 previousSentAt，不能拿 lastSentAt 顶替（调用顺序是"先记本次、再诊断"，顶替会让它恒为 0ms、永远没有信息量）。 - 形态诊断必须读真正要发出去的那个对象，不读常量：常量只能证明"源码里写了多少字"，证明不了"线上发出去多少字"；空 system 时必须如实显示 0。 - 诊断行绝不写凭据：账号只以进程内自增序号出现。 ## ★ 接线上的一个真实 bug（我自己引入并自查出来） `installZcodeAdapter` 最初把 DIAG 源码直接 `.. ZCODE_ADAPTER_SRC` 拼接 —— 而 DIAG 末尾是 `return Z`，直接拼会让那个 return 结束整个 chunk ⇒ 适配器代码永不执行，且装载会静默成功（"加载成功但适配器不存在"）。修法：包进 `(function() ... end)()` 让 return 只结束该函数。 ## 判据 `internal/core/channels_zcode_3012_test.go`（走共用探针打那一份实现）： - 19 条分类矩阵（含上列全部审计反例） - formatGap 逐档（含 90000ms 必为「1分30秒」） - 诊断行凭据泄漏守卫（账号 id 的每个 ≥4 字符子串都不得出现） - 文案共用 + 必含「请勿连续重试」+ 空参不留空壳 - 形态诊断读实际对象（空 system 必须显示 0） ★ 变异 2/2 咬住。其中分类矩阵第一版没咬住 —— 因为"紧邻检查"独立挡住了那些用例，从未隔离词边界规则；补 5 个"block 紧邻但 3012 在标识符里"的用例后才有效。教训：必须有一组用例只被被测规则区分，否则别的守卫会把它的失效掩盖掉（本轮第 4 次"判据太弱"）。验证：internal/core 351s 全绿。	2026-10-16 01:38:51 +08:00
JianFeeeee	33bb7a98b2	fix(zcode): 日期块对齐参考的两条规则（幂等 + 只看第一条），修 off-by-one 通读参考 zcode-identity.ts 的 withContextPrefix 后发现我的实现漏了两条官方行为，且其中一条藏着真实 bug： ## ① ★ 幂等判断 off-by-one（真 bug） `"<system-reminder>"` 是 17 个字符，而我写的是 `c:sub(1, 16) == SR` —— 判断永远为假 ⇒ 幂等完全失效：同一请求重试/多次 transform 时日期块会叠加成多层，改变 content 的前缀结构（上游检查的正是这个结构）。修法：用 `#SR` 算长度，不写死数字。 ## ② 只看第一条消息，且它必须 role == "user" 我原来实现成「往后扫第一个 user 消息」。官方行为是：只处理 `messages[0]`，且若它不是 user 就完全不动 —— 不是去找后面那条 user。已对齐。 ## ③ 其它类型兜底参考对非字符串/非数组的 content 也会置为 `[prefix]`，照做。判据 2 条（新增）： - TestZcodeContextPrefixIsIdempotent 已含日期块时不重复插 - TestZcodeContextPrefixOnlyTouchesFirstMessage 首条非 user 时不动、首条 user 时插入变异 2/2 咬住：把 #SR 改回写死的 16 → 报红；去掉幂等判断 → 报红。 ★ 我自己在写这条判据时又犯了一个错并当场自查出来：断言「文本 content 应保持字符串」，而 anthropic 基座把文本转成块数组是正常的协议转换行为 —— 差点把正确的实现判成错。判据要验的是「日期块有没有被插进来」这个事实，不是 content 的容器类型。验证：internal/core 335s + internal/gateway 207s 全绿。	2026-10-16 01:13:24 +08:00
JianFeeeee	1e6b4864ec	feat(zcode): 身份块适配器 + 修复调度器泄漏 + codearts 目录 + 备份裁剪泛化 ## 1. ★ zcode 身份块适配器（channels-zcode）—— 准入的唯一开关参考实测（三账号 17 次请求）：zcode 的 /zcode-plan/anthropic 通道做请求体内容检查，system 缺官方身份块结构时直接 HTTP 405 + {"code":3012}：无 system → 3012 ✗ 仅 cliPrefix（42 字符） → 3012 ✗ cliPrefix + stable（约 2898 字符）→ 200 ✓ ⇒ 判据是「身份块结构是否存在」，与 HTTP 头、版本号、频率、多轮历史、tools 声明、运行时全部无关。我们此前用通用 anthropic 适配器 ⇒ 即使拿到 zcode 账号也必然被拒（现在 0 账号，但这是能不能用起来的前提）。实现：插件自装 channels-zcode —— 读内核 anthropic.lua 执行取基座，只覆盖 transform_request 注入身份块（协议转换始终与 anthropic 那一份一致，不漂移）： block[1] cliPrefix(42) / block[2] stable(2852) / block[3] Environment 段 / block[4] 调用方 system（必须追加在最后：上游看的是前缀结构）只给最后一块打 cache_control（Anthropic 上限 4 断点，逐块打会占满预算）日期块插入首条 user 的 content 数组最前（拼进字符串会改变结构）文本与参考逐字节一致（已核对：42 + 2856 = 2898）。 ★ 基座读不到时响亮失败，不静默退化 —— 否则会产出"身份块看着对、工具/图像全没转换"的请求，上游可能 200 但模型拿不到工具定义，症状是"模型变笨了"，与准入毫不相干、排查完全跑偏。判据 4 条 + 变异 2/2：不注入 → 报红；截断到 100 字符 → 报红。另加"协议转换不退化"判据（工具 input_schema / 图像块存活）。 ## 2. ★★ 同一缺陷家族第 3 个实例：Close() 不停调度器修完 on_unload 后全量回归 internal/lua 600s 超时，goroutine 快照显示 69 个卡在 stateSaver.loop 与 PluginRuntime.loop。根因：Runtime.Stop() 只在单插件 Unload 里调，Close() 不调 ⇒ 每个插件的调度循环在"进程关闭/测试结束"路径上永不停止。与 on_unload 完全同一形状。修法：Close() 新增 stopSchedulersAll()，顺序 = 停调度 → 落盘 → on_unload （调度器必须停在落盘之前，否则它写一个已收尾的 state）。 ★ 顺带：Stop() 不幂等（裸 close 会 panic: close of closed channel），两处都调之后可达 —— 用 sync.Once 加固。给函数加第二个调用点前先查幂等性。实测 internal/lua 从 600s 超时 → 62s 通过。 ## 3. codearts 模型目录：补两个必须 AK/SK 签名的端点 codearts 有 10 个账号但目录里只有硬编码 1 个模型。参考打两个端点： ① opengw.../gateway/config → result.models（benefit） ② snap-access.../v1/model/builtin → builtinModels（常规）而 refreshRemoteModels 只支持 Bearer ⇒ 这两端点从来没被打过。已加 ep.sign="codearts" 分支 + 两个解析形态 + opengw host 白名单。判据：两端点各自真实命中 + 每请求带 SDK-HMAC-SHA256 头 + 合并（非取其一）。 ## 4. TRAE PKCE 候选来源补齐（3 → 5）参考 authCodeCandidates 有 5 个来源，我们只有 3（漏了 authCodeInfo 为 JSON 的 authCode 字段、以及纯字符串形态）。★ 且不能写成 `a or b or c` 链 —— jsonField 取不到时返回空串，Lua 里空串是真值，链会在第一个空串处短路。判据 5 个参数化用例 + 变异 2/2 咬住（正是 or 链取不到的两个形态）。 ## 5. ★ 部署脚本：备份裁剪只修了一半（"两处只修一处"再现） prune_adapter_backups 有完整实现（含数量硬上限），但只针对 adapters.bak； sync_plugins 同样每次建 plugins.bak.* —— 修了 adapters 的堆积、plugins 继续涨。实测线上 plugins.bak 36 个、/etc/llmsproxy 192M。泛化为 prune_backups <prefix> + prune_all_backups（两个前缀都裁），加空前缀守卫。判据不止逐字检查，而是扫描脚本里所有 .bak.$(date) 创建点，要求每个前缀都在裁剪范围内 —— 将来新增第三种备份目录会立刻报红，而不是等它涨到几百兆。变异 2/2 咬住（只裁 adapters / 去掉守卫）。 ## 6. 上游客观缺口钉成可执行判据（TestUpstreamGapsAreDocumented） qoder 加密端点需 .wasm（参考仓库里也不存在）、TRAE PKCE 参考明确不支持、 zcode 滑块需真实浏览器交互。写成判据：任何人（包括未来的我）想"补"这些能力，必须先让判据失败 —— 即先推翻事实再动手。防的正是我前两轮的反复误判。清理：channels-buddy.lua（0 字节历史遗留，每次启动报 must return a table）。	2026-10-16 00:56:35 +08:00
JianFeeeee	89d759ece7	fix(kernel): Close() 从不调 on_unload —— 孤儿进程与回调文件泄漏 ## 症状本机积累 995 个 llmsproxy-loopback.py 进程（828 个超 24 小时），全是 /tmp/Test/ 与 .build-work/Test/ 下的测试残留；生产 /etc/llmsproxy/plugins/ 另有 *18 个孤儿 callback-.port（对应 .json 早已消失），且永远清不掉。 ## 真因（两层） 1. 回环回收本是惰性的：reapLoopback 只在会话过期时被 sweepSessions 触发。测试跑完直接退出 ⇒ 会话从未「过期」⇒ 进程常驻。生产会话真会过期，所以生产不漏进程 —— 但见第 2 条。 2. ★ 根因在内核：Plugins.Close() 只关 shard 与 saver，从不调用 on_unload —— 而 on_unload 只在单插件 Unload 时调。于是「进程关闭/ 测试结束」这条路径上，起了 OS 进程的插件永远收不了尾。插件的 plugin.on_unload（回收浏览器栈 + 回环）写得完全正确，只是从不被调用。这是「两处只修一处」缺陷的又一例：Unload 有、Close 没有。 ## 修法 - 抽 invokeOnUnload(p, name) 助手，Unload 与 Close 共用同一份实现** （两处各写一遍必然漂移，本次缺陷形状正是如此）；Close() 新增 callOnUnloadAll()。 - ★ 顺序：shards.Shutdown() → save.Close()（落盘）→ callOnUnloadAll()。落盘必须在前 —— saver 的最终写入要读插件的 Lua 表，on_unload 之后 state 已关，读到的就是空，最后一个区间的累积静默丢失（TestCloseFlushesTail 正是为守住这一点而存在）。我第一版把顺序写反，被该测试当场咬住。 - channels：启动清扫上一进程留下的孤儿 callback-.port/.json。loopbacks 追踪表只活在内存，进程被强杀时 on_unload 没机会跑，重启后内存表为空 ⇒ reapLoopback 无从知晓 ⇒ 那 18 个文件永久残留。 - channels：补 reap_loopbacks 端点（生产运维也可用：不必等会话过期）。 - channels：__set_loopback_probe 从覆盖改为合并条目 —— 覆盖会丢掉真实会话的 pid/port_file，让 reapLoopback 杀不掉接收器，探针自己成为泄漏源（实测：其他测试已归零，只有它留 1 个孤儿）。 ## 判据（均做变异验证） - internal/lua/plugin_unload_on_close_test.go TestPluginsCloseCallsOnUnload 看真实外部效应（插件在 on_unload 写磁盘 marker），而非「钩子被调用过」这类内部信号 TestPluginsCloseSurvivesFailingOnUnload best-effort 契约 - internal/core/channels_orphan_callback_test.go TestPluginLoadSweepsOrphanCallbackFiles 看目录真实状态：孤儿必须消失，非回调文件（.channels-store.json）不得误删 - 变异均咬住：注释掉 callOnUnloadAll → 报红；清扫改 no-op → 报红。 ## 实测修复前跑一次起会话的测试批次留 7×N 个残留进程 → 修复后 0 个；全量回归（go test -tags luajit ./... 10 包）后回环/VNC 残留均为 0。 ## 过程中自查出的两处疏漏（已修） 1. 判据顺序又写反一次（同上 TestCloseFlushesTail 咬住）。 2. 两枚变异残渣留在工作区*未还原：internal/gateway/discover.go 里 `add(raw, "/models", 0)` 被删、`classifyAuthStatus` 的 `\|\| len(body) >= 0` 恒真注入。已 git checkout 还原。教训：变异测试必须逐次收尾，别靠记忆。	2026-10-15 22:43:58 +08:00
JianFeeeee	8d23005f7d	fix(trae): 登录失败真因 —— 虚构的「授权码交换」+ 空 client_id 用户报「TRAE 登录后显示失败」。定位到三处偏差，其中一处是核心缺陷： ① ★ 虚构了一次不存在的「授权码交换」（核心） poll_login 的 trae 分支自己发明了一段逻辑：回调只带 code 时，拿 exchange_body 去打 ExchangeToken。但： · ExchangeToken 的签名是 RefreshToken，不是 code； · exchange_body 里根本没有 {code} 占位符，那次替换是空操作； · client_id 当时是空串。于是稳定 400，日志回一句误导性的「Trae 授权码交换失败: 400」—— 把真因「上游走了 PKCE 流程」掩盖成「交换出错了」，排查方向完全错。按参考实现（trae-oauth.ts parseTraeCallbackDetailed）修正：带 code 的回调是合法回调，只是不支持的 PKCE 分支，必须明确报出来。删除虚构交换，两条路径共用 traeCallback 内建的 PKCE 判定。 ② client_id 从空串改为实测真值 en1oxy7wnw8j9n（对齐参考 trae-product.ts 的 clientId；ExchangeToken 请求体里 ClientID 必填，留空稳定 400）。 ③ 两条路径（oauth_callback / poll_login）现在共用同一结论，不再漂移 —— 这正是缺陷能藏住的原因：修复只覆盖一条、另一条继续错。测试支撑： - 新增 __set_loopback_probe（注入 loopback 回调文件），否则无法驱动 poll_login 的 callback 分支（那才是真实登录走的路径）。 - 判据 4 条，全部做变异验证： TestTraePkceCallbackIsReportedNotExchanged 打 poll_login，断言没打 ExchangeToken 且点名 PKCE TestTraeExchangeSendsRealClientID token 直传真调交换，请求体形状正确 TestTraeClientIDIsNotBlank client_id 必须是实测真值 TestTraeCallbackPathsAgreeOnPkce 两条路径必须共用 traeCallback - 变异 2/2 咬住：client_id 改回空串 → 报红；虚构交换加回去 → 「实际打了 1 次 ExchangeToken」。 ★ 我在过程中自己犯的两个错（均由变异测试揭穿，已修正）： 1. 判据打错了路径 —— 第一版打 oauth_callback（那条一直是对的），注入缺陷后判据仍绿。改成打 poll_login 才咬住。教训：判据必须打真实被使用的那条路径，否则等于没测。 2. 判据写错了契约 —— poll_login 用 HTTP 200 + json.state 表达终态，我按 status != 200 断言，把正确的实现判成了错。回归：go test -tags luajit ./... 10 包全绿。	2026-10-15 22:04:28 +08:00
JianFeeeee	ddbafe822c	chore(main): 回流 —— opencode Zen 免费层可用 + noVNC path 相对名修复内容与 release/v2.0.x 完全一致（git checkout release/v2.0.x -- .）： - feat(opencode): Zen 免费层门禁四要素 + 两个 id 公式（详见 release 提交） - fix(vnc): noVNC 的 path 必须用相对名，否则 WebSocket 路径重复拼接	2026-10-15 20:31:45 +08:00
JianFeeeee	482a65958b	docs(plugins): 补「前缀代理」章节 —— 插件自起服务挂到网关同端口	2026-10-15 15:02:04 +08:00
JianFeeeee	796b30f5b0	feat(插件代理): 同源反向代理 —— VNC 不再暴露额外端口问题：登录返回的 view_url 是 http://127.0.0.1:60100/vnc.html，WebUI 直接把它嵌进 iframe。远程运维打开必白屏 —— 127.0.0.1 在客户端指向客户端自己，且 websockify/x11vnc 只绑回环，换服务器 IP 也连不上（实测 LAN IP 访问 000）。 ★ 教训：只验证"服务端截图有画面"就宣布 VNC 可用是不充分的。四层链路里 ①X 渲染 ②noVNC 客户端渲染一直是好的，白屏真因在第④层「客户端如何拿到地址」。内核新增通用「插件前缀代理」能力（不是为 channels 写的专用反向代理）： - plugin.http 支持 prefix = true：声明前缀路由，承接所有子路径 - handler 返回 { proxy = "http://127.0.0.1:PORT" }，内核每次请求都问一遍 ⇒ 会话停止/过期后插件不再给目标，旧地址自然失效（撤销点唯一） - 鉴权与角色门禁复用现有链路，无旁路 - statusRecorder 增加 Unwrap()，让 Hijack 穿透访问日志中间件（否则 WebSocket 升级失败） - 目标只允许带显式端口的字面回环 IP（用户拍板方案 A）：拒绝 https、localhost 主机名、无端口、带 userinfo/path/query；理由是主机名可能被 hosts/DNS 改写 - 拒绝跨站 Origin（WebSocket 带环境 Cookie，否则第三方网页可借管理员会话开隧道） - 不向插件后端转发 Authorization/Cookie/api_key channels 接入： - 新增 channels/browser/proxy/:session（prefix=true） - 会话代号 = seq-随机8位，防猜到活跃会话 - view_url 改为网关同源路径，noVNC 的 WebSocket 走同前缀 /websockify - 会话过期即回收浏览器栈并返回 404 判据（每条咬真实外部效应）： - 静态资源转发 - 真实 HTTP 101 升级 + 双向数据回传（只断言静态转发不够 —— 升级是白屏真考点） - 网关凭据不泄漏（在服务端断言请求头） - 非法目标全拒（公网/localhost/https/无端口/带 path、query、userinfo） - 跨站 Origin 403 - 未鉴权 401、过期会话 404、非子路径 404 回归：go test -tags luajit ./... 9 包全绿	2026-10-15 15:02:04 +08:00
JianFeeeee	25a525be84	避免部署构建占满临时文件系统	2026-10-15 13:01:58 +08:00
JianFeeeee	ea8a9ac4c6	修复用量总计与渠道账本统计	2026-10-15 12:52:03 +08:00
JianFeeeee	8f73f77ec2	chore(main): 回流 —— VNC 兜底登录真正可用（放开 browser-stack 不需要的加固 + 修 3 个插件缺陷）按纪律先在 release/v2.0.x 提交，再内容对齐回 main。校验：git diff release/v2.0.x = 0 行。	2026-10-15 08:23:25 +08:00
JianFeeeee	c36a794aa8	chore(main): 回流 —— 第三批逐模块对照文档按纪律先在 release 提交再内容对齐。校验：diff vs release = 0 行。	2026-10-14 20:15:08 +08:00
JianFeeeee	0f263f895a	chore(main): 回流 —— 账号池落盘原子性判据按纪律：先在 release/v2.0.x 提交，再内容对齐回 main。校验：git diff release/v2.0.x = 0 行。	2026-10-14 20:12:10 +08:00
JianFeeeee	044ff1129b	chore(main): 回流 release/v2.0.x —— 插件自装适配器三连（qoder/cline）+ 自动领取 covers_today + isFree 权威来源按发布纪律回流。这四笔原本误提交在 main 上（我的操作失误）：纪律要求修复先在 release/v2.0.x 提交、再回流 main。已迁移： ① release 上 cherry-pick 这四笔（干净落地）； ② main reset 回 9bec158（那四笔未推送，无远端影响）； ③ 内容对齐回 main —— 等价于只捡拾修复、不带版本号。内容： - channels-qoder 适配器：10605(排队) 与 110(额度耗尽) 分开说，厂商码留在插件域 - channels-cline 适配器：解析英文句子里的等待时长（内核按额度耗尽冷却而非 30s 猛敲） - auto_claim：按 covers_today 记账（Qoder 10:00 刷新前不得算已处理）+ 间隔 2 小时 - isFree：改为按平台声明权威来源（cline 用远端 free[]/命名约定，opencode 用 cost）校验：git diff release/v2.0.x = 0 行；go build 通过。	2026-10-14 20:01:24 +08:00
JianFeeeee	9bec158d2e	chore(main): 回流 release/v2.0.x（v2.0.12）—— 内容对齐，main 无独有内容按发布纪律回流。注意这是内容对齐而非 merge，理由与依据： 1. 纪律禁止 merge 回主干，因为 merge 会把发布分支的版本号变更带进 main。本项目版本号只由 `git describe --tags` 推导（Makefile VERSION），仓库里没有任何文件存放版本号 ⇒ 回流不存在版本污染风险。 2. 逐项核对确认 main 是 release 的内容严格子集： - `main` 独有的文件：0 个； - `internal/lua/plugins.go` / `internal/core/kernel_actions.go` 等内核文件 main 独有行数：0； - `deploy.sh` 那 14 行只是 emoji 清理（release 刻意去掉了 emoji）； - `channels.lua` 那 333 行是旧版内容（旧 exports 表、旧模型名单）。 - main 独有的 9 个提交按 patch-id 全部已在 release 中等效存在（`git cherry` 逐条列出均为 `-`，即已合入）。 3. 故回流 = 把 release 的内容带到 main，等价于"只捡拾修复、不带版本号"，且不会丢任何 main 独有的修复。本次带回 v2.0.12 的全部内容（37 个提交）： - 源串行 + 按模型节流（照 model-gate） - 已失效模型存储 + 远端目录闸门 - 余额分档选号 - 模型能力元数据（models.dev，isFree 权威判定） - 凭据续期修复（此前恒报 ok:true 却一个请求都不发） - 通用件 TTL 缓存 + 串行锁；account_test/account_adopt/account_delete 修正 - 内核级：出站授权持久化重启后不生效、`__llmsproxy_plugin_dir` ground truth 校验：`git diff release/v2.0.x` = 0 行；`go build -tags luajit ./...` 通过。	2026-10-14 16:52:58 +08:00
JianFeeeee	0004545190	fix(channels): Loomy 真实微信 appId/uuid 正则修正 —— 之前是我编的值 ## 用真上游实测逼出来的两处错误批准出站主机后逐个平台打真上游，Loomy 报「授权页未包含二维码 uuid」。核对参考常量后发现： 1. appId 是我编的：我写 `wx16e5c2b8e0c0e1f2`，参考是 `wx18d60be432287cf8`。上游不认这个 appid，返回的页面里自然没有二维码。同时补上微信要求的固定片段 `#wechat_redirect`。 2. uuid 正则不是参考的那条：我写的是 `uuid="..."` 形式，而真实微信页把 uuid 内嵌在 `<img class="js_qrcode_img" src="/connect/qrcode/<uuid>"/>`，兜底路径是 `l/qrconnect?uuid=<uuid>`。照参考 extractLoomyWechatUuid 的两条正则改写（它还带一个 `^[A-Za-z0-9_\-=+/]{6,64}$` 的字符集校验）。 3. UA 逐字统一为参考的 WECHAT_UA（`Chrome/120.0.0.0`）。 ## 教训（值得记）「照参考逐行移植」这一条，我在这两处做成了「凭印象写个看起来像的」。判据是端到端打真上游，不是测试通过 —— 单测用的是我自己编的夹具，夹具与生产同源出错时测试照样绿。这次是真上游把它逼出来的。 ## 判据 - 测试夹具改为真实微信页面形态（`<img ... src="/connect/qrcode/<uuid>">`）：用别的形态（如 `var uuid = "..."`）测出来的正则不是生产要用的那条。 - 生产实测：Loomy 从真微信拿到二维码 uuid（`open.weixin.qq.com/connect/qrcode/<uuid>`）。 - 四个新平台真上游全部 pending 且返回有效授权入口： qoder→qoder.com（真实 PKCE challenge）、zcode→bigmodel.cn、 loomy→open.weixin.qq.com（真实 uuid）、raccoon→xiaohuanxiong.com（本地 code） - 全量 core 回归通过；内核对照 v2.0.2 diff 为空。 ## 出站主机授权 channels 的 27 个声明主机已全部在设置页批准（8 个新增 + 陈旧条目自动清理），落盘到 .kernel-perms.json，重启后保留。	2026-10-13 10:17:50 +08:00
JianFeeeee	1dda9e4477	feat(channels): Raccoon 扫码登录实现 —— 12 个平台零 manual 第四处也是最后一处「把没实现说成做不到」：此前标 manual，理由"要扫图片二维码"。参考事实（raccoon-oauth.ts / raccoon-login-page.ts 注释）： · `qrcode_code` 由宿主侧本地随机生成（16 字节 hex），服务端接受任意自造 code 并进入 pending —— 完全绕开收不到的自定义协议回调 · 二维码只是一张公开页面 {apiBase}/login/mp?code=...&appname=... · 轮询 POST /api/web/auth/v1/login_with_qrcode_code {qrcode_code} → data.status ∈ pending / logging / canceled / success · success 但缺 token 视为未完成（否则产出空凭据并让流程卡死） · 参考明确：任何异常都降级为 pending（网络抖动/畸形响应/未知 status）真正需要人工的只有短信路径（阿里云滑块 captcha_param + 手机号 AES 加密）—— 那一条不做，但扫码这条完全自动化。 ## 同时按参考修正的两处错误 - `base_url` 写成 raccoon.sensetime.com，实际是 xiaohuanxiong.com；推理路径是 `/api/web/llm/v2`（标准 OpenAI 兼容） - 余额路径缺 `/api/web` 前缀，且未带 `X-Org-Code` / `X-Raccoon-Language` 头（照参考 raccoonHeaders） ## 判据 TestRaccoonQrPollBehavior（5 项）：本地生成 32 位 hex code + 二维码 URL； logging 保持 pending；success 且带 token 才完成；canceled 是终态失败；缺 token 的 success 必须 pending（防空凭据卡死）。全量 core 回归通过；内核对照 v2.0.2 diff 为空。 ## 十二个平台现状（零 manual） trae/minimax/cline/buddy/gemini/lobsterai/opencode/codearts 原有流程 + qoder(device-poll) / zcode(init-poll) / loomy(wechat-poll) / raccoon(qr-poll)	2026-10-13 10:08:59 +08:00
JianFeeeee	04f12fae71	feat(channels): Qoder / ZCode / Loomy 从 manual 变为真正可用的自动化登录审计 12 个平台时发现：四个标 flow="manual" 的平台里，三个的登录协议完全可以在 Lua 里实现 —— 我把"没实现"写成了"做不到"，理由全是错的。 ## Qoder：WASM 是聊天加密，不是登录错误理由：「登录要 WASM 签名头」。实际：WASM 用于 /algo/ 加密推理端点，登录本身是标准 PKCE 设备码轮询（qoder-oauth.ts / qoder.ts）：授权页 = {authBase}/device/selectAccounts?challenge&challenge_method=S256 &nonce&machine_id&client_id（本地拼装，不打网络）轮询 = GET {openApiBase}/api/v1/deviceToken/poll?nonce&verifier&challenge_method=S256 三个必须照抄的细节（参考点名）： · client_id 用 prod 的（非 prod 会在授权回调阶段被拒） · poll 挂 openApiBase（openapi.qoder.sh）；authBase 返回 401 · 404 = 尚无会话（继续等，判失败会让登录永远失败）实现：新增 judge="pending404" 判据 + 既有的 device-poll 机制支持 `GET_QUERY`/`auth_query`（PKCE 授权页形态，无 device_code）。顺带修 poll_login 的条件（原要求 `s.device_code`，PKCE 形态没有它 → 永远不推进）。 ## ZCode：授权流不涉及 captcha 错误理由：「登录要解 captcha」。实际：captcha 属于另一条已废弃的旁路（读本机官方客户端数据）；本流注释明确写着「普通进程就能走完」： ① POST {origin}/api/v1/oauth/cli/init Bearer <本地造的 flow_secret> → {flow_id, authorize_url, poll_interval_sec} ② 用户浏览器打开 authorize_url ③ GET {origin}/api/v1/oauth/cli/poll/{flow_id} → {code:0, data:{status,...}} 判据（参考点名）：4xx（除 408/429）才是终态失败；code!=0 或 data 缺失 → pending； token(zcode JWT) 与 user.user_id 必需，第三方 token 取 bigmodel/zai 二者之一。另按参考修正 base_url/adapter（走 Anthropic 协议的 zcode.z.ai 免费额度通道）并补余额端点。 ## Loomy：扫码在手机上，协议在 HTTP 里错误理由：「扫码在微信里完成，Lua 做不了」。实际：扫码动作确实在用户手机上，但协议全是纯 HTTP： ① 取 uuid（授权页 HTML 里抽）② 二维码图 URL（前端渲染） ③ 长轮询 long.open.weixin.qq.com/connect/l/qrconnect ④ wx_code → 讯飞账号端点换凭据（HMAC-SHA1 签名）判据（参考点名，早期版本读反了导致"扫码后卡在已扫码"）： 408=等待；404=已扫码待确认（继续轮询）；405=已确认（wx_code 在此帧）； 403=取消；402=失效签名：内核只有 sha256/hmac_sha256，没有 sha1/md5 —— 插件用 openssl 算（HMAC-SHA1 与 Python 实测一致），不改内核。账号头前缀是 `account ak:sig`。 ## 顺带修的真 bug 1. `loomyAuthHeaders` 调 `newToken()`，而它定义在文件后段 → Lua 词法作用域下是 nil，调用即崩。改用内核全局 sha256_hex 造 nonce。 2. `declaredHosts()` 只看 hosts/base_url/checkin → 各 flow 的端点域名（open.weixin.qq.com / account.xfyun.cn / openapi.qoder.sh / zcode.z.ai …）不在出站白名单里，授权页与长轮询会被拦。已按 flow 补全推导。 3. `set_endpoints` 不支持 wechat —— 自动化测试无法把 Loomy 端点指到假上游（端点覆盖是参考明确的产品配置能力，也是测试缝）。已补 wechat/initpoll。 4. 两处 Lua 字符串引号错误（`"$(cat ...)"` 与 `"([^"]+)"` 提前结束字符串，插件编译失败）。插件加载测试抓到的。 ## 判据 - TestQoderDevicePollBehavior（5 项）：授权页含 PKCE 四要素与 prod client_id； 404 保持 pending；轮询带 verifier/nonce；拿 token 即完成；池路径凭据落账号 ref - TestZcodeInitPollBehavior（4 项）：init 带会话密钥与 provider；pending 保持； ready 完成且凭据含 zcode_jwt + 第三方 token；池路径 - TestLoomyWechatPollBehavior（4 项）：抽出 uuid 并给二维码；408/404 都是 pending（404 非完成）；405 才完成且账号端点用 account ak:sig 签名；403/402 失败 - 全量 core 回归通过；确认测试不写生产插件目录、无孤儿进程 - 内核对照 v2.0.2：diff 为空 ## 剩余 Raccoon 仍为 manual（本地承载页 + SMS，含人工输入验证码），另做。	2026-10-13 10:02:54 +08:00
JianFeeeee	cf53d72af4	fix: 回退两处内核改动，channels 改为插件自持持久化（照参考实现）用户指出「你又tm改内核？」—— 核对后确认两处本可避免： 1. internal/lua/vm.go +32 行新增 base64_decode 全局函数 2. internal/lua/plugin_http_handler.go +16 行 InvokeHandler 补 markDirty 工作区已还原到 v2.0.2（git diff v2.0.2 = 0 行）。参考实现（dsh-our-free-model/vendor/channel-pack）对同一问题的做法： - 解 JWT：用语言自带的 `Buffer.from(..., 'base64url')`，从不为此改宿主。 → 我改成了插件的纯 Lua b64url_decode（约 20 行），实测解出真 JWT 的 nickname/sub/exp 全对。 - 状态持久化：插件自己 writeFileSync+renameSync 写 `channel-pack/state.json`，从不依赖宿主 settings。 → 参考还记下了同构教训（Gitee IKI7WT）：DSH 0.1.7 移除 settings.register() 后账号列表退化为纯内存；正解是插件探测宿主能力、自持文档，不是要求宿主改。我的 markDirty 修法方向相反：把插件的数据安全外包给宿主某条分发路径的实现细节。 - `.channels-store.json`（tmp + rename 原子替换），只放索引与配置（账号条目含 credentialRef 而非凭据本身、模型黑名单、设置、事件日志）。凭据仍在 .secrets/（0600），两者分离：即便文档泄露也不含 token。 - 变更点同步落盘（不用「置标志+定时 flush」）：本插件无 hooks、45 个端点各自变更状态，还有大量内部互调；挂在某个边界就必须保证每条路径都经过它，漏一条就是「操作成功但重启丢失」——正是本次要修的缺陷形态。状态实测 ~1.7KB，写入只发生在运维动作上，不在请求热路径。 - 黑名单写入收口到 setModelDisabled（写点曾有 5+ 处，散着写必漏）。 - 存量迁移：读内核遗留 `.channels.state.json`（v2.0.4 内核写的）→ 写自有文档 → 写成功才删遗留（写失败还删=用一次迁移丢数据）；自有存储已存在时也删遗留，否则内核 restore() 会在启动时用它覆盖。 1. 测试污染生产目录（严重）：插件 storeDir() 读 /etc/llmsproxy/config.yaml 决定落盘位置，而既有测试都没隔离 → 一次全量测试把 26 个测试账号写进了生产 .channels-store.json（含 fixture-a/example 等夹具 id）。 prod 文件已删除（真实账号另有来源）；kernelTestCore 现在隔离插件目录，且尊重调用方已设的值（多次「重启」需共用同一目录）。 2. model_set_disabled 改了写入口后仍引用已删除的局部变量（nil 索引崩溃）。 - TestChannelsStoreIsPluginOwned：状态写进插件自己的文件、不含凭据字段、新实例读回。变异（markDirty 空操作）→ FAIL。 - TestChannelsMigrationKeepsLegacyOnWriteFailure：写失败必须保留遗留文件。变异（无条件删）→ FAIL。（这条单独测：迁移成功后的删除有两条路径互相掩盖，只测「最终文件没了」区分不出「写失败也删了」。） - TestChannelsMigratesLegacyKernelState：遗留账号迁入内存 + 自有存储写出 + 遗留文件删除。 - 内核对照 v2.0.2：diff 为空。 go test ./internal/core/（78s）与 ./internal/lua/（63s）全绿；全量测试后确认生产插件目录未被写入。	2026-10-13 09:34:13 +08:00
JianFeeeee	03430bcef5	fix(deploy): 内置插件的修复无法下发 + buddy 余额解析口径 ## deploy.sh：内置插件修复本该覆盖 sync_plugins 原为「只补缺，已存在一律不动」。看着安全，实际造成功能性缺口：内置插件自身的修复永远下发不了。v2.0.3/v2.0.4/v2.0.5 三个渠道修复就这样全部卡在仓库里 —— 二进制换了、/etc/llmsproxy/plugins/channels.lua 还是旧版（实测 sha256 不同、headers_fn 计数 0），生产行为毫无变化。我自己的验证还被这个"静默不生效"骗过一轮：测试全绿、部署成功，线上仍是旧逻辑。修法：与 sync_adapters 同纪律 —— 内置同名文件覆盖（带备份），运行时新增/运维自加的非内置名字一律不动。内置源码是发行物的一部分，部署必须与二进制内容对齐；"只补缺"想保护的是非内置文件，两者不是一回事。判据：部署日志出现 `~ 更新内置插件: channels.lua`；部署后生产文件 sha256 与仓库一致。 ## buddy 余额：双层嵌套 + 只累加有效包余额端点响应是 data.Response.Data.Accounts[]（与签到端点的单层 data 不同），原实现按顶层找 totalCredit → 永远解析不出、回落 0 或报错。且刻意不用服务端的 TotalDosage：那是终身口径且取整（参考实测同一响应 TotalDosage=655 而 IDE 显示 155.67）。正确算法是遍历 Accounts 现算：只累加有效包的 CycleCapacityRemain（失效包服务端仍返回，并入会虚高），按两位小数规整；双层缺失时如实报错，不把「查不到」当「余额为 0」。判据 TestBuddyBalanceParseDoubleNested：100.5+55.17=155.67（失效的 500 不计入）+ 单层 data 判为失败。变异：改用 TotalDosage → 立即 FAIL（已实测）。 go test ./internal/core/ 与 ./internal/lua/ 全绿。	2026-10-13 08:05:24 +08:00
JianFeeeee	192e545d40	fix(channels): buddy 计费请求缺身份头 → 上游 401（逐行移植参考 checkinHeaders）修好凭据读取后，余额端点仍报 HTTP 401。逐行核对参考 checkinHeaders (credits.ts) 后发现我们只发了 Authorization，而 buddy 要求身份标识头齐全： X-Domain: copilot.tencent.com （以产品配置为准，不用凭据里的 domain 快照） X-Product: SaaS （部署类型） X-Product-Code: codebuddy （产品码） User-Agent: CodeBuddyIDE/1.106.1 X-User-Id / X-Enterprise-Id / X-Tenant-Id（凭据携带时）参考的注释特别警告 X-Domain 的方向：凭据里的 domain 是「登录时那个域名」的快照，跨产品迁移后会指错区域，所以必须以产品端点为准。 ## 实现 - 平台级声明 headers_fn(accessToken, cred) → 返回请求头表；buddy 据此逐行移植。 - fetchAccountJSON 增加头钩子位：spec 自己的 headers_fn 优先，否则回退平台级。未声明的平台仍走通用默认头（Bearer + JSON），不改变既有行为。 - set_endpoints 补齐 checkin_status / balance 端点覆盖（此前只覆盖旧的 plat.checkin，buddy 这类平台无从改指，自动化测试也指不到假上游）。端点覆盖是参考明确的产品配置能力，也是测试缝。 ## 判据 TestBuddyBillingHeadersMatchReference：把 buddy 余额端点指到本地假上游，断言四个必备身份头逐字段正确。变异：改名 headers_fn → 立即 FAIL（已实测）。 go test ./internal/core/ 与 ./internal/lua/ 全绿。	2026-10-13 07:57:56 +08:00
JianFeeeee	de9d7c8008	fix(lua): InvokeHandler 从不 markDirty —— 无 hooks 的插件状态永不落盘 ## 现象 channels 插件重启后账号池静默清空：status 返回 accounts={}、pool=null、log=0 条，磁盘上 `.channels.state.json` 从未存在过（billing/quota 的 .state.json 都在）。用户侧表现为「登录了，但重启一次账号就没了」。 ## 根因插件状态持久化有三条分发路径，其中两条会 markDirty： - hook 路径（invoke） → markDirtyLocked ✓ - 导出函数路径（Call） → markDirtyLocked ✓ - HTTP handler 路径（InvokeHandler） → 从不 markDirty ✗ channels 声明 `hooks = {}`，它的一切状态变更（账号入池、凭据引用、模型黑名单、事件日志）都只经过自己的 HTTP 路由。于是状态从未被标记为脏， `.channels.state.json` 从未写出，重启即全部丢失。 billing/quota 侥幸没踩到：billing 有 hooks，quota 走 Call。 ## 修复 InvokeHandler 在成功返回前 markDirtyLocked(p)，并在 handler 抛错的早退分支也标记（抛错前可能已改过状态，那次改动仍然是真实的）。与 Call / hook 路径同模式，只碰 stateSaver 自己的锁，不重入 p.mu（调用方已持锁）。 ## 判据 internal/lua/persist_test.go::TestInvokeHandlerIsPersisted 用「无 hooks、只走 HTTP handler」的插件复现 channels 形态：两次 handler 调用后 Close()（等最后一次 flush），断言 .state.json 存在且含 2 个账号。变异：撤掉 markDirtyLocked → 测试立即 FAIL（已实测）。 go test ./internal/lua/ 与 ./internal/core/ 全绿。	2026-10-13 07:47:55 +08:00
JianFeeeee	8a3059740f	fix(channels): 登录后账号拿不到凭据 —— 完成路径不传 account_id + 只存裸 token 用户报障：「登录了，但插件这边无法获取账号信息」。实证： account_list → has_credential=false，credits/balances → 「无凭据」，而 UI 上账号显示已登录。 ## 根因一：完成路径没把凭据写进池账号的键 UI 的真实流程是「account/add 建占位账号（credentialRef=channels:<plat>:<aid>） → login 带 account_id → 轮询 login/status」。但 poll_login 的两条完成分支（device-poll / state-poll）调用 complete_login 时没有传 account_id，于是走了兼容旧路径，凭据落到 `channels:<plat>` 这个与占位账号无关的键；池账号的 credentialRef 指向 `channels:<plat>:<aid>`，从未写入 → account_list 的 has_credential 恒为 false。修：两条分支都传 `account_id = s.account_id`（对齐参考 BuddyAuth.login 的 `flowOptions.accountId` 语义：多账号场景下凭据按账号 ref 写入）。 ## 根因二：只存裸 access_token，丢掉 refresh_token 与过期信息 state-poll 分支只取 `data.accessToken` 当凭据存，而参考 `runBuddyLoginFlow` 存的是 `buildCredential(token, account)` 的完整 JSON （access_token + refresh_token + expires_at + refresh_expires_at + token_type + scope + domain + user_id + nickname + enterprise_id + account_type）。只存裸 token 的后果：refreshable 恒为 false → 无静默续期；expires_at 未知。修：新增 buildCredential（逐字段对齐参考 buddy.ts）+ jwtClaim/absExpiryMs （参照实现：token 端点只回 expiresIn 不回 expiresAt，昵称只在 JWT 声明里） + credentialExpiresAtMs。state-poll 完成时存完整凭据 JSON 并回报 expires_at/refreshable。 ## 配套 - 新增 credentialOf(ref)：凭据取值助手，裸 token 与完整 JSON 两种形态都认（历史数据/device-poll/paste 是裸 token，buddy 是 JSON）。所有消费点（上游源 api_key、Bearer 头、HMAC 签名、备份）改走它，无须关心存储形态。 - complete_login 从凭据自动补齐 nickname/expiresAt/refreshable，调用方漏传也不丢。 - 内核新增 base64_decode（标准/base64url/无填充都认）：插件读 JWT payload 必需，否则要在 Lua 里重写 base64。通用能力，无厂商知识。 ## 判据 TestBuddyStatePollBehavior 行2/行4： - 行2 断言凭据是完整 JSON（含 refresh_token + 昵称），非裸 token - 行4 回归用户报障：走 account/add → 带 account_id 登录，断言 ① 凭据落在 channels:buddy:<aid> ② account_list 报 has_credential=true ③ refreshable=true 变异验证：去掉 account_id → 行4 立即 FAIL（已实测）。 go test ./internal/core/ 与 ./internal/lua/ 全绿。	2026-10-13 07:41:56 +08:00
JianFeeeee	028e42b036	fix(plugins): 出站主机授权两处真缺陷 —— 已启动 worker 看不到新授权、授权不落盘生产实证：channels 插件的 auth/state 在主机已授权后仍被拒（auth/state 失败: host "copilot.tencent.com" is not an allowed outbound destination），而 /api/plugins/channels/kernel 明明显示 hosts_granted=26。缺陷一（授权对已启动 worker 无效）： httpAllowlist 是不可变快照；bootPluginState 在 worker 启动时把指针绑进 Lua 闭包，闭包与 worker 同寿。GrantExtraHosts 之后 ps.allowHTTP 被整个换新（newHTTPAllowlist 返回新实例），已启动的 worker 仍持旧指针 → 授权接口返回 ok、设置页显示已批，请求却继续被拒。分片 VM（plugin_shard.go）同样中招。修法：allowlist 改为带 RWMutex 的可变共享对象，GrantExtraHosts 与 rebuildOutboundAllowlistLocked 原地 add —— 所有闭包立即看到新授权，worker 无需重建。rebuild 从"替换实例"改为"原地折叠"，并在注释里写明为什么。缺陷二（授权不持久化）： .kernel-perms.json 只写 actions；hosts 授权只存在运行态 map，重启即失。设置页看不出异常（actions 有持久化，读起来像"都持久化了"）。修法：文件行改为 jsonPluginPolicy{actions,all_read,hosts}（旧文件向后兼容，纯 actions 行照常解析）；Load 恢复 extraHosts；Save 把每个插件的 host 授权与 actions 一起写入（支持"只批了主机、没批动作"的行）。回归测试（internal/lua/plugin_http_test.go）： - TestGrantExtraHostsVisibleToAlreadyBootedWorker：按事故顺序构造（先启动 worker → 再授权），断言同一批 worker 立即可用新授权 + 旧引用不再失效。 - TestHostGrantsPersistAcrossRestart：授权落盘 + 新 registry 读回 + 插件重载后授权保留。 go test ./internal/lua/ 全绿；build/vet 通过。	2026-10-13 06:57:28 +08:00
JianFeeeee	84c9066bed	fix(plugins): 新内置插件要能落地 —— SeedBundled 改为按文件补齐，deploy.sh 补插件同步真实事故：channels.lua（多平台账号接入插件）在仓库里、在 2.0 二进制里（go:embed），生产却完全看不到它 —— /api/plugins 只有 billing/quota/usage。根因是两处叠加： 1. SeedBundled 只在 plugin_dir 不存在时才写内置插件。生产 plugin_dir 从首次安装起就存在，于是后来加入二进制的新插件永远不会落盘。目录存在不等于内容是最新的 —— 这个假设把"新增内置插件"整条路径堵死了。改为按文件补齐：只在该文件缺失时才 seed，已存在的一律不动（运维自己改过、或运行时新增的插件必须跨升级存活 —— 与适配器同一条规则）。 2. deploy.sh 完全不处理 plugins（只同步 adapters/）。即使内核修好了，部署脚本也没有把插件内容与仓库对齐的动作。新增 sync_plugins：备份、只补缺、对已有文件零改动、末尾逐个校验内嵌插件都在目标目录，摘要里打印插件目录。测试（internal/lua/vm_test.go）： - TestSeedBundledFillsMissingFilesInExistingDir：构造确切事故条件（目录已存在、只有部分插件），断言缺失的被补齐、运维自己的 billing.lua 不被覆盖、补齐后 channels 确实出现在插件表里。 - TestSeedBundledIdempotent：二次 seed 不覆盖已就位文件。 deploy.sh 通过 bash -n；go test ./internal/lua/ 全绿。	2026-10-12 19:07:17 +08:00

4 changed files with 33 additions and 0 deletions

									
										4

HANDOFF_2026-10-19.md
									
												View File
												
				@ -1,5 +1,9 @@

				# ModelRouter / llmsproxy 交接文档

				> **历史文档**：本文记录的渠道能力（channels / quota 插件与 4 个私有协议适配器）

				> 已于 v3.0.2 按合规要求整体移出仓库。保留原文仅作历史记录，其中的路径、

				> 模块名与适配器清单不再代表当前代码。

				更新时间：2026-10-19

				工作目录：`/home/program/llmsproxy`

				当前分支：`release/v2.0.x`

21

LICENSE Normal file

View File

 @ -0,0 +1,21 @@
 MIT License
 Copyright (c) 2026 HeNanMU-EEA
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal
 in the Software without restriction, including without limitation the rights
 to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 copies of the Software, and to permit persons to whom the Software is
 furnished to do so, subject to the following conditions:
 The above copyright notice and this permission notice shall be included in all
 copies or substantial portions of the Software.
 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
 AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 SOFTWARE.

									
										4

README.md
									
												View File
												
				@ -132,3 +132,7 @@ go test -tags luajit ./internal/lua # 单包（LuaJIT 相关改动必跑）

				- 分支与发布纪律见 [docs/git-workflow.md](docs/git-workflow.md)。

				- 插件放置在 `plugin_dir`，网关启动时**不会**创建、覆盖或删除任何插件文件；

				  升级桌面端也不会动它们。

				## 许可

				MIT License，见 [LICENSE](./LICENSE)。

									
										4

README_EN.md
									
												View File
												
				@ -149,3 +149,7 @@ go test -tags luajit ./internal/lua  # one package (required for LuaJIT changes)

				- Branch and release discipline: [docs/git-workflow-en.md](docs/git-workflow-en.md).

				- Plugins live in `plugin_dir`. The gateway never creates, overwrites or deletes

				  plugin files, and a desktop upgrade never touches them either.

				## License

				MIT License, see [LICENSE](./LICENSE).

Compare commits

75 Commits

v3.0.2 ... main

4

HANDOFF_2026-10-19.md

View File

21

LICENSE Normal file

View File

4

README.md

View File

4

README_EN.md

View File

Compare commits

75 Commits v3.0.2 ... main

4 HANDOFF_2026-10-19.md Unescape Escape View File

21 LICENSE Normal file Unescape Escape View File

4 README.md Unescape Escape View File

4 README_EN.md Unescape Escape View File

75 Commits

v3.0.2 ... main

4

HANDOFF_2026-10-19.md

View File

21

LICENSE Normal file

View File

4

README.md

View File

4

README_EN.md

View File