recallloom

RecallLoom

RecallLoom は、セッションベースのエージェント向けに、持ち運び可能なコンテキストハーネスを提供します。

重厚なインフラストラクチャを必要とせず、セッションをまたいだプロジェクトの継続性を支える、軽量なファイルモデルを提供します。

すべてを記憶することが目的ではありません。適切なプロジェクトの状態をセッションをまたいで永続化し、読みやすく、復元可能に保つことが目的です。

パッケージの範囲

このファイルは、インストール可能な recallloom/ スキルパッケージのエージェント向けエントリーポイントです。

このパッケージは、ホストエージェント標準のスキル検出フローを通じてインストールし、呼び出してください。 RecallLoom 自体は、パッケージ内にホスト固有のカスタムランチャーを必要としません。 パッケージには、サポート対象のホスト向けに、任意のネイティブラッパーテンプレートを含めることもできます。

このインストール可能なパッケージは、意図的に軽量に保たれています。 人間向けのリポジトリのランディングページやマーケティング資料が上流に存在する場合がありますが、インストールされたスキルディレクトリには含まれません。

ソースリポジトリでは、README.md と README.en.md が簡潔な公開向けエントリーポイント、README.zh-CN.md が互換性のためのエントリー、INDEX.md が全体の案内、USAGE.md が運用ガイドです。 これらのファイルは、別のロジックを定義するのではなく、インストール済みパッケージのこのエントリーポイントと同じヘルパー契約を説明しています。

パッケージの内容、プロトコルの詳細、ヘルパースクリプトの動作については、パッケージ自体に含まれる次のファイルを参照してください。

• managed-assets.json
• package-metadata.json
• references/file-contracts.md
• references/operation-playbooks.md
• references/package-support-policy.md
• references/recording-workflow.md
• references/protocol.md

パッケージ情報

• パッケージのバージョン：0.5.0
• プロトコルのバージョン：1.0
• サポート対象のプロトコルバージョン：
  • 1.0

実行時の前提条件

• Python 3.10 以降
• サポート対象のワークスペース言語：
  • en
  • zh-CN
• サポート対象のブリッジ先：
  • AGENTS.md
  • CLAUDE.md
  • GEMINI.md
  • .github/copilot-instructions.md

パッケージサポートの判定

RecallLoom パッケージのサポート判定は、プロジェクトのサイドカープロトコルとの互換性とは別のものです。

• ヘルパーはパッケージサポートを必ず確認し、プロジェクトの .recallloom/ にサポート状態を書き込んではなりません。
• サポート状態が readonly_only の場合、変更を伴うヘルパーは処理をブロックしなければなりません。一方、診断および読み取り専用のヘルパーは処理を続行してもかまいません。
• サポート状態が diagnostic_only の場合、診断ヘルパーのみが処理を続行すべきです。
• ローカルサポートキャッシュが存在しないためサポート状態が unknown_offline の場合、ローカルの診断、読み取り専用の操作、変更を伴う操作は続行してもかまいません。ローカルで RecallLoom を使うためにネットワークアクセスは必要ありません。
• ローカルサポートキャッシュの構造が無効、または内容を解釈できない場合、オフライン時に許可されるのは診断操作のみです。構造上有効な古いキャッシュは、現在のパッケージバージョンに照らして再評価され、その supported、upgrade_recommended、readonly_only、または diagnostic_only の制限が維持されます。
• 無効なキャッシュの診断では、公開しても安全な理由を示してキャッシュの状態を特定し、読み取り専用の診断、オンラインでの更新とキャッシュのアトミックな置き換え、またはパッケージスコープの無効なローカルキャッシュの削除を案内しなければなりません。パッケージのアップグレードをキャッシュ修復方法として提示したり、キャッシュが改ざんされていると説明したりしてはなりません。
• invalid_support_advisory は、無効なローカルキャッシュとは別の状態です。キャッシュの破損として扱うのではなく、アドバイザリーを修正または更新してください。
• ブロックされた操作は、blocked_reason: package_support_blocked と package_support オブジェクトを含む共通の失敗契約を返さなければなりません。references/package-support-policy.md を参照してください。

公開対象と必須チェック

• パッケージをインストール、理解、運用するためにユーザーが必要とするファイルに、パッケージとリリースの公開対象を限定しなければなりません。
• 公開対象に、複製されたプロジェクトの記憶、生成された実行時出力、マシン固有のデータ、メンテナー専用の作業ファイル、またはインストール可能なパッケージに不要な資料を含めてはなりません。
• 公開 CI と必須チェックでは、リポジトリの内容とメタデータを検証してもかまいません。
• 必須チェックに関する文言で、リポジトリのチェックを、ユーザーのローカルワークスペースの状態、ホストの動作、またはサイドカーの信頼性を証明するものとして示してはなりません。

非侵襲的なデフォルトと UX ゲート

• コアのインストールと日常的な使用において、フック、デーモン、ウォッチャー、MCP／プラグインによる強制、ホストアダプター、テレメトリー／メトリクス、またはリモートへのペイロード送信を必須としたり、自動インストールしたりしてはなりません。
• ネイティブのコマンドラッパーは、同じディスパッチャーを利用する任意の利便性向上用エントリーポイントであり、必須の強制レイヤーではありません。
• 管理対象のサイドカーの外部で行う通常のドキュメント／ソース／計画の編集は、来歴に影響する RecallLoom の状態に関わらない限り、警告を出さずに許可するか、手間を最小限に抑えなければなりません。
• 管理対象のサイドカーに関わる操作、または来歴に影響する操作では、来歴の状態が関連する場合、ヘルパーの準備状況の出力に allow、warn、ask、block のいずれかを表示します。
• warn は、リスクの低い構造上のみの状態や読み取り可能なレガシー状態に使用し、簡潔に保つ必要があります。同一セッション内で繰り返される、同じ低リスクの警告は、クールダウンに配慮してください。
• ask は、レガシーのレビュー／修復インポート、またはレビュー済みインポート基準状態の操作に使用し、リスクの高い書き込みの前に、オペレーターによる明示的な確認を必要とします。
• 偽造されたマーカー、検出されたレシート／ストアの不整合、state.json／config.json の直接編集、プライバシー違反、および inconsistent_or_tampered_evidence と分類された一般、レガシー、またはバインドされていない状態には、例外を認めず block を適用します。
• D5 は唯一の限定的な復旧遷移です。現在の D5 スキーマに対して契約上有効であり、障害発生時の状態と完全に一致する、ヘルパーパスのターゲットのみを対象としたハッシュ後証拠のみが、新たなバインディング、人による提案／レビュー、期待されるバインディングへの昇格を経て処理を進められます。これは例外ではなく、暗号学的な作成者証明にもなりません。昇格の前には、改めて validate、status、preflight を実行する必要があります。D5 の人間向け資料の該当セクション、JSON キー、昇格コマンドについては references/operation-playbooks.md を参照してください。
• リモートサービス、ホストのメモリー、プラグイン、MCP、フック、ラッパーを、ローカルのヘルパー証拠に対する権威として示してはなりません。
• レシートに裏付けられた変更は、ディスパッチャーが発行する管理対象ファイルへの書き込み、現在の最新カーソルへの日次ログの追記、および追記後のサマリー同期に限定されます。アーカイブとブリッジは引き続きプレビュー専用です。これらの対象がそれぞれ独自のレシート対応を備えるまでは、適用モードはサポートされません。

書き込みプロトコルの禁止事項

• 通常運用における管理対象サイドカーの変更には、該当するディスパッチャーのインターフェースを必ず使用してください。管理対象ファイルの書き込みには write、デイリーログへのエントリー追加には append を使用し、追記後の契約でその経路が必要な場合に限り sync-current-state-after-append を使用してください。ファイルを無条件に置き換えたり、パッチを無条件に適用したり、サイドカーファイルを手作業で作成したりして、ディスパッチャーを迂回しないでください。
• 通常運用でのデイリーログへの書き込みには、必ずディスパッチャーの append を使用してください。エントリーは内部ヘルパーが書き込みます。daily-log-entry マーカーを手作業で書き込まないでください。
• 通常運用でのデイリーログのカーソル修復には、必ずディスパッチャーの repair-daily-log-cursor を使用してください。修復は内部ヘルパーが実行します。state.json.daily_logs を手作業で編集しないでください。
• 通常運用での上書き型管理対象ファイルには、必ずディスパッチャーの write を使用してください。リビジョンを考慮したコミットは内部ヘルパーが実行します。file-state マーカーを手作業で書き込まないでください。
• 通常運用中に STORAGE_ROOT/state.json と STORAGE_ROOT/config.json を手作業で編集してはなりません。
• 通常運用では、該当するディスパッチャーのインターフェースのみを使用してください。管理対象ファイルへの書き込みとデイリーログへのエントリー追加には write と append を使用します。sync-current-state-after-append は、追記後の契約でその経路が必要な場合に限り使用します。commit_context_file.py と append_daily_log_entry.py は、ディスパッチャー／統合用の内部インターフェースです。ディスパッチャーは、ヘルパーを呼び出す直前に、自ら最新の事前チェックを実行し、バインディングを作成して、対応するリースを永続化します。読み取り専用の事前チェックでは、どちらのマテリアルも発行されません。また、オペレーターが独立して受け取るためのインターフェースはなく、ディスパッチャーが発行したマテリアルなしでヘルパーを直接呼び出した場合は、失敗することが想定されています。レビュー済みのインポート済みベースラインに対する最初の書き込みには、ディスパッチャーの write または append と --confirm-review-imported-baseline を使用してください。追記後の契約で必要な場合は、追記後の同期経路でもこの確認を受け付けます。内部ヘルパーはこのフラグを受け付けず、ディスパッチャーが発行した、確認に紐づくバインディングとリースのマテリアルのみを使用します。
• プロトコル 1.0 のデイリーログカウンターはファイル単位です。entry-seq は1つのデイリーログ内で 1..N、正規の entry-id は entry-{entry_seq} です。どちらもグローバルに一意だと見なさないでください。
• state.json.daily_logs.entry_count は entry_count のままにしてください。これは最新のアクティブなデイリーログ内のエントリーマーカー数を意味し、累積のグローバル件数ではありません。
• ヘルパーによる書き込みが失敗した場合は、原因を診断して修正し、再試行してください。それでも完了できない場合は、ヘルパーの失敗時の契約に従って報告してください。
• 破損したサイドカーの復旧には、正規の復旧提案／レビュー／昇格ヘルパーと validate_context.py を必ず使用してください。管理対象マーカー、state.json、config.json、レシート、ヘルパーのエビデンス保管領域を手作業で編集しないでください。

使用する場面

次のような場合に RecallLoom を使用します。

• 中断後に既存のプロジェクトを続行する
• 維持管理されているファイルからプロジェクトのコンテキストを復元する
• プロジェクトの現在の状態に関するメモリーを維持する
• 重要なマイルストーンの進捗を記録する
• セッションやツールをまたいだコンテキストのずれを減らす

よくあるきっかけ：

• このプロジェクトを続ける
• プロジェクトのコンテキストを復元する
• 前回の続きから始める
• rl-init
• プロジェクトのメモリーを更新する
• 今日の進捗を記録する
• 維持管理されているプロジェクトファイルに、次の作業へ引き継ぐ内容を整理して記録する

初回アタッチ時の動作

プロジェクトで初めて明示的に呼び出されたとき、RecallLoom はワークスペースがすでに初期化されていると想定してはなりません。

正しいフローは次のとおりです。

1. 有効な RecallLoom サイドカーがすでに存在するか確認する
2. 存在する場合は、初期化を余計な手順にせず、通常どおり続行する
3. 存在しない場合は、プロジェクトがまだ初期化されていないことを説明し、初期化を実行するかどうかを尋ねる
4. ユーザーが明示的に確認するか、直接 rl-init と指示した場合は、標準の初期化アクションを実行する
5. 環境で Python 3.10+ を利用できない場合は、サイドカーを手作業で作成せず、実行環境のブロック結果を返して停止する

rl-init は、サイドカーを初期化し、ワークスペースを検証して、次に推奨されるアクションを返すものです。ホストがネイティブのスラッシュコマンドを公開していない場合でも、安定した高レベルのアクション名として扱ってください。

現在のアクション一覧

現在のパッケージ系列で、オペレーター向けの安定したラッパーのターゲットは次のとおりです。

• rl-init
• rl-resume
• rl-status
• rl-validate

rl-init は、初回アタッチ時にオペレーターが使いやすい主要なアクション名です。 その他は、ホストエージェントが解釈するか、ホストがその機能に対応している場合にネイティブのカスタムコマンドへマッピングできる、オペレーター向けの安定したアクション名です。 rl-bridge は引き続き、ブリッジ処理の標準ディスパッチャー／ヘルパーアクションのラベルですが、このパッケージ系列では、そのラベルに対する汎用的なネイティブラッパーや、決定論的な初回ルーティングを保証しません。 これらのアクションを表す際は、引き続き自然言語をデフォルトの公開表現とします。

ディスパッチャーのコマンド一覧には、quick-summary、record --suggest、record --plan、append、write、sync-current-state-after-append、repair-daily-log-cursor も含まれます。 append、write、sync-current-state-after-append でのみ、上限付きのトランザクション結果が必要な場合は --compact-json を使用してください。このオプションは recallloom.transaction.compact/1.0 を出力し、UTF-8 で 2048 バイト未満に収まり、 従来のスキーマ 1.1 の --json 出力とは併用できません。 現在の状態のスナップショットには quick-summary を、永続化されるマイルストーン／決定／検証のシグナル後に副作用のない記録候補プロンプトを生成するには record --suggest を、記録の意図を分類して次の安全なヘルパーステップを得るには record --plan を、マイルストーンの記録には append --entry-json を使用してください。型付きの管理ファイルへの書き込みを行う前には、write --type ... --source-file <prepared-file> --dry-run または write --type ... --stdin --dry-run を使用してください。また、事前チェックでメタデータのみの post_append_summary_sync が許可された後に限り、sync-current-state-after-append --reuse-current-summary --semantic-unchanged-assertion-json <json> を使用してください。アサーション JSON の制約付きスケルトンについては references/recording-workflow.md を参照してください。 record --suggest は書き込みを行わず、バックグラウンドで監視せず、機密情報や添付された未加工の素材を書き込み経路に変換することもありません。プロンプトが適切な場合に、サニタイズされた記録候補の概要と、推奨される record --plan の経路を返すだけです。 state.json.daily_logs が解析済みの最新のアクティブな日次ログと一致しなくなった場合は、まずプレビューモードで repair-daily-log-cursor を使用してください。プレビューでは、公開しても安全な修復分類、preview_digest、予期されるワークスペースリビジョン、確認用情報、修復後の検証手順が返されます。適用モードでは、--apply --yes と、--expected-workspace-revision または --preview-digest による最新のプレビューとの紐付けが必要です。この操作は変更を伴うためサポート対象が制限されており、ヘルパーのレシートを書き込んだり、日次ログの内容を書き換えたりせずにカーソルフィールドを修復します。 これらのディスパッチャーの追加機能は、既存の v0.3.4 プロジェクトでは任意であり、サイドカープロトコル 1.0 は変更しません。

rl-init、rl-resume、rl-status、rl-validate のネイティブラッパーは、利便性のためのエントリーポイントにすぎません。同じディスパッチャーに処理を委譲する必要があり、自然言語による復元リクエストを置き換えたり、ヘルパーを迂回したり、ホスト固有の製品ロジックの複製を作成したりしてはなりません。

初期化済みプロジェクトの復元契約

ホストまたはエージェントが、一般的な初期化済みプロジェクトの復元リクエストを受け取った場合：

1. スキルを広範に呼び出す前に、有効な RecallLoom サイドカーがあるか確認します
2. サイドカーが有効な場合は、通常の RecallLoom 高速パスに進みます
3. サイドカーが存在しない、競合している、明らかに不十分である場合、またはユーザーが明示的に詳細なレビューを求めた場合に限り、より広範なメモリシステムやワークフローシステムを参加させます

現在のパッケージ系列では、rl-resume が、初期化済みプロジェクトの復元チェックポイントに対する、オペレーター向けの唯一の安定したアクション名です。 自然言語による復元リクエストが、引き続き主要な公開パスです。 パッケージ契約に裏付けられていない手動のサイドカーフォールバックや、ホスト固有の復元エイリアスを作らないでください。

公開インタラクションのルール

RecallLoom では、実装に関する言葉ではなく、ユーザーのタスクに関する言葉をデフォルトで使ってください。

• 「初期化する」「復元する」「既存プロジェクトの実態をインポートする」「続行する」「進捗を記録する」を優先します。
• ユーザーが明示的にオペレーター作業やデバッグ作業をしている場合を除き、ヘルパー名、セクションキー、coldstart というラベルから説明を始めないでください。
• 最初の応答は結果を優先し、アクションの提示は最小限にします。ルーティングの詳細を示すより、明確な次の手順を1つ示す方が適切です。
• 実行時の要件が満たされていない場合に、手動のサイドカーフォールバックを作らないでください。ブロックされた状態を示し、そこで停止します。
• これはサイドカーを手作業で構築するものではなく、パッケージ化された復元およびヘルパーの契約です。

高速パスと詳細パス

RecallLoom では、高速パスをデフォルトのインタラクションモードとして扱ってください。

• 高速パス：信頼できる情報源の範囲を最小限にし、インタラクションを最短にし、中断のコストを最小限にします。
• 詳細パス：情報源が競合している場合、情報源の網羅性が不十分な場合、直接推奨するにはリスクが高すぎる場合、またはユーザーが明示的に詳細なレビューを求めた場合にのみ使用します。
• ホストメモリからの入力は引き続きオプトインかつヒントに限定されます。そのような入力が存在する場合、エージェントは暗黙に昇格させるのではなく、明示的なレビューを促すようにしてください。

再開モードの選択：

• 次のエージェントが、何を読むか決める前に通常の段階的な読み取り計画のガイダンスを必要とする場合は、環境に応じて resume または status を使います。
• 現在の状態の把握で十分であり、state.json と rolling_summary.md に基づいて次の安全な手順を選べる場合は、resume --fast を使います。
• アクションの前に、安定した枠組み、信頼できる情報源へのルーティング、またはプロジェクト固有の update_protocol.md のガイダンスが必要な場合は、resume --full を使います。
• 日次ログのエビデンスは query_continuity.py で必要に応じて参照します。高速モードと完全モードの再開では、デフォルトで日次ログまで対象を広げないでください。

コアファイルモデル

RecallLoom は、3つの主要なメモリレイヤーを使用します。

• STORAGE_ROOT/context_brief.md：安定したプロジェクトの概要
• STORAGE_ROOT/rolling_summary.md：上書き形式の現在状態のスナップショット
• STORAGE_ROOT/daily_logs/YYYY-MM-DD.md：追記専用のマイルストーンエビデンス
• STORAGE_ROOT/config.json：機械可読なワークスペース設定
• STORAGE_ROOT/state.json：並行処理を考慮したヘルパー用の機械可読なサイドカー状態
• STORAGE_ROOT/update_protocol.md：読み取りと書き込みの動作をプロジェクト内で上書きするための推奨レイヤー

各ファイルの役割を一文で説明すると、次のとおりです。

• context_brief.md は、このプロジェクトの概要と取り組み方を説明します。
• rolling_summary.md は、現在の状況を説明します。
• daily_logs/ は、マイルストーン単位で何が起きたかを説明します。
• config.json は、ストレージと言語の設定を維持します。
• state.json は、ワークスペースのリビジョンと、ヘルパーから参照可能なサイドカー状態を追跡します。
• update_protocol.md が存在する場合、この特定のプロジェクトに対するデフォルトの読み取り／書き込みルールを限定または強化できます。

STORAGE_ROOT は PROJECT_ROOT/.recallloom/ または PROJECT_ROOT/recallloom/ のいずれかです。有効なストレージルートは1つだけ存在してよく、両方が存在する場合は推測せずに停止してください。

規範となるファイル契約は見出しラベルではなく、機械可読なマーカーです。プロトコル 1.0 は、ワークスペース言語として en と zh-CN をサポートします。references/file-contracts.md を参照してください。

最小コールドスタートフロー

1. プロジェクトのルートを探します。
2. STORAGE_ROOT/config.jsonを読み込みます。
3. STORAGE_ROOT/state.jsonを読み込みます。
4. STORAGE_ROOT/rolling_summary.mdを読み込みます。
5. STORAGE_ROOT/update_protocol.mdが存在する場合は、最小限の継続性セットを超えて読み進める前に、その内容を提示します。
6. 現在のタスクに、サマリーでまだカバーされていないフレーミング、スコープ、信頼できる情報源、またはフェーズのコンテキストが必要な場合に限り、STORAGE_ROOT/context_brief.mdを読み込みます。
7. マイルストーンの根拠、作業日の判断、または外部書き込みの調整が必要な場合に限り、最新のアクティブな日次ログを読み込みます。
8. 古いコンテキストを信頼する前、または大きな書き込みを行う前に、簡易な鮮度チェックを実行します。

コールドスタートでは、まず復元と判断を行う必要があります。 継続性ファイルを読み込んだだけで、next_stepを自動的に続行したり、プロジェクト作業を実行したりしてはいけません。

全体のフローについては、references/operation-playbooks.mdを参照してください。

現在の読み取り側ヘルパー

ここでは、読み取り側のヘルパーが3つ重要です。

• preflight_context_check.py：正式な書き込みの前に、リビジョンを考慮した鮮度レビューを実施します。引き継ぎ優先のダイジェスト、推奨される読み取り対象、書き込み階層のガイダンス、信頼性／ドリフト状態を返します。
• summarize_continuity_status.py：同じ鮮度基準に基づく、常時参照可能な継続性ステータスを提示します。同じダイジェスト群に加え、共有作業日状態と信頼性／ドリフトのガイダンスを返します。
• query_continuity.py：読み取り専用の継続性検索を提供します。answer、裏付けとなる引用、リスク／鮮度に関する注記を含む、回答優先の検索結果を返します。また、ヒット、トークン数の推定、予算のヒント、鮮度／競合状態、信頼性／ドリフト状態、出力バリアントのラベル、オーバーライドのレビュー対象も返します。日次ログの引用には明示的なdate値が含まれ、競合時には現在の状態を示すファイルが優先され、コンテキストウィンドウは上限内に保たれます。

これらの読み取り側サーフェスから返される、添付可能な継続性テキストはすべて、共有の添付テキストスキャン規則に従う必要があります。

最小限の書き込みルール

• 書き込み先を選ぶ前に、STORAGE_ROOT/update_protocol.mdが存在する場合は読み込みます。
• current_stateの変更は、通常rolling_summary.mdを対象とします。
• stable_ruleの変更は、通常context_brief.mdを対象とします。
• milestone_evidenceは、通常日次ログを対象とします。
• 永続的な変更を伴わない簡単な読み取りや軽微な編集では、コンテキストファイルを更新しないでください。

書き込み前のデフォルトの終了結果は、常に明示してください。

• no_writeは、正常な結果の一つです
• merge_current_stateは、rolling_summary.mdを更新します
• append_milestoneは、日次ログに追記します
• confirmとblockedは、推測による自動書き込みを停止します

読み取り側の信頼性に関する注記：

• sidecar_trust_stateはヘルパーのJSONに保持し、プロトコル1.0には含めません
• state.json.provenanceには、レシートによって確定されたヘルパーの書き込み後に、structurally_valid、review_imported_baseline、helper_evidencedなどのローカルな来歴マーカーを保存できます。運用上のprovenance_stateのルーティングは、引き続きヘルパーのJSONが担います
• ベースラインメタデータのないレガシーサイドカーは読み取り可能ですが、ヘルパーの書き込みを変更する前に、書き込みの準備状況をレビュー／修復インポート経由でルーティングする必要があります
• structurally_validとreview_imported_baselineが示すのは、構造／準備状況に関する根拠のみです。helper_evidencedとして扱ってはなりません
• レシートによる裏付けのある来歴を主張できるのは、ディスパッチャーによるレシートの確定処理が、任意のローカルレシートストアへの書き込みと来歴メタデータの更新を行った後に限られます。構造検証だけでhelper_evidencedを出力してはなりません
• デフォルトのrl-validate／validate_context.pyは、引き続き構造検証のみを行い、任意のレシートストアは読み取りません。レシートストアの検証は明示的に行います。--require-provenanceと、--changed-onlyまたは--fullのどちらか1つのスコープフラグを指定してください
• continuity_drift_risk_levelはレビューのためのシグナルであり、サイドカーが破損していることを証明するものではありません
• allowed_operation_levelとwrite_readinessは、ホストが低リスクの読み取り、レビュー優先、または事前確認後の書き込みフローを振り分ける際に役立ちます

プロジェクト固有のオーバーライドによって、読み取り順、書き込み順、またはアーカイブの動作を絞り込むことはできます。ただし、コアファイルの契約に代わるものではありません。

エージェントによるレイヤー分けの判断

継続性に関する内容を書き込む前に、エージェント自身がレイヤーを判断する必要があります。ヘルパーは安全な書き込みコンテキストや静的な書き込みレベルの指針を提供できますが、内容の意味に関するエージェントの判断に取って代わってはなりません。

管理対象ファイルを編集する前に、次の項目を確認してください。

1. 新たに長期的に保持すべき事実がありますか。それとも no_write が適切ですか？
2. 書き込みが必要な場合、主な内容は stable_rule、current_state、milestone_evidence のどれですか？
3. その出来事は複数のレイヤーにまたがるため、multi_layer_split が必要ですか？
4. 同じ事実がすでに記録されているため、重複ではなく統合するのが適切ですか？
5. レイヤーが不確かで、推測するのではなく defer または confirm にすべきですか？

レイヤーの既定値：

• stable_rule：長期的に有効なワークフロールール、情報源の振り分け、プロジェクトの境界、または復旧に関する事実です。既定の保存先：context_brief.md。
• current_state：現在のフェーズ、進行中のリスクや判断、次のステップなど、現在の状況です。既定の保存先：rolling_summary.md。
• milestone_evidence：完了した検証、承認、リリース、確定した決定、その他長期的に有効な証拠です。既定の保存先：日次ログ。
• 永続的な変更がない場合、議論がまだ安定していない場合、または境界に明示的な承認が必要な場合は、no_write、defer、confirm を有効な結果として選択できます。

複数のレイヤーが適切な場合は、異なる事実を各レイヤーに分け、同じ文を重複して記載しないでください。

詳細なルール、競合時の優先順位、自己レビュー用テンプレート、匿名化された調整事例については、references/operation-playbooks.md を参照してください。

プロトコル 1.0 では、update_protocol.md は人がレビューするオーバーライドレイヤーです。ヘルパーはその内容を提示しますが、自然言語で記述されたルールを自動的に実行することはありません。

RecallLoom は、有効な書き込みを最小限に抑えることを重視します。変更すべき内容を決めて準備するのはエージェントであり、その書き込みを引き続き安全に適用できるかどうかを判断するのはヘルパーです。

ワークスペースファイルを生成する際は、プロトコル 1.0 でサポートされている場合、ユーザーのワークスペース言語（en、zh-CN）を優先してください。

コンテキストを更新しない場合

次の理由だけでコンテキストファイルを更新しないでください。

• コールドスタートを行った
• プロジェクトに永続的な変更を加えずに短い質問へ回答した
• 安定した結論に至らないまま調査した
• 表現のみを編集した

このプロトコルはノイズを減らすためのものであり、すべてのセッションでドキュメント作成を行うことを目的としていません。

プロファイル

RecallLoom には次の 4 つのプロファイルがあります。

• profiles/general-project-continuity.md
• profiles/research-writing.md
• profiles/product-doc-collaboration.md
• profiles/software-project-coordination.md

プロファイルは、重視する点、証拠の扱い、内容のずれのリスクを調整します。既定では general-project-continuity.md を使用し、プロジェクトの特性が専門プロファイルと高い確度で一致する場合にのみ切り替えてください。

RecallLoom が目指していないもの

RecallLoom は、次のものを目指していません。

• 汎用メモリーサーバー
• 完全なエージェント実行ランタイム
• プラットフォーム固有の指示ファイルの代替
• 大規模で自律的なコーディングフレームワーク

これはプロジェクトの継続性を担うレイヤーであり、エージェントスタック全体ではありません。

詳細はこちら

• references/protocol.md
• references/file-contracts.md
• references/operation-playbooks.md
• references/anti-patterns.md
• references/profiles.md

ライセンス

このパッケージは Apache License 2.0 の下でリリースされています。