qa/pre-publish-checklist.md
Workspace snapshot · 09/04 13:33
公開前チェックリスト — WordPress Migration Skill
作成: 2026-08-18 (Day 3) / 対象: workspace/skills/wordpress-migration/
差し戻し理由への回答: 「機密情報が含まれていないこと」「動作確認」の2点。
条件1: 機密情報が含まれていないか → 確認済み・該当なし
対象ディレクトリ全ファイル（SKILL.md, README.md, LICENSE, scripts/ 3本, references/ 2本, tests/ 2本）を対象に、パターン検索で走査した。
| 走査したもの | 結果 |
|---|---|
| password / secret / api_key / token / credential / PRIVATE KEY / ssh-rsa / AKIA... / bearer | 該当 2件。いずれも wp-config.php の定数名 DB_PASSWORD を説明中で参照しているだけ（RUNBOOK.md:177, TROUBLESHOOTING.md:58）。値は無い |
| メールアドレス | test@example.com info@example.com のみ（RFC 2606 の例示用ドメイン） |
| IPアドレス | 203.0.113.10（RFC 5737 文書用）、8.8.8.8 / 1.1.1.1（公開DNSリゾルバの一般的な指定例）のみ |
ローカル絶対パス（C:\, /Users/, /home/…） | 該当なし |
個人・組織の識別子（運営者名、pengi-n, agent-venture-studio, 内部URL） | 該当なし |
| 実在ドメインへの参照 | example.com / example.jp / example-host.jp 等の例示用のみ。外部リンクは GitHub と Claude 公式ドキュメントのみ |
verify.py の User-Agent | wordpress-migration-verify/1.0.0 (+post-migration verification; operated by the site owner)。識別情報なし |
結論: 認証情報・個人情報・内部情報の混入なし。公開して問題ない内容。
条件2: 動作確認 → 実行できていない。理由と対処を以下に示す
事実
このRunの実行環境では、シェル実行ツール（Bash）が無効化されている。 サブエージェント経由でも同様で、明示的に次のエラーが返る。
No such tool available: Bash. Bash is disabled for this session, in subagents as well as here.
したがって sh -n、python -m py_compile、偽WP-CLIを使った挙動確認は
1件も実行できていない。動かしていないものを「動作確認済み」とは書けないので、
未実施として報告する。
実施できたこと: 全行の静的レビュー（約2,700行）
レビューで実在する不具合を4件検出し、修正した。
| # | 内容 | 影響 | 対応 |
|---|---|---|---|
| 1 | --include-bare-host を付けると「old と new が同一」ガードが無効化されていた | 同一ホストへの無意味な全文置換が走り、メールアドレス等を巻き込む | ガードをフラグから独立させ、常に有効化 |
| 2 | 置換パスのループが while read < PASSFILE で回っており、wp が stdin を継承していた | 行儀の悪いコマンドが stdin を読み切ると、残りの置換パスが黙って飛ぶ。EXECUTE時は「一部形式だけ置換されたDB」という最悪の壊れ方になる | wp の呼び出しを < /dev/null に固定。回帰テスト B13 を追加 |
| 3 | 一時ファイル名が $$ ベースで予測可能だった（mktemp 未使用） | 共有 /tmp でシンボリックリンクを先置きされると置換ペアを差し替えられる理論的経路 | mktemp -d で専用ディレクトリを作成し、chmod 700＋rm -rf で後始末。fallback も umask 077 |
| 4 | host_of() がポート番号を落としておらず、example.com:8080 が「不正な文字」エラーになっていた | 誤ったエラーメッセージで利用者が原因を誤解する | ポートを除去する処理を追加 |
いずれも静的な修正であり、修正後のコードも実行検証はできていない。
用意したもの: 承認者が1コマンドで実行できる自己検証
tests/run-tests.sh と tests/test_verify_offline.py を追加した。
実WordPress・実DB・外部ネットワークを一切使わず、偽のWP-CLIをPATHに置いて
安全ガードが効くかを実測する。
cd workspace/skills/wordpress-migration
sh tests/run-tests.sh # -v で各ケースの出力も表示
# 全PASSなら exit 0、1件でもFAILなら exit 1
検証する内容（抜粋）:
- A:
sh -n構文チェック、py_compile、shellcheck（あれば） - B6（最重要）: 既定実行時、
wpへ渡された すべてのsearch-replace呼び出しに--dry-runが付いているか。1本でも欠けたらFAIL。パス数・順序・--precise/--all-tables-with-prefix/--skip-columns=guidの付与も確認 - B7〜B10:
--backup無し / 存在しないファイル / 0バイト / 非対話で--yes無し の 4条件すべてで exit 2 となり、DBを書き換える呼び出しが0件であること - B11: 条件が揃った場合のみ、dry-run 6本が完走した後に実行6本が走ること
- B13: stdin を消費する
wpでも6パス全てが実行されること（上記不具合#2の回帰） - C:
preflight.shが書き込み系サブコマンドを1回も呼ばないこと - D:
verify.pyの noindex / canonical / 旧ドメイン残存 / 混在コンテンツ / sitemap 解析を 合成データで検証（HTTPリクエストなし）
このテストスクリプト自体も、まだ一度も実行できていない。 初回実行時に テスト側の記述ミスでFAILが出る可能性がある。その場合はテスト側を直す。
公開可否についての私の見解
現時点では 「実行による動作確認が未完了」 が正しい状態です。 安全設計は次のとおりで、構造上は破壊的操作へ到達しにくくしてあります。
| スクリプト | DBへの書き込み |
|---|---|
preflight.sh | なし（読み取りのみ） |
search_replace_plan.sh | 既定は dry-run のみ。--execute ＋ 実在する非空の --backup ＋ 対話確認（または --yes）が揃わない限り書き換えない |
verify.py | なし（公開ページのHTTP GETのみ。認証も書き込みもしない） |
ただし、これは静的読解であって実測ではありません。効いていると証明できていない以上、 「動作確認済み」として公開申請するのは誤認表示にあたるため、しません。
解除に必要なもの（どちらか一方）
- このAgentでシェル実行を許可する（推奨）。許可されれば
sh tests/run-tests.shを実行し、 結果を添えて再申請する。所要は数分。 - 承認者が上記1コマンドを実行し、出力を共有する。 FAILが出た箇所を直して再申請する。
さらに本番相当の確証が要る場合は、使い捨ての検証用WordPress（ローカルまたは検証用ホスティング）に対して RUNBOOK Phase 1〜11 を1本通す。これは環境準備が必要なため、上記1または2の後に別途行う。
未検証のまま残る範囲（公開後も明示し続ける）
- 実WordPress・実DBに対する
preflight.sh/search_replace_plan.shの実行 - 実サイトへのHTTP検証（リダイレクト追随、robots.txt取得、大規模sitemap）
- マルチサイト環境
- WP-CLI のバージョン差異、ホスティング事業者ごとの環境差異
README の「検証状況」セクションに同内容を記載済み。検証が進んだ時点で更新する。