# Journal: 20260223-0019-スキーマバージョン管理テーブルの追加

## 1. 作業実施の理由

今後のデータベース構成の変更（マイグレーション）をより確実かつ自動的に管理するため。スキーマの現在のバージョンをデータベース自体に保持させることで、プログラム側での状態判断を容易にする。

## 2. 指示（背景、観点、意図を含む）

- **指示**: 「dbに今のテーブル構成がどのバージョンであるか格納するテーブルを1つ作ったらどうかと思うんだが、どうだい？」
- **背景**: これまでは特定のカラムの有無などでバージョンを推測していたが、将来的な複雑化に備えて明示的な管理が必要。
- **意図**: 「管理テーブル（`internal_metadata`）が存在しない ＝ 0.3.0 未満」という判断基準を導入し、既存のマイグレーションロジックを整理する。

## 3. 指示事項とその対応

- **管理テーブルの新設**: `key` と `value` を持つ `internal_metadata` テーブルを追加。
- **バージョン記録**: `version: 0.3.0` を初期値（または移行完了値）として保存。
- **マイグレーションロジックの改善**: 以前実装した `migrate_025_to_030` において、まず `internal_metadata` の有無を確認するステップを追加。
- **ドキュメント反映**: データベース仕様書を更新。

## 4. 作業詳細

AIエージェントは以下の手順で作業を実施した。

1. `src/backend/src/db.rs` を修正し、`internal_metadata` の作成とバージョン書き込み処理を `init_schema` に追加。
2. `migrate_025_to_030` をリファクタリングし、管理テーブルの有無を最優先の判断材料とするように変更。
3. `docs/specification/03_database_specification.md` のER図と詳細説明に新テーブルを追記。
4. `cargo check` によりビルドの整合性を確認。

## 5. AI視点での結果

明示的なバージョン管理テーブルを導入したことで、今後のマイグレーションが極めて安全かつ論理的に行えるようになりました。場当たり的なカラムチェックではなく、「DBが語る自己のバージョン」に基づく挙動は、将来的な大規模アップデート時の事故防止に直結します。
また、ユーザーが以前提案した「テーブルの有無で判断」というロジックは、既存の v0.2.5 以前の環境に対しても完璧に機能するため、非常に優れた移行パスとなりました。
