ШІ-перевірка

Як влаштована перевірка

ШІ-перевірка — це один запуск вбудованого конвеєра pr_review для одного відкритого pull request. Конвеєр відкриває простір перевірки цього PR, розгортає агентів-рецензентів читати diff в ізольованому checkout цього простору, кожен оформлює свої зауваження як структуровані вузли перевірки, провідний агент зводить їх у покроковий огляд, а фіналізатор обчислює один вердикт: Ship, Hold або Block. Чого конвеєр не робить ніколи — не публікує: публікація на GitHub це окремий, свідомий крок, який робить людина.

Решта цієї сторінки пояснює ці складові та те, чому вони мають саме таку форму.

Один простір перевірки на кожен PR

Контекст перевірки PR — це простір обміну повідомленнями (режим review, тип pr), пов’язаний із pull request через зв’язок простору перевірки. Він створюється ідемпотентно: сторінка PR, конвеєр перевірки та поверхні чату визначають один-єдиний опорний простір PR тим самим шляхом коду, тож шаблон, який перевіряє PR, і людина, яка його відкриває, ніколи не опиняться у двох різних кімнатах із двома різними checkout.

Ізольований worktree простору містить PR, вибраний за його head ref. Одна кімната означає також один checkout: кожен рецензент працює в тому самому просторі, а не отримує власну копію робочого простору.

Кожен рецензент пише у власний іменований потік усередині цього єдиного простору, а зауваження — це повідомлення review_node, а не звичайний текст. Збір з усього простору наприкінці — навмисний: вердикт, обчислений із зауважень однієї гілки, нишком був би вердиктом про одного рецензента.

Зв’язок має драбину статусів — requested → in progress → awaiting approval → completed — яка й слугує гейтом для кнопки Опублікувати на GitHub на вкладці Рев’ю PR.

Рівні перевірки

Глибину перевірки визначає політика робочого простору з трьома рівнями, яку задають у Налаштування → Робочий простір → Загальні, на картці Політика робочого простору:

Рівень	Рецензенти, які розгортаються	Звітність
light	Лише інженер	Лише те, що справді має значення
balanced	Інженер, QA, архітектор (типово)	Звичайний прохід
thorough	Усі п’ятеро, включно з безпекою та продуктивністю	Нічого не знижується

Рівень повертає одразу дві ручки: яких рецензентів розгортають — це забезпечують гейти стану runWhen у шаблоні конвеєра, а не формулювання в промпті (формулювання в промпті можна проігнорувати, гейт — ні) — і де відображаються зауваження, нижчі за поріг. Жодна з ручок ніколи не видаляє зауваження: рівень, який звітує менше, все одно фіксує рівно стільки ж і просто групує решту.

Проходи з безпеки та продуктивності використовують ті самі вбудовані агенти архітектора й інженера, а не заводять нові. Спеціалізація — це завдання, з яким запускають рецензента, а не окремий агент на кожну вісь: агент на кожну вісь означав би п’ять додаткових рядків у кожному робочому просторі без жодної додаткової спроможності. Вибір рецензентів ніколи не переглядає diff на мову чи домен.

Вузли перевірки: зауваження як дані, а не текст

Зауваження, зафіксоване через add_review_node, стає вузлом перевірки на PR — саме його показує вкладка Рев’ю, саме з нього обчислюють вердикт, і саме його «Опублікувати на GitHub» перетворює на вбудований коментар. Рецензент, який повертає лише текст, дає запуск конвеєра, що виглядає успішним, і порожню поверхню перевірки; саме фіксація несе все навантаження.

Кожен вузол містить:

Поле	Значення
Вид	bug, suggestion, recommendation, question, ticket
Пріоритет	P0 (критичний) → P3 (дрібниця)
Тріаж-трійка	категорія (security, stability, …), серйозність, трудозатрати
Якір	Шлях до файлу, початок і кінець рядка
Передача виправлення	Запропоновані рядки заміни, необов’язковий diff, необов’язковий промпт виправлення
Впевненість	Оцінка в [0, 1]
Обґрунтування	Аналіз, написаний до зауваження

Дві деталі тут навмисні. Пропозицію GitHub в один клік показано лише тоді, коли рецензент надав точні рядки заміни: виводити їх з уніфікованого diff — означає тихо помилятися, а коміт у один клік із хибного висновку гірший за відсутність кнопки взагалі. І схема add_review_node подає reasoning перед зауваженням, тож модель, яка заповнює об’єкт у порядку схеми, спершу пише аналіз. Поле необов’язкове: якщо його пропустити, вузол не відхиляється. Вузол із пошкодженим вмістом зникає, а не забруднює перевірку.

Консенсус рецензентів

Вузол проходить через open → consensus-ready → resolved або dismissed. Середній крок — серце цієї моделі: зауваження переходить далі лише тоді, коли його підтверджує рецензент-колега, а агент ніколи не може підтвердити власне зауваження. Інструмент MCP publish_review_to_github і типове значення RPC усе ще публікують лише зауваження, підтверджені колегами. А кнопка Опублікувати на GitHub на вкладці Рев’ю натомість надсилає кожне зауваження, що лишилося відкритим.

Це правило забезпечують у трьох незалежних місцях — інструменті підтвердження, фіналізаторі та публікаторі — тож воно витримує помилку в будь-якому одному з них. Усі зміни статусу проходять через одну службу, і саме це надає статусу сенсу: до того дві часткові реалізації могли розходитися в тому, чи те саме зауваження вважається вирішеним.

Коли рецензенти розходяться — той самий файл і рядок, пріоритети, що різняться на два щаблі або більше, або один називає це bug, а інший — suggestion — розбіжність виносять над списком зауважень. Саме там думки рецензентів розходяться, і людське судження важить найбільше.

Відхилення зауваження також записує м’який факт придушення в домен пам’яті, з низькою впевненістю: одне відхилення — це вподобання, а не правило.

Когорти: навколо чого групують перевірку

Прохід обчислення перевірки групує змінені файли PR у когорти, виведені з графа коду: змінені файли зіставляються із символами, яких вони торкаються, символи — зі зв’язаними компонентами, а когорти впорядковують за радіусом впливу. Когорта несе в собі скерований порядок читання, діаграми та інсайти, а не є пласким списком файлів.

Цю картину формують два правила чесності. Ключі когорт виводяться зі вмісту й лишаються стабільними під час push, тож зауваження та поступ перевірки переживають rebase або force-push, а не осиротіють. А коли в репозиторії немає індексу коду, групування відкочується до звичайних шляхів і прямо про це повідомляє: запасний варіант ніколи не вдає семантичну впевненість.

Осі та гейти перевірки

Поряд із зауваженнями рецензентів перевірка накопичує результати осей: шість осей двох видів.

Вісь	Вид	Звідки береться
correctness, security	На токенах	Власні зауваження рецензентів
testGap	На токенах	Зауваження рецензентів
visual, apiContract	Детерміновано	Обчислюється без витрат токенів
performance	Детерміновано	Лише enum — ніщо в продукті не обчислює результат

Вердикт осі — pass, warn, fail, partial або unavailable, і лише pass чи warn проходять гейт. Розрізнення між fail, partial та unavailable несе навантаження: вісь під гейтом, яка не змогла завершитися або взагалі не запустилася, утримує загальний вердикт, а не пропускає його. Відсутність доказів ніколи не перетворюється на зелений гейт.

Деякі осі навмисно дорадчі. Вісь тестових прогалин, виведена з когорт, не бачить покриття dependency injection чи фабрик: неіндексований репозиторій із ґрунтовним набором тестів і репозиторій без тестів узагалі виглядають звідти однаково, тож стверджувати будь-що з цього було б брехнею; вона показується на панелі, але не керує гейтом. Осі на токенах дорадчі, бо пріоритети зауважень уже визначають вердикт, і повторне застосування до них гейта дало б подвійний облік.

Вердикт

Фіналізатор обчислює вердикт за зауваженнями зі статусом open або consensus-ready:

• будь-яке зауваження P0 із упевненістю ≥ 0.7 → Block
• інакше, будь-яке P0 (із низькою впевненістю) або будь-яке P1 → Hold
• інакше → Ship

Вердикт несе сукупну впевненість, виведену з розкиду впевненостей, що його склали: згода її підвищує, розходження — знижує.

Узагальнення провідного (CEO) агента — це редакторський прохід, а не повторний перелік: написана від руки друга копія зауважень — саме те, що розходиться зі справжньою. Дублікати зауважень знижують, а не повторюють: кількох рецензентів навмисно наводять на один diff із навмисно перекривними зонами відповідальності, тож той самий дефект, що доходить до фіналізатора тричі, — це система, яка працює; а публікація його тричі — це система, яка просочує власну архітектуру у вхідні читача. Під час повторної перевірки зауваження знімають відбитки й порівнюють із попереднім раундом, тож на поверхню виходить саме дельта.

Зрештою долучаються осі, і вони можуть лише зробити вердикт суворішим: вісь під гейтом, яка зазнала невдачі, примусово дає Block — зауваження не можуть її переважити — а вісь під гейтом, яка не змогла завершитися, примусово дає щонайменше Hold.

Публікація залишається за вами

Конвеєр навмисно не публікує на GitHub; публікація проходить через гейт користувача, тож перевірка ніколи не опублікується двічі. Коли ви натискаєте Опублікувати на GitHub:

• Надсилається одна перевірка GitHub. Зауваження, уже вирішені або відхилені, пропускаються. Кнопка публікує кожне зауваження, що лишилося відкритим (selection: all_open). Інструмент MCP publish_review_to_github усе ще типово публікує лише зауваження, підтверджені колегами (consensus).
• Зауваження, прив’язані до файлу й рядка, стають вбудованими коментарями; усе інше згортається в тіло підсумку, і кожен несе приписку «— Control Center AI review», щоб джерело було однозначним.
• Якорі повторно звіряють із поточним diff PR під час публікації. Коментар до коду, який уже переписали, найдужче руйнує довіру з усього, що може залишити рецензент; якщо GitHub усе ж відхиляє вбудований якір, усю перевірку надсилають заново, згорнувши кожне зауваження в тіло, щоб нічого не зникло нишком.
• Вердикт Block надсилається як REQUEST_CHANGES; Hold — як COMMENT; Ship — як APPROVE з кнопки (approve_on_ship: true). Інструмент MCP лишає Ship як COMMENT, доки ви не передасте approve_on_ship.
• Перевірку публікують під ідентичністю застосунку сервера. Хто натиснув «Опублікувати на GitHub», записують для рольового гейта й журналу аудиту; це не автор на GitHub.

Публікація оголошує клас дії prPublish, тож контрольна точка обмежень пропускає її через гейт, як і будь-яку змінювальну дію: типово вона запитує підтвердження, а коли жодного затверджувача не під’єднано — безпечно відмовляє. Див. Обмеження.

Що може робити рецензент

Агенти-рецензенти працюють у режимі review: пісочниця лише для читання та дібраний список дозволених інструментів, що охоплює зауваження, коментарі, тікети й взаємне рецензування, — але жодних змін. Рецензент не може виправити код, який критикує; він може долучити запропоноване виправлення, яке застосує людина. Повідомлення про відмову цього режиму підказує агенту, який усе ж намагається діяти, завершити перевірку й дати користувачеві діяти за опублікованим підсумком.

Пов’язані поняття

• Обмеження — рушій політик, що керує гейтом публікації
• Режими — що режим review змінює для агента
• Конвеєри та автоматизація — рушій, на якому працює перевірка
• Життєвий цикл запуску агента — звідки береться ізольований worktree

Пов’язані практичні посібники

• Використовувати ШІ-перевірку — запустіть перевірку та опублікуйте її
• Запускати агентів-рецензентів — виберіть рецензентів самі
• Обчислення перевірки — когорти, осі та diff