|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
ea8a9ac4c6
|
修复用量总计与渠道账本统计
|
2026-10-15 12:52:03 +08:00 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
6b6f9526ff
|
feat(channels): 对外功能面全量对齐参考 channel-pack RPC + 逐平台余额/签到状态端点
此前只实现了参考 RPC 面的一部分（账号池/模型开关/供应商/备份）。本次按
用户要求把对外呈现的功能补齐到与参考 channel-pack-rpc.ts 一致，并逐平台
移植真实余额/签到状态端点（不再'选一部分'）。
## 新增 RPC（对齐 channel-pack-rpc.ts 的 case 清单）
credits.status 逐账号签到状态（平台声明 checkin_status 时查，status_fn 解析；
无端点平台如实 null，与参考对 CodeArts/LobsterAI 处理一致）
credits.balances 逐账号余额（平台声明 balance 时查，total_fn 解析；无端点/无凭据
返回 {balance=null,error=...} 不编造数字 —— 对齐参考'不伪装余额'）
credits.permanentLock 永久积分锁定读写（buddy/loomy 等）
account.reset/retest 清限流标记 / 重测（支持 __all__ 批量）
model.setDisabledMany 批量模型开关
model.clearDead 清黑名单里已下线的死模型（只清不在 models 表的 id）
provider.getOrder/setOrder 供应商显示顺序（bogus id 过滤）
gateway.getEnabled/setEnabled 网关整体开关（复用 provider_set_enabled 语义）
backup.status 备份健康度（账号数/无过期时间账号数）
usage.tokenLedger 本网关 token 用量快照（数据源 /api/stats，与 usage 插件同思路）
usage.badge 渠道徽标（credits.balances 汇总）
usage.badgePreference 徽标偏好读写（非法值拒绝不回落，对齐参考注释）
onboarding.status/claim 新人任务（raccoon 桌面登录奖励 3000 分实测端点）
## 逐平台真实余额/签到端点（照各 *-credits.ts 逐字移植）
minimax signin/status 预检 + credit/details 余额（total=Σ remaining_amount，
避开参考踩过的 total_count 误读坑）
trae checkin_credits/status + ide_user_ent_usage（remain=Σ(limit-amount)）
buddy checkin-activity-status（不是 checkin-status 占位坑）+ get-user-resource
cline usage-limits（dollars，取剩余百分比最小的限额）
lobsterai profile-summary；qoder me/usage(userQuota+addOnQuota)；raccoon points/v1/balance
每平台 CHANNEL_CREDITS 能力表声明 unit/claim（对齐参考同名表）。
## WebUI 补齐
账号行展示逐账号余额（credits.balances）；详情动作区加「重置限流」「清死模型」；
顶栏加「Token 用量」弹窗（usage.tokenLedger）。node --check 过。
## 测试
TestChannelsExtendedRPCBehavior 10 子项全过：balances 无凭据报错不编造、status
无端点 null、reset、setDisabledMany、clearDead 只清死模型、provider order 过滤、
backup.status、badgePreference 非法拒绝、onboarding supported=false、permanentLock 读写。
全量 8 包回归通过。
已知未移植（如实说明，均需本机无法提供的运行时）：captcha.*（zcode 验证码载体，
需浏览器端求解器）、login.sendSms/submitSms（loomy 短信，备用路径）、
cline.requestLog/usage.tokenLedgerHistory（历史聚合，内核未落盘日维度表）。
|
2026-10-12 08:45:49 +08:00 |
|
|
|
4d0efab86b
|
feat(channels): 渠道控制台对齐参考 ChannelCard —— 账号池/模型开关/供应商治理/备份 + 全量 UI
用户要求与示例插件 dsh-our-free-model 的 WebUI 全面对齐。参考前端的
核心是 ChannelCard（client.js 3627 行起）：一个渠道可挂**多账号池**，
账号可逐个启用/停用/测试/删除/排序，模型可逐个开关，供应商整体开关，
账号备份导出/导入，自动签到开关。此前是单凭据 + 平表登录，差距大。
## 后端（channels.lua 新增 19 个 RPC，对齐参考 channel-pack 契约）
账号池（对齐参考 account.*）：
account_add/list/update/delete/test/refresh/reorder —— 一平台多账号，
每账号一条上游源 channels-<plat>-<aid>，凭据走保险库（0600 加密落盘）。
complete_login 带 account_id 时走池路径回填凭据。
模型开关（对齐 model.*）：
model_list/set_disabled/set_all_disabled —— 黑名单存 state，开关即重同步
该平台所有账号源（关掉模型=该账号源里去掉该模型）。
供应商治理（对齐 provider.*）：
provider_status（账号数/模型数/closed 态）+ provider_set_enabled
（关闭=全关模型+停用全部账号；打开=清黑名单+启用全部账号）。
一键领取（对齐 credits.claimAll）：
credits_claim_all —— 逐账号 claim_daily 收集结果，返回 {claimed, results}。
备份（对齐 backup.*）：
backup_export/import —— 账号池+凭据+模型黑名单+自动签到开关打包，导入
恢复凭据（走保险库）+重建全部账号源。
自动签到开关（对齐 usage.autoCheckin）：
auto_checkin —— 读写 state.settings.auto_checkin，关闭时 auto_claim 跳过。
auto_claim 升级为账号池驱动（逐账号 claim + 尊重 CHANNEL_CREDITS 能力表）。
**修一个真 bug**：__llmsproxy_secrets.set 返回 (true, nil) 成功 / (nil, err) 失败，
我多值赋给单变量拿到第一个返回值，误判为失败 → 改为 local _, serr = set(...)。
## WebUI（整个重写，对齐 ChannelCard 交互）
渠道网格（搜索/筛选全部·已接入·待接入/汇总条已接入N·账号总数）
→ 渠道详情（账号池列表：昵称/启用态/上次领取摘要 + 测试/刷新/停用/优先/删除；
模型折叠：逐个开关 + 全部启用/关闭 + 计数；添加账号=登录（占位账号先入池，
login 完成回填凭据，两步式对齐参考 account.create）；一键领取额度（结果
摘要展示成功数+失败原因）；供应商整体开关；自动签到开关；导出/导入备份）。
登录区仍覆盖 device-poll/callback/paste/manual/vnc 全部流程。
node --check 过内联 JS；凭据只经 complete_login 落保险库，不回显。
## 行为测试（channels_pool_test.go）
TestChannelsAccountPoolBehavior 5 个子测试全过：
账号增删改（含返回 account_id、改名、删空）
模型开关同步上游源（3模型→关1→2→全关→closed=true→全开恢复）
enabled开关同步上游源（停用删源、启用重建源）
供应商整体开关（关→无源+closed；开→源重建）
备份导出含凭据明文
## 已知边界（如实说明，未假装对齐）
- 余额逐账号展示：参考有 credits.balances（真实查上游余额），本环境各平台余额
端点形状差异大且多数需真实凭据，未编造假余额；账号行只显示上次领取摘要。
- usage.tokenLedger / cline.requestLog（用量账本/请求日志页）：参考有，本插件
内核侧已有 usage 记录但未暴露给插件，暂缺这两页（其余控制台能力已对齐）。
回归：全量 8 包（core/lua/gateway/config/types/scheduler/provider/e2e）通过。
|
2026-10-12 08:18:33 +08:00 |
|
|
|
2353d43c16
|
feat(channels): 全量厂商接入 —— Cline/Buddy/Gemini/LobsterAI/OpenCode/CodeArts/Qoder/ZCode/Loomy/Raccoon + 新流程 + WebUI 补齐
新增 10 个真实厂商平台（端点/模型/流程逐字照抄参考 channel-pack）：
device-poll（已有执行器）：
minimax 保留（MiniMax 形态：看 status 字段，slow_down +5s）
cline WorkOS 设备码（判据看 error 字段、HTTP 可非 2xx；slow_down +1s；
access_denied/invalid_grant 同组失败；成功后 register 第二跳
/api/v1/auth/register 换 Cline token）。新增 deviceRegister。
state-poll（新流程）：
buddy CodeBuddy（腾讯）。POST /v2/plugin/auth/state → authUrl+state；
轮询 GET /v2/plugin/auth/token?state=，业务码 11217 = 未就绪继续等
（对齐参考 loopGetToken：网络错误同样继续不中断）；token 就绪后
拿账号（失败不阻塞）。
callback：
gemini 标准 OAuth code 交换（oauth2.googleapis.com/token，六 scope 照抄）；
oauth_callback 增 code→token 交换分支（Gemini/LobsterAI 复用）。
lobsterai 本地回调 + authCode 换 token（lobsterai-server.youdao.com）。
trae 保留（token 直传 + ExchangeToken，已 8938574）。
paste：
opencode 直接贴 API key（无登录流）。
codearts 企业凭据 + SDK-HMAC-SHA256 签到（claim_fn 钩子，canonical request
+ 派生密钥链 kDate→kNonce→kSigning→signature）。
manual（后端给 manual_hint，明确说明而非假装成功）：
qoder WASM 签名头（纯 Lua 无法生成）
zcode captcha 求解
loomy 微信扫码
raccoon 图片二维码
WebUI（之前只覆盖 vnc/url+轮询/device-poll）：
chLogin 增 manual / paste 两个分支：manual_hint 展示 + 凭据粘贴框 +
提交按钮。新增 chComplete 调 channels/login/complete 落保险库，
凭据不回显、失败给可读错误不重载页面。node --check 过。
set_endpoints 增 register/state 覆盖（运维能力 + 测试缝，与 device/checkin 同语义）。
行为测试（照参考逐行）：
TestClineWorkOSBehavior 5 行：非200 authorization_pending 继续等 /
slow_down 退避 1s（interval=2）/ access_denied 失败 / 成功 register 凭据
是 CLINE-AT-1（不是 WorkOS token）/ 非200无 error 失败。
TestBuddyStatePollBehavior 3 行：state 申请给 authUrl / 首拍 11217 pending
次拍 token completed / account 查询失败不阻塞回退默认名。
变异测试修复（deviceOneStep 拆 workos/minimax 两分支后幸存体暴露）：
锚点 +step / authorization_pending 现两处同形，strings.Replace(,,1) 只改
workos 分支、minimax 决策表没杀到 → 改 ReplaceAll 全改；删冗余第 6 变异体。
5 变异体全杀。回归：channels/device/cline/buddy/trae/legacy/保险库/e2e 全绿。
|
2026-10-12 00:28:26 +08:00 |
|
|
|
893857464d
|
feat(channels): TRAE callback 真实移植 —— token 直传 + ExchangeToken（照参考逐行）
此前 oauth_callback 是通用 OAuth 形态（直接拿 code 当凭据），与 TRAE 真实
行为不符。参考实现 trae-oauth.ts 的回调是 **token 直传**，本次照其行为移植：
parseTraeCallbackDetailed（决策表 5 行）：
行1 refreshToken 直传（或 userJwt.RefreshToken 回退）→ ExchangeToken 换新
access（请求体 ClientID/RefreshToken/ClientSecret:'-'/UserID 照抄，
响应取 Token）→ 凭据 = 新 access
行2 无 refreshToken 但有 userJwt.Token → 直接兜底，**不打** ExchangeToken
行3 只有 code/authCodeInfo → PKCE 流，明确报"暂不支持"而非含糊失败
（参考注释强调：判为无效会让用户往错误方向排查）
行4 全空 → 报"回调未携带 refreshToken / userJwt.Token / code"
行5 ExchangeToken HTTP 失败 → 错误指明 ExchangeToken 阶段
配套：
- PLATFORMS.trae 增加 callback = {mode="trae", exchange_url, exchange_body}；
- oauth_callback 按平台 callback.mode 分派（nil→code 旧路径不变，googleish 不受影响）；
- traeCallback/jsonField 新函数；set_endpoints 支持 callback.exchange_url 覆盖
（既是运维能力也是测试缝，与 device 端点同语义）；
- TestTraeCallbackBehavior：5 行决策表 + 行1 断言凭据来自假上游新 Token
（防"把回调原值当凭据"）、行2 断言 ExchangeToken 零调用（防多余上游请求）。
回归：channels/trae/device 变异/压力/legacy/保险库/e2e 全绿。
|
2026-10-11 22:35:18 +08:00 |
|
|
|
2f5cde7fea
|
test(e2e): channels device-poll 真二进制端到端 + 修正插件 HTTP 前缀
TestChannelsDevicePollE2E 用真二进制跑通完整链路（对齐参考插件形态的终局验收）：
假平台上游（设备码/token/模型/对话端点）
→ 真网关进程 + plugin_dir（SeedBundled 落地 channels）
→ PUT /api/plugins/channels/kernel 授权（运维批准动作面）
→ call/set_endpoints 把 minimax 端点指到假上游（自建代理能力复用）
→ POST /api/plugins/http/channels/login 发起 device-poll
→ GET .../login/status 轮询：先 pending（authorization_pending），
后 completed（token 下发）且 account 取 nickname
→ 终局证据：/v1/models 出现 channels-minimax 的模型 MiniMax-M3
调试中抓到并修复：channels.lua 三处旧挂载前缀 /api/plugins/channels/http/
（正确为 /api/plugins/http/，spawnBrowser 回调路径、callback redirect_uri、
UI fetch 基址）—— UI 上点登录/回调一直会 404。
顺带：e2e 就绪探针复用 startGateway（无源时 /v1/models 空列表也 200）。
|
2026-10-11 21:44:40 +08:00 |
|
|
|
6f2b6b8d3d
|
feat(channels): device-poll 通用执行器 + 行为对齐测试（照参考实现逐行移植）
按用户要求：不是从头造，而是移植参考实现（minimax-oauth.ts）的行为，
并照对方代码的行为形成测试项。
新增（channels.lua）：
- b64url/hexToBin/devicePkce：PKCE S256（对齐 createMinimaxPkce）
- deviceOneStep：轮询决策单步执行器，分支顺序逐行对齐 pollMinimaxDeviceToken：
200+status=pending → 等
200+status=slow_down → interval+5s，等
200+status=denied/access_denied → failed(用户拒绝)
200+status=expired/expired_token → failed(码过期)
非200+error=authorization_pending → 等（OAuth 标准形态）
非200+error=slow_down → interval+5s，等
200+access_token → 成功
其它 → failed(带 error 文本)
- start_login device-poll 分支：申请设备码（PKCE）、user_code/授权URL透传、
verifier 只存会话不回显
- poll_login：device-poll 会话每次推进一步（页面驱动，不阻塞 —— 插件单VM单锁，
阻塞循环会卡死本插件全部钩子）；成功即落凭据+接入源
- set_endpoints 导出：运维把渠道端点指向自建代理/镜像；也供测试打假上游
- plugin.exports = { set_endpoints }
测试（channels_device_test.go）：假上游逐次响应，8 行决策表逐行断言
（pending 等待 / slow_down interval+5 / denied→failed / expired→failed /
authorization_pending 等 / slow_down(4xx) 等 / 成功→completed+account 取
nickname / error→failed 带文本）。全部通过。
教训（词法作用域）：devicePkce 原引用文件后段才定义的 newToken，Lua 下那是
nil 全局调用 —— 已改为自含熵源。
|
2026-10-11 20:08:00 +08:00 |
|
|
|
96d97b0e0e
|
feat(channels): MiniMax 渠道 —— PKCE 设备码流（RFC 8628）
第二个真实厂商，采用纯 HTTP 的设备码授权（无需本地服务器）：
- 申请: POST account.minimax.cn/oauth2/device/code
body: client_id=mcode-public&scope=agent.default&audience=agent-backend
&code_challenge={S256(verifier)}&code_challenge_method=S256
- 轮询: POST account.minimax.cn/oauth2/token
body: grant_type=device_code&device_code=..&client_id=mcode-public
&code_verifier=..
- 签到: POST agent.minimax.cn/minimax-cloud/api/v1/signin/claim body {}
- 模型 fallback: MiniMax-M3.1-Flash-Preview / M3 / M2.7-highspeed
（对齐参考仓库 minimax-product.ts）
device-poll 流程的三步状态机在 start_login/poll_login 中实现：
begin 时生成 PKCE verifier/challenge 并申请设备码，把 verifier 存进
会话（只在换 token 时用一次，不回显），页面轮询 token 端点直到
authorization_pending 结束。
|
2026-10-11 19:29:58 +08:00 |
|
|
|
6de9f28269
|
feat(channels): 逐厂商支持启动 —— TRAE 真实渠道接入 + checkin 表驱动
用户确认：仿照示例插件逐个支持厂商，自用、风险已知悉。
PLATFORMS 表升级为完整平台描述（对齐 dsh-our-free-model/channel-pack）：
- adapter 字段：接入内核用哪个协议适配器
- checkin 字段：每日签到 {url, method, body, headers}（可缺省=不支持）
- hosts 字段：登录域与上游域（供 plugin.hosts 推导）
- claim_fn/claim_result_fn 钩子位：特殊签名/响应解析的厂商挂点
TRAE（字节）为第一个真实渠道，作为后续厂商的模板：
- 登录：callback 流（www.trae.cn/authorization，token 直传）
- 模型 fallback：DeepSeek-V4-Flash/Pro、Kimi K3、GLM-5 系、Doubao-Seed-2.1
- 签到：POST https://api.trae.cn/trae/api/v2/ug/checkin_credits/claim body {}
（端点逐字对齐参考仓库 trae-credits.ts）
plugin.hosts 不再手写：declaredHosts() 从平台表推导（hosts+base_url+checkin.url），
避免"两份名单漂移"（参考仓库同类真实缺陷的教训）。
内核零改动。UI 登录框补回 ch-vnc-wrap 内嵌容器（上次重构时遗漏，VNC 兜底
流程会引用不到）。
|
2026-10-11 19:26:21 +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 |
|
|
|
d3203d88fc
|
feat(plugins): usage 插件进仓，随包播种
之前只通过 POST /api/plugins 装在生产上，源码仓里没有 —— 于是
core-dist.sh 的 deb/rpm/tar.gz 与 GUI 的 electron-builder 产物都不带它，
/v1/usage 在任何拿到安装包的人那里都是 404，页面显示「后台未开放消费接口」，
看起来像坏了而不像少了个可选功能。billing.lua / quota.lua 一直都是 embed 的，
usage 与它们同级。
四个测试（internal/lua/usage_plugin_test.go）盯的是三件容易在改 Lua 时被
无声破坏的事：
1. 遮罩算法必须与 Go 的 keyID() 一致。/api/stats 的 map 以掩码（***f9a9ed）
为键，handler 收到的是完整 key；传完整 key 不报错，只是静默返回 0。实测：
?key=***f9a9ed → reqs=33847
?key=sk-gw-7ffe…9ed → reqs=0
端点于是对一个有几十万次请求的 key 报「0 次」。
2. 不得读 PLUGIN.state / prices / 任何凭据：它报的是**调用者**的用量，
读配置里的 key 会把一个租户的花费报给所有租户。
3. 取不到数据必须报「usage unavailable」，不能返回 0：0 会被渲染成
「已用 0，0 次」，那是「这个 key 从没被用过」这个不同的、且错误的断言。
4. period 默认 all：日维度看起来像每天清零。
反向验证过 roles 声明：撤掉后 TestUsagePluginShipsAndGuardsItsOwnKey 变红。
(cherry picked from commit ae2b121959)
|
2026-10-07 17:37:22 +08:00 |
|
|
|
0858a747ca
|
fix(lua): 导出函数调用不标脏，插件状态从不落盘
quota 声明 hooks=[]，全部工作都在导出函数里。markDirty 只从 hook 与
SetState 触发，Call 两边都不占 —— 于是探测改的内存没人写盘，状态文件要等
下一次无关的配置写入才顺带刷新。
现象是「插件看起来没写」：负 memo 要等到下一次改配置才出现。用隔离实例
逐步观察时，一度把这误读成 memo 状态机的三个缺陷，逐个查清后只有这一条
是真的：
- 「未就绪轮次累计 streak」 —— 不成立。写侧本来就对临时条目用 streak=1，
65ed1b 版本已是这个行为。
- 「读侧用旧快照，streak 永远停在 1」 —— 是退避的设计行为。单进程内第二
次探测被退避挡在写侧之前，streak 自然不再增长；真实的多轮计数在跨进程
（trace_streak.py）下是 1/2/3/4。
- 「Call 不标脏」 —— 真缺陷，已验证：去掉 markDirtyLocked，
新增的 TestOnDemandCallIsPersisted 立刻变红。
顺带保留两处无行为差异的可读性收紧：provisionalEntry 统一按「集合非空」
判断临时条目（与 copySet 空集返回 nil 的写法对齐）。
判据：TestOnDemandCallIsPersisted 用 hookless 插件走导出函数累加，
反向证明（去掉 markDirtyLocked）会红。
(cherry picked from commit 3444d2d903)
|
2026-10-07 17:37:22 +08:00 |
|
|
|
7934507179
|
fix(quota): 未就绪适配器污染负 memo；被拒凭据被后续 404 掩盖
端到端验证时撞出两个真缺陷，都是单元测试全绿、隔离实例打真上游才暴露。
一、负 memo 语义混用
负 memo 说的是「这台 HOST 没有余额端点」，且无条件在每次探测前生效。
openDesign 缺 control_key 说的是「这台部署还没配」—— 两件事共用一个条目：
1. 未配 control_key → 探测 → 负 memo
2. 操作员写入 key → 探测被退避拦下，adapter 根本没跑
3. 结果：修复看起来无效，源持续沉默（退避窗口可达数小时）
不能靠「skip 就不记 memo」解决：真实 vela 主机上另外三个 adapter 都返回
404（关于主机的持久结论，正是 memo 存在的理由），verdict 一定是普通 skip。
做法是 memo 条目带上「哪些 vendor 因自身未配置而无法判断」：
- 未就绪的 adapter 直接不跑（跑了只能得到 401 或伪造的 skip）
- 条目带 unready 集合；该 vendor 配置好后条目作废重算
- 仍缺配置时条目依然写入（否则无看板的主机回到每次开页 60 秒超时），
但不退避 —— 退避会拒绝那个本来能成功的探测
二、401 被下一个 adapter 的 404 掩盖
adapter 循环不停在 error，而「最后一个胜」不精确：openDesign 走厂商的整份
主机列表，是最可能看到「key rejected」的那个，但它也可能排在最前（memo 记
得它应答过，下次就优先它）—— 于是它的 401 被下一个 adapter 的
404「no dashboard here」分类成「这台主机没有余额端点」。两种情况的修复动作
完全相反，输出却一样。规则改为：被拒凭据优先，且不被覆盖。
判据：12/12 变异全杀。三条曾经存活或误杀，逐条查清：
- rejected-as-skip 存活是因为测试没有复现生产调用顺序（memo 空 → openDesign
排最后 → 旧规则也能过），测试已改为预置 memo 并让另三个 adapter 走同一个
stub（它们读 base 而非 api_base，否则会全部传输失败）
- no-cred-guard 并非存活，只是杀它的不是我以为的那个测试（门禁后面还有
一道检查），预期已改正
- unready-memo-not-dropped 是真等价变异（known=false 与 nil 只差一次廉价
探活），已从清单移除
(cherry picked from commit 83f1ec0807)
|
2026-10-07 17:37:22 +08:00 |
|
|
|
97a6cf9224
|
feat(quota): OpenDesign 出站主机加入白名单
插件出站白名单 = 已配置源的 host。这条规则对每个 adapter 都成立，直到
OpenDesign —— 它把推理和计费拆在两个域上：推理 amr-link，计费 amr-api。
adapter 从推理主机推导计费主机，于是它请求的 host 从来不是操作员配过的
那个，请求在离开进程前就被拒，报"不是允许的出站目标"，读起来像插件 bug。
core.sourceHosts 现在同时加入派生主机，且仅当源本身就在 amr-link 上
（没有 OpenDesign 源的部署不会凭空获得这条授权）。
派生规则前后端各存一份，因为 Go 建白名单、Lua 建 URL，两边不一致的表现是
「请求被拒」而不是「命名不匹配的错误」。规则改成了完整主机名匹配：
`amr-link.` 前缀写法会把 amr-link.example.com 也改写成 OpenDesign 地址。
顺带修掉一个真缺陷：Lua 侧先 `gsub("/+$")` 再匹配主机名，而 base_url 是
`https://amr-link.open-design.ai/v1` —— 带路径时整串拿去匹配 `^...$`
永远不命中，改写静默失效，探测打到推理主机。改成先切路径。
这个缺陷是「行为断言」抓到的：上一版判据 grep 源码里的 gsub 模式，而
gsub 模式在改前改后都"看起来对"。8/8 变异全杀。
(cherry picked from commit 4a63b9dc0b)
|
2026-10-07 17:37:22 +08:00 |
|
|
|
d92db3a9fd
|
feat(quota): 接入 OpenDesign/Vela 余额探测（controlKey）
vela 一直显示 skipped，因为计费端点需要第二个凭据：推理走源自己的
runtimeKey，但 amr-api.open-design.ai 的 wallet/balance 和
billing/summary 只认桌面端登录时下发的 controlKey（runtimeKey 返回
401）。全量后拿到了 controlKey，本机 /root/.amr/config.json。
测了实测行为（两个端点各 200，约 1.3s）：
wallet/balance → balanceUsd / expiresAt / workspaceId
billing/summary → creditsPerUsd / membershipTier /
subscriptionCreditsUsd / totalConsumedUsd 等
实现要点：
- controlKey 走插件自己的 prices 表（插件系统本就按插件持久化一张
prices，与 state 分离），用 PUT /api/plugins/quota/state 设置；
base_url 保持推理主机，adapter 内部改写 amr-link→amr-api。
- 本账户 billingState=free，没有 codingPlan.windows，所以不设
rep.windows：页面显示"无周期数据"，而不是编一个 100%。
- creditsPerUsd 缺失时置 credits_rate_missing 并跳过积分换算，不默认
10000；*Usd 字段是权威值，直接采用。
- 401 归为 error（凭据要重登），不是 skip（无计费端点），两者修复动作
不同。
- skip 时把原因带上：区分「未配置凭据」和「上游无该端点」。
新增 7 条判据 + 7 个变异全部杀死（含一条"skip 丢原因"）。变异 harness
第一轮 6/6 时 no-cred-guard 存活，原因是该测试没设 api_base，探测被
出站白名单拦掉、与缺少凭据无法区分 —— 判据失效而非代码问题，已修。
(cherry picked from commit 75a0d247a4)
|
2026-10-07 17:37:22 +08:00 |
|
|
|
a1fddf72b7
|
fix(quota): 十三个退避中的源被渲染成「有数据」
## 症状
生产 Quota 页面上 17 个源里 13 个显示「有数据」徽标 —— 而它们实际上什么都
没返回，只是刚刚被退避跳过。
## 根因（三层，逐层都静默）
**① 退避记录缺 `skipped` 标记**
`due_sources` 与 `collectSource` 返回退避记录时没有 `skipped = true`，页面的
`filter(r => !r.skipped)` 就把它们当正常记录放进卡片。卡片渲染匹配已知字段，
一条只有 `reason` 的记录什么都匹配不上，于是落到兜底分支。
**② 兜底分支文案是「有数据」**
那是个断言 —— 它在说「探测有应答」。落到这里的记录其实是：一条退避通知、
一种我们不认识的错误形状、或供应商改了响应格式。把「没有证据」说成「有数据」，
十三个死上游就被渲染成健康的了。改成「未探测」。
**③ 退避与「没有余额接口」被混为一谈**
页脚原本统一说「未暴露余额接口」。这是对上游的另一种断言，而且对死上游是错的
—— 它有接口，只是暂时没探到。
## 「只改了一处」这个坑
`render()` 改成按 `backing_off` 标记分组之后，两个调用点都必须传**记录**而不是
名字。我先改了刷新路径就部署，结果是页脚显示「未列出 13 个源：、、、……」——
症状看起来像渲染 bug，实际是两个调用点与同一个函数之间的契约不一致。
快照路径那行 `.map(function(r){ return r.name; })` 是后来才补的。
判据 `TestQuotaRenderCallSitesPassRecordsNotNames` 现在要求两处都在。
## 顺带修掉的两个真 bug
**空 Lua 表在 Go 侧解码成 `{}` 而不是 `[]`**
`plan.backing_off || []` 里 `{}` 是 truthy，空表会原样进入 `out.concat()` 并抛错，
整次刷新报失败。改用 `Array.isArray` —— 它与插件实际返回的类型匹配。
**分组靠文案匹配是个定时炸弹**
原先用 `reason.indexOf("backing off") === 0` 判断退避。理由字符串一旦本地化，
退避就会被并进「未暴露余额接口」。改用显式 `backing_off: true` 标记，
判据里也改成按标记匹配 —— 变异把文案改回英文立刻变红。
## 判据
新增两条：
- `TestQuotaBackoffRecordIsSkippedAndFlagged` —— 退避记录必须带 `skipped` 和
`backing_off` 标记，且必须有 reason（否则卡片是空的）
- `TestQuotaRenderCallSitesPassRecordsNotNames` —— 两个调用点都不得把跳过列表
映射成名字
变异自证四次全部变红：去掉 `skipped`、去掉 `backing_off`、文案改回英文、
快照路径改回 map-to-name。
## 生产实测（浏览器真实点击）
```
第1轮 1694ms: 4 个源 · 0 个读取失败
13 个源正在退避（连续探测失败，等下次重试）：trae、qijiar、toter、…
第2轮 2488ms: 4 个源 · 0 个读取失败
13 个源正在退避（…）：trae、qijiar、toter、…
```
页面现在只列 4 个真有数据的源，13 个退避中的归到页脚并说明原因。
Co-Authored-By: ModelRouter <noreply@modelrouter.dev>
|
2026-10-05 10:27:18 +08:00 |
|
|
|
b9a025efba
|
feat(quota): 判定与记录回到共享 VM，只有网络等待才分片
## 我引入的自相矛盾
分片是为解决这个量出来的：
单源探测（无竞争） 1.4 – 3.3 s
20 源 Promise.all 29 s
20 源串行理论值 ≈ 29 s ← 吻合
根因是 Plugins.Call 持 p.mu 到 Lua 函数返回，**含全部网络等待**；一个 Lua VM
只有一个栈，锁不能去掉。于是每个并发调用用自己的 VM 跑同一份源码（实测 8 分片
2.407s → 0.304s）。
但分片 VM 有自己的 PLUGIN.state —— 而**退避状态就存在 state 里**：
fanout（分片） → memo 0 条 → 退避永不生效，每轮都付满 12s
call（共享 VM） → memo 17 条 → 13.1s → 4.8s
我设计分片时写了「分片不碰 state」这条硬约束（防 billing 的累加在各分片分叉、
saver 写出随机一份），却没意识到探测的退避状态恰好住在那里。约束和功能打架。
## 解法：按职责切开，不搬家
把退避表移到网关（B）能解决，但 quota 的 adapter memo 也在 state 里，而且
「插件自包含」是这个插件机制的前提。搬一半比不搬更糟。
所以判定与记录留在插件里，共享 VM 负责；只有网络等待分片：
due_sources 共享 VM，纯判定，不发请求（微秒级）
fanout 只对 due 里的源分片探测
memo_record 共享 VM，把这轮结果（成功和失败都记）写回
一个分片也不碰 state —— 约束保住了。
## 实测（隔离实例，18 源，与生产同配置）
第1轮 10163 ms 退避跳过 0 分片 18 答了 4
第2轮 1299 ms 退避跳过 14 分片 4 答了 4
第3轮 1288 ms 退避跳过 14 分片 4 答了 4
第4轮 1316 ms 退避跳过 14 分片 4 答了 4
**29s → 1.3s，且 4 个有余额的源每次都探到** —— 不是靠少显示换来的快。
## 几个细节
- due_sources 的 body 里不能出现 collectSource：一旦它自己探测，过滤就没有意义
了（成本在分片之前就付掉了）。有判据守着。
- memo_record 忽略 reason 以 "backing off" 开头的行 —— 那是被跳过的探���，
把它记成失败会让 streak 在一次没发生的探测上增长。
- 成功写成 vendor 字符串，streak 自然重置，不需要显式清零。
## 判据（新增 4 条，共 11 条读实际发布的 quota.lua）
- 两个导出存在且在 exports 里
- due_sources 不调 collectSource
- memo_record 让 streak 从分片失败里累加，成功后重置
- due_sources 把退避中的 host 挡在分片之外，且零网络请求
写判据时踩了一次：两个源用了同一台 httptest server，于是被判为同一个 host，
两个都退避 —— 这是按 host 记忆的**正确**行为，是我的判据写错了。
Co-Authored-By: ModelRouter <noreply@modelrouter.dev>
|
2026-10-05 08:17:57 +08:00 |
|
|
|
7c7cf3e078
|
fix(quota): hostOf 用了 gmatch 而不是 match —— memo 表从未命中过任何东西
## 这是退避失效的真正原因，而且比 TTL 严重
查生产 state 时发现的：19 条 memo，`hostOf(key)` 命中 **0** 条。
hostOf = function(u)
return (string.gmatch(u, "^https?://([^/]+)")()) or u
end
`string.gmatch` 返回**整个匹配**，不是捕获组；而带 `^` 锚定时迭代器不会前进，
所以第一次 `()` 调用返回 **nil**，函数走 `or u` 分支返回完整 URL。
后果是彻底的、而且完全静默：
- 每次查表都是 HOST_MEMO[nil]，每次写入也是 HOST_MEMO[nil]
- memo 表**对任何 host 从未命中过**
- 负 memo、PROBE_MEMO_TTL、以及刚加的指数退避，**全是看起来活着的死代码**
- 生产那 19 条历史 memo（key 是完整 URL，来自 ccquota 时代）从来没有被读过
所以「两个死上游每 30 分钟重付一次探测」的真实原因不是 TTL 到期，
而是压根没命中过 memo。
## 为什么这么久没人发现
失败模式与「memo 里没有可记的东西」完全不可区分：页面照常显示，卡片照常
skipped，没有任何报错。唯一线索是 state 里那 19 条条目 —— 它们看起来像是
在正常工作留下的痕迹。
## 修法
string.match(u, "^https?://([^/]+)")
判据 `TestQuotaMemoKeyIsTheHost` 钉住它：读**实际发布的** quota.lua，检查
用 string.match，并在运行时验四个 URL 的 host 抽取，以及同一 host 的两个不同
路径必须产出同一个 key（这正是按 host 做 memo 的意义）。
变异把 match 改回 gmatch 立刻变红，并打印出实际返回的完整 URL。
|
2026-10-05 08:17:57 +08:00 |
|
|
|
c4b37d4322
|
feat(quota): 探测退避改指数 —— 死上游不再每 30 分钟重付一遍
## 为什么 30 分钟 TTL 治不了死上游
线上有两个 host 已经**不可达十个小时**，而 PROBE_MEMO_TTL 是 1800 秒。
于是每次刷新它们的负 memo 都已经过期，每次都重付三个 adapter 的超时：
每个源 24s（预算修好前）、16s（修好后）。固定 TTL 对「已经死了很久」这个
形状完全无效 —— 它只会一直重复付。
指数退避：连续失败 streak 次，等待 1800 × 2^(streak-1)，封顶 6 小时。
成功会把 memo 覆盖成 vendor 字符串，streak 自然重置。
封顶不是可选项 —— 没有它，下线一周的 host 就不再被探测，页面会**永久**
把它误报成「没有余额接口」。
## 过程中判据抓到的三个真 bug
**① 记录守卫让 streak 永远是 1**
`if rep == nil and not HOST_MEMO[host]` 只在 host **第一次**失败时为真。
之后 memo 已是 table，守卫为假，什么都不写。实测连读四次都是
`{at:... streak:1}` —— 退避退化成固定 30 分钟，正是它要解决的问题。
**② `return 0` 在 Lua 里是真值**
`if streak == nil or streak <= 0 then return 0 end` —— 只有 nil 和 false
是假值。调用点写的是 `if backoffSeconds(...) then 跳过`，于是**所有没有
streak 字段的 memo 会被永久跳过**（而那正是本改动之前写的每一个 memo）。
**③ 上限路径 `return BACKOFF_MAX` 也是真值**
21600 会被判成「仍在等待」，封顶反而变成「永远不重试」—— 恰好是封顶要防的
那个故障。现在所有路径只返回布尔。
三个都是静默的：症状只是页面少了几张卡片，没有任何报错。
## 判据
五条，全部读**实际发布的 quota.lua**（go:embed 那份），不是副本：
- 退避确实被调用（变异把调用点换成 `if false` 时会红）
- 窗口表：每个 streak 的窗口长度、窗口内跳过、窗口过期后重试、
荒谬 streak 也必须重试
- 只返回布尔（六种输入，含无 streak 字段的老 memo）
- 记录守卫会替换 memo 而非合并
- 通过真实插件：首次失败记 streak=1；**跳过不算失败**（否则一个从不被探测的
host 会无限增长 streak，再也不会被重试）
变异自证六次全部变红：`return 0`、上限返回数字、守卫不替换、调用点去掉、
去掉上限、倍数改成 1。头一次跑「守卫不替换」漏放了 —— 因为我把集成判据缩到
只验首次记录，补了一条源码断言才抓住。
## 这个文件的判据绕了远路，如实记下
`HOST_MEMO` 是进程内缓存，只在首次 collect 时从 state 恢复，之后只往回写。
所以从 Go 侧改 state 对插件不可见 —— 我先是不自知地这么试了两轮，把一个
**正确工作的退避**看成坏的。现在窗口策略直接验函数（经 shim 导出插件自己的
backoffSeconds，不是重新实现），集成判据只留真正能从外部观察的两条。
shim 也踩过：直接把 `backoffSeconds` 当 export，而 Go 侧传的是 table，
于是 at=table、streak=nil，每次都走「无 streak」分支返回 false —— 看起来
和「退避永不触发」一模一样。包一层就对了。
|
2026-10-05 08:17:57 +08:00 |
|
|
|
345cbb30d6
|
fix(billing/quota): 探测预算用 os.clock 是 CPU 时间，12 秒预算从未生效
## 现象
线上 quota 页面点刷新后卡在「探测中…」，13 秒仍未完成，按钮一直 disabled。
## 实测根因（不是猜测，是量出来的）
单源探测，隔离实例，逐个测：
juziai 16029 ms
beizhi 16021 ms
localzen 2516 ms
frank 2028 ms
sensenova 258 ms
而插件自己写着 `PROBE_BUDGET_MS = 12000`。**修复前**这两个源各耗 **24013 ms**
—— 精确等于 4s 超时 × 2 次重试 × 3 个 adapter。预算形同虚设。
## 原因
`exhausted()` 用的是 `os.clock()`，它返回 **CPU 时间**。探测几乎全耗在网络等待上，
CPU 几乎不动，于是预算永远不触发。
判据 `TestPluginClockDuringNetworkWait` 直接量这件事：
3s blocked on HTTP: os.clock advanced 0.001s, os.time advanced 3s
**001 秒。** 一个用 CPU 时间写的预算，在 I/O 等待下永远不会响。
这个陷阱和「用忙等测锁竞争」是同一个，只是下沉了一层 —— 而且我第一版判据
正是这么写错的：用自旋循环当「网络等待」，结果 os.clock 走了 1.624s / 2s，
看起来 os.clock 跟的是墙钟，差点得出「不是这个原因」的错误结论。必须用真实
HTTP 请求重测才能拿到真相。
代码里两处同样的写法（第 434 和 466 行），一起改掉。
## 改完的效果
串行 20 源（/call/ 逐个） 84391 ms
fanout 20 源（并行） 16022 ms
⇒ 5.27x
单个死上游从 24s 降到 16s（12s 预算 + 收尾）。
## 还没解决的
16 秒仍然偏长，因为它等于**最慢那一个源**的预算。这不是并行失效，是并行
之后墙钟的必然下界。要再往下走只有两条路：把预算压到 4~6s，或者给已知死掉
的上游走缓存而不是每次重探。都是参数与策略选择，不是结构缺陷，留给下一步。
|
2026-10-05 08:17:57 +08:00 |
|
|
|
91e3013cb5
|
feat(billing): 长上下文阶梯定价（边际费率，与缓存折扣/峰段可叠加）
## 影响面实测
审计里 1000 条请求：**883 条（88.3%）prompt 超过 128k**，中位数 246849，
p90 298179，最大 354251。这不是小众场景，是 agent 负载的主流形态。
按「模型 × 源」拆开：其中真正按 token 计价的只有 alittokenplan 的 10 次
（deepseek-v4.1-flash，约 350k prompt），其余走 $70 套餐（commandcode）或
免费源（localzen），记 0 是正确的，对阶梯无影响。
那 10 次当前少算 54.9%（$0.3148 → $0.4877）。绝对值不大，但比例严重，
而且这个偏差只会随上下文变长而变大。
## 边际而非混合平均
阶梯只对**超过阈值的部分**重新计价，不是把整段按高价算。理由是可叠加性：
缓存读取同时享受缓存折扣**和**长上下文阶梯价，这与供应商的计费方式一致。
混合平均必须二选一，选错就正好低估「缓存命中的长请求」——而这恰是缓存
存在的意义所在（本部署缓存命中率 88%）。
超出部分按缓存/新鲜的比例拆分，不重不漏。
## DSL 两种写法
供应商两种发布方式都支持：绝对费率（OpenAI 报 \$3.00/M past 200k）和
倍数（DeepSeek 报 2x past 128k）。两者都缺必须报错 —— 一个没有费率的阶梯
会编译成一条「看起来处理了长上下文、实际没处理」的规则，静默少算且无迹可寻。
两者都给时以绝对费率为准，因为那是供应商真正报出的数字。
## 判据
Lua 侧两条（边际性、与缓存折扣叠加）+ Go 侧一条（两种写法与拒绝规则）。
变异自证三次：整段按高价 / 缓存部分不叠加折扣 / 缓存部分不计阶梯，
分别命中 0.40 vs 0.272、0.165 vs 0.2325、0.09 vs 0.2325。
规则编辑器加了三个输入（阈值 + 绝对费率 + 倍数），三项都留空 = 无阶梯 ——
与「阶梯费率为 0」刻意区分，所以是三个独立输入而不是从 0 推断是否存在阶梯。
Co-Authored-By: ModelRouter <noreply@modelrouter.dev>
(cherry picked from commit 314f4da8f2)
|
2026-10-04 14:50:47 +08:00 |
|
|
|
92b81ecfd3
|
feat(billing): reasoning 价接入 DSL 与规则编辑器
上一提交把链路打通后，reasoning_price 只能靠手改 prices 生效 —— 而 prices 是
编译产物，不是人能编辑的东西。这条补上让它真正可用：
- BillingToken 加 reasoning 字段（USD/百万，与 prompt/completion 同单位）
- compile 只在规则显式声明时写 reasoning_price，缺省时字段不出现
- 规则编辑器的模型行加「思考 $/M」输入框，含新增行的模板
缺省时「不出现」是刻意的：写 0 会被 billing 插件读成「思考免费」，
每个来自该模型的请求都会静默少算。判据专门钉住这一点，变异成「缺省写 0」
即变红。
输入框 placeholder 写明「留空=按输出价计（OpenAI/DeepSeek/Anthropic 都这样）」，
因为一个没有解释的空输入框会被当成「必填但我不知道填什么」。
判据还要求 m-r 出现两次 —— 只改已有行的模板而不改「+ 模型」新建的行，
会让新加的模型在下一次保存时静默丢掉这个价。
生产验证：PUT 一个 reasoning: "1.80" 的规则，编译产物里出现
reasoning_price: 1.8000000000000001e-06（USD/token）。测完已把生产配置恢复为
6 条规则（备份 config.yaml.bak-billing-20261004-122151 为基准重建，
20 个源数量核对一致）。
Co-Authored-By: ModelRouter <noreply@modelrouter.dev>
(cherry picked from commit b93799a919)
|
2026-10-04 14:50:47 +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 |
|
|
|
27b908d98c
|
fix(billing): 未定价按天统计，让「已修好」和「还在漏」不再长得一样
计费页只有一个终身计数器 unpriced_reqs，实测 6378 —— 占 18981 请求的 34%。
但这个数字回答不了运维唯一会问的问题：「还在漏吗？」
原因是它把两件事混在一起：加规则之前的历史欠账，和加规则之后仍在发生的漏计。
修好一个源之后终身计数纹丝不动，于是仪表盘上「未定价 6378」和一个仍在
什么都没记的系统完全无法区分。
改动：
- 钩子按 UTC 天写入 unpriced_by_day{day:{reqs, models}}。终身计数保留
（报表不该改写历史），天桶是新增的观察维度。
- 页面加「未定价（近 7 天）」一行。为 0 时额外显示「近 7 天无」——这时候
零本身就是结论：加的规则确实生效了。
- 没有天桶数据时返回 null 而不是 0。旧的 state 文件说「未知」，
不该假装有一份干净记录。
生产实测：全部视图 终身 6378 / 近 7 天 2；日视图隐藏终身计数（null）但保留
近 7 天 —— 周期视图原本把两者都置 null，因为那时根本没有天桶。
失败的请求同样计入（上游 502 的 gpt-5.5 也进了天桶）：一次失败的请求照样
消耗上游配额，只是没拿到 token，单看 token 维度会漏掉。
判据：两个不同日期的请求必须落到两个天桶且终身计数不重复累加；变异成
「总记今天」即变红（只判首日会漏掉这一点）。
Co-Authored-By: ModelRouter <noreply@modelrouter.dev>
(cherry picked from commit ba6de89d57)
|
2026-10-04 14:50:46 +08:00 |
|
|
|
cab3361073
|
fix(plugins): quota 页面加载时不再自动探测全部上游
首屏 19.1 秒 → 1.0 秒（生产实测）。
症状是"页面出来了但数据卡在加载"。量出来的原因不是渲染，也不是后端：
所有接口都在 0.4–2ms，而 Network 事件显示页面在头 70 毫秒内并发发出了 21 个
/api/plugins/quota/call/collect_source —— 每个源一次。CPU 采样 98% 空闲，说明
主线程不是在算，是在等。
插件页面的脚本里有 mount(); refresh();，而 refresh 会为每个源发一次探测。
探测要出网，且每次调用都持插件写锁，于是 21 次串行排队；冷启动实测 100 秒，
有缓存后 22 秒。WebUI 的首屏就这么被堵住了。
改动：
- 页面加载时不再自动探测。运维没要求的余额不值得用它换首屏。
- 改为先渲染上次的快照（pluginAPI.fetchState），标题栏标注"快照 HH:MM（点刷新
取实时）"。点刷新才真探测。这样打开页面立刻有内容，实时数字在后面更新。
- billing 页面同样有 refresh()，但它只读本机 state（1.5ms），无害，保留。
判据：首屏填充时间实测 19.1s → 1.0s，且首屏请求里不再出现 collect_source。
Co-Authored-By: ModelRouter <noreply@modelrouter.dev>
(cherry picked from commit c17a851ec1)
(cherry picked from commit 9823773330)
|
2026-10-04 14:50:46 +08:00 |
|
