並列 AI PR はマージ前に重なることがある。

なぜ既存ツールが捕まえないか

git のマージコンフリクトは「同じ行が両 PR で動いた時」しか発火しない。開いている PR 同士の重なりはもっと静かで、個別の diff は綺麗に見えることがある。CI は捕まえるが、多くの場合それは 2 つ目の PR が main に入った後だ。AI code reviewer は 1 PR ずつ読む。Merge queue はマージを直列化するが、どの開いている PR が干渉しそうかを説明するものではない。

並列 AI 作業では、レビュアーが追うべき open PR 同士の関係が増えます。重要なのは、誰が作業したかの物語ではなく、どの open PR が着地順の確認に値するかです。

役に立つツールの形

カテゴリは pre-merge collision control — 開いている PR の文脈をマージ前に見て、怪しい重なりを GitHub check として出すものです。AI エージェントワークフローで実用に足るには、自動で走り、GitHub の中、エージェントと人間が既にいる場所に出て、助言型に留まることが重要です。 ランド順は人間（または merge queue）が決める。

隣接カテゴリは関連はするが、この問いに直接答えない。Merge queue はマージを直列化するが重なりを知らない。AI reviewer は 1 PR ずつ読む。CI は per-PR でリベース後のツリーに対して走るので、PR 同士の干渉は 2 つ目の PR が入った後にしか出ないことがある。穴を埋める形は、開いている PR をマージ前に見る助言型チェックです。

Veripsa Core はどうやるか

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

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

• 開いている PR をまとめて見る。 その PR 単体ではなく、同時に開いている PR の文脈も見る。
• Content-free. 助言型チェックに必要な最小限の運用メタデータだけを使います。ファイル本文は保存しません。
• Advisory by default. verdict を投稿するだけ。Core 自身がマージを止めることはない。required-check にするかはブランチ保護の判断。
• Same-owner per-repo today. クロスリポ調整は roadmap。今は実装されていません。