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

name, description

name

description

review-pipeline

Конвейер ревью изменения — детерминированный гейт, сверка с дельта-спеками в обе стороны, базовый проход на отказы и лишнее, а в верхнем профиле враждебные постановки, эксплуатационный постмортем и архитектурный проход; триаж обязателен всегда. Три ступени стоимости: quick (4 прохода), standard (5, рабочее умолчание), wide (7, только крупное или незнакомое — 5-10% задач). Ступень выбирается по объёму и незнакомости изменения, спорный случай решается вниз. Порядок прогона — граф зависимостей, а не очередь: гейт открывает опиниативные проходы, проходы с пометкой «держит машину» идут цепочкой, триаж — единственный сток. Линейный прогон — по слову оператора или на занятой машине. Проектная специфика приходит из документов канона av-dev-pm. Вызывается из task-pipeline (чекпоинты ревью), из task-batch (финальная сверка) и отдельно — профилем design на предложении ДО кода.

Конвейер ревью

Готовит ревью — не заменяет его. Потребитель отчёта — оркестратор, который чинит код; человек читает только сводку, развилки и границы покрытия.

Три правила, из которых всё следует

Если ситуация не покрыта инструкцией — решай по ним.

1. Recall чек-листа равен длине чек-листа. Проход, устроенный как «проверь пункты 1..N», найдёт ровно перечисленное. Всё неявное — идиомы, форма решения, «так не делают» — неперечислимо по определению: перечислимое уже стало бы конвенцией. Отсюда деление проходов на applicative (применяют заданный критерий) и generative (сперва порождают критерий или альтернативу, потом сравнивают). Расширять чек-листы бесполезно; неявный слой достают только generative-проходы.
2. Ценность верификатора = наличие внешнего оракула × разведённость с автором, а не число ролей. Под всеми ролями одна модель с одними априорными, вход у всех общий: седьмая роль почти не добавляет recall, но линейно удорожает триаж. Иерархия надёжности: детерминированный инструмент > агент, который его запускает и интерпретирует вывод > агент с чистым мнением. Максимум работы переносим вниз.
3. Отчёт без границ покрытия хуже отсутствия отчёта. «Критичных проблем не обнаружено» потребляет ощущение проверенности, ничего не гарантируя. Секция границ покрытия обязательна и не сокращается — в том числе в докладе человеку.

Предпосылки

Конвейер опирается на внешнюю обвязку и без неё работает не целиком. Проверь это один раз, при установке плагина в проект:

• OpenSpec — жёсткая предпосылка, а не опция. Профиль design, проход review-specs и вызывающий пайплайн задачи завязаны на дельта-спеки (openspec/changes/<id>/specs/*/spec.md), на актуальные спеки (openspec/specs/) и на openspec validate --strict. В проекте без OpenSpec шаги, зовущие opsx:explore / opsx:propose / opsx:apply / opsx:archive, упадут на «нет такого скилла», а review-specs останется без источника требований. Проект без OpenSpec этим конвейером не проверяется — подключай OpenSpec, а не понижай прогон: ветка деградации здесь не пишется, потому что непроверенная ветка деградации хуже честного отказа.
• Документы канона — см. следующий раздел.
• Проектные копии этих скиллов и агентов удаляются при установке. Если в проекте уже лежат свои .claude/skills/review-pipeline, .claude/skills/task-pipeline, .claude/skills/task-batch или .claude/agents/<проект>-review-*.md — снеси их. Иначе короткое имя разрешится в устаревшую проектную копию, молча и без признаков подмены. По той же причине скиллы этого плагина зовутся с пространством имён: av-dev-pipeline:review-pipeline, av-dev-pipeline:task-pipeline, av-dev-pipeline:task-batch.

Что конвейер защищает — приходит из документов проекта

Проходы общие, а нарушать нельзя проектное. Инварианты, команду гейта, объёмы, прецеденты и модель угроз конвейер не знает — он читает их в документах канона av-dev-pm, напрямую и по жёстким путям. Отдельного файла-брифа нет: пути известны, посредник не нужен, а второй дом для тех же фактов разошёлся бы и выглядел актуальным.

Карта «что нужно проходу → где лежит» — references/project-facts.md. Прочитай её до раздачи заданий; там же таблица поразрядной деградации.

Деградация поразрядная, а не всё-или-ничего. Документа нет — деградирует то, что из него читалось, и только оно: нет docs/security.md — слабеет adversary; нет docs/research/ — числа неизвестны трём проходам; нет инвариантов в CLAUDE.md — critical по основанию «нарушен инвариант проекта» не присваивается никем. Каждый проход пишет свою строку в границы покрытия, с причиной; триаж сводит их и не сливает в одну.

Документов канона нет вовсе — проект не приведён к канону. Скажи это строкой и предложи скилл av-dev-pm:canon: одна операция на проект против деградации на каждой задаче. Прогон при этом не останавливается.

Что получает каждый проход

Задание любому проходу состоит из шести вещей:

• его блок вопросов из «Вопросы к проходам» в docs/review.md, если он там есть, — дословно. Блок адресован проходу поимённо и выведен из промаха этого проекта; заставлять девять charter'ов самим ходить за ним значит получить, что за ним ходят двое. Проход отвечает на такие вопросы явно, дополнительно к обязательным;
• контракт находок — путь к references/finding-contract.md (в установленном плагине — ${CLAUDE_PLUGIN_ROOT}/skills/review-pipeline/references/);
• изменение — идентификатор change и путь к его дельта-спекам;
• база диффа;
• профиль и режим прогона — чтобы проход знал, что писать в границы покрытия;
• сужение, если оно есть: конкретный узел, конкретная capability.

Чего проход не получает ни в каком режиме — выводов других проходов. См. «Порядок прогона».

Модель по проходу

Следует из правила 2: чем больше работы делает детерминированный инструмент, тем дешевле может быть модель; чем больше проход порождает критерий, тем дороже. Модель задана во frontmatter каждого агента, менять её здесь не нужно.

Модель	Цвет	Проходы	Почему
sonnet	green	gate, code, ops	вход структурный, критерий записан заранее
opus	yellow	specs, adversary, rubric, basics, architecture, triage	суждение без опоры на инструмент

Цвет charter'а кодирует модель, а не роль прохода. Это единственное назначение цвета: список агентов читается взглядом, и по нему сразу видно, чем платит прогон. Роль прохода из имени и так понятна, а цвет, розданный по ролям, не отвечает ни на один вопрос, который задают во время прогона. Раскладка живёт здесь и проверяется механически — цвет ставится один раз при заведении charter'а, а модель потом двигает калибровка, и разъезжаются они молча.

Моделей две, и верхняя из них — opus; выше неё конвейер не платит. Замер: на первом же прогоне самые ценные находки дали opus-проходы — сверка спек дала 13 находок с оракулами, а проход про идиоматичность (впоследствии упразднённый) — три эксперимента против драйвера БД с воспроизведёнными числами. Разницы в пользу модели дороже opus не обнаружилось ни на одном проходе, а прогон на ней стоил заметно дольше и дороже — значит платить за неё не за что.

Двое из шести держатся на opus по признаку, отдельному от суждения: их ошибка распространяется дальше собственной находки. Понижать их до sonnet вместе с остальными дешёвыми проходами нельзя.

• triage — через него проходит всё, что оркестратор реализует молча: ложноположительная находка становится кодом, потерянный critical — дефектом. Ошибка триажа дороже ошибки любого отдельного прохода.
• architecture — запускается только в верхней ступени, на 5–10% задач, потолок в 3 находки делает его дешёвым по выходу, а находка на предложении стоит абзаца против переписывания на готовом коде. Дёшево × высокое плечо.

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

Экономия достигается не понижением модели, а непуском прохода: quick — четыре прохода, standard — пять, wide — семь. Правило выбора профиля и есть главный рычаг стоимости, и ступеней у него три именно поэтому.

Второй рычаг, помимо непуска, — вход и потолок прохода, и он же объясняет basics на opus. «Проход среднего усилия» тут значит не дешёвую модель, а узкий вход (дифф и его окрестности, без карты проекта) и жёсткий потолок находок. Прогон он ускоряет тем, чего не делает: ничего не запускает, ничего не меряет, машину не держит — а именно замеры и цепочка меряющих проходов и составляли те самые долгие часы.

Профили

Профиль	Когда	Стадии	Проходов	Доля задач
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 назван по тому, что он добавляет: вход шире диффа. Он единственный, где живут тяжёлые проходы — враждебный, эксплуатационный и архитектурный, — и единственный, где что-то запускается и меряется. Отсюда и его доля: три прохода на стадии 3, два из них держат машину и потому идут цепочкой, а не разом. Это и есть те самые долгие часы, и платить их каждой задаче не за что.

Доля 5–10% — не пожелание, а проверка правила. Она не считается механически, но читается по журналу: если wide уходит каждая третья задача, ступень выбирают по ощущению важности, а не по факту изменения. Обратный перекос виден иначе — по журналу проскочивших дефектов в docs/review.md: класс, который ловят только меряющие проходы, начинает всплывать после мерджа.

Состав сверяется по этой таблице до коммита. Реестр из трёх-семи проходов проверяется взглядом — и это единственная защита от промаха, который уже случился: пропуск прохода не отличим от прохода без находок (гейт зелёный, спеки сошлись, отчёт выглядит полным), а заметить его мог бы только триаж, который сам заполняется тем, что ему подали. Отчёт обязан перечислять запущенные проходы поимённо и с исходом; непущенный идёт строкой «не запускался» в границы покрытия, а не отсутствует. Цена молчащего пропуска измерена: семь находок и отдельная задача на их дозакрытие.

Правило выбора — два вопроса по факту изменения, не по ощущению важности. Отвечать по порядку, первый подошедший ответ и есть профиль:

1. Изменение крупное или незнакомое? → wide. Крупное — трогает несколько узлов или слоёв разом, переносит ответственность между ними, перекладывает существующий код в новую форму (большой рефакторинг). Незнакомое — функциональность, которой в проекте ещё не было, и форму решения предстоит нащупать по ходу, а не выбрать до начала. Признак незнакомого простой: перед работой нельзя назвать, какие узлы будут тронуты.
2. Изменение мелкое? → quick. Мелкое — помещается в один узел, форма решения очевидна до начала работы, а откат сводится к обратной правке. Сюда идут мелкий багфикс, мелкая фича, правка текста и документации.
3. Всё остальное → standard. Это рабочее умолчание, и оно должно набирать большинство задач.

Два признака смотрят на разное, и в этом весь смысл двух вопросов. Первый — про объём и неизвестность: сколько мест трогается и знаем ли мы форму решения заранее. Второй — про обратимость: во что обойдётся ошибка, если она уедет в мердж. Раньше ступень выбиралась только по классу изменения («вводит ли новое понятие»), и объём в правило не входил вовсе; теперь входит, потому что цена разбирательства растёт именно с ним.

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

Что здесь считается крупным и что — незнакомым, проект может уточнить в docs/review.md, разделе настройки конвейера: поимённо, узлами или capability. Это уточнение, а не отмена: не записано — работает список выше.

Спорный случай решается вниз, и у этого есть цена

Правило асимметрично, потому что асимметрична цена ошибки.

• Спорно между standard и wide → бери standard. Ошибка в эту сторону стоит находки, которая всплывёт на следующей задаче или в журнале дефектов. Ошибка в обратную стоит трёх тяжёлых проходов, двое из которых держат машину и идут цепочкой, — и платится она на каждой задаче, выбранной неверно.
• Спорно между quick и standard → бери standard. Здесь разница в один дешёвый проход, зато он единственный, кто на этих ступенях вообще смотрит на отказы и на эксплуатацию.

Выбор сделан в пользу пропускной способности, и это записано, а не подразумевается. Конвейер настроен на поток задач, а не на максимум находок с каждой: поправить в следующей задаче дешевле, чем держать одну два часа. Отсюда три обязанности, без которых сделка превращается в незаметную потерю качества:

• границы покрытия называют непущенные проходы поимённо — иначе quick выглядит так же, как wide без находок;
• журнал дефектов в docs/review.md перестаёт быть хорошей практикой и становится единственной обратной связью: проскочивший дефект — единственный сигнал, что ступень выбрана слишком низко;
• возврат в код — повод пересмотреть ступень. Задача, которая приходит в тот же узел третий раз, уже не мелкая, чем бы ни выглядел её дифф.

Профиль — максимум по поверхности

Условия читаются сверху вниз, и первое подошедшее отвечает за весь дифф. Профиль изменения это максимум по его поверхности, а не средневзвешенное: одна строка в перечне границ задачи поднимает ступень всему остальному, включая ту часть, которая сама по себе была бы quick.

Обратное тоже верно и тоже не бесплатно: у каждой задачи есть несокращаемый костяк из четырёх проходов (гейт, спеки, код, триаж). Разрезать задачу, обе половины которой остаются в одном профиле, — значит заплатить костяк дважды за ту же проверку. Резать стоит там, где разрез снимает дорогой проход с большей части диффа. Шов и правило нарезки живут у того, кто ведёт задачи, — скилл av-dev-pm:tasks, его references/split.md. Пути туда конвейер не выносит: за пределы своего плагина он ходит вызовом скилла, а не файлом.

Профиль объявляется в отчёте. Понижение профиля — решение оркестратора, и оно попадает в границы покрытия строкой «профиль понижен до X, потому что …».

Порядок прогона — граф, а не очередь

Профиль отвечает «какие проходы», порядок — «что кого ждёт». Стадии остаются единицей состава (профиль набирается стадиями, см. таблицу выше), но порядок задают не их номера: между стадиями 1–3 настоящих зависимостей нет — ни один проход не читает вывод другого, — и очередь между ними была бы платой ни за что.

Рёбер два вида, и они разной природы. Путать их нельзя: первое про осмысленность (на красном гейте опиниативный проход не о чем), второе про железо.

Ребро	Смысл	Между кем
зависимость	B не стартует, пока A не закончил, потому что без A задание B не определено	гейт → все опиниативные; все проходы → триаж
конфликт за ресурс	A и B не держат машину одновременно; кто из них первый — неважно, направления у ребра нет	проходы, помеченные «держит машину»

flowchart TD
    gate["gate<br/>(стадия 0, держит машину)"]
    specs["specs"]
    code["code"]
    basics["basics<br/>(standard)"]
    adversary["adversary<br/>(wide, держит машину)"]
    ops["ops<br/>(wide, держит машину)"]
    architecture["architecture<br/>(wide)"]
    triage["triage — единственный сток"]

    gate -->|зелёный| specs
    gate -->|зелёный| code
    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

Читается граф так: всё, у чего входящие рёбра закрыты, уходит одним сообщением. В quick после зелёного гейта это specs и code разом, и сразу триаж. В standard к ним третьим добавляется basics — все трое уходят одним сообщением, ждать друг друга им нечего. В wide вместо basics идут три тяжёлых: architecture и первый из меряющей пары — сразу, второй меряющий — следом за первым, и он же определяет, когда стартует триаж.

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

Ребро значит «A закончил раньше, чем B стартовал», и ничего больше. В обычном графе задач ребро тянет за собой данные — здесь нет, и это не деталь реализации. Проход не видит находок других проходов, в каком бы порядке их ни запустили. Вся ценность конвейера держится на разведённости: под всеми ролями одна модель с одними априорными, и стоит показать ей чужой вывод — она согласится. Согласие нескольких проходов и так не повышает confidence (см. «Честный предел»); согласие наведённое ещё и маскируется под независимое подтверждение. Единственный, кто получает чужие выводы, — триаж, и это его работа.

Кто держит машину

Ресурс один и неделимый: машина — тесты, поднятый сервис, СУБД, порты, диск. Проходы, заявившие его, сериализуются между собой в любом профиле и на любой стадии; порядок внутри цепочки произволен.

Проход	Держит машину	Почему
gate	да	запускает инструменты проекта — но он источник графа и один по построению
adversary	да	находка есть построенный путь: он пишет падающий тест и гоняет его
ops	да	доказывает числами: время удержания блокировки, пик кучи, темп роста журнала
triage	да	проверяет оракул critical/major запуском — но он сток и тоже один
specs, code, basics, architecture, rubric	нет	читают и рассуждают, ничего не исполняют

Правило про ресурс, а не про имена. Раньше здесь стояло именованное исключение «adversary и ops»; оно рассыпается, как только проход начнёт мерить или в проекте появится свой. Два прохода на одной машине соревнуются за диск, CPU и за саму СУБД и выдают числа, которые не воспроизведутся, — а число, снятое под конкурентную нагрузку, это находка с испорченным оракулом. Её опровержение стоит дороже всего выигрыша от параллельности, и она хуже отсутствующей: выглядит доказанной. Правило выведено из находок, целиком державшихся на таких замерах; у каждого проекта они свои и лежат в журнале docs/review.md.

Проект вправе пометить «держит машину» и другой проход — в docs/review.md, разделе настройки конвейера. Снимать пометку с перечисленных нельзя.

Находка «переделать форму» — прогон повторяется целиком

Барьера стоимости в конвейере нет, и раннего выхода тоже. Барьер существовал ради независимой реализации — единственного прохода, чей счёт определялся объёмом вывода, — и ушёл вместе с ней. Граф во всех профилях плоский, от гейта до триажа: защищать за барьером нечего, architecture дёшев по выходу (потолок 3 находки), а сериализация не бесплатна — она разводит по очереди то, что могло идти разом.

Находка «форму изменения надо переделывать» ловится триажем, как и любая другая; дальше правило одно. Находка чинится, и конвейер запускается заново с нулевой стадии, а не «доезжает» остатком по коду, которого через час не станет. Если прогон всё же остановлен на полпути, незапущенные проходы идут в границы покрытия строкой «не запускался: прогон остановлен на <проход> из-за <находка>», поимённо, а триаж на половине прогона не запускается: его отчёт выглядит полным, потому что агрегирует всё, что ему подали, — это тот же молчащий пропуск, что и в разделе «Профили».

Находка, которая чинится в пределах существующей формы (Действие: инлайн), прогон не останавливает: дешевле дособрать все находки и починить пачкой, чем гонять конвейер дважды.

Линеаризация — когда графа мало

Граф можно вытянуть в одну цепочку. Это отступление, и оно называется в отчёте:

1. сказал оператор — «гони линейно». Набора называть не надо: линейный прогон ничего не портит, он только дольше, и домысливать тут нечего;
2. машина занята, и знает об этом вызывающий. Рядом идёт другая задача, поднят сервис, гоняется дорогая проверка проекта. Сам конвейер занятости машины не видит — её обязан назвать тот, кто запускает; так и делает av-dev-pipeline:task-batch, когда ведёт задачи параллельно;
3. разбор самого конвейера — когда выясняется, почему проход чего-то не нашёл, порядок и изоляция важнее скорости.

Обратное отступление — слить цепочку ресурса (пустить меряющие проходы разом) — бывает только по прямому слову оператора, и тогда в границы покрытия идёт строка: какие проходы шли одновременно и что замеры этого прогона как оракул слабее.

Режим объявляется в отчёте наравне с профилем: по графу — одним словом, линейно — с причиной (какой именно из трёх).

Стадия 0 — Gate (обязательна во всех профилях)

Агент review-gate. Запускает команду гейта из семантики гейта в CLAUDE.md и интерпретирует вывод.

Пока гейт красный — опиниативные проходы не запускаются. Оркестратор чинит и перезапускает гейт. Исключение одно: отказ, унаследованный от базовой ветки (гейт проверяет это прогоном на базе) — тогда он фиксируется находкой и не блокирует.

Гейт возвращает не только «зелено/красно», но и находки класса отсутствующая верификация: изменённые строки без покрытия, конкурентность без теста с параллельным доступом, флаки-тест (не ниже major), недоступный инструмент.

Шаги выбираются по изменённым файлам: правка документации не гоняет тесты, линтеры и детектор гонок. Пропуск при этом не молчит — он виден в сводке с причиной и уезжает в границы покрытия, как и любой другой SKIP.

Шаги, которые красят гейт безусловно, перечислены в CLAUDE.md с причиной. Проходу запрещено списывать такой отказ в мелочь.

Стадия 1 — Conformance (обязательна во всех профилях)

Два applicative-прохода: оба применяют записанный критерий, оба дешёвые. Машину не держат ни один, ребра между ними нет — уходят одним сообщением сразу после зелёного гейта, вместе со стадией 2 или 3 — той, что в профиле.

• review-specs — критерий взят из дельта-спек предлагаемого изменения, а не из proposal, сообщения коммита или описания задачи. Сверка двунаправленная; направление code → spec важнее.
• review-code — критерий взят из конвенций проекта, каталог docs/conventions/. Берётся только та их часть, которая не выражается правилом: механизируемое уже проверила стадия 0. Что именно механизировано, перечисляет conventions/README.md — повторять это проходом вредно.

Recall обоих равен длине их источника — это и есть предел applicative-проходов, ради которого существуют стадии 2 и 3.

Стадия 2 — Базовый проход (только standard)

Агент review-basics. Один проход, машину не держит, ничего не запускает и не меряет — уходит одним сообщением вместе со стадией 1, сразу после зелёного гейта.

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

Чего он не берёт — и это записано в его уставе отдельным разделом: замеров, эксперимента против драйвера и библиотеки, построенного пути атаки, карты проекта, границы домена, направления зависимостей. Всё это стоит машины или входа шире диффа, то есть ровно того, ради чего и существует wide.

Он покрывает миграцию и публичный контракт на standard. Это не побочный эффект, а условие, при котором миграция схемы вообще может не поднимать ступень: её шаг гоняет gate, спеку сверяет specs, а вопросы «обратима ли», «что с записями новой версии после отката» задаёт здесь basics. Уберёшь его — и standard останется без единственного прохода, который смотрит на ось времени.

Потолок — 4 находки плюс короткая секция «дешевле переделать до мерджа». Потолок и узкий вход и есть его «среднее усилие»: модель у него верхняя, потому что дешёвая на опиниативном проходе платит триажем (см. «Модель по проходу»).

Стадия 3 — Тяжёлые проходы (только wide)

Три прохода, и все три уходят сразу после зелёного гейта, в одном ряду со стадией 1:

• review-adversary — находка есть построенный путь, а не свойство;
• review-ops — постмортем от симптома у владельца сервиса к строке кода;
• review-architecture — концептуальная целостность на входе шире диффа.

Первые двое помечены «держит машину», поэтому между ними ребро конфликта: они идут цепочкой, а не разом (правило и его причина — в «Порядок прогона», раздел «Кто держит машину»). Направления у ребра нет: кто первый — неважно. architecture машину не держит и ждать ему нечего — он уходит в первой волне.

Цепочка не отменяется общим «гони по графу» — она и есть часть графа. Отменяет её только прямое слово оператора про эту пару, и тогда в границы покрытия идёт строка, что числа прогона сняты под соседней нагрузкой.

Эта стадия зарабатывает больше всех остальных вместе — и она же дороже всех остальных вместе. Измерено на пяти задачах подряд: враждебный проход дал пять из семи выживших находок дозапуска (включая обе верхние); эксплуатационный — единственный, кто нашёл, что откат бинаря поверх новой схемы стартует молча. Оба несут внешний оракул по построению: один обязан путь прогнать, второй смотрит ось времени и эксплуатации. Ровно поэтому они и стоят денег: оракул добывается запуском, а запуск — это машина, цепочка и часы.

Раньше эта пара стояла в standard, то есть на большинстве задач. Стадия переехала в wide сознательно и по цене, а не потому, что перестала находить: она осталась самой ценной, но её ценность оплачивается на каждой задаче, а получается — на немногих. Что из-за этого перестало проверяться на нижних ступенях, названо в «Честном пределе» и обязано идти строкой в границы покрытия каждого прогона quick и standard.

Материал берётся из документов: docs/security.md — враждебному, docs/architecture.md, docs/research/ и docs/database.md — эксплуатационному, docs/passport.md и карта проекта — архитектурному. Что с чем сшивать и почему — project-facts.md, раздел «Сшивать обязаны проходы». Без этих документов стадия вырождается в общие места.

Условие стадии и есть условие ступени wide: изменение крупное или незнакомое. У архитектурного прохода работа появляется тогда, когда трогается несколько узлов разом или в проекте становится больше сущностей, чем было; у меряющей пары — когда форму решения нащупывали по ходу, и потому неизвестно, где она протекает. На мелкой правке вопрос «не появился ли второй способ» отвечается «нет» до запуска, а построенный путь строить негде.

review-architecture получает вход шире диффа: дерево пакетов с назначением, граф внутренних зависимостей, инвентарь существующих концепций. Команду, которая это готовит, даёт раздел команд CLAUDE.md; нет команды — проход собирает карту сам и говорит об этом в границах покрытия.

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

Стадия 4 — Triage (обязательна)

Агент review-triage. Единственный сток графа и единственный, кто агрегирует. Входящие рёбра — все запущенные проходы: пока хоть один не вернул отчёт, триаж не стартует. Получает сырые выводы всех проходов, git diff, профиль, режим и список запущенных проходов; возвращает финальный отчёт.

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

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

Порядок: дедупликация по причине → оракул для всего critical/major → понижение неподтверждённого до гипотезы → отсев вкусовщины → ранжирование по ущербу × вероятности → потолок 7 пунктов в основном списке.

Профиль design — до кода

Запускается на шаге ревью спек (шаг 4 скилла av-dev-pipeline:task-pipeline), когда change уже имеет proposal.md и дельта-спеки, но кода ещё нет.

Состав здесь тоже не постоянный, и условие то же самое, что у wide: изменение крупное или незнакомое.

• всегда — review-specs в режиме «дизайн ДО кода». Дельта-спеки сверяются на каждой задаче: это самый дешёвый чекпоинт конвейера, и он ловит то, что на готовом коде уже не чинят;
• при крупном или незнакомом — плюс review-rubric (фаза 1 без фазы 2: рубрика на задуманный узел становится приёмочными критериями и уезжает в tasks.md) и review-architecture на предложении: можно ли выразить существующими понятиями — включая конструкции стандартной библиотеки, — не появляется ли второй способ. Вопрос «не изобретаем ли то, что уже есть в библиотеке» живёт здесь; тогда же задаётся вопрос автору дизайна: «предложи три формы решения и назови компромисс каждой» — если ответ показывает, что рассматривалась одна, это находка.

Причина условия — арифметика, а не экономия на осторожности. Чекпоинт стоит на каждой задаче, поэтому три прохода здесь умножаются на число задач, и при мелкой нарезке это самая большая статья конвейера. Рубрика же на узел знакомого рода порождает свойства уже существующего рода — те, что и так записаны конвенциями и спеками; а architecture на мелкой правке отвечает «нет» на свой главный вопрос ещё до запуска (см. «Стадия 3»).

Граф этого профиля свой, и он плоский. Гейта нет — кода ещё нет, запускать нечего; машину не держит ни один проход; сток — не триаж, а шаг 5 пайплайна задачи, где замечания отрабатываются правкой спек. Триаж здесь не нужен: находок единицы, и каждая либо правит спеку, либо становится развилкой.

flowchart TD
    proposal["предложение: proposal.md + дельта-спеки"]
    specs["specs (режим «дизайн ДО кода») — всегда"]
    novelty{{"изменение крупное<br/>или незнакомое?"}}
    rubric["rubric, фаза 1 → приёмочные критерии в tasks.md"]
    arch["architecture на предложении"]
    author["вопрос автору: три формы решения и компромисс каждой"]
    fix["шаг 5 пайплайна: правка спек, развилки — вопросом в запись"]

    proposal --> specs
    proposal --> novelty
    novelty -->|да| rubric
    novelty -->|да| arch
    novelty -->|да| author
    novelty -->|нет| fix
    specs --> fix
    rubric --> fix
    arch --> fix
    author --> fix

Смысл профиля: архитектурная находка на готовом коде стоит переписывания и поэтому игнорируется; та же находка на предложении стоит абзаца обсуждения.

rubric живёт только в этом профиле. Судить код по критерию, под который он писался, — корреляция по построению; те же 8–12 свойств уже лежат приёмочными критериями в tasks.md.

Контракт находок

Единый для всех проходов — references/finding-contract.md. Коротко: заголовок через последствие, обязательные поля Файл, Severity, Confidence, Оракул, Последствие, Предложение, Найдено проходом. critical без оракула или построенного пути не существует. Находка без поля «Последствие» не выводится вовсе.

Каждый проход завершает вывод блоком ## Coverage of this pass.

Что происходит с находками дальше

• Оркестратор чинит помеченное Действие: инлайн и не логирует мелочь.
• Действие: развилка — вопросом с вариантами и ценой каждого туда, где проект держит вопросы (это знает вызвавший пайплайн, а не конвейер). Оркестратор не останавливается: он урезает изменение до остатка и доводит его.
• Находка не для этого мерджа, но реальная (отложенный major, развилка, решённая «потом»), — не теряется, но и не заводится здесь. Конвейер отдаёт её списком урожая в отчёте: формулировка, оракул, провенанс (какой проход, какой change). Заведение задач принадлежит тому, кто ведёт задачи проекта, — у него свой формат, своя нарезка и свои правила дублей. Мелочь класса nit идёт в урожай одной пачкой, а не записью на находку.
• Promote candidates — по процедуре references/promote.md: находка → конвенция → правило линтера → удаление формулировки из конвенций. Третий шаг обязателен.
• Дефект, проскочивший ревью и всплывший позже, идёт в журнал проекта (references/review-journal.md) — сразу, не ретроспективно: теряется именно то, почему дефект не поймали.
• Отчёт триажа сохраняется вместе с изменением — openspec/changes/<id>/review/. Он единственное, по чему потом видно, что было найдено и что из этого не заведено: нулевой урожай при непустом отчёте виден сразу. Вместе с изменением он и переезжает: после opsx:archive его адрес — openspec/changes/archive/<id>/review/. Кто ищет отчёт после архивации (батч на финальной сверке, приёмщик на сессии), смотрит оба пути; «отчёта нет» объявляется, только когда пуст и архивный, иначе самый дорогой сценарий «состав ревью неизвестен, гоняем заново» срабатывает на каждой доведённой задаче.

Честный предел

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

Согласие нескольких проходов — не подтверждение: это один источник, высказавшийся несколько раз. Совпадение повышает приоритет, но не confidence.

Что недоступно этому проекту принципиально — перечисляет «Недоступно проверке» в docs/review.md, и оба его подраздела целиком уезжают в границы покрытия. Независимо от проекта недоступно:

• поведение внешних систем в их будущих версиях;
• реальный профиль нагрузки; и то, что на самом деле лежит в данных, — сверх того, что снято с провенансом в docs/research/;
• завязка внешних потребителей на текущую форму ответа;
• суждение «этой функциональности не должно существовать».

Отдельно и честно: поимённая сверка с положениями руководств по стилю языка не задаётся ни одним проходом. Проход про идиоматичность упразднён, его способные части переселены (эксперимент против поведения библиотеки и драйвера — в ops, вопрос 8; «не изобретаем ли то, что уже есть в библиотеке» — в architecture, вопрос 1), но различение «идиоматично против распространено» теперь не спрашивает никто. Класс обратимый — портит форму кода, не данные, — и его надо признавать в границах покрытия, а не считать проверенным.

На quick и standard не проверяется ничего, что требует запуска. Это самая крупная граница покрытия конвейера, и она обязана идти строкой в каждом таком прогоне — поимённо, а не общим «профиль ниже». Не проверяется: построенный путь атаки (его надо прогнать), поведение библиотеки и драйвера в вырожденном случае (достаётся только экспериментом), любое число — время удержания блокировки, пик кучи, темп роста журнала, стоимость на годовой истории. basics задаёт часть тех же вопросов чтением, и его ответы поэтому слабее: он формулирует условиями, оракула не приносит и выше гипотезы находку не поднимает — кроме той, что опирается на инвариант CLAUDE.md.

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

Так же честно и про упразднённый проход: «не знаю, чего не знаю» больше не достаёт никто. Проход независимой реализации писал свою версию узла, не открывая существующую, и диффил по решениям — декомпозиция, владение данными, модель конкурентности, форма решения там, где спека выбора не сделала. Он снят по решению оператора о стоимости — счёт определялся объёмом вывода, и на прогон он тратил больше всех остальных проходов вместе, — а не по замеру, который calibration.md требует перед удалением. Значит и записывается это как сознательное сужение, а не как «класс оказался пустым»: остаток независимого взгляда даёт профиль design (код пишется под его находки) и architecture (второй способ, лишние слои), но альтернативной реализации, с которой можно сдиффить решения, у конвейера теперь нет. Класс идёт строкой в границы покрытия каждого прогона — там же, где проект перечисляет своё в подразделе «перестали проверять сознательно».

Это и есть причина, по которой конвейер готовит ревью, а не заменяет его.

Ссылки

• references/project-facts.md — что нужно проходу и где это лежит в документах проекта; таблица поразрядной деградации.
• Skill av-dev-pm:canon — приведение проекта к канону документов.
• references/finding-contract.md — контракт находок.
• references/promote.md — промоут находка → конвенция → правило → удаление.
• references/calibration.md — калибровка инъекцией, вердикты keep/retune/drop.
• references/review-journal.md — журнал проскочивших дефектов.