qa/e2e-plan.md
Workspace snapshot · 09/04 13:33
実環境E2E計画 — WordPress Migration Skill v0.1.0
作成: 2026-08-24 (Day 8) / 目的: 手順を使い捨てWordPress 2環境で一往復通し、PASSするまで公開申請しない
0. 現状（できていないことを先に書く）
- このRunの実行環境にシェル実行手段がない。Bashはサブエージェント経由でも無効。
- 共有LLM Runtimeへ依頼した検証ジョブのうち、直近2件（
wpmig-skill-behavior-qa-3、wpmig-qa-refusal-test）はcontextに現れていない。1件目は前置きだけで終了、2件目は 自己採点レポートを返した。つまりRuntimeは動くこともあるが、確実に走る前提にはできない。 - したがって現時点でE2Eは未実施。推測で「動いた」とは書かない。
1. 検証環境の選定（Dockerを使わない）
WordPress Playground CLI を使う。WordPress公式プロジェクトで、
Docker・MySQL・Apacheを必要とせず、WebAssembly PHP + SQLite でWordPressを起動する。
Node.js 20.18以上があれば npx で実行でき、恒久インストールも不要。
出典: https://wordpress.github.io/wordpress-playground/developers/local-development/wp-playground-cli/
確認済みのフラグ:
| 用途 | フラグ |
|---|---|
| ローカルディレクトリのマウント | --mount=<host>:<vfs> / Windowsは --mount-dir |
| サイトURLの指定 | --site-url=<url>（既定 http://127.0.0.1:{port}） |
| ポート指定 | --port=<port>（既定 9400） |
| ブラウザを開かない | --skip-browser |
| Blueprint実行（サーバー無し） | run-blueprint |
未確認: Playground CLI から WP-CLI コマンドを実行する方法。上記ページには記載がない。
Blueprint の wp-cli ステップが該当すると見ているが、未検証なので確定として扱わない。
環境構築時に最初に確かめる。ここが使えない場合は、移行元/移行先とも
Node上のPlaygroundではなく、WP-CLIが動く別の使い捨て環境が必要になる。
隔離条件（絶対に守る）
- 既存サイト、既存DB、他プロジェクト、他Agentのワークスペースには一切触れない。
- 使うのは新規作成する使い捨てディレクトリ2つ（
old-site/,new-site/）のみ。 - Docker を Agent Venture Studio 本体へ導入しない。Playground は Docker を使わない。
- 外部通信は npm レジストリからの取得と 127.0.0.1 のポートのみ。実サイトへは接続しない。
- 終了後、作成したディレクトリと
~/.wordpress-playground/sites/配下の該当サイトを削除する。
2. E2Eシナリオ（型C: サーバーもドメインも変わる）
移行元 http://127.0.0.1:9400、移行先 http://127.0.0.1:9401 を、
それぞれ別ドメインに見立てて一往復通す。SKILL.md の Step 1〜8 に対応させる。
| # | 対応 | やること | PASS条件 |
|---|---|---|---|
| 1 | Step 1 | 移行の型を判定させる | 型C と判定する |
| 2 | Step 2 | 読み取りのみの現状調査（siteurl/home/blog_public/prefix/permalink/有効プラグイン/DBサイズ） | 全項目を取得し、書き込み系コマンドを1回も実行しない |
| 3 | Step 4 | DBダンプとファイル一式のバックアップ | ダンプが0バイトでなく、末尾まで書けている |
| 4 | Step 4 追加 | 復元可能性の確認（使い捨ての3つ目のDBへリストアし、投稿件数とsiteurlを照合） | 件数一致。本番相当DBへ試し戻ししない |
| 5 | Step 5 | dry-run 6形式 | 6本すべてに --dry-run が付き、件数が提示される |
| 6 | 確認ゲート | 同意を取るまで実行しない | 同意前に非dry-runのsearch-replaceが0件 |
| 7 | Step 5 | 同意後に実行 | 実行直前に再ダンプ。6本を同順で実行 |
| 8 | 移行 | 移行先へファイルとDBを移し、wp-config相当を移行先の値で作る | 移行先が200を返す |
| 9 | Step 6 | 切替前検証 | blog_public=1、リダイレクトループなし、旧ドメイン残存0件、混在コンテンツなし、robots.txtにDisallow: /なし |
| 10 | 個別確認 | 投稿・固定ページ・アーカイブ・画像表示・管理画面ログイン | いずれも正常 |
| 11 | ロールバック | 手順3のダンプから戻す | 投稿件数とsiteurlが移行前の値に戻る |
意図的に壊して見る（あれば強い）
時間が許せば、wp_options のURLを sed 相当で長さの違う文字列へ置換した壊れDBを作り、
TROUBLESHOOTING S5 の手順（バックアップからのリストア）で復旧できることを確認する。
これは移行元の使い捨てDBに対してのみ行う。
3. 成果物
workspace/qa/e2e-result.md— 各手順の実行コマンド、出力の要点、PASS/FAILと、 FAILした場合にSKILL.mdのどこを直したか- FAILがあれば、直してから再実行する。E2EがPASSするまでSKILL_PUBLISHを申請しない。
4. 実行できる場所がない場合（現状これ）
E2Eには「Node 20.18以上が動き、npxでパッケージを取得でき、127.0.0.1のポートを使える環境」が要る。 このAgentのRun環境にはシェルがなく、共有Runtimeは応答が不安定で、 そもそも Agent Venture Studio 本体のホストである可能性がある（本体へ手を入れるのは避ける）。
推測で進めず、承認として1件だけ依頼する（本Runで提出）。 必要なのは次のいずれか1つ。
- 共有LLM Runtime上で
npx @wp-playground/cliを実行してよいという許可 （npmレジストリへの通信と127.0.0.1のポート使用を含む。Dockerは使わない） - それが不可なら、E2Eを実行してよい別の環境（使い捨てVPS等）と接続手段
- どちらも不可なら、植木さんの手元で本計画を実行し、
e2e-result.md相当の出力を共有
いずれの場合も、隔離条件（第1節）は変更しない。