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

Розділ 03

Шаблони плану та завдань

Deep Work Plan — це каталог файлів markdown. Форма цього каталогу — і кожного файлу всередині нього — це те, що робить план придатним до рецензування і людьми, і агентами.

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

План — це каталог у .dwp/plans/ з назвою PLAN_001_<slug>/. Він містить:

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

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

Структура файлу завдання

Кожен файл завдання має назву <n>.task_<slug>.md і дотримується десятисекційної анатомії, докладно описаної в Базовому циклі. Секції завжди зʼявляються в цьому порядку, тож будь-який читач знає, куди дивитися. Кожне завдання заново привʼязується до мети плану, перш ніж діяти, що утримує агента від дрейфу на тривалому горизонті.

Final Review

Кожен план має завершуватися рівно одним обовʼязковим завданням: Final Review. Воно закриває план у пʼять упорядкованих етапів — у перевірці безпеки нічого не послаблено:

  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, номер і назву завдання, що було зроблено, та будь-які відхилення чи причини пропуску. Оскільки він лише зростає, він є надійною історією того, як план насправді розгортався.

Заголовки та перехресні посилання

Усі заголовки використовують регістр речення, а документи уникають маркетингової мови та знаків оклику. Ці домовленості тримають плани узгодженими між агентами та з плином часу.