手機優先認領頁、版本與組別切換、金額試算、公開防詐提醒。
Production map
Pickora 要長成代購工作台，不只是漂亮的併團表。
目前先把買家認領、代購方工作台、公開 API、安全邊界與上線門檻拆清楚。 接下來每個功能都要往這個架構接，不再散成一次性的 demo。
System layers
先建立穩定分層，之後接登入、資料庫與上傳才不會重打。
代購方後台、貨源、庫存、熟客需求、付款覆核、出貨名單。
認領提交、公開併團 snapshot、AI 客服安全路由，全部走 Zod schema 驗證。
Supabase schema、RLS、public views 已有初版；下一步把 localStorage demo 改成 API-backed state。
公開帳戶保護、人工覆核、AI 高風險轉人工、付款截圖私密儲存與稽核紀錄。
Vercel env、網域、Supabase Storage、備份、監控、測試與上線 checklist。
Operating flow
一條代購鏈從進貨判斷到出貨名單都要可追蹤。
建立版本、組別與商品格位，設定成本、國際運、手續費和台灣寄送。
買家用手機選擇想要的卡或商品，系統自動算總額並收集必要聯絡資料。
公開頁不裸露帳戶，付款資訊由固定聯絡渠道提供，後台人工確認末五碼與截圖。
匯出付款出貨名單，沉澱需求與庫存，下一批貨源用數據判斷要不要買。
Modules
功能模組要服務代購生意，而不是只服務單次小卡團。
小卡、多版本、多組認領與付款狀態
貨源成本、毛利、風險與採購決策
熟客想收什麼、預算多少、急不急
收款不公開、核款、異常交易與稽核紀錄
FAQ 優先、限額呼叫、金流問題轉人工
社群貼文、付款名單、出貨 CSV
Launch gates
這些沒補完之前，不把真實付款資料放進 production。
這不是卡關，是保護你的帳戶、買家資料與代購品牌。封測可以展示流程， 真實營運要把資料權限與檔案安全補齊。
正式站不能靠 demo 後台；代購方資料、付款資訊與出貨名單必須進入 authenticated 後台。
付款截圖不可公開 CDN；需使用私密 bucket、短效 signed URL、檔案類型與大小限制。
認領、付款確認、取消、出貨都要寫入 Supabase，狀態變更留下時間與操作者。
AI key 只放 server route；FAQ 先回、限額後再呼叫模型，高風險問題直接轉人工。
清楚標示非官方粉絲代購工具、付款人工確認、不代收代付、不做平台仲裁。
Route map
目前網站的公開面、後台面與 API 邊界。
/品牌入口與產品定位/g/ive-special-a買家手機認領頁/demo/admin封測營運工作台/admin正式後台登入入口骨架/safety安全與防詐原則/api/group-buys/[slug]公開安全併團資料 API/api/claims認領提交 API/api/supportAI 客服與 FAQ 防刷 API