並列 AI エージェントの PR をマージ前に調整する。

なぜ捕まえにくいのか

git のマージコンフリクトは同じ行が動いた時しか発火しない。2 つの PR は、個別の diff が綺麗に見えても干渉することがある。CI はいずれ捕まえるかもしれないが、それは 2 つ目の PR が既に main に入った後になりがちです。その頃には、さらに別の作業が新しい main の上に積まれているかもしれません。

並列 PR が増えるほど、追うべき関係も増えます。問いは絞れます: main に到達する前に、どの open PR が着地順の確認に値するか。

役に立つツールの形

カテゴリは multi-agent coordination — 開いている PR が干渉しそうな時に、マージ前に GitHub の中で知らせるチェックです。実用には、自動で走り、エージェントとレビュアーが既にいる場所に出て、advisory に留まることが重要です。 ランド順は人間（または merge queue）が決める。

隣接カテゴリのツール — merge queue、AI code reviewer、CI ゲート — はそれぞれ役に立つが、この具体的な問い「どの 2 つの PR が干渉しそうか」には答えない。Merge queue はマージを直列化するが重なりは知らない。AI reviewer は 1 PR ずつ読むので、ペアは見ない。CI は per-PR でリベース後のツリーに対して走るので、PR 同士の干渉は 2 つ目の PR が入った後にしか出ないことがある。

Veripsa Core はどうやるか

Veripsa Core は GitHub App。PR 上に助言型チェックを出すために必要な最小限の運用メタデータだけを使います。 ファイル本文は Veripsa に保存しません。

対象 PR で、Core は同じリポの開いている PR の文脈を見ます。 怪しい重なりが見つかった時、PR に advisory チェック — Clear / Heads up / Wait in line — が出る。必要な場合は推奨ランド順も付く。チェックは advisory がデフォルト。マージをゲートするかは、後でブランチ保護で決める判断です。

• Content-free. 助言型チェックに必要な最小限の運用メタデータだけを使います。ファイル本文は保存しません。
• Advisory by default. チェックが verdict を投稿するだけ。Core 自身がマージを止めることはない。required-check にするかはブランチ保護の判断。
• Same-owner per-repo today. クロスリポ調整は roadmap です。現在は、1 つのリポジトリ内の open PR を調整します。
• 無料カバレッジ帯。 リポジトリごとに十分な無料カバレッジ帯。超えたらアップグレード。