dsh-xdpool 2.1.0 → 2.1.1

package/README.en.md

@@ -2,11 +2,15 @@
 
 <p align="center">
   <a href="https://www.npmjs.com/package/dsh-xdpool"><img src="https://img.shields.io/npm/v/dsh-xdpool?style=flat-square&label=npm&color=cb3837" alt="npm version"></a>
-  <a href="https://www.npmjs.com/package/dsh-xdpool"><img src="https://img.shields.io/npm/d18m/dsh-xdpool?style=flat-square&label=downloads&color=cb3837" alt="npm downloads"></a>
+  <a href="https://www.npmjs.com/package/dsh-workbuddy-xdpool"><img src="https://img.shields.io/badge/downloads-9k%2Fmo%20%28prev%20name%29-cb3837?style=flat-square" alt="npm downloads under the previous name"></a>
   <a href="LICENSE"><img src="https://img.shields.io/github/license/XDTrees/dsh-xdpool?style=flat-square" alt="MIT license"></a>
   <a href="https://github.com/XDTrees/dsh-xdpool/stargazers"><img src="https://img.shields.io/github/stars/XDTrees/dsh-xdpool?style=flat-square" alt="GitHub stars"></a>
 </p>
 
+<p align="center">
+  <sub>Download stats still come from the previous package name <code>dsh-workbuddy-xdpool</code> (8,976/month as of 2026-10-12 — every download before the rename; the live shields badge kept getting rate-limited by the npm upstream, hence the snapshot figure). The new <code>dsh-xdpool</code> package accumulates its own stats, and the badge switches back to live data later.</sub>
+</p>
+
 English | [中文](./README.md)
 
 **Every free model quota you can get your hands on, wired into one DSH model pool.**
@@ -46,9 +50,9 @@ Then it grew into seven pages. Beyond the account pool: sign in to thirteen vend
 
 ![Aggregate channels: the aggregate switch, a search box, and the category filters — all 76 / API key 60 / free 1 / has free quota 10 / local 3 / needs authorization 2](assets/aggregate-channels.png)
 
-**The plugin card (Settings → Plugins → DSH WorkBuddy XD Pool)**
+**Account credit detail (a pool account: credit packages, streak, today's check-in, the credit reserve)**
 
-![WorkBuddy pool card: CN/global tabs, pool health, account panels with credit packages, per-account check-in, the points-automation panel, and the model directory](assets/settings-card.png)
+![Account credit detail: the active account expanded shows the credit total, a 16-day streak, the daily +100 credits, a checked-in-today button, CodeBuddy package balances with their expiry dates, and the credit-reserve input](assets/account-credits.png)
 
 **The points-automation panel**
 

package/README.md

@@ -2,11 +2,15 @@
 
 <p align="center">
   <a href="https://www.npmjs.com/package/dsh-xdpool"><img src="https://img.shields.io/npm/v/dsh-xdpool?style=flat-square&label=npm&color=cb3837" alt="npm version"></a>
-  <a href="https://www.npmjs.com/package/dsh-xdpool"><img src="https://img.shields.io/npm/d18m/dsh-xdpool?style=flat-square&label=downloads&color=cb3837" alt="npm downloads"></a>
+  <a href="https://www.npmjs.com/package/dsh-workbuddy-xdpool"><img src="https://img.shields.io/badge/downloads-9k%2F%E6%9C%88%20%28%E6%97%A7%E5%90%8D%29-cb3837?style=flat-square" alt="npm downloads under the previous name"></a>
   <a href="LICENSE"><img src="https://img.shields.io/github/license/XDTrees/dsh-xdpool?style=flat-square" alt="MIT license"></a>
   <a href="https://github.com/XDTrees/dsh-xdpool/stargazers"><img src="https://img.shields.io/github/stars/XDTrees/dsh-xdpool?style=flat-square" alt="GitHub stars"></a>
 </p>
 
+<p align="center">
+  <sub>下载量统计沿用旧包名 <code>dsh-workbuddy-xdpool</code>（截至 2026-10-12 为 8,976 次/月，改名前的全部下载；shields 的实时徽章常被 npm 上游限流，所以这里用了快照数字）。新包 <code>dsh-xdpool</code> 的统计会随时间累积，之后徽章会换回实时数据。</sub>
+</p>
+
 [English](./README.en.md) | 中文
 
 **把你手上所有能白嫖的模型额度，接进 DSH 的同一个模型池。**
@@ -46,9 +50,9 @@
 
 ![聚合渠道：聚合开关、搜索框、全部分类 76 / API Key 60 / 免费 1 / 有免费额度 10 / 本地 3 / 需授权 2 的分类筛选](assets/aggregate-channels.png)
 
-**插件配置卡片（设置 → 「XD Pool」一节）**
+**账号积分详情（池中账号：积分包、连签天数、今日已签、保留积分）**
 
-![WorkBuddy 池设置卡片：国内版 / 国际版切换栏、池健康状态、账号面板、积分包与合计、每账号每日签到、积分自动化面板、模型管理](assets/settings-card.png)
+![账号积分详情：当前使用的账号展开后显示合计积分、连签 16 天、每日 +100 积分、今日已签按钮、CodeBuddy 积分包余额与到期时间，以及保留积分输入框](assets/account-credits.png)
 
 **积分自动化面板**
 

package/cordis.patch.yml

@@ -1,49 +1,48 @@
-# Register the WorkBuddy XD Pool provider. Discovery is read-only: the plugin
-# reuses the WorkBuddy desktop app's own sign-in files and never starts a
-# separate OAuth flow. Requests rotate across every discovered account.
-- insert:
-    - id: llm-xdpool
-      name: dsh-xdpool
-# Bring up billion-context alongside us, so the card's billion page has a live
-# compressor to read instead of asking the user to install a second plugin.
-#
-# WHY THIS ROW LIVES HERE
-#
-# billion-context is a full plugin in its own right: it owns a loopback proxy, a
-# compaction lane and its own CLI. Nothing about it is a feature of this pool, and
-# this layer must never configure it — the row below only asks the host to mount
-# the package, and every other decision stays billion-context's.
-#
-# WHY IT IS NOT A DEPENDENCY OF OURS IN THE USUAL SENSE
-#
-# `dependencies` would make this a transitive requirement of the pool: upgrading
-# the pool would silently move the compressor's version under a user who only
-# ever installed the pool, and uninstalling the pool would take a feature the user
-# may still be using. Declaring it optional keeps both directions under the
-# user's control while still letting the host install it.
-#
-# THE DUPLICATE-MOUNT HAZARD, AND WHY IT IS SAFE HERE
-#
-# Mounting billion-context twice throws. The proxy provides a cordis service
-# under its own name, and the host refuses a second registration
-# (`service "…" has been registered at <…>`) rather than handing back the first
-# one, so the loser dies inside its own `apply`. That is exactly the failure this
-# pool already hit once with the shared sign-in channel pack, and it is why
-# `src/index.ts` checks the loader for a live entry before mounting anything.
-#
-# This row does not need that guard of its own: the host's own loader disables a
-# row whose module is already mounted elsewhere rather than letting it collide,
-# and the row id is unique to this layer. If a user has already added
-# billion-context to their profile themselves, this row is simply a second copy
-# of an existing layer and the host resolves that, not us.
-#
-# THE ID IS OURS AND MUST STAY OURS
-#
-# `bili-native` is declared by billion-context's own patch. A non-insert patch
-# replaces a row's whole config with no deep merge, so we must not restate its
-# config here — we only ever insert a row, which is additive and safe. Naming
-# this row `billion-context-xdpool` rather than `bili-native` keeps the two layers
-# from ever addressing the same entry.
-- insert:
-    - id: billion-context-xdpool
-      name: billion-context
+# Register the XD Pool provider. Discovery is read-only: the plugin reuses the
+# WorkBuddy desktop app's own sign-in files and never starts a separate OAuth
+# flow. Requests rotate across every discovered account.
+- insert:
+    - id: llm-xdpool
+      name: dsh-xdpool
+# billion-context is deliberately NOT mounted by this layer.
+#
+# 2.0.0 tried to. It inserted a row (`billion-context-xdpool`) so a profile that
+# had not installed the compressor would get one for free, and `src/billion-mount.ts`
+# held a runtime `create()` as a second path for the same job. Measured against a
+# profile that had ALREADY installed billion-context — which is the normal state
+# for anyone using that feature, since `bili-native` comes from billion-context's
+# own `dsh.bundle.patch.yml` — neither safeguard held:
+#
+#   the host did not disable our duplicate row, and it did not resolve it to a
+#   no-op. It left `enabled: true` and ran the fiber to `failed`, because
+#   billion-context registers a cordis service under its own name and a second
+#   registration is refused outright (`service "…" has been registered at <…>`).
+#
+# So every user who had installed billion-context got a permanently failed entry
+# in their plugin list — visible, unexplained, and pointing at us.
+#
+# The row below is kept, but DISABLED, for three reasons:
+#
+#   1. Addressability. `disabled: true` keeps the row's id resolvable, so a
+#      profile that wants to flip it on can do so with one edit instead of
+#      inventing a row.
+#   2. It states the decision where the old attempt lived, where the next person
+#      to wonder "why doesn't the pool bring up the compressor?" will look.
+#   3. It keeps `bili-native` (billion-context's own row) as the ONLY mount of
+#      that module, which is the arrangement that actually works.
+#
+# CONSEQUENCE, STATED PLAINLY
+#
+# A profile that has not installed billion-context sees the billion card report
+# "not installed". That is the honest reading of the facts, and it is already a
+# first-class state on that page — the page distinguishes not-installed from
+# no-answer from ready precisely so this case reads as information rather than
+# as a bug. Installing billion-context remains a decision the user makes; the
+# pool no longer makes it for them.
+#
+# `src/billion-mount.ts` no longer calls `create()` for the same reason: with
+# this row disabled, a runtime create would fight the very row it sits beside.
+# The function still runs — it is what lets the card distinguish
+# already-installed from not-installed — it just never mounts anything.
+- id: billion-context-xdpool
+  disabled: true

package/lib/bin.js

@@ -224,6 +224,34 @@ function chatHeaders(credential) {
 		"X-Product": "SaaS"
 	};
 }
+/**
+* The client-identity headers the desktop app puts on every chat completion.
+*
+* WHY THESE EXIST AND WHY THEY BELONG ON /v2/chat/completions ONLY
+*
+* The gateway attributes each request to a client, and that attribution is what
+* surfaces in the user's billing console as the "使用端" column. The desktop app
+* (`buildVlmGatewayHeaders` in its bundled `main/server.js`) sends
+* `X-IDE-Type`/`X-IDE-Name`/`X-IDE-Version` on every `/v2/chat/completions`, so
+* its traffic reads as "WorkBuddy". Our chat requests sent none of them, so the
+* same spend attributed to nothing — the column showed "–" and the user's
+* billing page looked like the requests had come from nowhere.
+*
+* They are deliberately NOT part of `chatHeaders()`, which is shared with the
+* points-automation endpoints (`listTasks` / `acceptTasks`). Those are not chat
+* completions, and the evidence for the desktop app sending identity headers on
+* them is nil — adding identity headers to an endpoint that never carried them
+* risks changing how that traffic is attributed or filtered, and the automation
+* was never reported broken. Only the two chat completions get these.
+*
+* The version is the same literal `openConversation()` already sends, so both
+* chat paths — the pool's and the automation's — claim the same client.
+*/
+const CHAT_IDENTITY_HEADERS = Object.freeze({
+	"X-IDE-Name": "WorkBuddy",
+	"X-IDE-Type": "WorkBuddy",
+	"X-IDE-Version": "5.5.6"
+});
 /** Refresh-endpoint headers; X-Refresh-Token appears here and nowhere else. */
 function refreshHeaders(credential) {
 	const headers = {
@@ -819,7 +847,10 @@ var WorkBuddyUpstreamClient = class {
 	async completeChat(credential, prepared, signal) {
 		const response = await this.fetchImpl(`${chatBase(credential)}/v2/chat/completions`, {
 			method: "POST",
-			headers: chatHeaders(credential),
+			headers: {
+				...chatHeaders(credential),
+				...CHAT_IDENTITY_HEADERS
+			},
 			body: prepared,
 			...signal === void 0 ? {} : { signal }
 		});
@@ -836,7 +867,10 @@ var WorkBuddyUpstreamClient = class {
 		try {
 			response = await this.fetchImpl(`${chatBase(credential)}/v2/chat/completions`, {
 				method: "POST",
-				headers: chatHeaders(credential),
+				headers: {
+					...chatHeaders(credential),
+					...CHAT_IDENTITY_HEADERS
+				},
 				body: prepared,
 				...signal === void 0 ? {} : { signal }
 			});
@@ -1316,15 +1350,13 @@ var WorkBuddyUpstreamClient = class {
 				method: "POST",
 				headers: {
 					...chatHeaders(credential),
+					...CHAT_IDENTITY_HEADERS,
 					"Accept": "text/event-stream",
 					"User-Agent": DESKTOP_TASK_UA,
 					"X-Conversation-ID": conversationId,
 					"X-Request-ID": String(Date.now()) + "000000",
 					"X-Agent-Intent": "craft",
 					"X-Agent-Type": "main",
-					"X-IDE-Name": "WorkBuddy",
-					"X-IDE-Type": "WorkBuddy",
-					"X-IDE-Version": "5.5.6",
 					"x-codebuddy-request": "1",
 					...expertId === "" ? {} : { "X-Expert-Id": expertId }
 				},

package/lib/client.js

@@ -445,7 +445,6 @@ window.__ModuleLoader__.load({
    sharing a line with a total. */
 .dsm-xdpool-packages li{display:inline-flex;align-items:baseline;gap:5px;min-width:0;padding:1px 8px;border-radius:999px;border:1px solid var(--dsw-alias-border-l1,#2f3035);background:color-mix(in srgb, var(--dsw-alias-bg-layer-1,#191a1e) 62%, transparent);color:var(--dsw-alias-label-secondary,#c6c9d0);font-size:11px;line-height:17px}
 .dsm-xdpool-packages-name{min-width:0;overflow:hidden;text-overflow:ellipsis;white-space:nowrap}
-.dsm-xdpool-packages-value{color:var(--dsw-alias-label-tertiary,#999);font-variant-numeric:tabular-nums}
 /* Per-package deadline: the upstream grants one-off packs at arbitrary clock
    times, so each pack carries its own timestamp. It sits inside its own chip on
    its own line — a pack name plus two timestamps did not fit on one line, and
@@ -453,8 +452,17 @@ window.__ModuleLoader__.load({
 .dsm-xdpool-packages-when{color:var(--dsw-alias-label-tertiary,#9aa0a8);font-size:10.5px;line-height:15px;font-variant-numeric:tabular-nums}
 .dsm-xdpool-packages-when-soon{color:var(--dsw-alias-state-warning-primary,#d97706)}
 /* The balance. Still the most important figure on the row — colour and weight,
-   not size: at 28px it outweighed the account name it belongs to. */
-.dsm-xdpool-total-value{color:var(--dsw-alias-state-success-primary,#22a06b);font-size:16px;line-height:22px;font-weight:700;letter-spacing:-.2px;white-space:nowrap;font-variant-numeric:tabular-nums}
+   not size: at 28px it outweighed the account name it belongs to. The green is
+   pinned rather than taken from the theme alias: at 16px/700 the alias green
+   read darker than the 11px figures beside it on the same row — the same hex
+   looks dimmer in large bold type than in small text — and the user read the
+   balance as grey next to the bright green streak chips. A slightly brighter
+   literal keeps the two readings of "green" on this row identical. */
+.dsm-xdpool-total-value{color:#2fbf7f;font-size:16px;line-height:22px;font-weight:700;letter-spacing:-.2px;white-space:nowrap;font-variant-numeric:tabular-nums}
+/* Per-package figures share the balance's green: they are the same credit
+   balance broken down, and rendering them in grey made the packages look
+   spent while the total looked alive. */
+.dsm-xdpool-packages-value{color:#2fbf7f;font-variant-numeric:tabular-nums}
 /* Model directory list. */
 .dsm-xdpool-models{gap:10px}
 .dsm-xdpool-models-head{display:flex;align-items:center;justify-content:space-between;gap:12px}
@@ -5177,7 +5185,7 @@ window.__ModuleLoader__.load({
 		*
 		* @module dsh-xdpool/version
 		*/
-		const POOL_VERSION = "2.1.0";
+		const POOL_VERSION = "2.1.1";
 		//#endregion
 		//#region src/client/PoolCard.tsx
 		/**

package/lib/index.js

@@ -275,6 +275,34 @@ function chatHeaders(credential) {
 		"X-Product": "SaaS"
 	};
 }
+/**
+* The client-identity headers the desktop app puts on every chat completion.
+*
+* WHY THESE EXIST AND WHY THEY BELONG ON /v2/chat/completions ONLY
+*
+* The gateway attributes each request to a client, and that attribution is what
+* surfaces in the user's billing console as the "使用端" column. The desktop app
+* (`buildVlmGatewayHeaders` in its bundled `main/server.js`) sends
+* `X-IDE-Type`/`X-IDE-Name`/`X-IDE-Version` on every `/v2/chat/completions`, so
+* its traffic reads as "WorkBuddy". Our chat requests sent none of them, so the
+* same spend attributed to nothing — the column showed "–" and the user's
+* billing page looked like the requests had come from nowhere.
+*
+* They are deliberately NOT part of `chatHeaders()`, which is shared with the
+* points-automation endpoints (`listTasks` / `acceptTasks`). Those are not chat
+* completions, and the evidence for the desktop app sending identity headers on
+* them is nil — adding identity headers to an endpoint that never carried them
+* risks changing how that traffic is attributed or filtered, and the automation
+* was never reported broken. Only the two chat completions get these.
+*
+* The version is the same literal `openConversation()` already sends, so both
+* chat paths — the pool's and the automation's — claim the same client.
+*/
+const CHAT_IDENTITY_HEADERS = Object.freeze({
+	"X-IDE-Name": "WorkBuddy",
+	"X-IDE-Type": "WorkBuddy",
+	"X-IDE-Version": "5.5.6"
+});
 /** Refresh-endpoint headers; X-Refresh-Token appears here and nowhere else. */
 function refreshHeaders(credential) {
 	const headers = {
@@ -979,7 +1007,10 @@ var WorkBuddyUpstreamClient = class {
 	async completeChat(credential, prepared, signal) {
 		const response = await this.fetchImpl(`${chatBase(credential)}/v2/chat/completions`, {
 			method: "POST",
-			headers: chatHeaders(credential),
+			headers: {
+				...chatHeaders(credential),
+				...CHAT_IDENTITY_HEADERS
+			},
 			body: prepared,
 			...signal === void 0 ? {} : { signal }
 		});
@@ -996,7 +1027,10 @@ var WorkBuddyUpstreamClient = class {
 		try {
 			response = await this.fetchImpl(`${chatBase(credential)}/v2/chat/completions`, {
 				method: "POST",
-				headers: chatHeaders(credential),
+				headers: {
+					...chatHeaders(credential),
+					...CHAT_IDENTITY_HEADERS
+				},
 				body: prepared,
 				...signal === void 0 ? {} : { signal }
 			});
@@ -1476,15 +1510,13 @@ var WorkBuddyUpstreamClient = class {
 				method: "POST",
 				headers: {
 					...chatHeaders(credential),
+					...CHAT_IDENTITY_HEADERS,
 					"Accept": "text/event-stream",
 					"User-Agent": DESKTOP_TASK_UA,
 					"X-Conversation-ID": conversationId,
 					"X-Request-ID": String(Date.now()) + "000000",
 					"X-Agent-Intent": "craft",
 					"X-Agent-Type": "main",
-					"X-IDE-Name": "WorkBuddy",
-					"X-IDE-Type": "WorkBuddy",
-					"X-IDE-Version": "5.5.6",
 					"x-codebuddy-request": "1",
 					...expertId === "" ? {} : { "X-Expert-Id": expertId }
 				},
@@ -11334,21 +11366,32 @@ function createWorkBuddyAdapter(options) {
 /** The package name the loader resolves, exactly as our patch row names it. */
 const BILLION_PACKAGE = "billion-context";
 /**
-* Is this package already running?
+* Is this package installed and able to run?
+*
+* Any entry whose name matches counts — including one whose fiber has not
+* started yet. When this function still decided whether to mount, a fiber-less
+* entry had to be treated as absent: treating an import-in-flight as present
+* would have skipped the mount and left the compressor never starting. Now that
+* nothing mounts, the distinction only picks a label, and the honest one is
+* "installed": a user watching billion-context's own boot does not want the
+* card telling them it is missing while its proxy is half-way up.
 *
-* `fiber.uid` is the host's "this fiber has actually started" flag: an entry
-* that exists but never finished importing is not a second mount, it is a
-* mount in progress, and treating it as absent would race it.
+* A DISABLED entry does not count. `loader.entries()` yields disabled rows too
+* — the host skips starting them, it does not drop them — and our own patch
+* row is disabled on purpose. Counting it would make every profile that never
+* installed billion-context read as "installed", which is precisely the lie the
+* card must not tell.
 */
 function mountedInLoader(loader, packageName) {
 	for (const entry of loader.entries()) {
 		if (entry.options?.name !== packageName) continue;
-		if (entry.fiber?.uid !== void 0 && entry.fiber.uid !== null) return true;
+		if (entry.options?.disabled === true) continue;
+		return true;
 	}
 	return false;
 }
 /**
-* Bring billion-context up if it is not already running.
+* Report whether the compressor is already running. Never mounts.
 *
 * Resolves rather than rejects on every path: a compressor that will not start
 * is a card that says so, never a pool that fails to boot. The pool's own model
@@ -11369,12 +11412,7 @@ async function mountBillionContext(ctx, logger) {
 			logger.info?.(`[xdpool] billion-context is already mounted; leaving it alone`);
 			return { state: "already-mounted" };
 		}
-		await loader.create({
-			id: "billion-context-xdpool",
-			name: BILLION_PACKAGE
-		});
-		logger.info?.(`[xdpool] mounted billion-context for the billion card`);
-		return { state: "mounted" };
+		return { state: "not-required" };
 	} catch (error) {
 		return {
 			state: "unavailable",