fix: some

openspec/changes/add-polling-priority-queue/specs/polling-priority-queue/spec.md

@@ -0,0 +1,79 @@
+## ADDED Requirements
+
+### Requirement: 优先轮询项列表
+
+The admin frontend SHALL provide a paginated list of card polling priority items through `GET /api/admin/polling-priority-items`. The query SHALL support `page`（默认 1，最小 1）、`page_size`（默认 20，最大 100）以及筛选参数 `card_id`、`task_type`、`status`、`trigger_type`，并按创建时间倒序返回。
+
+#### Scenario: 分页查询优先轮询项
+
+- **WHEN** 用户进入优先队列页面或提交筛选条件
+- **THEN** 前端 MUST 调用 `GET /api/admin/polling-priority-items`
+- **AND** 携带 `page`、`page_size` 及所选筛选参数
+- **AND** 页面 MUST 使用响应中的 `data.items`、`data.page`、`data.size` 和 `data.total` 渲染列表
+
+#### Scenario: 数据范围下推
+
+- **WHEN** 当前登录账号为代理
+- **THEN** 列表 MUST 只返回自身及下级店铺资产对应的优先轮询项
+- **AND** 平台卡对应的优先轮询项 MUST NOT 出现在列表中
+
+### Requirement: 人工优先入队
+
+The admin frontend SHALL enqueue a card for priority polling through `POST /api/admin/polling-priority-items` with request body `{ card_id, reason }`. The `reason` SHALL be required and no longer than 500 characters. The operation SHALL create or merge priority items for all in-scope polling task types（实名/流量/套餐/卡状态）of the card. The frontend SHALL NOT apply any existing manual daily quota or 24-hour deduplication constraints, SHALL NOT modify scheduling priority, and SHALL NOT bypass existing concurrency limits.
+
+#### Scenario: 人工入队成功
+
+- **WHEN** 用户填写卡号与原因并提交人工入队
+- **THEN** 前端 MUST 调用 `POST /api/admin/polling-priority-items`
+- **AND** 请求体为 `{ "card_id": 卡ID, "reason": "加急原因" }`
+- **AND** 页面 MUST 展示响应中的 `created_count`、`merged_count`、`task_types`、`task_type_names` 与 `items`
+
+#### Scenario: 重复入队合并
+
+- **WHEN** 同一卡同一任务类型已存在活动优先轮询项且再次入队
+- **THEN** 该卡该任务类型至多保持一条活动项
+- **AND** 响应 MUST 返回合并后的项并将该次入队计入 `trigger_count`
+
+#### Scenario: 原因校验
+
+- **WHEN** `reason` 为空或超过 500 字符
+- **THEN** 前端 MUST 阻止提交并给出校验提示
+
+### Requirement: 优先轮询项详情
+
+The admin frontend SHALL query a single priority polling item through `GET /api/admin/polling-priority-items/{id}`. 越权与不存在的响应 MUST 保持一致，不产生可枚举差异。该能力 SHALL NOT 提供优先级分级、有效期与人工重触发入口。
+
+#### Scenario: 查询单项详情
+
+- **WHEN** 用户查看某条优先轮询项详情
+- **THEN** 前端 MUST 调用 `GET /api/admin/polling-priority-items/{id}`
+- **AND** 页面 MUST 展示卡、任务类型、状态、触发类型、执行结果、失败原因、操作者、触发与尝试次数及相关时间字段
+
+#### Scenario: 越权与不存在不区分
+
+- **WHEN** 当前账号无权访问该记录或该记录不存在
+- **THEN** 前端 MUST 按同一错误处理，不得通过响应差异区分越权与不存在
+
+### Requirement: 枚举与状态映射
+
+The admin frontend SHALL map and display the backend enums for task type, status, trigger type and result with their Chinese labels.
+
+#### Scenario: 任务类型展示
+
+- **WHEN** 列表返回 `task_type` 为 `polling:realname` / `polling:carddata` / `polling:package` / `polling:card_status`
+- **THEN** 页面 MUST 分别展示为 实名检查 / 流量检查 / 套餐检查 / 卡状态检查
+
+#### Scenario: 状态与触发类型展示
+
+- **WHEN** 列表返回 `status`（`pending`/`processing`/`completed`/`failed`）、`trigger_type`（`purchase_activated`/`renewal_activated`/`queue_activated`/`addon_activated`/`no_valid_package`/`manual_trigger`）与 `result`（`success`/`failed`/空）
+- **THEN** 页面 MUST 展示对应的中文名称与枚举值
+- **AND** `result` 为空时 MUST 展示为未出结果
+
+### Requirement: 错误响应处理
+
+The admin frontend SHALL handle the documented error responses for the priority queue APIs: `400` 请求参数错误、`401` 未认证或认证已过期、`403` 无权访问、`500` 服务器内部错误。
+
+#### Scenario: 权限与参数错误提示
+
+- **WHEN** 接口返回 `401`、`403` 或参数校验错误
+- **THEN** 页面 MUST 展示对应错误提示且不产生前端异常