Додаток AI Diff Reviewer
Кожен Deep Work Plan завершується однаково: обовʼязковим Final Review, який прочитує весь накопичений планом набір змін, перш ніж роботу можна буде назвати зробленою. Перевірка безпеки всередині нього — остання точка, де ще можна щось помітити. Без сторонньої допомоги єдиний читач у цей момент — той самий агент, який написав цей код.
Цей додаток садить над тим дифом другого читача. Він підключає AI Diff Reviewer — у маркетплейсі він значиться як “AI Diff Reviewer”, наразі реліз v3.3.0 — до перевірки безпеки, де той повертає не прозу, а структуру: вердикт, таблицю знахідок і рівень серйозності для кожної. Починаючи з v3, знахідка critical означає, що верифікатор додатка підтвердив її другим, спрямованим на код викликом моделі; блокувати завершення до виправлення або явного прийняття можуть лише підтверджені критичні знахідки. Цей огляд — шлюз, а не коментар.
Починаючи зі стандарту 2.3.0, такий локальний огляд — частина базового рівня, а не додаток. Онбординг його встановлює; кожен Final Review його запускає. Опційною лишається CI-поверхня — Flow B, де той самий огляд контролює pull request’и через GitHub Action.
Межа, яка робить це безпечним для впровадження, окреслена навмисно вузько. Оглядач — це skill під ліцензією MIT, закріплений за тегом і виконуваний тим самим кодовим агентом, який у вас уже працює, тож жоден потік Deep Work Plan не залежить від комерційного сервісу, CI-провайдера чи секрету. Flow A (лише локально) отримує кожен онборджений репозиторій; Flow B пропонується явно і ніколи не встановлюється без запиту. Розробник може й зовсім відмовитися від оглядача — та відмова фіксується як заявлений виняток, і verify звітує про невідповідність репозиторію за цим пунктом, доки оглядача не буде встановлено.
Коли використовувати
| Сигнал | Дія |
|---|---|
| Кожен онборджений репозиторій | Flow A встановлюється у фазі 7a онбордингу (vendored-скіл + .review/extension.md); цільове оновлення harness додає його до репозиторіїв, онборджених раніше |
| Команда хоче CI-шлюз для злиття PR зі структурованими знахідками | Запропонувати Flow B — явний вибір, ніколи не за замовчуванням |
| Особистий або експериментальний репозиторій; локального огляду достатньо | Залишитися на Flow A — базовий рівень є повним |
Два потоки прийняття
| Потік | Що ви отримуєте |
|---|---|
| A — лише локально (базовий рівень) | Vendored-скіл + обовʼязковий .review/extension.md (через generate-extension). Запускає локальний огляд усередині перевірки безпеки кожного Final Review. Без робочого процесу GitHub Actions. |
| B — подвійна поверхня | Flow A плюс setup записує робочий процес огляду (Action @v3), той самий файл розширення для локального та CI. Необовʼязкові супутники apply-review і address-review після того, як CI публікує знахідки. |
Виявлення для локального огляду потребує skill + файл розширення в одному з: .review/extension.md, .github/ai-diff-reviewer/extension.md або .github/ai-pr-reviewer/extension.md. Одного skill недостатньо.
Що підключає цей додаток (навмисно обмежено)
Додаток DWP не перевинаходить оглядача. Він делегує встановлення, методологію, майстер CI, написання розширень, складання PR і цикли огляду після CI шести підскілам вихідного skill (батьківський типовий потік, generate-extension, setup, open-pr, apply-review, address-review).
Обовʼязковий локальний огляд
create додає крок локального огляду до перевірки безпеки кожного Final Review, а execute його запускає. Вивід додається під ## AI Diff Reviewer local review у локальному для плану analysis_results/SECURITY_REVIEW.md (усередині власної теки плану, ніколи в корені репозиторія).
- Відсутній оглядач — фіксується, ніколи не пропускається мовчки: відсутній skill чи розширення стає знахідкою
local reviewer not installed; Final Review запускає локальний прохід, коли скіл установлений, інакше знахідка переноситься в звіт про завершення — установка належить згоді онбордингу або явному виклику адд-она, ніколи не несподіваний бустреп. - Мʼякий збій (лише виклик): огляд, що міг стартувати, але завершився помилкою → попередити один раз, зафіксувати, продовжити; ніколи не провалювати завдання через цей промах.
- Шлюз після завершеного проходу: підтверджені знахідки
criticalблокують завершення Final Review до виправлення або явного прийняття (BC-07). Непідтверджені критичні твердження надходять як анотовані попередження — видимі та неблокувальні, докиstrict-unverified-criticals: trueне поверне блокування за твердженням. Огляд, що вперся в ліміт ходів (incomplete) чи в ліміт часу (timeout), не є чистим проходом при блокувальній суворості (BC-04).warning/infoдокументуються, але не блокують. - Flow A не потребує CI-секрету. Незаданий ключ провайдера не має пригнічувати локальний прохід.
CI-шлюз Flow B (необовʼязково)
Action DailybotHQ/ai-diff-reviewer@v3, зазвичай заблокований міткою (ready), зі стабільно названим завданням AI review gate для захисту гілки та необовʼязковою міткою пропуску skip-review-label: skip-ai-review. Починаючи з v3, бюджет огляду слідує за детермінованим рівнем ризику зміни — 8/20/30/40 ходів від low до critical при budget-profile: auto (fixed на час переходу повертає константи до v3), — а push, що не змінює коду, запускає раунд лише з верифікатором. Спільний prompt.md + розширення вирівнюють методологію та серйозність; локальна перевірка й CI лишаються методологічно ідентичними, при цьому раунди CI 2+ при Iteration-Aware Review можуть бути коротшими, а локальний прохід лишається повним.
Необовʼязкові супутники огляду
Два підскіли, які викликає розробник, замикають цикл після того, як CI публікує огляд; жоден із них ніколи не є файлом завдання плану (це порушило б обовʼязковий порядок фінальних завдань).
apply-reviewпроходить знахідки по одній (застосувати / відкласти / пропустити) зі згоди. За замовчуванням лише читання; ніколи не робить комітів і push.address-review(новий у v3.1.1) — це цикл одного звернення: знайти відкриті PR гілки, перевірити свіжість огляду для поточного head, подати знахідки з планом застосувати/відкласти/пропустити, а тоді — після одного «так» — застосувати, закомітити малими партіями Conventional Commits, зробити push і перевзвести оглядача тим способом, яким репозиторій його запускає (за міткою → перемкнути мітку вимк/увімк; за push → підтвердити новий запуск). На відміну відapply-review, він робить коміти й push; у цьому сенс циклу. На агрегованих оглядах ансамблю він читає агрегований документ і маркерai-pr-reviewer-aggregate.- Машинний шлях — структурований вивід, а не тіло огляду: документ
review-output/3.0(.aiprr/review-output.json, що знаходиться через виходиstructured-output-pathіstructured-output-sha256) несе запис запуску, знахідки з доказами та верифікацією, спростовані знахідки і шлюз. Тіло огляду, у якому написаноRecommendation: approve, не є доказом, що перевірка пройшла, — спочатку прочитайте блок Highest severity / Strictness gate / Check status у маркері відстеження.
Що змінилося у v3
Три релізи вийшли 2026-09-24 (v3.0.0, v3.0.1, v3.1.0), за якими послідував v3.1.1 із підскілом address-review; згодом v3.2.0 і v3.2.2 (2026-09-26) зробили цей цикл обізнаним щодо CI і здатним зводити PR, на якому оглядач ще не запускався. Жоден із них не змінює того, як цей додаток підключає оглядача — Flow A, три шляхи виявлення та драбина «ніколи не блокувати» лишилися незмінними, — але вони змінюють те, що отримує той, хто його впроваджує.
| Зміна | Що це означає для репозиторію DWP |
|---|---|
critical публікується лише після підтвердження (v3.0.0) |
Кожне заявлене критичне твердження — плюс 30 % вибірка попереджень — проходить другу коротку спрямовану на код перевірку окремим викликом моделі (≈ 3 k токенів, 10 с і $0.009 на підтверджену знахідку). Підтверджені критичні знахідки блокують перевірку безпеки; спростовані твердження лишаються видимими як анотовані попередження й перелічуються у структурованому виводі, ніколи не публікуючись інлайн. |
| Бюджети слідують рівню ризику (v3.0.0) | 8/20/30/40 ходів від low до critical, похідних з інвентарю змін (budget-profile: auto). Push, що не змінює коду, запускає раунд лише з верифікатором за −93 % вартості. budget-profile: fixed повертає константи до v3 у 30 ходів. |
| Незавершений огляд червоний (v3.0.0) | incomplete (ліміт ходів) і timeout (ліміт часу) публікують часткові знахідки й провалюють блокувальну суворість — «знахідок немає» відтепер завжди означає, що оглядач подивився й нічого не знайшов. |
| Структурований вивід — машинний шлях (v3.0.0) | Документ review-output/3.0 несе запис запуску, інвентар змін, знахідки з типізованими доказами та верифікацією, спростовані знахідки і шлюз. Читайте документ, а не збирайте тіла оглядів. |
| Шість підскілів (v3.1.1) | address-review долучається до роутера: одне звернення застосовує, комітить, робить push і перевзводить оглядача. |
| Цикл враховує CI (v3.2.0, v3.2.2) | address-review також читає логи невдалих workflow і виправляє їх у тому ж погодженому проході, оновлює гілку, що відстала від базової, і зводить PR, на якому оглядач ще не запускався (просте «loop the review» націлене на відкритий PR поточної гілки). |
| Необовʼязковий ансамбль (v3.0.0) | Гілки лише для читання mode: emit плюс одне завдання aggregate одноразово перевіряють консолідовані знахідки й публікують єдиний огляд. |
@v2 продовжує працювати |
Лінія v2 заморожена на release/v2 із шістьома місяцями супроводу безпеки та каталогу. v3 — рекомендація, ніколи не примусова міграція. |
Два з цих пунктів важать для методології більше за решту.
Шлюз підтверджених критичних знахідок укріплює перевірку безпеки. До v3 модель могла вільно заявити critical, і шлюз ішов за твердженням. Тепер критична знахідка у Final Review означає, що другий виклик моделі підтвердив її за кодом, і релізна кампанія виміряла різницю: 771 платний оціночний прогін у десяти кампаніях приблизно за $83 сумарно, критичний рівень досяг повноти 63/63 при точності 1.0 за підсумком розбору, а інкрементальні раунди скорочували вхідні токени на 62–76 %. Ці числа — опубліковані upstream вимірювання, а не власні вимірювання Deep Work Plan.
economy навмисно не дешевший. Бенчмарк upstream від 2026-09-16 показав у grok-4.3 0 із 5 відомих дефектів — він схвалює, не переглядаючи, — тоді як grok-4.5 зрівнявся з grok-4.6, знайшовши 3 із 5 без хибних спрацювань, за тієї самої вартості й учетверо меншого часу. Оскільки дешевшої моделі xAI, яка все ще справді переглядає, не існує, economy розвʼязується в ту саму модель, що й balanced, замість бути рівнем, який нічого не знаходить; на runner’і grok вартість масштабує бюджет ходів рівня ризику, а не вибір моделі. Тому шлях xAI через CLI дорожчає приблизно з $0.07 до приблизно $0.40–0.75 за огляд; З промпта v3.0 повторне вимірювання на 63 прогонах підняло grok-4.3 з 0 із 5 до 83 % повноти без хибних спрацювань і з ~31 % меншою вартістю — але він досі приблизно втричі частіше за grok-4.5 не записує файл знахідок, тож grok-4.5 залишається типовим значенням, а model: grok-4.3 — явним вибором із прийнятим компромісом. Ці числа — опубліковані upstream вимірювання, а не власні вимірювання Deep Work Plan.
Поведінка
- Flow A — базовий рівень; про Flow B питають, ніколи не вгадують. Встановлення незапитаного робочого процесу має більший слід, ніж залишатися на Flow A.
- Узгоджуйте, не перезаписуйте. Існуючий skill, розширення або робочий процес огляду зберігаються; заповнюйте лише прогалини.
- Автентифікація відкладена. Секрети провайдера для CI налаштовує супроводжувач; цей додаток ніколи не зберігає облікові дані.
- Нейтральність щодо постачальника. Комерційний сервіс, CI-провайдер чи секрет ніколи не потрібні; CI-поверхня — єдина частина, що торкається провайдера.
Примітки
Локальний огляд обовʼязковий починаючи зі стандарту 2.3.0; CI-поверхня опційна. Вихідний skill: DailybotHQ/ai-diff-reviewer. Посібник із міграції upstream: docs/MIGRATION_v3.md. Сторінка специфікації: Add-ons.