dsh-connect-workbuddy 4.8.1 → 4.9.0

package/CHANGELOG.md

@@ -1,5 +1,44 @@
 # Changelog
 
+## 4.8.2 (2026-10-18)
+
+> 版本号是 **patch**：只改积分面板第二行的文字配色，不改请求、响应、计费、排序或任何配置项。`stateTone` 的判定、圆点的颜色规则、行的顺序都与本版之前完全相同。
+
+### Changes
+
+- **积分面板第二行的「当前选用」改成绿色**
+  - **原来错在哪**：`ComposerCredits.tsx` 把那两个事实拼成**一个** span —— `detailLine(当前选用, 被限流 · 约 6 小时后)`。一个 span 只能有一种颜色，而它挂的是 `.dsm-workbuddy-composer-panel-mark`，颜色是原因用的琥珀色 `--dsw-alias-state-warn-primary`。于是「当前选用」这句陈述事实的话，被涂成了问题的颜色：在一张「被限流」的表格里，它看起来像第三种警告。
+  - **现在的形状**：第二行拆成两个 span，各得各的语气 ——
+    | 片段 | 类名 | 颜色 | 出现在 |
+    | --- | --- | --- | --- |
+    | 当前选用 | `.dsm-workbuddy-composer-panel-mark-current` | `--dsw-alias-state-success-primary`（绿） | 正在服务本 tab 的那一行 |
+    | 被限流 · 约 X 小时后 | `.dsm-workbuddy-composer-panel-mark-reason` | `--dsw-alias-state-warn-primary`（琥珀，**未变**） | 用不了的行 |
+  - **分隔符改由 CSS 画**：两个 span 之间的 ` · ` 来自相邻兄弟选择器 `-current + -reason::before{content:" · "}`，所以把这一行当**纯文本**读出来仍是 `当前选用 · 被限流 · 约 6 小时后` —— 行 `title` 的悬浮提示、`th` 的 `aria-label`、以及既有的字符串断言都不受影响。这也是没有把两段文案在 TS 里拼成一个字符串的原因：拼了就没法给它们分别上色。
+  - **刻意没动的**：圆点的颜色规则（能用=绿、不能用=红、未测=灰）与 `stateTone` 的判定一行未改。选哪个颜色回答的是「能不能用」，第二行回答的是「是不是我在用的那个」，这两条规则各自独立 —— 4.8.1 之前那一版正是因为把颜色同时用于两件事才读不出来。
+  - **测试**：`tests/composer-credits-render.spec.tsx` 新增用例钉住「选中为独立绿色 span、原因为独立琥珀 span、两者共存仍不合并」，颜色断言直接从 `WORKBUDDY_COMPOSER_CSS` 里读规则，而不是断言类名存在就算过。
+
+## 4.9.0 (2026-10-18)
+
+> 版本号是 **minor**：这不是只改内部或只改文案的 patch —— 它改了请求里每个模型声明的身份，因此**会改变发往同一模型的历史消息的重放形状**（thinking 不再被降级成正文）。计费前提本身没有改；不跨区、不换模型的会话，其请求体与 4.8.2 逐字节相同。
+
+### Changes
+
+- **issue #59 计费前提定案：`reasoning` 不计费；同时撤回我们自己一个说法、改正报告者两个数**
+  - **定案的是什么**：`docs/reasoning-investigation.md` §10.1 的 (ii)「上游忽不忽略 `reasoning`」自 4.6.x 起一直记**尚未测定**，`docs/audit/ISSUE59-VERIFY.md` 的 C7 也记 UNVERIFIABLE-LOCALLY。现在可以写清楚了，依据两条互不依赖的算式：
+    1. **同区同模型增量**（报告者的机器实测）：国际侧两次相邻请求之间 `promptTokens` +416，`reasoning` 字符 +1,290、其余块 +892。计费读法算出来是 **0.1907 tok/char**，不计费读法是 **0.4664**；后者与我们自己实测的 `tool-result` 系数 **455.5 tok/1k** 只差 2.4%，而那一步新增的正是 `assistant(tool-call)` + `tool(result)`。
+    2. **国际侧自己的账**（纯本仓库系数）：tool 块 959,283 字符 × 0.4555 = **436,953 tok**，已是它 447,306 总量的 **97.7%**；剩下的 10,353 tok 要分给另外 822,343 字符（0.0126 tok/char）—— 只要 `reasoning` 也计费，这笔账就凑不出来。
+  - **性质必须说准**：这是「**报告者实测 + 本仓库系数复算佐证**」，**不是本机实测**。本机没有 `global.jsonl`，`cn.jsonl` 685 条里 `promptTokens` 命中 0（都是 4.6.6 之前写的记录）。要升级成「本机独立复现」，还差一份独立账号的捕获或一次受控的 reasoning 开关 A/B。
+  - **我们撤回了什么**：4.8.0/4.8.1 的文档里那句「若 `reasoning` 计费，预测比值 0.697」是**量纲串了** —— 0.697 是两边非 reasoning 密度的比值，不是计费假设的预测。计费假设下两区计费字符几乎相等（差 0.15%），预测比值应 **≈1.00**，而实测 **1.4370**：计费假设是**被证伪**，不是被吻合。报告者的这条批评成立，`docs/audit/ISSUE59-VERIFY.md` 的追记里已写明。
+  - **改正了两个数**：报告者撤回 `text` 741,952 → **741,687**（原数重复计了 265 字符），代码注释与测试文件头随之更正；他给过的隐含系数 **0.3518 tok/char 作废**（分母串了，真分母是 555,724），该数从未进过公开文档，C7 当初「无法复现」的疑问至此解释完毕。
+  - **不变的部分**：`isSameModel` 判据、两个 provider id 的成因、`context-rescue` 的兜底行为，一条都没改 —— 本次只改文档与注释，不动任何运行时行为。
+
+- **issue #59 插件侧修复：两条路由的 model 身份统一，换区不再把 thinking 降级成正文**
+  - **原来错在哪**：pi-ai 只把历史里的 thinking 当 thinking 重放，条件是产生它的消息与本次请求的 provider、api、model id **三者全等**（`transform-messages.js:68`）；不等就**降级成普通正文**（`:88–96`）。本插件把国内版与国际版注册成两条独立路由（`workbuddy` / `workbuddy-global`），而它们是**同一个 model id** —— 于是换一次区，另一侧产生的全部 thinking 整批从 reasoning 桶挪进正文桶。报告者实测：同一份字节相同的历史，一侧 708K、另一侧 1.374M（1.94×），为其中一侧算出的压缩请求因此永远塞不进另一侧的窗口。
+  - **改了什么**：新增 `WORKBUDDY_MODEL_IDENTITY = 'workbuddy'`（`src/adapter.ts`），`toPiModel` 盖在模型上的 `provider` 字段两边都用它，`isSameModel` 于是成立。**路由 id 一个都没合并** —— 注册键仍是 `workbuddy` / `workbuddy-global`，各自指向自己的 shim、目录与凭据；`tests/issue59-cross-region-thinking.spec.ts` 断言「同一个 model 身份 + 各自的 baseUrl + 各自的路由键」三件事同时成立。
+  - **为什么能这样做而不出问题**：pi-ai 的查表本来就分两件事 —— `getModel(provider, id)` 是 `providers.get(provider).getModels()` 里按 id 找（`models.js:116–118`），**键**是路由 id，**盖在返回对象上的 `provider` 字段**是 provider 自己写的。本插件不注册 `fetchModels`，没有任何下游从该字段反推路由；openai-completions 的 api 只用它取厂商特例（都不匹配这两个 id）和错误信息里的标签。
+  - **没有一并「修」掉的**：同区内换模型仍降级（那是真的换了模型，thinking 签名对新模型未必有效，保留才是错的）；升级前录进历史的消息带旧的按区域 id，重放时仍按旧规则降级，但只会越聊越少，不影响新录的消息。真正的修法仍在上游：`isSameModel` 应当能读「provider 等价组」声明，而不是让插件去伪装身份。
+  - **测试如何证明**：`transformMessages` 上跑了两组对照 —— 旧的一对按区域 id 复现出 `[text, text]`（这正是报告的成因），新的一对给出 `[thinking, text]` 且正文原样保留；另有一条断言**不同 model id 仍然降级**，防止这次修复被误读成「任何模型都算同一个」。本地 pi-ai 0.85.1 与宿主 1.1.0 在这条判据上的行为已分别核对一致。
+
 ## 4.8.1 (2026-10-18)
 
 > 版本号是 **patch**：只改卡片界面的样式与排版，不改请求、响应、计费或任何配置项。发往上游的请求体与本版之前逐字节相同。

package/README.en.md

@@ -356,6 +356,10 @@ Marketplace screenshots and GitHub README badges are two separate mechanisms:
   - **"Signed out" and "your sign-in cannot be read" are reported separately.** When an encrypted file cannot be read, the advice is to install the desktop app or point `WORKBUDDY_APP_EXECUTABLE` at it — **not** to sign in again, which cannot help: the credential is fine, the key is what is missing.
 - **A 403 "request illegal" (code 11140) is a server-side policy refusal, not a sign-in problem.** The chat gateway sometimes refuses a request outright under its content policy; the body reads `{"code":11140,"msg":"request illegal","requestId":"…","displayMsg":{"en":"The content did not pass the safety review. Please adjust and retry."}}`. The plugin used to file this under the generic `client` error (HTTP 400), which DSH then displayed as an AUTH failure — it looked like a broken sign-in, but **signing in again cannot fix it**: the credentials are fine; it is this one request that was refused. The refusal now passes through as 403 with the official message, `code 11140`, and the `requestId` (give that to official support). The `error.code` written back to the host is the stable class `policy_reject` rather than the numeric `11140`: the host decides in-place retrial from that class, and a policy refusal is deterministic — retrying only burns the budget, and `11140` is not a word the host knows, and the per-model "test" reports "refused by the server's content policy" instead of "token refused". Two ways out: send the same prompt from the WorkBuddy desktop app with the same account (if the desktop app is refused too, the limit is on the account/content side), or switch region/account and retry.
 
+- **Switching region makes the context "grow", and can hit `code 11115` immediately — the gateway is not over-charging you.** The same history is counted under different buckets in the two regions, and the root cause is how the host's bundled `@earendil-works/pi-ai` replays history. It evaluates `isSameModel` for every assistant message (`transform-messages.js:68`, keyed on provider **and** api **and** model id all being equal): for a message that fails, its thinking is **downgraded to ordinary content** (`:88–96` — not dropped), and content is what the gateways count, while thinking goes out in a different field. This plugin registers the domestic and international editions as **two provider ids** (`workbuddy` / `workbuddy-global`, see [How it works](#how-it-works)) that carry the **same model id** — so one region switch moves **all the other side's thinking into the content bucket at once**. That is the cause of issue #59's "the same conversation history is charged 1.374M by the international gateway and 708K by the domestic one (1.94×)"; switching back is the same formula read the other way, 0.696×.
+  - Three consequences you can see: a region switch can move the token count by ±30%–94%, and **how far depends only on the other side's thinking character count, not on total history length**; **switching models inside one region** triggers the same downgrade (the model leg of `isSameModel`), so the count can move without a region switch at all; and that jump lands on top of the host's current compaction threshold (`min(0.8 × window, window − 128000 − 65536)`), so a session that was comfortably under the limit can hit `code 11115 prompt is too long` the moment you switch region.
+  - **This is a mismatch between the host and pi-ai, not a bug in this plugin**: not replaying thinking across providers/models is right in itself (another model's train of thought is not context this model should be fed), and the mistake is treating `provider` as a necessary condition for "the same model" when the two provider ids here are **two access regions of one model**. The fix belongs upstream (same api + same model id, providers as an equivalence group); on the plugin side the backstop is `src/context-rescue.ts` since 4.8.0 — **once the upstream confirms an overflow, it folds history in chunks and resends**, instead of replaying the entire range the host meant to compact (which is exactly what makes a compaction request overflow itself and deadlock). To see where it happened: set `WORKBUDDY_BODY_REPORT` to capture a body-composition report — it records counts only, never text.
+
 ## Disclaimer
 
 - This project is **for personal study and research only**. It drives only your own WorkBuddy account locally; do not use it commercially or beyond reasonable personal use.

package/README.md

@@ -366,6 +366,13 @@ else { await envelope.response.text() /* 或者按 SSE 消费 */ }
   - **「未登录」与「登录信息读不出来」是两件事**：加密文件读不出时，插件给出的建议是「安装桌面 App / 用 `WORKBUDDY_APP_EXECUTABLE` 指定其位置」，而**不是**「重新登录一次」——后者对这种情况无效（凭据本身是好的，缺的是密钥）。
 - **403「request illegal」（code 11140）是服务端策略拒绝，不是登录问题**：聊天网关有时会按内容策略直接拒绝一次请求，响应体形如 `{"code":11140,"msg":"request illegal","requestId":"…","displayMsg":{"zh":"内容未通过安全审核，请调整后重试。"}}`。此前插件把它归为通用 `client` 错误返回 400，DSH 侧又显示成 AUTH 异常——看起来像「登录坏了」，但**重新登录解决不了它**：凭据本身是好的，被拒的是这一次请求。现在这类拒绝按 403 原样透传，消息里带官方文案、`code 11140` 和 `requestId`（联系官方支持时提供）。写回宿主的 `error.code` 是 `policy_reject` 这个稳定类别（而非数值 `11140`）：宿主按类别决定要不要原地重试，而策略拒绝是确定性的——重试只会白烧预算，`11140` 也不是宿主认得的词；模型行的「测试」也显示「服务端按内容策略拒绝」而非「token 被拒」。遇到时的两个出口：在 WorkBuddy 桌面端用同一账号发同样的内容验证（桌面端同样被拒，说明限制在账号/内容侧）；或切换区域/账号后重试。
 
+- **切换区域会让上下文「变大」，甚至一换区就 `code 11115` 超限——不是网关多算你的钱**：同一份历史在两个区域的计费口径不同，根子在宿主内置的 `@earendil-works/pi-ai` 重放历史的方式。它给每条 assistant 消息算一次 `isSameModel`（`transform-messages.js:68`，判据是 provider **且** api **且** model id 三者全等）：不等的消息，其 thinking 会被**降级成普通正文**（`:88–96`，并不是丢弃），而正文是网关会数的，thinking 走的是另一个字段（字段名两边都是 `reasoning_content`）。**这一点已由 issue #59 报告者的同区增量实测证实**：`reasoning` 不计费，且同一侧自己的工具结果块按本插件实测的 455.5 tok/1k 就吃掉了它全部计费量的 97.7%。本插件把国内版与国际版注册成**两条 provider 路由**（`workbuddy` / `workbuddy-global`，见[工作原理](#工作原理)），而它们是同一个 model id——于是**换一次区，另一侧产生的全部 thinking 就整批从 thinking 桶挪进正文桶**。这就是 issue #59 里「同一份对话历史，国际网关算 1.374M、国内网关算 708K（1.94×）」的成因；反方向切回来则是同一公式的 0.696×。
+  - 由此带来三个用户可见的后果：换区后 token 计数可能跳 ±30%~94%，**跳多少只取决于另一侧 thinking 的字符数，与历史总长无关**；在**同一个区域内换模型**也会触发同样的降级（`isSameModel` 的 model 那条腿），所以不换区也可能看到计数变化；跳变叠加在宿主当前的压缩阈值（`min(0.8×窗口, 窗口−128000−65536)`）上，就会让本来不超限的会话一换区立刻撞上 `code 11115 prompt is too long`。
+  - **这是宿主与 pi-ai 之间的一处错配，不是本插件的 bug**：不跨 provider/模型重放 thinking 这件事本身是对的（别家模型的思考过程对当前模型没有上下文价值），错在把 `provider` 当作「是不是同一个模型」的必要条件，而这里两个 provider 字符串指的是**同一个模型的两个接入区域**。
+  - **本插件已在 4.9.0 起从插件侧绕开它**：两条路由注册的 **model 身份统一为 `workbuddy`**（`src/adapter.ts` 的 `WORKBUDDY_MODEL_IDENTITY`），也就是模型自己声明的 `provider` 字段两边相同，于是 `isSameModel` 成立、换区不再把 thinking 降级成正文。**路由 id 没有合并**——它仍是 `workbuddy` / `workbuddy-global`，各自指向自己的 shim、目录与凭据，所以一侧故障不会带走另一侧，模型选择器也仍是两组。依据是 pi-ai 自己的查表形状：`getModel(provider, id)` 取的是 `providers.get(provider).getModels()`（`models.js:116–118`），**查表用的键**与**模型上盖的 provider 字段**是分开的两件事。
+  - 升级后仍可能看到计数变化的部分：**在同一区域内换模型**仍会降级（`model` 那条腿是真的换了模型，thinking 签名未必对新模型有效，保留才是错的）；**升级之前就录在历史里的消息**带着旧的按区域 id，重放时仍按旧规则降级——这种历史只会越聊越少，不会反过来影响新录的消息。
+  - 真正的修法仍在上游（让 `isSameModel` 认「provider 等价组」声明，而不是让插件去伪装自己的身份）；插件侧的兜底是 4.8.0 起的 `src/context-rescue.ts`——**一旦上游确认超限，就按块折叠历史后重发**，而不是把宿主要压缩的整段历史原样重放一遍（原样重放正是「压缩请求自己超限 → 压缩死锁」的成因）。想亲眼看到这件事发生在哪条消息上：设 `WORKBUDDY_BODY_REPORT` 抓一次 body 组成报告，它只记计数、不记正文。
+
 ## 免责声明
 
 - 本项目**仅供个人学习和研究使用**，仅驱动使用者自己的 WorkBuddy 账号在本机调用，请勿用于商业用途或超出个人合理使用的场景。

package/lib/bin.js

@@ -1,5 +1,5 @@
 #!/usr/bin/env node
-import { C as defaultDesktopAuthDirs, F as WorkBuddyUpstreamClient, K as WORKBUDDY_APP_EXECUTABLE_ENV, O as legacyWorkbuddyOwnAuthPath, Q as findWorkbuddyAppExecutableWithSource, S as defaultDesktopAuthCandidates, a as readHostHeartbeat, c as WORKBUDDY_CONNECT_VERSION, d as FALLBACK_WORKBUDDY_MODELS_GLOBAL, j as workbuddyOwnAuthPath, l as piAiRuntimeInfo, o as workbuddyHostHeartbeatPath, ot as hostPeersInfo, r as isHeartbeatProcessAlive, u as FALLBACK_WORKBUDDY_MODELS, v as WORKBUDDY_AUTH_FILE_ENV, y as WorkBuddyCredentialStore } from "./host-heartbeat-BfAvb1_d.js";
+import { C as defaultDesktopAuthDirs, F as WorkBuddyUpstreamClient, K as WORKBUDDY_APP_EXECUTABLE_ENV, O as legacyWorkbuddyOwnAuthPath, Q as findWorkbuddyAppExecutableWithSource, S as defaultDesktopAuthCandidates, a as readHostHeartbeat, c as WORKBUDDY_CONNECT_VERSION, d as FALLBACK_WORKBUDDY_MODELS_GLOBAL, j as workbuddyOwnAuthPath, l as piAiRuntimeInfo, o as workbuddyHostHeartbeatPath, ot as hostPeersInfo, r as isHeartbeatProcessAlive, u as FALLBACK_WORKBUDDY_MODELS, v as WORKBUDDY_AUTH_FILE_ENV, y as WorkBuddyCredentialStore } from "./host-heartbeat-CS6PxirW.js";
 import { realpathSync } from "node:fs";
 import { fileURLToPath } from "node:url";
 //#region src/bin.ts