配布資料 42事例 #02: プロジェクト記憶の引き継ぎが静かに取りこぼされ続けた

コミットは成功します。エラーも出ません。なのに記憶が引き継がれていません。 いちばん気づきにくい種類の事故でした。

何が起きたか

プロジェクト記憶——AI の長期記憶——を SQLite の DB としてリポジトリに置き、git 経由で別端末へ引き継ぐ構成を採っていました。

セッション終了時に手動で git add して commit します。 コミットは成功したように見えるのに、記憶が引き継がれません。 これが繰り返し起きました。

原因は SQLite の WAL（先行書き込みログ）モードでした。 書き込み内容は git 管理外の別ファイルに滞留し、チェックポイントするまで本体の DB ファイルに反映されません。本体が「無変更」に見えるので、git は何もコミットしていなかったのです。

なぜ起きたのか

表面的には、手動 git add では WAL がフラッシュされないことです。

構造のほうが厄介でした。 既存の予防フックが「DB ファイルがステージ済みのときだけチェックポイントする」条件になっていました。つまり未統合のときほど発動しません。 見事な catch-22 です。

別の壊れ方もしました。記憶への長文書き込みが蓄積し、読み出しがサイズ超過エラーで機能停止しました。 記憶は書きすぎでも壊れます。

そこから生まれたルール

「記憶の同期は専用スクリプト（チェックポイント→add→commit→push を一括実行）以外で行わない。手動 git add は禁止」

「記憶には要点のみ書き、実装詳細はイシューコメントを正本にする」

どう機械に守らせたか

①pre-commit フックを「WAL に未統合バイトがあれば無条件にチェックポイント + add」に改修 ②pre-push フックが未統合を検出したら push を中止する（安全網） ③セッション開始フックが git フックの未取付を自動修復する ④長文書き込み（1500字超）には警告フックを出す

持ち帰るなら

「成功したように見えて何も起きていない」サイレント失敗が、記憶やバックアップの系では最も危ないです。

同期は1コマンドに固めます。手動手順は禁止します。 そして検知の側は、「失敗時に発動しない条件になっていないか」まで疑ってください。