呢套布局可以作為收斂方向，不過有三個概念要分清楚：唔係所有測試都可以無條件搬離業務套件；規範唔係所有 ADR 的摘要；凍結亦唔等於完成歸檔。以下逐項列出六個建議的適用範圍。文中提到的新路徑都只係候選，尚未建立或遷移。

1. 測試集中管理：可以做預設，但要留有語言例外

建議將測試集中管理作為預設，而唔係要求每個專案都清走原始碼目錄內的測試。

• **Python 專案：**優先集中放喺 tests/。遷移前要檢查匯入方式、測試探索、fixture 同 CI。現有倉庫的 CI 已採用集中測試路徑。
• **Go 專案：**如果白盒測試要存取套件內未匯出的成員，可以保留喺被測套件目錄；黑盒、跨元件同端到端測試則優先集中。Go 工具鏈會將測試檔同套件一齊編譯，亦支援同套件測試同外部測試套件兩種形式。1416
• 唔好混為一談：internal 套件的匯入限制，取決於目錄祖先關係，唔代表只有同一目錄先可以匯入；而存取未匯出成員，係另一層套件邊界。1016

所以，「所有 Go 測試都搬出業務目錄，同時保留白盒覆蓋及原有封裝」唔適合作為通用驗收要求。唔應為咗目錄整齊，就將內部狀態改為匯出，或者複製一份業務實作。

真正應該避免的，係無價值的工單碎片同重複驗證，而唔係合理的獨立測試檔案。持續回歸測試應納入版本管理；一次性探針先放入臨時區。

2. 規範、ADR 同全局規則：各自負責唔同問題

方向大致啱，但 specs/ 唔應定義成「由所有 ADR 抽出來的通用規範」。可以按以下方式分工：

層次	要回答的問題	內容來源
全局方法論	點樣分析、驗證同交付？	方法論維護者制定
專案入口 AGENTS.md	喺呢個專案應該點樣工作？	已確認的專案限制及操作入口
專案規範 specs/	現時要符合邊啲行為同契約？	使用者需求、已接受決策及獲批修訂
決策記錄 docs/adr/	點解揀呢個方案？	有架構影響的取捨及替代方案

Cline 官方文件有說明持久規則機制，可用來保存跨對話指示。4 不過，現有證據未能證明 Cline 會原生、自動將某類檔案寫入規範目錄；所以呢點應視為專案約定，而唔係 Cline 保證的功能。

專案內容唔需要全部人手寫，亦唔使等到遇上動態背壓先開始建立：

1. 初始化時，助手可以按使用者需求同倉庫證據提出專案規範；未確認的內容要保留為未知。
2. 開始任務前，讀取相關規範同決策，講清楚今次的驗收要求同驗證方法。
3. 只有出現重要的新取捨，先提出新 ADR；已有決策仍然適用，就直接引用，唔使每個計劃都另開一份。
4. 驗證結果可以證明實作合格，亦可以揭示規範有缺口；唔可以由實作結果自動反推需求。
5. 決策獲批、規範更新後，將現時有效的限制寫入對應規範，並引用相關 ADR，唔需要複製全部歷史。

簡單講：規範係現行契約，ADR 係決策依據，測試係可執行檢查。三者互相關聯，但唔可以互相取代。專案內的個別發現亦唔應未經審核，就升格成全局規則。

3. ADR 路徑遷移：可以統一，但毋須改變接受流程

將新決策的預設位置統一到 docs/adr/ 可行。呢個係專案命名約定，唔需要話佢係唯一的行業標準。

現有決策策略可以保留：

• 提案、已接受、被否決同已被取代的決策，都可以存檔，唔係只保留已接受的記錄。
• 新任務沿用相關而仍然有效的決策，避免重複建立相同 ADR。
• 舊決策被取代時，記錄新舊決策之間的關係，唔好改寫當時的理由。
• 測試通過，唔代表 ADR 自動獲得接受授權。

遷移時亦要更新實際引用、路由同權限限制，唔可以只搬檔案就當完成。

4. 計劃目錄：可以扁平存放，但凍結唔等於完成

將計劃集中放喺 plans/ 並採用扁平布局係可行的；唔需要為少量歷史計劃硬加子目錄。檔名可以考慮以下候選方式：

用途	候選檔名	含義
目前執行中的計劃	pending_implementation_plan.md	唯一預設的活動入口
完成後保存	plan-20261022-example-id.md	已完成並獲准歸檔的計劃
未完成但凍結	plan-20261022-example-id-frozen.md	保留未完成事項，但唔再預設執行

凍結唔需要新增目錄，亦唔一定要即時增加狀態列舉。現有校驗器已支援暫停狀態，可以先沿用；凍結檔要寫明暫停原因、剩餘事項同恢復條件。

要清楚分開三種情況：

• **完成歸檔：**所有必要驗收都已通過，並取得歸檔授權。
• **未完成凍結：**移出活動入口，但唔可以標成完成，亦唔可以將未驗證的提案升格成事實。
• **明確放棄：**交代唔再實施及其影響；唔好只寫成暫時擱置。要唔要新增正式終止狀態，應另行修訂契約。

預設只讀取活動入口，唔好每次都搜尋同一目錄下所有歷史檔案；只有使用者要求恢復或查閱歷史時，先有目標咁搵。恢復凍結計劃要重新取得授權，建立保留來源的新執行版本，再重新驗證；唔可以沿用舊有的綠燈狀態。呢個做法同現有生命周期規則一致。

另外，重新命名檔案只係保存操作，唔係驗收證明。過程要避免覆蓋檔案、保留未完成事項，同時處理相關引用；亦唔應為咗維持固定入口，就硬性建立空白計劃範本。

5. 測試同程式碼的關係：按模組及契約建立多對多映射

唔建議強制「一份程式碼配一份測試」。一個測試可以涵蓋多個元件；一個元件亦可能需要單元測試、屬性測試同整合回歸測試。

可以先採用以下做法：

• 喺 tests/ 內按模組或職責分目錄。
• 喺對應規範列出核心不變條件、相關測試入口，同有明確範圍的驗證指令。
• 只有當路徑關係確實難以查找時，先增加候選的測試映射檔。

映射檔只記錄必要關係：模組或契約識別碼、原始碼範圍、測試範圍同驗證入口。唔好複製成份目錄樹，亦唔好喺入面重複記錄測試通過狀態。

維護要求應該係路徑同指令保持有效；有映射檔唔代表覆蓋充分，更唔代表測試已通過。咁樣可以避免為咗減少檔案混亂，反而多加一份容易過時的人手帳簿。

6. 草稿可以清理，但可信度唔係由目錄決定

一次性草稿、臨時腳本同探索報告集中放喺 .scratch/ 係合理的。不過，「入面內容唔可以做一手資料」同「可以隨時全部刪除」都應該改成有條件的規則。

• 模型整理的研究摘要屬於二手解讀，唔可以自行升格為事實。
• 原始測試輸出同真實診斷記錄，即使放喺臨時目錄，都可能係一手證據；可信度要睇來源、環境、時間同完整性。
• 如果某項證據仍然被計劃、決策或驗收引用，而且係唯一副本，就唔可以隨意刪除。清理前要保存必要原件，或者清楚撤回依賴該證據的結論。
• 提煉出來的重要發現要保留證據位置、適用範圍同未知之處；濃縮內容唔可以將假設變成事實。

至於 docs/ 內的舊報告同架構圖，建議分清「現行維護文件」、「明確標示的歷史資料」同「有待核實的材料」，唔好見到舊就一律當垃圾：

• 現行文件要標明適用範圍，並喺相關契約變更時重新檢視。
• 舊圖或舊方案要標為歷史、過時或已被取代，預設唔應作為現行基準。
• 冇長期價值、亦冇引用依賴的過程資料，獲准後先移入臨時區或刪除。

保留資料同每次預設載入資料，係兩回事。保留有必要的歷史，唔代表每輪都要讀；要減少上下文干擾，優先採用定向讀取同有效性標記，而唔係抹走證據。

收斂結論

呢套布局可以採用，但要守住四條界線：測試集中管理，同時保留語言上的合理例外；規範維護現行契約，而唔係匯總所有 ADR；凍結狀態要保留未完成的事實；清理臨時資料時唔可以刪走唯一而必要的證據。

目前預設計劃路徑及允許路徑，以及分析模式的編輯範圍，仍然綁定舊布局。之後遷移時，要同步更新規則、範本、引用、校驗器同宿主適配設定，唔可以單靠改目錄名稱就當新規則已生效。

本輪只完成分析，未有寫入、遷移、凍結或清理任何資產。

呢套布局可以作為收斂方向，不過有三個概念要分清楚：唔係所有測試都可以無條件搬離業務套件；規範唔係所有 ADR 的摘要；凍結亦唔等於完成歸檔。以下逐項列出六個建議的適用範圍。文中提到的新路徑都只係候選，尚未建立或遷移。

1. 測試集中管理：可以做預設，但要留有語言例外

建議將測試集中管理作為預設，而唔係要求每個專案都清走原始碼目錄內的測試。

• **Python 專案：**優先集中放喺 tests/。遷移前要檢查匯入方式、測試探索、fixture 同 CI。現有倉庫的 CI 已採用集中測試路徑。
• **Go 專案：**如果白盒測試要存取套件內未匯出的成員，可以保留喺被測套件目錄；黑盒、跨元件同端到端測試則優先集中。Go 工具鏈會將測試檔同套件一齊編譯，亦支援同套件測試同外部測試套件兩種形式。1416
• 唔好混為一談：internal 套件的匯入限制，取決於目錄祖先關係，唔代表只有同一目錄先可以匯入；而存取未匯出成員，係另一層套件邊界。1016

所以，「所有 Go 測試都搬出業務目錄，同時保留白盒覆蓋及原有封裝」唔適合作為通用驗收要求。唔應為咗目錄整齊，就將內部狀態改為匯出，或者複製一份業務實作。

真正應該避免的，係無價值的工單碎片同重複驗證，而唔係合理的獨立測試檔案。持續回歸測試應納入版本管理；一次性探針先放入臨時區。

2. 規範、ADR 同全局規則：各自負責唔同問題

方向大致啱，但 specs/ 唔應定義成「由所有 ADR 抽出來的通用規範」。可以按以下方式分工：

層次	要回答的問題	內容來源
全局方法論	點樣分析、驗證同交付？	方法論維護者制定
專案入口 AGENTS.md	喺呢個專案應該點樣工作？	已確認的專案限制及操作入口
專案規範 specs/	現時要符合邊啲行為同契約？	使用者需求、已接受決策及獲批修訂
決策記錄 docs/adr/	點解揀呢個方案？	有架構影響的取捨及替代方案

Cline 官方文件有說明持久規則機制，可用來保存跨對話指示。4 不過，現有證據未能證明 Cline 會原生、自動將某類檔案寫入規範目錄；所以呢點應視為專案約定，而唔係 Cline 保證的功能。

專案內容唔需要全部人手寫，亦唔使等到遇上動態背壓先開始建立：

1. 初始化時，助手可以按使用者需求同倉庫證據提出專案規範；未確認的內容要保留為未知。
2. 開始任務前，讀取相關規範同決策，講清楚今次的驗收要求同驗證方法。
3. 只有出現重要的新取捨，先提出新 ADR；已有決策仍然適用，就直接引用，唔使每個計劃都另開一份。
4. 驗證結果可以證明實作合格，亦可以揭示規範有缺口；唔可以由實作結果自動反推需求。
5. 決策獲批、規範更新後，將現時有效的限制寫入對應規範，並引用相關 ADR，唔需要複製全部歷史。

簡單講：規範係現行契約，ADR 係決策依據，測試係可執行檢查。三者互相關聯，但唔可以互相取代。專案內的個別發現亦唔應未經審核，就升格成全局規則。

3. ADR 路徑遷移：可以統一，但毋須改變接受流程

將新決策的預設位置統一到 docs/adr/ 可行。呢個係專案命名約定，唔需要話佢係唯一的行業標準。

現有決策策略可以保留：

• 提案、已接受、被否決同已被取代的決策，都可以存檔，唔係只保留已接受的記錄。
• 新任務沿用相關而仍然有效的決策，避免重複建立相同 ADR。
• 舊決策被取代時，記錄新舊決策之間的關係，唔好改寫當時的理由。
• 測試通過，唔代表 ADR 自動獲得接受授權。

遷移時亦要更新實際引用、路由同權限限制，唔可以只搬檔案就當完成。

4. 計劃目錄：可以扁平存放，但凍結唔等於完成

將計劃集中放喺 plans/ 並採用扁平布局係可行的；唔需要為少量歷史計劃硬加子目錄。檔名可以考慮以下候選方式：

用途	候選檔名	含義
目前執行中的計劃	pending_implementation_plan.md	唯一預設的活動入口
完成後保存	plan-20261022-example-id.md	已完成並獲准歸檔的計劃
未完成但凍結	plan-20261022-example-id-frozen.md	保留未完成事項，但唔再預設執行

凍結唔需要新增目錄，亦唔一定要即時增加狀態列舉。現有校驗器已支援暫停狀態，可以先沿用；凍結檔要寫明暫停原因、剩餘事項同恢復條件。

要清楚分開三種情況：

• **完成歸檔：**所有必要驗收都已通過，並取得歸檔授權。
• **未完成凍結：**移出活動入口，但唔可以標成完成，亦唔可以將未驗證的提案升格成事實。
• **明確放棄：**交代唔再實施及其影響；唔好只寫成暫時擱置。要唔要新增正式終止狀態，應另行修訂契約。

預設只讀取活動入口，唔好每次都搜尋同一目錄下所有歷史檔案；只有使用者要求恢復或查閱歷史時，先有目標咁搵。恢復凍結計劃要重新取得授權，建立保留來源的新執行版本，再重新驗證；唔可以沿用舊有的綠燈狀態。呢個做法同現有生命周期規則一致。

另外，重新命名檔案只係保存操作，唔係驗收證明。過程要避免覆蓋檔案、保留未完成事項，同時處理相關引用；亦唔應為咗維持固定入口，就硬性建立空白計劃範本。

5. 測試同程式碼的關係：按模組及契約建立多對多映射

唔建議強制「一份程式碼配一份測試」。一個測試可以涵蓋多個元件；一個元件亦可能需要單元測試、屬性測試同整合回歸測試。

可以先採用以下做法：

• 喺 tests/ 內按模組或職責分目錄。
• 喺對應規範列出核心不變條件、相關測試入口，同有明確範圍的驗證指令。
• 只有當路徑關係確實難以查找時，先增加候選的測試映射檔。

映射檔只記錄必要關係：模組或契約識別碼、原始碼範圍、測試範圍同驗證入口。唔好複製成份目錄樹，亦唔好喺入面重複記錄測試通過狀態。

維護要求應該係路徑同指令保持有效；有映射檔唔代表覆蓋充分，更唔代表測試已通過。咁樣可以避免為咗減少檔案混亂，反而多加一份容易過時的人手帳簿。

6. 草稿可以清理，但可信度唔係由目錄決定

一次性草稿、臨時腳本同探索報告集中放喺 .scratch/ 係合理的。不過，「入面內容唔可以做一手資料」同「可以隨時全部刪除」都應該改成有條件的規則。

• 模型整理的研究摘要屬於二手解讀，唔可以自行升格為事實。
• 原始測試輸出同真實診斷記錄，即使放喺臨時目錄，都可能係一手證據；可信度要睇來源、環境、時間同完整性。
• 如果某項證據仍然被計劃、決策或驗收引用，而且係唯一副本，就唔可以隨意刪除。清理前要保存必要原件，或者清楚撤回依賴該證據的結論。
• 提煉出來的重要發現要保留證據位置、適用範圍同未知之處；濃縮內容唔可以將假設變成事實。

至於 docs/ 內的舊報告同架構圖，建議分清「現行維護文件」、「明確標示的歷史資料」同「有待核實的材料」，唔好見到舊就一律當垃圾：

• 現行文件要標明適用範圍，並喺相關契約變更時重新檢視。
• 舊圖或舊方案要標為歷史、過時或已被取代，預設唔應作為現行基準。
• 冇長期價值、亦冇引用依賴的過程資料，獲准後先移入臨時區或刪除。

保留資料同每次預設載入資料，係兩回事。保留有必要的歷史，唔代表每輪都要讀；要減少上下文干擾，優先採用定向讀取同有效性標記，而唔係抹走證據。

收斂結論

呢套布局可以採用，但要守住四條界線：測試集中管理，同時保留語言上的合理例外；規範維護現行契約，而唔係匯總所有 ADR；凍結狀態要保留未完成的事實；清理臨時資料時唔可以刪走唯一而必要的證據。

目前預設計劃路徑及允許路徑，以及分析模式的編輯範圍，仍然綁定舊布局。之後遷移時，要同步更新規則、範本、引用、校驗器同宿主適配設定，唔可以單靠改目錄名稱就當新規則已生效。

本輪只完成分析，未有寫入、遷移、凍結或清理任何資產。