Journal: 20260223-0018-データベースのマイグレーション対応（v0.2.5→v0.3.0）

1. 作業実施の理由

v0.3.0 で実施したテーブル構造の正規化により、以前のバージョン（v0.2.5）とのデータベース互換性が失われていた。既存ユーザーがデータを失うことなくスムーズに移行できるよう、自動マイグレーション機能を実装するため。

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

指示: 「マイグレーション作れる？」→「ごー」
背景: 手動でのDB削除・再構築はバリアが高いため、起動時に自動でスキーマを変換したい。
意図: 既存の items テーブルからドキュメントメタデータを抽出し、新しい 1:N 構造（documents テーブルとの紐付け）に再編する。その際、ベクトルデータとの整合性を保つため id を維持する。

3. 指示事項とその対応

自動検知: PRAGMA table_info(items) を使用して、古い path カラムの有無でマイグレーションの要否を判断。
データ移行:
- documents テーブルを新規作成し、ユニークなパスを移行。
- items テーブルを新スキーマで再作成（document_id を付与し、chunk_index を自動生成）。
- 全工程を一つのトランザクション内で実行し、整合性を担保。

4. 作業詳細

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

src/backend/src/db.rs に migrate_025_to_030 関数を実装。
init_schema の冒頭で上記関数を呼び出すように修正。
cargo check によりコンパイルの整合性を確認。
ウォークスルーを作成し、移行ロジックの妥当性を整理。

5. AI視点での結果

今回のマイグレーション対応により、ユーザーは特別な操作をすることなく TelosDB v0.3.0 へアップデート可能になりました。内部的にはテーブルのリネーム、データの再挿入、外部キー制約の一時解除など複雑な処理を行っていますが、これらをカプセル化することで、プロダクトとしての堅牢性とユーザー体験の両立を実現しました。以前のベクトル ID をそのまま引き継ぐ設計としたため、再インデックスの手間も最小限に抑えられています。