diff --git a/stack/kubernetes/LEARNING.md b/stack/kubernetes/LEARNING.md
index 0c294a2..4ed01b4 100644
--- a/stack/kubernetes/LEARNING.md
+++ b/stack/kubernetes/LEARNING.md
@@ -6,7 +6,7 @@
 
 **Формат каждого модуля:** зачем это → теория-минимум → практика руками → самопроверка → как это в реальных проектах.
 
-**Окружение курса** (одно на все модули, то же, что в CASE.md): Windows + Docker Desktop, кластер `kind` с именем `lab`, 1 control-plane + 2 worker. Не пересоздавай кластер между модулями без необходимости — большинство модулей продолжают работать в одном и том же кластере и в одних и тех же namespace (`demo`, `monitoring`), это ближе к тому, как выглядит реальная работа с уже существующим кластером.
+**Окружение курса** (одно на все модули, то же, что в CASE.md): Windows + Docker Desktop, кластер `kind` с именем `lab`, 1 control-plane + 2 worker. Все команды курса — в bash-синтаксисе (heredoc, `base64 -d`, настоящий `curl`), поэтому выполнять их нужно в **Git Bash** (ставится вместе с Git for Windows), а не в PowerShell/cmd — там половина команд не сработает или сработает иначе (`curl` в PowerShell — алиас на `Invoke-WebRequest`). Docker Desktop стоит выделить не меньше 8 ГБ RAM — иначе стек мониторинга из модуля 12 повиснет в Pending. Не пересоздавай кластер между модулями без необходимости — большинство модулей продолжают работать в одном и том же кластере и в одних и тех же namespace (`demo`, `monitoring`), это ближе к тому, как выглядит реальная работа с уже существующим кластером.
 
 ---
 
@@ -60,20 +60,25 @@ helm version
 
 ```bash
 kind create cluster --name lab
-kubectl run demo --image=nginxdemos/hello --restart=Always
+# создаём под через Deployment — контроллер, который будет поддерживать desired state
+# (голый `kubectl run demo --image=...` создал бы под без контроллера — его никто бы не пересоздал)
+kubectl create deployment demo --image=nginxdemos/hello
 kubectl get pods
-# демо self-healing: убиваем под руками
-kubectl delete pod demo
+# демо self-healing: убиваем под руками (имя вида demo-<хэш> — взять из вывода выше)
+kubectl delete pod <имя-пода>
 kubectl get pods
-# NAME    ... — под пересоздан автоматически (другой RESTARTS/AGE), потому что desired state требует, чтобы под существовал
+# под пересоздан автоматически с новым именем, потому что desired state требует, чтобы существовала 1 реплика
+
+# уборка — дальше в курсе работаем в отдельном namespace
+kubectl delete deployment demo
 ```
 
 ### Самопроверка
 
 - Своими словами: что такое desired state и чем декларативный подход отличается от «выполнить команду»?
-- Почему после `kubectl delete pod demo` под появился снова?
+- Почему после `kubectl delete pod <имя>` под появился снова — и почему с другим именем?
 
-*(Забегая вперёд: на самом деле голый `kubectl run` пересоздаётся не всегда — это будет явно разобрано в модуле 4 про Deployment. Здесь цель — просто увидеть идею self-healing на практике.)*
+*(Забегая вперёд: пересоздал под не «Kubernetes вообще», а конкретный контроллер — Deployment. Голый под, созданный через `kubectl run`, не пересоздаст никто — за него никто не отвечает. Иерархия Deployment → ReplicaSet → Pod подробно разобрана в модуле 4; здесь цель — просто увидеть идею self-healing на практике.)*
 
 ### Как это в реальных проектах
 
@@ -195,7 +200,7 @@ kubectl -n demo delete pod demo-pod       # удалить
 
 ### Как это в реальных проектах
 
-Голые Pod'ы в проде почти никогда не создают напрямую (кроме короткоживущих задач) — если под упадёт, его никто не пересоздаст, потому что за него никто не отвечает (в отличие от модуля 1, где `kubectl run` создавал под через неявный контроллер). Правильный способ — через Deployment, это модуль 4.
+Голые Pod'ы в проде почти никогда не создают напрямую (кроме короткоживущих задач) — если под упадёт, его никто не пересоздаст, потому что за него никто не отвечает (в отличие от модуля 1, где под был создан через Deployment и контроллер его пересоздал). Правильный способ — через Deployment, это модуль 4.
 
 ---