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
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
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
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
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
12bfd53f16
fix: 收口渠道源迁移与测试页合并
2026-10-19 17:21:22 +08:00
25970a2135
refactor(scheduler)!: 移除 priority 废弃字段 + 一通道一源 + discover 复用凭据
...
用户判据：「priority 直接移除」「即使带 key 也没有 /v1/responses」
「channel 插件的问题还没完全解决」「生图和聊天合并到一个导航项」
## 一、删除 priority（它从未参与跨源调度）
`config.Model.Priority` 号称"高者优先参与 AUTO 选源"，**那是错的**：
AUTO 链由 `config.ModelScope.Tier` 驱动（scheduler.Chain），priority 只被
`bestChatModel/bestImageModel` 用于"本源内部该发哪个模型"，与跨源调度无关。
把它当调度依据会让人以为拖个数字就能改顺序，改完毫无效果。
- 删 `config.Model.Priority` 字段与 `bestChatModel/bestImageModel` 的优先级比较
- 删 `seedAuto()`：**AUTO 链为空时网关应直接 503**，不能凭空播种用户没配过的档位
- 删 UI `buildLanes` 的 discovery 回退（按源 priority 自动铺开）与 sourceRows
- 清掉 config.yaml 里 140 行 priority
## 二、一通道 = 一个适配器 = 一个源（channels 插件）
旧设计「一账号一源」(`channels-<平台>-<12位hex>`) 有三个结构性后果：
1. 三个账号 ⇒ 三个源、三份同名模型，用户看到三行无法区分的东西
2. 谁先谁后**取决于注册顺序，不是余额**（rankAccounts 只用于展示，从未接进同步路径）
3. 换号要改源名 ⇒ 用户书签里的 `源:模型` 全部失效
新设计：
- 源名只跟通道绑定：`channels-<平台>`，换号 = 同名 add_source 覆盖 api_key
（内核 AddSource 是 UpsertSourceInYAML + 内存替换），对客户端完全透明
- `pickAccountForSource()`：凭据可用 → 余额分档（先快作废后永久）→
跳过已标记失效的号。没有 balance 声明的平台不据此排除（不因"不会查"判死）
- `request_end` 钩子：真实请求失败且是**终态**错误（需充值/封禁/凭据永久失效）
时给当前账号打 termErr，下次选号跳过；成功则清标记。
⚠️ 只认终态 —— 429/超时/抖动都**不**标记（那会把好号一个个废掉）
- `refresh_creds` 每 30 分钟巡检后重新选号（兜底心跳，纯本地判定）
- 迁移：同步时自动清掉旧版按账号拆的源（按已知平台前缀匹配，不用贪婪 match）
- 顺带修：`refresh_creds` 漏认 `refresh_fn` ⇒ codearts 的 DPoP 续期永不触发
## 三、discover 支持用已存凭据（真实缺口）
刷新已有源的模型目录，此前必须让运维**再粘一次明文 key** —— 而库里是
`enc:v1:` 密文，WebUI 也不回显明文。结果就是"想刷新 → 得重新申请 key"，
很多人干脆不刷，源的目录越放越旧（实例：某源 3 个生图模型从未登记）。
- `{"name":"oin"}` ⇒ 从已存源取 base_url + 解密凭据 + adapter
- 安全边界：已要求 admin；只能探测**本网关已配置的**源（不能拿任意 URL+key
做探测，那就成了 SSRF/密钥外带）；响应不回显 key
## 四、image_models 显式声明（补元数据缺失）
`discoveredModelKind` 只看上游 modality 字段，并刻意**不从模型名推断**
（错误的 kind 会毒死 AUTO 链）。但有些网关的 /v1/models 只返回
`{id,object,created,owned_by}` —— 零 modality，于是生图模型全落成 chat，
生图端点永远 `no image source configured`。
不解这个两难：默认仍完全按元数据（不猜），但允许 `image_models` **显式声明**。
写错的 id 明确报 400，不静默造一个不存在的模型。
## 五、UI：对话与生图合并为一个导航项
两者本是同一件事的两种输入（都选模型、都发请求、都读结果），只是 kind 与端点
不同。合并只发生在**导航层**：模型下拉仍按 kind 分组/禁选（把图片模型选进 chat
会请求到错误端点）。两个面板同时存在于 DOM，切换只改 display —— 来回切不会丢
已输入的文字、对话历史或已生成的图。
## 测试
- `TestUI_ImageModeIsReachableFromChatTab`：改为钉"合并后仍可达"（分段控件、
切换函数、面板容器、端点），并断言**旧 tab 三件套必须消失**（否则 goTab 会找
一个不存在的面板）
- 测试夹具显式建 AUTO 链（内核不再 seedAuto）：默认一源一 tier 倒序
（TestChatAUTO 验优先级）；TestChatAutoChainTierFailover 自己覆盖成同 tier
（验 tier 内轮转）—— 两者验不同机制，不能共用一个默认
- core 的一批断言从"按账号 id 找源"改为"按平台名找源"
gateway/config/provider 全绿；core 的 channels 用例全绿。
TestRealMutants 需工作树干净后才跑（其自带的变异残留防护）。
BREAKING CHANGE: config.Model.Priority 已删除。旧的 priority 字段会被 YAML
解码静默忽略（内核不校验未知字段），因此既有 config.yaml 仍可加载，但该字段
不再有任何作用 —— 调度顺序请通过 AUTO 链的 tier 表达。
2026-10-19 16:26:59 +08:00
8b318a8507
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:14 +08:00
7a8d97001c
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 14:57:13 +08:00
eaac0ef6b3
修复用量总计与渠道账本统计
2026-10-15 12:43:11 +08:00
41ff6d1be3
fix(channels): 修服务端浏览器栈的四处泄漏（含宿主 SHM 耗尽）
...
这些缺陷让「测试单独跑绿、全量跑红」，在生产同样会让登录用到一半失败。
## ① 宿主级：SIGKILL 杀 X 进程 → SysV SHM 段耗尽
X 服务用 MIT-SHM 与客户端通信，被强杀时这些段无人释放，成为系统级孤儿段
（nattch=0 但占着 kernel.shmmni 名额）。实测单个 Xvfb 约 84 段，上限 4096
⇒ 约 48 次异常退出即耗满。用满后**宿主上任何**新进程 shmget 都失败：
x11vnc 从 0.2s 能监听变成永远起不来（表现为「x11vnc 端口未就绪」）。
修：回收改为**先 SIGTERM、等 0.4s、再 SIGKILL**，让 X 自己释放 SHM。
实测 core 全包前后 shm 84 → 84（零泄漏）。
## ② 显示器锁泄漏 → 号段被烧穿
强杀留下 /tmp/.X<n>-lock，而选号是「锁/socket 存在就当被占」⇒ 每个被强杀的
显示器永久烧掉一个号；累积满 91 起后 pickFree 扫不到空位就 return start(91)
→ Xvfb 报 “Server is already active for display 91”（实测 41/41 全占）。
修：pickFreeX 回收陈旧锁（用 /proc/<pid> 判存活，不信 shell 退出码）+ 扫 200 个号
+ 扫不到如实报错；收尾清掉自己占的锁与 socket。
## ③ chromium profile 复用 → SingletonLock 卡死
数据目录原用 seq 编号，插件重启后 seq 重来 ⇒ 复用同目录 ⇒ 残留 SingletonLock
让 chromium 只打印 “Opening in existing browser session.” 就退出，新端口永不监听
→ 报「chromium 端口未就绪」。
修：目录名用唯一 tag（时间+随机），并在收尾清掉。
## ④ callback 流漏收浏览器栈
callback 流在 start_login 就拉起服务端浏览器栈，但没有任何路径负责回收
⇒ 每次放弃登录都留一套（实测一轮 core 全包攒 7 套 websockify+x11vnc）。
修：会话过期时若栈属于该会话就收掉；起新栈前先收旧栈（单会话栈）；
kernelTestCore 统一 t.Cleanup 调 stop_browser。
## 判据
- TestXDisplaySelectionReclaimsStaleLocks：陈旧锁必须被**回收复用**（只跳过不算通过）
- TestXDisplaySelectionKeepsLiveLocks：活锁不得被回收（反向）
- 两个变异（去掉收尾清理 / 有锁就当被占）均被抓
## 另：变异测试会污染生产源码，加进程级兜底
discover_mutate_test.go 会改写 internal/gateway/discover.go，靠 defer 回滚 ——
进程被强杀（go test 超时 / Ctrl-C / 误杀 shell）时 defer 不执行，变异体留在工作区，
下次运行会把它当"原始源码"，所有裁决静默失效（本仓真实踩过两次）。
新增 mutation_guard_test.go：进包即自愈已知变异体。
2026-10-13 15:24:07 +08:00
6fe6014d92
chore: 清理 emoji 与修正发布脚本仓库名
...
产品代码统一为纯文本风格（照参考实现），去掉 emoji：billing/quota/usage 插件、
channels 的提示文案、WebUI 文案，以及 go 测试、docs、packaging 脚本中的
注意/OK/FAIL 等符号化写法。第三方目录（vendor、node_modules、.probe）不动。
另：packaging/upload-release.sh 的仓库名改为真实全名
JianFeeeee/ModelRouter → HeNanMU-EEA/ModelRouter（前者是重定向，POST/PUT 不跟随
会 404）。
2026-10-13 13:42:57 +08:00
3c59c33c58
feat(adapters): 入向端点移交适配器 —— adapter.ingress + deserialize_request，内核主动让出
...
plan.md 的 R2 目标里有三行钩子契约，出向两条（serialize_response/serialize_chunk）
Phase 2 已落地，第三条 parse_request(protocol_body) -> unified 一直空着：
/v1/messages 的入向解析硬编码在内核 Go 里（anthropicRequest.toUnified），
Anthropic 改协议就得改内核。本次补齐这条对偶。
## 机制（与出向序列化对称）
- 适配器声明 adapter.ingress = "/v1/messages" 认领入站路径，并实现
deserialize_request(raw_body) -> unified_json。
- 内核 handleMessages 经新增的 parseViaIngress 判定：
- 有适配器认领该路径且实现了钩子 → 让出，解析由适配器完成；
- 无适配器认领 → 内核内置解析运行（R5 兜底，未配置部署仍可服务）。
- 认领了但钩子执行失败 → 硬错误 400，不静默换用另一种协议解析
（客户端说的正是该适配器声称支持的协议，悄悄换解析器只会错误调度）。
- 这是内核里唯一的新判定点，与 serializerFor 对称：出向选序列化器，入向选解析器。
## 内核改动
- internal/lua/vm.go：staticInfo 增 ingress 字段；inspectScript 读取；
新增 VM.AdapterForIngress(path)（确定性选择：同名多认领取字典序最小）。
- internal/gateway/messages.go：handleMessages 改为先读 body → parseViaIngress
（让出）→ 未认领时回落内置 anthropicRequest.toUnified。
内置解析与 anthropicRequest 类型保留——它们是兜底，不是死代码。
## 适配器改动
- internal/lua/adapters/anthropic.lua：声明 adapter.ingress = "/v1/messages"，
新增 deserialize_request，把内核原 Go 解析逻辑逐字段移植（system 两种拼写、
content 原样透传、缺省 thinking={enabled:false}、缺 messages 报错）。
内置 anthropic 默认随包播种，因此真实部署里内核总是让出给它，
Go 侧 anthropicRequest.toUnified 退化为纯兜底。
## 测试
- gateway：TestMessagesIngressYieldsToBundledAnthropic（让出后仍 200）、
TestAdapterForIngressClaim（声明可被找到、未声明路径为空、钩子存在）、
TestMessagesKernelFallbackWhenNoAdapterClaims（移除认领适配器后内核兜底仍 200）。
- lua：TestAnthropicDeserializeRequestShape 逐字段核对 Lua 与 Go 产出一致
（system 拼接、content、max_tokens/stream/temperature/top_p/top_k/stop_sequences、
缺省 thinking），TestAnthropicDeserializeRejectsMissingMessages。
- 全量回归：gateway/lua/core/config/types/provider/scheduler/e2e 全绿。
- 文档：docs/lua-adapters.md 补「入向让出钩子」章节 + plan.md 台账更新。
2026-10-12 16:32:30 +08:00
5948ad19ca
feat(plugins): 服务路径/适配器名冲突进裁决而非崩溃或硬拒绝（用户要求 A+B）
...
此前两类冲突各有问题：
A) 两个插件声明同一条 /api/plugins/http/ 服务路径 → 分发器按加载顺序静默
选一个（装个新插件就可能改变既有路径归属）。
B) 插件装与内置/他插件同名的适配器 → 硬错误 ErrAdapterNameReserved / owned by。
用户要求：都改成「报冲突、列出候选、运维选一个保留、选择持久化」，绝不崩溃
或拒绝启动。
## A 类：插件 HTTP 服务路径冲突
- dispatch（plugin_http_routes.go）同路径多认领时不再 load-order 选边：未裁决
返回 409 并点名候选；已裁决按赢家分发。
- route_conflicts.go：RouteConflicts/RouteWinner/ResolveRouteConflict，只统计
loaded 且未禁用的插件；赢家插件若不再声明该路径，裁决作废回未裁决态。
## B 类：适配器名冲突
- InstallAdapter 撞名（内置或他插件所有）不再硬拒，改挂起：现任继续服务，候选
入 AdapterConflicts，返回 typed ErrAdapterConflictPending（区分「代码错」）。
- ResolveAdapterConflict：incumbent 保留现任 / candidate 真正装上插件版（绕过
reserved 门禁——这是运维显式授权覆盖内置的唯一入口）并转移归属。
- 现任内置永不被静默覆盖，守住「第三方插件不得篡改内核发行物」信任边界。
## 持久化 + WebAPI + WebUI
- 两张裁决表落 .route-conflicts.json（routes + adapters），LoadDir 时读回；
重启后插件再装同名适配器自动套用上次裁决。
- WebAPI：GET /api/plugins/conflicts 列冲突；POST {kind,path|name,winner} 裁决。
- WebUI：插件页顶部「冲突裁决」卡片，逐条列路径/适配器冲突 + 候选 + 裁决按钮。
## 测试
- 单测 conflict_arbitration_test.go 6 项全过：路径冲突检测/裁决/持久化/重启、
赢家消失回退、适配器撞名挂起/incumbent/candidate/归属转移、非法 winner 拒绝、
自身更新不受影响（token 轮换不走冲突路径）。
- e2e conflict_arbitration_e2e_test.go 2 项全过（真二进制）：两插件抢路径→409
点名→裁决→200 赢家应答→/v1/models 无回归；插件装 shadow openai→挂起→现任
保留→裁决 candidate→插件版生效→冲突清空。
- 全量 build + vet 通过，既有 lua/gateway/core 回归无破坏。
修正过程中发现并修了一个真 bug：LoadAdapterSource 对 key≠declared 的适配器
重装会建第二个池、留旧池继续服务（v2 装了 v1 还在跑）——改成统一按注册键
归档，裁决 candidate 后新版本才真正生效。
2026-10-12 12:32:10 +08:00
50997a4e3a
fix(ui): 设置页适配额外出站主机授权 —— hosts_declared/hosts_granted
...
上一提交把 auth_hosts 语义泛化为 plugin.hosts（额外出站主机授权），但设置页
仍读旧字段名 auth_hosts_declared/auth_hosts_granted、提交 auth_hosts 键 ——
导致内核权限面板的主机授权区永远显示"未声明"，勾选保存也不生效。
- 读取: auth_hosts_declared/granted → hosts_declared/granted
- 提交: { auth_hosts } → { hosts }
- 文案: "登录主机" → "额外出站主机"（授权与登录无关，登录是插件自己的事）
内联 JS node --check 全部通过；UI 契约测试通过。
2026-10-11 16:47:24 +08:00
74ec1e7874
refactor(lua): 内核回归六项职责 —— 登录/浏览器全部移入插件
...
用户钉死了内核的职责边界，本提交把越界部分全部拆除：
内核只做：加载适配器 · auto 调度 · 加载插件 · 调度插件 · 维护源与 key · 签发密钥
## 架构纠正（用户指出的根本错误）
我此前把信任模型弄反了。实测：插件 VM 的 os.execute/io.popen/package 全部可达
(true,true,true) —— 插件从来不是 OS 级沙箱。正确的边界是：
插件 可信（运维安装），非沙箱，有完整 OS 能力 → 平台知识/登录/浏览器归它
适配器 不可信（可被动态安装），请求级 → 沙箱归它（12 个内置适配器实测均不碰
os/io/package，后续沙箱化零风险，属独立一步）
## 删除（内核越界部分）
- plugin_browser.go 内核浏览器管理器（Xvfb/chromium/x11vnc/websockify
进程栈、回环监听器）—— 388 行全删，浏览器由插件用
os.execute 自己拉起（实测 spawn+reap 闭环可用）
- plugin_login.go 登录会话状态机 + LoginFlow 枚举 + VNC 全局门禁
—— 457 行全删。"登录"从内核概念中消失
- gateway/browser_proxy.go viewer 反代
- handlePluginLogin API 登录会话列表端点
- vnc_enabled 全局开关 改为 per-plugin 授权（见下）
## 新增（内核职责内的通用机制，无任何登录/浏览器语义）
- plugin_outbound.go 通用额外出站主机授权：插件声明 plugin.hosts（请求）
→ 运维在设置页逐个批准（授权）。与 kernel actions
同一"声明≠授权"模型。内核只知道白名单加减，不知道
host 被用来干什么
- on_unload 生命周期钩子 卸载是"调度插件"的一部分：内核在关闭插件状态前调用
插件导出的 on_unload，让它自清理外部资源。内核不知道
资源是什么（进程/句柄/远端会话都行）。带进程回收回归
测试 TestOnUnloadReapsPluginProcesses
## channels.lua 全量接管
- 登录会话自持：plugin.state.sessions（nonce 只在 begin 响应出现一次，
惰性过期清理）
- 服务端浏览器栈自持：spawnBrowser 用 io.popen 拉起 Xvfb/chromium/x11vnc/
websockify 并记 pid，reapBrowser 回收；on_unload 兜底
- 优先级阶梯（用户指定）：① 本机浏览器（给 URL）→ ② 自动化（轮询/nonce 回调）
→ ③ VNC 无头浏览器兜底（无浏览器系统/自动化无法完成的场景，如回环重定向
必须落在服务端）
- plugin.auth_hosts → plugin.hosts（语义泛化：出站主机授权与登录无关）
## 验收
- 全仓旧符号零残留（grep 权威确认，代码+注释+lua+测试）
- 内核非测试代码零厂商名
- build + vet 全绿；lua/core/gateway/types/scheduler/provider 全量测试通过
- channels 端到端（登录→凭据→add_source→模型可见）继续通过
2026-10-11 16:24:55 +08:00
fa50ec8bc7
feat(lua): 服务端浏览器登录（VNC）+ 内嵌页签 —— 回环回调的唯一自动化路径
...
用户指明的场景修正了我的一个实质错误。我之前写"VNC 不解决取凭据，凭据还在
浏览器 profile 里"——这对 cookie 类成立，但对**回环重定向**不成立：
浏览器在用户机器 → redirect 到 127.0.0.1:P → 打到**用户的**回环 → 服务端收不到 code
浏览器在服务端 → redirect 到 127.0.0.1:P → 打到**服务端的**回环 → 插件直接收到 code
后者不需要"提取凭据"，code 自己流到监听方。所以对回环类登录，服务端浏览器
不是权宜之计而是**唯一自动化路径**。已实测验证（浏览器在服务端时 loopback
回调的 code 落到了服务端监听器）。
## 实现
plugin_browser.go：Xvfb(:N) ← chromium → x11vnc → websockify(noVNC) + 回环回调监听。
五个进程一起起停，因为失败模式是顺序相关的（崩掉的会话留下的 Xvfb 会让下一个
chromium 以看起来像浏览器 bug 的方式失败）。
**默认关闭，且不是"开了 VNC 就能登全部"**：每个平台单独走 vnc 流程才启动。
理由是这套东西风险最高——在服务端跑真实浏览器登录用户的第三方账号。
**边界**：插件拿到的是 view_url，**不是浏览器控制句柄**。CDP 端口不进 Lua。
否则一个插件就能读所有标签页的 cookie，而那个浏览器登录的是运维的账号。
**teardown 必须删 profile**：里面是活的第三方 session cookie，删它是安全契约
的一部分，不是收尾工作。
## viewer 反代（browser_proxy.go）
/browser/<id>/... → 该会话的 websockify。为什么不直连端口：
1. 鉴权——直连等于把已登录的浏览器暴露给任何能访问该端口的人（实测未鉴权
访问得 302 → /login，带 admin key 得 3912 字节 noVNC 页面）
2. WebSocket——noVNC 核心是 WS 升级，httputil.ReverseProxy 原生处理
3. 同源——WS 路径不需要跨域配置
## 内嵌在插件页签（用户要求）
viewer 用 iframe 内嵌进 channels 插件的登录区，而不是让人跳出去开新窗口：
- 插件 UI 拿到 view_url 就塞进 iframe src，登录完成/失效时清空 src 并隐藏
- 插件只对 `flow = "vnc"` 的平台起浏览器；其他流程继续用用户自己的浏览器
（等于白开一个高风险的浏览器是浪费）
## 插件本体：channels（同类插件）
单插件多平台，4 个平台示范四种流程（link-poll / callback / paste / vnc）。
登录 → 凭据进保险库（不进 state）→ add_source 接入内核 → 定时领额度。
声明式：plugin.kernel 申请内核动作、plugin.auth_hosts 申请登录主机，
设置页显示"申请中"由运维批准。平台表加一条就多一个平台，内核零改动。
开发中被测试抓到的三个真实缺陷（都在我自己的代码里）：
1. handler 返回 `{url=…}` 没有 status/json → 内核**静默丢弃**，200 空响应、
无任何错误。已把所有 handler 统一为 {status,json}，并加契约测试锁死。
2. 插件把 req.body 当表用 → 实际是 JSON **字符串**，所有平台参数都读不到。
加 bodyOf() 统一解码。
3. 顺带发现工作树里 discover.go 被改成 `return "image"`（非本次改动，像是早先
变异测试留下的），会改变模型类型推断；已还原。
测试：服务端浏览器会话（进程栈/默认拒绝/回调捕获/teardown 清理 profile）、
viewer 反代鉴权、插件 VNC 端到端、channels 插件端到端（含未授权时如实报告
source_error 而非假装成功）、handler 契约。
2026-10-11 14:26:28 +08:00
c3b858d5ba
feat(lua): 多流程登录会话抽象（R4-e）+ 内核权限设置页
...
用户决策：**多流程抽象**（VNC 作逃生舱）+ **单插件多平台**。
## 为什么不是 VNC 为主路径（实测参考插件后的结论）
grep 参考插件（dsh-our-free-model，13 个账号渠道）的源码：
puppeteer / playwright / chromium / headless / vnc / selenium → 0 处
它的登录全部是**把 URL 交给用户自己的浏览器**，插件轮询凭据是否就绪：
loginUrl 113 次 · cookie 133 次 · oauth 43 次 · deviceCode 8 次 · qrcode 7 次。
不以 VNC 为主路径的四条具体理由：
1. Passkey/WebAuthn 基本不可用：凭据绑在用户设备，VNC 里是另一台机器。
2. 无头浏览器更容易被判为机器人 —— 登录场景最不能踩这个。
3. 安全面：llmsproxy 以 root 运行（master.key 0600），systemd 已 ProtectHome=yes。
从 root 服务开 VNC 通道到"即将登录用户各平台账号"的浏览器 = 提权面绑高价值目标。
4. 最关键：VNC 不解决取凭据。登录后凭据活在浏览器 profile 的 cookie 里，
还是要提取 profile —— 那正是最脆弱的一环。轮询流程直接产出 token。
VNC 唯一不可替代的场景（服务端与用户不同网 + 平台要求登录 IP 与调用 IP 一致）
使它作为逃生舱存在：**默认关闭**，需运维显式开启。
## 登录会话抽象（plugin_login.go）
四种流程：link-poll（首选）· callback（复用 Phase 6 自定义挂载）· paste（兜住
cookie 类渠道）· vnc（逃生舱）。内核只管会话生命周期，不含任何平台知识。
- 会话只存**状态**不存凭据：凭据由插件写进自己的保险库，会话里放一个
UI 可见的记录会让 token 有机会被列表接口带出去
- nonce 只在 begin 时给（后续读取剥离），空 nonce 不匹配任何会话
- 读取时判定过期，无后台定时器（没有登录请求时零开销）
- 跨插件读不可行，且与"不存在"不可区分（否则会确认 id 存在）
## 关键阻碍与修法：登录主机不在出站白名单里
**实测确认**：`auth.huaweicloud.com` 被白名单拒绝
（"not an allowed outbound destination (allowed: the hosts of configured sources)"），
整个登录流程无法工作 —— 因为登录主机不是上游源。
修法与内核权限同一姿态：插件在源码 `plugin.auth_hosts` **声明**，运维在设置页
**批准**后才放行。只能批准插件声明过的 host（否则声明只是装饰），逐个批准
不连带（否则一个"登录"理由就能打开整张名单）。
## 设置页
插件表格新增"内核动作"列 + 点击展开的权限面板：动作清单按危险级排序、勾选即
授权、**申请中但未授权会标红**（那通常意味着插件某功能静默失效）。
另加登录主机批准面板（已批准/待批准）。
后端 /api/plugins/{name}/kernel（GET 看 declared vs granted，PUT 改）
与 /api/plugins/{name}/login（列在飞会话，供页面显示"等待你完成登录"+ URL）。
开发中自己引入并修掉一个缺陷：renderPlugins → refreshKernelSummary →
renderPlugins 无限递归；改为只原地 patch 受影响的单元格。
测试 8 个：会话生命周期/跨插件隔离/callback nonce/登录主机门控/只能批准已声明/
过期判定/VNC 需显式开启/未知流程名被拒。node --check 验证内联 JS 可解析。
2026-10-11 13:56:35 +08:00
24e00cdc50
feat(gateway): 插件可注册自定义对外挂载点（R3）
...
用户需求：插件与适配器可以注册对外服务的端口。
现状是插件端点被固定在 /api/plugins/http/ 下。那条限制有三个理由
（可 grep / 可整体撤销 / 不能影子内核路由），放开时必须逐条补回来：
- 命名空间约束：只接受 /plugins/ 与 /v1/plugins/
- 内核路由冲突检测：ValidateCustomMount + FindMountConflict（双向）
- 鉴权默认关闭：沿用 HTTPHandler 的 roles/keys/public 语义
新增 internal/gateway/mount.go：
- ValidateCustomMount：命名空间 + 冲突 + 逃逸校验，错误点名冲突对象
- FindMountConflict：**双向**检测（只查一边会让 /plugins/x 与
/plugins/x/sub 互相静默吞掉）
- BuildRouteTable / RouteOwner：冲突提示点名持有者（"plugin:other"）
- handleCustomMount：**复用** handlePluginHTTP 而不是重写一遍分发 ——
重写会造出两条必须保持一致的分发路径，而只在一处生效的安全规则
比没有更糟
关键防线：TestKernelRoutesAreAllCoveredByReservedPrefixes 从 server.go
刮出路由 switch 的字面量，逐个核对是否被 kernelReservedPrefixes 覆盖 ——
将来新增内核路由却忘记更新保留表时，这条测试会失败。否则新路由会静默
变成可被插件覆盖的。
测试 9 个：命名空间/影子内核路由/保留表同步/双向冲突/冲突点名/挂载解析/
路由表构成/端到端（自定义挂载 200 + /v1/plugins 形式 + 未注册 404 +
无 key 401 或 302）/内核路由不可拦截。
2026-10-11 10:47:17 +08:00
5f6939b590
revert(gateway): 还原 discover.go 的空白重排（非本次改动）
...
我此前对 internal/gateway/ 跑了整目录 gofmt -w，它把 discover.go 里
注释对齐重排了（upstreamModel 的 struct tag 列、copyFields 的行内注释）。
那不是本次任务的改动，且会破坏变异测试 harness 的文本锚点 ——
discover_mutate_test.go 按精确文本做变异注入，锚点对不上就直接判定
"这个变异会是 no-op" 并中止整套 harness。
教训：整目录 gofmt 会在你没打算改的文件上产生 diff。先还原。
2026-10-11 10:16:58 +08:00
e4111337cd
feat(gateway): /v1/messages 端到端 —— 内核不含任何 Anthropic 出站字段名
...
Phase 2 收尾。证明「对外协议由适配器决定、内核只调度」不是纸面主张：
Anthropic 客户端打 /v1/messages，拿到的是 Anthropic 形状。
- internal/gateway/messages.go：入向把 Anthropic 请求解析进统一格式
（content blocks 原样保留——只有适配器知道自己的上游接受哪种块类型；
system 支持字符串与 [{type:text,text}] 两种写法）。
调度/配额/AUTO 链/冷却/审计/插件 hook 全部复用 /v1/chat/completions
的同一条路径（serveUnified），差别只有两端线格式。
- internal/lua/adapters/anthropic.lua：新增 serialize_response /
serialize_open_preamble / serialize_chunk / serialize_close，
把统一格式译回 Anthropic Messages 形状（含 content 分块、
stop_reason 反向映射、input/output_tokens 改名）。
- 流式是 message_start → content_block_delta → message_delta →
message_stop；DoneMarker 为空所以内核**不会**擅自加 [DONE]。
内核出向零 Anthropic 字段名：解析是表驱动的，序列化属于适配器。
测试：
- messages_test.go 5 个端到端用例（真实 core+gateway + 只懂 Anthropic 的
假上游）：形状/stop_reason/块顺序/usage 命名、流式事件序列、入向校验、
鉴权、以及「未声明钩子时回落 OpenAI 兜底」。
- 修正两个 serializer 测试的前提断言（anthropic 现在确实声明了钩子，
这正是 Phase 2 的意图），并发测试改为按适配器各自校验形状。
golden 字节级未漂移；go test -tags luajit ./... 全绿。
2026-10-11 09:51:27 +08:00
93eeba3762
feat(types): 统一格式落地为内核实际使用的类型 —— 私有字段泄漏归零
...
Phase 2 收尾（入向）。ChatRequest 从"客户端发什么就是什么"改为
UnifiedRequest（最大集合）的别名，内核真正用上了那个超集类型。
改掉的具体缺陷：
1. 私有字段泄漏归零（v1 的核心问题）
v1 的 disable_thinking 是内核私有开关，却被序列化进交给适配器的 body，
迫使 10 个适配器各自写 req.disable_thinking = nil 来清理。
现在它是中立的 thinking 字段（{enabled, budget_tokens}），客户端与
适配器都认这个词：
- gateway/chat.go：thinkingFromClient() 把 disable_thinking 翻译成
thinking.enabled=false；冲突时中立字段优先（它能带预算，布尔不能）
- deepseek.lua：thinking.enabled=false → extra_body.thinking.type=disabled
- anthropic.lua：thinking.enabled=true + budget → 原生 {type,budget_tokens}
（enabled=false 时不传该字段——Anthropic 没有 type=disabled 这个写法）
- 其余 7 个适配器：把"清理内核私有字段"改成"清理中立字段"
2. Tools/ToolChoice 改 json.RawMessage
原为 []interface{}（OpenAI 原始形状 = 内核在假设某个协议）。
内核从不解释工具 schema——它原样交给适配器，所以原始形状不损失任何
内核侧统一性。ToolDef 结构化类型保留在包内供新适配器选用。
3. 删除 MarshalJSON 后门
v1 手工 splice ExtraBody 进 OpenAI 形状的 body；现在 ExtraBody 是
UnifiedRequest 上一个正正经经声明的字段。
渐进迁移：ChatRequest 保留为别名（不是新类型），49 处引用零改动编译，
语义变更不被机械改名淹没。
测试：新增 thinking_test.go（翻译链 4 例 + 泄漏回归 + tools 透传）；
vm_test.go 两处迁移到中立语义。golden 字节级未漂移。
2026-10-11 09:35:32 +08:00
9d6653a573
feat(gateway): 对外序列化移交适配器，OpenAI 格式降级为最后容错
...
内核不再硬编码对外 wire。writeChatCompletion / pumpStream 里的 OpenAI
帧拼装抽到 Serializer 接口，适配器可声明钩子完全接管。
优先级契约（用户明确要求：冲突时兜底直接让步）：
适配器声明 serialize_* -> 适配器完全接管
未声明 -> 兜底 openAISerializer
「让步」的含义：适配器接管后内核绝不往其输出补任何 OpenAI 字段。混合体
（半个 Anthropic + 半个 OpenAI）比任何一个单独结果都更难排查——客户端无法
解析，而排查时会指向错误的层。
接口把「流如何结束」也纳入：OpenAI 需 usage 帧 + [DONE]，Anthropic 用
message_stop，Gemini 用空 candidates 帧。DoneMarker 让适配器声明自己的
终止标记，避免擅自给严格客户端加 [DONE]。
新增能力：
- VM.HasFn(name, fn)：不占 worker 探测适配器是否声明某函数
- VM.AdapterRevision(name)：适配器源码每次替换 +1（接着旧值递增）
修掉两个开发中引入的真实缺陷：
1. 锁序倒置自死锁：LoadAdapterSource 里在已持有 v.mu.Lock() 时嵌套
v.mu.RLock() 取 revision，RWMutex 不可重入 -> 整个测试套件静默挂起。
症状是不报错也不超时，只是永不返回；靠 go test -timeout 的 goroutine
栈定位。
2. 缓存键漏掉 VM 维度：serializerCache 原按适配器名做键，导致同进程内两个
VM 共享判定，适配器重写后新钩子永不生效且不报错。键改为
(VM, revision, adapter)，回归测试 TestSerializerCacheIsPerVM。
测试三件套：
- 功能：适配器接管 / 兜底（无适配器）/ 钩子失败退回兜底 / 缓存随改写失效
- 压力：TestSerializerForConcurrent（16 worker × 40 次）
- 回归：golden 字节级未漂移，Phase 0 安全网生效
验证：go test -tags luajit ./... 全绿（gateway 200s / lua 56s）。
2026-10-11 08:57:51 +08:00
6113924655
chore(adapters): 移除非官方调用方式的适配器，保留官方适配器与模板
...
移除 4 个靠伪造客户端身份/绕过 WAF 才能工作的适配器，内核不再发行任何
非官方调用方式：
- opencodezen / opencode / opencodego：靠 x-opencode-* 客户端指纹冒充官方
客户端；zen 免费池明确要求「free tier can only be used in OpenCode」
- agentrouter：伪造 Origin: qwen.ai + Referer + X-Requested-With 绕过阿里云 WAF
保留 12 个官方适配器（openai/deepseek/anthropic/gemini/github/groq/mistral/
ollama/kimicode/qwen38/sensenova/trae），其中 sensenova/qwen38 实测零伪装特征。
本地保留两处：adapters/_local_archive/（gitignored 非递归子目录，不加载）
与线上 /etc/llmsproxy/adapters/（adapter_dir 权威副本，cp -f 不删文件）。
测试同步：删除仅服务于被移除适配器的 11 个测试函数与 usage_cost_test.go；
改写 2 处借 opencode 之名的 provider 测试为用 openai 的 HTML 错误页压缩能力
验证同一契约（适配器钩子拥有错误格式、原文不外泄）。
验证：go test -tags luajit ./... 全绿；二进制内 x-opencode-client /
QwenCode/0.2.0 / qwen.ai 等指纹字符串计数归零。
2026-10-11 08:17:56 +08:00
7836b95a84
fix(gateway): ?key= 传完整 key 会让 /api/stats panic
...
给 usage 插件探路时撞出来的，与插件无关。
Snapshot 的统计 map 以**掩码** key id 为键（keyID(req.Key)）——by_key 返回什么、
面板就传什么。而 exportKey 对 admin 允许 ?key= 任意值，于是：
byKey = map[string]*Stat{key: s.byKey[key]} // 传完整 key → 零值 nil *Stat
...
rows() 里 Stat: *v // 解引用 nil → panic
实测（改动前，线上）：
/api/stats?period=day&limit=1&key=sk-gw-7ffe12c5cbacec40bd39a7291df9a9ed
→ curl: (52) Empty reply from server
→ 日志: http: panic serving …: invalid memory address or nil pointer dereference
llmsproxy/internal/gateway.rows stats.go:771
net/http 会 recover 单个连接所以进程不死，但客户端拿到空响应，日志里每次一条
panic 栈。任何「这个 key 用了多少」的问法（key 已配但当天无流量、period 把它
的历史滤掉了）都会命中 —— 而零正是那个问题的答案，不是错误。
三处防御，因为同一个错误形状有四个入口：
- rows() 跳过 nil 而不是解引用（调用方不止 Snapshot）
- byStatus 的两处遍历同理
- PeriodSnapshot 的 buckets[k] 同理
by_key 仍保留该 key 的一行零值：面板按行存在与否渲染，缺行会让 key 整个消失。
判据：internal/gateway/stats_unknown_key_test.go（5 个测试）。反向验证过——
把 Snapshot 与 rows 的修复撤掉，TestSnapshotUnknownKeyDoesNotPanic 立刻 panic。
(cherry picked from commit af977efbf7
2026-10-07 17:37:22 +08:00
b6d0358079
test(harness): 变异测试拒绝在脏工作区上运行
...
两个变异 harness（Go 版 discover、Python 版 quota）都是「把变异写进源码
文件、跑测试、再还原」。这个形状有两个陷阱，上一轮都真踩到了：
一、脏工作区上的 baseline 是错的
变异被覆盖写入实现文件。如果文件本来就有未提交改动（上一轮被 background
task 超时杀掉、Ctrl-C 中断、编辑器里改了一半），那么:
- 捕获的「原始内容」不是已提交的源码，baseline 跑的是别的东西
- 留下的那个变异会被下一轮当成 baseline
两种情况下所有裁决都毫无意义，而 harness 仍然报出干净的分数 —— 正是
「判据失效」最坏的一种：它不报错。
改为直接拒绝运行（Go 版 t.Fatalf，Python 版退出码 2），并且不自动 checkout：
脚本分不清「残留变异」和「人正在改」，静默回退真实改动比停下来更糟。
二、注入必须原子，还原必须覆盖所有退出路径
Python 版原来用 open(path,"w")，就地截断。与它并发的构建（background
go test、编辑器 gofmt、编译器自己读文件）可能看到写了一半的文件，报
syntax error，然后被当成 COMPILE 静默豁免 —— 一个真实的变异就这样被放过。
改为 tempfile + os.replace。还原登记到 atexit 与 SIGINT/SIGTERM。
三、路径必须相对当前目录
Go 版最初用 cwd=包目录 + 仓根相对路径，git 匹配不到任何东西，守卫永远不
触发。两个 harness 现在都用 ./name，各自在自己目录里跑 git。
两个方向都验证过：干净时全杀（discover 11/11、quota 12/12），脏时拒绝运行。
(cherry picked from commit d01712a697
2026-10-07 17:37:22 +08:00
0e747b0891
fix(ui): 生图与自动探测按钮把对象塞给了 fetch
...
`api()` 是 `(p, o) => fetch(p, o)`，第二个参数是原生 fetch options，
所以 `body` 必须是字符串。两处都传了对象字面量：
- 生图页 `body: { model, prompt, n, size }`
- 源编辑框自动探测 `body: { base_url, api_key }`
fetch 把对象转成 `"[object Object]"`，网关 json.Unmarshal 失败返回
400，请求根本没到上游。生图页的现象是 lat_ms: 0。
两处都改成 JSON.stringify + 显式 Content-Type。
判据在源码层扫描全文件的每个 `method: "POST"`，而不是断言 DOM ——
wire format 在 DOM 里不可见，这也正是为什么之前测过 curl 端点却漏掉
了按钮。这条全文件扫描当场抓到了第二个同源缺陷（自动探测按钮）。
(cherry picked from commit 2fdb82b119
2026-10-07 17:37:22 +08:00
438629256d
feat(ui): 生图二级页面 + 图像模型不再混进对话页
...
## ① 图像模型曾与对话模型不可区分
根因是结构性的，不是漏了个过滤：
Provider.Models() → []string ← 只有 ID，Kind 被丢掉
SourceStatus.Models → []string ← 扁平列表
于是 /api/status 给前端的 34 个模型（29 对话 + 5 图像）长得一模一样。选了
gpt-image-2 就 POST 到 /api/chat —— 那个端点服务不了图像模型，必然失败，
而且报错完全不提「这是图像模型」。
修法：新增 ModelKinds []ModelKindInfo（[{id,kind}]），纯增量、omitempty，
老 UI 不受影响；前端按 optgroup 分组，且这些 option 是 **disabled** 的。
分组还不够 —— 分组只是视觉分隔，operator 照样能选，选了照样失败。
disabled 的 option 会自解释（「请到生图页」），可选的只会失败。
★ 写这段时踩了一次 String.replace 的坑：`imgOpts.join("").replace(...)`
只替换**第一个**匹配，于是 6 个图像模型里只有第 1 个被禁用。浏览器实测
逐条读 e.disabled 才抓到（siliconflow 禁用了、vela 的 5 个没有）。
判据只看 value 里有没有 "image" 的话，第一次跑就会永远报警——那是判据
自己错了，比没判据更糟。
## ② 生图二级页面
侧栏新增 tab，与「对话」并列。网格展示 + 提示词输入 + 数量/尺寸，
调用 /v1/images/generations（不是 /api/chat）。
按钮显示已用秒数：实测该上游 15.7s~112.5s，波动 7.6 倍，不显示进度
看起来就像卡死了。
浏览器实测（几何测量，非仅 DOM 断言）：
tab-image 容器 986×523 visible
img-grid 840×374 visible
提示词输入框 634×64 visible
生图页 6 个模型，全部 kind=image，全部可选
对话页 6 个图像模型，全部 disabled；97 个对话模型全部可选
## ③ base_url 引导不足
文案直接给出截断位置和具体后果，而不是泛泛地说「填 URL」：
填主机地址，通常不带 /v1 —— 网关会自动拼接路径。但各家约定不同：
若填 https://x.com/v1，对话路径会正确，而图像生成会变成 /v1/v1/… 而 404。
不确定就用上方「自动探测模型」。
/v1/v1 不是假设：ImageURL 是 BaseURL + ImageEndpoint()，而图像默认路径
是**绝对**的 /v1/images/generations，chat 的默认是相对的 /chat/completions。
两者对「版本段归谁管」的假设相反。今天在 vela 上为此排查了两次。
## 判据
新增 6 个契约测试：
- 对话页必须读 model_kinds（不读就会退回扁平列表）
- 禁用图像模型不能用 joined-HTML 的 String.replace（只改第一个）
- 生图页存在且注册进 TABS（漏了则 pane 永不可见，症状是「页面空白」）
- sendImage 必须打 /v1/images/generations
- urlHint 必须同时提到 /v1 和 404
- TestImageEndpointComposesUnderRealConditions 用真实形态验证：
相对路径拼出 /v1/images/generations 得 200，默认路径拼出 /v1/v1/… 得 404
2026-10-06 15:02:42 +08:00
a873fe4724
test(discovery): 真实变异注入 11/11，并给 harness 加三道防线
...
前几版 harness 先后报过「4 个变异存活」「11 个一个没跑」「9 个存活」，
查清后**全部是判据或变异本身失效，没有一个是代码问题**。这一版把三类
失效都变成显式失败，而不是静默给出错误结论。
**防线一：先证明 filter 选中了东西**
`go test -run <完全不存在>` **不打印** `[no tests to run]`（那句话只在
「包内有其他匹配项但目标没跑」时出现）。我原先据此写的检查方向是反的，
harness 第一步就自我否决。现在改成对比数字：空 filter 必须选中 0 个测试，
真实 filter 必须选中 >= 25 个。本次运行：32 / 0。
**防线二：编译失败 ≠ 变异被杀**
嵌套调用漏 `-tags luajit` ⇒ 纯 Lua 5.1 ⇒ billing.lua 的 goto 编译失败
⇒ 整包 build failed ⇒ **每个变异都「被杀」，给出满分**。这比假绿更隐蔽。
现在 [build failed] 直接 t.Fatalf。
**防线三：变异没改变行为 ≠ 判据漏放**
两次「存活」查清后都是**恒等变换**：
`&& out.BaseURL != ""` — 判据用零值结构体，BaseURL 为空，条件恒假
`&& len(out.BaseURL) >= 0` — len 恒 >= 0，条件恒真
正确写法是把赋值换成 `_ =`：读了变量让编译器满意，行为真的变了。
检测方式：变异后若结果行（剥掉测试名、排序后）与 baseline 完全一致，
报 no-op 而不是记成存活。
no-op 检测本身也修过：原来保留 === RUN 行（含测试名），两次运行测试顺序
不同 ⇒ 每个变异都「看起来变了行为」，检测形同虚设。
11 个变异覆盖：kind 判定、metadata 透传、非目录拒绝、URL 回退、
版本段搬移（chat 与 image 两条）、版本段识别、nil 切片、鉴权分类、
候选去重。
★ 判据的期望值不写死数字：候选去重修好后 len(cands) 从 3 变 2，
连改两次判据都是在追当前列表。改成断言「该覆盖的 URL 都在」。
2026-10-06 15:02:42 +08:00
31bc3968c5
fix(discovery): 裸 host 也必须有回退候选
...
补 image_endpoint 那一轮的测试暴露了一个覆盖缺口：候选构造是
if !hasVersion { add(raw, "/v1/models", 0) }
else { add(raw, "/models", 0) }
裸 host（https://api.vendor.com）因此只生成**一个**候选，没有任何回退 。
catalog 挂在裸 /models 上的厂商会被报成不可达。
为什么一直没发现：所有测试用的 base 都以 /v1 结尾。生产里唯一已配
kind:image 的 siliconflow（base_url https://api.siliconflow.cn）它的
/v1/models 恰好能应答——**一个能工作的巧合把这个洞盖住了**。
现在两个 catalog 路径无条件都试（偏好只决定「多个都成功时报告哪个」，
不决定「试哪些」）。同时修正优先级：base 已带版本段时第一候选必须是
相对的 /models，否则会先试 …/v1/v1/models——一个必然 404 的 URL，白花
一个来回，还让错误信息以无意义的 URL 开头。
判据同步改了：原本断言 len(cands)==2，那是**在测量当前的列表而不是
覆盖性质**，去重修一次漂一次。现在断言「该覆盖的 URL 都在」
（base+"/v1/models" 与 base+"/models"），实现怎么变都不会漂。
新增 discover_endpoint_test.go：
- 裸 base 不带版本段时 image_endpoint 必须留空，否则会写坏今天正常工作的
siliconflow 配置
- 裸 host + catalog 在 /v1 响应时 endpoint 必须是 /v1/chat/completions
（这正是我第一次把测试期望写反的地方：catalog 路径是上游要不要 /v1 的
唯一证据）
- 两种 base 形态下最终拼出的 chat/image URL 逐字断言，且都不含 /v1/v1
2026-10-06 15:02:42 +08:00
c40b5b5981
fix(discovery): 错误分类 + 去掉重复请求 URL
...
演练错误路径时发现两个真问题。
**① 密钥错误被报成 502（上游故障）。** 这是最常见的失败，却和「厂商挂了」
给出完全相同的错误。两者需要的动作正好相反：重新输 key vs 去查厂商状态页。
操作员只能猜。现在 401/403 会得到 401 并在信息里点名 api key；
DNS 不解析、TLS 失败、连接被拒也各自带一句可执行的说明。
**② 错误信息里的 tried 列表有重复。** base "https://h/v1 " + path "/models"
和 base "https://h " + path "/v1/models" 请求的是同一个地址，但候选去重只按
(base, path) 对，于是同一条 URL 在错误信息里出现两次——读起来像「试了两个
地方」，其实只试了一个。改成按最终 URL 去重。
去重后候选从 3 个变成 2 个，两个判据的期望值需要跟着改：
TestDiscoveryCandidates_DedupesAndPrefersTyped 和变异测试的
「fallback search」原本断言 >= 3，那是在测量 bug 而不是覆盖度。覆盖没有丢失：
剩下的两条是 https://h/v1/models 和 https://h/models，两个不同地址 。
新增判据：
TestDiscoverModels_WrongKeyIsUnauthorizedNotBadGateway
TestDiscoverModels_UnreachableStaysBadGateway（防止过度纠正）
TestDiscoveryCandidates_NoDuplicateRequests
TestDiscoverModels_FailureListsEachURLOnce（对操作员真正读到的文本断言）
2026-10-06 15:02:42 +08:00
7ce0378e8b
docs(discovery): 用实测数据替换注释里的猜测
...
composeImageEndpoint 原注释写着「两种形式都 404，无法区分」，那是我写代码时
的推测，不是观测。后来真实打了一次上游就分清了：
/v1/images/generations → 200（图像生成本身要几分钟，是上游耗时）
/v1/v1/images/generations → 404
/images/generations → 404
注释里的假话比没有注释更糟——下一个人会拿它当「已知的模糊地带」而不敢
收紧判据。
2026-10-06 15:02:42 +08:00
ae9f56ddb3
fix(gateway): 探测同时算出 image_endpoint，修 /v1/v1 404
...
上一版只算了 endpoint，图像生成仍然 404。根因是网关两条拼接路径的默认值
规则相反：
ChatURL = BaseURL + Endpoint() 默认 "/chat/completions" 相对
ImageURL = BaseURL + ImageEndpoint() 默认 "/v1/images/generations" 绝对
base_url 带 /v1 时 chat 拼成 /v1/chat/completions 正常，image 拼成
/v1/v1/images/generations 就 404。之前归一化 base_url 时修正了版本段的位置，
但没意识到图像这条路径的默认值自带 /v1，它跟 base 是各管一段。
探测现在额外返回 image_endpoint：base 末尾有版本段时给
/images/generations，否则留空用默认值。判据是 TestComposeImageEndpoint ——
它断言 base+结果绝不含 /v1/v1，这是那个 404 的字面形态。
apply 的继承逻辑相应改了：image_endpoint 不再从旧源继承。旧值是对旧
base_url 正确的，而 base_url 恰恰是这次可能变的东西，沿用它会留下一个对着
新 base 404 的陈旧值。前端 srcDiscover() 同步写入该字段。
端到端（隔离实例 18099，真实 amr-link 上游）：
探测 http 200，1.4s，29 chat + 5 image
apply http 200，落库 34 个模型
文本 http 200，2.0s
视觉 http 200，1.5s
图像 路径修正为 /v1/images/generations（不再 404；上游本身 120s 超时，
属其自身耗时，非路由问题）
探测对已存在的源返回 409 要求显式 replace_models=true，这个保护在验证中
确实生效了。
2026-10-06 15:02:42 +08:00
3860c7381f
feat(gateway): 源自动探测模型列表
...
只需填 URL 和 key 即可自动扫描上游模型并配置，不用再手抄模型 id。
端点
POST /api/sources/discover 只探测，不写任何东西
POST /api/sources/discover/apply 探测后落库
核心难点是 URL 形态而不是 /models 调用本身。网关按 base_url + adapter
endpoint 拼路径（openai 提供 "/chat/completions"），而各家厂商对版本段
放在 base 还是 path 上没有共识，也没有哪个响应头能说明。所以探测不信任
调用方给的 URL，而是按偏好顺序试若干候选，返回答的那个，并给出归一化
后的 base_url + endpoint 组合。这正是第一次配 vela 时 /v1/images/
generations 返回 404 的成因：base_url 里已有 /v1，默认图像路径再拼一次。
归一化的不变量是「版本段在 base_url + endpoint 里恰好出现一次」。留在两边
会重复；两边都没有则 chat 请求在要求版本段的厂商上会打错路径。
kind 只信上游自己声明的 modality，绝不从模型名猜。"gpt-image-2" 这类
id 也出现在同时提供对话服务的目录上，猜错会让 AUTO 链选中一个只支持图像
生成的 id，其后每一层都被它拖垮。
不做的事：
- 不逐模型发单 token 探活。34 个模型的目录跑一轮要花钱且耗时数分钟，
/models 是足够便宜的信号；模型是否真能应答留给正常请求路径。
- 不猜能力。「vision」出现在 id 里不等于该模型接受图片。
- 不自动写盘。探测只读，保存仍需操作员按按钮——错误的 base_url 会产出
一个看起来合理却无法使用的源。
已存在的源必须显式 replace_models=true 才会覆盖模型列表：重新探测顺手
抹掉为 AUTO 链手工调过的 priority 是最难排查的一类数据丢失。
测试用真实抓取的 amr-link /models 响应做夹具，它把 modality 嵌在
architecture 下、metadata 下还有 cost/context_limit，34 个模型里混着 5 个
图像生成 id——朴素解析器正好在这三处出错。
变异测试 9/9 全杀（TestRealMutants，baseline 43 个测试）。过程中发现并
修掉四个真缺陷：嵌套 metadata 丢失、null 被当空目录、候选盲目拼接出
/v1/v1、以及 discoveryResult 零值序列化成 null 会让前端渲染出
"undefined"。早先的 shell 版变异脚本因 -run 转义损坏报出 4 个"存活"，
实际是零个测试被执行——判据分不清"通过"和"没跑"就不是判据。
2026-10-06 15:02:42 +08:00
94c1e7688f
fix(gateway): 流式请求从未记录 reasoning_tokens
...
## 症状
接了一个 reasoning-heavy 的源之后，读生产审计文件发现：它的**流式**请求全部
只有 completion、没有 reasoning。实测对照：
流式 compl=8166 reasoning=— ← 网关记的
非流式 compl=751 reasoning=167 ← 同一个 adapter，非流式正常
客户端两种情况的响应都正确，所以**没有任何报错**。只有审计记录更安静。
## 根因
两条记账路径，只有一条读了它：
recordChatUsage(非流式) 读 resp.TokenUsage.CompletionTokensDetails
流式的 usage 合并(内联在 handler) 只读 Prompt 和 Completion
cache 记账当时被镜像过去了，**reasoning 单纯没加**。所以一个花了几百 token
思考的模型，在流式下看起来像什么都没想。
这不是 qwen38 的问题 —— 是任何流式 reasoning 模型的问题，之前没有源暴露它。
## 为什么是「读审计文件」发现的，而不是失败的测试
现有判据 `TestRecordChatUsageKeepsReasoningTokens` 只覆盖非流式那条路径。
流式那段内联在 handler 里，测不到。抽出 `applyStreamUsageDetails` 之后
才有地方挂判据 —— 抽取不是为了好看，是因为不抽就没法测。
## 判据（四条）
- 流式记录 reasoning，且精确值（512）
- **reasoning 绝不被加进 completion** —— 关系式断言，不是「字段存在」检查。
写成 `rec.Compl += reasoning` 会让每个思考 token 被收两次费。
- 上游没报 reasoning 时不写字段（0 在审计里表示「未上报」，与「没思考」不同）
- cache 记账未被顺带破坏 —— 三种输入形态各测一遍
变异自证三次变红：删掉 reasoning、加到 completion 上、破坏 cache 块。
第四次变异（`d.ReasoningTokens > 0` 改成无条件赋值）没变红 —— 那一版与原版
**行为完全相同**：rec.Reasoning 初值就是 0，且 json tag 带 omitempty，两种情况下
客户端都看不到这个字段。这是无行为差异的变异，不是判据漏放。
## 生产实测
部署前（13 条）：compl=204/277/1822/1264/740/… reasoning 全部未记录
部署后（ 1 条）：compl=213 reasoning=42 status=200
Co-Authored-By: ModelRouter <noreply@modelrouter.dev >
2026-10-06 15:02:42 +08:00
33b778faee
feat(plugins): 分片调用 —— 让阻塞型导出函数真正并行
...
## 问题
quota 页面 20 个源，刷新要 29 秒。页面用 `Promise.all` 并发发 20 个请求，
**看起来是并发的，实际不是**。
`Plugins.Call` 持 `p.mu.Lock()`，锁一直持有到 `L.Call` 返回 —— **包含 Lua 函数
内部的全部网络等待**。20 个请求到了网关后排队，串行累加。
生产实测：
单源探测（无竞争） 1.4 – 3.3 s
20 源 Promise.all 29 s 墙钟
串行理论值 ≈ 29 s ← 与实测吻合
代码里其实已经知道这个问题：quota.lua 第 104 行写着「the whole page shares ONE
Lua state under a write lock」，并为此把超时从 10s 压到 4s。但那只把 29s 变成
约 12s，没有解决「刷新不可用」。
而当初改成并发的理由（页面注释）是错的 —— 它假设并发能绕开串行。锁让它退化
回串行了。
## 不能去掉锁
一个 Lua VM 只有一个栈。两个并发调用会破坏栈。锁是必要的，答案只能是**让每个
并发调用有自己的 VM，跑同一份插件源码**。
先量，再写实现（8 分片 × 300ms 本地 HTTP 端点）：
共享 VM，8 次串行 2.407 s
8 个独立 VM 并行 0.304 s → 7.9x
顺带一个测量教训：这个 spike 第一版用**忙等**而不是网络 I/O，报出 2.3x。
那是量到了 12 核机器上的 CPU 争抢（负载 8.95），和锁无关。插件做的是网络等待，
spike 就必须做网络等待 —— 和上一条提交里 os.clock 那个错误是同一类。
## 实现
- `callOn(w, fn, args)`：从 `Call` 里抽出的「在某 VM 上调一个导出函数」。`Call`
从 66 行缩到 18 行，仍负责查找、export 白名单和共享 VM 的锁。
- `shardPool`：私有 VM 池，上限 32。开机约 0.1ms，池化省不了什么但省两次刷新
的重复开销。
- `ShardCall(name, fn, argsList)`：结果与输入**按位置对齐**。
- `POST /api/plugins/{name}/fanout/{fn}`：`{"args": [...]}`，上限 64 条。
- `pluginAPI.fanout()`：页面一次请求。
- quota.lua 改用 fanout。
## 分片的硬约束（写进注释，不是靠约定）
分片 VM **不能碰 PLUGIN.state** —— state 在 VM 里，每个分片一份副本，billing
的累加会各分叉，saver 写出去的是随机某一份。分片只能用于只读、幂等的工作。
所以 `callOn` 既不查 export 白名单（`Call` 那层才是安全边界）也不落盘。
## 一个分片失败不拖垮整批
一个上游连不上，不该让 20 张卡片变成一个错误。失败的分片在自己的位置留
null，其余照常返回。**但全部分片失败时报错** —— 那不是「某个上游挂了」，
是结构性问题，报成功会把它藏在满屏红卡片后面。
## 顺手修掉一个既有缺陷：热重载是坏的
写分片源码来源时，判据直接把它顶了出来：`LoadSource` 无条件 append，而
`findLocked` 返回**第一个**匹配。实测：
LoadDir 后 1 条 → LoadSource 后 2 条
[0] version=1 [1] version=2
find 返回 version=1
也就是说，**编辑插件并保存看起来什么都没发生** —— 旧版本一直被返回，新版本
躺在旁边不生效。修法是先 Unload 再加载。这不是为分片做的，是分片正好照到了
这条路径，已单独补判据 `TestReloadReplacesRatherThanAppends`。
## 判据
七条：并行性（有界而非计时断言，8×200ms 串行是 1.6s，超过 1.0s 即红）、
位置对齐、未导出与未知插件被拒、单个失败不拖批、全失败报错、用已安装源码而
非磁盘、以及热重载替换而非追加。
全量 9 包通过。
Co-Authored-By: ModelRouter <noreply@modelrouter.dev >
2026-10-05 08:17:57 +08:00
d119d09929
feat(billing): 记录 reasoning token，并支持按规则单独定价（默认不启用）
...
## 断掉的链路
types.go 里 ReasoningTokens 从被定义起就没人读过。适配器层早就解析并透传了
（opencodego / gemini / anthropic 都写了那段提取），网关在 chat.go 记录 usage
时读了 PromptTokensDetails.CachedTokens，却在隔壁的
CompletionTokensDetails.ReasoningTokens 上把它丢了 —— 数字到了响应里，
在唯一能留住它的地方被扔掉。
后果：任何计费规则都无法区分「思考」和「可见输出」。
## 为什么默认不启用定价
实测四个源（deepseek-v4.1-flash / claude-opus-4-8 / glm-5.3-flash /
space-bunny-free，含 anthropic thinking opt-in）全部不返回该字段。所以
reasoning_price 默认为 nil，costFor 完全跳过该分支，标准公式与改动前逐位相同
—— 这是关键：现有账单不能因为这次改动而变动。
启用时只应用「差额」：把思考部分从普通输出价重定价到思考价。完整再收一次会
对每个思考 token 双重计费，这正是判据里最容易被写出的错误实现。
clamp 到 completion_tokens：供应商报出比 completion 还大的 reasoning 是畸形
数据，不 clamp 会得到 92 倍于整个请求的费用，而且这个数字看起来足够合理，
能在仪表盘上活下来。
判据三条 + 三次变异自证（移除 clamp / 双重计费 / 默认启用）全部变红。
## 遗留
reasoning_price 未接入 BillingRule DSL —— 目前只能通过直接写 prices 生效。
DSL 字段要连带改 config 结构、编译器和规则编辑器 UI，是独立一步。
实测全部源都不返回该字段，所以这条暂时没有实际影响面。
Co-Authored-By: ModelRouter <noreply@modelrouter.dev >
(cherry picked from commit c36200b78b
2026-10-04 14:50:47 +08:00
ba10f03fc7
feat(plugins): 访问控制在插件页配置 + 修复 active 仪表在周期视图显示 0
...
## 插件管理页（用户要求：权限不要只放 config.yaml）
插件页新增两列（可见性、端点）和一块访问控制编辑器，可直接改：
- 每个插件的整体可见性（跟随插件 / 仅 admin / 仅 user / admin+user / 所有人）
- 每个注册端点的可访问角色与密钥（admin, user, @homeagent, public）
原先这些能力后端齐全但 WebUI 零入口，唯一改法是手改 config.yaml。
## 修掉的三个真缺陷
1. endpointAccess 读错了 override 的键
SetEndpointAccess 按 plugin#path 存，endpointAccess 却读 plugin 级。
后果：改了权限后 UI 仍显示插件声明的角色，再保存一次就把限制悄悄撤销。
鉴权一直是对的，只有显示和往返是坏的 —— 所以之前没被发现。
2. override 只在内存里
内存 map 让"billing 仅 admin"看着生效，直到下次重启限制凭空消失，
日志里没有任何线索。现在落盘到 plugin_dir/.access.json，
插件升级覆盖 .state.json 也不会连带放宽访问。删掉最后一个 override 就删文件，
"没有覆盖"用文件不存在来诚实表达。
3. 可见性列表泄漏内部键
端点 override 与插件可见性共用一个 map，UI 因此会看到 "probe#hello"
并可能把它当 audience 存回去。现在按已注册端点集合过滤。
另外把整体可见性接到同一条 /access 通路（path 用 *），并修了可见性下拉的
集合比较：服务端原样存 "admin, user"，而选项是 "user,admin"，不相等就会
显示"跟随插件"，用户一保存就把访问范围放宽回插件声明 —— 比显示错更糟。
## 活跃请求：三个视图显示 0
active 是实时仪表，没有日历周期可过滤，但周期响应压根没带这个字段。
前端 `st.active || 0` 于是把"字段缺失"变成了一句自信的"0 活跃"，
而 all 视图（响应里有该字段）显示真值 —— 三个视图 0、总视图正常。
现在周期响应带上 active，前端去掉 || 0 回退：缺失显示 — 而不是假装是 0。
判据：四个 period 都断言 active 存在且为数字；变异去掉字段即变红。
生产实测 day/week/month/all 均为 4。
Co-Authored-By: ModelRouter <noreply@modelrouter.dev >
(cherry picked from commit 120ba9e9573b28fde22e
2026-10-04 14:50:46 +08:00
35b9422232
feat(plugins): 可见性、state 分区、注册式 HTTP 端点 + 按密钥授权
...
插件页面不是自动公开的数据。billing 显示跨全部源的成本，quota 显示上游余额，
而这两者都不属于持有 user 密钥的人 —— 但 /api/ui-inject 不做任何角色过滤，
所以两者都发给了任何已认证的密钥。实测（不是推断）：club 这把 user 密钥拉到了
18672 字节的 billing state，里面是 16871 次请求 / $8.8616 / 21 个源名与各自
成本。
UIPage/UIElement 加 Audience，UIExtension 加 Visibility。语法刻意很小——"" 或
"all" 放行，"admin" 只给 admin，"admin,user" 列角色。**"*" 不是 all 的同义词**：
一个在配置文件里看起来受限、实际放行一切的东西，正是会静默失效的那种设置。
覆盖走 config.yaml 的 plugin_visibility，因为插件作者不知道本部署的策略，而运维
也不该为了改一行去编辑内置 .lua（下次升级就没了）。
过滤发生在 UIForRole 而非 HTTP 层：WebUI 启动载荷、Electron 外壳、测试都读同一
处，只在 HTTP 层过滤意味着其它消费者照旧全量泄漏。
角色可见性回答不了"哪一部分"。billing 里全局数字（total、by_source、by_model、
未定价告警）是部署数据，by_key / by_day_key 描述的是**一个**调用方。于是插件用
state_scope 声明哪些桶是全局的、哪些按调用方过滤，深度由插件给出（1 = {maskedKey:
桶}，2 = {day: {maskedKey: 桶}}）——两种形状都是 map，靠嗅探分不清"空桶"和"嵌套桶"。
不匹配的行**删除而不是置零**：置零会渲染成"你没花钱"，还会泄露"别人有这一行"。
billing 因此改为 visibility="all" + state_scope，而不是 admin-only —— 后者会让
split 失去意义，而前者不加 split 正是这次要堵的泄露。
有些东西值得从浏览器**外面**查（CI 判断上游余额是否为零、监控探针、盒子上的
另一个工具）。billing 从不需要（它只收 hook），quota 需要。为每个插件硬编码一条
路由意味着每次都要改网关，而把任意插件代码塞进主 mux 也不是路由表该做的事。
插件在 plugin.http 里声明 path/method/roles/keys，挂在 /api/plugins/http/ 下。
请求与响应都是普通 table 穿过 Go/Lua 边界。两条由 Go 侧而非信任插件来保证的性质：
status 与 method 走白名单（否则插件能选一个 3xx + Location 把调用者弹到它指定的
URL），Content-Length 与逐跳头被丢弃（否则插件能让网关的响应分帧错位）。
roles 太粗：无法表达"给 homeagent 开放、其他人不开"。keys 按**密钥名**授权而非密钥
值——密钥值会被轮换，规则写死在上面会静默失配；把凭据散进插件文件也是问题；而且
运维读的是名字。
**keys 非空时它是全部规则**，不是与 roles 的并集。写成并集的话，运维写两条允许名单
就会顺带放行所有 user 密钥，正好与意图相反。admin 永远放行，否则名单里一个拼写
错误会让唯一能诊断它的人也进不去。
写入前校验密钥名真实存在：一份写着错别字名字的名单会被存下、保存、在 WebUI 里
显示为"已配置"，然后拒绝每一个调用者——失败看起来像端点坏了，而不是名字错了。
readPluginUI / readPluginExports / readPluginHTTP 都在插件**注册期间**调用
luaToJSON，而它依赖 setupGlobals 才安装的 json 全局，于是静默返回空值。三处表现各
不同（页面字段为空、exports 看不见、端点数为 0），同一个原因。现在统一走
luaTableToGoValue。
readPluginHTTP 还额外踩了 golua 的 GetField 不做字符串→数字转换，用索引循环取数组
永远拿到 nil。
去掉角色过滤 → 3 条判据红（含"a user key can see the admin-only page"）；
去掉 page 级 audience → 1 条红。routes 层断言徽标齐全、方法与 path 校验、栈帧
归属、admin 豁免、{status=204} 合法、空表报错。
生产验证：admin 看到 14 个字段 / by_key 5 行 / total $8.86；user 看到 0 行。
Co-Authored-By: ModelRouter <noreply@modelrouter.dev >
(cherry picked from commit a6c6e6e5c75eef5ad635
2026-10-04 14:50:46 +08:00
85c81c63cc
feat(plugins): ccquota 多账户额度插件 + 页面→Lua 调用通道
...
A quota plugin cannot work on billing's model. Billing reports what the gateway
already measured, delivered on hooks during request forwarding. A plan balance
has no such arrival path: it exists only on the vendor's side, and the only way
to learn it is to ask — at the moment the operator clicks Refresh. No hook fires
on a click, and pluginAPI offered only state read/write.
So this adds the missing piece: POST /api/plugins/{name}/call/{fn}, plus
pluginAPI.call on the page side.
## Why the gate is an explicit export list
That endpoint is an HTTP surface into a Lua state. Without a declared allowlist
it would let any caller invoke the plugin's private helpers with crafted
arguments and read whatever it can see — for a plugin holding an API key, that
is handing the key to anyone who can POST. So a function is callable only if the
plugin listed it in plugin.exports. A plugin with no exports has no callable
surface; reading the missing list as "allow all" is exactly the failure mode
worth designing against. The endpoint is also admin-only.
## ccquota
One account per configured source on api.commandcode.ai, keyed by that source's
own key — two keys on one host are two seats, and both are shown. Reads
/alpha/whoami, /alpha/billing/credits, /alpha/billing/subscriptions and
/alpha/usage/summary. Each endpoint degrades independently: a vendor retiring
one route must not blank the others, and a key out of quota still reads credits
fine while inference 401s, so the report records WHICH part failed rather than
rendering a zero that reads as "no quota left".
The 401-is-everything trap: those endpoints need a bearer token plus three
headers. The token lives in the table now, per request. Passing the shared
header table straight through — my first version — yields 401 on every
endpoint, which is indistinguishable from a revoked key and sent me auditing the
account instead of the plugin.
## Also fixed: three real defects found by going live
- The bridge was registered as `httpGlobal` (the Go const's IDENTIFIER) instead
of `__llmsproxy_http` (its VALUE). Green unit tests, "attempt to call global
'__llmsproxy_http' (a nil value)" on first real request. Now a test boots a
real plugin and calls it the way a plugin does.
- The call router kept `call/` in the function name, so every call 502'd with
`does not export "call/collect_account"` while the exports list looked fine.
- readPluginExports used luaToJSON, which needs the `json` global — not yet
installed while a plugin is registering — so it silently returned an empty
list and every export looked undeclared. It uses luaTableToGoValue now.
Two tests hardcoded counts ("1 bundled plugin", "4 pages") and turned red the
moment a second bundled plugin existed. They now assert what they mean: billing
is among the bundled plugins, and the pages this test contributed all merged in
order. A count assertion is a changelog detector.
## Verified on production
commandcode 2198972886@qq.com active $0.0811 5h 0/14 wk 0.803/35 44,921 req
commmandcode2 jianf3112@gmail.com active $0.0700 5h 0/14 wk 0/35 43,827 req
Co-Authored-By: ModelRouter <noreply@modelrouter.dev >
(cherry picked from commit 111dc6d53f22c9215b02
2026-10-04 14:50:46 +08:00
0bf0653d00
fix(ui): 优先级页的保存/重置/添加按钮每次打开都被画布渲染冲掉
...
renderSortEditor 会整体替换 mount 的 innerHTML。per-key AUTO 弹窗的 mount
只有画布，覆写无害；但全局优先级页把 .card（连同里面装着工具栏的 h2）当
mount 传了进去，于是每次打开页面，画布一渲染就把工具栏删了。
症状很隐蔽：泳道和积木照常渲染、拖拽也正常，只是「保存排序」「重置」
「+ 添加档位」和聊天/生图切换全部消失 —— 优先级变得无从调整，也无从保存。
DOM 里数画布元素一切正常，只有量按钮的几何尺寸才看得见它没了。
修法：工具栏留在 .card 里，另给一个 #sort-mount 专供画布。per-key 弹窗
本来就是这个结构，无需改动。
判据 1 条，断言工具栏必须落在 #sort-mount 之外，且 renderSortEditor 必须
接收 #sort-mount 而不是 .card。变异（mount 改回 .card）判红。
生产 CDP 实测（真实点击，非仅 DOM 断言）：
5 个按钮全部可见，坐标尺寸正常（保存排序 72x29）
画布 4 泳道 / 10 块
点击「保存排序」→ toast「排序已保存并热重载 · 链上冷却已复位」
切走再回来，按钮仍在位
Co-Authored-By: ModelRouter <noreply@modelrouter.dev >
2026-10-04 07:05:36 +08:00
48e7e6b2a5
fix(gateway): AUTO 范围冲突的提示要放在 checkQuota，否则是死代码
...
上一版把消息加在请求路径的范围检查上，实测才发现它永远走不到：
AUTO 请求先经过 checkQuota(ctx, "AUTO")（在链被读取之前），范围不含 AUTO
时它当场返回旧文案「model \"AUTO\" is not allowed for this key」——那句会
把运维引去查配额，而配额并不是原因。
改为在 checkQuota 内对 AUTO 分流，输出说明真实原因与修法。请求路径那处
换成注释说明为何不再重复。
判据 1 条，断言 checkQuota 函数体内必须同时出现 isAuto(model) 与新文案
——放在别处不算数。变异（删掉该分支）导致编译失败，被捕获。
生产实测（临时把某密钥范围改成不含 AUTO 再恢复）：
HTTP 403 model_not_allowed
model \"AUTO\" is not in this key's model scope, so it cannot use AUTO;
add \"AUTO\" to the key's models or remove the scope restriction
Co-Authored-By: ModelRouter <noreply@modelrouter.dev >
2026-10-03 23:06:42 +08:00
cf14f66ad4
fix(gateway): AUTO 被密钥模型范围拦下时报错误导 + 编辑器给出提示
...
一个密钥的模型范围不含 AUTO 时，它用不了 AUTO —— 范围过滤发生在链之前。
但这两条路径都不说真话：
1. 请求侧：AUTO 走的是通用分支，返回 model_not_found "model \"AUTO\" is
not configured"，读起来像 AUTO 没配置。非 AUTO 模型早就有 model_not_allowed
的专门提示，AUTO 漏了。补上，并说明修法（把 AUTO 加进该密钥的 models，
或去掉范围限制）。
2. 编辑器侧：per-key AUTO 链编辑器可以正常配链、保存也成功，看起来一切正常，
但该密钥的每个请求都会 403。管理员无从得知。现在弹窗顶部在检测到冲突时
显示警告，并列出当前范围。
刻意不做的事：不自动把 AUTO 加进该密钥的模型范围。那等于悄悄授予运营
没要求的访问权，比一个显眼的警告更糟。
判据 1 条，除确认提示出现外还断言该函数体内没有 PUT/POST/fetch/api ——
它只报告，不得写回。变异（去掉 AUTO 判断）判红。
CDP 实测四种场景：范围含 AUTO → 无提示；范围不含 → 警告并列出范围；
空范围（不受限）→ 无提示；范围含 AUTO → 无提示。
Co-Authored-By: ModelRouter <noreply@modelrouter.dev >
2026-10-03 21:23:02 +08:00
130b3f2e8d
feat(ui): per-key AUTO 链默认复制全局链作为编辑起点
...
此前给没有独立链的密钥打开编辑器是空白画布，管理员要从 226 个模型里
一条条重新挑。真实任务是"这个用户拿全局链，但去掉他不该碰的两个源"，
所以起点应该是全局链本身。
- 无独立链时读 /api/auto 的 rules 预填（实测 4 泳道 / 10 块，与全局链
一致），不是 discovery 兜底（那会把每个源的每个模型都堆进来）。
- 提示区分三种状态，因为它们在画布上长得一样、点取消的后果完全不同：
复制来的起点 / 该密钥已有的独立链 / 清空后保存将恢复跟随全局。
- seeded 标记随关闭清理，避免下次的提示说错来源。
CDP 实测：打开无独立链的密钥 → 画布 4 泳道 10 块 + 提示"已复制全局链
作为编辑起点"；删一个块服务端仍 inherits:true；保存后 inherits:false
n=9、弹窗关闭；重开读回 4 泳道 9 块且提示消失（它现在有自己的链了）。
横向滚动可达性一并验证：scrollLeft 172 = scrollWidth-clientWidth，
滚到底后无残留不可达块。
判据 2 条 + 变异（恢复空白起点 / 去掉 seeded 标记均判红）。
Co-Authored-By: ModelRouter <noreply@modelrouter.dev >
2026-10-03 13:36:11 +08:00
dac0b4ce93
fix(ui): 统计区间文案在日视图恒为空、天数按小时桶误报
...
v1.9.0 加的「统计区间：起 → 止 (Nd)」正是用来解释"周 > 月"的，但它自己
在日视图上从来不出现在屏幕上。
原因：区间终点从最后一个 bucket 的标签拼出来，而 bucket 粒度随视图变化
—— 日视图按小时（"2026-10-03T09"），周/月按天（"2026-10-01"）。代码无条件
拼 "T00:00:00Z"，日视图就成了 "2026-10-03T09T00:00:00Z"，Date 拒绝该值，
toISOString() 抛 RangeError，整个赋值语句丢失。页面无任何报错，只是那行
字不见了——恰好是用户最常看的"今日"视图。
第二个问题同源：天数直接用了 st.buckets.length。日视图 5 个桶是 5 个小时，
界面却显示 "(5d)"。改为按窗口起止算天数。
CDP 实测（修复后）：
day 统计区间： 2026-10-03 → 2026-10-03 (1d) ← 原为空，且曾误报 5d
week 统计区间： 2026-09-28 → 2026-10-03 (6d)
month 统计区间： 2026-10-01 → 2026-10-03 (3d)
all （空，正确：终身累计没有窗口）
判据一条 + 变异：恢复原来的盲目拼接 → 判红。
Co-Authored-By: ModelRouter <noreply@modelrouter.dev >
2026-10-03 13:36:11 +08:00
f9cd0770a9
fix(ui): per-key 弹窗复用共享弹窗ID、编辑即落盘、空画布显示226个模型
...
截图看渲染 + 交互实测后发现的四个问题，都出在我自己新写的代码里。
一、弹窗用了全站共享的 #modal-wrap。
这个 id 是 App 内所有弹窗共用的，且允许多个同时存在（"添加档位"选择器就
开在本弹窗之上）。既有代码靠 .closest() 或 closeTopModal() 从按钮往上找，
是有效的——但本弹窗还要从画布侧被查（sortCanvasEl / keyAutoClose /
keyAutoInherit），那里没有按钮可走。实测点"添加档位"后 DOM 里同时有
modal-wrap=1 和 key-auto-modal=1，getElementById 会命中文档里的第一个，
也就是用户没在看的那一个：取消关掉错误的框，画布也可能解析到选择器上。
改为独立 id #key-auto-modal。
二、编辑即落盘，保存/取消形同虚设。
scrAddFromForm / sortScopeSave / scrDelSlot 等 6 处编辑后立刻调
persistAuto()。全局页这样是有意的（改动立即生效），但它和自己页面上那句
"点击保存排序后生效"的提示自相矛盾；在 per-key 弹窗里更严重——加一个槽位
就已经写进那个用户的链了，取消也无法撤销。收敛到 afterChainEdit()：
有 scope 时只提示、不落盘，保存是唯一写入口。
三、无独立链时画布显示全部 226 个模型。
注释写的是"显示空画布"，实现却是 buildLanes(idx, [], 'chat')——空 rules
会走 discovery 兜底，把每个源的模型全填进去。用户打开弹窗看到 226 个色块，
会以为这些就是这个密钥的链。改为空 rules 直接给 []。
四、"使用全局链"提示不随画布变化。
加完槽位后仍显示"该密钥使用全局 AUTO 链"，与旁边的色块直接矛盾。改为由
afterChainEdit 触发、按画布是否有内容决定去留。
另：批量替换时正则的缩进假设错了一次，把 afterChainEdit 自己改成了自调用
（无限递归），node --check 抓到后修掉。这类批量替换必须先过语法检查。
判据两条 + 变异：弹窗回到共享 id → 判红；去掉 scope 分支 → 判红。
CDP 实测：弹窗 id 唯一、添加后画布 0→1 块、添加后服务端 inherits=true
（未落盘）、取消后仍 inherits=true、选择器与弹窗并存互不干扰。
Co-Authored-By: ModelRouter <noreply@modelrouter.dev >
2026-10-03 11:20:29 +08:00
6311913812
fix(stats): 日/周/月视图请求记录表空白，滚动加载顺序错乱
...
首页记录表由 paintRecords(st.records) 渲染，而 /api/stats 的 period 分支
手写了一份响应 map，压根没有 records 字段 —— 只有 all 分支走 Snapshot()
才带得上。实测切到日/周/月，记录表恒为空。
两处数据源也不一致：
| 端点 | 数据源 | 排序 |
|---|---|---|
| /api/stats（all）| 内存ring（几百条）| oldest-first |
| /api/stats/records（翻页）| 审计文件（全部）| newest-first |
| /api/stats（period）| 无 | 无 |
前端靠 paintRecords 里一句 .reverse() 把 all 的 oldest-first 转成 newest-first，
翻页端点则本来就是 newest-first。首屏和翻页方向相反，滚动时新旧行会错位
拼接；且 all 分支不带 next_cursor，表永远停在第一屏。
修法：两个分支都改用 AuditPage（与翻页端点同一份代码路径），记录方向统一
由它决定，前端去掉 .reverse()。附带好处：记录深度不再受 maxRecs 限制，
"全部"视图真的能翻到底。
判据三条，变异验证：period 分支返回 nil records → 前两条判红；all 分支不
覆盖 records → "no next_cursor"判红。变异过程中我自己也犯了两次错：第一版
判据硬编码 newest-first，而AuditPage 在单文件（整块读完）与多文件（分块反向
读）下方向不同，改为断言两处方向一致；第三版想测 admin 过滤，但
newTestGateway 的 sk-test 不是 admin，改为测真正的越权边界（非admin 不能
用 ?key= 看别人的记录）。
CDP 实测：四个视图各 100 行、时间从新到旧，滚动加载 100→200 行且新末行
时间更旧（顺序衔接正确）。
Co-Authored-By: ModelRouter <noreply@modelrouter.dev >
2026-10-03 10:32:51 +08:00
aa003e84d3
fix(ui): per-key 编辑器画布画错容器、保存成功却不关弹窗
...
CDP 实测发现两个真 bug，都是复用画布时引入的。
一、画布画进了后台标签页。sortCanvasEl() 原本按文档顺序找，先命中
#scr-canvas（全局优先级页的画布）。而弹窗是挂在设置页之上的，两个画布
同时存在于 DOM —— 于是 per-key 的 36 条泳道被画进隐藏的全局画布，弹窗
里空空如也，回���全局页还会发现自己的链被覆盖了。
改为按 sortState.scope 解析：有 scope 就用 #key-auto-canvas，否则用
#scr-canvas。
二、保存成功却弹窗不关。!j.slots 分支里我写了 return，跳过了
keyAutoClose。写确实成功了（服务端已存），但用户看到弹窗还开着、按钮
还是禁用状态，会反复点保存。而且那条 toast 文案写成"保存后 AUTO 请求
会失败"，读起来像保存失败了 —— 一并改成"已保存，但槽位无法解析…"。
判据两条，变异验证：恢复按文档顺序查找 → 第一条判红；!slots 分支加
return → 第二条判红。第二条最初只查 keyAutoClose() 是否存在，变异加了
return 仍然通过，属于判据漏放，已改为扫描 try 块内 close 调用之前的
所有 return 语句。
CDP 复测（先开全局页制造干扰，再开 per-key 弹窗）：
- 弹窗画布 36 泳道，全局画布保持 4 泳道未被污染
- 保存 gpt-5.2@xinjianya 后弹窗关闭、服务端存储正确、scope 清空
- 重开弹窗读回 [["gpt-5.2@xinjianya"]]
Co-Authored-By: ModelRouter <noreply@modelrouter.dev >
2026-10-03 10:32:51 +08:00
13e2397e9c
fix(ui): per-key 链复用全局 AUTO 画布；统计周期显示实际窗口
...
两件事。
一、per-key AUTO 链的 UI 之前自己写了一套表格，只有 model + tier 两列，
比全局 AUTO 编辑器弱：没有拖拽排序、没有每槽位的 quota/period/hours。
这是重复实现且必然漂移。改为复用同一套泳道画布：
- 抽出 buildSortIndex / buildLanes / lanesToRules / renderSortEditor，
全局编辑器与 per-key 编辑器共用。
- sortState.scope 决定保存目标（null=全局，key=该密钥），persistAuto
按此分支；空 lane 列表即"恢复继承"，与后端空 PUT 等价。
- 画布查找走 sortCanvasEl()，两个 id 都能解析，否则拖拽在弹窗里静默失效。
- keyAutoClose 必须清 scope，否则关掉弹窗后全局编辑器会存到这个 key。
- 删掉旧的 keyAutoRow/keyAutoAddRow/keyAutoClear。
判据改为断言"复用"而非断言具体实现，并新增两条：
- 关闭弹窗不清 scope（全局编辑器会存错目标）
- per-key 编辑器不再挂载共享画布
二、"周视图总量大于月视图"不是 bug：日历周期并非嵌套。"本周"从周一开始，
所以月初会回溯到上月末几天，本周总量合法地大于本月。实测今天 2026-10-03
（周六）：周窗口 09-28→10-03（6 天，9.2B tokens），月窗口 10-01→10-03
（3 天，4.0B tokens）。
真正的缺陷是看不见这一点。统计页新增"统计区间：YYYY-MM-DD → YYYY-MM-DD
(Nd)"，让周 > 月 自解释。判据钉住这个事实，并做变异验证：把周窗口钳制到
月内（一个看起来很自然的"修复"）会被两条判据同时抓住。
CDP 实测：周视图显示"2026-09-28 → 2026-10-03 (6d)"，月视图显示
"2026-10-01 → 2026-10-03 (3d)"；per-key 编辑器渲染出 36 条泳道 / 226 个
块，与全局编辑器同款。
Co-Authored-By: ModelRouter <noreply@modelrouter.dev >
2026-10-03 08:26:57 +08:00
22decf2bd3
feat(keys): 每个密钥可配独立 AUTO 链，管理员代配
...
此前 AUTO 链是全局单值（cfg.Auto + Core.AutoChain()），所有用户共用一条链。
管理员无法为某个用户单独指定调度链。
按 per-key 覆盖 + 全局兜底实现：
- config.GWKey 增加 Auto 字段与 HasOwnAuto()。未配置即继承全局链，
存量部署零改动，新密钥天然继承全局链。
- Core 把 buildAutoChain 的归一化逻辑抽成 chainForRules，全局链、
生图链、per-key 链共用同一套编译，避免两处漂移。
- Core 增加 keyAutoChains 缓存 + AutoChainFor(key)。请求路径读缓存不
加锁，与全局链查询一致。缓存整表原子替换，不会看到半成品。
- 请求侧 chat.go 改用 AutoChainFor(reqKey)。冷却仍在 Provider 上按
model+source 共享：两条链指向同一个 slot 时共用冷却，与今天单链行为
相同，也避免为 per-key 维度重构冷却而改变现有可观测语义。
- API：GET/PUT/DELETE /api/keys/{key}/auto（admin），GET
/api/keys/me/auto（任意角色，只能读自己的）。空 PUT 与 DELETE 等价于
"恢复继承"，无法持久化一条会 503 的空链。写入时回报解析出的槽位数，
让管理员当场看到模型名写错，而不是等用户下次请求 503。
- 源变更时一并重编译 per-key 链，加源后无需重启即可生效。
判据 18 条，5 个变异全部被抓住：AutoChainFor 忽略 key、清空后不重建
缓存、源变更不重建、空 PUT 落盘成空链、me/auto 误要求 admin。
UI 判据做变异时发现漏放：只查函数定义存在，删掉按钮后仍通过。已改为
断言 keyCanvasHtml 内的调用点。
端到端实测（真实 HTTP + 两个 mock 上游）：admin 与 bob 初始同为 m-fast，
给 bob 配 m-cheap 后两者分流，重启后仍分流，DELETE 后 bob 回到 m-fast。
Co-Authored-By: ModelRouter <noreply@modelrouter.dev >
2026-10-03 07:45:54 +08:00
