корректор метки переехал в 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/agents/review-scope.md

@@ -1,6 +1,6 @@
 ---
 name: review-scope
-description: "Разметка задачи — один проход на всю задачу, сразу после propose и ДО обеих стадий ревью. Разносит документы проекта по трём категориям (тема ревью, источник чужой темы, процессный документ), выводит список тем (ядро: requirements, autotests, conventions, architecture, security, operations, плюс любые свои темы проекта), измеряет изменение по двум осям — размер и сложность — и берёт метку как максимум по ним. Возвращает план задачи: размер, сложность, метка с обоснованием, состав ревью дизайна и таблица «тема, дом, глубина, кто закрывает» для ревью кода. Каждый документ обязан попасть в план строкой своей категории. Адреса и разделы, а не пересказ содержимого. Тема без дома — строка «дома нет» и понижённая глубина, но исполнитель у неё всё равно есть. Кода и диффа не видит: их ещё нет. Только чтение, ничего не судит по существу."
+description: "Разметка задачи — один проход на всю задачу, сразу после propose и ДО обеих стадий ревью. Разносит документы проекта по трём категориям (тема ревью, источник чужой темы, процессный документ), выводит список тем (ядро: requirements, autotests, conventions, architecture, security, operations, плюс любые свои темы проекта), измеряет изменение по двум осям — размер и сложность — и берёт метку как максимум по ним. Обе оси выводит из корпуса пяти источников: запись задачи, proposal.md, design.md, tasks.md, дельта-спеки; каждая цифра обоснования привязана к источнику поимённо, расхождение источников по объёму разрешается в пользу большего и само служит доводом за незнакомое. Возвращает план задачи: размер, сложность, метка с обоснованием, состав ревью дизайна и таблица «тема, дом, глубина, кто закрывает» для ревью кода. Каждый документ обязан попасть в план строкой своей категории. Адреса и разделы, а не пересказ содержимого. Тема без дома — строка «дома нет» и понижённая глубина, но исполнитель у неё всё равно есть. Кода и диффа не видит: их ещё нет. Только чтение, ничего не судит по существу."
 tools: Read, Grep, Glob, Bash
 model: sonnet
 color: green
@@ -35,8 +35,9 @@ color: green
 пропущенная тема или не та метка, а не пропущенная находка.
 
 **Кода ты не видишь, и это не ограничение, а условие задачи.** Диффа на момент
-твоего запуска не существует. Размер ты оцениваешь по перечню границ задачи и по
-дельта-спекам, а не по `git diff --stat`.
+твоего запуска не существует. Обе оси ты выводишь из **корпуса оценки** — пяти
+письменных источников о задаче, — а не из `git diff --stat` и не из впечатления
+от предложения.
 
 ## Что тебе дают
 
@@ -52,17 +53,48 @@ color: green
   стандарт; читай оба, если оба есть, и скажи в плане, какой нашёл). Оттуда:
   инварианты — они сквозные и питают все темы; семантика гейта — тема
   `autotests`; директивы, называющие темы, которых нет в `docs/`;
-- **`openspec/specs/` и дельта-спеки change** — дом темы `requirements`. Дельты
-  вдобавок твой главный источник о размере: сколько capability затронуто и
-  сколько требований в каждой;
-- **`proposal.md` и `tasks.md`** change — что предлагается сделать и на сколько
-  шагов это разложено;
-- **запись задачи**, раздел «Затрагивает» — перечень границ, названный **до**
-  работы. Он и есть ответ на вопрос о сложности;
+- **`openspec/specs/`** — дом темы `requirements`;
+- **корпус оценки** — пять источников, из которых ты выводишь обе оси; разобран
+  ниже отдельным разделом, потому что это твоя главная работа;
 - **`docs/review.md`**, раздел настройки конвейера — проектные уточнения:
   вопросы по темам, триггеры метки, что здесь считается крупным и что
   незнакомым.
 
+## Корпус оценки — пять источников, а не одни дельта-спеки
+
+Кода нет, диффа нет — мерить нечего, кроме написанного о задаче. Написанного при
+этом много, и **каждый источник отвечает на свой вопрос**. Читай все пять: тот,
+который ты пропустил, — это ось, оценённая по остатку.
+
+| Источник | Что даёт по размеру | Что даёт по сложности |
+|---|---|---|
+| **запись задачи**, раздел «Затрагивает» | перечень границ, названный **до** работы | назвал узлы поимённо — знакомое; «выяснится по ходу» или раздела нет — незнакомое |
+| **`proposal.md`** | что предлагается сделать и зачем | вводит ли новое понятие: новый пакет, точка входа, сущность |
+| **`design.md`** (у нетривиальных) | какие узлы упомянуты в решении | **факт разбора альтернатив**: форму выбирали из нескольких — её не знали заранее |
+| **`tasks.md`** | число шагов и их разнородность: шаги, лежащие в разных узлах и слоях | шаг вида «разобраться», «выяснить», «попробовать» |
+| **дельта-спеки** | сколько capability затронуто и сколько требований в каждой | `ADDED` целой capability — поведения такого рода не было; только `MODIFIED` в одной — было |
+
+**`design.md` информативен и своим отсутствием.** Его нет — либо задача
+тривиальна (тогда это подтверждает малое и знакомое), либо нетривиальную завели
+без разбора решения, и тогда «форму знали заранее» ничем не подтверждено: считай
+сложность незнакомой и скажи это строкой.
+
+**Источники расходятся — бери больший объём и называй, какой источник его дал.**
+Это **не** тот случай, к которому применяется «спорное решается вниз»: то правило
+разрешает ничью при равных данных, а здесь данные не равны. Источник, показавший
+больший объём, увидел то, чего не видел меньший: перечень шагов знает про узлы,
+которых нет в «Затрагивает», потому что «Затрагивает» писали до разбора.
+Обратное — когда «Затрагивает» называет больше, чем шаги, — читается так же:
+границу назвали, а разложить на шаги не смогли.
+
+**Само расхождение — сигнал по второй оси.** Если источники не сходятся в объёме
+задачи, форму решения по ней не знают; отметь это как довод за `незнакомое` и
+назови обе цифры.
+
+Чего в корпусе **нет и не будет: диффа.** Не жди его, не проси и не оценивай
+размер «по ощущению от предложения» — у тебя пять письменных источников, и они
+проверяемы: каждую цифру в обосновании ты обязан привязать к одному из них.
+
 Чего ты **не** читаешь: `docs/adr.*` и `docs/research.*` — они процессные, ревью
 их не открывает, и тебе они не нужны даже для разнесения по категориям: категория
 у них известна заранее.
@@ -179,11 +211,10 @@ color: green
 отдельными строками и не выводи одну из другой — иначе проход, прочитавший
 метку, будет думать, что знает объём диффа.
 
-**Опирайся на факты, а не на впечатление.** Размер считается по дельта-спекам
-(сколько capability затронуто, сколько требований в каждой) и по разделу
-«Затрагивает» в записи задачи. Сложность отвечается по тому же разделу: он
-назван **до** работы, и если он называет узлы поимённо — изменение знакомое.
-Раздела нет или он говорит «выяснится по ходу» — незнакомое. Проектные уточнения — в `docs/review.md`,
+**Опирайся на факты, а не на впечатление.** Обе оси выводятся из корпуса оценки
+— пяти источников выше, — и **каждая цифра в обосновании привязана к источнику
+поимённо**: «размер средний: `tasks.md` даёт шесть шагов в двух узлах». Фраза
+«изменение выглядит средним» обоснованием не является. Проектные уточнения — в `docs/review.md`,
 подраздел «Триггеры метки», **тремя списками**: «крупное здесь» и «незнакомое
 здесь» поднимают метку по своей оси, «мелкое здесь» опускает до `small`. Третий
 список один на обе оси: вниз метку опускает только совпадение обеих сразу.
@@ -276,9 +307,13 @@ color: green
 Строго этот, он уезжает в отчёт целиком и служит границами покрытия:
 
 ```
-размер:    среднее — дельты трогают две capability, «Затрагивает» называет три узла
-сложность: знакомое — все три узла названы в записи задачи до начала работы
-метка:   medium — максимум по осям; ни одна не дала large
+размер:    среднее — tasks.md: 6 шагов в двух узлах; дельты трогают 2 capability;
+           «Затрагивает» называет 3 узла (взято большее — tasks.md)
+сложность: знакомое — «Затрагивает» называет узлы поимённо до начала работы;
+           design.md разбирает одну форму решения, альтернатив не рассматривал
+метка:     medium — максимум по осям; ни одна не дала large
+
+корпус:    запись задачи, proposal.md, design.md, tasks.md, дельта-спеки — все пять
 
 ревью дизайна: specs, rubric
 
@@ -313,11 +348,17 @@ operations      docs/architecture.md, «Эксплуатация» разбор
 ```
 ## Coverage of this pass
 - документов в docs/ найдено N, все N разнесены: тем M, источников K, процессных L
+- корпус оценки: какие из пяти источников прочитаны, какие отсутствуют и что это дало осям
+- расхождение источников по размеру: <какие цифры и какая взята, или «нет»>
 - тем без дома: <перечень или «нет»>
 - вопросов по темам роздано: <число>; адресованных не теме: <перечень или «нет»>
 - чего не смотрел: содержимого документов — по построению; кода и диффа — их ещё нет
 ```
 
+**Строка про корпус обязательна и тогда, когда прочитаны все пять.** Отсутствие
+источника меняет обе оси, и молчащий пропуск здесь дороже прочих: он двигает не
+одну тему, а состав обоих прогонов сразу.
+
 ## Чего ты не делаешь
 
 - **не судишь код** — ни одной находки по существу изменения;