migraguard 0.0.1

package/COMMANDS.md

@@ -0,0 +1,100 @@
+# migraguard commands
+
+## Migration management
+
+### `migraguard new <name>`
+
+Create a new migration SQL file with a UTC timestamp prefix.
+
+```bash
+migraguard new add_users_email_index
+# → db/migrations/20260301_120000__add_users_email_index.sql
+```
+
+### `migraguard squash`
+
+Squash multiple new (unrecorded in metadata.json) migration files into a single file. Run before merging to a release branch.
+
+```bash
+migraguard squash
+```
+
+### `migraguard apply`
+
+Apply pending migrations to the target DB via `psql`. Checks `schema_migrations` table for applied/failed/skipped status.
+
+```bash
+migraguard apply
+migraguard apply --verify   # verify schema dump before and after
+```
+
+### `migraguard resolve <file>`
+
+Mark a failed migration as skipped. Use when a subsequent forward migration covers the fix. Requires human judgment.
+
+```bash
+migraguard resolve 20260301_093000__add_user_email.sql
+```
+
+### `migraguard status`
+
+Show the status of all migration files: applied, pending, failed, or skipped. Requires DB connection.
+
+```bash
+migraguard status
+```
+
+### `migraguard editable`
+
+List migration files that are currently editable (modifiable and re-appliable). In the linear model this is the latest file; in the DAG model these are leaf nodes. With DB connection, also shows failed files eligible for retry.
+
+```bash
+migraguard editable
+```
+
+## Integrity checks
+
+### `migraguard check`
+
+Verify file integrity against metadata.json. No DB connection required. Detects: checksum mismatches on non-latest files, mid-sequence insertions, and multiple new files (enforces squash).
+
+```bash
+migraguard check
+```
+
+### `migraguard lint`
+
+Run Squawk lint on migration files to detect idempotency and safety rule violations.
+
+```bash
+migraguard lint
+```
+
+## Schema management
+
+### `migraguard dump`
+
+Dump the current DB schema via `pg_dump --schema-only`, normalize it, and save as `schema.sql`.
+
+```bash
+migraguard dump
+```
+
+### `migraguard diff`
+
+Show the diff between the current DB schema and the saved `schema.sql`.
+
+```bash
+migraguard diff
+```
+
+## Dependency analysis (extension)
+
+### `migraguard deps`
+
+Analyze and display the dependency graph between migration files.
+
+```bash
+migraguard deps
+migraguard deps --dot   # output in DOT format for Graphviz
+```

package/README.md

@@ -0,0 +1,819 @@
+# migraguard
+
+PostgreSQL 向けの SQL マイグレーション管理ツールチェイン。
+
+DDL を直 SQL で記述し、`psql` で実行するシンプルな構成を前提に、冪等性の担保・改ざん検知・スキーマ drift チェックを提供する。
+
+## 設計思想
+
+- **直 SQL**: マイグレーションは `psql -f` で実行可能な SQL ファイルとして管理する。ORM やマイグレーションフレームワーク固有の DSL を排除し、トランザクション境界を SQL に明示する
+- **forward-only**: 適用済みマイグレーションの変更を原則禁止し、常に前方向へ積み上げる。最新のマイグレーションファイルのみ、冪等性が担保されている前提で上書き更新・再適用を許容する
+- **リリース単位は 1 ファイル**: 複数のマイグレーションファイルはリリース前に `squash` で 1 ファイルにまとめる。1 ファイル = 1 リリース単位とすることで、エラー時の修正・再適用を単純化する
+- **依存ツリーによる並行リリース**（拡張）: DDL の依存関係を解析して DAG を構築し、独立した変更の並行作業・並行リリースを可能にする。線形モデルの制約を緩和し、大規模システムでの運用を改善する
+- **検証を左に寄せる**: Squawk による lint、チェックサムによる改ざん検知、スキーマ dump の diff を CI（PR 段階）で実行し、本番到達前にリスクを排除する
+- **最小構成**: `psql` + SQL ファイル + メタデータ JSON + DB 状態テーブルによる管理。ツール固有のロックイン・ブラックボックスを避ける
+
+## 二層の状態管理
+
+migraguard はファイル整合性と適用状態を分離して管理する。
+
+| レイヤ | 保存場所 | 役割 |
+|--------|----------|------|
+| **metadata.json**（リポジトリ） | `db/.migraguard/metadata.json` | マイグレーションファイルの一覧とチェックサム。CI での整合性チェックに使用。環境に依存しない |
+| **schema_migrations テーブル**（各 DB） | 各環境の PostgreSQL | その環境に適用済みのファイルとチェックサムを記録。`apply` 時に未適用分を判定する |
+
+metadata.json は「どのファイルが存在すべきか」を、schema_migrations は「どの環境に何が適用済みか」を表す。この分離により、同一のリポジトリから複数環境（検証・商用）への段階的リリースが正しく動作する。
+
+## 機能一覧
+
+### マイグレーション管理
+
+| 機能 | 説明 |
+|------|------|
+| `migraguard new <name>` | UTC タイムスタンプ付きの新規マイグレーション SQL ファイルを生成 |
+| `migraguard squash` | 未適用の複数マイグレーションファイルを 1 ファイルにマージ。リリース前に実行する |
+| `migraguard apply` | 未適用マイグレーションを順番に `psql` で実行。対象 DB の `schema_migrations` テーブルで適用済みを判定 |
+| `migraguard resolve <file>` | 失敗したマイグレーションを明示的にスキップ済みとしてマーク。後続の forward migration で修正済みであることを人間が判断した上で実行する |
+| `migraguard status` | 適用済み・未適用・失敗・スキップのマイグレーション一覧を表示 |
+| `migraguard editable` | 現在編集可能なマイグレーションファイルを一覧表示。線形モデルでは末尾ファイル、DAG モデルでは葉ノードが対象。DB 接続時は `schema_migrations` も参照し、failed 状態のリトライ可能ファイルも表示する |
+
+### 整合性チェック
+
+| 機能 | 説明 |
+|------|------|
+| `migraguard check` | metadata.json とファイル本体のチェックサム比較。最新ファイル以外の変更・追加を検出しエラーとする。DB 接続不要 |
+| `migraguard lint` | Squawk を使用した SQL lint。冪等性・安全性に関するルール違反を検出 |
+
+### スキーマ管理
+
+| 機能 | 説明 |
+|------|------|
+| `migraguard dump` | `pg_dump --schema-only` を実行し、正規化したスキーマを出力。diff が取れる形式で保存 |
+| `migraguard diff` | 現在の DB スキーマと保存済みスキーマ dump の差分を表示 |
+
+### 依存関係解析（拡張）
+
+| 機能 | 説明 |
+|------|------|
+| `migraguard deps` | マイグレーション間の依存関係グラフを解析・表示 |
+| `migraguard deps --dot` | DOT 形式で出力（Graphviz で可視化可能） |
+
+## ディレクトリ構成
+
+```
+project-root/
+├── migraguard.config.json          # 設定ファイル
+├── db/
+│   ├── migrations/            # マイグレーション SQL ファイル
+│   │   ├── 20260301_120000__create_users_table.sql
+│   │   ├── 20260302_093000__add_email_index.sql
+│   │   └── ...
+│   ├── schema.sql             # 正規化されたスキーマ dump（生成物）
+│   └── .migraguard/
+│       └── metadata.json      # ファイル一覧 + チェックサム（適用状態は含まない）
+└── ...
+```
+
+### schema_migrations テーブル（各環境の DB に作成）
+
+```sql
+CREATE TABLE IF NOT EXISTS schema_migrations (
+    file_name   VARCHAR(256) NOT NULL,
+    checksum    VARCHAR(64)  NOT NULL,
+    status      VARCHAR(16)  NOT NULL DEFAULT 'applied',  -- applied / failed / skipped
+    applied_at  TIMESTAMPTZ  NOT NULL DEFAULT CURRENT_TIMESTAMP,
+    resolved_at TIMESTAMPTZ,                              -- skipped 時の解決日時
+    PRIMARY KEY (file_name, checksum)
+);
+```
+
+`migraguard apply` の初回実行時に自動作成される。
+
+同一ファイルの再適用（チェックサム変更後の hotfix 再適用など）は別レコードとして記録される。これにより、あるファイルがいつ・どのバージョンで適用されたかの履歴が全て残る。
+
+status の意味:
+
+| status | 意味 |
+|--------|------|
+| `applied` | 正常に適用済み |
+| `failed` | 適用を試みたがエラーで失敗。未解決 |
+| `skipped` | `migraguard resolve` により明示的にスキップ。後続の forward migration で修正済みという人間の判断 |
+
+### 先祖返り検知
+
+apply 時、ファイルの現在のチェックサムが **過去のレコード（最新以外）のチェックサムと一致** した場合、先祖返り（意図しない巻き戻し）としてエラーにする。
+
+```
+例:
+  schema_migrations に以下の履歴がある場合:
+    (S1.sql, checksum_v1, applied)   ← 初回適用
+    (S1.sql, checksum_v2, applied)   ← hotfix で再適用
+
+  ファイルのチェックサムが checksum_v1 に戻っている
+    → 最新レコードは checksum_v2 → 不一致 → さらに過去の checksum_v1 と一致
+    → 先祖返りとしてエラー
+```
+
+これにより、ファイルを誤って古いバージョンに戻してしまった場合を検知できる。
+
+## 設定ファイル（migraguard.config.json）
+
+```json
+{
+  "migrationsDir": "db/migrations",
+  "schemaFile": "db/schema.sql",
+  "metadataFile": "db/.migraguard/metadata.json",
+  "naming": {
+    "pattern": "{timestamp}__{description}.sql",
+    "timestamp": "YYYYMMDD_HHMMSS",
+    "prefix": "",
+    "sortKey": "timestamp"
+  },
+  "connection": {
+    "host": "localhost",
+    "port": 5432,
+    "database": "myapp_dev",
+    "user": "postgres"
+  },
+  "dump": {
+    "normalize": true,
+    "excludeOwners": true,
+    "excludePrivileges": true
+  },
+  "lint": {
+    "squawk": true
+  }
+}
+```
+
+### naming 設定
+
+| キー | デフォルト | 説明 |
+|------|-----------|------|
+| `pattern` | `{timestamp}__{description}.sql` | ファイル名のテンプレート。`{timestamp}`, `{prefix}`, `{description}` を使用可能 |
+| `timestamp` | `YYYYMMDD_HHMMSS` | タイムスタンプのフォーマット。ソート順の基準になる |
+| `prefix` | `""` | 全ファイルに付与する固定プレフィックス。カテゴリやサービス名の識別に使用 |
+| `sortKey` | `timestamp` | ファイルのソート順を決定するキー。`timestamp`（タイムスタンプ部分で昇順）が標準 |
+
+**カスタマイズ例**:
+
+```json
+// マイクロサービス別にプレフィックスを付ける
+{
+  "naming": {
+    "pattern": "{prefix}_{timestamp}__{description}.sql",
+    "prefix": "auth"
+  }
+}
+// → auth_20260301_120000__add_users_table.sql
+
+// 連番ベースにする
+{
+  "naming": {
+    "pattern": "{prefix}_{timestamp}__{description}.sql",
+    "timestamp": "NNNN",
+    "prefix": "billing"
+  }
+}
+// → billing_0001__create_invoices_table.sql
+
+// カテゴリ + タイムスタンプ
+{
+  "naming": {
+    "pattern": "{prefix}_{timestamp}__{description}.sql",
+    "prefix": "order-service"
+  }
+}
+// → order-service_20260301_120000__add_shipping_status.sql
+```
+
+`migraguard new` はこの設定に従ってファイル名を生成する。`migraguard check` / `apply` はパターンに基づいてタイムスタンプ部分を抽出し、ソート順を決定する。
+
+`connection` は環境変数（`PGHOST`, `PGPORT`, `PGDATABASE`, `PGUSER`, `PGPASSWORD`）でオーバーライド可能。
+
+## マイグレーションファイルの規約
+
+### ファイル命名
+
+デフォルトのパターン:
+
+```
+YYYYMMDD_HHMMSS__<description>.sql
+```
+
+`naming` 設定でカスタマイズした場合:
+
+```
+<prefix>_YYYYMMDD_HHMMSS__<description>.sql
+```
+
+- タイムスタンプは UTC 固定（`naming.timestamp` で形式を変更可能）
+- description は英数字とアンダースコアのみ
+- 操作種別を先頭に付与: `create_`, `add_`, `alter_`, `drop_`, `backfill_`, `create_index_`
+- prefix はカテゴリ・マイクロサービス名等の識別子（`naming.prefix` で設定）
+
+### 冪等性の担保
+
+マイグレーション SQL は冪等に書く。途中失敗後の再実行で安全に完了すること。
+
+```sql
+-- IF NOT EXISTS / IF EXISTS を活用
+CREATE TABLE IF NOT EXISTS users (...);
+CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_users_email ON users (email);
+
+-- backfill は WHERE 句で冪等条件を付ける
+UPDATE users SET status = 'active' WHERE status IS NULL;
+```
+
+## squash のフロー
+
+`migraguard squash` は、開発中に作成した複数のマイグレーションファイルを 1 ファイルにまとめる。リリースブランチへのマージ前に実行する。
+
+```bash
+npx migraguard squash
+```
+
+1. metadata.json を読み込む
+2. `migrationsDir` のファイルのうち、metadata.json に記録されていない新規ファイルを特定
+3. 新規ファイルが 2 つ以上ある場合、タイムスタンプ順に連結して 1 ファイルにまとめる
+4. マージ後のファイル名は最新のタイムスタンプを採用し、description は結合する
+5. 元のファイルを削除し、metadata.json を更新
+
+```
+squash 前:
+  20260228_120000__add_user_email.sql     (新規)
+  20260301_093000__add_email_index.sql    (新規)
+
+squash 後:
+  20260301_093000__add_user_email_and_email_index.sql  (1ファイルに統合)
+```
+
+### なぜ 1 リリース = 1 ファイルか
+
+複数ファイルが未適用の状態でリリースすると、以下の問題が起きる。
+
+**エラー時に修正できない**:
+- `20260228_` と `20260301_` が未適用の状態で検証環境に反映
+- `20260228_` でエラー発生
+- 修正したいが、最新ファイルは `20260301_` なので `20260228_` の変更は check でブロックされる
+- `20260301_` は `20260228_` に依存しているため、両方の修正が必要になる
+
+**1 ファイルなら単純**:
+- squash 後の 1 ファイルがエラー → そのファイルを修正 → 再適用
+- 最新ファイルルールに適合し、冪等性により安全に再実行できる
+
+`migraguard check` は新規ファイル（metadata.json に未記録）が 2 つ以上ある場合にエラーとする。squash を実行してから push する運用を強制する。
+
+## apply のフロー
+
+`migraguard apply` は対象 DB の `schema_migrations` テーブルを参照して未適用分を判定・実行する。
+
+1. DB の `schema_migrations` テーブルから全レコードを取得
+2. `migrationsDir` のファイルをタイムスタンプ順にソート
+3. 各ファイルについて、**そのファイル名の最新レコード**（`applied_at` が最大のもの）を参照して判定:
+   - 最新レコードなし → 新規ファイル → `psql -v ON_ERROR_STOP=1 -f <file>` で実行
+   - 最新レコード status=`applied` + チェックサム一致 → スキップ
+   - 最新レコード status=`applied` + チェックサム不一致:
+     - 過去レコードのチェックサムと一致 → 即エラー（先祖返り検知）
+     - 最新ファイル（末尾） → 再適用（冪等性前提）
+     - 最新以外 → 即エラー（改ざん検知）
+   - 最新レコード status=`skipped` → スキップ（`resolve` 済み）
+   - 最新レコード status=`failed`:
+     - 最新ファイル（末尾） → リトライ（修正済みの想定）
+     - 最新以外 → 即エラー（未解決の失敗。`migraguard resolve` または squash が必要）
+4. 実行結果に応じて `schema_migrations` へ **新規レコードを INSERT**:
+   - 成功 → status=`applied`
+   - 失敗 → status=`failed`、以降のファイルは実行しない
+5. 最新ファイル（末尾）は更新があっても再適用を許容する（開発中の繰り返し反映、および本番エラー時の hotfix 対応を想定）
+
+metadata.json はこのフローでは参照しない。apply は DB の状態のみを信頼する。
+
+### 履歴の蓄積例
+
+```
+schema_migrations テーブルの状態推移:
+
+── 初回適用 ──
+(S1.sql, checksum_v1, applied, 2026-03-01 12:00)
+
+── S1 を修正して再適用（hotfix） ──
+(S1.sql, checksum_v1, applied, 2026-03-01 12:00)   ← 過去レコード（残る）
+(S1.sql, checksum_v2, applied, 2026-03-01 15:00)   ← 最新レコード
+
+── 誤って checksum_v1 に戻してしまった場合 ──
+→ 過去レコード checksum_v1 と一致 → 先祖返りエラー
+```
+
+### 失敗時のリカバリ
+
+```
+ケース 1: 最新ファイル S1 が失敗（S1 の後にファイルがない）
+  → S1 を修正して再度 apply（S1 は最新なので修正可能、failed → リトライ）
+  → 新しいチェックサムで applied レコードが追加される
+
+ケース 2: S1 が失敗した後に S2 が追加された（S1 は最新ではなくなった）
+  → apply は「S1 が未解決」でエラー停止
+  → 選択肢 A: migraguard resolve S1 → S1 を skipped にし、S2 で修正内容をカバー
+  → 選択肢 B: squash で S1 + S2 を 1 ファイルにまとめ直す
+              （DB 上の S1 の failed 記録は孤立するが、apply はファイル基準で動くため無害）
+```
+
+### resolve の動作
+
+```bash
+npx migraguard resolve 20260301_093000__add_user_email.sql
+```
+
+- 対象 DB の `schema_migrations` に、該当ファイルの最新 failed レコードと同じチェックサムで status=`skipped` のレコードを INSERT
+- `resolved_at` に現在時刻を記録
+- 該当ファイルの最新レコードが `failed` 以外の場合はエラー
+- 後続の forward migration で修正済みであることを人間が確認した上で実行する操作
+
+### スキーマ dump による事前検証（apply 時）
+
+`--verify` オプションを付けた場合、apply 前に以下の検証を行う。
+
+1. 現在の DB スキーマを dump し、保存済み `schema.sql` と比較
+2. 一致すれば apply を実行
+3. apply 完了後、新しいスキーマ dump を生成し `schema.sql` を更新
+
+```bash
+migraguard apply --verify
+```
+
+## check のフロー（CI 向け）
+
+`migraguard check` は CI 環境で実行することを想定したファイル整合性チェック。DB 接続は不要。
+
+1. metadata.json を読み込む
+2. `migrationsDir` の全ファイルのチェックサムを計算
+3. 以下をチェック:
+   - metadata.json に記録されたファイルのチェックサムが実ファイルと一致するか（最新ファイル以外）
+   - 最新ファイル以外に変更がないか
+   - 新しいファイルが途中に挿入されていないか（タイムスタンプ順で末尾以外に追加されていないか）
+   - **新規ファイル（metadata.json に未記録）が 2 つ以上ないか**
+4. 違反があればエラーコード 1 で終了し、差分の詳細を出力
+
+### check の限界と運用規約
+
+check は DB に接続しないため、「どの環境に何が適用済みか」は判定できない。apply は DB 側で `failed` 状態を検知してエラー停止するが、理想的にはこの状況自体を避けるべきである。以下のケースは運用規約で予防する。
+
+**問題が起きるケース**:
+
+```
+1. S1 を作成 → dev に反映（S1 適用済み）
+2. S1 を pro に反映する前に S2 を追加
+3. pro で S1 を apply → エラー発生 → schema_migrations に failed で記録
+4. S1 を修正したいが、最新は S2 なので check がブロック
+5. apply も「S1 が未解決」でエラー停止
+6. リカバリ: migraguard resolve S1 → S2 を apply（S2 で S1 の修正をカバー）
+```
+
+リカバリは可能だが、S2 が S1 の意図を正しくカバーしているかは人間が判断する必要がある。この状況を避けるための運用規約を設ける。
+
+**運用規約: 1 リリースの全環境デプロイが完了するまで、次のマイグレーションを追加しない**
+
+```
+S1 作成 → dev 反映 → pro 反映 → 全環境完了
+                                      │
+                              ここで初めて S2 を追加可能
+```
+
+この規約に反して S2 を追加した後に S1 の修正が必要になった場合は、S1 を直接修正するのではなく、**新しい forward migration（S3）で修正内容を記述する**。S1 は変更せず、S3 で S1 の問題を補正する。
+
+### check と apply の役割分担
+
+| | check | apply |
+|---|---|---|
+| 参照先 | metadata.json（リポジトリ） | schema_migrations テーブル（DB） |
+| DB 接続 | 不要 | 必要 |
+| 用途 | CI での事前検証（PR チェック） | 環境への実適用 |
+| 検出対象 | ファイルの改ざん・不正な追加・複数新規ファイル | 未適用ファイルの特定・適用 |
+
+## リリースフロー
+
+リリースブランチが `db_dev`（検証）、`db_pro`（商用）の場合の典型的なフロー。
+
+```
+feature ブランチで開発:
+  migraguard new add_user_email      → 20260228_120000__add_user_email.sql
+  migraguard new add_email_index     → 20260301_093000__add_email_index.sql
+  (個別に apply してローカルで動作確認)
+         │
+         ▼
+リリース準備:
+  migraguard squash                  → 1 ファイルにマージ
+  migraguard lint                    → lint チェック
+  migraguard check                   → 整合性チェック
+  git commit
+         │
+         ▼
+db_dev にマージ → CI が apply  → 検証環境に反映
+         │
+         │  エラー時: ファイル修正 → 再 apply（最新 = 唯一のファイルなので修正可能）
+         │
+         ▼
+db_pro にマージ → CI が apply  → 商用環境に反映
+         │
+         │  エラー時: 同じファイルを修正 → 再 apply
+         │  (検証環境は冪等性により修正版を再適用しても安全)
+         │
+         ▼
+       全環境完了 ← ここで初めて次のマイグレーションを追加可能
+```
+
+**重要**: 1 リリース（1 ファイル）の全環境デプロイが完了するまで、次のマイグレーションファイルを追加しない。この規約により、最新ファイルの修正・再適用が常に可能な状態を維持する。
+
+### 各環境の状態推移
+
+```
+           metadata.json     db_dev schema_migrations   db_pro schema_migrations
+           (リポジトリ)       (検証 DB)                  (商用 DB)
+
+squash後    [A, B, S]         [A, B]                     [A, B]
+dev反映後   [A, B, S]         [A, B, S ✓]                [A, B]
+pro反映後   [A, B, S]         [A, B, S ✓]                [A, B, S ✓]
+                                                           ↑ 次のリリース解禁
+
+A, B = 過去の適用済みファイル
+S = squash で生成されたファイル
+```
+
+metadata.json はファイル一覧のみを持ち、どの環境に適用済みかは各 DB が管理する。同一の metadata.json で複数環境への段階的リリースが正しく動作する。
+
+### 規約に反した場合のリカバリ
+
+全環境デプロイ前に次のファイルを追加してしまい、過去ファイルの修正が必要になった場合:
+
+1. 過去ファイルを直接修正しない（check がブロックする）
+2. 新しい forward migration を作成し、過去ファイルの問題を補正する SQL を記述する
+3. squash で現在の新規ファイルと forward migration を 1 つにまとめる
+
+## GitHub Actions との連携
+
+### PR 時のチェック（例）
+
+```yaml
+name: DB Migration Check
+on:
+  pull_request:
+    paths:
+      - 'db/**'
+
+jobs:
+  check:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Setup Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: '20'
+
+      - name: Install migraguard
+        run: npm ci
+
+      - name: Lint migrations
+        run: npx migraguard lint
+
+      - name: Check metadata integrity
+        run: npx migraguard check
+
+      - name: Verify schema dump
+        run: |
+          # shadow DB で全マイグレーション適用後の dump と比較
+          npx migraguard dump --connection-string "$SHADOW_DB_URL" > /tmp/actual_schema.sql
+          diff db/schema.sql /tmp/actual_schema.sql
+```
+
+### マイグレーション自動実行（例）
+
+```yaml
+name: Apply Migrations
+on:
+  push:
+    branches: [db_dev]
+    paths:
+      - 'db/migrations/**'
+
+jobs:
+  apply:
+    runs-on: ubuntu-latest
+    environment: dev
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Setup Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: '20'
+
+      - name: Install migraguard
+        run: npm ci
+
+      - name: Check integrity
+        run: npx migraguard check
+
+      - name: Apply with verification
+        run: npx migraguard apply --verify
+        env:
+          PGHOST: ${{ secrets.DB_HOST }}
+          PGDATABASE: ${{ secrets.DB_NAME }}
+          PGUSER: ${{ secrets.DB_USER }}
+          PGPASSWORD: ${{ secrets.DB_PASSWORD }}
+```
+
+## ローカル開発フロー
+
+```bash
+# 1. 新規マイグレーションファイルを作成
+npx migraguard new add_user_email
+
+# 2. 生成された SQL ファイルを編集
+vim db/migrations/20260301_120000__add_user_email.sql
+
+# 3. ローカル DB に適用（最新ファイルは何度でも再適用可能）
+npx migraguard apply
+
+# 4. 必要に応じて追加ファイルを作成・適用
+npx migraguard new add_email_index
+vim db/migrations/20260302_093000__add_email_index.sql
+npx migraguard apply
+
+# 5. リリース前に squash で 1 ファイルにまとめる
+npx migraguard squash
+
+# 6. lint + 整合性チェック
+npx migraguard lint
+npx migraguard check
+
+# 7. スキーマ dump を更新
+npx migraguard dump
+
+# 8. コミット
+git add db/
+git commit -m "add user email column and index"
+```
+
+## 依存ツリーモデル（拡張）
+
+線形順序モデルでは「末尾の 1 ファイルだけが修正・再適用可能」という制約がある。依存ツリーモデルはこの制約を緩和し、独立した変更の並行作業を可能にする。
+
+### 線形モデル vs 依存ツリーモデル
+
+```
+線形モデル:
+  A → B → C → D
+                ↑ D だけが修正可能。C のエラーが D のリリースをブロック
+
+依存ツリーモデル:
+          A (users テーブル作成)
+         / \
+        B   C (B: users にカラム追加, C: orders テーブル作成)
+        |     \
+        D      E (D: users にインデックス, E: orders にインデックス)
+
+  D と E は互いに独立 → 両方とも修正・再適用可能
+  D のエラーが E のリリースをブロックしない
+```
+
+### 依存関係の解析方法
+
+各マイグレーション SQL を PostgreSQL パーサ（`libpg_query`）で AST にパースし、オブジェクトの生成・参照関係を抽出して DAG（有向非巡回グラフ）を構築する。
+
+```
+SQL 文から抽出する情報:
+
+  CREATE TABLE users (...)
+    → 生成: users
+
+  ALTER TABLE users ADD COLUMN email VARCHAR(256)
+    → 依存: users  → 生成: users.email
+
+  CREATE INDEX CONCURRENTLY ON users (email)
+    → 依存: users, users.email
+
+  CREATE TABLE orders (user_id INT REFERENCES users(id))
+    → 依存: users  → 生成: orders
+```
+
+抽出可能な DDL と依存の種類:
+
+| DDL | 生成 | 依存 |
+|-----|------|------|
+| `CREATE TABLE` | テーブル | なし（REFERENCES があれば参照先テーブル） |
+| `ALTER TABLE ADD COLUMN` | カラム | テーブル |
+| `ALTER TABLE ADD CONSTRAINT` | 制約 | テーブル、カラム、参照先テーブル |
+| `CREATE INDEX` | インデックス | テーブル、カラム |
+| `CREATE VIEW` | ビュー | 参照先テーブル |
+| `CREATE FUNCTION` | 関数 | 参照先テーブル（本体の解析が必要） |
+| `DROP *` | なし | 削除対象のオブジェクト |
+
+### check と apply への影響
+
+依存ツリーモデルでは「最新ファイル（末尾）」の概念が「葉ノード（他から依存されていないファイル）」に置き換わる。
+
+**check の変更**:
+- 変更可能なファイル: 葉ノードのみ（線形モデルの「末尾」に相当）
+- 葉ノード以外のファイルが変更されていたらエラー
+- 新規ファイルが既存の葉ノードに依存する場合、その葉ノードはもう葉ではなくなる → ロックされる
+
+**apply の変更**:
+- トポロジカルソート順にファイルを適用（依存先が先）
+- 独立したファイル同士は順序不問
+- 失敗時: 失敗したファイルに依存するファイルのみブロック。独立したファイルは影響を受けない
+
+```
+例: D が失敗した場合
+
+          A
+         / \
+        B   C
+        |     \
+       [D]     E ← D と独立なので apply 可能
+
+  D の失敗は E のリリースをブロックしない
+```
+
+### 明示的依存の宣言
+
+AST からの自動抽出には限界がある（動的 SQL、業務ロジック上の依存など）。自動抽出できない依存は SQL ファイル内のコメントで明示的に宣言する。
+
+```sql
+-- migraguard:depends-on 20260228_120000__create_users_table.sql
+
+SET lock_timeout = '5s';
+...
+```
+
+または `migraguard.config.json` で宣言する。
+
+```json
+{
+  "dependencies": {
+    "20260301_093000__backfill_user_status.sql": [
+      "20260228_120000__add_user_status_column.sql"
+    ]
+  }
+}
+```
+
+自動抽出と明示的宣言をマージして最終的な DAG を構築する。明示的宣言は自動抽出の結果を上書きせず、追加の依存として合成される。
+
+### 大規模システムでの効果
+
+| 制約 | 線形モデル | 依存ツリーモデル |
+|------|-----------|-----------------|
+| 同時に修正可能なファイル | 1（末尾のみ） | 葉ノードの数（独立した変更の数） |
+| 並行リリース | 不可（全環境完了まで次を追加できない） | 独立したブランチは並行リリース可能 |
+| エラーの影響範囲 | 全後続ファイルがブロック | 依存するファイルのみブロック |
+| 複数チームの作業 | 直列化（1 チームずつ） | 独立したテーブルなら並行作業可能 |
+
+### 実装フェーズ
+
+依存ツリーモデルは線形モデルの上位互換として段階的に導入する。
+
+| フェーズ | 内容 |
+|---------|------|
+| Phase 1 | 線形モデルで基本機能（new / apply / check / squash / lint / dump）を実装 |
+| Phase 2 | `libpg_query` による DDL 依存抽出と `migraguard deps` コマンドを実装。情報表示のみで動作は変更しない |
+| Phase 3 | check と apply を依存ツリー対応に拡張。葉ノード判定、トポロジカルソート適用 |
+
+### 依存解析の候補ライブラリ
+
+| ライブラリ | 概要 |
+|-----------|------|
+| [libpg_query](https://www.npmjs.com/package/libpg_query) | PostgreSQL 実パーサの Node.js バインディング。SQL → AST のパースを提供 |
+| [@pg-nano/pg-parser](https://www.npmjs.com/package/@pg-nano/pg-parser) | TypeScript ファーストの PostgreSQL パーサ。型定義と AST ユーティリティ（`walk()`, `select()`）を提供 |
+
+Squawk は単一ファイル内の lint に特化しており、ファイル間の依存抽出機能は持たない。依存解析は上記ライブラリを使って自前で構築する。
+
+## 既存ツールとの比較
+
+migraguard の特徴は「運用規約そのものをツールに埋め込んで、CI で事故を未然に潰す」点にある。既存ツール（Flyway / Atlas / Sqitch / Graphile Migrate など）との差分を整理する。
+
+### 1. 二層の状態管理で多環境の段階的リリースを設計の中心に置いている
+
+リポジトリ側の整合性（metadata.json）と各 DB 側の適用状態（schema_migrations）を明確に分離し、「同一リポジトリから dev → pro の段階的リリース」を設計として破綻しにくくしている。
+
+[Atlas](https://atlasgo.io/concepts/migration-directory-integrity) も `atlas.sum` でディレクトリ整合性（Merkle hash tree 風）を担保するが、migraguard はさらに「環境ごとの差（applied / failed / skipped）を DB 側に寄せる」ことを明示的に設計している。
+
+### 2. 「最新版だけ編集 OK」をルール + 履歴設計で安全側に倒している
+
+単に「最新版だけ編集可」ではなく、apply 時に以下の判定ロジックまで踏み込んでいる。
+
+- 最新レコードが applied だが checksum 不一致 → 過去 checksum と一致したら「先祖返り」としてエラー
+- 最新ノード（線形なら末尾、DAG なら葉ノード）だけは再適用許可
+- それ以外は改ざんとして即エラー
+
+Flyway / Liquibase にも checksum 検証はあるが、「先祖返りを明確にエラー扱いする」を標準の運用モデルとして提示している例は多くない。
+
+### 3. DB 接続不要の整合性チェックを CI 前提で強制できる
+
+`migraguard check` は metadata.json と実ファイルのチェックサム突合で、DB 接続なしに以下を検出する。
+
+- 最新以外の変更を検出してエラー
+- 途中挿入を検出してエラー
+- 新規ファイルが 2 つ以上ならエラー（squash を強制）
+
+Atlas も整合性ファイル（`atlas.sum`）でディレクトリの整合性を強制できるが、migraguard は「squash による 1 リリース = 1 ファイル」を機械的に強制するところまで実装に落としている。
+
+### 4. スキーマ dump diff を apply ゲートに組み込んでいる
+
+`migraguard dump` / `migraguard diff` を機能として持ち、`apply --verify` で以下を一連の手順として定義している。
+
+1. 現在 DB の dump と保存 `schema.sql` が一致するか検証
+2. 一致したら apply
+3. apply 後に新 dump を生成して `schema.sql` を更新
+
+[Graphile Migrate](https://github.com/graphile/migrate) も「pg_dump を git 管理して差分を見る」ことを推奨しているが、migraguard はそれを verify ゲートとして apply に組み込み、手順抜け（運用のブレ）を減らす設計になっている。
+
+### 5. 失敗の取り扱いが現場運用（止める / 進める）を具体化している
+
+`schema_migrations` に `failed` / `skipped` を持たせ、`resolve` で明示的にスキップする運用を定義している。
+
+- 失敗したファイルが最新でなければ apply は即エラー停止（自動スキップしない）
+- `resolve` は人間の判断を介在させる明示的操作
+- 後続の forward migration で修正する運用を明文化
+
+既存ツールにも repair / ignore 的な逃げ道はあるが、migraguard は「どういう状況でそれを使うか」まで含めて設計されている。
+
+### 6. 依存 DAG への拡張が設計に組み込まれている
+
+線形モデルから依存 DAG（葉ノード = 編集可）への拡張が具体的に設計されている。
+
+- 依存解析で独立した変更を並行リリース可能にする
+- 失敗の影響を依存範囲に閉じる
+- トポロジカルソート順に apply
+
+[Sqitch](https://sqitch.org/docs/manual/sqitch/) は依存をマイグレーション間で宣言できるが、Merkle tree パターンで整合性を担保する。migraguard は「SQL ファイル（psql 実行）+ CI ゲート + dump diff」を軸にしたまま DAG へ拡張する方向性。
+
+### まとめ
+
+migraguard は既存ツールが提供する「実行エンジン」や「履歴テーブル」よりも、以下を重視している。
+
+- 運用事故の典型パターン（途中挿入、過去改変、先祖返り、段階的リリース中の詰まり）を CI ゲートと規約で潰す
+- スキーマ dump を監査可能な成果物として常に diff 可能にし、drift を検知する
+- 末端（線形なら末尾、DAG なら葉ノード）だけを可変にして hotfix を許す代わりに検出ロジックを強くする
+
+これらを最小構成（psql + SQL + JSON + dump）で実現する。
+
+## apply の排他制御
+
+冪等な SQL であっても、同時実行は競合状態を引き起こし得る。apply は排他制御として PostgreSQL の advisory lock を使用する。
+
+```
+apply の実行フロー（排他制御込み）:
+  1. DB 接続確立
+  2. pg_advisory_lock(hashtext('migraguard-apply')) を取得
+     → 同時に別プロセスが apply を実行している場合はブロック（待機）
+  3. schema_migrations を参照して未適用分を判定
+  4. 各ファイルを psql で実行、結果を schema_migrations に記録
+  5. 接続クローズ（advisory lock は自動解放）
+```
+
+advisory lock はセッション単位で効くため、apply 全体を単一セッションで実行する必要がある。接続が切れた場合はロックが自動解放され、再実行が安全に行える。
+
+CI パイプラインの並列実行（同一環境への同時 apply）や、手動 apply とパイプラインの競合を防止する。
+
+## DAG 移行時の互換方針
+
+線形モデルから依存ツリーモデルへ移行する際、既存環境の schema_migrations との整合性を維持する必要がある。
+
+### 移行手順
+
+1. **既存の schema_migrations はそのまま維持**: 線形モデルで記録されたレコードは、DAG モデルでも「依存関係が暗黙的に全直列」のファイルとして扱う
+2. **移行ポイントのマーカー**: DAG モデル導入時に metadata.json に `"model": "dag"` フラグを追加。このフラグ以前のファイルは線形順序、以降のファイルは DAG 解析対象とする
+3. **後方互換**: DAG モデル対応の migraguard は線形モデルの metadata.json も読める。逆（DAG → 線形へのダウングレード）は非サポート
+
+```
+metadata.json の移行例:
+
+{
+  "model": "dag",
+  "modelSince": "20260401_000000__first_dag_migration.sql",
+  "migrations": [
+    {"file": "20260301_...", "checksum": "aaa"},  ← 線形モデル時代（全直列扱い）
+    {"file": "20260302_...", "checksum": "bbb"},  ← 線形モデル時代
+    {"file": "20260401_...", "checksum": "ccc"}   ← DAG モデル（依存解析対象）
+  ]
+}
+```
+
+### check / apply の動作
+
+- `modelSince` より前のファイル: 従来通りタイムスタンプ順の線形チェック
+- `modelSince` 以降のファイル: DAG 解析による葉ノード判定、トポロジカルソート適用
+- 両者の境界: `modelSince` のファイルは、それ以前の全ファイルに暗黙的に依存する（線形モデルの最終状態を引き継ぐ）
+
+## 技術スタック
+
+| 項目 | 技術 |
+|------|------|
+| 言語 | TypeScript（Node.js） |
+| DB 接続 | `psql` CLI（DDL ファイルを直接渡す） |
+| スキーマ dump | `pg_dump --schema-only` |
+| SQL lint | [Squawk](https://squawkhq.com/) |
+| SQL パーサ | [libpg_query](https://www.npmjs.com/package/libpg_query) / [@pg-nano/pg-parser](https://www.npmjs.com/package/@pg-nano/pg-parser)（依存解析用） |
+| パッケージ管理 | npm |

package/bin/migraguard.js

@@ -0,0 +1,2 @@
+#!/usr/bin/env node
+import '../dist/cli.js';

package/dist/cli.d.ts

@@ -0,0 +1,2 @@
+
+export {  }

package/dist/cli.js

@@ -0,0 +1,57 @@
+import { Command } from 'commander';
+
+// src/cli/index.ts
+
+// src/index.ts
+var VERSION = "0.0.1";
+
+// src/cli/index.ts
+var program = new Command();
+program.name("migraguard").description("PostgreSQL migration guard \u2014 idempotent SQL migrations with CI-enforced integrity checks").version(VERSION);
+program.command("new <name>").description("Create a new migration SQL file with UTC timestamp").action((_name) => {
+  console.log("Not yet implemented");
+  process.exit(1);
+});
+program.command("apply").description("Apply pending migrations via psql").option("--verify", "Verify schema dump before and after apply").action(() => {
+  console.log("Not yet implemented");
+  process.exit(1);
+});
+program.command("check").description("Verify metadata integrity (no DB connection required)").action(() => {
+  console.log("Not yet implemented");
+  process.exit(1);
+});
+program.command("squash").description("Squash multiple new migration files into one").action(() => {
+  console.log("Not yet implemented");
+  process.exit(1);
+});
+program.command("lint").description("Run Squawk lint on migration files").action(() => {
+  console.log("Not yet implemented");
+  process.exit(1);
+});
+program.command("dump").description("Dump and normalize current DB schema").action(() => {
+  console.log("Not yet implemented");
+  process.exit(1);
+});
+program.command("diff").description("Show diff between current DB schema and saved schema.sql").action(() => {
+  console.log("Not yet implemented");
+  process.exit(1);
+});
+program.command("status").description("Show migration status (applied / pending / failed / skipped)").action(() => {
+  console.log("Not yet implemented");
+  process.exit(1);
+});
+program.command("resolve <file>").description("Mark a failed migration as skipped (requires human judgment)").action((_file) => {
+  console.log("Not yet implemented");
+  process.exit(1);
+});
+program.command("editable").description("List migration files that are currently editable (leaf nodes or latest file)").action(() => {
+  console.log("Not yet implemented");
+  process.exit(1);
+});
+program.command("deps").description("Analyze and display migration dependency graph").option("--dot", "Output in DOT format for Graphviz").action(() => {
+  console.log("Not yet implemented");
+  process.exit(1);
+});
+program.parse();
+//# sourceMappingURL=cli.js.map
+//# sourceMappingURL=cli.js.map

package/dist/cli.js.map

@@ -0,0 +1 @@
+{"version":3,"sources":["../src/index.ts","../src/cli/index.ts"],"names":[],"mappings":";;;;;AAAO,IAAM,OAAA,GAAU,OAAA;;;ACGvB,IAAM,OAAA,GAAU,IAAI,OAAA,EAAQ;AAE5B,OAAA,CACG,KAAK,YAAY,CAAA,CACjB,YAAY,+FAA0F,CAAA,CACtG,QAAQ,OAAO,CAAA;AAElB,OAAA,CACG,OAAA,CAAQ,YAAY,CAAA,CACpB,WAAA,CAAY,oDAAoD,CAAA,CAChE,MAAA,CAAO,CAAC,KAAA,KAAkB;AACzB,EAAA,OAAA,CAAQ,IAAI,qBAAqB,CAAA;AACjC,EAAA,OAAA,CAAQ,KAAK,CAAC,CAAA;AAChB,CAAC,CAAA;AAEH,OAAA,CACG,OAAA,CAAQ,OAAO,CAAA,CACf,WAAA,CAAY,mCAAmC,CAAA,CAC/C,MAAA,CAAO,UAAA,EAAY,2CAA2C,CAAA,CAC9D,MAAA,CAAO,MAAM;AACZ,EAAA,OAAA,CAAQ,IAAI,qBAAqB,CAAA;AACjC,EAAA,OAAA,CAAQ,KAAK,CAAC,CAAA;AAChB,CAAC,CAAA;AAEH,OAAA,CACG,QAAQ,OAAO,CAAA,CACf,YAAY,uDAAuD,CAAA,CACnE,OAAO,MAAM;AACZ,EAAA,OAAA,CAAQ,IAAI,qBAAqB,CAAA;AACjC,EAAA,OAAA,CAAQ,KAAK,CAAC,CAAA;AAChB,CAAC,CAAA;AAEH,OAAA,CACG,QAAQ,QAAQ,CAAA,CAChB,YAAY,8CAA8C,CAAA,CAC1D,OAAO,MAAM;AACZ,EAAA,OAAA,CAAQ,IAAI,qBAAqB,CAAA;AACjC,EAAA,OAAA,CAAQ,KAAK,CAAC,CAAA;AAChB,CAAC,CAAA;AAEH,OAAA,CACG,QAAQ,MAAM,CAAA,CACd,YAAY,oCAAoC,CAAA,CAChD,OAAO,MAAM;AACZ,EAAA,OAAA,CAAQ,IAAI,qBAAqB,CAAA;AACjC,EAAA,OAAA,CAAQ,KAAK,CAAC,CAAA;AAChB,CAAC,CAAA;AAEH,OAAA,CACG,QAAQ,MAAM,CAAA,CACd,YAAY,sCAAsC,CAAA,CAClD,OAAO,MAAM;AACZ,EAAA,OAAA,CAAQ,IAAI,qBAAqB,CAAA;AACjC,EAAA,OAAA,CAAQ,KAAK,CAAC,CAAA;AAChB,CAAC,CAAA;AAEH,OAAA,CACG,QAAQ,MAAM,CAAA,CACd,YAAY,0DAA0D,CAAA,CACtE,OAAO,MAAM;AACZ,EAAA,OAAA,CAAQ,IAAI,qBAAqB,CAAA;AACjC,EAAA,OAAA,CAAQ,KAAK,CAAC,CAAA;AAChB,CAAC,CAAA;AAEH,OAAA,CACG,QAAQ,QAAQ,CAAA,CAChB,YAAY,8DAA8D,CAAA,CAC1E,OAAO,MAAM;AACZ,EAAA,OAAA,CAAQ,IAAI,qBAAqB,CAAA;AACjC,EAAA,OAAA,CAAQ,KAAK,CAAC,CAAA;AAChB,CAAC,CAAA;AAEH,OAAA,CACG,OAAA,CAAQ,gBAAgB,CAAA,CACxB,WAAA,CAAY,8DAA8D,CAAA,CAC1E,MAAA,CAAO,CAAC,KAAA,KAAkB;AACzB,EAAA,OAAA,CAAQ,IAAI,qBAAqB,CAAA;AACjC,EAAA,OAAA,CAAQ,KAAK,CAAC,CAAA;AAChB,CAAC,CAAA;AAEH,OAAA,CACG,QAAQ,UAAU,CAAA,CAClB,YAAY,8EAA8E,CAAA,CAC1F,OAAO,MAAM;AACZ,EAAA,OAAA,CAAQ,IAAI,qBAAqB,CAAA;AACjC,EAAA,OAAA,CAAQ,KAAK,CAAC,CAAA;AAChB,CAAC,CAAA;AAEH,OAAA,CACG,OAAA,CAAQ,MAAM,CAAA,CACd,WAAA,CAAY,gDAAgD,CAAA,CAC5D,MAAA,CAAO,OAAA,EAAS,mCAAmC,CAAA,CACnD,MAAA,CAAO,MAAM;AACZ,EAAA,OAAA,CAAQ,IAAI,qBAAqB,CAAA;AACjC,EAAA,OAAA,CAAQ,KAAK,CAAC,CAAA;AAChB,CAAC,CAAA;AAEH,OAAA,CAAQ,KAAA,EAAM","file":"cli.js","sourcesContent":["export const VERSION = '0.0.1';\n","import { Command } from 'commander';\nimport { VERSION } from '../index.js';\n\nconst program = new Command();\n\nprogram\n  .name('migraguard')\n  .description('PostgreSQL migration guard — idempotent SQL migrations with CI-enforced integrity checks')\n  .version(VERSION);\n\nprogram\n  .command('new <name>')\n  .description('Create a new migration SQL file with UTC timestamp')\n  .action((_name: string) => {\n    console.log('Not yet implemented');\n    process.exit(1);\n  });\n\nprogram\n  .command('apply')\n  .description('Apply pending migrations via psql')\n  .option('--verify', 'Verify schema dump before and after apply')\n  .action(() => {\n    console.log('Not yet implemented');\n    process.exit(1);\n  });\n\nprogram\n  .command('check')\n  .description('Verify metadata integrity (no DB connection required)')\n  .action(() => {\n    console.log('Not yet implemented');\n    process.exit(1);\n  });\n\nprogram\n  .command('squash')\n  .description('Squash multiple new migration files into one')\n  .action(() => {\n    console.log('Not yet implemented');\n    process.exit(1);\n  });\n\nprogram\n  .command('lint')\n  .description('Run Squawk lint on migration files')\n  .action(() => {\n    console.log('Not yet implemented');\n    process.exit(1);\n  });\n\nprogram\n  .command('dump')\n  .description('Dump and normalize current DB schema')\n  .action(() => {\n    console.log('Not yet implemented');\n    process.exit(1);\n  });\n\nprogram\n  .command('diff')\n  .description('Show diff between current DB schema and saved schema.sql')\n  .action(() => {\n    console.log('Not yet implemented');\n    process.exit(1);\n  });\n\nprogram\n  .command('status')\n  .description('Show migration status (applied / pending / failed / skipped)')\n  .action(() => {\n    console.log('Not yet implemented');\n    process.exit(1);\n  });\n\nprogram\n  .command('resolve <file>')\n  .description('Mark a failed migration as skipped (requires human judgment)')\n  .action((_file: string) => {\n    console.log('Not yet implemented');\n    process.exit(1);\n  });\n\nprogram\n  .command('editable')\n  .description('List migration files that are currently editable (leaf nodes or latest file)')\n  .action(() => {\n    console.log('Not yet implemented');\n    process.exit(1);\n  });\n\nprogram\n  .command('deps')\n  .description('Analyze and display migration dependency graph')\n  .option('--dot', 'Output in DOT format for Graphviz')\n  .action(() => {\n    console.log('Not yet implemented');\n    process.exit(1);\n  });\n\nprogram.parse();\n"]}

package/dist/index.d.ts

@@ -0,0 +1,3 @@
+declare const VERSION = "0.0.1";
+
+export { VERSION };

package/dist/index.js

@@ -0,0 +1,6 @@
+// src/index.ts
+var VERSION = "0.0.1";
+
+export { VERSION };
+//# sourceMappingURL=index.js.map
+//# sourceMappingURL=index.js.map

package/dist/index.js.map

@@ -0,0 +1 @@
+{"version":3,"sources":["../src/index.ts"],"names":[],"mappings":";AAAO,IAAM,OAAA,GAAU","file":"index.js","sourcesContent":["export const VERSION = '0.0.1';\n"]}

package/package.json

@@ -0,0 +1,65 @@
+{
+  "name": "migraguard",
+  "version": "0.0.1",
+  "description": "PostgreSQL migration guard — idempotent SQL migrations with CI-enforced integrity checks, schema drift detection, and dependency-aware apply",
+  "type": "module",
+  "main": "./dist/index.js",
+  "module": "./dist/index.js",
+  "types": "./dist/index.d.ts",
+  "exports": {
+    ".": {
+      "import": "./dist/index.js",
+      "types": "./dist/index.d.ts"
+    }
+  },
+  "bin": {
+    "migraguard": "./bin/migraguard.js"
+  },
+  "engines": {
+    "node": ">=20.0.0"
+  },
+  "files": [
+    "dist",
+    "bin",
+    "COMMANDS.md"
+  ],
+  "scripts": {
+    "build": "tsup",
+    "dev": "tsup --watch",
+    "lint": "eslint",
+    "test": "vitest",
+    "test:run": "vitest run",
+    "typecheck": "tsc --noEmit",
+    "prepublishOnly": "npm run build"
+  },
+  "keywords": [
+    "postgresql",
+    "migration",
+    "database",
+    "schema",
+    "ddl",
+    "psql",
+    "ci",
+    "drift-detection",
+    "idempotent",
+    "dag"
+  ],
+  "author": "",
+  "license": "MIT",
+  "dependencies": {
+    "chalk": "^5.3.0",
+    "commander": "^12.1.0",
+    "glob": "^10.3.10"
+  },
+  "devDependencies": {
+    "@types/node": "^20.11.0",
+    "eslint": "^9.39.2",
+    "@eslint/js": "^9.39.2",
+    "@typescript-eslint/eslint-plugin": "^8.54.0",
+    "@typescript-eslint/parser": "^8.54.0",
+    "tsup": "^8.0.1",
+    "typescript": "^5.3.3",
+    "typescript-eslint": "^8.54.0",
+    "vitest": "^1.2.0"
+  }
+}