refactor(huya): 协作台账 done 状态展示名「已完成」→「抢购成功」（枚举值不变）

docs/设计-虎牙外部CK协作台账.md

@@ -200,7 +200,7 @@ CK 自带完整生命周期（导入 → 验证 → 使用/失效 → 重贴/重
 ### 4.1 业务状态机（一行的进度）
 
 ```
-pending ─人工确认─▶ bound ─充值─▶ recharged ─上脚本─▶ scripted ─兑换成功─▶ done
+pending ─人工确认─▶ bound ─充值─▶ recharged ─上脚本─▶ scripted ─抢购成功─▶ done
    │                 │              │                 │                  │
    └─────────────────┴──────────────┴─────────────────┴──────────────────┴──▶ failed（兑换失败）
    │                 │              │                 │                  │
@@ -213,7 +213,7 @@ pending ─人工确认─▶ bound ─充值─▶ recharged ─上脚本─▶
 | `bound` | **已确认绑定** | 人工核对「探针读到的绑定角色」与「主页截图」一致后手动切 | 人工（单行 / 批量） |
 | `recharged` | 已充值 | 充值完成后手动切（可跳步）；写 `recharged_at` | 人工 |
 | `scripted` | 已上脚本 | 脚本上完后手动切（可跳步）；写 `scripted_at` | 人工 |
-| `done` | 已完成 | 人工切；**或**「已上脚本」的单查积分/兑换记录命中礼包后自动切（§5.7） | 人工 / 系统判定 |
+| `done` | **抢购成功** | 人工切；**或**「已上脚本」的单查积分/兑换记录命中礼包后自动切（§5.7） | 人工 / 系统判定 |
 | `failed` | **兑换失败** | 人工切；**或**「已上脚本」的单查兑换记录**没有**这个礼包后自动切（§5.7） | 人工 / 系统判定 |
 | `void` | 已作废 | 任意流程内状态可进；`void_reason` 必填 | 人工 |
 
@@ -390,7 +390,7 @@ CK 失效了业务上可能仍然有效。列表上只做**显式提示**（红
 
 | 情况 | verdict | 业务状态 |
 | --- | --- | --- |
-| 兑换记录里有这一单的礼包（名字互相包含即算命中，`gift_matches_records()`） | `success` | 「已上脚本」→ 自动「已完成」`done` |
+| 兑换记录里有这一单的礼包（名字互相包含即算命中，`gift_matches_records()`） | `success` | 「已上脚本」→ 自动「抢购成功」`done` |
 | 接口通了，但记录里没有这个礼包 | `failed` | 「已上脚本」→ 自动「兑换失败」`failed` |
 | 接口没通 / 这单没填礼包名 | `unknown` | **不动**（数据不够，不许瞎判） |
 
@@ -543,7 +543,7 @@ CK 失效了业务上可能仍然有效。列表上只做**显式提示**（红
 - **状态**：Tag 展示，行内"下一步"按钮推进（带二次确认）；
 - **CK 状态**：Tag + 一键"验证"；
 - 筛选：店铺 / 负责人 / 业务状态 / CK 状态 / 关键词（订单号、绑定账号、角色、uid）；
-- 页头统计条：`待处理 N / 已绑定 N / 已充值 N / 已上脚本 N / 已完成 N / CK失效 N`。
+- 页头统计条：`待处理 N / 已确认绑定 N / 已充值·已上脚本 N / 抢购成功 N / 兑换失败 N / 已作废 N`（`done` 的展示名 2026-10-16 由「已完成」改为「抢购成功」，枚举值与库里数据不变）。
 
 > 交互细节（2026-10-16 用户拍板）：**店铺是点选按钮组**（列表里点单元格弹出同一组按钮，
 > 筛选条里也是），不是下拉；**新建时不用选负责人**——默认就是当前登录账号
@@ -807,7 +807,7 @@ CK 失效了业务上可能仍然有效。列表上只做**显式提示**（红
 | 全生命周期 | 新表 `huya_external_order_metrics` + 迁移 `20261016_0059`；`query_order_activity()` / `query_activity_batch()`；`POST /{id}/activity/query`、`POST /activity/query`、`GET /{id}/metrics`；列表回填 `last_score/last_metric_at/last_verdict/last_metric_message` |
 | 前端 | 状态筛选与汇总卡片加「兑换失败」；工具栏「批量改状态（下拉选目标）」+「批量查积分/兑换」；行操作加「查积分 / 兑换记录」「改状态…」；列表加「积分」列（积分 + 判定徽标 + 时间，全文进 Tooltip）；详情抽屉加「账号全生命周期」时间线 + 逐条命中的兑换记录 |
 | 测试 | 新增 `TestCollabStatusBatch`（4 例）、`TestCollabActivityLifecycle`（9 例）；`tests/test_migrations.py` 的 `HEAD_REVISION` → `20261016_0059`；全量 `pytest` 944 passed / 6 skipped |
-| 接口冒烟 | `/tmp/smoke_collab_api.py` 补到 **67 项全绿**：批量跳步 + 时间戳补齐、单行查询命中→自动「已完成」、非 `scripted` 只记快照、时间线倒序、列表回填、批量查询判定→自动「兑换失败」、`failed` 状态筛选、批量逐行隔离、回退仍要 `rollback`、删单级联删快照 |
+| 接口冒烟 | `/tmp/smoke_collab_api.py` 补到 **67 项全绿**：批量跳步 + 时间戳补齐、单行查询命中→自动「抢购成功」、非 `scripted` 只记快照、时间线倒序、列表回填、批量查询判定→自动「兑换失败」、`failed` 状态筛选、批量逐行隔离、回退仍要 `rollback`、删单级联删快照 |
 
 **这一轮踩到/定下的点**：
 
@@ -824,6 +824,10 @@ CK 失效了业务上可能仍然有效。列表上只做**显式提示**（红
 6. **尚未真机验证**：`getUserScore` / `getUserPrizeRecords` 两个接口只做了假客户端单测，
    真机字段名（`available_score` / `records[].prize_name`）还没拿真 CK 跑过一次；
    真机跑通前不要把"兑换失败"当成定论（先用单行查询看一眼 `raw`）。
+7. **展示名调整（同日第二刀）**：`done` 的展示名由「已完成」改成**「抢购成功」**
+   —— 只改 `ORDER_STATUS_LABELS` / `STATUS_META` / 下拉与卡片文案，
+   **枚举值仍是 `done`**（库里数据、接口参数、审计 detail 全不变，无需迁移）。
+   「判定结论」里的 `success` 仍叫「兑换成功」（那是"查到兑换记录"的结论，与状态名分开）。
 
 ---