# 45. Корректор метки, доля `small` и корпус оценки (2026-08-07)

Три правки по следам тем
[41](41-task-sizing-once.md)–[44](44-task-label-single-value.md), и все три
закрывают дыры, которые эти решения и открыли.

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

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

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

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

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

## Что из этого следует

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

**С162. Отсутствие сигнала — тоже сигнал, и его надо печатать.** Молчание
корректора неотличимо от его отсутствия, а решения по ним разные.

**С163. Проверка доли формулируется сравнением, а не порогом.** «Меньше, чем
`medium`» считается по любому журналу и не требует спорить о числе; порог «не
больше 30%» спорен ровно настолько, насколько несопоставимы задачи.

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