# LP実務ラボ：失敗時の復旧手順

## 原則

1. 問題が分からないまま追加修正を重ねない
2. 公開前なら公開せず、ローカルで原因を切り分ける
3. 公開後なら既知の正常な`site/`を再アップロードする
4. 秘密情報を公開した場合は、ページ差し替えだけで終わらせず認証情報を直ちに失効する

## A. ローカル表示が崩れた

1. 変更を止める
2. Claude Codeへ「ファイルを変更せず、直前の変更と表示崩れの原因候補を報告して」と依頼する
3. `index.html`と`styles.css`のどちらが原因か確認する
4. 修正内容を読んでから、対象箇所だけの修正を承認する
5. 幅390pxと1440pxを再確認する

Gitで正常版を保存済みなら、差分を確認してから対象ファイルを戻す。

```text
git status
git diff
git restore site/index.html site/styles.css
```

`git restore`は未コミット変更を破棄する。必ず専用ラボフォルダ内で差分を読み、戻してよい変更だけであることを確認してから実行する。

## B. 公開後のページが壊れている

1. 公開URLとローカル版の違いを確認する
2. ローカルに保存した既知の正常な`site/`を用意する
3. Cloudflare Pagesで新しいdeploymentとして正常な`site/`をアップロードする
4. 発行URLをシークレットウィンドウで開く
5. `VERIFICATION.md`を最初から再確認する

プロジェクト直下をアップロードしない。`BRIEF.md`、`CLAUDE.md`、検証記録を公開しないため、アップロード対象は`site/`だけにする。

## C. 誤った情報を公開した

1. 該当箇所をBRIEF.mdの正しい文言へ戻す
2. 実績、口コミ、価格、連絡先を全文検索する
3. 修正版を新しいdeploymentとして公開する
4. 公開URLで修正を確認する
5. 実サイトの場合は、影響範囲と公開時間を記録して責任者へ報告する

## D. 秘密情報を公開した

1. 公開ページの差し替えと並行して、漏れたAPIキー・パスワード・トークンを直ちに失効する
2. 利用ログを確認し、不正利用の有無を調べる
3. キャッシュ、過去deployment、検索インデックス等の残存範囲を確認する
4. 組織のインシデント対応手順に従う

削除や差し替えだけでは、既に取得された秘密情報を無効化できない。認証情報の失効を最優先にする。