ethanplusai/astro-conversion-kit

post-launch（ポストローンチ）

監視。DNSが移行した瞬間から、その後30日間、1日1回実行されます。報告のみを行い、決してゲート（ブロック）したり、修正したり、何かを通知したりしません。

唯一のルール

ブロッカーは最初に読み、最後にアナウンスする。 ローンチに関する何も（メール、投稿、クライアントへの電話）は、このレポートがクリーンになるまでアナウンスされません。アナウンスはローンチのステップの中で唯一、取り消しが効かないものです。そして、ここでの2つのブロッカーはまさに、ローンチが実際に完了していない状態を示しています。それは「誰も通過できない証明書」と「検索エンジンにサイトを忘れるよう指示するnoindex」です。どちらも、すでにログインしているブラウザでは問題なく見えてしまいます。

もし誰かがブロッカーが存在する状態でアナウンスを依頼してきたら、ブロッカーが何であり、それがもたらすコストを明確に述べ、言葉を和らげてはいけません。

読み取り専用

このスキルは読み取り専用です。ライブサイト、ステージングホスト、旧ホスト、およびリダイレクトマップ内のURLを取得し、4つのパブリックDNSリゾルバにドメインのポイント先を問い合わせます。書き込むものは2つだけで、どちらもオペレーター自身の記録です：レポートバンドルと、その中の watch.json です。サイトを編集したり、フォームを送信したり、設定を変更したり、プロバイダーAPIを呼び出したり、DNSに触れたりすることは決してありません。

以下の3つのルールに従い、報告時にもこれらのルールを再提示します。

1. すべての結果に対するエビデンス。 URL、ステータス、ヘッダー、DNS応答、CSVの1行。
2. スキップは合格ではない。 提供されなかったすべての入力は、「対象外」 という名前の行になります。
3. 「対象外」は決して合格ではない。 そのセクションを人間にそのまま繰り返します。

2つのモード

モード	実行タイミング	回答する内容
--mode cutover	DNSが移行した瞬間、および修正後	ローンチは実際に発生したか
--mode watch	1日1回、1〜30日目	今日の期限は何か、何かドリフトしていないか

cutover を最初に実行し、見つかった問題を修正し、クリーンになるまで再実行し、その後アナウンスします。同日に監視を開始します。

1. 入力を収集する

省略した入力ごとに、実行できないチェックが発生します。それぞれを確認し、推測しないでください。

• 本番環境のURL。 必須。
• baseline.json — pre-launch バンドルから、またはカットオーバー前にステージングに対して実行した launch-audit から取得します。これが「何か変わったか」を測定する基準です。これがない場合、4つのチェックは比較対象がなくなり、5つ目のチェックは --expect-analytics にフォールバックします。それらはすべて、その旨を明記します。
• redirects.csv — --old-url を指定して構築された launch-audit バンドルから取得します。すべての行は、それが記述されたURLで再リクエストされます。
• 置き換えられる旧サイトのURL。 （置き換えがある場合）
• ステージングURL。 ステージングコピーが封印されたことを確認するため。
• アナリティクス測定ID。 ベースラインがない場合に使用します。
• 設定されるべきだったDNSレコード。 apex= および www= の値として指定します。

ベースラインまたはリダイレクトマップがない場合は、実行前ではなく実行前にその旨を伝えてください。これらは以前の2つのフェーズから生成されるものであり、カットオーバー後は再作成できません。

2. カットオーバーチェックを実行する

スクリプトを実行してください。ソースを読んだり、その機能を再実装したりしないでください。

node scripts/post-launch.mjs --mode cutover --url <本番URL> \
  --baseline <baseline.jsonへのパス> --redirects <redirects.csvへのパス> \
  --old-url <旧サイトURL> --staging-url <ステージングURL> \
  --expect-analytics <測定ID> --expect-dns apex=<IP>,www=<ホスト> --out <ディレクトリ>

パスはこのスキル自身のディレクトリからの相対パスです — そのディレクトリからコマンドを実行してください。バンドルはカレントワーキングディレクトリの下に書き込まれます：--out を指定しない場合、./website-launch/<ホスト>-post-launch-<日付>/ に配置されます。上記のコマンドでは、これはこのスキルのディレクトリ内になります。--out を使用して、作業が存在する任意の場所にバンドルを書き込んでください。

その他のフラグ：--dev-host <ホスト>（繰り返し可）、--browser auto|on|off、--out <ディレクトリ>、--config <パス>、--json、--help。

終了コード： カットオーバーがどれほど悪くても、常に 0。使用方法のエラーまたはIO障害の場合は 2。終了コード0が「ローンチは正常」を意味することは決してありません — これは報告であり、ゲート（ブロック）ではありません。レポートを読んでください。

3. この順序でレポートを読む

references/reading-the-report.md にバンドルのレイアウトがあります。references/cutover-day.md は、その日の実行がなぜこの順序で行われるかを説明しています — 問題を順序を無視して修正し始める前に読んでください。

1. ブロッカー。 太字で表示され、その日のどのステップで発生したかに関わらず最初に表示されます。これらを他のすべてよりも先に、そして誰かにサイトがライブであると伝えるよりも先に修正してください。
2. 高重要度の結果。 リダイレクトのドリフト、欠落したページ、動作しないフォームエンドポイント、ライブのステージングコピー、まだサービスを提供している旧ホスト — これらはそれぞれ、今まさにトラフィックや問い合わせを失っているものです。今週ではなく、今日の作業です。
3. ベースラインとの差分。 references/baseline-diff.md は、ローンチ時に移動することが予想されるフィールドと、決して移動すべきでないフィールドを示しています。差分全体を損傷として報告するのではなく、誰も依頼していない部分のみを報告してください。
4. 中重要度および情報。 読んでください。内容を説明してください。今日は修正しないでください。
5. 「対象外」、そのまま。 すべての行、無編集で、クロールでは確認できない2つの項目も含めて。

その後、再実行し、ブロッカーがなくなるまで再実行を続けてください。

4. 6つの人的項目を処理する

これらは毎回の実行の最後に出力され、オプションではありません：

サイトマップを送信する（Search ConsoleとBing）   ·   トップページのインデックス登録をリクエストする
新しいSearch Consoleプロパティを確認する        ·   リアルタイムでアナリティクスを確認する
旧ホストを維持し、リダイレクトし続ける           ·   これがクリーンになってからアナウンスする

誰かの代わりにチェックを済ませたと報告しないでください。「エンドポイントが200を返した」は「人がテスト送信を受け取った」とは異なり、「タグがHTMLにある」は「リアルタイムでヒットが表示された」とは異なります。

5. 毎日監視を実行する

node scripts/post-launch.mjs --mode watch --url <本番URL> --day <n>

これにより、期限切れのタスク、今日期限のタスク、今後7日以内に予定されているタスクが表示され、自動部分が再実行され、実行結果が記録されます。references/thirty-day-watch.md には、全スケジュール、各日にSearch Consoleとアナリティクスで確認すべきこと、および「正常」とはどのような状態かを示す指標が記載されており、通常のローンチ後の落ち込みを災害として報告しないようにします。

--day を省略すると、最初の実行からの日数がカウントされます。監視が一度も実行されなかった日がある場合、自動タスクはそれをカバーする実行が行われるまで期限切れのままです。人的タスクは、人間がクリアするまで期限切れのままです。なぜなら、スクリプトが行ったことは誰かがSearch Consoleを開いたという証拠にはならないからです。

6. 30日目

2つのことがあり、どちらも自動化されていません：

• 振り返り。 何が後退したか、リダイレクトマップが見逃したもの、そして次のローンチで同じことを繰り返さないために pre-launch ゲートに追加すべきもの。書き留めてください。
• 旧ホストの廃止判断。 旧ホストは、Search Consoleに古いURLのクロールが表示されなくなり、かつリダイレクトが少なくとも30日間有効になってからでなければ、廃止してはいけません。両方が真になるまで、ホスト費用を支払い続けてください。早期に停止すると、旧サイトが獲得したすべてのリンクを失うことになります。

7. 結果を提示する

数ではなく、判断から始めてください。

1. 判定。 「カットオーバーには1つのブロッカーがあります」または「カットオーバーはクリーンです」。一文で。
2. 何がブロックしているか、修正方法を明記して。
3. 何が問題を引き起こしているか、原因別にグループ化：高重要度の結果、平易な言葉で。
4. ベースラインと比較して何が変わったか、誰も依頼していないもの。
5. 「対象外」、そのまま。
6. 人的項目、完了したものとそうでないもの。
7. ローンチをアナウンスしてよいか。 明示的に、どちらかの方法で述べてください。

決して実行されない2つのチェック

• コピー vs. ソース文書。 ライブページの文言と承認済みのコピーを比較するものはありません。人間が両方を読む必要があります。
• ページ vs. 合意されたスコープ。 どのページが存在するべきかを知るものはありません。構築されなかったページはここでは見えません。

リファレンス

ファイル	内容
references/cutover-day.md	日の順序付けられたスクリプト、および各ステップがその位置にある理由
references/thirty-day-watch.md	スケジュール、Search Consoleとアナリティクスで読むべきもの、正常な状態、旧ホストルール
references/baseline-diff.md	すべての差分フィールド、ローンチ時に変更が予想されるものとそうでないもの
references/reading-the-report.md	バンドル、重要度、ID、トリアージ方法

このスキルの位置づけ

pre-launch はデプロイ前にリポジトリをゲート（ブロック）します。launch-audit はステージングまたはライブURLをクロールし、報告します。post-launch はこれです：カットオーバーとその後の30日間。この順序で実行してください — このスキルに必要なベースラインとリダイレクトマップは、最初の2つによってのみ、そして旧サイトがまだ稼働している間にのみ作成できます。