AITM は、確実に動作し、プロジェクトについて学んだことを記憶できるよう、ローカルにかなりの量の状態を保持しています。ここでは、何が保存されているか、そしてそれがなぜ重要かを、平易な言葉でまとめます。

AITM が保存するデータ

データマップ

ローカルに永続化された状態が重要な理由

これらは付随的な帳簿管理ではなく、このガイドの他の箇所で扱うすべてを支える仕組みです。

• プロジェクトごとのデータベースがあるからこそ、コントラクト、タスク履歴、先例の検索が、アプリを閉じるたびにリセットされることなく、セッションをまたぎ、タスクをまたいで保持されます。
• タスクデータフォルダがあるからこそ、アーカイブは単なるタイトルの一覧ではなく、本当に役立つ監査証跡になります。そこに表示される結果、スクリーンショット、メタデータの各フィールドは、すべてこれらのフォルダから直接読み取られています。
• Worktrees は、パイプラインで説明している分離の保証を機械的に支える基盤です。各タスクが本当に別のファイルシステム上のチェックアウトを持つため、作業中の内容が誤ってメインブランチに漏れ出すことはありません。
• ナレッジグラフのドキュメントは、「AI がたまたま何かを覚えていた」状態を、「プロジェクトが自身の振る舞いについて、耐久性があり確認可能な記録を持っている」状態に変えるものです。ナレッジ共有を参照してください。

データベースのバックアップを、際限のない増加と気づかれないデータ損失から守る仕組み

データベースのバックアップ自体にも保護が必要です。そうでなければ、ディスクを使い切ってしまったり、最も必要なときに静かに消えてしまったりするかもしれません。AITM は段階的な保持ポリシーのもとでバックアップを保管し、そのサイズの異常を監視します。

• 段階的な保持 — N日より古いデータベースのバックアップをすべて一度に削除する単一の固定的な基準では、1日分の実行が欠けただけで、すべての DB バックアップが一気に消えてしまう可能性があります。そうではなく、AITM はバックアップを徐々に間引きます。直近の日次バックアップを数件、数日間隔の古いバックアップをいくつか、さらに古い週次バックアップを1件保持します。その結果、少数でありながら分散した復旧ポイントが得られ、バックアップ用ストレージが際限なく増えることもありません。
• サイズ異常のアラート — プルーニングが行われる前に、AITM は今日のデータベースバックアップのサイズを昨日のものと比較します。大幅な減少（データ損失の可能性）や、予期しない大幅な増加があると、以前のサイズ、現在のサイズ、変化の割合を含むメールアラートが送信されます。そのため、古い正常なバックアップが上書きまたはプルーニングされる前に、異常を知ることができます。
• 増分（delta）バックアップの検証付きプルーニング — 3日より古い増分の復旧用バックアップは継続的にプルーニングされますが、そのチェーンで保持される最新のバックアップが破損していないことが検証された後にのみ行われます。その検証が失敗した場合、そのデータベースのプルーニングは停止し、それより古いものは何も削除されません。したがって、最新のバックアップが1つ破損していても、その下にある古い正常なバックアップの削除へ連鎖することはありません。