Repo Mesh
スタンドアロン + クラウド
Repo Mesh はセルフホストのスタンドアロンビルドとクラウドの両方で動作します。ワークツリーノード、タスクキュー、Refinery、MCP mesh モードはすべてアカウントやクラウドサインイン不要でローカルに動作します。マシン間では、互いに直接到達できるスタンドアロンのデーモン（同じネットワークまたは Tailscale）をアカウントなしでコードによりペアリングできます。別々のネットワークにある同じアカウントのデーモンを調整するのはクラウドの機能です。マルチマシン を参照してください。
ダッシュボードは一度に 1 つのエージェントを表示します。Repo Mesh は、接続されたデーモンを 1 つのコントロールプレーンのもとに置きます。1 つの コーディネーター セッションが、多数のマシン — または同じマシンの多数の分離された git ワークツリー — で実行中のエージェントに作業を渡し、結果を収束させます。作業を分割し、アイドルなノードにそれをクレームさせ、マージを着地させましょう。
クラウドダッシュボードは、Repo Mesh ページ（/mesh）で mesh を表示します。スタンドアロンにはダッシュボードの mesh ページはありません — adhdev mesh CLI コマンドと MCP サーバーの mesh モードで操作してください。
仕組み
Repo Mesh は 直接のデーモン間 P2P DataChannel（node-datachannel 経由）で実行されます。クラウドサーバーの WebSocket は SDP offer/answer/ICE のシグナリングのみを中継し、両方のデーモンが同じアカウントに属していることを認可します。
これはデーモンの調整です — ダッシュボードコマンドのフォールバックでは ありません。ダッシュボードのコマンドとデータのトラフィックは、依然としてダッシュボード↔デーモンの P2P チャネルのみを使用します。Repo Mesh はそれをサーバー経由で再ルーティングすることはありません。
コーディネーターデーモンが集約 mesh_status スナップショットを所有します。ワーカーセッションはコーディネーターによってディスパッチされ、デフォルトで自動承認されます。完了は 証拠ベース です — git ステータス/チェックポイントと台帳イベントであり、エージェントの自己報告ではありません。Repo Mesh ツールは、mesh モードの MCP サーバーを通じてコーディネーターセッションに公開されます — MCP サーバー を参照してください。
中核となる概念
- Node — mesh に参加するワークスペース: エージェントが実行できるリポジトリのチェックアウト、または分離された git ワークツリー。
- Mission — それに向かって作業するタスクをグループ化し、永続的な記録として残る目標。複数タスクからなる作業をキューに入れる前にミッションを作成し、結果が決まったら
completedまたはabandonedとしてマークします。 - Task — ノード上のエージェントが実行する作業の単位で、
pending → assigned → completed/failedの順に移動します。mesh_enqueue_taskでdepends_onを使って次のタスクを鎖のようにつなげていくのがデフォルトの方法です — グラフは一度に全部宣言されるのではなく、一度に 1 つずつリンクが伸びていきます。 - Queue — アイドルなノードが自律的にクレームする待機タスクのデーモンローカルなリスト。キューはローカルファーストで権威があります。Cloud/D1 は軽量なメンバーシップとシグナリングメタデータのみを保持します。
- Ledger — ノード全体ですでに起きたことの追記専用の mesh 監査ログ（履歴であり、To-Do リストではありません）。境界付きの P2P 台帳スライスを通じてデーモン間で照合されます。
- Refinery — ワークツリーブランチをそのベースに再収束させるプロセス: 検証 → マージ → プッシュ → クリーンアップ。
オーケストレーション: プルベースのタスクキュー
特定のマシンにタスクをプッシュして待つのではありません。ミッションに対してタスクをキューに入れると、アイドルなノードがローカルファーストのキューから自律的に作業をプルします。つまり:
- マシンとプロバイダーにわたって一度に作業をファンアウトできます — あるノードで Claude Code、別のノードで Codex、3 番目のノードで Cursor CLI。
- 遅い、または忙しいノードは、単にこれ以上作業をクレームしません。速いアイドルなノードがキューを消化します。
- コーディネーターは、各セッションをポーリングするのではなく、完了/失敗イベントを監視します。
これが、1 人の人間が同時に多数のエージェントを調整できる理由です: 目標をタスクに分解し、アイドルなノードに自己割り当てさせ、収束をレビューします。
タスクの連鎖
ほとんどの多段階の作業は事前にすべて計画されるのではなく、進めながら段階的に判明していきます — そのため計画を組み立てるデフォルトの方法は、まずタスクを 1 つキューに入れ、必要だとわかった時点で depends_on でそれを指す次のタスクをキューに入れることです。依存関係グラフはこのようにして、一度に全部宣言されるのではなく、一度に 1 つずつリンクを伸ばして育っていきます。あるタスクが別のタスクに依存している場合、そのタスクは完了時に前段のタスクが報告した内容の短い要約を自動的に受け取るため、結果は手作業でコピーしなくても前方へ流れていきます。
すでに複数のタスクが確定している場合は、mesh_enqueue_batch で 1 回の原子的な呼び出しにまとめてキューに追加できます — 同じ depends_on の関係を一度に送信するだけで、別のエンジンではありません。
他のタスクが依存しているタスクが失敗またはキャンセルされると、依存側のタスクはブロックされたまま残り（ダッシュボードでは依存関係によるブロックとして表示）、コーディネーターに通知されます。メッシュのポリシー（onDependencyFailure: cancel）で、下流のチェーン全体をキャンセルさせることもできます。
リポジトリ中心のコラボレーション
Repo Mesh は、同じリポジトリを複数の場所から同時に作業する ことを中心に構築されています:
- ワークツリー分離 — 各ノードは分離された git ワークツリーになれるため、同じリポジトリの並列エージェントが互いの作業ツリーを踏み荒らすことがありません。
- 自動収束 — Refinery は完了したワークツリーブランチを受け取り、ベースに収束させます: 検証し、マージし、プッシュし、クリーンアップします。
- ブランチ収束の分類 — 触れられたすべてのノード/ブランチは、正確に 1 つの最終状態に着地します（main にマージ済み、マージが必要なプッシュ済みフィーチャーブランチ、レビューでブロック、クリーンアップ候補、またはマージ不可能）。これにより、何も静かにはぐれたブランチに残されることがありません。
- 安全なサブモジュール処理 — 収束はサブモジュールの到達可能性を考慮します。サブモジュールコミットがサブモジュールの origin からまだ到達できないブランチは、盲目的にマージされる代わりにレビューのために保留されます。
アイドルワーカーのクリーンアップ
アイドル状態になった（アクティブな作業がなく、コーディネーターでもない）委任されたワーカーセッションは、デフォルトで 30 分後に自動的に停止されます — mesh ハウスキーピングパスは 5 分ごとにチェックします。これにより、アイドルの CLI ランタイムが複数のノードにまたがって積み上がるのを防ぎます。TTL はメッシュごとのポリシー設定（delegatedSessionIdleTtlMinutes）なので、必要に応じて短く、長く、または無効にできます。
クロス検証
別個のタスクを分割することに加えて、コーディネーターは 同じ読み取り専用の質問 を異なるプロバイダーの 2〜3 個のワーカーに mesh_send_task で送り、報告を待ってから自分で答えを統合できます — 合意と相違を一緒に。
独立したマシン上の独立したエージェントを通じて同じ質問を実行することは、単一のエージェントの見解よりも信頼できます: 合意が答えを浮かび上がらせ、不一致がより詳しく見るべき部分を浮かび上がらせます。