dsh-astudio-connect 0.2.0 → 0.2.2

package/README.en.md

@@ -214,11 +214,20 @@ One press is two requests: read the pending list, then report completion. The ba
 | Outcome | Display |
 |---|---|
 | Claimed | Balance updates in place, `+100` appears in green beside the button and fades after 6 seconds |
-| Already claimed today / nothing pending yet | "Already claimed today"; the balance does not move |
+| Upstream answered `11003002` — booked before this press | "Already claimed today"; the balance does not move |
+| The pending list holds no reward | "Nothing to claim right now"; the balance does not move |
 | Sign-in expired (`code: 80000`, or 401/403) | Numbers cleared, "Sign-in expired" |
 | Upstream error / no `clientType` for this platform | "Unavailable" |
 
-Two identity headers are mandatory (without either, the gateway answers `11001001`): `clientType` (`21` on Windows, `22` on macOS) and `studioVersion`. The latter is only shape-checked, which is why the plugin sends a constant instead of reading the installed app's version — and why this works with AStudio uninstalled.
+The third row is deliberately not worded as "already claimed": the two are not the same state. `11003002` is upstream *saying* the popup was booked; an empty list only says the service is holding no reward at this moment — it may not have been issued yet, or the account may not have travelled with the request. Calling that "already claimed" tells someone to stop pressing a button that would still have worked, which is exactly what an earlier version did.
+
+"Not issued yet" is the common case, not the corner one: **the daily popup is only attached to the account once the desktop app starts.** Measured on `2026-11-05` with AStudio not running, every header combination polled `client-popups/pending` and got an empty list with the balance unchanged (7793); replaying the read-only endpoints the app hits on startup (`membership/me`, `points/summary`, `bot/models/configs`) changed nothing either. Starting the app the same day added 100 straight away. So the plugin can claim, but only on days you have already opened AStudio — otherwise there is no popup and the button truthfully reports "Nothing to claim right now". The headers are not the cause: adding `clientVersion` made no difference in an A/B run.
+
+`clientType` (`21` on Windows, `22` on macOS) and `studioVersion` are mandatory (without either, the gateway answers `11001001`). The desktop app also adds `clientVersion` to every request bound for an xfyun domain — both come from `electron.app.getVersion()`, currently `3.6.0` — and the plugin sends all three so its requests match the app's. The version is only shape-checked, which is why a constant works instead of reading the installed app's version, and why this works with AStudio uninstalled.
+
+One more detail `pending` will not forgive: `popupId` is a **positive integer**, and `complete` is parsed with `Number.isSafeInteger` upstream — a string makes the desktop client treat the whole popup config as invalid. The plugin used to read it as a string, which filtered out every reward the service sent while still reporting "already claimed", leaving the reward sitting there for the client to book. It now parses ids the way the client does and skips anything non-positive (the `-3` a preview uses, for instance).
+
+These endpoints are also scoped to the **account**, not just the session: the desktop client sends `ssoSessionId`, `sso_sessionid`, `account_id` and `token` on every account call. The plugin now sends all four, where it used to send only the session.
 
 > This is the plugin's **only** route that changes account state (`POST /astudio/claim`). It writes no local file, and it never touches other popup kinds in the pending list (announcements, feature tours): completing a popup it does not understand would mean deciding something on the user's behalf without knowing what.
 
@@ -276,6 +285,8 @@ Five write routes (probing, visibility, claim, and the two sign-in routes) requi
 
 | Plugin version | DSH kernel range it supports |
 |---|---|
+| `0.2.2` | `^0.2.1-rc.2` (from `0.2.1-rc.2`, below `0.3.0`) |
+| `0.2.1` | `^0.2.1-rc.2` (from `0.2.1-rc.2`, below `0.3.0`) |
 | `0.2.0` | `^0.2.1-rc.2` (from `0.2.1-rc.2`, below `0.3.0`) |
 | `0.1.1` | `^0.2.1-rc.2` (from `0.2.1-rc.2`, below `0.3.0`) |
 | `0.1.0` | `0.2.0-rc.2` (exact) |
@@ -284,6 +295,10 @@ The plugin declares a kernel range in `peerDependencies`; the host's `evaluatePl
 
 `0.2.0` carries the same kernel range as `0.1.1` and adds nothing but features: the points section in Settings (balance and the daily claim) and WeChat QR sign-in. One thing to know before upgrading — **from `0.2.0` the plugin writes a credential file to disk**. That is unavoidable for QR sign-in: without the app, somebody has to hold the session. It lives at `$DSH_HOME/.astudio-login.json`, mode `0600`, created only when you scan a code and deleted when you sign out. If you want the old behaviour — read the app's credentials and write nothing at all — stay on `0.1.1`.
 
+`0.2.1` is a fix-only release with an unchanged kernel range. **If you are on `0.2.0`, upgrade: its Claim button never actually claimed anything.** Pending popups carry `popupId` as a positive integer, but the plugin read it as a string, so every real reward was filtered out locally, the UI always said "already claimed today", and the reward sat untouched on the server — opening AStudio still claimed it. `0.2.1` parses the id the way the app does, separates "no pending reward" from an explicit `11003002` answer, and sends the four account-scoped cookies the claim endpoints expect.
+
+`0.2.2` only aligns the request headers, and **does not fix the "claimable only while the client is running" symptom**. Two changes: a new `clientVersion` header (constant `3.6.0`), and `studioVersion` moving from `3.5.5` to `3.6.0` — the desktop app's `fetchWithClientVersion` adds the former to every xfyun request and the plugin never sent it at all. An A/B run before and after this release showed the header is not the cause (see [Known limitations](#known-limitations)), so what this version actually delivers is making a plugin request indistinguishable from the app's, plus writing the real constraint into the docs: the daily reward is only issued after the desktop app has started. Any release note claiming this version fixed claiming is wrong.
+
 ## When the upstream refuses a request
 
 maas-api answers a non-conforming request with a bare `10005 invalid request` and never names the field. The plugin heals the request in the forwarding layer, in this order, without DSH or pi-ai having to change:
@@ -312,7 +327,8 @@ A refused body is also written to `%TEMP%\dsh-astudio-connect\failed-requests\`
 - [ ] **QR sign-in depends on three private upstream endpoints**: `scanlogin/qrcode` and `scanlogin/uids` on `sso.xfyun.cn`, plus the `api_key` inside `bot/models/configs`. If upstream adds a captcha, a signature or a device fingerprint, sign-in stops working (the panel then says "Sign-in is unavailable"), though a credential already stored keeps working.
 - [ ] **A stored sign-in is not refreshed**: once its `ssoSessionId` expires you have to scan again; the plugin does not renew it (upstream exposes no renewal endpoint — the client simply signs in again).
 - [ ] **One QR sign-in per DSH home**: switching accounts means signing out first; no multi-account coexistence.
-- [ ] **The claim button depends on two hard-coded client identity headers**: `clientType` (platform) and `studioVersion` (the constant `3.5.5`). If upstream ever demands a build number, a signature or a device fingerprint, this path dies immediately and the button will only report "Unavailable".
+- [ ] **The claim button depends on three hard-coded client identity headers**: `clientType` (platform), `studioVersion` and `clientVersion` (both constants, `3.6.0`, tracking the current client release). If upstream ever demands a build number, a signature or a device fingerprint, this path dies immediately and the button will only report "Unavailable".
+- [ ] **The daily reward is only claimable after the desktop app has run**: without the app, upstream never attaches the day's popup, so the plugin polls an empty list and the button truthfully reports "Nothing to claim right now". Measured on `2026-11-05` with the app closed: three header combinations plus a replay of the app's startup endpoints all left it empty; starting the app the same day added 100 immediately. This is upstream's issuance timing, not a defect the plugin can fix — claiming from DSH requires opening AStudio once that day.
 - [ ] **The CLI's `status` now issues one live fetch**: it waits for a real request so it can report the actual catalog source and model count; offline or signed out, it reports `empty` with the matching failure.
 - [ ] **No account-switch following**: unlike WorkBuddy's two variants, AStudio is a single product, so the plugin does not replicate variant-level capabilities.
 

package/README.md

@@ -214,11 +214,20 @@ GET  agent.xfyun.cn/xingchen-studio/bot/models/configs       → Cookie 用上
 | 结果 | 表现 |
 |---|---|
 | 领取成功 | 余额就地更新，按钮左侧显示 `+100`（绿色），6 秒后淡出 |
-| 今天已领过 / 服务端还没下发 | 显示「今日已领过」，余额不动 |
+| 上游明确回 `11003002`（这次点击之前就已入账） | 显示「今日已领过」，余额不动 |
+| 待领列表里没有这份奖励 | 显示「当前没有可领取的奖励」，余额不动 |
 | 登录已失效（`code: 80000` 或 401/403） | 数字清空并显示「登录已失效」 |
 | 上游异常 / 平台无对应 `clientType` | 显示「暂不可用」 |
 
-两个身份头是硬性要求（缺任一个，网关直接回 `11001001`）：`clientType`（Windows `21` / macOS `22`）与 `studioVersion`。后者只做形态校验，因此插件用常量而不是去读已安装的 AStudio 版本——这正是它能做到「不需要装 AStudio」的原因。
+第三种情况不写成「今日已领过」，因为这两种状态并不等价：`11003002` 是上游**明确**说这条弹窗早就被核销了；而列表为空只说明服务端此刻没挂着奖励，也可能只是今天还没下发，或者账号信息没有传全。把后者说成「已领过」，人就再也不会去点第二次了——早期版本正是在这里骗了用户。
+
+而「今天还没下发」这句话比想象中更常成立：**每日弹窗是桌面端启动之后才挂到账号上的**。实测（`2026-11-05`，客户端完全没开）三个请求头组合轮询 `client-popups/pending` 全部返回空列表、余额纹丝不动（7793）；把桌面端启动的那些只读接口（`membership/me`、`points/summary`、`bot/models/configs`）重放一遍，结论一样。同日启动客户端，余额随即 +100。所以插件能领，但前提是这一天你已经启动过 AStudio——不启动就不会有弹窗，按钮只能如实报「当前没有可领取的奖励」。请求头不是原因：补上 `clientVersion` 之后 A/B 结果没有任何变化。
+
+`clientType`（Windows `21` / macOS `22`）与 `studioVersion` 是硬性要求（缺任一个，网关直接回 `11001001`）。桌面端还会给所有讯飞域名的请求额外加一个 `clientVersion`（两者都取自 `electron.app.getVersion()`，当前是 `3.6.0`）；插件三个头都发，保持与客户端请求一致。版本号只做形态校验，所以用常量而不是去读已安装的 AStudio 版本——这正是它能做到「不需要装 AStudio」的原因。
+
+`pending` 的返回里还有一个必须按原样解析的细节：`popupId` 是**正整数**，`complete` 上游也用 `Number.isSafeInteger` 校验，客户端拿到字符串会直接判定整条弹窗配置非法。插件早期按字符串收，结果服务端下发的每一条奖励都被自己过滤掉了，界面照样报「今日已领过」，而奖励其实还老老实实躺在服务端——客户端一点就能领。现在按客户端的方式解析，非正整数的 id（例如预览用的 `-3`）直接跳过。
+
+这几个接口同时是按**账户**鉴权的：桌面端每个账号请求都带 `ssoSessionId`、`sso_sessionid`、`account_id`、`token` 四个 cookie。插件现在也照原样带上（早期只带 `ssoSessionId`）。
 
 > 这是本插件**唯一**会改动账户状态的接口（`POST /astudio/claim`）。它不改本地任何文件，也不碰 `pending` 里其它类型的弹窗（公告、功能引导等）：不理解的弹窗一律代用户完成，等于替用户做了一个不知道是什么的决定。
 
@@ -276,6 +285,8 @@ GET  agent.xfyun.cn/xingchen-studio/bot/models/configs       → Cookie 用上
 
 | 插件版本 | 支持的 DSH 内核版本 |
 |---|---|
+| `0.2.2` | `^0.2.1-rc.2`（`0.2.1-rc.2` 起，`0.3.0` 以下） |
+| `0.2.1` | `^0.2.1-rc.2`（`0.2.1-rc.2` 起，`0.3.0` 以下） |
 | `0.2.0` | `^0.2.1-rc.2`（`0.2.1-rc.2` 起，`0.3.0` 以下） |
 | `0.1.1` | `^0.2.1-rc.2`（`0.2.1-rc.2` 起，`0.3.0` 以下） |
 | `0.1.0` | `0.2.0-rc.2`（精确版本） |
@@ -284,6 +295,10 @@ GET  agent.xfyun.cn/xingchen-studio/bot/models/configs       → Cookie 用上
 
 `0.2.0` 的内核范围与 `0.1.1` 完全一致，发的只有功能：设置页的积分分区（看余额、领每日积分）与微信扫码登录。升级前需要知道一件事——**从 `0.2.0` 起插件会在本地落盘一个凭据文件**。这是扫码登录的必然结果：不装客户端就只能自己存会话。文件是 `$DSH_HOME/.astudio-login.json`，权限 `0600`，只在你主动扫码或点「退出登录」时增删；如果你只想要「读完客户端凭据就走、一个字节也不写」的旧行为，留在 `0.1.1`。
 
+`0.2.1` 是纯修复版，内核范围不变。**装了 `0.2.0` 的请升级：那一版的「领取」按钮实际领不到积分。** 待领弹窗的 `popupId` 是正整数，插件却按字符串接收，于是每条真实奖励都在本地被过滤掉，界面一律报「今日已领过」，而奖励还挂在服务端——打开 AStudio 客户端照样能领。`0.2.1` 按客户端的方式解析 id，把「待领列表为空」与「上游明确回 `11003002`」拆成两种结果，领取请求也补齐了按账户鉴权的四个 cookie。
+
+`0.2.2` 只做请求头对齐，**不解决「只有客户端开着才能领」那个现象**。改动有两处：新增 `clientVersion`（常量 `3.6.0`），`studioVersion` 从 `3.5.5` 提到 `3.6.0`——桌面端的 `fetchWithClientVersion` 会给所有讯飞域名请求加这个头，插件此前完全没有发过。发版前后的 A/B 实测表明这个头不是原因（见[已知限制](#已知限制)），所以这版的实际价值是把「插件发出的请求与客户端无法区分」这件事做实，以及把「每日奖励只在桌面端启动后才下发」这个限制如实写进文档。谁要是在版本说明里看到这版修好了领取，那话说错了。
+
 ## 请求被上游拒绝时
 
 maas-api 对不合规的请求只回一句 `10005 invalid request`，不说明是哪个字段。插件按下面的顺序自愈，全部发生在转发层，DSH 与 pi-ai 不需要改动：
@@ -312,7 +327,8 @@ maas-api 对不合规的请求只回一句 `10005 invalid request`，不说明
 - [ ] **扫码登录依赖上游三个私有接口**：`sso.xfyun.cn` 的 `scanlogin/qrcode` 与 `scanlogin/uids`，以及 `bot/models/configs` 里的 `api_key`。上游若加验证码、签名或设备指纹，扫码登录会直接失效（届时只显示「登录暂不可用」），但已保存的凭据仍然可用。
 - [ ] **扫码登录的凭据不会被主动刷新**：`ssoSessionId` 过期后需要重新扫码；插件不会拿它去换新（上游也没有公开的续期接口，客户端是重新登录）。
 - [ ] **一个 DSH 只保存一个扫码登录**：后期换账号需要先「退出登录」再扫，不做多账号并存。
-- [ ] **领取按钮依赖两个硬编码的客户端身份头**：`clientType`（平台）与 `studioVersion`（常量 `3.5.5`）。上游一旦要求构建号、签名或设备指纹，这条路会立即失效，届时按钮只会显示「暂不可用」。
+- [ ] **领取按钮依赖三个硬编码的客户端身份头**：`clientType`（平台）、`studioVersion` 与 `clientVersion`（后两者都是常量 `3.6.0`，跟随当前客户端版本）。上游一旦要求构建号、签名或设备指纹，这条路会立即失效，届时按钮只会显示「暂不可用」。
+- [ ] **每日奖励只在桌面端启动之后才可领**：客户端不启动，服务端就不挂当天的弹窗，插件轮到的永远是空列表，按钮只能如实报「当前没有可领取的奖励」。实测（`2026-11-05`，客户端未运行）请求头三种组合、外加重放客户端启动时的只读接口，都改变不了这一点；同日启动客户端后余额立即 +100。这不是插件能修的缺陷，而是上游的发放时机——想当天在 DSH 里领，就得先开一次 AStudio。
 - [ ] **CLI 的 `status` 会发起一次实时刷新**：它现在等待一次真实请求，才能如实报出目录来源与模型数；离线或未登录时报告 `empty` 与对应的失败原因。
 - [ ] **不做账号切换跟随**：与 WorkBuddy 双 variant 不同，AStudio 只有一个产品，插件不复制 variant 级能力。
 

package/lib/bin.js

@@ -1,5 +1,5 @@
 #!/usr/bin/env node
-import { i as createAStudioAuth, t as createAStudioCatalog } from "./catalog-CF9LFZ4P.js";
+import { i as createAStudioAuth, t as createAStudioCatalog } from "./catalog-CILzWwRh.js";
 import { existsSync, realpathSync } from "node:fs";
 import { fileURLToPath } from "node:url";
 //#region src/bin.ts

package/lib/{catalog-CF9LFZ4P.js → catalog-CILzWwRh.js}

@@ -518,6 +518,32 @@ function createAStudioAuth(options = {}) {
 	};
 	/** The chat token in use: our own sign-in wins over the app's. */
 	const resolvedToken = () => own()?.modelBearerToken ?? clientToken();
+	/**
+	* The cookie parts the account APIs authenticate with.
+	*
+	* The desktop client sends all four cookies (`ssoSessionId`, `sso_sessionid`,
+	* `account_id`, `token`) on every account call, and the reward endpoints are
+	* the ones that care about the extra two: `pending` is written against an
+	* identified account, not just a session. `token` is missing for a sign-in
+	* this plugin made itself — the QR exchange returns a model key, not an
+	* account token — so it is omitted rather than faked.
+	*/
+	const claimCredentials = () => {
+		const session = own();
+		if (session !== void 0) return {
+			ssoSessionId: session.ssoSessionId,
+			accountId: session.accountId
+		};
+		const ssoSessionId = readClientSsoSessionId(sessionPath());
+		if (ssoSessionId === void 0) return void 0;
+		const accountId = readSessionField(sessionPath(), "accountId");
+		const token = readSessionField(sessionPath(), "token");
+		return {
+			ssoSessionId,
+			...accountId === void 0 ? {} : { accountId },
+			...token === void 0 ? {} : { token }
+		};
+	};
 	/** The model key in use, with the same precedence. */
 	const resolvedModelToken = () => own()?.modelBearerToken ?? clientModelToken();
 	return {
@@ -538,6 +564,16 @@ function createAStudioAuth(options = {}) {
 			return own()?.ssoSessionId ?? readClientSsoSessionId(sessionPath());
 		},
 		/**
+		* The same credential, in the shape the claim's cookie needs.
+		*
+		* Separate from {@link ssoSessionId} because the reward endpoints want the
+		* account identified by cookie rather than by session alone, and only this
+		* module knows where the account id and token live.
+		*/
+		claimCredentials() {
+			return claimCredentials();
+		},
+		/**
 		* The `astron-session.json` this store reads the app's credentials from.
 		*
 		* Still reported for the status card, which names the file it looked at —

package/lib/client.js

@@ -1015,7 +1015,7 @@ window.__ModuleLoader__.load({
 		function isClaimDocument(value) {
 			if (typeof value !== "object" || value === null || Array.isArray(value)) return false;
 			const status = value["status"];
-			return status === "claimed" || status === "none" || status === "signed-out" || status === "expired" || status === "unavailable";
+			return status === "claimed" || status === "already" || status === "none" || status === "signed-out" || status === "expired" || status === "unavailable";
 		}
 		/** Narrow an unknown JSON value to the QR start route's document. */
 		function isQrStartDocument(value) {
@@ -1636,6 +1636,13 @@ window.__ModuleLoader__.load({
 						});
 						return;
 					}
+					if (result.status === "already") {
+						setNotice({
+							ok: false,
+							text: t("claimAlready")
+						});
+						return;
+					}
 					if (result.status === "none") {
 						setNotice({
 							ok: false,
@@ -1792,7 +1799,8 @@ window.__ModuleLoader__.load({
 			claiming: "Claiming…",
 			claimed: "+{points}",
 			claimedUnknown: "Claimed",
-			claimNone: "Already claimed today",
+			claimAlready: "Already claimed today",
+			claimNone: "Nothing to claim right now — it may already be booked by AStudio, or not issued yet",
 			pointsNav: "AStudio points",
 			pointsDailyHint: "One daily login reward per day — the same one the AStudio app books.",
 			pointsSignedOut: "AStudio is not signed in; the balances appear here once it is.",
@@ -1868,7 +1876,8 @@ window.__ModuleLoader__.load({
 			claiming: "领取中…",
 			claimed: "+{points}",
 			claimedUnknown: "已领取",
-			claimNone: "今日已领过",
+			claimAlready: "今日已领过",
+			claimNone: "当前没有可领取的奖励——可能已随 AStudio 入账，或今日尚未发放",
 			pointsNav: "AStudio 积分",
 			pointsDailyHint: "每日登录奖励每天一份，与 AStudio 客户端领的是同一份。",
 			pointsSignedOut: "AStudio 未登录，登录后这里会显示账户积分。",

package/lib/index.d.ts

@@ -246,7 +246,15 @@ type AStudioWebClaim = {
   points?: number;
   balance: AStudioWebPoints;
 } |
-/** Signed in, but the account service has no reward pending for today. */
+/**
+ * Upstream answered `11003002` for every popup found: today's reward was
+ * booked before this press. The one state that proves a claim already
+ * happened, as opposed to merely finding nothing.
+ */
+{
+  status: 'already';
+} |
+/** Signed in, but the account service is holding no reward for today. */
 {
   status: 'none';
 } | {
@@ -257,6 +265,119 @@ type AStudioWebClaim = {
   status: 'unavailable';
 };
 //#endregion
+//#region src/points.d.ts
+/** A read the points surface can present. */
+type AStudioPointsResult = AStudioWebPoints;
+/** Options for {@link createAStudioPointsClient}. */
+interface AStudioPointsClientOptions {
+  /**
+   * The account cookie to call with, or undefined when nobody is signed in.
+   *
+   * A provider rather than a file path: the cookie can come from the AStudio
+   * app's `astron-session.json` or from a sign-in this plugin made itself, and
+   * this module has no business knowing which.
+   */
+  sessionId: () => string | undefined;
+  /** Injected for tests. */
+  fetchImpl?: typeof fetch;
+  /** Injected clock, for TTL tests. */
+  now?: () => number;
+  /** Per-read timeout. */
+  timeoutMs?: number;
+}
+/** What the plugin and route consume. */
+interface AStudioPointsClient {
+  /**
+   * Read the balance.
+   *
+   * `fresh` bypasses the TTL cache — the section's ↻ uses it so a manual click
+   * always reaches upstream.
+   */
+  read(options?: {
+    fresh?: boolean;
+  }): Promise<AStudioPointsResult>;
+}
+/**
+ * Read the `ssoSessionId` from an AStudio session file.
+ *
+ * The app's way of finding the cookie. Kept exported because the auth store and
+ * the tests still read a file directly; the points client itself takes whichever
+ * provider it is handed.
+ *
+ * Returns undefined for a missing file, malformed JSON, an absent field, or a
+ * blank value — all of which mean "not signed in", a normal state the points
+ * section names rather than an error it reports.
+ */
+declare function readSsoSessionId(sessionPath: string): string | undefined;
+/**
+ * Parse the account service's balance envelope.
+ *
+ * The envelope is the legacy Astron shape — `{ flag, code, desc, data }` — and a
+ * dead session is answered with HTTP 200 plus `code: 80000`, which is why the
+ * status has to be read from the body as well as the HTTP status.
+ */
+declare function parseAStudioPointsBalance(payload: unknown): AStudioPointsResult;
+/**
+ * Create the balance client.
+ *
+ * The session file is re-read on every upstream call rather than cached: when
+ * AStudio is signed in again it rewrites that file with a new `ssoSessionId`, and
+ * a cached credential would keep the points section pinned to an expired session.
+ */
+declare function createAStudioPointsClient(options: AStudioPointsClientOptions): AStudioPointsClient;
+//#endregion
+//#region src/daily-reward.d.ts
+/** Options for {@link createAStudioDailyRewardClient}. */
+interface AStudioDailyRewardClientOptions {
+  /**
+   * The account this claim is made against, or undefined when nobody is signed in.
+   *
+   * A provider, so the credential can come from the AStudio app's session file
+   * or from a sign-in this plugin made itself — and so a re-login between two
+   * presses is picked up instead of pinning the first session.
+   */
+  credentials: () => AStudioDailyRewardCredentials | undefined;
+  /** Balance client used to report the post-claim balance. */
+  points: AStudioPointsClient;
+  /** Injected for tests. */
+  fetchImpl?: typeof fetch;
+  /** Overrides {@link astudioClientType}; `undefined` means "this platform has none". */
+  clientType?: string | undefined;
+  /** Overrides {@link ASTRO_STUDIO_VERSION}. */
+  studioVersion?: string;
+  /** Overrides {@link ASTRO_CLIENT_VERSION}. */
+  clientVersion?: string;
+  /** Per-call timeout. */
+  timeoutMs?: number;
+}
+/**
+ * The cookie parts the account APIs authenticate with.
+ *
+ * Mirrors what the desktop client sends: `ssoSessionId` and `sso_sessionid`
+ * are the same value under both names, and `account_id`/`token` are what make
+ * the request *account-scoped* rather than merely session-scoped. `token` is
+ * absent for a QR sign-in this plugin made itself — that exchange returns a
+ * model key, not an account token — and is then left out rather than guessed.
+ */
+interface AStudioDailyRewardCredentials {
+  ssoSessionId: string;
+  accountId?: string;
+  token?: string;
+}
+/** What the plugin and the claim route consume. */
+interface AStudioDailyRewardClient {
+  /** Book today's reward, if the account service is holding one. */
+  claim(): Promise<AStudioWebClaim>;
+}
+/**
+ * Create the claim client.
+ *
+ * The session file is re-read on every call for the same reason the balance
+ * reader does: AStudio rewrites it on re-login, and a cached credential would
+ * pin this to an expired session.
+ */
+declare function createAStudioDailyRewardClient(options: AStudioDailyRewardClientOptions): AStudioDailyRewardClient;
+//#endregion
 //#region src/auth.d.ts
 /** What the shim and upstream need from a credential. */
 interface AStudioCredentialStore {
@@ -321,6 +442,14 @@ declare function createAStudioAuth(options?: AStudioAuthOptions): {
    * precedence too.
    */
   ssoSessionId(): AStudioCredential;
+  /**
+   * The same credential, in the shape the claim's cookie needs.
+   *
+   * Separate from {@link ssoSessionId} because the reward endpoints want the
+   * account identified by cookie rather than by session alone, and only this
+   * module knows where the account id and token live.
+   */
+  claimCredentials(): AStudioDailyRewardCredentials | undefined;
   /**
    * The `astron-session.json` this store reads the app's credentials from.
    *
@@ -398,102 +527,6 @@ interface AStudioAdapter {
  */
 declare function createAStudioAdapter(options: AStudioAdapterOptions): AStudioAdapter;
 //#endregion
-//#region src/points.d.ts
-/** A read the points surface can present. */
-type AStudioPointsResult = AStudioWebPoints;
-/** Options for {@link createAStudioPointsClient}. */
-interface AStudioPointsClientOptions {
-  /**
-   * The account cookie to call with, or undefined when nobody is signed in.
-   *
-   * A provider rather than a file path: the cookie can come from the AStudio
-   * app's `astron-session.json` or from a sign-in this plugin made itself, and
-   * this module has no business knowing which.
-   */
-  sessionId: () => string | undefined;
-  /** Injected for tests. */
-  fetchImpl?: typeof fetch;
-  /** Injected clock, for TTL tests. */
-  now?: () => number;
-  /** Per-read timeout. */
-  timeoutMs?: number;
-}
-/** What the plugin and route consume. */
-interface AStudioPointsClient {
-  /**
-   * Read the balance.
-   *
-   * `fresh` bypasses the TTL cache — the section's ↻ uses it so a manual click
-   * always reaches upstream.
-   */
-  read(options?: {
-    fresh?: boolean;
-  }): Promise<AStudioPointsResult>;
-}
-/**
- * Read the `ssoSessionId` from an AStudio session file.
- *
- * The app's way of finding the cookie. Kept exported because the auth store and
- * the tests still read a file directly; the points client itself takes whichever
- * provider it is handed.
- *
- * Returns undefined for a missing file, malformed JSON, an absent field, or a
- * blank value — all of which mean "not signed in", a normal state the points
- * section names rather than an error it reports.
- */
-declare function readSsoSessionId(sessionPath: string): string | undefined;
-/**
- * Parse the account service's balance envelope.
- *
- * The envelope is the legacy Astron shape — `{ flag, code, desc, data }` — and a
- * dead session is answered with HTTP 200 plus `code: 80000`, which is why the
- * status has to be read from the body as well as the HTTP status.
- */
-declare function parseAStudioPointsBalance(payload: unknown): AStudioPointsResult;
-/**
- * Create the balance client.
- *
- * The session file is re-read on every upstream call rather than cached: when
- * AStudio is signed in again it rewrites that file with a new `ssoSessionId`, and
- * a cached credential would keep the points section pinned to an expired session.
- */
-declare function createAStudioPointsClient(options: AStudioPointsClientOptions): AStudioPointsClient;
-//#endregion
-//#region src/daily-reward.d.ts
-/** Options for {@link createAStudioDailyRewardClient}. */
-interface AStudioDailyRewardClientOptions {
-  /**
-   * The account cookie, or undefined when nobody is signed in.
-   *
-   * A provider, so the cookie can come from the AStudio app's session file or
-   * from a sign-in this plugin made itself.
-   */
-  sessionId: () => string | undefined;
-  /** Balance client used to report the post-claim balance. */
-  points: AStudioPointsClient;
-  /** Injected for tests. */
-  fetchImpl?: typeof fetch;
-  /** Overrides {@link astudioClientType}; `undefined` means "this platform has none". */
-  clientType?: string | undefined;
-  /** Overrides {@link ASTRO_STUDIO_VERSION}. */
-  studioVersion?: string;
-  /** Per-call timeout. */
-  timeoutMs?: number;
-}
-/** What the plugin and the claim route consume. */
-interface AStudioDailyRewardClient {
-  /** Book today's reward, if the account service is holding one. */
-  claim(): Promise<AStudioWebClaim>;
-}
-/**
- * Create the claim client.
- *
- * The session file is re-read on every call for the same reason the balance
- * reader does: AStudio rewrites it on re-login, and a cached credential would
- * pin this to an expired session.
- */
-declare function createAStudioDailyRewardClient(options: AStudioDailyRewardClientOptions): AStudioDailyRewardClient;
-//#endregion
 //#region src/login-session.d.ts
 /** On-disk format; readers reject anything else. */
 declare const LOGIN_SESSION_FORMAT_VERSION = 1;

package/lib/index.js

@@ -1,4 +1,4 @@
-import { a as readTokenFromConfig, c as describeLoginSession, d as writeLoginSession, i as createAStudioAuth, l as parseLoginSession, o as astudioLoginSessionPath, r as localIdentity, s as clearLoginSession, t as createAStudioCatalog, u as readLoginSession } from "./catalog-CF9LFZ4P.js";
+import { a as readTokenFromConfig, c as describeLoginSession, d as writeLoginSession, i as createAStudioAuth, l as parseLoginSession, o as astudioLoginSessionPath, r as localIdentity, s as clearLoginSession, t as createAStudioCatalog, u as readLoginSession } from "./catalog-CILzWwRh.js";
 import z from "@deepseek-ai/schemastery";
 import { existsSync, readFileSync } from "node:fs";
 import { dirname, join } from "node:path";
@@ -2387,6 +2387,19 @@ function astudioClientType(platform = process.platform) {
 	if (platform === "darwin") return "22";
 }
 /**
+* Read a popup id the way the desktop client does.
+*
+* The id is a positive integer on the wire, and `client-popups/complete` is
+* parsed with `Number.isSafeInteger` upstream. Accepting only strings here is
+* what once made every real reward look like "nothing pending": the popup was
+* delivered, failed this test, and the section announced a reward that had
+* never been booked.
+*/
+function popupIdOf(value) {
+	const id = typeof value === "number" ? value : typeof value === "string" ? Number(value) : NaN;
+	return Number.isSafeInteger(id) && id > 0 ? id : void 0;
+}
+/**
 * Reduce the gateway's `{ flag, code, desc, data }` envelope.
 *
 * A dead session is answered with HTTP 200 plus `code: 80000`, so the status has
@@ -2427,9 +2440,9 @@ function pendingRewards(data) {
 		if (typeof raw !== "object" || raw === null) continue;
 		const item = raw;
 		if (item["componentType"] !== "DAILY_REWARD_DIALOG") continue;
-		const popupId = item["popupId"];
+		const popupId = popupIdOf(item["popupId"]);
 		const instanceKey = item["instanceKey"];
-		if (typeof popupId !== "string" || popupId === "") continue;
+		if (popupId === void 0) continue;
 		if (typeof instanceKey !== "string" || instanceKey === "") continue;
 		rewards.push({
 			popupId,
@@ -2440,6 +2453,20 @@ function pendingRewards(data) {
 	return rewards;
 }
 /**
+* Build the cookie header the account APIs expect.
+*
+* Same four pairs the desktop client sends, in the same order. The claim is not
+* an anonymous "is there a reward?" question — the popup service answers an
+* unidentified caller with an empty list, which is indistinguishable from "no
+* reward today" unless the account travels with the request.
+*/
+function claimCookie(credentials) {
+	const parts = [`ssoSessionId=${credentials.ssoSessionId}`, `sso_sessionid=${credentials.ssoSessionId}`];
+	if (credentials.accountId !== void 0) parts.push(`account_id=${credentials.accountId}`);
+	if (credentials.token !== void 0) parts.push(`token=${credentials.token}`);
+	return parts.join("; ");
+}
+/**
 * Create the claim client.
 *
 * The session file is re-read on every call for the same reason the balance
@@ -2449,18 +2476,20 @@ function pendingRewards(data) {
 function createAStudioDailyRewardClient(options) {
 	const fetchImpl = options.fetchImpl ?? fetch;
 	const clientType = "clientType" in options ? options.clientType : astudioClientType();
-	const studioVersion = options.studioVersion ?? "3.5.5";
+	const studioVersion = options.studioVersion ?? "3.6.0";
+	const clientVersion = options.clientVersion ?? "3.6.0";
 	const timeoutMs = options.timeoutMs ?? DEFAULT_TIMEOUT_MS$1;
-	const call = async (sessionId, path, init = {}) => {
+	const call = async (credentials, path, init = {}) => {
 		let response;
 		try {
 			response = await fetchImpl(new URL(path, ASTRO_STUDIO_API_BASE), {
 				...init,
 				headers: {
 					Accept: "application/json",
-					Cookie: `ssoSessionId=${sessionId}`,
+					Cookie: claimCookie(credentials),
 					...clientType === void 0 ? {} : { clientType },
 					studioVersion,
+					clientVersion,
 					...init.headers ?? {}
 				},
 				signal: AbortSignal.timeout(timeoutMs)
@@ -2479,18 +2508,19 @@ function createAStudioDailyRewardClient(options) {
 		return readEnvelope(payload);
 	};
 	return { async claim() {
-		const sessionId = options.sessionId();
-		if (sessionId === void 0) return { status: "signed-out" };
+		const credentials = options.credentials();
+		if (credentials === void 0) return { status: "signed-out" };
 		if (clientType === void 0) return { status: "unavailable" };
-		const pending = await call(sessionId, ASTRO_DAILY_REWARD_PENDING_PATH);
+		const pending = await call(credentials, ASTRO_DAILY_REWARD_PENDING_PATH);
 		if (pending.kind === "expired") return { status: "expired" };
 		if (pending.kind !== "ok") return { status: "unavailable" };
 		const rewards = pendingRewards(pending.data);
 		if (rewards.length === 0) return { status: "none" };
 		let booked = 0;
+		let alreadyBooked = 0;
 		let bookedAmount;
 		for (const reward of rewards) {
-			const answer = await call(sessionId, ASTRO_DAILY_REWARD_COMPLETE_PATH, {
+			const answer = await call(credentials, ASTRO_DAILY_REWARD_COMPLETE_PATH, {
 				method: "POST",
 				headers: { "Content-Type": "application/json" },
 				body: JSON.stringify({
@@ -2499,7 +2529,11 @@ function createAStudioDailyRewardClient(options) {
 				})
 			});
 			if (answer.kind === "expired") return { status: "expired" };
-			if (answer.kind === "ok" || answer.kind === "already") {
+			if (answer.kind === "already") {
+				alreadyBooked += 1;
+				continue;
+			}
+			if (answer.kind === "ok") {
 				booked += 1;
 				if (reward.points !== void 0) bookedAmount = (bookedAmount ?? 0) + reward.points;
 				continue;
@@ -2507,6 +2541,7 @@ function createAStudioDailyRewardClient(options) {
 			if (booked === 0) return { status: "unavailable" };
 			break;
 		}
+		if (booked === 0) return { status: alreadyBooked > 0 ? "already" : "none" };
 		const balance = await options.points.read({ fresh: true });
 		return bookedAmount === void 0 ? {
 			status: "claimed",
@@ -3267,7 +3302,7 @@ function registerAStudioWebRoutes(ctx, deps) {
 	const pointsClient = createAStudioPointsClient({ sessionId: () => store.ssoSessionId() });
 	registerAStudioPointsRoute(ctx, { client: pointsClient });
 	registerAStudioClaimRoute(ctx, { client: createAStudioDailyRewardClient({
-		sessionId: () => store.ssoSessionId(),
+		credentials: () => store.claimCredentials(),
 		points: pointsClient
 	}) }, controlKey);
 	const afterSignInChange = () => {

package/package.json

@@ -2,7 +2,7 @@
   "name": "dsh-astudio-connect",
   "displayName": "DSH AStudio Connect",
   "description": "将 AStudio 应用中已登录的模型复用到 DeepSeek Harness — bring AStudio app models into DeepSeek Harness with zero configuration.",
-  "version": "0.2.0",
+  "version": "0.2.2",
   "author": "astudio-connect",
   "keywords": [
     "dsh-plugin",