rollback-planlisted

## Purpose 「失敗した後に何をすればいいかわからない」を防ぐ。 実装着手前にロールバック手順を設計し、失敗時の混乱と復旧コストを最小化する。 ## Use When - 実装・デプロイ・DB マイグレーションの前 - 「失敗したらどうするか」が未定義のままタスクが進んでいる場合 - ホットフィックス・緊急パッチの前 - 新しい依存関係（ライブラリ・外部サービス）を導入する前 ## Inputs 以下を準備すること。不足している場合は推測せず、不足を明示する。 - **実装・変更内容**: 何をするか（コード / DB / 設定 / インフラ） - **変更範囲**: 変更するファイル・テーブル・API・環境変数 - **現在の状態**: 変更前の状態（ブランチ / DB スキーマバージョン / デプロイバージョン） - **外部依存**: 変更に伴う外部サービス・API の変更（Stripe / Supabase / Vercel 等） - **許容ダウンタイム**: ロールバック中に受け入れられる最大停止時間 ## Output Contract 以下の順で出力すること。順序を変えない。 1. **論点**: このロールバック設計を左右する核心的な判断軸 2. **根拠**: その論点をそう判断した理由 3. **ロールバック手順**: 段階別の具体的な手順 4. **含意**: ロールバック可能性の高さ/低さが示す設計上のリスク 5. **改善案**: ロールバックコストを下げるための変更設計上の工夫 6. **代替案**: 完全ロールバックが不可能な場合の部分ロールバック・補償手順 7. **判断材料**: 「このロールバック計画で進む / 計画を強化する / 変更設計を見直す」を選ぶための情報 ### ロールバック手順 フォーマット | ステップ | 操作内容 | 実行者 | 確認方法 | 所要時間概算 | |---|---|---|---|---| | 1 | （例: git revert / feature flag OFF） | AI / 人間 | （確認コマンド・URL） | （分） | | 2 | （例: DB マイグレーションのロールバック） | AI / 人間 | | | | 3 | （例: 環境変数の切り戻し） | AI / 人間 | | | | 4 | （例: 動作確認） | AI / 人間 | | | ロールバック不可能な操作（例: 不可逆 DB 変更、外部サービスへの通知）は「補償手順」として別途記載する。 ## Review Lens - **目的妥当性**: ロールバック手順が実際の変更に対して実行可能か - **範囲の過不足**: 外部サービス（Stripe / Supabase）の状態変更が含まれているか - **中長期リスク**: ロールバック後に一時的に整合性が失われる期間がないか - **LAB全体との整合性**: Vercel / Supabase の具体的なロールバック方法が含まれているか - **非エンジニア理解可能性**: ロールバック手順を非技術者が実行できるか - **他LLM移植耐性**: 手順が Claude 固有の解釈に依存していないか ## Instructions 1. 変更を「コード / DB / 設定 / 外部サービス」に分類する 2. 各分類ごとにロールバック方法を具体的に記述する（コマンド・操作を含む） 3. 手順に依存関係がある場