FSWP 維護者 是做什麼的？
基礎（始終適用）： fswp-developer/references/lean-coding.md（少寫、重複使用）、fswp-developer/references/coding-standards.md（編碼標準、文件、國際化、無障礙），以及 fswp-security-engineer（輸入、輸出、授權）。
既有程式碼即規格。執行來自 fswp-architect 的已核准變更簡報（其已執行 detect_wp_project.py）。遵循專案自身的慣例，除非它們不安全；預設範本是給新專案用的，不是用來改寫他人風格的。
模式 A：更新現有外掛或主題
- 先讀取。 讀取變更所觸及的檔案、其呼叫者及其測試。注意前綴、命名、錯誤處理風格，以及設定與資料的儲存方式。
- 重現。 針對錯誤，寫下步驟與觀察到的結果；在變更任何東西前確認失敗。針對功能，陳述驗收檢查。
- 最小且有效的變更。 在共享程式碼中修復原因，而非在單一呼叫點。不要重新格式化未觸及的程式碼；雜亂的差異會隱藏真正的變更並破壞責任歸屬。
- 保護公開介面。 掛鉤名稱、函式與類別名稱、選項鍵、元資料鍵、REST 路由與形狀、簡碼屬性以及模板覆蓋都是合約。若要變更其中之一，請先棄用：保持舊的運作，呼叫
_deprecated_function()/_deprecated_hook()（或_deprecated_argument()），記錄替代方案，並且最早在下一個主要版本中移除。 - 升級路徑。 如果資料或架構變更：提高已儲存的版本選項，在載入時執行遷移（不僅在啟用時），使其具有冪等性，並測試從前一個版本的資料升級而不重新啟用。
- 相容性。 尊重宣告的
Requires at least和Requires PHP；使用function_exists()/版本檢查來保護較新的函式，或者有目的地提高最低要求並說明。 - 安全審查（
fswp-security-engineer）：錯誤修復不得在沒有授權、nonce、消毒與跳脫的情況下新增新的進入點。 - 版本與更新日誌。 修正 = 補丁，功能 = 次要，破壞性變更 = 主要。同時更新外掛/主題版本、常數、
readme.txt的 Stable tag 以及更新日誌。 - 交付 作為使用者工作儲存庫中的補丁或差異檔，或者當他們部署檔案時作為 zip。包含一致性檢查清單的結果。
主題：建議使用子主題或 theme.json/樣式變化，而不是編輯會接收更新的父主題。直接編輯父主題或第三方外掛檔案，在下次更新時將會遺失。
模式 B：為非自有產品開發附加元件
附加元件是一個獨立的外掛（或一個小主題層），用於擴充主產品。使用 fswp-plugin-developer（步驟 1-3 和 8）來結構化它，然後應用以下規則：
- 透過主產品的公開 API 擴充。 使用文件化的動作、過濾器、註冊表和 REST 路由。絕不編輯主產品檔案，並避免呼叫標記為私有或未記錄的內部函式；如果必須，請在一個適配器類別中隔離該呼叫並保護它。
- 宣告依賴關係。 當主產品在 WordPress.org 上時，在標頭中加入
Requires Plugins: host-slug（WordPress 6.5 及以上版本會強制執行）。同時在執行時期檢測：檢查類別、函式或常數，或版本常數，而不是外掛檔案路徑。 - 在正確的時間載入。 在確認主產品存在後，於
plugins_loaded（或主產品自身的就緒掛鉤）上初始化；在主產品的註冊掛鉤上註冊，而不是更早。 - 優雅且清楚地失敗。 主產品缺失或太舊：不做任何其他事情，顯示一個管理通知說明需要什麼，並且絕不致命錯誤。
- 版本範圍。 在 readme 和計畫中說明支援的主產品版本。測試最低和新版支援的版本。
- 相容性宣告。 有些主產品要求您宣告功能支援。例如：WooCommerce 期望擴充元件宣告對高效能訂單儲存以及基於區塊的購物車和結帳的相容性。閱讀主產品的開發者文件以了解目前的宣告呼叫。
- 資料所有權。 在您自己的前綴下儲存您的資料；不要寫入主產品的資料表或選項。解除安裝只會移除您的資料。
- 授權與命名。 遵循主產品的品牌與商標規則來命名；使用描述性的「用於 X」風格，而不是暗示它是官方的。
驗證
將變更交付給 fswp-qa-engineer，並以變更簡報的一致性檢查清單和相容性表格作為情境來源。references/safe-change-checklist.md 是快速交付前檢查清單。