Cambium

cambium

xylem スタックの一部です。

エージェントがすでに行った作業を、組織全体で活用できる複合的なナレッジに変える、ナレッジライフサイクル MCP です。cambium はすでに存在する 2 つの基盤をつなぎます。agentsync（何が起きたか：主張、完了、メモ、変更ファイル）とcontext-keeper（なぜか：決定事項、制約）を結び、どちらにもない次の 3 つの機能を追加します。

1. distill() — イベントを自動的にメモリに変換します（受動的なキャプチャ）
2. recall() — あらゆるエージェントタイプに対応する、統合された読み取りエンドポイントです （コーディングエージェント、Slack ナレッジベースボット、SRE ボットで同じストア、同じ呼び出し）
3. promote() — 信頼を得るにつれて、ナレッジをローカル → チーム → 組織へ昇格させます

木の形成層にちなんで名付けられました。あらゆる成長が起こる、薄い生きた組織です。

3 つ目の MCP を作る理由（データベースではなく）

ナレッジレイヤーが機能しないのは、誰も呼び出さないサイドシステムだからです。cambium の考えは、キャプチャと呼び出しがエージェントのループに組み込まれたネイティブツールでなければならず、状態は別のサービスではなく、作業がすでに存在する基盤である gitに保存しなければならない、というものです。ストレージは recall() の背後に隠された実装の詳細です。

範囲	保存場所	信頼の基準
local	<repo>/.cambium/knowledge.json	なし — あなたのものです
team	共有リポジトリの専用 cambium ブランチにある knowledge.json	想起が N 回以上 または 承認
org	専用の組織ナレッジリポジトリにある knowledge.json	承認が必須です。オプションでプルリクエストとして取り込むこともできます。レビューが基準となり、元に戻すには git revert を使います

チームへの書き込みには agentsync のパターンを使用します。.git/ の下にプライベートなワークツリーを作成し、git push を比較交換として使うため、同時に動作するエージェントが互いの変更を上書きすることはありません。

インストール

pip install -r requirements.txt      # just `mcp`

プルリクエストモードで組織への昇格を行う場合に限り、gh（GitHub CLI）が必要です。

設定

MCP クライアントをサーバーに接続します。起動時に環境変数を設定する必要はありません。

{
  "mcpServers": {
    "cambium": {
      "command": "python3",
      "args": ["/abs/path/to/cambium_server.py"]
    }
  }
}

初回から、親切に案内します。 MCP サーバーは会話を開始できないため、cambium は独自の応答を通じて使い方を案内します。設定前に status()（または任意のツール）を呼び出すと、単なる環境変数エラーではなく、構造化されたガイダンスが返されます。設定済みの項目、不足している項目、それぞれの不足による影響、そして問題を解決する正確な setup() の呼び出し方が示されます。

{
  "configured": false,
  "gaps": [
    {"setting": "CAMBIUM_REPO",
     "cost": "no project repo → cambium has no substrate; every tool is unavailable",
     "fix": "setup(project_repo=\"/abs/path/to/your/clone\", agent_id=\"your-id\")"},
    {"setting": "CAMBIUM_ORG_REPO",
     "cost": "org scope off → promotions stop at team; org-wide recall unavailable",
     "fix": "setup(project_repo=…, agent_id=…, org_repo=\"owner/knowledge or /abs/path/to/clone\")"}
  ],
  "next_step": "setup(project_repo=\"/abs/path/to/your/clone\", agent_id=\"your-id\")"
}

setup(project_repo, agent_id, org_repo?, org_pr?, team_branch?) で設定を完了します。パスを検証し、.cambium/ を作成して（リポジトリの .gitignore に追加し）、環境変数がない場合にサーバーが読み込むフォールバック設定を ~/.cambium/config.json に書き込みます。変更はすぐに反映され、再起動は不要です。シークレットは書き込まれません。ファイルに含まれるのはパス、ID、フラグのみで、リポジトリの外部に保存されます。org_repo がローカルにクローンしていない GitHub の owner/name の場合、setup はリポジトリを用意するための正確な gh／git コマンドを提示し、組織スコープはオフのままにします。リポジトリを作成したり、プッシュしたりすることはありません。

環境変数が優先されます。 MCP クライアントの設定で以下の変数を設定すると、キーごとに設定ファイルの値が上書きされます。この表が完全なリファレンスです。

環境変数	必須	デフォルト	意味
CAMBIUM_REPO	はい	—	プロジェクトのクローン（ローカルスコープ、agentsync と context-keeper の基盤）
CAMBIUM_AGENT_ID	はい	—	エージェント固有の ID
CAMBIUM_REMOTE	いいえ	origin	git リモート
CAMBIUM_GIT_TIMEOUT	いいえ	25	呼び出しごとの git／gh タイムアウト（秒）。処理が停止した呼び出しをサーバーが待ち続けず、すぐに失敗させます
CAMBIUM_TEAM_BRANCH	いいえ	cambium	チームスコープのブランチ
CAMBIUM_AGENTSYNC_BRANCH	いいえ	agentsync	distill が読み取る調整ブランチ名
AGENTSYNC_BOARD_REPO	いいえ*	—	ボードを保持するリポジトリ。agentsync が読み取るものと同じ設定なので、2 つのサーバー間で食い違いが生じません（以下を参照）
CAMBIUM_ORG_REPO	いいえ	—	組織ナレッジリポジトリのクローンへのパス（これがない場合、組織スコープはオフ）
CAMBIUM_ORG_PR	いいえ	直接プッシュ	1 = 組織への昇格時にプルリクエストを作成
CAMBIUM_PROMOTE_RECALLS	いいえ	3	ローカルからチームへの昇格に必要な再利用回数
CAMBIUM_RELEASE_CAPTURE	いいえ	オフ	1 = 完了／リリースへの移行時に agentsync の要求もキャプチャ（以下を参照）
CAMBIUM_CONFIG_FILE	いいえ	~/.cambium/config.json	フォールバック設定ファイルのパスを上書き（主にテスト用）

agentsync ボードの場所（ボードの指定）

• distill() は、完了した agentsync の要求を調整ボードから読み取ります。このボードは共有される、長期間使用するチームの成果物であり、現在のセッションのプロジェクトに依存するものではありません。そのため cambium は、セッションとは独立して、agentsync 自体とまったく同じ優先順位でボードの場所を解決します。

1. AGENTSYNC_BOARD_REPO — 明示的に指定したボードの場所（環境変数、または ~/.cambium/config.json の同じキー）。1 つの設定で両方のサーバーを構成します。
2. AGENTSYNC_REPO — agentsync の従来の明示的な指定。
3. CAMBIUM_REPO — ただし、そのリポジトリに調整ブランチが実際に存在する場合に限ります（ローカル HEAD → リモート追跡参照 → ls-remote の順に実際の参照を検索）。
4. それ以外の場合はボードなしとして明確に報告されます（次のセクション）。通知せずに処理することはありません。

理由。 以前、cambium は CAMBIUM_REPO で調整ブランチを探す一方、agentsync は（明示的な指定がなければ）~/.xylem/active_project.json に従っていました。そのため、両者が異なるリポジトリを参照する可能性があり、現在のプロジェクトがまだプロビジョニングされていない場合は、どちらも何も見つけられませんでした。distill() はその状態を単純な "no coordination branch found" という文字列で報告し、呼び出し側はそれを通常の状態として扱っていました。その結果、3 本脚の設計が知らぬ間に 2 本脚で動作し、distill は全期間を通じて agentsync の要求を一件も取り込めませんでした。

スキップされたソースは、完了したソースのようには見えません

distill() の戻り値が変更され、見つからなかった場合に成功と誤認できなくなりました。

• トップレベルの status は "distilled" ではなく "distilled_with_warnings" になります。
• トップレベルの warnings には、スキップされた基盤ごとに平易な説明が記録されます。
• sources.agentsync は {status, board_repo, board_source, branch, claims_seen, done_claims, imported, reason, fix} というオブジェクトです。そのため、「ボードがない」「ボードはあるが、誰も何も完了していない」「3 件インポートされた」という結果が、空の数字ひとつではなく、それぞれ明確に区別されます。

status() は同じ内容を substrates.agentsync_board に報告します。

組織のセットアップ：たとえば github.com/you/knowledge に、空の {"items": []} を含む（プライベートな）リポジトリをひとつ作成します。組織のナレッジを読み取る必要があるメンバーは全員、それをクローンし、CAMBIUM_ORG_REPO（または setup(org_repo=…)）にそのクローンを指定します。cambium はそのクローンを管理し、強制的に同期します。専用にして、そこで作業しないでください。

ツール

capture(content, type, kind, why, tags, valid_while) — ナレッジアイテムをローカルスコープに保存します（タイプ：memory | need | skill）。手動で行う方法です。 valid_while には、アイテムが依存する前提を任意で指定できます。そうすることで、後になって誤った前提を見つけやすくなります（Machine-maintained documentation entropy を参照）。

record_need(content, why, tags) — ニーズ（「X が不足している」）を第一級の項目として記録します。他の項目と同様に昇格できるため、繰り返し寄せられる要望をチームや組織のレベルで把握できます。

distill() — 自動で行う方法です。agentsync の調整ブランチ（現在 完了している 各 claim：タスク + メモ + 変更ファイル → outcome メモリ）と、context-keeper の .context/（有効な決定と制約。根拠および dec-NNN の出所情報を保持）を読み取ります。冪等なので、セッション終了時やコミット後のフックに接続すれば、capture を意識せずに使えます。

リリース時のキャプチャ（オプトイン、CAMBIUM_RELEASE_CAPTURE=1）。 agentsync は claim をエージェント ID にひも付けており、解放または再取得された時点で、その claim をライブ状態から削除します。提供されるのは、ブランチ上で書き換えられた claims.json だけで、フックやイベントはありません。そのため、完了後、完全な distill が実行される前に状態が変化した claim は、ひそかに失われます。このフラグを有効にすると、各 distill はエージェントごとに最後に確認した claim も記憶し、前回の実行以降に 状態が変化して消えた claim をすべてキャプチャします。スナップショットからその claim を再構築し、同じ重複排除ウォーターマークを使うため、解放時にキャプチャされた claim が後の完全な distill でも二重にインポートされることはありません。完了イベント（コミット後／セッション終了時のフック）で distill() を実行すれば、完了した作業は、たまたまライブ状態を確認できたときだけでなく、状態が変化した時点でキャプチャされます。

これは何ではないか：distill の実行時点で行う受動的なキャプチャであり、網羅的な再構築ではありません。保証の内容は明確です。distill のスイープで、完了状態の claim（またはメモ付きの claim）が確認されれば、その claim が後で状態変化しても、そのナレッジはキャプチャされます。 残るギャップは、2 回のスイープの間に完了状態が作られ、さらに消えてしまった場合（たとえば cambium が動作していなかった場合）には、一度も確認されず、agentsync の git ログにしか残らないことです。そのような claim を網羅的に再構築するためにログをたどる方法は、今後追加できる可能性があります（履歴は残っており、agentsync の history() で読み取れます）。この変更では、意図的に対象外としています。

import_memory(source, path) — 外部のメモリエクスポートを cambium に取り込み、出所情報タグ付きのローカルスコープのナレッジアイテムとして保存します（以下の Import を参照）。ソースに対しては読み取り専用で、インポートされたアイテムが自動的に昇格されることはありません。

recall(query, scope, limit) — ローカル、チーム、組織を横断して検索します。各ヒットはアイテムの想起カウンターを増やします（昇格で使われる信頼シグナル）。また、プロジェクトをまたいだ利用も記録します。関連度がしきい値を下回る場合は、確信があるように見えるノイズではなく、no_confident_match: true を返します。各結果には endorsed_as が含まれます。昇格されたアイテムでは、アイテムのプロジェクト横断的な意味が記されている推薦メモが、第一級のコンテキストとして提示されます。 endorse(item_id, note) — 項目を保証します。ローカル→チームへの昇格を迅速化します。 チーム→組織への昇格では必須です。

promote(item_id, to_scope, force, org_content) — 引数なしの場合、条件を満たすすべてのローカル項目をスキャンしてチームに昇格させます。to_scope="org" を指定すると、組織リポジトリにプッシュするか、CAMBIUM_ORG_PR=1 の場合は PR を開きます（PR がマージされるまで、注釈を付けたチーム側のコピーは残ります）。昇格時に last_verified が記録されます。昇格は検証そのものです。 一般化ゲート： 組織スコープはすべてのプロジェクトから読み取られるため、プロジェクト固有の内容に見える本文（ファイル名、test_* ID、dec-/con-NNN 参照、または項目の発生元プロジェクト自体を示すもの）は、組織境界で拒否されます。org_content= を使ってプロジェクト横断のルールとして書き直してください（具体的な本文は example として保持されます）。または force=True で上書きできます。拒否時には、推薦コメントがすぐに使える下書きとして返されます。これは推薦ゲートと同じ仕組みで、安全な方法が最も簡単な方法です。

generalize(item_id, org_content, note) — ゲートに対処するための関数です。すでに昇格済みの項目の本文を、具体的な内容を example として残しながら、プロジェクト横断のルールとしてその場で書き直します。ゲート導入前に組織スコープに到達した項目、またはゲートを強制的に通過した項目が対象です。対象の項目は review_promotions() の org_needs_generalization に表示されます。org_content を省略すると、項目の最新の推薦コメントにフォールバックします。組織の CAS 経路を通じて書き込みます（直接書き込むか、CAMBIUM_ORG_PR=1 の場合は共有の cambium/generalize PR ブランチを1つ使い、繰り返しの呼び出しを1つのレビュー可能な PR にまとめます）。冪等です。

verify_entry(item_id, note) — エントリが引き続き有効であることを確認し、last_verified を現在時刻に更新します（コメントは任意）。昇格済みのナレッジが気付かないうちに古くなるのを防ぐイベントです（機械が保守するドキュメントのエントロピーを参照）。

stale_report(project, older_than_days) — 昇格済み（チーム＋組織）のエントリを、検証日時が古い順に並べます。再検証されたことのない項目にはフラグを付け、各項目の valid_while の前提を明示します。古さを報告しますが、自動的に降格させることはありません。

review_promotions() — チームに昇格可能な項目、組織への昇格が推薦済みの項目、保留中の組織 PR、および org_needs_generalization を表示します。これは、本文がまだプロジェクト固有に見える組織項目（ゲート導入前に通過したもの、または強制的に通過したもの）の一覧です。各項目について、検出された特徴と、書き直し案としての推薦コメントが表示されます。

export_markdown(scope) — ナレッジを、人が読みやすい KNOWLEDGE.md としてスコープ、次にプロジェクトごとにまとめて出力します（各項目には、要約、種類、由来を示す dec-NNN／主張の発生元、参照回数、昇格日が含まれます。cp1252 の文字化けは正規化されます）。scope="org"（デフォルト）では、組織リポジトリの knowledge.json と同じ場所にある KNOWLEDGE.md を再生成してプッシュします。local／team／all の場合は、公開せずに Markdown を返します。組織への昇格後は自動的にも実行されるため、組織リポジトリのドキュメントは常に最新の状態になります。直接プッシュの場合は両方のファイルをまとめてコミットし、PR モードの場合は同じ PR ブランチに両方のファイルを追加します。

setup(project_repo, agent_id, org_repo?, org_pr?, team_branch?) — 新規状態から設定を完了します（設定を参照）。パスを検証し、.cambium/ を作成して、フォールバック設定を書き込みます。組織リポジトリの作成は行わず、代わりに gh コマンドを提示します。シークレットは書き込みません。

status() — まず設定状態を表示します。設定済みの項目、未設定の項目、各不足がもたらす影響、および解決に使う setup() を確認できます（未設定でもエラーは発生しません）。設定済みの場合は、スコープ／種類ごとの件数、インポートのウォーターマーク、接続済みの基盤も表示します。

複利的成長のループ

stobie's agent finishes work ──agentsync──▶ done claim + note + files
                                                 │
jonny's cambium: distill()  ◀────────────────────┘
        │ outcome memory (local)
jonny + teammates: recall() ×N  ──▶ trust grows ──▶ promote() → team
        │ visible to every collaborator's agent
someone: endorse()  ──▶ promote(to_scope="org")  ──▶ org repo / PR
        │
ANY agent, ANY project, ANY type (SRE bot, KB bot): recall(scope="org")

受動的な取り込み：Claude Code のフックを追加し、セッション終了時に distill を実行します。これにより、取り込みにかかる項目ごとの作業はゼロになります。完了イベント時にも（ポストコミットフックとして）実行し、CAMBIUM_RELEASE_CAPTURE=1 を設定すると、完了した agentsync 作業を完了した時点で取り込み、リリースや再取得によって消えてしまう前に記録できます。

インポート

import_memory(source, path) は、外部メモリシステムのナレッジを cambium に取り込みます。これはインポート／取り込み専用です。外部ストアを読み取り、cambium のアイテムを書き込みますが、ソースには書き戻しません（エクスポートは別の、よりリスクの高い機能であり、意図的に対象外としています）。インポートはソースアダプターとしてモデル化されており、distill の基盤リーダーと同じ形式です。アダプターがソースの場所からレコードを読み取り、正規化された cambium ナレッジアイテムを生成します。アイテムは、distill が使用するものと同じ正規化・書き込み／重複排除の経路を通ります。別の仕組みはありません。

インポートで保証されること：

• 常にローカルスコープです。 インポートされたアイテムは local スコープで追加されます。cambium 内で昇格の条件を満たしていないため、自動昇格されません。チーム／組織スコープへの昇格は、recall() の使用と endorse() を通じて、引き続き通常の方法で獲得します。
• 常に出所情報を記録します。 インポートされた各アイテムには source: {system, ref, imported: true, source_ts} が付与され、imported タグが付きます。そのため、インポートされたナレッジはネイティブに蒸留された記録と区別でき、出所（システム＋元の ID＋元のタイムスタンプ）まで監査できます。
• 冪等です。 同じレコードを再インポートしても何も追加されません。重複排除は、ソースレコードの安定した ID があればそれを使い、なければコンテンツハッシュを使って、共有のウォーターマーク経路を通じて行います。
• ソースに対して読み取り専用で、依存関係はありません（標準ライブラリとローカルファイルのみを使用し、ネットワークや外部認証は不要です）。

json アダプター（リファレンス）

同梱されている唯一のアダプターは、汎用 JSON／JSONL メモリエクスポートをローカルファイルから読み取ります。特定のサービスには依存しません。トップレベルの配列、memories／items／records／data／entries のいずれかの下にリストを含むオブジェクト、または JSONL（1 行につき 1 つの JSON オブジェクト）を受け付けます。各レコードは次のようにマッピングされます。

cambium のフィールド	ソースのキー（最初に見つかったものを使用）	存在しない場合
content（本文）	content, text, body, memory, note	レコードをスキップ（本文なし）
— 本文に統合	title, name, summary	省略
why	why, reason, rationale, context	空
kind	kind, type, category	"note"
tags	tags（リストまたはカンマ／スペース区切りの文字列）	imported, json のみ
source.ref	id, uuid, _id, key	代わりにコンテンツハッシュで重複排除
source.source_ts	timestamp, created_at, ts, time, date	省略

type は常に memory です。不正な行や、使用可能な本文がないレコードはスキップとしてカウントされ、インポートがクラッシュすることはありません。戻り値には imported／skipped／duplicates の件数がまとめられます。

# import_memory(source="json", path="/abs/path/to/export.jsonl")

アダプターは拡張ポイントです。 同梱されている形式は json のみです。これは特定のメモリ製品への対応を表明するものではありません。別のシステムを取り込むには、正規化済みアイテムを生成するアダプターを 1 つ IMPORT_ADAPTERS に追加します。コアロジックは変更不要です。ネットワークアクセスや認証情報が必要なアダプターは、意図的に含めていません。

機械が管理するドキュメントの陳腐化

信頼度に基づく昇格は、知識が取り込まれる際にその品質を守ります。ある項目がチームや組織に届くのは、再び想起されるか、推薦を受けてからです。しかし、その後に古くなったことを示す仕組みはありませんでした。ゲートを通過した時点では正しかった事実――「請求処理はNetSuiteで行う」「ステージングDBの接続数上限は90」――が、前提が崩れた後も信頼されたままになります。さらに悪いことに、エージェントはそれを想起し、それに基づいて行動し、引用するため、誤った前提は単に残るだけでなく、組織に定着し、使われるほど権威があるように見えてしまいます。昇格によって誤りのリスクは高まる一方で、誤りに気づく手段は増えません。

cambiumは、信頼度スコアや時間経過による減衰ではなく、検証イベントと前提の紐付けによってこの問題を解決します。どちらも誤った精密さを生み出すからです。0.62という信頼度は、誰も行っていない測定を暗示します。また、「90日ごとに信頼度が半減する」仕組みでは、単に安定していて正しい知識まで、気づかれないまま降格されてしまいます。その代わり、各項目には任意のlast_verifiedタイムスタンプ（昇格時に最初の検証として記録され、以後はverify_entryで記録します）と、それが依存する条件を示す任意のvalid_while前提が設定されます。古さの判定はイベント駆動型です。stale_reportは、昇格済みの項目を検証日時が古い順に並べ、再検証されていない項目にフラグを付けます。また、distillのリリース時処理では、作業が完了した時点で関連項目のうち検証日時が最も古いものを提示するため、再確認が既存のワークフローの流れに組み込まれます。last_verifiedがない、または古いという状態は、あくまで人間へのシグナルであり、自動的な降格にはつながりません。cambiumは注意すべき兆候を報告し、判断は人が行います。

確認する：tools/dashboard.py

python tools/dashboard.py --open

すべてのプロジェクトのcontext-keeperログとそこから抽出されたcambiumレイヤーを含む、メッシュ全体の自己完結型HTMLビューを1つ生成します。ビューは4種類です。

• 概要 — 記録済み → アクティブ → 抽出済み → 想起済み → 昇格済みという抽出の流れです。各段階は、1つ上の段階の部分集合です。
• プロジェクト — すべてのストアを並べ替え可能な表で表示します。クリックすると、プロジェクトの完全なログ、置換チェーン、制約のスコープ、健全性フラグを確認できます。
• ナレッジ — 抽出された内容、実際に想起される内容、ローカル → チーム → 組織という階層上での位置を確認できます。
• 健全性 — 文字化け、根拠の薄い項目、タグのない項目、古い項目、一度も想起されていない項目を、それぞれ母集団に占める割合として表示するため、ストアの規模が大きいだけで不健全に見えることはありません。

カウントはすでに可能でしたが、理解はできなかったため、このツールが作られました。最初の実行では、どのツール1つでも答えられなかった次の質問に答えられました。

スコープ	項目数	想起済み	想起回数
ローカル	229	15（7%）	117
チーム	136	134（99%）	774

知識を実際に読まれるようにするのは昇格です。 ローカルはステージング領域であり、想起率が低いのはシステムの不具合ではなく、正常に機能している証拠です。両方のスコープを1つのビューで確認して初めて、この結論が見えるようになります。このツールの最初のバージョンは.cambium/knowledge.jsonだけを読み込んでいたため（ローカルスコープのみ）、*"ローカルから移動したものはない"*と報告していました。チームの知識はGitブランチにあり、昇格済みの136項目は774回も想起されていました。

また、context-keeperが転送処理を修正する前に抽出された、cp1252の文字化けを含む84項目も明らかになりました。その多くは、最も頻繁に想起されるチームブランチに集中していました。tools/repair_mojibake.pyでローカルのストアを修復できます。チームブランチは共有Gitの状態であるため、意図的なプッシュに委ねられます。

設計上、ローカル限定です。 出力はGitで無視されます。メッシュには、非公開のリポジトリやリモートのないリポジトリも含まれるため、公開版で正直に示せるのは集計値に限られます。このビューにはすべてが表示されます。あなた自身のものだからです。読み取り専用であり、そのことはtest_dashboard.pyでバイト単位まで検証されます。

テスト

python3 test_cambium.py      # server integration suite
python3 test_dashboard.py    # the mesh dashboard

実際の git リポジトリを使った 62 件のケース：Markdown エクスポート（スコープ、次にプロジェクトごとにグループ化され、出典／再呼び出し／昇格日を含む KNOWLEDGE.md。cp1252 の文字化けを正規化し、直接プッシュモードと PR モードのどちらでも、組織への昇格時に knowledge.json と並べて自動書き込み）、書き込み時の正規化（distill に cp1252 で文字化けした em-dash を渡す基盤では、正規ストアに正しい状態で保存されるため、recall() はレンダリングされた .md だけでなく、修復済みのテキストを返します）、オンボーディング（未設定の status() は不足項目とコスト、修正方法を報告し、未設定時にはすべてのツールが役立つエラーメッセージを返し、setup() は初期状態から設定を行い、その設定がプロセス内で反映され、環境変数はファイルより優先され、組織名は作成されるのではなく gh コマンドとして提示され、Git 以外のパスや存在しないパスは拒否されます）、記録／再呼び出し（正直な回答保留を含む）、両方の基盤からの distill（agentsync のクレーム形式を厳密に再現し、context-keeper の .context/ スキーマを厳密に再現）と冪等性、昇格後の古さの判定（省略可能な last_verified／valid_while フィールド、省略フィールドの後方互換性、verify_entry のローカルおよびチームでの往復、昇格時の検証情報の記録、stale_report の古い順の並べ替え＋未検証フラグ＋経過期間およびプロジェクトのフィルター、リリース時の distill で検証プロンプトを表示）、リリース時の記録 （デフォルトでは無効。完了したクレームは再クレームによる変動があっても一度だけ正確に記録されます。記録済みのクレームが 完了 に達する前にリリースされた場合も、完全な distill では見落とされるところを保持します）、インポート（JSON および JSONL のエクスポート → 出典タグ付きのローカル項目、再インポート時の重複排除、ID がない場合のコンテンツハッシュによるフォールバック、不正または欠落フィールドはクラッシュせずにスキップ、インポートした項目はローカルに保持され昇格されず、ソースは変更されません）、昇格ライフサイクル全体（再呼び出しのしきい値、推薦による迅速な昇格、組織での推薦必須設定、gh をスタブ化した PR モード）、組織向け一般化ゲート（プロジェクト固有の本文は、判断材料と推奨される言い換えを示して組織境界で拒否されます。org_content= で一般化し、具体的な本文は example として保持します。force=True で上書きできます。普遍的に通用する本文は過剰にブロックされません。recall は endorsed_as を表示し、review_promotions は org_needs_generalization を自己報告し、generalize() はすでに昇格済みの本文をその場で言い換え、具体的な内容を example として保持し、フラグを解除し、冪等に動作します）、distill のレガシーフィールドへのフォールバック（rationale だけを含む v0.4 より前の context-keeper の決定でも、その WHY を distill します）、プロジェクト間の信頼追跡、同時に行われるピアのプッシュ下でのチーム書き込み CAS、実際の agentsync との統合テスト 2 件（隣接リポジトリが存在する場合、実際の agentsync の claim／finish／release ツールを実行します。release-capture の接合部も含みます）、そして実際の MCP stdio トランスポートテスト。CI ではプッシュのたびに実行します。

制限事項（正直に記載）

• 意味ではなく、語句の一致を基準にしています。 スコアラーはトークン／部分文字列の重複を基準にしています。決定論的で、依存関係もありません。後から埋め込みに置き換えることもできますが、ツールの契約は変わりません。
• 組織での使用状況は追跡されません（組織スコープでの再利用ではカウンターが増えません）。組織アイテムはすでに成長を終えています。
• PR モードでの昇格はトランザクションではありません。 チームのコピーは（PR の URL を注記した状態で）、人がマージするまで残ります。それが意図した動作です。レビューがゲートになります。 直接の帰結として、PR モードでは、組織への昇格は一度に 1 アイテムずつ行ってください。 すべての promote(item_id, to_scope="org") は origin/main からブランチを作成し、knowledge.json の同じ items 配列に追加します。そのため、同時に開いている 2 つの昇格 PR はこのファイルの同じ範囲を編集し、2 つ目は 1 つ目がマージされるまできれいにマージできません。（確認済み：2026-07-10 にナレッジ PR を続けて 2 つ開いたところ、2 つ目では knowledge.json の手動での競合解決が必要になりました。）PR を開いてマージしてから、次のアイテムを昇格してください。順番に処理すれば、競合を完全に回避できます。
• Distill は実行ごとにボードをちょうど 1 つ読み取ります。 distill() は、ボードのアドレス指定で解決されたリポジトリの <CAMBIUM_REMOTE>/<CAMBIUM_AGENTSYNC_BRANCH> から claims.json を git fetch します。AGENTSYNC_BOARD_REPO が設定されていればその値を使用し、設定されていなければ、そのブランチが実際に存在する場合に CAMBIUM_REPO を使用します。現在はプロジェクトのリポジトリに固定されていませんが、複数のボードを統合することもありません。別のボードで調整された作業や、別のバックエンドストアを使う agentsync-remote トランスポート経由の作業は、その実行では参照できません。ボードごとに一度 Distill を実行してください。
• Distill が取り込むのは、実行時点の情報であり、網羅的な情報ではありません。 デフォルトでは、agentsync で現在完了状態のクレームをインポートします。Distill がリアルタイムで取り込む前にクレームが解放されたり、再度クレームされたりすると、その情報は失われます。CAMBIUM_RELEASE_CAPTURE=1 を設定すると、完了／解放への状態遷移時にクレームを取り込むことで（最終確認済みスナップショットを介して）、この欠落の大部分を防げます。ただし、2 回のスイープの間に完了状態が作成され、完全に消えてしまった場合は、agentsync の Git ログからしか復元できません。この履歴をたどる機能は、ここでは実装されていません。

ライセンス

PolyForm Noncommercial License 1.0.0 — 非商用利用であれば自由に使用できます。

関連項目

xylem スタックの一部です。