Review Conventions（審查慣例）
審查變更的程式碼是否符合此儲存庫的風格，而不僅僅是是否能運作。優先考量召回率（Recall）而非精確率（Precision）：找出合理、有證據支持的不一致之處，供人類進行分類，包括那些專注於錯誤的審查會忽略的輕微風格和模式不匹配。
這是一個唯讀審查。請勿修改檔案、執行會寫入檔案的格式化工具，或發布評論。
流程
- 建立差異檔。 使用請求的目標。否則，檢查已暫存和未暫存的變更；如果都不存在，則將目前分支與其相對於已建立基礎分支的合併基礎進行比較。說明對比較目標的任何不確定性。
- 閱讀本地指導文件。 檢查適用的
AGENTS.md、CONTRIBUTING.md、樣式/架構文件以及相關的 lint/測試設定。不要假定這些文件涵蓋了未記錄的慣例。 - 主動在差異檔外搜尋先例。 對於每個新增或改變的實作選擇，檢查：
- 先看相同脈絡： 相鄰程式碼、兄弟檔案、包含的 UI 區域（例如工具列、頁首、對話框）、同一個套件/模組或相鄰的測試——即使它們實作了不同的功能。
- 再看相同行為： 其他等效 UI 控制項、操作、輔助函式或測試的實作。
- 最後看更廣泛的方向： 當本地做法不明確時，參考儲存庫範圍的模式和已記錄的遷移。 在實際可行的情況下比較多個代表性範例。優先考慮來自相同 UI 區域、模組或架構邊界的先例，而非功能相似的其它實作。只有在同一慣例同時適用於兩個上下文時，才將不同上下文中的實作視為反例。
- 刻意尋找慣例不符之處：
- UI： 在已建立的區域內混合不同元件系統；選擇與相鄰 UI 不同的控制項、組合方式、樣式、屬性或事件模式。
- 程式碼： 繞過現有的輔助函式/包裝器、使用不同的狀態管理或錯誤處理慣例、命名/型別/匯入慣例，或檔案位置不一致。
- 測試： fixture/設定、命名、結構、定位器或斷言風格不一致；變更現有的端對端選擇器或斷言，導致其目標範圍擴大但未說明原因。
- 變更範圍： 引入第二種方式來做同一件事，或在差異檔內進行不相關的風格重寫。
- 挑戰看似的不符之處。 在報告不符之前，需從變更程式碼的實作、呼叫者和測試中，確定其實際的責任和意圖。不要僅因為出現相關的術語或 API 就套用慣例。判斷所引用的慣例是否規範了正在測試的行為、實作機制或測試的位置，並解釋它為何適用於此變更。檢查是否有記錄的遷移、故意例外或真正不同的需求可以解釋這個選擇。當範例互相衝突時，報告不確定性，而不是發明統一的規則。
報告門檻
要積極尋找候選項目，而不是宣告規則。當有特定的先例或記錄的政策可以比較時，報告輕微且可能有爭議的偏差。不需要證明存在執行時期錯誤、高嚴重性或有多個相同的範例。
即使推斷出的慣例沒有明確記錄，也應報告有強烈支持的慣例；將其標記為推斷，並引用支持證據。
- 明確不符： 直接適用的指導方針或強烈的本地先例。
- 可能不符： 具體但有限/衝突的先例；值得人工審查。明確指出不確定性。
不要發明慣例、引用不相關的程式碼作為證據，或把一個偶然的範例變成通用規則。跳過純格式化/linter 的瑣事、沒有儲存庫證據的偏好、變更範圍外既存的問題，以及由 $review-agent 處理的通用正確性/安全性/效能錯誤。不要要求大規模重構以強制一致性。
範例： 當在工具列中新增一個切換開關時，應檢查該工具列中的其他控制項以及其他地方的切換開關。在基於 Quasar 的工具列中，使用不同的元件系統可能即使功能正常也值得提出發現。這是一種尋找本地慣例的方法，不是要求使用 Quasar 的萬用規則。
輸出
報告所有不同且有證據支持的候選項目，包括影響較低的項目；合併同一問題的重複實例。按對維護者的可能相關性排序，而不僅僅是嚴重性。
對於每個發現，提供：
- 位置： 變更的檔案和行號。
- 慣例證據： 確切的既有檔案/位置或記錄的規則；標記為已記錄或已推斷。
- 不符之處： 差異何在以及為何對於一致性很重要。
- 建議： 最小合理的調整，對於不確定的情況，以建議的方式表達。
- 信心等級：
高、中或低；對於中/低等級，說明不確定性。
將明確不符與可能不符分開。如果兩者都沒有證據支持的候選項目，則回覆 未發現慣例問題。 不要僅僅因為樣式問題或可能在人工審查時被拒絕就默默拋棄合理的案例。