Базовий цикл

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

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

Операції

• create — Згенерувати новий план із мети. Агент аналізує мету, розкладає її на послідовні завдання та пише файли плану. Коли мета неоднозначна, перед написанням він має ставити уточнювальні запитання.
• execute — Виконати план завдання за завданням. Агент оновлює журнал прогресу після кожного завдання та позначає статус завершення завдання. Він не повинен пропускати завдання, не записавши причину.
• refine — Змінити наявний план. Агент може додавати, видаляти чи переставляти завдання, але мусить зберігати завершену роботу та оновлювати таблицю завдань.
• resume — Продовжити перерваний план. Агент читає журнал прогресу та файли завдань, щоб відновити стан, а потім продовжує з першого незавершеного завдання.
• status — Відзвітувати про прогрес без виконання. Агент підсумовує завершені, поточні та очікувані завдання й нічого не змінює.
• verify — Перевірити відповідність без жодних змін. Агент звітує, чи репозиторій відповідає стандарту й чи коректно сформований план — кожне завдання несе критерії приймання та валідаційний gate. Див. документ про відповідність у специфікації.

Каталог виводу .dwp/

Усі артефакти DWP живуть у каталозі .dwp/ у gitignore в корені репозиторію. Тримання робочого простору поза контролем версій означає, що робочий стан плану ніколи не засмічує історію проєкту.

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

Девʼятисекційна анатомія завдання

Файл завдання

1. 01 Ціль
2. 02 Контекст
3. 03 Кроки
4. 04 Критерії приймання
5. 05 Перевірка
6. 06 Файли
7. 07 Залежності
8. 08 Ризики
9. 09 Завершення і журнал

Кожен файл завдання містить ці девʼять секцій по порядку. Структура гарантує, що кожна одиниця роботи самодостатня та придатна до рецензування:

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

Валідація, завершення та відновлення

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