foodie-server/specs/035-user-notification-voice/tasks.md

Tasks: 用户通知 eventScene 与前端交接

Input: spec.md、plan.md、frontend-integration.md。

进度: 已验证（本期后端测试/构建和审查修复通过；完整回归 1 项既有失败另记）。本期只新增 eventScene；不修改 App、云函数、音频或数据库。任务按现有用户故事追踪，步骤/签名/断言以 plan 为准；控制器公共夹具集中于 UserOrderNotificationSceneTest，其余旧控制器测试继续回归。

Phase 1: 契约（Plan Task 1）

• T001 [US2] 新建 ruoyi-admin/src/test/java/com/ruoyi/app/order/dto/OrderPushBodyDtoTest.java，证明只有新增场景、旧工厂不输出场景的预期失败。
• T002 [US2] 新建 ruoyi-admin/src/main/java/com/ruoyi/app/push/UserNotificationScene.java，修改 ruoyi-admin/src/main/java/com/ruoyi/app/order/dto/OrderPushBodyDto.java 的可选 eventScene 和 getUserJson 工厂；不建立额外事件封装类。
• T003 [US2] 运行 Task 1 测试及差异/暂存检查，独立提交契约，不推送。

Phase 2: 配送与入库（Plan Task 2）

• T004 [US1] 扩展 ruoyi-admin/src/test/java/com/ruoyi/app/order/PosOrderQsOprateControllerTest.java、PosOrderShOprateControllerTest.java、PosOrderAdminStatusControllerTest.java 和 flashdelivery/service/FlashDeliveryNotificationServiceTest.java、FlashDeliveryMultiPickupTest.java，运行成功场景、无地址、回滚/部分取件的失败测试。
• T005 [US1] 修改 ruoyi-admin/src/main/java/com/ruoyi/app/order/PosOrderQsOprateController.java 与 PosOrderController.java 的有效用户通知，明确三配送动作场景；历史 state 原值不变。
• T006 [US1] 修改 ruoyi-admin/src/main/java/com/ruoyi/app/order/PosOrderShOprateController.java，区分商家接单/出餐和自配送开始/完成；直接送达不补派送。
• T007 [US1] 修改 ruoyi-admin/src/main/java/com/ruoyi/app/flashdelivery/service/FlashDeliveryNotificationService.java，仅寄件用户成功接单/全部取件/送达带 eventScene，骑手路径不变。
• T008 [US4] 上述有效用户路径解除地址对入库的阻断，沿现有提交后通知边界；完成 Task 2 测试及范围检查后独立提交，不推送。

Phase 3: 现有其他通知（Plan Task 3）

• T009 [US3] 扩展 ruoyi-admin/src/test/java/com/ruoyi/app/pay/LinePayOrderNotificationServiceTest.java、omgpay/OmgPaymentNotifyServiceTest.java、order/DeliveryOrderNotificationServiceTest.java，运行支付/取消场景与非用户隔离的失败测试。
• T010 [US3] 修改 ruoyi-admin/src/main/java/com/ruoyi/app/pay/LinePayOrderNotificationService.java、omgpay/OmgPaymentNotifyService.java、order/DeliveryOrderNotificationService.java 的已有用户通知；支付/取消仅用独立用户 body，不污染商家/骑手。
• T011 [US4] 验证 type=0 不变、核销幂等、无地址仍入库，Task 3 测试通过后独立提交，不推送。

Phase 4: 验证及交接（Plan Task 4）

• T012 [US2] 扩展 ruoyi-admin/src/test/java/com/ruoyi/app/push/BusinessPushServiceTest.java、FcmPushSenderTest.java、ApnsPushSenderTest.java 和 utils/event/PushEventListenerTest.java，确认仅场景透传、旧通知/声音不变。
• T013 [US4] 只有测试确证 uni 用户参数编码破坏场景时，才修 ruoyi-admin/src/main/java/com/ruoyi/app/utils/PayPush.java 的该路径；不调整云函数。
• T014 [US2] 收口 specs/035-user-notification-voice/frontend-integration.md：七场景、原四字段+eventScene、JSON、前台要求、客户端选语言与无新增元数据的能力限制。
• T015 [US4] 执行 plan 的 JDK 21 定向测试/模块构建及 diff 检查，记录实际结果、提交 SHA、未验证项，确认所有改动只在后端与本 feature 文档后提交，不自动 push。

2026-10-09 实施与验证记录

• 契约提交 deb899b：只新增 eventScene，旧工厂键集合与旧字段值兼容；失败测试后 8/8 通过。
• 配送提交 a67107d：现代/旧骑手入口、自配送和商家出餐场景；70/70 通过。控制器共用事务/异步夹具集中在 UserOrderNotificationSceneTest，其他既有控制器测试继续回归。
• 支付/取消提交 1f3ba28：LINE/OMG 支付及现有外卖用户取消场景；22/22 通过，重复支付回调不再通知，商家/骑手 body 不增加场景。
• 通道与入库回归 49/49 通过；旧 payload、default sound、qsRing、pushsound.caf 保持。uni 仍转发完整 JSON，无证据需要修改 PayPush 参数编码，T013 按条件无需改代码。
• JDK 21 最终统一定向测试 149/149 通过（包含 UserOrderNotificationSceneTest），模块 package 为 BUILD SUCCESS。无 SQL、App、云函数、PC 或通道生产配置变更。
• 本地提交不自动 push；未部署、未生产试发，真实云端 payload 透传、App 音频/前台效果与真机尚未验证。
• 额外执行 mvn -pl ruoyi-admin -am test：admin 944 项，943 通过、1 失败、0 错误。唯一失败为 BackendI18nBundleContractTest 的泰文键集合检查：缺少 10 个 stall.qualification key；开始修改前的 9e4e5f 提交已存在同样缺失，语言包及该测试本次未修改。按范围不夹带无关修复，不能宣称完整回归全绿。一次只读整体审查另补记；定向测试也不代表 App 功能验收。

最终审查与修复验证

• 一次只读审查范围 9e4e5f3..9aff95d：无 Critical/Minor，一项 Important 是旧资料编辑复用 chuCan 错带 MERCHANT_READY。
• 已修正：实际 dispatchOrder 明确传场景；旧无状态编辑保留历史文字、不新增场景。真实 setOrderNoState 路径原状态 0/1/2 的三例回归 RED（3 失败、0 错误）后 GREEN；出餐测试改为验证实际 dispatchOrder，非用户 body 仍无场景。
• 修复后统一定向测试 152/152；独立商家/场景测试 33/33，避免测试夹具依赖 AsyncManager 初始化顺序；修复后 module package BUILD SUCCESS。
• 修复后再次全模块回归：admin 947 项，946 通过、1 失败、0 错误；唯一失败仍是上述基线泰文缺 10 个摊位审核 key。没有将这项失败隐藏或记作完整回归通过。
• 最终未验证项：真实云端部署是否保留 payload、实际推送到达、App 音频/前台播放、后台与锁屏真机行为、生产环境联调。本期不修改这些部分。

实施取舍及代价

• 按用户要求在原 checkout 实施，不创建 worktree/分支：没有额外隔离并发工作区；按任务明确暂存范围避免混入改动。
• 用 PowerShell 命令和本地执行记录替代 Bash 专用记账脚本：符合 Windows 环境，无产品行为变化，记录与验证命令保持等价。
• 共有控制器测试集中于 UserOrderNotificationSceneTest：避免重复异步/Spring 夹具，既有三个控制器测试仍运行；仅测试组织不同。
• 不修基线泰文摊位审核 key 缺失：与本次单字段范围无关，全量回归因此仍红，另行处理。
• 不纠正旧资料编辑已有“出餐”文字通知：保留用户要求的旧通知行为；其文字仍可能不合理，但不会新增错误语音场景。
• 云端透传和 App/真机声音交接前端：遵守不改 App/云函数和不部署的边界，本地验证不保证线上投递及播放效果。

Dependencies / 前端责任

T001–T003 → T004–T008 → T009–T011 → T012–T015；按批次做失败测试、实现、通过验证和提交，不按字段拆小批次。

前端负责音频、语言选择、统一入口、播放队列、生命周期、点击路由及真机验收。本期无新增事件标识、接收用户或时间，不能宣称已实现精准去重、跨账号校验或完整乱序判断。真实云端是否保留 eventScene 需联调；失败时反馈，不擅自修改云函数。