從代碼庫萃取品牌
概述
產品程式碼庫是品牌真實性的唯一來源。品牌套件（brand kit）會一次性地萃取至 marketing-videos/<brand>/brand.md 中，每個值都附帶其來源 file:line，且檔案會記錄萃取時所在的 repo commit，以便後續重新整理（refresh）而非重新讀取。
brand.md 契約
請依序撰寫以下章節。每個值的結尾必須標明來源，格式為 (path:line)。
- 來源 (Sources)：repo 路徑、分支、每個 repo 的
git rev-parse --short HEAD、萃取日期，以及每個 repo 一個機器可讀的區塊（供管線閘道 G1 偵測品牌是否過期）：```refresh repo: <product-repo> ref: HEAD commit: c8fb26e paths: src/data/content.ts src/app/globals.css public/brand ```repo是D:\Projects下的資料夾名稱。非 git 管理的 repo 應使用mtime: <ISO date>取代ref和commit。 - 識別 (Identity)：名稱、一句定位、標語、語氣（直接引用文案檔案，不要改寫）。
- 色彩代號 (Color tokens)：先列出語意化的品牌代號（
--color-brand-*、primary、AppColors.primary），再列出輔助代號。當不同表面（landing vs app）的代號不同時，每個表面應獨立一個表格。 - 字型 (Typography)：依表面區分。Landing 頁面的字型常與 app 不同；請同時檢查根佈局（root layout）及各區塊的
fonts.ts。 - Logo 與圖像 (Logos and imagery)：檔案路徑、區分真實產品渲染圖 vs 圖庫照片（圖庫照片絕不能冒充真實用戶），以及其授權或來源檔案。
- 允許的聲明 (Allowed claims)：功能、模式、定價、CTA 標籤、URL、聯絡方式。每一項都必須是直接引用並附帶來源。樣本資料請標記為
SAMPLE（使用假數字渲染），以便影片標示為「範例」。 - 禁止的聲明 (Forbidden claims)：聽起來合理但無來源的任何內容：用戶數、營收、評分、推薦、合作夥伴 Logo、「terpercaya（值得信賴）」、「#1」。
- 擷取目標 (Capture targets)：正式環境與暫存環境 URL、值得擷取的路由、App 截圖資料夾、Play Store URL。
- 模糊點 (Ambiguities)：重複或衝突的代號、網站與 App 之間不一致的文案、其他地方使用的但與程式碼矛盾的簡報（brief）數值。逐項列出給使用者，切勿擅自解決。
萃取檢查清單 (Extraction checklist)
| 查詢項目 | 常見位置 |
|---|---|
| 文案、CTA、定價 | src/data/content.ts、src/content/*.ts、landing 區塊元件、RELEASE_NOTES.md、docs/features/ |
| 網頁代號 | globals.css @theme / :root、tailwind.config.*、palette.ts |
| Flutter 代號 | lib/core/constants/app_colors.dart、app_text_styles.dart、pubspec.yaml 字型 |
| 字型 | app/layout.tsx（next/font）、區塊 fonts.ts、pubspec.yaml |
| Logo | public/brand/、docs/brand/、assets/icons/brand/ |
| URL | grep -rn "https://<brand-domain>" 遍歷 src/、metadataBase、site.ts、條款頁面 |
在宣告某值缺失之前，請先搜尋：在整個 src/ 中 grep 搜尋網域、CTA 文字以及代號名稱。
跳過 .env*、.mcp.json、google-services.json、keystores 以及任何金鑰或 token。切勿將其值複製到 brand.md。
當來源 repo 未檢出時（雲端工作階段）
閘道 G1 會回報 brand_repo_absent 作為資訊，而 G2 會根據 brand.md 中的精確引用（而非 repo）來驗證每個聲明（claim_verified_brand_kit）。這僅在 brand.md 使用 path:line 逐字引用文案時才有效，因此請務必直接引用文案，切勿改寫。重新整理 brand.md 需要 repo：請在筆記型電腦上執行，或將產品 repo 加入雲端工作階段，並將 MV_PROJECTS_ROOT 指向其父資料夾。
重新整理規則 (Refresh rule)
閘道 G1 會對每個 refresh 區塊執行 git -C <repo> log --oneline <commit>..<ref> -- <paths>，並在有任何變更時失敗，回報 brand_stale。修復方式：僅重新讀取有變更的檔案、更新其行、並 bump 區塊中的 commit。非 git 管理的 repo 則透過檔案修改時間與 mtime 進行比對。
擷取真實 UI (Capturing real UI)
| 產品表面 | 方法 |
|---|---|
| 即時網站 | 使用 HyperFrames 從正式環境 URL 擷取網站（product-launch-video 路由會做此事）；僅在使用者表示功能尚未發佈時才使用暫存環境 |
| 本機開發伺服器 | 僅在使用者要求尚未發佈的畫面時使用；在簡報中標示為「未發佈」 |
| Flutter App | 現有的真實截圖（站點 screens/、Play Store 素材）或模擬器截圖，放入裝置外框中 |
| 小動畫元素（CTA 按鈕、統計卡片） | 使用 brand.md 中的代號重建為 HTML；絕不憑空創造不存在的畫面 |
故事板聲明引用 (Storyboard claim references)
STORYBOARD.md 中的每個螢幕聲明都必須帶有其 brand.md 來源，例如 "Biaya layanan 2%" (<product-repo>/src/data/content.ts:212)。沒有來源的聲明將從故事板中刪除，而非軟化表述。
常見錯誤 (Common mistakes)
- 選取第一個找到的海軍藍（
--navy-main）而非語意化的品牌代號（--color-brand-navy）。優先使用語意化名稱，並將另一個列為模糊點。 - 為 landing 頁面影片使用了 app 字型，或相反。
- 只檢查一個檔案就宣告 URL「找不到」。
- 將圖庫照片顯示為客戶。