Mobile Design OS
執行滿足需求結果的最小平臺行動設計鏈。將工作路由至專門技能，在各階段之間保留穩定的 ID 與證據，絕不讓精美的視覺設計掩蓋未解決的產品、平台、狀態或驗證缺口。
建立執行
確定：
- 需求的結果：分析、產品架構、UX、視覺概念、完整設計包、原型、審查或實作交接。
- 目標平台與裝置尺寸。
- 可用的輸入：產品點子、截圖、URL、品牌素材、現有合約、程式碼或執行期證據。
- 授權範圍：僅設計、原型或程式碼變更。
- 真正需要使用者決策的事項，特別是安全模型、主要角色、MVP 邊界、視覺方向、框架覆寫與公開授權。
當工作需要跨越兩個或以上階段、或必須能夠恢復時，從 assets/design-run-template.json 建立 design-run.json。在建立或更新清單前，請先閱讀 references/pipeline-contract.md。
路由至所需的技能
在執行該階段之前，請完整閱讀所選技能的 SKILL.md。若需求僅需一或兩個階段，請勿載入所有技能內容。
| 需要 | 技能 | 完成證據 |
|---|---|---|
| 探索或比較參考資料 | mobile-reference-research | 有效的 reference-research.json |
| 提取機制與設計 DNA | analyze-mobile-ui | 有效的 design-dna.json |
| 架構產品與 MVP | mobile-product-brief | 有效的 product-brief.json |
| 定義流程、物件、畫面與狀態 | mobile-ux-architect | 有效的 ux-architecture.json |
| 建立低保真層級結構 | mobile-wireframe | 有效的 wireframe.json |
| 探索與渲染視覺 UI | mobile-ui-design | 使用者選定、鎖定、並在需求結構化交接時提供有效的 ui-design.json |
| 提取可重複使用的 token/元件 | mobile-design-system | 有效的 design-system.json |
| 建模或渲染互動行為 | mobile-prototype | 有效的 prototype.json 及 UI 對齊報告（當 UI 存在時） |
| 決定與測試原生行為 | mobile-platform-guidelines | 有效的 platform-guidelines.json |
| 審查整個鏈路 | mobile-design-review | 包含誠實決策的有效的 review.json |
| 規劃或實作程式碼 | mobile-design-to-code | 有效的交接以及當生成程式碼時的實際建置/測試證據 |
執行完整鏈路
對於端到端的需求，請依此順序執行，僅跳過明確標記為 not-required 的階段：
- 執行
mobile-product-brief以鎖定問題、受眾、啟動方式、核心循環、MVP、信任邊界與未決策的事項。 - 當缺少參考資料或需要比較時，執行
mobile-reference-research。 - 當截圖或參考產品必須成為可追溯的設計 DNA 時，執行
analyze-mobile-ui。 - 從經過驗證的簡報與參考決策執行
mobile-ux-architect。 - 在層級結構或狀態壓力非微不足道時，先於視覺樣式之前執行
mobile-wireframe。 - 執行
mobile-ui-design。強制提供恰好三個可比較的預覽，並在其使用者選擇閘門處停止。除非使用者明確委託選擇，否則不要選擇視覺方向。 - 選擇後，鎖定視覺方向並完成渲染畫面與結構化 UI 工件。
- 當需要下游重用或實作 token 時，執行
mobile-design-system。 - 執行
mobile-prototype，然後驗證 UI 與原型之間的狀態與互動對齊。 - 執行
mobile-platform-guidelines以取得原生行為與裝置測試案例。 - 執行
mobile-design-review，針對完整的可用鏈路進行審查。 - 僅當需求包含實作或交接，且審查決策允許時，才執行
mobile-design-to-code。
在每個階段後更新 design-run.json。保留上游的 Requirement、Flow、Screen、State、Token、Component 與證據 ID；絕對不要在下游階段默默重新生成識別符。
強制閘門
- 執行每個由所選技能命名的階段驗證器，並在繼續之前修復結構性失敗。
- 在宣稱 UX 完整之前，需要一個經過驗證的 Product Brief。
- 在宣稱 UI 完整之前，需要明確的狀態所有權與恢復機制。
- 在進行 Design System 或渲染原型工作之前，需要
visualLock.status: locked以及使用者或使用者委託的選擇來源。 - 當兩個工件都存在時，需要 UI 與原型對齊。
- 保留截圖與瀏覽器執行器，以證明執行期可訪問性、生命週期、權限、感測器、持久化、遞送或裝置行為。
- 保留程式碼交接，以證明生成的程式碼能夠建置或測試。當生成程式碼時，記錄確切的命令與結果。
- 在
pass之前，不允許有未解決的 P0 或 P1 問題，也不允許缺少高風險證據；否則使用conditional-pass、revise或fail，如審查技能所定義。
在交付多階段執行之前，執行 python3 scripts/validate_design_run.py <path-to-design-run.json> --root <run-directory>。
僅在重大決策時暫停
在以下情況暫停：
- 使用者必須在三個視覺方向中選擇。
- 決策會改變安全性、隱私、主要角色、核心價值循環、破壞性行為或 MVP 範圍。
- 缺少必要的輸入或授權。
- 下一步驟會聲稱尚未實際提供的外部評估、實體裝置證據、生產行為或公開授權。
否則，以標記的假設繼續進行，並將之記錄在清單中。
交付執行
回傳：
- 結果與當前階段決策。
- 已完成的階段與經過驗證的工件路徑。
- 使用者決策與標記的假設。
- 未解決的 P0/P1 問題與未測試的高風險行為。
- 下一個可執行的階段，或仍存在的確切外部/裝置/使用者閘門。
當必要階段待處理、等待使用者選擇、被阻擋、或結構有效但未經測試時，請勿將該鏈路描述為完整。