Lite-плани

Версія 5.0.0. Статус: стабільний. Цей документ специфікує представлення Lite-плану, введене поряд зі Специфікацією DWP: формат плану для мало- та середньомасштабної обмеженої роботи, що матеріалізується одразу, без стадії невиконуваної чернетки. Ключові слова MUST, MUST NOT, SHOULD, SHOULD NOT та MAY тлумачаються згідно з RFC 2119.

Представлення та життєвий цикл

План MUST бути одним із двох представлень, зафіксованим один раз у manifest.json як plan_format: Full зберігає по одному файлу на завдання під <n>.task_<slug>.md; Lite зберігає компактні, виконувані записи завдань інлайн у README.md, кожен за стабільним якорем {#task-N}. Lite-план — це не частковий або неформальний Full-план: кожен запис завдання все одно MUST нести мету, Торкнуту поверхню, критерії приймання, validation gate та журнал завершення, у тій самій нормативній формі, яку Анатомія завдання визначає для Full.

Чотири осі описують стан плану, і MUST відстежуватися незалежно, а не змішуватися:

Вісь	Значення	Сенс
Format	`lite`, `full`	Де живуть записи завдань
Materialization	`materializing`, `ready`, `promoting`	Чи записується папка плану, чи завершена, чи триває підвищення
Approval	`pending`, `approved`, `pre_approved`	Чи перевірила людина план, чи trust-режим попередньо схвалив його
Execution	`pending`, `in_progress`, `blocked`, `completed`	Поза́вданнєвий та загальний прогрес

Guided create записує пропозицію, що очікує на рецензування — Lite чи Full, вже справжній план, ніколи не одноразова чернетка. Trust матеріалізує готовий, попередньо схвалений план і негайно повертає керування. create і підвищення ніколи не виконують продуктову роботу; явний запит execute або resume схвалює готову поточну область плану і MUST зафіксувати це схвалення перед початком роботи; без такого запиту pending-пропозиція не виконується; невирішене підвищення в процесі MUST спочатку відновлюватися перед продуктовою роботою.

Створення та вибір формату

/dwp-create обслуговує намір планування на будь-якому масштабі, а не лише для великої роботи. Невелика, обмежена робота — одна проблема, приблизно один сеанс, без координації — це ціль Lite-плану; багатокрокова робота з реальним обсягом за замовчуванням використовує Full, згідно з Пропорційною строгістю. Пряме редагування, пояснення, перевірка статусу, відновлення чи явний запит без плану зберігають свій власний маршрут і ніколи не стають планом.

lite і full є уподобаннями формату; trust і auto — окремі опції взаємодії, і будь-який вид опції MAY зʼявитися на будь-якому кінці запиту, у будь-якому порядку:

/dwp-create trust fix the label
/dwp-create lite trust fix the label
/dwp-create fix the label trust lite
/dwp-create fix the migration full trust

Повторення тієї самої опції ідемпотентне; запит lite і full разом є помилкою. -- завершує розбір опцій.

Коли уподобання формату не вказано, create рекомендує одне і пояснює чому. Явний запит Full завжди перемагає. Явний запит Lite задовольняється, якщо тільки вимоги роботи чи validation gates не вміщуються в компактні інлайн-записи — у цьому разі create фіксує, чому натомість потрібен Full. Вибір MUST фіксувати спостережений обсяг, залежності, потрібну деталізацію інструкцій та невідомі, що стоять за рішенням — перевірюване судження, а не гарантія, що тримається для будь-якої моделі чи агента.

Lite несе рішення про паралелізацію так само, як і Full: рядок Execution: sequential — {rationale} або розділ Team Agents Configuration, із метаданими Team Agents для кожного завдання, приєднаними безпосередньо до заякорених записів завдань замість окремого файлу завдання. Рішення ніколи не є мовчазним і в Lite — Lite-план заявляє його точно так само, як це зробив би Full-план.

Підвищення та сумісність

Lite-план MAY бути підвищений до Full у будь-який момент, через /dwp-refine promote {plan_name} (див. dwp-refine). Підвищення стосується лише представлення: воно фіксує намір, записує цільові файли завдань, перевіряє, що кожна вимога та gate, які несла Lite-запис, все ще покриті, перемикає авторитетну копію з інлайн-записів README на файли завдань, потім знімає маркер виконання в процесі. execute та resume MUST відмовлятися продовжувати, поки маркер підвищення залишається встановленим. ID завдань та вже зафіксовані докази завершення MUST NOT переписуватися підвищенням; новий обсяг, виявлений під час підвищення, натомість проходить через refine і анулює лише той доказ, на який він впливає.

Підвищення ніколи не виконується автоматично у зворотний бік: Full-план не згортається мовчки назад у Lite. План, створений за ранішою версією специфікації — включно з v1 Full-планом узагалі без поля plan_format — зберігає свою зафіксовану форму й залишається відповідним; сесія refine MAY свідомо його мігрувати, але ніщо не робить це неявно.

plan_format у manifest.json незмінний після запису; підвищення змінює format у state.json і знімає його маркер promotion, і ніколи не переписує маніфест. Див. Стан плану — точні поля plan_format, format, materialization, approval, promotion та locator, а також їхні URL схеми v2.