統一設計系統
一個入口，涵蓋所有設計領域。
資源載入規則
開始時載入註冊表。各階段按需載入該階段的資源。 生成不經由使用者偏好檔案；技能架構見
skill-architecture.html，運行路線見skill-workflow.html，版本變更見CHANGELOG.md。
啟動時載入
| 資源 | 為什麼 |
|---|---|
manifest.md | 知道有哪些領域和資源 |
載入預算（硬上限）
本 skill 有 125 個檔案；讀完全部再動手 = 任務失敗。
| 約束 | 值 |
|---|---|
| 啟動載入（不計入預算） | manifest.md——註冊表必讀，不佔額度 |
| 主檔案外規則檔案最多再讀 | 4 個 |
| 這些檔案合計 | ≤1200 行（真實總閘） |
| 單檔案 >400 行 | 只讀被點名的 § 節，不讀全文 |
為什麼是 4：真正的成本是行數不是檔案數（Web 線 3 個必讀僅佔 1200 行的 37%）。檔案數上限是防「東讀一點西讀一點」的啟發式——4 個 × 平均 300 行 ≈ 1200 行，兩個約束自洽。別把第 4 個額度當成預設餘量隨便花，花之前先走下面的落點決策。
預算按序花在：① 領域主檔案（domains/web/distilled-playbook.md / domains/poster/MODE.md / domains/brand/MODE.md）② 該領域標「必須」的那份（如 domains/web/anti-slop/MODE.md）③ 確需具體數值時才讀 shared/ 對應 § 節。
按目前結構，一次 Web 任務的必讀是 3 個：distilled-playbook.md + domains/web/anti-slop/MODE.md + references/flow.md。素材三檔、本地字型清單、工程坑 P1–P11 都在本檔案，不必再下潛。第 4 個額度的設計用途：階段 ④ 讀 shared/react-bits-assets.md（§0 + §3，禁止整讀 1626 行）。其餘情形它就是餘量（確需第 4 份時用，見「新規則往哪放」）。
領域原則按域分片（參考級，不佔必讀額度）：跨領域通用核心 shared/design-principles.md（§1.1–§1.12）+ 領域子集 shared/design-principles-web.md / shared/design-principles-brand.md / shared/design-principles-poster.md。載入方式：按目前領域只載入對應子集，按需取用（如 Web 任務的階段①競品分析 / ③記憶點設計才讀 design-principles-web.md 對應節），參考級、不計入必讀 3 個額度，不必通讀通用核心全文。
references/gates.md 與 constraints.md 屬於可選參考（判據細則 / 邊界情形），不佔這 3 個額度——需要再查，不需要就跳過。
禁止：為「理解全貌」通讀所有被指向的檔案；整讀 shared/react-bits-assets.md（1626 行；選元件看 §3 分類 / §5 詳解）或 shared/design-philosophies.md（選哲學看 §選擇指南）；連讀 4 個以上檔案仍不動手。
新規則往哪放（落點決策，先走這裡再動預算）
新增一條規則時，按序判斷，前三步命中就不許新開檔案：
- 所有領域、所有任務都需要？ → 放主檔案（主檔案不計預算——這是必須級規則的正確成本：每次都要用，就該每次都在）。判據：海報任務和 Web 任務沒它都會做錯。
- 只屬於某個領域的流程？ → 併入該領域已有的必讀檔案（如 web 的併進
distilled-playbook.md），不新增檔案。SSoT：寧可用小標題分區，也不開新檔案。 - 只是數值 / 細則 / 查表？ →
shared/對應檔案，保持參考級（不佔必讀額度，需要才查）。主檔案若相關，留一行指針。 - 以上都不是、且確實每次必用？ → 才允許新增第 4 個必讀檔案。此時在「領域速查」登記它屬於哪條領域線，並確認 1200 行總閘仍夠（目前 Web 線用 439/1200）。
主檔案警戒線：≤400 行。 超過時優先把「非每次必用」的內容按判據下沉回 references（留一句話判據），而不是繼續膨脹——主檔案漲一行，所有任務都付一次。
耗盡即停：用已讀內容產出，交付時一行註明「跳過 X（載入預算）」。基於 3 個檔案的完整方案 > 讀 10 個檔案沒有產出。
交付前自驗（不佔載入預算）
產出 HTML 後，建議跑一次無頭瀏覽器渲染（npx playwright screenshot / 本地 Chrome·Edge --headless --screenshot），至少在 1440 與 390 兩個寬度各截一張，核對三件事：
- 首屏是否空白——動效若依賴 JS/IntersectionObserver 才顯形，慢機器與截圖場景會全白；首屏內容必須直接可見
- 是否橫向溢出或文字貼邊——檢查區塊的
padding簡寫有沒有覆蓋容器的左右內距 - 標題是否溢出——桌面寬度下標題超 3 行，說明
clamp()上限或字號錯了
發現問題當場修，別交付沒渲染過的頁面。看程式碼看不出這三類問題。
自驗預算（有上限，防止把自驗做成無限返修）：最多 2 輪，每輪 2 張（1440 / 390），單輪 ≤90 秒。兩輪後仍有問題就停手，把剩餘問題寫進交付說明——自驗是發現三類結構性問題的手段，不是把頁面調到完美。
7條核心設計原則
這7條原則是設計的靈魂指南。不是檢查清單，是思考方向。
| 原則 | 核心問句 | 含義 |
|---|---|---|
| 有根基 | 知道為誰設計、解決什麼問題 | 在動手之前搞清楚：目標使用者是誰？看完頁面後要做什麼？核心要傳達的一條資訊是什麼？沒有根基的設計 = 自嗨 |
| 有靈魂 | 有一個統領性的調性，所有決策服務於它 | "如果這個頁面是一個人，TA 的氣質是什麼？" 用一個詞定義（如"精緻"/"力量"/"叛逆"）。後續的顏色、字體、間距、動效都圍繞這個詞展開 |
| 有系統 | 所有元素服從同一套視覺語法 | 顏色、字體、間距、動效時長、互動反饋 — 建立統一規則後，每個新元素自動繼承這套系統，不需要逐個決策。詳見shared/system-design.md §2 設計起點選擇 + §3 三參數影響矩陣 |
| 有記憶點 | 至少一個讓人停下來看的東西 | 可以是獨特的互動方式、一種材質感、一種文字處理方式、一種空間關係。不需要複雜 — 一個精心執行的簡單創意，勝過十個粗糙的複雜效果 |
| 有溫度 | 傳遞情緒，不只是堆疊資訊 | 頁面給人什麼感受？安靜、活力、溫暖、神秘、科技感、自然感？情緒不是裝飾，是設計的底層驅動力 |
| 有品質 | 交付必須完整可用，不能有半成品 | 每個狀態都有交代（loading/empty/error/success），行動端適配完整，支援 prefers-reduced-motion，使用 CSS 變數 |
| 有匠心 | 你認真對待這個設計了嗎？ | 不遺漏重要內容，不馬虎，不以次充好，不隨便製作。每一個細節都認真對待，全力以赴，不偷工減料 |
單一真源契約（SSoT · 改本檔案前必讀）
本檔案過去的主要失效模式：同一規則被複製到 3–4 處——流程表格抄一遍、硬檢查點抄一遍、品質門抄一遍、約束再抄一遍。 後果不是"更保險"，而是被當成重複的空勾選：勾一處就算過，規則實際失效。這正是"紙面遵守 ≠ 程式碼級遵守"的機制成因。
分層職責（新增內容按此歸位，錯位即視為缺陷）：
| 層 | 位置 | 只放什麼 | 禁止放什麼 |
|---|---|---|---|
| 定義層 | 「工作方式約束」約束0–9、「通用底線」 | 規則的唯一定義 | — |
| 流程層 | 自適應設計流程各階段表格 | 何時做什麼 + 查哪個檔案 + 指針（"按約束X"） | 禁止複述約束定義 |
| 門禁層 | 第四階段執行門禁、品質門、工程坑門禁 | 核驗動作 / PASS 閾值 / 體檢問句 | 禁止重申制度性定義 |
歸位測試（加規則時必問）：這條是在定義規則，還是在核驗規則？ → 定義進定義層，核驗進門禁層，二者只能落一處。 → 進一步：判斷類（品味/連貫/豐富度，無法機械判定）歸品質門；事實類（能用 grep/ls/斷言驗證）歸工程坑門禁。歸錯層，這條規則就失效。
設計流程（6 階段）
| 階段 | 做什麼 | 交付物 |
|---|---|---|
| ① 調研與需求 | 提取隱性需求、判領域、定三參數 | 需求複述（CP1 用）+ 三參數 |
| ①.5 主動推演 | 把一句話需求延伸成完整 brief | 延伸後的 brief |
| ② 靈感鎖定 | 直接鎖 1 個最高級方向（四軸之一） | 方向 + 核心張力（CP2 用） |
| ③ 構思與敘事 | 資訊架構、滾動敘事、意圖映射 | Intention Map（強制；未產出不得進 ④） |
| ④ 系統設計 | 設計語法、動效盤點、能力盤點；動效/互動元件先查 shared/react-bits-assets.md §0（兌付狀態：11 個本地 ✅，其餘 🌐 需聯網）+ §3 海選，只用 ✅ 或自創等效 | 系統設計表 + 能力清單 ≥8–10 項（須註明元件來源：react-bits ✅ / 🌐 / 自創） |
| ⑤ 視覺實現 | 字型 / 色彩 / 版式 / 素材落地 | 頁面產物（HTML/CSS/JS，型態見 shared/code-generation-strategy.md §3.1；含字型與素材的落地或降級聲明） |
| ⑥ 互動與交付 | 互動、效能、三套門 | 過門禁的成品（CP4 用）+ usage-log.md 追加一行（日期 / 任務 / 種子 / 滑鼠族 / 元件） |
走到哪一階段，才讀
references/flow.md的哪一節——不必通讀。每節含「做什麼 / 具體內容 / 查閱什麼」三列。
領域分叉（重要）：上面 7 步是 Web 的完整流程。另兩個領域走自己的線，別套 Web 的階段與門禁：
- 海報 →
domains/poster/MODE.md§8 的 5 步：定尺寸 → 定主張 → 選家族 → 排三層 → 縮圖自檢 - 品牌 →
domains/brand/MODE.md的 B1–B5：策略（9 問法）→ 視覺模式 → Logo → 品牌板 → 產出
影片 → domains/video/MODE.md：先判該不該用（§1）→ 定角色與體積（§2）→ 選路線（§3）→ 做融合（§4，違和感 90% 在接縫）→ 過 V1–V9 交付檢查。
工具是旁路，不在主閉環裡：PPT / 影片匯出 / 翻新審計 / 設計思維 各自獨立觸發（見「領域速查」），與 6 階段並行，不佔階段編號。
工作方式約束 0–9（速查）
| # | 規則 | 判據 / 例外 |
|---|---|---|
| 0 | 使用者明確指令 > 通用預設 | 與硬規則衝突時指出並給替代；使用者堅持則遵從 |
| 1 | 直接鎖最高級方向，不拋平行選項 | 四軸之一（極致克制 / 密度 / 運動 / 材質）做到盡頭；不以實現難度為降級理由（難度只影響實現路徑，不影響方案） |
| 2 | = 約束1 的場景展開 | "隨便"→1 個方案；"給 2–3 個對比"才多方案 |
| 3 | 改動一次只問一個問題 | 多問 = 使用者無法歸因 |
| 4 | 精緻度優先於速度 | 動效無動機 / 節奏全平 / 狀態缺失 → 停下修 |
| 5 | section 數由規劃定 | <5 須寫明「為何極簡適合本 brief」；禁湊數、禁偷懶 |
| 6 | 模式是種子，不是骨架 | 禁「選風格→套骨架」，須當場重組 |
| 7 | 種子驅動連貫契約 | 每個維度要麼與種子共振，要麼寫明「刻意省略」 |
| 8 | 反保守生成紀律 | ≥3 種技術語言；互動須真實；文字也要動 |
| 9 | 素材庫取用紀律 | 先鎖種子 → 同族本頁 ≤1 → 寫使用聲明 |
| 10 | 方案凍結，禁順手撈現成 | 先列「方案需要什麼」再查「手上有」；替換必須寫「原定 / 實做 / 為何不等價」，靜默替換=失敗 |
完整規則、邊界情形與原理（含約束 0 的衝突裁決細則）見
references/constraints.md。約束 0 優先級最高，凌駕其餘約束與門禁（工程底線除外）。
門禁速查（交付前必過）
| 門 | 時機 | 查什麼 | 不過怎麼辦 |
|---|---|---|---|
| 執行門禁 | 進 ⑤ 之前 | 能力盤點 ≥8–10 項（必含 ≥1 文字動效 / ≥1 WebGL·Canvas / ≥1 GSAP·滾動編排）；同族重複須給種子理由（查 usage-log.md）；聯網獲取記錄（抓什麼→從哪→結果，A3）；交付型態受限時按可達上限給足並註明受限原因，禁虛構也禁默默缺項 | 補盤點再進 |
| 品質門 7 條 | ⑤ 末 · ⑥ 前 | 交付須給 PASS/HOLD 決定（taste-rules.md §8，禁「整體不錯」式放行）； critique 10 維 + 媒體/動效/佈局是否「克制而豐富」+ 種子連貫 + 反保守 7 問 | 回對應階段改，禁帶半成品交付 |
| 工程坑門禁 P1–P11 | 交付前 | grep / ls 機械核驗：字型落地、CDN 兜底、橫向溢出、斜體降部… | 修到 PASS，禁止帶 FAIL 交付 |
執行門禁與品質門的判據細則見
references/gates.md；工程坑 P1–P11 如下，屬每次必用，不再下沉。
工程坑門禁 P1–P11（交付前逐條跑）
與上方品質門的分工（關鍵）：品質門判「好不好」——品味/連貫/豐富度，屬判斷類，靠審美，無法機械判定； 本門禁判「有沒有壞」——會真實傷到可用性/觀感的已知工程缺陷，屬事實類，靠核驗。 收錄原則：只收能用 grep / ls / 運行時斷言機械核驗的項。判斷類規則一律不進本門（留在品質門），否則會退化為"自證合規"的空勾選。 執行：交付前逐條跑，任一條 FAIL → 修復後重驗，禁止帶 FAIL 交付。
| # | 坑（真實踩過的） | 核驗方式 | PASS 條件 |
|---|---|---|---|
| P1 | 只有背景動、內容不動（最常見、最傷"整體感"） | grep 每個內容 section 的滾動動畫綁定 | 內容容器存在 scroll-linked 的 translateZ/scale/rotate，不是只有 opacity/clip-path；且背景與內容由同一 progress 驅動 |
| P2 | 景深/裝飾層壓住內容 | 查 z-index 堆疊 + pointer-events | 近景/裝飾/雜訊層 z-index 低於內容層，且全部 pointer-events:none |
| P3 | 轉場閃爍/閃幀刺眼 | 查閃爍元素 opacity 峰值與 duration | 峰值 ≤ .4 且時長 ≥ .3s（可量化閾值，超出即刺眼） |
| P4 | prefers-reduced-motion 未真降級 | grep 該媒體查詢分支 | 存在分支且其中關閉 WebGL/重動效/閃爍，非僅縮短時長 |
| P5 | 字型/JS 引用了但檔案沒落地 | ls 產出目錄 assets/fonts/ 與 .js | @font-face 的 src、<script src> 指向的檔案物理存在（單檔案交付例外：改為核對交付裡是否給了 @font-face 片段 + TTF 清單）；若用了 interactive-editing.js，其檔案同樣在場且頁面已全面使用 CSS 變數（否則面板調不了參）（與品質門 6 同檢，此處是核驗動作） |
| P6 | CDN 依賴無兜底，庫缺失即白屏/無游標 | grep CDN <script> 是否有降級分支 | 關鍵庫載入失敗時頁面仍可讀、游標不消失（隱藏系統游標必須在 JS 確認就緒後） |
| P7 | 動畫動了非 GPU 屬性 | grep transition/animation/GSAP 屬性 | 僅 transform/opacity/filter（+相機參數），無 width/top/left |
| P8 | 行動端未降級 | 查斷點下的 WebGL 開關 | ≤820px 關閉重 WebGL，走 CSS 3D 降級 |
| P9 | 撞了 AI-slop 字型 | grep font-family / @font-face | 顯示字型不是 Inter / Fraunces / Instrument Serif（這三個已被用爛，見 anti-slop MODE.md） |
| P10 | 動效越檔 / 曲線越族 | grep -oE "transition:[^;]*[0-9]+m?s" 與 grep -oE "cubic-bezier\([^)]*\)"；出現 transition: all 即記問題 | 所有時長落在 motion-rules.md §1 四檔內、曲線 ⊆ §2 四族、無 all |
| P11 | 焦點不可見 / 控制項語義缺失 | Tab 走一遍（或無頭 page.keyboard.press("Tab") 後截圖）；grep outline://s*none、role="dialog"（須帶 aria-modal）、<th（須帶 scope） | 每元素有 focus-visible（≥2px、對比 3:1）；彈窗焦點陷阱 + Esc；表格表頭有 scope/caption（WCAG 2.4.7 / 1.3.1） |
沉澱回路（讓門禁自我進化）：每修掉一個工程坑，就地把它轉成一行可核驗斷言加進本表（寫清核驗方式 + PASS 閾值）， 而不是只寫"下次注意"。判斷類教訓寫進品質門，事實類教訓寫進本門禁——分類錯了這條規則就失效。
已知侷限（誠實標註）：本門禁只能攔已知且可核驗的坑，攔不住品味失敗與全新坑。 品味靠品質門 + 人眼驗收；全新坑靠上面的沉澱回路逐步收編。
交付後：回饋 → 回哪一階段
這是閉環的迴邊。先判定"哪一層錯了"，再決定退回幾格——直接從頭重做是最貴的錯誤。
| 使用者回饋 | 真正的問題在哪 | 回到 |
|---|---|---|
| "不是我想要的 / 理解錯了" | 需求 | ① 重新對齊 |
| "太平了 / 太保守 / 像模板" | 方向定檔不足 | ② 重鎖最高級方向（四軸之一） |
| "結構亂 / 不知道看哪" | 資訊架構與敘事 | ③ 重做 Intention Map |
| "不協調 / 各段不像一套" | 系統設計（語法不統一） | ④ 重建設計語法 |
| "就是不好看" | 視覺執行 | ⑤ 調字型/色/版式/素材 |
| "重做 / 重來 / 重新設計 / 換一個方案" | 明確要求新版本 | 全新重做（見下方三條硬規則） |
只改顏色 / 字型 / 間距 → 不必回階段，直接改並跳過 ④ 執行門禁（見 references/gates.md 的 D 條）。
多輪微改（同一任務延續）：首輪交付後使用者提「再調一下 / 換個感覺」，屬同任務延續——直接進對應階段（調色→⑤、換方向→②重鎖），不必重走 ① 也不重複 CP1；把多輪改動歸併後再統一交付，避免每輪都重新確認把使用者搞煩。
中途改大方向（③ 之後）：使用者說「換風格 / 方向錯了」→ 回 ② 重鎖（需求沒變只方向錯，不回 ①）；已寫的程式碼按新方向重構而非修補，禁止在錯誤方向上繼續堆細節（把"方向太平"當"視覺不好看"去調字號，改十輪也不會對）。
判錯的代價：把"方向太平"當"視覺不好看"去調字號，改十輪也不會對——先歸因，再動手。
重做 vs 修補（三條硬規則）
① 明確要求重做 → 必須全新版本，不許換皮 使用者說「重做 / 重來 / 重新設計 / 換一個方案」時：
- 必須重新選種子（約束7）、重寫 Intention Map，不復用上一版程式碼結構
- 交付說明必須列「上一版問題清單」：上一版錯在哪幾條 → 本版如何避免，證明不是同一方案換配色
- 判據：新舊兩版的「版式家族 / 動效層數 / 字型角色」三項中有兩項相同 → 這次是修補不是重做，須重來
② 「不合格」但沒指明 → 三選一，別問開放式 使用者只說「不合格 / 不滿意 / 不行」時，不要問「你想要什麼感覺」（使用者答不出）。給三個選項讓他指：
- 方向不對（氣質錯了）→ 回 ② 重鎖種子
- 結構不對（該看的東西看不到）→ 回 ③ 重做資訊架構與敘事
- 執行不行（方向對，就是沒做細）→ 回 ⑤ 按
shared/taste-rules.md§1 六個變數逐項調
一次只問這一個問題（約束3），使用者指完直接進對應階段。
③ 修補上限：2 輪封頂，超了強制重做 同一頁面的修補累計 2 輪後仍「不合格」→ 禁止第三次修補，必須升級為重做。 理由：兩輪修補都沒解決，問題就在方向或結構層，繼續調視覺只是消耗——「把太平了當不好看改十輪」是已記錄的失敗模式。
🛑 CHECKPOINT（只問該問的）
本 skill 預設不問方向（約束1），但下面 5 個節點必須停一下。除此之外不要中途請示——頻繁打斷是另一種失職。
| # | 節點 | 停下來的理由 | 你要給使用者什麼 | 不該做什麼 |
|---|---|---|---|---|
| CP1 | 需求解讀完成後 | 理解偏差的代價最高 | 一句複述：頁面類型 + 目標受眾 + 調性 + 三參數（或預設 8/6/5） | 讓使用者在 2–3 個方向裡選（違反約束1） |
| CP2 | 最高級方向鎖定後 | 方向錯了後面全廢 | 1 個方向的形象化描述（≤3 句），問「這個方向對嗎」 | 只報專業名詞（字型名/色值），使用者聽不懂 |
| CP3 | 使用者提改動要求時 | 一次改多處 = 無法歸因 | 一次只問一個問題，確認後再問下一個（約束3） | 一口氣拋 5 個問題 |
| CP4 | 交付前 | 未過門禁不得交付 | 品質門 7 條 + 工程門禁 P1–P11 的核驗結果（哪幾條 PASS、哪條跳過及理由） | 口頭聲稱「已檢查」而不給結果 |
| CP5 | 使用者說「可以了 / 差不多了」 | 該停就停 | 一句收尾 + 還差什麼（如有） | 繼續加戲、自行開啟下一輪最佳化 |
違反訊號（自查）：連續 3 個階段沒有一次使用者輸入、且未在 CP1/CP2 停過 —— 說明你在替使用者做決定，回退到 CP1。
不是 checkpoint 的事（問了反而糟）：選什麼字型、用什麼色值、section 放幾個、動效用哪個元件 —— 這些是你的判斷，不是使用者的活。
使用者意圖路由
| 使用者說什麼 | 起點 | 說明 |
|---|---|---|
| "寫一個頁面/元件"（需求明確） | ①需求解讀 → ②鎖方向 → ③Intention Map → ④系統設計 → 交付 | brief 以使用者明確需求為準；通用約束（含約束8）僅在使用者未指定的維度兜底，不覆蓋明確指令（約束0） |
| 「快速出活」「用現成主題」「換膚/換個主題」 | 主題快速線：讀 assets/themes/README.md 速查表（明暗→場景→強調色三步）選 1 套 → 複製其 :root 變數 → 按品牌微調 --accent → 交付 | 僅當使用者主動要求或明確趕時間時走；此時顯式豁免約束6（依據約束0：使用者指令 > 通用預設）。交付註明用了哪套主題、改了哪個變數。旗艦任務預設不走此線 |
| "幫我設計 landing page"（有方向需探索） | ①②之後直接鎖定最高級方向繼續 | 不要求使用者確認方向 |
| "改一下這個頁面的樣式"（已有程式碼） | 從⑤視覺設計開始 | 診斷 + 最小修改；動效新增/替換須補「區域性 Intention Map 動機表」（僅覆蓋改動 section）；純顏色/字型/間距修改豁免④執行門禁（見 references/gates.md 的 D 條） |
| "不知道用什麼風格" | ①②直接給出最高級方向方案 | 不列 2–3 個平行方向讓使用者選（約束1） |
| "做品牌設計" / "做海報" | 載入對應領域檔案 | 品牌 → domains/brand/MODE.md；海報 → domains/poster/MODE.md |
| "加個背景影片 / hero 放段影片" | 載入 domains/video/MODE.md | 先過 §1（是否非影片不可）→ §2 角色與體積上限 → §4 融合 → §9 V1–V9 檢查 |
| "做個後臺 / 管理臺 / 資料看板" | 先定骨架與表格，別先做看板 | design-patterns.md §6.4 交付順序：骨架 → 表格篩選 → 表單彈窗 → 看板 |
| 不確定 | 問使用者 | 從零設計 / 修改現有 / 需要風格建議 |
領域速查
工具類（評審 / 翻新 / 思維 / 幻燈片 / 影片匯出）的總覽與選型見
tools/README.md。
| 領域 | 觸發詞 | 載入路徑 |
|---|---|---|
| Web 頁面 | landing page / 官網 / 營銷頁 | domains/web/distilled-playbook.md（推理層，先讀）+ domains/web/anti-slop/MODE.md（反 AI 基線）；domains/web/integrated-rules.md（規則索引→shared/）+ domains/web/common-exceptions.md（例外裁決）；精確值查 shared/，CSS 查 domains/web/design-patterns.md / shared/css-patterns.md |
| 後臺 / 管理臺 | 後臺 / 管理臺 / dashboard / 資料看板 / CRM | domains/web/design-patterns.md §4 控制項規範 + §6 後臺介面（骨架/四類模板/密度）+ domains/web/integrated-rules.md §4 Token 契約 + shared/interaction-rules.md §7 鍵盤效率 |
| 品牌設計 | Logo / 品牌板 / 品牌設計 | domains/brand/MODE.md + domains/brand/brand-protocol.md + domains/brand/logo-concept-methods.md + domains/brand/visual-modes.md |
| 海報設計 | 海報 / poster / 宣傳圖 / 展架 | domains/poster/MODE.md（先定尺寸 §1 → 定主張 → 選家族 §3 → 排三層 §4） |
| Web 內嵌影片 | 背景影片 / hero 影片 / 產品示範影片 / 滾動影片 | domains/video/MODE.md（先判 §1 該不該用影片 → §2 角色 → §3 路線 → §4 融合 → §9 交付檢查） |
| 設計評審 | review / critique / 評審 | tools/critique.md |
…
[truncated for translation]