# 預約流程模擬指南 (Reserve Simulation Guide)

本指南整合了預約系統中 **單人 (Single)** 與 **多人 (Multi)** 情境的模擬路徑，對接 **會員 (Member)** 與 **情人 (Partner)** 兩端的程式碼邏輯與組件顯示。

---

## 目錄

### I. [基礎] 單人預約流程 (Single Task Flow)

1. [完美流程 (Happy Path)](#1-單人-完美流程-happy-path)
2. [會員取消情境 (Member Cancellation)](#2-單人-會員取消情境)
3. [情人取消流程 (Partner Cancellation)](#3-單人-情人取消流程)
4. [打槍流程 (Rejection Flow)](#4-單人-打槍流程)
5. [縮短時間流程 (Shorten Date Flow)](#5-單人-縮短時間流程)
6. [遲到處理流程 (Late Arrival Flow)](#6-單人-遲到處理流程)
7. [隱藏分支與初期取消 (Hidden Branch Paths)](#7-單人-隱藏分支)

### II. [進階] 多人約會流程 (Multi Task Flow)

8. [多人完美流程 (Multi Happy Path)](#8-多人-完美流程)
9. [多人流程差異與待補項 (Gap Analysis)](#9-多人流程差異與待補項)

### III. [通用] 定位與通知

10. [MQTT 同步說明](#10-mqtt-同步說明)

---

## I. 單人預約流程 (Single Task Flow)

### 1. 單人：完美流程 (Happy Path)

- **第一階段：邀約與接受 (LOVER_RECEIVED)**
  - **兩端**: 會員顯示 `<NewOrder />`；情人顯示 `<PartnerNewOrder />`。
  - **操作**: 情人點擊「同意接單」。
- **第二階段：付款 (LOVER_ACCEPTED)**
  - **兩端**: 会员完成付款；情人顯示 `<PartnerPaymentOrder />`。
- **第三階段：交通與抵達**
  - **情人操作**: 依序點擊「已出發」(`LOVER_DEPARTED`) -> 「已抵達」(`LOVER_ARRIVED`)。
- **第四階段：確認與約會**
  - **會員操作**: 會員點擊「確認抵達」(`MEMBER_CONFIRMED_ARRIVAL`)。雙方進入 `<DatingOrder />`。
- **第五階段：約會完成**
  - **結果**: 進入 `<SuccessOrder />` / `<PartnerSuccessOrder />`。

### 2. 單人：會員取消情境

- **付款後未出發**: 退還情人押金；全額退還會員。
- **情人出發後**: 扣除「打槍費用」補償情人，退還會員剩餘。
- **情人遲到 (>15分)**: 觸發彈窗，會員取消可獲全額退款。

### 3. 單人：情人取消流程

- **未出發前取消**: `LOVER_CANCELLED`，全額退還會員。
- **出發後取消**: 罰沒情人 `押金費用`，退還會員所有已支費用。

### 4. 單人：打槍流程

- **觸發**: 抵達後 15 分鐘內。
- **操作**: 會員支付「打槍費用」，狀態轉 `MEMBER_REJECTED`。
- **結案**: 情人點擊「確認打槍」後退還押金與訂單費用。

### 5. 單人：縮短時間流程

- **操作**: 會員發起縮短請求 (`MEMBER_REQUEST_SHORTER_DATE`)。
- **同意**: 情人同意後，依 `earlyRefundRate` 退款給會員。

### 6. 單人：遲到處理流程

- **協商**: 會員可選「遲到扣款」或「延長時間」。
- **回應**: 情人可「同意延長」或「不同意改為扣款」。

### 7. 單人：隱藏分支

- **情人拒絕接單**: 結案。
- **會員付款前取消**: 結案，無扣費。

---

## II. 多人約會流程 (Multi Task Flow)

### 8. 多人：完美流程 (Multi Happy Path)

在多人約會 (`taskType: 'multi'`) 中，雖然是一個整體的約會請求，但對於會員端而言，與每一位情人的互動（付款、確認抵達、結案）都是**獨立且並行**進行的。

#### 第一階段：發起與接單 (Individual Interaction)

- **會員操作**: 發起「多人約會」請求。
- **情境**: 會員頁面 `multi/[id].vue` 會列出所有受邀情人，每一位初期狀態皆為 `LOVER_RECEIVED`。
- **情人端**: 每位情人在自己的 `partner/reserve/[id].vue` 看到 `<PartnerNewOrder />` 並獨立決定是否接單。

#### 第二階段：個別付款 (Individual Payment)

- **會員端**:
  - 當某位情人點選「同意接單」後，該情人在 `multi/[id].vue` 的狀態轉為 `LOVER_ACCEPTED`。
  - 會員需在該情人的卡片點擊 **「確認邀約/付款」**。
  - **組件**: `MultiOrderAction.vue` 觸發 `payOrderFee`。
  - **注意**: 多人模式下，會員是針對「個別情人」的訂單費用進行支付與確認。支付完成後，該情人狀態變為 `MEMBER_FINISH_PAYMENT`。

#### 第三階段：交通階段 (Independent Travel)

- **情人端**: 每一位情人獨立執行「出發」與「抵達」。
  - **狀態流轉**: `LOVER_DEPARTED` (已出發) -> `LOVER_ARRIVED` (已抵達)。
- **會員端**: 各別情人的卡片會即時同步其交通狀態。
  - **UI 表現**: 若情人已抵達，卡片將出現「確認抵達」按鈕。

#### 第四階段：確認抵達與開始 (Individual Check-in)

- **會員操作**: 當情人抵達後，會員在該情人的卡片點擊 **「確認抵達」**。
  - **API**: `requestTaskLoverStatusModify` 帶入 `會員確認情人已抵達`。
- **狀態**: 該情人的狀態獨立轉為 `MEMBER_CONFIRMED_ARRIVAL`。

#### 第五階段：約會中與結案 (Independent Completion)

- **會員操作**: 約會結束時，會員在該情人的卡片點擊 **「約會完成」**。
  - **API**: `refundToWallet` (退還該情人的押金費用) 並帶入結案狀態 `會員約會完成`。
- **狀態更新**: 該情人卡片變更為 `MEMBER_FINISHED`，約會正式結束。

---

### 關鍵技術對接點：

1.  **組件獨立性**: 會員端 `MultiParticipantCard.vue` 透過 Props 傳入個別情人資料，其內部的 `MultiOrderAction.vue` 確保所有 API 呼叫都精確帶入 `loverId`。
2.  **狀態並行**: 系統架構允許狀態異步。例如：一名情人可能已經進入打槍（Rejection）倒數，而另一名情人可能才剛抵達準備開始。

---

### 9. 多人流程差異與待補項 (Gap Analysis)

經過代碼比對，多人流程在異常處理上仍有部分 UI 斷點。

- **✅ 已支持狀態 (Supported/Fixed)**:
  - `LOVER_ACCEPT_EXTEND_DATE_FOR_LATE`: 情人同意遲到延長後，會員仍可執行「約會完成」、「打槍」或「縮短時間」。
  - `LOVER_REJECTED_EXTEND_DATE_FOR_LATE`: 情人不同意延長（改為扣款）後，流程回歸正常進行。
- **✅ 已修復項目 (Fixed)**:
  - `useRefund.ts`: 增加 `loverId` 參數，確保精確退款。
  - `Partner Reserve Page`: 移除 `lover[0]` 寫死，改為動態識別當前登入伴友，修正頭像、ETD 與結束時間顯示。
  - `Partner Components`: 全面掃描並修正接單、打槍、縮短時間等組件中的 lover 識別邏輯。
  - 多人流程在「縮短時間」與「打槍中」不渲染複雜組件，僅以文字顯示「等待回應中...」。

---

## III. 通用：定位與通知

### 10. MQTT 同步說明

- **機制**: 監聽 `taskNew` 類型通知。
- **操作**: 點擊 MQTT 通知引導前往預約詳情頁，頁面重載後會根據 `taskStatus` 自動切換至正確的組件，達成兩端同步。