# Tasks: 可切换的原生业务推送通道

**Input**: `specs/033-native-push-routing/spec.md`、`plan.md`

**Execution**: 当前 `test-202609v2` 分支；不创建新分支。每项先写并运行失败测试，再实现、验证、核对暂存范围并提交。默认模式始终为 `uni`。

## Phase 1: 默认通道与配置（US1）

- [ ] T001 [US1] 在 `ruoyi-admin/src/main/java/com/ruoyi/app/push/` 定义接收端枚举、`business-push` 配置及原生模式启动校验；`ruoyi-admin/src/main/resources/application.yml` 仅设置默认 `uni` 与非秘密占位符。
- [ ] T002 [US1] 在 `ruoyi-admin/src/test/java/com/ruoyi/app/push/BusinessPushPropertiesTest.java` 覆盖默认启动、原生凭据缺失/无效和三端配置。

## Phase 2: 原生发送器（US2、US3）

- [ ] T003 [US2] 在 `FcmPushSender.java` 实现三命名 FirebaseApp 和按接收端 FCM 发送；在 `FcmPushSenderTest.java` 验证项目隔离、payload、失效错误与无敏感日志。
- [ ] T004 [US3] 在 `ApnsPushSender.java` 实现三端证书型 APNs HTTP/2 发送及环境选择；在 `ApnsPushSenderTest.java` 验证 topic、payload、证书错误与响应分类。

## Phase 3: 统一路由与业务集成（US1–US4）

- [ ] T005 [US1–US4] 在 `BusinessPushService.java` 实现 uni/native 选择、当前账号 token 读取、地址判定及异常隔离；在 `BusinessPushServiceTest.java` 覆盖默认 uni、六种原生组合及不自动回退。
- [ ] T006 [US1–US4] 修改 `PayPush.java` 的普通业务包装方法委托 T005；保留低层 uniCloud 方法供 uni 模式及排除路径使用，验证消息中心不重复入库。
- [ ] T007 [US2–US4] 将在用普通业务直连与 CID 前置过滤迁移到统一路由：`MerchantNotificationRouter.java`、`LinePayOrderNotificationService.java`、`OmgPaymentNotifyService.java` 和当前有效订单 Controller；同步更新相关测试。不改音视频、废弃入口或临时测试推送接口。

## Phase 4: 文档与验证

- [ ] T008 在 `specs/033-native-push-routing/quickstart.md` 记录三端外部凭据配置、默认关闭、启用/回退、真机检查；更新 `specs/012-im-user-integration/code-status.md` 与 `docs/order-push-overview.md`。
- [ ] T009 使用 JDK 21 运行定向测试和 `ruoyi-admin` 模块构建；核对完整 diff、暂存范围及未执行的外部 FCM/APNs 真机验证，再提交文档收口。

## Dependencies

T001–T002 → T003/T004 → T005–T006 → T007 → T008–T009。FCM 与 APNs 发送器可以独立评审，但本任务按当前会话顺序执行，不启动 Agent。