Skip to content
Deep Work Plan сегодня на Product Hunt Поддержать
← Все документы спецификации

Соответствие

Версия 1.3. Статус: стабильная. Этот документ определяет, что значит для репозитория быть соответствующим Deep Work Plan — то есть AI-first и пилотируемым агентами. Ключевые слова MUST, MUST NOT, SHOULD, SHOULD NOT и MAY следует трактовать так, как описано в RFC 2119.

Соответствие существует для того, чтобы «AI-first» был объективным, проверяемым свойством, а не впечатлением. Репозиторий либо отвечает приведённым ниже критериям, либо нет. Под-навык verify (/dwp-verify) проверяет их механически.

Соответствующий репозиторий

Соответствующий DWP репозиторий MUST удовлетворять всему перечисленному. Каждый артефакт MUST быть осмыслен под репозиторий — адаптирован к его реальным языкам, фреймворкам и командам. Универсальная заглушка, placeholder или содержимое, скопированное из другого репозитория, не удовлетворяет критерию.

  1. AGENTS.md в корне. Репозиторий MUST содержать корневой AGENTS.md, который включает (a) индекс документации, (b) обязательные правила для репозитория и (c) блок Quick Commands, команды которого реальны и исполнимы в этом репозитории. Команды-заглушки (например, npm test в репозитории, не использующем npm) MUST NOT присутствовать. Индекс MUST NOT ссылаться на файл в docs/, которого не существует, и файл SHOULD оставаться в пределах бюджета 150–500 строк, перенося детали в docs/ и ссылаясь на них вместо неограниченного роста.
  2. CLAUDE.md разрешается в AGENTS.md. CLAUDE.md MUST существовать и разрешаться в AGENTS.md (символьная ссылка или эквивалент, гарантирующий единый источник истины). Эти два файла MUST NOT расходиться.
  3. Иерархия docs/. Репозиторий MUST содержать каталог docs/, охватывающий стандартные категории (архитектура, стандарты, тестирование, команды разработки, безопасность и онбординг агента) с реальным, специфичным для репозитория содержимым. Сложные модули SHOULD нести собственный README.md. Руководство по тестированию MUST определять реальный инструментарий для тестов, линтинга и проверки типов — либо, для репозитория, у которого его нет, конкретную настройку, предложенную на основе стека во время онбординга. Пустое руководство по тестированию или «нет тестов» не удовлетворяет этому критерию: без определённого способа валидировать поведение у плана нет объективного validation gate.
  4. Дом .agents/. Репозиторий MUST содержать каталог .agents/ с agents/, commands/ и skills/, а также каталог в .agents/docs/, который соответствует тому, что есть на диске. Команды dwp-* MUST быть тонкими делегаторами к установленному навыку. Путь .claude MUST разрешаться в .agents.
  5. Игнорируемое git-ом рабочее пространство .dwp/. Репозиторий MUST содержать каталог .dwp/ с plans/, и .dwp/ MUST быть игнорируемым git-ом. Черновое пространство tmp/ SHOULD существовать и SHOULD быть игнорируемым git-ом.
  6. Навык методологии разрешим. Навык Deep Work Plan MUST быть установлен или подключён так, чтобы агент в репозитории мог вызывать его под-навыки.

Репозиторий полностью соответствует стандарту и с нулём опциональных дополнений. Опциональные дополнения (devcontainer, Dailybot, dependency-upgrade, design-system) MUST NOT требоваться для соответствия. Начиная со стандарта 2.3.0 локальный обзор AI Diff Reviewer (вендорённый skill + файл расширения) входит в базовый уровень: его отсутствие — провал для репозитория, объявляющего 2.3.0 или новее, и находка версии harness для устаревшего репозитория. Его CI-поверхность остаётся опциональной.

Хорошо сформированный план

Deep Work Plan в .dwp/plans/ хорошо сформирован, когда:

  1. Каждая задача MUST объявлять явные границы, критерии приёмки и хотя бы один validation gate (команду или проверку, которая объективно проходит или не проходит).
  2. Каждая задача, добавляющая новую базовую функциональность или изменяющая продуктовое поведение, MUST включать в свои критерии приёмки автоматизированное тестовое покрытие этого поведения и MUST запускать тесты репозитория вместе с его проверками линтинга и типов в своём validation gate — а не только сборку. Существующие тесты MUST оставаться зелёными; изменение поведения MUST обновить ломаемый им тест, а не удалять или пропускать его. Задачи, связанные исключительно с документацией, конфигурацией или исследованиями, освобождены от создания тестов, но всё же запускают барьер репозитория.
  3. Каждая задача, затрагивающая аутентификацию, обработку входных данных, секреты или конфигурацию, сетевую поверхность или зависимости, MUST нести в своих критериях приёмки ожидания по безопасности, связанные с этим изменением, и каждый коммит MUST быть свободен от секретных данных.
  4. План MUST сохранять прогресс так, чтобы работа переживала прерывание и могла быть возобновлена другим агентом. Задача MUST NOT записываться как completed, пока любая из её записей validation gate всё ещё показывает проваленный, неразрешённый прогон, и собственный журнал завершения задачи MUST NOT противоречить её зафиксированному статусу (например, задача completed, чей журнал всё ещё гласит «Status: pending», — это дефект, а не успех).
  5. План MUST закрываться своим зафиксированным финальным обзором. План, созданный под эту версию, MUST заканчиваться ровно одним обязательным Final Review — проверкой безопасности, валидацией финального состояния и сверкой решений по skills. План, созданный под более раннюю версию, заканчивается тремя обязательными финальными задачами (Security Review, Skills & Agents Discovery, Executive Report) и остаётся соответствующим. Критическая находка по безопасности блокирует завершение, пока она не исправлена или явно не принята. Само завершение — это верифицированная, восстанавливаемая транзакция, а не переключатель статуса: финальная задача закрывается через защищённый шаг публикации, который валидирует артефакты завершённого плана перед записью состояния и оставляет машинопроверяемую квитанцию FINALIZATION.json; прерванная публикация восстанавливается из доказательства и никогда не объявляется завершённой заново молча. Любой указатель на доказательство, на который ссылается запись gate, MUST разрешаться внутри собственной папки плана — повисший или выходящий за её пределы указатель — это находка, а не проходящее доказательство.
  6. Задачи SHOULD заново привязываться к цели плана перед выполнением, чтобы предотвратить отклонение на длинном горизонте.

Проверка соответствия

Соответствие SHOULD проверяться механически, а не осмотром. Запуск /dwp-verify формирует отчёт «прошёл/не прошёл» относительно приведённых выше критериев: наличие и реальное содержимое AGENTS.md, разрешение CLAUDE.md, категории docs/, совпадение каталога .agents/ с диском, статус gitignore для .dwp/ и tmp/, а для плана — то, что каждая задача несёт критерии приёмки и validation gate, с тестовым покрытием для задач, изменяющих поведение, и наличием зафиксированного финального обзора. Для плана он также проверяет, что markdown плана и его машиночитаемое состояние согласуются (рассинхронизированные README и state.json — это находка, а никогда не тихий успех), что завершённые задачи несут непротиворечивые доказательства gate и журнала, и — там, где завершённый план доходит до этого, — что квитанция публикации подкрепляет заявленное завершение. Проверяющий учитывает версию: он MUST принимать устаревший план (три обязательные финальные задачи, без Затронутой поверхности) как соответствующий и MUST отклонять план, который объявляет эту версию и объективно недействителен в её рамках. Он также сообщает об отсутствующей или устаревшей строке происхождения DWP standard: как о находке, называющей точечное обновление harness. Механический слой честен о своих пределах: без способного интерпретатора (Python 3.9+) он завершается ненулевым кодом выхода и явным вердиктом UNVERIFIED вместо того, чтобы пропускать свои проверки, — верификатор никогда не сообщает результат, который не проверял.

Репозиторий SHOULD перепроверяться после онбординга и после каждого завершённого плана, чтобы соответствие поддерживалось, а не утверждалось единожды.