Обчислення перевірки (когорти, осі та детерміновані 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 і повністю замінюють; кожна когорта має ключ, стабільний між push-ами, тож підсумок і поступ рев’ю переживають 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»Вісь контракту порівнює лише явні файли специфікації. Вона зіставляє шість
типових назв — 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, прохід обчислення рендерить змінені компоненти до і після через
headless-прохід golden flutter test у робочих деревах base і head цього PR, а
потім порівнює пікселі.
Знімки з позначкою changed або removed утримують візуальний гейт, доки їх не схвалять; знімки unchanged, added і approved знімають його. Недоступність має одну з чотирьох причин: немає Flutter SDK на хості, немає застосунку Widgetbook у репозиторії, немає сценаріїв використання, придатних для golden-тестів, або помилка golden-стенду.
Схвалення навмисної зміни — це review_studio.approveVisual.
Осі та вердикт
Розділ із назвою «Осі та вердикт»| Вісь | Керує |
|---|---|
| Коректність | Агенти-рецензенти (токени) |
| Безпека | Агенти-рецензенти (токени) |
| Прогалини в тестах | Агенти-рецензенти (токени) |
| Візуальна | Детерміновано (golden-стенд) |
| Контракт API | Детерміновано (diff специфікації) |
Три осі з токенами фіксуються, коли головний агент викликає finalize_review;
дві детерміновані осі фіксує прохід обчислення.
Кожна вісь повідомляє один зі станів:
| Стан | Значення |
|---|---|
| Pass | Виконано, нічого блокуючого не знайдено |
| Warn | Виконано, є неблокуючі зауваження |
| Fail | Виконано, знайдено блокуючу проблему |
| Partial | Виконано, але не завершено; результати неповні |
| Unavailable | Не вдалося запустити взагалі |
Лише pass і warn відкривають вісь із гейтом. Partial і unavailable навмисно відрізняються від fail, і жоден із них не відкриває гейт.
Осі зводяться в Ship, Hold або Block, і вони можуть зробити вердикт лише суворішим — його ніколи не знижують. Вісь із гейтом у стані Fail примусово дає Block; вісь у стані Partial або unavailable примусово дає щонайменше Hold. Тож блокуюча вісь, яку не вдалося запустити, утримує вердикт: відсутність доказів ніколи не робить гейт зеленим.
Вердикт на вкладці Рев’ю — той, який опублікував finalize_review.