# 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 行新增代码。
