Spec v3:集團架構 + 開分店顧問 AI + V2 整合
TL;DR — V3 把 V2 從「單店 AI 報告」擴成「集團智慧作業系統」。三個關鍵新東西:(1) 開分店顧問 AI(業界沒人做,我們的殺手 feature)、(2) BYOA 接入點(餐廳接自家 OpenAI/Claude/Gemini)、(3) tactic_plans 加 restaurant_id 修設計債(V2 在這裡卡關,V3 修)。
3 個一定要先知道的
- F6 migration 已建好集團 schema 但沒功能 —
restaurant_groups、group_members、local_overrides 表都在,visibility='group' 欄位也在 recipes/ingredients/vendors,GroupDashboardView 雛形也有。V3 把這些功能完整做出來,不是從零起。
- 業界 SMB 集團市場是空的 — Toast Enterprise 服務 50+ 店大集團,Lightspeed 服務 6-160 店,Square 沒集團概念。2-25 店的「想擴張的單店 / 小集團」沒人服務。ChefsMate 的甜蜜點。
- 「開分店顧問 AI」是 ChefsMate 獨家 — 我們已 own 客戶/銷售/員工/財務全資料,可以客觀算 readiness。Toast / Lightspeed 都假設你已決定要開,只賣工具。我們可以更早介入 — 在客戶還是「單店但想開分店」階段就用 AI 教育、評估、規劃。這會是 starter → growth → multi 升級的核心引擎。
為什麼現在做這個
2026-05-20 audit 跨 App 權限後的 4 個發現:
- F6 migration 已 deploy(
restaurant_groups / group_members / local_overrides)— 但只有 schema 和 GroupDashboardView 雛形,功能沒做完。
- POS / Customer App 已用 per-restaurant SQLite container 物理隔離 — 集團切店體驗已通暢。
- RLS P0 漏洞已修(2026-05-20 migration) — 安全層 ready,可以放心擴 group features。
- 單店訂閱已飽和 — 老闆們開始問「我想開第二家,你的系統能跟我一起嗎?」
業界 multi-location SMB 是空白市場
| 競品 | 單店 | 2-5 店 | 6-25 店 | 25+ 店 |
| Square | ✅ | 🟡 flat locations | ❌ | ❌ |
| Toast Standard | ✅ | 🟡 basic multi | ⚠️ Toast 強迫升級 Enterprise | ✅ Enterprise |
| Lightspeed | ✅ | ✅ | ✅ | ✅ |
| ChefsMate V3 | ✅ | ✅ Multi | ✅ Group | ✅ Enterprise |
Lightspeed 是直接競爭者,但他們是西方品牌,在台灣的服務、繁中、本地金流(藍新/綠界)、政府開放資料(假日/勞基法)幾乎沒有。
ChefsMate 已有的本土化是 moat。
三層 RBAC + Schema 設計
角色階層
| 層級 | 角色 | scope | 可做 |
| 集團 | HQ Owner | 全集團 | 所有事 + 邀請 HQ Admin / 區經理 / 店長 |
| HQ Admin | 全集團 | 讀寫所有店資料但不能改集團 owner |
| 區域 | Region Manager | restaurant_scope[] | 只能讀寫 scope 內的店 |
| 單店 | Store Owner | 單店 | 該店所有事 |
| Store Manager | 單店 | 該店日常營運(不能改訂閱) |
| Staff | 單店 | 打卡 / 點餐 / 查排班 |
Schema 變更
-- 1. group_members 加 restaurant_scope (區經理用)
ALTER TABLE group_members
ADD COLUMN restaurant_scope UUID[] DEFAULT NULL;
-- NULL = 全集團 (HQ tier)
-- 有值 = 區經理只能訪問這幾家店
-- 2. helper function 升級認 scope
CREATE OR REPLACE FUNCTION public.get_my_restaurant_ids()
RETURNS SETOF UUID AS $$
DECLARE v_user_id UUID;
BEGIN
v_user_id := public.get_my_profile_id();
IF v_user_id IS NULL THEN RETURN; END IF;
-- 既有: restaurant_members
RETURN QUERY
SELECT rm.restaurant_id FROM public.restaurant_members rm
WHERE rm.user_id = v_user_id AND rm.status = 'active';
-- 新增: group_members (HQ / 區經理)
RETURN QUERY
SELECT r.id FROM public.restaurants r
WHERE r.group_id IN (
SELECT gm.group_id FROM public.group_members gm
WHERE gm.user_id = v_user_id
AND (gm.restaurant_scope IS NULL OR r.id = ANY(gm.restaurant_scope))
);
END;
$$ LANGUAGE plpgsql SECURITY DEFINER SET search_path = public;
NEW Single source of truth for tenant access
get_my_restaurant_ids() 統一回該 user 能訪問的所有 restaurant_id。RLS policies 全部 reuse 這個 function,加區經理只改一處。
HQ 視角 — 多出哪 6 大類功能
1. 集團儀表板
NEW
- 今日營收 leaderboard:各店即時排名,點進去看細節
- 集團 KPI 趨勢圖:總營收 / 毛利 / 食材成本 / 人事成本 / 翻桌率
- 異常檢測:海邊店今日客流量比去年同期下降 30% → 自動 alert
- 跨店比較矩陣:客單價 / 翻桌率 / 取消率 / NPS / 員工 retention 並排
- 地圖視圖:各店在 Google Maps 上,顏色標示今日表現
2. 商品策略(業界對標 Lightspeed Multi-Location Menu)
NEW
- Master Menu:集團主菜單 → 各店繼承(F6
visibility='group' 已支援)
- Per-store override:海邊店漲價 + 加在地菜(
local_overrides 已支援)
- 跨店 A/B test:新菜在海邊店試 2 週 → ROI 分析 → 自動建議是否推給其他店
- 集團定價策略:逢年過節統一漲 5%、淡季統一打 9 折
- 菜單版本控管:全集團菜單 freeze 期間鎖死(行銷活動用)
3. 中央採購 + 中央廚房(見 §5)
NEW
簡介:集中採購壓低供應商議價、中央備料降低各店人事成本、配送路線優化。
4. 員工調度
NEW
- 跨店人力支援:海邊週末缺人 → 從溪邊調 2 人 → 自動計算薪資分攤
- 集中招募 ATS:HQ 發一個職缺 → 履歷池 → 分派到適合的店
- SOP 培訓:HQ 拍一個訓練影片 → 推播全集團員工 → 強制觀看率追蹤
- 跨店薪資對齊:同職等同薪 → 避免員工跳槽到同集團其他店
5. 財務整合
NEW
- 集團合併損益表:HQ overhead + 各店分店損益 → 集團合併報表
- 跨店資金調度:溪邊現金多 → 借海邊週轉 → 內部記帳
- 集團發票管理:同集團發票統一申報、母公司開發票給供應商
- 投資人報告:auto-gen PDF / Notion page,股東會用
- 預算 vs 實績:HQ 訂年度預算 → 拆到各店 → 月對月追蹤
6. 行銷
NEW
- 集團會員卡:一卡多店通用,集點累積跨店
- 跨店集點:海邊吃滿 1000 點 → 溪邊抵 50 元
- 集團 campaign:中秋全集團送月餅、HQ 統一行銷預算分配
- 區域 promotion:北部 3 家店推冬季鍋物、南部不推
- 社群整合:集團統一 IG / FB 後台,各店分權 post
你推測還能怎麼用 — 我列 6 個沒人想到的
推測 A. 集團 NPS 競賽 — 每月公佈各店 NPS 排名,前 3 名分紅、後 1 名上 HQ review。
推測 B. 跨店「最佳實踐 (Best Practice) 自動發掘」 — AI 看哪家店某指標突然變好,自動 reverse-engineer 是什麼變化(菜單?定價?員工?)然後建議推給其他店。
推測 C. 客戶跨店追蹤 — 老客在海邊店點過 50 次,第一次到溪邊店,POS 自動提醒店員「VIP 客戶,知道他吃辣不吃香菜」。
推測 D. 集團 supply chain finance — 集團統一給供應商月結 → 用集團信用換更好的付款條件(60 天 vs 30 天)→ HQ 統一管理供應商風險。
推測 E. 同集團「找朋友」 — 客人在 A 店 wallet pass 顯示「你的朋友也常來這集團」,促進跨店推薦。
推測 F. 集團「副廠機制」 — 集團統計食材消耗 → 自動拆給 3 家供應商(主廠 60% / 副廠 30% / 緊急廠 10%)→ 避免單一供應商斷貨風險。Toast / Lightspeed 都沒這個。
區經理視角 — 巡店 + 區域目標
區域儀表板
NEW
- 該區所有店的關鍵指標(營收 / 客流量 / 成本率 / NPS)
- 同區互比(pressure ranking)
- 區內人力調度視圖
- 區內銷售活動效果追蹤
巡店 (Field Visit) 系統
NEW
CREATE TABLE field_visits (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
group_id UUID NOT NULL REFERENCES restaurant_groups,
restaurant_id UUID NOT NULL REFERENCES restaurants,
region_manager_id UUID NOT NULL,
visited_at TIMESTAMPTZ NOT NULL,
checklist_responses JSONB, -- {"廚房整潔": 5, "員工儀容": 4, ...}
photos TEXT[], -- Supabase Storage URLs
overall_score INT,
issues JSONB, -- [{severity: 'high', desc: '...', assigned_to: UUID}]
follow_up_at TIMESTAMPTZ,
created_at TIMESTAMPTZ DEFAULT now()
);
- 區經理到店,App 內勾巡店 checklist
- 拍照 + 評分上傳
- 發現 issue → 自動分派 store manager + 設追蹤日
- HQ 看區經理巡店頻率報表
區域目標管理
NEW
- HQ 訂集團年目標 → 區經理拆到各店(可手動 + AI 建議)
- 區月會自動 agenda 生成(各店 KPI 變化 + AI 找出討論重點)
- 跨區比較 → HQ 排名區經理
中央廚房 (Central Kitchen)
為什麼集團要中央廚房
3-5 家店之後,各店各自備醬料 / 切肉 / 烘培,人事成本爆炸。業界主流(王品 / 鼎泰豐 / 八方雲集)都有中央廚房 — 把標準化、可運送的工作集中,各店只做最後組裝+出餐。降低各店廚師依賴 + 提升品質一致性。
Schema
CREATE TABLE central_kitchens (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
group_id UUID NOT NULL REFERENCES restaurant_groups,
name TEXT NOT NULL,
address TEXT,
capacity_kg_per_day INT,
active BOOLEAN DEFAULT true,
created_at TIMESTAMPTZ DEFAULT now()
);
CREATE TABLE central_kitchen_products (
-- 中央廚房做哪些半成品 / 成品
id UUID PRIMARY KEY,
kitchen_id UUID NOT NULL REFERENCES central_kitchens,
-- 對應到 menu_items 或 ingredients
source_recipe_id UUID REFERENCES recipes,
produces_ingredient_id UUID REFERENCES ingredients,
-- "300g 一袋的滷肉醬"
unit_size NUMERIC, unit_label TEXT,
cost_per_unit NUMERIC, -- 中央廚房內部成本
transfer_price NUMERIC -- 賣給分店的價(內部轉撥)
);
CREATE TABLE central_kitchen_orders (
-- 各店向中央廚房叫貨
id UUID PRIMARY KEY,
kitchen_id UUID NOT NULL,
restaurant_id UUID NOT NULL,
delivery_date DATE NOT NULL,
status TEXT, -- pending / packed / shipped / delivered
items JSONB -- [{product_id, qty, transfer_price}]
);
新增功能
NEW
- 叫貨 UI:店長像叫供應商一樣下單給中央廚房
- 配送路線:中央廚房一車跑 5 家店 → AI 算最佳路徑(整合 Google Maps API)
- 內部轉撥計帳:中央廚房做 100kg 滷肉成本 ¥30k,賣給海邊店 ¥10k / 溪邊店 ¥12k → 中央廚房虧損由 HQ 統一補
- 食安追溯:某批中央廚房滷肉出問題 → 自動查哪些店收到 → POS 自動下架
⭐ 開分店顧問 AI Agent
KILLER 這是 ChefsMate V3 最大差異化 — 業界沒人做。Toast / Lightspeed 都假設客戶已決定要開,他們只賣 onboarding 工具。我們在客戶還在「想但不敢開」階段就介入,變成 starter → growth → multi 訂閱升級的天然漏斗。
為什麼 ChefsMate 能做這個而別人不能
- 已 own 客戶銷售/客流/客單價/翻桌率 → 算營收 readiness
- 已 own 員工排班/薪資/retention → 算團隊 readiness
- 已 own 食材成本/利潤率/現金流(藍新/Stripe) → 算財務 readiness
- 已 own NPS/取消率/回流率 → 算品牌 readiness
- 有政府開放資料(假日/勞基法/商業司登記) → 算市場 readiness
5 維度評分演算法(第一版用 expert rule,後期 ML)
CREATE TABLE expansion_readiness_scores (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
restaurant_id UUID NOT NULL REFERENCES restaurants,
computed_at TIMESTAMPTZ NOT NULL DEFAULT now(),
-- 5 維度 (0-100)
financial_score INT, -- 現金流月數 / 毛利率 / 負債比 / 應收帳款週轉
operational_score INT, -- SOP 完整度 / 員工 retention / 出餐穩定度
brand_score INT, -- NPS / 客戶回流率 / 社群觸及
team_score INT, -- 副店長 ready / 二廚 ready / 招募 pipeline
market_score INT, -- 商圈飽和度 / 競品密度 / 房租 ROI 預估
overall_score INT, -- 加權總分
recommendation TEXT, -- AI 生成的整體建議
blockers JSONB, -- [{dim:'financial', issue:'現金流只夠 3 個月', severity:'high'}]
next_actions JSONB, -- [{action:'招募並訓練副店長', months_needed:6, cost:200000}]
ai_provider TEXT, -- 'chefsmate' / 'openai' / 'anthropic' / BYOA
ai_model TEXT -- 'claude-opus-4-7' / 'gpt-4-turbo' / etc
);
AI 對話流程
1. POS 主控台側欄出現「想開分店嗎?」icon (對 starter/growth tier 才顯示)
2. 點下去 → 進「擴張顧問」對話介面
AI: 「我看了你最近 6 個月資料,目前 readiness 是 62/100。
最大的 blocker 是現金流和團隊。要不要我細講?」
3. AI 列具體 blocker:
🔴 現金流:目前每月淨利 ¥80k,新店需 ¥1.2M 開辦 + ¥150k/月燒錢。
你的緩衝期只夠 3 個月,建議再存 ¥900k 或找投資人。
🟠 團隊:目前主廚一人 dependency,二廚未訓 lead。
建議招募並訓練二廚 6 個月,讓本店 SOP 可不靠你跑。
🟢 品牌:NPS 72(優),客戶回流率 45%(高於業界 30%)— 你有客群可以複製。
4. AI 提 12 個月 roadmap:
M1-M3: 招募二廚 + 開始 SOP 文件化
M4-M6: 二廚獨立帶班 1 個月,觀察出餐穩定
M7-M9: 存夠開辦金 + 開始看店面
M10-M12: 簽約 + 裝潢 + 開幕
5. 月度 review:
每月 1 日,AI 自動跑分數,推播給老闆
分數變化 + 是否在 roadmap 上 + 建議下個月重點
readiness >= 80 自動觸發升級流程
NEW
系統主動 prompt:「你的 readiness 88/100 — 準備好了。要不要升級到 Multi tier?Multi tier 開新店 wizard 會用你的現店資料一鍵 clone 設定。」
- 使用 F6 已建的
restaurant_groups schema
- 新店設定從本店 clone(菜單 / 員工角色 / 樓面)
- 第一個月 onboarding 顧問(人工 + AI)
AI 智慧報告 V2 → V3 升級
V2 是什麼(回顧)
V2 critique 的核心:
- 2 層架構(Anthropic Tool Use + Zod schema)
- 4 階段冷啟動(industry default → SMA-7 → Ridge → YoY)
- 信任分 tier(bronze/silver/gold)
- 業界對標:Tableau Pulse / Snowflake Cortex Analyst / Hex Magic
V3 新增能力
A. 集團維度查詢 (cross-store)
NEW
// 新 tool definitions (Anthropic Tool Use schema)
{
name: "compare_stores",
description: "比較集團內多家店的指標",
input_schema: {
type: "object",
properties: {
restaurant_ids: { type: "array", items: { type: "string" } },
metric: { enum: ["revenue", "gross_margin", "customer_count", "table_turnover", "nps"] },
period: { type: "object", properties: { from: "date", to: "date" } }
}
}
}
老闆可問:「比較我集團 3 家店這個月毛利率」/「為什麼海邊店這月來客數比溪邊少 20%?」AI 自動跑工具回答。
B. 戰術規劃 V3 — 修 tactic_plans 設計債
⚠️ 設計債:目前 tactic_plans / tactic_plan_items / tactic_plan_histories 三張表完全沒 restaurant_id 欄位。從 2026-05-20 RLS audit 發現的 — 這意味著 RLS 只能用 is_authenticated(),任何登入用戶看到任何餐廳的戰術 plan。
FIX V3 migration:
ALTER TABLE tactic_plans ADD COLUMN restaurant_id UUID REFERENCES restaurants;
ALTER TABLE tactic_plans ADD COLUMN group_id UUID REFERENCES restaurant_groups;
-- 舊資料回填(如果有的話):由現有 user_profile_id → restaurant_members → 第一家店
UPDATE tactic_plans SET restaurant_id = (...) WHERE restaurant_id IS NULL;
ALTER TABLE tactic_plans ALTER COLUMN restaurant_id SET NOT NULL;
-- 同步 tactic_plan_items(透過 plan_id → restaurant_id)和
-- tactic_plan_histories(同模式)
-- RLS
ALTER TABLE tactic_plans ENABLE ROW LEVEL SECURITY;
DROP POLICY dev_full_access ON tactic_plans;
CREATE POLICY tp_member_access ON tactic_plans FOR ALL
TO authenticated
USING (restaurant_id IN (SELECT get_my_restaurant_ids()))
WITH CHECK (restaurant_id IN (SELECT get_my_restaurant_ids()));
NEW
集團戰術規劃:HQ 訂目標 → AI 拆到各店
- AI 對話:「我下季想做 ¥6M,要怎麼分到我的 3 家店?」
- AI:基於各店 capacity (seats × turnover × avg_spending) 拆目標
- 自動寫到 tactic_plans (每店一筆,group_id 共用)
- 每月對照實績,plan vs actual 自動 alert
C. 開分店顧問 (見 §6)
NEW 透過 ReadinessScore tool 接入 V3 architecture。AI agent 用 ToolUse 跑各維度評分函數。
D. 中央廚房優化建議
NEW
老闆問:「如果海邊店的醬料改從中央廚房送,省多少?」
AI 跑 cost calculator tool → 用各店食材消耗 + 中央廚房 capacity + 配送成本 → 回估計值。
BYOA — Bring Your Own AI 接入點
為什麼餐廳會想 BYOA
- 老闆已訂 ChatGPT Plus / Claude Pro,不想額外付 ChefsMate AI 訂閱
- 中型集團有 IT,用 Azure OpenAI 或 AWS Bedrock(企業合約 + data residency)
- 未來 LLM 價格戰激烈,鎖死 provider 是風險
- 合規:某些餐廳(連鎖外資)有資料不能傳出境要求 → 自架 LLM
設計:Provider Adapter Interface
// 1. restaurant_settings 加 ai_config column
interface AIConfig {
provider: 'chefsmate' | 'openai' | 'anthropic' | 'gemini'
| 'azure-openai' | 'aws-bedrock' | 'self-hosted';
api_key_vault_id?: string; // Supabase Vault 加密儲存
model?: string; // 'gpt-4-turbo' / 'claude-opus-4-7' / 'gemini-1.5-pro'
endpoint?: string; // Azure / self-hosted custom URL
system_prompt_override?: string; // 集團 brand-specific
monthly_token_cap?: number; // 自我約束(避免突然爆量)
}
// 2. 抽象成 ProviderAdapter
abstract class AIProviderAdapter {
abstract async run(messages: Message[], tools: Tool[]): Promise<ToolUseResult>;
}
class AnthropicAdapter extends AIProviderAdapter { /* V2 既有 */ }
class OpenAIAdapter extends AIProviderAdapter { /* GPT-4 function calling */ }
class GeminiAdapter extends AIProviderAdapter { /* Google function calling */ }
class AzureAdapter extends AIProviderAdapter { /* Azure OpenAI endpoint */ }
class BedrockAdapter extends AIProviderAdapter { /* AWS Bedrock invoke */ }
// 3. Edge function 統一入口
// supabase/functions/ai-report/index.ts
const adapter = await getAdapterForRestaurant(restaurant_id);
const result = await adapter.run(messages, tools);
return result;
Tool definitions 統一不變
NEW 各 provider 都用同一套 tool schema(我們的 widget library)。
Anthropic Tool Use / OpenAI Function Calling / Gemini Function Declarations 在 JSON schema 上 99% 相容。
V3 抽象層只負責 message 格式轉換。
Pricing 策略
| 方案 | 誰付 LLM 費用 | ChefsMate 收 |
| ChefsMate AI(內建) | ChefsMate | 訂閱費含 token cap(超出限速,不額外計費) |
| BYOA(自接) | 餐廳自己付 OpenAI/Anthropic | 不另收 AI 費用,僅一次性 setup fee ¥5000 |
| Enterprise BYOA(Azure/Bedrock) | 客戶 cloud account | 整合 SLA fee,custom quote |
訂閱層級對齊業界
| Tier | 月費 | 店數 | 核心功能 | AI |
| Free | $0 | 1 | 訂位 / 點餐 / 結帳 basic | - |
| Starter | $30 | 1 | + 會員卡 + 報表 | 內建,100k token/月 |
| Growth | $80 | 1 | + 完整功能 + 串接 | 內建,500k token/月 + 開分店顧問 ⭐ |
| Multi 🆕 | $200 | 2-5 | + Group dashboard + 跨店比較 | 內建,2M token/月 + 集團維度 |
| Group 🆕 | $500 | 6-25 | + 區經理 + 中央廚房 | 內建,8M token/月 + 全功能 |
| Enterprise 🆕 | custom | 25+ | + BYOA + SLA + custom dashboard | BYOA(Azure/Bedrock) |
對標:Toast Enterprise 每店 $69-165/月 + processing fee,Lightspeed Multi-Location 起跳 $129/月。
ChefsMate $200/Multi (2-5 店均攤每店 $40-100) 對中小集團有競爭力。
12 個月實作 Phases
| Phase | 月份 | 主題 | 產出 |
| P1 | M1-M2 | 3 層 RBAC + 區經理 |
group_members.restaurant_scope[] / get_my_restaurant_ids() 升級 / POS 區經理選店 picker / web /group/[slug]/region route |
| P2 | M3-M4 | 集團儀表板 |
SQL views(group_daily_revenue 等)/ web GroupDashboardView 完整實作 / Realtime cross-store / 異常檢測 alert |
| P3 | M5-M6 | 中央廚房 |
central_kitchens schema / 叫貨 UI / 配送路線 / 內部轉撥計帳 |
| P4 | M7-M8 | AI V3 升級 + BYOA |
ProviderAdapter abstraction / tactic_plans 加 restaurant_id 修設計債 / 集團 tool definitions / BYOA UI |
| P5 | M9-M10 | 開分店顧問 AI ⭐ |
expansion_readiness_scores schema / 5 維評分 / AI agent dialogue / Roadmap generator / 月度 review job |
| P6 | M11-M12 | Enterprise tier |
SLA infra(uptime + on-call) / Custom dashboard builder / Azure/Bedrock integration / dedicated CSM playbook |
Open Questions(老闆要拍板)
Q1:tactic_plans 加 restaurant_id 怎麼回填?
現有資料(若有)需要某種對應規則。建議:由 user_profile_id → restaurant_members(取第一家 active store)。但如果是多店老闆已存了多店的 plan,可能會回填錯。需要先 query 看看有多少筆要處理。
Q2:BYOA 怎麼防 API key 洩漏?
選項:A. Supabase Vault(原生加密)/ B. AWS KMS / C. 餐廳每次 request 自己附 key。Vault 最簡單但要驗證生產環境 capability。
Q3:中央廚房成本內轉的會計模型對嗎?
目前設計:中央廚房算成本中心(損益歸 HQ),各店看「採購自中央廚房」=外部供應商一樣的入帳。但會影響稅務(集團內企業之間轉撥要不要開發票?要不要做 transfer pricing?)。建議找會計師 review 後再 finalize。
Q4:開分店 readiness 演算法權重?
第一版 expert rule:財務 30% + 營運 25% + 品牌 15% + 團隊 20% + 市場 10%。建議跟 5 個真實有開分店經驗的老闆 sanity check 後再 lock。
Q5:HQ tier 看員工個資?
區經理巡店看員工出勤、HQ Admin 看薪資 — 多大程度可讀員工 staff_personal_info?個資法 + 員工知情同意 怎麼設計?
Q6:集團會員卡 = 集團一張 vs 各店各一張?
Pros & cons:單卡通用對客戶體驗好,但若集團解散 / 加盟主退出,客戶資料歸屬權糾紛大。建議 default 各店一張,集團主動「啟用跨店」需要 group_owner 確認。
與 V2 spec 的關係
V3 is a strict superset of V2.
- V2 不變:2-layer architecture(Anthropic Tool Use + Zod)、4 階段 cold start、trust score tier、業界對標
- V3 加上:
- Cross-store tool definitions(compare_stores, group_kpi 等)
- BYOA provider adapter(OpenAI/Anthropic/Gemini/Azure/Bedrock)
- Expansion advisor agent(用 ToolUse 跑 5 維 readiness)
- tactic_plans schema migration(加 restaurant_id 修設計債)
- HQ/Region/Store 三層 RBAC
V2 可以單獨上線(已 commit)。V3 需要 12 個月分 6 phases ship。