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

Глава 02

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

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

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

Операции

  • create — создаёт новый план из цели. Агент анализирует цель, раскладывает её на последовательные задачи и пишет файлы плана. При неоднозначной цели ему следует задать уточняющие вопросы до того, как писать.
  • execute — выполняет план задача за задачей. Агент обновляет журнал прогресса после каждой задачи и отмечает статус её завершения. Он не должен пропускать задачи, не зафиксировав причину.
  • refine — изменяет существующий план. Агент может добавлять, удалять или переупорядочивать задачи, но обязан сохранить завершённую работу и обновить таблицу задач.
  • resume — продолжает прерванный план. Агент читает журнал прогресса и файлы задач, чтобы восстановить состояние, затем продолжает с первой незавершённой задачи.
  • status — отчитывается о прогрессе без выполнения. Агент резюмирует завершённые, выполняемые и ожидающие задачи и ничего не меняет.
  • verify — проверяет соответствие, ничего не меняя. Агент сообщает, отвечает ли репозиторий стандарту и хорошо ли сформирован план — несёт ли каждая задача критерии приёмки и validation gate. См. документ о соответствии в спецификации.

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

Все артефакты DWP живут в игнорируемом git-ом каталоге .dwp/ в корне репозитория. Держа рабочее пространство вне контроля версий, вы добиваетесь того, что рабочее состояние плана никогда не засоряет историю проекта.

.dwp/
├── plans/
│   └── PLAN_<slug>/
│       ├── README.md
│       ├── PROGRESS.md
│       └── <n>.task_<slug>.md
└── config.yaml

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

Каждый файл задачи содержит эти девять разделов по порядку. Структура гарантирует, что каждая единица работы самодостаточна и пригодна для ревью:

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

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

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