交付輸送帶規則
此專案在 GSD 之上運行按工單的交付輸送帶（參閱 docs/gsd_multilevel_delivery_pipeline.md）。計劃同時充當工單；這些規則使其保持可由輸送帶的確定性層機器消費。
語言。 所有成品 — 計劃、前置資料、提交、程式碼、PR 主體 — 均以英文撰寫。當直接與使用者溝通時，使用使用者的語言回覆；成品使用英文，對話使用使用者的語言。
給規劃者（撰寫 PLAN.md）
-
始終使用完整的前置資料：
phase、plan、title、type、wave、depends_on: []、files_modified: []、requirements: []。空的requirements是阻塞器 — GSD 的計劃檢查器和閘門 2（validate-graph）都會拒絕；請參考 ROADMAP 需求 ID，或當計劃是從外部匯入時使用外部追蹤器 ID。wave是給人類讀者的文件：圖形是權威的，驗證器會重新計算真實的依賴深度，並在您的值不一致時發出警告。保持真實而非裝飾性。 -
交付區塊（僅附加，絕不取代 GSD 欄位）：
delivery: ticket: T-<phase>-<plan> risk: low|medium|high # high 需要 human_checkpoint: true human_checkpoint: false repo: owner/name # 僅當工作位於另一個儲存庫時使用repo對於任何不觸及此儲存庫的工單是強制的。 省略它會導致輸送帶針對錯誤的儲存庫追蹤該工單：其 PR 可能在隔壁合併並通過測試，而看板始終顯示pending，並且每個依賴項都卡在一個永遠不會移動的工單後面。files_modified中的路徑隨後相對於該儲存庫 — 絕不應使用../other-repo/x.ts，因為沒有工作樹可以到達（閘門 2 會警告，狀態同步會暫停工單）。跨儲存庫的依賴項不會級聯：父項必須先合併，因此將合約端（類型/工具名稱）切片到自己的工單中，而不是讓消費者等待完整功能。 -
不要發明分支名稱。 規範分支是
ticket/<ID>-<slug>，其中 slug 是經過清理的工單標題（小寫、音譯、非字母數字摺疊為單個連字號，≤40 個字元）。省略delivery.branch— 圖形驗證器會生成它；顯式值會根據相同規則進行驗證。 -
files_modified 是合約，不是猜測 — 列出計劃觸及的每個路徑。空的
files_modified會使閘門 2 失敗（這是使「依賴無序工單永不衝突」可檢查的基礎，也是執行者的範圍）。依賴無序且路徑重疊的計劃也會使閘門 2 失敗；通過依賴項或重新切片解決，絕不要通過擴充套件 glob（匹配所有內容的裸 glob 會被標記）。 -
在計劃編寫之前，命名已經執行此操作的內容。 每個計劃的 Context 讀取必須指向工單擴充套件的現有實現（
path:line— 它基於的轉換器、排序器、中介軟體、輔助函式、端點），或記錄未找到的檢查：您搜尋了哪種行為以及您查看過的兩個或三個合理位置。按行為搜尋，而不是按您打算給新程式碼的名稱 — 重複項幾乎總是以其他名稱存在，這正是它通過審查的原因。「我沒有看到」與「我找過」不是同一陳述；只有後者是讀者可以信任的計劃。這是輸送帶中最便宜的閘門：未被注意的重複項會被整合器在整整一個階段後發現，此時其他工單已經基於它構建，而到那時移除它本身就是一個工單。與 §4 不同，這無法從前置資料中通過機器檢查 — 閘門 2 從未看到它，漂移檢查僅對其重新判斷的工單提供備份，因此將其寫下是控制手段。 -
驗證命令的範圍限定於工單，而非專案。 撰寫實際上涵蓋
files_modified的最窄命令 — 特定的測試檔案或過濾器、對觸及路徑的型別檢查和 lint。裸的npm test/make test/ 整個 e2e 套件在此不是驗證命令：它屬於 CI，CI 在專為其構建的硬體上每次推送執行一次。執行者在每次嘗試時執行這些命令，修復角色在每輪重新執行它們，因此未限定範圍的命令不僅慢一次 — 它是整個輸送帶的滴答速率，乘以每個工單在其自己的工作樹中並行執行。兩個屬性使命令可用：它必須在沒有外部服務的裸工作樹中執行，並且它必須因該工單的錯誤而失敗。無法限定範圍的命令（需要實時資料庫、瀏覽器、部署環境的套件）是僅限 CI 的檢查 — 在 Test strategy 下說明，並將其排除在 Verification commands 之外，而不是交給執行者一個無法執行的東西。 -
depends_on驅動級聯，而不僅僅是排序。 在史詩堆疊交付（預設）下，根工單（空的depends_on）的 PR 進入階段史詩分支；依賴工單則級聯 — 它 PR 到其主要父項的分支，而不等待合併，因此流程永不阻塞。精確宣告依賴項：虛假的依賴項會序列化流程，缺少的依賴項則會給執行者一個不完整的基礎。驗證器推匯出史詩（epic/<phase-dir>）、主要父項和pr_base；多個同階段父項（菱形）會收到警告 — 在可行的情況下線性化。保持依賴項在一個階段內。 跨階段的依賴項無法級聯 — 沒有共享分支可堆疊 — 因此依賴工單保持阻塞，直到父項的整個階段已合併到預設分支。驗證器會對每個此類依賴項發出警告；改為重新切片。 -
ID 是規範的：
T-<2 位數階段>-<2 位數計劃>。撰寫T-01-02，絕不寫T-1-2— 驗證器會正規化兩者，但分支、PR 標題和 Jira 標籤在其他所有地方都是進行字串比較。 -
值結尾不要有
#註釋。 將註釋放在單獨一行。files_modified: [a.ts] # note過去會將註釋摺疊到最後一個路徑中；解析器現在正確地將其剝離，但閘門 2 仍然拒絕任何包含#的值，因為這幾乎總是洩漏。 -
閘門 2 是機械的：僅當圖形驗證器以退出碼 0 結束時才通過。Jira/GitHub 問題、ROLLOUT.md 或散文摘要絕不能替代具體化的 PLAN 檔案。
-
Jira 是投影，不是真相來源。 預設情況下（除非
pipeline.jira.enabled: false或未連線 Jira MCP），decompose 在閘門 2 之後將驗證後的圖形匯出到 Jira（每個階段一個史詩，每個工單一個問題）並使用英文 — 絕不在此之前，也絕不替代。專案會自動解析並快取；Jira 失敗不得阻塞分解；PLAN 檔案保持規範。
給執行者（實現工單）
- 保持在
files_modified內部。 範圍外的更改屬於另一個工單 — 請升級而非默默擴充套件範圍。 - 在編寫新實現之前，閱讀現有實現。 無論計劃在 §5 下命名了什麼，再加上輸送帶從漂移檢查傳遞給您的任何
reuse_candidates：首先閱讀每個候選項，然後擴充套件它，而不是在其旁邊新增一個並行層。如果候選項確實不合適，請在您的證據中說明原因 — 這是合法的結果，但默默忽略則不是。重用絕不允許離開files_modified：如果基於它構建會使您超出範圍，則這是範圍外的升級（§1），而不是更廣泛的差異。 - 原子提交 以工單 ID 為字首：
feat(T-01-02): …。 - 在宣告完成之前，在本地執行計劃的 Verification commands 直到通過；從不宣稱驗證而沒有命令輸出。執行那些命令 — 不要通過將它們擴充套件到整個套件來「徹底」（§6）：CI 擁有完整執行，您在這裡啟動的套件會阻塞您自己的工作樹和與您共享機器的每個其他執行者。如果計劃的命令已損壞或明顯不涵蓋更改，請在計劃中修復或縮小它們，並在您的證據中說明；默默替換為
npm test不是修復。 - 工作樹和分支來自輸送帶（
tickets.json） — 不要特別建立分支或工作樹。您的 PR 基礎同樣由輸送帶解析（delivery-state.json→base：根工單的史詩分支，依賴工單的父分支） — 在史詩堆疊下，絕不直接向 main/master 開啟 PR。 - 在提交處停止。 不要
push，不要開啟拉取請求，不要觸及審查者。編排器在釋出任何內容之前機械地驗證工作樹（git log <base>..HEAD） — 該檢查會捕獲「代理報告成功但更改了任何內容」，並且僅當釋出不在被檢查代理手中時才有效。請交回您的驗證證據和 PR 主體。