ступень ревью поднимает проход, а не риск

Полный набор гонялся чаще, чем оправдано, и размер задач тут вторая причина,
не первая. Первая — триггеры: миграция схемы, публичный контракт и инвариант
поднимали ступень, не добавляя ни одного прохода. Миграцию гоняет gate шагом
миграций и разбирает ops, контракт сверяет specs направлением code→spec,
инвариант даёт основание для critical любому проходу — все трое уже в
standard. На проекте с базой и эндпоинтами верхняя ступень оказывалась не
исключением, а умолчанием: правило объявляло исключением то, что происходит
всегда.

Теперь ступень поднимает то, что даёт работу новому проходу. wide означает
ровно одно — изменение вводит новое понятие или структурную единицу; добавить
поле в существующий ответ это не концепт. standard стал рабочим умолчанием.
Проект, где изменение контракта и правда архитектурное, поднимает его сам в
docs/review.md — уточнением, а не возвратом прежнего умолчания.

Чекпоинт design получил то же условие: specs идёт всегда, rubric и
architecture — только при новом понятии. Он стоит на каждой задаче, поэтому
при мелкой нарезке три прохода умножаются на число задач.

Со стороны задач — шов нарезки: тест декомпозиции отвечает, допустим ли
разрез, шов отвечает, где его провести. Резать по границе, за которой падает
ступень; не резать, когда обе половины остаются в одной — костяк из четырёх
проходов платится за каждую задачу, и такой разрез делает ревью дороже.
Порога в числе границ нет по тому же принципу, что в теме 16: размер не
триггер. Дешёвое место заметить разнородную задачу — показ набора спринта,
там «Затрагивает» уже написан, а предложение ещё не заведено.

Правило выведено из состава проходов, а не из статистики прогонов — замер
остаётся за обкаткой. DECISIONS 18, RRR–WWW и следствия 72–75; JJJ темы 17
помечен как пересмотренный. Шаг про «Триггеры профиля» дописан в ещё не
выкаченную версию 3 канона, а не отдельной версией.

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

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

@@ -219,14 +219,19 @@ flowchart TD
 ### 4. (Нетривиальная) Ревью предложения — профиль `design`, ДО кода
 
 Первый чекпоинт. Вызови Skill **`av-dev-pipeline:review-pipeline`** с профилем
-`design` и ссылкой на change `<id>`. Он запустит `review-specs`
-(режим «дизайн ДО кода»), `review-rubric` (фаза 1: приёмочные критерии для
-задуманного узла) и `review-architecture` по предложению.
+`design` и ссылкой на change `<id>`.
+
+**Состав чекпоинта решает конвейер, а не ты**: `review-specs` в режиме «дизайн ДО
+кода» идёт всегда, а `review-rubric` и `review-architecture` — только когда
+изменение вводит новое понятие или структурную единицу (то же условие, что у
+ступени `wide`). Причина в том, что чекпоинт стоит на **каждой** задаче: при
+мелкой нарезке три прохода здесь умножаются на число задач и становятся самой
+большой статьёй конвейера.
 
 Смысл профиля: архитектурная находка на готовом коде стоит переписывания и
-потому игнорируется — та же находка здесь стоит абзаца обсуждения. Рубрику из
-`review-rubric` перенеси в `tasks.md` как приёмочные критерии; там же уже лежат
-критерии от постановки, если они были.
+потому игнорируется — та же находка здесь стоит абзаца обсуждения. Если
+`review-rubric` запускался, перенеси его рубрику в `tasks.md` как приёмочные
+критерии; там же уже лежат критерии от постановки, если они были.
 
 ### 5. Отработать замечания ревью предложения