審查程式碼
基於證據與專案上下文進行審查。優先關注不正確的行為、真實風險與回歸；不要為了填滿檢查清單而產生評論。
尊重範圍與安全性
- 將審查視為唯讀操作。未經明確要求，不得編輯程式碼、切換分支、安裝或更新依賴、套用修正、提交、發佈評論或執行部署。
- 可在安全且相關的前提下執行非變異性的本地檢查。在執行來自不可信變更的程式碼之前，需評估該指令及其效果。
- 未經授權，不得將程式碼、機密或中繼資料傳送給外部服務。
- 區分審查與實作：若請求僅為審查，則報告發現，不進行修正。
- 保留使用者現有的變更，避免破壞性指令。
建立上下文
- 完整閱讀
AGENTS.md以及適用於被審查目錄的指示。 - 透過請求、議題、PR 描述、diff 與相關歷史記錄，識別變更的目標、需求與邊界。
- 在斷定某事物為缺陷之前，檢查所有被變更的檔案以及直接相關的程式碼。
- 驗證專案實際的設定、版本、架構與慣例。不要透過類比套用其他語言或框架的標準。
- 在要求澄清之前，先調查本地可取得的資訊。僅當資訊缺口阻礙負責任的結論時才提問。
- 記錄分析的局限性，例如未執行的測試、不可用的依賴或缺乏需求。
執行審查
評估每個變更在適用維度上的表現：
功能性與回歸
- 確認實作符合請求的行為，並保留既有流程。
- 檢查邊界條件、空值或 null 值、部分失敗、操作重複、並發問題與狀態轉換。
- 檢查錯誤處理、回滾、冪等性與副作用。
- 驗證公開契約、向後相容性、遷移與對消費者的影響。
安全性與隱私
- 檢查在正確邊界上的輸入驗證與輸出編碼。
- 尋找授權、認證、CSRF、XSS、注入、路徑遍歷、SSRF、不安全上傳與大量賦值等漏洞。
- 檢查程式碼、回應、URL 與日誌中是否暴露機密或個人資料。
- 根據使用案例與資源評估權限；單獨的認證無法取代授權。
- 將依賴警報視為待確認的證據，考量其可利用性與修復的相容性。
資料、效能與可靠性
- 識別 N+1 問題、重複查詢、過度載入、昂貴的循環以及不適合預期資料量的演算法。
- 當變更觸及持久層時，檢查事務、鎖、約束、索引與參照完整性。
- 在相關路徑上驗證分頁、限制、逾時、重試與記憶體消耗。
- 僅當存在合理的瓶頸時才建議最佳化或快取；考慮失效與一致性。
- 在涉及金錢計算時，檢查小數精度、四捨五入與原子性。
設計與維護
- 評估內聚性、關注點分離、依賴方向與領域語言。
- 偏好簡單且明確的程式碼。不要為了消除所有重複而要求任意小的函式或過早的抽象。
- 檢查名稱、契約、型別處理以及用來說明非顯而易見決策的註解。
- 將機械性風格問題留給專案的格式化工具與 linter，除非它們影響正確性或理解。
測試與文件
- 檢查與風險成比例的測試，涵蓋主要行為、邊界、錯誤與相關回歸。
- 評估斷言的品質、隔離性以及測試在面對預期缺陷時能否失敗；不要僅使用覆蓋率百分比。
- 當公開行為變更時，檢查文件、API 契約與操作說明。
- 在執行檢查之前，遵循儲存庫規定的指令與環境。準確報告哪些已執行、哪些未執行。
針對 PHP 與 CakePHP 的檢查
當技術棧涉及 PHP 或 CakePHP 時，也需：
- 檢查 PHP 版本的相容性，並使用專案配置的工具，例如 PHPUnit、PHPCS、PHPStan、Psalm 與
composer audit。 - 保持 Controller 專注於 HTTP 輸入與編排；將業務規則放在專案所採用的層，通常是 Services。
- 檢查每個動作與資源的 Policy 與授權檢查。
- 評估 Validator、RulesChecker、
patchEntity()、Entity 的可存取欄位以及大量賦值保護。 - 偏好使用 ORM、查詢建構器與綁定參數，避免串接 SQL；檢查 associations、
contain()、欄位選取與 N+1 風險。 - 在涉及多個寫入的操作中檢查事務，並區分持久性失敗與意外例外。
- 檢查模板中的跳脫、明確標記為不跳脫的欄位、CSRF 以及可能洩漏內部細節的回應。
- 審查 migration 的實際可逆性、現有值、鎖、索引、外鍵以及與支援的資料庫的相容性。
- 尊重
composer.lock；不建議不加區別地更新依賴。
對於 Lavanderias Core 中的 CakePHP，特別尊重 Controller → Service → Table/Entity 流程、AbstractService::run() 的契約、按角色的 Policy、MariaDB、PHPUnit 以及在容器內執行指令（測試時始終不使用 -u root）。
針對前端網頁的檢查
- 檢查上下文相關的跳脫、安全的 DOM 操作、CSRF、伺服器端驗證與資料暴露。
- 驗證載入、錯誤、並發請求、取消以及順序錯亂的回應等狀態。
- 尊重本地技術棧與慣例；在 Lavanderias Core 的新程式碼中，偏好 StimulusJS 與 Axios，並將 jQuery 限制在舊有維護。
- 當變更影響介面時，評估無障礙性與回應式行為。
驗證發現
在報告問題之前：
- 確認該問題是由被審查的範圍引入或影響。
- 找到展示問題的最小子程式碼區域。
- 描述一個具體的場景，其中該行為會發生。
- 檢查是否有其他層、設定或測試已經緩解了該風險。
- 根據可能性與影響調整嚴重性，而非根據規則的抽象類型。
diff 中不存在並不表示系統中不存在。如果儲存庫可用，在報告缺乏授權、驗證、事務或等效保護之前，檢查相關層。如果只有孤立的片段，則將該點作為條件風險或疑問提出，而非確認的缺陷。
不要將遙遠的假設呈現為確認的缺陷。當存在相關的不確定性時，明確識別它，並說明哪種證據可以解決該疑問。
產出報告
首先按嚴重性順序呈現發現：
- 阻斷： 資料損毀、可利用的漏洞、嚴重不可用性或核心行為無法運作。
- 高： 可能的缺陷，具有重大影響或重要的回歸。
- 中： 真實問題，影響有限，依賴特定條件。
- 低： 具體且局部的改進，沒有立即的重大風險。
對於每個發現，包含：
### [嚴重性] 客觀標題
- 位置：`路徑/檔案.副檔名:行號`
- 證據：在程式碼中可演示的行為。
- 影響：受影響的場景與後果。
- 建議：與之成比例的修正方向，無需重寫整個解決方案。
始終使用檔案的本機行號，切勿使用 diff 檔案中的全域位置。如果 diff 未提供足夠的 hunk 編號，則引用符號或方法名稱，並說明行號不可用。保持範圍簡短，且直接與發現相關。將等效的發生分組，而不是重複評論。
在發現之後，簡短記錄：
- 影響結論的疑問或假設；
- 已執行檢查及其結果；
- 殘餘風險或測試缺口。
如果沒有發現，清楚說明，並仍報告局限性與已執行的檢查。除非使用者也要求摘要，否則不要用變更的通用摘要取代發現。