dachui/live-hub-py
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
623 Commits 3 Branches 0 Tags
bf2f120fdc2995b308ded4c9793742af1f28c782
Commit Graph
623 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
yml2213 253571730a feat(account): 补上改备注接口，remark_changed 事件从此有发射点 
`remark_changed` 此前是「定义了事件类型、但压根没有改备注的接口」，于是永远不发。
按 S4 的原则（留着一个永远不发的类型比删掉更糟 —— 看代码的人会以为它有数据），
补接口而不是删类型。

## 接口

`PUT /api/accounts/{id}/remark`，权限点 `account:remark`（授予 super_admin /
operation / support，与 `account:tag` 一致）。

- 与改标签一样走 `record_account_action()`：**审计 + 账号时间线一次写完**，
  审计带 `account_id`，事件 detail 带 `{from, to}`；
- **只做单个、不做批量**：备注是自由文本，给一堆账号写同一句备注没有实际意义
  （标签是短枚举才有批量）；
- 内容 trim 后截断到 256（与 `accounts.remark` 列宽一致），清空也记一条事件；
- 备注没变化时直接返回、**不写事件**：否则时间线会被「点开保存了一下但没改」刷满。

## 权限点新增前的安全检查

新权限点会被 `custom_permissions` 覆盖，所以先查了库：
`admin` / `kf1_test` 的 `custom_permissions` 是 **JSON null**（不是 SQL NULL），
Python 侧取出来是 `None` → `get_user_permissions` 走角色默认。
也就是说**没有任何用户在用自定义权限列表**，新增权限点不会把谁的能力锁掉。
（这一点很容易看错：`IS NULL` 判出来是「有自定义权限」，`JSON_LENGTH` 还是 1。）

## 前端

- 详情页「备注」一行改为可编辑（铅笔 → 输入框 → 保存/取消，回车即存）；
- `EVENT_STYLE` 补 `remark_changed`，时间线里能看到备注的每次变更。

## 一个自己踩到又修掉的坑

第一版把两个 `useState` 写在了 `if (!accountId) return <Empty/>` **之后** ——
正是本次会话刚在 LoginTasksPage 修掉的那类 hooks 顺序违规（`react-hooks/rules-of-hooks`
直接报错）。已上移到早期 return 之前的 state 区块。lint 抓到，构建不报，属于
「能跑但迟早炸」的那类问题。

## 验证

- `TZ=Asia/Shanghai`：**426 passed / 6 skipped**（S4 后 420 → 新增 6 条）
- `TZ=UTC`（相关文件）77 passed；ruff check/format 全绿
- 前端 `tsc -b && vite build` 通过、`npm run lint` 0 errors
- 新增用例：写入并带 from/to 事件与审计关联、未变化不写事件、清空也记一条、
  trim + 截断到 256、账号不存在 404、**新权限点确实在三个角色的默认权限里**
  （防止「加了接口但没人能用」）
 2026-10-04 15:21:48 +08:00
yml2213 0a922ce56d feat(account): S4 事件发射点补齐 —— 审计与时间线打通、批量事件、ck_invalid 只认转变 
S3 让 `status` 可信，S4 让**时间线完整**：账号上发生的事，时间线里都能查到。

## 补齐「定义了却从没发过」的事件

`assigned` / `tag_changed` 这两个类型早就定义了、前端 `EVENT_STYLE` 也渲染了，
但**全仓没有任何代码发过**（`grep` 只有定义处）。本次接上：

- 单个分配 / 批量分配 → `assigned`（detail 带 assigned_to / assigned_username）
- 单个改标签 / 批量改标签 / 按筛选批量改标签 → `tag_changed`（detail 带 from/to）

## 新增 `ck_cleared`，并修掉 `ck_invalid` 的刷屏

- **`ck_cleared`**：清 CK 是**不可逆**操作（重登当前成功率极低），时间线里却不留痕。
  现在单个清除与批量清除共用 `account_lifecycle.on_ck_cleared()`。
- **`ck_invalid` 改为只在「由好变坏」时发**。旧实现每轮巡检只要判定 invalid 就发一条，
  源码注释写着「避免每轮刷屏」，**但代码并没有做到** —— 6 小时一轮、失效一周就是
  28 条一模一样的事件。判定失效是**一次状态转变**，不是每轮读数。`error`（查不到）
  同样不改变结论、不发事件。

## 审计与时间线一次写完（防漏一边）

新增 `audit_service.record_account_action()`：**审计 + 账号事件一起写**，并把
`account_id` 落到审计上。这两件事必须成对出现 —— 只写审计，时间线就缺「谁改了什么」；
只发事件，合规审计就缺一条。分成两次调用写，迟早有人漏一边（`assigned` 就是这么漏的）。

顺带把批量删除的审计补上被删账号 id（`detail.account_ids`，截前 200 条）：
删账号会**连带删掉它的事件时间线**（外键），审计是唯一痕迹 —— 这正是 10-03
那次事故要留的东西。

## 批量操作不再逐条开 SAVEPOINT

批量分配/改标签可能覆盖几千个账号，而每个账号的时间线都该各留一条。
逐条走 `emit()` 会给每条开一个 SAVEPOINT，几千条时请求明显变慢。
新增 `emit_bulk()`：一次 executemany，整批包在**一个** SAVEPOINT 里，
与 `emit()` 一样**绝不抛异常**（整批失败就整批丢弃 + warning，不影响业务写入）。

## 检测入口收口：4 处 → 1 个 `on_ck_verdict()`

`ck_health` / 人工检测 / 工作台执行前检测 / 重登后复检 原本各自写
`ck_check_status` + `ck_check_result` + `ck_checked_at` + 发事件 + 调 `sync_status`，
口径容易分叉（`ck_invalid` 的刷屏就是这么来的）。现在统一走
`account_lifecycle.on_ck_verdict()`，顺序固定：**写结论 → 由好变坏记事件 → 重算状态**。

至此 `account_lifecycle` 成为**唯一**写生命周期字段的模块，并加了一条**源码扫描用例**
把它钉死（任何地方直接 `acc.status = ...` 都会让它红，并指出 file:line）——
比写在文档里的约定可靠。虎牙的 `huya_accounts.status` 是同一个病，但属另一套模型，
已在用例里显式排除并注明。

## 接口与前端

- 时间线支持 `?category=` 筛选（lifecycle / auth / business / ops）；
  响应补 `category` / `subject_*` / `actor_*`
- 前端 `EVENT_STYLE` 补上 `status_changed`（**S3 我漏的**：加了事件类型却没加样式，
  页面上显示成原始英文）与 `ck_cleared`；时间线加「分类」筛选

## 验证

- `TZ=Asia/Shanghai`：**420 passed / 6 skipped**（S3 后 404 → 新增 16 条）
- 迁移链 3 passed；ruff check/format 全绿；前端 `tsc -b && vite build` 与
  `npm run lint`（0 errors）均通过
- **两条关键用例都做过「反向验证」**（先注入旧行为确认会红）：
  - 把 `ck_invalid` 改回「每轮都发」→ 用例报 `3 == 1`；
  - 在路由里直接写 `acc.status = ...` → 不变量用例给出精确 file:line。
- 新用例还覆盖：批量分配/改标签逐账号发事件、清 CK 事件与审计关联、
  `emit_bulk` 的跳过与容错、时间线分类筛选、批量删除的 id 留痕。

未做（后续）：S5 业务事实直发事件 + `douyu_tasks` 保留策略、S6 账号页重构 +
`bind_status` 三列拆解。`remark_changed` 目前没有改备注的接口，故无发射点（已在文档标注）。
 2026-10-04 15:09:46 +08:00
yml2213 fbab805610 fix(ui): 修掉 LoginTasksPage 的 hooks 顺序告警（eslint 由红转绿） 
`setTaskSummary` 在 useEffect 里被使用（约 259 行），但它的 useState 声明在
约 420 行 —— eslint `react-hooks/immutability` 判为「访问了尚未声明的变量」。
这是 main 上就存在的历史问题，会让 `npm run lint` 失败。

**运行时其实不会踩 TDZ**（useEffect 在渲染后执行、且内部是 async，等到真正调用
setter 时声明早已执行完），但**声明与使用相隔 160 行**本身就是隐患：任何一次
把调用改成同步、或把 effect 往上移的重构都会真的炸。

处理：把 useState 声明移到任务相关 state 区块（taskPage / taskStatus / taskTotal
旁边）—— 既满足规则，也让这组状态聚在一起。先确认过**组件在声明之前没有任何
早期 return**，所以上移不会改变 hooks 的调用顺序。

验证：
- `npx eslint src/pages/LoginTasksPage.tsx` → 0 errors（原本 1 error）
- `npm run lint` → **exit 0**（29 个 warning 是既有的 react-refresh 提示，未动）
- `npm run build`（tsc -b && vite build）通过
 2026-10-04 14:52:05 +08:00
yml2213 1a8710834a feat(account): S3 生命周期状态收口 —— 6 状态状态机、唯一推导入口、停用/归档闭环 
`status` 列从「空壳」变成可信状态：S1 建了列、S2 让账号独立，本提交让状态真正
反映账号处境，并把「哪些账号要人处理」变成可筛选的事实。

## 状态机（7 → 6 个状态）

`imported` / `active` / `invalid` / `manual` / `disabled` / `archived`

**砍掉 `relogin`**：它完全等价于 `invalid + relogin_next_at is not None`，
独立成状态就多出一个必须与 `relogin_next_at` 同步的字段 —— 正是要消灭的「双份真相」。

## 唯一推导入口（防「双份真相」）

新增 `services/account_lifecycle.py`：
- `derive_status(account)` —— **纯函数**，按 cookie / ck_check_status / relogin_*
  推导状态；人工态（disabled/archived）优先级最高，不被覆盖；
- `sync_status(db, account)` —— 推导 + 变了才写，**幂等**（没变则不写库、不发事件，
  否则巡检每轮都往时间线刷一条）；
- `set_manual_state(db, account, state)` —— 停用/归档/`auto`（恢复自动推导）；
- `on_login_success(db, account)` —— **「登录成功对账号意味着什么」只定义一次**：
  作废本轮重登退避痕迹 + 重算状态。于是**「待人工」的账号被人工登录救回来时状态
  会自动恢复**，而不是卡在 manual。
- `MANUAL_KINDS` 从 `jobs/ck_relogin.py` 挪到这里（service 不该反向依赖 job）。

**9 处底层判据写入点全部接线**：登录成功、CK 清除（单个/批量）、ck_health 巡检、
人工 CK 检测、工作台执行前检测、重登复检、重登结算（成功/失败退避）。

## 消费端：补上一个真缺口 + 删掉两处临时派生

- ⚠️ **缺口**：`ck_health` / `ck_relogin` / `count_pending_relogin` 此前只按底层判据
  选行，**没排除 disabled/archived** —— S2 提交里已标注，状态一上线就会变成
  「停用的账号照样被自动重登」。现已全部排除。
- `automation.manual_queue` 原本用 4 个条件自己拼「需要人工」，现在一句
  `status == 'manual'`。同一判据从「3 处各写一遍」收敛成「1 处推导」。

## 接口与前端

- `PUT /api/accounts/{id}/lifecycle`（disabled/archived/auto + 原因，写审计）
- `PUT /api/accounts/{id}/automation`（**接上死开关**：`auto_managed` 此前没有任何
  接口/前端能改，永远是默认 True）
- 新增权限点 `account:manage`（运营默认拥有）
- 列表支持 `?status=` 筛选；**归档默认不出现**（要看需显式筛选）
- `AccountOut` / 概览接口补 status / status_label / status_reason / auto_managed
- 前端：账号列表加「状态」列与状态筛选；详情页状态卡 + 停用/归档/恢复/自动化开关

## 两个自查出来的问题（都已修）

1. **幂等键反而丢事件**：状态事件一开始用 `status:{id}:{target}:{秒级时间戳}` 作
   `source_ref`，结果同一账号在同一秒内两次切到同一状态就撞唯一键，`emit` 静默吞掉
   —— **状态改了、时间线却少一条**，正是本模块要消灭的「悄悄不一致」。
   改为不传 `source_ref`：`sync_status` 本身已幂等，不存在重复写入路径。已加用例。
2. **迁移与运行时规则分叉**：迁移 0042 的状态回填 CASE 原本会写出已被砍掉的
   `relogin`，且判据与 `derive_status` 不一致（次数用尽的会回填成 invalid 而非 manual）。
   已改成逐字对应，并加一条用例**真跑那段 SQL 与纯函数逐条比对**（已验证：
   临时改回旧 CASE 该用例立刻红）。

## 验证

- `TZ=Asia/Shanghai`：**404 passed / 6 skipped**（S2 后 373 → 新增 31 条）
- 迁移链 3 passed；ruff check/format 全绿；前端 `tsc -b && vite build` 通过
- 真实开发库核对：落库状态分布 active 4 / imported 8，**与 derive_status 逐账号比对无漂移**
- 新增用例覆盖：derive 真值表（每状态入口 + 人工态优先）、sync 幂等、
  人工态切换、**全生命周期走查**（导入→登录→失效→重登→转人工→人工救回→清 CK→停用）、
  自动化排除 disabled/archived、列表状态筛选、接口

未做（后续阶段）：S4 事件发射点补齐、S5 业务事实直发事件、S6 账号页重构。
 2026-10-04 14:48:22 +08:00
yml2213 94eace50c1 fix(events): S2.1 修掉 emit() 的 naive 时区偏移，并打通台账列与审计关联 
外部审计对 S1+S2 提出 3 条，全部复核成立，本提交一并修掉。第 1 条是真缺陷，
且已经写进数据了。

## 1. ⚠️ emit() 把 naive datetime 当成「本地时间」（数据正确性）

`emit()` 原来写 `(occurred_at or now).astimezone(UTC)`。对 **naive** 值，Python 会
把它当作**服务器本地时间**再换算 —— 本机 UTC+8，事件时间整整早 8 小时。

naive 的来源很具体：收集器用**裸 SQL** 读 `douyu_tasks`，绕过 `UTCDateTime`
装饰器，拿到的就是 naive。而这条路正是「充值/兑换/积分/开通」台账。

仓库早有既定约定（写在 `database.UTCDateTime` 里）：**naive → 视为已是 UTC，原样用**。
`scheduler._as_utc` / `yyb_service._as_utc` / `audit.py` 都遵守了，**只有 emit() 漏了**。
现抽成 `account_events_service.to_naive_utc()` 统一收口，并补齐文档。

**数据库铁证**（修复前，本机开发库）：
```
事件 occurred_at        源 douyu_tasks.finished_at    相差
2026-09-30 20:23:36  →  2026-10-01 04:23:36          8 小时
```
已用 `UPDATE ... JOIN douyu_tasks` 把那 3 条按源时间对齐（相差 0 秒），
修复 SQL 记在账号事件设计文档 §11.2 第 5 条，供曾开启过收集器的环境使用。
该作业默认 `enabled=false`、需人工开启，故生产大概率无受影响数据。

## 2. 回归用例：这个 bug 在 UTC 机器上**看不见**

`astimezone(UTC)` 在 TZ=UTC 下恰好是恒等变换 —— 旧实现与正确实现结果相同。
也就是说单写一条普通用例，在 CI/容器里会**假绿**，只在开发机现形。

所以用例显式把进程时区切到 UTC+8（`_force_non_utc_timezone`）。已验证：
**在 TZ=UTC 下临时还原旧实现，该用例照样红**。另补一条 aware 路径的用例，
防止「为了修 naive 把换算弄坏」。

顺带补了收集器的端到端用例：**事件 occurred_at 必须等于源任务 finished_at**。
旧用例只断言 written/watermark 数量、从不看时间，这正是 bug 一路绿灯的原因。

## 3. emit() 支持 S1 建的台账列（此前是「空壳」）

迁移 0042 给 `account_events` 加了 `category` / `subject_type` / `subject_key` /
`actor_type` / `actor_id` 与复合索引 `ix_account_events_ledger`，但 `emit()` 一直没
暴露它们 —— 列建好了没有写入方。现补齐参数与 INSERT，并加用例锁住「能写」。
S3 的 `status_changed`（`category="lifecycle"`）与 S5 的台账查询都要靠它。

## 4. 清 CK 的审计补 account_id

`DELETE /cookies/{id}` 与 `/cookies/batch` 的审计只写了 `target`（自由文本，
账号改名/重名就关联不上）。S1 已给 `audit_logs` 加了 `account_id`，这里补上写入
（批量时仅在只涉及一个账号时填），并加用例断言审计能反查到账号。
这是 S6「审计进账号时间线」的前置。

## 验证

- 新增/修改 5 条用例，先红后绿；**已验证在 TZ=UTC 下旧实现照样被这些用例抓到**
- `TZ=Asia/Shanghai`：**373 passed / 6 skipped**（原 368 + 5 条新用例）
- `TZ=UTC`：369 passed / 4 failed —— 那 4 条是 `test_huya_web_cookie_fields.py`
  的 qimei 用例，**在 main 上同样失败**（qimei 按 SDK 语义编码本地时间，
  与本次改动无关，也未修）
- ruff check / format 全绿；前端 `vite build` 通过（本次未动前端）
 2026-10-04 14:30:02 +08:00
yml2213 00125fbfc4 refactor(account): S2 读写一次切换 —— CK/健康/重登彻底搬到账号，登录记录退化为历史 
S1 加好了列，本提交把**读与写一起切**过去。这是设计里「同一份数据的读与写必须
在同一个提交里切」的要求：先切读或先切写都会出现「写账号、读记录」的中间态，
跑起来不报错，只是默默用错数据。

## 核心改动

**判定「谁有 CK」不再借道登录记录**
- `cookie_holding_filter()` / `cookie_operable_filter()` / `cookie_holding_account_ids_query()`
  / `visible_douyu_task_accounts()` 全部改为作用于 `Account`；
- `cookie_operable_filter()` 的「在途排除」仍查 `login_tasks`（那是**某次尝试**的属性），
  用 `NOT EXISTS` 子查询 + 迁移 0042 新增的 `(account_id, attempt_status)` 索引；
- 删除死代码 `latest_cookie_login_task()`；`latest_cookie()` 改为直接读账号。

**CK 写入**
- `_write_login_success()` 写 `Account.cookie / cookie_updated_at / cookie_source`；
- `_mark_attempt_failed()` 改看**账号**有没有 CK（决定是否沿用旧的失败语义）；
- 检测模式的 `task.cookie = ""` **不再清空账号的 CK**（见下「行为变更」）。

**自动化作业按账号调度**
- `ck_health`：`_select_tasks` → `_select_accounts`，`db.query(Account)`；新增
  `count_remaining()`（刻意不带 LIMIT，否则积压数恒等于批次上限）；
- `ck_relogin`：同样按账号选行；结算改为「账号 + 本轮尝试记录」，
  退避进度写账号；`settle_fresh_results(batch_id)` 按 `attempt_batch_id` 配对，
  `run_ck_relogin` 把 **account_ids** 交给 runner；
- 顺带让**没有任何登录历史的账号**也能被巡检/重登（以前它们永远进不了队列）。

**登录批次**
- `LoginBatchRunner` 去掉 `relogin_task_ids`，重登与登录统一走 `account_ids`；
- 批次行复用逻辑重写：只保证「同一账号不并发两行」，不再关心「哪一行持有 CK」。
  失败行复用同时看 `attempt_status`（账号有 CK 时 `_mark_attempt_failed` 刻意不动
  `status`，只看 status 会永远命不中 → 每次失败刷一行）。

**删除护栏语义变更（用户可感知）**
- 去掉「持有 CK 的记录不可删」——CK 在账号上，删历史不再影响登录态，历史终于可清理；
- **保留**「在途尝试不可删」（批次线程正拿着那条记录）。

## 行为变更（需评审）

1. **账号检测不再清空 CK**。旧代码在 check 模式写 `task.cookie = ""`，而那时记录的
   cookie 就是账号唯一凭证 —— 一次「批量检测」会把账号登录态删掉。解耦后
   「检测账号凭据」与「CK 是否有效」本就是两件事（后者归 `ck_health` 判），
   继续清空等于凭空制造不可逆的数据丢失（重登当前成功率极低）。
2. **Cookie 页的记录单位从「登录记录」变成「账号」**，所有接口的 id 入参/出参
   变成 `account_id`；`DELETE /cookies/{id}` 清的是该账号的 CK，**必写审计**。
3. 重复检测从「同一账号多行持 CK」改为「**同一个 CK 出现在多个账号上**」——
   后者才是真风险（两个账号共用一个登录态）。用 sha256 指纹分组：
   CK 是 AES-GCM + 随机 nonce 加密，**同一明文每次密文都不同**，比密文永远比不出重复。

## 修掉一个真实并发缺陷

`_write_login_success` 原先被传入 `self.db`（runner 主会话），而它是在**工作线程**里
用 `worker_db` 执行的。`emit()` 会往 `account_events` 插一行，其 `account_id` 外键对
`accounts` 那一行加**共享锁**；这把锁加在另一个会话上，紧接着本会话的
`UPDATE accounts SET cookie=...` 就被自己人挡住 —— 实测 **50 秒后
`Lock wait timeout exceeded`，登录明明成功却写不回 CK**（改造前 UPDATE 打在
`login_tasks` 上所以没撞上）。改为传 `worker_db`：事件本就该和状态变更同事务提交，
顺带修掉跨线程共用一个 Session 的隐患。

## 验证

- 全量 pytest **368 passed / 6 skipped**；迁移链 3 passed；
- 前端 `tsc -b && vite build` 通过；
- `ruff check` / `ruff format --check` 全绿（顺带修掉 main 上遗留的 F821）；
- 新增/改写的关键回归：**删掉全部登录历史后账号的 CK 与健康状态仍在**、
  **无登录历史的账号也能进巡检队列**、结算不碰 CK、删除护栏改为在途语义。

仍未做（设计里排期的后续阶段）：`account_lifecycle` 状态收口（S3）、事件发射点补齐（S4）、
业务事实直发事件（S5）、账号页重构（S6）。注意 `status` 目前只有模型默认值与迁移回填，
所以 `disabled/archived` 还没有任何写入方——S3 落地时要把自动化选行的状态过滤一起补上。
 2026-10-04 14:10:13 +08:00
yml2213 e916a7015d feat(db): S1 迁移 0042 —— 账号全生命周期落库（登录态 + 状态机 + 事件台账） 
账号不再依赖登录记录的第一步：把「账号自己的东西」搬到账号上。本提交**只加列、
只读源表**，不改任何行为，单独部署安全。

accounts 新增 15 列：
- 登录态：cookie / cookie_updated_at / cookie_source
- CK 健康：ck_check_status / ck_check_result / ck_checked_at
- 重登进度：relogin_attempts / relogin_next_at / relogin_last_error / relogin_failure_kind
- 生命周期：status / status_reason / status_changed_at / disabled_at / archived_at
- 索引：ck_checked_at、status、与 (status, relogin_next_at)

account_events 新增 5 列（category / subject_type / subject_key / actor_type / actor_id）
与台账复合索引 (account_id, event_type, subject_key, occurred_at) —— 支撑
「365 天同皮肤」这类需要检索客体的规则，让事件表同时承担业务台账。

login_tasks 补 (account_id, attempt_status) 索引：CK 搬到账号后，「在途尝试」只能留在
登录记录上，巡检/重登每轮都要按它过滤。

回填做成生产级：
- 只读 login_tasks、分块 200 账号、幂等（只在 accounts.cookie 为空时写）；
- 窗口函数取「最近一条持 CK 的行」，不用 GROUP_CONCAT（受 max_len 限制会静默截断）；
- 自校验 fail closed：回填不完整直接抛错让应用起不来，宁可起不来也不带半份 CK 上线；
- 外加值级校验，防张冠李戴（条数相等仍可能 A 账号拿到 B 账号的 CK）。

踩坑留档：cookie 是 TEXT，**不能有 server_default**（MySQL 1101：
BLOB/TEXT/GEOMETRY/JSON column can not have a default value），模型与迁移两侧都要去掉。

验证：
- 空库整链 upgrade head + 模型对齐 + 索引存在 → 通过；
- 本机开发库实跑 0041→0042：记录侧 4 个持 CK 账号 = 账号侧 4 个，值级不一致 0，
  CK 仍是密文（enc:v1: 前缀），状态分布 active 4 / imported 8；
- downgrade 到 0041 再 upgrade：数据完整还原（这是 CK 丢失场景的安全网）；
- 全量 pytest 364 passed / 6 skipped。
 2026-10-04 13:45:59 +08:00
yml2213 3a227ffec1 docs(account): 斗鱼账号全生命周期全新设计，取代旧的目标模型 
围绕账号做一套全新设计，不再参照虎牙，并丢掉旧结构的包袱。

推翻的直接证据：
1. 三个「状态」都找不到家 —— 凭证在 login_tasks.cookie、健康与重登在 login_tasks.ck_check_*/relogin_*、
   生命周期状态根本不存在（只能靠「有没有持 CK 的记录」反推）；
2. accounts.bind_status 一列塞了 36 种取值，混了三种性质（真绑定状态/一次性动作痕迹/业务结果）
   且互相覆盖 —— 查一次精英宝典状态就把 bind_confirmed 冲掉，账号详情页还拿它显示「绑定状态」；
3. 开通/积分/兑换/充值这些账号事实全埋在 douyu_tasks.result（22 万行 / 687MB，绝大多数是轮询噪声）；
4. 账号检测页粘贴文本检测、结果不落库、连 account_id 字段都没有，与库内账号完全脱节。

设计要点：
- 账号为聚合根；当前状态在账号上、发生过什么在 account_events，两者严格分离；
- 登录态（CK/健康/重登）内联 accounts（否决独立表：多会话与懒加载风险，且内联切换面最小），
  并说明 1:1 场景下 defer() 已能解决列表查询拖大字段的问题；
- 新增显式生命周期状态机 imported/active/invalid/relogin/manual/disabled/archived，
  写入收口到唯一服务，禁止各处直接赋值（bind_status 崩掉的直接教训）；
- account_events 扩展 category/subject_type/subject_key/actor_* 与台账复合索引，
  一张表同时承载「时间线 + 开通/积分/兑换/充值台账」，支撑 365 天同皮肤规则；
  有流程的兑换工单仍独立建表 —— 流程归工单、事实归事件流；
- login_tasks 瘦身为纯登录尝试历史，douyu_tasks 降级为执行日志并加保留策略；
- 迁移沿用 CK 解耦文档的回填机制（分块/幂等/自校验 fail closed/值级校验），
  历史业务记录不回填 douyu_tasks，需要时走斗鱼侧权威接口按需同步；
- 落地分 S1~S8，S1→S2 为关键路径，S8（drop 旧列）不可逆且前置每日备份。

同时更新 CK 解耦文档头部，标注其目标模型已被取代、迁移机制仍然有效。
 2026-10-04 13:37:07 +08:00
yml2213 44a1a2bc95 docs(account): 逐行核对 CK 解耦设计，并补账号全生命周期信息模型 
在动手前把那份「待评审」的设计与当前代码逐行对了一遍：

1. 方向成立（CK 确实只存在于 login_tasks.cookie），但原文 §5 漏了 4 处耦合点：
   - services/account_service.py:31 账号列表的 CK 筛选
   - services/douyu_service.py:283 业务任务页的账号可见性
   - routers/accounts.py:629-643 账号详情概览的裸 SQL（账号事件功能新增，原文写作时还没有）
   - routers/login.py:259 与 cookie_holding_filter 同口径的重复实现
2. latest_cookie() 是死代码，原文列为改造目标，实际直接删即可；
3. 修正漂移的行号（accounts.py 285/324/374 → 295/338/391）；
4. 补 §13「账号全生命周期信息模型」：现状把账号事实散在 5 张表 7 个页面，
   指出「账号没独立」在数据/接口/UI 三层的具体表现，以虎牙账号（已解耦的样板）为参照，
   给出四层信息模型、生命周期阶段缺口表与 S1~S6 落地顺序。
 2026-10-04 13:31:39 +08:00
yml2213 98a9f0e0bc chore(merge): 账号事件迁移改号 0041，并去重排查报告 
dev 与 main 从 294c6cd 分叉后，各自新增了一个 0040 迁移（都从 20261002_0039 起链）：
- main：20261003_0040 douyu_tasks.account_assigned_to（生产已应用）
- dev： 20261002_0040 account_events（未上生产）

两者合并即两个 alembic head，upgrade head 会直接失败。因为账号事件迁移从未被生产库
应用过，改号是安全的：

1. account_events 迁移改名为 20261003_0041，down_revision 指向 20261003_0040；
2. tests/test_migrations.py 的 HEAD_REVISION 同步改 20261003_0041；
3. 迁移保持幂等，本机开发库（alembic_version 已是 20261003_0040、account_events 表已存在）
   实跑 upgrade 通过，仅推进版本号、数据未动；
4. 顺带修正规划/解耦设计里「下一个迁移编号」的过期取值（现为 20261003_0042）。

排查报告去重：两个会话各自写了一份《生产服务器高负载排查…》报告，内容重叠且互相矛盾
（一处写 8 核/16GB，另一处有 nproc 原始输出为 4 vCPU/7.1GiB）。合并为单一文档
docs/生产服务器高负载排查与优化报告.md，以带原始命令输出的事实为准，删除重复的那份，
并修正引用它的迁移方案文档。
 2026-10-04 13:20:36 +08:00
yml2213 e88c41385b Merge branch 'main' into dev 
# Conflicts:
#	tests/test_migrations.py
 2026-10-04 13:17:43 +08:00
yml2213 b69c9ff6b6 docs(perf): 沉淀生产服务器高负载排查与MySQL任务排序优化实证报告 
1. 记录Postgres JIT导致CPU飙升197%的排查与禁用优化；
2. 记录MySQL任务列表跨表排序引发Using filesort与Out of sort memory的根因诊断；
3. 记录新增account_assigned_to与复合索引落地、24万历史任务回填及线上实测87倍提速实证。
 2026-10-03 13:26:19 +08:00
yml2213 7790be4e04 perf(douyu-tasks): 为斗鱼任务增加归属客服索引字段，彻底消除全表 filesort 慢查询 
1. 数据库新增迁移 20261003_0040，在 douyu_tasks 表增加 account_assigned_to 字段，并创建 (account_assigned_to, handbook_scope, id) 与 (account_assigned_to, id) 复合覆盖索引；
2. 迁移脚本自动回填历史 24 万条任务的所属客服 ID；
3. 任务服务与账号路由联动：创建任务时自动继承 account_assigned_to，修改账号分配时同步更新关联任务归属；
4. 斗鱼任务查询路由 _visible_tasks_query 改为通过 account_assigned_to 复合索引过滤，消除与 accounts 表的跨表关联与临时表全量文件排序；
5. 新增 test_douyu_task_assigned_optimization 单元测试并通过整链迁移与回归测试。
 2026-10-03 13:10:59 +08:00
yml2213 834bfdd1d0 feat(account-events): 账号详情页与账号事件历史全链路支持 
1. 新增账号事件数据表 AccountEvent 与迁移版本 20261002_0040_account_events，支持审计 Cookie 变更、自动重登、健康检查及任务执行事件；
2. 后端新增 account_events_service 并扩展 /api/accounts 路由，支持事件查询、过滤与上报；
3. 前端新增 AccountDetailPage 账号详情页组件，支持账号元信息展示、事件历史瀑布流与快捷重登操作；
4. 修复 CK 重登与自动化定时任务中事件关联逻辑，补充 test_account_events 单元测试；
5. 新增生产服务器高负载排查分析报告及相关设计文档。
 2026-10-03 12:58:58 +08:00
yml2213 294c6cd058 docs: 登录任务与 CK 解耦设计（待评审） 
根因：login_tasks 一张表同时扛四件事——CK 本体、CK 健康状态、重登调度、
登录历史。前三个是「账号当前状态」，第四个是流水，生命周期不同，于是
清理流水必然伤到状态（2026-10-03 因此丢了 5019 个 CK）。临时护栏只是兜底。

方案：照 huya_accounts 的既有先例，把 CK 与状态挂到 accounts，
login_tasks 退化为纯流水。

关键结论：
- **不做双写**：两处真相会悄悄发散（比报错更难发现），且旧路径会掩盖新
  路径的 bug；而它买到的回退保险本来就有——accounts.cookie 是权威副本，
  随时能反向回填出旧列。改为代码一次切换、旧列延后 drop。
- 两条不可省项：迁移必须自校验（回填不全就中止启动，fail closed）；
  在途判定仍要查 login_tasks（实测 255 行在途），需补 (account_id,
  attempt_status) 索引。
- 登录服务里「一行一账号」的复用逻辑是耦合产物（且已漏水），切换时其
  第一段 cookie_holding_filter 查询必须一起重写，否则静默退化。

含迁移与回填 SQL、读写切换清单、7 个提交的提交计划与依赖关系、
验收基线（13264 个账号持 CK）、测试计划、回退方案，以及待确认决策点。
 2026-10-03 11:40:05 +08:00
yml2213 cd60a48039 docs: 记录 CK 误删事故复盘与恢复方法，并补两条硬规则 
事故：删除登录任务时误删了 5019 个仍持有有效 CK 的记录（显示状态是
attempt_status，与是否持有 CK 语义不同）。已用 binlog 全部恢复。

复盘含：影响范围、根因、修复、可复用的 binlog 恢复流程，以及途中踩到的
四个坑（MySQL 8.4 无 mysqlbinlog、解出的列名是 UNKNOWN_COL* 导致假阴性、
tail 吞进度、JSON bytes 键）。
 2026-10-03 11:11:37 +08:00
yml2213 b89d7f2d27 chore: 移除误提交的 .bak 文件 2026-10-03 10:52:02 +08:00
yml2213 8310a9115e fix(login): 删除任务不再丢 CK —— 只删不持有 CK 的记录【数据安全】 
事故：斗鱼账号的 CK **只存在 `login_tasks.cookie`**（`accounts` 表没有
cookie 列），删掉记录即永久丢失登录态。而列表显示的「状态」是最近一次尝试
（`attempt_status`），于是一条**显示「失败」但实际仍持有有效 CK** 的记录
（status=success + cookie + 上次尝试失败）会被「清空失败」当成垃圾删掉。

修复：
- 批量删除只删空 cookie 的记录，持有 CK 的一律跳过，并在响应里报告跳过数；
- 单条删除遇到持有 CK 的记录直接 409，提示先处理该账号的 CK；
- 前端确认弹窗写明「持有 CK 的记录会跳过」。

顺带修统计口径：分页后 success/failed 只统计当前页，却和「共 N 个任务」
并排显示（曾出现「共 8508，成功 48」）。改走 /tasks/summary 的全局统计。

回归测试补 5 条，专门盯「显示失败但持有 CK」这个事故场景。
 2026-10-03 10:50:23 +08:00
yml2213 1722b0a81b fix(login): 翻页请求不再被轮询吞掉 
loadTasks 原来用「有请求在跑就直接返回」防重入，加了分页后这会把用户点
翻页/改筛选时发出的请求一并丢掉：页面停在上一页，要等下一次轮询（3~15s）
才会更新。改为请求序号「最新请求获胜」：过期响应直接丢弃，不再丢请求。
 2026-10-03 10:44:52 +08:00
yml2213 6ce988a3da docs: 记录部署即跑迁移、时区口径与任务列表分页用法 2026-10-03 10:44:06 +08:00
yml2213 7293d758f1 fix(login): 勾选跨页保留，并去掉 loadTasks 的多余依赖 
两个自己引入的问题：
- loadTasks 依赖 selectedAllMatching 会让每次翻页重建回调，进而触发
  上面的 effect 重新加载标签（多余请求）；
- 翻页静默清空勾选会让人困惑（「选了 10 个翻页就没了」），改为
  preserveSelectedRowKeys 跨页保留，删除数量在按钮上明确显示。
 2026-10-03 10:39:53 +08:00
yml2213 a0db26def3 feat(login): 任务列表支持分页、跨页全选与一键清空 
任务量早就过了单页能装下的规模（库里 1.4 万条，单批就 177 条），但接口
硬编码 limit(200)、前端 pagination={false}，于是「全选」其实只能选到前
200 条，失败任务清不干净。

- 接口加 page/page_size/status：不传 page 时仍返回裸数组（Cookie 页等
  老调用方依赖这个契约，不能改）；传了才返回 {items,total}，total 供跨页全选。
- 删除支持 all_matching：按当前筛选条件删全部，不必先翻完所有页去勾。
- 前端：分页控件（20/50/100/200/500，记住选择）、状态筛选、表头
  「选择全部 N 条（含其他页）」、「清空失败」一键操作。

两条护栏：
- **pending/running 一律不删** —— 删掉会让批次线程找不到记录；要停批次
  走 /stop/{batch_id}。
- 不给任何条件就拒绝删除，绝不默认全删。

顺带：带 join 的 query 不能 bulk delete（SQLAlchemy 会拒绝），改成先查
id 再按主键删。
 2026-10-03 10:37:52 +08:00
yml2213 5995f16c39 docs(plan): 补续作入口与 P0 踩坑留档（外部表结构核实、uv.lock、容器验证姿势） 2026-10-02 22:54:36 +08:00
yml2213 d669552be8 docs(plan): P0 施工单与真机验证结果归档（迁移 0039） 2026-10-02 22:51:25 +08:00
yml2213 afa5c815f6 feat(orders): P0 订单读取适配层——连 order_site 只读库查订单（默认关闭） 
让运营能按订单号查到订单，作为后续资料收集（P2）与皮肤准入（P3/P4）的输入。
order_site 零改动：只读直连、独立极小连接池、可一键降级。

上机核实推翻了规划两处假设（详见 §6.5.1）：
- orders 表没有 order_no 列，只有 id 与 platform_order_id → 查询入口用后者；
- platform_order_id 非唯一：541 组重复，形态固定为「91kaquan 内部行(已发货)
  + 真实店铺行(无人管)」。按规划原文的单行判据，这 540 个已发货订单会被误判
  成「没人管」而放行重复履约。改为**订单号维度聚合**：任一行已发货即 auto_fulfilled。

真机验证（只读账号 livehub_ro）：三桶判定全对，重复组正确拦下并回显真实
店铺行的中文名（狂沙舞者，而非内部码 suit_sand_dancer），单次查询 3.3ms。

顺带修一个只在真机才暴露的 bug：_get_engine 先置 _INITIALIZED 再读 URL，
一次落空就把模块永久毒化成不可用，之后补上连接串也救不回来。
 2026-10-02 22:50:20 +08:00
yml2213 d6c6113112 fix(automation): 被重启打断的轮次记为 interrupted，不再混进 failed 
部署重建容器会打断正在跑的作业，那轮永远写不回结果，由启动时的
cleanup_orphan_runs 收尾。之前收尾成 failed，于是页面上一片红 —— 但这并不是
作业本身的失败：账号侧的 CK 一个没丢（旧 Cookie 已保留），被中断的账号也会按
退避自动重试。混在 failed 里会掩盖真正的失败（如 SQL 语法错误）。

改为独立状态 interrupted，前端用中性灰显示「被中断」，与红色的「失败」区分开。
 2026-10-02 22:08:18 +08:00
yml2213 df62898d22 fix(automation): 调度心跳与作业周期解耦，修掉系统性跳轮 
线上现象：同一页面上「CK 自动巡检」的最近运行是 21:45:34，而「下次运行」显示
21:50:34 且已经过去了 —— 巡检明明只要 19 秒，却总是等在那里。

根因是把心跳周期直接当成了作业周期：TICK_SECONDS=300 既是「循环多久醒一次」，
又被写进 next_run_at = 作业结束 + 300s。两者同频会系统性跳轮：

  心跳 t=0     ck_health 19 秒跑完 → next = 5:19
  心跳 t=5:00  差 19 秒没到点 → 整轮空转，什么都不做
  心跳 t=10:00 才真正跑到

于是作业实际是每 10 分钟一轮，而不是设计的 5 分钟；只要作业耗时不是刚好 0，
就会稳定地"差一点点"被跳过。两个作业共享同一个心跳时，还会互相把对方的到期
时刻推后。

改动：
- 拆成两个常量：TICK_SECONDS=30（心跳，只做「有没有到点的作业」检查，几乎不
  耗资源）、JOB_INTERVAL_SECONDS=300（作业周期，跑完一轮后隔多久再跑）。
- next_run_at 改用 JOB_INTERVAL_SECONDS。
- /api/automation/jobs 的 scheduler 同时暴露两个值；启动日志一并打印。
- 页面：「单账号重检间隔」加 tooltip 说明它不决定调度频率（它只控制同一行多久
  重检/重试），避免和调度周期混淆。

回归测试（3 条）：心跳必须比作业周期密至少 4 倍；周期未到时连跳多次心跳都不跑；
把 next_run_at 拨到过去后下一次心跳必须跑到。

全量 304 通过。
 2026-10-02 21:57:41 +08:00
yml2213 847ed4539a fix(ui): 运行历史的假耗时、以及「下次运行」显示成过去时间 
两处显示问题（来自线上页面核对）：

1. 耗时列：被重启打断的轮次，finished_at 是 cleanup_orphan_runs 在重启后补上的，
   于是「耗时」把停机时间也算进去了（线上出现过 235s / 687s 这种假数字）。
   改为只有真正扫描过数据的轮次才计算耗时，其余显示 '-' —— 一轮就报错的
   （比如历史上的 SQL 语法错误）同理。

2. 下次运行：两个作业串行跑在同一个调度线程里，前一个耗时长时后一个会排队，
   next_run_at 因此会停在「已经过了」的时刻；直接显示一个过去时间看起来像故障。
   改为：未启用 → 「未启用」；已过期 → 「排队中（<时间> 到期，等待前序作业让出
   线程）」，未到期照常显示。
 2026-10-02 21:51:37 +08:00
yml2213 34d667cba0 fix(automation): 启动时收尾卡在 running 的运行记录 
作业是在调度线程里同步跑的：进程一重启（部署、崩溃、手工重启），那一轮就再没
机会写回结果，automation_runs 会永远停在 running，页面上一直显示「执行中」。
登录任务早有孤儿清理，运行记录原先漏了。

线上就是这么暴露的：部署时重建容器打断了正在跑的 ck_relogin 第 14 轮，重启清理
把 20 个在途账号标成了「重新登录中断（旧 Cookie 已保留）」（这部分是对的），
但 run 14 本身永远卡在 running，detail 为空。

新增 cleanup_orphan_runs()，在启动清理链里调用：把所有 running 的运行记录收尾为
failed + finished_at + 「服务重启中断」。如实记为 failed 而不是 success —— 那轮
确实没跑完；被中断的账号由各自的孤儿清理负责标记并按退避重试。

新增回归测试：只有 running 的被收尾，已完成的不受影响。

（另一件事一并说明：上一次部署我报告「零中断」是验证过早 —— 检查时部署的 up -d
还没执行到。实际情况是 mysql 未被重建（达到了本次改动目的），但应用容器因镜像
变化被正常重建，因此打断了那轮重登。）
 2026-10-02 21:35:42 +08:00
yml2213 ada3915856 fix(deploy): 按需重建容器，不再每次部署都重启 MySQL 
`deploy.sh` 主流程里是 `$COMPOSE up -d --force-recreate`（不带服务名），所以每次
部署都会把所有服务重建一遍 —— 包括 mysql。mysql 重启期间应用连不上库，表现为
每次部署都有约 90 秒的 502（今天几次部署都踩到了）。

改为 `$COMPOSE up -d douyu-login`：只处理应用服务，且交给 compose 判断是否需要
重建（镜像或容器配置真的变了才重建）。这样：

- 代码部署：应用镜像变了 → 只重建应用，mysql 完全不动；
- .env 改动：compose 会检测到容器配置变化 → 重建应用，mysql 仍不动；
- 什么都没变：不重建，零中断。

mysql 只在它自己的配置真的变了时才动（例如加 --default-time-zone 那次）。
 2026-10-02 21:26:39 +08:00
yml2213 c3fd299f3a test(db): 测试改用真实 MySQL，方言差异不再漏到生产 
生产是 MySQL 8、测试是 SQLite，两者的方言差异在本地完全测不出来。今天为此
付出了两次代价：

1. `ORDER BY ck_checked_at ASC NULLS FIRST` 在 SQLite 上完全正常，本地 258 条
   全绿，一部署到生产第一次巡检就 1064 语法错误（MySQL 不支持 NULLS FIRST）；
2. P1b 自动重登的结算复用调度器事务读取，在 SQLite 下看不出问题，但在 MySQL 的
   REPEATABLE READ 下读到的是批次开始前的快照 —— 10 条实际成功的重登全部被记成
   失败。SQLite 的读一致性与 MySQL 不同，这类问题跑一万遍也复现不出来。

改动：
- 新增 tests/support/db.py：测试专用引擎/会话工具，连接串从 .env 读取，
  默认指向独立的 douyu_login_test 库；
- 新增 tests/conftest.py：会话级建好表结构，每个用例前后清空所有表做隔离；
- 根 conftest.py 接管连接串设置：它在 pytest 收集阶段最先执行，在这里把
  DATABASE_URL 指向测试库，应用模块首次 import 拿到就是 MySQL，不依赖任何
  import 顺序（原先这里是 sqlite:// 兜底，改造后会变成「先建 SQLite engine
  再打补丁换成 MySQL」，顺序一变就静默跑错库）；
- 21 个测试文件的 setup 样板统一改用共享测试引擎；
- 两个迁移测试改为在临时库 douyu_login_mig_<随机> 上跑完整 alembic upgrade head，
  跑完 drop —— 迁移脚本本身也终于在 MySQL 上被验证；
- dev.sh 与 README 的过时说明一并更新（原先写着「不需要 MySQL / .env 配置」；
  「测试各自建 SQLite 内存库」）。

安全与易用：
- 测试库名与开发库同名时**直接拒绝运行**（clear_tables 会 DELETE 所有表，
  一旦 TEST_MYSQL_DATABASE 被指到 douyu_login 就是数据灾难）；
- 连不上 MySQL 时给出可操作提示（先 ./dev.sh 起库 / 用 TEST_MYSQL_DATABASE 覆盖），
  而不是抛一段 SQLAlchemy 原始堆栈。

验收：
- 全量 301 条通过，连跑两次结果一致（隔离有效），耗时约 12.5 秒（原 SQLite 约 3.6 秒）；
- 单文件独立运行通过（不依赖全量执行顺序）；
- `grep -rn sqlite tests/ conftest.py` 已无实际用法；
- **方言确实生效**：临时把一条查询改回 `NULLS FIRST`，13 条测试立刻变红（含运行期
  失败），还原即恢复；这条由 test_generated_sql_is_mysql_compatible 长期守着。

代价（已在 README 与规划附录 C.2 记明）：跑测试前必须先有 MySQL，pre-push 钩子
同理；CI 需要 service container。
 2026-10-02 21:22:08 +08:00
yml2213 b34c1ff5f3 fix(automation): 重登结算改用新事务读取，修掉「成功被记成失败」 
线上第一轮自动重登（10 条）报告「成功 0 / 失败 10」，但库里这 10 条的
attempt_status 全是 success —— 账号其实都救回来了，是结算读错了。

根因是 MySQL 的隔离级别：默认 **REPEATABLE READ**。调度器传进来的会话在挑候选
时就已经开了事务，而结算复用了这个会话去读 runner（另一个会话）刚提交的结果；
同一事务里重新查询只会看到事务开始时的快照，于是全部读成「未成功」。SQLite 的
读一致性与 MySQL 不同，所以这类问题在 SQLite 上跑一万遍也复现不出来。

后果不只是统计错：失败的账号会被写退避时间，其中 2 条还被判成「极验」进了待
人工队列 —— 等于把救回来的账号又标成需要人工。

改动：
- 新增 settle_fresh_results()：自己新开一个会话读结果并结算，绝不复用调度器的
  事务；run_ck_relogin 改用它。

（另一路 SQLite→MySQL 的测试改造已把测试套件真正跑在 MySQL 上，本次新增的回归
测试 test_settlement_sees_other_session_commit 正是靠这一点才守得住：它先让一个
会话开着事务，再由另一个会话提交成功，断言结算必须读到成功。）
 2026-10-02 21:09:48 +08:00
yml2213 2c532df14f fix(automation): 待重登积压数不再被批次上限截断 
页面上「待重登候选」显示 10 —— 那只是 ck_relogin 的 batch_size，不是真实积压。
根因是我用作业的候选查询取 count，而那个查询带 LIMIT batch_size，count 自然
被截断在批次上限；线上实际有一千多条待重登，页面却恒显示 10。

改为独立的 count_pending_relogin()：同一套资格条件（invalid + 有 CK + 允许自动
管理 + 未转人工 + 未超每日上限），但不带 LIMIT，也不按退避窗口过滤 —— 退避是
「什么时候试」的细节，不影响「还有多少要处理」。

新增测试：批次上限为 10 时，25 条积压必须报 25。

另：本次一并还原了 ck_health.py 里被外部改动引入的回归 —— 有人把选行排序改成
text("login_tasks.ck_checked_at ASC NULLS FIRST")，那是逐字透传给数据库的片段，
而 MySQL 不支持 NULLS FIRST（今天线上就是这么炸的 1064）。已恢复成可移植写法，
test_generated_sql_is_mysql_compatible 会拦住这类改动（本次正是它先报的红）。

全量 298 通过。
 2026-10-02 21:05:18 +08:00
yml2213 ed6e186655 fix(ui,test): 说明巡检与重登的联动关系；修掉一条按分钟偶发失败的测试 
看图时发现两个问题：

一、页面上那段说明是 P1a 时代的文案，已经过时且误导：「重登仍由人工在
「CK 检测与重登」页面操作」——P1b 上线后自动重登已存在。两个作业其实是联动的
上下游：巡检把账号标成 invalid，「CK 自动重登」的候选条件正是这个字段，所以
巡检一发现失效、重登作业下一周期就会接手。刻意分成两个作业是为了止损粒度
（巡检只读零风险；重登会真实登录，出问题可单独关掉）。据此改写说明文案，并在
两张卡片上标出「下游：CK 自动重登」/「上游：巡检标记为失效且有 CK 的账号」。

二、jobs 接口新增 pending_relogin：当前有多少条正等着自动重登。页面靠它把
上下游关系显性化 —— 没有这个数字，两个开关看起来像互不相干。计数走重登作业
自己的候选查询，保证「页面显示的待办」和「作业实际会捞的」是同一口径。

顺带修掉 tests/test_douyu_email_code_pick.py 里一条既有缺陷：它用
max(0, now.minute - 30) 构造「30 分钟前的邮件」，分钟数小于 30 时会退化成当前
整点（21:00:12 → "今天 21:00"），只比 now 早十几秒，于是断言随「当前几点」偶发
失败 —— 每小时前 30 分钟必红（已确认在我本次所有改动之前的提交上同样失败，
不是本次引入）。改成真实的时间减法，跨天时用「昨天」。

全量 298 通过。提交时另一路 SQLite→MySQL 的测试改造仍在同一工作区进行，
本次只暂存本功能相关文件。
 2026-10-02 21:01:17 +08:00
yml2213 8fc8e623b9 feat(automation): CK 自动重登（P1b）+ 失败分型与待人工队列 
P1a 的巡检只产出「谁失效了」的清单，不兑现修复：1,356 个失效账号仍要人工逐个
选集→点重登→过滑块。线上实测 20 个失效账号重登 20/20 成功（2 分 13 秒、零极验），
证实失效是会话级过期而非凭证问题，可救量约 1,350。

后端：
- 迁移 20261002_0038：login_tasks 加 relogin_failure_kind（枚举），供作业决定
  「继续退避重试」还是「转人工」；不用 attempt_message 做字符串匹配（文案一改
  就失效，页面也要按类型筛选）；
- jobs/ck_relogin.py：
  - 候选 = 巡检判定 invalid + 允许自动管理 + 无在途尝试 + 退避到期 + 未超每日上限
    + **未转人工**（极验/凭证问题不再自动重登）；
  - 复用 LoginBatchRunner(mode="relogin")，成功才替换 CK（沿用既有安全语义）。
    自动化身份取最早的超管做 created_by，权限给 login:view_all 以免受归属限制；
    总时长上限压到 240 秒，避免长时间占住调度线程；
  - settle_results() 独立成纯函数便于单测：成功清空退避状态；失败按分型分流 ——
    captcha/credential 转人工（不排期）、email_quota 退避到次日零点+随机抖动、
    email_code/interrupted/network 走 1h→3h→12h→24h 阶梯；次数用尽也停下等人工；
  - 未知文案默认按可重试处理（有每日上限兜底），别把可能只是抖动的账号推给人工；
- 注册第二个作业「CK 自动重登」（batch 10 / 并发 3，**默认关闭**）；
- 新增 GET /api/automation/manual-queue：按原因分组列出待人工处理的账号。可重试
  类型但已无下次排期的（次数用尽）单独成组 —— 否则会混进「验证码失败」里，客服
  看不出这个已经不会再自动试了。

前端：
- /automation 页新增「待人工处理」卡片，按分型分组展示（极验要过滑块、凭证要核对、
  次数用尽要人工确认），各带账号与最近失败原因。

测试：新增 26 条（分型顺序陷阱「上限」优先于「验证码」、退避阶梯、配额退避次日、
候选筛选、MySQL 方言编译、结算、待人工队列分组）。
提交前全量 297 通过、ruff 全绿、前端 tsc 通过。

注意：提交时另一路「测试改用 MySQL」的改造正在同一工作区进行，本次刻意只暂存
本功能相关文件，未触碰 tests/conftest.py、tests/support/ 及对方已转换的测试文件。
 2026-10-02 20:51:19 +08:00
yml2213 5645f19102 docs(plan): P1b 小规模实测完成——20/20 全部重登成功 
按 §7.4.7 第一段跑实测，用现有手动重登链路（batch 65eda0142b4c）对 20 个
invalid 账号重登，两组各 10：A「还没在 attempt_* 时代重试过」、B「取码 bug
时代失败过」。

结果：
- 成功率 20/20 = 100%（历史推断只有 78%）；耗时 2 分 13 秒（约 9 个/分钟）；
- 极验滑块 0 次；邮箱取码全部正常 —— B 组全过，证实那 144 条「验证码失败」
  确实是 20261001 修掉的取码 bug 造成的，修复在生产生效；
- 20 个 CK 全部替换成功，ck_check_status 由登录流程自动改回 valid。

可救量由此从估的 1,050 上调到约 1,350；失败分型仍要做但属少数路径。
实测速度与零极验说明当前风控容忍度比预想高，全量仍建议限速（每小时
100~200 个起步，观察极验率再决定是否加速）。
 2026-10-02 20:46:17 +08:00
yml2213 9143a3afa0 docs(plan): 按线上实测重写 P1b 设计——失败分型，并把 P1b 提到 P1a 之后 
线上数据把 P1b 的必要性和设计都改了：

- 巡检只产出失效清单、不兑现修复，1,356 个失效账号仍要人工逐个选集→重登→过
  滑块，所以要把 P1b 提前（原计划等一到两周观察期，但检测准确性/误判封堵/
  失效性质三个前提都已验证完）；
- 更正一处误判：那 1,356 个失效账号不是「从未成功过」，而是「曾经成功、CK 放
  了一两个月过期」。依据是 LoginTask 全项目只在一处创建（登录成功写回处），
  导入账号不建 LoginTask；attempt_status='' 只说明成功发生在该字段出现之前；
- 失效应属会话级（斗鱼回「用户未登录」而非密码错误），用库里密码重登大概率
  可救；按历史数据真实成功率约 78%，预计 1,356 个里可自动救回约 1,050；
- 新增失败分型 relogin_failure_kind（决策 11a）：极验/凭证问题转人工，取码/
  中断/网络自动重试，配额满退避次日。线上 415 个失败里 64% 实为可自动解决
  （取码 bug 与重启中断），不分型会白费 265 个可救名额；
- 记录速率约束：13,618 账号对应 13,618 个独立邮箱（1:1），单账号配额满不影响
  他人；瓶颈在 IP，建议走代理池 + 限速 30~60/小时；
- 排期改为 P1a → P1b → P0 → P2 → P3 → P4，P1b 估 2.5~3 人日；附录 A 补 P1b
  迁移，上线按「小规模实测 → 限量开 → 全量」三段。
 2026-10-02 20:41:25 +08:00
yml2213 f8c5e896d4 fix(automation): 巡检区分「查不到」与「失效」，并在大面积失败时自动暂停 
P1a 原本把「检测没通过」一律写成 invalid。但 check_douyu_cookie 的失败分两类：
斗鱼明确回「未登录/登陆异常」（CK 真失效），以及请求超时/响应异常（我们查不到）。
一视同仁的后果是：斗鱼接口抖动或被风控时，每 5 分钟 200 个、一小时就能把两千多个
好账号标成失效，客服会误判成「CK 大面积挂掉」。规划里的失败率熔断只给了 P1b，
P1a 漏了。

改动：
- 新增 classify_result()：valid / invalid（命中斗鱼鉴权类说法）/ error（其余）；
- error 时**不覆盖该行原来的 ck_check_status**，只更新 ck_check_result（带
  verdict 字段）与 ck_checked_at，并计入本轮 skipped；
- 一轮 error 占比 > 30% 且条数 >= 20 时自动把作业 enabled 置 false，message 与
  detail.paused 写明原因，避免继续污染；
- 真实死号占比高**不触发**暂停 —— 首轮 100% invalid 是预期情况（选行「从没检测过
  的优先」，积压的是两个月前批量导入、attempt_status 为空、从未登录的陈旧账号，
  生产实测 200 条错误信息一致为斗鱼侧「用户未登录」）。

新增 6 条测试：分类正确性、error 保留原结论、异常不再标失效、大面积失败自动暂停、
真实死号不暂停。全量 271 条通过。
 2026-10-02 20:35:30 +08:00
yml2213 60f1a8d542 docs(plan): 记录 P1a 生产上线结果与首轮数据结论 
按施工单三段走完并验证：调度器启动、手动 50 条观察无风控、启用后调度器自动
接管（12:27:26 跑完 200 条 / 22 秒 / next_run_at 按 tick 推进）。

记录两点供后续参考：
- 上线过程中抓到两个只有生产才暴露的问题（MySQL 不认 NULLS FIRST、compose 的
  environment 是显式列表导致 .env 新增变量传不进容器），均已在 C.2 记档；
- 首轮 100% invalid 属正常且是价值所在：选行「从没检测过的优先」，而积压的
  1,897 条多为 2026-08-04 批量导入、从未尝试登录、CK 已两个月的陈旧账号，
  斗鱼侧统一回「用户未登录」，非风控。客服页会突然出现大批失效账号，属预期。
 2026-10-02 20:34:00 +08:00
yml2213 65a4590291 refactor(time): 时间列统一走 UTCDateTime，并把 MySQL 会话时区对齐成 UTC 
问题不是「UTC 还是本地时间」，而是这套口径有两个半吊子的地方：

1. 库里存 naive UTC、读出来也是裸时间，于是每一处比较/输出都得自己补时区。
   项目里因此散了三份 _as_utc 和一堆 replace(tzinfo=UTC)，P1a 排下一轮时间
   时还炸过一次 TypeError: can't compare offset-naive and offset-aware。
2. MySQL 会话时区跟随系统 +08:00，而库里存的是 UTC —— SQL 里的 NOW()/
   CURDATE() 比库里的时间快 8 小时，查询会静默返回空（P1a 排查时就遇到过，
   看着像「没有数据」）。

改动：

- 新增 database.UTCDateTime：写时 aware→转 UTC 去 tzinfo、naive 视为 UTC；
  读时一律补 UTC 时区。底层 DDL 仍是 DATETIME，**不需要迁移**。models.py 的
  28 个时间列全部改用它，模型上的时间字段从此不再是裸值；
- docker-compose 给 mysql 加 --default-time-zone=+00:00，让 SQL 时间函数与存储
  口径一致。安全性已核实：全库 0 个 TIMESTAMP 列、0 个 CURRENT_TIMESTAMP
  默认值，改这里不会改变任何已有数据的语义；
- 新增 tests/test_utc_datetime.py：读出必须 aware、能直接和 datetime.now(UTC)
  比较、带 +08:00 的写入要落成 UTC、naive 写入视为 UTC，并有一条元测试扫描
  Base.metadata，防止以后新增时间列忘了用 UTCDateTime。

保留既有的 _as_utc 补丁（对 aware 值是幂等的，属防御性代码）；新代码不再需要。
「存 UTC、算 UTC、显示本地」三条线至此各自明确：存储与比较统一 UTC，日志按
容器 TZ 显示本地时间，前端 formatTime 负责转本地。
 2026-10-02 20:27:07 +08:00
yml2213 3d5d0f551f fix(automation): 去掉 MySQL 不认的 NULLS FIRST，排序改用可移植写法 
生产 MySQL 上手动跑第一轮就报 1064：

  You have an error in your SQL syntax ... near 'NULLS FIRST, login_tasks.id ASC'

NULLS FIRST 是 PostgreSQL/SQLite 语法，MySQL 不支持。本地测试全绿是因为跑在
SQLite 上（它认识这个语法），属于方言差异漏网 —— 生产是 MySQL、测试是 SQLite，
行为测试覆盖不到这类问题。

改成 `ck_checked_at IS NULL DESC, ck_checked_at ASC, id ASC`：三个方言下语义
一致（没检测过的优先）且都是合法 SQL。顺带把选行查询抽成 build_select_query，
便于按方言编译做回归。

新增回归测试：用 MySQL 方言 compile() 选行 SQL，断言不含 NULLS FIRST/LAST，
且「没检测过优先」用可移植写法表达。

规划附录 C.2 记下这条：写 SQL 前先确认方言；P0 连的是 order_site 的 PostgreSQL，
项目里已经出现 MySQL / SQLite / PG 三套方言。
 2026-10-02 20:14:49 +08:00
yml2213 f8a4a0baff fix(compose): 补齐自动化与 P0/P2 的环境变量透传，并放宽部署等待窗口 
部署 P1a 时发现两个问题：

一、compose 的 environment 是显式列表（不是 env_file），只写进 .env 不会传进
容器。于是 .env 里新加的 AUTOMATION_ENABLED=true 容器查不到，日志照旧打印
「AUTOMATION_ENABLED 未开启，自动化调度器不启动」——调度器根本没起。早先
§15.1 写入的 ORDER_SITE_* 与 OSS_* 也是同样情况，P0/P2 会直接踩到。

补齐 9 个变量的透传：AUTOMATION_ENABLED、ORDER_SITE_DATABASE_URL /
LOOKUP_ENABLED / LOOKUP_TIMEOUT_SECONDS、OSS_ENDPOINT / BUCKET /
ACCESS_KEY_ID / ACCESS_KEY_SECRET / PREFIX，全部带默认值（缺省即关闭或空），
不配置也不会让容器起不来。

二、deploy.sh 只等 15×2=30 秒就判「服务启动超时」，而 mysql 一起重建时应用
就绪约 35 秒，于是部署实际成功却报失败。等待窗口放宽到 40×2=80 秒。

规划附录 C.2 记下这条约定：新增环境变量要同时改 .env（实值）、
docker-compose.yml（透传）、.env.example（留档）三处。
 2026-10-02 20:12:24 +08:00
yml2213 7aaaeebe2b fix(automation): 修正调度口径——作业每 5 分钟跑一轮，interval_seconds 只是单行重检间隔 
P1a 把两个「间隔」混成了一个：next_run_at 用的是 job.interval_seconds，于是
作业 6 小时才跑一轮、每轮 200 条 = 800 条/天，全库 12,881 条要 16 天才能过
一遍 —— 等于没巡检，与规划里「账号 6 小时内被查一次」的目标差了两个数量级。

按规划原意修正：
- TICK_SECONDS 60 → 300：作业每个 tick（5 分钟）跑一轮；
- next_run_at 改为 finished + TICK_SECONDS，不再用 interval_seconds；
- interval_seconds 只作为「同一行多久重新检测」的选行 cutoff（选行逻辑本来就
  是这么用的，无需改）；
- 容量口径随之更新：5 分钟一轮 × 200 条 = 40 条/分钟 ≥ 需要的 36 条/分钟，
  冷启动约 5.4 小时覆盖全库，稳态每轮一百多条；
- 前端标签由「巡检周期(小时)」改为「单账号重检间隔(小时)」，说明文案写清
  「每 5 分钟跑一轮」，避免运维误以为是作业周期。

同步更新规划文档 §7.2/§7.3（含两个间隔不能混的说明）与附录 C 的三段上线
步骤（立即跑一次 → 每轮 50 观察 → 每轮 200 启用）。
 2026-10-02 19:54:31 +08:00
yml2213 2379598800 docs(plan): 记录迁移编号不能改名的坑，并说明应用过后的对齐做法 
P1a 的迁移先叫 20261002_0038，本地 dev 库应用过之后为保持链条连续改名成
0037，dev 库的 alembic_version 还记着旧编号，再启动就报
Can't locate revision identified by '20261002_0038'。

结论写进附录 C.1：编号要在被任何库应用之前定下来；已经应用过又必须改名时，
除改文件外还要把每个应用过的库 UPDATE alembic_version 对齐（前提是迁移内容
未变）。
 2026-10-02 19:48:47 +08:00
yml2213 f745a61df1 feat(automation): CK 自动巡检（P1a），只检测不改 CK 
后台原本靠人工逐批点「CK 检测」发现失效账号，1.2 万个账号根本盯不过来。
P1a 把「哪些账号失效了」自动化：自动挑久未检测的账号、调现成检测接口、
把结果写回 ck_check_*。**本作业不替换任何 CK**，重登仍由人工点，符合规划里
「先做只读/只提示，确认无误再做自动动作」的渐进上线原则。

实现：
- 迁移 20261002_0037：automation_jobs / automation_runs 两张表，
  login_tasks 加 relogin_attempts / relogin_next_at / relogin_last_error
  （为 P1b 备好），accounts 加 auto_managed（特殊账号不参与自动化）；
- services/automation/scheduler.py：进程内调度线程，60s tick，状态全部落库
  （重启不丢调度进度、不重复跑轮）；AUTOMATION_ENABLED 默认关闭，作业开关
  也默认关闭；ensure_jobs 只补缺失行、不覆盖运维改过的配置；
  作业异常只记 failed，不拖垮调度线程；单容器 --workers 1，无需分布式锁；
- services/automation/jobs/ck_health.py：选行口径与人工检测一致
  （cookie_holding_filter：持有 CK 且无在途尝试），叠加久未检测、
  auto_managed、batch_size，按 ck_checked_at 升序（最久没查的优先）；
  只写 ck_check_status / ck_check_result / ck_checked_at；
- routers/automation.py：GET /jobs、PATCH /jobs/{key}、POST /jobs/{key}/run、
  GET /runs；新增权限点 automation:view（运营可看）与 automation:manage
  （仅超管），改配置与手动触发都写审计；
- 顺带补 POST /api/login/batch 的审计（此前批次是谁发起、多少账号无据可查）；
- 前端 /automation 页：作业卡片（开关/周期/单轮条数/并发）、运行历史、
  「立即跑一次」；总开关未打开、调度线程未运行时给明确提示。

验证：
- 22 条新测试覆盖调度器行为（只跑到点的、异常不抛出、下轮时间、配置不被重置）、
  选行条件（在途尝试/auto_managed/间隔/batch_size）、接口与权限，其中一条
  专门断言巡检后 cookie/status/message/attempt_status 一字未动；
- 全量 257 条通过；前端 tsc 与构建通过；
- 端到端用 3 个真实账号跑真实斗鱼接口：巡检结果与直接调 check_douyu_cookie
  逐条一致（3/3 valid），CK 与尝试状态全程未变。

顺带修掉一处会炸生产的坑：DB 时间列读出来是 naive UTC，直接与
datetime.now(UTC) 比较会 TypeError，现统一走 _as_utc() 补时区。
 2026-10-02 19:47:41 +08:00
yml2213 6537d77323 chore(gitignore): 忽略 .env.bak* 与 backups/，防口令和账号数据误提交 
原规则只忽略 .env，改 .env 前留的备份（.env.bak-时间戳）虽然未跟踪但**未被
忽略**，一次 git add -A 就会把数据库口令提交进仓库；backups/ 目录同理，服务器
上那份 login_tasks 全量备份有 33MB 账号数据。
 2026-10-02 19:34:37 +08:00
yml2213 6a62bbe70f docs(plan): 新增自动化与资料收集规划与皮肤准入映射分析 
把「CK 全靠人工维护 / 资料靠人转述 / 兑换无台账」整理成分期规划，并基于两套
线上库的实测数据定下关键口径。

数据结论（2026-10-02 实测）：
- order_site 271,134 单按履约路由二选一且完全不重叠：A 有 fulfillment_tasks
  85,338 单（88.3% 已 delivered，是发货平台的活）、B 有 work_orders 96,755 单
  （打手）、C 两者都无 89,542 单 —— 只有 C 是「没人管」，才是本系统的目标；
- 斗鱼可兑换商品只有 78 个（皮肤类 60）。C 桶皮肤类 923 个快手商品名映射过去：
  62 个唯一命中（27.7% 件数）、14 个命中多个（12.4%，需用户选）、847 个斗鱼
  兑不了（59.9%）—— 准入白名单以斗鱼商品目录为准，不匹配就不建单；
- order_items.spec_json 已带 sellerId/relItemId/relSkuId/skuNick，(itemId, skuId)
  才是单订单的精确定位键（4,092 个数字 skuId 中 89% 唯一），接单平台就是按
  sku_exact/sku_series 匹配的，本系统照此设计；
- CK 巡检规模 12,881 行（valid 10,079 / invalid 905 / 从未检测 1,897），按 6h
  周期反推 batch_size 应为 200 而非 50，否则实际周期被拉长到 21 小时。

规划要点：
- 与 order_site 整合选只读直连 PG：order_site 零代码改动，跨库 SQL 只允许出现在
  一个适配层文件里，另配降级开关与只读保护参数；
- P1 拆成 P1a（只检测、不改动任何 CK）与 P1b（自动重登，默认关闭），按「渐进
  上线」原则逐步减少人工；
- 用户截图一律进私有 OSS 桶 + 后端鉴权代理读图，不落本地磁盘；
- P4 的规则/模板/状态机对齐 order_site 接单平台：资料模板固定为游戏编号 +
  游戏昵称 + 主页截图，皮肤由订单号自动对应，仅多选类让用户选一件；
- 取消规则映射层（与 skin_aliases 职责重叠），规则直接挂 commodity_id，
  连带去掉 rule_ambiguous 状态。

三轮复核：① 补齐结构与缺口（术语表、P0 章节、权限表、配置清单、保留策略、
文案、测试计划、风险回退、迁移与文件清单、施工单）；② 逐条核对代码事实
（路径/符号/接口/字段/迁移 head/测试基线全部命中）；③ 找出并修掉 8 处实现级
矛盾（选择结果无处存、365 天命中的状态缺失、draft 悬空、多选回链断点、P4 与
P1b 排期矛盾、映射层重叠、P2 能力错位、用户回看链接缺失）。

含：docs/自动化与资料收集规划.md、docs/皮肤准入映射分析.md，并更新文档索引。
 2026-10-02 19:34:37 +08:00
yml2213 2bdabc4e03 fix(compose): 补容器资源限额，并修正数据卷默认值以防错挂空卷 
一、内存 / CPU 限额
douyu-login 与 mysql 此前均为 unlimited（Mem=0、NanoCpus=0）。本机 7G 且与
order_site 共用，任一方内存失控都会把整机拖垮（order_site 曾因此被 OOM kill）。
现各限 2G / 2 核；可用 DOUYU_LOGIN_MEM_LIMIT、DOUYU_LOGIN_CPUS、MYSQL_MEM_LIMIT、
MYSQL_CPUS 在 .env 覆盖。

二、修正 mysql-data 的卷名默认值（重要，防数据事故）
原默认值 live-hub-py_mysql-data 是**另一个空卷**，真实数据在项目改名前的
douyu_login_py_mysql-data（4G+）。由于该行改动之后一直没重建过容器，
隐患一直没暴露；2026-10-02 第一次重建容器即挂到空卷，
表现为数据全丢（douyu_tasks 由 228475 行变成空表）。

现默认值指向真实卷，并默认 external: true（不再由本项目创建/删除该卷，
docker compose down -v 也不会把它删掉）。修完不再依赖 .env 是否设置该变量。
 2026-10-02 19:34:29 +08:00
yml2213 168421b40c fix(douyu): 恢复二维码常驻显示，绑定类任务终态也要能看到码 
上一版加了「任务进终态后隐藏账号列表里的小二维码」，但绑定类任务等不到扫码
时会以 success 收尾（douyu_runner_bind: "已生成绑定二维码，未检测到新扫码
角色"），url 仍在结果里，码却被藏掉，客服再也点不开 —— 绑定/电竞绑定/小店
绑定都受影响。

二维码的意义与任务终态无关：只要 result 里还有地址就一直显示。这里恢复
taskQrUrl()，删除 activeTaskQrUrl 与 QR_TERMINAL_STATUSES。

「开通时二维码闪一下就变小」不会复发：根因是支付弹窗被自动关闭 + 已开通账号
被误判到账，现在弹窗不再自动关，且已开通账号在开通前就被拦下、根本不生成
支付码。
 2026-10-02 09:14:40 +08:00
yml2213 99db772ddd feat(douyu): 精英宝典支持查询开通状态，开通前先校验且不再误判到账 
线上两个问题：工作台看不到账号有没有开通精英宝典；点开通时二维码会「闪一下
就变小」——大图弹窗 2~4 秒后自动关闭，只剩列表里 56px 的小二维码。

根因：
- getUserInfo 的 manualType/expireTime 才是开通状态的权威口径，但只有兑换
  流程用过一次，没有任务类型对外暴露；前端只看积分列，而「开通后积分花完」
  和「从未开通」都是 0 分，区分不了（实测 13456 manualType=1/score=0）；
- 开通前不查状态，且到账判定写成「积分 >= 300」：账上本来就有 680 分的账号
  在出码后第一轮轮询就被判成功，前端按 paymentArrived 自动关掉了弹窗。

改动：
- 新增任务类型 query_elite_status：查 manualType/manualScore/expireTime 并
  落库到 accounts.elite_opened / elite_expire_time（迁移 20261001_0036），
  精英工作台加查询按钮与「宝典状态」列（已开通+到期 / 未开通）；
- create_elite_qr 开通前先查状态：已开通直接判成功、不再生成支付码（方案 A），
  既消除二维码闪现，也避免给已开通账号开出真实支付单；
- 到账判定改为「积分比开通前增长」，基线用与轮询同源的 credit/balance 取，
  取不到基线才退回旧口径；
- 支付弹窗不再自动关闭：到账/失败/停止都在弹窗里给结论 + 手动关闭；列表小
  二维码在任务进终态后隐藏。

新增 9 条测试覆盖上述行为，回退 runner 时其中 8 条失败。
 2026-10-01 19:08:25 +08:00