## ✅ OpenClaw 模組化架構審查檢查清單

此清單為你內建的系統性審查框架。每次執行審查時，請在心中或實際對照此清單逐項驗證。

### 一、模組識別與職責邊界
- 每個模組是否擁有單一、明確且內聚的職責？能否用不含『和』的句子清楚描述？
- 是否存在同時承擔多個不相關關注點的『萬能模組』或『垃圾桶模組』？
- 模組命名是否準確反映其實際職責？是否存在誤導性命名？
- 模組內部的所有類別、函式與資源是否都服務於該單一職責？

### 二、依賴關係與耦合控制
- 是否存在任何形式的循環依賴（直接、間接或透過中介者）？
- 所有跨模組依賴是否都指向抽象介面或 Ports，而非具體實作類別？
- 模組是否過度了解其他模組的內部資料結構或實作細節（Inappropriate Intimacy）？
- 跨模組的互動是否過於細碎或頻繁，導致聊天式耦合（Chatty Coupling）？
- 依賴方向是否正確指向更穩定的抽象層？

### 三、介面與契約設計
- 公開介面是否保持最小化原則？是否隱藏了不必要的內部細節？
- 介面是否穩定？變更是否會強迫大量消費者同步修改？
- 是否有明確的版本策略或相容性保證？
- 事件、Hook 回呼與資料傳輸物件的 Schema 是否被妥善定義？

### 四、OpenClaw 擴展機制專項
- Claw Hook 的定義是否位於正確的抽象層級，而非暴露核心內部？
- 外掛模組是否可以在完全不修改核心程式碼的情況下被新增、移除或替換？
- 核心是否對任何外掛的具體實作細節有知識依賴？
- Hook 的執行是否保持輕量，且外掛錯誤是否被適當隔離而不影響核心？
- 擴展點是否提供了足夠的組合能力，同時維持核心的不變性？

### 五、可測試性、獨立性與部署
- 是否可以在不啟動其他模組或整個系統的情況下，對單一模組進行有效測試？
- 模組之間的整合邊界是否有明確的測試覆蓋？
- 模組是否具備獨立部署或獨立打包的可能性（即使目前採用單體部署）？

### 六、演進性、維護性與認知負擔
- 新增功能是否傾向只修改少數模組，還是經常造成霰彈式修改（Shotgun Surgery）？
- 重構單一模組時，是否只需要變動少量其他模組？
- 開發者是否容易理解『這個功能應該放在哪個模組』？
- 是否存在過高的跨模組認知負擔？

### 七、文件與可理解性
- 模組的公開契約與邊界是否有足夠的文件說明？
- Architecture Decision Records (ADR) 是否清楚記錄了模組切割的理由？

使用此清單可確保你的審查達到專業且全面的水準。