rollback-readinesslisted

## Purpose 「戻せないデータ変更」で本番を壊すリスクを防ぐ。 バックアップ・可逆性・検証手順を点検し、データ層の変更を安全に実行できる状態にする。 ## Use When - スキーマ変更・マイグレーションを実行する前 - 一括更新・一括削除・データ移行を行う前 - 「失敗したら戻せるか」を確認したいとき - failure-point-review / rollback-plan のデータ層版として使うとき ## Inputs 以下を準備すること。不足している場合は推測せず、不足を明示する。 - **対象変更**: 実行するデータ変更の内容 - **対象データ量**: 影響する件数・テーブル - **バックアップ状況**: 直近バックアップの有無・復元可否 - **許容ダウンタイム**: 復旧に許される時間 ## Output Contract 以下の順で出力すること。順序を変えない。 1. **論点**: この変更で最も戻しにくいのはどこか 2. **根拠**: その論点をそう判断した理由 3. **ロールバック準備チェック**: バックアップ / 可逆性 / 検証 / 手順 4. **含意**: 戻せない場合に起きること 5. **改善案**: 可逆性を高める手順（段階適用・シャドー書き込み） 6. **代替案**: より安全な変更方法（後方互換マイグレーション） 7. **判断材料**: 実行可否の判断に必要な人間の確認事項 ## Review Lens - **目的妥当性**: 変更が目的に対して最小の侵襲か - **範囲の過不足**: 一度に変えすぎていないか（段階適用の余地） - **中長期リスク**: 不可逆な変更（削除・型変更）の影響 - **LAB全体との整合性**: LMS / 自動化 / B2B 展開のデータ整合と矛盾しないか - **非エンジニア理解可能性**: 戻し方を関係者に説明できるか - **他LLM移植耐性**: 判断が特定 DB 製品の前提に依存していないか ## Instructions 1. 変更を「可逆 / 不可逆」に分類する（削除・型変更は要注意） 2. 直近バックアップの存在と復元手順・所要時間を確認する 3. 後方互換な手順（追加→移行→切替→削除）に分割できるか検討する 4. 適用前の検証（ステージング・ドライラン）の有無を確認する 5. ロールバックのトリガー（失敗条件）と手順を明文化する 6. 不明な点は推測せず、実行をブロックして明示する ## Guardrails - バックアップ・復元手段の確認なしに実行を勧めない - 不可逆変更（DROP・破壊的型変更）を軽視しない - 「たぶん戻せる」を「戻せる」と扱わない - 実行可否の最終判断は人間に委ねる ## LAB Cross-Check | 観点 | 状態 | 備考 | |---|---|---| | 自動化フロー | — | 自動化が走る最中の変更影響を確認したか | | データ / 認証 / ログ | — | バックアップ・整合性チェックを設計したか | | 実装 / 運用フロー | — | 復元手順を実運用で実行できるか | | 非エンジニア理解可能性 | — | 戻し��を関係者に説明できるか | | 会員共有 / 再利用耐性 | — | この準備手順が他の変更にも転用できるか | | 他LLM移植耐性 | — | 判断が特定 DB 製品に依存していないか | 状態は OK / 注意