Skip to content
← Все главы

Глава 03

Шаблоны плана и задач

Deep Work Plan — это каталог файлов Markdown. Форма этого каталога — и каждого файла внутри него — это то, что делает план пригодным для ревью и людьми, и агентами.

Структура плана

План — это каталог в .dwp/plans/ с именем PLAN_001_<slug>/. Он содержит:

  • manifest.json — идентификатор плана и указатель на его активный контракт, записывается первым при материализации.
  • contract.json — контракт спецификации и границы плана.
  • journal.ndjson — журнал событий только для добавления.
  • state.json — снимок, спроецированный из journal, никогда не редактируется вручную.
  • README.md — обзор плана: цель, таблица задач и статус.
  • PROGRESS.md — человекочитаемый хронологический журнал выполнения.
  • <n>.task_<slug>.md — файл спецификации из десяти разделов на задачу.
  • analysis_results/ — каталог для артефактов анализа, отчётов и логов проверок.

Текущий пакет 7.x по умолчанию создаёт планы v7 со slug из 2–5 слов, как и в v6. Сохранённый поток v5 использует 2–4 слова (так как его схема считает числовой ID одним словом). Новые планы получают монотонно возрастающие числовые ID длиной не менее трёх цифр (например, PLAN_001_add_payment_webhooks/). Существующие папки без номера PLAN_<slug>/ остаются доступными для чтения и никогда не переименовываются; никакие планы не мигрируют неявно. Если есть нумерованные планы, latest указывает на план с наибольшим числовым ID.

Структура файла задачи

Каждый файл задачи называется <n>.task_<slug>.md и следует десяти нормативным разделам установленного навыка (подробнее об анатомии задачи см. Основной цикл). Каждая задача перед действием заново привязывается к цели плана, что удерживает агента от отклонения на длинном многочасовом горизонте.

Final Review

Каждый план должен заканчиваться ровно одной обязательной задачей: Final Review. Она закрывает план пятью строго упорядоченными этапами — проверки безопасности и validation gates ни в коем случае не ослабляются:

  1. Проверка безопасности — аудит всего, что изменил план, на предмет секретов, рисков инъекций и новой поверхности атаки, обновление docs/SECURITY.md и запуск обязательного локального ревью AI Diff Reviewer по всему диапазону плана (отсутствие ревьюера фиксируется как замечание local reviewer not installed, а не пропускается молча). Критические находки блокируют завершение.
  2. Валидация финального состояния — полные наборы тестов, линтеров и проверки типов репозитория запускаются и проходят на финальном состоянии. Любые исправления инвалидируют затронутые результаты и требуют перезапуска.
  3. Сверка решений по навыкам — проверка того, что каждая задача зафиксировала локальное решение по навыкам, со сверкой кандидатов в analysis_results/SKILLS_CANDIDATES.md.
  4. Сверка документации — сопоставление затронутой поверхности каждой задачи, изменившей поведение, с документацией (docs/TESTING_GUIDE.md, архитектура, AGENTS.md), фиксирующей эту функциональность.
  5. Завершение — записи плана согласованы (список задач, журнал прогресса и в планах v6 и v7 снимок и квитанция, полученные из journal); отчет о результатах, доказательствах и ограничениях, и однократное предложение Executive Report.

Соглашения README и PROGRESS

README.md плана должен содержать заголовок (# Deep Work Plan: <name>), прозаическую формулировку цели, необязательный раздел исходных материалов, таблицу задач (номер, имя задачи, флажок статуса) и строку статуса плана в форме <n>/<total> tasks complete.

PROGRESS.md — это журнал выполнения, в который можно только добавлять. Каждая запись фиксирует временную метку в формате ISO 8601, номер и имя задачи, что было сделано, а также любые отклонения или причины пропуска. Поскольку он только растёт, он остаётся надёжной историей того, как план разворачивался в действительности.

Заголовки и перекрёстные ссылки

Все заголовки используют написание с заглавной только первого слова, а документы избегают маркетингового языка и восклицательных знаков. Эти соглашения сохраняют согласованность планов между агентами и во времени.