@eddyskywalker/dsh-chatgpt-subscription 0.28.0 → 0.29.0

package/CHANGELOG.md

@@ -2,6 +2,30 @@
 
 ## Unreleased
 
+## 0.29.0 - 2026-10-19
+- **[Antigravity] 429 不再被当成「配额耗尽」：裸 429 不冷却账号、不换账号，也不再把上游原因藏起来**
+  - **现象**：账号配额还很充足（实测 Gemini 5h 桶剩余 95.95%、周桶剩余 84.67%，Claude/GPT 100%），插件却报「账号配额已耗尽」，并把该账号的 Gemini 配额族冷却 15 分钟；此后每次重试都被账号池直接挡下，连一次网络请求都不发。
+  - **根因一（端点链）**：[adapter.ts](../src/host/antigravity/adapter.ts) 与 [image-tool.ts](../src/host/antigravity/image-tool.ts) 的端点候选循环只在 ok/400/404 时中断，主端点失败后会落到兜底端点。实测 `https://daily-cloudcode-pa.googleapis.com` 对 Antigravity 请求稳定 200，而 `https://cloudcode-pa.googleapis.com` 对**每一个** Antigravity 请求都回 429 `{"error":{"code":429,"message":"Resource has been exhausted (e.g. check quota).","status":"RESOURCE_EXHAUSTED"}}`——没有 details、没有 Retry-After。这个 429 于是成了「被上报的那一次失败」。
+  - **根因二（裸 429 被当成了配额结论）**：该 429 正文里没有任何重置时间，`retryDelayMs()` 返回 undefined，旧代码回落到写死的 15 分钟冷却并把它记成「配额已用尽」。**配额结论需要证据**：裸 429 只说明上游拒绝了这一次请求，不说明这个账号的 Gemini 或 Claude/GPT 额度用完了。
+  - **改法一（端点链）**：429 立即结束本次尝试的端点链——一个端点给出的配额结论不会因为换端点而变好，而兜底端点对每个 Antigravity 账号都回 429。**被上报的是第一个应答端点的结果**，除非后面的端点成功（ok）或回答 400/404（这两条中断条件原样保留）；所以「主端点 5xx + 兜底端点 429」现在报的是那个 5xx，而不是兜底端点的 429。
+  - **改法二（裸 429 不等于配额耗尽）**：429 给出了重置时间（quotaResetTimeStamp / quotaResetDelay / RetryInfo.retryDelay / Retry-After）时行为完全不变：按上游给的时长 `markFamilyCooldown(account.id, family, statedWaitMs, '429 Rate Limit')`、有下一个账号就换账号、最终报 `LlmError(..., 'RATE_LIMIT', { status: 429 })`。**没有重置时间的裸 429 不再冷却账号、不再换账号**，改为可重试且与账号无关的 `LlmError(..., 'SERVER', { status: 429 })`——`SERVER` 在 DSH 默认重试集合内，也是本仓库「上游说不、但不是账号的错」的既有措辞（见 `src/host/kimi-code/adapter.ts` 的 upstreamOverload）。文案直说「上游返回 429 但未给出重置时间，因此按瞬时限流处理，不视为账号配额耗尽」，并附上截断后的上游原始响应。图片工具同理：`ANTIGRAVITY_IMAGE_RATE_LIMITED` 保留，但裸 429 不再调用 `markFamilyCooldown`，文案也不再宣称配额已用尽。
+  - **改法三（上游原话随冷却一起留存）**：[account-pool.ts](../src/host/antigravity/account-pool.ts) 的 `markFamilyCooldown()` 多一个可选的 `detail`，冷却条目把它和 `until`/`reason` 放在一起——**上游的原话跟着它自己造成的冷却一起走**：[adapter.ts](../src/host/antigravity/adapter.ts) 与 [image-tool.ts](../src/host/antigravity/image-tool.ts) 在为配额型 429 记冷却时，把截断后的上游响应体作为 `detail` 一起写进去。`getEffectiveAccountFor` 保留「哪一族在冷却、最短还要几分钟」的措辞，**「上游返回：」后面引的是最先解除的那条冷却所带的 detail**（与那个「最短预计 N 分钟」指的是同一条，两者不会各说各话）；**没有任何 detail 时整句都不加**——共享内核抛出的那句「全部 N 个 Antigravity 账号均处于配额限制或冷却中」说的是**号池状态**而不是上游，它只作为 cause 链留在错误里，绝不会被贴上「上游返回」的标签。
+  - **验证**：`npm run typecheck` 0 错误；全量 **247 passed | 1 skipped（248 文件）、4016 passed | 7 skipped、0 failed**。新增 7 条回归守卫（adapter 4 条、image-tool 1 条、account-pool 2 条），并给既有的图片 429 用例加了两条断言（「429 只问一次」「上游原话随冷却一起写」）；**变异验证**：把这 3 个源码文件回退到改前版本后 6 处变红；再把「上游返回：」改回引号池状态那句话、或让 adapter 不再把上游响应体交给冷却，account-pool 与 adapter 的 3 条当场变红，恢复后全绿。
+- **[账号池] 冷却剩余时间改成秒级实时倒计时，并把「账号 × 模型」的停用窗口显示出来**
+  - **现象**：账号卡片上的「冷却中（剩 5 分）」是一个**静止的数字**——它在页面绘制那一刻算一次就再也不动了。5 分钟的冷却，用户会看着「剩 5 分」整整 5 分钟。同一行里的「重置冷却」按钮点掉之后，徽章还在（它跟号池状态不是一回事），而真正让这个号不可用的是「某个模型被停用」这件事，界面上**一个字都没有**。
+  - **改法一（实时倒计时）**：[AccountPoolSection.tsx](../src/client/common/AccountPoolSection.tsx) 里 `now` 从渲染时取的 `Date.now()` 变成 React state，由一个 1 Hz 的定时器推进。**定时器只在真有东西在冷却时才跑**（`counting` 开关），没有冷却的设置页不会为此每秒唤醒一次标签页；卸载时清理。徽章显示真实剩余时间：整分钟用原措辞，分钟+秒用新模板，不足一分钟**只显示秒**——「剩 1 分」撑最后 59 秒是假的。冷却结束，徽章**自己消失**，不用等下一次刷新。
+  - **改法二（模型停用行）**：WorkBuddy 的订阅按**账号 × 模型**计量 24 小时窗口（429 `code 6004`），所以被限的是**那个模型**、账号本身还能服务别的模型。号池里这份状态原来只活在内存里，接口一个字都不吐，界面因此把号显示成可用。现在它进账号摘要 DTO（[account-pool-contracts.ts](../src/shared/account-pool-contracts.ts) 的 `modelCooldowns`），卡片为每个被停用的模型单开一行，**标明模型名并给它自己的倒计时**；账号级徽章与模型行是**两件不同的事**，不混为一谈。
+  - **改法三（重置冷却真的清干净）**：号池的 `clearCooldown` 现在**连该账号的模型停用一起清掉**。留着它等于报告了一次没有发生的重置，而且那份状态用户根本没有别的手段能清。
+  - **改法四（WorkBuddy 卡片补轮询）**：[useWorkBuddySection.ts](../src/client/workbuddy/useWorkBuddySection.ts) 补上兄弟标签页都有的 60 秒可见态轮询。此前它只在标签页重新可见时刷新，于是**已经解除的冷却、已经出现的模型停用会一直挂在屏幕上**，直到手动刷新页面。
+  - **验证**：`npm run typecheck` 0 错误；全量 **247 passed | 1 skipped（248 文件）、4009 passed | 7 skipped、0 failed**；`npm run build` 通过。新增 5 条回归守卫（逐秒倒计时并到点自行消失、模型行渲染与缺席、WorkBuddy 60 秒重读、共享标签纪律扩展到新键、号池摘要与状态路由透出模型停用）。
+- **[进展更新] 默认开启，并补上「宿主服务晚到」时丢失的右侧栏入口**
+  - **现象一（多数用户）**：「进展更新」的开关默认是**关**的。没手动开过的用户装上插件后：`progress_update` 工具的 `execute` 一直返回 `displayed: false`，系统提示词里没有引导节，8 轮催促也不触发——功能整套静默不工作，而设置页里那个开关是唯一线索（截图里它是关的）。
+  - **现象二（部分用户）**：右侧栏 guide 里那一格「进展更新」**整格不出现**。页签类型是在本插件 `apply` 的那一刻同步向 `ctx.get('sidebarRightTabs')` 读的；宿主 `ui-sidebar-right` 若比本插件晚上线，那次读回来的是 `undefined`，注册被整段跳过——面板注册齐全但右侧栏空着，用户根本找不到入口（`test/progress-updates-client.test.tsx` 里那条「guide 入口缺失」的回归守卫就是为这个写的）。
+  - **改法一（默认开启）**：[src/index.ts](../src/index.ts) 的 `progressUpdates` 由 `default(false)` 改为 `default(true)`；[src/host/progress-updates/index.ts](../src/host/progress-updates/index.ts) 的 `resolveProgressUpdatesSettings` 判定由 `enabled === true` 改为 `enabled !== false`（**缺省即开启**，只有显式写 `false` 才关）；[settings-section.tsx](../src/client/progress-updates/settings-section.tsx) 的开关展示同步按「缺省即开启」——宿主还没答上来时显示为**开**而不是关。关掉的能力没有丢：设置页写 `false` 立刻生效（字段是 `volatile()`，不重挂插件行）。
+  - **改法二（晚到的服务自动补注册）**：[src/client/progress-updates/index.ts](../src/client/progress-updates/index.ts) 里，服务在位时仍**就地注册**（同步，行为不变）；服务缺席但上下文支持 `ctx.inject` 时，改用 `ctx.inject(['sidebarRightTabs'], ...)` **等它上线时补注册**页签类型与 guide 入口。取服务时先试 scope 的属性读（scope 的 inject 名单里有它，合法）、失败再退回 `ctx.get()`——本插件自己的静态 `inject` 没有这个服务名，直接读属性会被 Cordis 拒绝。设置表单 `configForms` 晚到时同样按需重取，设置页不再永久停在只读态。
+  - **没有踩的坑**：`ctx.inject` 在 Cordis 里会新建一个 fiber，服务永不上线时它就一直等着，**不影响**本插件其余部分的挂载；因此没有把 `sidebarRightTabs` 写进本插件的静态 `inject` 名单（那会让整个插件在没装 `ui-sidebar-right` 的部署上挂不上）。
+  - **验证**：`npm run typecheck` 0 错误（`tsc -b --force` + `tsc -p test/tsconfig.json`）；全量 **247 passed | 1 skipped（248 文件）、4006 passed | 7 skipped、0 failed**；`npm run build` 通过。新增/更新 5 条回归守卫，并做**变异验证**：临时回退这 4 个源码文件后，其中 5 条全部变红（默认开启 3 条、侧栏服务晚到 1 条、设置服务晚到 1 条），恢复后全绿。
+
 ## 0.28.0 - 2026-10-19
 - **[MiniMax Code] 模型目录跟上正式版：`MiniMax-M3.1-Flash` 取代 `MiniMax-M3.1-Flash-Preview`，并给存量用户留了一条迁移路**
   - **上游改名了**：MiniMax 于 2026-10-19 发布正式版 `MiniMax-M3.1-Flash`（官方 Model Invocation 页的 Supported Models 表已不再带 `-Preview` 后缀，1,000,000 上下文）。我们随包的硬编码目录里那条 `MiniMax-M3.1-Flash-Preview` 已经不是上游当前的名字。