docs: scope a repeat review round to the delta

The reviewer prompt was identical for every round, and the canon said
nothing about the scope of a repeat pass, so r2 re-derived the product
framing and re-checked acceptance criteria the fix never touched: the r2
pass on #150 cost a full pipeline run over one line in a test fixture.

From the second cycle on, the subject is the delta against the SHA the
previous verdict was given on: each earlier finding must be shown closed
by a line of code or text, only the criteria the delta can reach are
re-verified, and whatever is carried over is listed with the round and SHA
it came from. Cheap gates still run every round.

The scope shrinks, the strictness does not. A fix can break a criterion an
earlier round accepted — that is how regression #102 happened — so the
boundary is the findings plus everything the delta can reach, and a
non-local delta (a rebase onto a moved dev, a behaviour contract change, a
new subsystem) still gets the full pass.

Issue: #214
User-Visible: no

.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 краткий комментарий: вердикт, ключевые находки

PROCESS.md

@@ -138,7 +138,7 @@ S1-new → S2-analysis → S3-spec → S4-spec-review ⟲ → S5-ready →
   (решение владельца 2026-08-19, #202: отдельный issue дороже правки на месте).
   Low либо правится, либо снимается решением ревьюера с записью.
 - **Выход:** «Готово к разработке» либо возврат в «ТЗ в работе» — не более
-  4 циклов (§4).
+  4 циклов (§4). Второй и последующие циклы разбираются по дельте (§2.10).
 
 ### 2.5 Готово к разработке (DoR)
 
@@ -195,7 +195,7 @@ S1-new → S2-analysis → S3-spec → S4-spec-review ⟲ → S5-ready →
   без High это жёлтый вердикт и возврат автору, фикс проходит повторный цикл.
   Medium **вне скоупа** — отдельный issue (#202).
 - **Выход:** очередь на пре-релиз либо возврат в «В разработке», не более
-  4 циклов (§4).
+  4 циклов (§4). Второй и последующие циклы разбираются по дельте (§2.10).
 
 ### 2.8 Закрытие после выпуска беты
 
@@ -216,6 +216,42 @@ S1-new → S2-analysis → S3-spec → S4-spec-review ⟲ → S5-ready →
 - **Отклонено:** закрытие с записанной причиной (вне скоупа, дубликат, цена не
   оправдана). Тихое закрытие без причины запрещено.
 
+### 2.10 Повторный раунд ревью — объём по дельте
+
+Решение владельца 2026-08-19 (issue #214). Относится и к ревью ТЗ, и к
+код-ревью, начиная со второго цикла.
+
+**Предмет повторного раунда — дельта, а не задача целиком.** Раньше объём
+разбора не был оговорён, промпт ревьюера для всех раундов был одинаковым, и
+повторный цикл заново выводил продуктовую рамку и перепроверял AC, которых
+правка не касалась: r2 по #150 стоил полного прогона конвейера ради одной
+строки в тестовой фикстуре.
+
+Порядок:
+
+1. найти вердикт предыдущего раунда и **SHA, на котором он получен**; SHA в
+   вердикте не назван — это находка;
+2. объявить дельту: `git diff <тот SHA>..HEAD` для кода, дифф файла ТЗ либо тела
+   issue для этапа ТЗ;
+3. по каждой находке предыдущего раунда показать, **чем именно она закрыта** —
+   строкой кода или текста, а не заявлением автора;
+4. заново проверять только те AC, чьё доказательство дельта задевает;
+5. **раздел «Унаследовано из r<N−1>»** обязателен: что принято без повторной
+   проверки, со ссылкой на документ того раунда и SHA. Без перечня сокращение
+   превращается в молчаливое доверие.
+
+Дешёвые гейты (`typecheck`, `test`, `build` со сверкой копий бандла) гоняются в
+каждом раунде: код изменился, а стоят они минуты. Тяжёлые — по дельте (§10.2).
+
+**Разбор остаётся полным**, если дельта не локальна: ребейз на ушедший вперёд
+`dev` (после ребейза это другой код, §7.2), смена контракта поведения, задета
+новая подсистема, либо объём дельты сопоставим с исходной задачей.
+
+Сокращается объём **разбора, а не строгость**: правка по замечанию способна
+сломать AC, который предыдущий раунд признал выполненным — так появилась
+регрессия #102. Граница не «только находки», а «находки плюс всё, до чего
+дотягивается дельта».
+
 ---
 
 ## 3. Правила