162 Commits

Include renames

Author	SHA1	Message	Date
yml2213	fdc57752dc	refactor(huya): 协作台账 done 状态展示名「已完成」→「抢购成功」（枚举值不变）	2026-10-16 22:06:39 +08:00
yml2213	e8abd60734	feat(huya): 协作台账状态机新口径（跳步/已确认绑定/兑换失败）+ 账号全生命周期快照（迁移 0059）	2026-10-16 22:00:34 +08:00
yml2213	aac264b639	feat(huya): 协作台账店铺字典·新建强校验·同买家多单 + uid 放开（迁移 0057/0058） ... - 店铺字典（迁移 0057）：大按钮点选 + 「新店」自定义自动登记；重命名可级联、 停用/备注；列表行内改、详情、筛选条共用同一个 picker - 新建强校验：订单编号/店铺/CK/礼包名/主页截图必填；贴 CK 即探针预览， 读不到绑定角色禁止提交；礼包用工作台配置的活动 SID 现拉（浏览器缓存 + 强制刷新） - 图片：绑定图停用、「绑定斗鱼号」下线（绑定关系改由探针读 bind_game_*）， 主页截图改为新建必填（弹窗内先传 OSS 再随表单落库） - 同买家多单软识别：按「绑定账号 + 绑定角色」整批一次查询，列表「同买家」列 + 详情分组，点单号直接切单 - uid 放开唯一性（迁移 0058）：同一份 CK 可服务多单，原 409 冲突改为提示 + 审计 - 列表体验：序号列、搜索扩到 11 个字段、CK 状态列截断、新建弹窗放大并去滚动条 - 验证：pytest 932 passed / 6 skipped；接口冒烟 56 项全绿；tsc+eslint+build 通过	2026-10-16 21:29:08 +08:00
yml2213	df8c63b829	feat(huya): 外部 CK 协作台账（S1–S6）+ 图片上传能力 ... 协作台账：新表 huya_external_orders 替代 Excel 多人协同表（设计见 docs/设计-虎牙外部CK协作台账.md），一条 CK 一行，所有人共享、改动留痕。 - 前端 pages/HuyaCollabPage.tsx + 菜单「虎牙 → 外部单协作」/huya/collab： 内联编辑（带乐观锁 version）、图片缩略图、详情抽屉（字段表单 + 两个图片槽位 + 操作时间线）、粘贴导入弹窗（带 TSV 预览）、批量/单条验证 CK、页头统计条、筛选 - 两套状态机：业务 pending→bound→recharged→scripted→done（旁路 void）、 凭据 unverified/valid/invalid/disabled；唯一写入口在 services/huya_collab_service.py， 字段级审计 + 整数 version 乐观锁（不用 updated_at：DATETIME 只到秒） - CK 只读探针 check_user_bind_game_account（真机判据：响应非 None 且 status == 200）， 成功即覆盖写绑定快照 bind_game_account/bind_game_role/bind_game_channel（迁移 0056）， 失败只改凭据状态、不动业务状态；人工只能停用/恢复（POST /{id}/ck/status） - 贴/换/重建 CK、TSV 批量导入（SAVEPOINT 单行隔离，部分失败不整体失败）、 权限 huya:collab:view/edit/manage（删除只给运营） - 孤儿图清理脚本 scripts/cleanup_orphan_file_assets.py（默认 --dry-run） 图片上传（协作台账截图用）：OSS/本地双后端 + 缩略图变体 + /api/files 代理回读， 权限 file:upload / file:view。 验证：pytest 880 passed / 6 skipped；ruff format 全绿、ruff check 仅剩既有告警； 前端 tsc -b / eslint / vite build 通过；接口端到端冒烟 29 项全绿（TestClient，探针用假客户端）； 探针真机冒烟 3 例（有效 CK=True、别人 uid=False、裸 cookie=False）。	2026-10-16 19:38:59 +08:00
yml2213	9a0d59825c	fix(huya): 开通商品只保留真正可购买的 spu，并清理历史死商品行 ... 真机 2026-10-15（HAR 10.15-精英徽章两个-1 + 逐个 spu 探测）：面板里的「精英徽章 hy-5872824」是积分中心「赠送指定礼物得积分」那排的礼物 spu —— getGoodsInfoV5 仍返回 200+价格，但 listPayChannelV5 返回 401「您的设备环境暂不支持购买该商品」，所以下单必报「当前支付渠道不可用」（与数量无关）。真能买的是 hy-8343549 精英徽章 ¥1 / hy-8343551 精英令 ¥10。 - 内置候选换成可购买的 4 个：hy-8328015 宝典 / hy-8327356 币 / hy-8343549 徽章 / hy-8343551 令 - 刷新商品增加「能买到」闸门：详情 200 后再校验 listPayChannelV5，非 200 或渠道为空即剔除并记录服务端原话 - 下单流程渠道失败时透出服务端消息，只有渠道真不在可用列表才说「当前支付渠道不可用（可用：…）」 - 商品列表只认「最近一次刷新」那一套：原先按账号并集返回，别的账号旧刷新留下的礼物 spu 会和最新一套叠成 7 个选项 - 刷新时清理历史死行：本账号旧行 + 全局默认行（account_id 为空）+ 其它账号里已不在候选中的 spu 行 - 测试：401 商品被剔除、渠道失败透传、列表只认最近一套、刷新清理别处死行	2026-10-15 21:01:23 +08:00
yml2213	0b9a01ab3f	feat(huya): 开通支付码复用未支付旧单 + 二维码改用支付宝收银台直达地址 ... - 限购商品（精英宝典 buy_limit=1）挂着未支付旧单时，真正先失败的是购买权限 校验 checkUserBuyAuth（真机 703「已超过该商品的购买上限，下单失败~」）， createOrderV5 根本不会执行；现在 checkUserBuyAuth 与 createOrderV5 两处失败 都会回退 find_reusable_order，拿同一商品的未支付旧单继续 payOrderSubmitV5。 - 新增支付宝收银台直达地址解析（resolve_pay_entry_url）：跟随网关 302 后的 excashier.alipay.com/standard/auth.htm?payOrderId=…（93 字符，原始网关地址 1616 字符）写入结果 pay_cashier_url；解析失败回落本站短链 /api/huya/pay/<task_id>?k=<hmac>，后端跑在 localhost 时客户也扫得开。 - 前端 QRCode 显式 color="#000" bgColor="#fff"：antd v6 暗色主题默认 color=token.colorText、bgColor=transparent，白码落在白底容器里根本看不见。 - 支付成功后列表「二维码」列不再展示二维码（qrDoneLabel → 已支付/已开通）。 测试：pytest 767 passed / 6 skipped；typecheck、eslint、ruff 通过。	2026-10-15 19:28:26 +08:00
yml2213	73536d62c8	feat(huya): 工作台补手机号/精英宝典列与一键查询 ... - 手机号列：外部 CK 的 `----手机号` 本来就落在 huya_accounts.game_phone， 列表一直没展示；现在单独成列，并纳入搜索 - 精英宝典列：显示「已开通/未开通/未查询」+ 开通时间 + 有效期 · 开通状态 = 积分中心 getRedeemNeedGoods 的 tag5（真机对照网页：1=已开通， 0=未开通，此时 tag7 会列出开通套餐），拿不准时为 NULL（显示「未查询」） · 开通时间 = revenueWebUI.queryUserOrderList 里已支付的宝典订单 pay_time （按 SPU 白名单 + 订单名含「精英宝典」识别，未支付订单不计，取最近一次） · 有效期 = PlayMallUI.queryAllocation 页面配置的本赛季节点 tag10/tag11 （2026-10-15 抓包：精英宝典福利季丨Q4，2026-10-09 ~ 2026-12-31 23:59:59）， 不写死索引，递归找带 tag10/tag11 的节点 - 新任务 query_all「一键查询」：勾选账号一次跑完角色绑定 + 宝典开通 + 积分， 按部分失败如实汇总（某个接口挂了不影响其它结论），并把宝典状态写回账号 - 迁移 20261015_0053：huya_accounts 新增 elite_opened / elite_open_time / elite_expire_time（时间存 Unix 秒，与斗鱼 elite_expire_time 同约定） - 开通商品按页面「赠送指定礼物得积分」那一排对齐成 6 款（去掉页面已不用的 旧版精英宝典 hy-5879340），列表接口只返回账号级快照并按 spu 去重 - 建 WSS 会话失败（积分中心端点静默不回包）时回退 HTTP cdnws， 不再让整批任务判失败 - 列表列宽改按比例分配，避免宽屏下被拉出奇怪的宽度；最近操作不再重复状态 - 新增 tests/test_huya_elite_query.py（10 条）；同步迁移头版本断言 真机验证：#65 已开通（10-13 20:41:45，有效期 12-31）、#70 新开通 （10-15 16:37:37）判定与订单/网页一致	2026-10-15 16:53:30 +08:00
yml2213	7ca0f7ee28	fix(huya): 刷新开通商品不再依赖已下线的活动任务接口 ... 真机（2026-10-15）实测 webActUI.getActTaskDetail(act 25135) 返回 601「活动已下线」，刷新开通商品第一步就失败，下拉框一直为空。 - 商品来源改为内置候选（积分中心页面「赠送指定礼物得积分」那一排， 全部经 getGoodsInfoV5 真机验证 code=200）：精英宝典 hy-8328015 ¥30、 精英币 hy-8327356 ¥0.1、精英徽章 hy-5872824 ¥1、精英令 hy-5879346 ¥10、 精英令*10 hy-5874269 ¥100、精英令*100 hy-5874270 ¥1000； 旧版精英宝典 hy-5879340 页面已不再使用，从候选移除 - 活动任务详情降级为可选补充：返回非 200 只记 warning 并写入 result.task_detail_error，不再让整次刷新失败；失败原因以商品详情为准 - 刷新时清掉该账号全部旧商品行（不限 sid），避免同名商品重复 - 列表接口只返回账号级快照并过滤 2026-07-04 的全局种子行， 同一 spu_id 保留最新一行（原先 精英宝典 会出现两次） - 前端：下拉标签带 spu 便于区分，按内置顺序排序，默认自动选中第一项 - 新增 tests/test_huya_recharge_goods_source.py（6 条）：活动下线响应字节 回归、下线不阻断刷新、活动商品仍会并入、失败原因归属、跨 sid 清理、 列表去重与隐藏种子行（均已做反向验证） 真机验证：刷新成功 6 个商品，价格/库存与网页一致	2026-10-15 15:57:25 +08:00
yml2213	4ce30e5c26	feat(huya): 精英宝典工作台支持导入外部 CK ... - 新增 POST /api/huya/workbench-accounts/import-cookies（huya:task + huya:import）： 外部 CK 复用现有解析入库后直接加入当前用户的工作台集合，导入完即可在工作台执行 「生成开通支付码／绑定二维码／查询角色／刷新积分」等操作 - 新账号自动 assigned_to=导入者：客服的账号列表按归属过滤，不设归属会「导入成功但看不到」 - import_huya_cookies_detailed 返回账号对象供工作台复用，原 import_huya_cookies 行为不变 - 工作台账号卡片新增「导入外部 CK」入口（huya:import 权限控制）与导入弹窗 验证：新增 tests/test_huya_workbench_import_ck.py（入库、归属、工作台集合、重复导入幂等、 全脏数据不建记录）；按 AGENTS.md 做了反向验证（关掉归属赋值后该用例变红，还原后恢复）。 前端 tsc -b 与全量 pytest 通过。	2026-10-15 14:56:58 +08:00
yml2213	ec07e4fc06	fix(config): 修复切换充值渠道报错及补齐 peace_enabled 字段声明 ... - 在 DouyuConfigOut 与 DouyuConfigUpdate 中补齐 peace_enabled 声明与序列化 - 在 update_config 中使用 getattr(req, field, None) 安全读取属性，避免 AttributeError 导致 500 - 在 _config_out 中加入 peace_enabled 输出映射 - 增加切换充值渠道与配置更新的单元测试	2026-10-08 11:49:41 +08:00
yml2213	4eef45efe4	fix(accounts): 完善手机号必绑与账号注销等登录异常分型识别 ... - 补充必须绑定手机号与账号注销/封禁/冻结等错误文案的识别规则 - 增加数据修正迁移 20261008_0052，回写历史账号和登录任务的失败分型 - 增加列表查询与导出时根据错误文案自动兜底细化 failure_kind 的逻辑 - 增加并完善相关分型单元测试	2026-10-08 11:26:19 +08:00
yml2213	f8ad6e1777	perf(assignments): 优化分配管理页面加载性能与角标数量展示 ... - 前端改造为服务端分页查询 (accountApi.listPaged)，避免一次性拉取 1.6 万+ 账号导致页面卡死 - 优化后端 assignments_summary 聚合查询，消除大子查询临时表 - 修复 Badge 默认 99+ 限制，设置 overflowCount 支持展示完整账号数量 - 修复测试用例 test_business_events.py 当前时间跨天断言问题	2026-10-08 11:08:41 +08:00
yml2213	f101414f5e	feat(accounts): 新增登录异常分型统计、多选/全量导出、筛选记忆及页面组件模块化拆分 ... - 新增登录失败异常分型统计：支持「必须绑定手机号」、「极验滑块」、「凭证错误」、「邮箱取码失败」、「邮箱配额已满」、「网络异常」分型识别、生命周期联动（待人工）与一键筛选； - 新增账号名单与明细导出功能：支持勾选多选或按当前筛选条件全选，可导出纯用户名名单 (TXT) 或 UTF-8 BOM 结构化明细报表 (CSV)，并支持一键复制到剪贴板； - 优化筛选条件记忆机制：支持页面切换/返回后自动保留所有筛选与排序状态，新增顶部「重置全部筛选」快捷按钮； - 模块化拆分 AccountsPage：将 2100+ 行的大文件拆解至 pages/accounts/ 子目录（包含状态卡片、筛选面板、工具栏、操作弹窗与表格构建器），提升可维护性； - 验证方式：新增 5 个后端自动化单测 (test_account_failure_and_export.py)，全量 694 个测试用例通过，前端 TypeScript 编译与 pre-commit 代码规范检查全部通过。	2026-10-07 17:23:39 +08:00
yml2213	44b762ea8c	fix(overview): 锁定核心高价值套装并修复未查询空值误判 ... - 高价值套装精确匹配「套装-兔兔白日梦」与「套装-狂战萌兔」，排除头盔/背包/手榴弹散件干扰 - 增加 is_suit_queried_expr，未查询或 NULL 账号严禁误判为双套均可兑换 - 修复前后端序列化空值保持，完善列表与详情页准入状态和判定依据展示 - 新增头盔排除与 NULL 统计防错回归单测，全量通过 689 个用例	2026-10-07 15:27:30 +08:00
yml2213	d11fa1032d	feat(login-tasks): 按状态导出 CSV + 登录失败写进账号生命周期 ... 一、失败入账号一生（此前完全缺失） 生产实测：`login_ok` 1,456 条、`relogin_failed` 73 条，但**没有 login_failed**， 而 login_tasks 里 attempt_status='failed' 有 247 条 —— 这 247 次失败在账号时间线上 一条痕迹都没有，「这账号为什么一直登录不上」在账号页上无从回答。 - 新增事件类型 login_failed，在 `_mark_attempt_failed` 里写入 - **被停止 / 被中断不写**：分型把「已停止/中断/服务重启」归到 interrupted， 那不是账号的问题 —— 否则运营按一次停止就能给几十个账号刷满假失败 - 事件带分型（captcha/credential/email_code/email_quota/network）， 同时落进 detail.kind，以后可直接按「验证码失败」筛账号 - 幂等键 login_task:{id}:failed:{ts}，与成功路径同构 二、失败分型下沉成共用 service `classify_failure` 原在 automation/jobs/ck_relogin.py，手动登录也要用。 挪到 services/login_failure.py（job 改为 import，`ck_relogin.classify_failure` 这个名字保留，旧调用方与用例不受影响），并提供型别中文标签与 `is_account_fault` 判据 —— 与仓库既有的「service 不该依赖 job」分层一致。 三、按状态导出 CSV - 新增 GET /api/login/tasks/export：不分页，导出当前筛选的**全部**匹配记录； 列：账号/状态/失败原因/失败分型/批次/最近尝试时间(UTC)/标签/归属客服 - 权限与筛选与列表**完全共用**，客服只导出自己名下账号 - 带 UTF-8 BOM（不加 Excel 打开中文表头是乱码），导出动作写审计 四、修一个口径不一致的真 bug 页面「失败 N」= failed + error 之和，但筛选只认 failed —— 所以截图里「失败 389」点进去只有 386 条（差的就是那几条 error）； 「清空失败」同样漏删 error。现在把状态组收敛成一份 `_apply_status_filter`， 列表 / 导出 / 批量删除三处共用。 测试：684 passed, 6 skipped（本次新增 13 个）；三条关键断言做了反向验证 （去掉 stopped 判断 / 失败组去掉 error / 去掉 BOM，对应用例均变红）。	2026-10-07 12:54:57 +08:00
yml2213	281769b440	feat(accounts): 账号列表按归属筛选，批量分配支持按筛选全选 ... 原来只有 assigned_only（已分配），筛不出「未分配」，也看不到账号归谁。 新增 assign_status/assigned_user_id 可与标签、CK、搜索等叠加； BatchAssign 支持 all_matching，「筛出未分配 → 一键分给某人」不必先勾选。	2026-10-07 09:13:54 +08:00
yml2213	5da12df16b	feat(account-check): 登录接口可选 wgapi / iframe ... 账号检测原来把 WgapiLoginAPI 写死在执行器里，收不到邮箱验证码时只能干等； 登录任务早就可选 iframe（邮箱验证走 iframe 接口）。默认仍 wgapi，旧行为不变。	2026-10-06 20:19:26 +08:00
yml2213andCursor	f2157f67f7	feat(accounts): 账号列表按列排序，默认把还能换套装的排到前面 ... 分页在服务端，点表头按全库排，不能只排当前这一页。 Co-authored-by: Cursor <cursoragent@cursor.com>	2026-10-05 18:50:43 +08:00
yml2213andCursor	998998c390	feat(automation): 巡检和重登优先保住高价值账号的 CK ... 价值按套装和积分现算，不看标签。第 1、2 档 6 小时巡检一次，并先占重登名额。 Co-authored-by: Cursor <cursoragent@cursor.com>	2026-10-05 17:51:04 +08:00
yml2213	27e9107e38	fix(accounts): 修复鱼翅筛选参数类型为浮点数并优化错误提示 ... 1. 后端将 min_gold 与 max_gold 参数及 Schema 类型从 int 改为 float | None，支持小数鱼翅（如 >0 快捷筛选的 0.01）； 2. 修复前端 axios 拦截器在遇到 FastAPI 422 验证错误时未展开 detail 导致弹出 [object Object] 的问题； 3. 单元测试补充验证浮点数鱼翅过滤场景。	2026-10-05 11:36:46 +08:00
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	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	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	62d9053e8a	feat(account): 官方兑换记录补成账号事件（三作用域）+ 一键查询结果落到账号 ... ## 官方兑换记录 → 真正的账号事件 关键发现：斗鱼官方兑换记录**带真实兑换时间**（`time` 字段），所以可以直接 补成正常的历史事件，时间线因此变完整（这就是「账号全生命周期」该有的样子）， 列表的兑换聚合也随之准确 —— 上线前的兑换不再是一片空白。 - **三个作用域都拉**：精英宝典 / 电竞手册（共用 `exchange_records`，只有 manual_id 不同）/ 和平小店（`xpd_embed_query` → `xpd_purchase_records`） - 幂等键含作用域：`official_exchange:{scope}:{account}:{commodity}:{time}` - `detail.scope` 标作用域；`source=official_sync` 与"当场记的"分得开 - 任一作用域失败只记进 `errors`，不影响其余（小店未开通会报 `Livelink登录态校验失败`，属正常） ## 一键查询结果落到账号（不再只留在任务里） - 新增 `accounts.high_value_owned`（迁移 0048）：**已兑换过的高价值套装名**， 供列表展示。单开一列而不是让列表读 `overview_snapshot` —— 那份 JSON 有 1~2KB， 15000 个账号各带一份会把响应放大到几十 MB。 - 迁移**可安全重跑**（启动时会自动跑）：加列前查 `information_schema`。 ⚠️ 回填里**不要** `op.get_bind().commit()` —— MySQL 的 DDL 自动提交而 commit 会打乱版本记账，表现为"列加上了、版本号没更新"，下次启动重复 ADD COLUMN 直接把服务起不来（生产上就是启动即挂）。 - 迁移里从旧快照**回填** `high_value_owned`，已查过的账号不必重查。 ## 两个 bug 1. **「最近一次兑换」按插入 id 排**（应为事件时间）：补录的历史事件 id 最大、 时间却最老，会把几个月前的老兑换显示成"最近一次"。改为 `occurred_at DESC, id DESC`。 2. **手写的 `@model_serializer` 没列新字段** → 属性有值、JSON 里没有。 这是本项目第三次踩 Pydantic 静默丢字段；已补，并把断言改为看 `model_dump()`。 ## 列表「兑换记录」口径 只聚合**官方**记录（`source=official_sync`）：用户要求列表看官方的权威口径， 我们当场记的那些留给详情页时间线。另加 `GET /accounts/{id}/exchange-records` 供列表点击预览（按需拉取，不进列表响应）。	2026-10-04 20:03:42 +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	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	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	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	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	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
yml2213	6a25097412	fix(douyu): 替换 CK 是最后一步，只有登录成功才写回记录 ... 上一版把可见性改成「记录里还有 CK」，账号不会再消失，但根因还在：批次启动 时就把复用的成功记录改成 pending（旧 CK 仍在），停止或失败后没人恢复状态， 记录一直显示成一次没完成的登录。 按「替换 CK 是最后一步」把两者拆开： - login_tasks 新增 attempt_status / attempt_message / attempt_batch_id / attempt_at，批次只写 attempt_*，status/cookie/message 只在登录成功时更新； - _begin_attempt 只登记尝试，_mark_attempt_failed 只记录失败（已有 CK 的记录 原样不动），_write_login_success 是唯一替换旧 CK 的入口； - 停止批次、代理不可用、登录异常、进程重启清理全部改为收敛 attempt_*， 因此停止一个批次不可能再让账号失去 CK； - 复用的记录改用「持有 CK 的记录」，不再创建第二条记录，失败记录在无 CK 时 才复用； - 登录任务列表/统计按 attempt_* 展示「这次登录怎么样了」，批次筛选同时匹配 attempt_batch_id；CK 操作页的重登状态也从 attempt_* 映射； - 迁移 20261001_0035 归一存量数据：持有 CK 的记录 status 统一为 success、 历史状态搬进 attempt_*，无 CK 且卡在 pending/running 的收敛为 failed。 新增测试：批次失败/停止不碰旧 CK、成功后替换 CK、列表展示尝试状态、 迁移存量数据归一。	2026-10-01 18:29:49 +08:00
yml2213	64c399617a	fix(douyu): 账号只要还持有 CK 就不再从工作台消失 ... 线上事故：分配给客服的账号（如「远行者103」）在斗鱼工作台与 CK 列表里 查不到，只有账号管理里还能搜到。原因是可见性判定写成了 LoginTask.status == "success"，而按设计保留旧 CK 的三种状态都不再是 success： - 普通登录批次启动时会把复用的成功记录置为 pending/running（旧 CK 保留）， 批次被停止或失败后一直停在 pending，账号永久消失； - CK 重登失败置为 relogin_failed（旧 CK 保留），账号从工作台消失； - 普通登录失败置为 failed（复用记录的旧 CK 未清空），同样消失。 线上现状：12545 个账号持有 CK，但只有 11703 个能出现在工作台，842 个 （644 重登失败 + 176 排队中 + …）对客服和管理员都不可见。 改动： - douyu_service 新增 cookie_holding_filter()/latest_cookie_login_task()， 以「记录里还留着 Cookie」作为唯一判据，并抽出 LOGIN_IN_FLIGHT_STATUSES 与 cookie_operable_filter() 供检测/重登入口复用； - 斗鱼工作台账号列表、任务账号校验、账号管理 has_cookie 筛选、分配校验与 概览、CK 管理/操作列表、首页 CK 统计统一改用该判据； - 工作台取 CK 从 latest_success_login_task 换成 latest_cookie_login_task， 保证重登失败/排队中的账号仍能被任务正常执行； - 新增 cleanup_orphan_login_tasks()：进程重启后把遗留的 pending/running 收敛为 failed 并保留旧 CK，避免页面永久显示排队中。 新增回归测试覆盖上述状态下的可见性、可执行性与启动清理。	2026-10-01 18:18:02 +08:00