Базовий цикл

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

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

Операції

• create — Згенерувати новий план із мети. Агент аналізує мету, розкладає її на послідовні завдання та пише файли плану. Коли мета неоднозначна, перед написанням він має ставити уточнювальні запитання. У guided-режимі агент одразу матеріалізує Lite-план — компактну, вже виконувану пропозицію, — а розробник вирішує, залишити його, підвищити до Full-плану з файлами завдань, відредагувати чи зупинитися; у trust-режимі агент одразу матеріалізує обране представлення (Lite чи Full) без етапу перегляду. Обидва представлення описані в специфікації. Аналіз вимог і перевірка якості плану виконуються в будь-якому разі.
• 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 Title
2. 02 Context
3. 03 Read Before Starting
4. 04 Goal
5. 05 Touched Surface
6. 06 Instructions
7. 07 Acceptance Criteria
8. 08 Outputs
9. 09 Validation
10. 10 Execution Checklist + Completion & Log

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

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

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

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