Launch

Launch 是做什麼的？

Launch 是 shipyard 的交付流程：從任務簡報到交付、驗證的變更。它立於可驗證性邊界之上——代理程式持續執行一切可重複且可透過證據驗證的事項；人類則決定系統無法判斷或失敗成本高昂的事項。 目標並非最大化自動化，而是最大化可驗證工作的委派，讓人類的時間僅花在只有人類才能做出的決策上。

可驗證性測試，應用於每個步驟：如果這件事做錯了，系統能偵測到嗎？系統能自動重做或回滾嗎？ 兩者皆可 → 代理程式。沒有唯一答案、系統無法判斷、或失敗成本高昂 → 人類。

Launch 假設 shipyard 已存在——若不存在則拒絕執行。yard gate 是每次調用的第一個動作，在文件語言解析和讀取任何提供的規格之前執行：

• 執行完整的 drydock --check 稽核——缺少的表面、缺少或無效的 CONTEXT.md 前置元資料 documentLanguage、死路徑、詞彙表中未在程式碼中使用的術語、從未被引用的標準。這是單一標準：Launch 不執行自己的獨立設施清單。
• 可操作/高信心的發現會硬性阻止執行： 逐字列出每個此類發現，指向 /oh-my-claudecode:drydock，聲明執行從未開始且未產出任何產物，然後停止。若沒有明確的覆蓋，則將任何發現視為阻斷性的。
• 狹義覆蓋（僅限明確意圖）： 低信心發現、drydock 報告中明確分類為誤報的發現、或用戶明確聲明的測試/拋棄式儲存庫，僅可透過刻意的、每次調用的用戶意圖來覆蓋——覆蓋必須指明發現的名稱或拋棄式範圍，且絕不能無聲地吞沒高信心的可操作發現。沒有通用的繞過標誌。
• 目前的稽核限制： 目前 --check 是一個技能指令檢查清單，沒有機器可讀的發現/嚴重性合約或可執行檔——嚴重性分類依賴 drydock 報告的措辭，直到存在結構化合約為止。機器可讀的發現/嚴重性退出合約是預期的後續工作；gate 的措辭誠實地說明它可以和不能依賴哪些機械性內容。
• 乾淨的稽核（或明確覆蓋的低信心/誤報/拋棄式範圍）允許執行。 每個紙本軌跡插槽（CONTEXT.md、docs/adr/、docs/business/）和設施表面此時都已存在；Launch 在決策確定時填寫紙本軌跡，但從不建立插槽。
• 規則條目是 CLAUDE.md——shipyard 地圖不承認任何替代品。

邊界

人類檢查點（關鍵的 20%）	代理程式持續執行（機械化的 80%）
C1 撰寫任務簡報（目標 + 範圍）	事實調查和儲存庫探索，自助服務
C2 核准驗收標準 + 測試縫清單	訪談準備：前沿問題批次處理並附帶建議答案
C3 核准任務分解（粒度、阻斷邊緣）	規格和任務草擬、機械驗證（獨立性、可證明性、符合單一上下文）
C4 回答執行中途出現的不可逆決策（批次處理、非同步）	在商定的縫處進行 TDD 實作、建置、測試、回歸
C5 接受完成報告；透過開放假設和逐行沉積清單否決	程式碼審查、跨變更驗證、團隊前沿排程、完整的紙本軌跡

在檢查點之間，管線從不閒置：代理程式持續處理所有不依賴待處理人類答案的前沿工單。

生命週期姿態

Launch 是對 OMC 現有生命週期的無狀態組合——它不擁有自己的運行時狀態機：

• 團隊擁有任務狀態、轉換、取消和運行時清理；Launch 從不超出團隊合約變更它們。
• 規範的 plan → execute → review → verify 表面擁有其現有的生命週期行為。Launch 創作的產物僅限於 .omc/specs/<feature-slug>/、CONTEXT.md、docs/adr/ 和 docs/business/——此外，僅在 C5 核准後，才包括階段 5 表格中命名的沉積插槽。
• Launch 沒有自動恢復功能。中斷後，重新讀取產物和目前的團隊狀態，但僅能透過在擁有團隊生命週期達到支援的終端/清理邊界後，重新明確調用 Launch 來繼續。絕不能推斷人類核准或重播 in_progress 任務。
• 模糊工作屬於導航者的管轄範圍：當霧門路由到 /oh-my-claudecode:ask-navigator 時，執行從未開始——沒有產物，沒有部分狀態。導航者的地圖是跨會話的唯一載體；Launch 僅從它交回的任務簡報恢復。
• Launch 不添加自己的核准收據、修訂計數器、重播日誌、取消路徑、回滾機制或清理生命週期。

此技能中的任何持久性聲明都是關於磁碟上檔案的聲明，而不是關於隱藏運行時的聲明。

階段 0——入口

只有通過乾淨的 yard gate，執行才能到達此階段。在讀取提供的規格或進入階段 1 之前，需解析文件語言。目前調用中的明確人類選擇優先；否則從 CONTEXT.md 前置元資料中精確的穩定鍵 documentLanguage 讀取有效的 BCP-47 風格標籤；否則需從 CLAUDE.md 然後 README.md 獲得一致的、高信心的推斷。持續存在的、裸的或僅區域的中文標籤存在指令碼歧義，必須在該權威層級詢問一次，絕不能透過推斷繞過。遺失、混雜、衝突、低信心、無效明確或指令碼歧義的中文證據需要一次批次處理的語言問題；不要猜測。中文必須解析為明確的 zh-Hans 或 zh-Hant 指令碼標籤。zh-Hans-* 選擇簡體 Companion 而 zh-Hant-* 選擇繁體 Companion，同時完整的標準化標籤會被持久化。在撰寫任何 Launch 創作的產物之前，將解析後的標準化標籤持久化回 CONTEXT.md，以便新的明確調用可以在沒有隱藏對話狀態的情況下讀取它。人類閱讀和維護這些產物；代理程式則與語言無關。

僅在地化散文和人面對的標籤/可地化的純量值。路徑、斜線命令、標誌、程式碼區塊、佔位符、前置元資料鍵和機器語義值、YAML/JSON 鍵、生命週期令牌（plan、execute、review、verify）、狀態列舉（pending、in_progress、completed、failed、ready-for-agent）、ID、工單 blockedBy、公共團隊 blocked_by，以及所有解析器/控制令牌保持字節不變。語言 Companion 是互斥的：僅輸出一個選定的渲染，絕不輸出雙語重複的標題或標籤。

• 在任何其他事情之前進行簡短的自我檢查：簡報是否命名了目標、範圍邊界和非目標？如果缺少兩個或以上，請說明並要求一次銳化——在軟簡報上執行管線會將模糊性轉化為看起來自信的輸出。
• 霧門：在銳化通過後，應用導航者的霧測試——問題 1：目的地能否用一句話陳述（此努力正在尋找路徑的規格、決策或變更）？問題 2：能否立即精確陳述前三個決策，即使沒有一個可以回答？任一答案為否 → 執行從不開始：明確說明，指出未產出任何產物，建議 /oh-my-claudecode:ask-navigator（shipyard 的導航者將霧繪製成決策工單地圖並交回任務簡報），然後停止。移交殘留問題和任何已確定的詞彙，以便導航者的 W1 不再重新詢問它們。
• 地圖檢查：在讀取提供的規格或進入階段 1 之前，尋找開放的 navigator:map（追蹤器標籤，或在 .omc/wayfinder/ 下）。存在一個且此次調用未提供新的簡報 → 建議 /oh-my-claudecode:ask-navigator 以處理該地圖上的下一個決策，然後停止。存在一個且提供了新的簡報 → 詢問一個問題——繼續開放的地圖，還是開始新的努力——然後再繼續。
• 提供了規格路徑 → 讀取它，跳轉到階段 2。
• 任務簡報 → 階段 1。
• 單點修復 → 移交給執行，退出。

階段 1——收斂（人類決定，代理程式準備）

使用設計樹協議執行訪談：繪製決策及其依賴關係，然後以前沿輪次進行——將每個目前可問的問題批次處理為一輪，編號，每個附帶一個建議答案。人類回答；樹形重塑；重新計算前沿。事實始終由子代理程式根據儲存庫證據自助取得——人類僅被詢問那些無論多少探索都無法解決的問題。

紙本軌跡，在每個項目確定時撰寫：

• 領域詞彙 → 儲存庫根目錄下的 CONTEXT.md（每個術語一個條目）
• 通過 ADR 測試的決策（難以逆轉、缺乏上下文時令人驚訝、涉及真實權衡）→ docs/adr/NNNN-<slug>.md
• 在收斂過程中發現的業務規則和背景 → docs/business/（每個業務問題一篇文章，開頭段落說明其重要性）

此處未收斂是正常的工作，而非失敗：如果前沿無法清空，則呈現殘留問題並排序——這是 C2 的輸入，不是錯誤。如果殘留問題本身無法精確陳述（霧測試問題 2 失敗），則目的地本身未確定，這超出了 C2 的權限：停止，記錄已確定的內容（CONTEXT.md 中的詞彙、已回答的問題），建議 /oh-my-claudecode:ask-navigator，然後退出——管線從不發明目的地。

Loft 繞道。 一個殘留問題雖然精確但無法用散文解決——它需要被看到或點擊，而不是被描述（UI 應該長什麼樣子、狀態模型感覺是否正確）——則透過產物而不是更多問題來回答：使用「loft」調用技能工具，讓船長做出反應，並將該反應回納到訪談中。loft 過的產物是 C2 的輸入；船長為他們所看到的簽署，而不是為他們被告知的內容。

Harbour 簡報。 由 /oh-my-claudecode:harbor 移交的任務簡報帶有已簽署的決策、連結和適用條件：將它們視為已做出——不要重新詢問未變更的業務目標。如果自證據收集以來程式碼已移動（新的 HEAD、變更的基础），則重新驗證受影響的技術證據；超出已簽署簡報的新實作範圍仍需要自己的核准。

階段 2——規格合成（代理程式草擬 → C2 核准）

合成 .omc/specs/<feature-slug>/spec.md：

# <Feature> 規格
## 問題
## 解決方案
## 用戶故事        （編號，每個附帶可測試的驗收標準）
## 實作決策
## 測試決策   （僅限外部行為）
## 超出範圍

草擬所有內容，然後在 C2 處停止：呈現驗收標準和測試縫清單以供人類核准。縫的選擇基於儲存庫證據和深層模組紀律（公共介面、現有測試縫、深度分析）；人類確認或更正清單——人類未核准的縫不會有測試。

持久性門（代理程式強制執行，無需核准）：規格和工單攜帶合約，而非座標——沒有檔案路徑，沒有行號。比散文更好地編碼決策的片段（狀態機、歸約器、模式）是例外，並說明其來源（通常是 loft）。

階段 3——任務分解（代理程式草擬 → C3 核准）

在 .omc/specs/<feature-slug>/tickets/ 下分割成垂直切片：

• NN-slug.md，每個工單一個檔案，按依賴順序排列，每個聲明 blockedBy: [ids]
• 每個工單跨越每個層級，可獨立演示，並符合一個新鮮的上下文
• 廣泛的重構採用擴展-收縮模式：添加新形式、分批遷移、移除舊形式——每個批次一個工單

首先執行代理程式端的機械驗證（獨立性、可證明性、上下文契合）。然後是 C3：呈現粒度、阻斷邊緣和建議的合併/分割以供人類核准。迭代直到核准。將每個工單標記為 ready-for-agent。

整合接線規則：每個垂直切片都包含自己的接線和一個斷言——其輸出沒有任何東西掛載、服務或導入的切片未完成。沒有單個切片擁有的跨切片縫（路由掛載、靜態服務、入口點接線）會獲得一個明確的整合工單，作為最後的前沿項目。

階段 4——執行前沿

前沿是其所有阻斷者都已完成的所有工單。

並行（預設，2+ 個工單）。 將工單交給團隊：每個工單成為一個團隊任務，blockedBy 邊緣繼承——團隊的領取機制只選取前沿任務。生成 N 個工作人員。每個工作人員使用在 C2 中核准的縫處的 TDD 紀律進行實作，應用 /oh-my-claudecode:minimal-code-discipline 作為撰寫時紀律（它保持選擇加入）；一個工單僅在程式碼審查通過差異後由審查者宣布關閉——實作者絕不能自我核准。

串行（單個工單，或 --serial）。 一次將一個工單委派給一個執行子代理程式；相同的審查門。

雙軸審查關閉。 關閉審查沿兩個軸並行進行，分別報告——從不合併或交叉排名，因為一個變更可以通過一個軸而失敗另一個軸（符合標準但行為錯誤；忠實但違反慣例）。當任一軸失敗時，審查者使工單失敗：

• 標準軸——差異針對匹配的 docs/standards/ 卷，加上僅涉及判斷的異味基線（已記錄的儲存庫標準覆蓋基線；工具已強制執行的任何內容都跳過）。這是使標準表面被引用的常設消費者。
• 規格軸——差異針對此工單的驗收標準（規格是工單從中分解的總帳；僅在追溯標準的來源以及裁決走私的範圍——沒有工單對應的行為時才查詢它）

…

[由於原始文字被截斷，其餘部分將在完整內容可用時翻譯。目前，階段 4 的其餘部分和階段 5 保持不翻譯。]