マイグレーション適用戦略・金銭テーブルの非破壊方針・バックアップ/復旧を決める

背景

packages/db/drizzle/ にマイグレーションはコミットされる方針(project.md)だが、デプロイ時に誰がいつ適用するか、金銭・監査テーブルへの破壊的変更をどう扱うか、バックアップ/復旧をどうするかは未決。

なぜ今決めるか

複数レプリカでブート時自動適用にすると起動レースでマイグレーションが競合し得る。append-only の台帳・監査テーブルに破壊的変更(列の型変更・drop・再作成)を掛けると履歴が壊れる。会計記録・監査・会員マッピングは失うと Stripe からの再突合でも完全復元できない部分がある。いずれも運用開始後は不可逆で、方針が無いまま入ると損失が取り返せない。

論点・選択肢

• 適用戦略: デプロイのリリースフェーズで単発実行するか、ブート時自動か。ロールバック不能な破壊的変更の扱い。
• 金銭/監査テーブルの非破壊: 追加のみ(列追加は nullable/デフォルト付き)、破壊的変更は新テーブル + バックフィルの expand-contract に限定する。
• バックアップ/復旧: 頻度・保持・リストア手順・PITR の要否。「会計記録は再構築不能ゆえバックアップ必須」という要件を確定。頻度や基盤の責任分界(自前か NeoShowcase 側か)は情報不足なら暫定。
• マイグレーション前後のバックアップ義務化。

受け入れ条件

• マイグレーション適用戦略・金銭テーブルの非破壊方針・バックアップ必須の要件が決まっている。
• 運用実態に依存する数値/手順は暫定と明示され、要件は今確定している。

関連

project.md のマイグレーション規約を金銭テーブル向けに具体化。ブート時自動適用の競合はデプロイ・トポロジ(単一/複数レプリカ)の決定に依存する。お金の記録アーキテクチャと接続する。

Read project.md for the existing migration rules and inspect packages/db/drizzle/ to understand how migrations are committed. Resolve the release-versus-boot application strategy, non-destructive rules for monetary and audit tables, and backup/restore requirements. Done means these requirements and any provisional operational values are documented and accepted.