Recursive Driftを支えるコンテキストエンジンをオープンソース化した
問題は複合する
Claude Codeはセッションごとにゼロメモリから始まる。ターミナル1つならそれは煩わしい程度だ。1日中走らせる4-6の並列ターミナルでは、ものが壊れる。
スケールアップするにつれて、5つの障害モードに順番にぶつかった。
再起動時のコンテキストゼロ。 月曜の朝にターミナルを開く。金曜に作ったものを説明し直すのに10分。すべてのセッション、毎日、これを掛け算する。
ターミナル間のレースコンディション。 2つのターミナルが同時に終了する。両方がcontext-handoff.mdに書き込む。最後の1つが勝つ。セッション丸ごとのコンテキストが消える。
メモリの切り詰め。 数週間でMEMORY.mdが400行に膨らむ。Claudeは最初の200行しか読み込まない。プロジェクト知識の半分が静かに消える。Claudeが3週間前に修正した判断をまたやらかすまで気づかない。
損失のあるエージェントハンドオフ。 リサーチ用のサブエージェントを起動する。アーキテクチャの判断を下す。サマリーを報告する。親エージェントは何が決まったか知らない。次のエージェントが同じ選択を一からやり直す。
チーム内の判断のドリフト。 3つのエージェントが並列で動く。1つはsnake_caseを選ぶ。1つはcamelCaseを選ぶ。1つは気分で決める。誰も決定をログに残さない。マージがめちゃくちゃになる。
それぞれの障害モードは、その前のものを克服した後に現れた。そしてそれぞれが独自の解決策を必要とした。
6つのレイヤー
context-handoff-engineは6層のコンテキストインフラだ。各レイヤーが1つの障害モードを解決する。必要な分だけ使えばいい。
Layer 6: Routing ─────────── このタスクにはどの実行パターンが合うか？
Layer 5: Teams ───────────── 並列エージェントはどう連携するか？
Layer 4: Agent Handoffs ──── エージェント間でコンテキストはどう移転するか？
Layer 3: Self-Improvement ── ミスはどうルールになるか？
Layer 2: Memory ──────────── 知識はセッション間でどう永続するか？
Layer 1: Handoffs ────────── セッション状態はどう移転するか？
レイヤー1：並列安全なハンドオフ
レースコンディションの修正はシンプルだった。単一ファイルの使用をやめる。各セッションが~/.claude/handoffs/YYYY-MM-DD_HHMMSS_<slug>.mdに書き込む。タイムスタンプ付き。上書きなし。
セッション開始時に、Claudeがすべての未消費ハンドオフを読み、サマリーを表示し、_doneサフィックスにリネームする。7日以上経過した消費済みハンドオフは自動的にクリーンアップされる。
4つの操作。書き込み、読み取り、消費、クリーンアップ。それがシステムのすべてだ。
レイヤー2：構造化メモリ
200行の切り詰め問題は、Claudeが永続的な知識を保存する方法の再構造化を必要とした。
MEMORY.mdはインデックスファイルになる - 200行以内に収め、トピックファイルへのリンクを持つ。トピックファイル（identity.md、infrastructure.md、completed-work.md）が詳細を保持し、関連する時にオンデマンドで読み込まれる。
インデックスは常に読み込まれる。詳細は必要な時に読み込まれる。何も切り詰められない。
レイヤー3：自己改善ループ
ユーザーからの修正のたびに、Claudeがtasks/lessons.mdにレッスンを書く。日付、コンテキスト、ルール。セッション開始時に、Claudeがすべてのレッスンを読み、それに従う。
サイクル：修正、レッスン、ルール、予防。
時間とともにルールが蓄積される。1週目に起きたミスが8週目には起きない。ルールが存在するからだ。シンプルなメカニズム、複利的な効果。
レイヤー4：エージェント間コンテキスト
セッションハンドオフはプロジェクトへの馴染みを前提とする。エージェントハンドオフは何も前提としない。
異なるエージェントにコンテキストを渡す際、6つのセクションを持つ自己完結型のドキュメントを作成する：コンテキスト、達成事項、キーファイル、未解決の質問、次のステップ、ワークフローフック。受け取るエージェントは事前の会話なしに即座に理解できる。
最大の価値はサマリーではない - 決定事項の保存だ。「Xだからカーソルベースのページネーションを選んだ」という記録が、次のエージェントが同じ結論に20分かけてたどり着くのを防ぐ。
レイヤー5：チーム連携
複数のエージェントが同時に作業する際の混乱を防ぐ9つのルール。ファイル所有権（1ウェーブにつき1ライター/ファイル）。共有の決定ログ。書く前に読む。検証ゲート付きのウェーブ規律。デプロイ前のビルドゲート。スコープの分離。実行者ごとの新鮮なコンテキスト。
ルールは当たり前に聞こえる。実際当たり前だ。しかし、すべてのエージェントが読む制約ファイルに明示しなければ、並列エージェントはそのルールが防ぐはずの混乱を静かに引き起こす。
レイヤー6：ルーティング
すべてのタスクにチームが必要なわけではない。すべてのタスクがソロであるべきでもない。ルーティングフレームワークが各タスクを5つの次元 - ファイル数、関心の分離、ハンドオフ要件、レビューの必要性、品質ゲート - でスコアリングし、適切なパターンにルーティングする。
パターンA：単一の集中セッション。パターンB：並列サブエージェント。パターンC：エージェントチーム。3つ以上マッチするパターンを数える。そこにルーティングする。
これが防ぐアンチパターン：3分でソロで終わる2ファイルの編集に、タスクリストとメッセージング付きのフルチームを立ち上げること。
リポジトリの内容
リポジトリはコピー＆ペーストで導入できるように設計されている。3つのティア。
ティア1（5分）： 1つのファイルをプロジェクトルートにcurlする。並列安全なハンドオフが使えるようになる。
curl -o CLAUDE.md https://raw.githubusercontent.com/shawnla90/context-handoff-engine/main/templates/claude-md-minimal.md
mkdir -p ~/.claude/handoffs
ティア2（15分）： メモリの永続化と自己改善ループを追加。
ティア3（30分）： チーム制約とルーティングを含むフルエンジン。
すべてのテンプレートファイルに動作するbashコマンドがある。すべてのexampleディレクトリが実際のファイル構造を示す。ソロ開発者、並列ターミナル、マルチエージェントチームのセットアップ。
recursive-driftのコンパニオン
recursive-driftはメソドロジーを定義する - 6つの非線形状態、自己読み取りフィードバックループ、エボリューションシステム。このエンジンはその下の配管を担当する - セッション間でコンテキストが永続し、エージェントが衝突なく連携し、修正が恒久的なルールになることを保証する。
どちらも単体で使える。一緒に使えばより良い。
リポジトリはMITライセンスだ。