lfg

重要：你必須依序執行以下每個步驟。不得跳過任何必要步驟。不得直接跳到撰寫程式碼或實作階段。規劃階段（步驟 1）必須先完成並驗證，才能開始任何實作工作。違反此順序會產生不良結果。

呼叫下方任何技能時，請根據主機平台提供的可用技能清單解析其名稱，並使用該清單中的確切條目。某些平台會將技能列在插件命名空間下（例如 compound-engineering:ce-plan）；其他平台則只列出裸名稱。若猜測的簡寫不在清單中，呼叫將會失敗——在呼叫 Skill/Task 工具前，務必比對清單中的逐字條目。

任務可視性

在步驟 1 之前，若平台提供任務追蹤功能，請發布一個簡短的階段層級管線剩餘工作檢視。此檢視應根據下方使用者有意義的結果來推導，而非直接反映全部十個步驟或揭露內部閘門。在呼叫子技能前，請取代或清除 LFG 的任務檢視，僅顯示子技能的任務表面；子技能返回後，在呼叫下一個子技能前，請重新建立或重新整理 LFG 的剩餘管線工作。僅在條件閘門觸發時才加入條件性工作。若無任務追蹤功能可用，則正常繼續，無需在對話中模擬任務清單。

產出物根目錄

此管線將計畫記錄在 <root>/plans/ 下，審查殘留項目記錄在 <root>/residual-review-findings/ 下。請在你首次組合 <root>/ 路徑時（根據下方區塊）解析 <root>，切勿在此之前解析。對 <root>/... 的寫入以及對 <root>/solutions/ 的讀取都算組合 <root>/ 路徑，因此任一操作都會觸發解析；只有完全不觸及 <root>/ 路徑的執行（僅暫存或無儲存庫流程）才會跳過此步驟。

<!-- ce-docs-root:start -->
在組合任何產出物路徑之前，請先解析 CE 產出物根目錄 <root>。

• 讀取 <repo-root>/.compound-engineering/config.local.yaml 中的 docs_root，然後讀取 config.yaml；第一個非空值勝出（<repo-root> = git rev-parse --show-toplevel）。若未設定，則 <root> 為 docs，與先前完全相同。
• 驗證設定的值：必須是相對於儲存庫的目錄，其真實路徑（解析符號連結後）必須位於儲存庫內，且既不是儲存庫根目錄，也不在 .git/ 下。否則以錯誤訊息停止，指出 docs_root 及其值——絕不回退到 docs。
• 使用 <root> 作為唯一的產出物位置：若不存在則建立，將每個路徑組合為 <root>/<subdir> 並加上此技能自己的子目錄，且絕不另外讀取 docs。
  <!-- ce-docs-root:end -->

各階段的路由載體

在步驟 1 之前，請解讀呼叫對話是否表達了將管線階段（規劃或實作）指派給特定模型或工具的語義意圖。這是判斷，而非關鍵字或提示詞匹配：明確的指令如「用 fable 規劃」或「實作用 Codex」會建立指派，而僅在功能內容、引用資料、比較文字或檔案名稱中提及 Codex、Composer、Fable 或其他模型/工具，則不會建立指派。有兩個管線階段可路由，各自有其載體：

• 規劃階段路由到 ce-plan，使用 plan_model:<alias> 載體——即規劃撰寫的模型（模型提升），僅限模型。範例別名：fable、opus。規劃階段沒有跨工具引擎：若指派將某個工具範圍限定在規劃階段（「用 codex 規劃」、「在 cursor 上規劃」）則不支援——請將其視為路由載體阻礙，而非將工具名稱編碼為 plan_model:<harness>，因為 ce-plan 無法處理該載體，且會靜默回退到對話模型。只有實作階段會路由到不同的工具。
• 實作階段路由到 ce-work，使用 implementation_engine 物件（語法如下）——即撰寫工具/模型。

根據範圍解析每個指令：

1. 有範圍的指令——指令指名了階段（「用 fable 規劃」、「codex 用於實作」、「plan fable, codex work」）。將其路由到該階段的載體。多個有範圍的指令可能同時解析，各自對應到其階段。
2. 無範圍的指令——僅指定模型/工具，未指名階段（「用 fable」、「with codex」）。僅將其綁定到實作階段；切勿將無範圍的指令擴大到規劃階段或所有階段。在步驟 1 之前的 LFG 開場行中揭露已解析的綁定（例如「將實作路由到 Codex；規劃階段維持使用對話模型。」）。
3. 無範圍且確實有歧義，且有人類在場——當無範圍的指令可能合理地屬於多個階段，且錯誤綁定會造成重大成本，且主機是互動式的（提供阻斷問題工具，且非 disable-model-invocation/無頭執行），則在步驟 1 之前提出一個前置問題來綁定階段，然後繼續自動執行。在 disable-model-invocation/無頭執行中，絕不發問——套用實作預設值並揭露。預設路徑是強制的：LFG 由排程器、迴圈和巢狀協調器執行，沒有使用者可以回答，因此未解析的指令必須始終回退到揭露的預設值，而非阻塞。

需求強度是根據整個指令推斷，而非單一詞彙：「use Codex for implementation」是偏好強度（prefer）；「only use Composer for implementation」是需求強度（require），因為其語義拒絕原生回退。

實作載體語法。 當實作解析為一個候選時，保留一個暫態的 implementation_engine 物件，包含以下四個欄位：

• mode：prefer 或 require
• target：恰好是 codex、claude、grok、cursor 或 composer 之一——一個工具名稱，絕非模型名稱
• model：明確的模型固定值，否則為 null
• source：呼叫方可見的來源，標識當前的 LFG 指令

一個指名了裸模型但未指定工具的指令（例如「use fable」、「with opus」）是模型固定值，而非目標：將其編碼為提供該模型家族的服務工具，並將別名放在 model 中——Claude 家族模型（fable、opus、sonnet、haiku）為 {"target":"claude","model":"<alias>"}。切勿將模型名稱放在 target 中；若你無法將指定的模型映射到五個工具之一，則為路由載體阻礙，而非靜默丟棄使用者指令的 null 綁定。

當實作指令改為指定有序的回退清單時，請勿將其截斷為純量載體——保留整個有序指派作為當前任務的實作意圖，且不傳遞 implementation_engine: 物件。在 CE Work 的接合點，該仍活躍的當前任務指派優先於設定，並會依序進行正規化與預檢。這是階段範圍的上下文，而非計畫內容；若主機無法在其技能呼叫之間保留該上下文，請以路由載體阻礙停止，而非靜默丟棄後續候選項。

淨化產品輸入。 從進入規劃階段的功能請求中移除所有路由指令，保持請求的其他部分不變。切勿將 implementation_engine 物件或任何已移除的指令傳遞給 ce-plan、ce-doc-review、ce-code-review、已定決策摘要，或任何規劃或審查產品輸入——載體是階段範圍的路由權威，而非產品內容或已定的產品決策。plan_model:<alias> 載體是唯一的例外：它是結構化的路由資料，與淨化後的請求一起傳遞給 ce-plan——絕非編織到請求中。請勿在此處從現有設定建構載體：當某階段沒有明確綁定時，ce-work 和 ce-plan 負責解析仍適用的對話/專案意圖以及每次簽出的現有設定。

1. 使用上述準備好的淨化功能請求（或當沒有路由指令時，使用你被呼叫時收到的未變更引數）呼叫 ce-plan 技能。當規劃階段的指令已解析時，在其呼叫前加上 plan_model:<alias> 載體——結構化的路由資料，與請求並列，絕非編織到請求中——這樣即使是在管線模式下，ce-plan 的模型提升也能在選定的模型上撰寫計畫。

   在呼叫之前，從呼叫對話中組合一份已定決策摘要，並與那些引數一起傳遞：方向（1-2 行）；已定決策，每個決策包含四個必要欄位——決策內容、其來源類別（user-directed 或 user-approved）、被拒絕的替代方案，以及一行理由；開放領域；以及一行常設的報告衝突行。若某個條目的被拒絕替代方案無法陳述，則降級為指令或開放領域。範圍應限於主題——僅限於與正在交付的功能相關的決策；若有疑慮，則降級（重新討論是安全的底線；匯入過時的已定決策則不是）。若對話中沒有已定決策，則完全跳過組合，並如上所述直接呼叫 ce-plan——無需空摘要儀式。摘要是暫態的：一旦 ce-plan 寫入計畫，計畫中標記的 KTD 即為正式版本。

   閘門：停止。若 ce-plan 回報任務非軟體相關且無法在管線模式下處理，則停止管線並通知使用者 LFG 需要軟體任務。若 ce-plan 回傳包含 settled-decision-invalidated 的阻塞報告，則停止管線並附上原因通知使用者——不要重試。否則，驗證 ce-plan 工作流程是否在 <root>/plans/ 下產生了計畫檔案。若未建立計畫檔案，則使用相同的引數再次呼叫 ce-plan。重試時直接重複使用已組合的摘要——絕不重新組合。在書面計畫存在之前，不要繼續進行步驟 2。記錄計畫檔案路徑——它將在步驟 2 傳遞給 ce-work，並在步驟 4 傳遞給 ce-code-review。

   在繼續之前，請先讀取計畫元資料。若計畫具有 artifact_contract: ce-unified-plan/v1，則僅在其具有 artifact_readiness: implementation-ready 和 execution: code 時才繼續。對於 artifact_readiness: requirements-only、任何無法辨識的 readiness 值、execution: knowledge-work、方法計畫輸出、尋求答案/通用輸出，或無效的類似進度的 readiness 值，請停止管線。LFG 絕不直接啟動 /goal；當目標模式或動態工作流程合適時，ce-work 擁有該實作引擎的選擇權，且必須在之後將控制權返回給 LFG。

2. 當不存在純量暫態載體時（包括當保留的有序當前任務指派仍在上下文中活躍時），使用 mode:return-to-caller <plan-path-from-step-1> 呼叫 ce-work 技能。當純量載體存在時，使用確切字串主機形式 mode:return-to-caller implementation_engine:<compact-json> <plan-path-from-step-1>。

   若純量暫態載體存在，請將其確切的 implementation_engine.{mode,target,model,source} 資料序列化為緊湊 JSON，緊接在 implementation_engine: 前綴之後（例如 implementation_engine:{"mode":"prefer","target":"codex","model":null,"source":"lfg-current-turn"}）。這是結構化的呼叫者資料，位於可攜式字串信封中，不是計畫路徑或實作提示的一部分。當其不存在時，不要傳遞空載體。ce-work 隨後會解析仍存在的有序當前任務指派（若存在），否則解析適用的對話/專案意圖和每次簽出的現有設定。LFG 是自動的、無頭的呼叫者：它絕不會提示以削弱需求強度的路由。

   可選的 implementation_run:<safe-id> 載體僅用於復原。在初始的步驟 2 呼叫中絕不包含它。在下方唯一的一次證據協調復原中，將其放在相同的引擎載體之後（若存在）和未變更的計畫路徑之前：mode:return-to-caller implementation_run:<safe-id> <plan-path-from-step-1> 或 mode:return-to-caller implementation_engine:<compact-json> implementation_run:<safe-id> <plan-path-from-step-1>。安全 ID 必須符合 ^[A-Za-z0-9._-]{1,128}$ 且包含至少一個非句點字元。拒絕格式錯誤或重複的 run/engine 載體，而非啟動工作。

   閘門：停止。在繼續之前，請先讀取結構化回傳。status: blocked 或 status: failed 的回傳會停止管線。特別是，不可用的 require 路由不得提示、回退或啟動原生工作。已完成的 prefer 回退可以繼續到步驟 3，但僅限一次，且必須在使用者面前顯著揭露其請求與實際的路由/模型以及 fallback_reason；回退不是再次呼叫實作的理由。

   對於 status: complete，請驗證實作工作已執行——檔案已建立或修改，超出計畫範圍。需要相同的計畫路徑、已變更的檔案、嘗試/完成的 U-ID（若存在）、驗證結果、行為變更訊號，以及 standalone_shipping_skipped: true。還需要路由感知的收據欄位 implementation_engine_binding、requested_route、actual_route、requested_model、actual_model、fallback_reason、run_id、unit_receipts、plan_checkpoint、blockers 和 recovery_path。即使原生執行使某些值為 null，這些欄位也是必需的；它們共同承載綁定來源、請求與實際的身份、回退、持久執行、每個單元的處理/整合/驗證/提交狀態、檢查點揭露、阻礙和復原路徑。恢復的回傳必須攜帶相同的 run_id；絕不將恢復視為啟動新單元或第二個 LFG 尾端的許可。

   當 behavior_change: true 時，還需要 verification_evidence，其中指名相關的單元/任務、已檢查的現有測試、新增/變更或保持不變的測試、適用的失敗或特徵證據、驗證執行，以及任何故意的測試例外。請勿在 LFG 內部決定測試策略；證據是 ce-work 的合約。同時從回傳中讀取 settled_decision_conflicts：路由為阻礙的條目會以 status: blocked 到達並停止管線；記錄任何已繼續但標記的條目——它們必須到達步驟 6 的持久殘留記錄和步驟 8 的 PR 描述上下文，因為後續審查可能不會重新發現它們。

   若 behavior_change: true 但 verification_evidence 缺失或過於模糊而無法判斷行為如何被保護，則以復原模式再呼叫 ce-work 一次。重複使用相同的 implementation_engine:<compact-json> 載體（若存在）並保持相同的計畫路徑。使用安全的非 null run_id，以第一次回傳中的確切值加上 implementation_run:<safe-id>。當 actual_route 為 native 且 run_id 為 null 時，重複原始 ce-work 呼叫一次，不帶 implementation_run: 載體；這保留了既有的原生冪等性/證據協調路徑。非原生回傳若沒有安全 run id，則保持阻塞，而非嘗試發現或第二次實作。不要提示使用者，也不要更改計畫路徑或引擎載體；這是證據協調，而非新的分派。復原依賴 ce-work 的協調路徑來檢查已實作的工作、填補缺失的證據，並在不重新實作的情況下返回。若第二次回傳仍然缺乏連貫的驗證證據，則以阻塞狀態停止，並報告缺失的欄位，而不是繼續簡化/審查/交付。

3. 對分支差異呼叫 ce-simplify-code 技能。

   此步驟在審查之前執行，以便步驟 4 的程式碼審查涵蓋簡化後的程式碼。當變更僅為文件（僅變更 markdown/文件路徑）或微不足道（大約少於 10 行變更）時，跳過此步驟。否則讓 ce-simplify-code 自行解析分支差異的範圍；它會保留行為並執行測試套件。將步驟 1 的計畫路徑作為結構固定點上下文傳遞，而非作為簡化範圍（分支差異仍是範圍），並附上一行約束：session-settled: 標記的 KTD 是簡化必須保留的結構固定點（故意的重複保持重複）。

   請勿在此步驟提交。ce-simplify-code 將其變更留在工作樹中；步驟 4 的審查範圍涵蓋工作樹（包括未提交的變更），而步驟 8 的 ce-commit-push-pr 會提交剩餘的所有內容。在此處提交會將任何仍未提交的 ce-work 編輯掃入誤導的 refactor 提交，並可能因樹從未乾淨而停滯。

4. 使用 mode:agent plan:<plan-path-from-step-1> 呼叫 ce-code-review 技能。

   傳遞步驟 1 的計畫檔案路徑，以便 ce-code-review 可以驗證需求的完整性。讀取技能發出的可操作發現摘要。同時讀取任何標記為 settled_conflict 的發現（每個都指名衝突的 KTD）。若標記發現的證據是無效的——已定決策無法運作：不可行、錯誤或破壞性——則在交付前提之前以阻塞狀態停止管線，並報告該發現。標記為偏好等級的發現則繼續進行（僅報告），但必須流入步驟 6 的殘留記錄。

   mode:agent 是僅報告的設計——它會呈現發現，但絕不編輯樹；LFG 在步驟 5 中套用符合條件的發現。在向使用者說明進度時，請將其表述為「審查發現 X → 在步驟 5 中套用 X」，而非「程式碼審查未自動修正」。僅報告的審查後接 LFG 套用的修正，是預期的合約，而非缺口。

交付前提（步驟 5–9）。 在交付步驟之前，執行一次 git remote。若其列出無遠端（例如沙盒/拋棄式簽出，僅有 git init 但無 origin），則交付僅限本地：執行以下步驟要求的所有提交，但跳過所有推送、PR 建立/編輯和 CI 監看動作——步驟 5 和 6 中的推送、步驟 8 中的推送和 PR 建立，以及完整的步驟 9。缺少遠端是終端性的僅限本地狀態，而非錯誤：絕不重試推送或尋找遠端——進行本地提交並繼續到步驟 10。當遠端存在時，正常執行步驟 5–9。

5. 套用並持久化審查修正（步驟 4 之後必要，在殘留交接之前）

   載入 references/review-followup.md 並執行其套用步驟（機械式套用 + 當有變更時提交/推送）。在符合條件的審查修正僅留在工作樹中未提交時，請勿繼續進行殘留交接、執行瀏覽器測試或輸出 DONE。

6. 自動化殘留交接（僅當步驟 4 報告了一個或多個可操作的 downstream-resolver 發現，且未在步驟 5 中套用時；當報告為 Actionable findings: none. 時跳過）

   不要提示使用者。此步驟擁抱自動駕駛合約：殘留必須在 DONE 之前變得持久，但代理絕不停止詢問。當步驟 4 發出了任何 settled_conflict 標記的發現，或步驟 2 的回傳攜帶了已繼續但標記的 settled_decision_conflicts 條目時，也執行此步驟——兩者都在套用路徑之外，但它們是分歧類別，必須在此處變得持久。

   1. 以非互動模式載入 references/tracker-defer.md。傳遞來自步驟 4/5 的可操作殘留發現（或當摘要被截斷時的執行產出物）。
   2. 收集結構化回傳：{ filed: [...], failed: [...], no_sink: [...] }。
   3. 從結構化回傳組合一個 ## Residual Review Findings Markdown 區段（這會進入步驟 4 中已提交的記錄檔案，而非 PR 主體）：
      • 對於 filed 中的每個項目：一個項目符號，包含嚴重性、檔案:行號、標題，以及追蹤器工單 URL 的連結。
      • 對於 failed 中的每個項目：一個項目符號，包含嚴重性、檔案:行號、標題，以及失敗原因（例如 Defer failed: gh returned 401 — tracker unavailable）。
      • 對於 no_sink 中的每個項目：一個項目符號，包含嚴重性、檔案:行號和標題，逐字內嵌，以便已提交的記錄檔案成為持久記錄。
      • 對於步驟 4 中每個 settled_conflict 標記的發現：一個項目符號，包含嚴重性、檔案:行號、標題，以及標記所指名的衝突 KTD——即使該發現僅供報告，也包含在內。
      • 對於步驟 2 中每個已繼續但標記的 settled_decision_conflicts 條目：一個項目符號，包含 KTD、證據，以及其路由方式。
   4. 持久記錄——絕非 PR 主體。 請勿將 ## Residual Review Findings 區段寫入 PR 描述；這會重複 GitHub 自己的追蹤，並在項目解決時過時。審查殘留沒有自己的 GitHub 討論串，因此它們透過步驟 2 中提交的追蹤器工單加上一個已提交的記錄檔案來變得持久——而非 PR 主體區段或重複工單的 PR 評論。使用組合的區段（包含工單連結）和來源執行上下文，建立/取代 <root>/residual-review-findings/<branch-or-head-sha>.md。僅暫存該檔案，提交 docs(review): record residual review findings，並在有設定遠端時推送（根據交付前提）：若上游存在，則 git push；否則若遠端存在，則解析一個可寫入的遠端（偏好 origin，否則為第一個設定的遠端）並 git push --set-upstream <remote> HEAD；若完全沒有遠端，則本地提交即為持久接收器。

   在殘留變得持久之前（追蹤器工單已提交和/或記錄檔案已提交），不要輸出 DONE。一旦記錄檔案存在，絕不因追蹤器提交失敗而阻塞 DONE。當遠端存在時，推送失敗是停止並報告；當沒有遠端時，絕不重試推送或阻塞 DONE。

7. 使用 mode:pipeline 呼叫 ce-test-browser 技能。

8. 使用 mode:pipeline branding:on 呼叫 ce-commit-push-pr 技能。將步驟 1 中記錄的計畫路徑，以及步驟 2 中任何已繼續但標記的 settled_decision_conflicts 條目，串入呼叫中，以便 PR 主體的已定決策來源行及其標記繼續條款可以觸發。

   這會提交任何剩餘變更、推送分支，並開啟拉取請求——根據模式權杖，以非互動方式進行。若它在 PR URL 之後列印 New concepts: 尾綴，則記錄概念名稱以供步驟 10 使用。一旦 PR URL 已知，將其回填到步驟 6 中提交的任何殘留工單（filed 清單）中，以便每個工單連結到承載該發現的 PR——盡力而為，絕不因工單更新失敗而阻塞 DONE。若步驟 6 已開啟 PR（使用 gh pr view --json number,url,state 2>/dev/null 檢查），則跳過 PR 建立，但仍提交並推送任何未提交的變更。根據交付前提，當沒有設定遠端時，請勿呼叫 ce-commit-push-pr——其提交步驟會無條件推送（git push -u origin HEAD），因此字面上的呼叫仍會遇到不可能的推送。請改為自行在本地提交任何剩餘變更（git add -A && git commit），並完全跳過推送和 PR 建立。

9. 透過 ce-babysit-pr 監看 PR 直到 CI 決定（僅當目前分支存在開啟的 PR 時）

   偵測 PR；若不存在或 gh 不可用，則完全跳過此步驟並繼續到步驟 10。

   gh pr view --json number,url,state
   

   呼叫 ce-babysit-pr mode:pipeline <pr-url>。它會執行有界限的管線迴圈：監看 CI，透過 ce-debug mode:pipeline 修復真正的（收斂的）失敗——絕不削弱、跳過或模擬斷言——解析透過 ce-resolve-pr-feedback mode:pipeline 到達的任何審查評論，並在 CI 決定或其預算（預設 3 輪修正）達到時停止。這取代了 LFG 先前手動的 CI 迴圈；請勿在此處重新實作 CI 監看。每當有開啟的 PR 存在時，無條件呼叫它——看起來可能乾淨的 CI 執行不是跳過 babysit 並自行輪詢 gh pr checks 的理由。某一瞬間的綠色 CI 不是此步驟的目標：babysit 也會在 PR 的生命週期中解析審查評論，因此當諮詢性檢查（例如 Bugbot）仍在等待或評論未處理時，通過的檢查不算「完成」，也絕不能取代該呼叫。

   收集其結構化結果（{ status, fixes_applied, residuals }）。它會將無法修復的 CI 作為執行報告評論發布在 PR 上，並返回殘留——請勿撰寫 ## CI Failures Unresolved PR 主體區段。needs-human 殘留（需要產品/設計決策的修正）會被延遲，而非套用——這是自動駕駛合約，保持不變。一旦 babysit 已呈現殘留，不要阻塞 DONE。

10. 完成時輸出 <promise>DONE</promise>

    對於以下兩個使用者可執行的交接，預設使用 /ce-explain <name> / /ce-babysit-pr <pr-url>。僅當活躍主機是 Codex 或明確記錄了美元符號前綴的技能呼叫時，才使用 $ce-explain <name> / $ce-babysit-pr <pr-url>。僅將呼叫渲染為行內程式碼，並僅輸出一種形式。

    若步驟 8 記錄了 New concepts: 尾綴，則先為每個概念輸出一行：New concept introduced: <name> — run <rendered ce-explain invocation> to go deeper.

    若存在開啟的 PR，則加入一行，引導使用者使用互動式監看到合併（管線模式在「CI 決定」時停止，而非「已合併」）：PR is moving — run <rendered ce-babysit-pr invocation> to watch it through review to merge.

    在 DONE 承諾之前，檢查步驟 1 的正式計畫中是否有語義角色 work-relationships。當該角色存在時，載入 references/next-work-handoff.md；或者當較舊的未標記產品合約似乎指名了此計畫擁有的領域加上未來單獨規劃的領域及其關係時，也載入；該參考文件擁有謹慎的舊版語義回退、候選選擇和選擇加入提供合約。不要匹配確切的可見標題，不要將普通的非目標視為未來工作，也不要在使用者明確接受提供之前呼叫 ce-handoff。若兩個語義訊號都不存在，則不要載入參考文件，也不提供下一步工作。

    然後輸出 DONE 承諾。

現在從步驟 1 開始。記住：先規劃，再實作。絕不跳過規劃。