 yml2213
|
5405d4b1d1
|
fix(overview): 纠正高价值套装以商城 status==1 为最高准入裁判
- 根因：斗鱼官方商城接口 status==1 代表「已达兑换上限」，历史代码误以为商品列表全为全局字段而单纯依赖常被官方清空的 exchange_records，导致已兑换账号被误判为可兑换
- 修复：extract_high_value_goods 结合商城完整列表 status==1 现场判定已兑换，exchange_records 作为历史展示与兜底
- 前端：优化工作台与一键查询展示，明确展示「已达上限 N 个: ...」与「未达上限」，消除反向歧义
- 文档：沉淀坑 #9 到 AGENTS.md，并更正设计-账号一键查询.md
|
2026-10-07 14:51: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 |
|