DWP v5: обіцянки, тепер гарантовані

Сьогодні ми випускаємо Deep Work Plan v5. Це не переписування з нуля: це місяці реального використання — включно з прямим аудитом 108 реальних планів — які прогалина за прогалиною виявляли, де обіцянки методології та реальна поведінка агента могли розходитися. Чесний підсумок цього релізу: методологія обіцяла все це й раніше — тепер вона це гарантує. До v5 агент, який слідував документації до букви, усе одно міг потрапити в реальні сценарії відмови; кожен із цих сценаріїв, виявлений завдяки цьому використанню й цьому зворотному зв’язку, тепер закритий і зафіксований виконуваним тестом, а не заклеєний ще більшою кількістю прози. За цей цикл набір контрактів скіла зріс зі 132 до 258 тестів, і кожна гарантія нижче була валідована наживо проти випущеного тега — встановлена в чистий репозиторій і проведена через власні потоки, перш ніж цей запис було написано.

Верифікатор, який ніколи не заявляє неперевірений успіх. Перевірки відповідності раніше деградували мовчки: без здатного інтерпретатора вони пропускали всі перевірки, але все одно друкували вердикт «відповідає», а жирний текст усередині поля могли прийняти за відсутнє поле. Тепер верифікатор завершує з явним вердиктом UNVERIFIED щоразу, коли неспроможний перевірити насправді. Верифікатор ніколи не звітує про успіх, який не перевіряв, — довіра до gate’ів і є всією пропозицією, і gate, який може пропустити власну перевірку, розриває цей ланцюг.

Єдиний контракт затвердження для планів Lite. Три поверхи відповідали трьома різними способами на питання «чи затверджує запуск цього плану його поточний обсяг?», і агент міг застрягнути в глухому куті або працювати без авторизації саме на найнебезпечнішому кордоні. v5 встановлює всюди один контракт: явний execute або resume затверджує поточний обсяг ready і фіксує це затвердження перед будь-якою роботою; пропозиція в очікуванні сама по собі нічого не авторизує; перерване підвищення відновлюється перед запуском будь-якої продуктової роботи.

Багаторепозиторна оркестрація, яка не пошкоджує. Перевизначення середовища хаба-оркестратора раніше витікало в дочірні репозиторії — дочірній міг писати стан планів у власні теки хаба. Шаблони оркестратора друкували FAIL, виходячи з успіхом, а перевірка повноти, що грепала рядок стану, могла прочитати одне завершене завдання як завершений план. Тепер корінь хаба зберігається перед входом у субрепозиторії, кожен дочірній вирішує власний .dwp/ в ізоляції, кожна гілка відмови завершується з помилкою, повнота парситься зі стану верхнього рівня плану, а точка входу devcontainer поширює помилки копіювання перед будь-яким видаленням.

Єдина матриця згоди для адонів. Який адон встановлюється за замовчуванням, який лише пропонується і який огляд обов’язковий — раніше поверхи відповідали по-різному. v5 проголошує одну матрицю: AI Diff Reviewer обов’язковий для локального огляду, пришпилений до перевіреного релізу, з оглядом у CI як явний opt-in, який ніколи не встановлює себе сам; адон design-system — обов’язкова пропозиція при виявленні UI-роботи, але встановлення лише після явного прийняття; адон dependency-upgrade приходить як майже типовий, інертний делегатор з відкатом за точним знімком; dailybot звітує лише там, де авторизований. Порожній diff більше не зараховується як завершений огляд.

Справжній механізм для довгих планів. Аудит 108 реальних планів показав, що робота, що паралелиться, була звичайною, але послідовне рішення майже ніколи не декларувалося, а stage gate існували лише як ситуативна практика. v5 зобов’язує завжди декларувати рішення виконання — послідовно з зафіксованою причиною, коли паралелізація недоречна — додає необов’язкові Stage Gates для планів на двадцять і більше завдань і збагачує Plan Variables рівнем строгості, планкою доказу та забороненими діями. Усе це вантажиться прогресивно і ніколи не обтяжує план Lite.

Context обов’язковий, одна ціль на завдання. Плани могли сповзати в позбавлені контексту списки завдань, а одне завдання могло зібрати три цілі за одним зеленим gate. v5 вимагає пару Goal і Context на рівні плану, Context на кожне завдання — те, що новій сесії потрібно, щоб розпочати це завдання самостійно — в кожному новому записі (завершені записи лишаються точно такими, як їх написано), і робить одну ціль на завдання нормативним правилом із вартовим проти деградації.

Безпечний шлях оновлення. /dwp-upgrade — нове. Його перевірочна фаза працює лише на читання і нічого не встановлює; оновлення починається лише з явного прийняття, а локальні адаптації порівнюються і показуються перед перезаписом чого-небудь; встановлення цілить у точний тег і верифікує себе; onboarding проходить заново, як свіжий init. Оновлення ніколи не торкається .dwp/ — жоден план, файл стану, запис gate чи доказ не мігрується, не переписується і не анулюється.

Чесний, вимірюваний доказ. Твердження про ефективність тепер перемірюються на трьох бейзлайнах — v3.0.0, v4.0.3 і фінальному дереві — зі скриптом вимірювання, закоміченим у репозиторій. Результати звітуються в байтах файлової системи і ніколи не переводяться в числа токенів чи витрат, які ми не можемо підтримати; кожне неперевірюване твердження карантинується саме як таке в записі оцінки.

Версійний, опублікований контракт. Кожна обіцянка вище підкріплена даними, які можуть прочитати інші інструменти, а не лише прозою: формати plan-manifest і plan-state тепер версіюються як лінія схем v5 — plan-manifest/v5.json і plan-state/v5.json — тож план, верифікатор або стороння утиліта можуть перевірити відповідність опублікованому, машиночитному контракту замість абзацу документації. У лінії v5 нічого не змінює форму порівняно з v2: наявні плани, що посилаються на схеми v1 або v2, лишаються дійсними і ніколи не переписуються.

Deep Work Plan v5 слідує стандарту DWP 5.0.0. Читайте нормативну специфікацію, дивіться репозиторій скіла або починайте впровадження з /init.

Оновлення — 2026-09-17 · скіл v5.4.0

Перший точковий реліз лінії v5 закриває останній шлях, яким план міг завершитися на роботі, що ніколи по-справжньому не перевірялася, і визначає, де живуть докази самого плану. Стандарт DWP 5.0.0 лишається незмінним: це реліз контракту додатка та документації, а не схеми.

Огляд, який ніколи не виконувався, більше не є невідрізненним від чистого. Перевірка безпеки у Final Review вже розрізняла відсутнього рецензента — що фіксується як знахідка — і виклик, що зазнав помилки, який попереджає один раз і продовжує. Рецензент вище за течією додав третій результат: запуск, що стартує й завершується, не записавши жодної знахідки. Без власної назви він зливався з «прохід завершено, нічого не знайдено», а це дозволило б закрити план на огляді, якого не було. Тепер це самостійний стан: фіксується як незавершений огляд, ніколи не зараховується як доказ того, що набір змін чистий, і ніколи не є підставою закрити Final Review. Три різні результати — і жоден не означає, що диф прочитали і він виявився чистим.

Докази плану належать планові. Стандарт уже розміщував запис аналізу, реєстр skills, огляд безпеки та журнали шлюзів у analysis_results/ самого плану, але ніколи не проголошував цю винятковість правилом. Тому власний аудиторський інструмент репозиторію, чий шлях звіту за замовчуванням вказує на робочий каталог, міг записати докази плану в корінь репозиторію — і жоден потік цього не помічав. Специфікація тепер цього вимагає: усе, що потік виробляє про план, потрапляє до теки цього плану, а інструментові, чий типовий вивід — робочий каталог, слід явно передати його опцію виводу. Доказ, якого немає там, де план його обіцяє, — це втрачений доказ. У цьому практична причина правила, а не вподобання щодо впорядкування файлів.

Закріплення AI Diff Reviewer підіймається до v2.3.0. Обовʼязковий локальний огляд тепер встановлює рецензента, який відокремлює runner від backend: той самий огляд можна запускати проти будь-якої сумісної кінцевої точки, не змінюючи того, від чого залежить DWP, — гарантія нейтральності посилюється, а не послаблюється. Додаються інсталятори з перевіркою контрольної суми, типові значення вартості, що виміряні, а не припущені, і наступні раунди, які переглядають справді новий диф, переносячи нерозвʼязані знахідки. В останнього є договірний наслідок, який варто сказати прямо: власна заява моделі про те, що знахідку розвʼязано, її не знімає — знімає супровідник.

Принципи роботи тепер постачаються разом із харнесом. v5.5.0, що вийшов того ж дня, змушує онбординг навчати агентів репозиторію не лише того, що в репозиторії є, а й того, як працювати: десять стислих моделей поведінки — відповідати за результат, дослідити перш ніж питати, самостійно вирішувати рутину, ескалювати коли підстав або повноважень справді бракує, і перевіряти перш ніж заявляти про завершення, серед інших — записаних вбудовано в AGENTS.md, де їх знайде агент, який читає лише точку входу. Це усталені значення в межах запиту, а не нові повноваження: вони не можуть переважити дозволи хоста, вужчі межі, шлюзи плану чи власні правила погодження репозиторію. Оновлення узгоджує їх за змістом, а не за ключовими словами, тож рівнозначні правила, що вже є у файлі, зберігаються, а не переписуються.

Закріплення AI Diff Reviewer підіймається до v2.3.1. Скіл v5.5.1 встановлює рецензента, у якого check, тіло огляду та коментар відстеження узгоджені. Тіло, у якому написано Recommendation: approve, не доводить, що check пройшов, — читайте блок Check status маркера відстеження. У режимі advisory підтверджене виправлення може зняти знахідку, чий тред уже згорнуто, тож застряглий PR може стати зеленим після справжнього виправлення.

Нормативний текст — у специфікації, можливості рецензента — у довіднику додатка, джерело — у релізі v5.5.1.

Оновлення — 2026-09-25 · skill v5.5.3 + оглядач v3.1.1

Додаток AI Diff Reviewer тепер документує та встановлює лінію v3 оглядача, випущену 2026-09-24 (v3.0.0 → v3.1.1, рухомий пін @v3). Skill v5.5.2 переписала нормативні документи додатка, онбординг-гачок і шаблон інтеграції навколо того, що оглядач v3 реально робить, а v5.5.3 випустила сторону CI. Найбільш навантажені зміни, звірені з випущеним оглядачем на тезі v3.1.1:

critical тримає шлюз лише після підтвердження. З v3 кожне критичне твердження моделі — плюс 30-відсоткова вибірка попереджень — отримує другу коротку перевірку на основі коду окремим викликом моделі (≈ 3 k токенів, 10 с і $0.009 за підтверджений виклик). critical публікується — і блокує Final Review — лише коли цей верифікатор його підтвердить; спростовані твердження залишаються видимими як анотовані попередження і перелічуються в структурованому виводі, ніколи інлайн. Огляд, що вичерпав ліміт ходів (incomplete) або настінний годинник (timeout), червоний за блокуючої суворості: «немає знахідок» тепер завжди означає, що оглядач подивився і не знайшов нічого.

Бюджет слідує рівню ризику. Бюджет огляду виводиться з детермінованого рівня ризику зміни — 8/20/30/40 ходів від low до critical — і push без змін коду виконує раунд лише верифікатора з −93 % вартості. budget-profile: fixed відновлює до-v3 константи на перехідний період; інкрементальні раунди скорочують вхідні токени на 62–76 %.

Шість під-skill, одна з них — цикл. Роутер отримує address-review (новий у v3.1.1): одне звернення знаходить відкриті PR гілки, перевіряє, що огляд покриває поточний head, представляє знахідки з планом застосувати/відкласти/пропустити, а після одного «так» — застосовує, комітить малими пачками Conventional Commits, пушить і перевзводить оглядач так, як репозиторій його тригерить. apply-review лишається лише для читання; структурований вивід (review-output/3.0) — машинний шлях для будь-якої автоматизації. Лінія @v2 лишається замороженою на release/v2 з шістьма місяцями підтримки безпеки та каталогу — v3 є рекомендацією, ніколи примусовою міграцією.

Оглядач тепер оглядає власні доми. Репозиторій skill і цей вебсайт обидва запускають етикетко-гейтований CI-огляд — одну grok-ногу через DailybotHQ/ai-diff-reviewer@v3, що спрацьовує раз за накладання етикетки ready (зніміть і надіньте знову для повторного запуску), з чесним пропуском, коли провайдерський секрет відсутній. Цей сайт також vendor’ить оглядача v3.1.1, тож локальний Final Review і документація тепер вчать одного контракту.

Читайте специфікацію, довідник додатка для повного списку можливостей v3, реліз v5.5.3 для джерела або реліз оглядача v3.1.1 для того, що змінилося угорі.