режимы прогона: ревью параллельно, батч — по одной задаче

Умолчания разошлись по цене шага. Проход ревью читает и рассуждает: он
ничего не поднимает, ни за что не дерётся и по построению не видит
выводов соседа — очередь между проходами добавляет только ожидание.
Задача батча тянет полный цикл пайплайна с гейтом, поднятием сервиса и
вложенным ревью — две такие дерутся за порты, каталоги и железо.

review-pipeline: параллельно внутри стадии — умолчание. Последовательно —
по трём причинам с именем в отчёте: сказал оператор, проходы меряют,
машина занята. Просьба «последовательно» набора не требует. Меряющая пара
adversary + ops стала именованным исключением: она идёт по очереди
всегда, и общее «гони параллельно» этого не отменяет. Ранний выход
переехал на границу стадии.

task-batch: план собирается графом зависимостей и в умолчании
линеаризуется. Параллельно — по просьбе, и просьба разрешает ширину
графа, а не «всё разом»; потолок 2–3 и одиночная волна замеряющей задачи
сохранены как правила этого режима. Режим ревью внутри задачи выводится
из режима батча и называется в charter'е. Финальная сверка гонит
review-specs по capability параллельно.

DECISIONS 14 — с причиной; версия канона не меняется, канон этих скиллов
не описывает.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

av-dev-pipeline/skills/review-pipeline/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: review-pipeline
-description: Конвейер ревью изменения — детерминированный гейт, сверка с дельта-спеками в обе стороны, враждебные постановки и эксплуатационный постмортем, независимая реализация по триггеру, архитектура и обязательный триаж. Проходы гонятся последовательно; параллельно — только по явной просьбе и с явно названным набором. Проектная специфика приходит из документов канона av-dev-pm. Вызывается из task-pipeline (чекпоинты ревью), из task-batch (финальная сверка) и отдельно — профилем design на предложении ДО кода.
+description: Конвейер ревью изменения — детерминированный гейт, сверка с дельта-спеками в обе стороны, враждебные постановки и эксплуатационный постмортем, независимая реализация по триггеру, архитектура и обязательный триаж. Проходы внутри стадии гонятся параллельно; последовательно — по особой причине (меряющая пара, занятая машина) или по слову оператора. Проектная специфика приходит из документов канона av-dev-pm. Вызывается из task-pipeline (чекпоинты ревью), из task-batch (финальная сверка) и отдельно — профилем design на предложении ДО кода.
 ---
 
 # Конвейер ревью
@@ -183,44 +183,42 @@ description: Конвейер ревью изменения — детермин
 
 | Режим | Как | Когда |
 |---|---|---|
-| **последовательно** (умолчание) | по одному, следующий стартует после отчёта предыдущего | всегда, пока не попросили иначе |
-| **параллельно** | названные проходы — одним сообщением | только по явной просьбе **и** с явно названным набором |
+| **параллельно** (умолчание) | проходы стадии — одним сообщением | всегда, пока не сработала особая причина |
+| **последовательно** | по одному, следующий стартует после отчёта предыдущего | по слову оператора **или** по одной из особых причин ниже |
 
-**Умолчание — последовательно, и его не надо обосновывать.** Обосновывается
-отступление.
+**Умолчание — параллельно, и его не надо обосновывать.** Обосновывается
+отступление. Проходы независимы по построению: ни один не видит выводов другого
+(см. ниже), у всех общий вход и разные критерии. Очередь между ними не добавляет
+ничего, кроме ожидания, — а ожидание на каждом чекпоинте ревью платится каждой
+задачей.
 
-**Параллельный режим включается при двух условиях сразу**, и второе так же
-обязательно, как первое:
+**Последовательно гоним в трёх случаях, и каждый называется в отчёте:**
 
-1. **о нём попросили явно** — «гони параллельно», а не «сделай побыстрее»;
-2. **названо, что именно гнать параллельно** — поимённый набор проходов
-   («`specs` и `code` параллельно») или стадия целиком («стадию 1 параллельно»).
+1. **сказал оператор** — «гони последовательно». Набор при этом называть не
+   обязательно: последовательный прогон ничего не портит, он только дольше, и
+   домысливать тут нечего;
+2. **проходы меряют.** `adversary` и `ops` доказывают находки числами: время
+   удержания блокировки против её таймаута, пик кучи против размера тела, темп
+   роста файлов журнала, длительность транзакции. Два меряющих прохода на одной
+   машине соревнуются за диск, CPU и за саму СУБД и выдают числа, которые не
+   воспроизведутся. Это не гипотеза: правило выведено из находок, целиком
+   державшихся на таких замерах, — у каждого проекта они свои и лежат в журнале
+   `docs/review.md`. Число, снятое под конкурентную нагрузку от соседнего
+   прохода, — это находка с испорченным оракулом, а её опровержение стоит дороже
+   всего выигрыша от параллельности. **Эта пара идёт по очереди всегда** — это
+   правило стадии 2, а не решение прогона (см. её раздел);
+3. **машина занята, и знает об этом вызывающий.** Рядом идёт другая задача,
+   поднят сервис, гоняется гейт или дорогая проверка проекта. Сам конвейер
+   занятости машины не видит — её обязан назвать тот, кто запускает; так и
+   делает `av-dev-pipeline:task-batch`, когда ведёт задачи параллельно.
 
-Просьба без набора — **не основание**: гоним последовательно и одной строкой
-говорим, что набор не был назван. Это не придирка к формулировке. Параллелить
-можно ровно то, что не мешает друг другу, а знание об этом лежит у того, кто
-просит: он видит, занята ли машина, и ждёт ли он от прогона замеров. Домысливать
-набор за него — значит принять решение, которое он оставил себе.
+Отдельная причина, не связанная со стоимостью, — **разбор самого конвейера**:
+когда выясняется, почему проход чего-то не нашёл, порядок и изоляция важнее
+скорости.
 
-Почему умолчание именно такое:
-
-- **Замеры.** Проходы `adversary` и `ops` доказывают находки числами: время
-  удержания блокировки против её таймаута, пик кучи против размера тела, темп
-  роста файлов журнала, длительность транзакции. Два меряющих прохода на одной
-  машине соревнуются за диск, CPU и за саму СУБД и выдают числа, которые не
-  воспроизведутся. Это не гипотеза: правило выведено из находок, целиком
-  державшихся на таких замерах, — у каждого проекта они свои и лежат в журнале
-  `docs/review.md`. Число, снятое под конкурентную нагрузку от соседнего
-  прохода, — это находка с испорченным оракулом, а её опровержение стоит дороже
-  всего выигрыша от параллельности.
-- **Машина одна.** Рядом идёт задача, поднят сервис, гоняется гейт или дорогая
-  проверка проекта.
-- **Ранний выход** возможен только при последовательном прогоне (см. ниже).
-- **Разбор самого конвейера.** Когда выясняется, почему проход чего-то не нашёл,
-  порядок и изоляция важнее скорости.
-
-Если параллельный режим всё же включён, в границы покрытия идёт строка: какие
-проходы шли разом и что замеры, снятые в этом прогоне, как оракул слабее.
+Если меряющие проходы всё же пошли разом — а это бывает только по прямому слову
+оператора, — в границы покрытия идёт строка: какие проходы шли одновременно и
+что замеры этого прогона как оракул слабее.
 
 **Чего режим не меняет — и это не подлежит обсуждению.** Проход **не видит**
 находок других проходов ни в каком режиме. «Последовательно» значит «по
@@ -231,15 +229,17 @@ description: Конвейер ревью изменения — детермин
 маскируется под независимое подтверждение. Единственный, кто видит всё, — триаж,
 и это его работа.
 
-**Ранний выход** (последовательный режим делает его возможным — это его побочная
-выгода, а не повод его выбирать). Допустимо остановить прогон, не докатив
-остаток, ровно в одном случае: находка требует **переделки формы** изменения, и
+**Ранний выход — по границе стадии.** Стадии идут по порядку в любом режиме,
+поэтому остановиться между ними можно всегда; последовательный режим добавляет к
+этому возможность остановиться **внутри** стадии — это его побочная выгода, а не
+повод его выбирать. Допустимо остановить прогон, не докатив остаток, ровно в
+одном случае: находка требует **переделки формы** изменения, и
 остальные проходы будут смотреть на код, которого через час не станет. Тогда:
 
 - прогон останавливается, находка чинится, конвейер запускается **заново с
   нулевой стадии** — а не «доезжает» остатком по старому коду;
 - незапущенные проходы идут в границы покрытия строкой «не запускался: прогон
-  остановлен на <проход> из-за <находка>», поимённо;
+  остановлен на <проход или стадия> из-за <находка>», поимённо;
 - триаж запускается только на полном прогоне. Отчёт триажа по половине проходов
   выглядит полным, потому что агрегирует всё, что ему подали, — это тот же
   молчащий пропуск, что и в разделе «Профили».
@@ -248,8 +248,9 @@ description: Конвейер ревью изменения — детермин
 (`Действие: инлайн`), **не делается**: дешевле дособрать все находки и починить
 пачкой, чем гонять конвейер дважды.
 
-Режим объявляется в отчёте наравне с профилем, и если он **параллельный** — с
-причиной и составом. Последовательный объявляется одним словом.
+Режим объявляется в отчёте наравне с профилем. Параллельный — одним словом.
+**Последовательный — с причиной** (какой именно из трёх) и с составом, если по
+очереди шла только часть проходов.
 
 ## Стадия 0 — Gate (обязательна во всех профилях)
 
@@ -275,8 +276,8 @@ description: Конвейер ревью изменения — детермин
 ## Стадия 1 — Conformance (обязательна во всех профилях)
 
 Два applicative-прохода: оба применяют **записанный** критерий, оба дешёвые.
-Замеров они не делают и потому безобиднее прочих, если параллельный режим
-попросят с их именами; сами по себе идут по очереди, как и все.
+Замеров они не делают и не мешают друг другу ничем — это канонический случай
+умолчания: оба уходят одним сообщением.
 
 - `review-specs` — критерий взят из **дельта-спек предлагаемого изменения**, а не
   из proposal, сообщения коммита или описания задачи. Сверка двунаправленная;
@@ -296,11 +297,13 @@ Recall обоих равен длине их источника — это и е
 - `review-adversary` — находка есть **построенный путь**, а не свойство;
 - `review-ops` — постмортем от симптома у владельца сервиса к строке кода.
 
-**Эту пару параллелить не стоит даже по просьбе — переспроси.** Оба доказывают
-находки замером, и оба меряют одно и то же железо. Запущенные разом, они портят
-числа друг другу, а испорченный оракул хуже отсутствующего: находка выглядит
-доказанной. Если их всё же назвали в параллельном наборе — выполняй, но скажи в
-границах покрытия, что числа этого прогона сняты под соседней нагрузкой.
+**Эта пара — именованное исключение из умолчания: она идёт по очереди всегда.**
+Оба доказывают находки замером, и оба меряют одно и то же железо. Запущенные
+разом, они портят числа друг другу, а испорченный оракул хуже отсутствующего:
+находка выглядит доказанной. Очередь здесь не обосновывается — она правило
+стадии, и на общее «гони параллельно» не отменяется. Если оператор прямо велел
+гнать разом **и эту пару** — выполняй, но скажи в границах покрытия, что числа
+этого прогона сняты под соседней нагрузкой.
 
 **Эта стадия зарабатывает больше всех остальных вместе, и потому стоит в
 `standard`, а не только в `deep`.** Измерено на пяти задачах подряд: враждебный

av-dev-pipeline/skills/review-pipeline/references/review-journal.md

@@ -98,9 +98,8 @@
 - **готовые оракулы** — выборка по пометке `пойман ревью`: находка того же
   класса подтверждается ссылкой на запись, а не рассуждением;
 - **основание для правил конвейера** — требование называть запущенные проходы
-  поимённо, отказ от чисел, производных от размера корпуса, и правило
-  последовательного прогона выведены из конкретных записей, а не из общих
-  соображений;
+  поимённо, отказ от чисел, производных от размера корпуса, и правило очереди для
+  меряющих проходов выведены из конкретных записей, а не из общих соображений;
 - **счётчик обратимости решений** — сузили состав проходов и через месяц поймали
   дефект ровно того класса, который перестали проверять: решение пересматривается
   фактом, а не спором.