Show HN: Foremerge – 並列コーディングエージェント間の意図の競合を検出

GPTreeでは、チーム全体で複数のコーディングエージェントを1つのリポジトリで並列ワークツリー上で実行しています。PR作成時のレビューや修正にかかる時間の無駄に加え、最も痛手となるのは、複数のプランやチケットが、両立不可能なアーキテクチャ変更を引き起こす場合です。例えば、一方のエージェントがクラスを置き換えている最中に、別の一方がそれを拡張しようとするようなケースです。Gitは結果として生成されるパッチが偶然同じ行に触れた場合にのみ競合を検出し、レビュー担当者が両方のチケットに精通している場合にのみ検出されます。 Foremergeは、Gitの上に位置するローカルな「Gitライク」な調整レイヤーです（つまり、Gitやワークツリーの機能に干渉したり、その使い方を変更したりしません）。各エージェントは編集前に、意図とその変更するスコープ、そして各スコープに対して実行する操作を公開します。 ``` foremerge intent publish --agent "$A" \ --summary "Replace PaymentService with StripePaymentService" \ --scope symbol:PaymentService=replace foremerge intent publish --agent "$B" \ --summary "Add PayPal support to PaymentService" \ --scope symbol:PaymentService=extend ``` 2番目のエージェントによる公開は、コードを一切書き込む前に、高い破壊的対加算的な検出結果を返します。エージェントはそれぞれ自身のワークツリーを保持し、共有状態はGitの共通ディレクトリにある単一のSQLiteファイルです。フックやマージドライバー、履歴を書き換えるものは何もありません。 これはCLIとMCPサーバーを備えた単一のRustバイナリとして出荷され、18のツールと`foremerge setup all`によってClaude Code, Codex, Cursorに組み込まれます。プロトコルはプロバイダー固有のものではないため、ClaudeエージェントとCodexエージェントは同じストアを通じて調整できます。作業が受け入れられる前に、Foremergeは設定された名前付きチェックを、変更の正確なGit状態に対して実行します。テストがパスしたと主張するエージェントは記録されますが、それ自体がチェックを実行しない限り、受け入れゲートを満たすことはありません。 検出は決定的であり、コードを読むジャッジモデルはありません。高い競合は宣言された操作に対してのみアサートされ、推論から導き出される一致は高レベル未満でキャップされます。クレームはアドバイザリーなリースでありロックではないため、2つのエージェントがデッドロックなしに同じスコープを保持することも可能です。オープンソース版は単一のマッチングであり、分散コンセンサスではありません。 私たちは、同じリポジトリで最大98のエージェントが並行作業する状況で、競合ゼロを達成しました（本来は100の予定でしたが、リソース制限により2つのエージェントが実行に失敗しました）。 先週のビルドから76のインテントを自身のローカルエージェントで発生順にリプレイしました。サンプルには正確に1つの競合（フラグが立てられた）があり、レビューでは一方のエージェントがクラス名でスコープを宣言し、もう一方が内部メソッドでスコープを宣言していたという盲点が見つかりました。次のリリースでこれを修正する予定です。 セットアップは、README.mdのクイックスタートの説明をエージェントに貼り付けるか、手動で行うことで30秒で完了します。 `curl -fsSL https://foremerge.com/install.sh | sh` または `cargo install --locked foremerge` の後、リポジトリ内で `foremerge init && foremerge setup all` を実行します。 Apache-2.0ライセンスです。 最も欲しいフィードバックは、エージェントの計画間のどの競合を実際にフラグ立てしてほしいか、そしてどの競合をノイズとして許容したいかということです。 リポジトリはこちら: https://github.com/naw103/foremerge ウェブサイト: https://foremerge.com この問題が解決されることについての追加情報: https://foremerge.com/blog/