審查運算（群組、軸與確定性差異）
PR 的檢閱分頁在審查管線運作期間顯示它的即時進度，之後則顯示它所發佈的產物， 以及其上的各種操作。一個分頁、兩種狀態，因為它們是同一件事在兩個時刻的樣子。它不是 預設分頁：除非有人主動要求，否則 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 合約軸」的章節合約軸只對明確的規格檔案做差異比對。它會匹配六個預設檔名 —— openapi.yaml、
openapi.yml、openapi.json、swagger.yaml、swagger.yml、swagger.json ——
再加上任何檔名含有 openapi 或 swagger，且以 .yaml、.yml 或 .json 結尾的
變更檔案。從處理常式程式碼推斷出的合約不在範圍內，GraphQL 綱要也不做差異比對。
每個變更都會被分類 —— endpoint、parameter、schema 與 response 的新增、移除與修改 —— 並帶有一個嚴重程度：breaking（移除 endpoint 或 param、收緊型別、新增必填 param）、non-breaking（附加式），或 informational。被拒絕的變更會讓合約閘門失敗， 未作出決定的 breaking 變更亦然；breaking 但已核准的會提出警告；沒有 breaking 變更 則通過。標記為 derived (advisory) 的差異永不參與閘門。
核准或拒絕一個變更用的是 review_studio.setContractDecision。
視覺軸
標題為「視覺軸」的章節如果 PR 在一個帶有 Widgetbook 應用程式的 Flutter 儲存庫中改動了 UI 元件，運算階段
會透過在該 PR 的 base 與 head 工作樹中進行一次無介面的 flutter test golden 執行，
渲染出這些變更元件的前後狀態，然後對像素做差異比對。
標記為 changed 或 removed 的快照會扣住視覺閘門，直到被核准；unchanged、 added 與 approved 的快照則會放行。無法使用的原因有四種：主機上沒有 Flutter SDK、儲存庫中沒有 Widgetbook 應用程式、沒有可進行 golden 測試的使用案例，或 golden 測試裝置發生錯誤。
核准一個有意為之的變更用的是 review_studio.approveVisual。
各軸與判定
標題為「各軸與判定」的章節| 軸 | 驅動來源 |
|---|---|
| 正確性 | 審查代理（token） |
| 安全性 | 審查代理（token） |
| 測試缺口 | 審查代理（token） |
| 視覺 | 確定性（golden 測試裝置） |
| API 合約 | 確定性（規格差異） |
三個 token 軸會在主導代理呼叫 finalize_review 時記錄下來；兩個確定性軸則由運算階段
記錄。
每個軸會回報下列狀態之一：
| 狀態 | 含義 |
|---|---|
| Pass | 已執行，未發現任何阻擋性問題 |
| Warn | 已執行，有非阻擋性的顧慮 |
| Fail | 已執行，發現阻擋性問題 |
| Partial | 已執行但無法完成；結果不完整 |
| Unavailable | 完全無法執行 |
只有 pass 和 warn 能放行受閘門控管的軸。Partial 和 unavailable 刻意與 fail 區分開來，兩者都不會放行閘門。
各軸會彙總成 Ship、Hold 或 Block，而且它們只會讓判定變_更_嚴厲 —— 判定絕不會被降級。受閘門控管且失敗的軸會強制給出 Block；partial 或 unavailable 的軸則至少強制給出 Hold。因此，一個無法執行的阻擋性軸會_扣住_ 判定：缺乏證據永遠不會讓閘門變綠。
檢閱分頁上的判定，就是 finalize_review 所發佈的那一個。