多餐廳資料隔離 — 一家餐廳一個 sqlite 重構

1. 為什麼做這個更新

2. Audit 發現了什麼

🪲 真正的 root cause（已修但只是堵漏）

ChefsMateShared/.../Sync/Core/Syncable.swift 的 GenericSyncExecutor.upload 自我修復邏輯：

觸發鏈：

1. user 切到 B 餐廳（currentRestaurantId = B）
2. A 餐廳的某個 model 被 markForUpload（mapper 更新 / sheet markForSync）
3. 上傳 → server RLS 拒絕（user 在 B context，A row 屬於 A）
4. self-heal 改 model.restaurantId = B
5. retry upsert 成功 → server row 永久變成 B 的

📊 兩個結構性問題（沒徹底解就還會再爆）

3. 三種方法評估

我去查了 B2B SaaS 業界怎麼處理多 tenant 的 local cache：

4. 老闆最終選擇：方案 A

選 A 的理由（業界已驗證）：

• 0 污染風險 — 檔案系統層級隔離，連 SQL injection 都污染不到
• 瞬間切換 — 切換 = swap ModelContainer，不需要 re-pull
• 每家獨立 cache — 切到別家後切回來，原本資料還在
• 砍掉 25+ filter 程式碼 — view @Query 不需要再加 restaurant_id filter
• Rule 6 變多餘 — 「每個 query 都要 filter」這條鐵則不需要再守
• pending upload 天然安全 — 不會跨 container 漏寫

5. 設計總覽

🔑 4 層架構

6. 實作 Phase（即時更新）

7. 給工程師看的技術細節

7.1 Container 命名規則

ChefsMatePOS-{restaurantId}.sqlite         // per-restaurant
ChefsMatePOS-shared.sqlite                 // 跨租戶

restaurantId 用 UUID lowercase 去 hyphen，避開檔名特殊字元
e.g. "ChefsMatePOS-5fa79171c0ff400e8a67a7efb9b15c08.sqlite"

7.2 Entity 分類規則

分類依據：DB schema 是否有 restaurant_id 欄位 + 是否多餐廳共享。

7.3 SwiftUI 動態 ModelContainer

// ChefsMatePOSApp.swift
@StateObject private var auth = AuthManager.shared

var body: some Scene {
    WindowGroup {
        ContentView()
            .modelContainer(currentContainer)        // ← 切換 currentRestaurantId 自動 swap
            .environment(\.sharedModelContainer, sharedContainer)
    }
}

private var currentContainer: ModelContainer {
    if let rid = auth.currentRestaurantId {
        return RestaurantContainerRegistry.shared.getOrCreate(rid)
    }
    return RestaurantContainerRegistry.shared.bootstrap  // 未登入用空 container
}

7.4 Migration 流程（首次升級）

1. App 啟動 → 偵測 UserDefaults flag "migrated_to_multi_container_v1" == false
2. 偵測舊 ChefsMatePOS.sqlite 存在
3. 建 legacy ModelContainer 讀舊 store
4. 拿到所有 user 的 restaurantIds (AuthManager.memberships)
5. for each rid: createContainer(rid)
6. for each Syncable entity:
     - fetch all from legacy container
     - group by restaurantId
     - insert into corresponding new container
7. shared entities → insert into shared container
8. flag = true, 舊 sqlite rename .legacy.backup
9. 完成 → 繼續正常啟動

7.5 跨 container 的 query 怎麼辦？

「跨餐廳列表」（罕見場景，如管理員看所有餐廳的 today 總營收）：

1. iterate restaurantIds → 各自 container fetch → 合併 in memory
2. 或用 Supabase 直接 query（cloud-side aggregate）

不做 cross-container SQL join。如果一個 feature 需要 join → 該 feature 走 cloud-side。

7.6 風險與緩解