break
aab56a6998
All checks were successful
构建并部署到测试环境（无 SSH） / build-and-deploy (push) Successful in 14m13s
新增 000228 成对迁移 tb_polling_priority_item：卡、任务类型、状态、触发类型、来源订单/套餐使用记录、
触发次数与来源集合、尝试次数、失败原因、人工原因与操作者、店铺快照与各时间列；以活动项部分唯一索引
uq_polling_priority_item_active（仅 deleted_at IS NULL AND status IN ('pending','processing') 占键位）
表达「同卡同任务类型至多一条活动项」，另有状态/时间索引与全列注释；down 守卫在存在活动项或未终态行时
拒绝回滚并给出中文原因。
新增优先轮询请求可靠事件 polling.priority.requested（载荷版本 v1、事件键前缀 prio:）与消费者：只在原
业务事务内追加、幂等键稳定；消费者按卡 × 纳入任务类型（realname/carddata/card_status/package）逐条
建项并在提交后下发执行提示，重复投递只合并触发次数、来源集合与最近触发时间，不新建行也不重复调用。
触发点为四类自动场景 purchase_activated / renewal_activated（按同载体更早套餐使用记录判定）/
queue_activated / addon_activated 与「无有效套餐」no_valid_package（仅在普通套餐轮询来源且存在待生效
套餐使用记录时追加；事件通道显式拒绝 manual_trigger）；入队对象恒为卡，绑定设备资产在触发事务内冻结
在用卡快照逐卡建项，不使用设备当前卡槽口径。
轮询共享基类新增认领接缝：四个 Handler（realname/carddata/card_status/package）在并发信号量之后、调用
上游之前探测活动项——待执行条件认领、执行中且 90 秒租约未到期则跳过并延后、无活动项时行为与既有完全
等价；超租约允许相邻执行接管，尝试次数只在真正发起执行后累加，未达上限（3）回到活动态按既有间隔重排，
达上限或业务校验类失败进入失败终态并保留可安全展示原因；执行前校验卡自身与绑定设备的轮询开关。未引入
通用卡级锁与 Redis 活动标记，分片队列的出队、入队与移除路径未改动。
提示通道按任务类型独立键（polling:priority:{taskType}），与既有手动触发队列分离；调度器在同一周期内先
排空优先提示、再排空手动触发队列，提示排空不受分片背压跳过影响；未新建调度设施或异步任务类型。
新增人工优先入队与只读查询三条路由 POST /api/admin/polling-priority-items、
GET /api/admin/polling-priority-items、GET /api/admin/polling-priority-items/:id：人工入队复用既有轮询
权限判定（抽取为同包共享函数），原因必填，不受每日 500 次上限与 24 小时去重约束，重复抑制由活动项合并
承担；读侧按店铺快照下推数据范围，越权与不存在不可区分，不提供优先级分级、有效期或人工重触发入口。
新增 7 个审计动作（enqueue/claim/fail/retry/complete/dequeue/manual_denied）与资源
polling_priority_item，并按（操作者类型，来源）注册，人工侧与 Worker 侧均通过来源校验。
同步 OpenAPI 文档装配三处与路由注册；归档 Change 至
openspec/changes/archive/2026-09-17-add-priority-polling-queue/ 并同步主 Spec（新增
priority-polling-queue、polling-operations 追加单次执行互斥 Requirement 与三条路由索引）与上下文健康
证据（requirement-evidence 150 行、入口矩阵 http 403 / async 56）。
本机验证：junhong_cmp_test 与隔离 Redis DB 15，未连生产、未启动 Worker/API、未调用运营商上游；迁移
up/down/up 与 down 守卫实测（含 dirty=true 记账口径与 force 恢复），A–F 批 94 PASS、接缝 63 PASS、
提示通道 12 PASS、清理零残留 20 PASS。成功路径 Complete、真并发互斥、尝试上限第 3 次判定、HTTP 层权限
矩阵、通道阈值持锁复机边界与三类生效触发点生产集成留待测试部署验证（见
docs/verification/add-priority-polling-queue-verification.md 第 4 节）。自动化测试按项目决策为 N/A，
未新增 *_test.go。
2.7 KiB
2.7 KiB
Scope
- 迭代编号：
AUG26-016。
Why
紧急卡状态查询与普通轮询竞争，无法保证处理顺序或追踪加急事实。
What Changes
- 新增受限管理的卡轮询优先队列：以持久化事实记录触发来源、次数、最近时间与执行结果；同一卡同一轮询任务类型至多一条活动优先项。
- 触发来源：主套餐购买后立即生效、排队主套餐顺延生效、加油包生效、资产无有效套餐且存在待生效套餐使用记录、具备既有人工触发权限的账号人工入队。
- Worker 复用既有轮询任务类型与既有轮询内容优先领取执行；同一卡同一任务类型只允许一次上游调用，优先项不以任何方式使卡退出普通轮询。
- 复用既有手动队列式的执行提示通道（独立提示键，调度周期内先排空），不新建调度设施、异步任务类型或队列。
- 新增最小可读接口（列表与详情，支持筛选与分页），权限与人工入队一致并按数据范围下推。
非目标
- 不做优先级分级（P0/P1/P2）与优先级规则配置。
- 不做有效期字段与过期出队语义。
- 不做独立异常记录页、人工重触发入口，以及资产/卡详情的优先轮询状态展示。
- 不新增可维护的参数配置项；不改普通轮询内容、并发上限、失败重试与外部调用保护。
- 不做普通轮询异常补偿场景（现状无判据，登记为后续独立 Change）。
- 不改人工触发 API 的任务类型白名单、每日次数上限与 24 小时去重规则。
Capabilities
New Capabilities
priority-polling-queue: 卡轮询加急队列：触发场景与入队事实、同卡同任务类型唯一活动项与合并、优先调度与执行提示通道、认领与租约、尝试上限与出队、事实与查询的可追溯。
Modified Capabilities
polling-operations: 新增「优先轮询项与普通轮询的单次执行互斥」行为要求；既有人工触发的任务类型白名单、每日次数上限与 24 小时去重保持不变。
Impact
- 路由与文档装配：新增后台路由与 Handler，并同步文档工厂、API 组装与文档生成入口三处装配。
- Worker：新增可靠事件消费者注册；调度器新增优先提示排空。
- 轮询执行：纳入执行集合的轮询任务类型增加认领接缝（无活动项时行为与当前完全一致）。
- 触发写入：订单与套餐生效事务新增优先请求事件追加（同事务写入，提交后投递）。
- Schema：新增成对迁移与优先项表（含活动项部分唯一索引）。
- 常量与审计：新增触发类型、状态与尝试上限常量，以及轮询优先队列的审计动作与资源常量。