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