CovD831/重新架構開發工作流程

重新架構開發工作流程 是做什麼的？

使用此技能將架構重新設計轉化為可開發的套件。 產出不僅僅是一張圖表：它是一份關於將建構什麼、如何遷移、如何測試以及哪些部分仍不受支援的限定合約。 將重新架構視為一個持續的遷移計劃。每個套件是一個可審查的交付增量，而不是承諾規範或實現整個未來系統。

運作原則

1. 區分權威與意圖。 首先閱讀當前程式碼、測試、架構權威文件和儲存庫說明。將重新設計文件標記為目標、計劃或證據；切勿將其表述為當前行為。
2. 命名現有事物。 將每個提議的模組映射到當前的類別、合約、註冊表、儲存庫或進入點。不要用發明的新名詞隱藏現有內容。
3. 明確所有權。 說明每個邊界擁有什麼、不擁有什麼，誰寫入持久性事實，誰授權變更，以及誰負責復原。
4. 從真實消費者中獲得抽象。 只有在真實消費者移除了命名依賴、統一了真實註冊或使不變量可強制執行時，才承認新的抽象。一般抽象需要兩個消費者；狹義的安全邊界可能只為一個消費者承認。
5. 從真實的垂直切片開始。 保留一個舊有測試用例，並為相同場景添加一個目標邊界測試用例。合成的圖表可以測試機制，但無法證明架構。
6. 在替換前凍結合約。 在移除具體依賴之前，定義輸入、輸出、授權、身分、冪等性、失敗、持久化、復原和相容性。
7. 將效能視為證據，而非理由。 優先保留權威、持久相容性和復原；然後針對當前路徑測量等效工作負載。
8. 保持文件可維護。 每個聲明指定一個規範所有者，保持當前/目標/歷史狀態的可見性，並連結到策略，而不是跨文件複製。
9. 規劃連續交付。 每個增量陳述可交付成果、延遲事項、下一個推進觸發條件以及所需的晉升證據。

工作流程與模組載入

第一級 (L1) 代表系統邊界，第二級 (L2) 代表穩定的模組/邊界合約，第三級 (L3) 代表特定任務的實作細節。將專案現有的標籤映射到這些含義，而不是引入第二個分類法。

首先確定合適的規模。閱讀 references/deliverable-matrix.md 並選擇最小的、能讓下一個決策可審查的套件。以下階段是完整路徑，而非每個請求和強制檢查清單。僅在對應階段或關注點活躍時才載入其他參考文件。

每個套件或遷移增量必須宣告交付範圍。交付矩陣擁有其 schema、僅設計的縮減、延遲事項和推進條件。

階段 0 — 解析權威與基線

• 閱讀儲存庫說明、README、開發指南和架構權威文件（如果存在）。
• 在得出沒有更早的重新架構計劃存在的結論之前，搜尋方向、文件、發行、遷移、任務和交接記錄。
• 針對與請求相關的每個活躍計劃，在定義新範圍之前，閱讀其最新的增量記錄、審查決策、未解決的延遲事項、開放的 L1/L2 聲明、ADR 以及記錄的下一個任務。
• 驗證先前的推進觸發條件和晉升證據。如果其中任一項未滿足，或存在未解決的阻塞性發現，請先向使用者呈現狀態和選項，然後再繼續。如果使用者授權例外，請在當前增量記錄中記錄原因、核准者和受影響的範圍。
• 識別原始碼層級結構和確切的基線版本。檢查當前的進入點、狀態/資料擁有者、持久化、測試、範例和擴展註冊表（如果存在）。
• 記錄哪些已實現、哪些是目標意圖以及哪些是未知的。
• 在聲稱降低耦合性之前，建立一個可重現的依賴性或註冊庫存：一個可重複執行的命令/腳本、已檢查的輸出或報告，以及用於前後比較的相同方法。

遵循儲存庫現有的任務帳本、問題系統和交接格式。不要要求特定的協作工具，也不要將對話歷史用作架構權威。

階段 1 — 定位與範圍

記錄：

• 系統是什麼以及誰在其上建構；
• 當前耦合或成長引起的問題；
• 第一階段的部署邊界；
• 非目標與延遲的功能；
• 有界優勢以及每個聲明的比較基準。

同時，建立複雜度預算。載入 references/document-and-complexity-gates.md 以了解預算、文件所有權規則和停止條件。偏好有界限的聲明，而不是「更模組化」或「更可擴展」這類詞語。

使用者決策門檻

不要從程式碼或圖表中推斷產品意圖。當儲存庫證據無法回答關於範圍、所有權、部署、相容性、安全性、成功標準或遷移順序的實質問題時，暫停並詢問使用者。將相關選擇組合在一起，顯示觀察到的事實和權衡，並在合理時推薦保守的預設值。

使用 references/user-decision-gates.md 獲取特定階段的問題和持久記錄位置。如果使用者明確授權某個實質選擇，則選擇推薦或最受支援的可逆轉選項，記錄授權和假設，然後繼續。明確記錄非實質的可逆轉假設，而不是阻礙進度。

階段 2 — 第一級目標架構

定義主要子系統或協調平面、狀態/資料權威和唯一寫入者、身分所有權、依賴方向、應用程式進入點、流程/部署邊界以及受控的通訊形式。

L1 是必需的，且在實作方向確定之前，目標範圍內必須明確。它無需描述每個未來模組，但不能讓所有權、依賴方向或部署範圍模糊不清。命名未解決的 L1 問題及其所有者和決策門檻。

載入 references/architecture-contracts.md 以了解 L1 圖表規則以及在後續階段中使用的 L2/L3/介面綱要。

階段 3 — 當前到目標的映射

對於每個當前熱點，將第一個動作分類為保留、暴露、改編、拆分、合併、棄用或移除。記錄當前擁有者、目標擁有者、保留的通訊/持久化路徑以及移除門檻。將交付範圍作為延遲事項的規範所有者。

不要僅僅因為主題有趣就建立文件。首先找到規範所有者；僅在所有權、狀態、受眾或生命週期有重大差異時才建立新文件。

階段 4 — 第二級模組合約

為每個穩定模組或跨模組邊界建立一個 L2 合約。涵蓋責任與非責任、當前元件、提供/需要的服務、可寫入的權威、允許的呼叫/資料可見性、生命週期/失敗、相容性以及延遲到實作的決策。

在第一個套件中，L2 可能保持不完整。將重要聲明標記為已建立、有條件或開放。每個開放的選擇需要一個有界實驗、證據門檻或可解決它的實作門檻；不要為了表面功夫而發明精確性。

使用 references/architecture-contracts.md 中的 L2 和互動形式規則。當套件包含多個文件時，使用 references/document-and-complexity-gates.md 中的導航和規範所有者檢查。

階段 5 — MVP 與任務本地合約

選擇能夠演練預期邊界的最小的真實閉環。讀取/生命週期閉合切片可能先於首次寫入邊界切片。僅在與描述性名稱配對時保留本地 MVP 標籤，並準確說明該切片證明了什麼以及未證明什麼。

在對一個有界的實作任務進行編碼之前，僅凍結該任務所使用的 L3 合約。在實作任務採用或記錄對其的修訂之前，它仍是一個候選項。不要為未選取的模組建立 L3 文件。使用 references/architecture-contracts.md 中的 L3 和介面檢查清單。

階段 6 — 對抗審查與雙向鋼鐵人

執行一次嘗試破壞所有權、復原、相容性、遷移和證據聲明的對抗性審查，隨後進行一次鋼鐵人審查，陳述最強的價值和故意保守的邊界。偏好未編寫該套件的獨立審查者；否則使用新的上下文並揭露此限制。

使用 references/adversarial-review.md 了解審查時機、問題和單一協調帳本。立即處理每個發現。阻塞性發現會保持門檻關閉，直到風險被解決或由使用者或獨立審查者明確降級/接受為例外；僅拒絕或延遲並不會打開門檻。

階段 7 — 遷移、驗證與晉升

定義帶有相容層、中止條件、移除門檻、回滾/重啟邊界、舊有/目標測試用例和等效證據的分階段遷移。僅在實作、相容性證據和儲存庫權威更新一起合併後，才將目標文本晉升為當前架構。

在每個增量結束時，選擇一個結果：繼續、執行命名實驗、修訂目標/合約，或停止並保留當前路徑。僅在下一個增量的觸發條件和晉升證據滿足時才開始。載入 references/migration-and-promotion.md 以了解詳細的證據、實驗和 ADR 規則。

階段 8 — 交接與發布

發布前：

• 驗證元數據、連結、目錄和相關的一致性/回歸檢查；
• 檢查完整 diff 中是否有不相關的檔案或不受支援的實作聲明；
• 更新專案現有的變更/交接記錄；
• 使增量記錄可從方向或目錄條目中發現；
• 陳述確切的下一個任務和擁有者。

除非使用者授權該外部變更，否則不要建立 PR 或推送分支。當獲得授權時，除非執行時期行為實際發生變化，否則將套件描述為目標設計/文件。

可選關注點

插件、版本共存、流程隔離、熱替換和動態卸載不是預設的架構需求。僅在請求的設計實際啟動這些關注點之一時，才載入 references/optional-concerns.md。

模組路由

需求	載入
選擇最小的工件集合和交付範圍	deliverable-matrix.md
請求或記錄使用者的實質決策	user-decision-gates.md
定義 L1/L2/L3 或面向實作的介面	architecture-contracts.md
控制文件成長、複雜度或過度設計	document-and-complexity-gates.md
執行對抗審查和鋼鐵人審查	adversarial-review.md
規劃遷移、實驗、ADR 或晉升	migration-and-promotion.md
設計插件、隔離或版本共存	optional-concerns.md

不要預設載入每個模組。活躍階段和請求的可交付成果決定了需要哪些參考文件。

禁止事項

• 不要在證明一個真實切片之前重寫整個程式碼庫。
• 不要將每個檔案/類別都變成插件。
• 不要在沒有明確目標決策和失敗模型的情況下建立重複的狀態擁有者、排程器、儲存庫、匯流排或生命週期權威。
• 不要透過重新命名的穿透包裝器隱藏混合的責任。
• 不要僅憑較低的依賴數就聲稱解耦。
• 不要將合成示範作為主要的 MVP 退出條件。
• 不要讓擴充清理暗示領域完成或銷毀。
• 不要將任務筆記、基準分數或生成的散文視為當前架構權威。