Вычисления проверки (когорты, оси и детерминированные diff-ы)
Вкладка «Ревью» PR — это живой прогресс конвейера проверки, пока он работает, а затем опубликованный им артефакт вместе с действиями над ним. Одна вкладка с двумя состояниями, потому что это одно и то же в два момента времени. Она не вкладка по умолчанию: у PR нет проверки, пока её не запросят, поэтому открывает её именно Спросить AI.
За этой вкладкой cc_server строит когорты файлов, выполняет детерминированные
оси и отдаёт их через RPC-операции review_studio.* (cohorts, blastRadius,
cohortImpact, ciSignals, dependencyDiffs, setContractDecision,
approveVisual, compute и их пары watch*). Сохранённая раскладка, которая
всё ещё называет pr.reviewStudio, открывает эту же вкладку «Ревью».
На вкладке «Ревью»:
- Консолидирующий агент публикует обычный артефакт разговора через
publish_artifact, поэтому вкладка отображает его тем же просмотрщиком артефактов, который открывается из сообщения в чате, — отдельной копии системы артефактов «в форме ревью» не существует. - Замечания располагаются в панели рядом с ним, а вердикт едет по тонкой полосе над артефактом, а не в шапке дашборда.
- Баннер устаревания появляется, когда head PR ушёл вперёд относительно проверки.
О самом процессе см. Использовать ИИ-проверку, а о том, как действовать по её результатам, — Проверить и смержить PR.
Когорты
Заголовок раздела «Когорты»Когорты группируют изменённые файлы PR в производные от содержимого корзины файлов, связанных по смыслу, и ранжируют их по влиянию, чтобы самая рискованная группа читалась первой. Они пересчитываются при каждом изменении head-SHA и заменяются целиком; у каждой когорты есть ключ, стабильный между отправками, поэтому сводка и прогресс проверки переживают rebase.
Если в репозитории нет индекса кода, когорты откатываются к группировке по
путям. Чтобы проиндексировать репозиторий, откройте Настройки → Рабочее
пространство → Репозитории — в строке каждого репозитория есть действие
Индексировать код, которое запускает конвейер index_code и сообщает о
прогрессе на месте.
Граф кода разбирает только языки с поставляемой грамматикой (Dart, JS/TS, PHP, Python, Rust, Zig, C/C++, Go, Java, Ruby, C#, Swift, Kotlin, R, Assembly, MATLAB, Ada). Репозиторий на любом другом языке никогда не даст семантических когорт, сколько бы раз вы его ни индексировали.
Агент может записать для когорты сводку в markdown через set_cohort_summary и
приложить структурированную диаграмму-обзор через 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 не сравниваются.
Каждое изменение классифицируется — добавление, удаление или изменение эндпоинтов, параметров, схем и ответов — и несёт степень серьёзности: breaking (удалённый эндпоинт или параметр, ужесточённый тип, новый обязательный параметр), non-breaking (дополняющее) или informational. Отклонённое изменение проваливает контрактный шлюз, как и изменение уровня breaking, оставленное нерешённым; изменение уровня breaking, но одобренное, даёт предупреждение; если изменений уровня breaking нет, шлюз пройден. Diff, помеченный derived (advisory), никогда не управляет шлюзом.
Одобрение или отклонение изменения — это review_studio.setContractDecision.
Визуальная ось
Заголовок раздела «Визуальная ось»Если PR меняет компоненты интерфейса в Flutter-репозитории с приложением
Widgetbook, проход вычислений рендерит изменённые компоненты до и после через
безголовый golden-проход flutter test в базовом и head-worktree PR, а затем
сравнивает пиксели.
Снимки, помеченные changed или removed, удерживают визуальный шлюз до одобрения; снимки unchanged, added и approved его открывают. Недоступность имеет одну из четырёх причин: нет Flutter SDK на хосте, нет приложения Widgetbook в репозитории, нет вариантов использования, пригодных для golden-тестов, или ошибка golden-харнесса.
Одобрение намеренного изменения — это review_studio.approveVisual.
Оси и вердикт
Заголовок раздела «Оси и вердикт»| Ось | Чем управляется |
|---|---|
| Correctness | Агенты-ревьюеры (токены) |
| Security | Агенты-ревьюеры (токены) |
| Test gap | Агенты-ревьюеры (токены) |
| Visual | Детерминированно (golden-харнесс) |
| API contract | Детерминированно (diff спецификации) |
Три оси на токенах записываются, когда ведущий агент вызывает finalize_review;
две детерминированные оси записывает проход вычислений.
Каждая ось сообщает одно из:
| Состояние | Значение |
|---|---|
| Pass | Запускалась, ничего блокирующего не найдено |
| Warn | Запускалась, есть неблокирующие замечания |
| Fail | Запускалась, найдена блокирующая проблема |
| Partial | Запускалась, но не смогла завершиться; результаты неполные |
| Unavailable | Не смогла запуститься вовсе |
Только pass и warn открывают ось под шлюзом. Partial и unavailable намеренно отличаются от fail, и ни одно из них не открывает шлюз.
Оси агрегируются в Ship, Hold или Block, и они могут сделать вердикт только более строгим — он никогда не понижается. Ось под шлюзом, которая проваливается, принудительно даёт Block; ось в состоянии partial или unavailable — как минимум Hold. Так блокирующая ось, которая не смогла запуститься, удерживает вердикт: отсутствие доказательств никогда не делает шлюз зелёным.
Вердикт на вкладке «Ревью» — тот, который выставил finalize_review.