顧客掃碼入桌菜單 / 購物車我的訂單送出訂單
廚房看板#A12 · 2 項製作中#A13 · 4 項待出餐#A14 · 1 項新訂單
管理後台RBAC 權限
- 3角色介面：顧客、廚房、後台
- 11Prisma 資料模型
- 16API 路由
- 4Vitest 測試套件
問題
小型餐廳的點餐同時牽涉三種人：顧客要能自己掃碼點餐並知道餐點進度，廚房要即時看到新訂單，店家要能管理菜單、桌位與員工權限，並看到營運數字。三方看的是同一批資料，金額與狀態必須一致，也不能讓任何一端竄改。
功能
顧客
掃描桌上 QR Code 入桌（相機不可用時可手動輸入桌號），瀏覽菜單、選擇加料、購物車與結帳；「我的訂單」會自動更新狀態。
廚房
現場看板每 5 秒輪詢，依狀態列出訂單並推進製作進度。
後台
分類、商品、加料群組、桌位與使用者管理，加上營運 Dashboard 與報表圖表。
架構
關鍵設計決策
金額只信任伺服器
建立訂單時從資料庫重新讀取商品價格與加料選項計算金額，前端送來的金額一律不採用；商品必須屬於該店且仍在販售。
加料規則在後端驗證
每個加料群組都有最少／最多選擇數與是否必選，違反時回傳帶錯誤代碼的結構化錯誤，例如 OPTION_RULE_VIOLATION。
訂單狀態機
NEW → PREPARING → COMPLETED，完成前可取消；COMPLETED 與 CANCELLED 是終態，非法的狀態轉換會被擋下。
RBAC 權限模型
7 種權限、3 種預設角色：ADMIN 擁有全部；MANAGER 管理菜單、桌位、訂單與報表；STAFF 只能處理訂單。
可重現的環境
Docker Compose 等資料庫健康檢查通過才啟動 App，啟動時依序 generate → migrate deploy → seed；seed 每次重建示範資料，可重複執行。
用真的手機測試
Nginx 反向代理讓同一個 Wi-Fi 下的手機直接連線，實際走完掃碼點餐流程。
品質
TypeScript 型別檢查、ESLint，以及 Vitest + Testing Library 的四組測試，涵蓋權限守衛、訂單服務、訂單 API 與報表服務。