レビューコンピュート（コホート、軸、決定論的 diff）
PR のレビュータブに映るのは、レビューパイプラインが動作している間はそのライブの 進捗であり、動作が終わればパイプラインが公開した成果物と、そこに付いたアクション です。1 つのタブが 2 つの状態を取るのは、同じものの 2 つの時点だからです。これは 既定のタブではありません。誰かが要求するまで PR にレビューは存在しないため、それを 開くのは AIに質問です。
そのタブの背後で、cc_server はファイルのコホートを構築し、決定論的な軸を実行し、
それらを review_studio.* の RPC オペレーション（cohorts、blastRadius、
cohortImpact、ciSignals、dependencyDiffs、setContractDecision、
approveVisual、compute と、それぞれの watch* 版）として提供します。
pr.reviewStudio という名前が残る永続化済みレイアウトも、この同じレビュータブを
開きます。
レビュータブでは：
- 統合エージェントは
publish_artifactで通常の会話成果物を公開するため、タブは チャットバブルが開くのと同じ成果物ビューアを通してそれをレンダリングします — レビュー専用の成果物システムのコピーは存在しません。 - 指摘はその横のレールに並び、判定はダッシュボードのヘッダーではなく、成果物の上の 細いバーに乗ります。
- PR の head がレビューより先に進むと、レビューが古くなったことを示すバナーが 表示されます。
流れについては AI レビューを使う を、 それに対する操作については PR のレビューとマージ を 参照してください。
コホート
「コホート」というセクションコホートは、PR の変更ファイルを、内容から導かれたバケット — 意味の上でひとまとまりに なるファイルの集まり — にグループ化し、影響度で順位付けするため、最もリスクの高い グループから読むことになります。コホートは head SHA が変わるたびに再計算され、 まるごと置き換えられます。各コホートは push をまたいでも安定したキーを持つため、 要約とレビューの進捗は rebase を越えて生き残ります。
リポジトリがコードインデックスされていない場合、コホートはパスによるグループ化に
フォールバックします。リポジトリをインデックスするには、
設定 → ワークスペース → リポジトリを使います — 各リポジトリの行には
コードをインデックスアクションがあり、index_code パイプラインを実行し、その場で
進行状況を報告します。
コードグラフがパースするのは、同梱の文法を持つ言語だけです（Dart、JS/TS、PHP、 Python、Rust、Zig、C/C++、Go、Java、Ruby、C#、Swift、Kotlin、R、Assembly、 MATLAB、Ada）。それ以外の言語のリポジトリは、何度インデックスしても意味論的な コホートを生成できません。
エージェントは set_cohort_summary でコホートの markdown 要約を記録し、
add_review_diagram で構造化されたウォークスルー図を添付できます — 型付きの
シーケンス、エンティティリレーション、ステートマシンのオブジェクトであり、
mermaid テキストではありません。すべてのエッジは実際のコードグラフと照合され、
グラフが裏付けられないエッジは、事実として描画されるのではなく未検証としてマーク
されます。
API コントラクトの軸
「API コントラクトの軸」というセクションコントラクトの軸が diff を取るのは、明示的なスペックファイルだけです。6 つの
既定の名前 — openapi.yaml、openapi.yml、openapi.json、swagger.yaml、
swagger.yml、swagger.json — に加えて、名前に openapi または swagger を
含み、.yaml、.yml、.json のいずれかで終わる変更ファイルにも一致します。
ハンドラーコードから推測されたコントラクトは対象外であり、GraphQL スキーマの diff は
取りません。
各変更は分類され — エンドポイント、パラメーター、スキーマ、レスポンスの追加、削除、 変更 —、重大度を持ちます：breaking（エンドポイントやパラメーターの削除、型の 厳格化、新しい必須パラメーター）、非破壊的（追加のみ）、または情報提供です。却下 された変更はコントラクトゲートを失敗させ、未決定のままの breaking 変更も同じです。 breaking だが承認済みの場合は警告になり、breaking 変更がなければパスします。 **派生（参考）**とマークされた diff は決してゲートしません。
変更の承認または却下は review_studio.setContractDecision です。
ビジュアルの軸
「ビジュアルの軸」というセクションPR が Widgetbook アプリのある Flutter リポジトリで UI コンポーネントを変更すると、
コンピュートパスは、PR の base と head のワークツリーでヘッドレスの flutter test
ゴールデンパスを使って変更前後のコンポーネントをレンダリングし、そのピクセルを
diff します。
changed または removed とマークされたスナップショットは、承認されるまで ビジュアルゲートを保留します。unchanged、added、approved の スナップショットはゲートを解除します。利用不可には 4 つの理由のいずれかがあります： ホストに Flutter SDK がない、リポジトリに Widgetbook アプリがない、ゴールデン テスト可能なユースケースがない、またはゴールデンハーネスのエラーです。
意図した変更の承認は review_studio.approveVisual です。
軸と判定
「軸と判定」というセクション| 軸 | 駆動するもの |
|---|---|
| 正確性 | レビュアーエージェント（トークン） |
| セキュリティ | レビュアーエージェント（トークン） |
| テストギャップ | レビュアーエージェント（トークン） |
| ビジュアル | 決定論的（ゴールデンハーネス） |
| API コントラクト | 決定論的（スペック diff） |
3 つのトークン軸は、リードエージェントが finalize_review を呼び出したときに記録
されます。2 つの決定論的な軸は、コンピュートパスによって記録されます。
各軸は次のいずれかを報告します：
| 状態 | 意味 |
|---|---|
| Pass | 実行され、ブロックするものは見つからなかった |
| Warn | 実行され、ブロックしない懸念がある |
| Fail | 実行され、ブロックする問題が見つかった |
| Partial | 実行されたが完了できず、結果は不完全 |
| Unavailable | まったく実行できなかった |
ゲート対象の軸を解除できるのは pass と warn だけです。Partial と unavailable は fail とは意図的に区別されており、どちらもゲートを解除しません。
軸は Ship、Hold、Block に集約され、軸は判定をより厳しくすることしか できません — 決して格下げされることはありません。失敗したゲート対象の軸は Block を強制し、partial または unavailable の軸は少なくとも Hold を 強制します。つまり、ブロックする軸が実行できなかった場合、その軸は判定を引き留め ます。証拠がないことは、決してゲートをグリーンにしません。
レビュータブに表示される判定は、finalize_review が投稿した判定です。