dsh-connect-workbuddy 5.12.2 → 5.12.3

package/CHANGELOG.md

@@ -1,5 +1,104 @@
 # Changelog
 
+## 5.12.3 (2026-10-28)
+
+> issue #155 的**两个独立 Bug**：**① 业务码按字节匹配 JSON**——`11128`/`14003`/`14018` 用
+> `body.includes('"code":11128')` 判定，于是同一个信封 `{"code":11128}` 认得、多一个空格的
+> `{"code": 11128}` 和写成字符串的 `{"code":"11128"}` 都不认，渠道闸被静默判成 `client`，
+> **整条救援阶梯不再运行**（#113 的修复等于被一个空格关掉）；**② 删账号只清内存、不清持久化选择**——
+> 磁盘上 `accounts.cn` 仍写着死 id，下次 `applySelection` 把它读回来，CN 整块变「已保存的账号在本机
+> 已不存在」且账号列表一条不渲染。
+
+### Fixes
+
+- **渠道闸/限流/耗尽三族业务码按字节匹配，一个空格就漏判（#155）**
+  - **现象**：报告者贴回来的那条消息里**自相矛盾**——正文写着 `code 11128`，同一句却带
+    `"type":"client"`，收尾是「请按上面的提示调整后重试」。两半出自同一个信封、同一份 body。
+  - **根因**：分类器判族用 `body.includes('"code":11128')`——对**一种序列化**做字节测试；上游 JSON 里
+    多一个空格、或把码写成字符串，判据就落空。而 `code 11128` 那半走 `parseUpstreamErrorDetail`
+    （`JSON.parse`），照旧读得到。**以下矩阵是把每行都跑在 HEAD 代码上测出来的**，不是推理：
+
+    | body 写法 | HEAD classify | HEAD detail.upstreamCode |
+    | --- | --- | --- |
+    | `{"code":11128}` | `channel_reject` | 11128 |
+    | `{"code": 11128}` | `client` ← 漏 | 11128 |
+    | `{"code":"11128"}` | `client` ← 漏 | `undefined` ← 也漏 |
+    | `{"error":{"code":11128}}` | `channel_reject` | `undefined` ← **反向**不一致 |
+    | `{"CODE":11128}` | `client` ← 漏 | `undefined` |
+  - **两种不同的错位**，报告者只能贴出第一种。第 2 行就是 #155 那条消息：分类器按 substring 说
+    `client`，展示那半按 `JSON.parse` 读到**顶层数字** `11128` 照旧打印 —— 一条回复里，诊断和它自己的
+    证据互相打脸。第 3–5 行对支持更糟、对用户不可见：不但两个读取器不一致，**连要求用户提供的那个码都
+    整个消失**，`channel_reject` 贴出来却没有 `11128` 可锚。第 4 行方向相反（substring 恰好命中嵌套的
+    `"code":11128`，解析器当时只认 `error.data.code`），说明这不是「换成解析器就完了」—— 两侧都得读同一个
+    事实，才可能一致。
+  - **代价不只是文案**：`client` 是**唯一不进渠道救援阶梯**的类别（`src/shim.ts` 的门是
+    `result.kind === 'channel_reject'`），于是 `forceNeutralHead` 与两级扰动重试一次都不会跑 —— 用户被
+    要求「调整请求后重试」，而插件根本没试过救援。`14003` 同族实测降级目标**随 HTTP 状态而变**：
+    `429 {"code": 14003}` → `soft_rate`、`400` → `client`，而 `model_busy` 是三个**不换号**的类别之一
+    （`isFailoverWorthy`）—— 落到 `soft_rate` 就是让整个账号池挨个烧一次真实请求去学一个模型级的事实。
+    `14018` spaced 单独看会掉成 `client`，实测只有当 `msg` 里带上了 `Credits exhausted` 那句话时才被
+    措辞标记救回 `hard_credit` —— 措辞一改就失效，正是本仓库反复记录的那类脆弱判据。
+  - **修法**：新增 `statesBusinessCode(body, code)`，`CHANNEL_REJECT_CODE`/`MODEL_BUSY_CODE`/
+    `CREDITS_EXHAUSTED_CODE` 三个常量从字符串形态改成数字，6 处家族判断统一走它。**三段读取，顺序即安全性**：
+    ① 信封自己声明的码是最终答案，**绝不再做文本扫描** —— 否则 `extError` 里嵌套的 `"code":11128` 会盖掉外层
+    `14003` 的自判，正好是 #127 反过来要的精度；② 解析成功却没在已知三种形态里声明码的 body，仍走带引号锚点
+    的文本扫描 —— 这条是**严格扩量**：#127 只留解析器，反而把 `{"error":{"code":11140}}` 这种旧文本匹配本来
+    认得的写法**收窄**掉了；③ 扫描锚在 `"code":<n>` 而非裸数字，十六进制 requestId 恰好含 `11128` 仍不能把
+    无关 body 提上来（原文本形态存在的理由，一并保留）。
+  - **一处先前例**：`CONTEXT_TOO_LONG_CODE`（`11115`，#101）早就写成 `/"code"\s*:\s*11115(?!\d)/u` —— 本仓库
+    **第三次**独立撞上同一个坑，前两次各修各的族，这就是为什么这次收成一个共享读取器，而不是第四处正则。
+  - **顺带修两处同源缺陷**：`envelopeError()` 已把 `code` 解析成数字，却只把 `msg` 交给分类器 —— 而 `msg`
+    永远不含 `"code":…`，于是每个「靠业务码判定」的族在这里都不可见，答案一律落到 `client`（#144 那条
+    `workbuddy upstream client (http 400): 请求被拦截，请重新发送` 就是一个插件已经握有其码的信封）；改为按
+    规范形重建 body 再分类。`parseUpstreamErrorDetail()` 原先只认**顶层**且 `typeof === 'number'` 的 `code`，
+    现与分类器共用 `businessCodeOfDocument`（补上 `{"error":{"code":…}}`，排在 `error.data.code` 之后以免
+    细节盖掉判定）—— 不再出现「按码判了类、却不打印码」。
+- **删掉一个账号后，该区域的持久化选择复活成死 id（#155 第二份报告）**
+  - **现象**：「删了一个账号就这样了」——CN 整块变「未登录」，提示「已保存的账号在本机已不存在」，而上方账号
+    列表**一条都不渲染**；`usage?region=cn&detail=fast` 答 `status=signed-out selectionLost=true`，但同一份
+    响应里明明还有 3 个 token 未过期的账号，国际版正常。报告者自己定位到 `cordis.patch.yml` 里
+    `accounts: cn: <本机已不存在的 id>`，并靠手发 `POST /__save {"field":"accounts","value":{"cn":""}}`
+    恢复的 —— 本条就是把那个手动动作变成自动。
+  - **根因是「只清了一半」**：`removeAccount()` 确实清了内存里的 `this.accountId`，所以**本次会话内一切正常**、
+    删除也回报成功；但设置文档里的死 id 一个字节都没动，下一次 `applySelection`（重启，或**任何一次设置保存**）
+    把它读回来重新 pin，区域随即掉进死胡同：`current()` 找不到 → `resolve()` 抛 no signed-in account →
+    走 `signed-out` 分支，而该状态下卡片的建议指向一个它自己并不渲染的列表。会话内看不出问题、故障延后到重启才
+    现形，正是这两步之间的缝隙让报告者和「删账号」连不起来。**只存在于内存的忘记不是修复，是拖延。**
+  - **修法**：`removeOne` 之后调用 `clearRegionAccountSelection()`，**只在被删账号正是本区持久化 pin 时**
+    写 `accounts[region] = ''`。判定与写入同在一个函数里，调用方无法只挑一半。四条约束都是这条修复的一部分：
+    - **写 `''`，绝不删键**：`''` 是「跟随 App 当前登录」的哨兵（也是全新安装的默认值，所以这是**恢复**而非
+      发明状态）；删掉的键含义是「从未配置」，会回落到旧版扁平 `accountId`，把用户**悄悄切到另一个账号**。
+    - **只清 pin 了该号的区域**：无关的删除必须零次写入 —— 内存里 `current()` 都拒绝回退到别的账号，
+      删除不能绕过它、从设置文件里做同样的事（换账号等于换人计费）。
+    - **整字段合并**：`accounts` 是两个区域共用的一张平表，按调用方视角重建会抹掉兄弟区域的 pin；判定与写入
+      都读 `describe()` 的权威文档，且先 `unwrapVolatileDeep` —— 把 volatile 的 `{get}` 活引用写进 payload，
+      settings 服务会整次拒绝（`found a function at $.ops[0].value.get`）。
+    - **同时覆盖旧版扁平 `accountId`**：pre-split 配置的 `accounts` 是空的、只靠扁平字段 pin，
+      `regionPinsAccount` 认这条；而哨兵会**终止**那次回落，所以一次写入同时 settle 两种写法。
+    - **fail-soft**：写设置失败只记 warn，绝不回报「删除失败」—— 凭证文件此刻已经真删了，说它还在是第二个谎。
+
+### Tests
+
+- `tests/issue155-envelope-spelling.spec.ts` 新增 23 条（#155）：紧凑/带空格/字符串码/嵌套四种写法 ×
+  11128/14003/14018/11140 四族；`{"CODE":11128}` 归族（这一半是**恢复**不是保留：member 层先前对 body
+  做了 `toLowerCase()` 因而认大写、`tests/issue98-channel-gate` 钉的是 member，而 family 层测的是原始 body、
+  不认 —— 现在一个读取器同时回答两侧）；十六进制 requestId 含 `11128` 不得被提上来；嵌套 `11128` 不得盖掉外层
+  `14003` 的自判；**分类器与展示给用户的那条码不许互相矛盾**。
+- `tests/issue155-account-removal.spec.ts` 新增 17 条（#155）：`regionPinsAccount` 四个方向（本区 pin 了=清 /
+  兄弟区 pin 了别的=不清 / 已在跟随 App=不写 / 只靠扁平字段 pin=清，且扁平字段只归它被归属的那个区）；
+  `nextAccountsSelection` 保兄弟区、只答 `accounts` 字段而非整个 section、`''` 作为数据保留（区别于缺键）；
+  volatile 活引用不得漏进 payload；无服务/无命名空间时零写入。
+- `tests/issue155-removal-e2e.spec.ts` 新增 5 条（#155 的**接线**）：真实 `apply()` + 真实路由 + 真实 config
+  对象（settings 双按引用答 `describe()`、`mutate` 原地提交并广播 `loader/volatile-update`），断言
+  「删除 → 触发那次重读（等价于重启或任何一次设置保存的 `applySelection`）→ 区域仍 `signed-in` 且
+  `selectionLost` 消失」这条旧代码做不到的完整链条；另测兄弟区 pin 存活、无关删除零次写入、写失败时删除仍回报
+  200。单独存在的理由与 `tests/pool-e2e.spec.ts` 相同：纯 helper 用例对着我自己写的 double，摘掉 `index.ts`
+  里的接线它们全绿。
+- 变异验证（每条都确认会让对应用例变红）：分类器退回 `body.includes('"code":N')` → **11 条红**；删掉
+  「本区是否 pin 了该号」的判定 → **4 条红**；写整个 section 而非 `accounts` 字段 → **4 条红**；
+  `removeOne` 退回只清内存 → **1 条红**（正是那条延后到重启才现形的链）。
+- 全量：`tsc` 双配置 0 错误，**146 文件 / 2536 通过（2 条按平台跳过）**，`tsdown` 构建通过。
+
 ## 5.12.2 (2026-10-27)
 
 > 两处修复：**① 装完重启插件消失**（#151）——把宿主提供的 `@earendil-works/pi-ai` 标成 optional

package/lib/bin.js

@@ -1,5 +1,5 @@
 #!/usr/bin/env node
-import { C as WorkBuddyCredentialStore, D as defaultDesktopAuthDirs, E as defaultDesktopAuthCandidates, I as workbuddyOwnAuthPath, Lt as WORKBUDDY_APP_EXECUTABLE_ENV, M as legacyWorkbuddyOwnAuthPath, S as WORKBUDDY_AUTH_FILE_ENV, Ut as findWorkbuddyAppExecutableWithSource, V as WorkBuddyUpstreamClient, Zt as hostPeersInfo, a as readHostHeartbeat, c as WORKBUDDY_CONNECT_VERSION, d as rosterSeenPath, f as piAiRuntimeInfo, m as FALLBACK_WORKBUDDY_MODELS_GLOBAL, o as workbuddyHostHeartbeatPath, p as FALLBACK_WORKBUDDY_MODELS, r as isHeartbeatProcessAlive, u as describeRosterSeenPayload } from "./host-heartbeat-BdTV4Aoi.js";
+import { C as WorkBuddyCredentialStore, D as defaultDesktopAuthDirs, E as defaultDesktopAuthCandidates, I as workbuddyOwnAuthPath, Lt as WORKBUDDY_APP_EXECUTABLE_ENV, M as legacyWorkbuddyOwnAuthPath, S as WORKBUDDY_AUTH_FILE_ENV, Ut as findWorkbuddyAppExecutableWithSource, V as WorkBuddyUpstreamClient, Zt as hostPeersInfo, a as readHostHeartbeat, c as WORKBUDDY_CONNECT_VERSION, d as rosterSeenPath, f as piAiRuntimeInfo, m as FALLBACK_WORKBUDDY_MODELS_GLOBAL, o as workbuddyHostHeartbeatPath, p as FALLBACK_WORKBUDDY_MODELS, r as isHeartbeatProcessAlive, u as describeRosterSeenPayload } from "./host-heartbeat-D1N-f8Q6.js";
 import { readFile } from "node:fs/promises";
 import { realpathSync } from "node:fs";
 import { fileURLToPath } from "node:url";

package/lib/{host-heartbeat-BdTV4Aoi.js → host-heartbeat-D1N-f8Q6.js}

@@ -2430,14 +2430,14 @@ const HARD_CREDIT_MARKERS = [
 * this guards against. Marker tables rot in a way codes do not: the gateway can
 * reword its sentence without changing the contract it advertises, and the
 * failure is silent (the branch simply stops matching). A code cannot drift like
-* that, and matching it in quoted-key form keeps a request id that happens to
-* contain the digits from promoting an unrelated body.
+* that, and reading it (see {@link statesBusinessCode}) keeps a request id that
+* happens to contain the digits from promoting an unrelated body.
 *
 * ONLY a corroborating signal, never a substitute: the code is checked in
 * addition to the markers, so a body that names the code AND reads as a policy
 * refusal still resolves by the marker table's order.
 */
-const CREDITS_EXHAUSTED_CODE = "\"code\":14018";
+const CREDITS_EXHAUSTED_CODE = 14018;
 /** Session-invalidation markers that mean "sign in again in the WorkBuddy app". */
 const SESSION_DEAD_MARKERS = ["Offline user session not found", "12153"];
 /**
@@ -2474,7 +2474,21 @@ function businessCodeOf(body) {
 		return match?.[1] === void 0 ? void 0 : Number(match[1]);
 	}
 	if (typeof parsed !== "object" || parsed === null) return void 0;
-	const raw = parsed;
+	return businessCodeOfDocument(parsed);
+}
+/**
+* The business code a PARSED failure document states, or `undefined`.
+*
+* ONE READER FOR TWO CALLERS (issue #155's second half). The classifier needs
+* the code to decide a kind; `parseUpstreamErrorDetail` needs it to print
+* `code 11128` in the reply the user pastes into an issue. The display half used
+* to read only a top-level `code` that was `typeof === 'number'`, so for two of
+* the spellings below the SAME body produced a diagnosis from the code while
+* showing no code at all — and `client`/`channel_reject` is exactly the pair a
+* reporter needs to be able to cross-check. Extracted so the two cannot drift
+* again; `businessCodeOf` keeps the unparseable-body fallback on top of it.
+*/
+function businessCodeOfDocument(raw) {
 	const direct = asBusinessCode(raw["code"]);
 	if (direct !== void 0) return direct;
 	const error = raw["error"];
@@ -2484,6 +2498,8 @@ function businessCodeOf(body) {
 			const nested = asBusinessCode(data["code"]);
 			if (nested !== void 0) return nested;
 		}
+		const direct = asBusinessCode(error["code"]);
+		if (direct !== void 0) return direct;
 	}
 	const data = raw["data"];
 	if (typeof data === "object" && data !== null) return asBusinessCode(data["code"]);
@@ -2493,21 +2509,97 @@ function asBusinessCode(value) {
 	if (typeof value === "number" && Number.isInteger(value)) return value;
 	if (typeof value === "string" && /^\d{4,6}$/u.test(value.trim())) return Number(value.trim());
 }
+/**
+* Whether a failure body states this business code, in ANY of its spellings.
+*
+* THE BUG THIS REMOVES (issue #155). Three of the four code families below were
+* recognised by `body.includes('"code":11128')` — a byte test on ONE
+* serialization. Issue #127 had already proven that test unreliable, but it
+* converted `11140` ONLY: measured on `6bdba2a`, `businessCodeOf` has exactly
+* one call site, despite that commit's message claiming `11128` as well. So the
+* SAME envelope answered one thing to the parser and another to the classifier.
+* Measured row by row against the shipped code:
+*
+*   body                       classify         detail.upstreamCode
+*   {"code":11128}             channel_reject   11128
+*   {"code": 11128}            client ← 漏      11128
+*   {"code":"11128"}           client ← 漏      undefined ← 也漏
+*   {"error":{"code":11128}}   channel_reject   undefined ← 反向不一致
+*   {"CODE":11128}             client ← 漏      undefined
+*
+* TWO DIFFERENT mismatches. Row 2 is what the reporter pasted into issue #155:
+* `code 11128` in the text (`parseUpstreamErrorDetail` reads a top-level NUMBER,
+* which JSON.parse delivers even for a spaced body) beside `"type":"client"`
+* (decided by the substring) — a diagnosis disagreeing with its own evidence
+* inside one message. Rows 3–5 are worse for support and invisible to the user:
+* the readers disagree AND the code support asks for is missing entirely. Row 4
+* runs the OTHER way (the substring happens to hit the nested `"code":11128`
+* while the parser only knew `error.data.code`), which is why this could not be
+* fixed by "just use the parser" — both readers must consult ONE fact.
+* That is not cosmetic — `client` is the one kind that does NOT
+* enter the channel rescue ladder (`src/shim.ts`, gated on
+* `kind === 'channel_reject'`), so `forceNeutralHead` and both perturbation
+* rungs never fired, and the user was told to "adjust the request" for a
+* refusal the plugin had not actually tried to rescue. Issue #113's whole fix
+* silently switches off depending on a space.
+*
+* THREE READS, IN THIS ORDER, and the ordering is the safety property:
+*
+* 1. A code the envelope STATES is final. `businessCodeOf` found one ⇒ that is
+*    the answer, and the text scan below is never consulted. Without this rule,
+*    OR-ing the two reads would let a nested sub-object's `"code":11128`
+*    (inside `extError`, say) reclassify an envelope whose own verdict is
+*    `14003` — promoting a detail over the verdict, the reverse of the precision
+*    issue #127 bought.
+* 2. A body that PARSES but states no code in the three shapes `businessCodeOf`
+*    knows still gets the quoted-key text scan. That is where this fix strictly
+*    widens the old behaviour: an undocumented nesting (`{"error":{"code":…}}`)
+*    used to be recognised by the substring, and dropping it here would be a
+*    regression dressed up as a refactor.
+* 3. The scan anchors on `"code":<n>`, never the bare digits, so a hexadecimal
+*    request id containing `11128` cannot promote an unrelated body — the hazard
+*    the original quoted-key form existed to avoid, kept intact. The scan is
+*    applied case-insensitively. This half RESTORES rather than preserves a
+*    behaviour, and the two halves of the family disagreed about it: the member
+*    predicates lower-cased the body before testing it (so `{"CODE":11128,…}`
+*    matched, pinned by `tests/issue98-channel-gate`), while the family
+*    predicate tested the RAW body and did not. One reader now answers both.
+*
+* The text form is derived from the number rather than declared beside it: two
+* constants for one code are two truths that drift, and a stale text form would
+* silently reinstate the bug above for exactly the spelling this function exists
+* to catch.
+*/
+function statesBusinessCode(body, code) {
+	const stated = businessCodeOf(body);
+	if (stated !== void 0) return stated === code;
+	return body.toLowerCase().includes(`"code":${code}`);
+}
 /** The `11140` content-policy family, whatever the envelope's JSON spelling is. */
 const CONTENT_POLICY_CODE = 11140;
 /**
-* Content-policy refusal markers from the chat gateway. The quoted-key form
-* avoids substring hits inside unrelated values (request ids are hex and can
-* contain `11140` by coincidence).
+* Content-policy refusal markers from the chat gateway. The code is READ rather
+* than text-matched so a request id cannot contain `11140` by coincidence and
+* promote an unrelated body — and, since issue #155, so the ONE read is shared
+* with every other family here instead of being a second, subtly different rule.
 *
 * `request illegal` is deliberately absent: the live `11128` channel-gate body
 * uses the SAME `msg`, so this marker used to run first and classify that gate
 * as `policy_reject`. The consequence was severe — the channel rescue ladder
 * never ran, the reply changed 400 to 403, and users were told to switch
 * accounts for a request-side refusal (issue #127).
+*
+* THE NESTING GAP #127 LEFT BEHIND, and why this now reads through
+* {@link statesBusinessCode}. Issue #127 replaced the text match with the parser
+* alone, which is exact for the three shapes that parser knows (`code`,
+* `error.data.code`, `data.code`) — and therefore silently NARROWED coverage for
+* a body whose code sits anywhere else, such as `{"error":{"code":11140}}`, which
+* the old text match did catch. The helper keeps both: a code the envelope states
+* wins outright (the precision #127 was after), and the text scan runs only when
+* nothing was stated, where it can only restore a match the parser could not see.
 */
 function isContentPolicyBody(body) {
-	return businessCodeOf(body) === CONTENT_POLICY_CODE;
+	return statesBusinessCode(body, CONTENT_POLICY_CODE);
 }
 /**
 * Whether a failure body is the account-restriction member of the `11140`
@@ -2607,25 +2699,32 @@ function isUndecodablePolicyBody(body) {
 /**
 * Business code of the MODEL-scoped throttle (`14003`, "too many requests").
 *
-* The quoted-key form for the same reason as the policy markers: a request id is
-* hexadecimal and can contain the digits `14003` by coincidence, and a bare
-* substring search over an arbitrary failure body is how a red herring gets
-* promoted into a routing decision.
+* A number rather than the quoted-key text form: the text match was exact for
+* one serialization only, so a spaced or string-quoted envelope lost the
+* `model_busy` kind and fell through to whatever its HTTP status says — measured
+* at HEAD, `429 {"code": 14003}` became `soft_rate` and `400` became `client`.
+* That is not a cosmetic rename: `model_busy` is one of the three NON-failover
+* kinds (`isFailoverWorthy` in `src/shim.ts`), because the throttle is a fact
+* about the MODEL and the next credential joins the same one — so `soft_rate`
+* walks the whole pool burning a real request per account to learn nothing,
+* while `client` prints neither the kind's advice nor its code (issue #155). See
+* {@link statesBusinessCode}.
 */
-const MODEL_BUSY_CODE = "\"code\":14003";
+const MODEL_BUSY_CODE = 14003;
 /**
 * Business code of the gateway's CHANNEL gate (`11128`, "Illegal API invocation
 * from an unapproved channel").
 *
-* The quoted-key form for the same reason as the markers above: a request id is
-* hexadecimal and can contain the digits `11128` by coincidence.
+* A NUMBER, not the quoted-key text form it used to be. Matching the text was
+* exact only for one serialization, which is the whole of issue #155 — see
+* {@link statesBusinessCode}.
 *
 * A DIFFERENT gate from the one {@link conversationHeaders} works around, which
 * also answers `11128` (`conversation id missing`). The code is the same
 * because the gateway reuses it for every rule in that family; the BODY is what
 * tells them apart, so {@link isChannelRejectBody} requires both halves.
 */
-const CHANNEL_REJECT_CODE = "\"code\":11128";
+const CHANNEL_REJECT_CODE = 11128;
 /**
 * Business code for "the request exceeded the model's context window" (issue #101).
 *
@@ -2723,24 +2822,23 @@ const FIRST_MESSAGE_GATE_MARKER = "first message is not system prompt";
 * SAME second. A 6004, by contrast, carries a `将在 … UTC+8 重置` sentence and
 * is per-account.
 *
-* So the criterion is the CODE alone, matched in its quoted-key form so a
-* request id that happens to contain the digits cannot promote it. Exported so
-* the probe and the chat path cannot drift into two different answers about one
-* body.
+* So the criterion is the CODE alone, read by {@link statesBusinessCode} so a
+* request id that happens to contain the digits cannot promote an unrelated
+* body. Exported so the probe and the chat path cannot drift into two different
+* answers about one body.
 */
 function isModelBusyBody(body) {
-	return body.includes(MODEL_BUSY_CODE);
+	return statesBusinessCode(body, MODEL_BUSY_CODE);
 }
 /**
 * Whether a failure body belongs to the `11128` gate family AT ALL.
 *
-* The code is matched in its quoted-key form (`"code":11128`): a request id is
-* hexadecimal and can contain the digits `11128` by coincidence, and a bare
-* substring search over an arbitrary failure body is how a red herring gets
-* promoted into a diagnosis.
+* The code is READ, not text-matched (issue #155): a spaced or string-quoted
+* envelope used to fall out of the family here, and out of the rescue ladder
+* with it. {@link statesBusinessCode} keeps both reads.
 */
 function isChannelGateFamilyBody(body) {
-	return body.includes(CHANNEL_REJECT_CODE);
+	return statesBusinessCode(body, CHANNEL_REJECT_CODE);
 }
 /**
 * Whether a failure body is the gateway's CHANNEL gate — i.e. whether it
@@ -2791,14 +2889,12 @@ function isChannelRejectBody(body) {
 * `msg` can. Hence the wording is the criterion and the code is the
 * corroboration, never the other way round.
 *
-* BOTH halves are required, and the code is matched in its quoted-key form
-* (`"code":11128`): a request id is hexadecimal and can contain the digits
-* `11128` by coincidence, and a bare substring search over an arbitrary
-* failure body is how a red herring gets promoted into a diagnosis.
+* BOTH halves are required, and the code is read by {@link statesBusinessCode}
+* rather than text-matched, so a spaced envelope names its member too (issue
+* #155). The wording half stays case-insensitive: it is prose.
 */
 function isConversationIdGateBody(body) {
-	const lower = body.toLowerCase();
-	return lower.includes(CHANNEL_REJECT_CODE) && lower.includes(CONVERSATION_ID_GATE_MARKER);
+	return statesBusinessCode(body, CHANNEL_REJECT_CODE) && body.toLowerCase().includes(CONVERSATION_ID_GATE_MARKER);
 }
 /**
 * Whether a failure body is the FIRST-MESSAGE gate (`11128`).
@@ -2811,11 +2907,11 @@ function isConversationIdGateBody(body) {
 *
 * Excluded from the prompt diagnosis for the same reason as
 * {@link isConversationIdGateBody}, and named by the same rule: the CODE plus
-* the WORDING, case-insensitively, code in its quoted-key form.
+* the WORDING, the code read rather than text-matched (issue #155), the wording
+* case-insensitively.
 */
 function isFirstMessageGateBody(body) {
-	const lower = body.toLowerCase();
-	return lower.includes(CHANNEL_REJECT_CODE) && lower.includes(FIRST_MESSAGE_GATE_MARKER);
+	return statesBusinessCode(body, CHANNEL_REJECT_CODE) && body.toLowerCase().includes(FIRST_MESSAGE_GATE_MARKER);
 }
 /**
 * Which member of the `11128` family a body is, decided by the plugin's OWN
@@ -2885,7 +2981,7 @@ function classifyUpstreamError(status, body) {
 	if (status === 402) return "hard_credit";
 	const lower = body.toLowerCase();
 	for (const marker of HARD_CREDIT_MARKERS) if (lower.includes(marker.toLowerCase()) || body.includes(marker)) return "hard_credit";
-	if (body.includes(CREDITS_EXHAUSTED_CODE)) return "hard_credit";
+	if (statesBusinessCode(body, CREDITS_EXHAUSTED_CODE)) return "hard_credit";
 	for (const marker of SESSION_DEAD_MARKERS) if (body.includes(marker)) return "session_dead";
 	if (isAccountRestrictedBody(body)) return "account_restricted";
 	if (isContentPolicyBody(body)) return "policy_reject";
@@ -2931,7 +3027,8 @@ function parseUpstreamErrorDetail(body) {
 	const displayMsg = localizedText(raw.displayMsg) ?? (typeof raw.msg === "string" ? raw.msg : void 0);
 	const tips = localizedText(raw.displayTips);
 	const detail = {};
-	if (typeof raw.code === "number") detail.upstreamCode = raw.code;
+	const statedCode = businessCodeOfDocument(raw);
+	if (statedCode !== void 0) detail.upstreamCode = statedCode;
 	if (typeof raw.requestId === "string") detail.requestId = raw.requestId;
 	if (typeof raw.msg === "string" && raw.msg !== "") detail.rawMsg = raw.msg;
 	if (displayMsg !== void 0) detail.displayMsg = displayMsg;
@@ -4321,10 +4418,21 @@ function parseEnterpriseInstant(value) {
 * A JSON body on a 401/403 is still a credential refusal: the edge answered in
 * the business shape, but the token is just as unusable, so it maps to the same
 * actionable error instead of a generic "client" failure.
+*
+* THE CLASSIFIER IS HANDED THE CODE, NOT JUST THE SENTENCE (issue #155's sibling).
+* `readEnvelope` has already parsed `code` as a number, and this call used to
+* rebuild its diagnosis from `msg` alone — a sentence that never contains
+* `"code":…`. Every family that decides on its business code was therefore
+* invisible here, and the answer fell through to `client`: the report filed as
+* `workbuddy upstream client (http 400): 请求被拦截，请重新发送` (#144) is one
+* envelope whose code the Host was already holding. Re-stating the envelope in
+* its canonical form is what lets the shared classifier see both halves it is
+* written to read: the code, and the same `msg` wording it saw before. Strictly
+* more information than the text-only call, never less.
 */
 function envelopeError(status, envelope) {
 	if (status === 401 || status === 403) return new WorkBuddyCredentialRejectedError(status);
-	const kind = classifyUpstreamError(status, envelope.msg);
+	const kind = classifyUpstreamError(status, `{"code":${envelope.code},"msg":${JSON.stringify(envelope.msg)}}`);
 	return /* @__PURE__ */ new Error(`workbuddy upstream ${kind} (http ${status}): ${envelope.msg.slice(0, 160)}`);
 }
 /**
@@ -7566,7 +7674,7 @@ function describeRosterSeenPayload(raw) {
 //#endregion
 //#region src/version.ts
 /** The npm package version this build was produced from. */
-const WORKBUDDY_CONNECT_VERSION = "5.12.2";
+const WORKBUDDY_CONNECT_VERSION = "5.12.3";
 //#endregion
 //#region src/host-heartbeat.ts
 /**

package/lib/index.js

@@ -1,4 +1,4 @@
-import { $ as parseCreditMultiplier, $t as withFileLock, A as isEncryptedCredentialError, At as pickMediaModel, B as WorkBuddyCredentialRejectedError, Bt as deriveAtRestKeyId, C as WorkBuddyCredentialStore, Ct as IMAGE_TAG_TEXT_TO_IMAGE, D as defaultDesktopAuthDirs, Dt as imageMimeForPath, E as defaultDesktopAuthCandidates, Et as imageDataUrl, F as workbuddyAccountId, Ft as imageDefaultFor, G as forceNeutralHead, Gt as isWorkbuddyBundle, H as channelGateMemberOf, Ht as findWorkbuddyAppExecutable, I as workbuddyOwnAuthPath, It as nativeModalityOf, J as isCredentialRejectedError, Jt as openEncryptedField, K as isContextTooLongBody, Kt as macosBundleExecutable, L as CONTEXT_OVERFLOW_MARKER, Lt as WORKBUDDY_APP_EXECUTABLE_ENV, M as legacyWorkbuddyOwnAuthPath, Mt as parseQueueAnswer, N as parseWorkBuddyAuth, Nt as queueNoticeText, O as defaultDesktopAuthPath, Ot as isBareBase64Image, P as preferredAccountName, Pt as NATIVE_MODALITY_BY_MODEL_ID, Q as openingEvidenceOfBody, Qt as resolveDshHome, R as CREDENTIAL_REJECTED_CODE, Rt as clearAtRestKeyCache, S as WORKBUDDY_AUTH_FILE_ENV, St as IMAGE_TAG_IMAGE_TO_IMAGE, T as authFileName, Tt as WorkBuddyImageError, U as classifyUpstreamError, V as WorkBuddyUpstreamClient, Vt as fetchAtRestKeyPayload, W as declaredTools, Wt as isEncryptedFieldWrapper, X as knownRegionOf, Xt as workbuddyAppExecutableCandidates, Y as isFirstMessageGateBody, Yt as readAtRestKey, Z as modelIdOfBody, _ as deriveCatalog, _t as WorkBuddyVideoError, a as readHostHeartbeat, at as requestEvidenceOf, b as ENCRYPTED_CREDENTIAL_CODE, bt as resolveVideoParams, c as WORKBUDDY_CONNECT_VERSION, ct as REFUSES_OFF_MODEL_IDS, dt as offDefaultFor, en as writeFileAtomic, et as parseReasoning, f as piAiRuntimeInfo, ft as offRefused, g as applyContextBudgets, gt as VIDEO_TAG_TEXT_TO_VIDEO, h as WorkBuddyCatalog, ht as VIDEO_TAG_IMAGE_TO_VIDEO, i as processStartTimeMs, it as regionOf, j as isVaultAccountId, jt as sniffImageMime, k as hasEncryptedCredentialFields, kt as parseImageDataUrl, l as createFileRosterSeenStore, lt as defaultOffModelIds, m as FALLBACK_WORKBUDDY_MODELS_GLOBAL, mt as withEffectiveOff, n as clearHostHeartbeat, nt as perturbChannelFingerprints, o as workbuddyHostHeartbeatPath, ot as rewriteSessionTitleModel, p as FALLBACK_WORKBUDDY_MODELS, pt as recordRefusal, q as isConversationIdGateBody, qt as macosNestedAppBundles, r as isHeartbeatProcessAlive, rt as prepareChatBody, s as writeHostHeartbeat, st as attachBusyLevels, t as WORKBUDDY_HOST_HEARTBEAT_FILENAME, tt as parseUpstreamModel, ut as lastRefusalFor, v as fallbackModelsFor, vt as parseSupportedSecondsRange, w as WorkBuddyEncryptedCredentialError, wt as MAX_INPUT_IMAGE_BYTES, x as WORKBUDDY_AUTH_FILENAME, xt as DEFAULT_IMAGE_SIZE, y as withoutRouters, yt as pickVideoModel, z as WORKBUDDY_FALLBACK_SYSTEM_PROMPT, zt as deriveAtRestKey } from "./host-heartbeat-BdTV4Aoi.js";
+import { $ as parseCreditMultiplier, $t as withFileLock, A as isEncryptedCredentialError, At as pickMediaModel, B as WorkBuddyCredentialRejectedError, Bt as deriveAtRestKeyId, C as WorkBuddyCredentialStore, Ct as IMAGE_TAG_TEXT_TO_IMAGE, D as defaultDesktopAuthDirs, Dt as imageMimeForPath, E as defaultDesktopAuthCandidates, Et as imageDataUrl, F as workbuddyAccountId, Ft as imageDefaultFor, G as forceNeutralHead, Gt as isWorkbuddyBundle, H as channelGateMemberOf, Ht as findWorkbuddyAppExecutable, I as workbuddyOwnAuthPath, It as nativeModalityOf, J as isCredentialRejectedError, Jt as openEncryptedField, K as isContextTooLongBody, Kt as macosBundleExecutable, L as CONTEXT_OVERFLOW_MARKER, Lt as WORKBUDDY_APP_EXECUTABLE_ENV, M as legacyWorkbuddyOwnAuthPath, Mt as parseQueueAnswer, N as parseWorkBuddyAuth, Nt as queueNoticeText, O as defaultDesktopAuthPath, Ot as isBareBase64Image, P as preferredAccountName, Pt as NATIVE_MODALITY_BY_MODEL_ID, Q as openingEvidenceOfBody, Qt as resolveDshHome, R as CREDENTIAL_REJECTED_CODE, Rt as clearAtRestKeyCache, S as WORKBUDDY_AUTH_FILE_ENV, St as IMAGE_TAG_IMAGE_TO_IMAGE, T as authFileName, Tt as WorkBuddyImageError, U as classifyUpstreamError, V as WorkBuddyUpstreamClient, Vt as fetchAtRestKeyPayload, W as declaredTools, Wt as isEncryptedFieldWrapper, X as knownRegionOf, Xt as workbuddyAppExecutableCandidates, Y as isFirstMessageGateBody, Yt as readAtRestKey, Z as modelIdOfBody, _ as deriveCatalog, _t as WorkBuddyVideoError, a as readHostHeartbeat, at as requestEvidenceOf, b as ENCRYPTED_CREDENTIAL_CODE, bt as resolveVideoParams, c as WORKBUDDY_CONNECT_VERSION, ct as REFUSES_OFF_MODEL_IDS, dt as offDefaultFor, en as writeFileAtomic, et as parseReasoning, f as piAiRuntimeInfo, ft as offRefused, g as applyContextBudgets, gt as VIDEO_TAG_TEXT_TO_VIDEO, h as WorkBuddyCatalog, ht as VIDEO_TAG_IMAGE_TO_VIDEO, i as processStartTimeMs, it as regionOf, j as isVaultAccountId, jt as sniffImageMime, k as hasEncryptedCredentialFields, kt as parseImageDataUrl, l as createFileRosterSeenStore, lt as defaultOffModelIds, m as FALLBACK_WORKBUDDY_MODELS_GLOBAL, mt as withEffectiveOff, n as clearHostHeartbeat, nt as perturbChannelFingerprints, o as workbuddyHostHeartbeatPath, ot as rewriteSessionTitleModel, p as FALLBACK_WORKBUDDY_MODELS, pt as recordRefusal, q as isConversationIdGateBody, qt as macosNestedAppBundles, r as isHeartbeatProcessAlive, rt as prepareChatBody, s as writeHostHeartbeat, st as attachBusyLevels, t as WORKBUDDY_HOST_HEARTBEAT_FILENAME, tt as parseUpstreamModel, ut as lastRefusalFor, v as fallbackModelsFor, vt as parseSupportedSecondsRange, w as WorkBuddyEncryptedCredentialError, wt as MAX_INPUT_IMAGE_BYTES, x as WORKBUDDY_AUTH_FILENAME, xt as DEFAULT_IMAGE_SIZE, y as withoutRouters, yt as pickVideoModel, z as WORKBUDDY_FALLBACK_SYSTEM_PROMPT, zt as deriveAtRestKey } from "./host-heartbeat-D1N-f8Q6.js";
 import z from "@deepseek-ai/schemastery";
 import { appendFile, mkdir, open, readFile, rename, rm, stat, writeFile } from "node:fs/promises";
 import { randomBytes, randomUUID, timingSafeEqual } from "node:crypto";
@@ -715,6 +715,82 @@ function nextRegionEnabled(value, region, enabled) {
 	});
 }
 /**
+* The per-region account SELECTIONS map (`Config.accounts`), as plain data.
+*
+* `value` may be the whole settings SECTION or the `accounts` FIELD: `describe()`
+* hands back the section with volatile fields as live references, and a blind
+* spread of that leaks the `get()` function into a write payload — the settings
+* service then refuses the whole save with `found a function at $.ops[0].value.get`
+* (measured at the card's save endpoint, `src/web-status.ts`). Unwrapping first is
+* what makes the merge carry data and not behaviour.
+*
+* The map is recognised by its KEYS, not by its shape: only region ids can appear
+* in it, while a section always carries at least one non-region key (`authFile`,
+* `regions`, `cliBridge`). Same direction as {@link regionsMapOf} chose for the
+* reason documented there — a nested copy is a DIFFERENT, older value, so the
+* outer object's own keys decide what it is.
+*/
+function accountsMapOf(value) {
+	const unwrapped = unwrapVolatileDeep(value);
+	if (!isRecord$1(unwrapped)) return {};
+	if (hasRegionKey(unwrapped)) return unwrapped;
+	const nested = unwrapVolatileDeep(unwrapped["accounts"]);
+	return isRecord$1(nested) ? nested : {};
+}
+/**
+* Build the next `accounts` FIELD for one region's selection.
+*
+* ONLY the target region's key changes; the sibling region is carried over
+* verbatim. `accounts` is a flat two-key map that BOTH regions write, so a
+* whole-field write that rebuilt it from one caller's view would drop the other
+* region's pin — the failure mode every other `next*` helper in this file exists
+* to prevent, in a field that is easier to clobber because it looks trivial.
+*
+* The value is written as given, including `''`. That distinction is load-bearing
+* and not a detail: `''` is the Clear sentinel ("this region follows the app's
+* current sign-in"), while an ABSENT key means "never configured" and still falls
+* back to the legacy flat `accountId` — see `selectAccountFor`. A helper that
+* deleted the key to "clear" a region would silently re-bind it to whichever
+* account the legacy field names.
+*/
+function nextAccountsSelection(value, region, accountId) {
+	return {
+		...accountsMapOf(value),
+		[region]: accountId
+	};
+}
+/**
+* Whether one region's selection is PERSISTENTLY bound to this account id.
+*
+* THE QUESTION {@link nextAccountsSelection} MUST ANSWER BEFORE WRITING. Two
+* persisted sources can pin an account, and clearing only the obvious one leaves
+* the other in place:
+*
+* 1. `accounts[region]` — the per-region slot, the current spelling.
+* 2. the deprecated flat `accountId`, which `selectAccountFor` falls back to for
+*    the ONE region the startup scan attributed it to (`legacyAccountRegion`) and
+*    only when that region's slot is ABSENT. A pre-split profile therefore pins
+*    its account through field 2 while field 1 holds nothing at all — and that
+*    is precisely a profile whose user can remove an account and inherit an
+*    orphaned pin.
+*
+* `accounts[region] === ''` answers `false` even when the id matches nothing: the
+* sentinel means "this region follows the app's current sign-in", which already
+* cannot point at a dead account, so there is nothing to clear and a write would
+* be noise (and a needless settings round trip).
+*
+* @param value the resolved settings section, or the `accounts` field.
+* @param region the region whose pin is being questioned.
+* @param accountId the account about to be removed.
+* @param legacyAccountId the deprecated flat `accountId`, read as persisted.
+* @param legacyRegion which region the startup scan attributed that flat id to.
+*/
+function regionPinsAccount(value, region, accountId, legacyAccountId, legacyRegion) {
+	const configured = accountsMapOf(value)[region];
+	if (configured !== void 0) return configured === accountId;
+	return legacyAccountId !== void 0 && legacyAccountId === accountId && legacyRegion === region;
+}
+/**
 * Project one card row into its persisted `lastCatalog` shape: the native
 * context window becomes the stored `contextWindow`, and the card-only
 * presentation fields (`nativeContextWindow`, `multimodal`) are removed BY
@@ -897,6 +973,64 @@ async function healRegionsField(service, ns) {
 	}], void 0);
 	return true;
 }
+/**
+* Drop one region's PERSISTED account selection, and only if it pinned this
+* account.
+*
+* THE HOST-SIDE HALF OF ISSUE #155'S SECOND REPORT. A user removed one account
+* and the whole CN tab turned into「已保存的账号在本机已不存在」, with no way back:
+* the card's advice points at a list it does not render in that state, so the
+* reporter escaped by hand-posting `{"field":"accounts","value":{"cn":""}}` to
+* the save endpoint. This is that write, made automatic.
+*
+* WHY A WRITE AT ALL — the store already forgets. `removeAccount` clears the
+* in-memory selection, which is why the region keeps working for the rest of the
+* session. But the settings document still names the dead id, so the next
+* `applySelection` — a restart, or any settings save — re-reads it, re-pins it,
+* and the region falls back into the same dead end. An in-memory forget that is
+* never persisted is not a fix; it is a delay.
+*
+* THE DECISION LIVES HERE, WITH THE WRITE, because the two must never be
+* separated by a caller's guess. Clearing a region that did NOT pin this account
+* would move the user off the account they chose, and「换账号等于换人计费」is the
+* rule every writer in this plugin obeys: this function writes for exactly the
+* region whose persisted pin names the account being removed, and no others.
+*
+* WRITES `''`, NEVER A DELETED KEY. The sentinel means "follow the app's current
+* sign-in" — the plugin's documented default, which is what a fresh install does,
+* so this restores a state rather than inventing one. An absent key means "never
+* configured" and falls through to the legacy flat `accountId` (`selectAccountFor`),
+* which would resurrect whichever account that field names: a silent switch
+* through another door. The sentinel also TERMINATES that lookup, which is why one
+* write settles both spellings — a pre-split profile pinned through the flat
+* field is cleared by this same write.
+*
+* FAIL-SOFT BY CONTRACT: a service that cannot answer, or a region that pinned
+* nothing, costs no write. The caller logs a failed mutation rather than failing
+* the removal, because the credential file is already gone by then and reporting
+* "could not remove" would be the lie.
+*
+* @param service The Host's settings service, or `undefined` to no-op.
+* @param ns The namespace this plugin's settings live under.
+* @param region The region being checked; the sibling is preserved by the merge.
+* @param accountId The account about to be removed.
+* @param legacyAccountId The deprecated flat `accountId`, as persisted.
+* @param legacyRegion Which region the startup scan attributed that field to.
+* @returns whether a write happened.
+*/
+async function clearRegionAccountSelection(service, ns, region, accountId, legacyAccountId, legacyRegion) {
+	if (service === void 0) return false;
+	const row = service.describe().find((entry) => entry.ns === ns);
+	if (row === void 0) return false;
+	const section = row.value ?? {};
+	if (!regionPinsAccount(section, region, accountId, legacyAccountId, legacyRegion)) return false;
+	await service.mutate(ns, [{
+		op: "set",
+		path: ["accounts"],
+		value: nextAccountsSelection(section, region, "")
+	}], void 0);
+	return true;
+}
 //#endregion
 //#region src/credential-recovery.ts
 /** How long a verdict stays fresh by default. */
@@ -12017,8 +12151,31 @@ function apply(ctx, config) {
 			* Forget ONE account's plugin-stored credential (the vault entry; the
 			* desktop app's files are never touched). The card rescans afterwards,
 			* so the row disappears the moment the write lands.
+			*
+			* AND DROP THE REGION'S PERSISTED PIN, when this was the pinned account
+			* (issue #155's second report). `removeAccount` forgets the selection in
+			* memory only, so the next `applySelection` — a restart, or any settings
+			* save — re-reads the dead id out of `accounts.<region>`, re-pins it, and
+			* the tab returns to「已保存的账号在本机已不存在」with the card's advice
+			* pointing at a list that state does not render. The clear is decided from
+			* the settings document rather than from the store, and is scoped to the
+			* one region that pinned this account: an unrelated removal must not move
+			* anybody off the account they chose.
+			*
+			* FAIL-SOFT, like the field repair above: the credential is already gone by
+			* the time this runs, so a settings write that cannot land must not be
+			* reported as a failed removal — that would tell the user the account is
+			* still there when it is not.
 			*/
-			removeOne: async (region, accountId) => stacks[region].store.removeAccount(accountId)
+			removeOne: async (region, accountId) => {
+				const removed = await stacks[region].store.removeAccount(accountId);
+				try {
+					await clearRegionAccountSelection(hostSettings(), settingsNs, region, accountId, unwrapVolatile(current().accountId), legacyAccountRegion);
+				} catch (error) {
+					ctx.logger.warn("dsh-connect-workbuddy: the account was removed, but the region could not be un-pinned from settings; the selection may reappear as orphaned after a restart", error);
+				}
+				return removed;
+			}
 		},
 		/**
 		* OAuth QR sign-in for this card. The session lives in `src/oauth.ts`

package/package.json

@@ -2,7 +2,7 @@
   "name": "dsh-connect-workbuddy",
   "displayName": "DSH Connect WorkBuddy",
   "description": "把本机登录的 WorkBuddy 模型（国内版与国际版）接入 DeepSeek Harness：每次刷新按上游目录自动读取每个模型的积分倍率，支持逐模型图片输入开关、多账号切换与账号池自动换号，并提供每日签到、卡片与输入框里的胶囊积分读数等只读积分概览。",
-  "version": "5.12.2",
+  "version": "5.12.3",
   "author": "dingminhua",
   "copyright": "Copyright (c) 2026 LaoDing",
   "license": "MIT",