dachui/live-hub-py
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
561 Commits 3 Branches 0 Tags
512ea3db062d841824083d26adf4a49eaa09ca87
Commit Graph
118 Commits
Author SHA1 Message Date
yml2213 512ea3db06 feat(accounts): 增加高价值资产一键筛选与高级自定义筛选功能 
1. 后端新增高价值套装状态筛选（双套均可换/可换白日梦/可换萌兔/已拥有/高价值待救/未查资料），兼容 MySQL 原生 JSON 与 SQLite unicode 转义存储；
2. 后端新增多维资产与状态区间筛选（积分范围、鱼翅范围、宝典开通、电竞开通、角色绑定状态），并支持与批量打标签/删除联动；
3. 统计接口 accounts_summary 新增 high_value 聚合数据，毫秒级返回各类高价值资产数量；
4. 前端账号管理页面新增「高价值一键筛选」胶囊区（带数量徽标与激活状态，即点即滤）；
5. 前端新增可折叠「高级自定义筛选」面板，支持套装状态下拉、积分快捷区间（≥300、≥600）、鱼翅快捷区间（>0、≥6）、宝典与角色绑定状态多条件组合；
6. 补充 6 个高价值筛选与资产区间单元测试，全量用例通过。
 2026-10-05 11:23:48 +08:00
yml2213 9ac98dad89 fix(automation): 补全作业改用界面上的「同一账号多久重检」—— 之前那个字段对它无效 
用户问「同一账号多久重检是啥意思」，顺着查发现**我的作业没在用它**。

## 「同一账号多久重检」是什么

**每个账号的体检周期**：一个账号这轮被查了，多久之后才重新进入候选。
批量扫描类作业的通用参数，配合另外两个决定"扫不扫得过来"：

    需要的能力 = 总账号数 ÷ 重检间隔
    实际的能力 = 每轮条数 ÷ 运行间隔

**实际 < 需要 → 永远扫不完**（队列越来越长）。

按这个口径核对「CK 自动巡检」的默认值（生产 14,574 个持有 CK 的账号）：

    需要 14,574 ÷ 6 小时 = 2,429 个/小时
    实际   200 条 ÷ 5 分钟 = 2,400 个/小时

**几乎精确匹配** —— 那两个默认值是校准过的，不用动。

## 但我的作业读的是 config 里的 refresh_days

于是界面上那个「同一账号多久重检」**对本作业是死的**（改了没反应）——
正是用户上一条批评过的同一类缺陷：「看起来能配、其实配的是不相干的东西」。
我在同一个问题上连着栽了两次（上一次是拿 `interval_seconds` 当调度频率算吞吐）。

改成 `job.interval_seconds`，与其它批量作业**同一套口径**；
默认 7 天（查过的账号 7 天后再查）。config 里的 `refresh_days` 整个去掉。

## 顺带

- 注册处显式写明两个参数：`interval_seconds=7 天`（重检）+ `run_interval_seconds=5 分钟`（调度）
- 用例改名并加注释，钉住"重检间隔必须来自界面那个字段"

## 验证

TZ=Asia/Shanghai **639 passed / 6 skipped**；ruff 全绿；前端 build 通过。
 2026-10-04 21:33:50 +08:00
yml2213 55f899c615 feat(automation): 拆开「多久跑一次」与「同一账号多久重检」—— 调度频率终于可配 
用户反馈：「单账号重检间隔(小时) 很别扭，直接设置多久跑一次、一次跑多少个更符合直觉」。

**对，而且比"别扭"更严重：调度频率以前根本改不了。**

## 问题：两个概念挤在一个字段里

`_run_one` 里原本写着：

    job.next_run_at = finished + timedelta(seconds=JOB_INTERVAL_SECONDS)   # 硬编码 300 秒

也就是不管界面上填什么，下一轮永远是「跑完 + 5 分钟」。
而界面那个「单账号重检间隔(小时)」对应的是 `interval_seconds` ——
它只被作业**自己的选行逻辑**使用（"这行多久该重检"），**完全不参与调度**。

于是出现最坏的情况：**看起来能配调度，其实配的是一个不相干的参数**。
上一轮我还拿它算过吞吐（"10 分钟一轮"），算错了 —— 已在调度器注释里纠正。

## 拆法

| 概念 | 字段 | 界面 |
| --- | --- | --- |
| **多久跑一次** | `run_interval_seconds`（迁移 0051，默认 300）| 「多久跑一次(分钟)」|
| 同一账号多久重检 | `interval_seconds`（不变）| 「同一账号多久重检(小时)」|

- `next_run_at = finished + run_interval_seconds`（有下限 30 秒，避免忙轮询）
- 接口：`GET` 返回新字段、`PATCH` 可改
- 前端：两个输入框分开，并把原来那段绕口的 tooltip
  （"它不决定调度频率 —— 调度周期见页面顶部说明"）改掉 ——
  那句话本身就是这个设计缺陷的自白

## 默认 300 秒

与改动前**实际行为一致** —— 不会因为这次迁移让已有作业突然变快或变慢。
想调快就自己填（比如「账号资料定时补全」填 5 分钟 + 每轮 400 条 ≈ 3 小时补完）。

## ⚠️ 顺带说明一个你截图里可能看到的现象

截图里「账号资料定时补全」显示的是 **0.5 小时 / 30 条** —— 那是我**最初的默认值**。
因为 `ensure_jobs` **只创建不更新**，我后面改成 10 分钟/400 **不会作用到已存在的行**。
这是刻意的（否则会覆盖运维的手工调整），但意味着**默认值改了要手动在界面上改**，
或者删掉那行让 `ensure_jobs` 重建。现在有了「多久跑一次」这个框，直接填就行。

## 测试（+3）

- 下一轮按**运行间隔**排，不是按「同一行重检间隔」（两个值刻意设成不同来钉住）
- 不填时默认 300 秒（保持旧行为）
- 过小的间隔被夹到下限

## 验证

TZ=Asia/Shanghai **639 passed / 6 skipped**；ruff 全绿；前端 build 通过、lint 0 errors。
 2026-10-04 21:30:13 +08:00
yml2213 aea8e4f73d perf(automation): 调度器改为**作业之间并发**，慢作业不再挡住快作业 
用户要求做这条（原本串行）。串行的代价现在很明显：新加的「账号资料定时补全」
一轮要 4 分钟以上，而源码注释里写的是「目前只有 CK 巡检，单轮约 20~40 秒」——
那 4 分钟里 CK 巡检/重登只能干等。

## 两处保护（缺一不可）

**① 在途守卫**（并发化之后最容易出的事故）

`next_run_at` 是作业**跑完之后**才更新的，所以一个跑得比 tick 还久的作业，
下一个 tick 看它仍然是「到期」状态 —— 没有守卫就会被**再派发一次**，
等于把速率翻倍（对斗鱼接口就是"并发放开"，正是风控最敏感的地方）。
所以用 `_IN_FLIGHT` 记录在跑的作业 key，且**成功/失败都必须清标记**
（否则该作业以后再也不跑了）。两条都有用例钉住。

**② 独立 session**

SQLAlchemy 的 Session **不是线程安全的**。作业现在真的并行了，
所以每个作业在自己的 `SessionLocal()` 里跑，按 key 重新取行
（调度线程里那行可能已经过期）。共用 session 会互相踩事务。

## tick 不再被拖住

调度循环改用 `run_due_jobs(db, wait=False)`：**派发完就返回**，
tick 保持 5 分钟一轮，不再等作业跑完。

`wait=True`（默认）保留原语义：顺序执行、用调用方的 session 并返回 outcomes ——
测试与手动触发走这条，所以既有的 33 条调度器用例**一条没改**。

## ⚠️ 顺带纠正我自己上一轮的一个错误说法

我上一条说「interval_seconds=10 分钟」会生效 —— **不对**。`_run_one` 里写着：

    下一轮固定在一个 tick 之后；interval_seconds 是「同一行多久重检」，
    由作业自己在选行时用，**不参与调度**。

也就是下一轮永远是「跑完 + 5 分钟」。所以「账号资料定时补全」的真实节奏是
`4.4 分钟跑 + 5 分钟等 ≈ 9.4 分钟一轮` ≈ 2,553 个/小时 ≈ **3.05 小时**，
和之前估的 3.2 小时吻合。

## 测试（+4）

- `wait=False` 立刻返回、作业在后台真的开始了
- **在途作业不会被重复派发**（速率翻倍那个事故的守卫）
- 失败后仍会清在途标记、作业能再跑（别被永久卡死）
- `_release` 即使对不存在的 key 也不炸

## 验证

TZ=Asia/Shanghai **636 passed / 6 skipped**；ruff 全绿。
 2026-10-04 21:24:35 +08:00
yml2213 fd578683b6 feat(automation): 新增「账号资料定时补全」作业 —— 分批慢跑，不撞风控 
## 为什么不能一次性跑全量

生产约 **8,000 个**「CK 有效但没查过」的账号。一次性发起 ≈ **8 万次斗鱼请求**，
很容易触发风控 —— 而风控一旦触发是**所有账号一起受影响**。试水 200 个时
0.65 秒/账号看着很香（全量 86 分钟），但那正是危险的地方：**跑得越快越容易被封**。

## 新作业 `account_overview_refresh`

照「自动巡检」（`ck_health`）那套做，并复用它的两道保护。

| 项 | 默认 | 说明 |
| --- | --- | --- |
| `interval_seconds` | 30 分钟 | 多久一轮 |
| `batch_size` | 30 | 每轮查多少（约 20 秒跑完）|
| `concurrency` | 3 | 并发 |
| `refresh_days` | 7（config 可调）| 查过的多久后再查 |
| `enabled` | **False** | 默认关，由运维手动开 |

按默认值：8,000 个约 **3 天**补完，全程不打满斗鱼接口。

## 两类账号**分开**（用户明确要求）

- **没查过的**（`overview_queried_at IS NULL`）**优先**
- 查过的只在超过 `refresh_days` 后重新入选

否则"周期性刷新老账号"会永远挤掉"从没查过的新账号"。
MySQL 没有 `NULLS FIRST`，用 `ORDER BY overview_queried_at IS NULL DESC` 等价实现。

## 只查有效 CK

`ck_check_status == 'valid'`。失效的查了也是白查（只会多一条失败记录），
交给「CK 检测与重登」处理。另外沿用 `cookie_operable_filter()`（有 CK 且无在途尝试）、
排除人工状态（停用/归档）与「不参与自动化」的账号。

## 风控熔断（沿用巡检口径）

一轮里失败率 > 50%（且样本 ≥ 10）就**自己把自己关掉**，交给人确认。
消息里写明可能原因，否则运维只看到"失败率高"会一头雾水：

    失败率过高，已自动关闭作业（大面积失败通常是**被风控**或接口抖动，请先确认再重开）

样本 < 10 不熔断 —— 1 个失败就是 100%，比例没意义。

## 查询记录

每轮都建真实的 `douyu_tasks` 行（payload 标 `source=scheduled_refresh`），
「哪个账号、什么时候、查出来什么」都有据可查，也能在任务列表里
区分「定时巡检」与「人工点查询」。账号上的 `overview_queried_at`
则是"下次该不该再查"的依据。

## 验证

- **镜像库实测**：`本轮查 3 个：成功 3 / 失败 0（剩 7784 个待查）`
- 本地 `TZ=Asia/Shanghai` **632 passed / 6 skipped**；ruff 全绿
- 新增 11 条用例：选择口径（只查有效 CK、没查过优先、refresh_days 可调、
  人工状态排除、batch_size 限流）+ 熔断（高失败率关闭、正常不关、小样本不熔断）
  + 一条回归：计数不能走带 LIMIT 的查询（作业第一版就是这么挂的）
 2026-10-04 21:14:16 +08:00
yml2213 8f231e6edf fix(binding): 角色绑定只看 is_bound_role —— 「是否开通」与「是否绑定角色」是两件事 
用户明确指出：**精英/电竞是否开通，和是否绑定角色没关系**。

## 我确实混了（虽然这次没触发）

`derive_from_bind_info` 里有个兜底：

    if bound_role is True or bound_act is True: return BOUND

`role_bind_status` 这一列问的是「**角色**绑没绑」，而 `is_bound_act` 是
「**活动**维度」的标志 —— 拿它兜底就是把两件事混起来。
一旦有账号 `is_bound_act=True` 而角色未绑，就会报出"角色已绑定"的**错结论**。

## 生产数据证实了用户的说法

查已查询的 196 个账号：

    电竞 opened=False 且 bind=bound  →  **187 个**

也就是**187 个账号绑了角色、但电竞手册压根没开通** —— 两者完全独立。

同时数据也证明 `is_bound_role` 本身就够用（不需要那个兜底）：

    判为 bound 的里面：精英 183 个全都有角色名（0 个没有）
                      电竞 187 个全都有角色名（0 个没有）

## 改法

去掉 `is_bound_act` 的参与，**只看 `is_bound_role`**：

    is_bound_role 真  → bound
    is_bound_role 假  → unbound
    缺失              → None（保持 unknown，别把"没查到"写成"没绑定"）

语义上不再有"把活动当角色"的路径。

## 测试

把两条**编码了旧行为**的用例改掉，并补一条钉住领域事实：

- 只有 `is_bound_act` 没有 `is_bound_role` → **None**（推不出角色结论）
- `{"is_bound_role": True, "manual_type": 0, "expire_time": "0"}` → **bound**
  （绑了角色+没开通，两者独立，不该因为"没开通"而变成别的）

## 验证（本地）

TZ=Asia/Shanghai **620 passed / 6 skipped**；ruff 全绿。
 2026-10-04 21:01:42 +08:00
yml2213 ccd05cba9c feat(overview): 关掉和平小店查询 + 修电竞「已开通」不落库 
## ① 和平小店总开关（默认关）

小店目前是**关闭状态**，但不跳过的话一键查询仍会对每个账号发小店请求，
结果 100% 失败 —— 实测 200 个账号里 `exchange_records_peace` 失败 **195 次（100%）**：

    Livelink登录态校验失败

100% 意味着不是账号问题。这既淹掉真错误、又让人以为出故障。

新增 `douyu_config.peace_enabled`（迁移 `0050`，**默认 False**）。
关着时**完全跳过**小店的所有请求（绑定 + 兑换记录），并且**不记 errors** ——
「配置成关的」和「查失败」是两回事，混在一起会让 errors 失去意义。

将来小店恢复，在后台打开这个开关即可；打开后小店失败仍会**如实暴露**
（有用例专门钉住这一点，别把开关当成遮羞布）。

## ② 修：电竞手册「已开通」不会被一键查询更新

用户问"电竞到期时间为什么拿不到"，查下去发现**两层**：

**第一层不是 bug**：那 200 个账号 `esports_opened` 全是 0（没开通电竞手册），
所以 `expireTime="0"`、没有到期时间可存。注意
**"电竞已绑定角色"≠"电竞手册已开通"**。实测 `opened_but_no_expire = 0`，没有异常。

**第二层是真 bug（不对称）**：

    _refresh_elite_handbook   → 写 account.elite_opened  ✅
    _refresh_esports_handbook → 不写 account.esports_opened ❌

`esports_opened` 只在"开通"任务里被设置，所以**详情页电竞的「已开通/未开通」
根本不会被一键查询更新**。已改成与精英对称（口径同 create_esports_qr：
`manual_type >= 1` 即已开通）。

## 测试（+2）

- 小店关着时：**不发**小店请求、**不查**小店绑定、**不记** peace 相关的 errors，
  且结果里标明 `peace_skipped`
- 小店打开时：失败**仍然如实暴露**（反向用例，防止开关变成遮羞布）

## 验证（本地）

TZ=Asia/Shanghai **620 passed / 6 skipped**；ruff 全绿。
 2026-10-04 20:59:17 +08:00
yml2213 631e33a4f6 fix(events): 撞唯一键是幂等命中，不该刷 WARNING + dump 整条 SQL 
## 现象（用户从日志里发现的）

    WARNING | 写入账号事件失败（account=60 exchange）：
    (1062, "Duplicate entry 'official_exchange:elite:60:20260120QYOOB_bag360:...'")
    [SQL: INSERT INTO account_events (...) VALUES (...)]
    [parameters: {...}]

## 分析：**不是 bug，是幂等机制在工作，但日志级别错了**

`emit()` 刻意**不做预检查**，直接 INSERT，靠 `source_ref` 的唯一索引去重；
撞了就 catch（SAVEPOINT 只回滚这一条）。所以：

- **数据是对的** —— 重复的被挡住，`exchange_events_added` 只计新写入的
- **日志是错的** —— 撞唯一键被当成异常打 WARNING，还把整条 SQL + 参数 dump 出来

而"撞唯一键"在这里是**预期内的正常情况**：一键查询会把斗鱼官方兑换记录补成事件，
同一个账号会被反复查询 —— 第二次开始每条记录都会撞。一次查询能刷几十屏，
既淹掉真日志、又让人以为出事了（用户就是因此来问的）。

## 修法

区分「唯一键冲突」与「真错误」：

- 确认是 **1062**（并带 `Duplicate entry` 字样）→ 降为 **DEBUG**，一句话说明"已存在，跳过"
- 其它完整性错误（如非空约束 1048）→ **仍然是 WARNING**

刻意**不把 IntegrityError 整个静音** —— 那会把真问题一起藏起来。
新增 `_is_duplicate_entry()` 只在两种信号都对上时才降级。

## 测试（+3）

- 重复写入返回 False，且**不产生**任何 "写入账号事件失败" 的 WARNING
  （用 loguru 的临时 sink 真的抓日志来断言，不是看代码）
- 重复写入不会写进第二条
- `_is_duplicate_entry` 只认 1062，1048（非空约束）仍然返回 False
 2026-10-04 20:35:24 +08:00
yml2213 6b5271c983 feat(account): 一键查询补上「角色绑定状态」—— 以前从来没人查过，97% 显示"未知" 
## 问题（用户："这个做了吗？我看好像都是未知"）

**只做了一半**：

- 列的拆分做了（S6）：三列存在、写入收敛到 set_bind_status、迁移映射与运行时对齐
- 但**没有任何一处真的去查绑定状态**（grep -c bind_info douyu_runner_overview.py = 0）

那三列的值从来不是查来的，而是 S6 迁移时从旧的垃圾场列 bind_status
**能推的推、推不出的留 unknown**。只把明确陈述了绑定事实的旧值映射过来
（bind_confirmed → bound、bind_qr_generated → pending、game_not_bound → unbound），
其余一律 unknown —— 因为旧列被"查限兑商品""送礼物"这类**无关动作**覆盖过，
从无关动作推绑定状态就是造假。当时留 unknown 是对的，但结果是：

真实生产分布（15182 个账号）
  精英 unknown 14683 (96.7%)   电竞 14730 (97.0%)   小店 15045 (99.1%)

## 修法：真的去查，用唯一写入者写回

一键查询新增三个绑定查询（接口都已存在，活动别名走后台配置）：
bind_info / esports_bind_info / xpd_bind_info。

新增 derive_from_bind_info() 把返回推导成 4 态，**并做了实测校准**：

  账号  列值(旧)   is_bound_role   角色名            推导
  51    unknown     False           (空)              unbound
  60    unknown     True            唉清静的一生      bound
  61    unknown     True            柿子洋音          bound
  62    unknown     True            FatalistIc        bound

**4 个里 3 个其实已绑定，全被 unknown 盖住了。**

两个刻意的设计：

1. **推导不出来时返回 None，且不动原值** —— "没查到"和"没绑定"必须分开，
   写 unbound 就是编造结论（小店未开通、返回里没有标志时实测就是这种情况）
2. **不产出 pending** —— 它描述"正在绑定/待确认"这种**进行中的动作**
   （如刚生成过二维码），那是一次查询的副作用，不是查询能观测到的状态
3. need_bind_role **不是**"未绑定"的信号：实测**已绑定**的账号上它也是 1，
   拿它当判据会把这 3 个已绑定的判成未绑

端到端实测（账号 51）：

  查询前: 精英=unknown  电竞=unknown  小店=unknown
  查询后: 精英=unbound  电竞=unbound  小店=unknown  ← 推不出来，正确保持原值

## 显示：把"没查过"和"查了推不出"分开

三处都改了（用户要求）：全 unknown 时不再显示「精? 电? 店?」，
而是 **未查询**（点一键查询就有了）/ **未能判定**（斗鱼这次没给结论）。

## 验证（本地）

TZ=Asia/Shanghai **615 passed / 6 skipped**；ruff 全绿；前端 build 通过、lint 0 errors。
新增 9 条用例（含"need_bind_role 不是信号"的反向回归）。
 2026-10-04 20:22:54 +08:00
yml2213 85a6186993 feat(account): 电竞手册到期时间落库与展示；迁移 0048 改名 
## 背景（用户反馈）

「精英宝典和电竞手册已开通的话，应该增加时间展示，可以看到开通时间和过期时间」

- 精英宝典：开通时间来自事件；过期时间 `elite_expire_time` 本来就有
- 电竞手册：开通时间来自事件；**过期时间原来没有落库** ——
  只在 `_refresh_esports_handbook` 的返回值里带着，界面上只能看到「已开通」

## 改动

- 新增 `accounts.esports_expire_time`（迁移 0049，与 `elite_expire_time` 对称），
  刷新电竞手册时写回
- 详情页：**已开通才显示**「开通 x / 到期 x」两行小字；顺手删掉底部那段
  重复的「开通时间」说明（已挪到每项旁边）
- 新增 `formatUnixSeconds()`：斗鱼的到期时间是**秒级时间戳**，
  原 `formatTime()` 只收字符串；新函数对 `0`/空/负数一律显示 `-`

## 明确回答：历史开通记录**查不到**

实测官方兑换记录里**只有商品兑换、没有开通记录**（账号 61：精英 2 条都是套装）。
我们自己的 `elite_opened` / `esports_opened` 事件也只有上线后的。
所以历史上的开通时间拿不回来 —— 按用户说的「没有就算了」，
并把这点写进界面说明，别再让人去找。

## 测的时候抓出一个真 bug（又是 1970）

电竞到期时间的 `"0"`（斗鱼用它表示「没有到期时间」）被原样存成 `0`
→ 界面会显示 **1970/1/1**。已修（`0`/空 → `None`）并加回归用例 ——
这个坑在积分到期上踩过一次，这次差点重演。

## 迁移 0048 改名

`20261004_0048_overview_summary.py` → `20261004_0048_high_value_owned.py`：
上一轮把内容从「汇总」收敛成单一用途的 `high_value_owned`，文件名没跟着改。
revision id 不变、迁移状态不受影响；同时清了 `__pycache__`
（本仓库被过期 `.pyc` 咬过，症状是「改了没生效」）。

## 验证（本地）

`TZ=Asia/Shanghai` **608 passed / 6 skipped**；ruff 全绿；前端 build 通过、lint 0 errors。
 2026-10-04 20:17:05 +08:00
yml2213 6865b916ba test(account): 一键查询 / 官方兑换记录 / 生命周期用例 
围绕这几轮改动补齐用例（本文件共 53 条）：

- **判定规则**：只看官方兑换记录；全局库存**永不**推出「该账号已拥有」
  （回归用例 —— 正是第一版踩的坑）；字段缺失是 None（未知）而不是 False（没有）
- **失败隔离**：单项外部调用失败不影响其余，且如实写进 errors
- **只读性**：一键查询不发事件、不改生命周期状态
- **官方记录补成事件**：带**真实兑换时间**（不是"发现它的时刻"）、
  幂等（重复查询不重复落）、无 commodityId 时跳过
- **排序回归**：「最近一次兑换」按事件时间，不是插入 id
- **时间归一化**：0 / "0" / 空 / 负数 → None（1970 那个 bug 的回归）
- **迁移安全**：不得在迁移里 commit(op.get_bind())；加列前必须有存在性检查
  （扫代码时**跳过注释** —— 注释里正解释着"不要这样做"，第一版用例因此假红）
- **接口契约**：详情返回快照与查询时间、列表**不**带整份快照；
  断言一律看 model_dump()（只看属性会假绿 —— AccountOut 有手写
  @model_serializer，字段没列进去时属性有值、JSON 里没有）

另修两条**把 bug 当期望值**的既有用例：

1. 「最近一次兑换」原断言的是最后**插入**的那条（旧行为按 id 排），
   改为真正最近的（按事件时间）；
2. 按用户名查找夹具不可靠（make_account("key") 每次建新账号、库里一直累积），
   改为按 id 精确查找。
 2026-10-04 20:04:11 +08:00
yml2213 aea05952af refactor(account): 一键查询不该重复展示账号字段 —— 改成刷新它们，只留账号表里没有的 
用户反馈：「一键查询也太重复了，直接更新账号信息不行吗？为啥很多都要再展示一次？
那建立账号信息表有啥用」——**说得对，是我设计错了**。

## 问题

面板把鱼翅 / 积分 / 钱包余额 / 精英宝典 / 电竞手册又原样列了一遍，
而这些账号表（`accounts`）本来就有对应列，账号详情也在显示同一批值 ——
同一屏出现两份，既冗余又让人分不清哪份是准的。

## 改法：查询 = 刷新，不是另开副本

| 内容 | 处理 |
| --- | --- |
| 鱼翅 / 积分 / 交易余额 / 开通状态 | 写回**账号表**（`_refresh_*` 本来就在写），由账号详情已有界面展示 —— **面板不再重复** |
| **积分到期时间** | 有 `accounts.points_expire_at` 列，但**查询漏了没写、界面也没显示** → 现在写回，并加到账号信息区展示 |
| **高价值套装是否已获得** | 账号表没有 → **只有这个该单独展示** |
| **官方兑换记录** | 账号表没有 → 单独展示 |

面板因此瘦身成只含「🎯 高价值套装」+「兑换记录」（+ 错误提示 + 查询时间），
标题也改成「高价值套装与兑换记录（一键查询）」，不再叫"账号信息"。

## 修了一个连带 bug

积分到期时间一直没被查询写回账号（只在快照里躺着），界面也没展示 ——
现在 `_parse_expire_at` 后写入 `accounts.points_expire_at`，
且斗鱼返回 `0` 时写 `None` 而不是 `0`（否则又显示 1970/1/1）。

## 测试（+3，共 41）

`TestOverviewRefreshesAccountFields`：资产/开通状态确实写回账号列、
**积分到期时间写回**、`willExpireTime="0"` 时清成 None 而非 0。

## 验证

`TZ=Asia/Shanghai` **593 passed / 6 skipped**；ruff 全绿；前端 build 通过、lint 0 errors。
 2026-10-04 19:22:34 +08:00
yml2213 c2520613ca fix(account): 修一键查询「一直循环」—— 快照字段加到了列表接口而不是详情接口 
用户报：账号详情点「一键查询」会一直循环（Network 里刷一片 `overview` 请求）。

## 根因

上一轮我把 `overview_snapshot` / `overview_queried_at` 加到了**列表**接口
（锚点 `**bind_payload(acc),` 第一次出现的位置在列表构造器里），详情接口没有。
两层后果：

1. **详情不返回 `overview_queried_at`** → 前端 `marker !== before` 永远相等
   → 轮询到 120 秒超时。看起来就是"点一下一直转圈刷请求"。
2. **列表每个账号都带一整份 JSON 快照** → 15000 个账号的响应体积爆炸
   （这个是我自己引入的回归，比第一个更隐蔽）。

## 修法

- 字段从**列表**移除、加到**详情**（列表刻意不返回，注释写明原因）
- 前端轮询**加自证**：第一次拿到响应时若没有标记字段，**立刻报错退出**，
  而不是傻等 120 秒 —— 这类"字段没返回"的 bug 不该再以死循环的形式暴露

## ⚠️ 过程中我又踩了一个，被既有用例抓住

删那 4 行时**把 `**bind_payload(acc),` 一起删掉了**，导致列表不再返回绑定列
（`role_bind_status` 显示的是 Pydantic 默认值 `unknown`）。

`TestListViewKeyColumns::test_item_carries_key_columns` **立刻变红** ——
既有用例替我把这个真回归挡下来了。已恢复，并确认 diff 只剩预期的 3 行。

## 新增回归用例（+2，共 38）

`TestSnapshotExposedOnDetailOnly`：
- 详情**必须**返回快照与查询时间（不返回前端就会轮询到超时）
- 列表**不得**返回完整快照（每个账号一份 JSON，体积爆炸）

并做了**反向验证**：把"详情不返回字段"的 bug 注入回去 → 用例立刻红。

另外把 `TestListViewKeyColumns::_item` 按用户名查找改成按 id ——
`make_account("key")` 每次建新账号而库里一直累积，按用户名可能命中很早以前那个
（这次就让用例假红过一次）。

## 验证

`TZ=Asia/Shanghai` **590 passed / 6 skipped**；`TZ=UTC` 80 passed；
ruff 全绿；前端 build 通过、lint 0 errors。
 2026-10-04 19:19:53 +08:00
yml2213 3866b49087 fix(account): 一键查询按反馈收敛 —— 只在账号管理展示、结果落账号、修 1970 显示 
按用户反馈改了四处。

## ① 结果只在账号管理展示（不再出现在精英宝典/电竞手册页）

移除了工作台页的结果弹窗与导入。**类型集合保留**（三个工作台都有）——
因为账号页批量建任务要用 `handbook_scope` 过 `DOUYU_HANDBOOK_TASK_TYPES` 校验，
去掉会被「该任务不属于当前工作台」拦掉；去掉的只是**快捷操作按钮**。

## ② 不再每次弹出

原来任务跑完就自动弹面板，而且任务会被反复轮询到。现在整个弹窗机制去掉了：
结果落在账号上，打开账号就能看。

## ③ 结果写进账号（新增迁移 0047）

新增 `accounts.overview_snapshot`（JSON）+ `overview_queried_at`，覆盖式只留最新一份。
详情页直接读账号上的快照，不再轮询任务。

**为什么放账号而不是只留任务里**：任务会被保留策略清掉（长保留档 90 天），
而「这个账号现在什么情况」是**账号的信息**，不该依赖一条日志的寿命。

## ④ 修 1970/1/1 08:00:00（真 bug）

斗鱼用 `0` / `"0"` / 空串表示「没有这个时间」。原实现直接透传，
前端 `new Date(0)` → **1970/1/1 08:00:00** —— 运营会以为"到期时间是 1970 年"。

两端都修了：
- 后端新增 `_ts()`，把 `0`/`"0"`/空/负数 归成 `None`（积分到期、宝典到期、
  电竞到期、商品活动时间四处都过一遍）
- 前端 `formatTime` 也把 `0`/负数显示成 `-`（上游再出错也不至于显示 1970）

## 测试（+14 条，共 36）

- `TestTimestampNormalisation`：`0`/`"0"`/空/负数 → `None`；真实时间戳透传
- `TestSnapshotIsWrittenToAccount`：快照与时间落到账号上、
  **`willExpireTime="0"` 不能落库成 0**（1970 的回归用例）、覆盖式不追加

## 验证

`TZ=Asia/Shanghai` **588 passed / 6 skipped**；`TZ=UTC` 41 passed；
ruff 全绿；前端 build 通过、lint 0 errors。
 2026-10-04 19:12:51 +08:00
yml2213 d285196287 feat(account): 账号「一键查询」（异步 + 批量）—— 含一次重要的判定修正 
按 `docs/设计-账号一键查询.md` 实现。异步任务、支持批量（后端每账号一条任务）。

## 功能

- 新任务类型 `query_account_overview`：**只读**聚合查询，不改账号状态、不发事件
  （纯查询不是「事实」，按既有设计例行查询不进时间线，否则会刷屏）
- 一次拉全：鱼翅 / 钱包兑换余额 / 积分（含到期）/ 精英宝典 / 电竞手册 /
  **官方兑换记录** / 限兑商品，并**重点标出「兔兔白日梦」「狂战萌兔」是否已获得**
- **单项失败不整体失败**：账号没绑电竞手册是常态，失败只写进 `errors` 并在 UI
  **如实展示** —— 避免「没查到」被读成「没有」
- 批量：`create_douyu_planned_tasks` 本来就是每账号一条任务，前端加「批量一键查询」
- 前端：详情页一键查询卡片 + 结果面板（两个套装单独高亮）；任务页结果自动弹面板；
  三个工作台的快捷操作/类型集合都加了

## ⚠️ 修正：判定「是否已获得」用错了依据

设计文档第一版说「`storeStatus == 0` → 已拥有」，依据是
「账号 558（兑换过）count=0，账号 15407（没兑换）count=96982」。

**这是错的。** 那两条记录分别取自 **2026-08-01** 和 **2026-10-04**，相隔两个月 ——
我把**时间差异**当成了**账号差异**。

**同一时刻**同时查 558 / 607（都兑换过）和 15507（没有），
商品项的**所有字段完全一致**，`preExchange.isExists` 也都是 0；
`count` 的取值分布是 0/98746/103350/109832…，**随时间变化 = 全局库存**。
用它判「这个账号有没有」必然给错结论 —— 而对高价值资产给错结论是本功能最不能接受的。

**正确依据：`exchange_records(manual_id)`**（斗鱼官方的**账号级**兑换记录）。
真实斗鱼实测：

| 账号 | 官方兑换记录 | 判定 |
| --- | --- | --- |
| 558 | 破片手榴弹-兔兔白日梦 | **已获得 ✅** |
| 607 | 破片手榴弹-兔兔白日梦 | **已获得 ✅** |
| 15507 | （0 条） | 未获得 ✅ |

同时刻三者看到的兔兔白日梦库存**都是 96956**（全局），兑换记录却区分得干干净净。

顺带发现：同一件东西有多个商品名（`套装-兔兔白日梦`、`破片手榴弹-兔兔白日梦`），
所以按**核心词子串**匹配整个名字家族。

商品列表的 `score`/`count`/活动时间仍展示，但明确是**全局**信息
（「现在还能不能换、要多少分」），与「该账号是否已获得」分开。

## 测试

`tests/test_account_overview.py` 22 条，含**回归用例**：
`test_global_stock_never_implies_owned`（全局售罄不能推出账号拥有）——
正是第一版踩的坑。另有失败隔离、只读性（不发事件/不改状态）、
批量每账号一条任务、`missing` 不被静默丢弃。

## 验证

- `TZ=Asia/Shanghai` **574 passed / 6 skipped**；`TZ=UTC` 27 passed
- ruff 全绿；前端 build 通过、lint 0 errors
- **真实斗鱼端到端**：三个账号各跑一次真查询，8 项全部成功（`errors: []`），
  已获得/未获得判定全部正确
 2026-10-04 19:07:35 +08:00
yml2213 2f610a53e3 feat(ops): S1–S7 上线清单 + 回滚前置脚本（已在生产克隆库完整演练） 
生产还停在 `20261003_0040`，S1–S7 一条都没上。本次在**生产克隆库**上把
「迁移 → 校验 → 回滚」完整走了一遍，并把可执行的清单落成文档。

## 演练结果（克隆库，与生产逐项同构）

| 步骤 | 结果 |
| --- | --- |
| 克隆生产库 | 15,182 账号 / 14,324 CK / 版本 `0040` / 27 张表，与生产一致 |
| **迁移全链 0041→0046** | 6 个迁移，**9 秒**，无错误（含 S1 的 fail-closed 自校验） |
| 账号数 | 15,182 ✓ 不变 |
| **CK 搬运** | 账号侧 14,323 = 登录记录侧**去重账号数 14,323**（精确相等）|
| 精英/电竞映射 | bound 410 / pending 75 / unbound 14；电竞 **unbound 26**（修复生效）|
| `esports_opened` | **4** ✓（抢救生效）|
| `source_ref` 可空 | `YES` ✓ |
| **回滚降级** | 6 个迁移，**2 秒**；`bind_status` 原值完好、两列回到 `varchar(32)` |

## 🔴 演练查出的关键风险（不演练绝对发现不了）

S2 之后 CK **只写 `accounts.cookie`、刻意不双写** `login_tasks.cookie`。
而降级会 **drop 掉 `accounts.cookie`** —— 也就是：

> **部署期间新拿到的 CK，会在回滚时全部丢失。**

CK 丢失是本项目唯一不能承受的损失（重登成功率≈0、全量重登≈2.7 天）。

于是新增 `scripts/backfill_login_tasks_from_accounts.py`（**回滚前置**）：
把账号侧 CK / 健康 / 重登进度搬回旧列；没有历史行的账号补一条合成行
（否则旧代码靠 `login_tasks` 找不到它的 CK）；没有 CK 的账号清掉旧行残留
（否则旧代码以为它还持有 CK）。自带 `--dry-run` 与**自检**
（账号侧 ≤ 登录记录侧去重数，不通过就别降级）。

**同样在克隆库上验证过**：模拟「部署期间新拿到一个 CK」→ 跑回填 → 降级 →
**该 CK 完整幸存**（task#100 / 账号 168）。不跑回填的话它就没了。

## 补齐了之前做不到的那项验证

本地没有生产的加密密钥，所以之前只验证了 CK「搬过去了」、没验证「能解密」。
这次**在生产上只读实测**：抽样 5 条 `login_tasks.cookie`，**5/5 解密正常**
（长度 1613–1660）。这是清单里第 1 节的部署前基线。

## 交付物

- `docs/上线清单-S1-S7部署.md`：部署前检查 / 执行顺序（**先停应用→迁移→再起代码**）/
  七项逐条校验 / 回滚预案（含正确顺序）/ 已知限制 / 演练证据
- `scripts/backfill_login_tasks_from_accounts.py` + 2 条用例
  （搬回已有行、无历史行时补合成行）

## 验证

`TZ=Asia/Shanghai`：**552 passed / 6 skipped**；ruff 全绿。

⚠️ 清单里写明：**S8（删旧列）本次不做** —— 要等稳定运行 + 逻辑备份之后。
 2026-10-04 18:18:30 +08:00
yml2213 0b1fc1dee0 feat(events): 补齐资产【出项】—— 开通金额、鱼翅消耗、积分到期（C 最全） 
审「哪些操作该进账号生命周期」时发现：**进项有账、出项没账** ——
充值/积分到账都有金额，而开通（花积分）、送礼（花鱼翅）几乎没记，
于是「一共充了多少」算得出来，「花哪儿了」算不出来。

按确认的范围一次做完（应用宝充值**不动** —— 它按游戏角色记账、且未启用）。

## A. 开通类事件补金额

`elite_opened` / `esports_opened` 以前只记「开通后的积分余额」，不记**花了多少**。
现在补 `amount = -(开通前后积分差)`，并用**实测余额差**而不是"开通要多少分"的常量
（活动价、折扣会让实际扣减不同）。任一侧拿不到就不写金额，不编数字。

## B. 鱼翅消耗事件（新 `gold_spent`）

送礼以前只发「积分到账」，**花掉的鱼翅没有任何记录**。现在：
- 送礼**前后各刷一次**鱼翅（原来只在送礼后刷），取**实测余额差**；
- 发 `gold_spent`，`amount` 用负数（与 `exchange` 一致）；
- 余额没减少或拿不到 → **不发**：宁可少一条，也不要记一笔没发生的消耗。

## C. 积分到期（新 `points_expire`）

积分到期是资产真实减少，但**斗鱼不会通知** —— 只在积分查询里给 `willExpireTime`。
所以：
- 新增 `accounts.points_expire_at`（迁移 `0046`），送礼流程学到就写下来；
- 新增作业 `points_expire_check`：扫「已到期且积分未归零」的账号，补写事件并清标记
  （不重复记）；积分已为 0 则只清标记、不发事件（避免 `-0` 噪声）。

⚠️ **金额的诚实边界**：到期那一刻**到底扣了多少，我们没亲眼看到**。
所以默认 `confirmed=False`、标题带「（预计）」，记的是「当时余额」这个**预计要归零**的数量，
**不假装它是确认过的扣减**。作业刻意不发网络请求（纯 DB 可跑、不需要 CK），
要变成已确认只能由「到期后重查、真看到余额下降」的调用方补。

## 顺带修掉一个会静默丢事件的坑

同一个任务可能产生**两条事件**（送礼：既「积分到账」又「消耗鱼翅」）。
`source_ref` 是唯一键 —— 共用 `task_ref(task_id)` 会让**后写的那条被静默丢弃**。
已让副事件带后缀（`douyu_task:{id}:gold`），主事件保持原形态（与旧收集器一致）。
有用例专门钉住「一个任务两条事件都不丢」。

## 验证

- `TZ=Asia/Shanghai`：**550 passed / 6 skipped**（+18 条）
- `TZ=UTC`（事件 + 迁移 + 绑定）95 passed；ruff 全绿；前端 build 通过、lint 0 errors
- 真实开发库：迁移 `0046` 已应用；作业烟测 → 扫到 1 个到期账号，
  写入「积分到期 -500（预计）」`confirmed=False`，标记被清、重跑不再重复

## 现在的资产流水（斗鱼侧）

| 方向 | 覆盖 |
| --- | --- |
| 进项 | 充值（二维码/供应商/回调三路径去重）✅、积分到账 ✅ |
| 出项 | 兑换 ✅、**开通 ✅（新补金额）**、**送礼鱼翅 ✅（新）**、**积分到期 ✅（新，标预计）** |
| 未动 | 应用宝充值（独立系统、按游戏角色记、当前未启用） |
 2026-10-04 18:10:46 +08:00
yml2213 4c1fe0c84f fix(account): 补上电竞绑定映射漏掉的 game_not_bound（连生产库才发现的） 
把生产库克隆到本地做部署演练时，拉了三列绑定状态的**真实取值全集**，发现
`esports_bind_status` 里存在 `game_not_bound`（生产 26 行），而我的映射表里没有它
—— 会被归成 `unknown`，可它明明在说「没绑定」。

第一版映射只覆盖了文档里举的几个例子。**教训：映射表必须拿真实取值全集核对。**

修法：Python 映射与迁移 `0044` 的 CASE 同步补上 `game_not_bound → unbound`
（两者有逐字比对用例，不会分叉），并新增一条用**生产实测取值全集**驱动的用例
（17 + 11 + 9 个取值），以后往这三列加新取值时会被提醒确认语义，
而不是默默变成 `unknown`。

已在生产克隆库上验证：电竞列 unbound 从 0 变成 26（正是那批）。
 2026-10-04 17:49:02 +08:00
yml2213 eec42aa8a7 feat(check): 账号检测新增「按账号选择」—— 旧的手动输入与逻辑完整保留 
按反馈是**增加**而不是**替换**：旧路径一行未动，新路径另起一条。

## 两套来源并存

| | 手动输入（旧，默认） | 选择账号（新） |
| --- | --- | --- |
| 来源 | 粘贴文本 | 库里账号的凭据（不用人工粘贴） |
| 条目 `account_id` | **无** | 有 |
| 结果落账号时间线 | **否**（保持旧行为） | 是，新事件类型 `account_check` |
| 批次 / 并发 / 重试 / 代理 / 导出 zip | 完全不变 | 完全不变 |

**旧路径的「不发事件」是刻意的**：粘贴进来的账号没有归属，凭空造一条没有账号的
事件只是污染时间线。`parse_account_check_lines`、`export_line`、zip 分组全部未动，
有用例专门钉住这一点。

## 「选择账号」支持筛选（按反馈补充）

不是给一个扁平下拉，而是先按条件缩小范围再决定选法：

- 筛选：**标签 / 生命周期状态 / CK 健康**（复用账号列表同一套 `_filter_accounts_query`，
  两处口径不会不一致）
- 选法：手动多选（选项随筛选刷新）**或**「按筛选全选」（含列表里没显示出来的）

服务端支持 `select_all_matching + 各筛选条件`，与账号列表批量操作的字段形状一致。
可见性沿用账号域口径：客服只能检测自己名下的账号（越权 id 直接 403）。

## 结果表加账号回链

「选择账号」模式下条目带 `account_id`，账号列变成可点链接 → 直接跳到账号详情，
结果也在那里的时间线上。

## 排查中修掉两个 bug（都不是测试发现的）

**① `registry.create` 漏传 `account_id`**
它构造 `AccountCheckItemState` 时没把 `account_id` 从输入复制过去。
后果：批次照跑、结果照显示、zip 照导出，**事件永远不发且没有任何报错**。
是「跑一次真实检测再查事件表」才发现的（查出来 0 条）。已补，并加了用例。

**② 终态判断写成「键存在」而不是「非空」**
`_run_one` 置 `running` 时会显式传 `finished_at=None`，而判断写的是
`"finished_at" in updates` → **中间态也发事件**，于是时间线上记的是
`账号检查：running`；真正的终态再发时撞同一个幂等键被**静默丢弃** ——
结果是「只有一条，但记错了」，比没有更糟。

改成判非空。此处暴露了一个**假绿的用例**：我原来的「中间态不发事件」用例
没传 `finished_at=None`（与真实调用不一致），所以放过了这个 bug；
而且它还缺 `session.commit()`，在 MySQL REPEATABLE READ 下根本看不到
另一个会话刚提交的行 —— 双重假绿。两处都修了，并做了反向验证
（改回旧判断 → 用例立刻红）。

## 验证

- `TZ=Asia/Shanghai`：**520 passed / 6 skipped**（新增 17 条检测模式用例）
- `TZ=UTC`（检测 + 迁移）20 passed；ruff 全绿；前端 build 通过、lint 0 errors
- **真实端到端**：用真实库账号起批次 → 检测跑完（斗鱼返回「账号已认证」）→
  事件确实落库；清掉脏数据后用**与 `_run_one` 完全相同的调用序列**复验：
  两次 `_set_item` 只产生一条事件，且 title 是
  `账号检测：账号已认证`、`status=account_verified`（不再记成 running）

注：验证时真实触发了几次斗鱼登录检测（开发库那两个账号），结果都是「已认证」。
 2026-10-04 17:34:58 +08:00
yml2213 5ae5d92978 feat(account): 兑换记录列 + 修掉 source_ref NOT NULL 导致的事件静默丢失 
三件事合成一次提交（按反馈不再一改一提交）。

## ① 账号列表加「兑换记录」列

次数 + 最近一次（商品名 + 日期），填上列表右侧的空档。

数据源是**账号自己的事件流**（`account_events` 的 `exchange`），不是 `douyu_tasks`
的 JSON —— 后者是执行日志，S5 起业务事实已经在事件里了。

性能上刻意**每页只跑两条聚合查询**（不是每行一条 N+1）：
一条分组算 `count` + `max(occurred_at)`（走 `(account_id, event_type, occurred_at)`
复合索引），一条用窗口函数 `ROW_NUMBER()` 取每个账号最新那条的商品名。
实测 6 个账号 3 条兑换事件，聚合与「最近」都正确。

「兑换 」前缀在前端剥掉（列头已经叫「兑换记录」，再带前缀是重复）。

## ② 修掉一个静默丢事件的 bug（排查中发现的）

**现象**：开发库上「状态变迁 / 分配 / 标签 / 备注 / CK 清除」这些事件**一条都没有**，
而带幂等键的事件（业务事实、`ck_invalid`、`relogin_*`）照常写入 ——
时间线看起来有数据，只是恰好缺了某一类，**极难发现**。

**根因**：`source_ref` 是**可选**幂等键（模型与迁移文件都是 `nullable=True`，
`emit()` 对没有天然幂等键的事件就传 `None`）。但早期那版迁移
（重编号成 `0041` 之前的 `0040`）建的是 **NOT NULL**，而我后来只改了
**迁移文件**、没管**已建好的库** —— Alembic 只记版本号，不会重放已应用的脚本。
`__pycache__` 里那个 `20261002_0040_*.pyc` 就是旧版留下的痕迹。

**为什么静默**：`emit()` 按设计吞掉任何异常（事件是旁路，不能影响主流程），
只记一条 warning，调用方也从不检查返回值。已实测复现：
`emit(...)` 返回 `False` + warning，实际落库 `0` 条。

**修法**：迁移 `20261004_0045` 改回可空（`MODIFY`，**唯一索引保留**，幂等，
生产若跑过旧版也一并修好）。修复后实测：`emit` 返回 `True`、落库 1 条。

## ③ 补一条能防「未来」同类问题的守卫

`tests/test_migrations.py` 原本只比对「表/列/索引在不在」，**不比对可空性**。
已加：迁移建出的列**不允许比模型更严**（模型说可空、库里 NOT NULL）。

只查这个**危险方向**：反方向（模型 NOT NULL、库里允许 NULL）是无害的宽松，
历史遗留里有 28 处，一并报出来只会制造噪声、逼人修没收益的东西。

> 这条守卫**有边界**，已在代码注释与设计文档 §3.5.1 写明：
> 它在**全新库**上跑整链，只能防「未来的迁移建错」，**防不了已有库的历史漂移**。
> 已验证：临时禁用 `0045`，该用例仍通过（全新链本来就是对的）。

## 验证

- `TZ=Asia/Shanghai`：**503 passed / 6 skipped**（+3 条兑换列用例）
- `TZ=UTC`（迁移 + 列表相关）45 passed；ruff 全绿；前端 build 通过、lint 0 errors
- 真实开发库：迁移已应用（head `20261004_0045`），
  `source_ref` 现在 `IS_NULLABLE=YES` 且唯一索引仍在；
  不带幂等键的事件确实能落库；兑换聚合返回值正确

注：验证时在开发库那个有 CK 的账号上留了 3 条 `exchange` 演示事件
（兔兔白日梦 / 冠军鸡腿 / 烟花），是为了让列有数据可看，随时可删。
 2026-10-04 17:25:40 +08:00
yml2213 8a8c637db0 refactor(ui): 账号列表页重做 —— 状态分布当筛选入口，砍掉重复与噪声 
这页还是 S6 之前的老壳子：4 张统计卡有 3 张是装饰、状态与 CK 两列在说同一件事、
ID 单独占一列、绑定列 12 行全是「精? 电? 店?」。

## 统计卡 → 生命周期分布（可点击筛选）

原来：账号总数 / **标签数** / **已分配** / **未分配**。
标签数在筛选里就能看；已分配与未分配是一对冗余；而且它们都回答不了
「我该干什么」。现在按**生命周期状态**分布：总数 / 正常 / CK失效 / 待人工 /
未登录 / 已停用，**点一下就是「只看这些」**（`statusFilter`），计数为 0 的自动变淡。

后端 `accounts_summary` 相应扩出 `by_status` / `visible_total` /
`ck_invalid_count` / `no_cookie_count`。口径与列表一致：**归档不计入**。

## 表格列收敛

| 改动 | 理由 |
| --- | --- |
| **ID 列 → 并入「账号」小字** | 客服不看 ID，但报障时还要念得出来；合并后省一列宽度 |
| **CK 列 → 并入「状态」副行** | 生命周期状态里的「CK 失效」就是 CK 的结论，两列在说同一件事。合并后主标签给结论、副行小字给细节（检测时间 / `error` 这种「状态正常但没查明白」） |
| **绑定列：三个都 unknown 时显示「—」** | 满屏问号只是噪声，不如一眼看出「还没查过绑定」 |
| **「上传时间」→「导入时间」，精确到日** | 名字一直叫错；列表里只关心「哪一批」，时分秒是噪声（精确值挪进 tooltip） |
| **去掉「按状态筛选」下拉** | 上面卡片就是筛选入口，两处并存是重复（`STATUS_OPTIONS` 随之删除） |

## 验证

- `TZ=Asia/Shanghai`：**500 passed / 6 skipped**（+3 条 summary 用例）
- `TZ=UTC`（相关文件）82 passed；ruff 全绿
- 前端 build 通过、`npm run lint` **0 errors**
- 真实开发库：`by_status = {active: 4, imported: 8}`、`ck_invalid_count=0`、
  `no_cookie_count=8`、`visible_total=12`（与库内实际一致）

未动（待确认）：「显示凭据」开关与密码/邮箱/邮箱密码三列 —— 这是老「卖号」视图的残留，
默认关闭所以不占地方，但不确定现在的重登/检测流程还需不需要人工读凭据。
 2026-10-04 16:55:12 +08:00
yml2213 885a780bd3 feat(account): S6 账号页重构 —— 列表关键列 + 详情页生命周期状态卡 
S6 的展示层部分（数据模型部分见上一个提交）。目标：客服打开账号页要能一眼回答
「这账号能不能用、要不要我处理、账上还有多少」。

## 账号列表：加关键列 + 三个筛选

新增四列，**全部直接来自 `accounts` 行**（不 JOIN、不聚合 —— 列表是全站最热接口）：

| 列 | 内容 |
| --- | --- |
| **CK** | 有无 CK / 正常 / 已失效 / 检测异常 + 最近检测时间 |
| **绑定** | 精/电/店 三个作用域各一个小标签（✓ / … / ✗ / ?） |
| **积分 / 鱼翅** | 两行小字 |

新增筛选：**CK 健康**、**角色绑定**（三个作用域任一命中即算）。
`AccountOut` 相应补齐 `has_cookie` / `ck_check_status` / `ck_checked_at` /
`points` / `gold_balance` / 三组绑定状态与标签。

## 账号详情页：生命周期主页

顶部新增**生命周期状态卡**，把之前散落的信息聚成一眼可读的几格：

- **生命周期状态**：状态标签 + 不参与自动化标记 + 变更时间与原因
- **CK**：有无 / 健康 / 最近检测时间
- **角色绑定**：精/电/店三格
- **账上还有多少**：积分 / 鱼翅 / 兑换余额
- **归属与标注**：分配客服（下拉）+ 标签（就地编辑）—— 之前详情页只能看不能改

业务台账补上**登录成功次数**与**最近登录**（`stats` 里本来就有，只是没展示）。
时间线已有分类筛选，生命周期操作入口（停用/归档/恢复/自动化）S3 已加。

## ⚠️ 顺带修掉一个静默 bug

`bind_payload()` 的字段名按**作用域名**拼成了 `elite_bind_status` / `peace_bind_status`，
而 schema 声明的是 `role_bind_status` / `xpd_bind_status`。Pydantic 默认
`extra='ignore'`，于是多出来的键**被静默丢弃**、声明过的字段保持默认值 ——
**接口永远返回 unknown 而不报任何错**（这正是它躲过前面几轮测试的原因）。

修法：前缀改为由**列名**推导（`SCOPE_PAYLOAD_PREFIX`），并在模块导入时自检
「载荷前缀 == 列名前缀」。另加两条用例：`bind_payload` 的键必须都被
`DouyuTaskAccountOut` / `AccountOut` 声明（这是能抓到这类错的那种用例）。

顺带发现我自己之前那条 payload 用例**把错误的前缀当成了预期**，一并修正。

## 自己踩的坑

详情页加客服列表时又把 `useEffect` 写在了早期 `return` 之后 ——
和本次会话前面修 `LoginTasksPage` 的是同一个错。eslint（`react-hooks/rules-of-hooks`）
当场抓住，已上移。**`tsc` 与 `vite build` 都不会报这个**。

另外：列表关键列那处编辑我曾以为已生效（脚本打印了成功），实际没落到文件里 ——
后面是靠「读回文件确认」和用例失败才发现。已改为每次都读回核对。

## 验证

- `TZ=Asia/Shanghai`：**497 passed / 6 skipped**（S6 前半 490 → +7）
- `TZ=UTC`（相关文件）通过；ruff 全绿；前端 build 通过、lint **0 errors**
- **真实开发库端到端**：列表与工作台接口都返回了真实值
  （`has_cookie=True` / `ck_check_status=valid` / `role_bind_label=未知`），
  修 bug 前这两处返回的是被丢弃后的默认值

未做：`bind_status` 旧列待 S8 drop；保留策略里「状态派生类查询」已可下探到 7 天档（待确认）。
 2026-10-04 16:45:39 +08:00
yml2213 a64380fbcc feat(account): S6 bind_status 三列拆解 —— 四值枚举、唯一写入口、前端改读账号 
`accounts.bind_status` 是个**语义垃圾场**：一个自由文本列，6 个文件、**29 处写入**、
20 多种取值，混了三种东西 —— 真状态（`bind_confirmed`）、动作痕迹（`goods_locked`）、
纯查询痕迹（`points_queried`）。它是**覆盖式**的，所以 `bind_confirmed` 会被之后
任意一次查询盖掉 —— 「这个账号到底绑没绑」根本查不出来。
`esports_bind_status` / `xpd_bind_status` 是同一个病。

## 收敛成四值 + 三列一义

`unknown` / `unbound` / `pending` / `bound`，每个作用域一列：

| 列 | 作用域 |
| --- | --- |
| `accounts.role_bind_status`（**新增**） | 精英宝典角色 |
| `accounts.esports_bind_status`（收敛） | 电竞手册角色 |
| `accounts.xpd_bind_status`（收敛） | 和平小店角色 |

- 新增 `services/account_binding.py`：唯一写入口 `set_bind_status()`，
  传旧自由文本直接 `ValueError`（否则垃圾会被写回去）；`map_legacy_bind_status()` 负责旧值映射。
- **29 处自由文本写入全部删除或改走枚举**：真状态走枚举，动作/查询痕迹**不再写状态列**
  （动作已由 S5 的直发事件记录，查询痕迹本来就不该是状态）。
- `accounts.bind_status` 保留原值便于比对，**已无任何写入方**，待 S8 drop。
- 一条**源码扫描用例**禁止任何地方再出现 `account.bind_status = "..."` 这类写入。

## 回填不猜（设计文档 §5.5）

只映射**明确陈述了绑定关系**的取值（`bind_confirmed`/`esports_bound`/`xpd_bound` → bound，
`*_qr_*`/`*_ready` → pending，`game_not_bound`/`xpd_not_bound` → unbound），
**其余一律 unknown**。因为列是覆盖式的，「最后一件事是查询」并不代表没绑定。
迁移 SQL 与 Python 映射有一致性用例：**解析迁移源码里的 CASE 逐条比对**
（已反向验证：故意改错一条映射，用例立刻红）。

## ⚠️ 顺带救回一个差点被我自己丢掉的状态

「**电竞手册是否已开通**」以前**只寄生在 `esports_bind_status` 的 `esports_opened`
取值里**（`elite_opened` 有独立布尔列，电竞没有）。归一化会把那个取值抹成 `unknown`
→ **静默丢状态**。所以：
- 新增 `accounts.esports_opened` 布尔列（与 `elite_opened` 对称），开通任务成功时置位；
- 迁移里**必须先 `save_esports_opened()` 再归一化**，顺序用例钉住；
- 详情页「电竞手册」开通状态改读 `esports_opened`。

## 前端不再从任务日志反推账号状态

工作台原来从**当前加载的那一页任务**里挑每个账号最新的一条来推绑定状态
（`latestConfirmBindTaskByAccount` 等）。两个问题：① 支撑任务一旦翻出窗口，
**显示的状态就是错的**；② 这让任务日志变成「账号状态库」，于是它永远不敢清理。

现在状态读账号字段，任务日志只补「扫码流程中的瞬时信息」（如确认前的
`pending_role_name`）。删掉了两个不再需要的派生与对应的 `clearPending` 绕行逻辑。

## 踩到并修掉的东西

- **模型与迁移不一致**：我把模型收窄成 `String(16)`，迁移却留着 `String(32)` ——
  测试库按模型建、生产按迁移建，两边列宽不同。已让迁移也收窄，且**收窄必须在
  归一化之后**（旧取值最长 19 字符，先收窄会截断成废值）。downgrade 也补齐了反向操作，
  已实测 `downgrade -1 && upgrade head` 干净。
- **parity 用例第一版是抄了一份 SQL**（迁移改了用例也不会红，等于没测）——
  改成解析迁移源码；后来又因为列已收窄、19 字符的旧值塞不进测试库，
  干脆改成源码级解析比对（不造数据）。

## 验证

- `TZ=Asia/Shanghai`：**490 passed / 6 skipped**（S5 后 450 → 净增 40）
- `TZ=UTC`（相关文件）106 passed；迁移链 3 passed；ruff 全绿
- 前端 `tsc -b && vite build` 通过、`npm run lint` **0 errors**
- 真实开发库：迁移重放后三列均为 `varchar(16) NOT NULL DEFAULT 'unknown'`；
  12 个账号的旧值 `elite_status_queried`（纯查询痕迹）→ **unknown**（没有猜成 bound）

未做（后续）：S6 的**账号页重构**（列表关键列 / 生命周期主页）保留；
`bind_status` 旧列待 S8 drop；保留策略里「状态派生类查询」现在技术上可下探到 7 天档，
保守起见留待确认（影响的是在用页面显示，不是历史）。
 2026-10-04 16:28:06 +08:00
yml2213 6e729e7a80 feat(account): S5 业务事实直发事件 + 删掉收集器 + 任务日志保留策略 
时间线从此覆盖**全部**业务事实，`douyu_tasks` 也有了可控的增长边界。

## 一、删掉收集器（它必然漏数据）

`jobs/account_events_collect.py` 连同 `_task_to_event` / `COLLECTED_TASK_TYPES` /
水位线一起删除，迁移 `20261004_0043` 清掉它的作业行。删除理由是实测出来的：

- **靠 allowlist 认业务类型，新增类型就静默丢**：原有名单只有 5 个，
  而 `exchange_esports_goods`（电竞兑换）、`exchange_xpd_goods`（和平小店兑换）、
  `pay_locked_order`（锁单支付）、`donate_esports_*`（电竞礼物积分）**从来没进过时间线**；
- **「任务 success」≠「业务真的发生了」**（见下）；
- **字段路径靠抽样猜**：二维码充值的 `result` 里根本没有金额，收集器恒写
  `amount=None`，`recharge_total` 系统性少计；
- 作业默认 `enabled=False`，生产上一直没跑。

历史**不回填**（既有结论不变）：需要历史走斗鱼侧权威接口
（`query_exchange_records` / `query_xpd_purchase_records` / `query_points` 都是现成任务类型）。

## 二、业务事实直发：命名构造函数

新增 `services/business_events.py`：`record_recharge` / `record_exchange` /
`record_points_credit` / `record_bind`。每类事实的字段、标题、金额符号只定义一次
（与 S4 的 `record_account_action`、`on_ck_verdict` 同一套路）。

**9 处成功点接线**：`exchange_goods` 真兑换分支、`exchange_esports_goods`、
`exchange_xpd_goods`、`pay_locked_order`、`create_gold_qr`（二维码 + 供应商轮询 +
**供应商回调**三条路径）、`donate_elite_gift`、`donate_esports_gift`、
`confirm_bind`、`confirm_esports_bind`。

**只记真实事实**（按你的决定）：`exchange_goods` 里「预约到货 / 已预兑 / 预兑确认」
三条 success 分支**不发事件** —— 它们不消耗积分也没换到东西，旧收集器只按 status
收集，于是每预约一次就生成一条金额为空的 `exchange` 把 `exchange_count` 灌大。
`confirm_bind` 里「检测到账号本来就已绑定」那条也跳过。

## 三、修掉两个真 bug（都是钱账）

1. **到账判据 `!=` → `>`**（`douyu_runner_gold.py`）：余额**下降**也算「鱼翅已到账」。
   批内并发（最高 10）时同账号送礼会消耗鱼翅，余额一变就被充值任务读成到账，
   **往台账记一笔根本没发生的充值**。
2. **供应商回调晚于 runner 超时**：原来守卫是「任务状态没被改过才更新」，
   于是 runner 先判 failed、回调随后说成功的那笔真金白银**永远不进时间线**。
   改成按**回调自己的终态**判断，并补发事件。

## 四、发射顺序：一个会静默丢事件的坑

`_mark_task` 内部 `db.commit()`，而 `emit` 用 `db.begin_nested()` **只 RELEASE
SAVEPOINT、不提交外层事务**；runner 的 `finally` 只 `close()`（未提交即回滚）。
所以**在 `_mark_task` 之后发事件会被静默丢弃，且 `emit` 仍返回 True**。
所有接线一律紧贴 `_mark_task(success)` **之前**，并加了源码扫描用例钉住
（已反向验证：故意挪到之后，用例立刻报出 file:line）。

## 五、`douyu_tasks` 保留策略（新增作业，默认关闭）

`jobs/douyu_tasks_retention.py`，两档：

| 档 | 保留 |
| --- | --- |
| 噪声查询（只读看一眼就走，且前端不拿它派生账号状态） | **7 天** |
| 其余一切（业务事实 + 状态派生依赖的查询 + **以后新增的类型**） | **90 天** |

长保留档用 `task_type NOT IN (噪声名单)` 表达 → **新增类型默认长保留**，不会因为
「忘了加名单」被误删（正是收集器翻车的反面）。在途任务（planned/pending/running）
**绝不删**；分批删避免长锁；两个窗口都能在作业 `config` 里改，不必发版。

⚠️ 「前端从任务列表反推账号当前状态」那几类查询（`query_xpd_bind_info` /
`query_esports_game_name` 等）**故意留在长保留档** —— 删早了工作台账号行会变
「未查」，那是把**当前显示**搞坏。根治要靠 §3.6 的状态列拆解（后续阶段）。
作业默认 `enabled=False`，由运维决定何时打开。

## 验证

- `TZ=Asia/Shanghai`：**450 passed / 6 skipped**（S4 后 426 → 净增 24）
- `TZ=UTC`（相关文件）101 passed；ruff check/format 全绿
- 前端 build 通过、lint 0 errors
- 真实开发库：迁移已应用（head `20261004_0043`，孤儿作业行已清）；
  保留作业实跑确认「作业行默认关闭、SQL 在 MySQL 上正确、近期行不误删」
- **两处反向验证**：把 `record_bind` 挪到 `_mark_task` 之后 → 顺序用例报红；
  修掉 `registered_jobs()` 那个**假绿用例**（它返回 dict，原来的集合推导式
  遍历空字典恒成立），并在断言里加了反向确认

未做（后续）：S6 账号页重构 + `bind_status` 三列拆解（做完才能把状态派生类查询
也纳入短保留）、S7 账号检测改账号维度、S8 丢 `login_tasks` 旧凭据列。
 2026-10-04 16:00:42 +08:00
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 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 e88c41385b Merge branch 'main' into dev 
# Conflicts:
#	tests/test_migrations.py
 2026-10-04 13:17:43 +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 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 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 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 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 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 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 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 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 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 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 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