diff --git a/PROCESS.md b/PROCESS.md
index 68b7ede6..40252f7e 100644
--- a/PROCESS.md
+++ b/PROCESS.md
@@ -813,6 +813,28 @@ S7-code-review → код-ревью → слияние в dev → S8-merged л
 никто не может выйти и о котором никто не узнает, для конвейера хуже громкой
 ошибки.
 
+**Ветка приводится к `dev` до ревью, а не после** (#257). Раньше ревью читало ветку
+как есть, а слияние делало ребейз — проверенный SHA и слитый SHA были разными
+коммитами. Пока расхождение с `dev` текстовое, ребейз упирается в конфликт и это
+видно; смысловое расхождение git склеивает молча, и в `dev` уезжает комбинация,
+которую ревьюер не читал. Именно так пришёл регресс #234. Шаг перед ревью делает
+одно из трёх:
+
+- ветка уже содержит весь `dev` — ничего;
+- отстала и ребейзится чисто — ребейз, `push --force-with-lease`, ревью по
+  приведённому состоянию. Факт ребейза передаётся в промпт, чтобы сработало
+  правило §7.2 о полном разборе вместо дельты;
+- конфликт — возврат в `S6-in-progress` **до** запуска ревью. Цикл при этом не
+  расходуется: код никто не читал, вердикта нет.
+
+Проверка стоит до ревью не только ради совпадения SHA. Конфликт всё равно вернул бы
+задачу, но обнаруживался он после сорока пяти минут работы ревьюера и потраченных
+лимитов подписки, хотя виден за пять секунд до них.
+
+`--force-with-lease` здесь обязателен с явным ожидаемым значением: между чтением
+ветки и пушем автор мог запушить коммит, и слепой `--force` потерял бы его молча.
+Расхождение lease — падение прогона, а не предупреждение.
+
 Поэтому зелёное код-ревью с неудавшимся слиянием ведёт не в `S8-merged`, а в
 `S6-in-progress`: работа действительно вернулась к автору, только осталась не
 правка кода, а ребейз. Вердикт при этом в силе, переделывать нечего. После ребейза