DWP v5: обещания становятся гарантиями

Сегодня мы выпускаем Deep Work Plan v5. Это не переписывание с нуля: это месяцы реального использования — включая прямой аудит 108 реальных планов, — которые пробел за пробелом выявляли, где обещания методологии и реальное поведение агента могли расходиться. Честное резюме этого релиза: методология обещала всё это и раньше — теперь она это гарантирует. До v5 агент, следовавший документации буква в букву, всё же мог попасть в реальные сценарии отказа; каждый из них, выявленный благодаря этому использованию и этой обратной связи, теперь закрыт и закреплён исполняемым тестом, а не залатан дополнительной прозой. Контрактный набор скилла вырос за этот цикл со 132 до 258 тестов, и каждая гарантия ниже была вживую проверена против выпущенного тега — установлен в чистый репозиторий и проведён через собственные сценарии ещё до того, как написана эта запись.

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

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

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

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

Настоящая механика для длинных планов. Аудит 108 реальных планов показал: параллелизуемая работа была обычным делом, но последовательное решение почти никогда не объявлялось, а стадийные гейты существовали лишь как разовая практика. v5 требует всегда объявлять решение об исполнении — последовательное с зафиксированной причиной, когда параллелизм не оправдан, — добавляет опциональные Stage Gates для планов из двадцати и более задач и обогащает Plan Variables уровнем строгости, планкой доказательности и запрещёнными действиями. Всё это загружается прогрессивно и никогда не отягощает Lite-план.

Обязательный Context, одна цель на задачу. Планы могли сползать в списки задач без контекста, а одна задача могла упаковать три цели за одним зелёным гейтом. v5 требует пару Goal и Context на уровне плана и Context на каждую задачу — то, что новой сессии нужно, чтобы начать эту задачу в одиночку, — в каждой новой записи (завершённые записи остаются ровно как написаны), и делает «одна цель на задачу» нормативным правилом с защитой от распада.

Безопасный путь обновления. /dwp-upgrade — новое. Фаза проверки только читает и ничего не устанавливает; обновление начинается только с явного согласия, причём локальные адаптации сравниваются и показываются до перезаписи чего-либо; установка нацелена на точный тег и проверяет сама себя; онбординг перевыпускается как свежий init. Обновление никогда не трогает .dwp/ — ни один план, файл состояния, запись гейта или доказательство не мигрирует, не переписывается и не инвалидируется.

Честные измеримые доказательства. Заявления об эффективности теперь перемеряются на трёх базовых линиях — 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.