dachui/live-hub-py
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
590 Commits 3 Branches 0 Tags
86ca2ed021686499d12282cf928d13f6d5e73fd3
Commit Graph
590 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
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 64dc9a9116 docs(query): 账号「一键查询」设计 —— 数据源已用生产镜像实证 
决策已定：两个套装属精英宝典（manual_id/rid 用后台配置）、异步任务。

## 关键实证（镜像库真实数据）

「是否已拥有某套装」**能直接从斗鱼官方查**：
query_limited_goods 的商品项里 count / foreverCount / storeStatus 是**账号维度**的。
实测「套装-兔兔白日梦」—— 已兑换的账号 558 是 count=0/storeStatus=0，
未兑换的 15407 是 count=96982/storeStatus=1。配合 countLimited=1（每账号限兑 1 次），
判定规则就是 storeStatus==0 → 已拥有。

⚠️ 同时记下风险：storeStatus=0 也可能是全局售罄，UI 要写「不可再兑」并显示 count。

## 另一个坑

任务类型 query_exchange_records **在生产从未运行过**（0 行）；
真正的官方兑换记录接口是客户端的 exchange_records()（activity_client.py:950），
**没有被任何任务接线**。一键查询要用它。

## 文档内容

数据源矩阵（8 个客户端方法 + 参数来源）、任务设计（新类型
query_account_overview，只读、单项失败不整体失败、errors 如实展示）、
结果 JSON 结构、后端/前端/测试实现清单、判定规则、镜像库复现样本、风险。

注：本次只落设计不写实现 —— 上下文不足以一次干净做完，
半成品比未开始更糟。实现按本文档一次完成。
 2026-10-04 18:56:01 +08:00
yml2213 4732c02c09 feat(ops): 本地生产镜像同步脚本 + 上线清单补充说明 
生产已部署完成（main@2f610a5，迁移 20261004_0046）。为了让后续测试能在本地跑，
把生产库同步成本地镜像，并把同步流程固化成脚本。

## 本次建立的本地镜像

`douyu_login_prod` —— 与生产逐项一致：15,182 账号 / 14,323 CK / 15,169 登录记录 /
**253,424 条 douyu_tasks（含 837MB JSON，可实测保留策略）** / 迁移 0046 / 907MB。

**已验证本地 `.env` 的 `APP_ENCRYPTION_KEY` 与生产一致** ——
抽样解密正常（CK 前缀 `dy_accounts_main`，长度 1659–1702），
所以镜像里的 CK 可用，CK 相关测试能跑。这一点不成立的话镜像基本没用。

## 脚本里规避的两个坑

1. **不要把 `mysqldump` 串进 SSH 管道**：实测 ~49KB/s（MySQL 读 + gzip + 网络互相拖），
   改成「服务器本地 dump 成文件 + rsync」后 ~8MB/s，**快两个数量级**。
   下载那步用 **rsync 而非 scp**：可断点续传，网断了不用重来。
2. 恢复前先 `DROP DATABASE`，避免旧数据残留造成「看起来同步了其实没有」。

## 文档

`docs/上线清单-S1-S7部署.md` 追加「把生产库同步到本地」一节：用法、
镜像内容、两个前提（密钥必须一致；**不要在镜像库上跑测试套件** ——
测试用独立的 `douyu_login_test`），以及上面两个坑。
 2026-10-04 18:46:26 +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 d3f5198227 style(ui): 账号列表列宽优化 —— 账号列不再吃掉全部剩余空间 
截图里的毛病很具体：**「账号」列被撑到 1000+px**，中间空出一大块，
而「状态」列只有 150px，把「检测 2026-10-01 19:07:25」挤成了两行。

根因是我前面把 ID 合并进「账号」列时，顺手把它的 `width` 去掉了 ——
于是它成了唯一的弹性列，把剩余空间全吃了。

修法：
- **账号列定宽 200 + `ellipsis`**，用户名过长就省略（`title` 保留全文）
- **CK 时间改用 `formatTimeShort`**（`10-01 19:07`），状态列加宽到 180，
  一句话能放下，不再折行
- 其余列宽按内容重新配比：绑定 190→150、积分 110→120、标签 170→190、操作 80→90（居中）
- **`tableLayout="fixed"`**：列宽按比例分配、剩余空间**均匀摊开**，
  而不是像 auto 布局那样全塞给内容最宽的那一列 —— 这才不会再出现「一列独大」

顺带清掉因此失效的 `formatTime` 导入（导入时间列上轮已删，它没有其它调用点）。

验证：pytest 500 passed / 6 skipped；ruff 全绿；build 通过、lint 0 errors。
 2026-10-04 17:19:09 +08:00
yml2213 a21e4a7e2a feat(ui): 账号列表恢复「标签」列（含就地编辑） 
按反馈把标签列加回来。这列不只是展示 —— **有 `account:tag` 权限时就是一个
内联编辑框**：选已有标签或直接输入新标签即保存，无权限时退化为只读 Tag。

因此一并恢复它所依赖的东西：
- `handleSetTag`（单条改标签）
- `tagColorMap` + `TAG_COLORS`（只读态的标签配色）
- `useMemo` 导入

所以现在改标签有三个入口，各管一段场景：
| 入口 | 场景 |
| --- | --- |
| 列表「标签」列 | 单条快速改 |
| 列表「批量打标签」 | 一批一起改 |
| 详情页状态卡 | 在账号全貌下改（S6） |

列表列最终为：**账号 / 状态 / 绑定 / 积分·鱼翅 / 标签 /（凭据三列，开关控制）/ 操作**

验证：pytest 500 passed / 6 skipped；ruff 全绿；前端 build 通过、lint 0 errors。
 2026-10-04 17:12:13 +08:00
yml2213 e24af9ad75 fix(ui): 账号列表按反馈调整 —— 保留批量操作与凭据开关，去掉「分配给」列 
上一个提交把四项一起砍了，其中两项理解反了，按反馈改回来：

## 恢复（撤销上一提交的 ① ④）

- **「显示凭据」开关 + 密码/邮箱/邮箱密码三列**
- **「批量打标签」「批量删除」按钮**，以及随之必需的**整套勾选机制**：
  `rowSelection`、`selectedRowKeys`、`selectedAllMatching`、
  「已选择 N 个 / 选择当前筛选下全部」提示条、批量设置标签弹窗、
  `handleBatchTag` / `handleBatchDelete`

## 新增去掉：**「分配给」列**

分配统一走「分配管理」页（`/accounts/assignments`，页面一直在），
列表里的内联分配下拉是重复入口。随之清掉只服务于它的
`handleAssign` / `loadUsers` / `users` 状态 / `userApi` 与 `UserInfo` 导入。

## 保持删除（反馈里未提）

**「标签」列**与**「导入时间」列**仍不恢复。注意因此产生的一处连带：
标签列里的**内联编辑框**也没了 —— 现在改标签的入口是
**批量打标签**（列表）+ **详情页状态卡**（S6 已做），够用。

## 踩到并修掉

用「区间删除」砍 `handleAssign`→`handleDelete` 时，把夹在中间的
**`handleBatchTag` 一起删了**（后来 `handleBatchTag` 引用未定义才暴露）。
已补回。教训：按区间删代码前要先确认区间里没有别的东西 ——
这类错误 `tsc` 只在**引用处**报，很容易看漏。

## 最终形态

- 列：账号 / 状态 / 绑定 / 积分·鱼翅 /（凭据三列，开关控制）/ 操作
- 工具栏：筛选（标签 · CK · 绑定 · 搜索）+ 显示凭据 + 批量打标签 + 批量删除 + 批量导入
- 618 行；`TAG_COLORS` / `tagColorMap` / `handleSetTag`(单条改标签)
  等确认无用的死代码已清

## 验证

- `TZ=Asia/Shanghai`：500 passed / 6 skipped；ruff 全绿
- 前端 build 通过、`npm run lint` **0 errors**
 2026-10-04 17:10:17 +08:00
yml2213 cb87a844b3 refactor(ui): 账号列表按「只做管理」重做 —— 砍掉凭据/标签/时间列与批量操作 
承接上一个提交。按确认的结果，四类老壳子残留一并移除：

## ① 「显示凭据」开关 + 密码 / 邮箱 / 邮箱密码 三列

这是老「卖号」视图的残留。移掉后列表不再有任何凭据字段，
`include_sensitive` 参数不再从列表请求里传（后端能力保留，需要时仍可显式请求）。

⚠️ 副作用：**界面上暂时没有地方能看到账号密码了**。当前重登全自动，
不需要人工读凭据；但如果你偶尔要抄出来核对，告诉我，我在**详情页**加一个
带权限校验 + 写审计的「查看凭据」，而不是把三列塞回列表。

## ② 「标签」列

标签仍可**筛选**（顶部下拉），但不再占一列。设置标签的入口统一到**详情页**
（S6 已在状态卡里做了就地编辑），列表里那个内联编辑框随之删除 ——
所以 `handleSetTag` / `tagColorMap` / `TAG_COLORS` 一并清掉。

## ③ 「导入时间」列

去掉（详情页仍有完整的导入时间与状态变更时间）。

## ④ 「批量打标签」「批量删除」按钮

随之移除**整套勾选机制**：`rowSelection`、`selectedRowKeys`、
`selectedAllMatching`、「已选择 N 个 / 选择当前筛选下全部」提示条、
批量设置标签弹窗、以及两个 handler。**单条删除保留**（操作列，受 `account:delete` 管）。
批量接口在后端保留不动（S4 已给它们接了逐账号事件，别浪费）。

## 结果

- 列表列：**账号 / 状态 / 绑定 / 积分·鱼翅 / 分配给 / 操作**
- 工具栏：筛选（标签 / CK / 绑定 / 搜索）+ 批量导入
- 文件 601 → 478 行；`Alert` / `TagOutlined` / `Eye*` / `App` / `modal` 等
  随之失效的导入与变量全部清掉（靠 `tsc --noUnusedLocals` 逐个抓出来）

## 验证

- `TZ=Asia/Shanghai`：500 passed / 6 skipped；ruff 全绿
- 前端 build 通过、`npm run lint` **0 errors**
- 逐个删除后都用 `tsc` 反查死代码，没有留下未使用变量
 2026-10-04 17:01:34 +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 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