リンクされたリポジトリ

​

どんなときに必要か

1. producer/consumer の契約の破壊。 バックエンドが API のフィールド名を変えたのにフロントエンドが古い名前を読み続けている。producer が追加した enum の値をどの consumer も処理していない。writer と reader が同じキャッシュキーを別々の方法で導出している。契約は 2 つのリポジトリに分かれており、何もそれを保証していません。
2. 自分のリポジトリが依存しているコードが、自分のリポジトリにない。 Git submodule、vendor された社内パッケージ、ビルド時に取得される共有ライブラリ。レビューはあなたのリポジトリを submodule なし・パッケージのインストールなしでクローンするため、submodule やビルド時の依存はレビュー中は空のディレクトリ（あるいはエージェントが辿れない import）になります。正規の型・ルール・クライアントがそうしたリポジトリにあるなら、それをリンクすることがレビューにそれらを読ませる唯一の方法です。
3. 同じビジネスルールがチャネルやサービスごとに再実装されている。 価格計算、在庫の可否、バリデーション、注文ステータスの遷移。正規の場所に一度だけ存在し、あちこちに「だいたい」コピーされているものです。正規のリポジトリをリンクすれば、エージェントは推測ではなく、正のソースと比較できます。

​

何が得られるか

const isNotApproved =
    error.response?.data?.error === 'INTEGRATION_NOT_APPROVED';

Bug · medium — [cross-repo] フロントエンドは error.response?.data?.error が INTEGRATION_NOT_APPROVED かを見ていますが、バックエンドの sendError（src/api/response.ts）はコードを message フィールドで返します。not-approved の分岐は決して一致せず、ユーザーには常に汎用のエラートーストが表示されます。代わりに data.message を読んでください。

​

指摘はどこに付くか

• すべてのコメントはあなたの PR の diff の行に付きます。リンク先リポジトリのコードは [cross-repo] タグ付きで、相手側ファイル名とともに、コメント内に根拠として引用されます。Kody がリンク先リポジトリにコメントしたり、指摘を立てたり、変更を加えたりすることはありません。
• 指摘は相手側ファイルの確証が取れた場合にのみ挙げられます。根拠のない「このリテラルはバックエンドと一致していなければならない」は出力されません。
• Additional context used の行は、レビュー中にリンク先リポジトリが実際に読まれた場合にのみ表示されます。行がなければ参照されていません（理由は後述）。

​

仕組み

​

何がこのパスを有効化するか

• 文字列リテラル（コード、イベント名、パスのセグメント、ヘッダー名）
• エクスポートされたシンボル（export function/const/class/type/interface/enum）
• enum・type・interface のメンバー
• オブジェクト / ペイロード / DTO のフィールドキー
• status・state・エラーコードらしき識別子（status、code、errorCode、kind、event、key など）
• 契約らしきファイルパス（dto/、schema/、api/、types/、clients/、openapi、proto など）

​

何も表示されないとき

1. diff に境界面がなかった（ゲートがオフのまま — リファクタリングでは想定どおり）。
2. ゲートはオンだったが、エージェントが結論に至るのにリンク先リポジトリを必要としなかった。
3. リンク先リポジトリを取得できなかった（権限、タイムアウト）— レビューはそれなしで続行します。
4. リンク先リポジトリがこの Kodus 組織に接続されていない、または組織のプランにこの機能が含まれていない — リンクは無視されます。

​

リンク先リポジトリの追加

​

Web アプリで

​

kodus-config.yml で

linkedRepositories:
  - repository: "org/backend-api"
    instructions: "このフロントエンドが利用する REST API"
    ref: main   # 任意のピン。省略すると同名ブランチのカスケード

• repository（必須）— 組織に接続されているリポジトリのフルネーム（owner/repo）。
• instructions、ref — Web アプリの項目と同じ意味（下記）。

​

Instructions（指示）

このダッシュボードが利用する REST API。エラーレスポンスは
src/api/response.ts が組み立てる — エラーコードはそこと突き合わせること。

共有の注文ステートマシン。ステータスの enum は
src/domain/order-status.ts にある。定義された値をすべて処理する必要がある。

ビジネスルール・型・クライアントの正規ライブラリ。ここでは git submodule として
利用しているため、ソースはこのリポジトリにない。バリデーションルールは src/rules/、
API クライアントは src/clients/ にある — フィールド名とステータス値はそこと
突き合わせること。

​

Ref pin（ブランチの選択）

1. PR 説明文での上書き — レビュー対象 PR の説明に、リンク先のブランチや PR を書きます（例：org/backend-api#123 や org/backend-api@feature-x）。単発かつ最優先。すでにリンク済みのリポジトリにのみ適用されます。
2. 設定の ref ピン（この項目）が設定されていれば。
3. 一致するブランチのオープン PR — リンク先リポジトリで、head ブランチが自分の PR の head ブランチと一致するオープンなプルリクエスト。
4. リンク先リポジトリの同名ブランチ。
5. リンク先リポジトリのデフォルトブランチ（次いで main/master にフォールバック）。