профили ревью: тяжёлые проходы в верхнюю ступень, на умолчании — один базовый

Тема 33 сняла самую большую разовую статью расхода, но не тронула главную —
частоту. Меряющая пара стояла в standard, то есть на большинстве задач, и именно
она делала прогон долгим: два прохода держат машину, идут цепочкой и доказывают
находки запуском. Цель разбора названа прямо: лучше поправить в следующей задаче,
чем держать одну два часа.

adversary и ops переехали в wide. Стадия осталась самой урожайной за всю историю
замеров — пять из семи выживших находок дозапуска и единственная находка про
молчаливый старт отката, — но её ценность оплачивается на каждой задаче, а
получается на немногих. Решение по цене, не по ценности.

Заведён review-basics: мелкая осадка двух тяжёлых проходов, без единого запуска.
Стоит только в standard. Восемь вопросов, на которые отвечают чтением: таймаут и
отказ соседа, идемпотентность и одновременная запись, остановка на середине,
частичный откат при двух версиях, наблюдаемость и тишина, очевидный рост объёма,
второй способ мимо единой точки (грепом, не картой), что отсюда удалить. Потолок
4 находки, машину не держит, ничего не меряет.

Вопрос про частичный откат — не для полноты списка. Без него правило «миграция
схемы не поднимает ступень» рассыпалось бы: раньше миграцию разбирал ops, а он
теперь наверху. Проход заведён затем, чтобы у standard остался хоть один взгляд
на ось времени.

Модель у него верхняя, opus, и это не спорит со словом «средний»: усилие режется
входом и потолком, а не моделью. Дешёвая модель на опиниативном проходе платит
триажем — это записанный замер, отменять его без нового замера нечем.

Лестница вышла 4/5/7. Главный выигрыш не в числе проходов, а в том, что из
standard ушла цепочка: теперь там гейт, три прохода одним сообщением и триаж —
граф плоский, ждать некому.

Правило выбора ступени переписано на два вопроса, и объём изменения вошёл в него
впервые. Крупное или незнакомое — трогает несколько узлов, переносит
ответственность, форму решения нащупывают по ходу — это wide, и он рассчитан на
5-10% задач. Мелкое — один узел, форма очевидна заранее, откат сводится к
обратной правке — quick. Всё остальное standard, рабочее умолчание. Раньше
ступень выбиралась только по классу изменения и на размер смотреть запрещала;
теперь признаков два: класс отвечает за обратимость, объём — за цену
разбирательства.

Отрицательный тест сохранил прежнюю мудрость в новой рамке: что после мерджа не
откатывается обратной правкой — не quick, каким бы маленьким ни был дифф. Три
строки миграции идут в standard.

Спорный случай решается вниз, и асимметрия объяснена ценой: ошибка в сторону
standard стоит находки на следующей задаче, ошибка в обратную — трёх тяжёлых
проходов на каждой задаче, выбранной неверно.

Сделка записана вместе с обратной связью, иначе это тихая потеря качества. На
quick и standard не проверяется ничего, что требует запуска: построенный путь,
эксперимент против драйвера, любое число. Это самая крупная граница покрытия
конвейера, и она идёт строкой в каждом таком прогоне поимённо. Сигналов о том,
что ступень занижена, два: журнал дефектов в docs/review.md и сам basics —
он единственный, кто смотрит на дифф целиком на нижних ступенях, и обязан
сказать строкой, если задача выглядит крупнее профиля.

Побочно: условие профиля design то же самое, так что rubric и architecture на
предложении тоже упали до 5-10% задач.

Тема 34 в DECISIONS.md, следствия 130-133. Версия канона не поднята; инструкция
проекту дописана в пункт 8 записи «Версия 4».

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: "Конвейер ревью изменения — детерминированный гейт, сверка с дельта-спеками в обе стороны, враждебные постановки и эксплуатационный постмортем, архитектурный проход и обязательный триаж. Три ступени стоимости: quick, standard, wide. Порядок прогона — граф зависимостей, а не очередь: гейт открывает опиниативные проходы, проходы с пометкой «держит машину» идут цепочкой, триаж — единственный сток. Линейный прогон — по слову оператора или на занятой машине. Проектная специфика приходит из документов канона av-dev-pm. Вызывается из task-pipeline (чекпоинты ревью), из task-batch (финальная сверка) и отдельно — профилем design на предложении ДО кода."
+description: "Конвейер ревью изменения — детерминированный гейт, сверка с дельта-спеками в обе стороны, базовый проход на отказы и лишнее, а в верхнем профиле враждебные постановки, эксплуатационный постмортем и архитектурный проход; триаж обязателен всегда. Три ступени стоимости: quick (4 прохода), standard (5, рабочее умолчание), wide (7, только крупное или незнакомое — 5-10% задач). Ступень выбирается по объёму и незнакомости изменения, спорный случай решается вниз. Порядок прогона — граф зависимостей, а не очередь: гейт открывает опиниативные проходы, проходы с пометкой «держит машину» идут цепочкой, триаж — единственный сток. Линейный прогон — по слову оператора или на занятой машине. Проектная специфика приходит из документов канона av-dev-pm. Вызывается из task-pipeline (чекпоинты ревью), из task-batch (финальная сверка) и отдельно — профилем design на предложении ДО кода."
 ---
 
 # Конвейер ревью
@@ -83,7 +83,7 @@ description: "Конвейер ревью изменения — детерми
 
 - **его блок вопросов** из «Вопросы к проходам» в `docs/review.md`, если он там
   есть, — **дословно**. Блок адресован проходу поимённо и выведен из промаха
-  этого проекта; заставлять восемь charter'ов самим ходить за ним значит
+  этого проекта; заставлять девять charter'ов самим ходить за ним значит
   получить, что за ним ходят двое. Проход отвечает на такие вопросы явно,
   дополнительно к обязательным;
 - **контракт находок** — путь к
@@ -106,7 +106,7 @@ description: "Конвейер ревью изменения — детерми
 | Модель | Цвет | Проходы | Почему |
 |---|---|---|---|
 | `sonnet` | green | gate, code, ops | вход структурный, критерий записан заранее |
-| `opus` | yellow | specs, adversary, rubric, architecture, triage | суждение без опоры на инструмент |
+| `opus` | yellow | specs, adversary, rubric, basics, architecture, triage | суждение без опоры на инструмент |
 
 **Цвет charter'а кодирует модель, а не роль прохода.** Это единственное
 назначение цвета: список агентов читается взглядом, и по нему сразу видно, чем
@@ -122,16 +122,16 @@ charter'а, а модель потом двигает калибровка, и
 модели **дороже** `opus` не обнаружилось ни на одном проходе, а прогон на ней
 стоил заметно дольше и дороже — значит платить за неё не за что.
 
-Двое из пяти держатся на `opus` по признаку, отдельному от суждения: **их ошибка
+Двое из шести держатся на `opus` по признаку, отдельному от суждения: **их ошибка
 распространяется дальше собственной находки.** Понижать их до `sonnet` вместе с
 остальными дешёвыми проходами нельзя.
 
 - `triage` — через него проходит всё, что оркестратор реализует **молча**:
   ложноположительная находка становится кодом, потерянный `critical` — дефектом.
   Ошибка триажа дороже ошибки любого отдельного прохода.
-- `architecture` — запускается только там, где изменение вводит новое понятие,
-  потолок в 3 находки делает его дешёвым по выходу, а находка на предложении
-  стоит абзаца против переписывания на готовом коде. Дёшево × высокое плечо.
+- `architecture` — запускается только в верхней ступени, на 5–10% задач, потолок
+  в 3 находки делает его дешёвым по выходу, а находка на предложении стоит абзаца
+  против переписывания на готовом коде. Дёшево × высокое плечо.
 
 **Самая дешёвая модель не используется ни на одном проходе, и это не экономия
 наоборот.** Дешёвая модель на опиниативном проходе даёт правдоподобные находки,
@@ -141,23 +141,36 @@ charter'а, а модель потом двигает калибровка, и
 Дешёвому проходу просто не осталось работы.
 
 Экономия достигается не понижением модели, а **непуском прохода**: `quick` —
-четыре прохода, `wide` — семь. Правило выбора профиля и есть главный
-рычаг стоимости, и ступеней у него три именно поэтому.
+четыре прохода, `standard` — пять, `wide` — семь. Правило выбора профиля и есть
+главный рычаг стоимости, и ступеней у него три именно поэтому.
+
+Второй рычаг, помимо непуска, — **вход и потолок прохода**, и он же объясняет
+`basics` на `opus`. «Проход среднего усилия» тут значит не дешёвую модель, а
+узкий вход (дифф и его окрестности, без карты проекта) и жёсткий потолок находок.
+Прогон он ускоряет тем, чего **не** делает: ничего не запускает, ничего не меряет,
+машину не держит — а именно замеры и цепочка меряющих проходов и составляли те
+самые долгие часы.
 
 ## Профили
 
-| Профиль | Когда | Стадии | Проходов |
-|---|---|---|---|
-| `quick` | багфикс, локальная правка, доки | 0, 1, 4 | 4 |
-| `standard` | **рабочее умолчание**: поведение, миграция схемы, публичный контракт, инвариант | 0, 1, 2, 4 | 6 |
-| `wide` | изменение вводит новое понятие или структурную единицу | 0, 1, 2, 3, 4 | 7 |
-| `design` | **до кода**, на предложении | specs, плюс rubric и architecture по условию `wide` | 1–3 |
+| Профиль | Когда | Стадии | Проходов | Доля задач |
+|---|---|---|---|---|
+| `quick` | мелкое: багфикс, мелкая фича, локальная правка, доки | 0, 1, 4 | 4 | много |
+| `standard` | **рабочее умолчание**: всё, что не мелкое и не крупное | 0, 1, 2, 4 | 5 | большинство |
+| `wide` | крупное или незнакомое: большой рефакторинг, функциональность, форму которой ещё предстоит нащупать | 0, 1, 3, 4 | 7 | **5–10%** |
+| `design` | **до кода**, на предложении | specs, плюс rubric и architecture по условию `wide` | 1–3 | — |
 
-**`wide` назван по тому, что он добавляет: вход шире диффа.** Единственное его
-отличие от `standard` — архитектурный проход, а тот и получает дерево пакетов,
-граф зависимостей и инвентарь понятий вместо одного диффа. Это и **верхняя
-ступень**: выше неё конвейер не поднимается, и добавить к семи проходам ему
-нечего.
+**`wide` назван по тому, что он добавляет: вход шире диффа.** Он единственный, где
+живут тяжёлые проходы — враждебный, эксплуатационный и архитектурный, — и
+единственный, где что-то **запускается и меряется**. Отсюда и его доля: три прохода
+на стадии 3, два из них держат машину и потому идут цепочкой, а не разом. Это и
+есть те самые долгие часы, и платить их каждой задаче не за что.
+
+**Доля 5–10% — не пожелание, а проверка правила.** Она не считается механически, но
+читается по журналу: если `wide` уходит каждая третья задача, ступень выбирают по
+ощущению важности, а не по факту изменения. Обратный перекос виден иначе — по
+журналу проскочивших дефектов в `docs/review.md`: класс, который ловят только
+меряющие проходы, начинает всплывать после мерджа.
 
 **Состав сверяется по этой таблице до коммита.** Реестр из трёх-семи проходов
 проверяется взглядом — и это единственная защита от промаха, который уже
@@ -168,49 +181,70 @@ charter'а, а модель потом двигает калибровка, и
 границы покрытия, а не отсутствует. Цена молчащего пропуска измерена: семь
 находок и отдельная задача на их дозакрытие.
 
-Правило выбора профиля — **по факту изменения, не по ощущению важности**:
+Правило выбора — **два вопроса по факту изменения, не по ощущению важности**.
+Отвечать по порядку, первый подошедший ответ и есть профиль:
 
-- изменение вводит **новое понятие или структурную единицу**: новый пакет
-  или слой, новая точка входа, второй способ делать то, что уже делается, перенос
-  ответственности между узлами → `wide`;
-- иначе меняется поведение, видимое снаружи, трогается схема, публичный контракт
-  или инвариант проекта → `standard`;
-- иначе → `quick`.
+1. **Изменение крупное или незнакомое?** → `wide`. Крупное — трогает несколько
+   узлов или слоёв разом, переносит ответственность между ними, перекладывает
+   существующий код в новую форму (большой рефакторинг). Незнакомое —
+   функциональность, которой в проекте ещё не было, и **форму решения предстоит
+   нащупать по ходу**, а не выбрать до начала. Признак незнакомого простой: перед
+   работой нельзя назвать, какие узлы будут тронуты.
+2. **Изменение мелкое?** → `quick`. Мелкое — помещается в один узел, форма
+   решения очевидна до начала работы, а откат сводится к обратной правке. Сюда
+   идут мелкий багфикс, мелкая фича, правка текста и документации.
+3. **Всё остальное** → `standard`. Это рабочее умолчание, и оно должно набирать
+   большинство задач.
 
-**Ступень поднимает то, что даёт работу новому проходу, а не то, что кажется
-рискованным.** Это правило вывода, по которому спорные случаи решаются без нового
-списка: спроси, какому проходу изменение даёт работу, которой у него не было
-ступенью ниже.
+**Два признака смотрят на разное, и в этом весь смысл двух вопросов.** Первый —
+про **объём и неизвестность**: сколько мест трогается и знаем ли мы форму решения
+заранее. Второй — про **обратимость**: во что обойдётся ошибка, если она уедет в
+мердж. Раньше ступень выбиралась только по классу изменения («вводит ли новое
+понятие»), и объём в правило не входил вовсе; теперь входит, потому что цена
+разбирательства растёт именно с ним.
 
-Оно же объясняет, почему миграция схемы и публичный контракт **не** поднимают
-ступень, хотя выглядят опаснее прочего. Они не добавляют ни одного прохода:
-миграцию гоняет `gate` шагом миграций и разбирает `ops` («миграция под живым
-потоком», «частичный откат при двух версиях»), контракт сверяет `specs`
-направлением `code → spec`, инвариант даёт основание для `critical` любому
-проходу. Все трое уже в `standard`. Раньше эти три факта стояли триггерами
-верхних ступеней, и на проекте с базой и эндпоинтами верхняя ступень оказывалась
-не исключением, а умолчанием — то есть правило объявляло исключением то, что
-происходит всегда. `architecture` же получает работу **не** от того, что контракт
-изменился, а от того, что появилось новое понятие: добавленное поле в
-существующем ответе — не концепт.
+**Отрицательный тест `quick`, и он важнее положительного:** изменение, которое
+после мерджа **не откатывается обратной правкой**, — не `quick`, каким бы
+маленьким ни был дифф. Сюда попадают миграция схемы и данных, формат на диске,
+публичный контракт, имя, которое разойдётся по кодовой базе. Три строки миграции
+— это `standard`, а не `quick`: размер диффа и цена ошибки здесь расходятся.
 
-Что здесь считается новым понятием, проект может уточнить в `docs/review.md`,
-разделе настройки конвейера. Это **уточнение**, а не отмена: не записано —
-работает список выше. Проект, где изменение контракта и правда архитектурное
-(публичный SDK, чужие потребители), там же поднимает его до `wide` — и это
-уточнение, а не возврат прежнего умолчания.
+Что здесь считается крупным и что — незнакомым, проект может уточнить в
+`docs/review.md`, разделе настройки конвейера: поимённо, узлами или capability.
+Это **уточнение**, а не отмена: не записано — работает список выше.
 
-### Профиль — максимум по поверхности, и отсюда размер задачи
+### Спорный случай решается вниз, и у этого есть цена
+
+Правило асимметрично, потому что асимметрична цена ошибки.
+
+- **Спорно между `standard` и `wide` → бери `standard`.** Ошибка в эту сторону
+  стоит находки, которая всплывёт на следующей задаче или в журнале дефектов.
+  Ошибка в обратную стоит трёх тяжёлых проходов, двое из которых держат машину и
+  идут цепочкой, — и платится она **на каждой** задаче, выбранной неверно.
+- **Спорно между `quick` и `standard` → бери `standard`.** Здесь разница в один
+  дешёвый проход, зато он единственный, кто на этих ступенях вообще смотрит на
+  отказы и на эксплуатацию.
+
+**Выбор сделан в пользу пропускной способности, и это записано, а не подразумевается.**
+Конвейер настроен на поток задач, а не на максимум находок с каждой: поправить в
+следующей задаче дешевле, чем держать одну два часа. Отсюда три обязанности,
+без которых сделка превращается в незаметную потерю качества:
+
+- **границы покрытия называют непущенные проходы поимённо** — иначе `quick`
+  выглядит так же, как `wide` без находок;
+- **журнал дефектов в `docs/review.md` перестаёт быть хорошей практикой и
+  становится единственной обратной связью**: проскочивший дефект — единственный
+  сигнал, что ступень выбрана слишком низко;
+- **возврат в код — повод пересмотреть ступень.** Задача, которая приходит в тот
+  же узел третий раз, уже не мелкая, чем бы ни выглядел её дифф.
+
+### Профиль — максимум по поверхности
 
 Условия читаются сверху вниз, и **первое подошедшее отвечает за весь дифф**.
 Профиль изменения это максимум по его поверхности, а не средневзвешенное: одна
 строка в перечне границ задачи поднимает ступень всему остальному, включая ту
 часть, которая сама по себе была бы `quick`.
 
-Отсюда следствие, которое дороже любой настройки триггеров: **цена ревью растёт
-быстрее размера задачи.** Крупная задача не просто даёт больше диффа — она с
-высокой вероятностью зацепит верхнее условие и оплатит верхний профиль целиком.
-
 Обратное тоже верно и тоже не бесплатно: у каждой задачи есть **несокращаемый
 костяк из четырёх проходов** (гейт, спеки, код, триаж). Разрезать задачу, обе
 половины которой остаются в одном профиле, — значит заплатить костяк дважды за ту
@@ -243,29 +277,33 @@ flowchart TD
     gate["gate<br/>(стадия 0, держит машину)"]
     specs["specs"]
     code["code"]
-    adversary["adversary<br/>(держит машину)"]
-    ops["ops<br/>(держит машину)"]
+    basics["basics<br/>(standard)"]
+    adversary["adversary<br/>(wide, держит машину)"]
+    ops["ops<br/>(wide, держит машину)"]
     architecture["architecture<br/>(wide)"]
     triage["triage — единственный сток"]
 
     gate -->|зелёный| specs
     gate -->|зелёный| code
-    gate -->|зелёный| adversary
-    gate -->|зелёный| ops
+    gate -->|"зелёный, standard"| basics
+    gate -->|"зелёный, wide"| adversary
+    gate -->|"зелёный, wide"| ops
     gate -->|"зелёный, wide"| architecture
     adversary -. один ресурс — машина .- ops
     specs --> triage
     code --> triage
+    basics --> triage
     adversary --> triage
     ops --> triage
     architecture --> triage
 ```
 
 Читается граф так: **всё, у чего входящие рёбра закрыты, уходит одним
-сообщением**. В `standard` после зелёного гейта это три узла разом — `specs`,
-`code` и первый из меряющей пары, — а второй меряющий идёт следом за первым. В
-`wide` к этой тройке добавляется четвёртым `architecture`. В `quick` — `specs` и
-`code` разом, и сразу триаж.
+сообщением**. В `quick` после зелёного гейта это `specs` и `code` разом, и сразу
+триаж. В `standard` к ним третьим добавляется `basics` — все трое уходят одним
+сообщением, ждать друг друга им нечего. В `wide` вместо `basics` идут три тяжёлых:
+`architecture` и первый из меряющей пары — сразу, второй меряющий — следом за
+первым, и он же определяет, когда стартует триаж.
 
 **Схема здесь старше прозы.** Она не иллюстрация к тексту, а сам алгоритм
 планировщика; проза ниже объясняет рёбра и называет их цену. Разошлись — прав
@@ -292,7 +330,7 @@ flowchart TD
 | `adversary` | да | находка есть **построенный путь**: он пишет падающий тест и гоняет его |
 | `ops` | да | доказывает числами: время удержания блокировки, пик кучи, темп роста журнала |
 | `triage` | да | проверяет оракул `critical`/`major` запуском — но он сток и тоже один |
-| `specs`, `code`, `architecture`, `rubric` | нет | читают и рассуждают, ничего не исполняют |
+| `specs`, `code`, `basics`, `architecture`, `rubric` | нет | читают и рассуждают, ничего не исполняют |
 
 **Правило про ресурс, а не про имена.** Раньше здесь стояло именованное
 исключение «`adversary` и `ops`»; оно рассыпается, как только проход начнёт
@@ -374,7 +412,7 @@ flowchart TD
 
 Два applicative-прохода: оба применяют **записанный** критерий, оба дешёвые.
 Машину не держат ни один, ребра между ними нет — уходят одним сообщением сразу
-после зелёного гейта, вместе со стадией 2, если она в профиле.
+после зелёного гейта, вместе со стадией 2 или 3 — той, что в профиле.
 
 - `review-specs` — критерий взят из **дельта-спек предлагаемого изменения**, а не
   из proposal, сообщения коммита или описания задачи. Сверка двунаправленная;
@@ -385,52 +423,84 @@ flowchart TD
   перечисляет `conventions/README.md` — повторять это проходом вредно.
 
 Recall обоих равен длине их источника — это и есть предел applicative-проходов,
-ради которого существует стадия 2.
+ради которого существуют стадии 2 и 3.
 
-## Стадия 2 — Adversarial и operational (`standard`, `wide`)
+## Стадия 2 — Базовый проход (только `standard`)
 
-Два прохода:
+Агент `review-basics`. Один проход, машину не держит, ничего не запускает и не
+меряет — уходит одним сообщением вместе со стадией 1, сразу после зелёного гейта.
+
+**Он не самостоятельная оптика, а мелкая осадка двух тяжёлых проходов.** Берёт из
+эксплуатационного — вопросы, на которые отвечают чтением, а не замером: есть ли
+таймаут и отличит ли отправитель «медленно» от «упало»; идемпотентна ли повторная
+операция и не теряют ли данные две одновременные; читает ли старый код новую схему
+после частичного отката; что останется, если процесс остановят между шагами;
+увидит ли человек, что поток оборвался ночью. Берёт из архитектурного — только то,
+что видно рядом с диффом: не появился ли **второй способ** делать то, что уже
+делается, мимо единой точки проекта, и **что опытный человек отсюда удалил бы**.
+
+Чего он **не** берёт — и это записано в его уставе отдельным разделом: замеров,
+эксперимента против драйвера и библиотеки, построенного пути атаки, карты проекта,
+границы домена, направления зависимостей. Всё это стоит машины или входа шире
+диффа, то есть ровно того, ради чего и существует `wide`.
+
+**Он покрывает миграцию и публичный контракт на `standard`.** Это не побочный
+эффект, а условие, при котором миграция схемы вообще может не поднимать ступень:
+её шаг гоняет `gate`, спеку сверяет `specs`, а вопросы «обратима ли», «что с
+записями новой версии после отката» задаёт здесь `basics`. Уберёшь его — и
+`standard` останется без единственного прохода, который смотрит на ось времени.
+
+Потолок — **4 находки** плюс короткая секция «дешевле переделать до мерджа».
+Потолок и узкий вход и есть его «среднее усилие»: модель у него верхняя, потому
+что дешёвая на опиниативном проходе платит триажем (см. «Модель по проходу»).
+
+## Стадия 3 — Тяжёлые проходы (только `wide`)
+
+Три прохода, и все три уходят сразу после зелёного гейта, в одном ряду со
+стадией 1:
 
 - `review-adversary` — находка есть **построенный путь**, а не свойство;
-- `review-ops` — постмортем от симптома у владельца сервиса к строке кода.
+- `review-ops` — постмортем от симптома у владельца сервиса к строке кода;
+- `review-architecture` — концептуальная целостность на входе шире диффа.
 
-**Оба помечены «держит машину», поэтому между ними ребро конфликта: они идут
-цепочкой, а не разом** (правило и его причина — в «Порядок прогона», раздел «Кто
-держит машину»). Направления у ребра нет: кто первый — неважно. Со стадией 1 они
-конфликта не имеют и стартуют одновременно с ней; ждать её незачем.
+**Первые двое помечены «держит машину», поэтому между ними ребро конфликта: они
+идут цепочкой, а не разом** (правило и его причина — в «Порядок прогона», раздел
+«Кто держит машину»). Направления у ребра нет: кто первый — неважно.
+`architecture` машину не держит и ждать ему нечего — он уходит в первой волне.
 
 Цепочка не отменяется общим «гони по графу» — она и есть часть графа. Отменяет
 её только прямое слово оператора про эту пару, и тогда в границы покрытия идёт
 строка, что числа прогона сняты под соседней нагрузкой.
 
-**Эта стадия зарабатывает больше всех остальных вместе, и потому стоит уже в
-`standard`, а не только в верхнем профиле.** Измерено на пяти задачах подряд: враждебный
-проход дал пять из семи выживших находок дозапуска (включая обе верхние);
-эксплуатационный — единственный, кто нашёл, что откат бинаря поверх новой схемы
-стартует молча. Оба несут внешний оракул по построению: один обязан путь
-**прогнать**, второй смотрит ось времени и эксплуатации, которую не смотрит
-никто другой.
+**Эта стадия зарабатывает больше всех остальных вместе — и она же дороже всех
+остальных вместе.** Измерено на пяти задачах подряд: враждебный проход дал пять из
+семи выживших находок дозапуска (включая обе верхние); эксплуатационный —
+единственный, кто нашёл, что откат бинаря поверх новой схемы стартует молча. Оба
+несут внешний оракул по построению: один обязан путь **прогнать**, второй смотрит
+ось времени и эксплуатации. Ровно поэтому они и стоят денег: оракул добывается
+запуском, а запуск — это машина, цепочка и часы.
+
+Раньше эта пара стояла в `standard`, то есть на большинстве задач. Стадия
+переехала в `wide` **сознательно и по цене, а не потому, что перестала находить**:
+она осталась самой ценной, но её ценность оплачивается на каждой задаче, а
+получается — на немногих. Что из-за этого перестало проверяться на нижних
+ступенях, названо в «Честном пределе» и обязано идти строкой в границы покрытия
+каждого прогона `quick` и `standard`.
 
 Материал берётся из документов: `docs/security.md` — враждебному,
 `docs/architecture.md`, `docs/research/` и `docs/database.md` —
-эксплуатационному. Что с чем сшивать и почему — [project-facts.md](references/project-facts.md),
-раздел «Сшивать обязаны проходы». Без этих документов стадия вырождается в общие
-места.
+эксплуатационному, `docs/passport.md` и карта проекта — архитектурному. Что с чем
+сшивать и почему — [project-facts.md](references/project-facts.md), раздел
+«Сшивать обязаны проходы». Без этих документов стадия вырождается в общие места.
 
-## Стадия 3 — Global (`wide`, `design`)
+**Условие стадии и есть условие ступени `wide`:** изменение крупное или
+незнакомое. У архитектурного прохода работа появляется тогда, когда трогается
+несколько узлов разом или в проекте становится больше сущностей, чем было; у
+меряющей пары — когда форму решения нащупывали по ходу, и потому неизвестно, где
+она протекает. На мелкой правке вопрос «не появился ли второй способ» отвечается
+«нет» до запуска, а построенный путь строить негде.
 
-Агент `review-architecture`. Уходит в первой волне, сразу после зелёного гейта, в
-одном ряду со стадиями 1 и 2. Машину не держит, ждать ему нечего.
-
-**Условие этой стадии и есть условие ступени `wide`:** изменение вводит новое
-понятие или структурную единицу. Не «изменение крупное» и не «изменение опасное»:
-у прохода появляется работа ровно тогда, когда в проекте становится больше
-сущностей, чем было, — и тогда осмысленны оба его вопроса. На изменении, которое
-ничего не вводит, вопрос «не появился ли второй способ» отвечается «нет» до
-запуска, а вопрос «что опытный человек отсюда удалил бы» вырождается во
-вкусовщину, которую потом отсеивает триаж.
-
-Получает **вход шире диффа**: дерево пакетов с
+`review-architecture` получает **вход шире диффа**: дерево пакетов с
 назначением, граф внутренних зависимостей, инвентарь существующих концепций.
 Команду, которая это готовит, даёт раздел команд `CLAUDE.md`; нет команды —
 проход собирает карту сам и говорит об этом в границах покрытия.
@@ -470,12 +540,12 @@ Recall обоих равен длине их источника — это и е
 имеет `proposal.md` и дельта-спеки, но кода ещё нет.
 
 **Состав здесь тоже не постоянный, и условие то же самое, что у `wide`:**
-изменение вводит новое понятие или структурную единицу.
+изменение крупное или незнакомое.
 
 - **всегда** — `review-specs` в режиме «дизайн ДО кода». Дельта-спеки сверяются
   на каждой задаче: это самый дешёвый чекпоинт конвейера, и он ловит то, что на
   готовом коде уже не чинят;
-- **при новом понятии** — плюс `review-rubric` (фаза 1 без фазы 2: рубрика на
+- **при крупном или незнакомом** — плюс `review-rubric` (фаза 1 без фазы 2: рубрика на
   задуманный узел становится приёмочными критериями и уезжает в `tasks.md`) и
   `review-architecture` на предложении: можно ли выразить существующими понятиями
   — **включая конструкции стандартной библиотеки**, — не появляется ли второй
@@ -486,10 +556,10 @@ Recall обоих равен длине их источника — это и е
 
 Причина условия — арифметика, а не экономия на осторожности. Чекпоинт стоит
 **на каждой задаче**, поэтому три прохода здесь умножаются на число задач, и при
-мелкой нарезке это самая большая статья конвейера. Рубрика же на узел, который не
-вводит нового понятия, порождает свойства уже существующего рода — те, что и так
-записаны конвенциями и спеками; а `architecture` без нового понятия отвечает «нет»
-на свой главный вопрос ещё до запуска (см. «Стадия 3»).
+мелкой нарезке это самая большая статья конвейера. Рубрика же на узел знакомого
+рода порождает свойства уже существующего рода — те, что и так записаны
+конвенциями и спеками; а `architecture` на мелкой правке отвечает «нет» на свой
+главный вопрос ещё до запуска (см. «Стадия 3»).
 
 **Граф этого профиля свой, и он плоский.** Гейта нет — кода ещё нет, запускать
 нечего; машину не держит ни один проход; сток — не триаж, а шаг 5 пайплайна
@@ -500,7 +570,7 @@ Recall обоих равен длине их источника — это и е
 flowchart TD
     proposal["предложение: proposal.md + дельта-спеки"]
     specs["specs (режим «дизайн ДО кода») — всегда"]
-    novelty{{"вводит новое понятие<br/>или структурную единицу?"}}
+    novelty{{"изменение крупное<br/>или незнакомое?"}}
     rubric["rubric, фаза 1 → приёмочные критерии в tasks.md"]
     arch["architecture на предложении"]
     author["вопрос автору: три формы решения и компромисс каждой"]
@@ -593,7 +663,22 @@ flowchart TD
 никто. Класс обратимый — портит форму кода, не данные, — и его надо признавать в
 границах покрытия, а не считать проверенным.
 
-Так же честно и про второй упразднённый проход: **«не знаю, чего не знаю» больше
+**На `quick` и `standard` не проверяется ничего, что требует запуска.** Это самая
+крупная граница покрытия конвейера, и она обязана идти строкой в каждом таком
+прогоне — поимённо, а не общим «профиль ниже». Не проверяется: построенный путь
+атаки (его надо прогнать), поведение библиотеки и драйвера в вырожденном случае
+(достаётся только экспериментом), любое число — время удержания блокировки, пик
+кучи, темп роста журнала, стоимость на годовой истории. `basics` задаёт часть тех
+же вопросов **чтением**, и его ответы поэтому слабее: он формулирует условиями,
+оракула не приносит и выше гипотезы находку не поднимает — кроме той, что
+опирается на инвариант `CLAUDE.md`.
+
+Это сознательная сделка, а не пробел в устройстве: цена ступени `wide` платится на
+каждой задаче, а окупается на немногих. Проверяется сделка не рассуждением, а
+журналом дефектов: если класс, который ловят только меряющие проходы, начал
+всплывать после мерджа — ступень выбирают слишком низко.
+
+Так же честно и про упразднённый проход: **«не знаю, чего не знаю» больше
 не достаёт никто.** Проход независимой реализации писал свою версию узла, не
 открывая существующую, и диффил по решениям — декомпозиция, владение данными,
 модель конкурентности, форма решения там, где спека выбора не сделала. Он снят по

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

@@ -83,6 +83,7 @@ stateDiagram-v2
 | `review-specs` | поведение вне спеки | добавить незаказанный фолбэк-дефолт на пустом входе |
 | `review-code` | нарушение прозаической конвенции | увести штатный отказ мимо единой точки трансляции ошибки |
 | `review-rubric` | нарушенное свойство узла | у клиента внешнего сервиса убрать таймаут и протяжку `context` |
+| `review-basics` | отказ, видимый чтением | убрать обработку ошибки записи так, чтобы отказ считался успехом |
 | `review-architecture` | второй способ | завести вторую точку генерации id мимо единой |
 | `review-adversary` | построенный путь | принять внешний идентификатор без разбора до запроса в хранилище |
 | `review-ops` | деградация окружения | убрать обработку недоступности внешней зависимости в фоновом цикле |

av-dev-pipeline/skills/review-pipeline/references/project-facts.md

@@ -47,6 +47,13 @@
   нет — она **выводится по обратимости последствия** и помечается «выведена по
   обратимости», а не выдаётся за решение проекта.
 
+**У `basics` стыков нет, и это не упущение.** Он не меряет, поэтому сшивать число
+с настройкой ему нечего; единственное его основание для `critical` — инвариант из
+`CLAUDE.md`, всё остальное он формулирует условиями и оставляет гипотезой. Его
+вход намеренно узкий: единые точки и внешние зависимости из `docs/architecture.md`,
+инварианты из `CLAUDE.md`, журнал из `docs/review.md`. Широкий вход — это профиль
+`wide`, и там он есть у `architecture`.
+
 ## Деградация — поразрядная
 
 Документа нет — деградирует то, что из него читалось, и **только оно**. Каждый
@@ -67,7 +74,7 @@
 | `docs/database.md` | замер не с чем сравнить: находка не поднимается выше гипотезы |
 | `docs/passport.md` | `architecture` теряет границу домена и вырождается в общее мнение |
 | `docs/review.md` | `triage` отсеивает вслепую: типовых ложноположительных нет |
-| `docs/architecture.md` | «не появился ли второй способ» не проверяется — единых точек не знает никто |
+| `docs/architecture.md` | «не появился ли второй способ» не проверяется — единых точек не знает никто; `basics` теряет ещё и перечень внешних зависимостей |
 
 Строка в границах покрытия обязана называть **причину**: «`docs/security.md` в
 проекте нет» читается иначе, чем «есть, но периметр не назван». Без причины

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

@@ -116,7 +116,11 @@ description: Проводит несколько задач разом — пл
 
   Ни один триггер не сработал — задача не замеряющая, даже если её ревью
   окажется `wide`. Профиль про глубину проверки, замеряющая — про соревнование за
-  железо; это разные вопросы, и совпадают они не всегда;
+  железо; это разные вопросы, и совпадают они не всегда. Обратное тоже бывает и
+  тоже законно: помеченная задача, чьё ревью пошло профилем `quick` или
+  `standard`, машину не займёт вовсе — меряющие проходы живут только в `wide`.
+  Пометка от этого не снимается: она ставится **до** выбора профиля, и
+  перестраховка здесь стоит одной волны, а ошибка — испорченных чисел;
 - **нумерованные артефакты — номера раздаёт оркестратор заранее.** Если проект
   нумерует миграции (путь — `docs/.pm.json`, ключ `migrations`), посмотри последний
   номер и **раздай номера всем задачам, которые, вероятно, их добавят**, до

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

@@ -223,8 +223,8 @@ flowchart TD
 
 **Состав чекпоинта решает конвейер, а не ты**: `review-specs` в режиме «дизайн ДО
 кода» идёт всегда, а `review-rubric` и `review-architecture` — только когда
-изменение вводит новое понятие или структурную единицу (то же условие, что у
-ступени `wide`). Причина в том, что чекпоинт стоит на **каждой** задаче: при
+изменение крупное или незнакомое (то же условие, что у ступени `wide`, и та же
+доля — 5–10% задач). Причина в том, что чекпоинт стоит на **каждой** задаче: при
 мелкой нарезке три прохода здесь умножаются на число задач и становятся самой
 большой статьёй конвейера.