AI エージェント（Claude Code、Cursor、Cline、Continue、…）が アップストリームのバグに対する候補の修正を提案してきた。素直な問いは 「本当にバグを直したのか、それとも修正に見えるだけか?」。Vivarium の branch-fix ループはこれに 機械的な verdict 反転 で答える: 修正をレシピのランタイムに通し、バグがまだ trigger するか を見るだけ。

verdict のセマンティクス。 reproduced は 「バグが trigger する（修正は回避できていない）」、 unreproduced は「バグが trigger しない（修正が壊れた code path を回避できた）」。動く修正は verdict を reproduced から unreproduced に反転させる。

2 つのパスは同じワイヤ形（Contract v1）と同じ比較サーフェス （/repro/compare）を共有する:

Layer ディスパッチは自動 — レシピのカタログエントリが既にどの Layer かを知っているし、MCP の verify_branch_fix ツールは両方に 正しい足場を返す。

既知のレシピから入るか、エラー文から入るかで 2 通り:

Path A に opt-in した Layer 1 レシピは、ベースライン出力の下に 「Try a fix」 パネルを描画する。現時点でこのパネルを出荷しているレシピは無い。ランタイム側の仕組みとこのガイドは、次に opt-in するレシピのために残してある。

エージェント駆動のショートカット。 AI エージェントから verify_branch_fix(slug, fix_url) を呼ぶと、ツールは ?fix_url= 事前読み込み済みの compare_url を返す — その URL を開けばレシピページが自動で fix を走らせる。 verify_branch_fix(slug, fix_source) も同様 （≤4 KiB inline、長い fix は fix_url 経由）。

Layer 2（Docker カタログ）はブラウザ タブでは走らせられない — バグは本物の OS、本物のソケット、 本物のファイルシステムを要求する。Path B はビルドをあなた自身の インフラに移し、push したイメージに対する verdict を GitHub Actions ワークフローでキャプチャする。

巨大 upstream build 用 PAT-push ヘルパー。 無料 GitHub Actions ランナーには重すぎる upstream プロジェクト （Node.js、Chromium 等）をラップしたレシピは、バイナリをローカルで 先にビルドする必要がある。write:packages スコープの classic PAT （ghcr.io は現状 container-registry 認証で fine-grained PAT を サポートしていない）を ~/.config/vivarium/ghcr-pat（mode 0600）に置き、 mise run branch-fix:publish <slug> <tag> <dockerfile> <context> を実行すると、build → ghcr.io/<your-user>/vivarium-<slug>-fix:<tag> に push → docker logout までやってくれる — 認証情報は docker config に残らず、gh CLI の auth state も 触らない。mise run ghcr:login 単体で初回 PAT セットアップ 手順が表示される。

エージェント駆動のショートカット。 Layer 2/3 の slug に対する verify_branch_fix(slug) は、コピペ可能な gh_command を返す。エージェントが実際にそれを走らせるには gh 認証とレジストリアクセスが必要 — だがコマンド自体は 組み立て済み。

branch-fix の verdict が伝えるのはちょうど 1 つ: 修正が当たった状態で バグは trigger したか?

• オリジナル = reproduced、branch-fix = unreproduced。 修正がバグを回避した。典型的な 「修正が動いた」結果。

• オリジナル = reproduced、branch-fix = reproduced。 修正は slop — outcome を変えていない。 修正を反復して再走させる。

• オリジナル = unreproduced、branch-fix = reproduced。 リグレッション — あなたの変更が バグを導入した。diff を巻き戻すか、何を変えたかを確認する。

• オリジナル = unreproduced、branch-fix = unreproduced。 どちらも変化なし。レシピが 非アクティブ（アップストリームが既に修正済み）か、現在のランタイム に対してあなたの修正が no-op。

Path A は ユーザーランド の修正が壊れた code path を回避するか をテストする — アップストリームのインタプリタにパッチを当てる わけではない。Path B は 完全に再ビルドしたイメージ がバイナリレベルでバグを直すかをテストする。重みは違う、ワイヤ形は同じ。

• ランタイムが verdict 生成前にエラーした。 Path A ではパネルのステータスラインが赤になり、ランタイムエラー テキストが出る。よくある原因: ペーストした修正の構文エラー。 構文を直して Run をもう一度クリック。

• スキーマが verdict 形を reject した。 /repro/compare は各 verdict を verdict.schema.json （Contract v1 rev3）に照らして検証する。エラーリージョンは bad フィールドの JSON path を表示する。Path A は構造的に well-formed な verdict を生成するので、これが見えるなら 手編集ファイルをドロップしている可能性が高い。

• CORS で URL 取得がブロックされた。 公開 raw GitHub と Gist URL は CORS 対応ヘッダを返す。セルフホスト URL はしばしば 返さない。その場合はペーストモードへフォールバック。

• Path B のプライベートレジストリイメージ。 ランナーは認証なしで pull する。プライベートレジストリは v1 の スコープ外。public ref に push するか、pull 認証情報フォロー アップを待つ。

• 修正が長すぎて ?fix= に入らない。 インライン URL パラメータの上限は 4 KiB。Gist や fork URL を 使った ?fix_url= を使う。