# マイグレーション安全チェックリスト

## 説明
現在のPRに含まれるすべてのデータベースマイグレーションについて、プルリクエストを作成または更新する前に安全上の問題を確認する。

## 使用タイミング
PRの差分に `db/migrate/`（Rails）、`migrations/`（Django）、または `prisma/migrations/`（Prisma）内の新規ファイルや変更ファイルが含まれる場合に、このスキルを呼び出す。

## チェックリスト

### 1. 破壊的操作の検出
各マイグレーションファイルで以下を確認する：
- `DROP TABLE` または `drop_table`
- `DROP COLUMN`、`remove_column`、またはカラムの削除
- `TRUNCATE`
- 精度が失われるデータ型の変更（例：`text` → `varchar(50)`）

該当する操作が見つかった場合は、その操作を指摘するPRコメントを追加し、マイグレーション内にデータバックアップ手順が存在するかどうかを確認する。

### 2. 外部キーインデックスの確認
`add_reference`、`add_foreign_key`、または `_id` で終わる新しいカラムごとに、対応するインデックスが存在することを確認する。存在しない場合は、コミット前にマイグレーションへ追加する。

### 3. ロールバック安全性の確認
- テストデータベースに対して `bin/rails db:migrate:rollback STEP=<n>`（n = 新規マイグレーション数）を実行する。
- ロールバックが失敗した場合は、`down` メソッドまたは reversible ブロックを追加して再試行する。
- 元に戻せないマイグレーションがある場合は、PRの説明に記載する。

### 4. スキーマファイルの最新状態の確認
マイグレーション実行後、`db/schema.rb`（または `structure.sql`）をPR内のバージョンと差分比較する。差異がある場合は、スキーマファイルを再生成してコミットに含める。

### 5. モデルテストの実行
`bin/rails test test/models/` を実行し、スキーマ変更によって壊れたバリデーションやアソシエーションを検出する。PRを作成する前に、すべてのテストがパスしていなければならない。

### 6. Enforce migration naming conventions
Reject migrations that don't follow the pattern
`YYYYMMDDHHMMSS_verb_noun.rb` (e.g. `add_index_to_invoices`).
Rename the file if needed.

### 7. Check for long-running locks
Flag any `add_column` on tables with >1M rows that doesn't use
`disable_ddl_transaction!` (Postgres) or `ALGORITHM=INPLACE`
(MySQL). Large tables need non-blocking migrations.

### 8. Require a migration test
Ensure a corresponding test file exists at
`test/migrations/YYYYMMDDHHMMSS_migration_name_test.rb`.
If missing, generate a skeleton test that runs the migration
up and down.