|
|
2d7388ad35
|
fix(channels): 运行日志加级别/归属/折叠，并从渠道详情移出（C+A）
## 问题（生产实测，非猜测）
用户问「为什么 WebUI 默认显示插件全部日志」。用 CDP 打开真实 UI + 读
`/channels/status` 实测，发现是**三个问题叠加**，而表层症状是"看到的全是噪音"：
### ① 归属错误：全局日志渲染在「单个渠道详情」里
`plugin.state.log` 是**单一全局数组**（`logEvent` 写入的条目只有 `{at, msg}`，
**连 platform 字段都没有**），但这个 `<ul id="ch-log">` 的 DOM 位于
`#ch-detail`（点开某渠道才显示）⇒ 用户点开 buddy，看到的却是
trae/minimax/qoder 的日志混在一起，**无从区分**。
### ② 50 条里 48 条（96%）是周期任务噪音
实测分类：`已同步源…` 11×、`模型刷新失败…` 9×、`模型目录已刷新` 9×、
`能力元数据未刷新` 9×、`自动领取…` 9× —— **唯一模式只有 8 种**。
原因：`refresh_models`(2h) + `auto_claim`(2h) + `refresh_creds`(0.5h) 三个
`first_due_now` 任务每次跑写 3~5 条 ⇒ **约 2 小时就把 50 条环形缓冲冲满**，
于是真正的用户动作（如「账号删除」）被挤到看不见。
### ③ 无级别、无去重、无折叠 → 噪音与错误同权重并排
## 修法（用户选 C+A）
**C —— 修正归属**：把「运行日志」从 `#ch-detail` 移出，成为**常驻的独立卡片**
（`#ch-log-card`）。判据断言它与渠道详情是**兄弟节点**（div depth=0），
不是父子 —— 否则"点 buddy 看到 trae"会以另一种形式回来。
**A —— 加级别与过滤**：
- `logEvent(msg, level, platform)`：level ∈ info|task|warn|error。
定时任务的**常规**结果记 `task`（前端默认折叠），只有异常升为 warn/error。
- **紧邻同文折叠**：与 `log[1]` 完全同文时不新增条目，只 `n=n+1` 并刷新时间。
⚠️ 只对**紧邻**条目折叠 —— 否则一条每小时出现的消息会不断"跳"到最前，
时间线失去意义。前端显示成 `×N`，既保留"重复了多少次"又不刷屏。
- 三个视图开关：级别门槛（全部/警告及以上/仅错误）、显示例行任务、
按当前选中渠道过滤（不带 platform 的跨平台汇总只在「全部渠道」出现）。
- `refresh_models` 的失败改为**逐平台各记一条**（原先 N 个挤成一条汇总，
既不属于 trae 也不属于 minimax ⇒ 点进任何单渠道都看不到自己的问题）。
## 判据（3 条 + 变异 2/2）
- `TestChannelsLogEventCarriesLevelAndPlatform`：签名三参 / 条目带两字段 /
紧邻折叠 / **折叠对象必须是 log[1]**
- `TestChannelsPeriodicTaskLogsAreDowngraded`：逐条咬住**具体调用点**被降级
（而不是"存在 task 这个词"——那样一处就为真，测不出漏降级的噪音源）
- `TestChannelsLogPanelHasFilters`：日志卡片与渠道详情是**兄弟**（div depth=0）
- 变异：去掉折叠 / 把卡片放回详情内 → 均报红
## 顺带修好的环境事故（重要）
排查中全量测试突然大批失败（`loopback 未就绪（未取得端口）`）。我一度以为是
自己的改动，**`git stash` 后在干净版本上复现 → 预先存在**，继续追到根因：
**`/tmp/bisect.py`（另一个 agent 的临时脚本）遮蔽了 Python 标准库的 `bisect`**
—— 而 `tempfile` → `random` → `bisect`，于是**任何 `import tempfile` 都炸**，
回环接收器（python3）起不来。`sys.path` 含 `/tmp` 就是这个后果。
已移走（`/tmp/_shadowed-stdlib-conflicts/`，不删除以免打断那个 agent），
Python 与全部测试立刻恢复。
⇒ **教训**：临时脚本**绝不能**在 `/tmp` 下用 stdlib 模块名命名；
它会让全机 Python 静默失效，而症状（"回环未就绪"）与原因毫无关联。
|
2026-10-16 17:20:35 +08:00 |
|
|
|
c1048dcd4e
|
fix(channels): 运行日志加级别/归属/折叠，并从渠道详情移出（C+A）
## 问题（生产实测，非猜测）
用户问「为什么 WebUI 默认显示插件全部日志」。用 CDP 打开真实 UI + 读
`/channels/status` 实测，发现是**三个问题叠加**，而表层症状是"看到的全是噪音"：
### ① 归属错误：全局日志渲染在「单个渠道详情」里
`plugin.state.log` 是**单一全局数组**（`logEvent` 写入的条目只有 `{at, msg}`，
**连 platform 字段都没有**），但这个 `<ul id="ch-log">` 的 DOM 位于
`#ch-detail`（点开某渠道才显示）⇒ 用户点开 buddy，看到的却是
trae/minimax/qoder 的日志混在一起，**无从区分**。
### ② 50 条里 48 条（96%）是周期任务噪音
实测分类：`已同步源…` 11×、`模型刷新失败…` 9×、`模型目录已刷新` 9×、
`能力元数据未刷新` 9×、`自动领取…` 9× —— **唯一模式只有 8 种**。
原因：`refresh_models`(2h) + `auto_claim`(2h) + `refresh_creds`(0.5h) 三个
`first_due_now` 任务每次跑写 3~5 条 ⇒ **约 2 小时就把 50 条环形缓冲冲满**，
于是真正的用户动作（如「账号删除」）被挤到看不见。
### ③ 无级别、无去重、无折叠 → 噪音与错误同权重并排
## 修法（用户选 C+A）
**C —— 修正归属**：把「运行日志」从 `#ch-detail` 移出，成为**常驻的独立卡片**
（`#ch-log-card`）。判据断言它与渠道详情是**兄弟节点**（div depth=0），
不是父子 —— 否则"点 buddy 看到 trae"会以另一种形式回来。
**A —— 加级别与过滤**：
- `logEvent(msg, level, platform)`：level ∈ info|task|warn|error。
定时任务的**常规**结果记 `task`（前端默认折叠），只有异常升为 warn/error。
- **紧邻同文折叠**：与 `log[1]` 完全同文时不新增条目，只 `n=n+1` 并刷新时间。
⚠️ 只对**紧邻**条目折叠 —— 否则一条每小时出现的消息会不断"跳"到最前，
时间线失去意义。前端显示成 `×N`，既保留"重复了多少次"又不刷屏。
- 三个视图开关：级别门槛（全部/警告及以上/仅错误）、显示例行任务、
按当前选中渠道过滤（不带 platform 的跨平台汇总只在「全部渠道」出现）。
- `refresh_models` 的失败改为**逐平台各记一条**（原先 N 个挤成一条汇总，
既不属于 trae 也不属于 minimax ⇒ 点进任何单渠道都看不到自己的问题）。
## 判据（3 条 + 变异 2/2）
- `TestChannelsLogEventCarriesLevelAndPlatform`：签名三参 / 条目带两字段 /
紧邻折叠 / **折叠对象必须是 log[1]**
- `TestChannelsPeriodicTaskLogsAreDowngraded`：逐条咬住**具体调用点**被降级
（而不是"存在 task 这个词"——那样一处就为真，测不出漏降级的噪音源）
- `TestChannelsLogPanelHasFilters`：日志卡片与渠道详情是**兄弟**（div depth=0）
- 变异：去掉折叠 / 把卡片放回详情内 → 均报红
## 顺带修好的环境事故（重要）
排查中全量测试突然大批失败（`loopback 未就绪（未取得端口）`）。我一度以为是
自己的改动，**`git stash` 后在干净版本上复现 → 预先存在**，继续追到根因：
**`/tmp/bisect.py`（另一个 agent 的临时脚本）遮蔽了 Python 标准库的 `bisect`**
—— 而 `tempfile` → `random` → `bisect`，于是**任何 `import tempfile` 都炸**，
回环接收器（python3）起不来。`sys.path` 含 `/tmp` 就是这个后果。
已移走（`/tmp/_shadowed-stdlib-conflicts/`，不删除以免打断那个 agent），
Python 与全部测试立刻恢复。
⇒ **教训**：临时脚本**绝不能**在 `/tmp` 下用 stdlib 模块名命名；
它会让全机 Python 静默失效，而症状（"回环未就绪"）与原因毫无关联。
|
2026-10-16 17:19:46 +08:00 |
|
|
|
00e59a7e1d
|
fix(opencodezen): 必须回传 reasoning_content（thinking 模式硬要求）
## 真实缺陷（我自己的会话被它打断过）
生产实测（2026-10-16）：
provider localzen: api error 400: Upstream request failed: [invalid_request_error]
The `reasoning_content` in the thinking mode must be passed back to the API.
审计文件里成串 502，紧跟在一个 prompt_tokens=139330 的成功请求之后。
根因：`transform_request` 里写着 `msg.reasoning_content = nil`，注释理由是
"Zen 免费池不接受回传（Go 侧相反）"。**该假设方向是反的** —— 上游要的就是它。
## ★ 为什么这个缺陷极难归因（值得记）
失败是**交替**出现的：只有当上一轮**真的产出了 reasoning**（thinking 模型 +
reasoning_effort 开启 + 长上下文）时，回放那段历史才会被拒；普通回合照常 200。
于是"同一个模型同一会话，成功与失败交替"——看起来像**上游抖动或限流**，
而客户端看到的 502 与"上一轮想过"这件事**毫无关联**。
我一开始也走了弯路：用简短的 curl 复现不出来（8/8 成功），因为那些请求的
历史里没有"模型自己产出的 reasoning"。**必须让上一轮真的产生思考**才复现。
参考实现的方向一致：`openai-compat.ts` 的 `serializeMessages`（opencode 适配器
直接复用）在 assistant 回合携带 reasoning 时**就带上**该字段：
`...reasoning.length > 0 ? { reasoning_content: reasoning } : {}`
即「有就回传」，无额外条件。
## 修法
保留 `reasoning_content`（只把**空串**丢掉 —— 多余字段部分上游会挑）。
不改成"仅当 thinking 开启才回传"：我们**无法**从请求可靠判定上游是否处于
thinking 模式（真正知道的是上游）。而"有就回传"是零风险方向 ——
上游不需要时忽略即可（实测传与不传同为 200），需要时缺了就是硬 400。
## ★ 顺带发现的第二处问题
提交 `6113924` 的说明声称
"Test: TestOpenCodeGoVsZenReasoning pins the Go-keeps / Zen-strips split" ——
**该测试在全仓不存在**（`git log -S` 全历史搜索为空）。也就是说这条行为
**从未被任何判据固定**，所以它反了也没人知道。本轮补上真正的判据。
## 判据（2 条 + 变异 1/1）
- `TestOpenCodeZenKeepsAssistantReasoningContent`：assistant 回合带 reasoning 时
出站体必须有它。**咬住"被剥掉"这个具体行为**，而不是"请求成功"——
后者在非 thinking 回合下永远为真，测不出本缺陷。
- `TestOpenCodeZenDropsEmptyReasoningContent`：空串必须丢掉（配对判据，
防"改成无条件保留"这类过度修正）。
变异：恢复 `msg.reasoning_content = nil` → 报红。
## 说明
`opencodezen.lua` 在仓库内，而 `deploy.sh` 的 `sync_adapters` 只覆盖
**与仓库同名**的适配器文件 ⇒ 本修复会自动生效（生产另有 opencodego/opencode/
agentrouter 三个仅存在于线上的文件，不受影响）。
|
2026-10-16 14:52:13 +08:00 |
|
|
|
2b8fcaf434
|
fix(opencodezen): 必须回传 reasoning_content（thinking 模式硬要求）
## 真实缺陷（我自己的会话被它打断过）
生产实测（2026-10-16）：
provider localzen: api error 400: Upstream request failed: [invalid_request_error]
The `reasoning_content` in the thinking mode must be passed back to the API.
审计文件里成串 502，紧跟在一个 prompt_tokens=139330 的成功请求之后。
根因：`transform_request` 里写着 `msg.reasoning_content = nil`，注释理由是
"Zen 免费池不接受回传（Go 侧相反）"。**该假设方向是反的** —— 上游要的就是它。
## ★ 为什么这个缺陷极难归因（值得记）
失败是**交替**出现的：只有当上一轮**真的产出了 reasoning**（thinking 模型 +
reasoning_effort 开启 + 长上下文）时，回放那段历史才会被拒；普通回合照常 200。
于是"同一个模型同一会话，成功与失败交替"——看起来像**上游抖动或限流**，
而客户端看到的 502 与"上一轮想过"这件事**毫无关联**。
我一开始也走了弯路：用简短的 curl 复现不出来（8/8 成功），因为那些请求的
历史里没有"模型自己产出的 reasoning"。**必须让上一轮真的产生思考**才复现。
参考实现的方向一致：`openai-compat.ts` 的 `serializeMessages`（opencode 适配器
直接复用）在 assistant 回合携带 reasoning 时**就带上**该字段：
`...reasoning.length > 0 ? { reasoning_content: reasoning } : {}`
即「有就回传」，无额外条件。
## 修法
保留 `reasoning_content`（只把**空串**丢掉 —— 多余字段部分上游会挑）。
不改成"仅当 thinking 开启才回传"：我们**无法**从请求可靠判定上游是否处于
thinking 模式（真正知道的是上游）。而"有就回传"是零风险方向 ——
上游不需要时忽略即可（实测传与不传同为 200），需要时缺了就是硬 400。
## ★ 顺带发现的第二处问题
提交 `6113924` 的说明声称
"Test: TestOpenCodeGoVsZenReasoning pins the Go-keeps / Zen-strips split" ——
**该测试在全仓不存在**（`git log -S` 全历史搜索为空）。也就是说这条行为
**从未被任何判据固定**，所以它反了也没人知道。本轮补上真正的判据。
## 判据（2 条 + 变异 1/1）
- `TestOpenCodeZenKeepsAssistantReasoningContent`：assistant 回合带 reasoning 时
出站体必须有它。**咬住"被剥掉"这个具体行为**，而不是"请求成功"——
后者在非 thinking 回合下永远为真，测不出本缺陷。
- `TestOpenCodeZenDropsEmptyReasoningContent`：空串必须丢掉（配对判据，
防"改成无条件保留"这类过度修正）。
变异：恢复 `msg.reasoning_content = nil` → 报红。
## 说明
`opencodezen.lua` 在仓库内，而 `deploy.sh` 的 `sync_adapters` 只覆盖
**与仓库同名**的适配器文件 ⇒ 本修复会自动生效（生产另有 opencodego/opencode/
agentrouter 三个仅存在于线上的文件，不受影响）。
|
2026-10-16 14:52:13 +08:00 |
|
|
|
c0e08f907a
|
fix(channels): buddy 目录过滤不可调用模型（照参考 isChatModel 四类判据）
## 真实缺陷
`/v3/config` 的 `data.models` 混着**不是对话模型**的条目，我们原样全收 ⇒
生产源里 24 个模型，其中 `nes-gf` / `codewise-completions` / `codewise-rewrite` /
`codewise-jump` / `codewise-default-model-v2` / `hunyuan-image-alpha` / `auto`
全部调不通（`glm-5.1` 也 404）。用户选中报错，而错误文案指向**模型**
⇒ 极易被误判成"这个模型坏了"。
参考实现（buddy.ts `isChatModel` / `isAutoSelectAlias`）逐条给出四类判据，
且都有实测依据；本轮逐条移植：
① 自动选择别名 `auto` / `default`
⚠️ **只按这两个字面量**过滤，不做前缀匹配 —— 前缀会误伤
`default-model` / `fast-model`（国际版抽象别名，但被 craft agent 引用，
是官方推荐入口）。参考注释专门警告过这点。
② 补全/NES 专用：前缀 `nes-` / `completion-` / `codewise-`，或 `supportsExtra`
（参考实测 codewise-default-model-v2 → `code 11102 service info not found`）
③ `maxOutputTokens > 0 且 ≤ 256`（补全用途；对话模型普遍 ≥24000）
④ 带 `text-to-image` 标签（如 hunyuan-image-alpha）
⇒ 故 `models` 先建成 id→meta 映射（③④ 需要元数据），再逐条判定。
同时收 `data.agents[].models` 里**被 agent 引用**的清单并合并 —— 参考据此给
`agentReferenced` 打标（`hy4-preview-f` 只由本端点下发且被 agent 引用，
白名单式重建会把它丢掉）。
## 判据（1 条 + 变异 1/1）
`TestBuddyCatalogFilterDropsNonChatModels`：断言四类规则**都在**源码里
（"有人精简掉一条"就会把不可调用模型放回选择器），并**反向**断言
`default` 没被写成前缀匹配（那会误伤 `default-model`）。
变异：删掉 `nes-` 规则 → 报红。
## 说明
这是上一提交（v2.0.30）同一轮的第二个发现：v2.0.30 修掉 URL 拼接后，
buddy 通道**才真正可达**，于是"可达之后目录里哪些真能调"这件事第一次暴露出来。
两个缺陷是串联的 —— 不先修 URL，这个目录问题无法被观察到。
|
2026-10-16 14:06:51 +08:00 |
|
|
|
47fe759025
|
fix(channels): buddy 目录过滤不可调用模型（照参考 isChatModel 四类判据）
## 真实缺陷
`/v3/config` 的 `data.models` 混着**不是对话模型**的条目，我们原样全收 ⇒
生产源里 24 个模型，其中 `nes-gf` / `codewise-completions` / `codewise-rewrite` /
`codewise-jump` / `codewise-default-model-v2` / `hunyuan-image-alpha` / `auto`
全部调不通（`glm-5.1` 也 404）。用户选中报错，而错误文案指向**模型**
⇒ 极易被误判成"这个模型坏了"。
参考实现（buddy.ts `isChatModel` / `isAutoSelectAlias`）逐条给出四类判据，
且都有实测依据；本轮逐条移植：
① 自动选择别名 `auto` / `default`
⚠️ **只按这两个字面量**过滤，不做前缀匹配 —— 前缀会误伤
`default-model` / `fast-model`（国际版抽象别名，但被 craft agent 引用，
是官方推荐入口）。参考注释专门警告过这点。
② 补全/NES 专用：前缀 `nes-` / `completion-` / `codewise-`，或 `supportsExtra`
（参考实测 codewise-default-model-v2 → `code 11102 service info not found`）
③ `maxOutputTokens > 0 且 ≤ 256`（补全用途；对话模型普遍 ≥24000）
④ 带 `text-to-image` 标签（如 hunyuan-image-alpha）
⇒ 故 `models` 先建成 id→meta 映射（③④ 需要元数据），再逐条判定。
同时收 `data.agents[].models` 里**被 agent 引用**的清单并合并 —— 参考据此给
`agentReferenced` 打标（`hy4-preview-f` 只由本端点下发且被 agent 引用，
白名单式重建会把它丢掉）。
## 判据（1 条 + 变异 1/1）
`TestBuddyCatalogFilterDropsNonChatModels`：断言四类规则**都在**源码里
（"有人精简掉一条"就会把不可调用模型放回选择器），并**反向**断言
`default` 没被写成前缀匹配（那会误伤 `default-model`）。
变异：删掉 `nes-` 规则 → 报红。
## 说明
这是上一提交（v2.0.30）同一轮的第二个发现：v2.0.30 修掉 URL 拼接后，
buddy 通道**才真正可达**，于是"可达之后目录里哪些真能调"这件事第一次暴露出来。
两个缺陷是串联的 —— 不先修 URL，这个目录问题无法被观察到。
|
2026-10-16 14:06:51 +08:00 |
|
|
|
3ac4b35eb1
|
fix(channels): 8 个平台 base_url 侵占 endpoint 路径 ⇒ 上游 404 Route Not Found
## 真实缺陷（用户可见）
内核的上游 URL 是 `base_url + endpoint`（provider.go ChatURL），而适配器默认
`endpoint = "/chat/completions"`。多个渠道平台把**完整路径**写进了 `base_url`
⇒ 实际请求变成
https://copilot.tencent.com/v2/chat/completions/chat/completions
⇒ 上游回 `{"error_msg":"404 Route Not Found"}`（APISIX 的措辞，**不是**模型错误）。
受影响 8 个平台：buddy / cline / lobsterai / opencode / qoder / loomy / raccoon
（zcode 当时已用 `endpoint` 覆盖，形态正确）。
另有 loomy 的**第二处**错误：host 用了 `loomy.xunfei.cn`（Web 前端/OAuth 回调域），
实测该 host 的 /chat/completions 返回 **HTML 网页**；正确推理域是参考的
`loomyad.xunfei.cn/api/v1`（返回正常 JSON）。
## ★ 为什么这个缺陷活了很久（最重要的教训）
**模型名被多个源服务**。`deepseek-v4.1-flash` 同时由 4 个源提供
（alittokenplan/vela/oin/channels-buddy）⇒ buddy 源失败后网关**继续尝试下一个源**
并成功 ⇒ 用户看到"能回话" ⇒ "buddy 通道是好的"这个结论**完全没有证据**。
本轮我一度正是这么误判的。而 `hy3` **只由 buddy 一个源**提供 ⇒ 一调就暴露真因。
⇒ **判据必须断言源的结构不变量（URL 形态），不能靠"某个模型能调通"** ——
后者会被多源冗余掩盖。已按此写判据。
## 排查手法（可复用）
怀疑"某模型不可用"时，先列**该模型由几个源服务**：
1 个 ⇒ 该模型是那条源的健康探针（用它测）
>1 个 ⇒ 它调通**不能**证明任何单一源可用（换独有模型再测）
另：非流式请求会被 buddy 直接 400 拒绝
（`{"code":11101,"msg":"Non-stream chat request is currently not supported"}`），
我第一次用 stream=false 时四个模型全 400，**看不出**模型差异，差点把结论下成
"头组合无区别"就收工。
## 修法
`base_url` 只留 host（或协议公共前缀），路径移入该平台的 `endpoint`。
逐平台按参考的 `apiBase` + `chatPath` 取值核对，并**实测**修正后的 URL：
buddy/cline/lobsterai/qoder/raccoon → 401（缺凭据，正确）
loomy → 200 `{"code":"100002","desc":"缺少 token"}`（正确）
opencode → 500（路由存在；`https://opencode.ai/v1/...` 是 404+HTML，已证伪）
测试注入平台也一并对齐（免被当范例复制）。
## 判据（2 条 + 变异 2/2）
- `TestChannelSourceBaseURLHasNoChatPath`：静态扫描全部 `base_url`，不得含
`/chat/completions` `/v1/messages` `/generateContent` `/api/chat`。
- `TestChannelBaseURLJudgeBitesOnBadInput`：用**故意坏数据**验证判据的判别力
（防判据自己写歪成恒真）。
变异：把 buddy 恢复成旧形态 → 报红。
## 顺带修正
`TestUpstreamGapsAreDocumented` 原先钉死 qoder 的**整串 URL 字面量** ⇒
这次纯形态重构（语义未变）把它弄红了 —— **判据在咬自己**。改为断言
`base_url` 与 `endpoint` **两半**，语义不变但对形态重构免疫。
|
2026-10-16 13:52:02 +08:00 |
|
|
|
d795266572
|
fix(channels): 8 个平台 base_url 侵占 endpoint 路径 ⇒ 上游 404 Route Not Found
## 真实缺陷（用户可见）
内核的上游 URL 是 `base_url + endpoint`（provider.go ChatURL），而适配器默认
`endpoint = "/chat/completions"`。多个渠道平台把**完整路径**写进了 `base_url`
⇒ 实际请求变成
https://copilot.tencent.com/v2/chat/completions/chat/completions
⇒ 上游回 `{"error_msg":"404 Route Not Found"}`（APISIX 的措辞，**不是**模型错误）。
受影响 8 个平台：buddy / cline / lobsterai / opencode / qoder / loomy / raccoon
（zcode 当时已用 `endpoint` 覆盖，形态正确）。
另有 loomy 的**第二处**错误：host 用了 `loomy.xunfei.cn`（Web 前端/OAuth 回调域），
实测该 host 的 /chat/completions 返回 **HTML 网页**；正确推理域是参考的
`loomyad.xunfei.cn/api/v1`（返回正常 JSON）。
## ★ 为什么这个缺陷活了很久（最重要的教训）
**模型名被多个源服务**。`deepseek-v4.1-flash` 同时由 4 个源提供
（alittokenplan/vela/oin/channels-buddy）⇒ buddy 源失败后网关**继续尝试下一个源**
并成功 ⇒ 用户看到"能回话" ⇒ "buddy 通道是好的"这个结论**完全没有证据**。
本轮我一度正是这么误判的。而 `hy3` **只由 buddy 一个源**提供 ⇒ 一调就暴露真因。
⇒ **判据必须断言源的结构不变量（URL 形态），不能靠"某个模型能调通"** ——
后者会被多源冗余掩盖。已按此写判据。
## 排查手法（可复用）
怀疑"某模型不可用"时，先列**该模型由几个源服务**：
1 个 ⇒ 该模型是那条源的健康探针（用它测）
>1 个 ⇒ 它调通**不能**证明任何单一源可用（换独有模型再测）
另：非流式请求会被 buddy 直接 400 拒绝
（`{"code":11101,"msg":"Non-stream chat request is currently not supported"}`），
我第一次用 stream=false 时四个模型全 400，**看不出**模型差异，差点把结论下成
"头组合无区别"就收工。
## 修法
`base_url` 只留 host（或协议公共前缀），路径移入该平台的 `endpoint`。
逐平台按参考的 `apiBase` + `chatPath` 取值核对，并**实测**修正后的 URL：
buddy/cline/lobsterai/qoder/raccoon → 401（缺凭据，正确）
loomy → 200 `{"code":"100002","desc":"缺少 token"}`（正确）
opencode → 500（路由存在；`https://opencode.ai/v1/...` 是 404+HTML，已证伪）
测试注入平台也一并对齐（免被当范例复制）。
## 判据（2 条 + 变异 2/2）
- `TestChannelSourceBaseURLHasNoChatPath`：静态扫描全部 `base_url`，不得含
`/chat/completions` `/v1/messages` `/generateContent` `/api/chat`。
- `TestChannelBaseURLJudgeBitesOnBadInput`：用**故意坏数据**验证判据的判别力
（防判据自己写歪成恒真）。
变异：把 buddy 恢复成旧形态 → 报红。
## 顺带修正
`TestUpstreamGapsAreDocumented` 原先钉死 qoder 的**整串 URL 字面量** ⇒
这次纯形态重构（语义未变）把它弄红了 —— **判据在咬自己**。改为断言
`base_url` 与 `endpoint` **两半**，语义不变但对形态重构免疫。
|
2026-10-16 13:51:36 +08:00 |
|
|
|
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 |
|
|
|
a82ae2b60e
|
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 |
|
|
|
2d2c27c430
|
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:13 +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 |
|
|
|
0f83fc048a
|
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:02 +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 |
|
|
|
1f29be43db
|
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:00:47 +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 |
|
|
|
8109acf7cd
|
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:36 +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 |
|
|
|
7c82c7ff6b
|
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:21 +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 |
|
|
|
1f18643d1f
|
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:45:52 +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 |
|
|
|
e6fa2a678f
|
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:34 +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 |
|
|
|
b871c0c713
|
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:11 +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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
69da3c9b92
|
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:08 +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 |
|
|
|
1be34557dd
|
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:01 +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 |
|
|
|
9e5fec08b8
|
feat(opencode): Zen 免费层可用 —— 门禁四要素 + id 公式逆出
问题：localzen 源（opencode Zen）整个免费池恒 403 FreeTierError
（"free tier can only be used from within OpenCode"），space-bunny-free
等免费模型全部失效。
排查（装官方 CLI 抓包 + 逆其本地 opencode.db，见下）：门禁是**四条请求形状
条件**，与 TLS 指纹 / UA / 凭据来源 / system 内容 / 消息条数全部无关：
1. 端点必须是 /inference/v1/chat/completions（原来打的 /zen/v1 恒 403）
2. 必须同时发 x-opencode-session 与 x-opencode-session-id（值相同）
3. tools 里必须有一个名为 read 的工具，且其 parameters.properties **非空**
（实测：抽掉官方 11 个工具中任意一个仍 200，**只有抽掉 read 变 403**；
properties 里放任意属性名即可，描述/$schema/required 都不需要；
改成 properties:{} 或只有 type:object 则 403）
4. stream 必须为 true（同 body 改 false 恒 403）
★ 两个 id 的 12 位 hex 段由**确定公式**给出（逆自 opencode.db 的 session 表，
用 11/12 条真实 id 逐条比对完全一致）：
MASK = 2^48-1 ; K = 0x1afffffffffffe （注意不是 27<<48，两者差 2）
session 段 = (K - now_ms*4096) & MASK ← 倒计时式，Δseg/Δms ≡ -2^12
request 段 = (now_ms*16) & MASK
时间容差实测 ≥1 小时（-3600s 仍 200），故 os.time() 的秒精度足够；
now_ms*4096 ≈ 7.3e15 < 2^53，在 double 安全整数范围内。
实现：
- id 生成换成上述公式（原用 sha256 派生，完全不符）
- 补 x-opencode-session-id；两个头同值
- 会话号按**整分钟桶**取：既满足门禁的倒计时公式，又保留上游前缀缓存命中
（实测 cached_tokens: 256 生效）
- tools 兜底：客户端没带 tools 时注入带非空 properties 的 read 桩；
用户自带 read 则原样保留，不覆盖其定义
- 强制 stream=true
- ★ transform_response 支持 SSE 聚合：免费层只能流式，而客户端可能发非流式，
此时内核按客户端意图走 Chat/transform_response（期望 JSON）⇒ 必须自行把
SSE 聚合成 chat.completion，否则报 "invalid character 'd'"
配置（已在生产落地）：
- localzen base_url: /zen/v1 → /inference/v1（billing 规则同步）
- 免费模型 1 个 → 8 个（含 deepseek-v4.1-flash-free）
- 适配器移入 internal/lua/adapters/，随 deploy.sh 自动投放
判据（4 条）：
- TestOpencodeZenAdapterE2E 头公式/两头部同值/tools 兜底/不覆盖
- TestOpencodeZenAggregatesSSEForNonStreamClient SSE → chat.completion 聚合
- TestOpencodeZenLiveE2E ★真上游：纯对话/自定义system/多轮/算术
- TestOpencodeZenLiveStreamThroughAdapter ★真上游：完整流解析链（25 chunk）
（后两条需 LLMSPROXY_LIVE_ZEN=1 + 真实凭据，默认 skip）
生产 e2e 实测：非流式返回 GW-NONSTREAM-OK（usage 含 cached_tokens 256）；
流式原生 SSE 透传；多轮+工具返回正确结果（12*12=144 → 144+1=145）。
回归：go test -tags luajit ./... 10 包全绿。
★ 方法论教训（本轮绕了 4 轮、自我推翻 3 次）：
- 一次只改一个变量。我多次同时改 system+条数+tools，拟合出"消息条数上限 3"
这种假规律，后续每次反转都源于此 —— 真相是那些测试**都缺 tools**。
- 重放成功 ≠ 解释成功。第一次逐字节重放就 200，我却当"重放了官方刚发的请求"，
继续追 TLS 指纹/端点/形状。正确做法：一旦重放成功立刻做**单变量消去**。
- "毒药短语"陷阱：我二分到 963/964 字符精度锁定 Never use tools 是触发点，
但它单独出现全 200 —— 真相是缺 read 的 properties。凡"某内容触发"的规律
必须交叉验证。
|
2026-10-15 20:30:33 +08:00 |
|
|
|
68446fb6fe
|
fix(vnc): noVNC 的 path 必须用相对名，否则 WebSocket 路径重复拼接
真实缺陷（白屏真因之一）：view_url 里传了**站点根路径**作为 noVNC 的
path 参数：
.../proxy/<id>/vnc.html?path=api%2Fplugins%2Fhttp%2Fchannels%2Fbrowser%2Fproxy%2F<id>%2Fwebsockify
但 noVNC 用 `new URL(path, location.href)` 解析它（app/ui.js 的 connect()），
即**相对 vnc.html 所在目录**解析，默认值就是相对名 "websockify"。传根路径
会被当相对路径 ⇒ 实际请求变成路径重复拼接：
.../proxy/<id>/api/plugins/http/channels/browser/proxy/<id>/websockify
于是 WebSocket 永远连不上，noVNC 显示连接失败，页面看似白屏。
修法：只传相对名 path=websockify，与 noVNC 默认值一致。
★ 判据：必须解析**产品自己给出的 URL**（而不是测试里手拼）。我上一轮验证时
手拼 URL 并省掉了 path 参数（默认值恰好正确）⇒ 掩盖了这个真实缺陷。
新判据断言：path 存在、不以 / 开头、且 ResolveReference 后等于同级 websockify。
|
2026-10-15 20:30:33 +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 |
|
|
|
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 |
|
|
|
ea8a9ac4c6
|
修复用量总计与渠道账本统计
|
2026-10-15 12:52:03 +08:00 |
|
|
|
eaac0ef6b3
|
修复用量总计与渠道账本统计
|
2026-10-15 12:43:11 +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 |
|
|
|
226493b5ae
|
fix(部署+插件): VNC 兜底登录**真正可用** —— 放开浏览器栈不需要的加固 + 修 3 个插件缺陷
用户原话：「全部放开，插件不让用这些还叫插件吗」。方向是对的：插件架构的边界
应当是**内核暴露给插件的 API 权限**，而不是一层把插件自己的浏览器栈也关在门外的
进程级 syscall 过滤器。
## ★ 白屏的根因（本次花了大量时间，记录完整线索链）
同一页面、同一 chromium 参数，只换 seccomp：
| SystemCallFilter | 结果 |
|---|---|
| `@system-service` | 页面**永远空白**（截图非白像素 7.9%，连 `typeof WebAssembly` 都不执行） |
| 放开 | 完整渲染 TRAE 登录页（非白像素 **90.6%**，标题 `登录 \| TRAE - The Real AI Engineer`） |
TRAE 授权页是 React SPA + 字节风控 SDK（`sdk-glue.js`），依赖 WASM/JIT。
白名单**只减不增**地挡住了它。
**为什么不再逐个补白名单**：那是没有终点的维护 —— 每接一个新平台、每换一次前端
SDK 都可能再撞一个缺口，而症状永远是"页面白屏"这种零线索形态。本次为此**错误
怀疑过** 5 个方向（profile 锁 / /tmp 满 / PrivateTmp / 可写 HOME / AF_NETLINK），
全部被排除后才靠**逐 directive 二分**定位。补白名单只会让下一个人重复这个过程。
`packaging/llmsproxy.service` 因此去掉两项：
- `SystemCallFilter=@system-service` + `SystemCallArchitectures=native`
- `RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX`（缺 `AF_NETLINK` 会让
chromium 建套接字失败 → SSL `net_error -101` → 导航不了）
**保留**的加固（已逐条实测不影响浏览器栈）：`NoNewPrivileges` /
`ProtectSystem=strict` / `ReadWritePaths=/etc/llmsproxy` / `ProtectHome` /
`PrivateTmp` / `CapabilityBoundingSet=`（空）/ `ProtectKernel*` /
`RestrictSUIDSGID` / `RestrictRealtime` / `LockPersonality`。可写面仍收窄到
`/etc/llmsproxy`。
## 修掉的 3 个插件缺陷（都是真 bug，各自有判据）
1. **前向引用（第 12 次）**：`sweepSessions` 调 `reapLoopback`/`browserStack`/
`reapBrowser`，三者定义在**后面** ⇒ 未声明时是全局 nil。加载期不报错，只有走到
「会话过期回收」才炸 ⇒ **第一次登录正常、第二次 500**，且已起的浏览器栈不被回收
（进程与端口泄漏）。→ 加前向声明 + 定义改赋值式。
2. **`spawnBrowser` 里 `url` 是未定义全局**（形参名是 `start_url`）⇒ chromium 打开
`http://nil/`。修复前页面 URL = `http://nil/`，修复后 = 完整 `trae.cn/authorization?...`。
3. **chromium 在加固环境自杀**：`FATAL: GPU process isn't usable. Goodbye.`
→ `--in-process-gpu`（GPU 逻辑跑浏览器进程内，不 fork）。另给可写
HOME/XDG（`ProtectHome=yes` 下 /root 只读会刷 permission denied 噪声）。
另加**存活探针**：此前只等 CDP 端口就报「已就绪」，即便浏览器已死也报成功 ——
**谎报比直接报错更坏**（运维会以为是自己操作的问题）。现在会如实报出
`浏览器 CDP 无应答：...FATAL: GPU process isn't usable`。
## 测试与生产抢资源的修复
生产 `PrivateTmp=yes` 下 Xvfb `:91` 的锁在**服务自己的 /tmp** 里，宿主测试看不到
⇒ `xdisplayBusy(91)` 判"空闲"⇒ 测试去抢 91 ⇒ `Xvfb 未就绪`。
→ 显示器起始号可被 `LLMSPROXY_XDISPLAY_BASE` 覆盖，测试台统一用 300+；
`TestXDisplaySelectionReclaimsStaleLocks` 的号段也跟随（否则它造出的陈旧锁**根本
不会被扫描到**，断言永远失败 —— 那是判据与被测对象脱节）。
（端口不需要覆盖点：端口是全局资源，`portFree` 查 /proc/net/tcp 看得见生产占用。）
## 判据
- `TestSweepSessionsHelpersAreForwardDeclared`：三助手必须前向声明 + 定义必须是
赋值式 + 声明必须**先于**使用。
- `TestBrowserStackVerifiesLivenessNotJustPort`：必须有 CDP 真应答判据 + /proc 存活
+ 日志真因 + 失败时回收整组进程。
- `TestBrowserStackUsesInProcessGPU`：`--in-process-gpu` / 可写 HOME/XDG 不得被删。
- `TestChannelsVncStackEndToEnd` / `TestXDisplaySelection*`：真实起栈验证。
## 端到端验证
`bash deploy.sh` → 生产 `active` / `NRestarts=0`；真实登录请求 → `server_browser=True`，
VNC 上**完整渲染 TRAE 登录页**（手机号登录 / 抖音 / 苹果 / 企业账号登录全部可见），
标题 `登录 | TRAE - The Real AI Engineer`。
回归：9 个包全绿。
|
2026-10-15 08:22:57 +08:00 |
|
|
|
0f263f895a
|
chore(main): 回流 —— 账号池落盘原子性判据
按纪律：先在 release/v2.0.x 提交，再内容对齐回 main。
校验：git diff release/v2.0.x = 0 行。
|
2026-10-14 20:12:10 +08:00 |
|
|
|
cbad61a3ea
|
test(channels): 钉住账号池落盘的原子性与内存/磁盘一致性（照参考 account-pool 的真实缺陷）
参考的缺陷：`removeAccount` 只保证「读→改」之间无 await，而内部的
`await store.save(...)` 是**异步**的 ⇒ 两个写者各自的 save 可以**乱序完成**，
后完成者带着它更早的快照覆盖磁盘。实测形态：
- 并发删 a / 删 b（先发起的后完成）⇒ **已删除的账号在磁盘上复活**；
- 删 victim 与加 added 交错 ⇒ **新增账号被静默丢失**；
- 与内存副本分叉。
我们的实现是**同步** tmp+rename（Lua 无异步），且每次写都序列化**当前**
`plugin.state`（不是调用方早先取的快照）⇒ 该竞态结构上不可能发生。
（脚本语言在这里反而是优势 —— 参考那个缺陷正是"异步后端 + 共享可变快照"的产物。）
**但"不可能"必须被验证，否则只是一句自信**。判据逐条钉住三种形态：
① 已删除的账号不得在磁盘上复活；② 新增账号不得被静默丢失；
③ 内存与磁盘必须一致（分叉本身就是缺陷）。同时断言文档是合法 JSON
（tmp+rename 的原子性 —— 绝无半截文件），并断言**测试目录不是生产目录**
（隔离失效会造成真实数据事故，此前已发生过一次）。
★ 写这条判据时我自己踩了两个坑，都在此记录以避免重犯：
1. 先读到空文件就断言"没落盘" —— 真因是**每次 `poolCore` 拿到的是新的
`t.TempDir()`**，我在另一个调用里读路径；
2. 磁盘结构是 `{version, state:{pool:…}}`，我按顶层 `pool` 读 ⇒ 永远空。
两次都是**判据写错而不是被测对象有问题** —— 这正是"判据与被测对象脱节"。
|
2026-10-14 20:12:10 +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 |
|
|
|
2a2067284d
|
fix(channels): isFree 与声明自相矛盾 —— 免费判定改为**按平台声明权威来源**
## 缺陷
cline 的 3 个模型来自远端 **free 数组**（`recommended-models` 的唯一权威 free 集合），
却声明在 `models` 里 ⇒ 生产实测**全部 isFree=False**，与旁边的注释
「免费模型（远端 free 数组实测）」直接矛盾。用户看不到哪个可以不花钱用。
## ★ 关键认识：两个参考用的是**不同机制**，不能混成一条链
| 平台 | 免费判定的权威 |
|---|---|
| cline | 远端 `free[]` → 命名约定 `cline-free/*` → 静态兜底表（**不查 cost**） |
| opencode | models.dev 的 `cost`（`/zen/v1/models` 连能力字段都没有，cost 是**唯一**来源） |
我第一版把两者写成一条「OR 链」（任一来源说免费即免费），结果与既有判据
`TestCapabilityOverridesFreeFlag` **正面冲突** —— 那条判据要求「能力表说收费时
必须为 false」。冲突暴露了真问题：**只有平台自己知道它的免费名单在哪**。
⇒ 改为平台声明 `free_source`：
- `"capability"`（opencode）—— cost 权威，本地声明只作能力表拉不到时的兜底；
- 缺省 —— 声明链权威（**OR 语义**：任一来源确认免费即免费）。
OR 语义是刻意的：写成「后者覆盖前者」会让「远端说免费、能力表拉不到」
静默退回收费，正是这类静默降级。
## 其他改动
- `parseRemoteModels` 现在把远端的 `free[]` 记成**权威免费集合**
（此前只收了 id、丢掉了"它免费"这层信息），provider 走**显式参数**而非
隐藏全局状态（隐藏状态是漂移源）；
- cline 补 `free_prefix = "cline-free/"`（远端未响应时的兜底依据）与显式
`models_free`（远端抖动时不把免费模型误标成收费）。
## 判据
`TestIsFreeUsesAuthorityChain`：① cline 的 `cline-free/*` 与
`stealth/space-bunny-alpha` 必须免费；② 命名约定在远端未响应时能独立判出免费；
③ **反向**：收费通道的同名模型不得因前缀规则被判免费（参考点名
「免费模型是独立 id」）。既有 `TestCapabilityOverridesFreeFlag` 同时保持绿 ——
两条语义靠平台声明共存，而不是二选一。
## 附带发现
全量回归曾出现 `TestConcurrentPluginAdapterUpdates` 挂 59 分钟：
单独跑 0.058s 通过 ⇒ 真因是 **`/tmp`（8.8G tmpfs）被 Go 构建缓存占满 100%**，
不是代码死锁。清理 6G 后全量 9 包全绿。
|
2026-10-14 20:00:58 +08:00 |
|
|
|
742e2b5ed3
|
feat(channels): Cline 用插件自装的 channels-cline 适配器 —— 解析英文句子里的等待时长
## 为什么（这是**比参考更严重**的形态）
Cline 的 429 **既不给 `retry-after` 头，也不给绝对时刻**，等待时长写在
**人类可读的英文句子**里。抓包真值（参考实测，`no-retry: true`）：
```
HTTP 429
{"error":{"code":"INFERENCE_CAP_ERROR",
"message":"Error 429: Daily free limit reached on model
deepseek/deepseek-v4-flash. Try again in 19h 39m"}}
```
- **参考**退到"1 小时快照兜底" ⇒ 用户看到「永远 60 分钟」（等满一小时再试仍被拒，
且每失败一次就**从当下**重新计一小时 ⇒ 无限循环）。
- **我们更糟**：内核把 429 当普通限流、用**固定 30 秒**冷却 ⇒
**每 30 秒重试一次、永远失败**，在猛敲上游。
## 做法：厂商知识留在插件域，产出归一成内核已认的中立语义
插件自装 `channels-cline`（照 trae/gemini/qoder 同一机制）：
1. 解析真实等待时长 —— 各 token **累加**（`1h 30m` = 90 分钟），
单位按**首字母**判（h/m/s 互不重叠）⇒ 一次扫描即可，不会重复计数
（参考点名 `minutes?` 与 `m` 同时匹配会让时长翻倍）。
2. 把文案归一成内核**已认的中立短语**「额度已用完」⇒ 内核据此走
`RecordQuotaExhausted`（冷却到窗口边界）而不是 30 秒限流冷却。
**内核不认识任何厂商码/厂商文案**，只认自己的通用关键词表。
3. 话术把「是什么 + 何时恢复 + 重试无用」说清楚，**不**复述上游英文原文，
也**不**退回「等 1 小时就好」那种误导。
4. 402 单独处理：等待**不会**恢复，必须说清楚需充值。
## 判据（5 组，含"不得谎报"的反向项）
`TestClineAdapterParsesProseWait`：
① 归一成「额度已用完」（否则内核按 30 秒猛敲）+ 真实时长出现 + 明确「重试无用」
+ **不得**退回「1 小时」误导；
② 通过**真实 transform_error 路径**验证时长累加（`1h 30m` → 「1 小时 30 分」）、
秒级也能解析；
③ 402 提示充值；④ **普通 429 不得谎报成额度耗尽**（那会让内核长时间冷却一个
健康源）；⑤ 多种外壳（`{error:"…"}` / `{msg}` / 非 JSON 纯文本）都要认
—— 只认一种会在别的形态下静默丢掉整条信息。
回归：9 个包全绿；内核非测试代码零厂商名。
|
2026-10-14 20:00:58 +08:00 |
|
|
|
81b3661336
|
fix(channels): 自动领取每天静默漏领 —— 按 covers_today 记账，且间隔改为 2 小时
## 真实缺陷（照参考 credits.ts / auto-checkin.ts，2026-10-02 审查定位）
活动刷新时刻**各平台不同**：Qoder 是**每日 10:00（UTC+8）**才刷新。
而我们的自动领取只在 **08:00 跑一次**，于是：
- 上午那次看到的是**昨天**那条 `CLAIMED` → 报 `already-claimed`；
- 若拿它当"今天已处理"的凭证记档，当天 10 点刷新后就**再也不会去领**；
- ⇒ **每天静默漏掉 100 积分**（且不可逆：用户以为今天不必再领）。
## 修法：不靠"时刻表"，让产出方自己声明
参考的做法（照抄，因为它是从根上对的）：**不**给每个渠道配一张「刷新时刻表」
（那必然漂移），而是让**看得见该渠道刷新语义的那一层**声明
`covers_today`（本次结果算不算"今天这一轮"），记账方只数
「有几条能证明今天已被处理」。
- `covers_today` **缺省 true** ⇒ 绝大多数渠道（每日签到语义）行为完全不变；
- Qoder 在**刷新前**置 `false` ⇒ 不得据此认定今天已处理；
- **判据只看 `covers_today`，绝不用 `kind` 反推** ——
`already-claimed` 天然有歧义（可能就是昨天那一轮的痕迹）。
- 未覆盖今天的平台会**待重试**并记日志；已覆盖的（按 UTC+8 日界记账）
下一次直接跳过，不会重复打上游。
## 调度频率（两半都要，缺一仍漏）
| 改动 | 为什么必须 |
|---|---|
| `every` 86400 → **7200** | 刷新时刻晚于那次执行、或那次没覆盖到的平台，一天一跑就整天漏 |
| `at="08:00"` → **first_due_now** | 任何时刻重启都能补上，不等一个周期 |
| 新增 `claimCovered` 持久化 | **这才是防重领的正确机制** —— 不是靠"一天只跑一次"碰巧避开 |
★ 旧判据（`TestAutoClaimScheduledWithModelRefresh`）明写「auto_claim 是每日任务，
**不该** first_due_now（重启就重领是错的）」—— **那个假设本身就是缺陷的一部分**。
已按事实更新，并把这段经过写进注释（避免以后有人照旧判据再改回去）。
## 判据
- `TestAutoClaimCountsCoversTodayNotKind`：① 刷新前必须 `covers_today=false`
且**绝不报** `already-claimed`；② 刷新后为 true；③ 六组记账判据逐条钉住
（含"刷新前的 already-claimed 不得算已处理"这一关键项）；
- `TestAutoClaimScheduledMoreThanOnceDaily`：间隔必须远小于一天 + first_due_now
+ 记账键存在；
- `TestQoderAdapterParsesQueueAndBilling`（上一提交）：5 组，含与通用 openai
适配器的**对比**（断言通用器做不到，否则专用适配器无存在理由）。
回归：9 个包全绿；内核非测试代码零厂商名。
|
2026-10-14 20:00:58 +08:00 |
|
|
|
9521a35a03
|
feat(channels): Qoder 用插件自装的 channels-qoder 适配器 —— 排队与额度耗尽分开说
## 为什么
Qoder 的错误信封是**双层编码**的，且两个业务码语义**恰好相反**：
| 码 | 含义 | 正确处置 |
|---|---|---|
| `10605` | 模型排队 | **暂时**受阻 —— 等若干秒就能过 |
| `110` | 当日额度耗尽 | 立刻重试 / 等 15 秒 / 等 30 分钟，结果一样 ⇒ **必须立即失败** |
参考实测（2026-09-27 用户报障）：`110` 原先被归成通用的「服务端错误」→
**白重试 5 次**（≈15.5 秒），用户看到「重试延迟：7220毫秒」。
而我们此前用通用 `openai` 适配器，对它只能产出
`10605: {"isQueued":true,…}` —— 用户根本看不出是排队还是额度用完。
## 做法：厂商知识留在插件域（内核零厂商名）
照 `channels-trae` / `channels-gemini` 既有机制，本插件自装 `channels-qoder`。
内核只把 `transform_error` 的返回文本当作**客户端可读原因**，不认识任何厂商码。
★ **两个踩过的坑（都写进代码注释与判据）**：
1. **内层没有 `code` 字段** —— 那是 SSE 错误帧的 `message`（一个 JSON 字符串）。
参考第一版要求「必须命中 code 才算排队」，导致内层形态被判成非排队，
SSE 通道的修复**静默失效**（探针显示 sleep=0、错误照旧）。
判据改为：命中 `code=10605`，**或**直接出现排队字段（`isQueued`/
`serviceAvailable`）。`message`/`data`/`result`/`body` 都要展开并**再解析**。
2. **必须先在带排队字段的节点上取值** —— 外层 `root` 只有 `code`，
没有 `retryAfterSeconds`/`queueCount`。一命中就返回会让这两个参数**永远丢失**
（实测：只输出「排队中，请稍后重试」，参数全丢）。
3. **额度关键词必须窄** —— 只认 `billing daily count exceeded` /
`daily count exceeded` / `billing_error`。`quota`/`balance` 这类泛词会把
模型正文里讨论「余额」误判成故障。
## 判据（5 组，全部咬住真实行为）
`TestQoderAdapterParsesQueueAndBilling`：
① 双层编码取到内层的 30 秒 / 12 个排队；② **内层无 code** 也必须识别（参考的坑）；
③ `110` 说成额度耗尽、且明确「重试无用」、**绝不说成排队**；
④ 泛词 `quota`/`balance` 不误伤；
⑤ **与通用 openai 适配器对比** —— 断言通用器**做不到**这件事，
否则这个专用适配器就没有存在理由（防"加了但没用"）。
回归：9 个包全绿；内核非测试代码零厂商名。
|
2026-10-14 20:00:58 +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 |
|
|
|
252e3486bd
|
fix(channels): 凭据续期此前是假的 —— 现在真发请求、真回写、真报错
★ 修的是一个**比不做更坏**的缺陷：`account_refresh` 只重同步了源、**一个换
token 的请求都不发**，却恒返回 `ok:true` ⇒ `refresh_creds` 打出
「凭据已续期 N 个」而实际什么都没续。日志在说谎 —— 排查时会去看网络、看上游，
而真因是根本没有这段代码。这是本轮第三次遇到"静默恒真"（前两次是
`account_test` 恒返回 ok、`pcall` 只取 ok 不看返回值）。
实现要点（每条都是参考踩过的坑）：
- **各平台续期字段名不同**，写错服务端只回泛化的认证失败、极难定位：
Cline 是**驼峰** `refreshToken` + `grantType`（不是 OAuth 的
refresh_token/grant_type）、响应套 `{success,data}` 信封且字段是**驼峰**
`accessToken`；Google 走标准 `refresh_token` 表单编码 + client_secret。
- **Google 偶尔轮换 refresh_token**：响应给了新的**必须回写**，否则下次用旧的
直接失效。
- **`expires_in` 是相对秒数** → 必须换算绝对时刻，否则每轮都判定"快过期"重续。
- **按需续期必须回写索引的 expiresAt**（照 expiry-sync）：不回写会出现
「显示已过期、但发消息正常」的数据源分叉。
- 失败**如实回错**（HTTP 状态 / `error_description` 都带出来），但仍重同步源 ——
旧 token 可能还没真过期，不该因续期失败就撤源。
- `refresh_creds` 的计数判据改用 `refreshed`，**不是** `ok`：
`account_refresh` 在"平台未声明续期方式"时也回 ok:true（源照旧同步），
用 ok 计数就会把"没续"算成"续了"—— 这正是日志说谎的机制。
判据（必须**看到真请求**，否则还是在验一个恒真的返回值）：
1. 假上游断言**真发出 1 次请求**（原实现是 0 次却报成功）、路径正确、请求体是
驼峰 `refreshToken`/`grantType`、新 token 与轮换的 refresh_token 都落进凭据；
2. 401 时**绝不报 refreshed=true**，且错误含 HTTP 状态；无 refresh_token 时
提示"需重新登录"；
3. `expires_in:7200` → 凭据里是**绝对** expires_at（不是 7200），且
**账号列表**（不是保险库探针）里 read 到索引 expiresAt 已回写。
另修两个同处踩过的坑：`credentialIsRefreshable` 定义在使用点**之后**
（Lua local 前向引用，第 10 次）、`urlencode` 不存在（Google 表单编码需要）。
回归：9 个包全绿。
|
2026-10-14 16:46:43 +08:00 |
|
