店家專區（Vendor Hub）把店家介紹、菜單圖片、外部來源和最後點餐時間放到同一張卡片。畫面集中之後，資料責任反而更需要拆清楚：管理者換了菜單圖片，是否也換了可訂購品項？顯示店家已啟用，是否就代表今天能下單？

實作給出的答案很具體。店家資料同時保留 menu_image_url 與 menu_source_url，前者是可預覽的圖片，後者是外部菜單來源；是否可訂購則另外由開團日期和截止時間推導。店家資料模型

當一個頁面開始承接不同責任，先把業務概念（Domain）說清楚，才能決定哪些欄位可編輯、哪些結果只能顯示。

Day 5 已談過多店家如何把常數變成資料。這一篇往前走一步：資料集中在 Vendor Hub 之後，哪些行為應該歸店家管理，哪些仍由其他規則決定？

名稱可以相容，更新要找到同一個店家

Repo 會把舊寫法「合十」整理成「禾拾」。讀取清單時，後端依整理後的名稱去重；若同時有舊名和正式名稱，優先採正式名稱那筆。查近期開團時，也會把相容名稱納入查詢。店家後端

但更新店家不是拿顯示名稱去定位。操作傳入穩定的 vendorId，後端再限制可修改的欄位：介紹、聯絡資訊、網站、菜單來源、菜單圖片、更新日期與啟用狀態。

這份允許清單沒有 name 或 vendor_id。因此不能把「現在顯示統一名稱」推論成「管理頁可以任意改識別，連歷史紀錄也一起改」。讀取相容和正式改名，是不同任務；歷史資料的處理留到 Day 24。

菜單預覽不是菜單來源，更不是價格規則

Vendor Hub 的圖片預覽只使用 menu_image_url。點圖片會開啟放大視窗，外部來源則另作連結。這避免把一個網頁網址直接當成圖片，或讓「打開來源」和「放大現有圖片」混成同一個操作。Vendor Hub 元件

測試定義也明確檢查：圖片 src 不使用 menu_source_url。這不是純外觀要求，而是在固定兩個欄位的意思。前端測試

更重要的限制是，店家基本資訊（metadata）的更新路徑只寫店家欄位和稽核事件，沒有順便改餐點價格。管理者更新卡片上的圖片，不等於替某個日期建立一份新菜單。若要讓 AI 同時處理這兩件事，需求必須分別說清楚，不能靠「更新菜單」四個字涵蓋一切。

最後點餐時間借用日曆的答案

店家頁需要顯示最後點餐時間，但不能自己再寫一套截止計算。

後端從 calendar_settings 讀近期開團資料，使用共用的 deadlineInfo 取得截止時間；前端 formatVendorCutoff 只把傳來的時間轉成台北時區的可讀文字。

同樣地，enabled 只表示店家啟用。is_open_for_ordering 還要求近期開團中有當日或未來、尚未截止的日期。這兩個欄位回答不同問題，不能看到「可使用」就跳過訂單送出時的資格檢查。

目前近期開團查詢只取最近五筆，因此這是卡片摘要，不是完整的未來供餐日曆。若營運情境需要列出更長的預約期間，就得另訂查詢與呈現契約，不能假設這張卡片已經涵蓋所有日期。

管理頁也要說清楚自己不能做什麼

更新入口允許管理員（Admin）與代理管理員（ProxyAdmin）管理基本資訊，仍拒絕一般使用者和唯讀檢視（View As）。後端會檢查未知欄位、網址格式、日期與空更新，並寫入 VENDOR_UPDATED 稽核事件。後端測試定義

以上更新規則由程式與測試定義支持，未重新執行編輯流程或測試。

另於 2026-10-03 擷取店家專區畫面，只核對可見資訊；靜態截圖不證明更新權限或截止計算已實測。

共用語言的價值，在於少猜一次

這些區分可以直接拿來描述下一次修改。AI 接到「只更新店家基本資訊」時，才有足夠線索知道哪些欄位能動、哪些規則要沿用。

也不必每個頁面都建立一套新模型。只顯示一次的欄位，用元件狀態就可能足夠；Vendor Hub 值得獨立，是因為店家識別、資料來源、管理權限與開團資訊已經被多個流程共同使用。

本系列實作專案

這是一套持續開發中的便當訂購系統。文章著重「為什麼」，GitHub 保留實際程式碼、文件與演進紀錄。

GitHub：https://github.com/henryfir456/bento-order-app

下一篇會看訂單管理的三個視角：同一批訂單，為什麼查明細、分樓層與報總數，需要不同的畫面，卻不能各自定義一份答案？