V0 / 2024一次性點餐表格
新落單 02#A12菠蘿油 · 奶茶接受訂單
落緊鑊 01#A09沙嗲牛肉麵準備完成
得咗 01#A07常餐 · 熱咖啡通知取餐
一個點餐練習，
如何成為營運系統。
這次升級不只是畫面更漂亮，而是加入價格信任邊界、持久訂單、職員角色與完整狀態歷史。
真正改變伺服器重新計價交易式建立訂單角色權限 Kanban訂單狀態歷史
V1 / NOW前後台營運 Demo
這個項目證明甚麼
AI 協助 Next.js 重寫、資料模型、元件實作與測試；點餐規則、狀態流程、營運界線及驗收由我定義。
V0 與 V1 Git 分支、公開客人點餐流程、資料庫 schema、Server Actions、職員 Kanban 及狀態歷史。
證據路徑
最近核證2026-08-27一眼分清已上線、受保護與下一步。
公開客人流程已逐步實機核證；登入後的職員操作只列作受保護範圍，不以無法公開查閱的畫面充當證明。
公開餐牌與客人落單
公開版本可瀏覽餐牌，選擇食品並進入點餐設定，毋須帳戶或示範數據登入。
加料、數量與特別要求
實機流程已驗證走料、套餐飲品、冷熱飲加價、數量及特別要求等結構化選項。
職員 Kanban 與訂單歷史
職員介面受登入保護；Portfolio 只說明角色、六個狀態與歷史設計，不公開帳戶、店舖或資料庫內容。
真實商戶、付款與多店營運
目前仍是已部署的單店概念 Demo；資料結構為擴展路線預留空間，但未完成商戶自助開通、帳單、網域映射或完整租戶隔離。
Guest → Kitchen客人到廚房的完整流程
Server-trusted伺服器重新計價
6 states可追溯訂單生命週期
問題
最初的 Flask 版本能選餐及計價，卻把整個服務壓縮成一張一次性表格；沒有持久訂單、角色權限、合法狀態轉換或職員協作介面。
做法
我先重畫客人、伺服器、廚房與管理者之間的責任，再以 Next.js、Supabase、Auth.js 與 Drizzle 實作：結構化加料、伺服器重新計價、交易式建單、角色權限 Kanban 及六狀態歷史。
結果
一個五分鐘練習成為已部署、可測試的單店前後台營運 Demo。資料模型為往後多商戶路線保留空間，但目前不聲稱真實商戶採用、付款處理、收入或完整多租戶隔離。
一張訂單如何穿過整個系統
公開餐牌提供食品圖片、套餐飲品、冷熱選項、數量與特別要求。
建單時重新讀取菜單與選項，不信任瀏覽器傳入的價格，再以 transaction 保存訂單。
職員只能沿合法狀態圖推進訂單，完成前亦保留付款狀態檢查。
受保護後台承載菜單、設定、訂單歷史與報表入口，不在 Portfolio 公開真實營運資料。
這個項目保留香港茶記的日常感，但展示重點不是懷舊視覺，而是如何把看似簡單、實際充滿條件分支的服務，整理成可驗證、可追溯、可繼續擴展的營運流程。