n0ctx/dag-engineering

DAG Engineering

把較大的工程任務拆成有依賴關係的子任務（節點），每個節點由子代理在自己的 worktree 和分支裡實現，主代理在整合 worktree 中逐個合併驗收。返修也遵守這項隔離，子代理不進入整合 worktree 修改或提交。主代理負責調查規劃、派發、整合、返修安排和最終驗收；調查子代理唯讀回答具體問題；節點子代理先按 refine 細化，再實現並提交單個節點；審查子代理唯讀審查。

調查深度、子代理數量和驗證範圍按任務實際複雜度決定；沒有獨立工作時不為使用子代理而拆分。

Codex 派發任何子代理時顯式設定 fork_turns="none"。

0. 繼續已有 plan

開始前查看主工作區的 .dag/。存在「plan 狀態：進行中」的 plan 時，讀取它，結合 Git 實際狀態從當前進度繼續，不重新拆分。plan 與 Git 不一致時，以核實後的程式碼狀態修正 plan。

1. 整合 worktree 存在 MERGE_HEAD（git -C <整合wt> rev-parse -q --verify MERGE_HEAD）：整合中斷，驗證結果未知，執行 git merge --abort 後把該節點按 submitted 重新整合。
2. 逐個核對節點：
   • done：確認節點提交已合入整合分支（git -C <整合wt> merge-base --is-ancestor <提交> HEAD），不重複執行。
   • submitted：節點提交已合入整合分支時，直接標為 done（合併提交只在驗證通過後產生）；否則按第 6 步整合。
   • running：本會話中代理仍在執行就繼續等待。代理已不存在時，查看節點 worktree 的提交和未提交改動，派新代理在同一 worktree 從現有成果繼續，不新建 worktree。
   • blocked：讀取原因，判斷條件是否已經解除。
   • pending：按第 5 步排程。節點還是舊寫法（目標、範圍、步驟、驗收、驗證）時，派發前改寫成第 4 步的範本。
3. 所有節點都已 done：從第 7 步繼續。

狀態不明時不刪除 worktree、分支或未提交改動。

1. 開整合 worktree

每個 DAG 開一個整合 worktree 和分支，只由主代理寫入，主工作區不改動。

git worktree add "../<repo>-<plan-id>" -b "dag/<plan-id>"

• <plan-id> 用簡短的 kebab-case 描述本次工作；分支或目錄已存在時換一個名字。
• 主工作區有未提交改動時，告訴使用者這些改動不會進入 worktree，由使用者決定先提交還是繼續。
• 驗證命令依賴安裝步驟（如 node_modules、虛擬環境）時，先在整合 worktree 完成安裝。
• 記下起點提交（git rev-parse HEAD），整體審查以它為基準。

2. 調查與關鍵設計

順序：需求分析 → 定向程式碼調查 → 統一關鍵設計。

主代理先根據需求定位現有實現、相關模組、呼叫關係和測試，列出影響規劃的未知問題。歧義會改變目標、範圍或驗收標準時，先問使用者；其餘不確定項寫進 plan 的「假設」。

存在多個相互獨立的調查問題時，在同一條訊息裡派發唯讀調查子代理並行調查；問題少或相互依賴時主代理自己查。調查按具體問題劃分（已有實現與複用、關鍵介面與呼叫鏈、共享狀態與外部資源、測試與工程約束等），不按目錄機械劃分。調查子代理直接讀整合 worktree，不需要自己的 worktree。指令寫明：

唯讀調查 <整合wt>，不修改任何檔案，不派發其他代理。目標：<…>。範圍：<…>。需要回答：<問題列表>。問題回答完即停止，不做範圍外的探索。只彙報：關鍵事實及位置（檔案:符號）、可複用的現有實現、工程約束、未能確認的事項；區分確認的事實和推測。

主代理整合結果，處理相互矛盾的結論，只對影響規劃的缺口補查。事實足以寫出節點的 goal、scope、verify 和 stop 時就停止調查；steps 的細節留給節點子代理開工時細化（第 5 步）。規劃時的調查只到能定節點邊界的深度：用結構查詢（檔案與行數、呼叫關係、依賴邊、清單條目）回答，不讀函式實現；讀懂實現是節點子代理的事。

跨模組事實（某個符號被誰呼叫、某個模組依賴什麼、一組檔案連同依賴有多大）用語言伺服器、ast-grep 或搜尋按需查，不整份讀原始碼推導；查到一次就記下複用：主代理或調查子代理查到的，寫進相關節點的 refine 結果或 note；節點子代理在彙報裡列出新發現的跨節點事實，主代理記進會用到它的下游節點的 refine。下游開工時先看這些記錄，記錄不足或可能已過時（相關程式碼已被後續節點改動）再重查。

然後確定並寫進 plan 的「關鍵設計」：

• 目標行為和非目標；
• 直接複用的已有實現、依賴或平台能力；
• 功能及程式碼的歸屬；
• 跨節點必須一致的介面、資料結構和架構約束；
• 共享資源和整合條件。

只固定跨節點協作必需的設計，節點內部實現留給節點子代理。不為未來需求增加抽象，不重複實現已有能力。

3. 拆分 DAG

• 節點粒度：以一個可獨立驗收的行為為單位，包含使它可執行、可驗證的必要接入。設定、腳手架、文件只有一個節點使用時併入該節點，多個節點使用時提成一個上游節點。高耦合、拆開會產生無法驗證的中間狀態或大量重複修改的工作合併成一個節點；低耦合的工作拆開以便並行。不為增加並行度強行拆分。
• 逐項核對：節點需要覆蓋大量檔案或條目時，先明確核對項和逐項驗收標準；可獨立核對的範圍交給唯讀子代理並行處理，彙總缺口後再實施。已有核查結論仍有效時直接複用，不重複掃描。
• 依賴：只有下游真正需要上游的程式碼、決定或已驗證的行為，或者上游失敗會讓下游作廢時，才寫依賴。共享介面已在關鍵設計中確定、雙方能各自實現和測試時，不寫依賴，允許並行，由整合驗證檢查真實對接。不為控制順序編造依賴。
• 衝突：沒有依賴但不能安全同時執行的節點才標衝突：邏輯上互相影響的修改，資料庫、埠等共享執行資源，遷移序號等必須串行分配的資源。同一檔案的普通修改重疊不算衝突，允許並行，由 Git 合併處理；只有重疊集中、合併成本明顯高於串行時才標衝突。
• 仍需實驗才能確定的方案：建一個調查節點產出結論，下游依賴它。

每個節點按第 4 步的範本寫。規劃時寫 goal、scope、verify、stop、refine；steps 由節點子代理開工時按 refine 細化（第 5 步），規劃時已能確定的步驟可以先寫。

• goal：一兩句，做完後什麼行為成立。
• scope：允許修改的檔案或目錄、明確不許改的部分，以及必須遵守的關鍵設計和業務約束。
• verify：可觀察的驗收結果，以及能直接執行的真實命令，包含受本節點改動影響的現有守衛，如文件體量、程式碼複雜度、分層和契約檢查。優先使用窄入口；沒有窄入口才執行完整檢查，完整檢查不與其他驗證並發。
• stop：本節點特有的停下彙報條件，如「歸屬按規則判不出」「某介面不存在」。通用條件已在派發指令裡，不重複寫。
• refine：寫出 steps 需要查清的事項，寫成可執行的查詢，如「列出 X 字首下的全部條目及其依賴的未處理模組」「列出 Y 的全部呼叫方」。由節點子代理在開工第一段完成。規劃或調查時已經查到的結論直接寫在 refine 裡並標明已查，子代理直接用，不重查；refine 只把尚未回答的項留作查詢。沒有待查事項寫「無」。
• steps：有序步驟，每條只做一件可核對的事，寫到模組、命令、介面一級：做什麼、落在哪、對外行為是什麼。函式一級只在邊界處寫：同一檔案要分給不同節點，或某個函式的歸屬有爭議時，列出邊界兩側各有哪些函式。

來源材料和關鍵設計已經確定的值、條件、邊界，直接寫進相關節點，不留給子代理推導。檔案、符號和命令必須來自實際程式碼，不得編造。以下寫法要改掉：

• 「酌情實現」「處理邊界情況」這類不可執行的描述；
• 驗收標準只複述實現動作，如「實現了 X」；
• 行為類驗收只靠檔案存在、能匯入或關鍵字搜尋來證明；
• 分類或取捨只引用規則名、文件章節（如「按 D7 判」），不寫預設動作和例外條件。

派發前檢查 plan，回答兩組問題。

**計劃全部完成後，全域驗收標準是否必然達成。**按以下各項找缺口：

1. 範圍從實際來源列舉，不只從需求推：涉及的程式碼、設定、版本庫外的檔案與本機狀態、安裝與部署方式、其他執行平台、外部呼叫方。每一項恰好歸一個節點，或寫進非目標。
2. 每條驗證都成立：能在目標環境執行；執行時不寫生產資料或外部系統，確需寫入的節點寫明隔離方式；通過即能推出對應的驗收結論；驗證所用的工具本身已被驗證。
3. 計劃引入的臨時豁免、相容層、過渡資料和工具，都有節點負責撤除或轉正。
4. 寫外部系統、切換生產環境、只在其他平台執行的路徑，交付前至少有一個節點在真實環境實際執行一次。
5. 節點之間介面與架構一致；依賴、衝突沒有錯誤或遺漏；節點之間的整合有節點負責；每個節點的 refine 能查出 steps，verify 都能執行。

缺口補成節點。補不了，或補上的代價需要使用者取捨時，寫進 plan 的「完成度缺口」，交使用者決定。

設計是否浪費時間。

6. 每個節點的產出都有下游使用者，驗證也算；沒有使用者的節點刪掉。
7. 需要使用者決定或在場、會改變既有行為的節點，不讓其他節點等它；有下游必須等它時，拆成不改行為的部分（先做）和改行為的部分（後做）。
8. 兩個以上節點要用的同一能力或工具，提成一個上游節點，不讓各節點各做一遍。逐個節點確認它的 verify 靠什麼證明；兩個以上節點要用同一種驗證手段（新舊對照、重放、產物比對等）時，也提成上游工具節點，該節點的 verify 包含用一個已知有差異的樣本證明工具能報出差異。兩個以上節點要反覆查同一份大型資料（清單、對映表、決策文件），而專案沒有按需查詢的入口時，也提一個上游節點補上查詢入口。
9. 估出每個節點需要讀懂和修改的量（按 scope 內檔案加它依賴的、尚未處理的程式碼計算）。量大到一個子代理難以穩妥完成，或橫跨互不相關、能各自獨立驗收的模組時，拆開；內聚緊、拆開會產生無法驗證的中間狀態的，量大也不拆。行數只是判斷依據，不設固定閾值。估不出的，把要算的內容寫進 refine，由節點子代理開工第一段估算；拆法要在建 worktree 前定時，按第 5 步先派調查子代理估算。
10. 沒有重複實現已有能力，沒有不必要的拆分或過度設計，可以安全並行的節點沒有被串行。

節點不超過 5 個時由主代理檢查。超過 5 個時，先把草稿按第 4 步寫到 .dag/<plan-id>.md，再派一個唯讀子代理審查，只給它 plan、需求和程式碼位置，不給主代理的推理過程：

唯讀審查 <plan 路徑>，不修改任何檔案，不派發其他代理。需求：<原始需求或其位置>。程式碼：<整合wt>。按以下各項逐條檢查：<上面 1–10 項原文>。只彙報：完成目標的缺口、浪費時間的設計、需要使用者決定的事項；每條寫位置、證據（檔案:符號、命令輸出或 plan 原文）和最小修改建議，區分確定的問題和推測。

主代理只修改有具體證據的問題。

4. 儲存 plan

寫到主工作區的 .dag/<plan-id>.md，不放進任何 worktree，避免被提交。.dag/ 未被 Git 忽略時，把它加到 .git/info/exclude。

# <plan-id>

- 目標：
- 全域驗收標準：
- 非目標：
- 假設：
- 完成度缺口：<計劃做完仍不能保證達成的部分，及使用者的決定；沒有寫「無」>
- 關鍵設計：
- plan 狀態：進行中
- 整合 worktree：<路徑>  分支：dag/<plan-id>  起點：<sha>
- 介面記錄：`.dag/<plan-id>-interfaces.md`

## 節點

### N1 <標題>
#### goal
#### scope
#### steps
<節點子代理開工時細化>
#### verify
#### stop
#### refine
#### state
- 依賴：無
- 衝突：無
- 狀態：pending
- worktree：  分支：  提交：

## 執行記錄
- N1：<合併提交 sha> <一句話結果>。<返修、異常或遺留問題；沒有不寫>

介面記錄檔案與 plan 放在一起，每個節點合入時追加一節，節點子代理可以唯讀它：

## N1（<合併提交 sha>）
- <介面、命名與位置>：<形狀與用法>

執行記錄只寫結果和遺留；對外介面寫進介面記錄檔案，跨節點事實寫進會用到它的下游節點的 refine，對照差異等細節留在節點的提交說明和彙報檔案裡。

goal 到 refine 都傳給節點子代理；state 只供主代理使用。

狀態取值：

• pending：未派發；
• running：子代理正在實現或返修；
• submitted：子代理已提交，等待整合；
• done：已合入整合分支並通過主代理驗收；
• blocked：無法繼續，原因寫進執行記錄。

plan 只由主代理修改。每次狀態變化都立即更新，它是跨會話繼續工作的依據。

儲存後向使用者簡要展示節點、依賴、可並行的節點、完成度缺口，以及全部需要使用者決定的事項（一次列全，不分輪詢問）。使用者只要求出計劃時在這裡停下；否則繼續執行。

5. 動態派發

依賴全部 done、且與 running/submitted 節點沒有衝突的 pending 節點即為就緒節點。找出全部就緒節點，在同一條訊息裡並行派發，不設固定的並發上限，實際並發以代理工具和環境允許為準。之後每有節點 done，立即重新找就緒節點並派發，不等待其他獨立節點結束。

派發每個節點前，主代理只做前置核對：列出本節點用到的上游決定、介面、命名和規則，確認都已合入整合分支 HEAD。其中某項還會被 running 或 pending 的節點改變時，給本節點補上依賴，暫不派發。

refine 裡的查詢由節點子代理在開工第一段完成，主代理不自己跑。以下兩種情況例外，先按第 2 步派唯讀調查子代理，只收結論：

• 節點可能要拆成可並行的多個節點，拆法要在建 worktree 前定：調查子代理按 refine 估算體量與耦合，主代理按第 3 步第 9 項拆分後再分別派發。
• 幾個就緒節點要查同一個問題：派一個調查子代理一起回答，不一個節點派一個。

然後從整合分支當前 HEAD（最新已驗收的整合提交）建立節點 worktree，把路徑、分支寫進 plan 並標為 running：

git -C <整合wt> worktree add "../<repo>-<plan-id>-<node-id>" -b "dag-node/<plan-id>/<node-id>" HEAD

驗證依賴安裝步驟時，在指令中要求節點子代理先在自己的 worktree 完成安裝。

給節點子代理的指令按以下順序組織，只包含這些內容：

1. worktree 路徑和分支。
2. 該節點 plan 中 goal、scope、steps（已有時）、verify、stop、refine 的原文。
3. note（只寫在指令裡，不寫進 plan）：
   • 介面記錄檔案的絕對路徑，只給路徑，不在指令裡複述上游介面。
   • 本節點特有的補充：主代理定的邊界與取捨、使用者決定的原文、只與本節點相關的上游事實、已知的坑、查資料用的命令。一般不超過約 20 行；資料超過約 200 行或只用到其中一部分時，給摘錄或查詢命令，不只給檔案路徑；專案說明檔案會被子代理自動載入，其中已寫的規則不重複；verify 中輸出很長的命令，寫明看哪一部分（如結尾的彙總行）。
   • 彙報檔案路徑：.dag/<plan-id>-reports/<node-id>.md（主工作區的絕對路徑）。
4. 以下要求，放在指令最後：

只在給定 worktree 內工作，不操作整合分支、其他節點的分支或 worktree，不派發其他代理。除指令給出的彙報檔案外，不修改 .dag/ 下的檔案；除介面記錄檔案外，不讀 .dag/ 下的檔案。專案說明檔案裡寫給主會話的開工、收工步驟（讀計劃、跑狀態檢查、恢復 plan 等）不適用於你。查資料先用 note 給出的命令和摘錄，note 沒覆蓋的再自己查；不整份閱讀 plan、決策文件或大型清單。

分兩段工作。第一段：按 refine 查清事實（refine 裡標明已查的結論直接用，只查尚未回答的項），在不改變 goal、介面和 scope 的前提下定出 steps（寫到模組、命令、介面一級；同一檔案要與其他節點分開時列出邊界兩側的函式），估算需要讀懂和修改的量。出現以下任一情況時停下，回一份不超過約 30 行的摘要（steps 草稿、估算量、建議的拆法、需要主代理或使用者決定的事項）等待答覆：邊界或歸屬判不出；需要改變跨節點介面或修改 scope 外的檔案；實際程式碼與節點描述衝突；量大到一個子代理難以穩妥完成，或橫跨能各自獨立驗收的模組；出現 stop 中列出的情況。都沒有時不停，直接進入第二段，摘要放進最終彙報。

第二段：按 steps 實現，在不改變 goal、介面和 scope 的前提下自行決定局部實現方式。執行 verify 中的命令，通過後提交本節點的全部改動，提交訊息為 <plan-id>/<節點>: <摘要>，確認 git status 乾淨。驗證未通過時不提交。第二段中出現第一段列出的停下情況，或實際量超過第一段估算的約兩倍，停下彙報，不要自行擴展；已完成的部分能通過 verify 中適用的命令就先提交，不能就保留在 worktree 不提交，彙報裡列出已完成和剩餘的工作。

結束或停下時，把完整彙報（改動摘要、驗證命令及完整結果、對照差異、偏差說明）寫進彙報檔案，只回給主代理不超過約 40 行：狀態（DONE：完成且驗證通過；DONE_WITH_CONCERNS：完成但有疑慮；BLOCKED：無法完成或停下）、提交 sha、驗證結果一行、對外介面的新增或改變、新發現的跨節點事實（如某個符號還被哪些模組使用、某個介面實際的形狀）、疑慮或阻塞原因、需要決定的事項。

子代理第一段停下回摘要時，主代理核對邊界和需要決定的事項（需要使用者決定的先問使用者），把確認的 steps 寫回 plan，再用代理工具的續接能力（Claude Code 的 SendMessage；Codex 向同一代理傳送後續輸入）讓同一個子代理繼續第二段，不新派代理，避免重讀它已讀過的程式碼。建議拆分時，按第 6 步「plan 本身有誤」的規則拆：原子代理繼續其中一部分，其餘部分作為新節點從第 5 步派發。原代理無法續接時，派新代理在同一 worktree 繼續，並附上摘要。

子代理返回提交後，把提交 sha 寫進 plan，標為 submitted，進入第 6 步。

等待規則（調查、審查子代理同樣適用）：

• 有具體且不與子代理範圍衝突的獨立工作（如整合已提交的節點）時，先完成它；沒有時進入原生等待。
• Claude Code 使用後臺代理的完成通知或原生等待。Codex 直接呼叫代理工具，不放入 functions.exec 或 functions.wait；wait_agent 設定 timeout_ms=600000，若工具引數不支援該值，使用允許的最長等待。工具只能批次返回結果時按其能力處理，不模擬不存在的通知。
• 不用迴圈短暫 sleep、查詢代理列表或重複檢視 Git 狀態代替等待，也不為傳送進度更新而縮短等待。
• 收到結果或使用者訊息後立即處理。僅等待逾時不代表失敗，繼續等待，不重新派發仍在執行的節點。

6. 逐節點整合驗收

主代理在整合 worktree 中一次整合一個 submitted 節點，其他子代理繼續工作。不直接採信子代理的彙報：

1. git -C <整合wt> diff --stat HEAD...<節點分支>：改動的檔案都在節點 scope 內；節點 worktree 的 git status 沒有遺留的未提交改動。再看與其他節點共用的檔案（公共模組、設定、守衛基線、清單、契約測試）的完整 diff，確認符合 goal 和關鍵設計。節點自有的新程式碼靠第 3 步的驗證和實測行為判斷，不逐行閱讀；需要細節時讀彙報檔案裡相關的段落。
2. 合併但先不提交：

   git -C <整合wt> merge --no-ff --no-commit "dag-node/<plan-id>/<node-id>"
   

3. 在整合 worktree 執行該節點 verify 中的命令，以及受合併影響的整合檢查；對照 verify 的驗收結果逐條核對，至少實際驗證一條行為。受影響守衛的新增失敗在本節點修復，不留到最終驗收；已有失敗單獨記錄，不放寬閾值或基線。不要求每次都跑完整測試套件。
4. 全部通過：git -C <整合wt> commit --no-edit，節點標為 done，寫一行執行記錄，把對外介面追加進介面記錄檔案，把跨節點事實寫進會用到它的下游節點的 refine，然後回到第 5 步派發新解鎖的節點。

清單覆蓋類驗收須逐項記錄已核實的結論、待核實項和缺口。只有全部宣告範圍已核實並滿足驗收標準，才能標為 done；檔案存在、正文非空或抽樣通過不能代替逐項覆蓋。

合併出現衝突時，雙方意圖清楚的普通重疊由主代理直接解決，再執行第 3 步。

其餘衝突或檢查未通過時，撤銷未完成的合併（git -C <整合wt> merge --abort），整合分支保持在上一個已驗收提交，節點提交保留在節點分支上。按問題歸屬處理：

• 節點實現缺陷：節點標回 running，把具體問題交回原節點子代理在原 worktree 修復後重新提交；原代理不可續接時，派新代理在同一 worktree 繼續。主代理不預設親自重寫節點實現。
• 需要節點參考最新整合成果的衝突：讓節點子代理在自己的 worktree 合併 dag/<plan-id> 後解決衝突、重新驗證並提交。
• 跨節點介面或邏輯衝突：主代理確定正確設計，更新 plan 的關鍵設計和相關節點，再交給相關節點子代理調整。
• plan 本身有誤（scope、steps、依賴或 verify 與實際程式碼不符）：根據新發現的程式碼事實只修改受影響的節點、依賴和驗收，保留有效的已完成成果，不重新設計整個 DAG。修改涉及全域驗收標準或非目標時，先問使用者。
• 子代理彙報 DONE_WITH_CONCERNS：疑慮影響驗收標準時按未通過處理；否則照常整合，把疑慮寫進執行記錄。
• 子代理因實際量超出估算而停下：已提交的部分能獨立驗收時，把本節點的 goal、scope、verify 改成已完成的部分，按本步整合；剩餘工作按「plan 本身有誤」拆成新節點，從第 5 步派發。已提交部分不能獨立驗收時，不整合，節點保持 running，把剩餘工作寫進該節點的 steps，派新代理在同一 worktree 從現有成果繼續。
• 子代理彙報 BLOCKED 或節點無法繼續：標為 blocked 並記錄具體原因，依賴它的節點不派發，其他節點繼續。沒有就緒或執行中的節點、但仍有 blocked 節點時，停下向使用者報告阻塞原因，等使用者決定後再繼續；不進入第 7 步。

節點 done 後清理它的 worktree 和分支。worktree 有未提交改動時停下檢查，不使用 --force 或 -D：

git -C <節點wt> status --porcelain
git -C <整合wt> worktree remove "<節點wt>"
git -C <整合wt> branch -d "dag-node/<plan-id>/<node-id>"

blocked、返修中或狀態不明的節點保留 worktree 和分支。

7. 整體審查

所有節點都 done 後，派一個唯讀子代理審查整合分支的完整改動：

唯讀審查 <整合wt> 中 <起點sha>..HEAD 的全部改動，不修改任何檔案，不派發其他代理。對照以下目標、全域驗收標準和非目標檢查：需求覆蓋、跨節點介面和行為的一致性、重複實現、偏離關鍵設計的架構、正確性缺陷、遺留的偵錯或臨時程式碼、重要測試是否缺失或沒有真正覆蓋聲稱的行為。每個問題給出位置、證據和涉及的節點，區分確定的問題和推測；另列需要使用者決定的事項。

指令中附上 plan 的目標、全域驗收標準、非目標和關鍵設計。

主代理核實每個問題後按歸屬安排修復：需要實現的問題作為修復節點（如 F1）寫進 plan，按第 5–6 步派發和整合；區域性且明顯的小問題（如遺留的偵錯語句）主代理可以直接在整合 worktree 修改並提交。需要使用者決定的事項不自行決定，寫進報告。

8. 最終驗收並報告

主代理在整合 worktree 完成以下檢查：

1. 檢視 <起點sha>..HEAD 的完整 diff，確認沒有超出 plan 目標的改動。
2. 執行所有節點的驗證命令，以及專案中覆蓋改動模組的測試、建置和 lint 命令。
3. 逐條核對全域驗收標準。

檢查失敗時：問題在 plan 目標內，按第 7 步的歸屬規則修復後重新檢查；問題不在 plan 目標內（如起點就已失敗的測試），不修復，寫進報告。全部完成後把「plan 狀態」改為「已完成」。

最終報告包括：完成的節點和對應合併提交、審查發現和處理、驗證結果、未完成或有風險的事項、需要使用者決定的事項、整合 worktree 路徑和分支、保留的節點 worktree。合併到目標分支和刪除整合 worktree 只在使用者要求時進行。