diff --git a/docs/releases/v0.4.2/release-plan.md b/docs/releases/v0.4.2/release-plan.md
new file mode 100644
index 0000000..64058b4
--- /dev/null
+++ b/docs/releases/v0.4.2/release-plan.md
@@ -0,0 +1,50 @@
+# План релиза v0.4.2
+
+## Метаданные
+
+- Тег релиза: `v0.4.2`
+- Тип повышения версии: `patch`
+- Обоснование выбранной версии: совместимое дополнение документации — новая секция «Черновые коммиты» в `commits.md` и правило порядка «merge → удаление head-ветки» в `pull-request.md`; код валидатора и init-скрипта не менялся
+- База рабочей ветки: `master` (`2fa53e6`)
+- Рабочая ветка: `release/0.4.2`
+- PR подготовки релиза в основную ветку: [#15](https://github.com/prikotov/git-workflow/pull/15)
+- Ответственный: владелец проекта
+- Плановая дата публикации: 2026-09-24
+
+## Состав
+
+- Включённый PR: [#14](https://github.com/prikotov/git-workflow/pull/14)
+- Источник: задача калибровки конвейера сабагентов проекта-потребителя stocks2 ([PR #275](https://github.com/prikotov/stocks2/pull/275))
+- `commits.md`: секция «Черновые коммиты» — формат `chore(<scope>): wip <что сделано> / черновик <что сделано>`, явное исключение из повелительного наклонения для пометки, пример; черновой коммит делает сам исполнитель — целенаправленно, на атомарном и логически завершённом этапе
+- `pull-request.md`: в «Выполнение merge» — head-ветку удалять только после merge: удаление ветки до слияния автоматически закрывает PR
+
+## Риски
+
+- Проекты-потребители увидят новую секцию после повторного запуска `bin/git-workflow-init`; существующие локальные копии документации не перезаписываются автоматически — расхождение копий с пакетом возможно до переинициализации.
+- Изменения docs-only: на код валидатора, init-скрипт и CI не влияют.
+- Миграции данных и переменных окружения отсутствуют.
+
+## Порядок публикации
+
+1. Слить PR из `release/0.4.2` в `master` после успешного CI и одобрения.
+2. Проверить совпадение содержимого одобренной ветки и коммита слияния.
+3. Создать и отправить аннотированный тег `v0.4.2` на проверенный коммит слияния.
+4. Создать GitHub Release по существующему тегу.
+
+## Проверки перед публикацией
+
+- `composer validate --strict`
+- CI репозитория успешен
+- Проверка относительных Markdown-ссылок и `git diff --check`
+- Тег и ветка выпуска до начала подготовки свободны
+
+## Проверки после публикации
+
+- GitHub Release `v0.4.2` опубликован и указывает на ожидаемый SHA.
+- Composer VCS metadata видит тег `v0.4.2`.
+
+## Действия при проблеме после релиза
+
+- Откат не используется; опубликованный тег не изменяется.
+- Исправление выпускается новой patch-версией из тега `v0.4.2`.
+- Координация: GitHub Issue и задача в `todo/`.