foodie-server/specs/004-qr-table-order/tasks.md

Tasks: 扫码桌号点餐

Input: Design documents from /specs/004-qr-table-order/ Prerequisites: plan.md (required), spec.md (required)

Tests: 手动测试，无自动化测试任务。

Organization: Tasks grouped by user story to enable independent implementation and testing.

Format: [ID] [P?] [Story] Description

• [P]: Can run in parallel (different files, no dependencies)
• [Story]: Which user story this task belongs to (e.g., US1, US2, US3)

---

Phase 1: Setup (数据库 & 实体基础)

Purpose: 数据库加字段，实体和 DTO 同步更新

• T001 在 pos_order 表新增 table_id BIGINT DEFAULT NULL COMMENT '餐桌码ID' 字段
• T002 [P] 在 order_parent 表新增 table_id BIGINT DEFAULT NULL COMMENT '餐桌码ID' 字段
• T003 [P] 在 ruoyi-system/src/main/java/com/ruoyi/system/domain/PosOrder.java 新增 private Long tableId 字段
• T004 [P] 在 ruoyi-system/src/main/java/com/ruoyi/system/domain/OrderParent.java 新增 private Long tableId 字段
• T005 [P] 在 ruoyi-admin/src/main/java/com/ruoyi/app/order/dto/OrderCreateInput.java 新增 private Long tableId 字段

Checkpoint: 数据库字段已加，Java 实体和 DTO 已同步

---

Phase 2: User Story 1 - 扫码下单关联餐桌码 (Priority: P1) 🎯 MVP

Goal: 下单接口接收可选 tableId，校验有效性，写入订单

Independent Test: 创建一个档口码，模拟下单传入 tableId，检查订单中 tableId 和 tableNum 是否正确

Implementation for User Story 1

• T006 [US1] 在 UserOrderController.java 中注入 ITableQrcodeService
• T007 [US1] 在 UserOrderController.java 中新增独立方法 validateAndFillTableInfo(OrderCreateInput input)：若 tableId 不为空则查询 table_qrcode 记录，校验存在且未停用，以码记录的 tableNo 覆盖 input.tableNum；为空则跳过
• T008 [US1] 在 createOrder 方法中调用 validateAndFillTableInfo(input)，位置在 createOrderParent 调用之前；createOrderParent 和 createOrderChild 中仅新增 setTableId(input.getTableId())，不改动其他逻辑
• T009 [US1] 手动测试：创建档口码 → 下单传入 tableId → 验证订单 tableId 和 tableNum 正确 → 传入无效 tableId → 验证报错

Checkpoint: 扫码下单流程完整，订单正确关联餐桌码

---

Phase 3: User Story 2 - 扫通用码点餐 (Priority: P2)

Goal: 验证通用码场景下 tableId 同样正确关联

Independent Test: 创建通用码（type=1），模拟下单传入通用码的 tableId，检查订单正确

Implementation for User Story 2

• T010 [US2] 手动测试：创建通用码 → 下单传入通用码 tableId → 验证订单关联到通用码而非档口码
• T011 [US2] 手动测试：同一通用码下，选择不同档口分别下单 → 验证每个订单的 tableId 都指向同一个通用码

Checkpoint: 通用码场景验证通过

---

Phase 4: User Story 3 - 商家查看桌号 (Priority: P3)

Goal: 商家端订单详情展示桌号

Independent Test: 商家端查看带桌号的堂食订单，确认桌号正确显示

Implementation for User Story 3

• T012 [US3] 确认 PosOrder 返回的 JSON 中 tableId 和 tableNum 字段在订单详情接口中正确返回（后端无需改动，MyBatis-Plus 自动映射）
• T013 [US3] 手动测试：商家端查看堂食订单详情 → 确认显示桌号 → 查看非堂食订单 → 确认不显示桌号

Checkpoint: 商家端能正确看到桌号

---

Phase 5: Edge Cases & Polish

Purpose: 边界情况验证和收尾

• T014 不传 tableId 下单 → 验证普通下单流程不受影响
• T015 [P] 传入已停用的 tableId 下单 → 验证报错提示"该餐桌码已停用"
• T016 [P] 传入已删除的 tableId 下单 → 验证报错提示"餐桌码不存在"
• T017 前端扫桌码后中途退出 APP 再回来 → 验证 tableId 丢失后按普通下单处理

---

Dependencies & Execution Order

Phase Dependencies

• Phase 1 (Setup): No dependencies - start immediately
• Phase 2 (US1): Depends on Phase 1 completion
• Phase 3 (US2): Depends on Phase 2 (共用同一套代码逻辑，仅验证场景不同)
• Phase 4 (US3): Depends on Phase 1 (数据已有，仅需确认返回)
• Phase 5 (Polish): Depends on Phase 2 completion

Parallel Opportunities

• T001, T002 可并行执行（不同表）
• T003, T004, T005 可并行执行（不同文件）
• Phase 3 和 Phase 4 可并行测试（不同验证维度）

---

Implementation Strategy

MVP (Phase 1 + Phase 2)

1. 完成数据库加字段
2. 完成实体和 DTO 加字段
3. 完成下单接口校验逻辑
4. 手动验证核心流程

核心代码改动集中在 UserOrderController.java，约 10-15 行新增代码。