Foremerge

Foremerge

Foremerge は、Git 上に構築されたコーディングエージェント向けのオープンソースの連携プロトコルです。エージェントは、意図、意味上の主張、依存関係、暫定的な ChangeSet、判断、検証、来歴を共有しながら、互いに独立したワークツリーで作業します。

エージェントにインストールを指示する	→	完了	→	衝突が反映される前に確認する
Claude Code、Codex、または Cursor に1行貼り付けます		Foremerge がインストールされ、自動で設定されます		別々のワークツリーでも、各エージェントは他のエージェントが変更しようとしている内容を確認できます

ステータス： Foremerge 0.6.0 は、1.0 前のローカル優先の MVP です。CLI、JSON API、MCP サーバー、SQLite ストア、決定論的な競合検出機能、検証を通過条件とするライフサイクルを実装済みです。公開スキーマは今後変更される可能性があります。公開済みのベンチマーク結果はまだなく、マシン間の連携はこのプロジェクトの対象外です。

仕組み

同じプロジェクトで、2つの AI エージェントが同時に作業しているとします。それぞれがコードの独自のコピーを使うため、ファイルをめぐって競合することはありません。どちらも作業を終え、どちらの成果も正しく見えます。しかし、互いの作業を取り消していたことに気づきます。

Git がそれを警告できないのは、Git が比較するのはテキストであり、意図ではないからです。2つのエージェントが同じファイルの同じ箇所を編集すると、Git はそこで止めてくれます。しかし、それぞれ単独では妥当な編集が、別々のファイルに反映される場合は検出できません。たとえば、あるエージェントがすべての呼び出し元を新しい StripePaymentService に移行する一方で、別のエージェントが古い PaymentService に PayPal サポートを追加したとします。重複する箇所がないため、Git は何も警告せずに両方をマージします。その結果、PayPal の作業は、もう誰も呼び出さないクラスに取り残されます。

Foremerge は、エージェントが作業を始める前に、これから行うことを宣言することで、この問題を解決します。

1. 各エージェントは、これから変更する箇所を宣言します。 コードではなく、「sendEmail 関数を変更します」のように対象を伝えます。
2. すべてのエージェントが、1つの共有リストを読み取ります。 これはプロジェクトの .git フォルダー内にある小さなデータベースです。Claude、Codex、Cursor のいずれを使っていても、マシン上のすべてのエージェントが同じ状況を確認できます。
3. 2つの計画が衝突すると、すぐに通知されます。 Foremerge は該当する2つのエージェントを示し、計画が衝突する理由を説明して、作業の分割方法を提案します。この時点では両方のワークツリーはまだクリーンなので、作業を破棄する必要はありません。

共有のホワイトボードのようなものだと考えてください。エージェントは作業を始める前に、これから取り組む内容を書き込み、ほかのエージェントがすでに書いた内容を読み取ります。

Foremerge が意図的に行わないことは2つあります。ファイルをロックしたり、エージェントをブロックしたりすることはありません。1つのエージェントがクラッシュしただけで全体が停止するのを防ぐため、警告はあくまで参考情報として提示され、最終的な判断はユーザーに委ねられます。また、競合の判断にモデルを使うこともありません。同じ入力からは、常に同じ結果が得られます。

Git ではまだ見えない競合

Agent A: Replace PaymentService with StripePaymentService
Agent B: Add PayPal support to PaymentService

これらのエージェントは、同じ行に触れずに異なるツリーで作業できます。 それでも計画は衝突します。一方が拡張ポイントを削除し、もう一方がそれに依存しているためです。

両方のエージェントが同じ symbol:PaymentService スコープを宣言しており、一方はそれを replace すると述べ、もう一方は extend すると述べています。Foremerge は、どちらもコードを書き込む前にこの2つの宣言を比較し、HIGH の警告を出して、PaymentProvider のような安定した抽象化を使って調整するよう提案します。この提案は説明可能な根拠であり、自動的なアーキテクチャ上の決定でも、強制的なロックでもありません。

操作は要約から読み取るのではなく宣言されるため、どちらのエージェントが計画をどのように表現したかは関係ありません。「支払いを Stripe に統合する」と「PaymentService を Stripe に置き換える」は、同じ判定になります。

Git は引き続き永続的なリポジトリです。Foremerge はその上に不足していた共有認識を提供します。

0.1.0 リリースバイナリの実行で記録された実際の競合フィールドをもとに表示しています。 examples/terminal-session.txtを参照してください。表示されているコマンドでは、示されている jq フィルターを使っています。出力は読みやすさのために一部省略しています。

クイックスタート：5分以内に最初の競合を確認する

コーディングエージェントに任せる

連携させたいリポジトリ内で、これを Claude Code、Codex、または Cursor に貼り付けます。

Set up Foremerge in this repository so we can coordinate parallel agents.

1. Install it:      curl -fsSL https://foremerge.com/install.sh | sh
2. Initialize:      foremerge init
3. Wire this client and any others in use: foremerge setup all
4. Register the check I should be validated against, for example:
                    foremerge checks set test -- cargo test --all-targets
5. Confirm:         foremerge doctor --client all

Then read the Foremerge skill that step 3 installed for this client and follow
it from now on: publish your intent with semantic scopes before editing, claim
the scope, and check for conflicts before you start.

ステップ4は、このリポジトリで実際に使用するテストコマンドに変更してください。ステップ3ではクライアントに MCP サーバーを有効にするよう求めるため、その前に確認のプロンプトが表示されます。Codex への登録はユーザーレベルですが、登録はすべてのリポジトリで共通です。連携させたいリポジトリ内で Codex を起動してください。

または自分で設定する

最近の Git と jq が必要です。チェックサム検証済みのビルド済みリリースバイナリをインストールします（macOS と Linux 対応。スクリプトは ~/.local/bin にインストールします）。

curl -fsSL https://foremerge.com/install.sh | sh

ヒント

2つのコマンド、1つのプログラム。 これにより foremerge と fmg がインストールされます。後者は同じバイナリの短縮名なので、fmg status と foremerge status は同じ動作をします。以下の例では foremerge と表記していますが、どちらを入力してもかまいません。

または、npm からインストールします（macOS、glibc 搭載の Linux、Windows x64 対応）。パッケージには同じリリースバイナリが含まれているため、インストール時にコンパイルやダウンロードは行われません。

npm install -g foremerge

または、Rust 1.85 以降を使ってソースからビルドします：cargo install --locked --git https://github.com/naw103/foremerge foremerge、またはチェックアウトから cargo install --locked --path . を実行します。Windows バイナリは リリースページにあります。更新するには、インストール時と同じ方法でアップグレードしてから、foremerge setup を再実行し、エージェントクライアントを再起動してください。Foremerge のアップグレードでは、各手順が重要な理由を説明しています。次に、連携させたいリポジトリ内で以下を実行します。

foremerge init
foremerge doctor

インストーラー、リリースアーカイブ、cargo install は、いずれも 0.4.0 以降、両方の名前を含みます。PATH 上ですでに別のものが fmg に応答する場合、インストーラーはそれを上書きせず、そのまま残してその旨を通知します。

このリポジトリで使うクライアントにネイティブスキルと MCP エントリをインストールし、エージェントが名前を指定して実行を要求できる信頼済みチェックを定義します。

foremerge setup all
foremerge checks set test -- cargo test --all-targets
foremerge doctor --client all

受け入れ判定は検証ゲート付きです。Foremerge はエージェントの言葉を鵜呑みにせず、自らチェックを実行します。受け渡しの失敗を実際に検出できるビルドや型チェックなど、短時間で実行できるチェックを選んでください。CI スイート全体ではなく、他のエージェントが作業を完了扱いにできるかどうかをこのゲートが判定します。これは CI の代わりにはなりません。このリポジトリで有意義な検証項目がない場合は、常に成功するチェックを登録するのではなく、そのことを一度だけ伝えてください。

foremerge checks policy advisory

この方法で受け付けた作業は、理由とともに UNVERIFIED として記録されるため、チェックが実行されていないのに実行されたかのような監査証跡が残ることはありません。foremerge doctor は、登録済みのチェックをこの環境で実際に実行できるかどうかを報告します。これはエージェントのワークツリーで重要です。依存関係のディレクトリは通常 Git で無視され、git worktree add では作成されないためです。

1 つのクライアントをセットアップするには、setup codex、setup claude、または setup cursor を使用します。セットアップでは、無関係な設定が保持されます（プロジェクトの MCP JSON のキー順も含みます）。Foremerge をアップグレードすると、Foremerge が管理する未編集のスキルファイルはその場で更新されますが、編集したスキルファイルや、内容が異なる Foremerge の MCP エントリは、--force を明示的に指定しない限り置き換えられません。setup all はすべてのクライアントのセットアップを試み、それぞれの結果を報告します。1 つでも失敗した場合は、ゼロ以外の終了コードで終了します。Codex の MCP 登録はユーザーレベルで、すべてのリポジトリで利用できます。Codex の起動元ディレクトリに基づいて解決されます。詳しくはエージェントクライアントのセットアップを参照してください。

init は、リポジトリの Git 共通ディレクトリにローカルの調整状態を作成します。追跡対象のファイルは変更しません。コードを書く前の検出を試すには、以下のワークツリーを使用しないセッションで十分です。実際のコーディングエージェントでは、分離されたワークツリーと実際のモデル識別子を登録してください。

STRIPE_AGENT=$(
  foremerge --json agent register \
    --name stripe-agent \
    --no-worktree |
  jq -er '.data.id'
)

STRIPE_RESULT=$(
  foremerge --json intent publish \
    --agent "$STRIPE_AGENT" \
    --task "modernize-payments" \
    --summary "Replace PaymentService with StripePaymentService" \
    --scope symbol:PaymentService=replace
)
STRIPE_INTENT=$(printf '%s\n' "$STRIPE_RESULT" | jq -er '.data.intent.id')

PAYPAL_AGENT=$(
  foremerge --json agent register \
    --name paypal-agent \
    --no-worktree |
  jq -er '.data.id'
)

PAYPAL_RESULT=$(
  foremerge --json intent publish \
    --agent "$PAYPAL_AGENT" \
    --task "add-paypal" \
    --summary "Add PayPal support to PaymentService" \
    --scope symbol:PaymentService=extend
)
PAYPAL_INTENT=$(printf '%s\n' "$PAYPAL_RESULT" | jq -er '.data.intent.id')

printf '%s\n' "$PAYPAL_RESULT" |
  jq '.data.conflicts[] | {kind, severity, scope, explanation, suggestion}'

printf '%s\n' "$PAYPAL_RESULT" |
  jq '.data.related_work[] | {agent, summary, asserted, overlap}'

最初のコマンドは、ローカルでの実行結果から現在の検出内容を出力します。2 番目のコマンドは related_work を出力します。これは、もう一方のエージェントの意図と、両方で宣言された操作を含む、重複するすべてのスコープです。Foremerge は重複している内容を示します。その意味を判断し、foremerge assess record で記録するのはあなたです。事前にファイルを変更する必要はありません。キャプチャされた、明確にラベル付けされたターミナルの記録を確認してください。

クレームは所有権のコンテキストを追加しますが、どちらのエージェントもブロックしません。

foremerge --json work claim \
  --agent "$STRIPE_AGENT" \
  --intent "$STRIPE_INTENT" \
  --scope symbol:PaymentService \
  --reason "Changing the provider boundary" >/dev/null

foremerge --json work claim \
  --agent "$PAYPAL_AGENT" \
  --intent "$PAYPAL_INTENT" \
  --scope symbol:PaymentService \
  --reason "Adding another provider" |
  jq '.data | {advisory_only, warnings}'

foremerge --json work query --scope symbol:PaymentService |
  jq '.data[] | {agent: .agent.name, intent: .intent.summary, open_conflicts}'

どちらのクレームも成功します。クレームは独占的な所有権ではなく、リース付きの助言であるため、2 番目の応答には重複の警告が含まれます。

リリース済みの 0.4.0 バイナリで録画しました。すべてのコマンドとその出力は実際のものです。

Git の上位レイヤーとしての役割

  coding agent A                                  coding agent B
        |                                               |
  isolated worktree A                            isolated worktree B
        |                                               |
        +--------- semantic events, not edits ----------+
                              |
                    CLI / MCP / JSON API
                              |
                     Foremerge service
                    /        |        \
       SQLite coordination   git CLI   validation argv
       in <git-common-dir>       |           |
                    \         Git repository /
                     durable commits and refs

すべてのフロントエンドは、同じサービスとストアを使用します。セマンティックグラフは次のとおりです。

Agent → Task → Intent → Claim → Symbol → Dependency
      → ChangeSet → Test → Result → Decision → Provenance

変更処理では、型付きの SQLite プロジェクションを更新し、グラフエッジを具体化して、ハッシュチェーンで連結されたセマンティックイベントを 1 つのトランザクション内で追記します。このログは改ざんの証拠として有用ですが、リモート ID 署名や分散合意ではありません。

Git ワークツリー：ファイルは分離、認識は共有

Foremerge は Git 共通ディレクトリを解決し、デフォルトのデータベースを次の場所に保存します。

<git-common-dir>/foremerge/state.sqlite3

リンクされたワークツリーは、チェックアウトしたファイルが別々でも、同じ共通ディレクトリを共有します。Git 標準の機能を薄くラップした Foremerge のコマンドを使って、ワークツリーを作成できます。

foremerge worktree create \
  --branch agent/paypal \
  --path ../payments-paypal \
  --base HEAD

foremerge --cwd ../payments-paypal --json agent register \
  --name paypal-agent \
  --model "$ACTUAL_MODEL_ID"

同じリポジトリ内の別のワークツリーでは、登録済みのエージェントとその意図がすぐに確認できます。--database PATH または FOREMERGE_DB で保存先を上書きできますが、状態を共有するには、すべてのローカルエージェントが同じデータベースを参照する必要があります。MVP では複数のマシン間で SQLite を複製しません。ネットワークマウントされたデータベースから、分散環境での安全性を推測しないでください。

Foremerge は、ChangeSet のフィンガープリントと承認済み参照用に Git の状態をスナップショットします。マージ、リベース、チェリーピック、プッシュ、ターゲットブランチの更新は自動で行いません。

セマンティックワークフロー

INTENT ─claim→ CLAIMED ─start→ IN_PROGRESS ─publish→ PROVISIONAL
       ─validate current fingerprint→ VALIDATED
       ─accept gates→ ACCEPTED ─record Git ref→ COMMITTED

サポートされているスコープの種類は次のとおりです。

symbol api schema config infra test migration env file component contract domain

役に立つ範囲で、最も狭いセマンティックスコープを公開してください。ファイルパスだけでは、API、設定、スキーマ、インフラストラクチャ、言語をまたぐ衝突を見落とします。

一般的なコマンド：

境界	コマンド
来歴を登録する	foremerge agent register --name NAME --model MODEL
意図を公開する	foremerge intent publish --agent ID --task TASK --summary TEXT --scope KIND:KEY=OPERATION
スコープを確保する	foremerge work claim --agent ID --intent ID --scope KIND:KEY
実装を開始する	foremerge work start INTENT_ID --agent AGENT_ID
誰が変更しているか確認する	foremerge work query --scope KIND:KEY
各エージェントの作業内容を確認する	foremerge status
計画を事前確認する	foremerge conflicts check --intent TEXT --scope KIND:KEY=OPERATION
結論を記録する	foremerge assess record --agent ID --intent ID --related-intent-id ID --verdict V --rationale TEXT --action A
調整メッセージを送信する	foremerge coordinate send --from ID --to ID --message TEXT
セマンティックイベントを監視する	foremerge work watch --after-seq 0

現在のすべてのフラグについては、foremerge <command> --help を実行してください。--json、--cwd、--database などのグローバルフラグは、サブコマンドの前後どちらにも指定できます。

ChangeSet と検証ゲート

ChangeSet には、エージェント／モデル、タスクと意図、影響を受けるファイル／シンボル／コントラクト、依存関係、実装の概要、報告されたテスト、判断、来歴、ワークツリー、フィンガープリント、ステータス、Git ref が記録されます。受け入れられた候補と、その後の取り込みコミットは、それぞれ accepted_commit と integration_commit として個別に保持されます。

誠実な統合の手順は次のとおりです。

1. 意図を公開し、セマンティックスコープを確保して、実装を進行中にします。
2. 分離されたエージェントブランチで作業し、コミットします。
3. クリーンな候補の ChangeSet を公開します。
4. Foremerge に、正確なフィンガープリントを対象とする検証の実行を依頼します。
5. 深刻な衝突を解決してから、引き続きクリーンで検証済みの ref を受け入れます。
6. 通常の Git またはプルリクエストを使って統合します。
7. 永続的な統合コミットを Foremerge に記録します。

foremerge work claim \
  --agent "$AGENT_ID" \
  --intent "$INTENT_ID" \
  --scope component:payments
foremerge work start "$INTENT_ID" --agent "$AGENT_ID"

# Implement the change and commit it on this isolated branch before publishing.
CHANGESET_ID=$(
  foremerge --json changeset publish \
    --agent "$AGENT_ID" \
    --intent "$INTENT_ID" \
    --summary "Introduce PaymentProvider and StripePaymentProvider" \
    --file src/payments.rs \
    --symbol PaymentProvider \
    --symbol StripePaymentProvider \
    --contract payment-provider \
    --provenance-json '{"source":"coding-agent"}' \
    --git-ref HEAD \
    --worktree "$PWD" |
  jq -er '.data.id'
)

foremerge changeset validate "$CHANGESET_ID" \
  --worktree "$PWD" \
  -- cargo test --all-targets

foremerge changeset accept "$CHANGESET_ID" --git-ref HEAD

# Integrate with ordinary Git, then record the commit that actually landed.
foremerge changeset commit "$CHANGESET_ID" --git-ref main

エージェントが報告した --reported-test COMMAND=STATUS の値は、来歴の記録にのみ使われます。受け入れ要件を満たすものではありません。Foremerge が実行する検証では、コマンドの引数ベクトル、終了ステータス、出力、所要時間、候補のフィンガープリントが記録されます。検証後に変更が検出されると、その試行は正式な根拠として扱われなくなりますが、changeset attempts で出力と変更パスの診断を引き続き確認できます。

一時的な未追跡の出力を生成する信頼済みチェックについては、オペレーターが、追跡対象のファイルを変更せずに、完全一致またはディレクトリプレフィックスのルールを設定できます。

foremerge validation-exclusions set \
  --path coverage.log \
  --path target/validation-reports/

正規化されたポリシーダイジェストは候補のフィンガープリントの一部です。追跡対象の変更は除外できず、MCP がポリシーを変更することもできません。また、受け入れ前に生成ファイルを削除する必要があります。ADR 0001 を参照してください。

受け入れには、クリーンなワークツリーであり、未解決の HIGH 衝突がないことも必要です。ただし、呼び出し元が、表示される --allow-high-conflicts オーバーライドと --override-reason "..." を意図的に併用する場合は除きます。明確な根拠を示して衝突を解決することを推奨します。受け入れによって refs/foremerge/accepted/<changeset-id> が作成されますが、コードはマージされません。

検証コマンドは、オペレーティングシステムの権限で信頼済みのローカルコードとして実行されます。Foremerge はコマンドをサンドボックス化しません。

エージェントクライアントと MCP：ライフサイクルツール一式

foremerge mcp を stdio 経由で実行します。MCP に HTTP デーモンは必要ありません。どちらも同じデータベースを利用するアダプターです。

ツール	目的
register_agent	エージェント、モデル、機能、ワークツリーの来歴を記録します
publish_intent	予定している作業を通知し、各スコープに対してどのような変更を加えるかを宣言して、評価対象となる競合と関連作業を受け取ります
record_assessment	関連するインテントのひとつについて、判断した内容と実施することを記録します
claim_work	セマンティックスコープに対するリース付きの助言的クレームを作成します
query_work	エージェント、インテント、クレーム、ChangeSet、競合を検索します
check_conflicts	コードを変更する前に、公開済みまたは暫定のインテントを確認します
publish_changeset	実装、テスト、判断、Git の来歴を記録します
coordinate_with_agent	競合または ChangeSet に紐づいた永続的なメッセージを送信します
start_work	クレーム済みの作業を実装段階に進めます
resolve_conflict	永続的な競合に対する監査済みの解決内容を記録します
run_verification	生の MCP argv を使わず、名前で指定した信頼できるリポジトリチェックを実行します
accept_changeset	最終的な競合、依存関係、検証、Git のゲートを適用します
record_commit	実際の Git 統合コミットを記録します
discard_work	放棄された作業、または受け入れられずに取り込まれた作業を終了し、クレームとブロッカーを解放します
list_agents	登録済みエージェントの来歴を読み取ります
get_intent	ひとつのインテントと現在の競合スナップショットを読み取ります
get_changeset	ひとつの ChangeSet と Git／来歴の状態を読み取ります
status	一貫性のあるコーディネーターの状態スナップショットをひとつ読み取ります

有効な最小構成である examples/mcp-config.json から始めてください。この設定では、クライアントがリポジトリを作業ディレクトリとして foremerge を起動することを前提としています。リポジトリの作業ディレクトリを設定できないクライアントでは、mcp の前に絶対パスで --database を指定してください。リンクされたワークツリーの .git がディレクトリであると決めつけず、代わりに Git の共通ディレクトリを取得してください。

インストーラー、ネイティブスキルの場所、クライアント固有の MCP ファイル、診断、安全な置き換えルールについては、エージェントクライアントのセットアップを参照してください。トランスポートの動作、スキーマ、名前付きチェック、入力例、複数ワークツリーの設定については、MCP のセットアップを参照してください。

ソースクローンには、.codex/skills、.claude/skills、.cursor/skills、ポータブルな .agents/skills の場所、および Claude Code プラグインに同等のスキルが含まれています。さらに、ポータブルな Claude と Cursor の MCP テンプレートも含まれています。Cargo でインストールすると正規のスキルが埋め込まれるため、foremerge setup を使って、このソースツリーをコピーせずに別のリポジトリへインストールできます。

ローカル JSON API

デーモンは、認証付きのループバック HTTP を http://127.0.0.1:47811 でデフォルト起動します。init は、プラットフォームが対応している場合、ファイルのアクセス権を非公開に設定してベアラートークンを作成します。

1 つ目のターミナルで：

foremerge daemon

もう 1 つのターミナルでは、推測するのではなく Foremerge からトークンのパスを取得してください：

export FOREMERGE_URL=http://127.0.0.1:47811
TOKEN_FILE=$(foremerge --json init | jq -er '.data.token_file')
FOREMERGE_TOKEN=$(tr -d '\r\n' < "$TOKEN_FILE")

curl --fail --silent --show-error \
  --header "Authorization: Bearer $FOREMERGE_TOKEN" \
  --get "$FOREMERGE_URL/v1/work" \
  --data-urlencode 'scope=symbol:PaymentService' |
  jq .

トークンを表示、コミット、共有しないでください。/healthz はデータベースを使わないプロセスの稼働確認用で、/readyz は待機せずに実行する範囲限定のストアプローブです。どちらも公開されています。デーモンを信頼できるローカルテスト用に --no-auth を指定して意図的に起動した場合を除き、ページ分割されたイベントチェーン監査を含むすべての /v1 ルートでトークンが必要です。MVP はループバック以外へのバインドを拒否し、セキュリティ強化されたマルチテナントサービスではありません。

CLI の代替手段である foremerge request は、ローカルの認証情報を自動的に読み込みます。実行可能な curl の手順は examples/api-requests.sh にあります。すべてのルートとエラーのリファレンスはJSON APIを参照してください。

MVP で意図的に保証していないこと

• 競合検出は決定論的で説明可能ですが、ヒューリスティックです。同義の概念を見逃したり、互換性のある作業に警告を出したりする可能性があります。
• クレームは警告を出すだけで、ファイル、シンボル、エージェントをロックすることはありません。
• 検証に合格したことが示すのは、記録されたフィンガープリントに対して記録されたコマンドが合格したということだけであり、テスト計画が完全だったことを示すものではありません。
• Git の参照とプロセスの結果は、モデル、プロンプト、テストについての自己申告の文章よりも強い証拠です。
• イベントチェーンは保持されているチェーン内の変更を検出しますが、署名、リモートアテステーション、外部チェックポイントではありません。
• ローカルの SQLite は共有モードのコンセンサスを実現するものではなく、ループバックのベアラートークンも公開デプロイ向けのセキュリティモデルではありません。
• 実行可能なベンチマーク用フィクスチャ、再現可能なクエリハーネス、ベンチマーク計画はありますが、協調実行と非協調実行のパフォーマンス結果はまだ公開されていません。
• Foremerge は、コードレビュー、アーキテクチャの管理責任、CI、セキュリティスキャン、Git ホスティングのルール、バックアップに取って代わるものではありません。

Foremerge を統合ゲートとして使用する前に、制限事項と信頼モデルをすべてお読みください。

ドキュメント

ドキュメント	解説内容
アーキテクチャ	なぜ Rust の単一バイナリ、SQLite、Git CLI、共有の common-dir 状態を採用するのですか？
プロトコル	エージェントは何を、いつ公開しますか？
状態モデル	どの遷移と不変条件が作業を制御しますか？
競合検出	どの決定論的ルールが検出結果と提案を生成しますか？
Git 統合	フィンガープリント、ワークツリー、承認済みの参照はどのように動作しますか？
エージェントクライアント	Codex、Claude Code、Cursor はどのようにスキルと MCP サーバーを検出しますか？
MCP のセットアップ	クライアントは、ライフサイクルと読み取り用の 18 個のツールをどのように設定して呼び出しますか？
JSON API	提供されているルート、リクエストボディ、認証、エラーは何ですか？
OpenAPI スキーマ	機械可読な HTTP 契約はどのようなものですか？
ベンチマーク計画	協調実行と非協調実行をどのように比較しますか？
検証除外 ADR	検証で無視できる生成パスと、その理由は何ですか？
ロードマップ	現在、次期、将来の予定、および対象外のものは何ですか？
制限事項	MVP が保証しないことは何ですか？
ブランド	Foremerge のあらゆる場面で適用されるマーク、色、書体、アイコン、CLI 出力のルールは何ですか？

変更履歴、セキュリティポリシー、行動規範もご覧ください。

リンク

• ウェブサイト：foremerge.com
• クレート：crates.io/crates/foremerge
• MCP Registry 名：mcp-name: io.github.naw103/foremerge

貢献とライセンス

貢献を歓迎します。特に、スコープ用語、競合の証拠、ChangeSet の来歴、検証ポリシーに関するプロトコルへのフィードバックをお待ちしています。CONTRIBUTING.mdを読み、次にローカルの完全なゲートを実行してください。

make verify

Foremerge はApache License 2.0の下でライセンスされています。