docs: 整理 Sub2API 运维任务记录

2026-07-15 08:47:24 +02:00
parent 985baa8d50
commit 20436b8290
53 changed files with 1076 additions and 202 deletions
@@ -0,0 +1,22 @@
+# R2.10 任务报告
+
+## 范围
+
+通过 PK01 Sub2API 受控 CLI 调整手工 runtime 账号 ID `27` 的人类可读成本标注与账号全局优先级；未修改 Sub2API 源码、版本、YAML 管理范围或外部哨兵。
+
+## 近期证据
+
+近 24 小时原生账号聚合：账号原名称 `https://sub.yjxm1221.top plus 0.01`，尝试 `2472`、成功 `2429`、失败 `43`，可归因上游客户错误 `40`，失败率 `1.74%`；评分 `94.5/A`、置信度 high，TTFT P95 `11709ms`、样本 `1944`；请求 `2429`、Token `20.252M`、标准 API 计费基数 `242.2789 USD`。账号当时 active、schedulable，容量 `50`，优先级 `1`，窗口内临时不可调度命中 `30` 次。
+
+## 决策与执行
+
+新采购成本为每 1 USD 标准 API 计费对应 `0.025 CNY`。账号质量和时延仍优秀，但新成本高于 `iceiu 0.011`，因此优先级从 `1` 调整到 `3`：排在免费账号优先级 `1` 和 `iceiu` 优先级 `2` 之后，仍排在约 0.03 成本的优先级 `5` 账号之前。
+
+- account-name dry-run：精确命中 ID `27`，仅名称从 `https://sub.yjxm1221.top plus 0.01` 变为 `https://sub.yjxm1221.top plus 0.025`。
+- priority dry-run：精确命中 ID `27`，仅优先级从 `1` 变为 `3`。
+- 两项 confirm 均 `writeSucceeded=1`、`writeFailed=0`、`reconciled=1`、`mismatched=0`。
+- 最终只读快照：名称 `https://sub.yjxm1221.top plus 0.025`，优先级 `3`，active、schedulable=true，proxy `3`，容量 `50`，原临时不可调度模板保持不变。
+
+## 结论
+
+成本标注与优先级已按最新价格、近期质量和时延完成精准 runtime 调优，最终状态与期望一致。
@@ -1,23 +1,38 @@
 # R2.2.16 任务报告

-## 结论
+## 结果

-用户 `mail0795336304@163.com` 的“卡住约 15 分钟”不发生在 Sub2API 的在途请求、账号排队或 proxy 3 出网阶段。服务端证据显示，上一笔请求于 2026-07-14 14:43:33（UTC+8）成功结束，下一笔直到 14:59:54 才进入 Sub2API，中间约 16 分 21 秒没有该用户的新入站请求。卡点因此位于 Sub2API 入站之前，优先怀疑客户端、本地 Agent 状态机或客户端到入口之间的请求提交链路。
+- PK01 owning YAML 与实际运行镜像均为 `0.1.155`；运行状态 healthy。
+- 上下文窗口超限可仅通过 Sub2API v0.1.155 官方配置实现：
+  - 官方入口为 `/api/v1/admin/error-passthrough-rules`；
+  - 新增 YAML 模板 `openai-context-window-client-error`；
+  - 同时匹配 OpenAI 平台、错误码 `400/502` 与上下文超限关键词；
+  - 将最终状态码映射为 `400`，保留上游具体响应体并继续记录监控事件。
+- 规则已通过受控 CLI 写入 PK01，并由官方 API 回读为 `ruleId=1`、`state=synced`。
+- “首 Token 超过 180 秒后切号”无法通过 v0.1.155 官方配置等价实现：
+  - `openai_response_header_timeout` 只约束 HTTP 响应头，不是 TTFT；
+  - `stream_data_interval_timeout` 可约束流读取静默时间，默认已为 180 秒，但超时返回普通流错误，不会形成账号 failover；
+  - 因此未设置不等价超时项，也未修改 Sub2API 源码。
+- Grok、账号、分组、优先级和调度状态均未改动。

-## 原生运维证据
+## 持久化

- 用户 ID：22；账号状态 active；用户并发上限 10，调查时 current concurrency 为 0。
- API Key：名称 `pika_win`、ID 46、分组 `unidesk-codex-pool`；调查时 current concurrency 为 0。
- 最近 30 分钟共 7 笔请求，均为成功，无用户可见错误。
- 14:43:33 完成请求 `client:1daa3f3e-99a5-4fc4-809c-6f6ef854a2b2`，流式、`gpt-5.6-sol`，耗时 28.922 秒，账号 33。
- 14:59:54 下一笔请求 `client:8d1f8ef9-e703-482c-ace9-0d8f13a5c8e3` 才进入服务端；内部 request ID `efdb251f-8e86-4f18-99ee-fa1094419dc0`，15:00:43 完成，HTTP 200，耗时 49.115 秒。
- 最新请求使用上游账号 `https://api.iceiu.com plus 0.03`（ID 33）、模型 `gpt-5.6-sol`、proxy 3；没有 failover、select failure 或 forward failure。
- proxy 3 为 `platform-infra-sub2api-pk01-local-egress-proxy`，127.0.0.1:10809；对应 Hysteria 客户端自 7 月 8 日持续 active，调查窗口无错误日志，当前存在正常连接。
+- PR：https://github.com/pikasTech/unidesk/pull/2072
+- Merge commit：`9a0bf6c7f76b2b736035989a32b7743991da7d73`
+- owning YAML：`config/platform-infra/sub2api-codex-pool.yaml#runtime.errorPassthroughRules`
+- 受控 CLI：`platform-infra sub2api codex-pool error-passthrough list|apply|delete`
+- 技能参考：`.agents/skills/unidesk-sub2api/references/codex-pool.md`
+- 官方源码版本：https://github.com/Wei-Shaw/sub2api/tree/v0.1.155

-## 判定边界
+## 验证

-Sub2API v0.1.153 当前原生 request 明细记录请求完成耗时，但未记录流式首字时间和逐事件间隔。因此不能从现有数据精确证明客户端何时展示首字；不过“16 分 21 秒无入站请求”、用户/API Key 并发均为 0，以及随后请求 49 秒正常完成，足以排除 Sub2API 内部排队、上游账号占槽 15 分钟和 proxy 3 在该窗口报错。
-
-## 建议
-
-让用户侧保留该时段客户端日志，重点检查本地 Agent 是否在上一轮完成后未推进状态、请求是否直到 14:59:54 才真正发出，以及本地 HTTP/SSE 客户端是否错误等待已经关闭的流。后续 CLI 可泛化补充按用户邮箱映射用户 ID、请求间空窗和 TTFT/末事件可见性；本次只读调查未取消请求，也未修改 runtime、YAML、proxy 或调度。
+- TypeScript 相关文件 `bun --check` 全部通过。
+- `git diff --check origin/master...HEAD` 通过。
+- dry-run：目标规则为 `missing`、`mutation=false`。
+- confirm apply：`mutation=true`、`state=synced`。
+- 再次 list：`mutation=false`、`ruleId=1`、`state=synced`。
+- `platform-infra sub2api status --target PK01`：
+  - `sub2api-app` healthy；
+  - 镜像 `docker.1panel.live/weishaw/sub2api:0.1.155`。
+- `config/platform-infra/sub2api.yaml`：
+  - PK01 `image.tag: 0.1.155`。
@@ -1,94 +0,0 @@
-# R2.2.37 Sub2API 原生 Grok 接入 Codex 调查报告
-
-## 调查边界
-
-本任务只读检查 `Wei-Shaw/sub2api` 官方仓库最新发布标签、主线源码、发布说明、issue 和合并 PR；未修改 PK01 runtime、YAML、源码或部署。
-
-## 版本基线
-
- 官方仓库最新发布标签为 `v0.1.155`，提交 `41cec0db059ffb82d0efdcfcf07a24ab51fbfe97`，发布时间为 2026-07-14。
- 官方最新发布说明：<https://github.com/Wei-Shaw/sub2api/releases/tag/v0.1.155>。
- `v0.1.155` 已包含原生 Grok provider、Grok OAuth、xAI API Key、Codex Responses 兼容、Grok 渠道健康监控和近期 Grok 兼容修复。
-
-## 核心结论
-
-最新 Sub2API 已原生支持 Grok 上游接入 Codex，普通接入不需要修改 Sub2API 源码。正确链路是：
-
-```text
-Codex CLI
-  -> Sub2API /v1/responses
-  -> Sub2API API Key 绑定的 platform=grok 分组
-  -> platform=grok 的 OAuth 或 API Key 账号
-  -> OAuth: cli-chat-proxy.grok.com/v1/responses
-     API Key: api.x.ai/v1/responses
-```
-
-不要把 Grok 配置成 `platform=openai` 的自定义 base URL。原生 Grok 路径负责 OAuth 刷新、CLI 身份头、请求字段净化、模型映射、配额观察、429 冷却和 Grok 专属健康监控；伪装成 OpenAI 会绕过这些能力。
-
-## 官方源码证据
-
-### 路由与分组选择
-
- `backend/internal/server/routes/gateway.go` 把 `PlatformOpenAI` 和 `PlatformGrok` 都识别为 OpenAI Responses 兼容平台。
- `/v1/responses`、`/responses` 和 `/backend-api/codex/responses` 均可由 Grok 分组进入 OpenAI gateway。
- API Key 所绑定分组的平台决定请求走哪个 provider，因此客户端使用的是 Sub2API API Key，不是直接使用 xAI Key。
-
-### Grok 专用转发
-
- `backend/internal/service/openai_gateway_forward.go` 在账号平台为 `grok` 时直接调用 `forwardGrokResponses`。
- `backend/internal/service/openai_gateway_grok.go` 同时接受 `oauth` 和 `api_key` 两种 Grok 账号。
- 转发前会映射模型、净化 xAI 不兼容字段和工具，OAuth 请求还会带 Grok CLI 身份与缓存路由信息。
- Codex WebSocket Responses 入站被接受，但 Grok 上游实际桥接为 HTTP/SSE，并非 xAI WebSocket 透传。
-
-### 模型映射
-
- `backend/internal/pkg/xai/models.go` 默认包含 `grok-4.5`、`grok-4.3`、`grok-build-0.1`、`grok-composer-2.5-fast` 和 Grok 4.20 系列。
- 默认别名包括 `grok -> grok-4.5`、`grok-latest -> grok-4.5`、`grok-build -> grok-build-0.1`、`grok-composer -> grok-composer-2.5-fast`。
- 最清晰的 Codex 配置是直接请求 `grok-4.5`。只有消费端必须沿用其他模型名时，才在 Grok 账号的 `model_mapping` 中显式映射；不建议用 `gpt-*` 名称长期伪装 Grok，以免模型归因、价格和排障语义混乱。
-
-## Sub2API 配置步骤
-
-1. 在管理后台创建原生 Grok 账号：
-   - 订阅账号：选择 `Grok -> OAuth` 并完成 xAI 授权；推理默认走 `https://cli-chat-proxy.grok.com/v1`。
-   - 官方计费 API：选择 `Grok -> API Key`，base URL 使用 `https://api.x.ai/v1`。
-2. 创建平台为 `grok` 的分组，并把 Grok 账号加入该分组。
-3. 创建一个 Sub2API API Key，并把该 Key 指派给 Grok 分组。
-4. 先验证该 Key 的 `/v1/models` 能看到 `grok-4.5`，再做 `/v1/responses` 的同步、流式和工具调用 smoke。
-5. 对 OAuth 账号保持保守并发起步；是否提高并发应由实际首 Token、429 和渠道健康数据决定。
-
-## Codex 客户端配置模板
-
-`~/.codex/config.toml` 可使用独立 provider，避免覆盖现有默认 provider：
-
-```toml
-model_provider = "sub2api_grok"
-model = "grok-4.5"
-
-[model_providers.sub2api_grok]
-name = "Grok via Sub2API"
-base_url = "https://<sub2api-public-host>/v1"
-wire_api = "responses"
-requires_openai_auth = true
-supports_websockets = false
-```
-
-认证使用绑定 Grok 分组的 Sub2API API Key，通过 Codex 既有 `auth.json` 或受控凭据入口注入；不要把 xAI Key 直接交给 Codex，也不要把密钥写入仓库。初次接入建议保持 HTTP Responses；Sub2API 虽支持 Codex WebSocket 入站，但 Grok 上游仍为 HTTP/SSE，只有完成真实 WS smoke 后再启用 Codex WebSocket 标记。
-
-## 官方 issue 与修复演进
-
- 原生 Grok 订阅支持由 PR #3310 引入，明确覆盖 `/v1/responses`、`/responses` 和 `/backend-api/codex/responses`：<https://github.com/Wei-Shaw/sub2api/pull/3310>。
- PR #3558 补齐 Codex/OpenAI 兼容路由、WebSocket 入站桥接和 Codex 请求净化：<https://github.com/Wei-Shaw/sub2api/pull/3558>。
- Issue #3952 记录旧实现缺失 Grok CLI 版本身份头会被 OAuth 上游以 426 拒绝：<https://github.com/Wei-Shaw/sub2api/issues/3952>。
- PR #4009 修复 CLI 身份头、OAuth 路由、`additional_tools`、Composer 推理参数，并加入 xAI API Key 账号：<https://github.com/Wei-Shaw/sub2api/pull/4009>。
- `v0.1.152` 已发布上述关键修复，`v0.1.155` 又修复 Grok reasoning `content:null` 422、缓存路由和监控能力，因此新接入应直接以 `v0.1.155` 为基线。
-
-## 风险与验收重点
-
- OAuth 与 API Key 是不同上游路径，不能混用 base URL：OAuth 走订阅 CLI proxy，API Key 走 `api.x.ai`。
- Codex 的私有/新增 Responses 字段可能领先 xAI schema；`v0.1.155` 已清理已知的 `additional_tools`、不兼容 reasoning 字段和 `content:null`，仍应以真实工具调用 smoke 为准。
- Grok quota 是被动观察上游 rate-limit header；首次成功请求前显示 unknown 属正常现象。
- `401` 表示凭据问题，`403` 表示权限或订阅 entitlement，`429` 会进入临时不可调度；这些应按真实错误分类，不能统一当网络失败。
-
-## 建议
-
-直接采用 `v0.1.155` 的原生 Grok provider，优先建立独立 Grok 分组和独立 Sub2API Key，以 `grok-4.5 + Responses + HTTP` 作为首个受控配置。无需 Sub2API 源码变更；下一步若要落地，应先把账号、分组、Key 和模型映射声明进 owning YAML，再走受控 plan/apply 和最小 smoke。
@@ -0,0 +1,3 @@
+# R2.2 通用故障归因与调优任务报告
+
+本分支集中保留客户可见错误归因、所有分组诊断、failover/重试、TTFT、runtime CRUD、临时不可调度模板及账号粒度评分的基础能力。原 R2.2.1-R2.2.15 均已完成；客户专项事件、账号优先级、利润和 Grok 接入已迁到独立职责分支。
@@ -0,0 +1,23 @@
+# R2.4.1 任务报告
+
+## 结论
+
+用户 `mail0795336304@163.com` 的“卡住约 15 分钟”不发生在 Sub2API 的在途请求、账号排队或 proxy 3 出网阶段。服务端证据显示，上一笔请求于 2026-07-14 14:43:33（UTC+8）成功结束，下一笔直到 14:59:54 才进入 Sub2API，中间约 16 分 21 秒没有该用户的新入站请求。卡点因此位于 Sub2API 入站之前，优先怀疑客户端、本地 Agent 状态机或客户端到入口之间的请求提交链路。
+
+## 原生运维证据
+
+- 用户 ID：22；账号状态 active；用户并发上限 10，调查时 current concurrency 为 0。
+- API Key：名称 `pika_win`、ID 46、分组 `unidesk-codex-pool`；调查时 current concurrency 为 0。
+- 最近 30 分钟共 7 笔请求，均为成功，无用户可见错误。
+- 14:43:33 完成请求 `client:1daa3f3e-99a5-4fc4-809c-6f6ef854a2b2`，流式、`gpt-5.6-sol`，耗时 28.922 秒，账号 33。
+- 14:59:54 下一笔请求 `client:8d1f8ef9-e703-482c-ace9-0d8f13a5c8e3` 才进入服务端；内部 request ID `efdb251f-8e86-4f18-99ee-fa1094419dc0`，15:00:43 完成，HTTP 200，耗时 49.115 秒。
+- 最新请求使用上游账号 `https://api.iceiu.com plus 0.03`（ID 33）、模型 `gpt-5.6-sol`、proxy 3；没有 failover、select failure 或 forward failure。
+- proxy 3 为 `platform-infra-sub2api-pk01-local-egress-proxy`，127.0.0.1:10809；对应 Hysteria 客户端自 7 月 8 日持续 active，调查窗口无错误日志，当前存在正常连接。
+
+## 判定边界
+
+Sub2API v0.1.153 当前原生 request 明细记录请求完成耗时，但未记录流式首字时间和逐事件间隔。因此不能从现有数据精确证明客户端何时展示首字；不过“16 分 21 秒无入站请求”、用户/API Key 并发均为 0，以及随后请求 49 秒正常完成，足以排除 Sub2API 内部排队、上游账号占槽 15 分钟和 proxy 3 在该窗口报错。
+
+## 建议
+
+让用户侧保留该时段客户端日志，重点检查本地 Agent 是否在上一轮完成后未推进状态、请求是否直到 14:59:54 才真正发出，以及本地 HTTP/SSE 客户端是否错误等待已经关闭的流。后续 CLI 可泛化补充按用户邮箱映射用户 ID、请求间空窗和 TTFT/末事件可见性；本次只读调查未取消请求，也未修改 runtime、YAML、proxy 或调度。
@@ -1,4 +1,4 @@
-# R2.2.17 任务报告
+# R2.4.2 任务报告

 ## 结果

@@ -1,4 +1,4 @@
-# R2.2.18 任务报告
+# R2.4.3 任务报告

 ## 结果

@@ -1,4 +1,4 @@
-# R2.2.19 任务报告
+# R2.4.4 任务报告

 ## 结果

@@ -17,4 +17,4 @@

 ## 后续

-内部监控超时、请求切号关联和 P0/P1/P2 快速查询分别由 R2.2.23 与 R2.2.21 继续增强；这些后续能力不改变本任务的原生只读边界。
+内部监控超时、请求切号关联和 P0/P1/P2 快速查询分别由 R2.4.8 与 R2.4.6 继续增强；这些后续能力不改变本任务的原生只读边界。
@@ -1,4 +1,4 @@
-# R2.2.20 任务报告
+# R2.4.5 任务报告

 ## 目标

@@ -1,4 +1,4 @@
-# R2.2.21 任务报告
+# R2.4.6 任务报告

 ## 结果

@@ -1,4 +1,4 @@
-# R2.2.22 任务报告
+# R2.4.7 任务报告

 ## 结论

@@ -1,4 +1,4 @@
-# R2.2.23 任务报告
+# R2.4.8 任务报告

 ## 结果

@@ -1,4 +1,4 @@
-# R2.2.24 任务报告
+# R2.4.9 任务报告

 ## 结论

@@ -0,0 +1,3 @@
+# R2.4 客户事件与原生诊断任务报告
+
+本分支汇总用户卡顿反馈、一键用户追踪、原生智能诊断与渠道监控、P0/P1/P2 快查，以及错误 #17440、#17490、#17511 的专项调查。迁入的九项任务及报告均保持完成状态。
@@ -0,0 +1,108 @@
+# R2.5.10 任务报告
+
+## 范围与来源
+
+- 窗口：最近 8 小时。
+- 目标：PK01。
+- 数据源：
+  - Sub2API 原生 admin/ops 分组概要、账号可用性与并发；
+  - 原生 admin usage 账号流水、Token 与 `actual_cost`；
+  - 原生 request-errors 与 system-log 账号评分证据。
+- 全程只读，未修改 runtime、YAML、优先级、账号或运行面。
+- Grok 按现有利润策略排除，不进入 OpenAI 账号成本与利润聚合。
+
+## 分组概要
+
+- `unidesk-codex-pool`：
+  - Ops 请求 2,155；
+  - 客户错误 29，错误率 1.35%；
+  - 上游错误率 7.33%；
+  - TTFT P99 893,414 ms；
+  - usage 流水约 1,940 请求、13.264M Token、189.5743 标准 API USD。
+- `自用`：
+  - Ops 请求 3,291；
+  - 客户错误 0；
+  - 上游错误率 0.21%；
+  - TTFT P99 24,285 ms；
+  - usage 流水约 2,942 请求、21.951M Token、344.7493 标准 API USD。
+- 当前账号可用 8/10、并发 5/225、排队 0。
+- 账号 29、30 因余额不足 403 不可用。
+
+## 盈利池账号评分与流水
+
+- `https://sub2.pokexiao.com pro 0.05`：
+  - 100/A，高置信度；
+  - 192 次尝试，失败率 0，TTFT P95 6,797 ms；
+  - 192 条流水、2.567M Token、26.8695 API USD。
+- `https://api.iceiu.com plus 0.03`：
+  - 100/A，高置信度；
+  - 223 次尝试，失败率 0，TTFT P95 4,619 ms；
+  - 223 条流水、0.435M Token、21.1954 API USD。
+- `https://sub.yjxm1221.top plus 0.01`：
+  - 99.5/A，高置信度；
+  - 630 次尝试，失败率 0.16%，TTFT P95 9,806 ms；
+  - 约 627 条流水、3.988M Token、50.0402 API USD。
+- `https://ai.whistlelads.com plus 0.03`：
+  - 99/A，高置信度；
+  - 296 次尝试，失败率 0.34%，TTFT P95 9,070 ms；
+  - 约 295 条流水、3.009M Token、39.7672 API USD。
+- `https://sub2.pokexiao.com plus 0.03`：
+  - 88/B，高置信度；
+  - 627 次尝试，失败率 3.99%，TTFT P95 7,554 ms；
+  - 25 个客户错误，占盈利池 29 个客户错误的 86.2%；
+  - 约 602 条流水、3.229M Token、51.4244 API USD。
+- `https://api.recurdream.com plus 0.02`：
+  - 20/insufficient，低置信度；
+  - 仅 1 次尝试且发生 failover，最终恢复；
+  - 盈利池无足够 usage 流水，不能据此判定退役。
+- `lyon9801 0.10`、`https://sub.yjxm1221.top pro 0.06`：
+  - 该窗口无尝试，评分证据不足。
+- `https://api.lwylink.xyz pro 0.1`、`https://api.lwylink.xyz plus 0.05`：
+  - 无尝试且当前余额不足，不可用。
+
+## 自用池账号评分与流水
+
+- `https://sub2.pokexiao.com pro 0.05`：
+  - 100/A，高置信度；
+  - 549 次尝试，失败率 0，TTFT P95 9,381 ms；
+  - 549 条流水、3.757M Token、64.4262 API USD。
+- `https://sub2.pokexiao.com plus 0.03`：
+  - 99.4/A，高置信度；
+  - 990 次尝试，失败率 0.20%，一次 failover 成功；
+  - TTFT P95 7,149 ms；
+  - 约 988 条流水、6.778M Token、102.8114 API USD。
+- `https://ai.whistlelads.com plus 0.03`：
+  - 99.1/A，高置信度；
+  - 770 次尝试，失败率 0.26%，一次 failover 成功；
+  - TTFT P95 10,806 ms；
+  - 约 768 条流水、6.238M Token、93.7645 API USD。
+- `https://api.iceiu.com plus 0.03`：
+  - 99/A，高置信度；
+  - 301 次尝试，失败率 0.33%，TTFT P95 7,456 ms；
+  - 301 条流水、0.663M Token、43.9813 API USD。
+- `https://sub.yjxm1221.top plus 0.01`：
+  - 96.8/A，高置信度；
+  - 335 次尝试，失败率 0.90%，两次 failover 均恢复；
+  - TTFT P95 13,377 ms；
+  - 约 328 条流水、4.471M Token、39.3431 API USD。
+- `https://api.recurdream.com plus 0.02`：
+  - 40/insufficient，低置信度；
+  - 9 次尝试、3 次 failover 均恢复，未产生客户错误；
+  - 约 6 条流水、0.262M Token、1.4470 API USD。
+
+## 经济汇总
+
+- 盈利池收入：约 ¥18.9574。
+- 盈利池采购成本：约 ¥5.2183。
+- 自用池采购成本：约 ¥10.8493。
+- 不扣自用成本利润：约 ¥13.7392。
+- 扣除自用成本利润：约 ¥2.8899。
+- 单价口径为人民币倍率，即每 1 标准 API USD 对应的人民币售价或采购成本，不是汇率换算。
+
+## 结论
+
+- 盈利池主要质量问题集中在 `https://sub2.pokexiao.com plus 0.03`，但其自用池表现为 99.4/A，暂不能解释为账号整体不稳定；应继续按盈利池模型、请求类型和极端 TTFT 请求下钻。
+- 盈利池 TTFT P99 约 893 秒，而活跃账号 P95 仅约 4.6–9.8 秒，表明是少量极端长尾，不支持整体降低账号评分或全面降优先级。
+- `https://api.recurdream.com plus 0.02` 样本过少，评分低但 failover 均恢复，不足以退役。
+- 账号 29、30 是明确余额故障，应保持不可用，不纳入质量比较。
+- Ops 请求、评分尝试和 usage 流水来自不同原生接口，时间边界与计费过滤不同，数量不能强行一一相等。
@@ -0,0 +1,37 @@
+# R2.5.11 任务报告
+
+## 结论
+
+- PK01 `unidesk-codex-pool` 最近 8 小时复核时约有 2295 个请求、32 个客户可见错误，客户错误率 1.39%。
+- 32 个客户错误不是同一种账号故障：
+  - 17 个为上下文窗口超限，属于客户输入约束，不扣账号分；
+  - 2 个为 `glm-5.2` 未被分组账号支持，属于模型路由配置，不扣账号分；
+  - 11 个为 `Upstream service temporarily unavailable`；
+  - 2 个为 `Upstream request failed`。
+- 状态码分布为 502 共 29 个、404 共 2 个、524 共 1 个；同步 30 个、流式 2 个。
+- 账号 `https://sub2.pokexiao.com plus 0.03` 原始客户错误 25 个，其中 17 个上下文超限被排除，只有 8 个明确上游错误参与评分；修正后评分为 96.2/A，而不是此前把全部客户错误计入后的 88/B。
+- 两个代表性同步 502 均已触发 failover，但请求上下文随后立即 `context canceled`，切号没有剩余执行窗口；这不是当前池并发不足，因为观察时容量 225、在用约 5、排队 0。
+
+## Priority 调整
+
+- 账号 27 `https://sub.yjxm1221.top plus 0.01` 保持 priority 1，兼顾最低成本和高质量。
+- 账号 28 `https://ai.whistlelads.com plus 0.03`、31 `https://sub2.pokexiao.com plus 0.03`、33 `https://api.iceiu.com plus 0.03` 调整为 priority 5；账号 32 `https://sub2.pokexiao.com pro 0.05` 保持 priority 5。
+- 账号 35 `https://api.recurdream.com plus 0.02` 调整为 priority 20：成本低，但样本少且存在已恢复的上游失败，需要继续观察。
+- `lyon9801 0.10` 保持 priority 20，作为零毛利应急账号；账号 19 `https://sub.yjxm1221.top pro 0.06` 保持 priority 50。
+- 全部写入均通过受控 runtime priority dry-run、confirm 和逐账号自动回读完成；未修改分组、容量、代理、凭据、状态、可调度或临时不可调度规则。
+
+## 工具与 SKILL
+
+- PR #2077 增加 runtime priority 单账号与精准批量 dry-run/confirm、仅字段更新和逐账号自动对账。
+- PR #2082 将评分、请求量、Token、标准 API 美元计费基数、人民币采购倍率和人民币上游成本聚合到一次 `runtime errors --group ... --since ...` 查询。
+- 可靠性扣分改为保守的明确归因：只计入原生 upstream 分类、稳定上游网关消息、failover 和 `forward_failed`；上下文、输入校验、模型路由、内部/业务、无账号和未知归因错误全部保留可见但不扣分。
+- CLI 输出新增 `scoreableUpstreamErrorRequests`、`excludedNonUpstreamErrorRequests`、排除原因桶和账号成本流水表。
+- `runtime.ts` 从超过 3000 行按输出投影、远端脚本头部和远端脚本尾部拆分，相关文件均低于 2000 行。
+- `unidesk-sub2api` SKILL 已固化一次查询完成评分与流水分析、完整账号名称输出和非上游错误不扣分的规则。
+
+## 验证
+
+- 相关 TypeScript 文件 `bun --check` 全部通过，`git diff --check` 通过。
+- PK01 真实只读回归中，账号 31 一次显示 624 请求、3.607M Token、56.3256 API USD、0.030 CNY/API USD 和 1.6898 CNY 上游成本。
+- `runtime list --target PK01` 回归通过，账号名称、priority 和 runtime 状态正常显示。
+- PR #2082 已合并，merge commit 为 `3464e93acd8a2d688933f03f0f78303cdf9c6c64`；该交付为 CLI/SKILL 轻量变更，`rollout=not-applicable`。
@@ -0,0 +1,5 @@
+# R2.5.12 任务报告
+
+- 原生 trace 证实并发限额错误发生于 SSE 已提交后的 HTTP 200 阶段，`upstream_error_response_already_written=true`；官方临时不可调度规则依赖 HTTP 状态码，不能挽救当前流。
+- 现有通用模板已覆盖 429/502/503/504/524 的 `concurrency limit exceeded`，继续追加规则无效，因此未修改模板。
+- 已在 `unidesk-sub2api` 禁止事项中固化：未获明确授权时，不修改 Sub2API 源码、版本，也不启用、扩展或调整外部哨兵。
@@ -1,4 +1,4 @@
-# R2.2.25 任务报告
+# R2.5.1 任务报告

 ## 结果

@@ -1,4 +1,4 @@
-# R2.2.26 任务报告
+# R2.5.2 任务报告

 ## 范围

@@ -1,4 +1,4 @@
-# R2.2.27 任务报告
+# R2.5.3 任务报告

 ## 目标

@@ -1,4 +1,4 @@
-# R2.2.28 任务报告
+# R2.5.4 任务报告

 ## 范围

@@ -1,8 +1,8 @@
-# R2.2.29 任务报告
+# R2.5.5 任务报告

 ## 目标

-按 R2.2.28 的最近 4 小时评分与用量结论，精准调整 PK01 Sub2API runtime-manual 账号的全局 priority。只修改 priority，不修改分组、容量、代理、凭据、状态、可调度或临时不可调度规则。
+按 R2.5.4 的最近 4 小时评分与用量结论，精准调整 PK01 Sub2API runtime-manual 账号的全局 priority。只修改 priority，不修改分组、容量、代理、凭据、状态、可调度或临时不可调度规则。

 ## 执行与保护

@@ -1,4 +1,4 @@
-# R2.2.30 任务报告
+# R2.5.6 任务报告

 ## 目标

@@ -7,7 +7,7 @@
 ## 已完成登记

 - 子 Issue：https://github.com/pikasTech/unidesk/issues/2037
- MDTODO：R2.2.30，进行中。
+- MDTODO：R2.5.6，进行中。
 - 独立 worktree：`/root/unidesk/.worktree/sub2api-runtime-priority`。
 - 分支：`feat/sub2api-runtime-priority`，基于最新 `origin/master` 创建并推送，worktree clean。

@@ -1,4 +1,4 @@
-# R2.2.31 任务报告
+# R2.5.7 任务报告

 ## 窗口与范围

@@ -1,4 +1,4 @@
-# R2.2.32 任务报告
+# R2.5.8 任务报告

 ## 经济口径

@@ -0,0 +1,68 @@
+# R2.5.9 任务报告
+
+## 范围
+
+- 目标：PK01 Sub2API v0.1.155。
+- 原生观测窗口：约 2026-07-15 00:20 至 02:20（UTC+8）。
+- 范围：全部 3 个分组；只读使用原生 admin Ops overview、request-errors、upstream-errors、account-availability、usage、system-log 索引及稳定 request trace。
+- 查询有秒级时间漂移：全分组概要为 2214 个请求；随后分组下钻分别为 622、1593、7 个请求。
+
+## 全局用户可见错误
+
+- 全分组概要：2214 个请求、25 个客户错误，客户错误率 1.13%；27 个上游错误，上游错误率 1.22%。
+- `unidesk-codex-pool`：621 个请求、19 个客户错误，错误率 3.06%；20 个上游错误，错误率 3.22%。
+  - 17 个同步 502 来自账号 31 `https://sub2.pokexiao.com plus 0.03`，模型为 `claude-opus-4-8`，原始语义是输入超过模型上下文窗口。
+  - 代表请求 `97a552d6-2b4d-45ff-a449-240201e5f127` 最终 502，未触发 failover；这不是随机账号不稳定，切号通常不能解决超上下文输入。
+  - 2 个 `glm-5.2` 请求因组内没有支持账号快速返回 404，其中同步、流式各 1 个。
+- `自用`：1586 个请求、0 个客户错误；4 个上游错误全部经 4 次 failover 恢复，客户错误率 0%。
+  - 另有 2 个 HTTP 200 后 `forward_failed` 的流式 degraded 请求，稳定请求 ID 为 `abc711f6-aff0-486f-a94b-09426ee4cac1`、`57f1308e-cbe9-4804-bcd9-a2fb5149e944`；它们不计入原生客户错误率，但客户可能感知到流式中断。
+- `grok`：7 个请求、6 个客户错误；SLA 分母排除 3 个 business-limited 后错误率为 75%。
+  - 唯一账号 36 `https://sub.yjxm1221.top grok` 出现 3 次上游 502 overload。
+  - 3 次均触发 failover，但排除失败账号后没有其他候选；随后另有 3 个请求在路由阶段直接 503。
+  - 代表请求 `dfd99f91-52e4-4de9-bea9-d64a3e8e623b` 在 1346 ms 收到上游 502，同毫秒进入切号，2 ms 后因 `no available accounts` 返回 502。因此不是切号超时，而是单账号池没有备用候选。
+
+## 首字延迟
+
+- `unidesk-codex-pool`：TTFT P50 3729 ms、P95 8983 ms、P99 10688 ms、最大 101398 ms。
+- `自用`：TTFT P50 4076 ms、P95 12768 ms、P99 23386 ms、最大 540382 ms，长尾明显高于商业池。
+- `grok`：成功流式首 token 样本不足，TTFT 不可用；唯一成功请求总耗时 2264 ms，不能代替 TTFT。
+- 当前 Sub2API 原生 Ops 响应未提供 `/v1/responses` 与 `/v1/responses/compact` 的独立 request-level TTFT，因此本窗口不能可靠拆分普通与 compact；总耗时没有被冒充为 TTFT。
+- 账号长尾重点：
+  - `https://sub.yjxm1221.top plus 0.025`：自用池 TTFT P95 19286 ms、P99 49075 ms、最大 540382 ms。
+  - `https://ai.whistlelads.com plus 0.03`：自用池 P95 14827 ms、P99 25735 ms、最大 27701 ms。
+  - `https://api.iceiu.com plus 0.03`：自用池 P95 9088 ms、P99 18947 ms、最大 31725 ms。
+  - `https://sub2.pokexiao.com plus 0.03`：商业池最大 101398 ms；自用池 P99 14588 ms、最大 59814 ms。
+
+## 账号评分
+
+评分是分组内、窗口内分析结果；可靠性 60、TTFT 25、当前可用性 15。上下文错误会降低可靠性分，因此不能直接解释为供应商网络质量。
+
+### unidesk-codex-pool
+
+- `https://ai.whistlelads.com plus 0.03`：100/A，高置信，130 次尝试、0 失败，TTFT P95 9906 ms。
+- `https://sub2.pokexiao.com pro 0.05`：100/A，中置信，14 次尝试、0 失败，TTFT P95 4839 ms。
+- `https://api.iceiu.com plus 0.03`：100/A，高置信，55 次尝试、0 失败，TTFT P95 5416 ms。
+- `https://sub2.pokexiao.com plus 0.03`：86.3/B，高置信，373 次尝试、17 次失败，TTFT P95 6557 ms；扣分全部来自超上下文请求，不应据此退役账号。
+
+### 自用
+
+- `https://sub2.pokexiao.com pro 0.05`：100/A，高置信，113 次尝试、0 失败，TTFT P95 7035 ms。
+- `https://api.iceiu.com plus 0.03`：100/A，高置信，161 次尝试、0 失败，TTFT P95 9088 ms。
+- `https://sub2.pokexiao.com plus 0.03`：99.6/A，高置信，764 次尝试、1 次失败，1 次 failover 成功，TTFT P95 7152 ms。
+- `https://ai.whistlelads.com plus 0.03`：96.3/A，高置信，200 次尝试、2 次失败，1 次 failover 成功，TTFT P95 14827 ms。
+- `https://sub.yjxm1221.top plus 0.025`：94/A，高置信，193 次尝试、3 次失败，2 次 failover 均成功，TTFT P95 19286 ms；主要风险是极端长尾。
+- `https://api.recurdream.com plus 0.02`：100/insufficient，低置信，仅 3 次尝试，不能与高样本账号等价排序。
+
+### grok 与无样本账号
+
+- `https://sub.yjxm1221.top grok`：20/insufficient，低置信，4 次尝试、3 次失败，3 次 failover 均无候选；虽然样本少，但失败模式明确。
+- `lyon9801 0.10`、`https://sub.yjxm1221.top pro 0.06`、`https://api.recurdream.com plus 0.02` 在商业池等账号本窗口无流量，保持 insufficient，不伪造评分。
+- `https://api.lwylink.xyz pro 0.1` 与 `https://api.lwylink.xyz plus 0.05` 当前均因余额不足 403 不可用；两个 OpenAI 分组均为 8/10 可用。
+
+## 结论与建议
+
+1. 当前不是 Sub2API 总并发问题：全局查询时使用量分别为 11/225、10/225、0/10，排队均为 0；不建议以降低并发作为主修复。
+2. 商业池最大错误源是超上下文请求被包装成 502。应优先调查 Sub2API 的 Anthropic 兼容错误映射，把确定的输入/上下文错误转换为明确 4xx；不要给账号加临时不可调度，也不要靠切号掩盖客户输入问题。
+3. Grok 是当前真实可靠性短板。单账号结构使 failover 必然失败；源头方案是增加独立可用候选或在没有候选时快速、明确降级。仅增加冷却规则会减少重复撞击，但不能恢复请求。
+4. 自用池的上游 5xx 已被切号吸收，但 2 个流式 degraded 仍需继续观察；账号 27 的 540 秒 TTFT 极端值应在后续窗口确认是否复现，再决定是否调整 priority，不能凭单个最大值自动降级。
+5. 评分上，账号 32、33 最稳定；账号 31 在自用池表现优良，商业池 B 级主要受客户上下文错误污染；账号 27 可靠性尚可但时延长尾最明显；Grok 账号需要优先补冗余。
@@ -0,0 +1,41 @@
+# R2.6.10 任务报告
+
+## 结论
+
+若 2026-08 不再采购固定账号 `lyon9801 0.0`，售价保持 `0.15 CNY per API USD`，并且营业流量维持当前日均，预计可以盈利。按其他活跃账号实际加权平均边际成本接管 lyon 流量，预计盈利池利润约 `1442.93 CNY/月`；扣除自用成本后的整体利润约 `1051.71 CNY/月`。
+
+## 数据口径
+
+- 快照截至 2026-07-15 02:06 UTC，来源为 PK01 Sub2API 原生 admin usage，共 20 次分页读取。
+- 当前日均线性外推至 31 天；预计盈利池标准 API 计费基数约 `11650.914122 API USD`，售价 `0.15 CNY per API USD`，营业额 `1747.637118 CNY`。
+- 下月不计 `lyon9801 0.0` 的 `1300 CNY` 固定成本，也不假设 lyon 继续以零边际成本承接流量。
+- 当前 lyon 在盈利池占 `24.5497%`，在自用池占 `19.0978%`。
+
+## 替代成本
+
+- 非 lyon 盈利池账号当前加权平均采购倍率：`0.026153228 CNY per API USD`。
+- 非 lyon 自用池账号当前加权平均采购倍率：`0.031014832 CNY per API USD`。
+- lyon 盈利池流量按该平均倍率替代，预计新增采购成本 `74.805089 CNY/月`。
+- lyon 自用流量按该平均倍率替代，预计新增采购成本 `74.713171 CNY/月`。
+- 替代后盈利池总采购成本约 `304.709018 CNY/月`；自用总采购成本约 `391.213866 CNY/月`。
+
+## 利润情景
+
+- 只删除固定成本、仍假设 lyon 流量零边际成本的理论上限：不扣自用 `1517.733190 CNY`，扣自用 `1201.232495 CNY`。
+- 按其他账号当前加权平均成本接管的现实预测：不扣自用 `1442.928101 CNY`，扣自用 `1051.714235 CNY`。
+- 若 lyon 流量都能由 `0.01` 倍率账号承接：不扣自用 `1489.130568 CNY`，扣自用 `1148.540377 CNY`。
+- 若 lyon 流量只能由 `0.06` 倍率账号承接：不扣自用 `1346.117462 CNY`，扣自用 `885.079784 CNY`。
+
+## 日均现实预测
+
+- 营业额：约 `56.38 CNY/天`。
+- 盈利池采购成本：约 `9.83 CNY/天`。
+- 自用采购成本：约 `12.62 CNY/天`。
+- 不扣自用利润：约 `46.55 CNY/天`。
+- 扣自用利润：约 `33.93 CNY/天`。
+
+## 风险
+
+移除 lyon 后，其他盈利池账号需多承接约 `32.54%` 流量，自用池其他账号需多承接约 `23.61%`，合计非 lyon 账号负载约增加 `27.74%`。财务预测成立的前提是剩余账号具有该容量，且错误率、重试和客户流失不恶化；本报告未把可靠性下降造成的收入损失货币化。因此建议将 `1051.71 CNY/月` 视为当前流水不变时的中心估计，而非保证值。
+
+本次仅只读评估，未修改账号、YAML、runtime、Sub2API 或外部哨兵。
@@ -0,0 +1,23 @@
+# R2.6.11 任务报告
+
+## 交付
+
+- 已通过 [PR #2087](https://github.com/pikasTech/unidesk/pull/2087) 合并到 `master`，合并提交 `062faeb81f680728d08cd4eabef01f5e3fdf5372`。
+- `profit` 新增 `--sale-rate <CNY/API_USD>`，只覆盖本次只读候选售价，不修改 YAML。
+- `profit` 新增可重复的 `--scenario-without-account <id-or-exact-name>`，使用精确账号 ID 或完整名称模拟账号退出。
+- 情景在同一次 Sub2API 原生 usage 聚合中自动移除选中账号绑定的期间成本，并把其盈利池和自用池流量分别按各自剩余账号的实际加权采购倍率重分配。
+- 默认 Kubernetes 风格汇总和显式 JSON 直接披露理论利润上限、重分配利润、日均营业额与成本、账号流量占比、替代成本和剩余账号负载增幅，不再需要 `--accounts` 分页及手工算术。
+- selector 不存在时失败；剩余账号有未知成本、没有替代计费基数或仍有未分类流量时输出 `partial`，不把未知成本当作零。
+- Sub2API skill 描述和 `references/codex-pool.md` 已同步通用入口、计算语义与容量风险边界；核心代码和文档入口未固化具体账号、月份或售价。
+
+## 验证
+
+- PK01 真实只读命令一次返回 `status=complete`、两种利润、日均值、两池账号占比和负载增幅：`profit --month 2026-07 --forecast --sale-rate 0.15 --scenario-without-account 'lyon9801 0.0'`。
+- 显式 `--json` 保留精确十进制、完整账号名称、替代成本和负载增幅。
+- 非法 `--sale-rate -1` 在发起远端请求前明确拒绝。
+- `quick_validate.py .agents/skills/unidesk-sub2api` 通过。
+- `git diff --check` 通过。
+
+## 边界
+
+本次只修改 UniDesk CLI 与 skill 文档；未修改 Sub2API 源码、版本、YAML、runtime、外部哨兵或线上账号。
@@ -0,0 +1,43 @@
+# R2.6.12 任务报告
+
+## 综合结论
+
+- 本月 `lyon9801 0.0` 的 `1300 CNY` 已经发生，属于沉没成本；本月应继续保持高利用率，优先消耗其零边际成本能力，不建议提前停用。
+- 下月默认不续固定号。按当前流量和其他账号实际加权成本接管，售价 `0.15 CNY/API USD` 时预计不扣自用利润 `1447.41 CNY/月`，扣自用利润 `1055.78 CNY/月`。
+- 即使售价仍为 YAML 当前 `0.10 CNY/API USD`，不续固定号后预计不扣自用利润 `863.06 CNY/月`，扣自用利润 `471.44 CNY/月`，仍为正。
+
+## 固定号经济性
+
+- 当前 lyon 流量份额只避免约 `150.35 CNY/月`替代采购成本，远低于 `1300 CNY`固定费；在当前份额下，相关流量需约增长 `8.65` 倍才覆盖固定费。
+- 即使现有盈利池和自用池全部由 lyon 承接，按当前其他账号成本最多避免约 `697.25 CNY/月`采购成本，仍低于固定费；总流量需约增长 `1.86` 倍且 lyon 能承接全部流量，才接近纯成本保本。
+- 当前流量下合理续费上限：保持当前份额约 `150 CNY/月`；若能稳定承接全部现有两池流量，理论上限约 `700 CNY/月`。`1300 CNY/月`不具备纯财务合理性。
+- 保留 lyon 相对不续的月度增量代价约为：不扣自用 `1224.78 CNY`，扣自用 `1149.65 CNY`。只有其可靠性预计能避免超过约 `1150 CNY/月`的客户流失、补偿、故障和支持成本时，续费才可能合理。
+
+## 售价建议
+
+- 财务转正不依赖把售价从 `0.10`提高到 `0.15`；不续固定号后，两个售价下均盈利。
+- `0.15`相较 `0.10`把扣自用利润从约 `471.44 CNY`提高到约 `1055.78 CNY`，增加约 `584.34 CNY/月`安全垫。
+- 建议把 `0.15`作为新销售或可调整套餐的目标核算价；存量客户是否调整应结合市场、承诺和流失风险，不应仅凭成本立即统一涨价。
+- YAML 当前 `saleRateCnyPerApiUsd` 仍为 `0.10`；本轮 `0.15`只是只读情景，不代表实际售价已变更。
+
+## 容量与可靠性
+
+- 移除 lyon 后，盈利池其他账号需增加约 `32.64%`负载，自用池其他账号需增加约 `23.77%`，因此不能只看利润直接切除。
+- 续费决策前应使用 Sub2API 原生账号级评分、客户可见错误、普通请求与压缩请求 TTFT、并发限制和 failover 成功率，确认剩余账号能承接增量。
+- 不默认使用外部哨兵；如需运行时试切或调整 priority，必须另获明确授权，并继续使用官方 runtime 能力和受控 CLI。
+- 优先级原则应为“质量达标后按边际成本排序”：稳定的 `0.01`/`0.02`账号优先，质量合格的 `0.03`账号承担主力与冗余，`0.05`/`0.06`账号作为容量和故障兜底；不得在没有最新评分时仅按账号名称直接批量调整。
+
+## 自用成本
+
+- 不续固定号后的自用采购成本预计约 `391.62 CNY/月`，应作为独立预算披露，不用盈利池利润掩盖。
+- 建议日常同时观察“不扣自用”和“扣自用”两种口径：前者判断销售业务，后者判断整体现金收益。
+
+## 建议执行顺序
+
+1. 本月继续充分使用已付费 lyon，不提前退场。
+2. 月末前用原生账号级指标确认剩余账号容量和质量，不做未经授权的试切。
+3. 下月默认不续；只有报价降至约 `700 CNY/月`以内，或流量与可量化可靠性价值显著提升时重新评估。
+4. 新销售按 `0.15`核算，存量价格单独评估。
+5. 不续后持续观察客户可见错误、TTFT、重试与切号成功率；若可靠性损失接近约 `1150 CNY/月`，再评估固定直连账号或其他高质量容量方案。
+
+本任务只形成运营建议，未修改 YAML、runtime、Sub2API、外部哨兵、账号或售价。
@@ -1,4 +1,4 @@
-# R2.2.33 任务报告
+# R2.6.1 任务报告

 ## 结果

@@ -1,4 +1,4 @@
-# R2.2.34 任务报告
+# R2.6.2 任务报告

 ## 修正结论

@@ -1,4 +1,4 @@
-# R2.2.35 任务报告
+# R2.6.3 任务报告

 ## 结论

@@ -1,4 +1,4 @@
-# R2.2.36 任务报告
+# R2.6.4 任务报告

 ## 交付

@@ -0,0 +1,6 @@
+# R2.6.5 任务报告
+
+- owning YAML 增加 `2026-07` 的 lyon9801 一次性期间成本 1300 CNY；账号流量边际倍率改为 0.0。
+- 利润 CLI 增加 `--month YYYY-MM`，使用 Sub2API 原生 `/api/v1/admin/usage/stats` 按分组和账号聚合，约 8 秒完成；短时 `--since` 保留逐条 usage 精确窗口。
+- 账号 15 已通过 runtime CRUD 从 `lyon9801 0.10` 改为 `lyon9801 0.0`，全局 priority 从 20 调为 1，写后自动回读均 reconciled。
+- 7 月至今：收入 525.078160 CNY，盈利池流量成本 103.817293 CNY，自用流量成本 142.692022 CNY，期间成本 1300 CNY；不扣自用净利润 -878.739133 CNY，扣自用净利润 -1021.431155 CNY。
@@ -0,0 +1,5 @@
+# R2.6.6 任务报告
+
+- 利润 CLI 增加 `--month YYYY-MM --forecast`，按月初至当前实际秒数线性外推收入、盈利池流量成本和自用流量成本；一次性期间成本只扣一次。
+- 2026-07 实测缩放系数 2.20319165：预计整月收入 1157.554135 CNY，盈利池流量成本 228.743080 CNY，自用流量成本 315.207563 CNY，一次性成本 1300 CNY。
+- 预计整月不扣自用利润 -371.188945 CNY，扣除自用利润 -686.396508 CNY。该结果是 run-rate 预测，不是已实现收益。
@@ -0,0 +1,42 @@
+# R2.6.7 任务报告
+
+## 结论
+
+亏损的决定性原因不是 `lyon9801 0.0` 占比过低，而是当前整月销售流水不足以覆盖其 `1300 CNY` 月度一次性成本。提高 lyon 占比可以降低其他账号边际成本，但在当前收入规模下不能单独扭亏。
+
+## 数据口径
+
+- 统计月：2026-07，截至 2026-07-15 01:53 UTC，按月内流水线性外推，缩放系数 `2.20184522`。
+- 整月预计收入：`1159.137600 CNY`。
+- 盈利池流量成本：`228.951233 CNY`。
+- 自用池流量成本：`316.145204 CNY`。
+- `lyon9801 0.0` 一次性成本：`1300 CNY`，边际成本按 `0.0` 计算。
+- 不扣自用预计利润：`-369.813633 CNY`。
+- 扣除自用预计利润：`-685.958837 CNY`。
+
+## lyon9801 占比与价值
+
+- 盈利池月初至今标准 API 美元计费基数合计 `5264.391840 USD`，其中 `lyon9801 0.0` 为 `1291.868865 USD`，占 `24.54%`。
+- 自用池月初至今标准 API 美元计费基数合计 `5719.246077 USD`，其中 `lyon9801 0.0` 为 `1092.319869 USD`，占 `19.10%`。
+- lyon 盈利池整月预计收入贡献约 `284.45 CNY`，只覆盖固定成本的 `21.9%`。
+- 按其他自用账号平均边际成本估算，lyon 在自用池整月约避免 `74.64 CNY` 采购成本；收入贡献与避免成本合计约 `359.09 CNY`，只覆盖固定成本的 `27.6%`。
+
+## 亏损归因
+
+1. 固定成本是决定性约束。即使盈利池和自用池全部由零边际成本的 lyon 承接，整月收入仍只有 `1159.14 CNY`，理论最好利润为 `1159.14 - 1300 = -140.86 CNY`。
+2. 盈利池其他账号边际成本扩大亏损。当前 `228.95 CNY` 盈利池流量成本使不扣自用亏损从理论最低 `-140.86 CNY` 扩大到 `-369.81 CNY`。
+3. 自用池成本进一步扩大管理口径亏损。当前 `316.15 CNY` 自用成本使扣自用亏损达到 `-685.96 CNY`。
+4. lyon 占比有提升空间，但不是根因。当前盈利池占比 `24.54%` 不算低；即使提升至 `100%`，最多消除现有盈利池边际成本，仍亏 `140.86 CNY`。
+
+## 盈亏平衡
+
+- 理想零边际成本：整月收入至少达到 `1300 CNY`，比当前预测增加约 `12.15%`。
+- 保持当前盈利池成本率且不扣自用：整月收入约需 `1619.98 CNY`，比当前预测增加约 `39.76%`。
+- 保持当前成本结构并扣除自用：整月收入约需 `2013.93 CNY`，比当前预测增加约 `73.74%`。
+
+## 建议
+
+- 保持 `lyon9801 0.0` 的高优先级，让新增盈利池流量优先落到该账号，以降低边际成本；不应把提高占比误判为足以单独扭亏。
+- 首要经营目标应是增加盈利池销售流水：理想状态至少增长 `12.2%`，按当前账号组合更实际的保本目标约为增长 `40%`。
+- 自用池单独核算预算和成本，不用盈利池收入掩盖自用消耗；扣自用口径用于整体现金成本，不扣自用口径用于盈利池经营判断。
+- 本次仅只读分析，未修改 runtime、Sub2API 源码、版本或外部哨兵。
@@ -0,0 +1,24 @@
+# R2.6.8 任务报告
+
+## 口径
+
+沿用 R2.6.7 截至 2026-07-15 01:53 UTC 的 2026-07 整月线性预测：盈利池标准 API 美元计费基数 `11591.376000 USD`，盈利池流量成本 `228.951233 CNY`，自用流量成本 `316.145204 CNY`，`lyon9801 0.0` 本月一次性成本 `1300 CNY`。售价按 `0.15 CNY per API USD` 计算，不做汇率换算。
+
+## 结果
+
+- 整月预计收入：`1738.706400 CNY`。
+- 不扣自用预计利润：`1738.706400 - 228.951233 - 1300 = 209.755167 CNY`。
+- 扣除自用预计利润：`209.755167 - 316.145204 = -106.390037 CNY`。
+- 相比售价 `0.10`，两种利润口径均改善 `579.568800 CNY`。
+- 若盈利池和自用池全部由零边际成本的 `lyon9801 0.0` 承接，理论利润为 `438.706400 CNY`。
+
+## 保本售价
+
+- 保持当前盈利池账号组合、不扣自用：约 `0.131904 CNY per API USD`。
+- 保持当前账号组合并覆盖自用成本：约 `0.159178 CNY per API USD`。
+
+## 判断
+
+售价 `0.15` 足以使盈利池经营口径转正，预计利润约 `209.76 CNY`；但不足以同时覆盖当前自用池成本，整体现金成本口径仍预计亏损约 `106.39 CNY`。提高 `lyon9801 0.0` 占比会继续改善结果：若边际成本充分降至零，`0.15` 售价下理论利润可达约 `438.71 CNY`。
+
+本次只读计算，未修改 YAML、runtime、Sub2API 源码、版本或外部哨兵。
@@ -0,0 +1,34 @@
+# R2.6.9 任务报告
+
+## 新鲜快照
+
+使用最新 `origin/master` 的利润 CLI，从 PK01 Sub2API 原生 `/api/v1/admin/usage/stats` 拉取 20 次分页查询。统计窗口为 2026-07-01 00:00 UTC 至 2026-07-15 02:01:35 UTC，实际已过 `14.084440241` 天；盈利池计费基数 `5282.65742955 API USD`，盈利池采购成本 `104.2007966605 CNY`，自用采购成本 `143.759478531 CNY`。缺失成本账号和未分类流量均为零。
+
+售价按 `0.15 CNY per API USD` 重算；`lyon9801 0.0` 的 `1300 CNY` 是本月一次性成本，日均仅用于利润摊销，不代表每天发生现金支出。
+
+## 实际日均与整月日均
+
+线性外推不会改变日均值：实际已过时长计算和整月预测除以 31 天结果一致。
+
+- 每日标准 API 计费基数：`375.070456 API USD`。
+- 每日营业额：`56.260568 CNY`。
+- 盈利池每日变动采购成本：`7.398292 CNY`。
+- 自用池每日变动采购成本：`10.206971 CNY`。
+- lyon 本月固定成本日均摊销：`41.935484 CNY`。
+- 不扣自用的每日总成本：`49.333776 CNY`，每日利润 `6.926793 CNY`。
+- 扣除自用的每日总成本：`59.540747 CNY`，每日利润 `-3.280178 CNY`。
+
+## 月度对应值
+
+- 整月预计营业额：`1744.077622 CNY`。
+- 盈利池变动成本：`229.347041 CNY`。
+- 自用变动成本：`316.416113 CNY`。
+- 固定成本：`1300 CNY`。
+- 不扣自用预计利润：`214.730581 CNY`。
+- 扣除自用预计利润：`-101.685532 CNY`。
+
+## 判断
+
+每日经营在固定成本前是正贡献：不扣自用时为 `48.862277 CNY/天`，扣自用时为 `38.655305 CNY/天`。前者高于固定成本日均摊销 `41.935484 CNY/天`，因此盈利池口径盈利；后者低于固定成本摊销，因此整体口径每天约亏 `3.28 CNY`。此前计算方向正确，新快照将整体预计亏损从约 `106.39 CNY` 更新为约 `101.69 CNY`。
+
+本次只读复核，未修改 YAML、runtime、Sub2API 或外部哨兵。
@@ -0,0 +1,3 @@
+# R2.6 成本与利润统计任务报告
+
+本分支汇总 YAML-first 利润 CLI、CNY per API USD 口径修正、最近 7 天统计和单次聚合优化。四项历史任务及报告均已迁入并保持完成状态。
@@ -0,0 +1,7 @@
+# R2.7.1 Sub2API 原生 Grok 接入 Codex 调查报告
+
+只读核查官方最新发布 `v0.1.155`、源码和相关 issue/PR。最新版本原生支持 `platform=grok`，账号类型包括 xAI OAuth 和 API Key；公开 `/v1/responses`、`/responses` 与 `/backend-api/codex/responses` 可服务 Codex Responses 请求。正确拓扑是 Codex 使用绑定 Grok 分组的 Sub2API API Key，由分组选择 Grok provider，再转发到 OAuth subscription proxy 或 xAI API。
+
+普通接入无需修改 Sub2API 源码。客户端应直接使用 `grok-4.5` 与 Responses wire API；只有消费端必须保留别名时才配置 `model_mapping`。不应把 Grok 伪装成 `platform=openai`，否则会绕过 Grok 专属 OAuth、身份头、请求净化、配额和监控逻辑。
+
+官方演进证据包括 Grok subscription PR #3310、Codex compatibility PR #3558、CLI identity issue #3952 与综合修复 PR #4009。任务未修改 runtime、YAML、代码或部署。
@@ -0,0 +1,41 @@
+# R2.7.2 Codex Grok profile 接入 Sub2API 报告
+
+## 结果
+
+已把 `/root/.codex/config.toml.grok` 调整为独立的 Sub2API Grok Responses provider：
+
+- `model_provider = "Sub2API_Grok"`
+- `model = "grok-4.5"`
+- `review_model = "grok-4.5"`
+- `model_reasoning_effort = "high"`
+- `base_url = "https://api.pikapython.com/v1"`
+- `wire_api = "responses"`
+- `requires_openai_auth = true`
+- `supports_websockets = false`
+
+`/root/.codex/auth.json.grok` 原本已经是 Codex 需要的 `OPENAI_API_KEY` 结构，且其中 Key 正是绑定 Sub2API Grok 分组的 Key，因此未替换密钥，只做结构、fingerprint 和权限验证。两个文件权限均保持 `0600`，未输出完整密钥。
+
+## 验证
+
+- TOML 解析成功，provider、模型、base URL 和 Responses transport 均符合预期。
+- JSON 解析成功，仅包含 `OPENAI_API_KEY`；验证前后 fingerprint 均为 `2d90208c41f3`。
+- 使用该 Key 请求 `https://api.pikapython.com/v1/models` 返回 HTTP 200，共 22 个 Grok 模型，包含 `grok-4.5`、`grok-4.3`、`grok-build-0.1` 和 Grok Composer，证明 Key 已绑定原生 Grok 分组。
+
+## 最小推理 smoke
+
+第一次 `grok-4.5` Responses smoke：
+
+- 最终 HTTP 502。
+- Sub2API request ID：`5fb6cb9f-5243-4f6a-a4c9-70a908b12a3e`。
+- 请求已进入 `grok` 分组和账号 `https://sub.yjxm1221.top grok`（账号 36）。
+- 上游返回 502 后触发 failover，但该分组只有一个账号，排除原账号后出现 `no available accounts`。
+
+第二次有界复测：
+
+- 最终 HTTP 503。
+- Sub2API request ID：`25064661-32e1-42ad-9ec3-84c154bf870e`。
+- trace 结论为 `account-select-failed`，6ms 内出现 `no available accounts`，说明前一次失败后当前 Grok 池无可调度候选。
+
+## 结论
+
+Codex profile、认证文件、Sub2API API Key 和 Grok 分组路由均已正确配置。当前不能完成成功推理验收的原因是 Grok 分组唯一上游账号返回 502 后没有第二候选，而不是本地配置或鉴权格式错误。没有为掩盖该问题继续盲目重试，也未修改 Sub2API runtime、分组或账号状态。
@@ -0,0 +1,36 @@
+# R2.7.3 Grok 账号测试与网关路径复核报告
+
+## 新证据
+
+用户在 Sub2API 管理端对 `https://sub.yjxm1221.top grok` 执行账号连接测试成功：账号类型为 API Key，模型为 `grok-4.5`，上游返回正常文本。这证明账号凭据、base URL 和最小 xAI Responses 请求可用。
+
+## 网关复测
+
+使用绑定 Grok 分组的 Sub2API Key，经公开 `/v1/responses` 复测：
+
+- 结构化 Codex 风格请求返回 502，请求 ID `86069838-2559-45a7-a683-8b029f03b447`。
+- 账号连接测试同形态的 `input:"hi" + stream:true` 请求，在调度恢复后仍返回 502，请求 ID `dfd99f91-52e4-4de9-bea9-d64a3e8e623b`。
+- 502 后 `v0.1.155` 会把 Grok 账号临时不可调度 2 分钟；期间请求返回 503 `no available accounts`。这解释了中间的 503，但不是首个 502 的根因。
+- 原生窗口显示账号 36 可恢复为 `AVAILABLE=true`，因此不是永久禁用或认证错误。
+
+## `v0.1.155` 源码路径差异
+
+管理端 `testGrokAccountConnection`：
+
+- 直接使用账号的 API Key 和 base URL。
+- 请求体固定为 `model + input:"hi" + stream:true`。
+- 不经过分组调度。
+- 不注入 Grok prompt-cache identity。
+
+公开 Grok gateway 的 `forwardGrokResponses`：
+
+- 先经过分组调度和模型映射。
+- 调用 `resolveGrokCacheIdentity`，按 Sub2API API Key、模型和请求内容生成租户隔离 identity。
+- 即使是 Grok API Key 账号，也会向 Responses body 写入 `prompt_cache_key`，并写入 `X-Grok-Conv-Id` header；只有 Free OAuth 专属工具注入受 `IsGrokOAuth()` 限制。
+- 第三方 base URL 因而收到的载荷不等同于管理端连接测试。
+
+## 结论
+
+“账号连接测试成功”与“Codex 经 Sub2API Grok 分组成功”并不矛盾。前者证明最小直连可用；后者当前稳定在上游账号 36 返回 502 后失败。根据 `v0.1.155` 源码，最值得优先验证的差异是公开网关为第三方 Grok API Key 上游增加的 `prompt_cache_key` / `X-Grok-Conv-Id` 及其他 Responses 净化，而不是本地 `config.toml.grok`、`auth.json.grok` 或账号凭据。
+
+本任务保持只读，没有修改账号、runtime、分组或 Sub2API 源码。当前 Codex profile 配置仍正确，但该第三方上游尚未通过真实 Codex 网关载荷验收。
@@ -0,0 +1,3 @@
+# R2.7 Grok 原生接入与 Codex 兼容任务报告
+
+本分支汇总官方 Grok provider 源码调查、`~/.codex` Grok profile 配置，以及管理端账号直连测试与公开 Responses 网关差异复核。三项任务均已形成独立报告；当前结论是本地 profile 和分组 Key 正确，第三方 Grok API Key 上游仍需验证对网关缓存 identity 与真实 Codex 载荷的兼容性。
@@ -0,0 +1,26 @@
+# R2.8 MDTODO 层级治理任务报告
+
+## Skill 规则
+
+已在通用 `mdtodo-edit` skill 中加入层级约束：同一个 SUBITEM 下的直接 SUBSUBITEM 一般不超过 20；接近上限时必须按稳定职责、阶段或交付面拆成兄弟 SUBITEM，禁止机械按每 20 条分桶；已超限时先重组层级和编号，并保留状态、语义与报告关联。
+
+## 文件重组
+
+将原 `R2.2.1-R2.2.38` 按职责重组：
+
+- `R2.2`：通用故障归因、failover、runtime CRUD 与临时不可调度，15 项。
+- `R2.3`：system-log 索引能力，保持原编号。
+- `R2.4`：客户反馈、专项事件与原生诊断，9 项。
+- `R2.5`：版本、账号质量评分、用量归因和调度优先级，8 项。
+- `R2.6`：成本与利润统计，4 项。
+- `R2.7`：Grok 原生接入与 Codex 兼容，3 项。
+
+已迁移并重新编号历史报告，保留完成/进行中状态；原进行中的账号质量聚合和 runtime priority CLI 分别迁为 `R2.5.3` 与 `R2.5.6`。已消除并行 stash 遗留的冲突标记和重复 `R2.2.37`，为官方 Grok 调查、Codex profile 配置和网关复核分配独立编号与报告。
+
+## 验证
+
+- `mdtodo-edit` skill 通过 `quick_validate.py`。
+- MDTODO 无重复 ID、无 Git 冲突标记。
+- 直接 SUBSUBITEM 数量为 `R2.2=15`、`R2.4=9`、`R2.5=8`、`R2.6=4`、`R2.7=3`。
+- 没有职责分支超过 20。
+- 已完成任务的报告链接均存在；仍进行中的父任务允许尚无总结报告。
@@ -0,0 +1,22 @@
+# R2.9 任务报告
+
+## 范围
+
+通过 PK01 Sub2API 受控 CLI 调整手工 runtime 账号 ID `33` 的人类可读成本标注与账号全局优先级；未修改 Sub2API 源码、版本、YAML 管理范围或外部哨兵。
+
+## 近期证据
+
+近 24 小时原生账号聚合：账号原名称 `https://api.iceiu.com plus 0.03`，尝试 `1039`、成功 `1030`、失败 `9`，可归因上游客户错误 `6`，失败率 `0.87%`；评分 `90.3/A`、置信度 high，TTFT P95 `58247ms`、样本 `915`；请求 `1030`、Token `3.512M`、标准 API 计费基数 `103.3889 USD`。账号当时 active、schedulable，容量 `20`，优先级 `5`。
+
+## 决策与执行
+
+新采购成本为每 1 USD 标准 API 计费对应 `0.011 CNY`。考虑其 A 级可靠性、成本显著低于 0.03 档但 TTFT 慢于最优账号，将优先级从 `5` 适度提高到 `2`，保留在免费账号优先级 `1` 之后。
+
+- account-name dry-run：精确命中 ID `33`，仅名称从 `https://api.iceiu.com plus 0.03` 变为 `https://api.iceiu.com plus 0.011`。
+- priority dry-run：精确命中 ID `33`，仅优先级从 `5` 变为 `2`。
+- 两项 confirm 均 `writeSucceeded=1`、`writeFailed=0`、`reconciled=1`、`mismatched=0`。
+- 最终只读快照：名称 `https://api.iceiu.com plus 0.011`，优先级 `2`，active、schedulable=true，proxy `3`，容量 `20`，原临时不可调度模板保持不变。
+
+## 结论
+
+成本标注与优先级已按近期质量和成本完成精准 runtime 调优，最终状态与期望一致。
@@ -0,0 +1,36 @@
+# R3.1 任务报告
+
+## 结果
+
+- PK01 Sub2API 原生最近 24 小时 usage 选中 17 名活跃非管理员用户。
+- 每人计划增加 `10 USD`，计划总额 `170 USD`。
+- 模式为 `dry-run`，`mutation=false`。
+- `writeAttempted=0`、`writeSucceeded=0`、`writeFailed=0`、`reconciled=0`，没有实际充值。
+
+## 用户名单
+
+| 邮箱 | 用户 ID | 请求数 | 当前余额 USD | 计划余额 USD |
+|---|---:|---:|---:|---:|
+| Bernard@test.com | 23 | 2 | 99.96938600 | 109.96938600 |
+| MacRsh@test.com | 11 | 341 | 42.92200430 | 52.92200430 |
+| darrendreamc@163.com | 13 | 182 | 30.52278440 | 40.52278440 |
+| huiguo@test.com | 15 | 472 | 56.49675000 | 66.49675000 |
+| hyglql@test.com | 10 | 935 | 546.01330750 | 556.01330750 |
+| laogen@test.com | 7 | 1678 | 370.04147180 | 380.04147180 |
+| mail0795336304@163.com | 22 | 227 | 662.40832140 | 672.40832140 |
+| miuser@test.com | 21 | 54 | 688.02232555 | 698.02232555 |
+| name@test.com | 9 | 274 | 421.88935290 | 431.88935290 |
+| phuohuo163@outlook.com | 20 | 248 | 565.16767640 | 575.16767640 |
+| ren@test.com | 3 | 155 | 201.19074850 | 211.19074850 |
+| ric@test.com | 4 | 23 | 42.35029270 | 52.35029270 |
+| skylin008@gmail.com | 17 | 68 | 245.71857260 | 255.71857260 |
+| wenrui@test.com | 5 | 68 | 30.73914185 | 40.73914185 |
+| xiaoyang@test.com | 2 | 2012 | 5413.81344685 | 5423.81344685 |
+| yinl0801@qq.com | 19 | 483 | 851.18146340 | 861.18146340 |
+| zhuo@test.com | 16 | 89 | 149.21926750 | 159.21926750 |
+
+## 精确确认名单
+
+用户 ID：`23,11,13,15,10,7,22,21,9,20,3,4,17,5,2,19,16`。
+
+该名单仅用于后续明确授权时固定选择范围。本任务未使用 `--confirm`，不得把本报告解释为实际充值授权或完成记录。
@@ -0,0 +1,44 @@
+# R3.2 任务报告
+
+## 结果
+
+- 已通过 [Issue #2097](https://github.com/pikasTech/unidesk/issues/2097) 和 [PR #2102](https://github.com/pikasTech/unidesk/pull/2102) 增加 Sub2API 原生公告受控 CLI。
+- PR 已合并到 `master`，merge commit 为 `43f34ccfe82c3be55b731d0e5c7e416de1bcccb5`。
+- CLI 支持公告 `list`、`get`、`create`：默认 Kubernetes 风格紧凑文本，显式 `--json` 输出机器结构。
+- `create` 支持标题、Markdown 正文、状态、通知模式、原生 targeting 以及 Unix 秒或 RFC3339 时间窗。
+- `create` 默认 dry-run；只有显式 `--confirm` 才调用原生创建 API。
+- 确认创建后的回读对账覆盖 ID、`title`、`content`、`status`、`notify_mode`、`targeting`、`starts_at` 和 `ends_at`；任一差异均返回失败并披露 `mismatchedFields`。
+
+## 原生能力依据
+
+- Sub2API 官方仓库 `Wei-Shaw/sub2api` 的 `v0.1.155` 原生提供 `/api/v1/admin/announcements`。
+- 原生后端支持分页列表、按 ID 查看、创建、更新、删除和阅读状态；本次按授权范围接入列表、查看和受控创建。
+- 未修改 Sub2API 源码、版本、外部哨兵或运行面配置。
+
+## 补偿公告预览
+
+- 标题：`服务稳定性补偿说明`。
+- 内容语义：计划向最近 24 小时有实际使用记录的 17 名活跃用户每人增加 10 USD，总计 170 USD，确认后发放。
+- 文案使用“计划”和“确认后发放”，没有表述为已经到账。
+- dry-run 返回 `mutation=false`、`writeAttempted=0`，完整预览正确。
+- PK01 原生公告列表只读验证返回 `mode=read-only`、`mutation=false`、`total=0`、`returned=0`。
+
+## 验证
+
+- scoped CLI help 通过。
+- 显式 JSON dry-run 输出合同通过。
+- 字段级对账纯内存 fixture 通过：全匹配无差异，多字段差异和 ID 差异均准确披露；`network=false`。
+- `git diff --check` 通过。
+- 子代理交付 commit：`2ab5fb87a2693ad6076e3abdeb3801c74269be69`。
+- 主代理纠偏 commit：`2c0cf9479197a37728a3c697da230fb9e7ce28de`。
+
+## 写入边界
+
+- 本轮没有使用 `--confirm`。
+- 公告发布数为 0。
+- 充值写入数为 0。
+- 实际公告发布和每人 10 USD 充值仍需用户对具体公告参数及固定用户名单再次明确授权。
+
+## 后续改进
+
+- post-task 已登记 [Issue #2106](https://github.com/pikasTech/unidesk/issues/2106)，用于改进 `platform-infra` 深层 scoped help 的渐进披露，减少后续无效调用；不作为本任务合并门禁。
@@ -0,0 +1,37 @@
+# R3.3 任务报告
+
+## 结果
+
+通过 Sub2API 受控 CLI 精确查询了北京时间 `2026-07-14 17:00:00` 至 `18:00:00` 的活跃非管理员用户。该窗口按 `Asia/Shanghai` 转换为 UTC `2026-07-14T09:00:00Z` 至 `2026-07-14T10:00:00Z`，使用半开区间 `[start,end)`。
+
+共选中 7 名用户：
+
+| 邮箱 | 用户 ID | 请求数 |
+|---|---:|---:|
+| MacRsh@test.com | 11 | 1 |
+| huiguo@test.com | 15 | 31 |
+| hyglql@test.com | 10 | 126 |
+| laogen@test.com | 7 | 158 |
+| mail0795336304@163.com | 22 | 26 |
+| yinl0801@qq.com | 19 | 3 |
+| zhuo@test.com | 16 | 35 |
+
+## CLI 改进
+
+- owning YAML `config/platform-infra/sub2api-codex-pool.yaml#credits.timezone` 新增默认时区 `Asia/Shanghai`。
+- `credits grant` 新增通用 `--active-start/--active-end` 精确时间窗。
+- 未带偏移的 ISO 时间由 CLI 按 YAML IANA 时区换算为 UTC；本地与 UTC 边界同时披露。
+- 远端继续使用 Sub2API 原生 admin usage 和用户 API，并按 UTC 半开区间逐条过滤。
+- PK01 旧 Python 缺少 `zoneinfo`，因此时区换算在 Bun/Intl 控制面完成，远端只接收已验证 UTC 边界。
+
+实现通过 [PR #2117](https://github.com/pikasTech/unidesk/pull/2117) 合并，merge commit 为 `7b43da1ab842183d36476e174e17fb7f45891b57`。
+
+## 验证
+
+- `bun --check scripts/src/platform-infra-sub2api-codex/credits.ts`：通过。
+- `bun --check scripts/src/platform-infra-sub2api-codex/config.ts`：通过。
+- `git diff --check`：通过。
+- PK01 原入口 dry-run：`ok=true`、`selection=active-window`、`selected=7`。
+- 写入证据：`mutation=false`、`writeAttempted=0`、`writeSucceeded=0`。
+
+没有执行充值，没有修改 Sub2API 源码、版本、哨兵或运行面配置。
@@ -0,0 +1,30 @@
+# R3.4 任务报告
+
+## 结果
+
+在 `config/platform-infra/sub2api-codex-pool.yaml#credits.excludedUsers` 中加入：
+
+- `zhuo@test.com`
+- `huiguo@test.com`
+
+排除列表是通用精确 selector 配置，支持用户 ID 或邮箱，邮箱按大小写不敏感匹配。活跃时间窗与显式 `--users` 模式均在生成补偿计划和确认 selector 前应用该列表。
+
+## CLI 可见性
+
+默认 Kubernetes 风格输出新增 `EXCLUDED` 表格，披露邮箱、用户 ID、窗口请求数、`yaml-excluded-user` 原因和匹配 selector。汇总首行同时披露 `selected` 与 `excluded`。全部候选被排除时显示 `--users <none>`，不再给出可执行的空确认提示。
+
+## 验证
+
+- Bun 语法检查和 `git diff --check` 通过。
+- 北京时间 `2026-07-14 17:00:00` 至 `18:00:00` 固定窗口 dry-run：
+  - `selected=5`；
+  - `huiguo@test.com` 请求数 31，按 YAML 排除；
+  - `zhuo@test.com` 请求数 35，按 YAML 排除；
+  - `mutation=false`、`writeAttempted=0`。
+- 显式 `--users 15,16` dry-run：
+  - `selected=0`、`excluded=2`、`total-usd=0`；
+  - `mutation=false`、`writeAttempted=0`。
+
+实现通过 [PR #2119](https://github.com/pikasTech/unidesk/pull/2119) 合并，merge commit 为 `7920322030270a49164d78971dae2f0a6454997c`。
+
+没有执行充值，没有修改 Sub2API 源码、版本、哨兵或运行面。
@@ -0,0 +1,30 @@
+# R3.5 任务报告
+
+## 查询窗口
+
+- 本地时间：`2026-07-14 17:00:00` 至 `18:00:00 Asia/Shanghai`。
+- UTC：`2026-07-14T09:00:00Z` 至 `10:00:00Z`。
+- 区间：半开区间 `[start,end)`。
+- 数据源：Sub2API 原生 `/api/v1/admin/usage` 的 `input_tokens`、`output_tokens`。
+- 所有 1,267 条 usage 的 Token 字段覆盖均为 `complete`。
+
+## 用户用量
+
+| 用户 | ID | 分类 | 请求数 | 输入 Token | 输出 Token | 总 Token |
+|---|---:|---|---:|---:|---:|---:|
+| MacRsh@test.com | 11 | 补偿候选 | 1 | 506 | 12,309 | 12,815 |
+| hyglql@test.com | 10 | 补偿候选 | 126 | 593,470 | 187,782 | 781,252 |
+| laogen@test.com | 7 | 补偿候选 | 158 | 1,608,741 | 180,207 | 1,788,948 |
+| mail0795336304@163.com | 22 | 补偿候选 | 26 | 29,735 | 21,641 | 51,376 |
+| yinl0801@qq.com | 19 | 补偿候选 | 3 | 52,270 | 3,396 | 55,666 |
+| huiguo@test.com | 15 | YAML 排除员工 | 31 | 61,069 | 30,623 | 91,692 |
+| zhuo@test.com | 16 | YAML 排除员工 | 35 | 701,758 | 26,110 | 727,868 |
+| admin@sub2api.platform-infra.local | 1 | 管理员排除 | 887 | 2,327,308 | 706,151 | 3,033,459 |
+
+## CLI 改进
+
+credits 固定窗口现在按用户聚合请求数、输入 Token、输出 Token、总 Token，以及 Token 字段覆盖行和缺失行。缺失字段会标记 `partial`，精确用户模式没有 usage 窗口时标记 `unavailable`。原有角色、状态、余额和对账列保持不变。
+
+实现通过 [PR #2122](https://github.com/pikasTech/unidesk/pull/2122) 合并，merge commit 为 `2add8477e4ea95070e896a66b29769ad1597f9bf`。
+
+查询为 dry-run：`mutation=false`、`writeAttempted=0`，没有执行充值。
@@ -0,0 +1,46 @@
+# R3.6 任务报告
+
+## 执行范围
+
+按用户明确授权，仅对固定用户 ID `11,10,7,22,19` 每人增加 `30 USD`，总额 `150 USD`；并发发布服务稳定性补偿公告。未使用移动活跃窗口，未包含 YAML 排除员工、管理员或其他用户。
+
+## 充值结果
+
+受控入口：`platform-infra sub2api codex-pool credits grant`，目标 `PK01`，显式 `--confirm`。
+
+- selected: 5
+- writeAttempted: 5
+- writeSucceeded: 5
+- writeFailed: 0
+- reconciled: 5
+- mutation: true
+
+| 用户 | ID | 充值前 | 增加 | 充值后 | 对账 |
+|---|---:|---:|---:|---:|---|
+| MacRsh@test.com | 11 | 42.92200430 USD | 30 USD | 72.92200430 USD | true |
+| hyglql@test.com | 10 | 542.68010850 USD | 30 USD | 572.68010850 USD | true |
+| laogen@test.com | 7 | 349.15434580 USD | 30 USD | 379.15434580 USD | true |
+| mail0795336304@163.com | 22 | 662.40832140 USD | 30 USD | 692.40832140 USD | true |
+| yinl0801@qq.com | 19 | 841.79106140 USD | 30 USD | 871.79106140 USD | true |
+
+充值原因为 `2026-07-14 service stability compensation: 30 USD for five authorized active users`，批次使用受控 CLI 幂等键并逐用户回读余额。
+
+## 公告结果
+
+受控入口：`platform-infra sub2api codex-pool announcements create`，目标 `PK01`，显式 `--confirm`。
+
+- announcement ID: 1
+- status: active
+- notify mode: popup
+- targeting: 全体用户（空条件）
+- starts/ends: 无限制
+- writeAttempted: 1
+- mutation: true
+- reconciled: true
+- mismatchedFields: 空
+
+标题为“服务稳定性补偿说明”。正文说明符合本次补偿条件的用户已到账 `30 USD`。
+
+## 结论
+
+充值和公告两条并发操作均成功到达终态并通过 Sub2API 原生回读对账，无失败用户、无公告字段漂移、无范围扩大。
@@ -0,0 +1,7 @@
+# R3 任务报告
+
+- 新增受控 `credits grant`：支持 `--active-since` 选取原生 usage 中的活跃非管理员用户，也支持精确用户 ID/邮箱 selector；默认 dry-run。
+- 活跃窗口只允许生成计划；确认必须固定使用 dry-run 返回的精确用户 ID 列表，防止移动窗口改变名单。
+- 每个用户的余额 add 写入使用由精确名单、金额和原因生成的确定性 `Idempotency-Key`，随后逐用户回读余额。
+- 24 小时 dry-run 选中 18 个用户，每人拟增 20 USD，总额 360 USD；`writeAttempted=0`、`mutation=false`，未实际充值。确认 selector 为 `18,23,11,13,15,10,7,22,21,9,20,3,4,17,5,2,19,16`。
+- 单用户精确 selector dry-run 验证通过，移动活跃窗口带 `--confirm` 会在本地拒绝。实际充值必须等待用户对具体名单、金额和原因再次明确授权。
@@ -15,9 +15,9 @@

 增强 CLI 使用 Sub2API 原生 admin/ops 数据诊断请求错误、账号可用性、并发和 request trace，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.1_Task_Report.md)。

-### R2.2 [in_progress]
+### R2.2 [completed]

-在连续新窗口复核临时不可调度、failover、客户可见错误率和流式 degraded 请求，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.2_Task_Report.md)。
+集中跟踪 Sub2API 通用客户错误归因、failover、临时不可调度模板、runtime CRUD 和所有分组诊断能力，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.2_Task_Report.md)。

 #### R2.2.1 [completed]

@@ -69,73 +69,171 @@

 #### R2.2.16 [completed]

-紧急只读追踪用户 mail0795336304@163.com 反馈请求卡住15分钟：定位用户ID、近30分钟请求、当前长请求/并发、request ID、账号与模型，区分排队、上游首字、流式间隔、代理网络或客户连接，不取消请求且不修改runtime、YAML、proxy或调度，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.2.16_Task_Report.md)。
-#### R2.2.17 [completed]
-
-复盘用户直接反馈的只读追踪过程并交由 Artificer 实现 [Issue #2000](https://github.com/pikasTech/unidesk/issues/2000)：增加通用的一键用户追踪 CLI，以邮箱或用户ID关联请求空窗、用户/API Key并发、client/internal request ID、上游账号名称、proxy基础设施和证据化归因，采用Kubernetes列表风格与稳定ID渐进披露，减少手工API与重复trace调用，不改运行面，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.2.17_Task_Report.md)。
-#### R2.2.18 [completed]
-
-将 PK01 的 Sub2API 通过 owning YAML 从 v0.1.153 受控升级到 v0.1.155：只修改 PK01 target镜像版本，依次执行状态核对、plan、apply dry-run、镜像预拉、受控apply、状态与公开健康验证，保持账号池runtime和Codex pool配置原样，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.2.18_Task_Report.md)。
-#### R2.2.19 [completed]
-
-交由 Artificer 实现 [Issue #2004](https://github.com/pikasTech/unidesk/issues/2004)：增强 Sub2API CLI 拉取 v0.1.155 原生智能诊断与渠道监控状态，泛化所有分组/渠道概要和指定对象下钻，以Kubernetes列表风格呈现TTFT、上游与客户错误率、原生建议和证据边界，以及7/15/30天渠道运行状态、平台/模型、对话延迟、端点PING、可用率、最近记录和刷新事实，使用稳定ID渐进披露，不重算第二套诊断且不修改运行面，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.2.19_Task_Report.md)。
-
-#### R2.2.20 [completed]
-
-快速缓解错误 #17440：基于 request e5c08dde-9e60-4a14-9458-5574cec00b65 的真实链路，将精确短语 Input must be a list 补入通用 504 临时不可调度规则，对全部非 lyon9801 账号精准批量 dry-run、确认下发和自动回读对账，不改容量、优先级、代理或 Sub2API 源码，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.2.20_Task_Report.md)。
-#### R2.2.21 [completed]
-
-交由 Artificer 实现 [Issue #2013](https://github.com/pikasTech/unidesk/issues/2013)：定义并实现 Sub2API P0/P1/P2 故障快速查询 CLI，P0 为上游故障穿透客户，P1 为首字延迟偏高且普通与 compact 分开统计并突出极端离群，P2 为上游错误率偏高；支持所有分组概要与按等级、分组、账号名称、模型、请求类型、稳定 request ID 下钻，默认 Kubernetes 列表风格和固定分页，不靠手工 limit，不修改运行面，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.2.21_Task_Report.md)。
-
-#### R2.2.22 [completed]
-
-主代理只读追踪客户错误 #17490（request ID 4eb9a84b-7346-47a8-bb66-fb7b44317279）：使用 Sub2API 原生 Ops、trace、账号完整名称、failover/retry/临时不可调度和近期窗口证据，定位账号 https://sub2.pokexiao.com plus 0.03 的同步502为何穿透客户，区分候选耗尽、context取消、不可重试阶段或模板未命中；先调查，不盲目新增generic 502规则，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.2.22_Task_Report.md)。
-#### R2.2.23 [completed]
-
-交由 Artificer 实现 [Issue #2016](https://github.com/pikasTech/unidesk/issues/2016)：增强 CLI 对 Sub2API 内部账号/渠道监控的原生只读访问，展示探测 timeout、cadence、阶段耗时、账号选择、上游首字节、切号/重试和最终状态，支持所有监控对象概要与稳定 ID 下钻，默认 Kubernetes 列表风格且不靠手工 limit；不修改运行面、不发新探针，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.2.23_Task_Report.md)。
-#### R2.2.24 [completed]
-
-只读调查错误 #17511（request ID `f7ff0efe-64d3-4dd7-8716-20bdfc3a2f90`）为何上游 502 后未成功切号，重建流式请求的账号选择、首字节、响应提交、failover、排除列表、context deadline 与最终客户错误链，并与内部 monitor 请求 #17490 对照，不修改运行面，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.2.24_Task_Report.md)。
-#### R2.2.25 [completed]
-
-将 PK01 Sub2API 从 v0.1.155 受控回退到 v0.1.147：只修改 owning YAML 版本事实，在最新 master 的独立干净 worktree提交并通过受控 GitHub PR 合并，随后使用原 platform-infra Sub2API 交付入口完成 PK01 rollout，并核验实际镜像、版本、健康状态和原入口可用性，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.2.25_Task_Report.md)。
-#### R2.2.26 [completed]
-
-只读执行 PK01 Sub2API 最近4小时所有分组的上游账号质量评分：使用原生 Ops 账号请求量、客户/上游错误、切号、重试、临时不可调度、TTFT 和当前可用性，完整报告账号名称、评分、等级、置信度和扣分原因；兼容 v0.1.147，不修改 runtime、YAML 或调度配置，完成任务后将详细报告写入任务报告，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.2.26_Task_Report.md)。
-#### R2.2.27 [in_progress]
-
-交由 Artificer 实现 [Issue #2035](https://github.com/pikasTech/unidesk/issues/2035)：增强 Sub2API 最近窗口账号质量分析，在同一分组、同一账号、同一窗口的一张 Kubernetes 列表中聚合展示评分/等级/置信度/失败率/TTFT 与请求数/Token（M/B）/金额（$）；复用 v0.1.147 原生 admin usage 分页，JSON 保留精确值与来源，字段缺失不伪造为零，并修复 `--group <id>` 精确下钻错误，不修改运行面，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.2.27_Task_Report.md)。
-
-#### R2.2.28 [completed]
-
-只读核查 PK01 Sub2API 当前全部 OpenAI 上游账号的实际 priority、分组成员关系、可调度与可用状态，并结合最近4小时分组内评分、失败率、TTFT、Token和金额给出分层的推荐优先级调整方案；报告完整账号名称，区分立即建议、观察建议和证据不足，不直接修改 runtime、YAML或调度配置，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.2.28_Task_Report.md)。
-#### R2.2.29 [completed]
-
-按 R2.2.28 的最近4小时评分与用量结论，精准调整 PK01 Sub2API 账号全局 priority：只更新明确列出的 runtime-manual 账号，变更前全量预检、失败自动回滚、变更后批量回读对账；不修改分组、容量、代理、凭据、状态、可调度或临时不可调度规则，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.2.29_Task_Report.md)。
-#### R2.2.30 [in_progress]
-
-交由 Artificer 实现 [Issue #2037](https://github.com/pikasTech/unidesk/issues/2037)：为 Sub2API runtime 接入账号全局 priority 的单账号与精准批量 dry-run/confirm、所有 selector 预检、写后自动回读对账、所有权提示和 Kubernetes 列表/显式 JSON 输出；明确 lower-is-higher、没有分组优先级，兼容 v0.1.147，不自动调整评分、不部署或修改运行面，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.2.30_Task_Report.md)。
-#### R2.2.31 [completed]
-
-只读复核 PK01 Sub2API 全局 priority 调整生效后约25分钟的新窗口：按全部分组和完整账号名称统计请求量、流量份额、客户/上游错误、失败率、TTFT、切号、Token与原生金额，并将账号名称尾部0.02/0.025/0.03/0.05/0.06/0.1作为上游采购成本权重综合评价当前分层，给出下一轮优先级建议；不修改运行面，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.2.31_Task_Report.md)。
-#### R2.2.32 [completed]
-
-按用户确认的经济口径修正 PK01 Sub2API runtime：将账号15名称从lyon9801标注为lyon9801 0.10，并按净售价0.10减采购成本重新调整全局priority，将零毛利账号15从1降至20、将成本0.02且近期表现良好的账号35从20升至5；执行前校验名称/旧值，变更后回读，不修改分组、容量、代理、凭据、状态、可调度或临时不可调度规则，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.2.32_Task_Report.md)。
-#### R2.2.33 [completed]
-
-实现 YAML-first 的 Sub2API 利润统计 CLI：默认读取最近24小时原生 admin usage，按账号完整名称聚合请求、Token（M/B）和 actual_cost，并依据 YAML 声明的盈利分组、自用分组、净收入系数与账号名称尾部采购成本系数，输出不扣除自用成本和扣除自用成本两种利润口径；缺失成本或未分类流量必须标记 partial，默认 Kubernetes 列表风格、显式 --json 保留精确值，兼容 v0.1.147，不修改 runtime，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.2.33_Task_Report.md)。
-#### R2.2.34 [completed]
-
-纠正 Sub2API 利润 CLI 的币种与倍率语义：原生 actual_cost 是标准 API 美元计费基数，售价 0.10 和账号名称尾部 0.02/0.025/0.03/0.05/0.06/0.10 都表示每 1 美元标准 API 计费对应的人民币单价；将 YAML、字段名、Kubernetes 表格、JSON 和 skill 统一改为 CNY per API USD，重新统计最近24小时人民币利润，不做汇率换算且不修改 runtime，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.2.34_Task_Report.md)。
-#### R2.2.35 [completed]
-
-只读计算 PK01 Sub2API 最近7天成本与利润：使用已修正的 CNY per API USD 口径，从原生 admin usage 按完整账号名称聚合标准 API 美元计费基数、人民币收入和人民币采购成本，分别给出不扣除自用成本与扣除自用成本的人民币利润；不修改 runtime，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.2.35_Task_Report.md)。
-#### R2.2.36 [completed]
-
-由 Artificer 优化 Sub2API 利润统计 CLI 的单次聚合与渐进披露，减少 7 天成本利润计算中的重复查询、外部解析和手工算术；默认 Kubernetes 风格与显式 JSON 都应直接保留紧凑汇总，账号明细语义化下钻，缺失历史成本时输出参数化利润公式；不修改 runtime 或部署，关联 [GitHub issue #2043](https://github.com/pikasTech/unidesk/issues/2043)，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.2.36_Task_Report.md)。
-#### R2.2.37 [in_progress]
-
-把 `~/.codex/config.toml.grok` 和 `~/.codex/auth.json.grok` 调整为通过 Sub2API 原生 Grok 分组接入 Codex；保留密钥脱敏和文件权限，先验证现有 Key 的分组/模型能力，再修改并做最小只读配置验收，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.2.37_Task_Report.md)。
+核对 Sub2API v0.1.155 官方源码与配置能力并按支持边界实施两项源头调优：将确定的模型上下文超限错误避免包装为通用上游502，以及在官方配置确实支持响应首 token 超过180秒触发当前请求failover时通过 owning YAML和受控CLI启用；Grok不处理，不修改Sub2API源码，不用隐藏UniDesk补丁伪造上游能力，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.2.16_Task_Report.md)。
 ### R2.3 [completed]

 调查并收敛 Sub2API 原生 system-log 索引未保留策略事件的能力缺口，关联 [Issue #2027](https://github.com/pikasTech/unidesk/issues/2027)，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.3_Task_Report.md)。
+
+### R2.4 [completed]
+
+集中跟踪客户直接反馈、专项请求事件和 Sub2API 原生诊断能力，形成按用户、请求、账号和监控对象快速下钻的运维入口，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.4_Task_Report.md)。
+
+#### R2.4.1 [completed]
+
+紧急只读追踪用户 mail0795336304@163.com 反馈请求卡住15分钟：定位用户ID、近30分钟请求、当前长请求/并发、request ID、账号与模型，区分排队、上游首字、流式间隔、代理网络或客户连接，不取消请求且不修改runtime、YAML、proxy或调度，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.4.1_Task_Report.md)。
+#### R2.4.2 [completed]
+
+复盘用户直接反馈的只读追踪过程并交由 Artificer 实现 [Issue #2000](https://github.com/pikasTech/unidesk/issues/2000)：增加通用的一键用户追踪 CLI，以邮箱或用户ID关联请求空窗、用户/API Key并发、client/internal request ID、上游账号名称、proxy基础设施和证据化归因，采用Kubernetes列表风格与稳定ID渐进披露，减少手工API与重复trace调用，不改运行面，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.4.2_Task_Report.md)。
+#### R2.4.3 [completed]
+
+将 PK01 的 Sub2API 通过 owning YAML 从 v0.1.153 受控升级到 v0.1.155：只修改 PK01 target镜像版本，依次执行状态核对、plan、apply dry-run、镜像预拉、受控apply、状态与公开健康验证，保持账号池runtime和Codex pool配置原样，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.4.3_Task_Report.md)。
+#### R2.4.4 [completed]
+
+交由 Artificer 实现 [Issue #2004](https://github.com/pikasTech/unidesk/issues/2004)：增强 Sub2API CLI 拉取 v0.1.155 原生智能诊断与渠道监控状态，泛化所有分组/渠道概要和指定对象下钻，以Kubernetes列表风格呈现TTFT、上游与客户错误率、原生建议和证据边界，以及7/15/30天渠道运行状态、平台/模型、对话延迟、端点PING、可用率、最近记录和刷新事实，使用稳定ID渐进披露，不重算第二套诊断且不修改运行面，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.4.4_Task_Report.md)。
+#### R2.4.5 [completed]
+
+快速缓解错误 #17440：基于 request e5c08dde-9e60-4a14-9458-5574cec00b65 的真实链路，将精确短语 Input must be a list 补入通用 504 临时不可调度规则，对全部非 lyon9801 账号精准批量 dry-run、确认下发和自动回读对账，不改容量、优先级、代理或 Sub2API 源码，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.4.5_Task_Report.md)。
+#### R2.4.6 [completed]
+
+交由 Artificer 实现 [Issue #2013](https://github.com/pikasTech/unidesk/issues/2013)：定义并实现 Sub2API P0/P1/P2 故障快速查询 CLI，P0 为上游故障穿透客户，P1 为首字延迟偏高且普通与 compact 分开统计并突出极端离群，P2 为上游错误率偏高；支持所有分组概要与按等级、分组、账号名称、模型、请求类型、稳定 request ID 下钻，默认 Kubernetes 列表风格和固定分页，不靠手工 limit，不修改运行面，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.4.6_Task_Report.md)。
+#### R2.4.7 [completed]
+
+主代理只读追踪客户错误 #17490（request ID 4eb9a84b-7346-47a8-bb66-fb7b44317279）：使用 Sub2API 原生 Ops、trace、账号完整名称、failover/retry/临时不可调度和近期窗口证据，定位账号 https://sub2.pokexiao.com plus 0.03 的同步502为何穿透客户，区分候选耗尽、context取消、不可重试阶段或模板未命中；先调查，不盲目新增generic 502规则，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.4.7_Task_Report.md)。
+#### R2.4.8 [completed]
+
+交由 Artificer 实现 [Issue #2016](https://github.com/pikasTech/unidesk/issues/2016)：增强 CLI 对 Sub2API 内部账号/渠道监控的原生只读访问，展示探测 timeout、cadence、阶段耗时、账号选择、上游首字节、切号/重试和最终状态，支持所有监控对象概要与稳定 ID 下钻，默认 Kubernetes 列表风格且不靠手工 limit；不修改运行面、不发新探针，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.4.8_Task_Report.md)。
+#### R2.4.9 [completed]
+
+只读调查错误 #17511（request ID `f7ff0efe-64d3-4dd7-8716-20bdfc3a2f90`）为何上游 502 后未成功切号，重建流式请求的账号选择、首字节、响应提交、failover、排除列表、context deadline 与最终客户错误链，并与内部 monitor 请求 #17490 对照，不修改运行面，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.4.9_Task_Report.md)。
+### R2.5 [in_progress]
+
+集中跟踪 Sub2API 版本基线、上游账号质量评分、用量归因和账号全局调度优先级，保留只读评估与受控 runtime 调整边界，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.5_Task_Report.md)。
+
+#### R2.5.1 [completed]
+
+将 PK01 Sub2API 从 v0.1.155 受控回退到 v0.1.147：只修改 owning YAML 版本事实，在最新 master 的独立干净 worktree提交并通过受控 GitHub PR 合并，随后使用原 platform-infra Sub2API 交付入口完成 PK01 rollout，并核验实际镜像、版本、健康状态和原入口可用性，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.5.1_Task_Report.md)。
+#### R2.5.2 [completed]
+
+只读执行 PK01 Sub2API 最近4小时所有分组的上游账号质量评分：使用原生 Ops 账号请求量、客户/上游错误、切号、重试、临时不可调度、TTFT 和当前可用性，完整报告账号名称、评分、等级、置信度和扣分原因；兼容 v0.1.147，不修改 runtime、YAML 或调度配置，完成任务后将详细报告写入任务报告，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.5.2_Task_Report.md)。
+#### R2.5.3 [in_progress]
+
+交由 Artificer 实现 [Issue #2035](https://github.com/pikasTech/unidesk/issues/2035)：增强 Sub2API 最近窗口账号质量分析，在同一分组、同一账号、同一窗口的一张 Kubernetes 列表中聚合展示评分/等级/置信度/失败率/TTFT 与请求数/Token（M/B）/金额（$）；复用 v0.1.147 原生 admin usage 分页，JSON 保留精确值与来源，字段缺失不伪造为零，并修复 `--group <id>` 精确下钻错误，不修改运行面，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.5.3_Task_Report.md)。
+#### R2.5.4 [completed]
+
+只读核查 PK01 Sub2API 当前全部 OpenAI 上游账号的实际 priority、分组成员关系、可调度与可用状态，并结合最近4小时分组内评分、失败率、TTFT、Token和金额给出分层的推荐优先级调整方案；报告完整账号名称，区分立即建议、观察建议和证据不足，不直接修改 runtime、YAML或调度配置，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.5.4_Task_Report.md)。
+#### R2.5.5 [completed]
+
+按 R2.5.4 的最近4小时评分与用量结论，精准调整 PK01 Sub2API 账号全局 priority：只更新明确列出的 runtime-manual 账号，变更前全量预检、失败自动回滚、变更后批量回读对账；不修改分组、容量、代理、凭据、状态、可调度或临时不可调度规则，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.5.5_Task_Report.md)。
+
+#### R2.5.6 [in_progress]
+
+交由 Artificer 实现 [Issue #2037](https://github.com/pikasTech/unidesk/issues/2037)：为 Sub2API runtime 接入账号全局 priority 的单账号与精准批量 dry-run/confirm、所有 selector 预检、写后自动回读对账、所有权提示和 Kubernetes 列表/显式 JSON 输出；明确 lower-is-higher、没有分组优先级，兼容 v0.1.147，不自动调整评分、不部署或修改运行面，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.5.6_Task_Report.md)。
+#### R2.5.7 [completed]
+
+只读复核 PK01 Sub2API 全局 priority 调整生效后约25分钟的新窗口：按全部分组和完整账号名称统计请求量、流量份额、客户/上游错误、失败率、TTFT、切号、Token与原生金额，并将账号名称尾部0.02/0.025/0.03/0.05/0.06/0.1作为上游采购成本权重综合评价当前分层，给出下一轮优先级建议；不修改运行面，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.5.7_Task_Report.md)。
+#### R2.5.8 [completed]
+
+按用户确认的经济口径修正 PK01 Sub2API runtime：将账号15名称从lyon9801标注为lyon9801 0.10，并按净售价0.10减采购成本重新调整全局priority，将零毛利账号15从1降至20、将成本0.02且近期表现良好的账号35从20升至5；执行前校验名称/旧值，变更后回读，不修改分组、容量、代理、凭据、状态、可调度或临时不可调度规则，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.5.8_Task_Report.md)。
+#### R2.5.9 [completed]
+
+只读分析 PK01 Sub2API 最近2小时所有分组的用户可见错误、普通与 compact 请求首字延迟分布及完整账号名称质量评分，关联请求量、上游错误、failover、重试、临时不可调度、当前可用性和样本置信度，给出主因与调度观察建议，不修改 runtime、YAML 或运行面，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.5.9_Task_Report.md)。
+#### R2.5.10 [completed]
+
+只读统计 PK01 Sub2API 最近8小时所有分组的账号质量评分与流水，按完整账号名称聚合请求量、Token（M/B）、标准API美元计费基数、客户/上游错误、failover、重试、临时不可调度、TTFT、当前可用性、评分等级与置信度，并区分盈利池和自用池；不修改runtime、YAML或运行面，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.5.10_Task_Report.md)。
+#### R2.5.11 [completed]
+
+精确分析 PK01 最近8小时盈利池客户可见错误：按状态码、响应详情、账号、模型、同步/流式、端点、阶段、failover/retry和代表request ID重建具体原因；随后结合两分组账号评分、样本置信度、采购成本和盈利贡献，生成精确全局priority方案，先dry-run再确认写入并批量回读，不修改分组、容量、代理、凭据、可调度或临时不可调度规则，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.5.11_Task_Report.md)。
+#### R2.5.12 [completed]
+
+只读确认流式并发限额错误发生于 SSE 已提交后的 HTTP 200 degraded 阶段，核验官方临时不可调度配置无法挽救当前流后停止追加无效规则；固化默认不修改 Sub2API 源码、版本或外部哨兵的边界，仅在用户明确授权时允许这些手段，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.5.12_Task_Report.md)。
+
+### R2.6 [completed]
+
+集中跟踪 Sub2API 标准 API 美元计费基数、人民币采购成本、售价和多口径利润统计，保持 YAML-first 的经济口径，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.6_Task_Report.md)。
+
+#### R2.6.1 [completed]
+
+实现 YAML-first 的 Sub2API 利润统计 CLI：默认读取最近24小时原生 admin usage，按账号完整名称聚合请求、Token（M/B）和 actual_cost，并依据 YAML 声明的盈利分组、自用分组、净收入系数与账号名称尾部采购成本系数，输出不扣除自用成本和扣除自用成本两种利润口径；缺失成本或未分类流量必须标记 partial，默认 Kubernetes 列表风格、显式 --json 保留精确值，兼容 v0.1.147，不修改 runtime，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.6.1_Task_Report.md)。
+#### R2.6.2 [completed]
+
+纠正 Sub2API 利润 CLI 的币种与倍率语义：原生 actual_cost 是标准 API 美元计费基数，售价 0.10 和账号名称尾部 0.02/0.025/0.03/0.05/0.06/0.10 都表示每 1 美元标准 API 计费对应的人民币单价；将 YAML、字段名、Kubernetes 表格、JSON 和 skill 统一改为 CNY per API USD，重新统计最近24小时人民币利润，不做汇率换算且不修改 runtime，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.6.2_Task_Report.md)。
+#### R2.6.3 [completed]
+
+只读计算 PK01 Sub2API 最近7天成本与利润：使用已修正的 CNY per API USD 口径，从原生 admin usage 按完整账号名称聚合标准 API 美元计费基数、人民币收入和人民币采购成本，分别给出不扣除自用成本与扣除自用成本的人民币利润；不修改 runtime，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.6.3_Task_Report.md)。
+#### R2.6.4 [completed]
+
+由 Artificer 优化 Sub2API 利润统计 CLI 的单次聚合与渐进披露，减少 7 天成本利润计算中的重复查询、外部解析和手工算术；默认 Kubernetes 风格与显式 JSON 都应直接保留紧凑汇总，账号明细语义化下钻，缺失历史成本时输出参数化利润公式；不修改 runtime 或部署，关联 [GitHub issue #2043](https://github.com/pikasTech/unidesk/issues/2043)，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.6.4_Task_Report.md)。
+#### R2.6.5 [completed]
+
+扩展 YAML-first 利润算法：将 lyon9801 的边际采购倍率改为 0.0，并把 2026-07 的 1300 元一次性账号成本作为期间固定成本单列；利润 CLI 支持按月聚合并分别披露流量成本、一次性成本和扣除后的两种利润口径，再依据近期账号质量与边际利润调整账号全局 priority，不修改 Sub2API 源码、版本、外部哨兵、分组、容量、代理、凭据或可调度状态，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.6.5_Task_Report.md)。
+#### R2.6.6 [completed]
+
+基于本月已有 Sub2API 原生流水增加整月收益 run-rate 估算：将月初至当前的收入、盈利池流量成本和自用流量成本按已过时间线性外推至月末，一次性期间成本只扣一次，输出不扣自用与扣除自用两种整月预计利润、缩放系数和 MTD 实际基准；保持 YAML-first 经济口径，不修改 runtime 或 Sub2API，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.6.6_Task_Report.md)。
+#### R2.6.7 [completed]
+
+只读分析 2026-07 整月收益预测亏损根因：按盈利池与自用池、完整账号名称、标准 API 美元计费基数、边际成本和一次性成本拆解，量化 lyon9801 当前流量占比、固定成本覆盖率、全量切向 lyon 的理论上限和当前组合盈亏平衡流水，判断亏损主要来自 lyon 占比、总流水不足、自用成本还是其他账号边际成本；不修改 runtime 或 Sub2API，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.6.7_Task_Report.md)。
+#### R2.6.8 [completed]
+
+按售价 0.15 CNY per API USD 只读重算 2026-07 整月预测收入、盈利池利润、扣除自用后的整体利润、当前组合保本售价和全量 lyon 理论利润；沿用 R2.6.7 同一流水快照与成本结构，不修改 YAML、runtime 或 Sub2API，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.6.8_Task_Report.md)。
+#### R2.6.9 [completed]
+
+复核售价 0.15 CNY per API USD 的整月预测：重新拉取当前 Sub2API 原生流水，并按实际已过时长计算每日标准 API 计费基数、营业额、盈利池变动成本、自用成本、lyon9801 固定成本日均摊销及两种日利润，核对月度外推是否一致；只读，不修改配置或运行面，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.6.9_Task_Report.md)。
+#### R2.6.10 [completed]
+
+评估 2026-08 不再采购固定账号 lyon9801 0.0 时的预期盈利：售价保持 0.15 CNY per API USD，按最新日均流水外推 31 天，分别计算直接取消 1300 元固定成本的理论上限，以及 lyon 当前盈利池和自用池流量按其他活跃账号实际加权平均边际成本接管的现实预测；披露容量与质量风险，只读且不调整账号，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.6.10_Task_Report.md)。
+#### R2.6.11 [completed]
+
+将固定账号退出核算流程沉淀到通用利润 CLI 和 Sub2API skill：增加可复用的排除账号情景参数，一次原生 usage 聚合直接输出售价覆盖、理论上限、按剩余账号分组加权成本重分配的现实利润、日均营业额与成本、账号流量占比和剩余账号负载增幅；保持默认 Kubernetes 列表风格与显式 JSON，避免账号分页和手工算术，不修改 Sub2API 运行面，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.6.11_Task_Report.md)。
+#### R2.6.12 [completed]
+
+基于最新 0.15 售价情景、当前 0.10 YAML 口径、lyon9801 固定成本、两池替代成本、账号负载增幅和可靠性价值，形成综合运营建议：明确本月沉没成本利用、下月续费决策、可接受固定号价格、售价策略、容量与质量门槛、自用预算和账号优先级原则；只做建议，不修改配置或运行面，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.6.12_Task_Report.md)。
+### R2.7 [completed]
+
+集中跟踪 Sub2API 原生 Grok 账号、分组、Codex Responses 接入和第三方 Grok 上游兼容性，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.7_Task_Report.md)。
+
+#### R2.7.1 [completed]
+
+只读调查 Sub2API 官方源码和 issue，确认最新原生 Grok provider 通过 Sub2API 接入 Codex 的受支持路径，区分 OAuth、API Key、Responses、模型映射和源码能力边界；不修改 runtime、YAML、代码或部署，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.7.1_Task_Report.md)。
+#### R2.7.2 [completed]
+
+把 `~/.codex/config.toml.grok` 和 `~/.codex/auth.json.grok` 调整为通过 Sub2API 原生 Grok 分组接入 Codex；保留密钥脱敏和文件权限，验证现有 Key 的分组与模型能力，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.7.2_Task_Report.md)。
+#### R2.7.3 [completed]
+
+结合管理端 `https://sub.yjxm1221.top grok` API Key 账号连接测试成功的新证据，复核 Codex Grok profile 经 Sub2API `/v1/responses` 的网关链路，区分账号直连测试与分组调度路径，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.7.3_Task_Report.md)。
+### R2.8 [completed]
+
+整理本 MDTODO FILE 的职责层级和编号，并把同一 SUBITEM 下的直接 SUBSUBITEM 一般不超过 20 固化到 mdtodo-edit skill，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.8_Task_Report.md)。
+
+### R2.9 [completed]
+
+将 `https://api.iceiu.com/` 对应上游账号的人民币采购成本标注调整为 `0.011`，结合 Sub2API 原生近期账号评分、错误率、TTFT、用量和当前 runtime 优先级选择适度提高后的优先级；手工账号使用精准 runtime CRUD，变更前 dry-run、确认写入后逐字段回读对账，不修改 Sub2API 源码、版本或外部哨兵，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.9_Task_Report.md)。
+### R2.10 [completed]
+
+将 `https://sub.yjxm1221.top/` 对应上游账号的人民币采购成本标注调整为 `0.025`，结合 Sub2API 原生近期账号评分、错误率、TTFT、用量和当前 runtime 优先级适当调整优先级；手工账号使用精准 runtime CRUD，变更前 dry-run、确认写入后逐字段回读对账，不修改 Sub2API 源码、版本或外部哨兵，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.10_Task_Report.md)。
+## R3 [completed]
+
+增加 Sub2API 客户余额精准批量充值 CLI：支持从原生最近24小时用量提取活跃用户并生成每人增加20美元的补偿计划，也支持显式用户ID或账号 selector；默认 dry-run 输出完整账号、用户ID、当前余额、增额和目标余额，写入必须显式 --confirm 并自动回读对账。本轮只实现并验证 dry-run，禁止实际充值，必须等待用户再次明确授权，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R3_Task_Report.md)。
+
+### R3.1 [completed]
+
+从 PK01 Sub2API 原生最近24小时 usage 精确列出活跃非管理员用户，并生成每人增加10 USD额度的批量补偿 dry-run：披露完整邮箱、用户ID、请求数、当前余额、增额和目标余额，实际写入数必须为0；不使用 --confirm，不执行充值，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R3.1_Task_Report.md)。
+
+### R3.2 [completed]
+
+交由 Artificer 实现 [Issue #2097](https://github.com/pikasTech/unidesk/issues/2097)：对接 Sub2API 原生公告后端并增加受控公告 CLI，支持公告列表、精确查看、创建 dry-run、显式确认发布和写后回读对账；为最近24小时17名活跃用户每人10 USD、总额170 USD的补偿生成公告预览，本轮禁止实际发布公告或充值，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R3.2_Task_Report.md)。
+
+### R3.3 [completed]
+
+通过 Sub2API 受控 CLI 精确拉取北京时间 2026-07-14 17:00:00 至 18:00:00 的活跃非管理员用户；时间解释必须读取 owning YAML 的默认 Asia/Shanghai 时区，不用相对窗口近似，不执行充值或其他运行面写入；若 CLI 缺少绝对时间窗能力，先按通用方式补齐并验证后再查询，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R3.3_Task_Report.md)。
+
+### R3.4 [completed]
+
+在 Sub2API credits owning YAML 的排除列表中加入内部员工账号 zhuo@test.com 与 huiguo@test.com，并让活跃用户补偿 dry-run 按通用精确 selector 排除并披露 employee-excluded 原因；复测北京时间固定窗口不再选中这两个账号，不执行充值，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R3.4_Task_Report.md)。
+
+### R3.5 [completed]
+
+增强 Sub2API credits 固定时间窗查询，按原生 usage 的实际字段为每名用户聚合请求次数、输入 Token、输出 Token 和总 Token，并重新列出北京时间 2026-07-14 17:00 至 18:00 的客户与 YAML 排除账号；必须披露字段来源和缺失值，不执行充值，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R3.5_Task_Report.md)。
+
+### R3.6 [completed]
+
+按用户明确授权，对固定补偿候选用户 ID 11、10、7、22、19 每人增加 30 USD，总额 150 USD，并并发发布服务稳定性补偿公告；两条操作都必须通过 Sub2API 原生受控 CLI 显式 confirm，使用精确名单、写后回读和公告字段对账，禁止扩大到 YAML 排除员工或管理员，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R3.6_Task_Report.md)。