Design SystemInternalAuthority Stack

規則衝突時誰贏？

Internal維護者文件，不是 Design System 內容。

這頁是什麼

系統裡有很多「東西」都在給你指令 —— CLAUDE.md 規則、build 腳本、design_analyzer 的分析、外部 skill 的建議。當這些指令互相衝突時，誰贏？這頁把這個順序寫明白。

一共 5 層，從上到下優先順序遞減：

  1. 最終裁判 ── L1
  2. 實際狀態 ── L2
  3. build 時的自動檢查 ── L3
  4. Phase skill（在自己的 phase 裡能擋） ── L4
  5. 建議（僅供參考） ── L5

每層的詳細內容與裡面有誰 → 往下看。完整 entity 清單在 Entities 頁。

blocking— 會直接擋下不合規的 codehelper— 只是自動跑，不會擋

最終裁判 · L1

CLAUDE.md 的規則 —— 所有衝突的最後答案。不會輸給任何人。

誰在這層（21 個）
ruleSource of TruthrulePage Building RulesruleCross-DS HandoffprocessPhase A — Migration / AnalysisprocessPhase B — Builder / ImplementationprocessMigration Workflow (6 steps)referencePattern MappingruleProduct Components LayerruleRendering Context (Dark-first)ruleInteraction & State RulesruleLayout & Spacing RulesruleOutcome Color SystemrulePreview Page Completeness RuleruleSystem Log RuleruleGap List BindingruleExternal Skill GovernanceruleAudit AuthorityruleRe-evaluation Guard (B/C)enforcementPre-output ValidationblockingenforcementGrep-able Bans (6 rules)blockingruleRule Enforcement (meta)
衝突時輸給

（不會輸給任何人）

實際狀態 · L2

theme.css 的 token 與 src/components/ 的實作 —— L1 規則的實體。

誰在這層（3 個）
referencestyle.css (Live DS)referenceComponents (base / application / product)logsystem-log.md
衝突時輸給

L1（L1 規則決定 L2 應該長什麼樣）

build 時的自動檢查 · L3

build 前自動跑的腳本。不合規會直接擋下，不讓 code 進 main。

誰在這層（2 個）
scriptverify-preview-coverage.mjsblockingscriptgenerate-recent-updates.mjshelper
衝突時輸給

L1

Phase skill（在自己的 phase 裡能擋） · L4

design_analyzer 在 Phase A、design_auditor 在 audit 時登場的 skill —— 在 phase 內有否決權。

誰在這層（3 個）
skilldesign_auditorskilldesign_analyzerskillsystem_mapper
衝突時輸給

L1–L3

建議（僅供參考） · L5

外部 skill、slash command —— 只提供意見，任何衝突都輸給 L1–L4。

誰在這層（5 個）
skillui-ux-pro-maxskillawesome-design-mdskilldesign-for-aiskillnew-ds-to-legacy-translationskilldesign-for-ai commands (8)
衝突時輸給

L1–L4

衝突時的勝負關係（5 條）

跨層級的明文覆寫規則。每條寫成一句話：「X 贏過 Y」。

  • Source of Truth 贏過 ui-ux-pro-max

  • Source of Truth 贏過 awesome-design-md

  • Source of Truth 贏過 design-for-ai

  • design_auditor 贏過 design-for-ai

    （design_auditor primary on multi-audit）

  • design_auditor 贏過 design-for-ai commands (8)

邊界情況

L3 定義含糊：blocking gates vs helpers（點開看）

L3 叫「build 時的自動檢查」，但目前同時住了兩種東西：

  • verify-preview-coverage ── 真正會擋（exit 1）
  • generate-recent-updates ── 只是更新 generated file（exit 0）

兩者同住是因為「都在 predev / prebuild 跑」，不是因為「都會擋」。

三種可能的處理方式：

  1. 重新定義 L3 為「build 時的自動化」而不是「blocking gates」，接受混合行為
  2. 把 helper 移到 L2-runtime（generator 更接近 runtime artifact）
  3. 拆成 L3a-blocking / L3b-helper ── schema 改動，只有 helper 數量長大時才值得

目前：1 blocking + 1 helper，暫不拆分。加一條 clarifying note 到 schema、等 helper ≥ 3 再回頭檢視。