tasks.md 2.7 KB

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。