diff --git a/docs/stability-verification.md b/docs/stability-verification.md
index 79958e4..699cf6d 100644
--- a/docs/stability-verification.md
+++ b/docs/stability-verification.md
@@ -123,11 +123,21 @@ wait   # все замеры /ping должны быть заметно < 0.100
 
 ## План отката (rollback)
 
-Каждая стадия — отдельный, независимо ревертируемый коммит на своей ветке
-(`fix/stage-1-hangs` … `fix/stage-6-healthcheck`); порядок стадий = порядок деплоя.
+Единица отката — **стадия целиком**, не отдельный коммит. Каждая стадия живёт на своей
+ветке/PR (`fix/stage-1-hangs` … `fix/stage-7-verification`) и, как правило, состоит из
+**двух коммитов**: feature-коммит + фикс review-раунда (последний нередко чинит реальный
+баг — напр. fail-closed XSS в стадии 4, watchdog-gate в стадии 6). Поэтому `git revert`
+одного коммита осиротит фикс review-раунда и даст несогласованный откат. Откатывать нужно
+на гранулярности стадии; порядок стадий = порядок деплоя.
 
-- Стадии 1 и 2 — низкорисковые, деплоятся первыми; при регрессе откатываются по одной
-  (`git revert <commit>` соответствующей стадии) без затрагивания остальных.
+- **Как откатывать стадию** — зависит от того, как ветки влиты в `fix/stability`/`main`:
+  - если стадия влита **squash-merge** (один коммит на стадию) — `git revert <squash-commit>`
+    откатывает её целиком, однозначно;
+  - если стадия влита **merge-коммитом** — `git revert -m 1 <merge-commit>` откатывает весь
+    вклад ветки (оба коммита) разом;
+  - если история линейная (rebase/fast-forward) — реверт **всех** коммитов стадии
+    (`git revert <feature>..<review-fix>` включительно), а не одного.
+- Стадии 1 и 2 — низкорисковые, деплоятся первыми; откатываются независимо от остальных.
 - Стадия 3 (FileResponse) независима — реверт возвращает прежний ручной стриминг.
 - Стадия 4 требует, чтобы 4.2 откатывалась не позже 4.3 (иначе рендер-в-потоке остался бы
   без безопасного пути сохранения media id) — откатывать стадию 4 целиком.