корректор метки переехал в code; размер считается по пяти источникам

Сигнал «метка, вероятно, занижена» жил в review-basics — в единственном месте. А
basics с меткой small не запускается, если у проекта нет своих тем: значит на
типичном проекте задача с меткой small шла без рантайм-проверки того, что метка
выбрана верно. Дыра появилась вместе с удешевлением small и попала в самую
вероятную точку ошибки: занижают туда, где дешевле, а цена занижения там же и
выросла — три темы ядра смотрятся только против записанных инвариантов.

Сигнал перешёл в review-code, и он подходит по построению: идёт при любой метке,
видит дифф целиком, а на small уже читает инварианты, то есть держит весь
материал, из которого сигнал выводится. Признаков четыре, и один весит больше
прочих — изменение, которое не откатывается обратной правкой, при метке small это
прямой промах отрицательного теста. У basics сигнал остался вторым,
подтверждающим: он смотрит оптикой тем и видит то, чего не видно из кода как
кода, — что вопросов, отложенных до large, накопилось слишком много. Триаж теперь
обязан сказать и когда сигнала нет: «корректор отработал, возражений нет» и
«корректор не запускался» по молчанию неразличимы.

У small появилась доля, и она сформулирована сравнением, а не порогом: small не
должен обгонять medium, ориентир — до трети задач. Проверка нужна именно теперь.
Пока quick и standard совпадали составом, дрейф между ними не стоил ничего, и её
не было; сейчас он стоит трёх тем ядра. У дрейфа вниз есть стимул, и он назван
прямо: метку выбирает не автор, но по описанию, написанному автором — занижённое
описание даёт занижённую метку без чьего-либо умысла.

Размер теперь считается по корпусу из пяти источников. Разметчик читал
proposal.md и tasks.md, но design.md не открывал вовсе, а метод был описан одной
фразой «размер считается по дельта-спекам». Дельты описывают заказанное поведение
и молчат об объёме работы: шесть шагов в двух узлах видны в tasks.md, а факт, что
форму решения выбирали из нескольких, — только в design.md. Каждый источник
получил свою строку по каждой оси, и каждая цифра обоснования обязана быть
привязана к источнику поимённо; «изменение выглядит средним» обоснованием больше
не считается.

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

Заодно две грамматические опечатки от вчерашнего переименования в SKILL.md.
Решение — 45.

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

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

@@ -214,7 +214,7 @@ charter'а, а модель потом двигает калибровка, и
   проде, и он тоже не оставляет следа ни в отчёте, ни в границах покрытия. По той
   же причине, что `specs`, и это дороже всего в конвейере: проход идёт на каждой
   задаче.
-- `architecture` — запускается только в старшей метки, на 5–10% задач, потолок
+- `architecture` — запускается только со старшей меткой, на 5–10% задач, потолок
   в 3 находки делает его дешёвым по выходу, а находка на предложении стоит абзаца
   против переписывания на готовом коде. Дёшево × высокое плечо.
 
@@ -228,7 +228,9 @@ charter'а, а модель потом двигает калибровка, и
 стало **дважды перечислимым**: размер считается по перечню границ задачи и
 дельта-спекам, сложность отвечается одним проверяемым признаком («можно ли до
 работы назвать тронутые узлы»). Плюс три независимых корректора: отрицательный
-тест `small`, правило «спорный случай вниз» и сигнал `basics` о заниженной метке. Дешёвая модель безопасна ровно потому, что её вывод устроен как список,
+тест `small`, правило «спорный случай вниз» и **сигнал о заниженной метке от
+`code`** — тот идёт при любой метке и видит дифф целиком. Дешёвая модель
+безопасна ровно потому, что её вывод устроен как список,
 а не как мнение.
 
 **Самая дешёвая модель не используется ни на одном проходе, и это не экономия
@@ -356,8 +358,8 @@ flowchart TD
 
 | Метка | Когда | Ревью дизайна | Ревью кода: стадии | Проходов всего | Доля задач |
 |---|---|---|---|---|---|
-| `small` | малое **и** знакомое: багфикс, локальная правка, доки | `specs` | 1, 2, 5 (+3 при своих темах) | **5–6** | много |
-| `medium` | **рабочее умолчание**: среднее и знакомое | `specs`, `rubric` | 1, 2, 3, 5 | **7** | большинство |
+| `small` | малое **и** знакомое: багфикс, локальная правка, доки | `specs` | 1, 2, 5 (+3 при своих темах) | **5–6** | **до трети, и меньше, чем `medium`** |
+| `medium` | **рабочее умолчание**: среднее и знакомое | `specs`, `rubric` | 1, 2, 3, 5 | **7** | **большинство** |
 | `large` | крупное **или** незнакомое: большой рефакторинг, функциональность, форму которой ещё предстоит нащупать | `specs`, `rubric`, `architecture` | 1, 2, 4, 5 (+3 при своих темах) | **10–11** | **5–10%** |
 
 Ревью дизайна разбирается отдельно ниже — оно идёт до кода, у него свой плоский
@@ -404,10 +406,28 @@ flowchart TD
 Совпадение неслучайное: `basics` держит темы ядра ровно при одной метке из трёх,
 а приёмником проектных тем работает на всех.
 
-**Доля 5–10% — не пожелание, а проверка правила.** Если `large` уходит каждая
-третья задача, метку выбирают по ощущению важности. Обратный перекос виден по
-журналу проскочивших дефектов: класс, который ловят только меряющие проходы,
-начинает всплывать после мерджа.
+**Доли — не пожелание, а проверка правила, и проверок теперь две.**
+
+**Сверху: `large` — 5–10%.** Если туда уходит каждая третья задача, метку
+выбирают по ощущению важности. Обратный перекос виден по журналу проскочивших
+дефектов: класс, который ловят только меряющие проходы, начинает всплывать после
+мерджа.
+
+**Снизу: `small` не должен обгонять `medium`.** Ориентир — до трети задач, но
+сравнение важнее числа: **перевес `small` над `medium` значит, что рабочее
+умолчание сместилось, а решения об этом никто не принимал.** Проверка нужна
+именно теперь: пока `quick` и `standard` совпадали составом, дрейф между ними не
+стоил ничего, и её не было. Сейчас он стоит трёх тем ядра, которые на `small`
+смотрятся только против инвариантов, — то есть ровно того, чем `small` и дёшев.
+
+Считается это по журналу дефектов и по отчётам, а не по ощущению: метка
+напечатана в каждом отчёте, и посчитать её за спринт — работа на минуту.
+
+**У дрейфа вниз есть свой стимул, и его стоит назвать.** `small` дешевле по
+времени и по деньгам, а выбирает метку хоть и не автор, но проход, читающий
+описание, написанное автором. Занижённое описание даёт занижённую метку без
+чьего-либо злого умысла — потому корректор и вынесен в `code`, который смотрит
+уже на код, а не на описание.
 
 **Состав сверяется до коммита — по плану разметки задачи, а не по этой таблице.** План
 и есть реестр: тема, дом, глубина, кто закрывает. Это единственная защита от
@@ -675,11 +695,28 @@ flowchart TD
 считалась дважды, и один из двух раз — без разведённости с автором. Теперь она
 считается один раз и обслуживает обе стадии.
 
-**Что он читает.** Запись задачи, `proposal.md` и дельта-спеки change, `tasks.md`
-change, `docs/` на уровне имён и заголовков, `CLAUDE.md` и `AGENTS.md`,
-`docs/review.*` — раздел настройки. **Диффа он не читает: кода ещё нет.** Размер
-он оценивает по перечню границ задачи и по дельта-спекам, а не по `git diff
---stat`.
+**Что он читает.** `docs/` на уровне имён и заголовков, `CLAUDE.md` и
+`AGENTS.md`, `openspec/specs/`, `docs/review.*` — раздел настройки. Плюс **корпус
+оценки**: пять письменных источников о задаче, из которых выводятся обе оси.
+
+| Источник | Размер | Сложность |
+|---|---|---|
+| запись задачи, «Затрагивает» | перечень границ, названный до работы | узлы названы поимённо — знакомое |
+| `proposal.md` | что делаем и зачем | вводит ли новое понятие |
+| `design.md` | какие узлы в решении | **разбирались ли альтернативы** |
+| `tasks.md` | число шагов и их разнородность | шаг «разобраться», «выяснить» |
+| дельта-спеки | сколько capability и требований | `ADDED` целой capability против `MODIFIED` |
+
+**Диффа он не читает: кода ещё нет** — и это причина, по которой корпус должен
+быть широким. Одни дельта-спеки описывают заказанное поведение, но молчат об
+объёме работы: шесть шагов в двух узлах видны в `tasks.md`, а факт, что форму
+решения выбирали из нескольких, — только в `design.md`. Оценка по одному
+источнику это оценка по остатку.
+
+**Расхождение источников по объёму разрешается в пользу большего** — не «спорное
+вниз»: там ничья при равных данных, здесь один источник просто видел больше.
+Само расхождение при этом идёт доводом за `незнакомое`: если о задаче написано
+так, что источники не сходятся в объёме, формы решения не знают.
 
 Возвращает **план задачи**: размер и сложность с обоснованием, метка как
 максимум по ним, состав ревью дизайна, список тем с домами и глубинами для ревью
@@ -688,7 +725,8 @@ change, `docs/` на уровне имён и заголовков, `CLAUDE.md`
 
 **Он не судит по существу** — ни одной находки об изменении. Его ошибка это
 пропущенная тема или не та метка, и обе видны: разнесение документов сверяется
-с `ls docs/` за секунду, а заниженную метка ловит `basics` своим сигналом.
+с `ls docs/` за секунду, а заниженную метку ловит `code` своим сигналом — на
+любой метке, потому что он идёт всегда.
 
 Право у разметчика симметричное: **поднять и понизить метку он может
 одинаково**, но обоснование обязательно в обоих случаях и всегда — строкой, какой