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.