代點餐上線後，一個人不必自己操作手機，也能由管理者替他完成訂單。但功能的終點不能只停在「資料庫多了一張訂單」。管理者還要看見被代點者的新餘額，回到成員清單時不能讀到舊值，結束代點後也不能繼續沿用別人的操作情境。

App.jsx 的 handleConfirmSubmit 會更新被代點者的餘額、讓成員餘額清單失效，再重讀該成員的訂單；handleExitDelegatedOrder 則清除代點對象，讀回操作人自己的資料。前端實作

這些程式路徑能證明收尾被設計進功能，但還不能等同於 Production 已完整走過一次。

完整功能切片（feature slice）要跨過一次操作的起點、寫入和收尾；只把各層的修改做完，還不能證明使用流程完整。

先從「替誰訂」走到「回到自己」

Repo 裡的代點流程可以沿著這條路讀：

1. 開啟代點成員選單，載入後端認定可代點的對象；員編篩選只縮小這份清單。
2. 選人後，清除唯讀檢視模式，帶入對方預設取餐樓層，進入日曆並讀取對方訂單。
3. 選擇可操作日期與餐點，確認畫面上的品項、數量、樓層和金額。
4. 送出時仍保留登入操作人，另外附上 targetUserId，表示本次替誰下單。
5. 成功後更新目標餘額、刷新訂單；結束代點時清除目標，再回到自己的情境。

這條路徑讓審查範圍超出按鈕與請求：入口是否選對人，出口是否回到自己，也都是功能的一部分。

Day 13 已拆過操作人與資料擁有者的跨層契約，這裡只沿用一條前提：代點不改變訂單與餘額的歸屬。本篇要看的，是這條前提如何撐住一次完整操作。

五種規則要在同一次操作裡成立

系統把管理角色分成管理員（Admin）與權限較有限的代理管理員（ProxyAdmin）；角色名稱相近，不代表能操作的日期與截止規則相同。

其中「可代點對象」也有具體條件。isEligibleOrderTarget 檢查有效帳號、員編與完整基本資料，沒有把 LINE 綁定列為必要條件。前端不能因為某位成員沒有 LINE，就自行把他當成不能代點的人。資格與時間規則

要注意版本差異：早期版本曾讓 ProxyAdmin 只限當日、但可略過截止；本篇依核對時的程式，採「當日及未來合格日期，仍受截止約束」。拿舊版說明驗收新功能，會得到相反答案。完整版本演進留到 Day 25。

newBalance 接上的，是操作最後一段

下單成功回傳的 newBalance，不能無條件寫到頁面頂端的本人餘額。

前端先判斷是否正在代點：是的話更新 delegatedOrderUser.balance；一般下單才更新登入者自己的餘額。接著將 memberBalancesLoaded 設為 false，表示整份成員清單需要重新讀取，而不是把一個新值硬塞回可能已過期的清單。

取消代點訂單也走同樣的目標餘額收尾。這使「訂單取消了」與「退款已反映在正確的人身上」成為同一個流程的完成條件。相關測試定義同時檢查送出與取消路徑。代點前端測試

Day 14 已談過如何把這個教訓留在測試裡。換成產品視角，它提醒我：成功提示只是中間點，後續畫面是否仍可信，才決定操作是否真的結束。

拆工作時，先保留一條能走完的路

若只拆成前端、後端、資料庫三份工作，每一份都可能完成，卻沒有人負責「返回管理頁後看到什麼」。比較實用的拆法是先寫一條可走完的情境，再標出每一步需要哪些層配合。

例如：管理者替一位有效且未綁 LINE 的成員，在合格日期下單，確認目標餘額更新，再退出代點。另補一條不能成立的情境：截止後由 ProxyAdmin 送出，後端拒絕，不能留下半張訂單或部分扣款。

這些是驗收時應執行的情境，不能用「各層都有測試」替代實際操作結果。正式驗收還要記錄所用版本、角色、日期、回應與畫面狀態；本文的流程判斷依據程式與測試定義，未重跑整套回歸。

另於 2026-10-03 擷取一組頁尾顯示 v0.15.4 的真實畫面，涵蓋選人、代點情境與退出，但沒有送出訂單；因此它只能證明這些介面狀態確實存在，不能證明成功送出後的 newBalance、重新讀取或完整端到端流程。

AI 很快能把按鈕、請求與後端分支接起來。代點餐留下的工程觀察是：需求若只描述新增動作，收尾最容易消失。把「完成後誰看到什麼、退出後恢復誰的資料」一起寫進切片，跨層修改才有共同終點。

本系列實作專案

這是一套持續開發中的便當訂購系統。文章著重「為什麼」，GitHub 保留實際程式碼、文件與演進紀錄。

GitHub：https://github.com/henryfir456/bento-order-app

下一篇會回到店家專區：菜單圖片、資料來源、店家資訊和截止時間集中後，哪些資料真的屬於店家，哪些只是借來顯示？