Loft 是做什麼的？
在形狀確認之前，不切割任何鋼材。 造船師在切割任何鋼板之前，會先以全尺寸放樣並修正船體的線條。Loft 將同樣的順序應用於設計問題：當文字討論已窮盡時 — 兩個看似合理的答案，都無法透過對話來驗證 — 建立一個低成本的可執行成品，讓隊長對其做出反應，並將該反應納入決策。
角色契約。 團隊負責建造成品；隊長的唯一工作是做出反應 — 而這個反應就是決策。成品是輔助判斷的工具，絕非交付物的預先起跑。
何時使用 loft
- 設計問題卡在文字描述中：反覆重述，仍無法定案（例如「路徑頁面應該長怎樣」、「這個狀態模型感覺對嗎」）
- 導航地圖上帶有
loft票證 - 規格討論進展到「我們得先看到它才知道」
不要在以下情況使用 loft：
- 問題可以從倉庫證據或直接詢問隊長得到答案（那是訪談，不是放樣）
- 目標本身不明確（那是迷霧 —
/oh-my-claudecode:ask-navigator） - 答案已存在於 ADR（不要重複放樣已解決的決策）
- 所謂的「設計問題」其實是 bug（那是除錯器的管轄範圍）
選擇分支
根據問題的性質來選擇。選錯分支會浪費整個成品。
邏輯分支 — 模型正確嗎？
針對狀態、業務規則、資料結構或演算法的問題（例如「重考時解鎖會退化嗎？」、「這個 reducer 在邊界條件下是否成立？」）：
- 將承載決策的核心 — 狀態機、reducer、結構描述或演算法 — 提取為一個純模組：沒有 DOM、沒有 I/O、沒有框架。撰寫時要確保一旦形狀確認，就能直接移入真實程式碼庫而不需修改。
- 將其包裝在一個可點擊的 HTML shell 中：每個情境一個按鈕，按順序走過棘手的邊界案例，每次點擊後都能看到完整狀態。
- 確認後，該模組即可透過 launch 重新以實際工作形式進入。在放樣期間，
main分支保持不動，shell 則留在分支上。
UI 分支 — 它應該長怎樣？
針對形狀與編排的問題（「步驟式還是卡片式？」、「進度條應該放在哪裡？」）：
- 一個路由，三個在結構上不同的變體 — 資訊架構、導航模型、資訊密度。僅在樣式上不同的變體無法回答任何問題：三個不同的皮只是牆紙。
- 頁面上有一個切換器用於循環顯示變體；盡可能嵌入現有產品中，這樣真實的資料密度會考驗設計，而不是三個整齊的假資料列。
- 確認後，決策被轉移，而變體留在分支上，作為為何如此設計的記錄。
紀律
- 一條指令即可執行 — 使用倉庫中最簡單的現有 serve 指令；如果
file://模組 CORS 會咬人，則將模組內嵌到 shell 中。幾秒內載入完成；無需超出倉庫現有範圍的建置步驟。 - 沒有持久化、沒有測試、沒有抽象、沒有錯誤處理（僅處理快樂路徑）。成品應該是你絕對不想出貨的東西 — 這些規則的存在就是為了讓它保持這個狀態。
- 預期第一個形狀會受到質疑：在同一個會話中於分支上進行修改。隊長確認最終形狀就是決策；一個沒有人質疑的成品，通常回答了一個根本沒有人提出的問題。
- 成品的完整生命週期：幾分鐘的構建時間 + 一個會話的決策時間。如果它開始長成生產級程式碼，請停止：那個工作屬於 launch，而不是 loft。沉沒成本正是這個技能存在的目的是要防止的失敗模式。
- 一次 loft 回答一個問題。兩個問題就是兩次 loft — 或者一個實際上包含兩個問題的問題。
摺疊答案
成品是證據，不是終點。當隊長做出反應時：
- 將決策記錄在其歸屬之處 — 問題評論、規格的 Implementation Decisions 區塊，或待決決策備註 — 使用隊長自己的話，加上一行「為什麼」。比文字更精確的片段（reducer、狀態機、結構描述）可以內嵌在該處，並標記為已放樣（lofted）。
- 將成品推送到
loft/<name>分支。它永遠不會合併：它將作為主要原始資料，當未來有人需要了解該決策的「為什麼」時，可以開啟查閱。 - 成品中的任何內容都不會進入
main— 對於邏輯分支，確認後的模組會透過 launch 重新以實際工作形式進入；對於 UI 分支，真正的頁面會根據決策從頭建立。
範圍與非目標
- Loft 產出的是答案，而非交付物：沒有執行時期、沒有狀態檔案、沒有始終在線的東西。
- 它不進行診斷（除錯器）、不為迷霧繪圖（
/oh-my-claudecode:ask-navigator）、不批准自己的答案（隊長的唯一反應就是核准）。 - 它不取代接縫批准：放樣的 UI 顯示的是形狀；其測試接縫仍然在 C2 階段被批准。
完成定義
隊長已做出反應，答案存放在決策所屬之處，成品存放在其分支上 — 且成品中沒有一行程式碼進入 main。