diff --git a/.github/workflows/process.yml b/.github/workflows/process.yml
index 831de739..a080a149 100644
--- a/.github/workflows/process.yml
+++ b/.github/workflows/process.yml
@@ -230,6 +230,38 @@ jobs:
             Этап: ${{ needs.guard.outputs.stage }}
               spec — ревью ТЗ (PROCESS.md §2.4)
               code — код-ревью (PROCESS.md §2.7)
+            Цикл: r${{ needs.guard.outputs.cycle }}
+
+            **Если цикл не первый — объём разбора по дельте, а не заново**
+            (PROCESS.md §2.9, issue #214). Раньше промпт был одинаковым для
+            всех раундов, и повторный цикл заново выводил продуктовую рамку и
+            перепроверял AC, которых правка не касалась: r2 по #150 стоил
+            полного прогона ради одной строки в тестовой фикстуре.
+
+            Порядок для r2 и дальше:
+              1. найди вердикт предыдущего раунда в комментариях issue и SHA,
+                 на котором он получен. SHA в вердикте не назван — это находка;
+              2. объяви дельту: `git diff <тот SHA>..HEAD` для кода, дифф файла
+                 ТЗ или тела issue для spec. Дельта — предмет этого раунда;
+              3. по каждой находке предыдущего раунда покажи, чем именно она
+                 закрыта: строка кода или текста, а не заявление автора;
+              4. заново проверяй только те AC, чьё доказательство дельта
+                 задевает. Остальные наследуй;
+              5. в документе обязателен раздел «Унаследовано из r<N-1>»: что
+                 принято без повторной проверки, со ссылкой на документ того
+                 раунда и SHA, на котором вывод получен. Без этого перечня
+                 сокращение — молчаливое доверие, а такой тихий успех уже
+                 дважды стоил дня (#171, #207).
+
+            Разбор остаётся ПОЛНЫМ, если дельта не локальна: ребейз на ушедший
+            вперёд dev (после ребейза это другой код, §7.2), смена контракта
+            поведения, задета новая подсистема, либо объём дельты сопоставим с
+            исходной задачей. Сомневаешься — разбирай полностью и скажи почему.
+
+            Сокращается объём РАЗБОРА, а не строгость: правка по замечанию
+            способна сломать AC, который предыдущий раунд признал выполненным —
+            так появилась регрессия #102. Поэтому граница не «только находки», а
+            «находки плюс всё, до чего дотягивается дельта».
 
             Прочитай в этом порядке, прежде чем судить:
               1. docs/SCOPE.md — зачем продукт существует и для кого. Он
@@ -273,7 +305,8 @@ jobs:
             правке — не тщательность, а потеря времени: полные наборы это
             предрелизный гейт (PROCESS.md §8), а не гейт ревью.
 
-            Всегда, они дешёвые:
+            Всегда, они дешёвые, и в повторном раунде тоже: код изменился,
+            а стоят они минуты:
               `npx tsc --noEmit`, `npm test`, `npm run build` со сверкой трёх
               копий бандла.
 
@@ -318,7 +351,10 @@ jobs:
             docs/reviews/<SPEC|CODE>-REVIEW-${{ github.event.issue.number }}-r${{ needs.guard.outputs.cycle }}.md
             (SPEC для этапа spec, CODE для code): скоуп, как проверялось,
             находки с воспроизведением, что проверено и корректно, чего не
-            проверял. Каталог docs/reviews/ создай, если его нет. Больше не
+            проверял. Для r2 и дальше добавь два раздела: «Закрытие раунда
+            r<N-1>» — таблица «находка | чем закрыта | где это видно», и
+            «Унаследовано из r<N-1>» — что принято без повторной проверки, с
+            документом и SHA. Каталог docs/reviews/ создай, если его нет. Больше не
             пиши ничего: любой файл вне docs/reviews/ опубликован не будет.
 
             Затем оставь в issue краткий комментарий: вердикт, ключевые находки