エージェント駆動の Repo Mesh セットアップ

このページは、すでに ADHDev が動作している 1 台以上のマシンに Repo Mesh をセットアップするよう指示された AI コーディングエージェント（Claude Code、Codex、Hermes など）に向けて書かれています。番号付きの手順を順番にたどり、各ステップを書かれているとおりに正確に実行してください — シェルコマンドのものもあれば、MCP ツール呼び出しのものもあります（すぐ下のボックスを参照）。

人間の読者の方へ: このページをエージェントに渡して 「mesh セットアップガイドに従って Repo Mesh をセットアップして」 と伝えてください — エージェントが調査を行い、設定を提案し、何かを書き込むステップごとにあなたの承認を求めて停止します。あなたは承認するだけで、残りはエージェントが行います。

これは 自動化されたショートカット です。その背後にある概念については Repo Mesh を、手を動かす手動のウォークスルーについてはチュートリアル: 最初の実タスクを読んでください。

フローの形: マシンがすでにセットアップ済み → mesh を作成 → mesh_init が設定を提案 → あなたが承認 → コーディネーターを起動。

MCP ツールと CLI コマンドは交換可能ではありません

このページに出てくるすべての mesh_* という名前（mesh_plan_onboarding、mesh_create、mesh_add_node、mesh_init、mesh_status など）は MCP ツール です — シェルではなく、エージェントのツールインターフェース経由で呼び出してください。adhdev mesh init や adhdev mesh_status というコマンドは存在せず、シェルで mesh_* という名前を実行すると "unknown command" で失敗します。

これらのステップの一部には、MCP クライアントなしで同じことを行う CLI 相当のコマンド（adhdev mesh plan、adhdev mesh create、adhdev mesh add-node）もあり、本文中の ```bash ブロックで示されています。ラベルのない素のコードブロック（bash なし）で示されているものは、シェルコマンドではなく MCP ツール呼び出し です。CLI 相当のコマンドはステップ 2 で終わります — mesh_init（ステップ 3）とそれ以降のすべて（スロット、MAGI、コーディネーターツールセット）に CLI の形式はなく、MCP 専用です。

このガイドの前提

mesh ノードをホストするすべてのマシンに、動作する ADHDev のインストールが必要です。まだセットアップされていないマシンがある場合は、先にそのマシンでエージェント駆動の新規マシンセットアップを実行してからここに戻ってください。

単一マシン vs マルチマシン

	単一マシンの mesh	マルチマシンの mesh
動作環境	スタンドアロンおよびクラウド	クラウドのみ
ノード	1 台のマシン上の 1 リポジトリの git ワークツリー	複数マシンにまたがるワークスペース
アカウントの要否	不要（スタンドアロン）	必要 — すべてのデーモンで同じアカウント

単一マシンの mesh は、セルフホストのスタンドアロンビルドでも本物であり完全に機能します: ワークツリーノード、タスクキュー、Refinery、MAGI、MCP mesh モードはすべてローカルで動作します。スタンドアロンにできないのは マシン間のリレー だけです — 同じアカウントの複数のデーモンを調整するのはクラウドの機能です。

エージェント向けの目安: ユーザーが 1 台のマシンでワークツリー並列性を求めているなら、スタンドアロンで十分です。2 台以上のマシンを挙げているなら、各マシンでクラウドサインインが必要です（マルチマシンを参照）。

ステップ 0 — 前提条件を検証する

0a. このマシンでデーモンは起動していますか？

bash

adhdev status

期待される結果: デーモンが正常と報告される — スタンドアロンなら localhost:3847、クラウドモードならマシンが api.adhf.dev に対して online と表示される。

そうでない場合: 停止して、先にエージェント駆動の新規マシンセットアップを実行してください。死んだデーモンに対して続行しないでください — 以降のすべてのステップがそれを必要とします。

0b. ワークスペースはリモートを持つ Git リポジトリですか？

Repo Mesh は mesh をリポジトリのアイデンティティで識別し、それは Git リモートに由来します。追加したいワークスペースで以下を実行してください:

bash

git rev-parse --show-toplevel
git remote -v

期待される結果: リポジトリのルートパスと、少なくとも 1 つのリモート。リモートがない場合、ステップ 2 の探索は remote_not_found で失敗します — mesh 作成時に手動でアイデンティティを渡すこともできますが（--identity）、実際のリモートを使うのが通常の経路です。

0c. mesh ツールは揃っていますか？

これは最も飛ばされがちなステップであり、これなしでは以降の何も動きません。mesh_* ツールは mesh モードで動作している ADHDev MCP サーバー から提供されます。そこに至る方法は 2 つあり、順序があります:

まず標準モード — 素の MCP 登録により、3 つのブートストラップツール mesh_plan_onboarding、mesh_create、mesh_add_node が使えます。mesh を作成するにはこれで十分です。
次に mesh モード — mesh が存在するようになったら、--repo-mesh <mesh_id> を付けて再登録し、完全なコーディネーターツールセットを取得します。

mesh モードは mesh がまだ存在しない場合、起動を拒否します ので、いきなり mesh モードに飛ぶことはできません。

既存の .mcp.json を信用する前にゴースト mesh を確認する

このワークスペースにすでに --repo-mesh <mesh_id> を含む .mcp.json がある場合、その mesh が本物だと思い込まないでください — 以前のセッションの残骸で、その mesh は後に削除されている可能性があります。まず確認してください:

bash

adhdev mesh list

.mcp.json の mesh_id がそのリストにない場合、既存の登録は ゴースト設定 として扱ってください: mesh モードでの起動に失敗するか、静かに何も指さない状態になります。再利用しようとせず、下のステップ 2 で得られる mesh_id で削除または置き換えてください。

MCP クライアントの設定に標準モードを登録します。サーバー名は自由に選べますが、adhdev が慣例です:

json

{
  "mcpServers": {
    "adhdev": {
      "command": "adhdev",
      "args": ["mcp"]
    }
  }
}

Codex の場合、同等の登録は JSON の編集ではなく CLI 呼び出しです:

bash

codex mcp add adhdev -- adhdev mcp

MCP サーバーには稼働中のデーモンが必要です

adhdev mcp はツールを登録する前にデーモンに ping を打ち、到達できなければ終了コード 1 で終了します。local モードはポート 3847 のスタンドアロンデーモン（adhdev standalone）を、IPC モードはクラウドデーモン（adhdev daemon）を対象とします。MCP サーバーが起動時に落ちる場合は、ステップ 0a を再確認してください — ほとんど常にデーモンが動いていないことが原因です。

必要になった場合に役立つフラグ:

フラグ	意味
`--mode <local\|ipc>`	トランスポート。`local` = スタンドアロンデーモン、`ipc` = クラウドデーモン
`--port <n>`	デーモンのポート。デフォルト: local は `3847`、ipc は `19222`
`--password <pass>`	設定している場合のスタンドアロンデーモンのパスワード
`--repo-mesh <mesh_id>`	mesh モードに切り替える（ステップ 2c）

同等の環境変数: ADHDEV_PASSWORD、ADHDEV_MESH_ID、ADHDEV_MCP_TRANSPORT。

MCP 設定を編集したらクライアントを再起動する

MCP サーバーはクライアントの起動時に読み込まれます。登録を変更したら、新しい エージェントセッションを開始してください — すでに動作中のセッションは新しいツールを取り込みません。

ステップ 1 — マシンを棚卸しする

ユーザーがマルチマシンの mesh を望んでいる場合、到達できないノードを追加してしまわないよう、mesh を構築する前にすべてのマシンがオンラインであることを確認してください。

bash

adhdev status

これを各マシンで実行するか、クラウドダッシュボードのマシン一覧を確認してください。対象となるすべてのホストが 同じアカウント の下で online と表示されている必要があります。

マシンが足りない場合: エージェント駆動の新規マシンセットアップを通してください。そのマシンでのクラウドサインインは人間のステップです — エージェントには行えません。

ユーザーがマシンを 1 台しか持っていない場合: それで問題ありません、続けてください。ステップ 2b でリモートノードの代わりにワークツリーノードを構築することになります。

ステップ 2 — mesh を構築する

2a. まず計画する（読み取り専用で、何も書き込みません）

必ずドライランから始めてください。mesh_plan_onboarding は ファイルシステムの読み取りとローカルの Git クエリのみ を行います — fetch も、設定の書き込みも、ブランチやワークツリーの作成もありません。

MCP ツール呼び出し（シェルではなく、エージェントのツールインターフェース経由）:

mesh_plan_onboarding(workspace: "<absolute path to repo>")

同じ計画を表示する CLI 相当のコマンド:

bash

adhdev mesh plan
adhdev mesh plan --json    # complete machine-readable plan

期待される結果: kind が create_mesh_and_onboard、add_existing_workspace、clone_new_worktree のいずれかである計画と、discovery ブロック（リポジトリのアイデンティティ、ブランチ、clean/dirty）、および読み取り専用か承認が必要かの印が付いたステップの一覧。CLI は最後にこう表示します: "Nothing was written."

行動する前に計画を読んでください。 次に呼び出すべき 3 つのツールのどれかを教えてくれますし、ブロッカーを途中ではなく最初に浮かび上がらせてくれます。

よくある失敗コードとその意味:

コード	意味
`not_git_repository`	ディレクトリが違います — `workspace` をリポジトリのルートに向けてください
`remote_not_found`	Git リモートがありません。ステップ 0b を参照
`dirty_workspace`	未コミットの変更があります — コミットまたは stash してから再計画してください
`nested_worktree`	ワークツリーのワークツリーの中にいます。メインのチェックアウトを使ってください
`compatible_mesh_exists`	このリポジトリの mesh がすでに存在します — 作成せずノードを追加してください
`detached_head`	先にブランチをチェックアウトしてください

2b. mesh を作成してノードを追加する

計画が指示したとおりに従ってください。

新しい mesh を作成する（計画の kind が create_mesh_and_onboard）— MCP ツール呼び出し:

mesh_create(name: "<mesh name>", add_current: true)

add_current: true は、同じ呼び出しで現在のワークスペースを mesh の最初のノードとして登録します。レスポンスには、以下すべてで必要になる mesh_id が含まれます。

mesh_create(add_current: true) は providerPriority を設定しません

mesh_add_node とは異なり、mesh_create には provider_priority パラメーターがありません。それが登録する最初のノードは、あなたが設定するまで policy.providerPriority を持ちません — このステップの最後にある注意書きを参照してください。

CLI 相当のコマンド:

bash

adhdev mesh create my-project --add-current

既存のワークスペースをノードとして追加する（計画の kind が add_existing_workspace）— 2 台目のマシンや 2 つ目のチェックアウトにはこれを使います。MCP ツール呼び出し:

mesh_add_node(workspace: "<absolute path>", mesh_id: "<mesh_id>")

オプション: 書き込みタスクを決して割り当てるべきでないノードには read_only: true、そこで動作するエージェントを固定するには provider_priority: ["claude-cli", "codex-cli"] — なぜこれが重要かは下の providerPriority の注意書きを参照してください。

CLI 相当のコマンド:

bash

adhdev mesh add-node mesh_abc123 --worktree --provider-priority claude-cli,codex-cli

ワークツリーノードを作成する（計画の kind が clone_new_worktree）— 1 台のマシンで並列性を得る方法です。実際に git worktree add を実行します。MCP ツール呼び出し（CLI 相当なし）:

mesh_clone_node(source_node_id: "<node_id>", branch: "<new branch name>")

オプションの base_branch — デフォルトは現在の HEAD です。

先に進む前に providerPriority を確認する

mesh_launch_session は、policy.providerPriority が空のノードに対して明示的な type なしで呼ばれた場合、フェイルクローズします（missing_provider_priority）— そして mesh_create(add_current: true) も mesh_clone_node もそれを設定しません。今作成したすべてのノードを確認してください:

mesh_status()

あるノードの providerPriority が欠けている場合は、mesh_add_node で登録するときに provider_priority を渡すか、そのノードに対して常に明示的な type を付けて mesh_launch_session を呼び出すか、ダッシュボードの Repo Mesh ポリシーエディタ / コミットされた .adhdev/mesh.json を通じてポリシーを設定してください。mesh_init（ステップ 3）は検出された CLI プロバイダーから providerPriority のリストを推奨しますが、それは 助言にすぎず — あなたの代わりにノードポリシーへ書き込むことはありません。

構築したものを検証する:

bash

adhdev mesh show mesh_abc123
adhdev mesh status mesh_abc123

show はノードを一覧表示し、status は各ノードのヘルスを調べます。

2c. MCP サーバーを mesh モードで再登録する

mesh ができたので、クライアントを mesh モードに切り替えて完全なコーディネーターツールセットを解放します。MCP 設定を更新し、プレースホルダーを実際の mesh_id に置き換えてください:

⏸ エージェントのランタイムがこの編集をブロックすることがあります — 回避しないでください

.mcp.json の編集は、将来のセッションが得るツールを変えるため、一部のエージェントランタイムでは通常のファイル編集とは別の承認でゲートされます。あなたがエージェントで、この編集がブロックされた場合: ゲートを迂回しようとしないでください。 停止して、.mcp.json への正確な 1 行の差分（Hermes なら YAML ブロック）と実行するコマンドを人間に渡し、本人が適用できるようにしてください。再試行、エスカレーション、あるいは同じバイトを書く別の方法を探すことは、この安全チェックの意味を無にします。

json

{
  "mcpServers": {
    "adhdev-mesh": {
      "command": "adhdev",
      "args": ["mcp", "--mode", "ipc", "--repo-mesh", "mesh_abc123"]
    }
  }
}

Hermes の場合、同じものを mcp_servers の下に YAML で書きます — ファイルの場所は hermes config path で見つけてください:

yaml

mcp_servers:
  adhdev-mesh:
    command: adhdev
    args:
      - mcp
      - --mode
      - ipc
      - --repo-mesh
      - mesh_abc123
    enabled: true

Codex の場合:

bash

codex mcp add adhdev-mesh -- adhdev mcp --mode ipc --repo-mesh mesh_abc123

その後、エージェントセッションを再起動 してください。mesh モードではツール面が完全に置き換わります — 標準のセッションツールがなくなり、mesh コーディネーターツールが現れます。

スタンドアロンのユーザーへ

--mode ipc の代わりに --mode local を使ってください。IPC モードはクラウドデーモンと、local モードはポート 3847 のスタンドアロンデーモンと通信します。

ステップ 3 — `mesh_init` にリポジトリ設定を提案させる

これが init のステップです — リポジトリを読み取り、妥当なデフォルトを書き込んでくれるので、設定ファイルを手書きせずに済みます。

mesh_init は MCP ツールであり、CLI コマンドではありません — adhdev mesh init は存在しません。エージェントのツールインターフェース経由で呼び出してください。これは 2 段階のツール です: デフォルトではプレビューし、あなたが明示的に指示したときにのみ書き込みます。

3a. プレビュー（デフォルト — 何も書き込みません）

MCP ツール呼び出し（CLI 相当なし）:

mesh_init()

これだけです。write のデフォルトは false なので、この実行はドライランです: レスポンスは dryRun: true で返り、提案された各設定は written: false を持ちます。

3 つのリポジトリレベルの設定ファイルを提案します:

ファイル	何を設定するか
`.adhdev/refine.json`	Refinery の検証 — ブランチが収束する前に通過しなければならないコマンド
`.adhdev/worktree_bootstrap.json`	新しく作られたワークツリーで何を実行するか（依存関係のインストール）
`.adhdev/change-impact.json`	変更影響分析の設定

また providerPriority の推奨 も返しますが、これは助言にすぎません — mesh_init があなたの代わりに適用することは決してありません。

検証コマンドがどう選ばれるか。 mesh_init はあなたの package.json のスクリプトを読み、typecheck、test、lint、build の 4 つのカテゴリと照合します。名前がカテゴリと一致するスクリプト、または <category>: で始まるスクリプトが、npm run <script> として推奨コマンドになります。推奨は mesh レベルのプロジェクトコマンドとマージされ、重複が除去され、最大 4 件に制限 されます。

npm 以外のリポジトリには推奨が出ません

検出は、typecheck / test / lint / build という正確な名前の npm スクリプト、または typecheck: / test: などで始まるものにのみ一致します。cargo test、go test、poetry run pytest、素の tsc --noEmit、あるいは別の名前のスクリプト（check、vitest など）を使うリポジトリでは推奨がゼロになり、skippedReason: "no_suggestion" が返ります。これは失敗ではなく想定どおりです — そうしたリポジトリでは .adhdev/refine.json を手書きしてください。

3b. 人間とレビューする ⏸ 人間のステップ

⏸ 人間のステップ — 書き込む前に提案を見せること

提案された refine、worktreeBootstrap、changeImpact の各ブロックをユーザーに提示し、明示的な承認を得てください。これらのファイルは リポジトリ内に 着地し、将来の作業が収束するかどうかを決めるゲートになります — ここでテストコマンドを間違えると、後のすべてのマージが静かにブロックされます。

特に refine の検証コマンド について確認してください: これらは、このリポジトリで実際に通過しなければならないコマンドですか？それが、人間が必ず自分の目で確かめるべき唯一のフィールドです。

3c. 書き込む（承認後にのみ）

MCP ツール呼び出し:

mesh_init(write: true)

mesh_init は 既存の設定を決して上書きしません。ファイルがすでにある場合は skippedReason: "already_exists" で返り、そのまま残されます。意図的に置き換えるには:

mesh_init(write: true, overwrite: true)

overwrite のデフォルトが true になっているだけの同じ操作として mesh_reinit もあります — リフレッシュを意図する場合はこれを使い、呼び出しから意図が明確になるようにしてください。

検証: レスポンスがファイルごとに dryRun: false と written: true を報告します。ディスク上で確認してください:

bash

ls .adhdev/

これらのファイルをコミットしてください。 これらはリポジトリの設定です — すべてのノードとすべての将来のコーディネーターが同じルールを読む、というのが要点なのです。

ステップ 4 — モデル、制限、MAGI

このステップの内容にはすべて機能するデフォルトがあります。ユーザーが実際に気にしていることだけを変更し、答えによって結果が変わる場合にのみ質問してください。

4a. ノードスロット — どのエージェントとモデルがどこで動くか

スロットは、プロバイダー（および任意でモデルと思考レベル）を難易度クラスに束縛します。ノードの現状を確認してください:

mesh_node_slots_list(node_id: "<node_id>")

ノードに明示的なスロットがない場合、そのプロバイダー優先度と mesh ごとの難易度プリセットから妥当なものが導出されます。プリセットのデフォルトは次のとおりです:

難易度	モデル	思考レベル
`easy`	`haiku`	`low`
`medium`	`sonnet`	`medium`
`difficult`	`opus`	`high`

freeform は 4 番目の有効な難易度で、意図的にプリセットを持ちません。

ユーザーから要望がない限り、ここは触らないでください。 導出されるデフォルトは、ほとんどの mesh で正しいものです。スロットを明示的に設定するのは、ユーザーがコスト制御を望む場合（安価な作業を小さいモデルに固定する）や、1 台のマシンにしか存在しないプロバイダーがある場合です。

mesh_init と同様に、このツールもデフォルトはドライランです:

mesh_node_slots_set(node_id: "<node_id>", slots: [...])            # preview
mesh_node_slots_set(node_id: "<node_id>", slots: [...], write: true)  # apply

スロットは丸ごと置き換えられます

slots は既存のものにマージされません — ノードのスロットリスト全体を 置き換えます。必ず先に mesh_node_slots_list を実行し、現在のものから新しい配列を組み立ててください。さもないと静かに設定を落とすことになります。書き込む前にドライランを実行し、currentSlots と proposedSlots を比較してください。

スロットごとに: provider は必須です。model、thinkingLevel、difficulty（配列）、capability（配列）、maxParallel は任意です。空の difficulty は、そのスロットがすべての難易度を扱うことを意味します。

4b. ポリシー制限 — デフォルトのままにする

mesh ポリシーはチェックポイント、プッシュ承認、リトライ、並行度を管理します。デフォルトは意図的に、並行度については寛容に、安全性については保守的に設定されており、セットアップ中に触るべきではありません。 特に:

maxParallelTasks はデフォルトで事実上無制限です。ダッシュボードは意図的にこのコントロールを隠しています。
requireApprovalForPush のデフォルトは true です — プッシュ前に確認します。
requirePostTaskCheckpoint のデフォルトは true です — 各タスクの後に作業がチェックポイントされます。
delegatedWorkerAutoApprove のデフォルトは true です — ワーカーセッションが自身のツールプロンプトで停止しません。

ユーザーに尋ねるのはこれ 1 つだけ: プッシュ承認を有効のままにしたいかどうか。それ以外はすべてデフォルトのまま先に進んでください。ポリシーは mesh セットアップツールではなく、ダッシュボードの Repo Mesh ポリシーエディタ、またはコミットされた .adhdev/mesh.json で設定します。

4c. MAGI — 任意。複数のエージェントを使うなら有効にする価値があります

MAGI は同じ質問を複数のエージェントに同時に投げ、答えを比較します。これは クロス検証 の機能で、それを機能させる軸は エージェント/ベンダーの多様性 です — モデルが異なれば失敗の仕方も異なるので、2 つのベンダーが食い違うことこそが得たいシグナルです。

これは、どの CLI をインストールしているかの話であって、何台マシンを持っているかの話ではありません。 2 つ以上の異なるエージェント — たとえば claude-cli と codex-cli — が利用できるなら、MAGI パネルは 単一マシン でも完全に有効です。ほとんどの開発者はすでに複数の CLI をインストールしているので、スキップするより提案する価値があります。パネルをマシンにまたがらせれば独立性が上乗せされますが、それはボーナスであって前提条件ではありません。

ユーザーに使いたいかどうか尋ねてください。 複数のエージェントベンダーを使っているなら推奨し、CLI が 1 つしか入っていないならスキップして理由を伝えてください。

仕組みとして、MAGI は 少なくとも 2 つの独立した (ノード, プロバイダー) ターゲット を必要とし、単一エージェントへ静かに劣化することは決してありません。ターゲットはノードとプロバイダーの組で識別されるため、1 つのノード上の 2 つの異なるプロバイダーは 2 つの別々のターゲットとなり、要件を満たします。さらに MAGI は、パネルに含まれる異なるプロバイダーが 2 未満、または異なるノードが 2 未満の場合に助言的な注意を出します — これはパネルがどれだけ相関しているかのヒントであって、失敗ではありません。実際に重要な構成は 2 つの異なるベンダー です。1 つのプロバイダーを 2 つ複製したパネルは、マシンをまたいでいるかどうかにかかわらず弱いケースです。

ユーザーが望む場合は、パネルをタスク種別に束縛します。有効な種別は claim_audit、rca、design、freeform です:

mesh_magi_kind_panel_list()                                        # what's configured now
mesh_magi_kind_panel_set(task_kind: "rca", slots: [...])           # preview
mesh_magi_kind_panel_set(task_kind: "rca", slots: [...], write: true)

ノードスロットと同じ 2 つのルールが当てはまります: デフォルトはドライラン、そしてスロットリストはパネルを 丸ごと置き換えます。各スロットには provider が必要で、nodeId、model、capabilityTags、n（レプリカ数、デフォルト 1）は任意です。nodeId はこの mesh のノードを指していなければならず、そうでなければ呼び出しは拒否されます。

パネルは mesh ごとに保存され、マシンローカル です — リポジトリではなく ~/.adhdev/meshes.json に存在します。

ステップ 5 — コーディネーターを起動する

コーディネーターは、mesh ツールを保持し、ノードに作業を渡すセッションです。

コーディネーターは自分自身を起動できません

mesh_launch_coordinator というツールも、コーディネーターを起動する adhdev mesh サブコマンドも存在しません。あなたがこれを読んでいるエージェントなら、ツールを呼び出してこのステップを完了することはできません — 人間に渡すか、下のパス B を使ってください。

パス A — ダッシュボード（通常の方法）⏸ 人間のステップ

⏸ 人間のステップ — 人間がここをクリックします

ダッシュボードで Repo Mesh ページ（/mesh）を開きます。
mesh にまだホストがピン留めされていない場合は、ホストデーモンを設定します — これは起動とは別の、意図的なアクションです。
ドロップダウンから CLI プロバイダーを選びます。
Launch Host をクリックします。

デーモンはそのプロバイダー用の mesh MCP サーバーを自動的に登録し、コーディネーターセッションをダッシュボードのタブとして開きます。選んだプロバイダーが手動の MCP セットアップを必要とする場合、UI が貼り付け用の設定ブロックを表示します — それを適用し、新しい CLI セッションを開始してください。

失敗は、知っておく価値のある明示的なコードとして現れます: mesh_coordinator_node_not_found（ワークスペースが解決されない）、mesh_coordinator_provider_priority_unusable（そのノードで使えるエージェントがない）、mesh_coordinator_mcp_registration_failed（登録に失敗したため、セッションは 起動されなかった — 意図的なフェイルクローズ）。

パス B — MCP mesh モード（ダッシュボードなし）

すでにステップ 2c を済ませているなら、あなたは事実上コーディネーターです: あなたのセッションが mesh モードのツール面を保持しています。確認してください:

mesh_status()

期待される結果: ノードを一覧する集約スナップショット。ツールが存在しない場合、mesh モードの登録が効いていません — ステップ 2c を再確認し、セッションを再起動してください。

ステップ 6 — スモークテスト

mesh に実作業を渡す前に、ループが機能することを証明してください。小さく安全なタスクを 1 つキューに入れます:

mesh_enqueue_task(...)

アイドルなノードがキュー内の作業をクレームします — これが意図された経路です。mesh_send_task は代わりに特定のセッションを直接ターゲットにします。キューを意図的に迂回するときだけ使ってください。

動きを観察します:

mesh_view_queue()
mesh_status()

期待される結果: タスクが queued → claimed → completed と移動し、mesh_git_status がそれを実行したノード上の変更を示します。

完了は 証拠ベース です — エージェントの自己報告ではなく、git ステータス、チェックポイント、台帳イベントです。タスクが成功を報告した場合は、信じる前に副作用を確認してください。

もっと実質のある本格的な最初のタスクについては、チュートリアル: 最初の実タスクをたどってください。

人間が実際にやったこと

このページをエージェントに貼り付けた。
各マシンでサインインした — マシンごとに 1 回、ブラウザ承認（クラウドのみ）。
mesh_init の設定提案を承認した。
ダッシュボードで Launch Host をクリックした。 4′. 条件付き: エージェントのランタイムがステップ 2c の .mcp.json 編集をブロックした場合、エージェントから渡された 1 行の差分を適用した。
それ以外のすべて — Git の探索、mesh の作成、ワークツリーノード、設定の検出、スロットのデフォルト — はエージェントが行った。

トラブルシューティング

セッションに mesh_* ツールが存在しない — MCP サーバーが mesh モードになっていないか、セッションが設定変更より前のものです。ステップ 2c を再確認し、新しい セッションを開始してください。MCP 設定はクライアントの起動時に読み込まれます。
MCP サーバーがすぐに終了する — ツールを登録する前にデーモンに ping を打ち、到達できないときは 1 で終了します。adhdev status を実行してください。local モードには adhdev standalone が、ipc モードには adhdev daemon が必要です。
mesh モードが起動を拒否する — mesh モードには既存の mesh が必要です。adhdev mesh list で ID を確認し、なければ先に標準モードで作成してください。
.mcp.json にすでに --repo-mesh <id> があるのに mesh モードが起動しない / adhdev mesh list に表示されない — 削除された mesh のゴースト設定です（ステップ 0c の注意書きを参照）。adhdev mesh list で確認し、ステップ 2 で得た実在の ID に置き換えてください。
adhdev mesh init が unknown command と言う — mesh_init は MCP ツールであり、CLI のサブコマンドではありません。mesh モードで登録した後（ステップ 2c）、シェルではなくエージェントのツールインターフェース経由で呼び出してください。
エージェントのランタイムが .mcp.json の編集をブロックする — 一部のランタイムでは想定どおりです（ステップ 2c）。エージェントはブロックを迂回しようとせず、正確な差分をあなたに渡すべきです。
mesh_launch_session が missing_provider_priority / "no providerPriority policy" で失敗する — そのノードに policy.providerPriority がなく、明示的な type も渡されていません。type を設定して mesh_launch_session を呼ぶか、ノードに provider_priority を設定してください（mesh_add_node で追加し直すか、mesh ポリシーを編集）。mesh_init の providerPriority の提案は助言にすぎず、自動的に適用されることはありません。
計画から dirty_workspace が返る — コミットまたは stash してから再計画してください。オンボーディングは、未コミットの作業の上にノードを構築することを意図的に拒否します。
compatible_mesh_exists — このリポジトリの mesh がすでに存在します。mesh_create ではなく、それに対して mesh_add_node を使ってください。
mesh_init が何も書き込まなかった — ファイルがすでに存在するか（skippedReason: "already_exists" — 置き換えるつもりなら overwrite: true を渡してください）、何も検出されなかったかです（skippedReason: "no_suggestion" — npm 以外のリポジトリ。設定を手書きしてください）。
adhdev mesh status であるノードが probe-failed と表示される — そのマシンのデーモンがオフラインか、スタンドアロン上のマルチマシン mesh です。マシン間の調整にはクラウドが必要です。
MAGI が magi_kind_not_configured でエラーになる — 先に mesh_magi_kind_panel_set でそのタスク種別にパネルを束縛してください。自動のフォールバックパネルはありません。
MAGI が magi_insufficient_targets でエラーになる — 独立した (ノード, プロバイダー) ターゲットが 2 つ未満しか利用できません。通常の対処は 2 つ目のエージェント CLI をインストールまたは有効化することで、2 台目のマシンは必要ありません。MAGI はターゲット 1 つでは動作しません。

次に読むもの

Repo Mesh — 概念: ノード、ミッション、キュー、台帳、Refinery
チュートリアル: 最初の実タスク — 完全な手動ウォークスルー
MCP サーバー — 完全なツールリファレンスとすべての登録形式
マルチマシン — ノート PC + デスクトップ + 業務用マシンの連携（クラウドのみ）
エージェント駆動の新規マシンセットアップ — 新しいマシンを参加できる状態にする

エージェント駆動の Repo Mesh セットアップ ​

このガイドの前提 ​

単一マシン vs マルチマシン ​

ステップ 0 — 前提条件を検証する ​

0a. このマシンでデーモンは起動していますか？ ​

0b. ワークスペースはリモートを持つ Git リポジトリですか？ ​

0c. mesh ツールは揃っていますか？ ​

ステップ 1 — マシンを棚卸しする ​

ステップ 2 — mesh を構築する ​

2a. まず計画する（読み取り専用で、何も書き込みません） ​

2b. mesh を作成してノードを追加する ​

2c. MCP サーバーを mesh モードで再登録する ​

ステップ 3 — mesh_init にリポジトリ設定を提案させる ​

3a. プレビュー（デフォルト — 何も書き込みません） ​

3b. 人間とレビューする ⏸ 人間のステップ ​

3c. 書き込む（承認後にのみ） ​

ステップ 4 — モデル、制限、MAGI ​

4a. ノードスロット — どのエージェントとモデルがどこで動くか ​

4b. ポリシー制限 — デフォルトのままにする ​

4c. MAGI — 任意。複数のエージェントを使うなら有効にする価値があります ​

ステップ 5 — コーディネーターを起動する ​

パス A — ダッシュボード（通常の方法）⏸ 人間のステップ ​

パス B — MCP mesh モード（ダッシュボードなし） ​

ステップ 6 — スモークテスト ​

人間が実際にやったこと ​

トラブルシューティング ​

次に読むもの ​

エージェント駆動の Repo Mesh セットアップ

このガイドの前提

単一マシン vs マルチマシン

ステップ 0 — 前提条件を検証する

0a. このマシンでデーモンは起動していますか？

0b. ワークスペースはリモートを持つ Git リポジトリですか？

0c. mesh ツールは揃っていますか？

ステップ 1 — マシンを棚卸しする

ステップ 2 — mesh を構築する

2a. まず計画する（読み取り専用で、何も書き込みません）

2b. mesh を作成してノードを追加する

2c. MCP サーバーを mesh モードで再登録する

ステップ 3 — `mesh_init` にリポジトリ設定を提案させる

3a. プレビュー（デフォルト — 何も書き込みません）

3b. 人間とレビューする ⏸ 人間のステップ

3c. 書き込む（承認後にのみ）

ステップ 4 — モデル、制限、MAGI

4a. ノードスロット — どのエージェントとモデルがどこで動くか

4b. ポリシー制限 — デフォルトのままにする

4c. MAGI — 任意。複数のエージェントを使うなら有効にする価値があります

ステップ 5 — コーディネーターを起動する

パス A — ダッシュボード（通常の方法）⏸ 人間のステップ

パス B — MCP mesh モード（ダッシュボードなし）

ステップ 6 — スモークテスト

人間が実際にやったこと

トラブルシューティング

次に読むもの