評估 NinjaFirewall (WP Edition) 4.9 的相容性，結論是兩者可共存且 不需要開發 AddOn（該外掛全 codebase 零個 apply_filters('nfw_*') / do_action('nfw_*')，官方相容手段全在部署層）。但核心有一個隱患必須補。 TMDO_Options_Manager::register_settings_group() 以 pre_update_option_{key} 回傳 $old_value，讓選項不再落地 wp_options、改存專屬設定表。而 NinjaFirewall 的 Full WAF 走 auto_prepend_file，在 WordPress 載入前就以 原生 mysqli 直查 wp_options 取 nfw_options / nfw_rules。一旦這些鍵被 重導向，WAF 會讀不到設定而靜默停止防護 —— 不報錯、不寫 log。 nfw_rules 約 77KB 且 autoload=auto，正是 autoload 瘦身最誘人的目標， 因此這條路徑並非理論風險。 Added - PROTECTED_OPTIONS 常數與註冊守衛（nfw_options / nfw_rules / nfw_checked）， 命中時發出 _doing_it_wrong()。守衛置於方法開頭，全部鍵都被擋時提前返回， 不再建立空的設定表。 - tests/unit/OptionsManagerProtectedTest.php（4 tests / 10 assertions）， 鎖住「受保護鍵絕不會被掛上 pre_option_* / pre_update_option_* 攔截」。 - docs/WAF-COMPATIBILITY.md：模式差異、symlink 多租戶部署、WP SaaS 開站 流程與驗證清單、三條開發約束、實測風險矩陣。 Changed - Migration Wizard 輪詢 500ms → 2s，與四個 stress-test 面板一致。 原本 2 req/s 打同一 REST endpoint，易觸發 WAF rate-limit 與 bot 偵測。 autoload 最佳化不受影響：optimize_autoload() 只改 autoload 欄位、不刪列， 而 Full WAF 的 SELECT * 不看 autoload。 驗證：591 tests / 1166 assertions 通過，PHPCS 零違規，版本一致性 1.0.2。 dev30 於 Full WAF 與 WP WAF 兩種模式下實測，firewall log 中 TMDO 相關 攔截 0 筆。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SdjXAU473eekjPBB8vPVRS
- readme.txt（WP 外掛目錄格式，隨 ZIP 發佈）：Stable tag 對齊 1.0.0， changelog 補 1.0.0 條目 - CONTEXT.md（領域詞彙表）：Status 區塊改寫為 v1.0.0 實況； HPCT_INTERCEPTORS 與 HivePress Adapter 兩節標註「已搬到 AddOn，核心無此常數」 - docs/：ENTITY_ADAPTER_COOKBOOK、2 篇 ADR、INTEGRATION_PATTERN_DECISION、 anti-eav-lint.yml.template - cookbook 修掉兩個死連結（ANTI_EAV_PLAYBOOK 在來源外掛就不存在） - INTEGRATION_PATTERN_DECISION 加 v1.0.0 後記：結論已被 AddOn 拆分取代 - template 改 wpdev/2meet-data-optimizer + ref v1.0.0 + wp tmdo lint - README.md 文件索引補上以上 7 個檔案 前綴改寫刻意只動類別/函式/slug（WPDO_→TMDO_、wp-data-optimizer→2meet-...）， wpdo_ option/cron/hook/表名與 wpdo/v1 REST namespace 一律保留 —— 這是資料層 零遷移的前提。
wpdev
wpdev
wpdev
wpdev