fix

fix（オプトイン方式の書き込み）

disable-model-invocation: true は、モデルがこれを自発的に実行することは決してないという意味です。実行できるのは、ユーザーが /claude-seo-ai:fix を実行した場合のみです。書き込みは seo-fixer-writer サブエージェント（Write/Edit を持つ唯一のエージェント）を通じてのみ行われ、明示的な確認を得てから実行されます。

--category はレポートの検出結果を絞り込み、検出結果のモジュール ID（M5、M7、M17、…）、軸（search、ai、both — both は前の 2 つの両方に一致します）、修正可能クラス（auto、proposed、advisory）、またはスコープ（page、site、…）に対して、大文字と小文字を区別せずに照合します。トピックの語彙ではなく、カンマ区切りにも対応していません。フィルターを広げるには、フラグを繰り返してください（--category M5 --category M17）。ユーザーの依頼をこれらの語に置き換えてください。「スキーマを修正して」は --category M5、「安全なものだけ」は --category auto です。適用したフィルターも伝えてください。 --target には、アダプター ID に加えて、エイリアス local、shopify、wordpress、manual と、プロバイダー名 webflow／wix／ghost／hubspot／bigcommerce を指定できます（いずれも page-api に展開されます）。

何よりも先に、以下の絶対ルールを守ってください。

• 記憶を頼りに修正してはいけません。 すべての変更は、ディスクに保存された report.json に基づきます。このターゲットのレポートがない場合は、先に監査を実行してください。トランスクリプトから検出結果を再構成してはいけません。
• 書き込みは決して行いません。 このスレッドで実行するのは読み取り専用の操作（capabilities、plan、preview、verify）です。apply、publish、rollback はライターサブエージェントの担当であり、いずれもチケットが必要です。

修正可能クラス（各検出結果の fixable フィールドに基づきます。schema/finding.schema.json を参照）

• AUTO — 決定論的で、追加のみを行い、機械で検証でき、意味上のリスクが低いものです。差分と確認を得たうえで書き込めます。メタの viewport／charset／<html lang>、Tier-1 JSON-LD ブロック、（確認済みの入力のみを使った）sameAs／@id／dateModified、AI クローラー向けの robots.txt プリセットと Sitemap: 行、自己参照型 canonical、hreflang リンクセット、OG/Twitter カード、画像の width／height、XML サイトマップのエントリ、llms.txt（開示条件付き、スコア 0）。
• PROPOSED — 文章または意味を変更するものです。差分を作成し、項目ごとの承認を必須とします。生成された <title> とメタディスクリプション、回答ブロック／TL;DR の書き換え、内部リンクの挿入、見出し構成の変更、生成された画像の代替テキスト。
• ADVISORY — 書き込みは決して行いません。コンテンツ／E-E-A-T の書き換え、統計や引用の追加、Core Web Vitals、レンダリング戦略、リダイレクト／ステータスコード、リンク構築、Merchant Center／GBP のバックエンドデータ。

各ステップのセットアップ

DATA="${CLAUDE_SEO_AI_HOME:-${CLAUDE_PLUGIN_DATA:-$HOME/.claude-seo-ai}}"
SCRIPTS="${CLAUDE_PLUGIN_ROOT}/scripts"

以下の各コマンドは node "${CLAUDE_PLUGIN_ROOT}/scripts/<x>.mjs" … の形式で、--data "$DATA" を指定します。 認証情報をフラグとして渡すことは決してありません。アダプターは環境変数から CLAUDE_PLUGIN_OPTION_<KEY>、次に <KEY> の順で読み取ります。キーが不足している場合は、そのキー名を伝えてください。ここに値を貼り付けるようユーザーに求めてはいけません。

フロー

0. 解決して早期終了する。 DATA と SCRIPTS を解決します。--rollback <run_id> が指定されている場合は、ほかの処理をすべてスキップします。<DATA>/fix/runs/<run_id>/manifest.json を読み取り、復元される内容（<DATA>/backups/<run_id>/ のファイル、before/*.json のペイロード、公開済みテーマの previous_live_id）を提示して確認を得た後、ライターに各アダプターの rollback --all を実行させます。報告して終了します。

1. レポートを読み込む — 記憶を頼りにしない。 --report <path>、それがなければ --run <id>、それもなければ、このターゲットの <DATA>/runs/<host>/latest にある最新の実行結果を使います。report.json（検出結果、スコア、ターゲット）と、その隣にある profile.json を読み取ります。レポートが見つからない場合、または generated_at が 24 時間より前の場合は、その旨を伝え、先に /claude-seo-ai:audit を再実行することを提案してください。ユーザーが指示するまでは、古いレポートを使って続行してはいけません。 2. プラットフォームプロファイルを確認します。 profile.platform、profile.framework、 profile.capabilities、profile.write_targets を読み取ります。プラットフォームの確信度が high 未満の場合、または --target auto で複数の書き込み先が候補に残る場合は、検出内容（シグナルを含む）を提示し、 ユーザーに確認するか、--target で上書きするよう求めます。誤ったプロファイルを選ぶと、誤った対象に書き込みます。

3. アダプターを選択し、準備状況を確認します。 選択ルールは次の順です。

• ローカルパスのターゲット（または --project <dir>） ⇒ local-files に加え、ソースツリーが所有しないリソースごとのフィールドに対応するプラットフォームアダプター。
• shopify ⇒ shopify-theme + shopify-admin。
• wordpress ⇒ 認証情報があり、SEO プラグインが書き込みを公開している場合は wordpress-rest、そうでなければ --ssh/WP_SSH が設定されている場合は wordpress-wpcli、それ以外は instructions。
• webflow / wix / ghost / hubspot / bigcommerce ⇒ キーがある場合は page-api、それ以外は instructions。
• squarespace / framer / unknown ⇒ instructions。

各アダプターについて、node "${CLAUDE_PLUGIN_ROOT}/scripts/adapters/<adapter>.mjs" capabilities --data "$DATA" を実行します。 不足しているキーは名前のみを列挙し、入力するには claude-seo-ai の /plugin を実行するか、Claude Code を起動するシェルで環境変数に設定するよう案内します。キーが不足しているターゲットは instructions に降格しますが、実行が停止することはありません。

4. 計画します。 1 回の呼び出しで計画全体を作成します。

node "${CLAUDE_PLUGIN_ROOT}/scripts/fix-plan.mjs" --report <report.json> --profile <profile.json> \
  --targets <a,b> --run <run_id> [--category …] [--include-proposed] [--answers <json>] \
  [--project <dir>] [--dev-url <u>] [--lang en|es] --data "$DATA"

<DATA>/fix/runs/<run_id>/ に plan.json と manifest.json を書き込み、ターゲットごとにまとめた概要を返します。未解決の現実世界の入力（ロケールマップ、sameAs プロフィール URL、robots のプリセット、リダイレクト先、公開日など）は、チャットで質問し、--answers で渡します。 決して推測で補わず、TODO:<field> プレースホルダーを一切書き込みに含めないでください。

5. プレビューします。 変更ごとに preview --run <dir> --change <id> を実行します。出力をターゲットごとにまとめ、すべての変更に live_impact のバッジを付けます。[none]（ファイルまたはステージング済みテーマ）、[staged]（下書き／未公開の対象に書き込まれ、訪問者には見えない）、[LIVE]（即座に表示される）のいずれかです。ファイルの場合は統合差分、API ペイロードの場合はリクエスト + 変数 + before の値、CLI 操作の場合は正確なコマンドを表示します。Shopify テーマの変更には theme check の結果も含まれ、エラーがある場合は適用できません。

6. --dry-run で停止します。 概要を表示し、何も書き込まれていないことを明言して終了します。デフォルトではドライランとして扱います。ユーザーが適用を明確に求めていない場合は、ドライランとして実行します。

7. 確認を得てから、チケットを発行します。 変更ごとに確認するか、ユーザーが一括で受け入れられるようにするかは、ユーザーが選びます。確認時には、受け入れる内容の live_impact を明示する必要があります。確認された変更ごとに、確認と同じターン内で次を実行します。

node "${CLAUDE_PLUGIN_ROOT}/scripts/fix-ticket.mjs" issue --command "<the exact apply command>" \
  --run <run_id> --change <chg_id> --data "$DATA"

チケットは一度だけ使用でき、有効期限は 15 分です。確認済み ID を manifest.json.confirmed に記録します。ユーザーが直前に受け入れていない変更や、ユーザーに提示していないコマンドについて、チケットを発行してはいけません。

8. 書き込み処理を 1 回だけディスパッチします。 JSON エンベロープを使って Agent(seo-fixer-writer) を 1 回呼び出します。エンベロープには RUN_DIR、SCRIPTS_DIR（絶対パスの ${CLAUDE_PLUGIN_ROOT}/scripts）、DATA、PROJECT_ROOT（ローカルターゲット）、confirmed_change_ids[]、変更ごとのチケット ID を格納する tickets、デフォルトが false の publish、force、lang、および return: "JSON array of findings only" を含めます。--publish には2 回目の確認と、公開コマンド専用のチケットが必要です。公開によってステージング済みの作業が表示されるため、適用確認に公開を含めてはいけません。

9. 検証します。 適用した変更ごとに verify --run <dir> --change <id> [--dev-url <u>] を実行し、さらに検出結果自体の verification.reproduce を確認します。結果を正直に読み取ります。CDN やページのキャッシュが古い場合は合格ではなく、pending_cache とします。開発サーバーのないローカルフレームワークターゲットはソースレベルでのみ検証できます。「ソースを検証済み。デプロイ後に再監査してください」と伝え、公開ページの問題が修正済みだと主張してはいけません。 10. レポート。 変更・対象・live_impact・ステータス・検証をまとめた表に続けて、ステージング済みで未公開の内容、キャッシュに関する注意事項、ロールバックコマンド （/claude-seo-ai:fix --rollback <run_id>）、次の手順（公開、再監査、ユーザーがクリックして完了する残りの instructions 項目）を示します。

対象の形式

• URL のみ（--project なし）：local-files は選択しません。編集できるソースツリーがないためです。フレームワークサイトでは、プラットフォームアダプターを通じてリソースごとの修正を行い、それ以外はすべて instructions で案内します。また、ソースを編集する場合は --project <dir> を指定して再実行するよう提案します。
• ローカルのフレームワークプロジェクト：監査は http://localhost:3000 またはビルド済みの出力に対して実行された可能性がありますが、修正では route-map（ルートからファイルへのマッピング）を通じてソースを編集し、--dev-url で稼働中の開発サーバーを再取得して検証します。3 つのうち、どれを検証したかを明記します。
• API キーのないホスト型ビルダー：instructions は、値を入力済みの正確なクリック手順を --lang en|es で表示します。これは失敗ではなく、実際の成果です。

安全性（必須ルール）

• デフォルトはドライランです。 書き込みには、ユーザーからの依頼と変更の確認が必要です。
• Git を考慮します：--force が指定されていない限り、作業ツリーに未コミットの変更がある場合は書き込みを拒否します。git status --porcelain で確認し、seo-fix/<date> ブランチを優先します。
• 最初にバックアップを作成します：ローカルファイルは <DATA>/backups/<run_id>/<relpath>、リモートリソースは <RUN_DIR>/before/<change_id>.json に保存し、Shopify はテーマ全体をコピーします。--rollback <run_id> は、これらのバックアップからのみ復元します。
• 冪等性を確保します：各変更にはマーカーまたは存在確認を設けます。再実行時には重複したブロックを追加せず、skipped_idempotent になります。
• デフォルトでは本番に反映しません：Shopify は未公開のテーマに反映し、Webflow/HubSpot はステージング状態を維持します。WordPress では status も投稿内容も変更しません。Wix ではエンドポイントの要件で必要な場合を除き、publish:false を設定します。[LIVE] と記載する場合は、依頼を求める前にその旨を伝えます。
• .git/、.env*、ロックファイル、鍵などの機密情報、wp-config.php、Shopify の config/settings_data.json には決して触れません。guard-write フックと guard-bash フックがそれぞれ独立して適用します。
• 認証情報：環境変数のみを使用し、argv に含めず、表示せず、リポジトリ内のファイルにも書き込みません。ログ内のコマンドは秘匿化します。
• 捏造しません：統計、引用、価格、評価、本人確認用リンクを作り出さず、dateModified を過去の日付に設定しません。