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`	Пер-задачный и общий прогресс

Управляемый 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.