@eddyskywalker/dsh-chatgpt-subscription 0.8.1 → 0.8.3

package/CHANGELOG.md

@@ -2,6 +2,51 @@
 
 ## Unreleased
 
+- **发版修正：`latest` 不再停在 0.7.0**。用户反馈「更新了一下，从 0.8 又变成 0.7 了」——npm 上 `latest` 一直是 **0.7.0**，而 `0.8.0-alpha.0` 到 `0.8.2` 全部落在 `alpha` 标签下，`npm install` 与 `dsh plugin add` 不带标签时解析的正是 `latest`，所以从 0.8 升级会退回 0.7。根因是 `package.json` 里的 `publishConfig.tag: "alpha"`：它让**每一次**发布都进 `alpha`，`latest` 因此自 0.7.0 之后再没动过。
+  - **修法一：把已发布的 0.8.2 提升为 `latest`**（`npm dist-tag add @eddyskywalker/dsh-chatgpt-subscription@0.8.2 latest`）——不重新发版。提升前逐文件核对了 npm 上的 0.8.2 与本地源码的干净构建（`rm -rf lib && npm run build` 后 `npm pack`）：`lib/index.js`、`lib/client.js`、`lib/client.js.map` **逐字节相同**，其余声明文件一致，因此提升 0.8.2 等于发布当前源码。0.8.2 里比干净构建多出 `lib/types/host/compaction-patch.d.ts{,.map}` 两个**孤立**声明文件（仓库里没有对应源码、也没有任何代码引用，是发布当时 `lib/` 的增量残留），运行时不受影响；这类残留正是下面那条「发版前清空 `lib/`」的原因。
+  - **修法二：删掉 `publishConfig.tag`（保留 `access: public`）**，让稳定版按 npm 默认进 `latest`。这不是把预发布也推向 `latest`：npm 11 起对预发布版本**强制要求显式 `--tag`**（`You must specify a tag using --tag when publishing a prerelease version.`，见 npm 的 `lib/commands/publish.js`），所以下一次 alpha 必须写明 `npm publish --tag alpha`，不会静默盖掉 `latest`。
+  - **顺带清掉遗留的 `next` 标签**：它从首次发布起就指向 `0.1.0-alpha.0`，与任何在用版本都不对应。
+  - **验证**：`npm view @eddyskywalker/dsh-chatgpt-subscription dist-tags` 现在为 `latest: 0.8.2`（`alpha` 仍是 0.8.2）；在空目录里执行一次真实的 `npm install @eddyskywalker/dsh-chatgpt-subscription`，装到的是 0.8.2 且 `lib/index.js` 就位。
+
+- **支持 DSH 0.1.7-rc.1**（本机 harness 仓库与 `dsh --version` 都已是它，npm 上 `next` 也是它）。这一版**不需要任何行为改动**——alpha.1 桥接过的会话消息模型与设置 API 在 rc.1 一字未改，`dsh-llm`、`dsh-settings`、`dsh-web`、`dsh-attachment`、`dsh-timeout`、`dsh-host-webserver` 与四个 client 包在该窗口内**只有版本号变化**（窗口本身 318 个提交 / 911 个文件，绝大多数与本插件无关）。动作落在基线、一处契约漂移和依赖清单上。
+  - **dev 基线升到 `0.1.7-rc.1`，peer 范围加入 `^0.1.7-rc.1`**。需要说清的是：这个 peer 子句是**为可读性**，不是解封——`^0.1.7-alpha.1` 本来就覆盖 `0.1.7-rc.1`（同一个 `0.1.7` 元组，预发布比较器在元组内匹配），已用 `semver.satisfies` 对全部 dsh peer 逐条验证。rc.1 新增的**启动期 peer 兼容性预检**（`packages/boot/app-boot/src/plugin-compatibility.ts`：不满足即把该行 `disabled` 并写 stderr，读不到 peer 元数据也一律拒绝）对本插件因此是**空集**。
+  - **`tool.call.toolview` 的入参从单一 `block` 变成三态联合**（`packages/client/ui-tool/.../contract/slots.ts` 的 `ToolCallPhaseProps`：`preparing` / `start` / `result`），`RunningToolCall` 相应拆成 `PreparingToolCall`（**根本没有 `argsRaw`**）与 `StartedToolCall`。`ToolCallTree` 对**每个阶段**都调用已注册的 keyed 视图，所以图片卡确实会拿到 `preparing` 的 block；`CodexImageToolView` 原先直接读 `block.argsRaw`，在 `preparing` 上读的是不存在的属性。**这不是用户可见的故障**（读到 `undefined` 后照常渲染「正在生成图片」，只是少了提示词摘要），属接缝处的契约漂移；现改为只在声明了该字段的分支读取（`dispatchedArgsRaw`，用 `'argsRaw' in block` 判定），旧代走的正是原来那条分支，**由构造保证而非版本判断**。
+  - **顺带记录一个类型盲点**：`slots.d.ts` 从 `@deepseek-ai/dsh-client-ui-chat/client` 引入这些块类型，而该包**既没有安装、也不是 `dsh-client-ui-tool` 声明的依赖**（那个包连 `dependencies` 字段都没有）；两个 tsconfig 都开着 `skipLibCheck`，于是这些类型退化成 `any`，`tsc` 对 `block` 的形状既查不出错、也证明不了对。上面关于 `tool.call.toolview` 的结论**全部来自读 harness 源码，不是来自类型**。把 `dsh-client-ui-chat` 加成 devDependency 能让这一面真正被检查，但那是一个需要随世代维护的新依赖，留作维护者决定。
+  - **vendor 只涨版本、不动源码**：cordis 4.0.3 → 4.0.4、schemastery 3.18.3 → 3.18.4，`vendor/cordis/src` 与 `vendor/schemastery/src` 在该窗口的 diff 为**空**，清单里只是把内部范围从 `workspace:^` 收紧成 `workspace:~`。alpha.1 记录过的 `Fiber.update()` 陷阱（4.0.2→4.0.3）没有新变化，`search-provider-switcher.ts` 里 `entry.fiber?.await()` 的等待依然正确。`dsh-tools` 新增可选的 `projectContent` 钩子，纯加法，未采用。`package-lock.json` 里跟着动的 cordis 4.0.4 / loader 1.0.5 / group 1.0.4 / include 1.0.9 / cosmokit 1.8.5 / schemastery 3.18.4 是 rc.1 各包收紧 peer 后的必然结果，源码行为不受影响。
+  - **pnpm 清单同步**：`pnpm-workspace.yaml` 的 `minimumReleaseAgeExclude` 由 `0.1.7-alpha.1` 换成 `0.1.7-rc.1`（vendor 行把旧版本作为备选保留），并补上 rc.1 所需的 cordis 4.0.4 / loader 1.0.5 / cosmokit 1.8.5 / schemastery 3.18.4 / group 1.0.4 / include 1.0.9；`pnpm-lock.yaml` 用 pnpm 11.24.0 重新生成，`lockfileVersion` 仍是 `'9.0'`，供应链策略校验通过、`--frozen-lockfile` 退出码 0。CI 走的是 `npm ci`，这两个文件只影响用 pnpm 安装的人。
+  - **验证**：`npm run typecheck`（先删掉两个 `.tsbuildinfo` 并以 `tsc -b --force` 强制全量，避免增量空跑被误判为通过）与 `npm run build` 均 **0 错误**；`npx vitest run` **96 个文件通过 / 1 跳过（97），1256 条通过 / 7 跳过、0 失败**。对照 alpha.1 基线（1250 条通过、95 个文件通过 / 1 跳过）**除新增用例外逐项一致**，确认 rc.1 未引入回归。`npm ci --dry-run` 同步，`npm pack --dry-run` 完好（282 个文件）。旧代回测在独立干净目录按 `^0.1.5-rc.1` 装出完整闭包（实得 0.1.5-rc.3）：`tsc -b` **0 错误**，`npx vitest run` **1253 条通过 / 0 条失败**；唯一无法加载的仍是 `test/subagent-model-authorization-ptc.test.ts`（它的 3 条在 rc.1 上通过，0.1.5 闭包里没有 `@deepseek-ai/dsh-ptc-runtime`）。新增 `test/codex-image-tool-view.test.tsx` 6 条，按字面写出各阶段的线形状（preparing / start / rc.1 之前的 running / 结果 / 出错 / 非 JSON 参数），**两代都通过**。该文件锁定的是**行为而不是「修复」**——原实现在 preparing 上产出完全相同的结果，因此它区分不出改动前后，这一点如实记下。
+
+- **新增第五条线路：GLM（智谱 / Z.ai Coding Plan）**，Provider id 为 `zhipu-coding-plan`，与另外四条线路功能对齐（多账号号池、模型勾选、逐模型能力表、上下文窗口覆盖、默认思考深度、额度卡片与输入框右侧胶囊）。该 id 特意与用户常用的自定义 `zai` / `zhipu` OpenAI 兼容条目分开，安装本插件不会覆盖或隐藏原有自定义 API。
+  - **两个部署、两套控制台，区域是凭据属性**：国际区 `https://api.z.ai`、国区 `https://open.bigmodel.cn`，两边的 Key **互不通用**。添加 Key 时显式选择区域，账号卡片逐条标注，模型请求走该账号自己的 host；凭据里的 base URL 由区域推导而不是采信落盘值，手改文件也无法把 Key 指向别的主机。
+  - **订阅接口不是开放平台接口**：Coding Plan 的模型面是 `{base}/api/coding/paas/v4`（不是通用付费的 `/api/paas/v4`），添加 Key 时先用它读一次该部署自己的模型目录做验证，未通过就不落盘——这是这个产品最常见的一次配错，错误文案直接告出「Key 大概该来自哪个控制台」。整次登录只花一次上游读（验证用的目录被缓存）。
+  - **额度取自订阅自己的监控接口**，且鉴权方式与模型接口**不同**：`/api/monitor/usage/quota/limit`（5 小时 + 每周 + 月度 MCP 工具调用）与 `/api/biz/subscription/list`（套餐名）用**不带 `Bearer` 前缀的裸 Key**——实测带前缀判 401、裸 Key 通过——而模型接口用文档记载的 `Bearer`。两条 header 各自成函数，并各有测试锁定。窗口按上游的 `unit`/`number` 换算成分钟后再命名（`unit 3 × number 5` → 5 小时，`unit 6 × number 1` → 每周），同时兼容 `TOKENS_LIMIT` 与新版 `CREDIT_LIMIT` 两种拼写，避免卡片对活账号报「无额度」。
+  - **模型能力逐模型查表**（`src/host/zhipu/model-catalog.ts`，转录自订阅侧模型注册表与官方文档）：图片支持、思考档位、能否关闭思考都是逐模型事实，**不能按族名推断**——`glm-5.3-flash` 接受图片而 `glm-5.3` 不接受；`glm-5.3` 有三档而 `glm-5.2` 只有两档；`glm-4.7` / `glm-4.5-air` 这类 toggle 模型根本不收 `reasoning_effort`。运行时以订阅侧 `GET /models` 为准，但它只覆盖上下文窗口，能力字段不被这份列表改写（列表声明窗口，不声明能力）。
+  - **思考档位先收敛再发出**：上游对 GLM-5.x 只接受 `low` / `high` / `max`，其余取值**直接报错**而非被忽略；DSH 的档位词表更宽，因此每个取值都收敛到该模型自己的档位表后才发出。收敛的**排序覆盖两套词表**——这一点是实测出来的缺陷：只按上游三档排序时，`minimal`（比 `low` 更省）会被当成未知值弹到中间档，用户选最省的一档反而换来 `high`，既违背意图又更费额度；修好后 `minimal`→`low`、`medium`→`high`、`xhigh`→`max`。关闭思考的值一律不发：GLM-5.3 / GLM-5.3-FLASH / GLM-4.7 把 `thinking.type: "disabled"` 判为错误，省略即它们的 `enabled` 默认。另外不发 `stream_options`（文档未记载该字段，且上游的流式文档显示 usage 无需它也会到达），避免为无收益的字段冒 400 的风险。
+  - **瞬时失败按 `code` 分类重试**（`src/host/zhipu/adapter.ts`）：上游 5xx / `code 1230` / `code 1234` / 服务过载归为可重试，走与兄弟线路一致的有界退避（最多 3 次、1.5s 起步、15s 上限、0.2 抖动）并遵守上游 `Retry-After`。**401/403 与 `code 1000` / `1003` / `1001`（Key 失效）、`1311`（套餐不含该模型）、`1309`（套餐已过期）明确不重试**——它们与「额度窗口用尽」（`1308` / `1310`）共用 429 状态码，但处理方式完全相反，因此分类读响应正文的 `code` 而不只看状态码。
+  - **号池复用共享内核**：走 `AccountPoolCore` 与同一张设置卡片，因此具备顺序耗尽 / 轮询调度 / 粘性会话、429 冷却换号、账号级失效（保留账号、重新添加即恢复）、设为主账号、备注与清除冷却。账号 id 是 **Key 摘要 + 区域**，别名只显示「区域 + Key 后四位」；明文 Key 既不进 id、别名，也不进任何响应（测试断言 `/accounts/add` 与 `/status` 的响应体不含 Key 本身）。号池文档逐条容错解析：**单条损坏的账号被丢弃而不是让整份文档读失败**——池读取抛错会把「已登录」报成「未登录」，一条坏行就会让整条线路下线。
+  - **验证**：`npm run typecheck` 与 `tsc -p test/tsconfig.json` 均 0 错误；`npm test` **93 个文件通过 / 1 跳过，1213 条通过 / 7 跳过、0 失败**（连续多轮复跑稳定）。新增 3 个测试文件共 **67 条**：`test/zhipu-adapter.test.ts`（38 条）锁定逐模型能力与未知模型回落、上游列表窗口合并而能力不被改写、两种鉴权 header、额度窗口与 `CREDIT_LIMIT` 兼容、两套词表的档位收敛、请求构造（始终流式、不发 `stream_options`、不发关闭思考、未声明的档位不发）、`reasoning_content` 流式映射与截断流拒绝、以及读 `code` 的重试/不重试分类（含 `providerRetryAfterMs`）；`test/zhipu-routes.test.ts`（18 条）锁定添加 Key 先验证后落盘且失败不写入、跨源拒绝、额度窗口与失败原因随状态返回、设置读写与 `null` 恢复默认、连接探测走对话面而非列表、启用集合三态，以及号池的去重 / 同 Key 跨区不冲突 / 冷却 / 失效保留 / 池前单凭据投影；`test/zhipu-ui.test.tsx`（11 条）锁定卡片渲染账号区域与套餐、逐窗口进度与重置倒计时、无额度空态、区域选择器、逐模型能力 tooltip、胶囊取**最紧窗口**并按剩余量分级、容量解析与格式化、以及两份词表键集合一致。`test/client-registration.test.ts` 同步扩展为六个标签页与第六条 `conversation.input.right` 注册。
+
+- **修掉测试套件长期存在的不稳定（并发下的假失败与跨用例串扰）**。此前 `npm test` 在默认并发下几乎每轮都失败 4–6 条，早先被当作「既有偶发」放过；实测后确认是真实缺陷，且**失败会污染下一个用例**。
+  - **根因**：套件里有多条用例真的去 spawn `powershell.exe` 跑 Windows DPAPI 凭据存储（`token-store-windows` 一个文件就有 6 次），而 `testTimeout` 定在 15s——隔离测量最慢的一条要 **12.3–14.3s**（自身波动就有 2s），余量不到 3s。默认 worker 数按核心数取 15，子进程相互争抢（这里瓶颈是子进程吞吐而非 CPU），于是稳定超时。
+  - **超时的伤害不止那一条用例**：超时后仍在飞的请求不会被取消，它们会落进**下一个用例**的 fetch mock，把那个用例也判失败。实测抓到的调用序列是「配额那一组各出现两次 + 前一个用例遗留的 4 次 `streamGenerateContent`」，在断言上就表现为 `expected to be called 4 times, but got 8 times`。这正是「检查一下是不是问题」值得做的原因——它看起来像随机抖动，实际是一条会扩散的失败。
+  - **修法**：`vitest.config.ts` 的 `testTimeout` 由 15s 提到 **60s**（约为实测最慢值的 4 倍：健康运行绝不会触发，仍能抓住真正卡死的用例），并把 `maxWorkers` 限到 **4** 作为第二道保险。**成本为零**：这些用例受子进程延迟而非 CPU 约束，4 个 worker 实测 ~51s，15 个 worker ~54s。
+  - **验证**：`npm test` **连续 5 轮、每轮 1213 条全通过**；为确认主因，另在**默认 15 worker** 下只改超时复跑 **11 轮**，同样全通过——说明超时余量是主因，worker 上限是针对「外部负载（CI、同机并行任务）重新引入超时、而超时又会串扰邻居」这一放大路径的兜底。修复前：15 worker 下 4–5 条失败、4 worker 下 1/3 概率失败；修复后 0 条。
+- **WorkBuddy 每日自动签到**（参考 workbuddy2api 的 `daily_checkin.py` 移植并适配到插件进程内）：
+  - 新增 `src/host/workbuddy/checkin.ts`：国区账号（含桌面收编与已隐藏账号）在 Host 启动时签到一轮，之后每 10 分钟幂等补检（当日已签零请求）；先查 `checkin-activity-status` 幂等预查再调 `daily-checkin`，活动无权益当天不再重试，失败当天最多自动重试 3 次；token 续期复用凭据存储现有的过期续期+回写机制（桌面账号原子写回 IDE 的 *.info）。国际区账号不参与。（初版曾做「散列分时窗口」，试用后按用户反馈简化为启动即签，窗口配置已移除。）
+  - 状态持久化到 `storages/workbuddy-checkin.json`（tmp+rename 原子写），同日重启免费；签到是进程内调度，**DSH 未运行的当天不签到**。
+  - 偏好：`dsh-workbuddy` 命名空间与文件存储双轨新增 `checkin: { enabled }`。
+  - 路由：`/workbuddy/api/status` 附带签到汇总（今日 x/y、失败数、上次运行时间，聚合无账号标识）；新增 `POST /workbuddy/api/checkin/now` 手动补签（同源校验，忽略窗口与重试上限但仍跳过当日已签账号）；`/settings` 接受 `checkin` 补丁。
+  - 设置页新增「每日签到」区块：开关、「今日已签 x/y」总状态与「立即签到」按钮；中英文案。
+  - **合并后修复（评审发现）**：
+    - **关掉开关后重启仍会签到一次**。偏好 store 在无 register seam 的 harness（0.1.7 的 `SettingsForms`，即当前实际安装的形态）上异步预热，`status()` 在落盘文档读回之前一直返回出厂默认值；而 Host 构造完调度器立刻 tick，于是「已关闭」的账号每次重启都被签一次。`WorkBuddyPreferenceStore` 新增 `ready()`，调度器在每轮开头 await 它（memoize，只等一次）。
+    - **活动未开启的账号当天被永久放弃**。原先 `active === false` 记 `done = true`，而 Host 通常在活动开放前启动，这一条就吃掉了当天唯一的机会——补检也救不回来。现在 `inactive` 与 `done` 分开记录，未开启的账号每小时复查一次（`CHECKIN_INACTIVE_RECHECK_MS`），手动补签不受该节流限制。
+    - **「今日已签 x/y」把「无签到活动」算成已签**。汇总新增 `skippedToday`，卡片单独显示「无活动 z」，不再把没签到说成签到。
+    - **自动 tick 进行中点击「立即签到」被静默吞掉**。原 `tick()` 直接 join 在飞的 promise，手动「忽略开关与重试上限」的语义随之丢失；改为串行队列，手动请求在飞行中的那轮结束后补跑一轮。自动 tick 仍合并（重复的自动轮没有意义）。
+    - **`lastRunAt` 未落盘**，重启后卡片立刻显示「尚未运行」；现在随状态文件持久化（`version: 2`，v1 文档仍可读）。
+    - **上游字段容错**：签到状态按蛇形/驼峰双拼写读取，并把 `0/1`、`"true"` 一并归一（对齐参考实现的 `normalize_checkin_status`）；`daily-checkin` 返回「已签到」类软失败改判为成功，不再无谓消耗当天重试次数；401 触发一次强制续期重试（`ensureFresh` 只看本地过期时间，服务端提前吊销的 token 原本每次都要烧掉一次尝试）。
+  - **验证（合并后复跑）**：`npm run typecheck`、`tsc -p test/tsconfig.json`、`npm run build` 均 0 错误；`npm test` **95 文件通过 / 1 跳过，1250 通过 / 7 跳过、0 失败**（连续复跑一致）。新增 `test/workbuddy-checkin-review-fixes.test.ts`（19 条）逐条锁定上述修复——**该文件在未修复的源码上跑是 18 条里失败 11 条**，确认它真的覆盖这些路径，而不是只描述期望；`test/workbuddy-section-pool.test.tsx` 新增 4 条覆盖设置页区块（汇总含「无活动」、旧 Host 不渲染该区块、开关补丁落盘、手动签走对路由）。
+  - **验证**：`npm run typecheck`、`npm run build` 通过；`npm test` 全绿。新增 `test/workbuddy-checkin.test.ts`：首次 tick 即签、之后零请求、开关关闭不动/手动补签强制、国际区跳过、已签不重复请求、无权益当天不重试、失败 3 次封顶且手动可重试、过期 token 先续期再签到并回写桌面文件、多账号全签、同日状态文件去重、状态路由汇总/旧 Host 返回 null、手动路由同源与方法门禁、设置补丁持久化与旧版窗口字段兼容。
+
 - **模型上下文窗口跟随模型开关，并支持恢复默认**（用户报告：「本项目提供的供应商模型是可以开关显示的，但是配置同页面的配置上下文不行，能不能开启什么模型再调整什么模型的上下文，增加支持恢复默认的选项」）。
   - **上下文窗口只列已勾选启用的模型**：五个标签页统一——ChatGPT 页按 `visibleModelIds`，Antigravity / Command Code / Kimi Code / WorkBuddy 按 `model.enabled`；一个都没勾选时显示空态提示。四页新增 `contextDraftsFor(status)` 并让所有播种路径（`/status`、目录刷新、以及**模型开关请求返回后**）都走它，否则刚勾选的模型会渲染成空输入框（此前上下文区与开关无关，草稿总是先于行存在）。
   - **ChatGPT 页放开到全部模型**：原先只有 `CONFIGURABLE_CONTEXT_MODEL_IDS` 里写死的 6 个模型（恰好等于默认可见的 6 个）能配上下文，勾上 5.5 / 5.4 / 5.4 Mini / 5.3 Codex Spark 后没有对应输入框。现在 `CONFIGURABLE_CONTEXT_MODEL_IDS`、`ConfigurableContextModelId`、`isConfigurableContextModelId` 全部删除，改用既有的 `isCodexModelId`：偏好 schema 按 `CODEX_MODEL_CATALOG` 生成、路由接受任意目录模型、`src/host/model-catalog.ts` 去掉「只有那几个模型才读覆盖值」的守卫。可调上限沿用家族规则（GPT-6 系 872K，其余 1M），与 5.6 系列此前的规则一致。

package/README.md

@@ -14,6 +14,7 @@
 - [Kimi Code 线路](#kimi-code-线路)
 - [Command Code 线路](#command-code-线路)
 - [WorkBuddy 线路](#workbuddy-线路)
+- [GLM（智谱 Coding Plan）线路](#glm智谱-coding-plan线路)
 - [子代理模型授权](#子代理模型授权0215-起)
 - [随包分发的 Agent Preset](#随包分发的-agent-preset)
 - [升级、降级与卸载](#升级降级与卸载)
@@ -83,6 +84,18 @@
 - **流中断即失败**：上游必然以 `finish_reason` 或 `data: [DONE]` 结束，两者都缺失说明连接中途断开，此时抛出错误而不是把半截文本当成完整回答；
 - 额度来自 `/billing/meter/get-user-resource`，卡片展示套餐名、本周期已用/上限、剩余额度与重置时间；设置页为「设置 → 订阅服务 → WorkBuddy」标签页，对话输入框右侧有该线路的额度胶囊。
 
+**GLM（智谱 Coding Plan）线路**
+
+- 注册 `zhipu-coding-plan` Provider，接入**智谱 / Z.ai 的 GLM Coding Plan 订阅**。该 ID 特意与用户常用的自定义 OpenAI 兼容线路 `zai` / `zhipu` 分开，安装插件不会覆盖或隐藏原有自定义 API；
+- **订阅接口与开放平台是两套东西**：Coding Plan 的模型接口是 OpenAI 兼容的 `{base}/api/coding/paas/v4`，**不是** 通用付费的 `/api/paas/v4`——把开放平台的 Key 或后者当 base URL 用会被判为鉴权失败。国区（`open.bigmodel.cn`）与国际区（`api.z.ai`）的 Key **互不通用**，因此区域是**凭据属性**：添加时显式选择，卡片逐条标注，模型请求走该账号自己的 host；
+- **添加 Key 前先验证**：`POST /zhipu/api/accounts/add` 先用该 Key 读一次部署自己的模型目录，未通过就不落盘，并直接告出「Key 大概来自哪个控制台」——这是这个产品最常见的一次配错。整个登录只花一次上游读（验证用的目录会被缓存）；
+- **多账号号池，与另外四条线路同源**：走共享内核 `AccountPoolCore`（`src/host/common/account-pool.ts`）并复用同一张设置卡片（`src/client/common/AccountPoolCard`），因此具备**顺序耗尽 / 轮询调度 / 粘性会话**三种策略、429 冷却换号、账号级失效（保留账号、重新添加即恢复）、设为主账号、账号备注与清除冷却。账号 id 是 **Key 摘要 + 区域**，别名只显示「区域 + Key 后四位」，明文 Key 既不进别名也不进 id，更不会出现在卡片上（有测试锁定）；
+- **模型能力逐模型查表**（`src/host/zhipu/model-catalog.ts`）：是否接受图片、有哪些思考档位、能否关闭思考都由该表决定，运行时以订阅侧 `GET /models` 为准（只覆盖上下文窗口，能力不被上游列表改写）。图片能力不能按族名推断——**`glm-5.3-flash` 接受图片而 `glm-5.3` 不接受**；档位也不能——`glm-5.3` 有三档而 `glm-5.2` 只有两档，`glm-4.7` / `glm-4.5-air` 这类 toggle 模型根本不收 `reasoning_effort`；
+- **思考档位只发上游认的值**：上游对 GLM-5.x 只接受 `low` / `high` / `max`，其余取值**直接报错**（不是被忽略）。DSH 的档位词表比这宽，因此每个取值都先收敛到该模型自己的档位表再发出；收敛按**两套词表统一排序**，`minimal` 这类「比 low 更省」的档位会落到 `low` 而不是被当成未知值弹到中间档——否则用户选了最省的一档反而会换来 `high`，既不符合意图又更费额度。关闭思考的值本线路一律不发：GLM-5.3 / GLM-5.3-FLASH / GLM-4.7 把 `thinking.type: "disabled"` 判为错误，省略该字段就是它们的 `enabled` 默认；
+- **额度来自订阅自己的监控接口**：`{base}/api/monitor/usage/quota/limit` 给 5 小时与每周两个额度窗口（外加月度 MCP 工具调用次数），`{base}/api/biz/subscription/list` 给套餐名。这两个接口的鉴权用的是**不带 `Bearer` 前缀的裸 Key**（实测：带前缀判 401，裸 Key 通过），与模型接口的 `Bearer` 形式不同，因此两条 header 各自成函数。窗口按上游的 `unit`/`number` 描述换算成分钟后再命名，兼容 `TOKENS_LIMIT` 与新版 `CREDIT_LIMIT` 两种拼写；
+- **瞬时失败按错误类别重试**（`src/host/zhipu/adapter.ts`）：上游 5xx、`code 1230/1234` 与服务过载归为可重试并走有界退避（最多 3 次，1.5s 起步、15s 上限、0.2 抖动），429 会带上上游 `Retry-After`。而 **401/403 与 `code 1000/1003/1001`（Key 失效）、`code 1311`（套餐不含该模型）、`code 1309`（套餐已过期）明确不重试**——它们与「额度窗口用尽」同样是 429，但只有后者值得重试，因此分类读响应正文的 `code` 而不只看状态码，并给出可操作的提示（换模型 / 续费 / 重新添加 Key）；
+- 模型勾选、思考深度、上下文窗口覆盖与额度在「设置 → 订阅服务 → GLM」标签页中配置，输入框右侧另有额度胶囊（取**最紧的那个窗口**，因为 5 小时窗口和每周窗口会各自先耗尽）。
+
 **设置页**
 - 展示账号（脱敏 email、套餐、账号 ID 后四位）、连接状态、额度与订阅增强功能开关；
 - **偏好落盘位置随 harness 生成**：有 `settings.register` 的一代（≤0.1.6）仍写进 harness 的设置文档；0.1.7 起该 API 被 `SettingsForms` 取代，偏好改由插件自己持久化到 `<dshHome>/storages/dsh-chatgpt-subscription-preferences.json`（0600、原子写；读取失败或校验不过就回落默认值；**首次运行会从旧设置文档里本插件的段一次性迁移**），五条线路的模型开关同样从各自既有的 `storages/*-models.json` 水合，因此重启后不会像被重置；
@@ -136,7 +149,7 @@ dsh plugin --profile web add @eddyskywalker/dsh-chatgpt-subscription
 npx @deepseek-ai/dsh plugin --profile web add @eddyskywalker/dsh-chatgpt-subscription
 ```
 
-**版本阶段**：`latest` 目前是 0.7.0；0.8.0 的正式版尚未定稿，先以 `0.8.0-alpha.0` 发到 `alpha` 标签，因此上面两条命令装到的仍是 0.7.0。要试用 alpha，需显式带上标签或版本号：
+**版本阶段**：`latest` 现在是 **0.8.2**，上面两条命令装到的就是它。（此前 0.8.0-alpha.0 至 0.8.2 都只发在 `alpha` 标签下，`latest` 一直停在 0.7.0，于是升级时版本会从 0.8 退回 0.7。）预发布版仍只进 `alpha`，需要显式带上标签或版本号：
 
 ```sh
 dsh plugin --profile web add @eddyskywalker/dsh-chatgpt-subscription@alpha
@@ -344,9 +357,13 @@ DSH 设置页的「Subagent」卡片会把勾选的模型写成会话级的允
 | 浏览器授权 | `POST /v2/plugin/auth/state` + `GET /v2/plugin/auth/token` |
 | 令牌续期 | `POST /v2/plugin/auth/token/refresh` |
 | 额度 | `POST /billing/meter/get-user-resource` |
+| 签到状态 | `POST /billing/meter/checkin-activity-status`（仅国区） |
+| 每日签到 | `POST /billing/meter/daily-checkin`（仅国区） |
 
 两区后端分别是 `https://copilot.tencent.com`（国区）与 `https://www.workbuddy.ai` / `https://www.codebuddy.ai`（国际区）。**请求身份统一使用 CLI UA**（`CLI/2.63.2 CodeBuddy/2.63.2`）：实测 `CodeBuddyIDE` 被 `/v3/config` 以 400 `code 12403` 拒绝，国际区对话端点也直接返回 401，因此不做按端点切换。
 
+**每日自动签到**（仅国区；语义与 workbuddy2api 的 `daily_checkin.py` 对齐）：DSH 启动时自动签到一轮，运行期间每 10 分钟幂等补检（当日已签的账号不再发请求）；签到前先查签到状态，token 过期会自动续期并回写（桌面账号写回 CodeBuddy 自己的凭据文件）。失败当天最多自动重试 3 次；**活动尚未开启的账号不会当天放弃**——首次签到状态若报无权益，之后每小时复查一次，避免开机早于活动开放时间就错过当天。国际区账号不参与（国际后端没有签到活动）。**DSH 没开机的当天不会签到**——插件不是常驻服务。设置页「每日签到」区块可开关自动签到、查看「今日已签 x/y · 无活动 z · 失败 w」并手动「立即签到」（手动会重跑一轮并绕过开关与重试上限）。签到状态存在 `storages/workbuddy-checkin.json`，token 不出 Host。
+
 ### 插件路由（WorkBuddy）
 所有路由都以 `/workbuddy/api` 为前缀：
 
@@ -362,15 +379,56 @@ DSH 设置页的「Subagent」卡片会把勾选的模型写成会话级的允
 | GET / POST | `/models`、`/settings` | 读取或更新勾选模型、上下文窗口与默认思考深度 |
 | POST | `/catalog/refresh` | 强制刷新网关模型目录 |
 | POST | `/connection/test` | 用已识别凭据向上游发一次最小请求测试连接 |
+| POST | `/checkin/now` | 立即执行一轮每日签到（忽略开关与重试上限、不受无活动复查节流限制；当日已签的账号仍跳过） |
 
 与其它线路一样，所有修改状态的路由只接受同源 JSON POST，并校验 `Origin` 与 `Host`。
 
+## GLM（智谱 Coding Plan）线路
+
+1. 在你要用的平台上订阅 **GLM Coding Plan**，并在对应控制台创建 API Key：[Z.ai](https://z.ai/manage-apikey/apikey-list)（国际区）或 [智谱开放平台](https://open.bigmodel.cn/)（国区）；
+2. 重启 DSH，让 Host 加载本插件；
+3. 打开 **设置 → 订阅服务 → GLM**；
+4. 在「添加账号」里**先选区域**（国际区 / 国区），粘贴 Key 后点「保存并验证」——验证不通过就不会写入，并会提示 Key 应来自哪个控制台；
+5. 按需勾选模型、设置默认思考深度与上下文窗口。
+
+`zhipu-coding-plan` 会像其他 Provider 一样出现在 DSH 模型选择器中，并可与名为 `zai` / `zhipu` 的自定义 API 同时存在。**上下文窗口**默认取该模型官方声明的窗口（GLM-5.x 系列为 1M），可逐模型覆盖（用于 DSH 的压缩与溢出判断，支持 `1M` / `512K` / `200000` 等写法）；**默认思考深度**只对该模型声明了档位时生效，选项为上游真正接受的 `low` / `high` / `max`。
+
+**上游接口**（前缀 `{base}` 为该账号区域的 host）：
+
+| 用途 | 路径 | 鉴权 |
+| --- | --- | --- |
+| 模型生成 | `POST {base}/api/coding/paas/v4/chat/completions` | `Authorization: Bearer <Key>` |
+| 模型目录（也是添加 Key 时的验证接口） | `GET {base}/api/coding/paas/v4/models` | `Authorization: Bearer <Key>` |
+| 额度窗口 | `GET {base}/api/monitor/usage/quota/limit` | `Authorization: <Key>`（**无 `Bearer`**） |
+| 套餐信息 | `GET {base}/api/biz/subscription/list` | `Authorization: <Key>`（**无 `Bearer`**） |
+
+两区 host 分别是 `https://open.bigmodel.cn`（国区）与 `https://api.z.ai`（国际区）。请求只带本插件自己的 UA，不冒充官方客户端。
+
+### 插件路由（GLM Coding Plan）
+
+所有路由都以 `/zhipu/api` 为前缀：
+
+| 方法 | 路径 | 说明 |
+| --- | --- | --- |
+| GET | `/status` | 账号、额度、模型目录与路由归属 |
+| POST | `/accounts/add` | 验证并保存一个 API Key（可选 `alias`） |
+| POST | `/accounts/remove` | 删除当前账号（单凭据模式） |
+| POST | `/accounts/action` | 号池动作：`set-primary` / `set-alias` / `delete` / `clear-cooldown` / `clear-auth-failure` / `strategy` |
+| GET / POST | `/quota` | 强制刷新额度（POST）或读取当前状态（GET） |
+| GET / POST | `/models`、`/settings` | 读取或更新勾选模型、上下文窗口、默认思考深度与选中账号 |
+| POST | `/catalog/refresh` | 强制刷新模型目录 |
+| POST | `/connection/test` | 向上游对话接口发一次最小流式请求测试连接 |
+
+与其它线路一样，所有修改状态的路由只接受同源 JSON POST，并校验 `Origin` 与 `Host`；响应里永远不含 API Key（只含 Key 后四位）。
+
 ## 安全边界
 
 Antigravity 的 access token / refresh token 使用独立的系统凭据存储：Windows 使用 CurrentUser DPAPI（`$DSH_HOME/storages/antigravity-oauth.json.dpapi`），macOS 使用登录钥匙串，Linux 使用 Secret Service。macOS / Linux 的服务名为 `dsh-antigravity`，账号键按旧凭据文件的绝对路径生成，隔离不同的 `DSH_HOME`。
 
 **WorkBuddy token 仅在 Host 内处理，从不进入浏览器**（`/workbuddy/api` 响应不含 `accessToken` / `refreshToken`，有测试锁定）。桌面扫描账号仍使用 CodeBuddy 自己的登录态文件：续期只原子写回其 `auth` 块；从本插件删除时只隐藏/恢复，绝不删除原文件。通过浏览器授权添加的账号归本插件所有，保存在独立系统凭据存储中：Windows CurrentUser DPAPI（`$DSH_HOME/storages/workbuddy-accounts.json.dpapi`）、macOS 登录钥匙串、Linux Secret Service；这类账号可在设置页真正删除。
 
+**GLM Coding Plan 的 API Key 同样只在 Host 内处理，从不进入浏览器**（`/zhipu/api` 响应只含后四位提示，不含 Key 本身，有测试锁定）。它保存在独立系统凭据存储中：Windows CurrentUser DPAPI（`$DSH_HOME/storages/zhipu-credentials.json.dpapi`）、macOS 登录钥匙串、Linux Secret Service；号池另用一份同样加密的文件 `$DSH_HOME/storages/zhipu-pool.json`，账号 id 与别名都只是 Key 的摘要与后四位。
+
 升级后首次访问 Antigravity 凭据时，会读取旧 `storages/antigravity-oauth.json`，加密保存并读回校验；成功后删除旧 JSON，通常无需重新登录。失败会保留旧文件并报告错误，不会回退到明文存储。注销同时清理旧文件和新凭据。Linux 需要 `secret-tool`（libsecret 工具包）及可用、已解锁的 Secret Service 钥匙环；无桌面服务的主机也需要配置该服务。系统凭据存储保护落盘数据，不防御当前用户下已获权限的进程。
 
 Antigravity 的 Gemini 用量以流结束时的上游累计计数为准，缓存输入单列、思考 token 计入输出并另行提供明细；DSH 使用该输出计数计算 tok/s。Gemini 工具往返会保留原始思考签名，并在支持的运行时请求思考摘要；若上游没有返回摘要文本，插件不会生成替代内容。
@@ -415,6 +473,8 @@ npm run build
 npm pack --dry-run
 ```
 
+`vitest.config.ts` 把 `testTimeout` 设为 60s、`maxWorkers` 限到 4 是有原因的，改回去会让套件重新变得不稳定：多条目测真的会 spawn `powershell.exe` 跑 Windows DPAPI 凭据存储，隔离测量最慢的一条要 12–14s。超时余量不够时不只是那一条失败——**超时后仍在飞的请求会落进下一个用例的 fetch mock**，把邻居也判失败（表现为 `expected to be called 4 times, but got 8 times`）。限并发不增加耗时：这些用例受子进程延迟约束，4 个 worker 约 51s，15 个约 54s。
+
 测试使用 mock OAuth、Responses SSE 和 Wham usage，不需要真实 ChatGPT 凭据。真实账号的端到端登录与生成应在独立 DSH profile 中人工验收，避免影响日常 profile。
 
 ## 故障排查
@@ -443,4 +503,9 @@ npm pack --dry-run
 | Kimi Code 报 429 `engine is currently overloaded` | 服务容量问题（工作日 14:00–17:00 高峰更常见），会自动退避重试；若响应里带 `error.type = exceeded_current_quota_error` 则属于配额耗尽，插件不会重试而是提示补充额度 |
 | Kimi Code 额度显示为空 | 卡片会同时给出失败原因（`/v1/usages` 的 401/403/5xx 文案），按提示处理后点「刷新用量」重试；确认用的是订阅账号——开放平台的 key 在这里不会被接受 |
 | Kimi Code 账号一栏为空 | 账号身份取自 OAuth token 自身的 JWT 声明，套餐名取自 `/me`（`/usages` 自 2026-09 起不再返回 `user_level_name`）。重新登录或点「刷新用量」即可写入；若仍为空但显示「已登录」，点「测试连接」可确认凭据是否仍被接受 |
+| GLM 添加 Key 报「rejected the API key」 | Key 与所选**区域**不匹配，或它不是 Coding Plan 的 Key。错误文案会指明应来自哪个控制台（`api.z.ai` 或 `open.bigmodel.cn`）：换区域重试，并确认订阅生效；开放平台按量付费的 Key 在订阅接口上不被接受 |
+| GLM 报 `code 1311`（套餐不含该模型） / `code 1309`（套餐已过期） | 这两个都是账号权益问题而非瞬时故障，插件不会重试：前者换一个模型，后者去官网续费。两者与「额度窗口用尽」共用 429 状态码，插件按响应正文的 `code` 区分处理 |
+| GLM 报 `code 1214`（参数被拒） | 多为该模型不支持的思考档位或不可读的图片：`glm-5.3` 不接受图片（用 `glm-5.3-flash`），档位只有 `low` / `high` / `max`。卡片只会列出该模型真正声明过的能力 |
+| GLM 额度显示为空或「该账号没有可用的配额数据」 | 监控接口可用但该账号没有生效的套餐；确认订阅已开通，再点「刷新用量」。卡片会同时显示接口本身的失败原因（如 401 / 5xx 文案） |
+| GLM 模型不出现在选择器里 | 卡片上若显示「模型路由已被其他 Provider 占用」，从占用方（自定义的 `zai` / `zhipu` 线路）移除该 Provider，插件会在下一次路由变更时自动接管；否则检查是否勾选了模型 |
 | Kimi Code 发送视频却没有画面 | `k3-256k` 不支持视频，切到 `k3` 或 `kimi-for-coding`；容器须在白名单内（mp4/mpeg/mov/avi/x-flv/mpg/webm/wmv/3gpp）；若该模型走的是 Anthropic 线路，视频会降级为文字（该协议没有文档化的视频块）。以上情况模型都会收到明确的文字说明，据此向你说明而不是凭空回答 |