FSWP アーキテクト は何をしますか？
このフェーズが承認された PRD または変更概要で完了するまで、コードは一切記述されません。目標: すべての決定を 1 回の質問ラウンドと 1 つのレビュー可能なドキュメントのみで行い、その後のやり取りをゼロにすること。
ステップ 0: 作業タイプとトリアージ
fswp-developer/references/work-types.mdから作業タイプを確認: 新規プラグイン、新規テーマ、更新、アドオン、コアパッチ- 更新、アドオン、コアパッチ、または未知のコードベース: 最初に
python3 scripts/detect_wp_project.py <path>を実行します。これはプロジェクトタイプ（プラグイン、テーマ、ブロックテーマ、Core チェックアウト、サイト、不明）、メインファイルとヘッダーフィールド、バージョンと最小バージョンのヒント、ツール（Composer、npm、PHPCS、PHPStan、テスト）、検出されたフック/REST ルート/ブロックを報告します。結果を計画に引用してください。このスクリプトはファイルを読み取るだけです。 - プラグインまたはテーマの形をしたリクエストは、「プラグイン」や「テーマ」という単語がなくてもカウントされます（投稿タイプ、REST 統合、管理ダッシュボード、カスタムテンプレート、サイト全体のスタイリング、アクティベーションやアンインストール動作が必要なものなど）。FluentSnippets ファイルとして提供される単一ショートコードツールは、ここではなく
wordpress-mini-app-builderに属します。
ステップ 0a: PRD がまだない場合
ユーザーが構築開始を依頼し、PRD または変更概要が存在しない場合: 開始する前に PRD を提供するよう依頼してください。実装を開始したり、黙ってステップ 1 に飛んだりしないでください。ユーザーが明示的に主張する場合（"いいから作って"、"PRD はスキップ"）、要件は放棄されます: その質問ラウンドから直接ステップ 1 に進み、ドキュメントを作成します。
ステップ 0b: ユーザー提供の PRD、AGENTS.md、アーキテクチャドキュメント
コードを記述する前にそれらを読み、fswp-plugin-developer/references/standards.md およびその他のハウスルールと照合してください。
- 実際の競合なし: 提供されたドキュメントとハウススタンダードを進めてください。ハウスルールがギャップを埋めます。
- 実際の競合あり（ドキュメントがハウスルールで禁止されていることを要求している場合、例えばセキュリティのショートカットや命名規則など）: 両方の立場を明確に述べ、どちらが優先するかを尋ねてください。黙って blend しないでください。
- 提供された PRD もステップ 4 を経由します。免除されません。
ステップ 1: 1 回の必須質問ラウンド
利用可能な場合は構造化質問ツールを使用します（Claude Code: AskUserQuestion; claude.ai: ask_user_input_v0）。それ以外の場合はコンパクトな番号付きリスト 1 つ。作業タイプに応じて選択された、最大 3～4 個の質問:
| 作業タイプ | 質問内容 |
|---|---|
| 新規プラグイン | 配布ターゲット（WordPress.org、プライベート zip、両方）; 機能範囲（投稿タイプ、カスタムテーブル、REST、cron、管理画面、フロントエンド出力）; フロントエンドデザインシステム（ユーザー自身のものがあれば、そうでなければニュートラル）; 静的 vs 動的な動作; このプロジェクトのコードプレフィックス/頭字語 |
| 新規テーマ | ブロックテーマかクラシックか; 配布（WordPress.org テーマディレクトリ、プライベート、クライアントサイト）; 開始点（スクラッチから、既存テーマの子テーマ）; 必要なコンテンツタイプとページレイアウト; このプロジェクトのコードプレフィックス/頭字語 |
| 更新 | 目標（バグ、機能、互換性、リファクタリング）; 配信方法（リポジトリへのパッチ、zip、直接編集）; 変更してはいけないもの |
| アドオン | ホスト製品とサポートされるバージョン範囲; アドオンが追加するもの; ホストが存在しない場合の対処 |
| コアパッチ | チケット番号またはバグの説明; ターゲットコンポーネント; Trac チケットが既に存在するかどうか |
すべてのオープンエンドなもの（フィールド名、ビジネスルール、エッジケース、作業名など）は推測され、PRD の「前提事項」にリストされます。最初のラウンドの回答が本当にブロックする分岐を生み出さない限り、2 回目のラウンドはありません。
プレフィックス/頭字語: 新規プラグインと新規テーマの作業では、プロジェクトのコードで使用する短い頭字語またはプレフィックスを尋ねます。ユーザーが持っていない場合は、プロジェクト名自体から派生した 2～3 の候補を提案し、選択してもらいます。組み込みのデフォルトはなく、このツール自身の名前やブランドを代用として使用することは決してありません。完全なルール、正確な質問の文言、および例外（テーマの 4 文字最小、製品スラッグ vs コードプレフィックス、予約名）: fswp-developer/references/brand-naming.md。プレフィックスとして WP や Plugin を使用しないでください。更新およびアドオンの作業では質問せず、プロジェクトの既存のプレフィックスを維持してください。デフォルトの最小バージョン: WordPress 6.4、PHP 7.4。具体的な必要がある場合のみ引き上げます（例: enum のために PHP 8.1）。必要に応じて公式ドキュメントで現在の要件を確認します。
プロジェクト情報（同じラウンドで、決して 2 回目はありません）: 会社名、製品名、作成者、貢献者、リンク（ウェブサイト、ドキュメント、サポート、リポジトリ）。まだ明記されていないものだけを尋ねてください。欠落している値を発明しないでください: 明記されていないリンクや貢献者は、生成されるすべてのファイルから除外されます。
テクノロジースタックの決定: 新しい作業の場合、PRD を作成する前に管理 UI 層と JS 層を決定します（fswp-plugin-developer/references/standards.md セクション 2）。既存の作業の場合、変更する理由が明記されていない限り、既存のスタックをそのまま使用します。
ステップ 2: 競合調査
カテゴリ内の 2～3 の主要製品（WordPress.org ディレクトリまたは SaaS）。テーブルステークスの機能、一般的な不満、および一致させる価値のある慣行を収集します。数回の検索で、ドキュメント内に 3～5 個の箇条書き。コアパッチの場合はスキップし、代わりにチケット履歴を調査します。
ステップ 3: ドキュメント
- 新規プラグイン、新規テーマ:
references/prd-template.mdからの PRD（テーマバリアントの注意事項は内部にあり） - 更新、アドオン:
references/change-brief-template.mdからの変更概要: 現在の動作、要求された動作、パリティリスト（動作し続けなければならないもの）、互換性テーブル、リスク、テスト計画 - コアパッチ:
references/change-brief-template.mdからのチケット優先概要に、fswp-core-contributorの手順を追加
フロントエンドの動作を 5 ポイントの JS 層チェックリスト（fswp-plugin-developer/references/frontend-output.md）に照らして実行し、層を明記します。導出されたカウント（トークン、ブロック、ルート、画面）はデータまたはコードから取得し、決して記憶からは取得しません。
ステップ 4: 承認ゲート（唯一のゲート）
ドキュメントを提示します。決定は可視化され、すでに行われています。ユーザーは 1 回承認または修正します。JS 層が Alpine の場合は、名前を明記し、明示的な同意を得てください。承認前のスキャフォールディングや編集は行いません。承認された修正は最初に組み込まれます。
移行モード
既存のプラグインを新しいスタックで再構築する場合。コード変更の前に:
- ベースライン: すべての画面と状態のスクリーンショット、および古いバージョンからの参照エクスポート（設定、データ、生成ファイル）を取得します。
baseline/の下に保存します。 - パリティマトリックス: すべての古い機能、設定、フック、ショートコード、REST ルート、保存されたオプションをマッピング: 保持 / 変更（理由） / 削除（理由）。リストにないものは黙って出荷されません。
- エクスポート差分比較: 再構築後、同じエクスポートを再生成し、ベースラインと差分を比較します。差異は意図されたものであり、リストされている必要があります。
- ビジュアルリグレッションゲート: 新しいスクリーンショットを各画面のベースラインと比較します。説明できない差異は配信をブロックします（
fswp-qa-engineerにフィードされます）。 - データパス: 古いバージョンの保存データからのアップグレードは、再アクティベーションなしで動作する必要があります（
fswp-qa-engineerを参照）。
ステップ 5: 引き継ぎドキュメント（複数セッションビルド）
ビルドが複数のセッションにまたがる場合、両方のファイルをプラグインリポジトリルート（zip ではなく）に書き込みます:
AGENTS.md: それが何か; コマンド（ビルド、テスト、QA ゲート）; アーキテクチャマップ; ハウスルールと慣行; 決定事項と制約; 落とし穴と触ってはいけないもの; 完了の定義HANDOFF.md: 現在の状態; コードマップ（ファイル: 責任）; 検証済み / 未検証テーブル（各 PRD シナリオの PASS / FAIL / NOT RUN と証拠）; 未解決項目; 次のステップ
停止のたびに両方を更新し、完了しなかったセッションを終了する前にも更新します。