一句話總結：採購單的雲端化（thin-client）+ 同步速度優化兩大基礎建設都完成， 用戶提的「付款帳戶追蹤」feature 也 ship 完整。POS 上架 9 個 feature 排在 有精神時段，主 App 重構排在 睡覺自動跑，瑣碎 debug 排在 低精神時段。
所有小任務都屬於某個大計劃。點開可以看完整 task list 和進度。 右下角「大計劃」標籤 可以從任何 item 跳到對應大計劃。
目標：所有商業邏輯搬到 server（Route → Orchestrator → Gate + Primitive + Repository 4 層），
App 只負責顯示 + 收使用者操作。改規則改一次就全部生效，3 個 App 不會 drift。
進度：3/14 個 PO 動作完成、16 張 audit card 排隊。受影響 entity：
PurchaseOrder（pilot）、Recipe、Vendor、Ingredient、MenuItem、Settings、Budget、Tactic 等。
目標：App 啟動 / 下拉刷新時的同步速度大幅提升。
已驗證：4256 ms / 2 個 HTTP（vs legacy 49000 ms / 60+ HTTP）= 12 倍快。
剩下：HybridSyncManager 補償同步 + DataSyncService 內部 syncer 接到 bundled API，再省 ~50 個 HTTP。
目標：每筆錢進出（訂金、營收、採購、退款、臨時收支）都記到 AssetTransaction 表， 老闆能準確知道每個帳戶餘額、每月哪邊賺哪邊花。
有發現新 bug 隨時告訴我。沒精神時段適合做這個。
API key、Webhook、Stripe migration 等基礎建設。多數可在睡覺時段做。
看得見的工具，幫助老闆 + AI 同步狀態。
根據老闆當下精神狀況選擇做什麼。每個 item 點一下展開 看「當時的提示詞」+「無腦測試 checklist」（如果有）+「所屬大計劃」。
⋮⋮ 把任務拖到別的時段欄。
順序會存在你瀏覽器（localStorage）。下方有「重設順序」按鈕可恢復預設。
測試1:點擊「已付」過後，最近的交易紀錄裡面沒有顯示已付的貨款，用戶選擇已付的時候是不是應該要選擇付款帳戶，這樣才可以完全掌握每個帳戶付出去多少錢？老闆選擇的設計（A+C）：
我選A+C，跳出選單的同時，有預設的帳戶可以直接選擇，預設的選項可以從設定裡面去設定
✅ [DefaultPaymentAccount] 預設付款帳戶已更新。關閉 sheet 重進，仍打勾。✅ [PO Pay] API success: ... → status=paid, asset=...✅ [PO Pay] API success: ... → status=unpaid⚠️ [PO Pay] API failed, rolling back → PO 自動回到欠款，paidFromAssetId 清空第四部點擊取消訂位之後不是跑到退款待處理，是進入取消待確認，詳細的定位資訊如同畫面，同意取消的那個按鈕應該要改成兩個按鈕，雖然政策規定是定位前24個小時內取消不退訂金，但是在這個按鈕上面應該還是可以讓用戶自己選擇同意取消並退款或者是同意取消不退款，如果點擊同意取消並退款，就會顯示政策規定的機種退款%數讓用戶選擇要退多少錢，用戶選擇之後呢就會進入退款程序，出現帳號後五碼讓餐廳端填寫，餐廳端匯完錢之後填寫後五碼按下送出就會發送一封郵件給客人，如果會匯款的金額大於政策規定的金額，應該要寫理由，並且有理由的範本：我們的退款政策是XXX，老闆權衡了一下，決定退款X%。目前按下同意取消按鍵之後這組定位會直接被刪除（直接在定位系統上面消失），不確定是在UI層面消失還是連supabase裡面都消失，我希望他一直留在系統裡面，以供後續查看比對。
我覺得訂位頁面上面的分類膠囊應該要重新整理一下，內容的部分也應該要整理一下，「即將到來」這個膠囊是不必要的可以刪掉，今日和全部的膠囊排在第一二位順序不會變，其他的膠囊如果有出現 badge 就會自動往前排序，不過最好把每一個分類的膠囊都直接顯示不需要滑動，如果是直接顯示的方式，就應該要按照訂位的時間軸排序。如果點擊月曆檢視模式，膠囊應該要消失，變成一個返回分類檢視的按鈕。
點擊月曆檢視模式的某一天，就會變成日檢視模式，可以直接重用座位安排裡面的時間軸畫面，在座位安排時間軸畫面，拖動訂位區塊，應該要可以改變訂位的時間、或者是換桌安排（要記錄在那個預先座位安排的表單裡，並標記是手動安排的座位，不會隨著別的訂位自動安排而變更，等到客人入座的時候就會按照手動安排來入座，後續的客人訂位也會參考這個表單安排座位（已經有這個功能幫我確認一下））在日檢視模式點擊任何一個訂位就可以看到訂位詳細資訊。
我現在在測試#4，客人先訂位，在老闆還沒有確認訂位之前就修改人數，當老闆點擊核准修改，其實就等於是確認訂位了，所以不必按兩次，核准修改這個按鈕點擊後的效果等同確認訂位。還有就是，要讓老闆判斷是否可以核准訂位，應該要直接顯示當天那個時段的訂位和桌位分佈，讓老闆知道這個客人有位子，而且安排的桌位合理。如果老闆覺得不合理也可以調整桌位後點擊核准修改，就會記錄下老闆的手動安排。進度：Phase A 已 ship（orchestrator auto-confirm），Phase B/C 待設計 POS UI
我在測試#3的時候，用老闆的帳號邀請員工加入餐廳，當老闆送出邀請後，我想改一下行為： 1、員工 email 收到邀請，點擊 email 裡面的連結後跳出下載 app 的連結（放在 todo 裡面（現在還沒有正式連結））、填寫員工基本資料的表單連結（放在 chefsmate.app 網域底下）（符合 ChefsMate 主設計風格）（填寫一些正常公司會需要的資訊） 2、如果員工的手機在老闆發出邀請的當下正開啟著 App，則會跳出確認加入的對話框（希望對話框符合 ChefsMate 主設計風格），點擊確認後，如果還沒有填寫員工基本資料，則會跳出填寫員工基本資料畫面。（如果能重用 web 上的表單設計最好）（員工的基本資料會放在 ChefsMate Staff 裡面）
還有就是如果補關帳的時候有列出尚未結帳的點餐單，應該要可以讓用戶點擊進去訂單詳情看是誰還沒結帳、點了什麼東西、顯示聯絡方式和一個處理這張單的section（刪除訂單/補結帳/列成耗損訂單（忘記跟客人結帳）（客人可以在事後在某個地方找到這筆訂單補結帳，如果聯絡得到的話）/店家請客（優惠為0元），可以讓用戶多筆訂單一起處理或是單筆單筆點進去處理
Q1打開收銀機的用意應該是有時候會有臨時性支出用收銀機裡面的錢付款，應該把這個功能先改寫為「臨時支出/收入記帳」，如果有臨時支出/收入（比如買文具/收到小費）就可以在這裡記帳，並且同步到 chefsmate 主App的記帳功能、POS的關帳功能。留一個收銀機接口，未來如果我突然改變主意想要讓用戶也可以接上收銀機的時候，就可以擴充這個按鈕。
Q3臨時消費sheet應該就跟Q1的功能一樣。
PO的流程可以做到點貨完成了，但是「已付、欠款、新增項目」這三個按鈕我覺得應該要融合在點火流程裡面...
1. 時間軸的欄寬可以縮小一些，當用戶提起（拖移的動作拆分位：長按、提起、移動、放下）某個訂位時，時間軸的欄寬會自動變得更窄（訂位的卡片寬度響應變窄），讓用戶能看到更多時間節點，並會在時間表的上方標寫現在所在的桌號時間段（從長按開始到放下前都會顯示，以用戶設定的可訂位間隔時間為單位）並會將訂位卡片顯示為半透明卡片；用戶在移動訂位的時候會有手機的微震動觸覺回饋，代表吸附到某個間隔時間，並且會有小紅線段在時間軸上表示現在所在位置。 2. 時間軸的時間標示：應該要按照員工的上班時間區段來顯示... 3. 把「推算」改成「系統安排」；待確認推算改成「待確認+系統安排」；如果手動安排的結果跟系統安排一樣，則顯示為手動安排。如果點擊任何一個手動安排的訂位會有一個按鈕出現：「還原為系統安排」... 4. 上一輪做的還原上一步按鈕沒有真的還原上一步，會亂跳請看影片
想到什麼新功能、想改的 UX、想看的報表，先丟進來。
AI 每次來會 review 一次，覺得適合就會幫你加進「大計劃」或「三條路線」對應位置。
💾 願望存在你瀏覽器（localStorage）。要分享給 AI 看請按「匯出」貼給我。
這些是寫在 CLAUDE.md 跟我各個 skill 裡的「工作守則」。
老闆懂這些就知道為什麼我會這樣做（而不是另一種方法）。
只負責解析輸入、呼叫 Orchestrator、把 Result 翻成 HTTP response 或 UI state。不做決策、不拼 SQL。
依 Gate 結果組合 Primitives，回 Result type。商業流程的順序在這裡決定。
輸入 state 回傳 boolean / decision。不碰 DB、不發 IO。
例：canTransferReservation(status)、isTableCapacityEnough(...)。
一次 DB write / 一次 push / 一次 email。
例：removeMember、updateDepositStatus、insertSeatingAssignment。
這些 skill 我看到對應的檔案就會自動 follow 規則，避免重複踩過的坑。
Backend/Data/Supabase/Repository/ 下的 UpsertPayload 時觸發。避免 RLS 42501、欄位漏寫。
POS_流程邏輯圖.md。
避免「同一個人因換手機號被當兩個 user」的 bug。
老闆的偏好——快速迭代。
老闆的 CI 才能測到。
不能只 grep / read 就推（2026-05-08 RefundSheet 事件教訓）。
正在被本頁取代。
老闆跟我都會忘。
這些是目前 Things 3 上開著的 work-related task。已經整合在「大計劃」section，
這裡保留原始分類給老闆對照。
協議：以後 AI 改 task 狀態時也會更新本頁，不再用 things-sync.sh。
所有都在 main 上，3 個 app 都 build 過。
這些事我做不了 / 不該替老闆決定，需要回答後我才能繼續。