Skip to content
← Все главы

Глава 02

Основной цикл

DWP определяет небольшой набор операций, которые ведут план от цели к завершённой, пригодной для ревью работе: create → execute → refine → resume → status, а verify служит проверкой соответствия, подтверждающей результат. Вместе они образуют цикл, которому агент следует на протяжении всей жизни плана. Агенты выполняют по одной задаче за раз, проверяя каждый шаг, прежде чем двигаться дальше.

Этот цикл — операционная форма spec-driven-разработки. План — это спецификация, по которой агент выполняет работу, каждая задача несёт явные критерии приёмки, а шаг валидации — это gate, превращающий утверждение о завершении в его доказательство. Поскольку план и его журнал прогресса живут в репозитории, цикл возобновляем между сессиями и агентами.

Операции

Навык методологии делегирует намерение девяти специализированным поднавыкам: шесть основных операций выполнения, два помощника жизненного цикла и механизм создания:

  • create — создаёт новый план из цели. Агент анализирует цель, раскладывает её на последовательные задачи и пишет файлы плана. В управляемом режиме агент сразу материализует Lite-план — компактное, уже исполняемое предложение в README.md, — позволяя разработчику сохранить его, повысить до Full-плана, отредактировать или отменить; в trust-режиме материализует выбранное представление (Lite или Full) напрямую без подтверждения. Анализ требований и проверка качества плана выполняются в обоих режимах.
  • execute — последовательно выполняет план задача за задачей. Агент обновляет журнал прогресса, запускает validation gates и коммитит после каждой задачи. В trust-режиме выполнение продолжается автономно без вопросов между задачами.
  • refine — изменяет существующий план (добавление, редактирование, разделение или переупорядочивание задач, либо повышение Lite-плана до Full). Проверенные свидетельства строго сохраняются, а неподтверждённое ослабление критериев запрещено.
  • resume — продолжает прерванный план. Агент читает журнал с возможностью только добавления и файлы задач для восстановления состояния, затем продолжает с первой незавершённой задачи без повторения готовой работы.
  • status — отчитывается о прогрессе без выполнения (строго только для чтения). Агент резюмирует завершённые, выполняемые и ожидающие задачи и ничего не меняет.
  • verify — проверяет соответствие, ничего не меняя (строго только для чтения). Агент сообщает, отвечает ли репозиторий стандарту AI-first и несут ли задачи плана явные критерии и validation gates.
  • onboard — исследует целевой репозиторий и на основе рассуждений — никогда не через копирование шаблонов — формирует адаптированный AGENTS.md, стандартную иерархию docs/, документацию модулей и набор .agents/ с симлинками.
  • upgrade — проверяет апстрим-релизы, запрашивает согласие разработчика перед загрузкой, устанавливает зафиксированные стабильные теги и согласует локальные адаптации, не затрагивая существующие планы .dwp/.
  • author — создаёт и развивает локальные для репозитория навыки, агенты или слэш-команды под реальные повторяющиеся рабочие процессы, сохраняя синхронизацию каталога .agents/docs/.

Выходной каталог .dwp/

Все артефакты DWP живут в игнорируемом git-ом каталоге .dwp/ в корне репозитория. Держа рабочее пространство вне контроля версий, вы добиваетесь того, что рабочее состояние плана никогда не засоряет историю проекта. Конфигурация аддонов на уровне репозитория фиксируется в .dwp/config.json (dwp-config/v1), а планы располагаются в плоских нумерованных каталогах:

.dwp/
├── config.json
└── plans/
    └── PLAN_001_<slug>/
        ├── manifest.json
        ├── contract.json
        ├── journal.ndjson
        ├── state.json
        ├── README.md
        ├── PROGRESS.md
        ├── 1.task_<slug>.md
        ├── 2.task_<slug>.md
        └── analysis_results/

Анатомия задачи из десяти разделов

Каждый файл задачи следует десяти нормативным разделам, показанным выше, в порядке, определённом установленным навыком.

  1. Goal — один абзац, формулирующий, чего достигает задача.
  2. Context — предыстория, ссылки и почему эта задача существует.
  3. Затронутая поверхность — что задача меняет и класс риска, который выбирает её проверку.
  4. Steps — упорядоченные, конкретные действия для выполнения.
  5. Acceptance criteria — чек-лист условий, определяющих готовность.
  6. Validation — команды или тесты, которые нужно запустить для проверки работы.
  7. Files — пути, которые предполагается создать или изменить.
  8. Dependencies — другие задачи или внешние предпосылки.
  9. Risks — что может пойти не так и меры по смягчению.
  10. Completion & Log — маркер статуса плюс хронологические заметки.

Валидация, завершение и возобновление

Валидация — часть задачи, а не запоздалая мысль: каждая задача называет команды или тесты, доказывающие её выполнение, и агент запускает их перед тем, как отметить завершение. Тесты здесь полноправны — задача, добавляющая новую функциональность или изменяющая поведение, должна добавить или обновить автоматизированные тесты этого поведения и запустить полную проверку качества кода репозитория (тесты плюс линтинг и проверку типов), а не просто подтвердить, что сборка прошла успешно; существующие тесты должны оставаться зелёными, обновлёнными до предполагаемого поведения, а не пропущенными. Безопасность полноправна так же — любая задача, затрагивающая аутентификацию, обработку ввода, секреты, сетевую поверхность или зависимости, несёт ожидания по безопасности этого изменения в своих критериях приёмки и держит каждый коммит свободным от секретов, и каждый план завершается Final Review — проверкой безопасности всего набора изменений, полной валидацией финального состояния и сверкой решений по skills. Завершение фиксируется явным маркером статуса ([ ] не начато, [~] в работе, [x] готово, [!] заблокировано) в разделе Completion & Log. Возобновление опирается на эти маркеры и журнал прогресса — агент может точно восстановить, где план остановился, и продолжить с первой незавершённой задачи, не переделывая выполненную работу.

v6 и v7: та же методология, более строгая структура

Текущий стандарт DWP — 7.0.0, его реализует линейка навыка 7.x. Этот пакет по умолчанию использует v7 для каждого нового плана; явный запрос v6 по-прежнему материализует план v6. Существующие планы v1, v2, v5 и v6 сохраняют записанное поколение и никогда не мигрируются незаметно; перенос плана v5 на v6 требует явного запроса на миграцию.

v6 сохраняет ту же методологию «план → задачи → проверочные шлюзы → завершение», команды со слешем и расположение .dwp/plans/. Инженерная структура становится строже благодаря контракту, журналу, манифестам контекста для задач, планировщику и отказу при пустом списке разрешений. v7 сохраняет этот слой записей и добавляет необязательный маркер задачи parallel_safe, событие журнала delegation для ограниченной работы, переданной другому агенту, и реестр аддонов .dwp/config.json; если ни один аддон делегирования не включён, каждый план по-прежнему выполняется последовательно в текущей сессии. Архитектурное решение — GO; эмпирическое неухудшение результатов агентов не измерялось.