Skip to content
← Усі розділи

Розділ 02

Базовий цикл

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

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

Операції

  • create — Згенерувати новий план із мети. Агент аналізує мету, розкладає її на послідовні завдання та пише файли плану. Коли мета неоднозначна, перед написанням він має ставити уточнювальні запитання. У guided-режимі агент одразу матеріалізує Lite-план — компактну, вже виконувану пропозицію, — а розробник вирішує, залишити його, підвищити до Full-плану з файлами завдань, відредагувати чи зупинитися; у trust-режимі агент одразу матеріалізує обране представлення (Lite чи Full) без етапу перегляду. Обидва представлення описані в специфікації. Аналіз вимог і перевірка якості плану виконуються в будь-якому разі.
  • execute — Виконати план завдання за завданням. Агент оновлює журнал прогресу після кожного завдання та позначає статус завершення завдання. Він не повинен пропускати завдання, не записавши причину.
  • refine — Змінити наявний план. Агент може додавати, видаляти чи переставляти завдання, але мусить зберігати завершену роботу та оновлювати таблицю завдань.
  • resume — Продовжити перерваний план. Агент читає журнал прогресу та файли завдань, щоб відновити стан, а потім продовжує з першого незавершеного завдання.
  • status — Відзвітувати про прогрес без виконання. Агент підсумовує завершені, поточні та очікувані завдання й нічого не змінює.
  • verify — Перевірити відповідність без жодних змін. Агент звітує, чи репозиторій відповідає стандарту й чи коректно сформований план — кожне завдання несе критерії приймання та валідаційний gate. Див. документ про відповідність у специфікації.
  • onboard — Введіть агента в репозиторій на основі міркувань, створивши AGENTS.md, посібники в docs/ та структуру .agents/.
  • upgrade — Оновіть harness репозиторію або наявні плани до новіших версій стандарту DWP.
  • author — Створюйте нові скіли, агентів або команди, узгоджені з конвенціями репозиторію, тримаючи каталог документації в синхронізації.

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

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

.dwp/
├── 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/
└── config.json

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

Десять секцій наведеної вище діаграми визначають анатомічну структуру кожного файлу завдання у Full-плані. Цей порядок гарантує, що кожна одиниця роботи повністю самодостатня, однозначна та придатна до незалежного аудиту:

  1. Мета — один абзац, що окреслює, чого досягає завдання.
  2. Контекст — передумови, посилання та чому це завдання існує.
  3. Зачеплена поверхня — що завдання змінює та клас ризику, який обирає її перевірку.
  4. Кроки — упорядковані, конкретні дії, які треба виконати.
  5. Критерії приймання — контрольний список умов, що визначають завершення.
  6. Валідація — команди чи тести, які треба запустити, щоб перевірити роботу.
  7. Файли — шляхи, які очікувано буде створено чи змінено.
  8. Залежності — інші завдання чи зовнішні передумови.
  9. Ризики — що може піти не так і як це помʼякшити.
  10. Завершення та журнал — маркер статусу плюс хронологічні нотатки.

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

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

v6 і v7: та сама методологія, суворіша структура

Поточний стандарт DWP — 7.0.0, його реалізує лінійка скіла 7.x. Цей пакет за замовчуванням створює кожен новий план у форматі v7; явний запит v6 і далі матеріалізує план v6. Наявні плани v1, v2, v5 і v6 зберігають зафіксоване покоління й ніколи не мігруються непомітно; перенесення плану v5 на v6 потребує явного запиту на міграцію.

v6 зберігає ту саму методологію план → завдання → шлюзи перевірки → завершення, slash-команди та розташування .dwp/plans/. Інженерна структура стає суворішою завдяки контракту, журналу, маніфестам контексту завдань, планувальнику та відхиленню порожнього списку дозволених можливостей. v7 зберігає цей шар записів і додає необовʼязковий маркер завдання parallel_safe, подію журналу delegation для обмеженої роботи, переданої іншому агенту, і реєстр аддонів .dwp/config.json; якщо жоден аддон делегування не ввімкнено, кожен план і далі виконується послідовно в поточній сесії. Архітектурне рішення — GO; емпіричну не-гіршість результатів агентів не вимірювали.