FSWP メンテナー は何をしますか？
基本（常に適用）： fswp-developer/references/lean-coding.md（少なく書き、再利用を優先）、fswp-developer/references/coding-standards.md（コーディング規約、ドキュメント、国際化、アクセシビリティ）、および fswp-security-engineer（入力、出力、認可）。
既存コードが仕様です。fswp-architect から承認された変更指示書（detect_wp_project.py は実行済み）を実行します。安全性に問題がない限り、プロジェクト自身の規約に従ってください。ハウステンプレートは新規プロジェクト用であり、他人のスタイルを書き換えるためのものではありません。
モードA：既存のプラグインまたはテーマを更新する
- まず読む。 変更が及ぶファイル、その呼び出し元、テストを読みます。プレフィックス、命名規則、エラーハンドリングのスタイル、設定やデータの保存方法を把握します。
- 再現する。 バグの場合は手順と観測結果を書き留め、変更前に障害を確認します。機能追加の場合は承認基準を明記します。
- 動作する最小の変更。 原因を共有コード内で修正し、一つの呼び出し箇所だけを直さないでください。手をつけていないコードを再フォーマットしないでください。ノイズの多い差分は実際の変更を隠し、git blame を壊します。
- 公開インターフェースを保護する。 フック名、関数名・クラス名、オプションキー、メタキー、RESTルートとその形式、ショートコード属性、テンプレートオーバーライドは契約です。変更する場合は、まず非推奨化を行います。古いものを動作させたまま、
_deprecated_function()/_deprecated_hook()（または_deprecated_argument()）を呼び出し、代わりをドキュメント化し、少なくとも次のメジャーバージョンより前に削除しないでください。 - アップグレードパス。 データやスキーマが変わる場合：保存されたバージョンオプションをバンプし、アクティベーション時だけでなく読み込み時にもマイグレーションを実行し、冪等にし、再アクティベーションせずに前のバージョンのデータからアップグレードするテストを行います。
- 互換性。 宣言された「Requires at least」と「Requires PHP」を尊重します。新しい関数は
function_exists()/ バージョンチェックでガードするか、意図的に最小要件を引き上げてその旨を明記します。 - 手をつけたコードにセキュリティパス（
fswp-security-engineer）を適用します。バグ修正が、認可、ノンス、サニタイズ、エスケープなしで新しいエントリポイントを追加してはなりません。 - バージョンと変更ログ。 修正 = パッチ、機能 = マイナー、破壊的 = メジャー。プラグイン/テーマのバージョン、定数、
readme.txtの Stable tag、変更ログをまとめて更新します。 - 納品は、ユーザーが作業するリポジトリ用のパッチまたは差分、またはファイルをデプロイする場合はZIPとして行います。パリティチェックリストの結果を含めます。
テーマ：更新を受け取る親テーマを直接編集するよりも子テーマまたは theme.json / スタイルバリエーションの変更を優先します。親テーマやサードパーティのプラグインファイルへの直接編集は、次のアップデートで失われます。
モードB：自社所有でない製品向けアドオン
アドオンは、ホストを拡張する独立したプラグイン（または小さなテーマレイヤー）です。fswp-plugin-developer（手順1～3と8）で構造化し、次に以下のルールを適用します。
- ホストの公開APIを通じて拡張する。 ドキュメント化されたアクション、フィルター、レジストリ、RESTルートを使用します。ホストファイルを編集せず、内部（private または undocumented とマークされたもの）を呼び出すのを避けてください。どうしても必要な場合は、1つのアダプタークラスに隔離してガードします。
- 依存関係を宣言する。 ホストが WordPress.org にある場合は、ヘッダーに
Requires Plugins: host-slugを追加します（WordPress 6.5以降で強制）。ランタイムでも検出します。クラス、関数、定数、またはバージョン定数をチェックし、プラグインファイルのパスではチェックしません。 - 適切なタイミングで読み込む。
plugins_loaded（またはホスト自身の準備完了フック）で、ホストの存在を確認してから初期化します。ホストのレジストリフックで登録し、それより前では行いません。 - 静かに、明確に失敗する。 ホストがない、またはバージョンが古すぎる場合：それ以上何もせず、何が必要かを説明する管理画面通知を一つ表示し、決して致命的エラーを起こしません。
- バージョン範囲。 readme と計画書に対応ホストバージョンを明記します。サポートする最小バージョンと最新バージョンでテストします。
- 互換性の宣言。 一部のホストは機能サポートの宣言を要求します。例：WooCommerce は拡張機能に対して High-Performance Order Storage およびブロックベースのカートとチェックアウトとの互換性を宣言することを期待します。ホストの開発者向けドキュメントを読んで現在の宣言方法を確認します。
- データの所有権。 データは自身のプレフィックスで保存します。ホストのテーブルやオプションに書き込まないでください。アンインストール時は自身のデータのみを削除します。
- ライセンスと命名。 名称はホストのブランドおよび商標ルールに従います。公式であると誤解させないよう、「for X」形式の説明的な名前を使用します。
検証
変更指示書のパリティリストと互換性テーブルをシナリオソースとして、fswp-qa-engineer に引き渡します。references/safe-change-checklist.md が納品前のクイックチェックリストです。