审查计算（队列、轴与确定性 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 变更则通过。 标记为 派生（仅供参考） 的 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 提交的那一个。