форма config.yaml сверяется с живым openspec, а не с памятью

Проверка формы знала имя схемы и перечень артефактов константами — и это не наше
решение, а состояние чужого инструмента. OpenSpec переименует артефакт: правила
под прежним именем перестанут применяться, конфиг останется выглядеть
написанным, канон продолжит требовать прежнее. Молчат при этом все три стороны,
и заметить расхождение было некому.

Сторожем поставлено сравнение версий. check спрашивает openspec --version —
десятые доли секунды — и сравнивает major.minor с той, на которой форма
сверялась. Разошлось — замечание, не отказ, с именем команды, которая
перепроверяет. Патч-версия в сравнение не берётся намеренно: формы она не меняет,
а нагоняй на каждый багфикс приучает пролистывать весь блок.

Перепроверяет docs.py openspec-form: берёт openspec templates --json, то есть
перечень артефактов текущей схемы, и печатает, что разошлось с константами.
Дорогой вызов вынесен из check сознательно — он стоит втрое дороже опроса версии,
а ответ меняется только вместе с версией. Дешёвая проверка служит воротами
дорогой, и дорогая не ржавеет, потому что зовут её не по памяти. Чинится
расхождение в плагине, а не в проекте, и команда печатает три адреса правки
списком: константы скрипта, скелет, журнал версий канона.

Пятой проверкой формы стали ключи под rules: — это имена артефактов, и правило,
адресованное несуществующему, не применяется молча. rules.spec вместо
rules.specs даёт конфиг, выглядящий написанным и не работающий.

Первый вариант этой проверки искал ключи отступом по всему файлу и нашёл их
внутри литерального блока context: строки «Language: Russian» и
«av-dev-pm:review-pipeline» выглядят ключами. Оба живых проекта из-за этого
покраснели на правде. Теперь разбор идёт от строки rules: до следующего ключа
нулевой колонки; на тех же проектах чисто, а опечатка в имени артефакта
по-прежнему находится.

Решение — 48.

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

DECISIONS.md

@@ -2258,3 +2258,872 @@ dev-skills — **маркетплейс плагинов**: скилл комм
 126. **Снятое слово называется вместе с заменой и остаётся записанным.** Убрать
      из текстов недостаточно: без записи «это снято и вот чем заменено» слово
      возвращается первым же, кто найдёт его удачным.
+
+## 33. Стоимость ревью: снят самый дорогой проход и самая дорогая модель (2026-08-06)
+
+Прогоны стали долгими, а счёт в токенах — заметным. Разбор шёл не по находкам, а
+по статьям расхода: что в конвейере стоит больше всего и что из этого окупается.
+Две статьи названы прямо оператором.
+
+**ААББОО. Проход независимой реализации снят целиком, и с ним профиль `deep`.**
+`reimpl` писал свою реализацию узла, не открывая существующую, и диффил по
+решениям. Его счёт определялся **объёмом вывода** — он один писал код, а не читал
+его, — и на прогоне это была самая большая строка расхода. Снят по решению о
+стоимости.
+
+Профиль `deep` от этого не «похудел», а исчез: `reimpl` был **единственным**, чем
+он отличался от `wide` (обоим оставалось бы 0, 1, 2, 4, 5). Держать два имени для
+одного состава нельзя — ровно от этой болезни лечилась ступень `wide` (решение
+JJJ): у профиля обязан быть один правильный ответ, иначе реестр состава нечем
+проверять. Ступеней теперь три: `quick`, `standard`, `wide`.
+
+Вместе с профилем ушло всё, что обслуживало только его:
+
+- **барьер стоимости** — он существовал ровно затем, чтобы дорогой проход не
+  писал реализацию против кода, который через час перепишут. Дорогого прохода
+  нет, и граф стал плоским во всех профилях: от гейта до триажа. Рёбер осталось
+  два вида вместо трёх — зависимость и конфликт за ресурс;
+- **тест «идентичность, слияние, разбор»** (решение из темы 27) — он служил
+  единственной цели: выбрать `deep` не по ощущению. Выбирать больше нечего, и
+  полторы страницы теста сняты вместе с проектным перечнем мест в
+  `docs/review.md`;
+- **стадии перенумерованы**: 0 гейт, 1 сверка, 2 враждебный и эксплуатационный,
+  3 архитектурный, 4 триаж. Дыра на месте третьей читалась бы как пропущенная
+  стадия.
+
+**ААББПП. Снятие записано как сознательное сужение, а не как «класс оказался
+пустым».** `calibration.md` требует замера на двух проектах перед удалением
+прохода, и замера не было — было решение о цене. Значит и в «Честном пределе»
+стоит честная строка: **«не знаю, чего не знаю» больше не достаёт никто.** Остаток
+независимого взгляда дают профиль `design` (код пишется под его находки) и
+`architecture` (второй способ, лишние слои), но альтернативной реализации, с
+которой можно сдиффить решения, у конвейера нет. Класс уходит в границы покрытия
+каждого прогона, а у проекта — в подраздел «перестали проверять сознательно».
+
+Без этой записи снятие через месяц читается как «проверено и признано лишним»,
+и вернуть проход было бы не на чем.
+
+**ААББРР. Самая дорогая модель снята со всех проходов.** На ней сидели трое:
+`review-triage`, `review-architecture` и `doc-code-drift` из `av-dev-pm`. Все трое
+переведены на `opus`. Основание для верхней модели — «ошибка распространяется
+дальше самой находки» — никуда не делось, но оно объясняет, почему эти двое **не
+опускаются до `sonnet`**, а не почему им нужна ступень выше `opus`: разницы в
+пользу более дорогой модели не показал ни один прогон, а время и счёт она множила.
+
+Палитра цветов схлопнулась до двух: `sonnet` → green, `opus` → yellow. Красного в
+репозитории больше нет, и `frontmatter.py` теперь отвергнет модель вне этих двух —
+раскладка проверяется механически, как и раньше.
+
+### Что из этого следует
+
+127. **Профиль, у которого не осталось собственного прохода, — не профиль.**
+     Ступень стоимости определяется тем, что она **добавляет**; сняли добавку —
+     сняли ступень, а не оставили имя. Иначе два имени указывают на один прогон, и
+     состав снова нечем проверить.
+128. **Удаление по цене и удаление по замеру записываются по-разному.** Первое
+     обязано назвать класс, который перестал проверяться, и оставить его в
+     границах покрытия. Второе — сослаться на замер. Смешение их даёт самый
+     дорогой вид тишины: пробел, выглядящий как решённый вопрос.
+129. **Механика, обслуживающая один проход, снимается вместе с ним.** Барьер
+     стоимости, тест выбора верхней ступени и проектный перечень мест держались
+     только на `reimpl`. Оставшись, они выглядели бы работающими правилами и
+     тратили бы внимание на каждом прогоне.
+
+## 34. Пропускная способность против глубины: тяжёлые проходы уехали в верхнюю ступень (2026-08-06)
+
+Тема 33 сняла самую большую разовую статью расхода, но не тронула главную —
+**частоту**. Меряющая пара стояла в `standard`, то есть на большинстве задач, и
+именно она делала прогон долгим: два прохода держат машину, идут цепочкой и
+доказывают находки запуском. Разбор шёл от цели, названной прямо: **лучше
+поправить в следующей задаче, чем держать одну два часа.**
+
+**ААББСС. `adversary` и `ops` переехали в `wide`, и это решение по цене, а не по
+ценности.** Стадия осталась самой урожайной за всю историю замеров — пять из семи
+выживших находок дозапуска и единственная находка про молчаливый старт отката. Но
+её ценность оплачивается на **каждой** задаче, а получается на немногих: оракул
+добывается запуском, запуск — это машина, цепочка и часы. Ступень, которая раньше
+была умолчанием, стала исключением на 5–10% задач.
+
+**ААББТТ. Заведён `review-basics` — мелкая осадка двух тяжёлых проходов, без
+единого запуска.** Он стоит только в `standard` и берёт ту половину вопросов, на
+которые отвечают **чтением**: таймаут и отказ соседа, идемпотентность и
+одновременная запись, остановка на середине, частичный откат при двух версиях,
+наблюдаемость и тишина, очевидный рост объёма — плюс два вопроса архитектурного:
+второй способ мимо единой точки (грепом, не картой) и что отсюда удалить. Потолок
+4 находки, машину не держит, ничего не меряет.
+
+Отдельная его обязанность — **вопрос 4, частичный откат**. Без него правило
+«миграция схемы не поднимает ступень» рассыпалось бы: раньше миграцию разбирал
+`ops`, а он теперь в `wide`. Проход заведён не «до кучи», а затем, чтобы у
+`standard` остался хоть один взгляд на ось времени.
+
+Модель у него верхняя, `opus`, и это не противоречит слову «средний»: усилие
+режется **входом и потолком**, а не моделью. Дешёвая модель на опиниативном
+проходе платит триажем — это записанный замер, и отменять его без нового замера
+нельзя.
+
+**ААББУУ. Объём и незнакомость изменения вошли в правило выбора ступени.** Раньше
+ступень выбиралась только по классу («вводит ли новое понятие»), и правило прямо
+запрещало смотреть на размер. Теперь вопросов два: крупное или незнакомое (трогает
+несколько узлов, переносит ответственность, форму решения нащупывают по ходу) →
+`wide`; мелкое (один узел, форма очевидна заранее, откат — обратная правка) →
+`quick`; всё остальное → `standard`. Причина смены: цена разбирательства растёт
+именно с объёмом и неизвестностью, а не с классом правила.
+
+Отрицательный тест `quick` сохранил прежнюю мудрость в новой рамке: **что после
+мерджа не откатывается обратной правкой — не `quick`, каким бы маленьким ни был
+дифф.** Три строки миграции идут в `standard`.
+
+**ААББФФ. Спорный случай решается вниз, и асимметрия объяснена ценой.** Между
+`standard` и `wide` — в пользу `standard`: ошибка сюда стоит находки на следующей
+задаче, ошибка обратно стоит трёх тяжёлых проходов на каждой задаче, выбранной
+неверно. Между `quick` и `standard` — тоже в пользу `standard`, но по другой
+причине: там разница в один дешёвый проход, зато единственный, кто на нижних
+ступенях смотрит на отказы.
+
+Доля `wide` 5–10% записана как **проверка правила, а не пожелание**: если ступень
+уходит каждой третьей задаче, её выбирают по ощущению важности.
+
+**ААББХХ. Сделка записана вместе с механизмом обратной связи, иначе это тихая
+потеря качества.** На `quick` и `standard` не проверяется ничего, что требует
+запуска: построенный путь, эксперимент против драйвера, любое число. Это самая
+крупная граница покрытия конвейера, и она обязана идти строкой в каждом таком
+прогоне поимённо. Обратная связь — журнал дефектов `docs/review.md`: класс,
+который ловят только меряющие проходы, начал всплывать после мерджа — значит
+ступень выбирают слишком низко. Плюс сам `basics` обязан сигналить строкой, если
+видит, что ступень занижена: он единственный, кто смотрит на дифф целиком на
+нижних ступенях.
+
+### Что из этого следует
+
+130. **Стоимость прохода — это его цена, умноженная на частоту, и вторая
+     переменная важнее.** Тема 33 убрала самый дорогой проход, тема 34 —
+     самый частый. Второе дало больше, хотя снятый проход был дешевле каждого
+     отдельного `reimpl`.
+131. **Урожайность прохода не отвечает на вопрос, где ему стоять.** Меряющая пара
+     осталась самой ценной и всё равно уехала вверх: ценность оправдывает
+     существование прохода, но не его частоту.
+132. **Замена тяжёлого прохода лёгким записывается как сужение, а не как
+     эквивалент.** `basics` задаёт те же вопросы чтением, и его ответы поэтому
+     слабее — условия вместо оракулов. Назвать это «покрыли то же дешевле» значит
+     соврать себе на первом же прогоне.
+133. **Ступень, выбираемая по классу изменения, слепа к объёму.** Правило,
+     запрещавшее смотреть на размер, защищало от выбора по ощущению важности — и
+     заодно отправляло трёхстрочную правку и переборку пяти узлов в один профиль.
+     Признаков нужно два: класс отвечает за обратимость, объём — за цену
+     разбирательства.
+
+## 35. Ревизия моделей: переведены двое из девяти, и критерий оказался не тот (2026-08-06)
+
+Сквозной проход по тринадцати уставам с одним вопросом: кого из девяти
+`opus`-агентов можно опустить на `sonnet` без потери. Ответ — двоих, и по дороге
+выяснилось, что критерий, которым конвейер до сих пор раздавал модели, отвечает
+не на тот вопрос.
+
+**ААББЦЦ. Модель выбирается по цене ошибки, а не по роду прохода.** Прежнее
+деление — applicative против generative — раздаёт модели по тому, **откуда**
+проход берёт критерий. Но платит проект не за происхождение критерия, а за
+разбирательство с находкой. Рабочий признак:
+
+- находка приходит **со ссылкой на записанный источник** (строка спеки, цель в
+  манифесте, значение в конфиге, номер правила) — её опровержение стоит одного
+  открытия файла. Дешёвая модель ошибается здесь **проверяемо**;
+- находка есть **суждение** («это второй способ», «этот оракул негоден», «эти два
+  документа противоречат») — опровержение стоит рассуждения, а рассуждение стоит
+  триажа или человека.
+
+Признак объясняет прежнюю раскладку лучше, чем она сама себя: `gate`, `code` и
+`ops` не потому дёшевы, что применяют чек-лист, а потому, что каждая их находка
+показывает пальцем на строку.
+
+**ААББЧЧ. `doc-code-drift` → `sonnet`.** У него закрытый перечень из восьми
+правил, и каждое — пара «факт в документе ↔ команда, которой он проверяется».
+Устав прямо запрещает суждение («верность и полноту не проверяешь»), требует
+формы «написано X, в коде Y, проверено командой Z» и правила «нечем проверить —
+не находка». Ложная находка опровергается **той же командой, которая её
+породила**. Это самый чистый случай признака за весь разбор.
+
+**ААББШШ. `task-form` → `sonnet`.** Семь пронумерованных правил с таблицами форм
+и поимённым перечнем подмен. Но решило не это, а потребитель: его находка —
+готовая формулировка, которую человек читает и отклоняет командой, а не
+оркестратор, который **молча реализует**. Довод, державший `triage` на верхней
+модели, здесь не работает вовсе: ошибка стоит строки чтения.
+
+**ААББЩЩ. `review-specs` рассмотрен и оставлен на `opus` — по причине, обратной
+общей.** Он самый частый `opus`-проход конвейера (идёт и в `design`, и на коде,
+то есть дважды за задачу), и по устройству он applicative: SKILL.md сам называет
+стадию 1 «два applicative-прохода, оба дешёвые», хотя платит за одного `sonnet`, а
+за другого `opus`. Расхождение разобрано и закрыто текстом: держит его наверху
+направление `code → spec`, где надо заметить **отсутствие** — тихий фолбэк,
+самодеятельный дефолт, проглоченную ошибку. Прочие держат `opus` из-за цены
+ложных находок, этот — из-за цены пропущенных, а пропуск не оставляет следа
+нигде: ни в отчёте, ни в границах покрытия.
+
+**ААББЭЭ. Остальные шестеро оставлены, и у каждого своя причина.**
+`adversary` и `rubric` порождают критерий по построению (второй — с запретом
+открывать код в первой фазе). `architecture` — чистое суждение о структуре.
+`triage` — сток, его ошибка становится кодом. `doc-consistency` ошибается ровно в
+ту сторону, которую дороже всего опровергать: путает «упомянуто в двух местах» с
+«оба утверждают». `basics` заведён час назад, половина его вопросов — суждение, и
+модель у него выбрана решением оператора в этой же сессии.
+
+**ААББЮЮ. Это разбор уставов, а не замер, и так и записано.** `calibration.md`
+двигает модель инъекцией дефекта; здесь инъекции не было. Двое переведены потому,
+что их ошибка **обнаруживается той же проверкой, что породила находку**, — то
+есть цена ошибки ограничена сверху независимо от модели. Для остальных такой
+границы нет, и трогать их без замера нельзя.
+
+### Что из этого следует
+
+134. **Дешёвая модель безопасна там, где её ошибку опровергает та же команда,
+     что породила находку.** Не «где критерий записан» — записанный критерий
+     бывает и у суждения, и у сверки, а разница между ними в том, чем кончается
+     спор.
+135. **Ошибка бывает двух родов, и модель защищает от разных.** Ложная находка
+     стоит триажа и видна; пропущенная не стоит ничего сегодня и не видна вовсе.
+     Проход, у которого дороже второе, держится на верхней модели даже будучи
+     applicative.
+136. **Потребитель находки — часть её цены.** Одна и та же ошибка стоит строки
+     чтения, если её читает человек, и разросшегося кода, если её молча реализует
+     оркестратор. Модель раздаётся с оглядкой на это, а не только на устройство
+     прохода.
+
+## 36. Темы ревью: документ проекта стал направлением проверки (2026-08-06)
+
+Замечено при сверке документов канона с составом ступеней: **три документа
+остались без читателя ниже `wide`** — `security.md`, `database.md` и `adr/`.
+Проект поддерживал их, а на 90% задач их не открывал никто. Причина оказалась не
+в переезде проходов, а в том, как описан состав прогона.
+
+**ААББЯЯ. Тема первична, проход вторичен, и это правило 0 конвейера.** Список тем
+нигде не был записан: он существовал побочным продуктом списка проходов. Проход
+уезжал в верхнюю ступень — и тема уезжала с ним **беззвучно**: отчёт честно
+говорил «`ops` не запускался» и не говорил «эксплуатацию не смотрел никто», а
+нужно второе. Теперь прогон описывается таблицей «тема → дом → глубина → кто
+закрывает», и таблица есть в каждом отчёте.
+
+**АВААА. Тема есть документ, и список тем открытый.** Всё, что проект кладёт в
+`docs/`, становится темой ревью; запретить нельзя, разрешения не надо. Не темы
+ровно две: `docs/tasks/` и `docs/review.*` (настройка самого конвейера — слой над
+темами). Отсюда главное следствие: **`docs/` перестал быть документацией и стал
+конфигурацией конвейера.** Проект настраивает проверку тем, что пишет о себе, а
+не отдельным файлом настроек, который разошёлся бы с документами.
+
+Ядро — шесть тем: `requirements`, `autotests`, `conventions`, `architecture`,
+`security`, `operations`. Их дома канон обещает. Всё сверх — темы проекта, и их
+разбирает `basics`: именных проходов конечное число, а тем столько, сколько
+заведёт проект, поэтому приёмник обязателен.
+
+**АВААБ. Тема живёт файлом или каталогом, на выбор проекта.** `docs/security.md`
+и `docs/security/` — одно и то же. Прежде форма была задана поимённо
+(`conventions`, `research`, `adr` — каталоги, остальные — файлы), и обосновать
+это было нечем; заодно в TODO висел открытый вопрос «а если `architecture.md`
+разрастётся». Теперь ответ механический: разросся — стал каталогом с `README.md`,
+и это не смена версии канона. Обе формы сразу — ошибка, и `docs.py` её ловит: два
+дома для одного факта расходятся молча.
+
+**АВААВ. Ступень выбирает разметчик, а не автор.** Заведён `review-scope`
+(`sonnet`), стадия 0, до гейта: находит документы, выводит темы, назначает
+глубины, выбирает ступень с обоснованием. Довод сильнее, чем синхронизация
+документов: **до сих пор профиль называл тот же оркестратор, который написал
+код** — то есть в точке выбора глубины проверки разведённости с автором не было
+вовсе, и решала она под давлением «я почти закончил». Вызывающий пайплайн профиль
+больше не передаёт.
+
+Право у разметчика симметричное — поднять и понизить, — но обоснование
+обязательно всегда, а не только при отступлении от умолчания.
+
+**АВААГ. Разметчик передаёт адреса, а не пересказ.** Проект однажды уже держал
+файл-посредник между документами и проходами (`review-brief.md`) и убрал его:
+второй дом расходится с первым и выглядит актуальным. Пересказ в задании — тот же
+посредник, живущий один прогон. Исключение одно: **отсутствие дома** — этого
+проход сам дёшево не выяснит.
+
+`sonnet` ему хватает потому, что вывод устроен как **список**: каждый файл в
+`docs/` обязан попасть в план темой или строкой «не тема, потому что», и план
+сверяется с `ls docs/` за секунду. Выбор ступени — суждение, но у него три
+независимых корректора: отрицательный тест `quick`, правило «спорный случай
+вниз» и сигнал `basics` о заниженной ступени.
+
+**АВААД. `quick` и `standard` совпали составом и разошлись глубиной.** Требование
+«нижние ступени закрывают все темы, просто не так глубоко» иначе не выполняется:
+темы одни и те же, а различать ступени больше нечем. Глубин три и они про способ
+доказательства, а не про старательность: **сверка** (открыть дом, открыть дифф,
+сравнить), **разбор** (построить сценарий рассуждением), **доказательство**
+(прогнать, померить, построить путь). Третья есть только в `wide` — она одна и
+требует машины.
+
+Цена принята: это единственное место конвейера, где профиль не выводится из
+списка проходов, поэтому глубина объявляется в отчёте наравне со ступенью.
+
+**АВААЕ. `review-code` переписан: технический разбор плюс конвенции.** Обнаружено
+по ходу: **никто не читал код как код.** `specs` сверял с требованиями, `basics` —
+с отказами окружения, `architecture` — с устройством, а `code` был проходом
+только по прозаическим конвенциям и прямо объявлял, что дефекты рантайма и логики
+не его. «Здесь ошибка в логике» не говорил никто, и это была самая крупная дыра
+конвейера — крупнее любой недосмотренной темы.
+
+Теперь у прохода две половины: девять классов технического дефекта (необработанная
+ветка отказа, пустое и нулевое, граница диапазона, перепутанный операнд,
+неосвобождённый ресурс, изменение под итерацией, неверно применённый интерфейс
+библиотеки, недостижимая ветка, «сделано соседнее») и прежняя сверка с
+конвенциями. Модель поднята до `opus` по признаку темы 35: цена **пропущенной**
+находки — дефект в проде, и она не оставляет следа ни в отчёте, ни в границах
+покрытия.
+
+**АВААЖ. Вопросы проекта переадресованы темам.** В `docs/review.*` было «Вопросы к
+проходам» в форме `ops: <вопрос>` — и когда `ops` уехал в `wide`, вопрос перестал
+задаваться молча. Стало «Вопросы по темам». Туда же «Недоступно проверке» — по
+темам, обоими подразделами.
+
+### Что из этого следует
+
+137. **Состав, описанный исполнителями, теряет предмет при перестановке
+     исполнителей.** Список проходов отвечает «кто работал», а нужен ответ «что
+     проверено». Первое выглядит полным ровно тогда, когда второе неверно.
+138. **Открытый список нуждается в приёмнике, иначе он обещание.** Разрешить
+     проекту завести свою тему и не назначить, кто её разбирает, — то же, что не
+     разрешать.
+139. **Регулятор глубины проверки нельзя оставлять в руках автора.** Не потому
+     что он злонамерен, а потому что давление «я почти закончил» действует
+     всегда и в одну сторону.
+140. **Дыру в покрытии находят не там, где ищут находки.** Три осиротевших
+     документа нашлись сверкой канона с составом ступеней, а отсутствие
+     технического ревью кода — сверкой оптик проходов между собой. Ни то ни
+     другое не всплыло бы на прогоне: прогон честно сообщал, что все запущенные
+     проходы отработали.
+
+## 37. `gate` и `autotests` сведены к одному имени (2026-08-07)
+
+Тема звалась `autotests`, закрывающий её проход — `gate`, и на всех трёх ступенях
+это была одна и та же клетка таблицы. Одна сущность под двумя именами — та же
+ошибка, что и два разных под одним, только тише: она не путает, а **теряет**.
+Вопрос проекта в `docs/review.*` адресуется теме; адресованный проходу — не
+приезжает никуда, и ровно этот отказ уже случился однажды с `ops` (тема 36, АВААЖ).
+
+**АГААА. Победило имя темы, а не имя прохода.** Три довода, по убыванию веса:
+
+1. **Тема первична (правило 0), а имена тем — это имена документов.**
+   `docs/autotests.md` проект напишет: что покрыто, что нарочно нет, где
+   `testdata`. `docs/gate.md` не напишет никто — гейт это команда, а не предмет.
+2. **Слово «гейт» уже занято дважды** — команда проекта и ребро графа («пока гейт
+   красный, опиниативные не идут»). Третье значение сделало бы отчёт нечитаемым:
+   «гейт красный» и «гейт нашёл» — про разное.
+3. **Тема шире гейта.** «Хватает ли проверок» и «чего в гейте намеренно нет» за
+   пределы красного/зелёного выходят. Назвать целое именем инструмента — тихо его
+   сузить.
+
+Цена названа честно: `autotests` звучит уже своего содержимого — линт, типы,
+сканер уязвимостей тестами не являются. Гасится строкой в уставе: тема — это
+«проверено ли машиной», а не «есть ли тесты», и гейт в ней инструмент, а не
+граница.
+
+### Что из этого следует
+
+141. **Тема и проход, совпадающие один в один на всех ступенях, обязаны носить
+     одно имя.** Пока имён два, у сущности два адреса, а адресуют её по одному —
+     и какой из двух окажется живым, решает случай.
+142. **Слово, уже значащее что-то в предметной области проекта, нельзя брать
+     именем роли конвейера.** «Гейт» принадлежит проекту раньше, чем ревью, и
+     спор за него ревью проигрывает.
+
+## 38. Шов между плагинами: канон не называет имён проходов (2026-08-07)
+
+Замечено при сведении тем документации с ревьюверами: `av-dev-pm` в шести местах
+называл конвейер поимённо — от прозы канона до **вывода `docs.py` пользователю**
+(«свои темы проекта: … — их разбирает `review-basics`»). Плагины при этом
+раздельные: `av-dev-pm` работает без конвейера, `av-dev-pipeline` — без канона,
+поразрядно деградируя.
+
+**АДААА. Общий словарь — имена тем и имена ступеней, и только они.** Ими проект
+настраивает ревью: вопросы по темам и триггеры профиля. Имён проходов канон не
+называет нигде. Направление зависимости при этом несимметрично и это верно:
+**конвейер называет документы канона поимённо, потому что он их читатель**, а
+обратной ссылки быть не может — документ живёт дольше, чем раскладка проходов.
+
+Заодно вычищены описательные адресации того же класса: «архитектурный проход
+судит», «враждебный проход выдумает», «там идут враждебный, эксплуатационный и
+архитектурный проходы». Последняя — худшая из них: это утверждение о **составе
+ступени**, живущее на стороне, которая о составе не знает.
+
+**АДААБ. Пример в правиле не должен нарушать само правило.** Объяснение, почему
+вопросы адресуются темам, звучало так: «вопрос, адресованный `ops`, перестал
+задаваться в тот день, когда `ops` уехал в верхнюю ступень». Правило про
+нестабильность имён, иллюстрированное именем. Стало «адресованный проходу» — и
+работает даже после того, как проход переименуют.
+
+### Что из этого следует
+
+143. **Ссылка из вывода скрипта дороже ссылки из прозы.** Устаревшую строку в
+     документе чинит тот, кто её читает; устаревшее имя в сообщении `docs.py`
+     доезжает до чужого проекта и там объясняется недоумением.
+144. **Список, который никто не ведёт, честнее списка, который ведут двое.**
+     Читателей документа не перечисляет ни одна сторона — читатель назначается
+     планом прогона. Прежняя ссылка на «таблицу читателей» пережила саму таблицу
+     и обещала то, чего нет, — с той самой правки, которая таблицу и убрала.
+
+## 39. Спринт без цели — законный случай (2026-08-07)
+
+Цель была обязательной: `sprint start --goal` требовал слаг, `check` считал
+ошибкой набор без названной цели, `sprint take` отказывал задаче под чужой
+целью. Модель описывала только спринт развития — а спринт бывает под багфикс,
+под техдолг, под здоровье проекта. Такой набор собран **по работоспособности, а
+не по направлению**, и цели у него нет не по недосмотру.
+
+Обходной путь существовал и был хуже прямого: завести цель-пустышку («Здоровье
+проекта») и вешать под неё `fix`-и. Тогда `ROADMAP.md` — документ про то, что
+приложение умеет, — обрастает строками про то, что оно не ломается, а тег
+`goal:` перестаёт значить направление.
+
+**АЕААА. Цель у спринта необязательна, но её отсутствие — ответ, а не молчание.**
+`sprint start` принимает `--goal <слаг>` **или** `--no-goal`, и голое отсутствие
+обоих — отказ с объяснением. Причина в стимуле: цель называет человек, и это
+единственный продуктовый вопрос всей сессии. Разреши мы заводить спринт просто
+без флага — забытый флаг, лень спросить и осознанное решение стали бы неотличимы
+на выходе, а дешевле всего из трёх агенту именно не спрашивать.
+
+**АЕААБ. В спринте без цели цель не проверяется вовсе.** Набор берёт что угодно
+готовое к взятию, включая задачи под разными целями: сверять не с чем. Правило
+«набор служит одной цели» не ослаблено, оно просто не применяется — целей в
+таком наборе не больше одной, их ноль. Взамен машинной проверки остаётся показ
+набора человеку до заморозки: у бесцельного спринта это **единственная**
+проверка состава, и в скилле это сказано прямо.
+
+**АЕААВ. Признак «спринт идёт» — слаг, а не цель.** Прежде код спрашивал цель и
+получал заодно ответ про то, открыт ли спринт; теперь эти вопросы разошлись.
+Слаг подходит на роль признака лучше цели по существу: он есть у любого спринта,
+потому что без него нечем проставить `sprint:<слаг>`, то есть нечем собрать
+урожай. Поле «Цель» в шапке остаётся на месте и у бесцельного набора — пишется
+прозой без ссылки: **«цели нет» и «цель потерялась» обязаны различаться**.
+
+### Что из этого следует
+
+145. **Необязательное поле, которое всё же решают, заводится парой «значение или
+     явный отказ».** Умолчанием тут был бы не выбор, а его отсутствие — и
+     отличить его от забывчивости уже не смог бы никто, включая автора.
+146. **Признак «сущность существует» нельзя вешать на её необязательное поле.**
+     Пока цель была обязательной, `sprint_goal()` отвечал сразу на два вопроса,
+     и это работало ровно до тех пор, пока второй ответ не понадобился отдельно.
+147. **Снятая проверка называет, что осталось вместо неё.** Цель не проверяется
+     — значит, за состав отвечают показ человеку и строка доклада; иначе
+     послабление читается как «здесь можно не думать».
+
+## 40. Три категории документов: не всякий документ — тема ревью (2026-08-07)
+
+Решение 36 объявило: **каждый документ проекта — тема ревью**. Правило дало
+открытый список тем и сделало `docs/` конфигурацией конвейера — это работает и
+остаётся. Но оно же оказалось неверным ровно наполовину, и потому вредным
+целиком.
+
+Паспорт и схему хранилища ревью читает, но темами они не являются: по ним нельзя
+сказать «в этом изменении сделано не так», они задают границу, по которой судит
+**чужая** тема. Журнал решений и журнал наблюдений ревью изменения не нужны
+вовсе: ADR объясняет прошлое решение, а не предъявляет требование к изменению.
+
+Ломалось это механически. Разметчик, применявший правило буквально, обязан был
+либо завести фантомные темы `passport`, `adr`, `database`, `research` и
+продублировать ими работу тем `architecture` и `operations`, либо потерять четыре
+документа молча. Обе ветки случались; в собственном образце плана разметчика
+`docs/passport.md` не попадал ни строкой, а его же обязательная арифметика
+покрытия («документов найдено N, все N разнесены») при этом не сходилась.
+
+**АЕАБА. Разрез один и проверяемый: можно ли по документу сказать «в этом
+изменении сделано не так».** Отсюда три категории. **Тема** — да, прямо
+(`conventions`, `security`, `architecture`, свои документы проекта). **Источник
+темы** — нет, но он задаёт границу для чужой темы (`passport`, `database`,
+`CLAUDE.md`, `openspec/specs/`). **Процессный документ** — нет, он про то, как мы
+работаем (`tasks/`, `review.*`, `adr.*`, `research.*`, `.pm.json`).
+
+**АЕАББ. Открыта одна категория из трёх.** `источник` и `процессный` перечислены
+поимённо и проектом не пополняются; открыта только `тема`. Прежняя формулировка
+«не темы ровно две» противоречила собственной раскладке канона — `.pm.json` был
+третьим, и правило-исправление жило в чужом плагине, в коде `docs.py`. Теперь
+документ, которого нет в раскладке, — однозначно своя тема проекта, и решать
+нечего.
+
+**АЕАБВ. «Не судит по нему» и «не открывает» — разные вещи.** `docs/review.*`
+проходы читают на каждом прогоне: там вопросы по темам, журнал дефектов, типовые
+узлы, типовые ложноположительные. Это чтение конвейером **своей обвязки**, а не
+критерия. `adr/`, `research/` и `tasks/` не открывает никто.
+
+**АЕАБГ. Цена решения записана, а не подразумевается.** Расхождение изменения с
+записанным решением прогоном больше не ловится — это работа сверки документации
+между спринтами. Измеренные числа проекта из ревью тоже ушли: проход,
+опирающийся на число, обязан **снять его сам, на этом прогоне**, и приложить
+команду замера. Обе потери идут обязательными строками в границы покрытия
+каждого прогона, и пишет их триаж — не проход, потому что проход о том, чего в
+конвейере нет, пожаловаться не может.
+
+### Что из этого следует
+
+148. **Плоское правило, верное наполовину, хуже двух правил.** Оно не даёт
+     половине случаев легального ответа, и исполнитель выбирает между двумя
+     плохими ветками — фантомной сущностью и молчащей потерей. Заметно это
+     становится не на определении, а на первом же образце вывода.
+149. **Открытым делается одно множество, а не все.** Открытый список ценен тем,
+     что в него попадает незнакомое; если открыты все категории, незнакомое
+     попадает в произвольную.
+150. **Отказ читать документ — тоже граница покрытия, и её пишет сток.** Строку
+     «этого не смотрел никто» некому подать снизу: проход, которого нет, отчёта
+     не присылает.
+
+## 41. Разметка задачи: одна величина, посчитанная один раз (2026-08-07)
+
+Разметка была стадией 0 **ревью кода** и платилась на каждом прогоне. Перед ревью
+дизайна ту же самую величину — «крупное или незнакомое?» — называл сам пайплайн
+задачи, то есть оркестратор, который только что довёл предложение до `propose`.
+Одно и то же измерялось дважды, и один из двух раз без разведённости с автором —
+ровно в той точке, ради которой разметчик и заведён.
+
+**АЕАВА. Разметка идёт один раз на задачу, сразу после `propose`.** Её план
+обслуживает обе стадии ревью: состав ревью дизайна и таблицу тем для ревью кода.
+Диффа она не видит — кода ещё нет; размер оценивается по дельта-спекам и перечню
+границ задачи.
+
+**АЕАВБ. Осей две, ступень — максимум по ним.** **Размер** (малое, среднее,
+крупное) — про объём; **сложность** (знакомое, незнакомое) — про то, известна ли
+форма решения заранее. Раньше обе были склеены в один вопрос «крупное **или**
+незнакомое?»: ответ получался тот же, но разметка не могла сказать «среднее, но
+совершенно знакомое» — а это и есть рабочее умолчание.
+
+**АЕАВВ. Ступень после кода не пересматривается.** Дифф может выйти крупнее
+ожидания — ступень не двинется. Пересмотр означал бы либо второй запуск
+разметчика (то, ради устранения чего он и переехал), либо машинный порог, который
+на нетипичной задаче срабатывает не туда. Расхождение факта с разметкой ловит
+журнал дефектов, постфактум, — так же, как и всякую другую ошибку выбора ступени.
+
+**АЕАВГ. План на диск не пишется.** Файл-план стал бы четвёртым артефактом рядом
+с `proposal.md`, `tasks.md` и `design.md`, пережил бы задачу и разошёлся бы с ней
+молча. Прервался пайплайн — разметка повторяется; это самый дешёвый его проход.
+
+### Что из этого следует
+
+151. **Величина, из которой выводится состав, считается один раз и одним
+     агентом.** Два места, считающие одно и то же, расходятся; расходятся они
+     молча, и побеждает то, у которого меньше разведённости с автором.
+152. **Разведённость — свойство момента, а не роли.** Тот же агент, спрошенный
+     до написания кода и после, даёт разные ответы; переезд по времени сделал
+     больше, чем сделал бы любой запрет.
+
+## 42. `quick` стал дешевле `standard` тремя способами (2026-08-07)
+
+`quick` и `standard` совпадали составом (шесть проходов) и различались глубиной
+трёх тем: сверка против разбора. На практике это означало один проход, задающий
+на один вопрос меньше, и потолок 4 вместо 2. Нижняя ступень не экономила почти
+ничего и называлась отдельной ступенью зря.
+
+Отдельно выяснилось, что дешевизна конвейера держалась на двух заявленных
+рычагах — узкий вход и потолок находок, — и **оба применялись к одному проходу
+из шести**. У `specs` и `code` потолка не было вовсе, а вход `code` включал
+чтение дома конвенций «весь и целиком» на каждой задаче.
+
+**АЕАГА. `quick` теряет приёмник тем.** Темы `security`, `operations` и
+`architecture` на этой ступени закрывает `code` сверкой с **записанными
+инвариантами** `CLAUDE.md`, потолком 1 находка на все три. Это не «глубина
+ниже» — это **другой дом темы**, куда более узкий, и в плане он так и называется.
+
+**АЕАГБ. Приёмник тем запускается тогда и только тогда, когда ему есть что
+принимать.** Правило было в `wide` («нет своих тем проекта — не запускается») и
+теперь распространено на `quick`. Совпадение неслучайное: темы ядра `basics`
+держит ровно на одной ступени из трёх, а приёмником проектных тем работает на
+всех.
+
+**АЕАГВ. Вход и потолок применены к каждому опиниативному проходу.** На `quick`
+`specs` читает только дельта-спеку, `code` — только индекс конвенций. Потолки
+напечатаны и раздельны по половинам `code`: 3 технических, 2 конвенционных, 1 по
+инвариантам. Раздельность обязательна — конвенционных находок больше по
+построению, и в общем списке они вытеснили бы техническую половину, чей пропуск
+дороже.
+
+**АЕАГГ. Сработавший потолок объявляется.** Проход, срезавший находки, говорит
+строкой, сколько осталось за срезом и какого рода. Молчащий срез неотличим от
+«больше не нашлось» — тот же класс молчащего пропуска, против которого написан
+весь конвейер.
+
+**АЕАГД. Отрицательный тест `quick` стал жёстче, а не мягче.** Вопросы «обратима
+ли миграция» и «что с записями новой версии после отката» задавал приёмник тем; на
+`quick` его нет. Значит изменение, которое не откатывается обратной правкой, на
+`quick` не идёт вовсе — каким бы малым оно ни было.
+
+### Что из этого следует
+
+153. **Ступень, не дающая экономии, не нужна.** Две ступени, различающиеся одним
+     вопросом одного прохода, — это одна ступень с шумом в отчёте.
+154. **Рычаг, применённый к одному исполнителю, — не рычаг, а исключение.**
+     Заявленный механизм экономии проверяется перечислением: к кому он применён и
+     к кому нет.
+155. **Проход без потолка выдаёт столько находок, сколько нашёл поверхностей.**
+     Ровно из-за этого был снят проход независимой реализации; тот же механизм
+     работал у `code` и `specs` и не был замечен, потому что счёт никто не считал.
+
+## 43. Ревью дизайна тоже растёт ступенями (2026-08-07)
+
+Состав ревью дизайна включался одним условием: `specs` всегда, `rubric` и
+`architecture` — вместе, «при крупном или незнакомом». Значит `standard` получал
+на предложении ровно один проход, то есть не отличался от `quick` ничем.
+
+**АЕАДА. Три ступени вместо двух: `quick` — `specs`; `standard` — плюс `rubric`;
+`wide` — плюс `architecture` и вопрос автору о трёх формах решения.**
+
+**АЕАДБ. Рубрика съехала вниз, архитектура осталась наверху, и это не
+симметричная правка.** Они зарабатывают на разном. Рубрика порождает **свойства
+узла** и окупается уже на среднем изменении: её выход уезжает приёмочными
+критериями в `tasks.md` и работает потом на всей задаче. Архитектура отвечает на
+вопрос «не появился ли второй способ», а он на среднем знакомом изменении
+отвечается «нет» ещё до запуска — держать её ниже `wide` значит платить за
+предсказуемый ответ на каждой задаче.
+
+**АЕАДВ. Тривиальность задачи больше не решает состав ревью.** Раньше она решала,
+звать ли ревью предложения вовсе; теперь глубину обеих стадий называет ступень, а
+тривиальная задача просто получает `quick`. «Пропустить ревью дизайна» и «пройти
+его одним самым дешёвым проходом» — разные вещи: сверка дельта-спек стоит
+меньше, чем разбор того, что она поймала бы на готовом коде.
+
+### Что из этого следует
+
+156. **Проходы, включаемые одним условием, стоит разводить по тому, на чём они
+     зарабатывают.** Общее условие — признак того, что их не сравнивали между
+     собой, а не того, что они равноценны.
+157. **Средняя ступень обязана отличаться от нижней на обеих стадиях.** Иначе
+     «рабочее умолчание» отличается от исключения только именем.
+
+## 44. Метка задачи: одно значение, по которому выбираются все ревьюверы (2026-08-07)
+
+Решения 41–43 развели классификацию на две оси и свели состав обеих стадий ревью
+к их максимуму. Значения этого максимума назывались `quick`, `standard`, `wide`,
+а сам он — «ступень». Оба имени описывали **ревью**: как глубоко смотрим, на
+какой ступеньке идём. Классифицируется же при этом **задача**, и результат
+классификации принадлежит ей, а не прогону.
+
+Расхождение не косметическое. Пока величина называлась свойством ревью, её было
+естественно пересчитать на каждом прогоне — что конвейер и делал, пока разметка
+не переехала к `propose`. Имя тянуло назад к устройству, из которого её только
+что вынули.
+
+**АЕАЕА. Классификация выдаёт задаче метку: `small`, `medium` или `large`.**
+Метка принадлежит задаче, ставится один раз при разметке и дальше только
+читается. Все проходы обеих стадий получают её в задании и обязаны напечатать в
+границах покрытия.
+
+**АЕАЕБ. Метка — единственный вход выбора исполнителей.** Ни класс задачи, ни её
+тип, ни тривиальность, ни ощущение важности состав больше не определяют. У
+конвейера один переключатель, и он напечатан в каждом отчёте.
+
+**АЕАЕВ. Слово «ступень» удалено, а не оставлено синонимом.** Два имени одной
+вещи расходятся — это ровно решение #37 про тему и проход. Метка ordered: `small`
+< `medium` < `large`, и там, где нужен порядок, говорится «младшая» и «старшая
+метка», а не вводится второе существительное.
+
+**АЕАЕГ. Метка — не синоним размера, и это записано там, где ошибиться легче
+всего.** Совпадают они в одном углу таблицы из трёх: малое **незнакомое**
+изменение получает `large`, трогая один узел. Поэтому план печатает три строки —
+размер, сложность, метка, — каждую со своим обоснованием, и выводить одну из
+другой запрещено. Проход, определивший объём диффа по метке, ошибётся именно на
+том случае, ради которого верхняя метка и заведена.
+
+### Что из этого следует
+
+158. **Имя величины должно называть её носителя, а не потребителя.** «Ступень
+     ревью» звала пересчитывать себя на каждом прогоне ревью; «метка задачи»
+     считается там же, где живёт задача.
+159. **Переключатель состава должен быть один и печатный.** Пока их два —
+     тривиальность и ступень, — состав выводится из пересечения, а пересечение
+     нигде не напечатано целиком.
+160. **Русские слова для осей, английские для значения.** Оси — суждение и
+     читаются прозой (`малое`, `знакомое`); метка — идентификатор, который
+     проходы сравнивают, и потому она английская. Тот же разрез, что «имена
+     файлов английские, текст русский» в каноне, и он же снимает путаницу
+     «крупное» против `large`.
+
+## 45. Корректор метки, доля `small` и корпус оценки (2026-08-07)
+
+Три правки по следам решений 41–44, и все три закрывают дыры, которые эти решения
+и открыли.
+
+**АЕАЖА. Сигнал о заниженной метке переехал в `review-code`.** Он жил в
+`review-basics` — единственном месте. А `basics` с меткой `small` не запускается,
+если у проекта нет своих тем: значит на типичном проекте задача с меткой `small`
+шла **без рантайм-проверки** того, что метка верна. Дыра появилась ровно вместе с
+удешевлением `small` и попала в самую вероятную точку ошибки: занижают туда, где
+дешевле, а цена занижения там же и выросла — три темы ядра смотрятся только
+против инвариантов.
+
+`code` подходит по построению: он идёт при **любой** метке, видит дифф целиком, а
+на `small` уже читает инварианты — то есть держит в руках весь материал, из
+которого сигнал выводится. У `basics` сигнал остаётся вторым, подтверждающим: он
+смотрит оптикой тем и видит то, чего не видно из кода как кода, — что вопросов,
+отложенных до `large`, накопилось слишком много. Триаж теперь обязан сказать и
+когда сигнала **нет**: «корректор отработал, возражений нет» и «корректор не
+запускался» по молчанию неразличимы.
+
+**АЕАЖБ. У `small` появилась доля, и она сформулирована сравнением, а не числом.**
+`small` не должен обгонять `medium`; ориентир — до трети задач. Проверка нужна
+именно теперь: пока `quick` и `standard` совпадали составом, дрейф между ними не
+стоил ничего, и её не было. Сейчас он стоит трёх тем ядра. У дрейфа вниз есть
+стимул, и он назван: метку выбирает не автор, но по описанию, написанному
+автором, — занижённое описание даёт занижённую метку без чьего-либо умысла.
+
+**АЕАЖВ. Размер оценивается по корпусу из пяти источников, а не по дельта-спекам.**
+Разметчик читал `proposal.md` и `tasks.md`, но `design.md` не открывал вовсе, а
+метод был описан одной фразой «размер считается по дельта-спекам». Дельты
+описывают заказанное **поведение** и молчат об объёме работы: шесть шагов в двух
+узлах видны в `tasks.md`, а факт, что форму решения выбирали из нескольких, —
+только в `design.md`. Каждый источник получил свою строку по каждой оси, и каждая
+цифра в обосновании обязана быть привязана к источнику поимённо.
+
+Отсюда два правила, которых раньше не было. **Расхождение источников по объёму
+разрешается в пользу большего** — и это не «спорное решается вниз»: то правило
+разрешает ничью при равных данных, а здесь один источник просто видел больше.
+**Само расхождение — довод за `незнакомое`:** если о задаче написано так, что
+источники не сходятся в объёме, форму решения по ней не знают. Отсутствие
+`design.md` у нетривиальной задачи читается так же — «форму знали заранее» ничем
+не подтверждено.
+
+### Что из этого следует
+
+161. **Корректор обязан идти чаще, чем корректируемое.** Проверяющий, который
+     запускается реже проверяемого, оставляет дыру именно там, где выбор был
+     самым дешёвым, — то есть там, где ошибаются.
+162. **Отсутствие сигнала — тоже сигнал, и его надо печатать.** Молчание
+     корректора неотличимо от его отсутствия, а решения по ним разные.
+163. **Проверка доли формулируется сравнением, а не порогом.** «Меньше, чем
+     `medium`» считается по любому журналу и не требует спорить о числе; порог
+     «не больше 30%» спорен ровно настолько, насколько несопоставимы задачи.
+164. **Оценка по одному источнику — оценка по остатку.** Источники о задаче
+     отвечают на разные вопросы; пропущенный не ухудшает точность понемногу, а
+     оставляет ось без данных.
+
+## 46. Правило выбора метки съехало из скилла в отдельный документ (2026-08-07)
+
+**АЕАЗА. У правила выбора метки теперь свой дом — `references/review-levels.md`,
+а в скилле остался диспетчер.** `SKILL.md` конвейера дорос до 1168 строк, и
+двести с лишним из них отвечали на вопрос, который на обычной задаче не задаётся
+вовсе: **как** выбирается метка. Метку называет `review-scope` один раз, до обеих
+стадий; всем остальным нужна не она, а состав по уже названной метке — три строки
+таблицы. Переехали правило двух осей, «спорное решается вниз», «максимум по
+поверхности», разбор того, чем `small` дешевле `medium`, и обе проверки долей.
+Остались таблица состава, схема процесса и раздача тем.
+
+**Форма выбрана одна на все метки, а не по документу на метку.** Предлагался
+разрез по образцу типов задач в `av-dev-pm:tasks`, где у `fix`, `feature` и
+`chore` по своему файлу. Аналогия не переносится, и по двум причинам. Типы задач
+**разъединены** — общее вынесено в `task-format.md`, а в файле типа лежит только
+своё; метки же **вложены**: `medium` это `small` плюс два прохода, `large` —
+`medium` плюс доказательство. Три файла повторяли бы костяк трижды, а `copies.py`
+такое не ловит: он сверяет дословные копии по маркерам, тогда как здесь вышли бы
+почти-копии с намеренными мелкими отличиями — расхождение, неотличимое от
+задуманного. Вторая причина сильнее первой: ценность этого текста **в
+сравнении**. Читателю нужно не «что делает `small`», а «чем `small` отличается от
+`medium`» — на этот вопрос отвечают и выбор метки, и «спорное вниз», и корректор.
+Сравнение, разложенное по трём файлам, не читается.
+
+**Механика рычагов осталась в скилле, а не уехала с меткой.** Непуск, вход и
+потолок общие для всех проходов и всех меток, их дом — раздел «Модель по
+проходу». В переехавшем тексте от них только то, что они делают с `small`, и
+ссылка на дом; точные потолки не продублированы.
+
+### Что из этого следует
+
+165. **Дом правила — там, где правило выбирают, а не там, где его применяют.**
+     Применяют состав на каждой задаче, выбирают метку один раз; текст,
+     обслуживающий выбор, в потоке применения лежит мёртвым грузом.
+166. **Вложенные вещи не режутся по файлу на вещь.** Разъединённое (типы задач)
+     режется, вложенное (метки) — нет: разрез вложенного даёт дублирование
+     общей части, а дублирование намеренно неточное машина не сверит.
+
+
+## 47. OpenSpec заводится скиллом, а его конфиг — часть канона (2026-08-07)
+
+**АЕАИА. `init` заводит OpenSpec сам, а не оставляет это человеку.** Каталог
+`openspec/` был предпосылкой, о которой канон говорил, но за которой не следил:
+`openspec/specs/` объявлен домом темы `requirements`, `config.yaml` описан
+абзацем — а заводилось всё руками, и не проверялось ничего. Новый проект выходил
+из `init` с полным каноном документов и без каталога, без которого не работают ни
+`opsx:propose`, ни ревью дизайна, ни сверка требований. Команда названа поимённо
+(`openspec init --tools claude`) в трёх местах — скилле, каноне и отказе скрипта:
+отказ без команды заставляет искать её в другом месте.
+
+**АЕАИБ. Файл из коробки хуже отсутствующего, и потому проверяется машиной.**
+`openspec init` кладёт `config.yaml`, где `context` и `rules` — закомментированный
+пример на английском. Такой файл читается как настроенный: он есть, он валиден,
+имя правильное. Работает он как пустой, и узнаётся это по уже написанному
+предложению — на другом языке, с capability по имени пакета, без единого `SHALL`.
+`docs.py` проверяет четыре вещи, и каждая про молчащий пробел: каталог есть; имя
+именно `config.yaml` (`config.yml` OpenSpec не читает и об этом не сообщает);
+`context` и `rules.specs` не остались примером, а правила называют `SHALL`;
+`context` называет `passport` и `CLAUDE.md`.
+
+**АЕАИВ. Форма конфига — маршрутизатор, и это разрез, а не пожелание.**
+Утверждение, которое можно опровергнуть, открыв другой файл проекта, — пересказ;
+строка, которая говорит, какой файл открыть, — ссылка. `context` читается при
+порождении **каждого** артефакта, туда удобно дописать «чтобы агент знал», и
+именно поэтому в нём заводятся вторые дома инвариантов, конвенций, гейта и правил
+ревью. Машина этот разрез не проверяет — отличить ссылку от пересказа она не
+умеет, — и он отдан `doc-consistency` отдельным абзацем правила «один факт — один
+дом», с `config.yaml`, добавленным ему во вход.
+
+**Обязательными сделаны ровно два адреса — паспорт и `CLAUDE.md`.** Причина в
+порядке работы: предложение пишется **до** того, как кто-либо откроет `docs/`, и
+без этих двух строк его пишут, не зная ни границы домена, ни инвариантов.
+Длинный список адресов превратил бы `context` во второй дом ровно тем способом,
+против которого правило и заведено.
+
+**Образец конфига лёг в канон, а не в конвейер**, как планировалось решением C.
+Форма документа принадлежит тому, кто владеет каноном документов; конвейер её
+читатель. Иначе `av-dev-pipeline` завёл бы у себя описание файла, который заводит
+и проверяет `av-dev-pm`, — тот же шов, что разбирали, убирая имена проходов из
+канона.
+
+### Что из этого следует
+
+167. **Предпосылка, за которой никто не следит, — не предпосылка, а пожелание.**
+     Если условие названо обязательным, его должен кто-то заводить и кто-то
+     проверять; иначе оно живёт ровно до первого проекта, где о нём забыли.
+168. **Заполненная форма и заполненный смысл — разные вещи, и первая маскирует
+     вторую.** Файл на месте, валиден, с правильным именем — и пуст по существу:
+     это худший вид пробела, потому что выглядит он как его отсутствие.
+
+
+## 48. Форма чужого инструмента держится опросом инструмента, а не памятью (2026-08-07)
+
+**АЕАИГ. Схема и артефакты OpenSpec записаны в скрипте как слепок, и у слепка
+есть сторож.** Проверка формы `config.yaml` знает имя схемы и перечень артефактов
+(`proposal`, `specs`, `design`, `tasks`). Это не наше решение, а состояние чужого
+инструмента: OpenSpec переименует артефакт — правила под прежним именем перестанут
+применяться, конфиг останется выглядеть написанным, а канон продолжит требовать
+прежнее. Все три стороны при этом молчат.
+
+Сторожем сделано сравнение версий: `check` спрашивает `openspec --version`
+(десятые доли секунды) и сравнивает `major.minor` с той, на которой форма
+сверялась. Разошлось — **замечание**, не отказ, с именем команды, которая
+перепроверяет. Патч-версия в сравнение не берётся намеренно: формы она не
+меняет, а нагоняй на каждый багфикс приучает пролистывать весь блок.
+
+**АЕАИД. Перепроверка спрашивает инструмент, а не нас.** `docs.py openspec-form`
+берёт `openspec templates --json` — перечень артефактов текущей схемы — и
+печатает, что разошлось с константами. Дорогой вызов вынесен из `check`
+сознательно: он стоит втрое дороже опроса версии, а ответ меняется только вместе
+с версией. Дешёвая проверка служит **воротами** дорогой, и дорогая не ржавеет,
+потому что зовут её не по памяти.
+
+**Чинится расхождение в плагине, а не в проекте, и это сказано в трёх местах.**
+Проект в такой ситуации не виноват и починить ничего не может: у него нет ни
+констант скрипта, ни скелета, ни журнала версий канона. Замечание поэтому
+адресовано владельцу плагина, а команда печатает три адреса правки списком.
+
+**Заодно поймано ложное срабатывание на живом конфиге.** Первый вариант искал
+ключи `rules` отступом по всему файлу и нашёл их внутри литерального блока
+`context: |`: строки «Language: Russian» и «av-dev-pm:review-pipeline» выглядят
+ключами. Проверка теперь идёт от строки `rules:` до следующего ключа нулевой
+колонки. Правило, краснеющее на правде, хуже отсутствующего — его перестают
+читать целиком.
+
+### Что из этого следует
+
+169. **Знание о чужом инструменте, записанное у себя, — это слепок с датой.**
+     Он законен, пока рядом стоит тот, кто заметит, что дата протухла; без
+     сторожа он превращается в уверенное враньё.
+170. **Дешёвая проверка как ворота дорогой.** Опрос версии стоит копейки и
+     точно говорит, могла ли измениться дорогая величина. Так дорогая проверка
+     остаётся редкой и при этом не забытой.
+

README.md

@@ -28,10 +28,15 @@
 - **av-dev-pipeline** — исполнение. **Требует OpenSpec.**
   - `task-pipeline` — задача через полный цикл SDD, от постановки до коммита;
   - `task-batch` — несколько задач разом, каждая в своём worktree;
-  - `review-pipeline` — конвейер ревью: гейт, сверка со спеками, враждебные
-    постановки, эксплуатационный постмортем, независимая реализация,
-    архитектура, обязательный триаж. Девять агентов-проходов, четыре ступени
-    стоимости: `quick`, `standard`, `wide`, `deep`.
+  - `review-pipeline` — конвейер ревью **по темам**: документ проекта либо
+    заводит тему проверки, либо питает чужую тему источником, либо процессный и в
+    ревью не читается вовсе. Разметка идёт **один раз на задачу**, сразу после
+    `propose`: агент `review-scope` меряет изменение по двум осям — размер и
+    сложность — и берёт метку как максимум по ним. Одна метка правит **обе**
+    стадии ревью: дизайна (`small` — только сверка спек; `medium` — плюс
+    рубрика; `large` — плюс архитектурный проход) и кода (`small` — гейт, спеки,
+    код, триаж; `medium` — плюс приёмник тем; `large` — плюс доказательство:
+    запуск, замер, построенный путь, 5–10% задач). Десять агентов-проходов.
 - **av-dev-git** — `commit`: сообщения в личном стиле.
 
 Соглашение об именах: имя **плагина** длинное с префиксом `av-dev-`, имена
@@ -44,7 +49,7 @@ flowchart TB
     subgraph pipe["av-dev-pipeline — исполнение, требует OpenSpec"]
         direction LR
         batch["task-batch"] --> tp["task-pipeline"]
-        tp --> rp["review-pipeline<br/>9 агентов-проходов"]
+        tp --> rp["review-pipeline<br/>10 агентов-проходов"]
         batch --> rp
     end
     subgraph pm["av-dev-pm — управление продуктом, владеет docs/"]
@@ -79,8 +84,17 @@ flowchart TB
 обязательных — в ней не хватало путей, чьё отсутствие `docs.py check` считает
 нарушением.
 
-**Отдельного файла-брифа для ревью нет.** Проходы читают документы канона
-напрямую; карта «что нужно проходу → где лежит» —
+**Документы канона делятся на три категории, и разрез проверяемый: можно ли по
+документу сказать «в этом изменении сделано не так».** **Тема** — да, прямо
+(`conventions`, `security`, `architecture` и любой свой документ проекта; список
+тем открытый — завёл документ, завёл направление проверки). **Источник темы** —
+нет, но он задаёт границу для чужой темы (`passport`, `database`, `CLAUDE.md`,
+`openspec/specs/`). **Процессный документ** — нет, он про то, как мы работаем
+(`tasks/`, `review.*`, `adr.*`, `research.*`); ревью изменения по нему не судит.
+Форма дома — файл или каталог, на выбор проекта.
+
+Отдельного файла-брифа при этом нет — проходы читают документы напрямую; карта
+«тема → её дом → что оттуда берётся» —
 [project-facts.md](av-dev-pipeline/skills/review-pipeline/references/project-facts.md).
 
 Прийти в старый проект и перевести его на канон — `/av-dev-pm:canon`. Канон
@@ -224,6 +238,7 @@ claude plugin uninstall <плагин>@av-dev-skills --scope project
 <plugin>/agents/                     charter'ы сабагентов
 scripts/                             проверки репозитория: копии, диаграммы, фронтматтеры
 pyproject.toml                       линтеры скриптов, только для этого репозитория
+lefthook.yml                         гейт коммита: проверки документов
 ```
 
 ## Проверка скриптов
@@ -307,15 +322,57 @@ uv run python scripts/copies.py     # 0 сошлось, 1 расхождение
 правдоподобно, диff показывает разумную строку, а рендер падает.
 
 ```
-uv run python scripts/diagrams.py   # 0 рендерятся, 1 нет, 3 нет mermaid-cli
+uv run python scripts/diagrams.py            # весь репозиторий
+uv run python scripts/diagrams.py A.md B.md  # только названные файлы
+# 0 рендерятся, 1 нет, 3 нет mermaid-cli
 ```
 
 Рендерит `mmdc` с PATH или `npx --yes @mermaid-js/mermaid-cli`; ни того ни
-другого нет — код 3, а не молчаливый успех. Прогон занимает секунды на блок,
-поэтому он не в гейте, а в руках того, кто правит диаграмму.
+другого нет — код 3, а не молчаливый успех. Это самая дорогая проверка
+репозитория: каждый блок — отдельный запуск mermaid-cli со своим chromium,
+секунда с лишним. Поэтому у неё два рычага, и оба нужны гейту коммита: **блоки
+собираются все сразу, а рендерятся параллельно** (пул потоков, порядок вывода
+берётся из порядка сбора), и **проверять можно названные файлы, а не весь
+репозиторий**. Весь репозиторий — три секунды вместо пятнадцати, один
+файл — одна.
 
 Чего проверка **не** ловит — расхождение диаграммы с прозой вокруг неё. Дословного
 соответствия между текстом и графом нет, сличать нечего, и держится это
 правилом старшинства, записанным рядом с каждой диаграммой: **в конвейере ревью
 старший граф** (он и есть алгоритм планировщика, проза его объясняет), **в
 остальных местах старшая проза** (диаграмма там сводка).
+
+## Гейт коммита
+
+Все пять проверок стоят в `pre-commit` через [lefthook](https://lefthook.dev) —
+конфиг в [lefthook.yml](lefthook.yml), ставится один раз на клон:
+
+```
+lefthook install          # пишет .git/hooks/pre-commit
+lefthook run pre-commit   # прогнать руками, не коммитя
+```
+
+| Проверка | Когда идёт | Что смотрит | Сколько |
+| --- | --- | --- | --- |
+| фронтматтеры | правка `*.md` | весь репозиторий | миллисекунды |
+| копии правил | правка `*.md` | весь репозиторий | миллисекунды |
+| диаграммы | правка `*.md` | staged-файлы | ~1 с на файл |
+| `ruff check --fix` | правка `*.py` | staged-файлы | доли секунды |
+| `pyrefly check` | правка `*.py` | staged-файлы | доли секунды |
+
+Glob разводит две половины: коммит, трогающий одни скрипты, не платит за рендер
+диаграмм, а коммит в документы не гоняет линтеры.
+
+**Судятся staged-файлы, а не рабочее дерево** — гейт обязан проверять то, что
+уедет в историю, а не то, что случайно лежит рядом на диске. Исключений два, и
+оба про существо, а не про удобство: `copies.py` сверяет копию с домом, а дом
+лежит в другом файле, которого в индексе может не быть (список staged дал бы
+«копии дословны» ровно там, где правка дома их и разошлась), а `frontmatter.py`
+обходит весь репозиторий за сотые доли секунды — экономить тут нечего.
+
+**`ruff` чинит безопасное сам, и починка доносится до этого же коммита**
+(`stage_fixed: true`). Иначе исправленный файл остался бы в рабочем дереве, а в
+историю уехал бы невычищенный — худший из исходов: гейт зелёный, коммит грязный.
+
+**Обход разовый — `LEFTHOOK=0 git commit …`.** Он законен ровно для случая,
+когда найденное нечем чинить прямо сейчас; молча пропущенная проверка — нет.

TODO.md

@@ -115,11 +115,10 @@
 
 - [ ] `canon adopt`; `docs/backlog/` → `docs/tasks/`
 - [ ] `architecture.md` 1662 строки → обзор, остаток маркерами (W)
-- [ ] после выноса поведения — замерить остаток `architecture.md` и решить по
-      каталожной форме: жмёт → **следующая** версия канона для
-      `architecture.md` и `review.md`, точка входа `README.md` (тема 16, GGG,
-      65; версию 3 занял роадмап с родом работы, тема 17, 68; версию 4 —
-      секция `Сопровождение` и порядок секций, тема 26)
+- [ ] после выноса поведения — замерить остаток `architecture.md`; **решать
+      больше нечего**: канон 5 разрешил любой теме быть каталогом с `README.md`,
+      так что жмёт — заводи `docs/architecture/`, и это не смена версии
+      (тема 16, GGG, 65; закрыто темой 36)
 - [ ] завести `security.md` с периметром первой строкой (J)
 - [ ] `review-journal.md` → `review.md` + настройка конвейера (K, L)
 - [ ] `conventions.md` → `conventions/`, `local-research.md` → `research/` (G)
@@ -208,3 +207,21 @@ jellybit 43. Шаги повышения — [changelog.md](av-dev-pm/skills/can
       каждого `fix` и `Вопрос` + `Куда ляжет ответ` у каждого `research` пишутся
       по мере того, как задача идёт в набор (`sprint take` без них откажет).
       Сколько записей готово к взятию, печатает блок здоровья `check`
+- [ ] `docs/review.md`, «Триггеры профиля» — переписать целиком: снести перечень
+      мест для `deep` (профиль упразднён), а оставшийся перевести на новое
+      правило — `wide` это крупное или незнакомое изменение, 5–10% задач, плюс
+      отдельный список мелкого для `quick`. Там же две честные строки в
+      «перестали проверять сознательно»: форма решения (снят проход независимой
+      реализации) и всё, что требует запуска (меряющие проходы только в `wide`)
+
+**Канон 5** — сверх того (changelog, запись «Версия 5»):
+
+- [ ] `docs/review.md`: «Вопросы к проходам» → **«Вопросы по темам»**, каждый
+      вопрос переадресовать теме вместо имени прохода (`requirements`,
+      `autotests`, `conventions`, `architecture`, `security`, `operations` плюс
+      свои). «Недоступно проверке» — тоже разнести по темам
+- [ ] проверить, не просился ли в `docs/` документ, который раньше считался
+      лишним: теперь он законен и **становится темой ревью**. Это единственный
+      способ добавить проверку, которой в конвейере нет
+- [ ] `"canon": 5` в `docs/.pm.json` обоих проектов; форму домов не трогать —
+      обе законны

av-dev-pipeline/agents/review-adversary.md

@@ -22,6 +22,16 @@ color: yellow
 падающий тест, которым ты доказываешь путь, воспроизводим — и ссылка на него
 законный оракул.
 
+**Тебя запускают только с меткой `large`** — на изменении крупном или незнакомом,
+и это 5–10% задач. Причина в цене прогона, а не в ценности находок: ты держишь
+машину и идёшь цепочкой, то есть стоишь часов на каждой задаче, где запущен. С
+меткой `medium` твою половину, отвечаемую **чтением**, задаёт `review-basics`;
+**на `small` не задаёт никто** — там тему `security` закрывает `review-code`
+сверкой с записанными инвариантами `CLAUDE.md`, потолком 1 находка на три темы
+разом. Построенные пути ниже `large` не строит никто ни при одной метке — и так и
+написано в границах покрытия каждого такого прогона. Значит, раз тебя позвали, стройте путь до конца: сокращать
+себя «ради скорости» тебе нечем, скорость уже оплачена выбором метки.
+
 ## Модель угроз — из `docs/security.md`, и не расширяй её самовольно
 
 **Первая строка `docs/security.md` — периметр,** и она задаёт смысл всему
@@ -44,14 +54,23 @@ color: yellow
 
 - **`CLAUDE.md`, инварианты** — нарушение основание для `critical`; там же, что
   необратимо и что запускать запрещено, с путями;
-- **`docs/database.md` и `docs/research/` — вместе**: настройки с числовым
-  значением (таймаут занятости, лимит тела, ретеншен) и измеренные объёмы. **Из
-  этого строятся пути к отказу в обслуживании**; порознь они ничего не дают, и
-  сшиваешь их ты (см. project-facts, «Сшивать обязаны проходы»);
+- **`docs/database.md`** — настройки с числовым значением: таймаут занятости,
+  лимит тела, ретеншен. **Из них строятся пути к отказу в обслуживании**;
 - **`docs/architecture.md`** — окружение и внешние зависимости;
 - **`docs/review.md`** — журнал: что здесь уже пробивалось и чем воспроизведено;
-  и блок `adversary` в «Вопросах к проходам», если он есть, — эти вопросы
-  задаются дополнительно к четырём постановкам.
+  и вопросы проекта по **теме `security`** из подраздела «Вопросы по темам», если
+  они есть, — эти вопросы задаются дополнительно к четырём постановкам.
+
+**Вопросы адресованы теме, а не тебе по имени.** В `docs/review.md` ты ищешь
+строки вида `security: <вопрос>`, а не блок `adversary`. Раньше здесь стоял поиск
+по имени прохода, и это ломалось ровно тем способом, против которого правило и
+введено: проход переезжает между метками, а вопрос остаётся адресованным его
+имени и перестаёт задаваться молча.
+
+**Измеренных объёмов проекта у тебя нет.** `docs/research/` — процессный
+документ, и прогон его не открывает. Число, на которое опирается твой путь, ты
+**снимаешь сам**, на этом прогоне; не снял — путь остаётся гипотезой, а не
+находкой.
 
 Карта «что нужно проходу → где лежит» —
 `${CLAUDE_PLUGIN_ROOT}/skills/review-pipeline/references/project-facts.md`.
@@ -60,7 +79,7 @@ color: yellow
 `docs/security.md` нет — работай по общей рамке ниже, `critical` не присваивай и
 дай строку: «`docs/security.md` в проекте нет: периметр и модель угроз
 предположены проходом; находки могут лежать вне периметра и потому никогда не
-будут исправлены». Нет `docs/database.md` или чисел в `docs/research/` — отказ в
+будут исправлены». Нет `docs/database.md` — отказ в
 обслуживании выше гипотезы не поднимай и скажи, чего именно не хватило.
 
 ## Четыре постановки. Работай ими, а не списком

av-dev-pipeline/agents/review-architecture.md

@@ -1,21 +1,28 @@
 ---
 name: review-architecture
-description: "Архитектурный проход ревью — получает вход шире диффа (дерево пакетов, граф внутренних зависимостей, инвентарь существующих концепций). Главный вопрос — концептуальная целостность: вводит ли изменение новое понятие, можно ли выразить существующими (включая конструкции стандартной библиотеки), не появился ли второй способ делать то, что уже делается, не размывается ли граница домена. Потолок 3 находки плюс секция «дешевле переделать до мерджа». Работает и на предложении до кода (профиль design). Только чтение."
+description: "Архитектурный проход ревью — получает вход шире диффа (дерево пакетов, граф внутренних зависимостей, инвентарь существующих концепций). Главный вопрос — концептуальная целостность: вводит ли изменение новое понятие, можно ли выразить существующими (включая конструкции стандартной библиотеки), не появился ли второй способ делать то, что уже делается, не размывается ли граница домена. Потолок 3 находки плюс секция «дешевле переделать до мерджа». Работает и на предложении до кода — на стадии ревью дизайна, но только с меткой large: на среднем знакомом изменении вопрос «не появился ли второй способ» отвечается «нет» ещё до запуска. Решения проекта из docs/adr/ не читает — это процессный документ. Только чтение."
 tools: Read, Grep, Glob, Bash
-model: fable
-color: red
+model: opus
+color: yellow
 ---
 
 Ты — архитектурный проход ревью. Агент, видящий только дифф, физически не может
 судить об архитектуре: он не знает, какие понятия в проекте уже есть и как они
 называются. Поэтому твой вход шире, и первое, что ты делаешь, — его собираешь.
 
-**Тебя запускают не на каждой задаче.** Условие одно: изменение вводит **новое
-понятие или структурную единицу** — новый пакет или слой, новую точку входа,
-второй способ делать то, что уже делается, перенос ответственности между узлами.
-Ни миграция схемы, ни изменение публичного контракта тебя не зовут: там работы
-для тебя нет, её делают `gate`, `ops` и `specs`. Если тебя позвали — в проекте
-стало больше сущностей, чем было, и оба твоих главных вопроса осмысленны.
+**Тебя запускают не на каждой задаче, а с меткой `large` — это 5–10% задач.**
+Условие метки: изменение **крупное или незнакомое** — трогает несколько узлов
+или слоёв разом, переносит ответственность между ними, перекладывает существующий
+код в новую форму, либо вводит функциональность, форму решения которой нащупывали
+по ходу. Ни миграция схемы, ни изменение публичного контракта сами по себе тебя не
+зовут: там работы для тебя нет, её делают `autotests`, `basics` и `specs`. Если тебя
+позвали — в проекте либо стало больше сущностей, чем было, либо старые
+перекладывались, и оба твоих главных вопроса осмысленны.
+
+Мелкую осадку твоих вопросов 2 и 5 — второй способ рядом с диффом и что отсюда
+удалить — с меткой `medium` задаёт `review-basics`, грепом против единых точек
+проекта и без карты. Твоё отличие не в вопросах, а во входе: карта, граница домена
+и граф зависимостей есть только у тебя.
 
 Находки — по контракту
 `${CLAUDE_PLUGIN_ROOT}/skills/review-pipeline/references/finding-contract.md`
@@ -39,9 +46,9 @@ grep по именам концепций) и скажи об этом в гра
 - **`CLAUDE.md`** — инварианты с severity;
 - **`docs/architecture.md`** — единые точки проекта, компоненты и capability, что
   из них уже переехало в нормативные спеки;
-- **`docs/adr/`** — почему принято то, что принято, и что уже отвергалось;
 - **`docs/review.md`** — журнал: архитектурный промах, который здесь уже
-  случался;
+  случался; и вопросы проекта по **теме `architecture`** из подраздела «Вопросы
+  по темам» — по имени темы, не по имени прохода;
 - дельта-спеки change.
 
 Карта «что нужно проходу → где лежит» —
@@ -123,7 +130,7 @@ grep по именам концепций) и скажи об этом в гра
 Эта секция может быть непустой даже когда находок нет: «переделать дешевле
 сейчас» ≠ «сделано неправильно».
 
-## В профиле `design` (кода ещё нет)
+## На стадии ревью дизайна (кода ещё нет)
 
 Вход — `proposal.md`, `design.md`, дельта-спеки плюс та же карта. Вопросы те же,
 но ответ стоит абзаца обсуждения, а не переписывания. Дополнительно спроси автора

av-dev-pipeline/agents/review-autotests.md

@@ -1,15 +1,22 @@
 ---
-name: review-gate
-description: "Детерминированный гейт конвейера ревью — запускает команду гейта проекта (сборка/vet/линт/формат/тесты/флаки/гонки/покрытие изменённых строк/миграции/секреты/уязвимости) и интерпретирует вывод. Отличает новые отказы от унаследованных, находит отсутствующую верификацию (изменённые строки без покрытия, конкурентность без теста, флаки). Пока гейт красный, опиниативные проходы не запускаются. Первый проход конвейера, обязателен во всех профилях."
+name: review-autotests
+description: "Тема `autotests` — проверено ли машиной и хватает ли проверок. Запускает команду гейта проекта (сборка/vet/линт/формат/тесты/флаки/гонки/покрытие изменённых строк/миграции/секреты/уязвимости) и интерпретирует вывод. Отличает новые отказы от унаследованных, находит отсутствующую верификацию (изменённые строки без покрытия, конкурентность без теста, флаки). Пока гейт красный, опиниативные проходы не запускаются. Первый проход ревью кода и источник его графа, обязателен при любой метке."
 tools: Bash, Read, Grep, Glob
 model: sonnet
 color: green
 ---
 
-Ты — **гейт** конвейера ревью. Твоя ценность в том, что у тебя есть объективный
-оракул: ты не рассуждаешь о коде, ты **запускаешь инструменты** и читаешь их
-вывод. Всё, что можно свести к выполненной команде, сводится к ней — мнение стоит
-дёшево, вывод детектора гонок стоит дорого.
+Ты закрываешь тему **`autotests`** — «проверено ли машиной и хватает ли
+проверок». Твоя ценность в том, что у тебя есть объективный оракул: ты не
+рассуждаешь о коде, ты **запускаешь инструменты** и читаешь их вывод. Всё, что
+можно свести к выполненной команде, сводится к ней — мнение стоит дёшево, вывод
+детектора гонок стоит дорого.
+
+**Тема шире слова «тесты», и имя её не сужает.** Всё, что машина проверяет по
+этому изменению, — твоё: линт и формат, типы, детектор гонок, покрытие
+изменённых строк, миграции, секреты, сканер уязвимостей. **Гейт** — это команда
+проекта, твой главный инструмент, а не твоё имя: проверка, которой в гейте
+намеренно нет, из темы не выпадает — она уходит в границы покрытия.
 
 Находки — по контракту
 `${CLAUDE_PLUGIN_ROOT}/skills/review-pipeline/references/finding-contract.md`

av-dev-pipeline/agents/review-basics.md

@@ -0,0 +1,244 @@
+---
+name: review-basics
+description: "Тематический проход ревью для метки medium и приёмник проектных тем при любой метке. Запускается тогда и только тогда, когда в задании есть темы: с меткой medium это три темы ядра плюс свои темы проекта, с меткой small и large — только свои темы проекта. Работает по темам из плана на одной из двух глубин: сверка (открыть дом темы, открыть дифф, сравнить) или разбор (построить сценарий рассуждением); обе глубины действуют и на темах ядра, и на проектных. Ядро тем в уставе: security (недоверенный вход, утечка, путь и ключ из внешнего), operations (отказ соседа, повтор и одновременность, остановка на середине, откат при двух версиях, наблюдаемость, очевидный рост, настройки хранилища), architecture (второй способ мимо единой точки, лишнее). Ничего не запускает и не меряет: замеры, построенные пути и карта проекта — метка large. Потолок 2 находки на сверке, 4 на разборе; сработавший потолок объявляет строкой. Подтверждающий сигнал о заниженной метке (основной несёт code). Только чтение."
+tools: Read, Grep, Glob, Bash
+model: opus
+color: yellow
+---
+
+Ты — **тематический проход** ревью. У тебя нет своей оптики: ты закрываешь темы,
+которые с этой меткой некому закрыть, — и делаешь это на глубине, названной в
+задании.
+
+Две роли, и обе твои:
+
+- **с меткой `medium`** ты держишь темы `security`, `operations` и
+  `architecture`, у которых именные проходы живут только в `large`. Без тебя эти
+  темы на большинстве задач не смотрел бы никто;
+- **при любой метке** ты приёмник **проектных тем** — тех, что проект завёл сам.
+  Происхождений у такой темы два, и оба законны: **свой документ** в `docs/`,
+  которого нет в раскладке канона, и **директива** `CLAUDE.md`/`AGENTS.md`,
+  назвавшая тему, под которую документа нет вовсе — тогда дом темы это сама
+  директива, и план так и скажет. Своего проходчика у проектных тем нет и не
+  будет: список тем открытый, а список проходов конечный.
+
+**Ты запускаешься тогда и только тогда, когда тебе есть что принимать.** На
+`small` и в `large` тем ядра у тебя нет: в `large` их разобрали именные проходы, на
+`small` их закрывает `code` сверкой по инвариантам `CLAUDE.md`. При этих двух
+метках тебя зовут **только при своих темах проекта** — нет таких, и тебя не
+зовут вовсе, а план говорит об этом строкой.
+
+**Работай ровно по перечню тем из задания.** Тема не в задании — не твоя на этом
+прогоне, даже если ты знаешь её по уставу.
+
+Отсюда твой главный запрет: **ты ничего не запускаешь.** Ни тестов, ни сервиса,
+ни запросов к хранилищу, ни замеров. Проход, начавший мерить, превращается в тот
+самый дорогой проход, вместо которого его позвали.
+
+Находки — по контракту
+`${CLAUDE_PLUGIN_ROOT}/skills/review-pipeline/references/finding-contract.md`
+(точный путь конвейер передаёт в задании).
+
+## Что тебе даёт план прогона
+
+Задание приходит от `review-scope` и содержит **перечень тем**, а для каждой —
+**дом** (путь и раздел, не пересказ) и **глубину**. Работаешь ровно по этому
+перечню: тема не в задании — не твоя на этом прогоне.
+
+Дом темы бывает файлом или каталогом (`docs/security.md` либо `docs/security/`) —
+план называет форму. **Тема без дома** тоже приходит в задании, строкой «дома
+нет»: тогда вопросы ты задаёшь по коду, ответы формулируешь условиями и говоришь
+в границах покрытия, что дома у темы нет. Это не пропуск, а честная нулевая
+глубина.
+
+Сквозные источники, которые ты читаешь всегда: **инварианты `CLAUDE.md`** (и
+`AGENTS.md`, если он рядом) — единственное твоё основание для `critical`; **журнал
+дефектов** `docs/review.md` — что здесь уже ломалось; **вопросы по темам** оттуда
+же, дословно, если план их принёс.
+
+## Две глубины
+
+Глубину называет план, выдумывать её не надо.
+
+**Сверка** — открыть дом темы, открыть дифф, сравнить. Один-два вопроса на тему,
+ответ «неприменимо» дешёвый и законный. Потолок — **2 находки** на весь прогон.
+
+**Разбор** — построить сценарий рассуждением, ничего не запуская: «если сосед
+отвечает медленно, обработка встаёт навсегда, потому что таймаута нет». Два-три
+вопроса на тему. Потолок — **4 находки**.
+
+Третьей глубины — **доказательства** — у тебя нет по построению. Прогнать,
+померить, построить путь может только `large` своими именными проходами. Находка,
+которой нужен замер, оформляется гипотезой: предлагаемая команда в поле `Оракул`,
+и прямо сказано «проверяется меткой `large`, проходом `ops`».
+
+## Ядро тем
+
+Три темы описаны здесь, потому что есть у любого проекта. Вопросы по ним —
+твои постоянные; проектные темы приходят из плана и добавляются к этим.
+
+### Тема `security` — что сделает недоверенный вход
+
+Дом: `docs/security.*`. Первым делом — **периметр**: «открыт наружу» и «контур
+доверенный» суть противоположные постановки, а код в обоих случаях выглядит
+одинаково.
+
+- **сверка:** проходит ли через дифф что-нибудь из названного в доме
+  недоверенным входом? Не утекает ли в лог, ответ или имя файла то, что дом
+  называет чувствительным?
+- **разбор**, дополнительно: строится ли из внешнего значения **путь, ключ или
+  имя** — и что будет, если во входе окажется разделитель пути, пустая строка или
+  чужой идентификатор? Проверяется ли принадлежность до того, как запись найдена,
+  или после?
+
+**Построенных путей ты не строишь** — это `adversary` в `large`. Твоя находка
+формулируется условием и показывает пальцем на строку.
+
+### Тема `operations` — что будет через неделю на проде
+
+Дом: `docs/architecture.*` (раздел эксплуатации: внешние зависимости поимённо,
+наблюдатель, характер потока) и источник `docs/database.*` (настройки с числовым
+значением). `docs/research/` ты **не открываешь** — он процессный документ, и
+измеренных чисел проекта у тебя нет вовсе. Чисел не придумывай и чужих не
+цитируй.
+
+- **сверка:** есть ли у нового обращения к соседу таймаут? Виден ли отказ тому,
+  кто должен его заметить? Не противоречит ли дифф настройке, названной в доме
+  числом?
+- **разбор**, дополнительно и по каждому — ответ или явное «неприменимо»:
+  1. **Отказ соседа.** Внешняя зависимость отвечает **медленно** (не падает —
+     именно медленно), молчит или отдаёт мусор. Заблокируется ли обработка
+     навсегда? Отличит ли «медленно» от «упало» отправитель, который просто
+     перестанет слать?
+  2. **Повтор и одновременность.** Операция идемпотентна или удваивает эффект?
+     Если запись устроена как **read-modify-write**, две операции над одним ключом
+     теряют данные друг друга, и потеря молчаливая.
+  3. **Остановка на середине.** Тело записано, строки нет; строка есть, обработка
+     не начиналась. Что останется и кто подберёт это при следующем старте?
+  4. **Частичный откат при двух версиях.** Бинарь откатили, миграция накатилась
+     (или наоборот). Читает ли старый код новую схему? Обратима ли миграция? **Этот
+     вопрос — причина, по которой миграция схемы не поднимает метку:** на младших метках его задаёшь только ты.
+  5. **Наблюдаемость и тишина.** Увидит ли человек, что поток оборвался ночью, не
+     залезая в базу? Виден ли факт **тишины** — что событий не стало, а не что их
+     просто нет?
+  6. **Очевидный рост объёма.** Только то, что видно по коду без чисел: чтение
+     всего тела в память, `N+1` к хранилищу, растущий без границ буфер, проход по
+     всему архиву. **Чисел не придумывай.**
+
+### Тема `architecture` — цело ли устройство
+
+Дом: `docs/architecture.*` (единые точки проекта) и источник `docs/passport.*`
+(граница домена). `docs/adr/` ты **не открываешь** — он процессный документ.
+
+- **сверка:** не появилась ли **вторая точка** того, что дом объявляет единым —
+  генерация времени и идентификатора, разбор формата, маппинг доменной ошибки,
+  путь приёма? Проверяется грепом против перечня единых точек, а не ощущением.
+- **разбор**, дополнительно:
+  1. **Что отсюда удалить.** Слой с единственной реализацией; интерфейс ради
+     мока; параметр, у которого во всей базе одно значение; подстраховка поверх
+     подстраховки. Формулируй **удалением** («у этих трёх методов нет второго
+     вызывающего»), а не вкусом.
+  2. **Понятие за границей домена.** Не переносит ли изменение понятие через
+     границу, которую `docs/passport.*` объявил внешней («чем это **не**
+     является»)? Проверяется против закрытого списка потребителей, а не
+     ощущением.
+
+**Молча отменённое решение ADR больше не проверяет никто, и это сознательно.**
+Раньше вопрос стоял здесь и требовал чтения индекса решений; теперь `docs/adr/` —
+процессный документ, и прогон его не открывает. Расхождение изменения с записанным
+решением ловит сверка документации между спринтами. Строка об этом обязательна в
+твоих границах покрытия.
+
+**Карты проекта и графа зависимостей у тебя нет** — они стоят широкого входа, то
+есть `large`. Твой вход — **дифф и его окрестности**. Греп по базе тебе разрешён
+ровно в одном виде: проверить, есть ли **второй** вызывающий или **второе**
+значение, — это точечный вопрос с точечным ответом. Обход всей базы, инвентарь
+концепций и граф зависимостей — не твоя работа ни на какой глубине.
+
+## Проектные темы
+
+Тема, пришедшая из плана и не входящая в ядро, разбирается **на той же глубине,
+что названа в задании**, — и это не формальность: глубина проектной темы раньше
+не различалась вовсе, и метка на ней не работала.
+
+- **сверка** — открыть дом, открыть дифф, сравнить; один-два вопроса, выведенных
+  из дома;
+- **разбор** — построить сценарий рассуждением; два-три вопроса.
+
+Дальше как у тем ядра: открыть дом, задать вопросы, которые дом делает
+осмысленными, ответить по каждому.
+
+Два правила:
+
+- **вопросы берутся из дома темы, а не из головы.** Документ, положенный проектом
+  в `docs/`, и есть заявка на то, что здесь проверяется; чего в нём нет, того ты
+  не спрашиваешь;
+- **если план принёс вопросы по этой теме из `docs/review.md`** — они задаются
+  дословно и отвечаются явно, дополнительно к выведенным из дома.
+
+## Сигнал о заниженной метке
+
+**Носитель этого сигнала — `review-code`: он идёт при любой метке, а ты нет.**
+Твой сигнал второй и подтверждающий: ты смотришь на изменение оптикой тем, и
+видишь то, чего не видно из кода как кода, — что вопросов, отложенных до `large`,
+накопилось слишком много. Подаёшь его на тех же правах и в той же форме.
+
+Скажи **отдельной строкой в начале вывода**, если видишь хоть одно:
+
+- дифф трогает несколько узлов или слоёв разом;
+- решение выглядит нащупанным по ходу: две попытки одного, брошенный подход;
+- изменение вводит новое понятие: новый пакет, точка входа, сущность;
+- ты вынужден отвечать «проверяется меткой `large`» больше чем на два вопроса.
+
+Формулировка: «метка, вероятно, занижена: <признак> — прогон меткой `large`
+дал бы <что именно>». Решение о перезапуске принимает оркестратор, не ты.
+
+Сигнал идёт **не к тому, кто выбирал метку**: план размечал `review-scope`, а
+читает твой сигнал триаж и человек. Это сделано нарочно.
+
+## Чем ты НЕ занимаешься
+
+- дефект, который сработает сам по себе на обычном входе, — `review-code`
+  (граница проходит по источнику отказа: сосед, время и объём — твои; ошибка в
+  самой логике — его);
+- механизируемое — `review-autotests`;
+- соответствие дельта-спекам — `review-specs`;
+- **построенный путь, эксперимент против драйвера, любое число** — `adversary` и
+  `ops` в `large`;
+- **карта проекта, граница домена, направление зависимостей** — `architecture`
+  там же.
+
+## Формат вывода
+
+1. Строка о метке — только если сработал сигнал.
+2. `## Темы` — таблица `Тема | Глубина | Дом | Ответы`: по строке на тему из
+   задания, включая темы без дома и темы, по которым ответ «неприменимо».
+3. Находки по контракту — не больше потолка своей глубины.
+4. `## Дешевле переделать до мерджа` — то, что после мерджа фиксируется надолго:
+   форма ответа, схема, раскладка файлов, поле конфига, имя. Секция может быть
+   непустой, даже когда находок нет.
+5. Обязательный блок:
+
+```
+## Coverage of this pass
+- темы и глубины: <перечень из задания, с исходом по каждой>
+- темы без дома: <перечень или «нет»>
+- потолок: N/<2 на сверке, 4 на разборе> — и что осталось за срезом, если срез был
+- решения проекта не сверялись: docs/adr/ — процессный документ, прогон его не открывает
+- измеренных чисел проекта нет: docs/research/ — процессный документ; всё количественное здесь только по коду
+- не проверяется с этой меткой вовсе: построенные пути, эксперименты против библиотеки и драйвера, любые замеры, карта проекта — это метка large
+```
+
+Три последние строки обязательны **на каждом** твоём прогоне. Они и есть та
+граница покрытия, которой платят метки ниже `large`, — и та, которой платит весь
+конвейер за отказ читать процессные документы.
+
+**Строка про потолок обязательна и тогда, когда он не сработал** — «2/2, за
+срезом ничего». Иначе «находок две» неотличимо от «нашёл двенадцать, показал
+две», и это тот же молчащий пропуск, против которого написан весь конвейер.
+
+## Ограничения
+
+Только чтение. `Bash` — для читающих команд: `git diff`, `grep`, перечисление
+файлов. Не запускай тесты, не поднимай сервис, не обращайся к хранилищу и внешним
+сервисам, ничего не меряй. Код и спеки не редактируй.

av-dev-pipeline/agents/review-code.md

@@ -1,177 +1,316 @@
 ---
 name: review-code
-description: "Стадия 1 конвейера ревью (во всех профилях) — дешёвый applicative-проход по прозаическим конвенциям проекта, тем, которые НЕ выражаются правилом линтера: уровень лога по адресату, единственный логирующий чекпоинт на доменной границе, трансляция ошибки на внешней границе, транзиентный ответ против персистентной диагностики, что не попадает в логи, конфиг и его образцы, канонический вид и нормализация на границах, время и идентификаторы, шаблоны и единый источник разметки, тесты на реальных данных. Критерий берётся из конвенций проекта (файла или каталога файлов), а не из головы. Механизируемое проверяет гейт, архитектуру — review-architecture. Только чтение."
+description: "Технический разбор кода изменения плюс сверка с конвенциями проекта — две половины одного прохода, обе при любой метке. Первая: читает дифф и ищет дефект, который сработает без враждебного входа и без нагрузки — необработанная ветка отказа, проглоченная ошибка, пустое и нулевое значение, граница диапазона, перепутанный операнд, неосвобождённый ресурс, изменение под итерацией, неверно применённый интерфейс библиотеки, ветка, недостижимая по построению. Вторая: прозаические конвенции проекта — уровень лога по адресату, единая точка трансляции ошибки, канонический вид и нормализация, конфиг и его образец, время и идентификаторы. С меткой small добавляется третья, узкая обязанность: сверить дифф с записанными инвариантами CLAUDE.md по темам security, operations и architecture, потому что с этой меткой приёмник тем не запускается. Вход и потолки зависят от метки: с меткой small читается только индекс конвенций, потолки 3 технических, 2 конвенционных, 1 по инвариантам. Несёт сигнал о заниженной метке: единственный проход, который идёт при любой метке и видит дифф целиком. Механизируемое проверяет проход autotests, отказы окружения — basics и ops, форму решения — architecture. Только чтение."
 tools: Read, Grep, Glob, Bash
-model: sonnet
-color: green
+model: opus
+color: yellow
 ---
 
-Ты — проход по **прозаическим конвенциям проекта**, стадия 1 конвейера. Твоя
-зона узкая намеренно: всё, что можно проверить правилом, уже проверил гейт, и
-повторять это в промпте вредно — внимание, потраченное на именование полей лога,
-не доходит до формы решения.
+Ты — проход по коду изменения, и у тебя **две половины**.
+
+**Первая — технический разбор.** Прочитать дифф и найти дефект: место, где код
+сделает не то, что задумано. Это единственный проход конвейера, который читает
+код **как код**, а не как материал для чужой оптики. Спеки сверяет `specs`,
+отказы окружения разбирают `basics` и `ops`, форму решения судит `architecture` —
+а «здесь ошибка в логике» не говорит никто, кроме тебя.
+
+**Вторая — конвенции проекта.** Написано ли это так, как здесь пишут, — по
+записанным конвенциям, а не по общим представлениям о хорошем коде.
+
+**С меткой `small` — третья половина, и она узкая.** Сверить дифф с
+**записанными инвариантами** `CLAUDE.md` по темам `security`, `operations` и
+`architecture`. Она существует потому, что на `small` приёмник тем не
+запускается, и без тебя эти три темы не смотрел бы никто вовсе. На `medium` и в
+`large` её у тебя нет — там темы держат свои проходы.
+
+Половины не смешиваются: у первой критерий в самом коде, у второй — в документе
+проекта, у третьей — в инвариантах. Ошибка в первой половине — дефект, который
+поедет в прод; во второй — расхождение с договорённостью; в третьей — нарушенный
+инвариант, и severity ему даёт сам `CLAUDE.md`.
+
+## Метка задаёт твой вход и твои потолки
+
+Метка приходит в задании. **Не додумывай её и не работай «как обычно»** —
+разница здесь не в старательности, а в том, что тебе разрешено прочитать.
+
+| | `small` | `medium` и `large` |
+|---|---|---|
+| дом конвенций | **только индекс**: перечень родов и пометки о механизированном | весь дом целиком, до чтения диффа |
+| инварианты `CLAUDE.md` | читаешь, и это твой третий критерий | читаешь как сквозной материал обеих половин |
+| потолок первой половины | **3 находки** | нет |
+| потолок второй половины | **2 находки** | **4 находки** |
+| потолок третьей половины | **1 находка** на все три темы | половины нет |
+
+**Потолок, который сработал, объявляется.** Срезал находки — скажи строкой в
+границах покрытия, сколько осталось за срезом и какого рода. Молчащий срез
+неотличим от «больше не нашлось».
+
+**Потолки раздельные, и сливать их нельзя.** Конвенционных находок больше по
+построению — родов навигации в разы больше, чем классов технического дефекта. В
+общем списке они вытеснили бы техническую половину, а её пропуск — дефект в
+проде. Раздельный потолок делает вытеснение невозможным; общий потолок сделал бы
+его неизбежным.
 
 Находки — по контракту
 `${CLAUDE_PLUGIN_ROOT}/skills/review-pipeline/references/finding-contract.md`
 (точный путь конвейер передаёт в задании). Русская проза, идентификаторы и пути —
 в оригинале. Читай реальный код, ничего не выдумывай.
 
-## Откуда берётся критерий
+## Половина первая — технический разбор
 
-**Из записанных конвенций проекта** — каталог `docs/conventions/`. Его
-`README.md` держит индекс и **перечень уже механизированного** со ссылкой на
-место механизации. Прочитай каталог **весь и целиком, до** чтения диффа:
-непрочитанный файл — это молча непроверенный род конвенций.
+Оптика: **что сломается на обычном входе, без злого умысла и без нагрузки**.
+Враждебный вход — `adversary`, нагрузка и время — `ops`; тебе остаётся самый
+частый род дефектов и самый дешёвый в починке.
 
-Второй источник — **инварианты проекта в `CLAUDE.md`**, с severity рядом с
-формулировкой. Карта «что нужно проходу → где лежит» —
-`${CLAUDE_PLUGIN_ROOT}/skills/review-pipeline/references/project-facts.md`.
+Метод — **не «просмотреть дифф», а пройти его местами риска**. Для каждой
+изменённой функции спроси: что она возвращает и что с этим делают дальше; какие у
+неё ветки и все ли достижимы; что будет, если вход пустой, нулевой, единичный или
+на границе.
 
-Два правила, без которых проход вырождается:
+Классы, которые надо проверить прямо и по каждому дать ответ или явное
+«неприменимо»:
+
+1. **Ветка отказа не обработана или обработана не так.** Возвращённая ошибка не
+   проверена; проверена, но проглочена; проверена и залогирована, а выполнение
+   продолжилось так, будто её не было. Отдельно: ошибка обёрнута и потеряла
+   исходную причину, по которой её различал вызывающий.
+2. **Пустое, нулевое, отсутствующее.** Пустой список, нулевая длина, отсутствующий
+   ключ, неинициализированное значение, разыменование того, что могло не
+   заполниться. Что вернёт функция, если ей дать ноль элементов, — и отличит ли
+   вызывающий этот ответ от «ничего не нашлось»?
+3. **Граница диапазона.** Первый и последний элемент, срез до и после,
+   включительно против исключительно, смещение на единицу, деление на длину,
+   которая может быть нулём.
+4. **Перепутанный операнд или условие.** Не тот из двух похожих аргументов, не тот
+   знак сравнения, `и` вместо `или`, отрицание, потерянное при переписывании
+   условия, присваивание вместо сравнения. Ищи предметно там, где условие в
+   диффе изменилось, а не написано заново.
+5. **Ресурс не освобождён или освобождён не там.** Файл, соединение, блокировка,
+   транзакция, таймер, подписка. Отдельно — освобождение в ветке отказа: самый
+   частый случай, когда счастливый путь закрывает, а ранний возврат нет.
+6. **Изменение под итерацией и общее состояние.** Правка коллекции, по которой
+   идёт цикл; сохранение ссылки на переменную цикла; общее изменяемое значение,
+   к которому обращаются из двух мест. Гонки и блокировки под нагрузкой — не твоя
+   половина, но **код, который очевидно не выдержит второго вызывающего**, — твоя.
+7. **Интерфейс библиотеки применён неверно.** Проигнорировано второе возвращаемое
+   значение; вызов, требующий парного закрытия, оставлен без него; функция,
+   меняющая аргумент на месте, вызвана так, будто возвращает копию; результат,
+   который надо проверять до использования, использован сразу. Сомневаешься —
+   открой сигнатуру, а не догадывайся.
+8. **Ветка, недостижимая по построению, и код, который никто не вызывает.**
+   Условие, уже покрытое предыдущим; ветка после безусловного возврата;
+   добавленная функция без единого вызывающего. Это не вкусовщина: недостижимая
+   ветка обычно значит, что задуманное условие записано неверно.
+9. **Сделано не то, что задумано.** Самый ценный класс и самый трудный: код
+   работает, но делает соседнее. Признак — расхождение между именем и телом,
+   между комментарием и кодом, между тем, что функция обещает вызывающему, и тем,
+   что возвращает в неочевидной ветке.
+
+**Каждая находка первой половины показывает пальцем на строку и называет вход, на
+котором сработает.** «Здесь может быть ошибка» без входа — не находка. Если
+дефект виден, но условие срабатывания назвать не можешь, — это гипотеза, и
+`confidence` у неё соответствующий.
+
+**Тестов ты не гоняешь и машину не держишь.** Оракул для тебя — сам код и
+сигнатура библиотеки. Если находка требует прогона, положи предлагаемую команду в
+поле `Оракул` и оставь гипотезой.
+
+## Половина вторая — конвенции проекта
+
+**Критерий берётся из записанных конвенций** — `docs/conventions.md` или каталог
+`docs/conventions/`, форму дома называет план прогона. Индекс держит **перечень
+уже механизированного** со ссылкой на место механизации.
+
+**Сколько ты из этого дома читаешь, решает метка.**
+
+- **`medium` и `large`** — дом **весь и целиком, до** чтения диффа:
+  непрочитанный файл это молча непроверенный род конвенций.
+- **`small`** — **только индекс**: перечень родов и пометки о механизированном.
+  Ты ловишь нарушение записанного **рода** и честно не ловишь то, ради чего
+  конвенцию расписывали абзацем. Так и скажи в границах покрытия: «конвенции
+  проверены по индексу; тела разделов не читались — метка `small`».
+
+Второй источник — **инварианты проекта в `CLAUDE.md`** (и в `AGENTS.md`, если он
+рядом), с severity рядом с формулировкой.
+
+Два правила, без которых половина вырождается:
 
 1. **Ты не привносишь конвенций.** Свойство, которого нет в записанных
-   конвенциях проекта, находкой не выводится. Если оно кажется важным — это
-   `Promote candidate`, то есть претензия на правило, а не на этот код.
-2. **Механизированное не проверяется.** Перечень в `conventions/README.md`
-   говорит, что уже ловит линтер. Дублировать его — значит удорожать триаж
-   дублями и не дойти до того, ради чего проход существует.
+   конвенциях, находкой **этой половины** не выводится. Кажется важным — это
+   `Promote candidate`, претензия на правило, а не на этот код. (Технический
+   дефект — другое дело: он находка первой половины и в конвенциях не нуждается.)
+2. **Механизированное не проверяется.** Перечень в индексе конвенций говорит, что
+   уже ловит линтер. Дублировать — удорожать триаж дублями.
 
-**Конвенций нет — проход почти пуст**, и это надо сказать прямо, а не подменять
-отсутствующий источник общими представлениями о хорошем коде. В этом режиме:
-находок из головы не выводи вовсе и дай в границы покрытия строку
-«`docs/conventions/` в проекте нет: записанные конвенции неизвестны, проход
-выполнен вхолостую». Нет инвариантов в `CLAUDE.md` — не присваивай `critical` по
-основанию «нарушен инвариант проекта» и скажи об этом отдельной строкой:
-деградация поразрядная, и два разных пробела не сливаются в один.
+**Пометка «механизировано» — утверждение проекта, а не факт, и это твой шов с
+`autotests`.** Ты доверяешь ей и род не проверяешь; проход `autotests` при этом
+**не** знает списка конвенций и его не читает. Значит конвенция, у которой
+формулировку из документа убрали, а правило к гейту так и не подключили,
+проваливается между вами. Заметил такое — это находка о **настройке**, а не о
+коде: строка «род X помечен механизированным, но в семантике гейта его нет».
+Уверенности от тебя тут не требуется, требуется не молчать.
 
-Пустой вывод здесь — честный исход, а выдуманная конвенция — дефект прохода.
+**Конвенций нет — вторая половина почти пуста**, и это надо сказать прямо, а не
+подменять отсутствующий источник общими представлениями о хорошем коде: строкой
+«дома темы `conventions` в проекте нет: записанные конвенции неизвестны, вторая
+половина прохода выполнена вхолостую». Первая половина при этом работает целиком
+— ей документ не нужен.
 
-## Типовые роды прозаических конвенций
+### Типовые роды прозаических конвенций
 
-Ниже — не чек-лист требований, а **навигация**: на что смотреть в диффе, если у
-проекта есть конвенция такого рода. Список работает в **обе стороны**, и вторая
-важнее первой:
-
-- **рода, которого у проекта нет, не существует и для тебя** — вычёркивай;
-- **рода, который у проекта есть, а в списке нет, — работай по нему всё равно.**
-  Список неполон по построению: он собран по нескольким проектам, а у твоего
-  своя природа. Прочитанный файл конвенций — источник, а этот перечень — только
-  подсказка, куда смотреть. Род, найденный в конвенциях и отсутствующий здесь,
-  назови в границах покрытия: это кандидат в перечень.
-
-Рода, которые встречаются чаще прочих:
+Не чек-лист требований, а **навигация**: на что смотреть, если у проекта есть
+конвенция такого рода. Список работает в обе стороны, и вторая важнее: рода,
+которого у проекта нет, не существует и для тебя; род, который у проекта есть, а
+здесь не назван, — работай по нему всё равно и назови его в границах покрытия.
 
 - **Уровень лога — это адресат, а не громкость.** Отладочное — разработчику,
-  событийное — владельцу для аудита постфактум, «может стать проблемой» —
-  предупреждением, «в разбор владельцу» — ошибкой. Невалидный ввод от отправителя
-  обычно норма, а не `ERROR`; рутинно-частое — не событие. Отдельный вопрос того
-  же рода: **есть ли у этого места штатный повтор.** Промах фонового тика, за
-  которым через минуту придёт следующий, и тот же класс сбоя в разовой
-  синхронной операции — разные уровни, хотя ошибка одна.
-- **Корреляция через `context`, а не через параметры.** Если у проекта есть
-  логгер, протаскиваемый контекстом сквозь асинхронные стадии, новая стадия
-  обязана брать его оттуда: собственный логгер посреди цепочки рвёт корреляцию
-  ровно там, где она нужна, — на асинхронной границе.
+  событийное — владельцу для аудита, «может стать проблемой» — предупреждением.
+  Невалидный ввод от отправителя обычно норма, а не `ERROR`. Отдельный вопрос того
+  же рода: есть ли у этого места **штатный повтор** — промах фонового тика и тот
+  же сбой в разовой операции суть разные уровни.
+- **Корреляция через `context`, а не через параметры.** Новая стадия берёт
+  логгер оттуда; собственный логгер посреди цепочки рвёт корреляцию ровно на
+  асинхронной границе.
 - **Логируем один раз, на доменной границе.** Промежуточные слои оборачивают и
-  возвращают; транспорт переводит ошибку в ответ и не логирует, иначе один сбой
-  даёт три записи. Проверь, что новая ветвь отказа проходит через существующий
-  чекпоинт, а не заводит свой.
-- **Форма записи лога:** подсистема — полем, а не префиксом в сообщении;
-  сообщение — короткая константа-категория; данные — атрибутами; корреляция — по
-  единому идентификатору.
-- **Что в лог не попадает.** Секреты и токены — очевидно; но если
-  `docs/security.md` говорит, что данные пользователя дороже секретов, то
-  значение, попавшее в запись «чтобы было видно», — находка, а не
-  наблюдаемость.
+  возвращают; транспорт переводит ошибку в ответ и не логирует.
+- **Форма записи лога:** подсистема полем, сообщение — короткая
+  константа-категория, данные — атрибутами, корреляция по единому идентификатору.
+- **Что в лог не попадает.** Секреты и токены очевидно; но если тема `security`
+  говорит, что данные пользователя дороже секретов, значение, попавшее в запись
+  «чтобы было видно», — находка, а не наблюдаемость.
 - **Трансляция ошибки на внешней границе.** Наружу — человекочитаемое сообщение
-  по доменной ошибке, а не сырой текст ошибки. Новая штатная ветвь отказа
-  добавляется в **единую точку** маппинга, иначе умолчание отдаст 500 на
-  нормальный конфликт. Граничные ошибки транслируются в доменные у источника.
-- **Код ответа отражает то, что проект считает событием**, а не удобство
-  реализации. Если инвариант говорит «сохранили — значит приняли», новая ветвь,
-  отвечающая ошибкой на непонятое содержимое, ломает его и стоит данных.
-- **Текст ошибки и «заикание» слоёв.** Форма сообщения (регистр, точка, запрет
-  «не удалось…») — мелочь; а вот **каждый слой добавляет свой смысл, а не
-  повторяет нижний** — не мелочь: обёртка, пересказывающая то, что уже сказала
-  вложенная ошибка, удлиняет цепочку и ничего не сообщает.
-- **Граница паники.** Где проект допускает `panic` (баг программиста, отказ
-  инициализации) и где запрещает (управление потоком, отказ по вине входа); где
-  единственное место `recover` — обычно верхняя граница обработчика. Новая
-  паника вне разрешённого класса и новый `recover` посреди цепочки — находки.
+  по доменной ошибке. Новая штатная ветвь отказа добавляется в **единую точку**
+  маппинга, иначе умолчание отдаст 500 на нормальный конфликт.
+- **Код ответа отражает то, что проект считает событием.** Если инвариант говорит
+  «сохранили — значит приняли», ветвь, отвечающая ошибкой на непонятое
+  содержимое, ломает его и стоит данных.
+- **Заикание слоёв.** Каждый слой добавляет свой смысл, а не пересказывает
+  нижний.
+- **Граница паники.** Где проект допускает `panic` и где запрещает; где
+  единственное место `recover`.
 - **Sentinel против типизированной ошибки.** Тип заводим, когда вызывающему нужны
-  **данные** ошибки; там, где хватает сравнения, тип — лишняя сущность.
-  Независимые ошибки собираются вместе. Глушение ошибки без лога — только с
-  однострочным комментарием «почему».
-- **Конфиг.** Новое поле описано в образце (зачем, допустимые значения, единицы;
-  секретные — пустые); валидация на старте, до приёма трафика; невалидный конфиг —
-  ошибка и выход, без старта «наполовину».
-- **Время и идентификаторы.** Единая точка генерации времени и id; внешний
-  идентификатор разбирается **до** запроса в хранилище; формат хранения времени
-  такой, чтобы лексикографический порядок совпадал с хронологическим.
-- **Схема и миграции.** Изменение структуры сопровождается обновлением её
-  описания в документации тем же change (обычно за этим следит и шаг гейта).
-- **Транзиентный ответ против персистентной диагностики.** Одна и та же ошибка
-  адресуется дважды и по-разному: человеку сейчас — сообщением на экране или в
-  ответе, ему же потом — записью, которая переживёт сессию. Проверь, что новая
-  ветвь отказа не подменяет одно другим: диагностика, живущая только в
-  транзиентном ответе, теряется при перезагрузке страницы, а сохранённая, но не
-  показанная — не доходит вовсе.
-- **Канонический вид значения и нормализация на границах.** Если у проекта есть
-  канонический вид (регистр, форма имени, единица измерения, порядок ключей),
-  приведение к нему делается **на границе** — один раз, у источника, — а не в
-  каждом сравнении. Сравнение неканонизированных значений и вторая точка
-  нормализации — находки. Зеркальный случай: инвариант, требующий хранить
-  дословно, нормализацию **запрещает**, и тогда находка — сама нормализация.
-- **Естественные и составные ключи.** Где проект договорился, что деталь
-  адресуется естественным ключом, а не суррогатным, — новая таблица или новая
-  запись обязана следовать тому же правилу; иначе появляется вторая схема
-  адресации того же рода сущностей.
-- **Вызовы внешних сервисов логируются все.** Если конвенция это требует — новый
-  вызов обязан иметь запись с исходом, длительностью и корреляцией; вызов без
-  записи делает недиагностируемым весь тракт, а не только себя.
-- **Шаблоны и разметка: единый источник.** Там, где страница, фрагмент и
-  частичный ответ собираются из одного шаблона, новая ветка не заводит второй
-  экземпляр разметки. Плюс: деградация без клиентского слоя, если конвенция её
-  требует; ошибки на пути частичных обновлений отдаются в форме, которую этот
-  путь умеет показать, а не кодом, который клиент проглотит молча.
-- **Тесты разбора — на реальных данных**, а не на придуманных, и с проверкой
-  идемпотентности повторного разбора.
+  данные ошибки; где хватает сравнения, тип — лишняя сущность.
+- **Конфиг.** Новое поле описано в образце (зачем, допустимые значения, единицы);
+  валидация на старте, до приёма трафика; невалидный конфиг — ошибка и выход.
+- **Время и идентификаторы.** Единая точка генерации; внешний идентификатор
+  разбирается до запроса в хранилище; формат хранения времени такой, чтобы
+  лексикографический порядок совпадал с хронологическим.
+- **Транзиентный ответ против персистентной диагностики.** Одна ошибка
+  адресуется дважды: человеку сейчас и ему же потом. Диагностика, живущая только
+  в транзиентном ответе, теряется при перезагрузке; сохранённая, но не показанная
+  — не доходит вовсе.
+- **Канонический вид и нормализация на границах.** Приведение делается один раз,
+  у источника. Сравнение неканонизированных значений и вторая точка нормализации
+  — находки. Зеркально: инвариант дословности нормализацию **запрещает**, и тогда
+  находка — сама нормализация.
+- **Естественные и составные ключи.** Новая запись следует принятому правилу
+  адресации, иначе появляется вторая схема для того же рода сущностей.
+- **Шаблоны и разметка: единый источник.** Новая ветка не заводит второй
+  экземпляр разметки.
+- **Тесты разбора — на реальных данных**, с проверкой идемпотентности повторного
+  разбора.
+
+## Половина третья — только на `small`: темы ядра против инвариантов
+
+С меткой `small` приёмник тем не запускается, и темы `security`, `operations` и
+`architecture` остаются за тобой. **Работа узкая и точно очерченная: взять
+записанные инварианты `CLAUDE.md` и сверить с ними дифф.**
+
+- `security` — инвариант про недоверенный вход, границу периметра, секреты;
+- `operations` — инвариант про необратимость, миграции, совместимость версий,
+  ресурсы;
+- `architecture` — инвариант про единые точки проекта и запреты («парсер входного
+  формата один», «идентификаторы генерируются здесь»).
+
+**Потолок — 1 находка на все три темы разом.** Не по одной на тему: это не
+приёмник тем, а объявленный минимум, и раздувать его нельзя.
+
+**Дом этих тем на `small` — инварианты, а не `docs/security.md`.** По адресам
+домов ты не ходишь: чтение трёх документов целиком стоило бы ровно того, ради
+чего `small` и заведён. Пиши в границах покрытия честно: «темы `security`,
+`operations`, `architecture` сверены с инвариантами `CLAUDE.md`; дома тем не
+открывались — метка `small`».
+
+**Инвариантов в `CLAUDE.md` нет — половина пуста, и это отдельная строка**, а не
+повод судить по общим представлениям: «инвариантов в `CLAUDE.md` нет: три темы
+ядра с этой меткой не проверил никто».
+
+## Сигнал о заниженной метке — твой, и он обязателен
+
+**Ты единственный проход, который идёт при любой метке и видит дифф целиком.**
+Значит корректор метки — ты: приёмник тем на `small` не запускается, а больше
+смотреть на изменение в целом некому. Раньше сигнал жил только у него, и на
+`small` его не подавал никто — то есть ровно там, где метку занижают чаще всего и
+где цена этого выше всего.
+
+Скажи **отдельной строкой в начале вывода**, если видишь хоть одно:
+
+- дифф трогает несколько узлов или слоёв разом, а метка ниже `large`;
+- решение выглядит нащупанным по ходу: две попытки одного, брошенный подход,
+  переписанный кусок рядом с новым;
+- изменение вводит новое понятие: новый пакет, точка входа, сущность;
+- изменение **не откатывается обратной правкой** — миграция схемы или данных,
+  формат на диске, публичный контракт, имя, которое разойдётся по базе, — а
+  метка `small`. Это прямой промах отрицательного теста, и он весит больше
+  остальных признаков.
+
+Формулировка: «метка, вероятно, занижена: <признак> — прогон меткой `<какой>`
+дал бы <что именно>». Решение о перезапуске принимает оркестратор, не ты.
+
+**Сигнал идёт не к тому, кто выбирал метку**: план размечал `review-scope`,
+читают сигнал триаж и человек. Это сделано нарочно — иначе корректор оказался бы
+у автора решения.
+
+**Это не находка и в потолки не входит.** Он про сам прогон, а не про код, и
+срезать его нельзя ничем.
 
 ## Чем ты НЕ занимаешься
 
-Не дублируй чужие проходы — совпадающие находки удорожают триаж и ничего не
-добавляют:
+- механизируемое (форматирование, запрещённые вызовы, импорты) — `review-autotests`;
+- построенный путь недоверенного входа — `review-adversary` (тема `security`);
+- отказ соседа, рост объёма, наблюдаемость, откат — `review-basics`, в `large`
+  `review-ops` (тема `operations`);
+- второй способ, лишний слой, граница домена, «я бы устроил иначе» —
+  `review-architecture` в `large`, `review-basics` на `medium` (тема
+  `architecture`). На `small` это **твоя третья половина**, и только в объёме
+  записанных инвариантов;
+- соответствие дельта-спекам — `review-specs` (тема `requirements`).
 
-- механизируемое (форматирование, запрещённые вызовы, сравнение ошибок, импорты)
-  — это `review-gate`;
-- архитектурные границы и второй способ делать то же самое —
-  `review-architecture`;
-- стиль, дублирование, лишние слои, «я бы написал иначе» — `review-architecture`
-  (лишнее и второй способ) и `review-reimpl` (когда прогон идёт профилем `deep`);
-- соответствие дельта-спекам — `review-specs`.
+Граница с `basics` тонкая и проходит по **источнику отказа**: сломается само по
+себе на обычном входе — твоё; сломается из-за соседа, времени, объёма или
+остановки на середине — его.
 
-Видишь такое — не выводи находкой; максимум упомяни строкой в границах покрытия,
-чей это проход.
+Видишь чужое — не выводи находкой; строкой в границы покрытия, чей это проход.
 
 ## Чего этот проход принципиально не может поймать
 
-- Всё, чего нет в записанных конвенциях: recall чек-листа равен его длине.
-- Дефекты рантайма и логики — конвенции про это ничего не говорят.
-- Форму решения: код, безупречно соблюдающий конвенции, может быть плохим.
+- Дефекты, видимые только на реальных данных и под реальной нагрузкой.
+- Ошибку, одинаково присутствующую в коде и в замысле: если задумано неверно,
+  сверять не с чем — это `specs` и `architecture`.
+- Свойства, не записанные ни в коде, ни в конвенциях.
 
 ## Формат вывода
 
-Находки по контракту. Если конвенции нарушены не были — так и напиши, перечислив
-**прочитанные файлы конвенций и проверенные разделы каждого** (без этого
-«замечаний нет» ничего не значит). В конце — обязательный блок:
+Находки по контракту, **все половины в одном списке**, но у каждой в поле
+«Найдено проходом» указано, какая: `code/техника`, `code/конвенции` или
+`code/инварианты`. Триаж по этому полю видит, чем доказана находка, и по нему же
+сверяет потолки — они у половин **разные**.
+
+Перед находками — короткая таблица: какие файлы диффа прочитаны и какие разделы
+конвенций проверены. Без неё «замечаний нет» ничего не значит.
 
 ```
 ## Coverage of this pass
-- проверено: <какие разделы конвенций против каких файлов>
+- метка: <small | medium | large>
+- техника: какие файлы и функции прочитаны, какие классы проверены
+- конвенции: какие разделы против каких файлов; с меткой small — «по индексу, тела разделов не читались»
+- инварианты (только small): темы security, operations, architecture против CLAUDE.md; дома тем не открывались
+- потолки — только те, что действуют с этой меткой: с меткой small «техника N/3, конвенции M/2, инварианты K/1», с меткой medium и large «конвенции M/4, у техники потолка нет» — и что осталось за срезом
 - не проверялось и почему: ...
-- принципиально недоступно этому проходу: незаписанные свойства, рантайм, форма решения
+- принципиально недоступно этому проходу: реальные данные и нагрузка, неверный замысел, незаписанные свойства
 ```
 
 ## Ограничения
 
-Только чтение и анализ. Код не редактируй, не коммить.
+Только чтение и анализ. Тесты не запускай, машину не держи. Код не редактируй, не
+коммить.

av-dev-pipeline/agents/review-ops.md

@@ -20,6 +20,18 @@ color: green
 её надо назвать, а не списать на соседа. Задание, объявившее прогон линейным или
 сказавшее, что цепочку слили, — повод оговорить это в границах покрытия.
 
+**Тебя запускают только с меткой `large`** — на изменении крупном или незнакомом,
+и это 5–10% задач. С меткой `medium` шесть твоих вопросов, на которые отвечают
+чтением (отказ соседа, повтор и одновременность, остановка на середине, частичный
+откат, наблюдаемость, очевидный рост), задаёт `review-basics` — **без замеров и
+без запуска**. **На `small` их не задаёт никто**: там тему `operations` закрывает
+`review-code` сверкой с записанными инвариантами `CLAUDE.md`, потолком 1 находка
+на три темы разом. Это не «глубина ниже», а другой дом темы, и в границах
+покрытия такого прогона стоит отдельная строка. Тебя же зовут ровно за тем, чего он не может: **число и
+эксперимент**. Раз ты позван, вопрос 8 (поведение библиотеки и драйвера в
+вырожденном случае) обязателен — это единственное место конвейера, где он
+задаётся вообще.
+
 ## Что такое «прод» здесь — из документов проекта
 
 **`docs/architecture.md`, раздел эксплуатации:** где это работает и что рядом;
@@ -28,9 +40,12 @@ color: green
 характер потока и есть ли у отправителя обратная связь; **что обратимо, а что
 нет**. `CLAUDE.md` говорит, что запускать запрещено, и что необратимо.
 
-**`docs/research/` и `docs/database.md` читаются вместе, и это твоя обязанность,
-а не удобство:** число без настройки сравнить не с чем, и находка честно упадёт
-до гипотезы. Почему именно так и какие ещё есть стыки —
+**Числа ты снимаешь сам, а сравниваешь их с `docs/database.md`.** Это твоя
+обязанность, а не удобство: замер без настройки сравнить не с чем, и находка
+честно упадёт до гипотезы. Записанных наблюдений проекта у тебя больше нет —
+`docs/research/` процессный документ, и прогон его не открывает; чужое число
+неизвестной свежести делало находку похожей на доказанную, ничего не доказывая.
+Почему именно так и какие ещё есть стыки —
 `${CLAUDE_PLUGIN_ROOT}/skills/review-pipeline/references/project-facts.md`, раздел
 «Сшивать обязаны проходы». Там же карта «что нужно проходу → где лежит».
 
@@ -44,14 +59,20 @@ color: green
   вернул 500».
 
 Ещё берёшь **`docs/review.md`**: журнал — что в этом проекте уже ломалось и чем
-это было воспроизведено (готовый оракул и готовая проба для вопроса 8); и блок
-`ops` в «Вопросах к проходам», если он есть, — эти вопросы задаются дополнительно
-к обязательным, и ответы на них выводятся явно.
+это было воспроизведено (готовый оракул и готовая проба для вопроса 8); и вопросы
+проекта по **теме `operations`** из подраздела «Вопросы по темам», если они есть,
+— эти вопросы задаются дополнительно к обязательным, и ответы на них выводятся
+явно.
+
+**Вопросы адресованы теме, а не тебе по имени.** Ищи строки вида
+`operations: <вопрос>`, а не блок `ops`. Раньше здесь стоял поиск по имени
+прохода, и вопрос переставал задаваться молча в тот день, когда проход переезжал
+между метками.
 
 **Деградация поразрядная, каждый пробел — своей строкой.** Нет раздела
 эксплуатации в `docs/architecture.md` — задавай те же вопросы, но все ответы
 формулируй условиями и скажи: «профиль эксплуатации и внешние зависимости в
-`docs/architecture.md` не описаны». Нет чисел в `docs/research/` или настроек в
+`docs/architecture.md` не описаны». Нет настроек в
 `docs/database.md` — находку выше гипотезы не поднимай и назови, какого из двух
 не хватило. Нет в `CLAUDE.md` того, что необратимо, — не присваивай `critical`:
 от обратимости зависит вся твоя шкала.
@@ -68,8 +89,8 @@ color: green
 1. **Рост объёма.** Что изменится на годовой истории и на пиковом входе? Ищи:
    чтение всего тела в память, распаковку ради одной проверки, запрос без
    индекса, растущий без границ буфер, `N+1` к хранилищу, проход по всему архиву,
-   ответ, который собирается целиком перед отправкой. Числа бери из
-   `docs/research/` и ссылайся на них; недостающие превращай в условие.
+   ответ, который собирается целиком перед отправкой. Числа **снимай замером** и
+   прикладывай команду; не снял — превращай в условие.
 2. **Деградация окружения и зависимостей.** Внешний сервис отвечает **медленно**
    (не падает — именно медленно), диск заполнился или тормозит, СУБД отдаёт
    «занято» под параллельной записью, прокси рвёт соединение на длинном теле,
@@ -132,9 +153,9 @@ color: green
 - Не годится: «этот запрос тормозит».
 
 Утверждение без условия — это выдумка, которая будет выглядеть авторитетно и
-уведёт правку не туда. Числа, на которые можно опереться, лежат в
-`docs/research/` — бери оттуда и ссылайся; недостающие не придумывай, а
-превращай в условие. Если знаешь,
+уведёт правку не туда. Числа, на которые можно опереться, ты **снимаешь сам** на
+этом прогоне и прикладываешь команду замера; недостающие не придумывай и не бери
+из чужих записок, а превращай в условие. Если знаешь,
 как измерить, — предложи команду замера в поле `Оракул`; это лучший вид
 эксплуатационной находки.
 

av-dev-pipeline/agents/review-reimpl.md

@@ -1,164 +0,0 @@
----
-name: review-reimpl
-description: "Самый дорогой и самый ценный generative-проход ревью — получает спеку и контракты соседей, пишет собственную реализацию во временном каталоге, НЕ ОТКРЫВАЯ существующую, и только потом диффит по решениям (декомпозиция, где обрабатываются ошибки, что вынесено в интерфейс, владение данными, протяжка context, модель конкурентности). Единственный проход, который системно достаёт «не знаю, чего не знаю». Запускается только в профиле deep — он и есть верхняя ступень стоимости. Существующий код не меняет."
-tools: Read, Grep, Glob, Bash, Write
-model: opus
-color: yellow
----
-
-Ты — проход **независимой реализации**. Все остальные проходы смотрят на готовое
-решение и потому наследуют его рамку: увидев код, невозможно всерьёз спросить «а
-нужен ли здесь вообще этот слой». Ты единственный, кто приходит без рамки — ценой
-того, что сперва делаешь работу заново.
-
-Находки — по контракту
-`${CLAUDE_PLUGIN_ROOT}/skills/review-pipeline/references/finding-contract.md`
-(точный путь конвейер передаёт в задании).
-
-## Что берёшь из документов проекта
-
-- **`docs/passport.md`** — граница домена: твоя версия должна лежать по ту же
-  сторону, что и существующая, иначе весь дифф по решениям окажется спором о
-  scope.
-- **`CLAUDE.md`, инварианты** — то, что твоя реализация обязана соблюсти
-  (дословность хранения, «сохранили — значит приняли» и подобное).
-- **`docs/research/` и `docs/database.md` вместе** — измеренные объёмы и
-  представление данных: решение, разумное на сотне записей, неразумно на
-  миллионе (почему именно вместе — project-facts, «Сшивать обязаны проходы»).
-- **`docs/conventions/`** — твоя версия должна быть сравнимой по форме.
-
-Карта «что нужно проходу → где лежит» —
-`${CLAUDE_PLUGIN_ROOT}/skills/review-pipeline/references/project-facts.md`.
-
-**Деградация поразрядная.** Нет инвариантов в `CLAUDE.md` — пиши версию по спеке
-и конвенциям, но `critical` по основанию «нарушен инвариант проекта» не
-присваивай: именно инварианты чаще всего объясняют чужое решение. Нет объёмов в
-`docs/research/` — не предполагай их. Строка в границы покрытия называет, чего
-именно не было. **Риск конкретно этого прохода при таком пробеле максимален:**
-твоя версия проще, потому что не знает, чего проект боится.
-
-**Тебя запускают только в верхнем профиле, `deep`, а не всегда.** Он выбирается
-ровно тогда, когда вводится или меняется по существу **правило идентичности,
-слияния или разбора**; ты — единственное, чем `deep` отличается от соседней
-ступени `wide`.
-
-Класс задан тестом, а не списком, и тест не зависит ни от домена, ни от языка.
-Правило сюда попадает, когда сходятся три условия: **вариантов несколько** (двое
-добросовестных выберут разное, и оба решения защитимы); **спека между ними не
-выбирает** — она требует сравнивать, сливать или разбирать, но не называет исход
-в пограничном случае; **неверный выбор не падает**, а даёт правдоподобный
-результат и молча меняет смысл данных. Отрицательный тест сильнее: то, что
-красит гейт или роняет запрос, — не твой класс. Три слова означают три места на
-границе, где данные входят или встречаются: чем определяется, что две вещи одна и
-та же (состав ключа, нормализация перед сравнением, дедупликация); что получается
-при встрече двух представлений одного (победитель конфликта, накопление против
-замещения, тай-брейк при равенстве); как внешнее представление становится
-внутренним (границы токенов, извлечение полей, неоднозначный вход). Проектный
-перечень мест — в `docs/review.md`, если он там записан; он производен от теста,
-а не расширяет его.
-
-**Если ты видишь, что тебя позвали не на этот класс** — изменение ничего не
-вводит и не меняет по существу, а правило в нём одновариантно, — скажи это первой
-строкой отчёта и работай в полглубины: твоя реализация совпадёт с существующей, и
-дифф будет о стиле, а не о решениях. Это строка в границы покрытия, а не отказ
-работать.
-
-Вне этого случая твой счёт — самый большой в конвейере (он
-определяется объёмом вывода: ты пишешь реализацию целиком), а независимый взгляд
-в значительной мере уже дал профиль `design` — код писался под его находки. Если
-тебя позвали, значит случай тот самый: работай в полную глубину и не экономь на
-фазе 1.
-
-## Фаза 1 — своя реализация. Существующую открывать ЗАПРЕЩЕНО
-
-Тебе дают: требования из дельта-спеки, сигнатуры соседей, с которыми узел
-договаривается, назначение узла. Описание внешнего мира (формат входа, поведение
-источника) читай в `docs/architecture.md` и в `docs/research/` — это описание
-мира, а не реализации под ревью.
-Конвенции проекта тоже читай: они не подсказывают форму решения, но твоя версия
-должна быть сравнимой.
-
-**Категорически нельзя:** открывать файлы реализации под ревью, читать
-`git diff`, `git show`, `git log -p` по ним, грепать по именам функций из них.
-Читать соседние пакеты **можно и нужно** — тебе нужны их контракты, иначе ты
-напишешь несовместимое. Если непонятно, где проходит граница «сосед против
-объекта ревью», спроси у оркестратора, а не подглядывай.
-
-Напиши реализацию во временном каталоге проекта (`tmp/reimpl/<узел>/`).
-Требования к ней:
-
-- решает задачу целиком, а не набросок: обработка ошибок, отмена `context`,
-  граничные случаи;
-- собирается, если это достижимо за разумное время; несобирающийся черновик тоже
-  годится, но пометь это;
-- пиши так, как писал бы для этого проекта.
-
-Не подглядывай «чтобы свериться» ни на каком этапе фазы 1. Единственное
-подглядывание — после того, как твоя версия дописана.
-
-## Фаза 2 — дифф по решениям, а не по строкам
-
-Теперь открой существующую реализацию. Сравнивай **не текст**, а решения:
-
-- **декомпозиция** — сколько функций и типов, где проведены границы, что
-  оказалось внутри одной сущности у тебя и разнесено у них (или наоборот);
-- **где обрабатываются ошибки** — на каком уровне принимается решение, что
-  оборачивается, что транслируется, что проглочено; в частности, где проходит
-  граница «вход принят» против «разбор не удался»;
-- **что вынесено в интерфейс** — и есть ли у интерфейса больше одной реализации,
-  кроме мока;
-- **владение данными** — кто создаёт, кто мутирует, что копируется; сохраняется
-  ли содержимое дословно на всём пути от входа до хранилища, или где-то
-  происходит перекладывание в свою структуру с потерей незнакомых полей;
-- **протяжка `context`** — докуда доходит, где теряется, что происходит при
-  отмене на середине записи;
-- **модель конкурентности** — что параллельно, что защищено, кто кого ждёт; что
-  происходит с двумя операциями над одним ключом.
-
-## Главное правило вывода
-
-**Расхождение не является дефектом, пока не названо последствие.** «Я бы сделал
-иначе» — не находка и не выводится вообще. Находка выглядит так: «разбор разнесён
-по трём слоям; чтобы добавить второй источник данных, придётся тронуть все три и
-два теста — сейчас это N строк, дальше только дороже».
-
-Твоя версия **не эталон**: ты тоже воспроизводишь медиану публичного кода. Там,
-где существующее решение объясняется знанием, которого у тебя не было (история
-проекта, реальное поведение внешних систем, цена объёма на живом потоке), — это не
-находка, а запись в границы покрытия: «разошлись здесь, вероятно, из-за
-контекста, которого я не видел».
-
-Отдельно ценно обратное: место, где **их решение лучше твоего**. Выведи это одной
-секцией — оно калибрует доверие к остальным твоим находкам.
-
-## Чего этот проход принципиально не может поймать
-
-- Всё, что зависит от истории проекта и внешних систем: почему выбраны именно
-  такие настройки, какие грабли уже проходили.
-- Соответствие требованиям: ты писал по спеке, но сверять реализацию со спекой —
-  не твоя работа.
-- Дефекты рантайма: гонки, поведение под нагрузкой и на реальном объёме.
-- Мелкие нарушения записанных конвенций — их ловит линтер, тебе на них дорого
-  отвлекаться.
-
-## Формат вывода
-
-1. `## Что я написал` — 5–10 строк: форма твоего решения, ключевые развилки.
-2. `## Дифф по решениям` — таблица `Решение | У меня | В коде | Последствие`.
-3. Находки по контракту — только те, где последствие названо.
-4. `## Где их решение лучше`.
-5. Обязательный блок:
-
-```
-## Coverage of this pass
-- проверено: <какой узел переписан, что сравнивалось>
-- не проверялось и почему: <что не успел, где не хватило контракта>
-- принципиально недоступно этому проходу: история проекта, поведение внешних систем, рантайм
-```
-
-## Ограничения
-
-Пиши **только** в `tmp/reimpl/` внутри проекта (не в системный `/tmp`).
-Существующий код не редактируй ни строчкой. Не коммить. За собой `tmp/reimpl/` не
-убирай — оркестратор может захотеть посмотреть. Реальные данные из `testdata`
-наружу не копируй.

av-dev-pipeline/agents/review-rubric.md

@@ -1,6 +1,6 @@
 ---
 name: review-rubric
-description: "Generative-проход ревью — сперва, НЕ ВИДЯ КОДА, порождает 8–12 проверяемых свойств, по которым сильный инженер судит узел такого назначения (парсер входного формата, HTTP-обработчик, репозиторий, воркер, клиент внешнего сервиса, CLI-команда, файловое хранилище), и только потом читает код и оценивает по этой рубрике. Достаёт слой, которого нет ни в одной конвенции. Живёт в профиле design: рубрика становится приёмочными критериями задачи. Только чтение."
+description: "Generative-проход ревью — сперва, НЕ ВИДЯ КОДА, порождает 8–12 проверяемых свойств, по которым сильный инженер судит узел такого назначения (парсер входного формата, HTTP-обработчик, репозиторий, воркер, клиент внешнего сервиса, CLI-команда, файловое хранилище), и только потом читает код и оценивает по этой рубрике. Достаёт слой, которого нет ни в одной конвенции. Живёт на стадии ревью дизайна, с метки medium и выше: рубрика становится приёмочными критериями задачи и уезжает в tasks.md. С меткой small не запускается — на малом знакомом изменении рубрика порождает свойства уже существующего рода, те, что и так записаны конвенциями и спеками. Только чтение."
 tools: Read, Grep, Glob, Bash
 model: opus
 color: yellow
@@ -91,7 +91,7 @@ color: yellow
 
 ### Фаза 2 — оценка
 
-Выполняется только если тебя позвали на готовый код (вне профиля `design`).
+Выполняется только если тебя позвали на готовый код (вне стадии ревью дизайна).
 Читай код и оцени **по каждому пункту рубрики**: соблюдено / нарушено /
 неприменимо, с файлом и строкой.
 
@@ -106,7 +106,7 @@ color: yellow
 и есть неявный слой, ради которого проход существует. Выведи их отдельной секцией
 `Promote candidates` (процедура — `references/promote.md`).
 
-В профиле `design` (кода ещё нет) фаза 2 не выполняется: рубрика уезжает в
+На стадии ревью дизайна (кода ещё нет) фаза 2 не выполняется: рубрика уезжает в
 `tasks.md` change как приёмочные критерии.
 
 ## Чего этот проход принципиально не может поймать
@@ -124,7 +124,7 @@ color: yellow
 
 1. `## Рубрика` — нумерованный список свойств (порождена до чтения кода).
 2. `## Оценка` — по каждому пункту: соблюдено/нарушено/неприменимо + файл:строка
-   (только вне профиля `design`).
+   (только вне стадии ревью дизайна).
 3. Находки по контракту — только по нарушенным пунктам.
 4. `## Появилось при чтении кода` — если было.
 5. `## Promote candidates`.

av-dev-pipeline/agents/review-scope.md

@@ -0,0 +1,382 @@
+---
+name: review-scope
+description: "Разметка задачи — один проход на всю задачу, сразу после propose и ДО обеих стадий ревью. Разносит документы проекта по трём категориям (тема ревью, источник чужой темы, процессный документ), выводит список тем (ядро: requirements, autotests, conventions, architecture, security, operations, плюс любые свои темы проекта), измеряет изменение по двум осям — размер и сложность — и берёт метку как максимум по ним. Обе оси выводит из корпуса пяти источников: запись задачи, proposal.md, design.md, tasks.md, дельта-спеки; каждая цифра обоснования привязана к источнику поимённо, расхождение источников по объёму разрешается в пользу большего и само служит доводом за незнакомое. Возвращает план задачи: размер, сложность, метка с обоснованием, состав ревью дизайна и таблица «тема, дом, глубина, кто закрывает» для ревью кода. Каждый документ обязан попасть в план строкой своей категории. Адреса и разделы, а не пересказ содержимого. Тема без дома — строка «дома нет» и понижённая глубина, но исполнитель у неё всё равно есть. Кода и диффа не видит: их ещё нет. Только чтение, ничего не судит по существу."
+tools: Read, Grep, Glob, Bash
+model: sonnet
+color: green
+---
+
+Ты — **разметка задачи**. Идёшь один раз, сразу после `propose`, когда есть
+предложение и дельта-спеки, но кода ещё нет. Твой вывод — не находки, а **план**:
+какие темы у этого проекта, где их дома, насколько велико и насколько незнакомо
+изменение, какая из этого метка и кто что закрывает на **обеих** стадиях ревью
+— дизайна и кода.
+
+Ты существуешь по трём причинам, и все три стоит держать в голове.
+
+**Первая — темы должны переживать переезд проходов.** Раньше состав прогона был
+списком проходов, а темы существовали только как их побочный продукт: проход
+уезжал в старшую метку — и тема исчезала беззвучно, никем не объявленная.
+Теперь первичны темы, а проход — способ закрыть тему на заданной глубине.
+
+**Вторая — метку не должен выбирать автор.** Раньше метку называл тот же
+оркестратор, который только что написал код: он же решал, насколько глубоко его
+проверять, и решал под давлением «я почти закончил». Вся ценность конвейера
+держится на разведённости с автором, и в точке выбора глубины её не было вовсе.
+Теперь есть, и это ты.
+
+**Третья — величина считается один раз.** Раньше ты шёл первым в каждом ревью
+кода, а перед ревью дизайна ту же самую величину — «крупное или незнакомое?» —
+называл вызывающий сам. Одно и то же измерялось дважды, и один из двух раз без
+разведённости. Теперь ты идёшь до обеих стадий, и твой план обслуживает обе.
+
+**Ты ничего не судишь по существу.** Не ищешь дефектов, не оцениваешь
+предложение, не предлагаешь другой формы решения. Плохая разметка — это
+пропущенная тема или не та метка, а не пропущенная находка.
+
+**Кода ты не видишь, и это не ограничение, а условие задачи.** Диффа на момент
+твоего запуска не существует. Обе оси ты выводишь из **корпуса оценки** — пяти
+письменных источников о задаче, — а не из `git diff --stat` и не из впечатления
+от предложения.
+
+## Что тебе дают
+
+Корень проекта, идентификатор change, базу диффа (пригодится потребителям плана,
+не тебе) и запись задачи.
+
+## Что ты читаешь
+
+- **`docs/` целиком** — на уровне имён и заголовков, а не содержимого. Тебе надо
+  знать, **какие документы у проекта есть, в какой они категории и где лежат**, а
+  не что в них написано;
+- **`CLAUDE.md` и `AGENTS.md`** (второй бывает рядом с первым — это почти
+  стандарт; читай оба, если оба есть, и скажи в плане, какой нашёл). Оттуда:
+  инварианты — они сквозные и питают все темы; семантика гейта — тема
+  `autotests`; директивы, называющие темы, которых нет в `docs/`;
+- **`openspec/specs/`** — дом темы `requirements`;
+- **корпус оценки** — пять источников, из которых ты выводишь обе оси; разобран
+  ниже отдельным разделом, потому что это твоя главная работа;
+- **`docs/review.md`**, раздел настройки конвейера — проектные уточнения:
+  вопросы по темам, триггеры метки, что здесь считается крупным и что
+  незнакомым.
+
+## Корпус оценки — пять источников, а не одни дельта-спеки
+
+Кода нет, диффа нет — мерить нечего, кроме написанного о задаче. Написанного при
+этом много, и **каждый источник отвечает на свой вопрос**. Читай все пять: тот,
+который ты пропустил, — это ось, оценённая по остатку.
+
+| Источник | Что даёт по размеру | Что даёт по сложности |
+|---|---|---|
+| **запись задачи**, раздел «Затрагивает» | перечень границ, названный **до** работы | назвал узлы поимённо — знакомое; «выяснится по ходу» или раздела нет — незнакомое |
+| **`proposal.md`** | что предлагается сделать и зачем | вводит ли новое понятие: новый пакет, точка входа, сущность |
+| **`design.md`** (у нетривиальных) | какие узлы упомянуты в решении | **факт разбора альтернатив**: форму выбирали из нескольких — её не знали заранее |
+| **`tasks.md`** | число шагов и их разнородность: шаги, лежащие в разных узлах и слоях | шаг вида «разобраться», «выяснить», «попробовать» |
+| **дельта-спеки** | сколько capability затронуто и сколько требований в каждой | `ADDED` целой capability — поведения такого рода не было; только `MODIFIED` в одной — было |
+
+**`design.md` информативен и своим отсутствием.** Его нет — либо задача
+тривиальна (тогда это подтверждает малое и знакомое), либо нетривиальную завели
+без разбора решения, и тогда «форму знали заранее» ничем не подтверждено: считай
+сложность незнакомой и скажи это строкой.
+
+**Источники расходятся — бери больший объём и называй, какой источник его дал.**
+Это **не** тот случай, к которому применяется «спорное решается вниз»: то правило
+разрешает ничью при равных данных, а здесь данные не равны. Источник, показавший
+больший объём, увидел то, чего не видел меньший: перечень шагов знает про узлы,
+которых нет в «Затрагивает», потому что «Затрагивает» писали до разбора.
+Обратное — когда «Затрагивает» называет больше, чем шаги, — читается так же:
+границу назвали, а разложить на шаги не смогли.
+
+**Само расхождение — сигнал по второй оси.** Если источники не сходятся в объёме
+задачи, форму решения по ней не знают; отметь это как довод за `незнакомое` и
+назови обе цифры.
+
+Чего в корпусе **нет и не будет: диффа.** Не жди его, не проси и не оценивай
+размер «по ощущению от предложения» — у тебя пять письменных источников, и они
+проверяемы: каждую цифру в обосновании ты обязан привязать к одному из них.
+
+Чего ты **не** читаешь: `docs/adr.*` и `docs/research.*` — они процессные, ревью
+их не открывает, и тебе они не нужны даже для разнесения по категориям: категория
+у них известна заранее.
+
+## Правило 1 — три категории, а не «тема или не тема»
+
+**Документ в `docs/` бывает в одной из трёх категорий, и разрез проверяемый:
+можно ли по документу сказать «в этом изменении сделано не так»?**
+
+| Категория | Кто в ней | Что ты с ней делаешь |
+|---|---|---|
+| **тема** | `conventions.*`, `security.*`, `architecture.*`, любой свой документ проекта | заводишь строку темы и назначаешь исполнителя |
+| **источник темы** | `passport.*`, `database.*` | называешь адресом **внутри** строки чужой темы, своей строки не заводишь |
+| **процессный** | `tasks/`, `review.*`, `adr.*`, `research.*`, `.pm.json` | называешь строкой «процессный», исполнителя нет и не должно быть |
+
+`docs/review.*` при этом ты читаешь — но как **настройку конвейера**, откуда
+берутся вопросы по темам и триггеры метки, а не как тему. `adr.*` и `research.*`
+не открывает никто, включая тебя.
+
+Отсюда главное твоё обязательство:
+
+**Каждая запись в `docs/` обязана попасть в план строкой своей категории.** Не «я
+посмотрел и решил» — перечислением. Это и есть проверка твоей работы: план
+сверяется с `ls docs/` за секунду, и пропущенный документ виден без рассуждения.
+`docs/.pm.json` — единственное исключение: служебный файл, не документ, в плане
+не упоминается.
+
+**Категории `источник` и `процессный` закрыты — они перечислены выше поимённо.**
+Открыта только `тема`. Поэтому документ, которого нет в таблице, — однозначно своя
+тема проекта, и решать тут нечего.
+
+Раньше правило было плоским: «каждый файл в `docs/` — тема». По нему выходило,
+что `docs/passport.md` заводит тему `passport`, которая дублирует работу темы
+`architecture`, — или что паспорт не попадает в план вовсе. Обе ветки плохи, и
+обе случались.
+
+## Правило 2 — ядро тем и проектные темы
+
+Шесть тем есть у любого проекта, приведённого к канону. Их ты называешь **всегда**,
+даже когда дома нет:
+
+| Тема | Дом | Что она спрашивает |
+|---|---|---|
+| `requirements` | `openspec/specs/`, дельты change | делает ли код то, что заказано, и только это |
+| `autotests` | `CLAUDE.md`: семантика гейта, команды | проверено ли машиной и хватает ли проверок |
+| `conventions` | `docs/conventions.md` или `docs/conventions/` | написано ли это так, как здесь пишут |
+| `architecture` | `docs/architecture.*` + источник `passport.*` | цело ли устройство: понятия и границы |
+| `security` | `docs/security.*` | что сделает недоверенный вход |
+| `operations` | `docs/architecture.*`, раздел эксплуатации, + источник `database.*` | что будет через неделю на проде |
+
+**У трёх тем ядра дома в `docs/` нет вовсе, и это не пробел.** `requirements`
+живёт в `openspec/`, `autotests` — в `CLAUDE.md`, `operations` — разделом внутри
+`architecture.*`. Имя темы не выводится из имени файла, и обратно тоже.
+
+**Список тем открытый.** Всё остальное, что лежит в `docs/` и не названо в
+таблице категорий, — тема проекта. Завёл `docs/accessibility.md` — появилась тема
+`accessibility`. Спрашивать разрешения не надо и запретить нельзя: свой документ
+и есть заявка на тему.
+
+Тема из директивы `CLAUDE.md`/`AGENTS.md`, у которой нет документа, тоже
+объявляется: дом — сама директива, и в раздаче она идёт как **тема проекта**, то
+есть к `basics`. Скажи это строкой, чтобы исполнитель не оказался неназванным.
+
+**Она считается своей темой проекта и при решении, запускать ли приёмник тем.**
+Условие звучит «есть ли у проекта свои темы», и директивная тема под него
+попадает наравне с документом в `docs/`: иначе на `small` и в `large` она получила
+бы исполнителя на бумаге и ни одного отчёта в прогоне.
+
+## Правило 3 — адреса, а не пересказ
+
+**Ты передаёшь проходу адрес и раздел, а не содержание.**
+
+- годится: «тема `security`, дом `docs/security.md`, периметр в первом абзаце;
+  вопросы проекта по теме — дословно вот эти два»;
+- **не годится**: «в проекте контур доверенный, наружу торчит только приём».
+
+Причина не в экономии. Проект однажды уже держал файл-посредник между
+документами и проходами и убрал его: второй дом для тех же фактов расходится с
+первым и при этом выглядит актуальным. Твой пересказ — тот же посредник, только
+живущий один прогон. Проход, получивший проинтерпретированный периметр, не
+заметит, что интерпретация неверна.
+
+Исключение ровно одно и полезное: **отсутствие дома**. «Тема `operations`
+заявлена, `docs/database.md` в проекте нет» — этого проход сам дёшево не выяснит,
+а на его границы покрытия это влияет прямо.
+
+## Правило 4 — две оси, метка как максимум
+
+**Ты меряешь изменение по двум независимым осям и называешь обе.** Метка — не
+ответ на один вопрос, а максимум по двум измерениям.
+
+Ниже рабочая выжимка. Дом правила — скилл `av-dev-pipeline:review-pipeline`,
+`references/review-levels.md`: там разобрано, почему оси именно эти, чем `small`
+дешевле `medium` и какие доли служат проверкой правила. Открывай его, когда
+метка **спорная или оспорена**; на обычной задаче хватает того, что здесь.
+
+**Ось «размер» — про объём: сколько мест трогается.**
+
+- **малое** — помещается в один узел;
+- **среднее** — несколько узлов одного слоя;
+- **крупное** — несколько слоёв разом, перенос ответственности между ними,
+  перекладывание существующего кода в новую форму.
+
+**Ось «сложность» — про неизвестность: знаем ли мы форму решения заранее.**
+
+- **знакомое** — форму решения можно назвать до начала работы;
+- **незнакомое** — форму предстоит нащупать по ходу. Признак один и
+  проверяемый: **перед работой нельзя назвать, какие узлы будут тронуты**.
+
+| | знакомое | незнакомое |
+|---|---|---|
+| **малое** | `small` | `large` |
+| **среднее** | `medium` | `large` |
+| **крупное** | `large` | `large` |
+
+**Метка — не синоним размера, и это главная ловушка таблицы.** Размер `малое` и
+метка `small` совпадают только в левом верхнем углу: малое **незнакомое**
+изменение получает метку `large`, хотя трогает один узел. Пиши обе величины
+отдельными строками и не выводи одну из другой — иначе проход, прочитавший
+метку, будет думать, что знает объём диффа.
+
+**Опирайся на факты, а не на впечатление.** Обе оси выводятся из корпуса оценки
+— пяти источников выше, — и **каждая цифра в обосновании привязана к источнику
+поимённо**: «размер средний: `tasks.md` даёт шесть шагов в двух узлах». Фраза
+«изменение выглядит средним» обоснованием не является. Проектные уточнения — в `docs/review.md`,
+подраздел «Триггеры метки», **тремя списками**: «крупное здесь» и «незнакомое
+здесь» поднимают метку по своей оси, «мелкое здесь» опускает до `small`. Третий
+список один на обе оси: вниз метку опускает только совпадение обеих сразу.
+Читай все три — список, который ты не прочёл, это настройка проекта, не
+сработавшая молча.
+
+**Диффа у тебя нет — кода ещё нет.** Не пытайся его считать и не жди его.
+
+**Отрицательный тест `small`:** что после мерджа не откатывается обратной правкой
+— миграция схемы и данных, формат на диске, публичный контракт, имя, которое
+разойдётся, — не `small`, каким бы малым ни было изменение. Тест жёсткий, и вот
+почему: на `small` приёмник тем не запускается, а вопросы «обратима ли миграция»
+и «что с записями новой версии после отката» задаёт именно он. С этой меткой их
+не задаст никто.
+
+**Спорный случай решается вниз.** Между `medium` и `large` бери `medium`,
+между `small` и `medium` бери `medium`. Ожидаемая доля `large` — 5–10% задач;
+если ты выбираешь его чаще, ты выбираешь по ощущению важности, а не по факту.
+
+**Размер, сложность и метка объявляются с обоснованием, и обоснование
+обязательно всегда** — не только когда ты отступаешь от умолчания. По строке на
+ось: какой факт дал этот ответ. Поднять и понизить ты вправе одинаково; молча —
+ни то ни другое.
+
+**Метка, названная тобой, действует до конца задачи и после кода не
+пересматривается.** Второй раз тебя не позовут — кроме случая, когда правка после
+ревью дизайна изменила сами дельта-спеки: план выведен из них, и план по
+отменённым требованиям назовёт не те темы.
+
+## Правило 5 — раздача тем на обеих стадиях
+
+**Ревью дизайна — состав по метке, тем не раздаётся.** До кода закрывать темы
+нечем: проверяется предложение, а не изменение.
+
+| Метка | Проходы на предложении |
+|---|---|
+| `small` | `specs` |
+| `medium` | `specs`, `rubric` |
+| `large` | `specs`, `rubric`, `architecture` + вопрос автору о трёх формах решения |
+
+**Ревью кода — раздача тем.** Кто закрывает тему, зависит от метки. Раскладка
+жёсткая, выдумывать её не надо:
+
+| Тема | `small` | `medium` | `large` |
+|---|---|---|---|
+| `requirements` | `specs`, сверка | `specs`, разбор | `specs`, разбор |
+| `autotests` | `autotests` | `autotests` | `autotests` |
+| `conventions` | `code`, сверка | `code`, разбор | `code`, разбор |
+| `architecture` | `code`, сверка по инвариантам | `basics`, разбор | `architecture`, доказательство |
+| `security` | `code`, сверка по инвариантам | `basics`, разбор | `adversary`, доказательство |
+| `operations` | `code`, сверка по инвариантам | `basics`, разбор | `ops`, доказательство |
+| тема проекта | `basics`, сверка | `basics`, разбор | `basics`, разбор |
+
+Две глубины, которые ты назначаешь:
+
+- **сверка** — открыть дом, открыть дифф, сравнить. Один-два вопроса на тему,
+  ответ «неприменимо» дешёвый;
+- **разбор** — построить сценарий рассуждением, ничего не запуская. Два-три
+  вопроса на тему.
+
+Третья глубина, **доказательство** (прогнать, померить, построить путь), тобою
+не назначается: она есть только в `large` и принадлежит именным проходам. В
+таблице она стоит **справочно**, чтобы состав читался целиком; в своём плане ты
+против этих трёх тем пишешь `доказательство` без выбора.
+
+**На `small` у трёх тем ядра дом другой, а не глубина меньше.** `security`,
+`operations` и `architecture` смотрятся против **инвариантов `CLAUDE.md`**, а не
+против своих домов, и закрывает их `code` с потолком 1 находка на все три. Так и
+пиши в плане: дом — `CLAUDE.md`, инварианты. Приписывать им дом
+`docs/security.md` было бы враньём — по этому адресу на `small` никто не пойдёт.
+
+**`basics` запускается тогда и только тогда, когда ему есть что принимать.**
+
+- на `medium` — всегда: три темы ядра плюс свои темы проекта;
+- на `small` и в `large` — только при своих темах проекта.
+
+Нет своих тем — в плане строка, и она разная: в `large` «`basics` не запускается:
+все темы разобраны именными проходами», на `small` «`basics` не запускается: темы
+ядра закрыты сверкой по инвариантам внутри `code`». Молчащего пропуска здесь быть
+не может.
+
+**Тема без дома исполнителя не теряет.** Нет `docs/security.md` — тема `security`
+всё равно идёт строкой, с пометкой «дома нет», и её всё равно кто-то закрывает:
+вопросы задаются по коду, ответы формулируются условиями. Падает **глубина**, и
+только она. Строки с исполнителем «никто» в твоём плане быть не может ни при
+каких обстоятельствах: тема без исполнителя — это и есть молчащий пропуск.
+
+## Формат вывода
+
+Строго этот, он уезжает в отчёт целиком и служит границами покрытия:
+
+```
+размер:    среднее — tasks.md: 6 шагов в двух узлах; дельты трогают 2 capability;
+           «Затрагивает» называет 3 узла (взято большее — tasks.md)
+сложность: знакомое — «Затрагивает» называет узлы поимённо до начала работы;
+           design.md разбирает одну форму решения, альтернатив не рассматривал
+метка:     medium — максимум по осям; ни одна не дала large
+
+корпус:    запись задачи, proposal.md, design.md, tasks.md, дельта-спеки — все пять
+
+ревью дизайна: specs, rubric
+
+ревью кода, темы:
+тема            дом                                  глубина  закрывает
+requirements    openspec/changes/<id>/specs/         разбор   specs
+autotests       CLAUDE.md, семантика гейта           —        autotests
+conventions     docs/conventions/                    разбор   code
+architecture    docs/architecture.md                 разбор   basics
+                + источник docs/passport.md
+security        docs/security.md                     разбор   basics
+operations      docs/architecture.md, «Эксплуатация» разбор   basics
+                дома нет: docs/database.md отсутствует
+
+процессные: docs/tasks/, docs/review.md, docs/adr/, docs/research/
+директивы:  CLAUDE.md найден, AGENTS.md отсутствует
+```
+
+Обрати внимание на две строки этого образца, потому что обе раньше писались
+неверно. `docs/passport.md` **не** заводит своей строки и **не** пропадает — он
+стоит источником внутри темы `architecture`. Отсутствие `docs/database.md` **не**
+порождает псевдотемы с исполнителем «никто» — оно понижает глубину темы
+`operations`, и та остаётся за своим исполнителем.
+
+Дальше — блок вопросов по темам из `docs/review.md`, **дословно**, с указанием,
+кому какой уходит. Вопрос, адресованный не теме (`passport`, `database`, `adr`,
+`research`, `review`), не раздавай: таких тем нет. Скажи об этом строкой — это
+находка о настройке проекта, и чинится она правкой `docs/review.md`.
+
+И обязательная строка:
+
+```
+## Coverage of this pass
+- документов в docs/ найдено N, все N разнесены: тем M, источников K, процессных L
+- корпус оценки: какие из пяти источников прочитаны, какие отсутствуют и что это дало осям
+- расхождение источников по размеру: <какие цифры и какая взята, или «нет»>
+- тем без дома: <перечень или «нет»>
+- вопросов по темам роздано: <число>; адресованных не теме: <перечень или «нет»>
+- чего не смотрел: содержимого документов — по построению; кода и диффа — их ещё нет
+```
+
+**Строка про корпус обязательна и тогда, когда прочитаны все пять.** Отсутствие
+источника меняет обе оси, и молчащий пропуск здесь дороже прочих: он двигает не
+одну тему, а состав обоих прогонов сразу.
+
+## Чего ты не делаешь
+
+- **не судишь код** — ни одной находки по существу изменения;
+- **не пересказываешь документы** (правило 3);
+- **не выдумываешь тем** — тема приходит из своего документа проекта или из
+  директивы, а не из представления о том, что стоило бы проверить, и **не из
+  документа категорий `источник` и `процессный`**;
+- **не оставляешь тему без исполнителя** — строки «закрывает: никто» не бывает;
+- **не решаешь за человека о понижении**: понизить метку ты вправе, но
+  обоснование идёт в отчёт и читается человеком.
+
+## Ограничения
+
+Только чтение. `Bash` — для `ls` и `grep` по заголовкам. Ничего не запускай,
+ничего не редактируй. `git diff` тебе не нужен: на момент твоего запуска кода
+ещё нет.

av-dev-pipeline/agents/review-specs.md

@@ -23,10 +23,30 @@ Development на OpenSpec). Оптика — требования, а не ст
 - **`docs/architecture.md`** — компоненты и capability, и **что из них уже
   переехало в нормативные спеки**. Без этого непереехавшая тема читается как
   пробел в спеке, и находка уходит в пустоту.
-- **`docs/research/`** — как внешний мир ведёт себя на самом деле.
 - **`docs/passport.md`** — граница домена: требование, переносящее понятие через
   неё, — находка в спеку, а не в код.
 
+**`docs/research/` ты больше не читаешь.** Он процессный документ, и прогон ревью
+его не открывает — ни один проход. Проверка «требование против записанного
+наблюдения» из конвейера ушла: наблюдение неизвестной свежести делало находку
+похожей на доказанную, ничего не доказывая. Скажи об этом строкой в границах
+покрытия.
+
+**Сколько ты читаешь, зависит от метки — она приходит в задании.**
+
+| | `small` | `medium` и `large` |
+|---|---|---|
+| источник требований | **только дельта-спека change** | дельта + затронутые актуальные спеки |
+| `design.md`, `tasks.md` change | не читаешь | читаешь |
+| `docs/architecture.md`, `passport.md` | не читаешь | читаешь |
+| `CLAUDE.md`, инварианты | читаешь всегда | читаешь всегда |
+| потолок находок | **3** | нет |
+
+На `small` это значит: сверка идёт против того, что заказано **этим изменением**,
+и только. Что в актуальных спеках уже было и как это соотносится с обзором
+архитектуры — не твой вопрос с этой меткой, и так и скажи в границах покрытия.
+Потолок, если сработал, объяви: сколько осталось за срезом.
+
 Пути спек жёсткие: актуальные — `openspec/specs/<capability>/spec.md`, дельты —
 `openspec/changes/<id>/specs/`. Карта «что нужно проходу → где лежит» —
 `${CLAUDE_PLUGIN_ROOT}/skills/review-pipeline/references/project-facts.md`.
@@ -49,12 +69,10 @@ Development на OpenSpec). Оптика — требования, а не ст
 каждой слитой задачи. Задание обязано назвать этот режим явно; не названо —
 работаешь по режиму 1 или 2 и говоришь в границах покрытия, что change не нашёл.
 
-Дополнительно поднимаешь: `design.md` и `tasks.md` change, затронутые актуальные
-спеки, инварианты из `CLAUDE.md`. Если тема ещё не перенесена в спеки и живёт
-только в `docs/architecture.md` — источник истины там, и это фиксируется в
-границах покрытия. Отдельно: `docs/research/` нормой не является, но именно там
-записано, как внешний мир ведёт себя на самом деле; требование, противоречащее
-наблюдению, — повод для находки в спеку.
+Дополнительно поднимаешь **с метки `medium`**: `design.md` и `tasks.md`
+change, затронутые актуальные спеки. Инварианты из `CLAUDE.md` — при любой метке. Если тема ещё не перенесена в спеки и живёт только в
+`docs/architecture.md` — источник истины там, и это фиксируется в границах
+покрытия.
 
 ## Режим 1 — дизайн/спеки ДО кода
 
@@ -168,8 +186,11 @@ Development на OpenSpec). Оптика — требования, а не ст
 
 ```
 ## Coverage of this pass
+- метка: <small | medium | large>; с меткой small — «источник только дельта-спека, актуальные спеки и обзор не читались»
 - проверено: <какие Requirements, какие файлы диффа прочитаны>
+- потолок (только small): N/3 — и что осталось за срезом
 - не проверялось и почему: ...
+- требование против записанного наблюдения не проверялось: docs/research/ — процессный документ, прогон его не открывает
 - принципиально недоступно этому проходу: форма решения, идиоматичность, эксплуатация
 ```
 

av-dev-pipeline/agents/review-triage.md

@@ -1,9 +1,9 @@
 ---
 name: review-triage
-description: "Обязательный финальный проход конвейера ревью — единственный, кто агрегирует. Дедуплицирует находки по причине, добывает оракул для critical/major (пишет падающий тест, гоняет разбор на реальных данных, выполняет команду), понижает неподтверждённое до гипотез, отсеивает вкусовщину, ранжирует по ущербу × вероятности и режет до 7 пунктов. Помечает каждую находку «инлайн» или «развилка» для оркестратора. Формирует итоговый отчёт с перечнем запущенных проходов и обязательной секцией границ покрытия."
+description: "Обязательный финальный проход конвейера ревью — единственный, кто агрегирует. Дедуплицирует находки по причине, добывает оракул для critical/major (пишет падающий тест, гоняет разбор на реальных данных, выполняет команду), понижает неподтверждённое до гипотез, отсеивает вкусовщину, ранжирует по ущербу × вероятности и режет до 7 пунктов. Помечает каждую находку «инлайн» или «развилка» для оркестратора. Сверяет план разметки задачи с пришедшими отчётами: тема, размеченная и оставшаяся без отчёта, — находка о самом прогоне. Формирует итоговый отчёт с планом, перечнем проходов и обязательной секцией границ покрытия."
 tools: Read, Grep, Glob, Bash, Write
-model: fable
-color: red
+model: opus
+color: yellow
 ---
 
 Ты — триаж конвейера ревью. Единственный проход, который видит выводы всех
@@ -21,21 +21,32 @@ color: red
 
 ## Вход
 
-Сырые выводы всех запущенных проходов, `git diff <база>..HEAD`, **список
-запущенных проходов**, профиль и режим прогона. Дельта-спеки — по мере
-надобности.
+Сырые выводы всех запущенных проходов, `git diff <база>..HEAD`, **план разметки
+задачи** (агент `review-scope`, один запуск после `propose`) и режим прогона.
+Дельта-спеки — по мере надобности.
+
+План — это таблица «тема → дом → глубина → кто закрывает» плюс размер, сложность
+и метка с обоснованием. Он твой главный инструмент сверки: ты единственный, кто
+видит и то, что размечено, и то, что пришло.
+
+**Плана нет — ты не запускаешься.** Сверка размеченного с пришедшим — твоя
+единственная защита от молчащего пропуска, и без плана она не выполняется вовсе.
+Отчёт, собранный без неё, выглядит полным ровно настолько же, насколько и
+неполный. Исключение одно и объявленное: финальная сверка стыка в
+`av-dev-pipeline:task-batch` — там разметчика нет по построению, и план тебе
+собирает сам батч, коротким списком запущенного.
 
 Из документов проекта тебе нужны:
 
 - **`CLAUDE.md`, инварианты** — что делает находку `critical` и что делает её
   развилкой; там же, **что необратимо** (от этого зависит ранжирование) и что
   запускать запрещено;
-- **`docs/review.md`, журнал** — готовые оракулы: находка того же класса, что уже
+- **`docs/review.*`, журнал** — готовые оракулы: находка того же класса, что уже
   воспроизводился здесь, подтверждается ссылкой на запись;
-- **`docs/review.md`, «Типовые ложноположительные»** — единственный проектный
+- **`docs/review.*`, «Типовые ложноположительные»** — единственный проектный
   вход в шаг 4;
-- **`docs/review.md`, «Недоступно проверке»** — оба подраздела, они целиком
-  уезжают в границы покрытия и **не сливаются в один список**.
+- **`docs/review.*`, «Недоступно проверке»** — оба подраздела, они по темам,
+  целиком уезжают в границы покрытия и **не сливаются в один список**.
 
 Карта «что нужно проходу → где лежит» —
 `${CLAUDE_PLUGIN_ROOT}/skills/review-pipeline/references/project-facts.md`.
@@ -74,8 +85,10 @@ color: red
 - выполнить команду и приложить вывод;
 - показать поимённое положение руководства, строку конвенции проекта или **дословный
   пункт из раздела инвариантов `CLAUDE.md`**;
-- сослаться на наблюдение в `docs/research/` — оно сильнее любого
-  рассуждения о том, «как должно быть».
+- сослаться на замер, снятый проходом **на этом прогоне**, с приложенной
+  командой — он сильнее любого рассуждения о том, «как должно быть». На чужие
+  записанные наблюдения не ссылайся: `docs/research/` — процессный документ,
+  прогон его не открывает, и свежесть числа оттуда ничем не подтверждена.
 
 Бюджет — по одной попытке на находку. Не превращай триаж в отдельное
 расследование. Ничего не запускай на рабочих данных — запреты в `CLAUDE.md`.
@@ -142,25 +155,39 @@ severity:
 Сомневаешься — ставь `развилка`. Ошибка в сторону лишнего вопроса дешевле
 незаказанной переработки.
 
-## Перечень проходов — обязателен и поимённый
+## Сверка плана с исходом — обязательна
 
-Сводка отчёта называет **каждый проход профиля** и его исход: отработал (сколько
-находок) / не запускался (почему). Сверь список запущенного с составом профиля
-сам, а не доверяй тому, что тебе подали: пропуск прохода **не отличим от прохода
+Сводка отчёта воспроизводит **план целиком** и против каждой темы ставит исход:
+закрыта таким-то проходом (сколько находок) / отчёта не пришло / дома у темы нет.
+Сверяй сам, а не доверяй тому, что тебе подали: пропуск **не отличим от прохода
 без находок**, и назвать его больше некому.
 
-Расхождение состава с профилем — это находка о прогоне, и она идёт в сводку
-первой строкой, а не растворяется в границах покрытия.
+**Тема без отчёта — находка о прогоне**, и она идёт в сводку первой строкой, а не
+растворяется в границах покрытия. Это то, чего прежний перечень проходов не
+показывал вовсе: список запущенного отвечал «все, кто должен был, отработали», а
+вопрос «что именно осталось непроверенным» задать было нечем.
+
+Отдельно проверь **сигнал о заниженной метке** — его подаёт `review-code` при
+любой метке и `review-basics`, когда запускается. Пришёл хоть от одного — веди
+его в сводку отдельной строкой, а не в общий список находок: метку выбирал
+`review-scope`, а не они и не ты, значит сигнал независим. Пришли оба — это одна
+строка с двумя провенансами, а не два пункта: согласие проходов приоритет
+повышает, `confidence` нет.
+
+**Сигнала нет — тоже скажи строкой.** «Корректор метки отработал, возражений
+нет» и «корректор не запускался» — разные вещи, и отличить их по молчанию
+нельзя.
 
 ## Границы покрытия — не сокращаются
 
 Финальная секция сводит границы всех проходов. Обязательно называет:
 
-- какие проходы запускались, в каком профиле и режиме;
-- какие **не** запускались и почему (профиль, бюджет, недоступный инструмент,
+- **план: темы, их глубины и дома** — включая темы, у которых дома нет;
+- какие проходы запускались, на какой метке и в каком режиме;
+- какие **не** запускались и почему (метка, бюджет, недоступный инструмент,
   остановленный прогон);
 - что каждый запущенный проход **не мог проверить в принципе** — из его charter'а;
-- **что осталось целиком на человеке** — «Недоступно проверке» из `docs/review.md`,
+- **что осталось целиком на человеке** — «Недоступно проверке» из `docs/review.*`,
   **двумя отдельными списками**: «не проверит ни один проход» и «перестали
   проверять сознательно». Слитый список бесполезен: при следующем промахе первый
   вопрос — «не тот ли это класс, который мы перестали проверять», и ответить на
@@ -171,7 +198,32 @@ severity:
 - **каких документов проекта не хватило** — строкой на каждый, **с причиной**:
   «`docs/security.md` в проекте нет», «есть, но периметр не назван». Строки
   приходят из проходов; слить их в одну «документации не было» нельзя —
-  деградация поразрядная, и разные пробелы чинятся разным.
+  деградация поразрядная, и разные пробелы чинятся разным;
+- **сработавшие потолки** — по строке на проход: сколько находок он показал,
+  каков был его потолок и что осталось за срезом. Проход обязан сообщить это сам;
+  не сообщил — так и напиши, это находка о прогоне.
+
+**Четыре строки ты пишешь сам, на каждом прогоне, и ни один проход их не
+принесёт.** Они про то, чего в конвейере нет вовсе, — а значит некому и
+пожаловаться:
+
+1. **Решения проекта не сверялись.** `docs/adr.*` — процессный документ, прогон
+   его не открывает. Расхождение изменения с записанным решением ловит сверка
+   документации между спринтами, а не ревью.
+2. **Записанные наблюдения проекта не использовались.** `docs/research.*` — тоже
+   процессный. Всякое число в находках снято проходом на этом прогоне; числа без
+   приложенной команды замера в отчёте быть не должно.
+3. **Поимённая сверка с руководствами по стилю языка не задавалась ни одним
+   проходом.** Различение «идиоматично против распространено» не спрашивает никто
+   с тех пор, как упразднён проход про идиоматичность.
+4. **Альтернативной реализации, с которой можно сдиффить решения, у конвейера
+   нет.** Проход независимой реализации снят по стоимости, а не по замеру; «не
+   знаю, чего не знаю» больше не достаёт никто.
+
+Плюс **с меткой `small`** — пятая строка: темы `security`, `operations` и
+`architecture` сверялись только с записанными инвариантами `CLAUDE.md`, дома этих
+тем не открывались. Свойство, которого нет в инвариантах, с этой меткой не
+проверил никто.
 
 Формулировка «критичных проблем не обнаружено» **запрещена** без этой секции: она
 потребляет ощущение проверенности, ничего не гарантируя, и это хуже, чем
@@ -188,8 +240,9 @@ severity:
 Строго секциями из контракта: `Блокирует мердж` (≤3) / `Стоит исправить сейчас`
 (≤4) / `Гипотезы без доказательства` / `Promote candidates` / `Границы покрытия`.
 
-Перед секциями — сводка: профиль и режим прогона, состояние гейта, **перечень
-проходов поимённо с исходом**, сколько находок пришло на вход и сколько осталось.
+Перед секциями — сводка: размер, сложность и метка с обоснованием разметки и режим прогона,
+состояние гейта, **план с исходом по каждой теме**, сколько находок пришло на
+вход и сколько осталось.
 
 ## Ограничения
 

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

@@ -27,7 +27,7 @@
 
 ```mermaid
 stateDiagram-v2
-    state "проход в профиле" as live
+    state "проход в составе метки" as live
     state "retune №1 — правка charter'а" as r1
     state "retune №2 — последняя попытка" as r2
     state "проход удалён" as dead
@@ -79,11 +79,14 @@ stateDiagram-v2
 
 | Проход | Класс дефекта для инъекции | Заготовка пробы |
 |---|---|---|
-| `review-gate` | отсутствующая верификация | убрать тест на изменённую ветку, оставить код рабочим |
+| `review-scope` | пропущенная тема | положить в `docs/` новый документ и проверить, попал ли он в план темой |
+| `review-autotests` | отсутствующая верификация | убрать тест на изменённую ветку, оставить код рабочим |
 | `review-specs` | поведение вне спеки | добавить незаказанный фолбэк-дефолт на пустом входе |
 | `review-code` | нарушение прозаической конвенции | увести штатный отказ мимо единой точки трансляции ошибки |
+| `review-code` | технический дефект | не проверить возвращённую ошибку в ветке раннего возврата |
 | `review-rubric` | нарушенное свойство узла | у клиента внешнего сервиса убрать таймаут и протяжку `context` |
-| `review-reimpl` | форма решения | размазать решение по трём слоям там, где хватало одной функции |
+| `review-basics` | отказ, видимый чтением | убрать обработку ошибки записи так, чтобы отказ считался успехом |
+| `review-basics` | своя тема проекта | нарушить правило из документа, у которого нет именного прохода |
 | `review-architecture` | второй способ | завести вторую точку генерации id мимо единой |
 | `review-adversary` | построенный путь | принять внешний идентификатор без разбора до запроса в хранилище |
 | `review-ops` | деградация окружения | убрать обработку недоступности внешней зависимости в фоновом цикле |
@@ -98,7 +101,7 @@ stateDiagram-v2
 
 ## Когда калибровать
 
-- при заведении нового прохода — **до** включения в профиль по умолчанию;
+- при заведении нового прохода — **до** включения в состав метки по умолчанию;
 - при правке charter'а существующего — иначе непонятно, правка помогла или нет;
 - при появлении записи в журнале проскочивших дефектов — калибруем тот проход,
   который должен был поймать;

av-dev-pipeline/skills/review-pipeline/references/finding-contract.md

@@ -13,7 +13,7 @@
 - Оракул: <падающий тест / команда с выводом / положение руководства / нет>
 - Последствие: <что произойдёт и при каких условиях>
 - Предложение: <конкретное изменение>
-- Найдено проходом: <имя агента>
+- Найдено проходом: <имя агента; у проходов с раздельными потолками — имя и половина, например `code/техника`>
 ```
 
 ## Правила
@@ -38,8 +38,8 @@
 - **`critical` по основанию «нарушен инвариант проекта» требует инвариантов.**
   Ссылка идёт на пункт раздела инвариантов `CLAUDE.md` дословно. Без них основание
   недоступно — см. [project-facts.md](project-facts.md), поразрядная деградация.
-- **Расхождение — не дефект, пока не названо последствие.** Особенно для прохода
-  независимой реализации: «я бы сделал иначе» без последствия не выводится.
+- **Расхождение — не дефект, пока не названо последствие.** Особенно для
+  архитектурного прохода: «я бы сделал иначе» без последствия не выводится.
 
 ## Шкала severity
 
@@ -76,10 +76,16 @@
 4. `Promote candidates` — кандидаты в конвенцию или правило линтера;
 5. `Границы покрытия` — сводная, обязательная.
 
-Перед секциями — сводка для человека: профиль и режим прогона, состояние гейта,
-**перечень запущенных проходов поимённо с исходом каждого**, сколько находок
-пришло на вход и сколько осталось. Перечень обязателен: пропуск прохода не
-отличим от прохода без находок, и назвать его больше некому.
+Перед секциями — сводка для человека: размер, сложность, метка и режим
+прогона, состояние гейта, **план разметки задачи с исходом по каждой теме**,
+сколько находок пришло на вход и сколько осталось.
+
+**Реестр сводки — темы, а не проходы, и это не оформление.** Перечень запущенных
+проходов отвечает «все, кто должен был, отработали» и молчит о том, что именно
+осталось непроверенным: уехавший в старшую метку проход уносит тему с собой
+беззвучно. План же называет тему, её дом, глубину и исполнителя — и тема,
+оставшаяся без отчёта, видна сразу. Перечень проходов из сводки не исчезает, но
+идёт **внутри** плана, колонкой «кто закрывает».
 
 Каждая находка в секциях 1–2 несёт дополнительное поле:
 

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

@@ -9,26 +9,50 @@
 второй дом для тех же фактов разошёлся бы и выглядел актуальным.
 
 Определение канона — в плагине `av-dev-pm`,
-`skills/canon/references/canon.md`. Здесь только карта «что нужно проходу →
-где это лежит».
+`skills/canon/references/canon.md`. Здесь только карта «тема → её дом → что
+оттуда берётся».
 
-## Карта
+## Карта тем
+
+**Дом бывает файлом или каталогом** — `docs/security.md` и `docs/security/`
+называют одну и ту же тему. Форму дома называет план разметки задачи; проход её не
+угадывает.
+
+| Тема | Дом | Что оттуда берётся |
+| --- | --- | --- |
+| `requirements` | `openspec/specs/`, `openspec/changes/<id>/specs/` | нормативное поведение и дельты изменения |
+| `autotests` | `CLAUDE.md`, семантика гейта | команда гейта, чем краснеет безусловно, чего в нём нет, кто гоняет дорогое |
+| `conventions` | `docs/conventions.*` | конвенции прозой и **что уже механизировано** правилом |
+| `architecture` | `docs/architecture.*` | компоненты и capability, единые точки проекта |
+| | источник `docs/passport.*` | что система делает и **чего не делает**, граница домена |
+| `security` | `docs/security.*` | периметр, недоверенный вход, из чего строятся пути и ключи, что вне модели |
+| `operations` | `docs/architecture.*`, раздел эксплуатации | окружение, внешние зависимости поимённо, наблюдатель, характер потока |
+| | источник `docs/database.*` | чем физически лежит запись, что при чтении и записи, настройки с числовым значением |
+| *тема проекта* | её **свой** документ в `docs/` | то, что проект счёл нужным записать |
+
+**`docs/adr.*` и `docs/research.*` в этой карте нет намеренно.** Они процессные
+документы: прогон ревью их не открывает. Раньше первый питал тему `architecture`,
+второй — `operations` и `requirements`; обе строки убраны, и цена этого названа в
+`SKILL.md`, раздел «Честный предел».
+
+**Дом темы зависит ещё и от метки.** На `small` темы `security`, `operations` и
+`architecture` смотрятся не против домов из этой таблицы, а против **инвариантов
+`CLAUDE.md`**, и закрывает их `code`. Таблица описывает полный дом темы; сколько
+из него открыто на этом прогоне, говорит план разметки задачи.
+
+Сквозное, не привязанное к теме:
 
 | Что нужно проходу | Где лежит |
 | --- | --- |
-| что система делает и **чего не делает**, граница домена | `docs/passport.md` |
-| инварианты **с severity рядом с формулировкой** | `CLAUDE.md`, раздел инвариантов |
-| команда гейта, чем краснеет безусловно, чего в нём нет, кто гоняет дорогое | `CLAUDE.md`, семантика гейта |
+| инварианты **с severity рядом с формулировкой** | `CLAUDE.md` (и `AGENTS.md`, если он рядом), раздел инвариантов |
 | что запускать запрещено, с путями; `testdata`; куда писать временное; имя основной ветки | `CLAUDE.md` |
-| компоненты и capability, окружение, внешние зависимости поимённо, наблюдатель, характер потока, единые точки проекта | `docs/architecture.md` |
-| чем физически лежит запись, что при чтении и записи, настройки с числовым значением | `docs/database.md` |
-| периметр, недоверенный вход, из чего строятся пути и ключи, что вне модели | `docs/security.md` |
-| измеренные числа **с провенансом**, поведение внешних систем на самом деле | `docs/research/` |
-| конвенции прозой и **что уже механизировано** правилом | `docs/conventions/` |
-| почему решено так, отвергнутые варианты | `docs/adr/` |
-| типовые узлы, типовые ложноположительные, вопросы к проходам, **триггеры профиля**, недоступно проверке | `docs/review.md`, раздел настройки |
-| прецеденты: воспроизведённые дефекты с оракулом | `docs/review.md`, журнал |
-| нормативное поведение и дельты изменения | `openspec/specs/`, `openspec/changes/<id>/specs/` |
+| типовые узлы, типовые ложноположительные, **вопросы по темам**, триггеры метки, недоступно проверке | `docs/review.*`, раздел настройки |
+| прецеденты: воспроизведённые дефекты с оракулом | `docs/review.*`, журнал |
+
+**Вопросы проекта привязаны к теме, а не к имени прохода.** Раньше блок в
+`docs/review.md` адресовался поимённо (`ops: <вопрос>`), и когда проход уехал в
+старшую метку, вопрос перестал задаваться молча. Тема переезд прохода
+переживает.
 
 ## Сшивать обязаны проходы
 
@@ -41,12 +65,27 @@
 - **замер + настройка.** «Пик 768 МиБ» — аномалия только рядом со строкой
   «запись лежит сжатой и распаковывается целиком»; «блокировка удерживалась
   5.019 с» — гарантированный отказ соседа только рядом с известным таймаутом
-  занятости. Числа в `docs/research/`, настройки в `docs/database.md`, и оба
-  читает `ops`, `adversary`, `reimpl`.
+  занятости. **Число проход снимает сам, на этом прогоне**, настройки берёт из
+  `docs/database.md`, и сшивают их `ops` и `adversary`. Раньше числа брались из
+  `docs/research/`; теперь этот документ процессный, и замер неизвестной свежести
+  больше не выдаёт себя за оракул.
 - **инвариант + обратимость.** severity берётся из `CLAUDE.md`; если её там
   нет — она **выводится по обратимости последствия** и помечается «выведена по
   обратимости», а не выдаётся за решение проекта.
 
+**У `basics` стыков нет, и это не упущение.** Он не меряет, поэтому сшивать число
+с настройкой ему нечего; единственное его основание для `critical` — инвариант из
+`CLAUDE.md`, всё остальное он формулирует условиями и оставляет гипотезой. Его
+вход намеренно узкий: дома тем из плана плюс инварианты и журнал. Широкий вход —
+это метка `large`, и там он есть у `architecture`. Греп по базе ему разрешён
+точечный — «есть ли второй вызывающий», — но обход всей базы и инвентарь
+концепций не его работа.
+
+**У `scope` стыков нет по другой причине: он не читает содержимого.** Его дело —
+найти дома и раздать темы, а не пересказать написанное. Пересказ сделал бы его
+посредником между документом и проходом, а посредник расходится с источником и при
+этом выглядит актуальным.
+
 ## Деградация — поразрядная
 
 Документа нет — деградирует то, что из него читалось, и **только оно**. Каждый
@@ -54,20 +93,26 @@
 список и **не сливает в одну строку**: разные пробелы чинятся разным — периметр
 пишется руками за десять минут, а числа требуют замера.
 
-**Кто какой документ читает — не здесь.** Полный список читателей ведёт канон
-(`Skill av-dev-pm:canon`, его `references/canon.md`, таблица «Кто читает»); ниже —
-только **последствие** отсутствия, и оно называет самое дорогое, а не всех
-пострадавших. Два списка читателей уже однажды разошлись; второго раза не надо.
+**Кто какой документ читает — из документа не выводится, а назначается планом.**
+Документ питает тему (это записано на стороне канона, таблица «Роли документов и
+темы ревью»), а тему на этом прогоне закрывает тот, кого назвала разметка задачи; вся
+раскладка «тема → проход → глубина» — в `SKILL.md` этого скилла и больше нигде.
+**Списка читателей не ведёт никто, и это не пробел.** Он жил бы на стороне
+канона, а документ живёт дольше, чем раскладка проходов: список разошёлся бы с
+конвейером молча и при этом выглядел актуальным. Однажды уже разошёлся.
 
-| Нет документа | Что деградирует |
+Ниже — только **последствие** отсутствия дома, и оно называет самое дорогое, а не
+всех пострадавших.
+
+| Нет дома | Что деградирует |
 | --- | --- |
 | `CLAUDE.md` без инвариантов | `critical` по основанию «нарушен инвариант проекта» не присваивается никем |
-| `docs/security.md` | `adversary` не знает периметра — формулирует условиями, `critical` не ставит |
-| `docs/research/` | числа неизвестны `specs`, `ops`, `adversary`, `reimpl` — формулируют условиями, а `specs` теряет проверку «требование против наблюдения» |
-| `docs/database.md` | замер не с чем сравнить: находка не поднимается выше гипотезы |
-| `docs/passport.md` | `architecture` теряет границу домена и вырождается в общее мнение |
-| `docs/review.md` | `triage` отсеивает вслепую: типовых ложноположительных нет |
-| `docs/architecture.md` | «не появился ли второй способ» не проверяется — единых точек не знает никто |
+| `docs/security.*` | тема `security` остаётся без дома: вопросы задаются по коду, `critical` не ставится, периметр неизвестен |
+| `docs/database.*` | замер не с чем сравнить: находка темы `operations` не поднимается выше гипотезы |
+| `docs/passport.*` | тема `architecture` теряет границу домена и вырождается в общее мнение |
+| `docs/review.*` | `triage` отсеивает вслепую: типовых ложноположительных нет; вопросы проекта по темам не задаются |
+| `docs/conventions.*` | вторая половина `code` идёт вхолостую: записанных конвенций нет |
+| `docs/architecture.*` | «не появился ли второй способ» не проверяется — единых точек не знает никто; тема `operations` теряет перечень внешних зависимостей |
 
 Строка в границах покрытия обязана называть **причину**: «`docs/security.md` в
 проекте нет» читается иначе, чем «есть, но периметр не назван». Без причины

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

@@ -6,7 +6,7 @@
 и один и тот же класс проскакивает второй раз.
 
 Тот же файл держит **настройку конвейера под проект** — типовые узлы, типовые
-ложноположительные, вопросы к проходам, недоступно проверке. Это не соседство по
+ложноположительные, вопросы по темам, недоступно проверке. Это не соседство по
 случаю: все четыре раздела — производные калибровки, а журнал им источник.
 
 ## Что туда попадает
@@ -29,7 +29,7 @@
 и `docs/adr/`.
 
 Отдельно сюда попадают **решения о составе прогонов**: перестали звать проход,
-понизили профиль правилом, сузили класс проверяемого. Не потому, что это промах,
+понизили метку правилом, сузили класс проверяемого. Не потому, что это промах,
 а потому, что здесь лежит цена: если что-то теперь проскочит, первый вопрос —
 «не тот ли это класс, который мы перестали проверять».
 
@@ -77,12 +77,13 @@
 Три адреса, и выбор между ними — половина ценности журнала:
 
 - **в документ проекта** — если проход не мог знать факта. Адрес зависит от рода
-  факта, и карта их всех — [project-facts.md](project-facts.md): объём и
-  измеренное число → `docs/research/`; настройка хранилища → `docs/database.md`;
+  факта, и карта их всех — [project-facts.md](project-facts.md):
+  настройка хранилища → `docs/database.md`;
   что необратимо и какой шаг гейта красит безусловно → `CLAUDE.md`; периметр и
-  недоверенный вход → `docs/security.md`. **Вопрос конкретному проходу**, если
-  промах лечится не фактом, а заданным вопросом, → раздел «Вопросы к проходам»
-  того же `docs/review.md`. Самый частый адрес и самый дешёвый. Прежде чем
+  недоверенный вход → `docs/security.*`. **Вопрос по теме**, если промах лечится
+  не фактом, а заданным вопросом, → раздел «Вопросы по темам» того же
+  `docs/review.*`; адресуй теме, а не имени прохода — проход уедет между
+  метками, тема останется. Самый частый адрес и самый дешёвый. Прежде чем
   править charter, проверь, не хватит ли факта или вопроса: charter общий для
   всех проектов, документ — про этот.
 - **в конвенции или в правило линтера** — если свойство выражается

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

@@ -0,0 +1,165 @@
+# Метки задачи — выбор, цена, доли
+
+**Дом правила выбора метки.** Состав проходов по каждой метке, схема процесса и
+раздача тем живут в [SKILL.md](../SKILL.md) — там диспетчер, и на готовой задаче
+его достаточно. Здесь то, что читают, когда метку **выбирают, оспаривают или
+калибруют**.
+
+Применяет правило `review-scope` при разметке задачи — не автор изменения. Его
+рабочая выжимка лежит в уставе агента; расходиться она с этим файлом не вправе, а
+при расхождении прав этот.
+
+## Правило выбора — две оси, а не один вопрос
+
+**Оси две, они измеряют разное, и метка есть максимум по ним.**
+
+| | **знакомое** — форму решения можно назвать до начала | **незнакомое** — форму предстоит нащупать по ходу |
+|---|---|---|
+| **малое** — один узел | `small` | `large` |
+| **среднее** — несколько узлов одного слоя | `medium` | `large` |
+| **крупное** — несколько слоёв, перенос ответственности, большой рефакторинг | `large` | `large` |
+
+**Метка — не синоним размера.** Совпадают они только в левом верхнем углу: малое
+**незнакомое** изменение получает `large`, трогая один узел. Поэтому в плане
+стоят три строки, а не одна: размер, сложность и метка — каждая со своим
+обоснованием. Проход, выведший объём диффа из метки, ошибётся ровно на этом
+случае — а он и есть самый опасный: незнакомая форма в одном узле течёт там, где
+её никто не ждёт.
+
+**Размер** — про объём: сколько мест трогается. **Сложность** — про
+неизвестность: знаем ли мы форму решения заранее. Признак незнакомого простой и
+проверяемый: **перед работой нельзя назвать, какие узлы будут тронуты**.
+
+Раньше обе оси были склеены в один вопрос «крупное **или** незнакомое?». Ответ
+получался тот же, но две вещи под одним именем не измеришь по отдельности, и
+потому разметка не могла сказать «изменение среднее, но совершенно знакомое» —
+а именно эта пара и есть рабочее умолчание. Теперь обе оси называются в плане
+поимённо, и обе — с обоснованием.
+
+**Оси называются и на стадии дизайна, и на стадии кода — но считаются один
+раз.** Это и есть причина, по которой разметка переехала к `propose`: состав
+ревью дизайна выводится из той же пары, что и состав ревью кода, а считать её
+дважды значит один раз посчитать без разведённости с автором.
+
+**Обратимость — не третья ось, а отрицательный тест.** Она не уточняет размер и
+не уточняет сложность: она запрещает нижнюю метку независимо от обеих.
+
+**Отрицательный тест `small`, и он важнее положительного:** изменение, которое
+после мерджа **не откатывается обратной правкой**, — не `small`, каким бы
+маленьким ни был дифф. Сюда попадают миграция схемы и данных, формат на диске,
+публичный контракт, имя, которое разойдётся по кодовой базе. Три строки миграции
+— это `medium`, а не `small`: размер диффа и цена ошибки здесь расходятся.
+
+Что здесь считается крупным, что — незнакомым и что — мелким, проект уточняет в
+`docs/review.md`, подразделе «Триггеры метки»: **тремя списками** — по одному на
+каждую ось вверх и один вниз, поимённо, узлами или capability. Это **уточнение**,
+а не отмена: не записано — работает таблица выше.
+
+## Спорный случай решается вниз, и у этого есть цена
+
+Правило асимметрично, потому что асимметрична цена ошибки.
+
+- **Спорно между `medium` и `large` → бери `medium`.** Ошибка в эту сторону
+  стоит находки, которая всплывёт на следующей задаче или в журнале дефектов.
+  Ошибка в обратную стоит трёх тяжёлых проходов, двое из которых держат машину и
+  идут цепочкой, — и платится она **на каждой** задаче, выбранной неверно.
+- **Спорно между `small` и `medium` → бери `medium`.** Раньше эта строка
+  обосновывалась тем, что состав одинаков и ошибка почти бесплатна. Теперь состав
+  разный, и обоснование стало прямо противоположным: на `small` три темы ядра
+  смотрятся **только против записанных инвариантов**, а спорный случай — ровно тот,
+  где неизвестно, покрыт ли он инвариантом. Сомнение здесь стоит дороже, чем
+  раньше, и потому решается вниз тем более твёрдо.
+
+**Выбор сделан в пользу пропускной способности, и это записано, а не подразумевается.**
+Конвейер настроен на поток задач, а не на максимум находок с каждой: поправить в
+следующей задаче дешевле, чем держать одну два часа. Отсюда три обязанности,
+без которых сделка превращается в незаметную потерю качества:
+
+- **границы покрытия называют темы и их глубину**, а не только запущенные
+  проходы — иначе `small` выглядит так же, как `large` без находок;
+- **журнал дефектов в `docs/review.md` перестаёт быть хорошей практикой и
+  становится единственной обратной связью**: проскочивший дефект — единственный
+  сигнал, что метка выбрана слишком низко;
+- **возврат в код — повод пересмотреть метку.** Задача, которая приходит в тот
+  же узел третий раз, уже не мелкая, чем бы ни выглядел её дифф.
+
+## Метка — максимум по поверхности
+
+**Обе оси меряются по всему диффу разом, и максимум по каждой отвечает за весь
+дифф.** Метка изменения — не средневзвешенное: одна строка в перечне границ
+задачи поднимает метку всему остальному, включая ту часть, которая сама по себе
+была бы `small`.
+
+Обратное тоже верно и тоже не бесплатно: у каждой задачи есть **несокращаемый
+костяк — гейт, спеки, код, триаж**. Разрезать задачу, обе половины которой
+остаются в одной метке, значит заплатить костяк дважды за ту же проверку.
+Резать стоит там, где разрез **снимает доказательство с большей части диффа**.
+Шов и правило нарезки живут у того, кто ведёт задачи, — скилл `av-dev-pm:tasks`,
+его `references/split.md`. Пути туда конвейер не выносит: за пределы своего
+плагина он ходит вызовом скилла, а не файлом.
+
+Разметка в костяк не входит — она платится один раз на задачу, а не один раз на
+прогон, и потому **разрез задачи её не удваивает**. Это единственное, что стало
+дешевле от переезда разметки к `propose`, и это же снимает прежний довод против
+нарезки.
+
+**Размер, сложность, метка и глубина объявляются в отчёте, и все четыре с
+обоснованием.** Метка выбирает `review-scope`; он вправе и поднять, и понизить
+её — но не молча: строка «метка X, потому что размер Y и сложность Z»
+обязательна на каждом прогоне, а не только когда метка отличается от ожидаемой.
+
+## Чем `small` дешевле `medium` и что это стоит
+
+Экономят три рычага — непуск, вход, потолок, — и они общие для всех проходов и
+всех меток; их дом и точные числа в [SKILL.md](../SKILL.md), раздел «Модель по
+проходу». Здесь только то, что рычаги делают **с этой меткой**:
+
+1. **Составом.** `basics` на `small` не запускается — кроме случая, когда у
+   проекта есть свои темы; тогда он идёт **только с ними**, ровно как в `large`.
+   Три темы ядра, которые он держал бы, переходят к `code` сверкой по
+   инвариантам.
+2. **Входом.** На `small` `specs` читает только дельта-спеку, а `code` — только
+   **индекс** конвенций (перечень родов и что механизировано), не весь их дом. На
+   `medium` оба читают дома целиком.
+3. **Потолком.** На `small` потолки самые жёсткие из трёх меток, и каждый
+   напечатан в границах покрытия своего прохода.
+
+**Что `small` за это не проверяет, названо поимённо и обязано идти строкой в
+границы покрытия:** темы `security`, `operations` и `architecture` смотрятся
+только против **записанных инвариантов** `CLAUDE.md`. Свойство, которого в
+инвариантах нет, с этой меткой не спросит никто — ни сценарием, ни чтением
+дома темы. Это и есть цена метки, и она заметно больше прежней: раньше `small`
+отличался от `medium` одним проходом на один вопрос, то есть не экономил
+ничего и назывался отдельной меткой зря.
+
+**`large` назван по тому, что он добавляет: вход шире диффа.** Он единственный, где
+живут тяжёлые проходы, и единственный, где что-то **запускается**. `basics` в нём
+берёт только проектные темы; своих тем у проекта нет — он не запускается вовсе, и
+план говорит об этом строкой. **На `small` действует то же правило и по той же
+причине** — приёмник запускается только тогда, когда ему есть что принимать.
+Совпадение неслучайное: `basics` держит темы ядра ровно при одной метке из трёх,
+а приёмником проектных тем работает на всех.
+
+## Доли — не пожелание, а проверка правила, и проверок две
+
+**Сверху: `large` — 5–10%.** Если туда уходит каждая третья задача, метку
+выбирают по ощущению важности. Обратный перекос виден по журналу проскочивших
+дефектов: класс, который ловят только меряющие проходы, начинает всплывать после
+мерджа.
+
+**Снизу: `small` не должен обгонять `medium`.** Ориентир — до трети задач, но
+сравнение важнее числа: **перевес `small` над `medium` значит, что рабочее
+умолчание сместилось, а решения об этом никто не принимал.** Проверка нужна
+именно теперь: пока две нижние метки совпадали составом, дрейф между ними не
+стоил ничего, и проверки не было. Сейчас он стоит трёх тем ядра, которые на
+`small` смотрятся только против инвариантов, — то есть ровно того, чем `small` и
+дёшев.
+
+Считается это по журналу дефектов и по отчётам, а не по ощущению: метка
+напечатана в каждом отчёте, и посчитать её за спринт — работа на минуту.
+
+**У дрейфа вниз есть свой стимул, и его стоит назвать.** `small` дешевле по
+времени и по деньгам, а выбирает метку хоть и не автор, но проход, читающий
+описание, написанное автором. Занижённое описание даёт занижённую метку без
+чьего-либо злого умысла — потому корректор и вынесен в `code`, который смотрит
+уже на код, а не на описание.

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

@@ -51,7 +51,7 @@ description: Проводит несколько задач разом — пл
 - **Батч не владеет спринтом и целями.** Он сообщает исход по каждой задаче в тех
   же трёх словах, что и `task-pipeline`: сделана / не доведена / оказалась крупнее
   задачи.
-- **Задачи закрывает пайплайн внутри каждого сабагента**, шагом 11 — после
+- **Задачи закрывает пайплайн внутри каждого сабагента**, шагом 12 — после
   коммита работы и **отдельным коммитом учёта**, вызовом Skill `av-dev-pm:tasks`.
   Батч сам записей учёта не трогает: он не знает, чем кончилась приёмка, и
   дублировать закрытие ему незачем. Но грязное дерево после сабагента — **его**
@@ -104,19 +104,22 @@ description: Проводит несколько задач разом — пл
   параллельном она гонится в волне **одна** (обоснование — ниже, в шаге 4).
   Помечается здесь, на планировании, а не во время прогона, и **независимо от
   режима**: состав волны определяется сейчас, режим может смениться просьбой уже
-  после плана, а профиль ревью сабагент выберет только внутри задачи — ключевать
-  волну на ещё не сделанный выбор нельзя. Триггеры — по фактам о задаче, каждый
+  после плана, а метка ревью назовёт разметчик уже внутри пайплайна задачи,
+  после `propose`, — ключевать волну на ещё не сделанный выбор нельзя. Триггеры — по фактам о задаче, каждый
   сам по себе достаточен:
   - трогает схему хранилища, миграцию, формат на диске или объём хранимого;
   - трогает конкурентность: транзакции, блокировки, фоновые циклы, общее
     состояние;
   - трогает размер тела, буфер, память, сжатие, ретеншен, темп потока;
-  - её тема названа в `docs/research/` или в журнале `docs/review.md` как место,
-    где уже мерили или уже ломалось.
+  - её тема названа в журнале `docs/review.md` как место, где уже ломалось.
 
   Ни один триггер не сработал — задача не замеряющая, даже если её ревью
-  окажется `deep`. Профиль про глубину проверки, замеряющая — про соревнование за
-  железо; это разные вопросы, и совпадают они не всегда;
+  окажется `large`. Метка про глубину проверки, замеряющая — про соревнование за
+  железо; это разные вопросы, и совпадают они не всегда. Обратное тоже бывает и
+  тоже законно: помеченная задача, чьё ревью пошло меткой `small` или
+  `medium`, машину не займёт вовсе — меряющие проходы живут только в `large`.
+  Пометка от этого не снимается: она ставится **до** разметки, и перестраховка
+  здесь стоит одной волны, а ошибка — испорченных чисел;
 - **нумерованные артефакты — номера раздаёт оркестратор заранее.** Если проект
   нумерует миграции (путь — `docs/.pm.json`, ключ `migrations`), посмотри последний
   номер и **раздай номера всем задачам, которые, вероятно, их добавят**, до
@@ -234,27 +237,31 @@ flowchart TD
    - прогони Skill **`av-dev-pipeline:task-pipeline`** ровно на этой задаче,
      полный цикл SDD с обоими чекпоинтами ревью;
    - если задаче назначен **номер артефакта** — используй строго его;
-   - **профиль ревью выбирается по факту изменения.** Батч не повод понижать
-     профиль: «нас много и мы спешим» — это ровно тот стимул, из-за которого
-     проходы пропускают;
+   - **метка ревью выбирает разметчик конвейера, а не ты и не сабагент.** Он
+     идёт внутри пайплайна задачи, шагом 4, сразу после `propose`, и его план
+     обслуживает оба чекпоинта. Метка в вызов не передаётся вовсе. Батч не
+     повод её понижать: «нас много и
+     мы спешим» — ровно тот стимул, из-за которого проходы пропускают, и он снят
+     тем, что регулятор не в руках у автора;
    - **режим прогона проходов ревью — от режима батча**, и его называет charter,
      а не сабагент: батч идёт по одной задаче → режим умолчательный, **`по
      графу`** (машина свободна); батч идёт волнами → **`линейно`**, твой worktree
      не один на машине, и этой причиной ты обязан объяснить режим в отчёте.
-     Внутренние рёбра графа — цепочку проходов, держащих машину, и барьер
-     стоимости — конвейер соблюдает сам, в любом режиме;
+     Внутренние рёбра графа — цепочку проходов, держащих машину — конвейер
+     соблюдает сам, в любом режиме;
    - **если вложенные сабагенты недоступны** (движок не даёт запускать агентов из
-     агента) — не пропускай ревью и не понижай профиль: проведи его **инлайн** по
-     тем же charter'ам `av-dev-pipeline`, сохранив обязательное — гейт до
-     опиниативных проходов, состав по профилю, триаж последним. И **скажи в
-     отчёте прямым текстом, что ревью шло инлайн**: инлайновый проход видит
-     контекст автора и потому разведён с ним слабее — это меняет доверие к
-     результату, а не только способ запуска;
+     агента) — не пропускай ревью и не понижай метка: проведи его **инлайн** по
+     тем же charter'ам `av-dev-pipeline`, сохранив обязательное — разметку первой
+     (план с темами и меткой), гейт до опиниативных проходов, состав по плану,
+     триаж последним. И **скажи в отчёте прямым текстом, что ревью шло инлайн**:
+     инлайновый проход видит контекст автора и потому разведён с ним слабее — а
+     инлайновая разметка вдобавок означает, что метка выбрал автор, и это
+     отдельная строка;
    - **вернуть отчёт**, в котором обязательно: исход задачи одним из трёх слов;
-     **объявленный профиль ревью и режим прогона**; что сделано; какие вопросы
+     **план прогона: метка с обоснованием, темы и их глубины**, и режим; что сделано; какие вопросы
      записаны и куда; изменённые файлы; добавлялся ли нумерованный артефакт и с
      каким номером; затронутые capability; состояние гейта; **перечень
-     запущенных проходов ревью поимённо с исходом каждого**; **путь к
+     тем с исходом по каждой**; **путь к
      сохранённому отчёту триажа** (`openspec/changes/<id>/review/`, после
      архивации — `openspec/changes/archive/<id>/review/`); шло ли ревью
      инлайн; границы покрытия.
@@ -271,29 +278,35 @@ flowchart TD
 
 ### 5. Проверить полноту ревью — до интеграции
 
-**Ветка, чей отчёт не называет профиль и проходы поимённо, не вливается.**
-Пропуск прохода не отличим от прохода без находок, и на уровне батча это ещё
-опаснее: отчётов много, каждый выглядит полным, а сверять их некому, кроме тебя.
+**Ветка, чей отчёт не называет план прогона, не вливается.** Пропуск не отличим
+от прохода без находок, и на уровне батча это ещё опаснее: отчётов много, каждый
+выглядит полным, а сверять их некому, кроме тебя.
 
 Сверка идёт в три шага, и порядок важен:
 
-1. **Возьми объявленный профиль** из отчёта задачи — он затем и заказан в
-   обязательных полях шага 4. Профиля в отчёте нет — перечень проходов сверять
-   не с чем; это само по себе основание не вливать, пока сабагент не назовёт
-   профиль и не обоснует его по факту изменения.
+1. **Возьми план прогона** из отчёта задачи — таблицу «тема → дом → глубина → кто
+   закрывает» с меткой и обоснованием; он затем и заказан в обязательных полях
+   шага 4. Плана в отчёте нет — сверять не с чем; это само по себе основание не
+   вливать, пока сабагент не покажет план разметки задачи.
 2. **Сверяй с независимым артефактом, а не с прозой отчёта.** Перечень проходов
    бери из **сохранённого отчёта триажа** (`openspec/changes/<id>/review/` или
    `openspec/changes/archive/<id>/review/` — задача доведена, change заархивирован) —
    пайплайн обязан его туда положить. Проза сабагента написана тем же, кто мог
    проход и пропустить: она подтверждает сама себя. Отчёта триажа на месте нет —
    считай, что состав неизвестен, и дозапускай ревью целиком.
-3. **Сверь состав** с таблицей профилей скилла
-   `av-dev-pipeline:review-pipeline` для объявленного профиля.
+3. **Сверь план с исходом**: против каждой темы плана обязан стоять отчёт либо
+   названная причина его отсутствия. Раскладка «тема → кто закрывает с этой меткой» — в скилле `av-dev-pipeline:review-pipeline`.
 
 Расхождение — не повод отменять задачу: дозапусти недостающие проходы **на
 ветке**, в её worktree, через `av-dev-pipeline:review-pipeline`, и только потом
 интегрируй.
 
+**Передай в дозапуск тот же план.** Триаж требует его обязательным входом — без
+плана он не может сверить, все ли размеченные темы вернули отчёт, а эта сверка и
+есть то, ради чего дозапуск затевается. Плана не осталось (сабагент не сохранил
+его в отчёте) — пусть повторит разметку задачи: это самый дешёвый проход
+конвейера, и он дешевле, чем прогон, который нечем сверить.
+
 **Находки дозапуска — такие же находки, и зелёный гейт их не отменяет.** Правило
 интеграции «вливаем только зелёные» смотрит на гейт, а дозапущенный `critical`
 гейт не красит: он был бы пропущен молча, если это не сказать прямо. Поэтому:
@@ -330,7 +343,7 @@ rebase делается **внутри worktree задачи**, а ff-слиян
   (`git -C <path> rebase --abort`), оставь ветку и worktree как есть, вынеси это
   в доклад как нераспознанное пересечение;
 - **дерево сабагента обязано быть чистым.** `git -C <path> status --porcelain`
-  до `rebase`: непусто — значит сабагент не довёл шаг 11 до коммита учёта (или
+  до `rebase`: непусто — значит сабагент не довёл шаг 12 до коммита учёта (или
   оставил мусор). Не форсируй и не коммить за него: назови задачу в докладе
   недоведённой и оставь ветку с worktree. Молчаливый `rebase` на грязном дереве
   всё равно откажет, но с сообщением про unstaged changes — а причина другая;
@@ -388,7 +401,26 @@ rebase в файле X», а не «нераспознанное пересеч
 - **заверши триажем.** Он единственный, кто агрегирует, и без него у находок нет
   ни оракула, ни пометки `инлайн`/`развилка` — а следующий абзац на неё
   опирается. Прогон из двух проходов без триажа — это сырые находки, выданные за
-  разобранные.
+  разобранные;
+- **план триажу собери сам, здесь, — разметчика на этой сверке нет.** Триаж
+  требует план обязательным входом: он сверяет размеченное с пришедшим, и без
+  плана эта сверка не выполняется вовсе. Разметка задачи сюда не годится — она
+  описывала одну задачу, а сверка идёт по интегрированной ветке. План здесь
+  короткий и составляется по факту запуска:
+
+  ```
+  метка:   не применяется — сверка стыка, а не ревью изменения
+  тема       дом                                  глубина  закрывает
+  requirements  openspec/specs/<capability-1>/    разбор   specs (стык)
+  requirements  openspec/specs/<capability-2>/    разбор   specs (стык)
+  architecture  docs/architecture.md              разбор   architecture
+                + источник docs/passport.md
+  ```
+
+  Темы, которых в этом списке нет (`autotests`, `conventions`, `security`,
+  `operations`, свои темы проекта), назови строкой «не проверяется на сверке
+  стыка: закрыто прогонами отдельных задач». Это не формальность — без такой
+  строки отчёт сверки читается как полное ревью ветки.
 
 Граф этой сверки — веер в один сток, и он такой же, как у обычного прогона:
 
@@ -414,7 +446,7 @@ flowchart TD
   `git worktree prune`. Worktree и ветки **провалившихся** не трогай — они нужны
   для ручного дожатия.
 - **Записей учёта батч не трогает** — их правит пайплайн внутри сабагента на
-  шаге 11. Батч сообщает исход по каждой задаче; если какой-то сабагент дошёл до
+  шаге 12. Батч сообщает исход по каждой задаче; если какой-то сабагент дошёл до
   коммита, но закрытия не сделал (плагина нет, вызов не разрешился), скажи это
   строкой — иначе задача останется открытой молча.
 - Доложи кратко:

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

@@ -1,6 +1,6 @@
 ---
 name: task-pipeline
-description: Автономно проводит одну задачу через полный цикл Spec Driven Development — от постановки до коммита (opsx explore→propose→ревью спек профилем design→apply→ревью кода→archive→коммит), с обязательными чекпоинтами ревью и докладом об исходе. Использовать, когда просят взять/сделать задачу или довести идею до реализации.
+description: "Автономно проводит одну задачу через полный цикл Spec Driven Development — от постановки до коммита (opsx explore→propose→разметка задачи→ревью дизайна→apply→ревью кода→archive→коммит), с обязательными чекпоинтами ревью и докладом об исходе. Разметка идёт один раз, сразу после propose: она называет размер, сложность и метка, и её план определяет состав обеих стадий ревью. Использовать, когда просят взять/сделать задачу или довести идею до реализации."
 ---
 
 # Пайплайн задачи
@@ -10,13 +10,14 @@ description: Автономно проводит одну задачу чере
 
 Это тонкая обёртка над каноническими скиллами `opsx:explore` / `opsx:propose` /
 `opsx:apply` / `opsx:archive` — вызывай их через Skill, не переизобретай их шаги.
-Ревью — скилл `av-dev-pipeline:review-pipeline`, он же держит правило выбора
-профиля.
+Ревью — скилл `av-dev-pipeline:review-pipeline`; он же держит правило выбора
+метки, а называет её агент `review-scope` на шаге 4 — один раз на задачу, для
+обеих стадий ревью.
 
 ## Предпосылки
 
 - **OpenSpec и скиллы `opsx:*` — жёсткая предпосылка, а не опция.** На них стоят
-  шаги 2, 3, 6 и 8, проход `review-specs` и профиль `design` (они завязаны на
+  шаги 2, 3, 7 и 9, проход `review-specs` и ревью дизайна (они завязаны на
   `openspec/changes/<id>/specs/*/spec.md` и на `openspec validate --strict`).
   **Проект без OpenSpec этим пайплайном не ведётся** — подключай OpenSpec, а не
   вырождай цикл: ветка деградации здесь не пишется, потому что непроверенная
@@ -47,14 +48,14 @@ description: Автономно проводит одну задачу чере
   проекте есть свой процесс управления задачами — он и решает, что брать.
 - **Форматом задач.** Пайплайн **не правит индексы руками и не выдумывает путь
   к скрипту учёта**: он зовёт Skill `av-dev-pm:tasks`, который этим владеет
-  (шаг 11). Закрытие как таковое — его работа, и это осознанное решение с
+  (шаг 12). Закрытие как таковое — его работа, и это осознанное решение с
   названной ценой: **приёмщик и исполнитель совпали**. Закрытие поэтому **не
   окончательно** — человек на сессии возвращает задачу `reopen` с причиной, а
   доклад по критериям приёмки становится единственным, по чему приёмка вообще
   возможна. Плагина `av-dev-pm` в проекте нет — вызов не разрешится, и тогда
   учёт остаётся владельцу, о чём говорится в докладе.
 - **Заведением задач из урожая ревью.** Отложенные находки отдаются **списком**
-  (см. шаг 7); превращать их в задачи — работа того, кто ведёт задачи проекта.
+  (см. шаг 8); превращать их в задачи — работа того, кто ведёт задачи проекта.
 - **Определением ценности.** «Нужна ли эта функциональность» — не вопрос
   пайплайна ни на одном шаге.
 
@@ -76,8 +77,8 @@ description: Автономно проводит одну задачу чере
 Задача сделана, когда верно всё:
 
 1. гейт проекта зелёный;
-2. ревью проведено **по профилю**, состав прогона сверен с таблицей профилей
-   поимённо, непущенные проходы названы в границах покрытия;
+2. ревью проведено, **план прогона сверен с исходом по каждой теме**, темы без
+   отчёта и без дома названы в границах покрытия;
 3. change заархивирован, дельты влиты в актуальные спеки;
 4. коммит сделан в текущую ветку;
 5. **критерии приёмки, если проект их дал, выписаны поимённо, и по каждому назван
@@ -148,7 +149,7 @@ description: Автономно проводит одну задачу чере
 
 ## Шаги
 
-Одиннадцать шагов с одной развилкой и одним досрочным исходом:
+Двенадцать шагов с одной развилкой и одним досрочным исходом:
 
 ```mermaid
 flowchart TD
@@ -157,26 +158,34 @@ flowchart TD
     big["исход «оказалась крупнее задачи»<br/>объявляется ДО заведения change"]
     s2["2. opsx:explore — груминг идеи"]
     s3["3. opsx:propose — change, дельта-спеки, tasks.md"]
-    s4["4. ревью предложения, профиль design"]
-    s5["5. отработать замечания + validate --strict"]
-    s6["6. opsx:apply — код, гейт, поведенческая верификация"]
-    s7["7. ревью кода, профиль по факту изменения"]
-    s8["8. opsx:archive"]
-    s9["9. синк документации — av-dev-pm:docs"]
-    s10["10. коммит работы — av-dev-git:commit"]
-    s11["11. закрыть задачу — av-dev-pm:tasks,<br/>вторым коммитом учёта"]
+    s4["4. разметка задачи — review-scope:<br/>размер, сложность, метка, план тем"]
+    s5["5. ревью дизайна, состав по метке"]
+    s6["6. отработать замечания + validate --strict"]
+    s7["7. opsx:apply — код, гейт, поведенческая верификация"]
+    s8["8. ревью кода, состав по той же метки"]
+    s9["9. opsx:archive"]
+    s10["10. синк документации — av-dev-pm:docs"]
+    s11["11. коммит работы — av-dev-git:commit"]
+    s12["12. закрыть задачу — av-dev-pm:tasks,<br/>вторым коммитом учёта"]
 
     s1 --> triv
     s1 -.-> big
     triv -->|"нет: идея или мутная постановка"| s2
     s2 --> s3
-    triv -->|"да: шаги 2 и 4 пропускаются"| s3
-    s3 --> s4 --> s5 --> s6 --> s7 --> s8 --> s9 --> s10 --> s11
+    triv -->|"да: шаг 2 пропускается"| s3
+    s3 --> s4 --> s5 --> s6 --> s7 --> s8 --> s9 --> s10 --> s11 --> s12
+    s4 -.->|"план задачи: та же метка"| s8
 ```
 
-Два чекпоинта ревью — шаги 4 и 7 — единственные места, где зовётся конвейер;
+**Разметка стоит одна и обслуживает обе стадии ревью** — шаги 5 и 8. Это и есть
+пунктирное ребро на схеме: план, посчитанный на шаге 4, доезжает до ревью кода
+без пересчёта. Раньше разметка была первым проходом внутри шага ревью кода, а
+состав ревью дизайна называл сам пайплайн — то есть одна и та же величина
+считалась дважды, и один из двух раз тем, кто только что написал предложение.
+
+Два чекпоинта ревью — шаги 5 и 8 — единственные места, где зовётся конвейер;
 порядок «сперва коммит работы, потом коммит учёта» на схеме тоже ребро, и оно
-обязательное (шаг 11).
+обязательное (шаг 12).
 
 Схема — **сводка**: содержание каждого шага в его разделе ниже, и при
 расхождении прав текст.
@@ -191,13 +200,20 @@ flowchart TD
 уезжают в `tasks.md` change. Файл задачи может быть удалён до коммита, а
 критерии обязаны его пережить.
 
-Оцени тривиальность (влияет на шаг 4):
+Оцени тривиальность — **теперь она влияет ровно на один шаг, второй**:
 
 - **тривиальная** — локальная правка без изменения поведения, спек и схемы,
-  решение очевидно. Explore и ревью спек пропускаются;
+  решение очевидно. Explore пропускается;
 - **нетривиальная** — новое или изменённое поведение, дизайн-развилки, задеты
   инварианты, схема или несколько capability. Полный цикл.
 
+**На состав ревью тривиальность больше не влияет** — это работа шага 4. Раньше
+она решала и то, звать ли ревью предложения вовсе; теперь глубину обеих стадий
+называет метку, и тривиальная задача просто получает `small`. Разница
+существенная: «пропустить ревью дизайна» и «пройти его одним самым дешёвым
+проходом» — не одно и то же, а сверка дельта-спек стоит меньше, чем разбор того,
+что она поймала бы.
+
 Здесь же — проверка на «крупнее задачи»: если видно, что одним заходом это не
 мерджится, объявляй исход **до** заведения change.
 
@@ -216,31 +232,67 @@ flowchart TD
 
 Критерии приёмки задачи, если они были, копируются в `tasks.md` отдельным блоком.
 
-### 4. (Нетривиальная) Ревью предложения — профиль `design`, ДО кода
+### 4. Разметка задачи — агент `review-scope`
 
-Первый чекпоинт. Вызови Skill **`av-dev-pipeline:review-pipeline`** с профилем
-`design` и ссылкой на change `<id>`.
+**Один запуск на всю задачу, и он обслуживает оба чекпоинта ревью.** Запусти
+агента `review-scope`, дав ему корень проекта, идентификатор change, базу диффа и
+запись задачи. Кода на этот момент нет, и это условие его работы, а не помеха.
 
-**Состав чекпоинта решает конвейер, а не ты**: `review-specs` в режиме «дизайн ДО
-кода» идёт всегда, а `review-rubric` и `review-architecture` — только когда
-изменение вводит новое понятие или структурную единицу (то же условие, что у
-ступени `wide`). Причина в том, что чекпоинт стоит на **каждой** задаче: при
-мелкой нарезке три прохода здесь умножаются на число задач и становятся самой
-большой статьёй конвейера.
+Он возвращает **план задачи**:
 
-Смысл профиля: архитектурная находка на готовом коде стоит переписывания и
+- **размер** (малое / среднее / крупное) и **сложность** (знакомое /
+  незнакомое), каждое с обоснованием по факту;
+- **метка** как максимум по двум осям: `small`, `medium` или `large`;
+- **состав ревью дизайна** — что звать на шаге 5;
+- **таблицу тем** «тема → дом → глубина → кто закрывает» — для шага 8;
+- разнесение документов проекта по трём категориям и строку про директивы.
+
+**Метка выбираешь не ты.** Раньше состав ревью дизайна называл этот пайплайн
+(«крупное или незнакомое?»), то есть тот же оркестратор, который только что
+довёл предложение до `propose`. Разведённости с автором в этой точке не было
+вовсе; теперь есть.
+
+**План держи в контексте до конца задачи.** На диск он не пишется: файл-план стал
+бы четвёртым артефактом рядом с `proposal.md`, `tasks.md` и `design.md`, пережил
+бы задачу и разошёлся бы с ней молча. Прервался пайплайн — повтори шаг 4, это
+самый дешёвый его проход.
+
+**Разметка повторяется ровно в одном случае** — если на шаге 6 правки изменили
+сами **дельта-спеки**: план выведен из них, и план по отменённым требованиям
+назовёт не те темы. Во всех прочих случаях, включая переделку формы кода на шаге
+8, метка остаётся прежней.
+
+### 5. Ревью предложения — ДО кода, состав по метке
+
+Первый чекпоинт. Вызови Skill **`av-dev-pipeline:review-pipeline`**, дав ссылку на
+change `<id>`, **план разметки с шага 4** и указание, что это ревью дизайна.
+
+Состав приходит планом, а не решается здесь:
+
+| Метка | Проходы на предложении |
+|---|---|
+| `small` | `specs` |
+| `medium` | `specs`, `rubric` |
+| `large` | `specs`, `rubric`, `architecture` + вопрос автору о трёх формах решения |
+
+`review-specs` в режиме «дизайн ДО кода» идёт **на каждой задаче**: это самый
+дешёвый чекпоинт конвейера, и он ловит то, что на готовом коде уже не чинят.
+Остальные включаются меткой, потому что чекпоинт стоит на каждой задаче и
+каждый лишний проход здесь умножается на число задач.
+
+Смысл стадии: архитектурная находка на готовом коде стоит переписывания и
 потому игнорируется — та же находка здесь стоит абзаца обсуждения. Если
 `review-rubric` запускался, перенеси его рубрику в `tasks.md` как приёмочные
 критерии; там же уже лежат критерии от постановки, если они были.
 
-### 5. Отработать замечания ревью предложения
+### 6. Отработать замечания ревью предложения
 
 - Мелочь и явные улучшения — правь сам в спеках и дизайне.
 - Развилки (компромисс, scope, инвариант) — вопросом в запись, спеки урезаются на
   остаток.
 - После правок перепрогони `openspec validate --strict <id>`.
 
-### 6. Написать код — `opsx:apply`
+### 7. Написать код — `opsx:apply`
 
 Вызови Skill `opsx:apply` для реализации `tasks.md`. Код — по конвенциям проекта
 (каталог `docs/conventions/`). Меняешь схему — обнови её описание в
@@ -256,22 +308,37 @@ flowchart TD
 **Сервис не оставляем лежать.** Если запуск упал — почини или откати до конца
 шага.
 
-### 7. Ревью кода — Skill `av-dev-pipeline:review-pipeline`
+### 8. Ревью кода — Skill `av-dev-pipeline:review-pipeline`
 
 Второй чекпоинт. Вызови Skill **`av-dev-pipeline:review-pipeline`**, дав ссылку
-на change `<id>`, базу диффа, профиль **и режим запуска**.
+на change `<id>`, базу диффа, **план разметки с шага 4** и режим запуска.
 
-**Правило выбора профиля живёт в скилле конвейера** (раздел «Профили»), проектные
-триггеры — в `docs/review.md`, если записаны. Здесь оно не пересказывается: три
-копии одного правила расходятся, и работать будет та, которую прочитали
-последней. Помни ровно одно — **профиль выбирается по факту изменения, а не по
-ощущению важности**, и посмотри таблицу перед вызовом.
+**Метка ты не выбираешь, и это правило, а не упрощение.** Её назвал
+`review-scope` ещё на шаге 4 — по размеру и сложности, с обоснованием по каждой
+оси. Причина в разведённости: ты только что написал этот код, и решать, насколько
+глубоко его проверять, тебе нельзя — под давлением «я почти закончил» решение
+известно заранее. Правило выбора живёт в скилле конвейера —
+`av-dev-pipeline:review-pipeline`, `references/review-levels.md`; проектные
+триггеры — в `docs/review.*`, подраздел «Триггеры метки».
+
+**Метка не пересматривается по факту диффа.** Дифф может выйти крупнее, чем
+ожидалось при разметке, — это не повод её поднимать: пересмотр означал бы второй
+запуск разметчика, ровно то, ради устранения чего он и переехал на шаг 4.
+
+**Считаешь метку заниженной — скажи это в докладе строкой, а не переспорь.**
+Разметчик вправе и поднять, и понизить; твоё несогласие это факт для человека, а
+не команда конвейеру. Место, где такое несогласие превращается в изменение
+правил, — журнал дефектов `docs/review.md`, и только постфактум.
+
+**Плана нет — ревью кода не запускается.** Триаж требует план обязательным
+входом: без него он не может сверить, все ли размеченные темы вернули отчёт, а
+эта сверка — единственная защита от молчащего пропуска. Потерял план (прервалась
+сессия, ушёл контекст) — повтори шаг 4, а не гони прогон без него.
 
 **Режим по умолчанию — `по графу`, и обосновывать его не надо.** Конвейер сам
 знает свои рёбра: гейт открывает опиниативные проходы, проходы с пометкой «держит
 машину» идут цепочкой (иначе замеры портят друг друга и находка выглядит
-доказанной), дорогие generative-проходы ждут барьера стоимости, триаж — сток.
-Твоего участия это не требует.
+доказанной), триаж — сток. Твоего участия это не требует.
 
 Просить **`линейно`** нужно только по причине, и она называется строкой: так
 сказал оператор; машина занята чем-то ещё (в том числе соседней задачей батча);
@@ -281,13 +348,14 @@ flowchart TD
 потолком 7 пунктов, разметкой `Действие: инлайн | развилка` и секцией границ
 покрытия.
 
-**Сверь состав прогона с таблицей профилей в скилле, прежде чем коммитить.**
-Отчёт обязан называть запущенные проходы **поимённо и с исходом**; непущенный
-идёт строкой «не запускался» в границы покрытия. Реестр короткий (4–8 проходов) —
-сверка стоит одного взгляда. Почему это правило существует, объясняет раздел
-«Профили» скилла конвейера; здесь — само требование.
+**Сверь план прогона с исходом, прежде чем коммитить.** Отчёт начинается планом
+разметчика — таблицей «тема → дом → глубина → кто закрывает», — и против каждой
+темы обязан стоять исход. Тема без отчёта и тема без дома — разные вещи, и обе
+должны быть названы. Реестр короткий (шесть тем ядра плюс свои) — сверка стоит
+одного взгляда. Почему это правило существует, объясняет раздел «Метки» скилла
+конвейера; здесь — само требование.
 
-Отработай так же, как шаг 5: помеченное `инлайн` чини сам и не логируй,
+Отработай так же, как шаг 6: помеченное `инлайн` чини сам и не логируй,
 `развилка` — вопросом в запись (он уже сформулирован триажем, его остаётся
 перенести). После правок — снова гейт.
 
@@ -301,19 +369,19 @@ flowchart TD
 сжатой строкой. Отчёт, из которого исчезло «что проверить было невозможно»,
 превращается в ложное ощущение проверенности.
 
-**Отчёт триажа сохрани вместе с change (`openspec/changes/<id>/review/`; шаг 8
+**Отчёт триажа сохрани вместе с change (`openspec/changes/<id>/review/`; шаг 9
 унесёт его в `openspec/changes/archive/<id>/review/` вместе с change) — это
 обязательно, а не «если удобно».** По нему потом видно, что было найдено и что из
 этого осталось в урожае. И это единственный **независимый** артефакт о составе
 прогона: под оркестратором `task-batch` именно по нему сверяют полноту ревью
 ветки, а не по твоей прозе — она написана тем же, кто мог проход и пропустить.
 
-### 8. Архивировать — `opsx:archive`
+### 9. Архивировать — `opsx:archive`
 
 Вызови Skill `opsx:archive`: change уезжает в архив, дельты вливаются в
 актуальные спеки.
 
-### 9. Синк документации
+### 10. Синк документации
 
 Ревью выполненного — до этого шага. Затем **вызови Skill `av-dev-pm:docs`**: он
 владеет содержимым документов канона и ведёт чек-лист синка. Плагина нет — шаг
@@ -338,7 +406,7 @@ flowchart TD
 сделан по перечню документов, без списка триггеров — плагина `av-dev-pm` нет».
 Канона в проекте тоже нет — назови это исходом и предложи `av-dev-pm:canon`.
 
-### 10. Коммит
+### 11. Коммит
 
 Коммить **в текущую ветку** (`git rev-parse --abbrev-ref HEAD`), сам ветку не
 создавай и не переключай, ничего не пушь. При ручном запуске HEAD обычно на
@@ -349,7 +417,7 @@ flowchart TD
 сделано», тело списком 1–3 пункта, без трейлеров). Одна задача — один осмысленный
 коммит.
 
-### 11. Закрыть задачу — **после коммита, не раньше**
+### 12. Закрыть задачу — **после коммита, не раньше**
 
 **Вызови Skill `av-dev-pm:tasks`** и попроси закрыть задачу как реализованную —
 он владеет форматом и двигает строку из набора спринта сам. Путь к его скрипту не
@@ -357,7 +425,7 @@ flowchart TD
 путь.
 
 **Порядок обязателен.** Закрытие удаляет файл задачи; сделанное до коммита оно
-оставило бы задачу закрытой без единого следа работы, если шаг 10 упадёт.
+оставило бы задачу закрытой без единого следа работы, если шаг 11 упадёт.
 
 **Закрытие тоже коммитится — вторым коммитом, тут же.** Удаление файла задачи и
 правка индексов (их имена знает `av-dev-pm`, не ты) — это правки в рабочем
@@ -385,7 +453,7 @@ flowchart TD
   это доклад приёмщику, а не отметка «принято»;
 - **`Урожай`** — отложенные находки списком (формулировка, оракул, провенанс).
   Задачи из него заводит тот, кто ведёт задачи проекта;
-- **одна строка границ покрытия**: какой профиль и режим гонялись, какие проходы
+- **одна строка границ покрытия**: какая метка и режим гонялись, какие проходы
   не запускались и что проверить было невозможно. Доклад без неё сообщает
   «проверено», не сообщая, что именно.
 
@@ -395,15 +463,16 @@ flowchart TD
   текущем worktree и на текущей ветке: не делай `git checkout`/`switch`, не
   создавай веток, не пушь.
 - Не пропускай `openspec validate --strict` перед архивацией.
-- Тривиальная задача: шаги 2 и 4 пропускаются; ревью кода (шаг 7) остаётся
-  всегда, но в профиле `quick`.
+- Тривиальная задача: пропускается только шаг 2. Обе стадии ревью остаются, но
+  с меткой `small` — один проход на дизайне и четыре на коде, а при своих темах
+  проекта пять: приёмник тем запускается, если ему есть что принимать.
 - Гейт блокирует: пока он красный, опиниативные проходы не запускаются. Чинить и
   перезапускать, а не «посмотреть заодно».
 - Если ревью предлагает крупную переработку — это развилка: не правь молча и не
   спрашивай, запиши вопросом и доведи остаток.
 - Держи вызывающего в цикле короткими репликами на переходах фаз, но не проси
   подтверждать механику.
-- **Занизить профиль ревью или пропустить проход — самый дешёвый способ
-  «ускориться», и он же самый дорогой по последствиям.** Защита одна: профиль
-  выбирается по факту изменения, состав сверяется поимённо, а непущенное
-  называется в отчёте строкой.
+- **Занизить метка ревью или пропустить тему — самый дешёвый способ
+  «ускориться», и он же самый дорогой по последствиям.** Защита устроена так,
+  что регулятора у тебя нет: метку выбирает разметчик **до того**, как ты
+  написал код, план сверяется по темам, непокрытое называется в отчёте строкой.

av-dev-pm/agents/doc-code-drift.md

@@ -2,8 +2,8 @@
 name: doc-code-drift
 description: "Сверка документов канона с кодом по закрытому перечню проверяемых фактов: имя основной ветки и команды из CLAUDE.md, запреты с путями, testdata и временный каталог, путь миграций из .pm.json, внешние зависимости поимённо в architecture.md против манифеста, настройки с числовым значением в database.md против конфига и кода, единые точки проекта против реального числа реализаций, capability против существующих модулей. Отвечает на «этот факт ещё верен», а не «эта архитектура правильная». Читает весь репозиторий, гоняет только читающие команды. Отдаёт готовые формулировки и ничего не правит сам. Согласованность документов между собой смотрит агент doc-consistency. Использовать на сессии между спринтами, а также после приведения проекта к канону (adopt) и после повышения версии канона (upgrade). Только чтение."
 tools: Read, Grep, Glob, Bash
-model: fable
-color: red
+model: sonnet
+color: green
 ---
 
 Ты — **сверка документов канона с кодом**. Один вопрос: **этот факт ещё верен?**

av-dev-pm/agents/doc-consistency.md

@@ -46,8 +46,9 @@ color: yellow
 ## Что тебе дают
 
 Корень проекта. Твоё чтение — `docs/**` (кроме `docs/tasks/`, его ведёт
-`tasks.py`), `CLAUDE.md` и `openspec/specs/**`. Плюс `openspec/changes/archive/`,
-когда проверяешь ADR: там лежат `design.md`, из которых записи промоутятся.
+`tasks.py`), `CLAUDE.md`, `openspec/specs/**` и `openspec/config.yaml`. Плюс
+`openspec/changes/archive/`, когда проверяешь ADR: там лежат `design.md`, из
+которых записи промоутятся.
 
 **Кода ты не читаешь.** Разошёлся ли документ с кодом — вопрос агента
 `doc-code-drift`, и у него для этого другой вход и другая цена.
@@ -63,6 +64,17 @@ color: yellow
    важнее совпадающих: совпадающие разойдутся завтра, разошедшиеся уже врут, и в
    этом случае назови **оба значения**, не выбирая за человека.
 
+   **Самое частое место второго дома — блок `context` в `openspec/config.yaml`.**
+   Он читается при порождении каждого артефакта, туда удобно дописать «чтобы
+   агент знал», и так в нём заводятся инварианты, перечень конвенций, состав
+   шагов гейта, границы домена и правила ревью. По канону там законны только
+   нужды порождения — язык, именование capability, придирки валидатора — и
+   **адреса** документов. Разрез проверяемый: **утверждение, которое можно
+   опровергнуть, открыв другой файл проекта, — пересказ и находка; строка,
+   которая говорит, какой файл открыть, — ссылка и норма.** Форму `config.yaml`
+   машина проверяет, этот разрез — нет: отличить ссылку от пересказа она не
+   умеет, и потому он твой.
+
 2. **Прямое противоречие между документами.** Самое дорогое, что ты находишь, и
    искать его надо адресно, а не вычитыванием подряд. Пары, которые расходятся
    чаще прочих:
@@ -113,7 +125,7 @@ color: yellow
      `adr/README.md`;
    - **замена парная**: новая запись пересматривает прежнее решение — у старой
      обязан быть статус «заменено на». Односторонняя замена оставляет две
-     активные записи об одном, и `architecture` прочитает ту, что нашёл первой.
+     активные записи об одном, и читатель прочитает ту, что нашёл первой.
 
 7. **Пустое названо пустым, а не заглушено.** Незаполненный документ канона
    держит **одну честную информативную строку**: «внешних зависимостей нет —

av-dev-pm/agents/doc-wording.md

@@ -103,7 +103,7 @@ color: green
 | Термин | Что называет |
 | --- | --- |
 | интейк | заведение записи с фильтром и дедупом: «заведение» называет создание файла, слить их — смешать две операции |
-| триаж | ступень конвейера, сводящая находки в решение |
+| триаж | стадия конвейера, сводящая находки в решение |
 | провенанс | обязательное свойство числа: чем и при каких условиях получено. «Источник» рядом называет саму запись, а не свойство |
 | дедуп, дедупликация | сверка нового против уже лежащего |
 | чек-лист | перечень, по которому идут сверху вниз, называя исход каждой строки |

av-dev-pm/agents/task-form.md

@@ -2,8 +2,8 @@
 name: task-form
 description: "Проверка формы записи каталога задач по существу: тип, разошедшийся с содержанием записи, форма заголовка по типу (цель — что приложение будет уметь, задача — что нужно сделать, разведка — о чём она), «зачем», пересказывающее заголовок вместо состояния и боли, раздел «Затрагивает» с замыслом вместо границ, критерий приёмки с оракулом только на словах, предписание процесса в теле, и связь задачи со строкой «Завершения» её цели. Читает файл цели, на которую ссылается задача. Отдаёт готовые формулировки на замену и ничего не правит сам. Язык текста (залог, оценки, стоп-слова, англицизмы) смотрит отдельный агент doc-wording. Использовать после заведения или разбора пачки записей, до взятия в спринт и на переоценке. Только чтение."
 tools: Read, Grep, Glob
-model: opus
-color: yellow
+model: sonnet
+color: green
 ---
 
 Ты — **проверка формы записи** каталога задач. Форма это не оформление: она
@@ -100,7 +100,7 @@ color: yellow
    одной партии»), — находка: слово стоит, проверки нет. Число критериев считает
    `tasks.py check`, тебе оно неинтересно.
 
-6. **Предписания процесса в теле нет.** «Делать профилем standard», «взять
+6. **Предписания процесса в теле нет.** «Делать с меткой medium», «взять
    такой-то агент» — это выбор, который делают, увидев изменение, а не при
    постановке. Он же путь понизить требования решением, принятым до
    проектирования.

av-dev-pm/skills/canon/SKILL.md

@@ -47,8 +47,19 @@ ds="$CLAUDE_PLUGIN_ROOT/skills/canon/scripts/docs.py"
 
 python3 $ds check --dir <корень> [--base <rev>]   # раскладка, ссылки, версия, сверки
 python3 $ds version --dir <корень>                # версия канона скрипта и проекта
+python3 $ds openspec-form                         # форма config.yaml против живого OpenSpec
 ```
 
+**`openspec-form` зовут не на каждом прогоне, а когда о нём попросил `check`.**
+Форма `openspec/config.yaml` описана в каноне слепком чужого инструмента — имя
+схемы и перечень артефактов, — и слепок стареет молча: OpenSpec переименует
+артефакт, правила под старым именем перестанут применяться, а конфиг останется
+выглядеть написанным. Поэтому `check` каждым прогоном сравнивает `major.minor`
+установленного OpenSpec с тем, на котором форма сверялась, и при расхождении
+даёт замечание с этой командой. Команда ничего не правит: она спрашивает
+инструмент и печатает, что разошлось. **Чинится это в плагине, а не в проекте** —
+константы `docs.py`, скелет в `skeletons.md` и запись в журнал версий канона.
+
 **Коды выхода — тот же словарь, что у `tasks.py`:** 0 сошлось, 1 дрейф, 2 ошибка
 употребления, 3 окружение, 4 внутренний сбой. Ветвись на коде, а не на тексте.
 
@@ -84,9 +95,10 @@ capability: незаполненный канон это переходное с
 1. `docs.py check`, при наличии базы диффа — с `--base`.
 2. **Агентов на каждом `check` не зови.** Оба — `doc-consistency` и
    `doc-code-drift` — зовутся раз в спринт (шаг сессии), а также шагом 6 `adopt`
-   и шагом 6 `upgrade`, на весь канон разом. Они дороги: оба на `opus`, второй
-   ещё и читает репозиторий. Позвал `doc-code-drift` — передай ему раздел
-   запретов `CLAUDE.md`.
+   и шагом 6 `upgrade`, на весь канон разом. Они дороги: `doc-consistency` — тем,
+   что на `opus` (сличение утверждений это суждение), `doc-code-drift` — тем, что
+   читает репозиторий целиком, хотя сам идёт на `sonnet`. Позвал
+   `doc-code-drift` — передай ему раздел запретов `CLAUDE.md`.
 3. Доклад: вывод скрипта строкой исхода, находки агентов поимённо, **граница
    покрытия** — что смотрели и чего не смотрели, и **кого из двоих позвал**:
    доклад, умолчавший об этом, читается как «сверено».
@@ -135,20 +147,25 @@ capability), `openspec/config.yaml`.
 1. `docs/.pm.json` с `{"canon": <текущая версия>}` и путём миграций, если БД есть;
 2. каталоги канона и скелет **по [references/skeletons.md](references/skeletons.md)**:
    незаполненное — одной честной информативной строкой, а не «TBD»;
-3. переносы содержимого;
-4. каталог задач — **вызови скилл `av-dev-pm:tasks`**, сценарий адаптации: он
+3. **OpenSpec, если его нет** — `openspec init --tools claude`, и `config.yaml`
+   по тому же скелету. Каталог есть, а `config.yaml` из коробки — тот же случай,
+   что отсутствие: закомментированный пример выглядит настройкой и не является
+   ею. Пересказ инвариантов, конвенций и правил ревью из `context` вычисти
+   ссылкой на дом — на переводимом проекте он там почти наверняка есть;
+4. переносы содержимого;
+5. каталог задач — **вызови скилл `av-dev-pm:tasks`**, сценарий адаптации: он
    владеет форматом задач. Он же переименует транслитные слаги в английские и
    тем же проходом починит перекрёстные ссылки;
-5. починка ссылок на перенесённое во всём репозитории — `docs/`, `openspec/`,
+6. починка ссылок на перенесённое во всём репозитории — `docs/`, `openspec/`,
    `CLAUDE.md`, `README.md`;
-6. удаление оригиналов — **только тех, чьё содержимое найдено в новом доме**;
-7. **шаг `docs.py check` в гейт проекта.** Путь к скрипту — переменной с
+7. удаление оригиналов — **только тех, чьё содержимое найдено в новом доме**;
+8. **шаг `docs.py check` в гейт проекта.** Путь к скрипту — переменной с
    умолчанием на канонический путь маркетплейса, чтобы переустановка плагина не
    меняла `Taskfile`; шаг обязан **краснеть внятно**, если скрипт не найден, а не
    пропускаться. Передай ему базу диффа (`--base`) той же переменной, что и
    остальным шагам гейта: без неё сверка миграций со схемой не гоняется вовсе.
    Пример строки покажи человеку — гейт принадлежит проекту, и правит его он;
-8. `docs.py check` — до **отсутствия дрейфа раскладки**. Замечания
+9. `docs.py check` — до **отсутствия дрейфа раскладки**. Замечания
    (незаполненные плейсхолдеры, слабое упоминание capability) остаются:
    незаполненный канон это объявленное переходное состояние из шага 5, а не
    отказ. **Пункт «задачи без цели» из вложенной проверки `tasks.py` тоже
@@ -198,7 +215,7 @@ capability), `openspec/config.yaml`.
 
 **Шаг 6 обязателен, и вот почему.** `check` сверяет **число** в `.pm.json` с
 версией скрипта — и только его. Применена ли запись журнала **по существу**, он
-не знает: проект несёт `"canon": 4` и может не иметь того, чего требовала любая
+не знает: проект несёт `"canon": 6` и может не иметь того, чего требовала любая
 из пройденных версий. Записи применяются руками (переименовать секцию, проставить
 типы, дописать раздел каждому `fix`), а ручной проход по нескольким записям
 подряд — ровно то место, где половина шага делается и забывается. Судьи и есть

av-dev-pm/skills/canon/references/canon.md

@@ -1,6 +1,6 @@
 # Канон документов проекта
 
-**Версия 4.**
+**Версия 7.**
 
 Это **единственный дом определения канона**. Скиллы `init`, `canon` и `docs`
 читают его, а не пересказывают: три описания одной раскладки разъедутся, и
@@ -34,7 +34,7 @@
 | --- | --- | --- |
 | `ROADMAP.md`, секция `Сопровождение` | план | **работы**, которые собираемся делать: цели и их задачи |
 | `architecture.md`, раздел «Эксплуатация» | состояние | **как устроено сейчас**: где работает, что рядом, кто перезапускает |
-| эксплуатационный проход ревью | оптика | **чем проверяем**: «это упало через неделю на проде» |
+| тема ревью `operations` | оптика | **чем проверяем**: «это упало через неделю на проде» |
 
 Слово **«поддержка» не употребляется вовсе** — в нём слышится помощь
 пользователю, а это другая работа.
@@ -47,26 +47,26 @@
 
 ## Раскладка
 
+**Документ канона живёт файлом или каталогом.** `docs/security.md` и
+`docs/security/` — одно и то же; форму выбирает проект по объёму написанного, и
+переход между формами не меняет ни канон, ни версию. Обе формы сразу — ошибка:
+два дома для одного факта расходятся молча.
+
 ```
 CLAUDE.md                      памятка агенту: что это, стек, инварианты с
                                severity, команды, семантика гейта, запреты
+AGENTS.md                      необязателен, лежит рядом; читается теми же
 docs/
   .pm.json                     версия канона и пути, нужные проверкам
-  passport.md                  зачем и для кого; чем НЕ является; сценарии
-  architecture.md              как сложено — обзор; окружение и эксплуатация
-  database.md                  схема хранилища; представление данных и настройки
-  security.md                  периметр; недоверенный вход; что вне модели
-  conventions/
-    README.md                  индекс, правило промоута, что механизировано
-    <slug>.md
-  research/
-    README.md                  как снималось, индекс
-    <slug>.md                  наблюдения и числа с провенансом
-  adr/
-    README.md                  индекс записей, статусы, правило замены
-    template.md
-    ADR-ГГГГ-ММ-ДД-slug.md
-  review.md                    настройка конвейера под проект + журнал дефектов
+  passport.md   | passport/    зачем и для кого; чем НЕ является; сценарии
+  architecture.md | architecture/  как сложено — обзор; окружение и эксплуатация
+  database.md   | database/    схема хранилища; представление данных и настройки
+  security.md   | security/    периметр; недоверенный вход; что вне модели
+  conventions.md | conventions/  как пишем код; что механизировано
+  research.md   | research/    наблюдения и числа с провенансом
+  adr.md        | adr/         почему решено так; статусы, правило замены
+  review.md     | review/      настройка конвейера под проект + журнал дефектов
+  <своя тема>.md | <своя тема>/  всё, что проект счёл нужным проверять
   tasks/                       скилл tasks: items/, ROADMAP.md, BACKLOG.md,
                                SPRINT.md, REJECTED.md
 openspec/
@@ -75,6 +75,77 @@ openspec/
   changes/archive/             архив изменений с design.md — сырьё для ADR
 ```
 
+**У документа-каталога обязателен `README.md`** — вход, по которому его читают агенты.
+`adr/` в форме каталога держит ещё и `template.md`, а записи именуются
+`ADR-ГГГГ-ММ-ДД-slug.md`.
+
+## Три категории документов
+
+Раньше здесь стояло плоское правило «каждый документ `docs/` — тема ревью». Оно
+неверно ровно наполовину: паспорт и схема хранилища ревью нужны, но темами не
+являются, а журнал решений и журнал наблюдений ревью изменения не нужны вовсе.
+Плоское правило заставляло разметчика либо плодить фантомные темы, либо терять
+документы молча — а молчащая потеря и есть то, против чего канон написан.
+
+**Разрез один и проверяемый: можно ли по документу сказать «в этом изменении
+сделано не так»?**
+
+| Категория | Ответ на разрез | Что с ней делает ревью |
+| --- | --- | --- |
+| **тема** | да, прямо | заводит направление проверки и требует исполнителя |
+| **источник темы** | нет, но он задаёт границу, по которой судит чужая тема | читается как материал, своей темы не порождает |
+| **процессный документ** | нет: он про то, как мы работаем, а не про изменение | не судит по нему изменение |
+
+| Документ | Категория | Куда питает |
+| --- | --- | --- |
+| `conventions.*` | тема | `conventions` |
+| `security.*` | тема | `security` |
+| `architecture.*` | тема | `architecture`; раздел эксплуатации — `operations` |
+| *свой документ проекта* | тема | своя тема, именем документа |
+| `passport.*` | источник | `architecture` — граница домена, «чем **не** является» |
+| `database.*` | источник | `operations` — схема и настройки с числами |
+| `CLAUDE.md`, `AGENTS.md` | источник | `autotests` (семантика гейта); инварианты — сквозные |
+| `openspec/specs/` | источник | `requirements` |
+| `openspec/config.yaml` | процессный | — (настройка порождения артефактов, слой **до** тем) |
+| `tasks/` | процессный | — |
+| `review.*` | процессный | — (настройка самого конвейера, слой **над** темами) |
+| `adr.*` | процессный | — |
+| `research.*` | процессный | — |
+| `.pm.json` | процессный | — (служебный файл, не документ) |
+
+**Список тем открытый, и это не послабление, а механизм.** Категории
+`источник` и `процессный` **закрыты** — они перечислены здесь поимённо и
+проектом не пополняются. Всё остальное, что проект кладёт в `docs/`, — тема: у
+конвейера есть приёмник для темы, к которой нет именной оптики, и заведён он
+ровно за этим. Завёл `docs/accessibility.md` — появилась тема `accessibility`, и
+она попадает в план каждого прогона.
+
+Отсюда следствие, ради которого правило и заведено: **`docs/` — это конфигурация
+ревью.** Проект настраивает проверку тем, что пишет о себе, а не отдельным файлом
+настроек, который разошёлся бы с документами.
+
+**«Не судит по нему» и «не открывает» — не одно и то же, и разница существенна.**
+`docs/review.*` проходы читают на каждом прогоне: там лежат вопросы по темам,
+журнал дефектов, типовые узлы и типовые ложноположительные. Это чтение конвейером
+**собственной настройки**, а не суждение об изменении, и потому оно законно.
+`adr/`, `research/` и `tasks/` не открывает никто: по ним изменение не судят, и
+настройкой конвейера они не являются.
+
+**Процессный документ — не документ второго сорта.** `adr/` и `research/`
+проверяются наравне с остальными, но **сверкой документации**, а не прогоном
+ревью: ADR без ссылки на архивный `design.md`, замена без парного статуса, число
+без провенанса — это работа агентов `doc-consistency` и `doc-code-drift`, и она
+осталась там же, где была. Изменилось одно: прогон ревью не открывает их как
+критерий и не судит по ним изменение.
+
+Цена этого решения записана, а не подразумевается: **расхождение изменения с
+записанным решением прогоном больше не ловится.** Раньше архитектурный проход
+читал `adr/` и мог сказать «здесь отменено решение ADR-2026-03-11, а парного
+статуса нет»; теперь это скажет только `doc-consistency` на сессии между
+спринтами. Сделка сознательная — ADR объясняет прошлое, а не предъявляет
+требование к изменению, и чтение всего каталога решений на каждой задаче
+оплачивалось на каждой, а срабатывало на единицах.
+
 ### Имена файлов английские, текст русский
 
 **Текст документов русский; имена файлов, capability и задач — английские,
@@ -99,22 +170,38 @@ kebab-case.** Причина не эстетическая: имя файла с
 умеет `tasks.py adopt`; для документов канона правит человек, а `docs.py` потом
 показывает, что ссылки целы.
 
-## Роли документов
+## Роли документов и темы ревью
 
-Одна строка на каждый — на какой вопрос он отвечает и кто его читает.
+Одна строка на каждый — на какой вопрос он отвечает, в какой он категории и
+какую тему питает. **Кто именно закрывает тему, здесь не указано намеренно**: это
+зависит от метки прогона и меняется вместе с конвейером, а документ живёт
+дольше. Раскладку «тема → проход → глубина» держит скилл
+`av-dev-pipeline:review-pipeline`.
 
-| Документ | Вопрос | Кто читает, кроме человека |
+**Общего словаря у канона с конвейером ровно три вида имён: имена категорий,
+имена тем и имена меток.** Категорий три — `тема`, `источник`, `процессный`;
+**меток тоже три, и они закрыты: `small`, `medium`, `large`.** Метка это итог
+классификации задачи, и по ней конвейер выбирает исполнителей на обеих стадиях
+ревью; проект её не выдумывает, а только уточняет триггеры. Ими проект и
+настраивает ревью — вопросами по темам и триггерами метки. **Имён проходов канон не называет нигде**, включая вывод `docs.py`:
+проход переименовывается и переезжает между метками, и канон, назвавший его, в
+этот день соврёт молча. Обратное направление законно — конвейер называет
+документы канона поимённо, потому что он их читатель.
+
+| Документ | Вопрос | Категория и тема |
 | --- | --- | --- |
-| `CLAUDE.md` | что нельзя нарушать, чем краснеет гейт | все агенты, всегда |
-| `passport.md` | зачем и для кого, чем это **не** является | `architecture`, `rubric`, `reimpl`, `specs` |
-| `architecture.md` | как сложено и где что работает | все проходы ревью |
-| `database.md` | что лежит в хранилище и какими настройками | `ops`, `adversary`, `reimpl` |
-| `security.md` | против кого защищаемся и что вне модели | `adversary` |
-| `conventions/` | как мы пишем код | `code` |
-| `research/` | что показала реальность, а не документация | `specs`, `reimpl`, `ops`, `adversary` |
-| `adr/` | почему решено именно так | `architecture` |
-| `review.md` | как настроен конвейер и что уже проскакивало | `triage`, каждый проход — свою часть |
-| `openspec/specs/` | что система делает — нормативно | `specs` |
+| `CLAUDE.md`, `AGENTS.md` | что нельзя нарушать, чем краснеет гейт | источник: `autotests`; инварианты — сквозные, во все темы |
+| `passport.*` | зачем и для кого, чем это **не** является | источник: `architecture` |
+| `architecture.*` | как сложено и где что работает | тема `architecture`; раздел эксплуатации — `operations` |
+| `database.*` | что лежит в хранилище и какими настройками | источник: `operations` |
+| `security.*` | против кого защищаемся и что вне модели | тема `security` |
+| `conventions.*` | как мы пишем код | тема `conventions` |
+| `openspec/specs/` | что система делает — нормативно | источник: `requirements` |
+| `research.*` | что показала реальность, а не документация | процессный |
+| `adr.*` | почему решено именно так | процессный |
+| `review.*` | как настроен конвейер и что уже проскакивало | процессный: слой **над** темами |
+| `tasks/` | что делаем и в каком порядке | процессный |
+| *свой документ проекта* | что проект счёл нужным проверять | **своя тема**, именем документа |
 
 ### `passport.md`
 
@@ -166,7 +253,7 @@ kebab-case.** Причина не эстетическая: имя файла с
 
 **Периметр первой строкой.** «Сервис открыт наружу» и «контур доверенный,
 публичного интернета здесь нет, не выдумывай его» — противоположные постановки
-под одним заголовком, и враждебный проход между ними сам не выберет. Контур ещё
+под одним заголовком, и разбор темы `security` между ними сам не выберет. Контур ещё
 не развёрнут — назови **оба** периметра, целевой и сегодняшний, и скажи прямо,
 против какого строятся находки.
 
@@ -229,18 +316,27 @@ kebab-case.** Причина не эстетическая: имя файла с
 - **Типовые узлы** — рода узлов проекта и 3–5 проверяемых свойств к каждому;
 - **Типовые ложноположительные** — находки, которые здесь выглядят убедительно и
   всегда неверны, каждая со строкой «почему здесь это не дефект»;
-- **Вопросы к проходам** — поимённо, в форме `<имя прохода>: <вопрос>
-  (<провенанс>)`;
-- **Триггеры профиля** — проектная конкретизация правила выбора профиля ревью:
-  что в этом проекте считается **новым понятием или структурной единицей** (это
-  поднимает прогон до `wide`) и **где живут правила идентичности, слияния и
-  разбора** (до `deep`) — перечнем мест, производным от теста конвейера, а не
-  вторым определением класса. Уточняет умолчания, а не отменяет их. Рабочее
-  умолчание — `standard`: миграция схемы и публичный контракт ступень **не**
-  поднимают, их проверяют проходы, которые в `standard` и так есть;
-- **Недоступно проверке** — два подраздела: «не проверит ни один проход»
-  (принципиальная граница, по факту промаха не пересматривается) и «перестали
-  проверять сознательно» (пересматривается первым).
+- **Вопросы по темам** — в форме `<тема>: <вопрос> (<провенанс>)`. **Не по именам
+  проходов**: проход уезжает между метками, а тема остаётся, и вопрос,
+  адресованный проходу, перестал бы задаваться молча в тот день, когда тот уехал
+  в старшую метку. Задаёт вопрос тот, кто закрывает тему на этом прогоне.
+  Адресовать можно только теме: `passport`, `database`, `adr`, `research` и
+  `review` — не темы, и вопрос, адресованный им, не задаст никто;
+- **Триггеры метки** — проектная конкретизация правила выбора метки ревью,
+  **тремя списками**. Два поднимают, по одному на ось: что в этом проекте считается
+  **крупным** (объём: сколько узлов и слоёв трогает) и что считается
+  **незнакомым** (форма решения: известна до начала или нащупывается по ходу).
+  Любая из двух осей поднимает прогон до `large`, старшей метки, — а она
+  рассчитана на 5–10% задач. Третий список — что считается **мелким** (опускает
+  до `small`); он один, потому что вниз метку опускает только совпадение обеих
+  осей сразу. Перечнем мест, узлами или capability, а не вторым определением
+  класса. Уточняет умолчания, а не отменяет их. Рабочее умолчание — `medium`:
+  миграция схемы и публичный контракт метку **не** поднимают, их проверяют
+  проходы, которые в `medium` и так есть;
+- **Недоступно проверке** — два подраздела, оба **по темам**: «не проверит ни
+  один проход» (принципиальная граница, по факту промаха не пересматривается) и
+  «перестали проверять сознательно» (пересматривается первым). Тема, у которой в
+  проекте нет дома, сюда не пишется: её и так называет план каждого прогона.
 
 **Журнал дефектов:** запись на каждый воспроизведённый дефект с пометкой
 **проскочил / пойман ревью**. Проскочившие — проверочный набор для калибровки конвейера,
@@ -316,10 +412,54 @@ kebab-case.** Причина не эстетическая: имя файла с
 ### `openspec/config.yaml`
 
 **Только нужды генерации артефактов** — язык, правила именования capability,
-придирки валидатора RFC 2119 — плюс ссылки на документы канона. Правило ревью,
+придирки валидатора RFC 2119 — плюс **адреса** документов канона. Правило ревью,
 пересказ конвенций и инварианты сюда не пишутся: у них есть свои дома, и второй
 дом разойдётся на первой же правке.
 
+**Каталог `openspec/` — часть канона, а не соседняя технология.** В нём дом темы
+`requirements`, и заводится он командой: `openspec init --tools claude`. Её
+выполняет `init` на новом проекте и `adopt` на переводимом; из канона она названа
+поимённо потому, что её печатает отказ `docs.py`, а отказ без команды заставляет
+искать её в другом месте.
+
+**Файл из коробки настройкой не является.** `openspec init` кладёт `config.yaml`,
+где и `context`, и `rules` лежат закомментированным примером. Такой файл читается
+как настроенный — он есть, он валиден, у него правильное имя, — а работает как
+пустой: предложение пишется без языка, без правил именования capability и без
+знания, где лежит граница домена. Это ровно тот класс, против которого написан
+весь канон, и потому здесь он проверяется машиной, а не чтением.
+
+Проверяется пять вещей, и каждая — про молчащий пробел, а не про вкус:
+
+1. **`openspec/` есть.** Нет — нет и дома темы `requirements`.
+2. **Имя файла `config.yaml`.** `config.yml` OpenSpec не читает и об этом не
+   сообщает: настройка, написанная в файл с таким именем, пропадает целиком.
+3. **`context` и `rules.specs` не остались примером.** Правила для `specs`
+   обязаны называть `SHALL`: требование без этого литерала валидатор отвергает.
+4. **`context` называет `passport` и `CLAUDE.md`.** Предложение пишется **до**
+   того, как кто-либо откроет `docs/`; без этих двух адресов его пишут, не зная
+   ни границы домена, ни инвариантов.
+5. **Ключи под `rules:` — имена артефактов схемы** (`proposal`, `specs`,
+   `design`, `tasks`). Правило, адресованное несуществующему артефакту, не
+   применяется и об этом молчит: `rules.spec` вместо `rules.specs` — конфиг,
+   выглядящий написанным и не работающий.
+
+**Схема и перечень артефактов — слепок чужого инструмента, и он стареет.**
+OpenSpec переименует артефакт или сменит схему — правила под прежним именем
+перестанут действовать молча, а канон будет продолжать требовать прежнее.
+Поэтому за свежестью слепка следит машина: `check` сравнивает `major.minor`
+установленного OpenSpec с версией, на которой форма сверялась, и при расхождении
+даёт **замечание** (не отказ: патч-версии формы не меняют, а нагоняй на каждый
+багфикс приучает пролистывать блок). Перепроверяет `docs.py openspec-form` — он
+спрашивает сам инструмент и печатает, что разошлось. **Чинится это в плагине, а
+не в проекте:** константы скрипта, скелет и запись в журнал версий канона.
+
+Шестого — «нет ли здесь пересказа» — машина не проверяет: отличить ссылку от
+пересказа она не умеет. Это работа `doc-consistency`, и раздел «Что проверяет
+машина, а что человек» называет её строкой.
+
+Форма — [skeletons.md](skeletons.md).
+
 ## Правило единственного дома
 
 Факт живёт ровно в одном файле; остальные ссылаются. Карта на случай спора:
@@ -387,6 +527,8 @@ kebab-case.** Причина не эстетическая: имя файла с
 | маркеры долга — числом | **протухший факт, разошедшийся с кодом** | `doc-code-drift` |
 | миграция изменена, а `database.md` нет | зависимость в манифесте, не названная в обзоре | `doc-code-drift` |
 | capability без упоминания в `architecture.md` | второй способ там, где обзор обещал единственный | `doc-code-drift` |
+| `openspec/config.yaml`: имя, `schema`, незаменённый пример, адреса паспорта и `CLAUDE.md`, ключи `rules` против артефактов схемы | **пересказ документа канона в `context` вместо ссылки** | `doc-consistency` |
+| версия OpenSpec разошлась с той, на которой сверена форма `config.yaml` | придирки валидатора: сменились ли они | никакой — проявляются отказом `openspec validate --strict` |
 | | связность и читаемость | `doc-wording` |
 
 **Агентов двое, и разведены они по глубине, а не по охвату.** `doc-consistency`
@@ -395,8 +537,8 @@ kebab-case.** Причина не эстетическая: имя файла с
 разрез, что между `task-form` и `doc-wording`.
 
 **Зовутся оба одинаково — раз в спринт на сессии, а также после `adopt` и после
-`upgrade`, на весь канон разом.** Не на синке документации: агент на `opus` по
-каждой сделанной задаче не окупается, а расхождение между двумя документами по
+`upgrade`, на весь канон разом.** Не на синке документации: `doc-consistency` на
+`opus` по каждой сделанной задаче не окупается, а расхождение между двумя документами по
 определению требует двух, и на большинстве задач синк правит один. Пачка,
 отбираемая работой, вдобавок не видит того, чего работа не касалась, — а именно
 там расхождение и живёт: правка отменяет решение в одном документе, парный статус
@@ -412,7 +554,7 @@ kebab-case.** Причина не эстетическая: имя файла с
 
 ```json
 {
-  "canon": 4,
+  "canon": 7,
   "migrations": "internal/store/migrations",
   "tasks": {
     "backlog": "INDEX.md"

av-dev-pm/skills/canon/references/changelog.md

@@ -13,6 +13,202 @@ upgrade` идёт по записям снизу вверх от версии п
 
 ---
 
+## Версия 7 — 2026-08-07
+
+`openspec/` был предпосылкой, о которой канон говорил, но за которой не следил.
+Каталог назван в раскладке, `openspec/specs/` объявлен домом темы `requirements`,
+`config.yaml` описан абзацем — а заводил всё это человек руками, и проверялось
+из перечисленного ничего. Заведение нового проекта проходило мимо: `init`
+собирал документы канона и оставлял проект без каталога, без которого не работают
+ни `opsx:propose`, ни ревью дизайна, ни сверка требований.
+
+Хуже отсутствия оказался файл из коробки. `openspec init` кладёт `config.yaml`,
+где `context` и `rules` — закомментированный пример на английском. Такой файл
+читается как настроенный: он есть, он валиден, имя правильное. Работает он как
+пустой, и узнаётся это по предложению, написанному на другом языке, с
+capability по имени пакета и без единого `SHALL`.
+
+**Что изменилось:**
+
+1. **`init` заводит OpenSpec сам** — `openspec init --tools claude`, до первого
+   документа канона. Команда названа в каноне поимённо, потому что её печатает
+   отказ `docs.py`.
+2. **У `openspec/config.yaml` появилась каноническая форма** и скелет в
+   `skeletons.md`. Содержание — только то, что нужно **в момент порождения
+   артефакта**: язык, правила именования capability, придирки валидатора и
+   **адреса** документов канона. Пересказ паспорта, инвариантов, конвенций и
+   правил ревью в него не переносится.
+3. **`docs.py check` проверяет пять вещей:** каталог `openspec/` есть; файл
+   называется `config.yaml` (`config.yml` OpenSpec читать не станет и об этом не
+   сообщит); `context` и `rules.specs` не остались примером, а правила для
+   `specs` называют `SHALL`; `context` называет `passport` и `CLAUDE.md`; ключи
+   под `rules:` — имена артефактов схемы, а не опечатки.
+4. **За свежестью формы следит машина, а не память.** Схема и перечень
+   артефактов — слепок чужого инструмента; `check` сравнивает `major.minor`
+   установленного OpenSpec с версией, на которой форма сверялась, и при
+   расхождении даёт замечание. Перепроверяет `docs.py openspec-form`, и чинится
+   расхождение **в плагине, а не в проекте**.
+5. **Шестое проверяет агент.** Отличить ссылку на документ от пересказа документа
+   машина не умеет — это работа `doc-consistency`, и в таблице «Что проверяет
+   машина, а что человек» она стоит строкой.
+
+**Что переехало:** ничего в раскладке `docs/`. Ни один файл не переименовывается
+и не перемещается.
+
+**Что сделать проекту:**
+
+1. Нет `openspec/` — завести: `openspec init --tools claude`. Команда кладёт ещё
+   и `.claude/skills/openspec-*` с `.claude/commands/opsx/*`; это её нормальная
+   работа, удалять их не надо.
+2. Открыть `openspec/config.yaml` и привести к скелету из
+   [skeletons.md](skeletons.md): блок `context` с языком, правилами именования
+   capability, требованием `SHALL` и **адресами** `docs/passport.md` и
+   `CLAUDE.md`; блок `rules` с четырьмя правилами для `specs`.
+3. **Вычистить из `context` пересказ.** Инварианты, перечень конвенций, состав
+   шагов гейта, правило выбора метки и состав проходов ревью — заменить ссылкой
+   на дом. Признак пересказа простой: строку можно опровергнуть, открыв другой
+   файл проекта.
+4. Проверить имя файла: `config.yml` переименовать в `config.yaml`. Если жили оба
+   — содержимое `.yml` до сих пор не читалось никем, и переносить из него нужно
+   именно то, чего нет в `.yaml`.
+5. `docs/.pm.json`: `"canon": 7`.
+
+---
+
+## Версия 6 — 2026-08-07
+
+Версия 5 объявила: **каждый документ `docs/` — тема ревью**. Правило оказалось
+верным ровно наполовину и потому вредным целиком. Паспорт и схему хранилища
+ревью читает, но темами они не являются — они задают границу, по которой судит
+чужая тема. Журнал решений и журнал наблюдений ревью изменения не нужны вовсе:
+ADR объясняет прошлое решение, а не предъявляет требование к изменению.
+
+Разметчик, применявший плоское правило буквально, обязан был либо завести
+фантомные темы `passport`, `adr`, `database`, `research` и продублировать ими
+работу тем `architecture` и `operations`, либо потерять четыре документа молча —
+а молчащая потеря и есть то, против чего канон написан.
+
+**Что изменилось:**
+
+1. **Три категории документов вместо одной.** Разрез проверяемый: можно ли по
+   документу сказать «в этом изменении сделано не так»? **Тема** — да, прямо
+   (`conventions`, `security`, `architecture`, свои документы проекта).
+   **Источник темы** — нет, но он задаёт границу для чужой темы (`passport.*` →
+   `architecture`, `database.*` → `operations`, `CLAUDE.md` → `autotests`,
+   `openspec/specs/` → `requirements`). **Процессный документ** — нет, он про то,
+   как мы работаем (`tasks/`, `review.*`, `adr.*`, `research.*`, `.pm.json`).
+2. **Категории `источник` и `процессный` закрыты, категория `тема` открыта.**
+   Прежде открытым был весь список, и «не темы ровно две» противоречило
+   собственной раскладке канона. Теперь пополняется только одно множество, и
+   документ, которого нет в раскладке, — однозначно своя тема проекта.
+3. **`adr/` и `research/` уходят из входа ревью изменения.** Прогон их больше не
+   открывает. Проверяться они не перестали: ADR без ссылки на архивный
+   `design.md`, замена без парного статуса, число без провенанса — это по-прежнему
+   работа `doc-consistency` и `doc-code-drift`, на сессии между спринтами.
+4. **`docs.py` печатает категорию в отказе.** «Нет источника passport» читается
+   иначе, чем «нет темы security». Обязательность при этом не изменилась:
+   заводятся все документы одинаково и с первого дня.
+5. **У задачи появилась метка — `small`, `medium` или `large`.** Это итог
+   классификации и **единственный вход, по которому конвейер выбирает
+   исполнителей** на обеих стадиях ревью. Прежние имена `quick`, `standard` и
+   `wide` описывали глубину прогона, то есть свойство ревью; метка описывает
+   **задачу** — а выбирают по ней одно и то же. Слово «ступень» уходит:
+   у одной вещи одно имя.
+6. **Метка выводится из двух осей и не равна ни одной из них.** Размер (малое,
+   среднее, крупное) и сложность (знакомое, незнакомое); метка — максимум по
+   ним. Малое **незнакомое** изменение получает `large`, трогая один узел, —
+   поэтому размер и метка пишутся отдельными строками, и выводить одно из
+   другого нельзя.
+
+**Цена, записанная явно:** расхождение изменения с записанным решением прогоном
+больше не ловится. Раньше архитектурный проход мог сказать «здесь отменено
+решение ADR-2026-03-11, парного статуса нет»; теперь это скажет только сверка
+документации. Сделка сознательная: чтение всего каталога решений оплачивалось на
+каждой задаче, а срабатывало на единицах.
+
+**Что переехало:** ничего в раскладке. Ни один файл не переименовывается и не
+перемещается.
+
+**Что сделать проекту:**
+
+1. `docs/review.*`, подраздел «Вопросы по темам»: убрать вопросы, адресованные
+   `passport`, `database`, `adr`, `research` и `review` — **ни одно из этих имён
+   больше не тема**. Под каноном 5 темой был каждый документ `docs/`, поэтому
+   такие вопросы там законны и почти наверняка есть. Переадресовать:
+   про границу домена и про решение → `architecture`; про хранилище, настройку и
+   измеренное число → `operations`. Вопрос, который никуда не переадресовывается,
+   удалить, а не оставить висеть: адресованный несуществующей теме, он не
+   задаётся никем и молча.
+2. Там же, «Недоступно проверке»: те же пять имён убрать из разнесения по темам,
+   переразнеся содержимое по оставшимся.
+3. Там же: подраздел **«Триггеры профиля» → «Триггеры метки»**, и разнести его
+   на **три** списка вместо двух — «крупное здесь» (про объём), «незнакомое
+   здесь» (про форму решения) и «мелкое здесь» (опускает до `small`). Раньше
+   первые две оси были склеены в один список, и потому объём в правило по факту
+   не входил.
+4. **Переименовать метки прогона везде, где проект их называет** — в «Триггерах
+   метки», в «Недоступно проверке», в журнале дефектов: `quick` → **`small`**,
+   `standard` → **`medium`**, `wide` → **`large`**. Метка это итог классификации
+   задачи, и три её значения — часть общего словаря канона и конвейера. Слово
+   «ступень» из документов уходит: у одной вещи одно имя.
+5. Проверить, что свои темы проекта не совпадают именем с закрытыми категориями:
+   `docs/passport/`, `docs/adr/`, `docs/research/`, `docs/database/`,
+   `docs/review/` — это слоты канона, а не свои темы, и своим смыслом их
+   наполнять нельзя.
+6. Ничего не заводить и не удалять: раскладка канона 6 совпадает с раскладкой
+   канона 5 файл в файл.
+7. `docs/.pm.json`: `"canon": 6`.
+
+---
+
+## Версия 5 — 2026-08-06
+
+Канон перестал быть списком файлов и стал **списком тем ревью**. Раскладка та же,
+но читается иначе: документ в `docs/` — это направление проверки, а не просто
+текст. Отсюда три правки, и все три развязывают то, что раньше было жёстко
+сцеплено.
+
+**Что изменилось:**
+
+1. **Тема живёт файлом или каталогом, на выбор проекта.** `docs/security.md` и
+   `docs/security/` — одно и то же; тема разрослась, стала каталогом с
+   `README.md` — канон не сменился и версия не двинулась. Прежде форма была
+   задана поимённо: `conventions`, `research` и `adr` обязаны были быть
+   каталогами, остальные — файлами, и обосновать это было нечем. Обе формы сразу
+   — ошибка: два дома для одного факта расходятся молча.
+2. **Список тем открытый.** Всё, что проект кладёт в `docs/`, становится темой
+   ревью и попадает в план каждого прогона; именной оптики у такой темы нет, её
+   разбирает общий проход конвейера, заведённый ровно за этим.
+   Прежде `docs.py` называл незнакомый файл «вне канона» — теперь называет своей
+   темой проекта и перечисляет их в отчёте. Не темы ровно две: `docs/tasks/` и
+   `docs/review.*`.
+3. **`AGENTS.md` рядом с `CLAUDE.md` — законно.** Он почти стандарт; обязателен
+   по-прежнему только `CLAUDE.md`, но если лежат оба, читаются оба, и проверки
+   канона смотрят на второй так же, как на первый.
+
+**Что переехало:**
+
+- в `docs/review.*`: **«Вопросы к проходам» → «Вопросы по темам»**, форма
+  `<тема>: <вопрос> (<провенанс>)`. Причина не косметическая: вопрос,
+  адресованный проходу, перестал задаваться молча в тот день, когда тот уехал в
+  верхнюю ступень ревью. Тема переезд прохода переживает, имя прохода — нет;
+- там же **«Недоступно проверке» — по темам**, оба подраздела.
+
+**Что сделать проекту:**
+
+1. Ничего не переименовывать, если всё уже разложено по канону 4: обе формы
+   дома законны, и текущая — одна из них.
+2. `docs/review.*`, подраздел «Вопросы к проходам»: переименовать в «Вопросы по
+   темам» и переадресовать каждый вопрос теме вместо имени прохода. Темы ядра —
+   `requirements`, `autotests`, `conventions`, `architecture`, `security`,
+   `operations`.
+3. Там же «Недоступно проверке»: разнести обе половины по темам.
+4. Проверить, не лежит ли в `docs/` документ, который раньше считался лишним и
+   потому не заводился. Теперь он законен и станет темой ревью — это и есть
+   способ добавить проверку, которой в конвейере нет.
+5. `docs/.pm.json`: `"canon": 5`.
+6. Позвать судей `doc-consistency` и `doc-code-drift` — шагом 6 `upgrade`.
+
 ## Версия 4 — 2026-08-05
 
 Две правки, обе про то, как читается каталог задач. Первая — секция роадмапа
@@ -127,9 +323,20 @@ upgrade` идёт по записям снизу вверх от версии п
    человека. **Переименование ADR это перенос ссылок**: слаг стоит в
    `adr/README.md`, в `architecture.md` и в чужих документах, и делается одним
    проходом, иначе останутся битые ссылки (их `docs.py` потом и покажет).
-8. `docs/.pm.json`: `"canon": 4`.
-9. Позвать **обоих судей** — `doc-consistency` и `doc-code-drift`, шагом 6
-   `upgrade`. Пунктов выше девять, половина из них ручная, и именно здесь видно,
+8. `docs/review.md`, подраздел «Триггеры профиля» — переписать целиком, он
+   отстал дважды. Снести перечень мест для `deep`: профиль упразднён вместе с
+   проходом независимой реализации, и перечень стал указателем в пустоту.
+   Оставшийся перечень перевести на новое правило: `wide` теперь означает не
+   «новое понятие», а **крупное или незнакомое** изменение и рассчитан на 5–10%
+   задач; отдельным списком назвать, что здесь считается **мелким** (это `quick`).
+   Форма подраздела — в [skeletons.md](skeletons.md). Там же проверить журнал
+   дефектов и «Недоступно проверке» на упоминания независимой реализации: класс
+   «форма решения, где спека выбора не сделала» переезжает в подраздел «перестали
+   проверять сознательно», а рядом с ним встаёт вторая честная строка — на
+   `quick` и `standard` не проверяется ничего, что требует запуска.
+9. `docs/.pm.json`: `"canon": 4`.
+10. Позвать **обоих судей** — `doc-consistency` и `doc-code-drift`, шагом 6
+    `upgrade`. Пунктов выше десять, половина из них ручная, и именно здесь видно,
     какие сделаны только наполовину: переименования секций и полей разводят
     документы, а `check` сверяет число версии, а не существо. Первый прогон на
     живом проекте вдобавок самый урожайный — правило единственного дома до сих пор

av-dev-pm/skills/canon/references/language.md

@@ -134,7 +134,7 @@
 | Термин | Что называет |
 | --- | --- |
 | интейк | заведение записи с фильтром и дедупом: «заведение» называет создание файла, слить их — смешать две операции |
-| триаж | ступень конвейера, сводящая находки в решение |
+| триаж | стадия конвейера, сводящая находки в решение |
 | провенанс | обязательное свойство числа: чем и при каких условиях получено. «Источник» рядом называет саму запись, а не свойство |
 | дедуп, дедупликация | сверка нового против уже лежащего |
 | чек-лист | перечень, по которому идут сверху вниз, называя исход каждой строки |

av-dev-pm/skills/canon/references/skeletons.md

@@ -46,7 +46,7 @@
 
 ## Что целью не является
 
-Граница домена. По ней архитектурный проход судит, не перенесено ли понятие
+Граница домена. По ней в теме `architecture` судят, не перенесено ли понятие
 через границу.
 
 ## Типовые сценарии
@@ -144,8 +144,8 @@
 
 ## Что вне модели
 
-Перечислить явно. Пустой пункт означает, что враждебный проход выдумает угрозу
-сам, и находка никогда не будет исправлена.
+Перечислить явно. Пустой пункт означает, что в теме `security` угрозу выдумают
+за тебя, и находка никогда не будет исправлена.
 ```
 
 ## `docs/conventions/README.md`
@@ -276,35 +276,63 @@
 Находки, которые здесь выглядят убедительно и всегда неверны. Каждая — с одной
 строкой «почему здесь это не дефект».
 
-### Вопросы к проходам
+### Вопросы по темам
 
-Форма: `<имя прохода>: <вопрос> (<провенанс>)`. Главный источник — журнал ниже.
-Проход, увидев свой блок, задаёт эти вопросы дополнительно к обязательным.
+Форма: `<тема>: <вопрос> (<провенанс>)`. Главный источник — журнал ниже. Вопрос
+задаёт тот проход, который закрывает эту тему на текущем прогоне, дополнительно
+к обязательным.
 
-### Триггеры профиля
+**Адресуй теме, а не имени прохода.** Проходы переезжают между метками и
+упраздняются; вопрос, адресованный проходу, перестанет задаваться в тот день,
+когда тот уедет в старшую метку, — и заметить это будет нечем. Тема переезд
+переживает.
 
-Проектная конкретизация правила выбора профиля: что здесь считается **новым
-понятием или структурной единицей** (поднимает прогон до `wide` и запускает
-архитектурный проход) и **где живут правила идентичности, слияния и разбора**
-(до `deep`, запускает независимую реализацию) — перечнем узлов или capability,
-поимённо. Уточняет умолчания конвейера, не отменяет их; рабочее умолчание —
-`standard`.
+Темы ядра: `requirements`, `autotests`, `conventions`, `architecture`,
+`security`, `operations`. Плюс любая своя — та, под которую проект завёл в
+`docs/` **свой** документ. Документы категорий `источник` и `процессный` тем не
+порождают, и адресовать вопрос `passport`, `database`, `adr`, `research` или
+`review` нельзя — таких тем нет. Вопрос про границу домена адресуй
+`architecture`, вопрос про хранилище и числа — `operations`.
 
-Перечень для `deep` **производен от теста конвейера**, а не заменяет его:
-правило попадает в класс, когда вариантов несколько, спека между ними не
-выбирает, а неверный выбор не падает, а молча меняет смысл данных. Перечисляй
-места, где этот класс здесь живёт, а не переписывай определение. Таких мест нет
-вовсе — так и напиши: `deep` тогда не запускается никогда, и это законное
-состояние.
+### Триггеры метки
+
+Проектная конкретизация правила выбора метки. **Списка три: по одному на
+каждую ось вверх и один вниз** — поимённо, узлами или capability.
+
+**Крупное здесь** — про объём: что трогает несколько узлов или слоёв, переносит
+ответственность между ними, перекладывает существующий код в новую форму.
+
+**Незнакомое здесь** — про форму решения: то, чего в проекте ещё не было и чью
+форму предстоит нащупать по ходу. Признак простой: перед работой нельзя назвать,
+какие узлы будут тронуты.
+
+Любая из двух осей поднимает прогон до `large`, старшей метки: там `security`,
+`operations` и `architecture` проверяют запуском, и там же единственные замеры.
+Метка рассчитана на **5–10% задач**; если сюда попадает каждая третья, списки
+написаны слишком широко.
+
+**Мелкое здесь** — опускает до `small`. Ориентир по доле — до трети задач, и в
+любом случае меньше, чем `medium`: перевес `small` значит, что рабочее умолчание
+сместилось само. Помни отрицательный тест конвейера: что
+после мерджа не откатывается обратной правкой (миграция, формат на диске,
+публичный контракт, имя), — не `small`, каким бы маленьким ни был дифф.
+
+Уточняет умолчания конвейера, не отменяет их; рабочее умолчание — `medium`.
 
 ### Недоступно проверке
 
+Оба подраздела — **по темам**: «в теме `operations` не проверяется X» читается,
+а «не проверяется X» через месяц не найдёт ни один проход.
+
 **Не проверит ни один проход** — принципиальная граница; по факту промаха не
 пересматривается.
 
 **Перестали проверять сознательно** — что, когда и почему, со ссылкой на запись
 журнала. Пересматривается **первым**, как только что-то проскочило.
 
+Тему, у которой в проекте нет дома, сюда писать не надо: её называет план
+каждого прогона, и это честнее разовой записи.
+
 ## Журнал дефектов
 
 Запись на каждый воспроизведённый дефект, сразу, а не ретроспективно: со
@@ -389,11 +417,91 @@ severity стоит здесь, а не выводится каждым прох
 тронуть рабочие данные, без третьего вся шкала ранжирования триажа держится на
 догадке.
 
+## `openspec/config.yaml`
+
+Каталог `openspec/` заводится командой — `openspec init --tools claude`, — и она
+кладёт `config.yaml` с закомментированным примером внутри. Пример **заменяется
+целиком**: нетронутый файл выглядит настроенным, а работает как пустой.
+
+**Это маршрутизатор, а не второй дом фактов.** Сюда пишут ровно то, что нужно
+**в момент порождения артефакта** и чего в этот момент ещё никто не открыл:
+язык, правила именования capability, придирки валидатора и **адреса** документов
+канона. Пересказ паспорта, инвариантов, конвенций и правил ревью сюда не
+переносится: расходится он молча, а замечают это в уже написанном предложении.
+
+```yaml
+schema: spec-driven
+
+context: |
+  Language: Russian
+  Пиши на русском, но:
+  - Структурные заголовки оставляй на английском:
+    ## ADDED/MODIFIED/REMOVED Requirements, ### Requirement:, #### Scenario:
+  - Ключевые слова GIVEN/WHEN/THEN и RFC 2119 (SHALL/MUST/SHOULD) — на английском
+  - Технические термины, пути и код — на английском
+
+  Имена capabilities:
+  - Capability — это ПОВЕДЕНИЕ или домен системы, а не пакет кода (совпадение с
+    именем пакета допустимо, но не критерий).
+  - Существительное, понятное без знания кода: ingest, parsing, storage,
+    read-api. НЕ store/httpapi — это реализация.
+  - Гранулярность по принципу «требования меняются вместе». Дробить, когда в
+    одной спеке смешиваются разные заботы. Переименовать дёшево (RENAMED
+    Requirements) — не дроби преждевременно в маленьком проекте.
+
+  RFC 2119 — требование валидатора, не стиль:
+  - Каждое ### Requirement ОБЯЗАНО содержать литерал SHALL или MUST, иначе
+    `openspec validate` падает. Поэтому эти слова и WHEN/THEN не русифицируем.
+
+  Что это за проект — читай перед предложением, а не отсюда:
+  - docs/passport.md — цель, её граница (чем проект НЕ является), потребители,
+    типовые сценарии, референсы;
+  - CLAUDE.md — инварианты с severity и семантика гейта;
+  - docs/architecture.md — устройство; docs/security.md — периметр;
+    docs/adr/ — почему решено так; docs/research/ — что уже измерено.
+  Пересказа этих документов здесь нет намеренно: второй дом факта расходится с
+  первым молча, и заметно это становится в предложении, которое уже написано.
+
+  Ревью: правило выбора метки и состав проходов здесь не пересказываем — их дом
+  скилл av-dev-pipeline:review-pipeline, проектная настройка — docs/review.md.
+
+  Конвенции кода: механизированное проверяет гейт, прозой остаётся
+  docs/conventions/. Ни состав шагов гейта, ни перечень конвенций здесь не
+  пересказываем: и то и другое растёт по ходу задач.
+
+  Развилка или блокер — сперва prior art. Готовые решения смотрим в референсах
+  паспорта, отвергаем — с названной причиной, и причина идёт в design.md этого
+  же изменения.
+
+rules:
+  proposal:
+    - Capabilities называй по поведению или домену системы, не по пакету кода
+  specs:
+    # Кавычки обязательны: без них YAML обрежет строку на первом '#'.
+    - "Каждое ### Requirement обязано содержать SHALL или MUST (иначе валидация падает)"
+    - "Сценарий — ровно #### (четыре решётки); три или список молча теряются"
+    - "SHALL/MUST должно стоять в ПЕРВОМ абзаце требования: валидатор смотрит только его"
+    - "Заголовки и WHEN/THEN/GIVEN — на английском, остальной текст на русском"
+```
+
+**Четыре правила для `specs` сняты отказами валидатора, а не выведены из
+документации** — потому и записаны дословно: без них каждое второе предложение
+узнаёт их падением `openspec validate --strict`. Блок `context` проект
+дополняет своим (стек, разведка, особенности домена), но **адреса паспорта и
+`CLAUDE.md` обязательны** — их отсутствие `docs.py check` называет отказом.
+
+**Ключи под `rules:` — имена артефактов схемы**, а не свободные слова:
+`proposal`, `specs`, `design`, `tasks`. Правило под чужим именем не применяется
+и об этом не сообщает, поэтому `rules.spec` вместо `rules.specs` даёт конфиг,
+выглядящий написанным и не работающий; `docs.py check` такой ключ называет.
+Перечень артефактов задаёт OpenSpec, а не канон, — за его актуальностью следит
+`docs.py openspec-form`.
+
 ## `docs/.pm.json`
 
 ```json
 {
-  "canon": 4
+  "canon": 7
 }
 ```
 

av-dev-pm/skills/canon/scripts/docs.py

@@ -25,54 +25,106 @@ from dataclasses import dataclass, field
 from pathlib import Path
 from typing import NoReturn
 
-CANON_VERSION = 4
+CANON_VERSION = 7
 
 OK, DRIFT, USAGE, ENV, INTERNAL = 0, 1, 2, 3, 4
 
 # --- Раскладка канона -------------------------------------------------------
 
-# Обязательные файлы: путь → на какой вопрос отвечает (для внятного отказа).
+# Документ канона: имя → (категория, на какой вопрос отвечает).
+#
+# Категории — из canon.md, раздел «Три категории документов». Разрез один: можно
+# ли по документу сказать «в этом изменении сделано не так»?
+#   тема       — да, прямо: документ заводит направление проверки изменения;
+#   источник   — нет, но он задаёт границу, по которой судит чужая тема;
+#   процессный — нет: он про то, как мы работаем, а не про изменение.
+#
+# **Категория не меняет обязательности документа** — заводятся все три
+# одинаково и с первого дня. Она меняет только то, что с документом делает
+# конвейер ревью, и потому печатается в отказе: «нет источника passport»
+# читается иначе, чем «нет темы security», и чинится теми же руками, но с
+# другим приоритетом.
+#
+# **Документ живёт файлом `docs/<имя>.md` либо каталогом `docs/<имя>/` с
+# README.md внутри.** Форму выбирает проект: документ разросся — стал каталогом,
+# и это не смена канона и не повод править скрипт. Обе формы сразу — ошибка: это
+# два дома для одного факта, ровно то, от чего канон и защищает.
+DOCS = {
+    "passport": ("источник", "зачем и для кого, чем НЕ является"),
+    "architecture": ("тема", "как сложено — обзор, окружение, эксплуатация"),
+    "security": ("тема", "периметр, недоверенный вход, что вне модели"),
+    "conventions": ("тема", "как мы пишем код; индекс, промоут, что механизировано"),
+    "research": ("процессный", "что показала реальность: наблюдения и числа"),
+    "adr": ("процессный", "почему решено так; индекс, статусы, правило замены"),
+    "review": ("процессный", "настройка конвейера + журнал дефектов"),
+}
+
+# Документ, обязательный только при условии: имя → (ключ .pm.json, категория,
+# пояснение).
+CONDITIONAL_DOCS = {
+    "database": ("migrations", "источник", "схема хранилища и настройки"),
+}
+
+# Обязательные файлы вне раскладки docs/.
 REQUIRED = {
     "CLAUDE.md": "памятка агенту: инварианты с severity, команды, семантика гейта",
     "docs/.pm.json": "версия канона и пути, нужные проверкам",
-    "docs/passport.md": "зачем и для кого, чем НЕ является",
-    "docs/architecture.md": "как сложено — обзор, окружение, эксплуатация",
-    "docs/security.md": "периметр, недоверенный вход, что вне модели",
-    "docs/review.md": "настройка конвейера + журнал дефектов",
-    "docs/conventions/README.md": "индекс конвенций, правило промоута, что механизировано",
-    "docs/research/README.md": "как снималось, индекс наблюдений",
-    "docs/adr/README.md": "индекс записей, статусы, правило замены",
-    "docs/adr/template.md": "шаблон записи ADR",
 }
 
-# Обязателен только при условии: путь → (ключ .pm.json, пояснение).
-CONDITIONAL = {
-    "docs/database.md": ("migrations", "схема хранилища и настройки"),
+# Файлы, которые документ-каталог обязан держать сверх README.md.
+DOC_EXTRA = {
+    "adr": {"template.md": "шаблон записи ADR"},
 }
 
-# Что вообще разрешено лежать в docs/ верхним уровнем.
-ALLOWED_FILES = {
-    ".pm.json",
-    "passport.md",
-    "architecture.md",
-    "database.md",
-    "security.md",
-    "review.md",
-}
-ALLOWED_DIRS = {"conventions", "research", "adr", "tasks"}
+# Настройка OpenSpec. Команда заведения — она же в скилле init; здесь потому,
+# что её печатает отказ, а отказ без команды заставляет искать её в другом месте.
+OPENSPEC_INIT = "openspec init --tools claude"
 
-# Слоты, которых в каноне нет, — с адресом, куда уезжает содержимое.
+# Адреса, которые обязан назвать блок context. Не пересказ документов, а именно
+# ссылки: предложение пишется до того, как кто-либо откроет docs/, и без этих
+# двух строк его пишут, не зная ни границы домена, ни инвариантов. Список
+# короткий намеренно — длинный превращает context во второй дом фактов.
+OPENSPEC_POINTERS = [
+    ("passport", "граница домена и «чем НЕ является» останутся непрочитанными"),
+    ("CLAUDE.md", "инварианты и семантика гейта останутся непрочитанными"),
+]
+
+# --- Форма config.yaml сверена с живым OpenSpec ------------------------------
+#
+# Три константы ниже — **слепок чужого инструмента**, а не наше решение. Схема,
+# перечень артефактов и версия, на которой это проверено, живут в OpenSpec и
+# меняются без нашего участия; здесь они записаны, чтобы проверка шла без запуска
+# node на каждом прогоне.
+#
+# Слепок стареет, и потому есть кто, кто это замечает: `check` сравнивает
+# major.minor установленного OpenSpec с OPENSPEC_CHECKED и, если они разошлись,
+# говорит замечанием «форма не перепроверена». Перепроверяет `docs.py
+# openspec-form` — он спрашивает сам инструмент и печатает, что разошлось.
+# Патч-версия сравнением намеренно не берётся: форма конфига в ней не меняется, а
+# замечание на каждый багфикс приучило бы пролистывать весь блок.
+OPENSPEC_CHECKED = "1.5"
+OPENSPEC_SCHEMA = "spec-driven"
+
+# Артефакты схемы. Ключ `rules:` адресуется артефакту, и адресованный
+# несуществующему **молча не действует** — ровно тот класс, ради которого вся
+# проверка и заведена.
+OPENSPEC_ARTIFACTS = ("proposal", "specs", "design", "tasks")
+
+# Служебное в docs/ и каталог, который ведёт tasks.py. Оба процессные, но
+# проверок формы у них нет: .pm.json не markdown, tasks/ ведёт другой скрипт.
+NOT_DOCS = {".pm.json", "tasks"}
+
+# Слоты, которых в каноне нет, — с адресом, куда уезжает содержимое. Имена,
+# совпадающие с темой, отсюда убраны намеренно: `docs/conventions.md` и
+# `docs/review/` теперь законные формы своих тем.
 RETIRED = {
-    "review-brief.md": "документы канона и есть бриф; остаток — в review.md",
-    "review-journal.md": "→ docs/review.md",
+    "review-brief.md": "документы канона и есть бриф; остаток — в review",
+    "review-journal.md": "→ документ review",
     "plan.md": "→ docs/tasks/ROADMAP.md",
-    "conventions.md": "→ docs/conventions/",
-    "local-research.md": "→ docs/research/",
-    "research.md": "→ docs/research/",
-    "specs": "поведение → openspec/specs/, обзор → docs/architecture.md",
+    "local-research.md": "→ документ research",
+    "specs": "поведение → openspec/specs/, обзор → тема architecture",
     "drafts": "идея → запись research, отказ → ADR, порядок → ROADMAP.md",
     "backlog": "→ docs/tasks/",
-    "review": "→ docs/review.md",
 }
 
 # --- Слаги в именах файлов --------------------------------------------------
@@ -118,11 +170,13 @@ def check_slugs(root: Path, rep: Report) -> None:
     if not docs.is_dir():
         return
     # Имена, выбранные каноном, а не проектом: их форма задана здесь же.
-    fixed = {"README.md", "template.md"} | ALLOWED_FILES
-    for sub in ("conventions", "research", "adr"):
-        folder = docs / sub
-        if not folder.is_dir():
+    fixed = {"README.md", "template.md"} | {f"{name}.md" for name in DOCS}
+    # Все документы-каталоги, включая свои темы проекта: правило имён общее, а
+    # перечислять их поимённо значило бы закрыть открытый список.
+    for folder in sorted(docs.iterdir()):
+        if not folder.is_dir() or folder.name in NOT_DOCS:
             continue
+        sub = folder.name
         for path in sorted(folder.rglob("*.md")):
             name = path.name
             rel = path.relative_to(root)
@@ -261,32 +315,107 @@ def check_version(root: Path, cfg: dict, rep: Report) -> None:
         )
 
 
+def doc_home(root: Path, name: str) -> tuple[Path | None, str | None]:
+    """Дом документа: файл `docs/<имя>.md` или каталог `docs/<имя>/`.
+
+    Возвращает путь и жалобу. Обе формы сразу — это два дома для одного факта, и
+    расходятся они молча: правят одну, читают другую.
+    """
+    docs = root / "docs"
+    as_file = docs / f"{name}.md"
+    as_dir = docs / name
+    if as_file.is_file() and as_dir.is_dir():
+        return as_file, (
+            f"{name} живёт сразу двумя домами — docs/{name}.md и docs/{name}/:"
+            f" оставить один, иначе правят один, а читают другой"
+        )
+    if as_file.is_file():
+        return as_file, None
+    if as_dir.is_dir():
+        if not (as_dir / "README.md").is_file():
+            return as_dir, (
+                f"docs/{name}/ без README.md — у документа-каталога вход"
+                f" обязателен: по нему его читают агенты"
+            )
+        return as_dir, None
+    return None, None
+
+
 def check_required(root: Path, cfg: dict, rep: Report) -> None:
     for rel, what in REQUIRED.items():
         if not (root / rel).exists():
             rep.error(f"нет {rel} — {what}")
-    for rel, (key, what) in CONDITIONAL.items():
-        if key in cfg and not (root / rel).exists():
-            rep.error(f"нет {rel} — {what} (обязателен: в .pm.json объявлен {key})")
-        elif key not in cfg and not (root / rel).exists():
-            rep.skip(f"{rel} — в .pm.json нет ключа {key}, проверка неприменима")
+
+    for name, (kind, what) in DOCS.items():
+        home, complaint = doc_home(root, name)
+        if home is None:
+            rep.error(
+                f"нет документа {name} (docs/{name}.md или docs/{name}/),"
+                f" категория «{kind}» — {what}"
+            )
+            continue
+        if complaint:
+            rep.error(complaint)
+        if home.is_dir():
+            for extra, why in DOC_EXTRA.get(name, {}).items():
+                if not (home / extra).is_file():
+                    rep.error(f"нет docs/{name}/{extra} — {why}")
+
+    for name, (key, kind, what) in CONDITIONAL_DOCS.items():
+        home, complaint = doc_home(root, name)
+        if complaint:
+            rep.error(complaint)
+        if key in cfg and home is None:
+            rep.error(
+                f"нет документа {name} (docs/{name}.md или docs/{name}/),"
+                f" категория «{kind}» — {what}"
+                f" (обязателен: в .pm.json объявлен {key})"
+            )
+        elif key not in cfg and home is None:
+            rep.skip(f"{name} — в .pm.json нет ключа {key}, проверка неприменима")
 
 
 def check_stray(root: Path, rep: Report) -> None:
+    """Лишнего в docs/ больше нет — есть свои темы проекта.
+
+    Категории `источник` и `процессный` **закрыты**: они перечислены в каноне
+    поимённо и проектом не пополняются. Открыта только категория `тема` —
+    поэтому любой документ в docs/, которого нет в раскладке, и есть заявка на
+    свою тему, и запретить её нельзя. Проверяются только слоты, у которых дом в
+    другом месте, — иначе переехавшее содержимое вернулось бы темой и выглядело
+    законным.
+    """
     docs = root / "docs"
     if not docs.is_dir():
         rep.error("нет каталога docs/")
         return
+    known = set(DOCS) | set(CONDITIONAL_DOCS)
+    own: list[str] = []
     for entry in sorted(docs.iterdir()):
         name = entry.name
         if name in RETIRED:
             rep.error(f"docs/{name} — слота нет в каноне: {RETIRED[name]}")
             continue
-        if entry.is_dir():
-            if name not in ALLOWED_DIRS:
-                rep.error(f"docs/{name}/ — каталог вне канона")
-        elif name not in ALLOWED_FILES:
-            rep.error(f"docs/{name} — файл вне канона")
+        if name in NOT_DOCS:
+            continue
+        topic = name[:-3] if entry.is_file() and name.endswith(".md") else name
+        if topic in known:
+            continue
+        if entry.is_file() and not name.endswith(".md"):
+            rep.error(f"docs/{name} — не markdown: тема ревью читается как текст")
+            continue
+        if entry.is_dir() and not (entry / "README.md").is_file():
+            rep.error(
+                f"docs/{name}/ без README.md — у темы-каталога вход обязателен:"
+                f" по нему её читают агенты"
+            )
+            continue
+        own.append(topic)
+    if own:
+        rep.note(
+            f"свои темы проекта: {', '.join(own)} — именной оптики у них нет,"
+            f" их разбирает общий проход конвейера"
+        )
 
 
 def canon_docs(root: Path) -> list[Path]:
@@ -302,9 +431,13 @@ def canon_docs(root: Path) -> list[Path]:
             if head in skip or head in RETIRED:
                 continue
             out.append(path)
-    claude = root / "CLAUDE.md"
-    if claude.exists():
-        out.append(claude)
+    # AGENTS.md лежит рядом с CLAUDE.md и читается теми же агентами: он почти
+    # стандарт, и проект вправе держать оба. Обязателен по-прежнему только
+    # первый.
+    for name in ("CLAUDE.md", "AGENTS.md"):
+        path = root / name
+        if path.exists():
+            out.append(path)
     return out
 
 
@@ -339,19 +472,182 @@ def check_placeholders_and_debt(root: Path, rep: Report) -> None:
             rep.debt(f"{rel}: {what}")
 
 
+def doc_text(root: Path, name: str) -> str | None:
+    """Текст документа целиком: файл или все markdown каталога, склеенные.
+
+    Проверке всё равно, одним файлом написан документ или десятью: она ищет
+    упоминание, а упоминание живёт в любом из них.
+    """
+    home, _ = doc_home(root, name)
+    if home is None:
+        return None
+    if home.is_file():
+        return home.read_text(encoding="utf-8", errors="replace")
+    return "\n".join(
+        path.read_text(encoding="utf-8", errors="replace")
+        for path in sorted(home.rglob("*.md"))
+    )
+
+
+def rules_keys(live: str) -> list[str]:
+    """Имена артефактов, которым адресованы правила, — и только они.
+
+    Идём от строки `rules:` до следующего ключа нулевой колонки, а не ищем
+    отступ по всему файлу: блок `context: |` — литеральный скаляр, внутри него
+    строки вида «Language: Russian» и «av-dev-pm:review-pipeline» выглядят
+    ключами и дали бы находку на ровном месте. Проверено на живом конфиге,
+    который так и падал.
+    """
+    out: list[str] = []
+    inside = False
+    for line in live.splitlines():
+        if not line.strip():
+            continue
+        if not line[0].isspace():
+            inside = line.startswith("rules:")
+            continue
+        if not inside:
+            continue
+        m = re.fullmatch(r"  ([A-Za-z_-]+):\s*", line)
+        if m:
+            out.append(m.group(1))
+    return out
+
+
+def check_openspec(root: Path, rep: Report) -> None:
+    """Настройка OpenSpec заведена и не осталась примером из коробки.
+
+    Разбираем текстом, а не YAML-парсером: у скриптов канона ноль внешних
+    зависимостей, а PyYAML в стандартной библиотеке нет. Всё, что проверяется
+    ниже, различимо построчно, и ложных срабатываний это не даёт: комментарии
+    отброшены, ключи верхнего уровня стоят в первой колонке.
+    """
+    os_dir = root / "openspec"
+    if not os_dir.is_dir():
+        rep.error(
+            "нет openspec/ — там дом темы requirements (openspec/specs/) и "
+            f"настройка генерации артефактов; заводится `{OPENSPEC_INIT}`"
+        )
+        return
+
+    if (os_dir / "config.yml").is_file():
+        rep.error(
+            "openspec/config.yml — читается только config.yaml, и этот файл "
+            "останется незамеченным: настройка будет пустой, а выглядеть будет "
+            "заполненной"
+        )
+
+    path = os_dir / "config.yaml"
+    if not path.is_file():
+        rep.error(
+            "нет openspec/config.yaml — язык, правила именования capability и "
+            "придирки валидатора будут заново угадываться на каждом предложении"
+        )
+        return
+
+    text = path.read_text(encoding="utf-8")
+    live = "\n".join(
+        line for line in text.splitlines() if not line.lstrip().startswith("#")
+    )
+    keys = set(re.findall(r"(?m)^([A-Za-z_]+):", live))
+
+    schema = re.search(r"(?m)^schema:\s*(\S+)", live)
+    if schema is None:
+        rep.error(
+            f"в openspec/config.yaml нет ключа schema — ожидается {OPENSPEC_SCHEMA}"
+        )
+    elif schema.group(1) != OPENSPEC_SCHEMA:
+        rep.error(
+            f"schema в openspec/config.yaml — {schema.group(1)}, а канон описан "
+            f"для {OPENSPEC_SCHEMA}"
+        )
+
+    if "context" not in keys:
+        rep.error(
+            "в openspec/config.yaml нет ключа context: файл остался примером из "
+            "коробки — предложение пишется без языка, правил именования "
+            "capability и адресов документов проекта"
+        )
+    else:
+        for pointer, why in OPENSPEC_POINTERS:
+            if pointer not in live:
+                rep.error(
+                    f"openspec/config.yaml не называет {pointer} — {why}"
+                )
+
+    if "rules" not in keys or "specs:" not in live:
+        rep.error(
+            "в openspec/config.yaml нет rules.specs — придирки валидатора "
+            "нигде не записаны, и каждое предложение узнаёт их отказом"
+        )
+    elif "SHALL" not in live:
+        rep.error(
+            "rules.specs в openspec/config.yaml не называет SHALL — "
+            "требование без этого литерала валидатор отвергает, а правило "
+            "проекта об этом молчит"
+        )
+
+    # Ключ под rules: — имя артефакта схемы. Опечатка или устаревшее имя не
+    # ломает ничего видимого: правила просто не применяются, а конфиг выглядит
+    # написанным.
+    for name in rules_keys(live):
+        if name not in OPENSPEC_ARTIFACTS:
+            rep.error(
+                f"rules.{name} в openspec/config.yaml — такого артефакта у схемы "
+                f"{OPENSPEC_SCHEMA} нет ({', '.join(OPENSPEC_ARTIFACTS)}): правила "
+                f"под ним не применяются и молчат об этом"
+            )
+
+    check_openspec_fresh(rep)
+
+
+def openspec_cli(args: list[str]) -> str | None:
+    """Спросить сам инструмент. None — его нет или он не ответил."""
+    try:
+        out = subprocess.run(
+            ["openspec", *args], capture_output=True, text=True, timeout=30
+        )
+    except (FileNotFoundError, OSError, subprocess.SubprocessError):
+        return None
+    return out.stdout.strip() if out.returncode == 0 else None
+
+
+def check_openspec_fresh(rep: Report) -> None:
+    """Не устарел ли наш слепок формы config.yaml.
+
+    Стоит один запуск `openspec --version` — десятые доли секунды. Перечень
+    артефактов и имя схемы отсюда не спрашиваются намеренно: они стоят втрое
+    дороже, а меняются только вместе с версией, и потому за ними ходит отдельная
+    команда `openspec-form`, а эта проверка говорит, когда её звать.
+    """
+    got = openspec_cli(["--version"])
+    if got is None:
+        rep.skip(
+            "openspec не отвечает (нет на PATH?) — актуальность формы "
+            "config.yaml не проверялась"
+        )
+        return
+    installed = ".".join(got.split(".")[:2])
+    if installed != OPENSPEC_CHECKED:
+        rep.note(
+            f"форма openspec/config.yaml сверена с OpenSpec {OPENSPEC_CHECKED}, "
+            f"установлен {got}: перепроверить — `docs.py openspec-form`. Пока не "
+            f"перепроверено, проверки формы судят по прежней схеме"
+        )
+
+
 def check_capabilities(root: Path, rep: Report) -> None:
     specs = root / "openspec" / "specs"
-    arch = root / "docs" / "architecture.md"
+    text = doc_text(root, "architecture")
     if not specs.is_dir():
         rep.skip("openspec/specs/ нет — сверка capability с архитектурой неприменима")
         return
-    if not arch.exists():
+    if text is None:
         rep.skip(
-            "docs/architecture.md нет — capability не сверены с обзором "
-            "(об отсутствии файла сказано отдельной строкой)"
+            "темы architecture нет — capability не сверены с обзором "
+            "(об отсутствии сказано отдельной строкой)"
         )
         return
-    text = arch.read_text(encoding="utf-8", errors="replace")
     for d in sorted(specs.iterdir()):
         if not d.is_dir():
             continue
@@ -365,14 +661,14 @@ def check_capabilities(root: Path, rep: Report) -> None:
             continue
         if loose:
             rep.note(
-                f"capability {name}: в docs/architecture.md есть слово «{name}», но "
+                f"capability {name}: в теме architecture есть слово «{name}», но "
                 f"нет ни ссылки на openspec/specs/{name}, ни имени в обратных "
                 f"кавычках — проверь, это про capability или про пакет"
             )
         else:
             rep.error(
                 f"capability {name} есть в openspec/specs/, но не упомянута в "
-                f"docs/architecture.md — обзор отстал от нормативных спек"
+                f"теме architecture — обзор отстал от нормативных спек"
             )
 
 
@@ -416,9 +712,12 @@ def check_migrations(root: Path, cfg: dict, base: str | None, rep: Report) -> No
     touched = [f for f in changed if f.startswith(migrations.rstrip("/") + "/")]
     if not touched:
         return
-    if "docs/database.md" not in changed:
+    # Тема database бывает файлом и каталогом — правкой считается любой её файл.
+    if not any(
+        f == "docs/database.md" or f.startswith("docs/database/") for f in changed
+    ):
         rep.error(
-            f"миграции изменены ({len(touched)} файлов), а docs/database.md — нет: "
+            f"миграции изменены ({len(touched)} файлов), а тема database — нет: "
             f"схема в документации отстала"
         )
 
@@ -470,10 +769,12 @@ def report(rep: Report) -> int:
             print(f"  {msg}")
 
     print(
-        "\nМашина проверила раскладку, имена файлов, ссылки, версию и две сверки\n"
-        "с кодом. Согласованность документов между собой и с кодом она не\n"
-        "проверяет — это суждение агентов `doc-consistency` (документ ↔ документ\n"
-        "↔ openspec) и `doc-code-drift` (документ ↔ код)."
+        "\nМашина проверила раскладку, имена файлов, ссылки, версию, форму\n"
+        "openspec/config.yaml и две сверки с кодом. Согласованность документов\n"
+        "между собой и с кодом она не проверяет — как и то, ссылается ли\n"
+        "config.yaml на документы или пересказывает их. Это суждение агентов\n"
+        "`doc-consistency` (документ ↔ документ ↔ openspec) и `doc-code-drift`\n"
+        "(документ ↔ код)."
     )
     if rep.errors:
         print(f"\nИтог: дрейф, {len(rep.errors)} пунктов.")
@@ -497,6 +798,7 @@ def cmd_check(args: argparse.Namespace) -> int:
     check_slugs(root, rep)
     check_links(root, rep)
     check_placeholders_and_debt(root, rep)
+    check_openspec(root, rep)
     check_capabilities(root, rep)
     check_migrations(root, cfg, args.base, rep)
     check_tasks(root, rep)
@@ -512,6 +814,71 @@ def cmd_version(args: argparse.Namespace) -> int:
     return OK
 
 
+def cmd_openspec_form(args: argparse.Namespace) -> int:
+    """Перепроверить слепок формы config.yaml по живому OpenSpec.
+
+    Ничего не правит и не трогает проект: спрашивает инструмент и печатает, что
+    разошлось с константами скрипта. Чинит человек — правкой констант, скелета в
+    skeletons.md и записью в журнал версий канона, если форма действительно
+    поменялась.
+    """
+    version = openspec_cli(["--version"])
+    if version is None:
+        fail(
+            ENV,
+            "openspec не отвечает: поставь его или проверь PATH — "
+            "перепроверять форму нечем",
+        )
+    raw = openspec_cli(["templates", "--json"])
+    if raw is None:
+        fail(ENV, "`openspec templates --json` не отработал — схему не спросить")
+    try:
+        artifacts = tuple(json.loads(raw))
+    except json.JSONDecodeError as exc:
+        fail(ENV, f"`openspec templates --json` отдал неразбираемое: {exc}")
+
+    print(f"OpenSpec установлен: {version}")
+    print(f"форма сверена с:     {OPENSPEC_CHECKED}")
+    print(f"артефакты схемы:     {', '.join(artifacts)}")
+    print(f"записано в скрипте:  {', '.join(OPENSPEC_ARTIFACTS)}")
+
+    diffs: list[str] = []
+    if ".".join(version.split(".")[:2]) != OPENSPEC_CHECKED:
+        diffs.append(
+            f"версия: поднять OPENSPEC_CHECKED до "
+            f"{'.'.join(version.split('.')[:2])} — но только после того, как "
+            f"остальные строки этого отчёта сойдутся"
+        )
+    for name in artifacts:
+        if name not in OPENSPEC_ARTIFACTS:
+            diffs.append(
+                f"новый артефакт {name}: решить, нужны ли ему правила в rules, "
+                f"и добавить имя в OPENSPEC_ARTIFACTS"
+            )
+    for name in OPENSPEC_ARTIFACTS:
+        if name not in artifacts:
+            diffs.append(
+                f"артефакта {name} у схемы больше нет: правила под ним в конфигах "
+                f"проектов молчат — убрать из OPENSPEC_ARTIFACTS, из скелета и "
+                f"записать в журнал версий канона"
+            )
+
+    print()
+    if not diffs:
+        print("Слепок сходится. Осталось глазами: не изменились ли придирки")
+        print("валидатора — их скрипт проверить не может, они проявляются только")
+        print("отказом `openspec validate --strict` на живой спеке.")
+        return OK
+    print("Разошлось:")
+    for line in diffs:
+        print(f"  - {line}")
+    print()
+    print("Правится в трёх местах сразу: константы этого скрипта, скелет")
+    print("`openspec/config.yaml` в skeletons.md и запись в changelog.md —")
+    print("иначе проекты останутся на прежней форме молча.")
+    return DRIFT
+
+
 def main() -> int:
     parser = argparse.ArgumentParser(
         prog="docs.py",
@@ -528,6 +895,12 @@ def main() -> int:
     p_ver.add_argument("--dir", default=".", help="корень проекта")
     p_ver.set_defaults(func=cmd_version)
 
+    p_form = sub.add_parser(
+        "openspec-form",
+        help="перепроверить форму config.yaml по живому OpenSpec",
+    )
+    p_form.set_defaults(func=cmd_openspec_form)
+
     args = parser.parse_args()
     try:
         return args.func(args)

av-dev-pm/skills/docs/SKILL.md

@@ -64,8 +64,9 @@ description: Вести содержимое документов канона
 
 **Но синк его не зовёт.** Оба судьи документов — `doc-consistency` и
 `doc-code-drift` — зовутся раз в спринт, шагом сессии, на весь канон разом.
-Причина в цене: агент на `opus` по каждой сделанной задаче — самая дорогая
-церемония процесса. К тому же расхождение между двумя документами по определению
+Причина в цене: `doc-consistency` на `opus` по каждой сделанной задаче — самая
+дорогая церемония процесса, а `doc-code-drift` хоть и на `sonnet`, но читает
+репозиторий целиком. К тому же расхождение между двумя документами по определению
 требует двух документов, а на большинстве задач синк правит один.
 
 Что теряется: привязка находки к задаче, которая её породила. Что выигрывается,
@@ -129,7 +130,7 @@ description: Вести содержимое документов канона
 Твоя часть на синке: **дефект пишется сразу**, а не «потом, когда починим».
 Со временем теряется не факт, а то, почему дефект не поймали, — единственное,
 ради чего журнал есть. И решение сузить проверки (перестали звать проход, понизили
-профиль) обязано попасть в раздел настройки, а не остаться в отчёте ревью.
+метка) обязано попасть в раздел настройки, а не остаться в отчёте ревью.
 
 ## Промоут в конвенции
 

av-dev-pm/skills/init/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: init
-description: "Завести новый проект — сессия вопросов и ответов по свободному описанию замысла, из которой рождается первичная документация по канону av-dev: паспорт, CLAUDE.md с инвариантами и командами, модель угроз с периметром, первые цели в роадмапе и скелет остальных документов. Использовать, когда начинают новый проект с нуля, когда есть только текст «что мне нужно и почему» и надо превратить его в рабочую документацию, когда просят провести стартовое интервью по брифу. Проект, где документация уже как-то ведётся, переводит скилл canon."
+description: "Завести новый проект — сессия вопросов и ответов по свободному описанию замысла, из которой рождается первичная документация по канону av-dev: паспорт, CLAUDE.md с инвариантами и командами, модель угроз с периметром, первые цели в роадмапе и скелет остальных документов. Заводит и OpenSpec (openspec init) с настроенным openspec/config.yaml — дом темы requirements, без которого не работают ни propose, ни ревью. Использовать, когда начинают новый проект с нуля, когда есть только текст «что мне нужно и почему» и надо превратить его в рабочую документацию, когда просят провести стартовое интервью по брифу. Проект, где документация уже как-то ведётся, переводит скилл canon."
 ---
 
 # Заведение нового проекта
@@ -28,6 +28,7 @@ description: "Завести новый проект — сессия вопро
 | `security.md` | `conventions/` |
 | `docs/tasks/ROADMAP.md` — первые цели | `research/`, `adr/` |
 | `docs/.pm.json` | `review.md` — журнал пуст, настройка появится с первым ревью |
+| `openspec/config.yaml` | |
 
 Честная строка информативна, а не «TBD»: «архитектуры пока нет: кода нет,
 заводится первой задачей». Проход читает её как факт.
@@ -39,7 +40,7 @@ description: "Завести новый проект — сессия вопро
 1. **Цель и потребители.** Ради чего это; кто пользуется — список закрытый, и
    он определяет, что считать нужным, а что интересным.
 2. **Чем это НЕ является и мера успеха.** Граница домена — критерий, по
-   которому архитектурный проход потом судит о переносе понятия. Мера — по чему
+   которому потом судят в теме `architecture` о переносе понятия. Мера — по чему
    поймём, что удалось.
 3. **Периметр и недоверенный вход.** Открыт наружу или контур доверенный; что
    приходит извне и каким каналом; что чувствительнее чего. Контур ещё не
@@ -68,17 +69,29 @@ description: "Завести новый проект — сессия вопро
 
 1. Прочитай бриф целиком. Выпиши, на какие блоки интервью ответ уже есть.
 2. Проведи интервью итерациями по ≤3 вопроса.
-3. Заведи `docs/.pm.json` с текущей версией канона.
-4. Напиши заполняемые документы. **Бриф переезжает в `passport.md`** и
+3. **Заведи OpenSpec: `openspec init --tools claude`.** Каталог `openspec/` —
+   часть канона, а не соседняя технология: в нём дом темы `requirements`, и без
+   него не работают ни `opsx:propose`, ни ревью дизайна, ни сверка требований.
+   Команда кладёт ещё `.claude/skills/openspec-*` и `.claude/commands/opsx/*` —
+   это её нормальная работа, не трогай их.
+4. Заведи `docs/.pm.json` с текущей версией канона.
+5. Напиши заполняемые документы. **Бриф переезжает в `passport.md`** и
    отдельным файлом не остаётся: два дома для одного замысла разойдутся на
    первом же уточнении.
-5. Заведи скелет остальных по [скелетам](../canon/references/skeletons.md) —
+6. Заведи скелет остальных по [скелетам](../canon/references/skeletons.md) —
    каждый с честной строкой.
-6. Каталог задач и первые цели — **вызови скилл `av-dev-pm:tasks`**: он владеет
+7. **Заполни `openspec/config.yaml`** по тем же скелетам. Файл из коробки —
+   закомментированный пример на английском; он **заменяется целиком**, потому что
+   нетронутый выглядит настроенным, а работает как пустой. Пиши туда только то,
+   что нужно **в момент порождения артефакта**: язык, правила именования
+   capability, придирки валидатора и **адреса** `docs/passport.md` и `CLAUDE.md`.
+   Инварианты, конвенции и правило ревью не пересказывай — у них есть дома, и
+   второй дом разойдётся с первым молча.
+8. Каталог задач и первые цели — **вызови скилл `av-dev-pm:tasks`**: он владеет
    форматом целей и задач.
-7. `docs.py check` из скилла `canon` — до отсутствия дрейфа. Замечания о
+9. `docs.py check` из скилла `canon` — до отсутствия дрейфа. Замечания о
    незаполненных плейсхолдерах остаются: их закрывает не `init`, а работа.
-8. Покажи человеку, что получилось, и **отдельным списком** — что выведено из
+10. Покажи человеку, что получилось, и **отдельным списком** — что выведено из
     брифа, что предположено, что осталось неизвестным. Правят по этим строкам.
 
 ## Что дальше

av-dev-pm/skills/session/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: session
-description: "Ритуал между спринтами и ведение самого спринта: разбор накопившихся вопросов, разбор прошедшего спринта про процесс, переоценка задач порциями, выбор цели и набор нового спринта с заморозкой. Плюс правила по ходу спринта — что врывается в замороженный набор, чем вопрос отличается от блокера, когда задача выходит из спринта, что считается сделанным и что идёт в доклад. Использовать, когда просят закрыть или начать спринт, собрать набор, разобрать вопросы, провести груминг/переоценку/ретроспективу, решить «что делать дальше» или доложить итоги, а также когда вернулись к проекту после перерыва и надо понять, где остановились. Формат и содержимое задач — скилл tasks."
+description: "Ритуал между спринтами и ведение самого спринта: разбор накопившихся вопросов, разбор прошедшего спринта про процесс, переоценка задач порциями, выбор цели (или решение, что спринт без цели) и набор нового спринта с заморозкой. Плюс правила по ходу спринта — что врывается в замороженный набор, чем вопрос отличается от блокера, когда задача выходит из спринта, что считается сделанным и что идёт в доклад. Использовать, когда просят закрыть или начать спринт, собрать набор, разобрать вопросы, провести груминг/переоценку/ретроспективу, решить «что делать дальше» или доложить итоги, а также когда вернулись к проекту после перерыва и надо понять, где остановились. Формат и содержимое задач — скилл tasks."
 ---
 
 # Сессия между спринтами
 
-Работа идёт спринтами: **набор задач под одну цель, замороженный до конца
-спринта**. Между спринтами — одна сессия из четырёх шагов. Этот скилл владеет
+Работа идёт спринтами: **набор задач, замороженный до конца спринта** — обычно
+под одну цель, но бывает и без неё. Между спринтами — одна сессия из четырёх шагов. Этот скилл владеет
 **ритуалом**: как сессия проводится и как спринт ведётся. Форматом и содержимым
 задач владеет скилл `tasks`, выполнением задачи — пайплайн проекта.
 
@@ -28,8 +28,8 @@ description: "Ритуал между спринтами и ведение са
 
 ## Роли
 
-**Человек** выбирает цель спринта, разбирает вопросы, держит право на
-необратимое и на истину в самих данных.
+**Человек** выбирает цель спринта — **или решает, что этот спринт без цели**, —
+разбирает вопросы, держит право на необратимое и на истину в самих данных.
 
 **Агент — оркестрация.** Он собирает набор под названную цель, ставит задачи,
 принимает отчёты и докладывает. Кто именно делает задачу — исполнитель, сабагент,
@@ -47,7 +47,10 @@ description: "Ритуал между спринтами и ведение са
   `question`.
 - **Блокер** — состояние, когда спринт не может продолжаться **ни одной**
   задачей.
-- **Спринт** — набор задач под одну цель, замороженный до его конца.
+- **Спринт** — набор задач, замороженный до его конца. Под одной целью — или
+  **без цели вовсе**, законно: багфикс, техдолг, спринт здоровья. Такой набор
+  собран по работоспособности, а не по направлению, и заводится явно
+  (`sprint start --no-goal`).
 
 ## Вопрос, блокер, необратимое
 
@@ -88,9 +91,17 @@ description: "Ритуал между спринтами и ведение са
 
 ## Заморозка набора
 
-**Цель одна.** Набор служит ей; задача, не служащая цели, в спринт не попадает,
-даже если взять удобно (`sprint take` это и запрещает). **Задача с открытым
-вопросом в набор не берётся.**
+**Целей не больше одной.** Названа цель — набор служит ей: задача под чужой
+целью в спринт не попадает, даже если взять удобно (`sprint take` это и
+запрещает). **Задача с открытым вопросом в набор не берётся** — это верно всегда.
+
+**Спринт без цели — законный случай, а не недосмотр.** Багфикс, техдолг,
+здоровье: работа на работоспособность, а не на направление. Цель не названа —
+сверять нечего, и в такой набор идёт что угодно готовое к взятию, в том числе
+задачи под разными целями. Заводится он **явно**, `sprint start --no-goal`:
+забытый флаг и решение человека иначе неотличимы, а это решение продуктовое.
+Взамен проверки цели остаётся доклад — спринт без цели **называется таковым и
+объясняется** одной строкой.
 
 **Новая работа падает в беклог, а не в идущий спринт.** Решение «врываться или
 отложить» принимается один раз правилом, а не заново каждый раз. Врывается
@@ -122,8 +133,8 @@ description: "Ритуал между спринтами и ведение са
    судьи документов канона на весь канон разом, раз в спринт: `doc-consistency`
    (документы между собой) и `doc-code-drift` (документы против кода).
 3. **Переоценка задач** порциями.
-4. **Выбор цели и набор спринта.** Цель называет человек, набор собирает агент и
-   показывает **до старта работ**.
+4. **Выбор цели и набор спринта.** Цель называет человек — либо называет, что
+   этот спринт без цели; набор собирает агент и показывает **до старта работ**.
 
 Рёбра подписаны тем, что ломается при их нарушении:
 
@@ -155,7 +166,7 @@ flowchart TD
 
 1. `tasks.py check` — блок здоровья скажет состояние спринта, число готовых к
    взятию и залежавшихся; при расхождении раскладки `--fix`.
-2. Прочитать `SPRINT.md`: цель, состав, дата начала.
+2. Прочитать `SPRINT.md`: цель (или запись, что её нет), состав, дата начала.
 3. **Развилка, и решает её человек.** Набор всё ещё твой — продолжай спринт, ни
    сессии, ни переоценки не нужно, они между спринтами. Взялся перечитывать,
    зачем эти задачи собраны вместе, — набор протух:
@@ -183,6 +194,7 @@ python3 $tk list --dir D --tag sprint:<слаг>    # шаг 3: урожай с
 python3 $tk list --dir D --stale                # шаг 3: дальше по залежалости
 python3 $tk list --dir D --goal <слаг>          # шаг 4: кандидаты под названную цель
 python3 $tk sprint start --dir D --goal <слаг>  # шаг 4: заводит и слаг спринта
+python3 $tk sprint start --dir D --no-goal      # шаг 4: набор без цели, явным флагом
 python3 $tk sprint take --dir D <слаг> …        # шаг 4: набор
 python3 $tk sprint close --dir D                # конец спринта; --dissolve при блокере
 python3 $tk reopen <слаг> --dir D --reason …    # приёмка не сошлась после закрытия
@@ -239,6 +251,11 @@ python3 $tk reopen <слаг> --dir D --reason …    # приёмка не со
 - **Сжать задачу до остатка** и отчитаться «сделана». Защита ослаблена там же.
   Пол для остатка — польза, названная в «зачем»; проверяет его человек при приёмке,
   и `reopen` — его инструмент.
+- **Объявить спринт без цели**, чтобы не задавать человеку продуктовый вопрос:
+  набор без цели берёт что угодно, и собрать его можно молча. Защита: цели нет
+  — это **ответ человека, а не умолчание** (`--no-goal` спрашивается так же, как
+  цель), плюс строка доклада, называющая спринт бесцельным и объясняющая почему.
+  Два бесцельных спринта подряд — предмет разбора процесса, а не мелочь.
 - **Занизить урожай** — не заводить найденное по ходу. Защита: поимённая сверка
   с **сохранённым независимым отчётом**, а не с прозой исполнителя. Каждая
   отложенная находка имеет либо слаг, либо строку «не заведена: причина».

av-dev-pm/skills/session/references/cadence.md

@@ -66,8 +66,11 @@
   ветки, команды, пути, внешние зависимости поимённо, настройки с числовым
   значением, единые точки проекта, capability.
 
-Раз в спринт, а не чаще, и причина в цене: оба на `opus`, а второй ещё и читает
-репозиторий. Но и не реже — **спринт это ровно то, что двигает код и документы**:
+Раз в спринт, а не чаще. Дорог из них по-настоящему первый — `doc-consistency`
+на `opus`: он сличает утверждения двух документов, и это суждение. Второй с
+недавних пор на `sonnet` — у него закрытый перечень фактов и команда на каждый, —
+но он читает репозиторий целиком, и дешёвым от смены модели не стал. Но и не
+реже — **спринт это ровно то, что двигает код и документы**:
 переименованная цель сборки, ушедшая зависимость, второй способ делать то, что
 обзор объявил единственным; факт, дописанный в `architecture.md`, уже живущий в
 `CLAUDE.md`. Протухшее и раздвоившееся неотличимо от свежего, и по нему принимают
@@ -222,23 +225,32 @@
    по каждой цели-кандидату — сколько под ней задач без открытых вопросов
    (`list --goal <слаг>`). Цель без готовых задач набором не станет: её сперва
    надо декомпозировать.
-2. **Цель называет человек.** Это продуктовое решение, а не механика: агент
-   предлагает и объясняет, но не выбирает.
-3. **Набор собирает агент** — `sprint start --goal <слаг>`, затем `sprint take
-   …`. Скрипт не даст взять цель, задачу с чужой целью, с открытым вопросом, без
-   типа и **без разделов, которых требует её тип** (у `fix` это в том числе
-   `Воспроизведение`, у `research` — `Вопрос` и `Куда ляжет ответ`, и сырьё
-   поэтому не берётся вовсе). Задача без цели (`fix`, `chore`, `research`)
-   берётся свободно — операционная работа входит в набор помимо его цели.
+2. **Цель называет человек** — либо называет, что цели не будет. Это
+   продуктовое решение, а не механика: агент предлагает и объясняет, но не
+   выбирает. **Оба ответа законны**, и «без цели» — такой же ответ, как слаг:
+   спринт бывает под багфикс, под техдолг, под здоровье проекта. Спрашивается он
+   так же, как цель, и в отдельный вопрос не выносится: это один и тот же вопрос
+   «подо что набираем».
+3. **Набор собирает агент** — `sprint start --goal <слаг>` (или `sprint start
+   --no-goal`), затем `sprint take …`. Скрипт не даст взять цель, задачу с чужой
+   целью, с открытым вопросом, без типа и **без разделов, которых требует её
+   тип** (у `fix` это в том числе `Воспроизведение`, у `research` — `Вопрос` и
+   `Куда ляжет ответ`, и сырьё поэтому не берётся вовсе). Задача без цели (`fix`,
+   `chore`, `research`) берётся свободно — операционная работа входит в набор
+   помимо его цели. **В спринте без цели чужой цели нет вовсе**: сверять не с
+   чем, берётся что угодно готовое, и единственной защитой остаётся показ набора
+   человеку.
 4. **Набор показывается человеку до старта работ.** Показ — это и есть момент
    заморозки: после него набор не двигается. **В показе называется состав по
    типам** — три `fix` и ни одной `feature` под целью развития это разговор про
    цель, а не про набор, и увидеть его надо до заморозки, а не в докладе по
-   итогам.
+   итогам. **У набора без цели показ — единственная проверка состава**: скрипту
+   там отказывать не по чему, и «что угодно готовое» превращается в осмысленный
+   набор только глазами человека.
 
    Здесь же последний дешёвый момент заметить **разнородную задачу**: раздел
    «Затрагивает» показывает границы до того, как заведено предложение об
-   изменении. Строка, которая одна тянет задачу на ступень выше остального
+   изменении. Строка, которая одна тянет задачу на метку выше остального
    перечня, — кандидат на разрез (шов — в `tasks`, `references/split.md`).
    Замеченная здесь, она стоит одного `edit`; замеченная на ревью — выброшенного
    предложения.
@@ -258,7 +270,8 @@
   названного, что разошлось.
 - Изменения списком: удалено как реализованное (со ссылками), ушло без
   реализации (с причинами), понижено до сырья, слито, сменило тип или цель.
-- Новый спринт: цель, набор со слагами, дата, состав по типам.
+- Новый спринт: цель — **или строка «без цели» с объяснением, почему** (багфикс,
+  техдолг, здоровье), — набор со слагами, дата, состав по типам.
 - **Границы покрытия**: сколько задач не трогали и какие именно секции, теги или
   цели остались — иначе доклад читается как «беклог разобран».
 - `tasks.py check` после правок — результат строкой.

av-dev-pm/skills/session/references/sprint.md

@@ -1,7 +1,8 @@
 # Ведение спринта
 
-Спринт — набор задач под одну цель, замороженный до его конца. Здесь то, что
-происходит **внутри** спринта: как задача заканчивается, что считается сделанным,
+Спринт — набор задач, замороженный до его конца: под одну цель или **без цели**
+(багфикс, техдолг, здоровье — это законно, `sprint start --no-goal`). Здесь то,
+что происходит **внутри** спринта: как задача заканчивается, что считается сделанным,
 кто принимает и что идёт в доклад. Как спринт набирается — шаг 4 в
 [cadence.md](cadence.md).
 
@@ -21,7 +22,7 @@
 - **Оказалась крупнее задачи** — распознаётся **до того, как под неё заведено
   предложение об изменении**, иначе его придётся выбрасывать. Выходит из набора,
   уходит на декомпозицию; спринт продолжается остальными, части заводятся под той
-  же целью и в замороженный набор не добавляются.
+  же целью (у спринта без цели — без неё) и в замороженный набор не добавляются.
 - **Отменена решением по ходу** — `close <slug> --reason "<ссылка на решение>"`
   прямо из спринта. Это редкий, но законный исход, и он называется в докладе.
 
@@ -170,9 +171,9 @@ flowchart TD
 
 Только два класса — правило и его обоснование в SKILL.md. Здесь механика:
 
-- вторжение **не добавляет** задачу в набор: `SPRINT.md` остаётся набором под
-  цель. Внеплановая работа делается и называется в докладе отдельной строкой
-  «внеплановое: что и почему»;
+- вторжение **не добавляет** задачу в набор: `SPRINT.md` остаётся тем набором,
+  который заморозили и показали. Внеплановая работа делается и называется в
+  докладе отдельной строкой «внеплановое: что и почему»;
 - если внеплановое требует больше пары часов, честнее распустить спринт, чем
   делать вид, что набор соблюдается;
 - всё остальное падает в беклог через обычный интейк и ждёт сессии.
@@ -181,8 +182,10 @@ flowchart TD
 
 Проверяемые якоря, а не пересказ:
 
-- **Цель спринта** и по каждой задаче набора: **хеш коммита**, дословный исход
-  проверок проекта, **исход по каждому критерию приёмки**.
+- **Цель спринта** — или строка «спринт без цели» с тем, чем он был (багфикс,
+  техдолг, здоровье): у бесцельного набора это единственное место, где состав
+  вообще объясняется. И по каждой задаче набора: **хеш коммита**, дословный
+  исход проверок проекта, **исход по каждому критерию приёмки**.
 - **Какие развилки решались** и чем обоснованы.
 - **Урожай:** сколько задач заведено, какие вопросы накопились, что вышло из
   спринта и почему, что было внеплановым.

av-dev-pm/skills/tasks/SKILL.md

@@ -69,7 +69,7 @@ docs/tasks/
   items/            задачи и цели файлами, <slug>.md, слаги английские
   ROADMAP.md        состояние проекта: что уже умеет и чего ещё не умеет
   BACKLOG.md        что можно взять — только задачи, целей здесь нет
-  SPRINT.md         текущий спринт: цель, набор, дата
+  SPRINT.md         текущий спринт: цель (или её отсутствие), набор, дата
   REJECTED.md       ушедшее БЕЗ реализации, с причиной и датой
 ```
 
@@ -207,7 +207,7 @@ stateDiagram-v2
 
 **Сопровождение и эксплуатация — целое и часть**, а не синонимы, и та же тема
 живёт ещё в двух местах канона: разделе «Эксплуатация» в `architecture.md` и
-эксплуатационном проходе ревью. Словарь у всех трёх общий и живёт одним домом —
+теме ревью `operations`. Словарь у всех трёх общий и живёт одним домом —
 [canon.md](../canon/references/canon.md), раздел «Сопровождение и эксплуатация».
 Пересказывать его здесь нельзя: три перечня «чем держат проект» уже разъезжались
 на «метриках и логах» против «мониторинга».
@@ -279,7 +279,7 @@ stateDiagram-v2
 **напоминает** — беклог, заведённый до появления типа, законен, и переоформлять
 его «заодно» здесь не просят.
 
-**Тип не выбирает профиль ревью и вообще ничего не предписывает пайплайну.**
+**Тип не выбирает метку ревью и вообще ничего не предписывает пайплайну.**
 Профиль выбирается по факту изменения, а не по типу задачи: `chore` бывает
 миграцией схемы, `fix` — правкой публичного контракта. Правило «предписание
 процесса в теле задачи снимается» типом не отменяется, а подтверждается: он
@@ -369,7 +369,7 @@ python3 $tk move S --dir D --section S [--reason R] [--after S | --first]
 python3 $tk close S --dir D --reason R      # в REJECTED.md + удалить (ушла без реализации)
 python3 $tk close S --dir D --implemented   # просто удалить (реализована и закоммичена)
 python3 $tk reopen S --dir D --reason R     # вернуть закрытую: приёмка не сошлась
-python3 $tk sprint start --goal S --dir D | take S… | drop S… --reason R | close [--dissolve --reason R]
+python3 $tk sprint start (--goal S | --no-goal) --dir D | take S… | drop S… --reason R | close [--dissolve --reason R]
 python3 $tk init --dir D [--sections …] [--items …] [--backlog …] …
 python3 $tk adopt scan --from … | apply --plan …   # разовая адаптация, references/adopt.md
 ```
@@ -523,8 +523,8 @@ python3 $tk adopt scan --from … | apply --plan …   # разовая адап
 **каждая давать видимую пользу**, а у штурма исход «выкинуть» — полноправный.
 
 Там же **шов**: где резать, когда допустимых мест несколько. Коротко — по
-границе, которая одна поднимает ступень ревью выше остальных; и не резать, когда
-обе половины остаются в одной ступени, потому что несокращаемый костяк проверок
+границе, которая одна поднимает метку ревью выше остальных; и не резать, когда
+обе половины остаются в одной метке, потому что несокращаемый костяк проверок
 платится за каждую задачу отдельно.
 
 ### Вычитка: два прохода, а не один
@@ -541,7 +541,13 @@ python3 $tk adopt scan --from … | apply --plan …   # разовая адап
 Разделены они не по охвату, а **по глубине**. Язык проверяется по словам и
 фразам, поштучно; форма записи требует понять, что задача делает, и открыть
 цель, на которую она ссылается. Слитый проход одну половину делает дорогой, а
-вторую — поверхностной. Отсюда и разные модели.
+вторую — поверхностной.
+
+Модель у обоих одна, `sonnet`, и это не отменяет разреза. Оба судят по
+**записанному правилу** — семь пунктов формы против правил языка, — а их находка
+приходит готовой формулировкой, которую читает и отклоняет человек, а не молча
+реализует оркестратор. Ошибка здесь стоит строки чтения, и платить за неё верхней
+моделью не за что.
 
 Каждый устав отказывается от чужой половины прямо: увиденное не по своей части
 идёт **строкой в границах покрытия**, а не находкой. Две проверки одного места
@@ -583,7 +589,7 @@ python3 $tk adopt scan --from … | apply --plan …   # разовая адап
 - **свойство репозитория в рамках** — номер миграции, хеш, версия зависимости:
   в лежалой задаче протухает молча и становится ложной рамкой. Снимается;
   снимок берётся при постановке, а не при заведении;
-- **предписание процесса в теле** — «делать таким-то профилем ревью», «взять
+- **предписание процесса в теле** — «делать с такой-то меткой ревью», «взять
   такой-то агент»: это второй дом для правила выбора и путь понизить требования
   решением, принятым до проектирования. Снимается;
 - **тип, разошедшийся с задачей** — задача заводилась починкой, а после разбора

av-dev-pm/skills/tasks/references/split.md

@@ -25,24 +25,25 @@
 Тест выше говорит, **допустим** ли разрез. Где его провести из нескольких
 допустимых мест — отвечает шов.
 
-**Шов — там, где падает ступень ревью.** Раздел «Затрагивает» перечисляет
-границы; если одна строка перечня поднимает ступень выше остальных, эта часть и
-режется отдельно. Пример: задача вводит новый пакет и заодно добавляет два поля в
-существующий ответ. Целиком это `wide` — семь проходов по всему диффу. Разрезанная
-по шву, она даёт `wide` на маленьком новом пакете и `standard` на остатке.
+**Шов — там, где падает метка ревью.** Раздел «Затрагивает» перечисляет
+границы; если одна строка перечня поднимает метку выше остальных, эта часть и
+режется отдельно. Пример: задача перекладывает несколько узлов разом и заодно
+добавляет два поля в существующий ответ. Целиком это `large` — семь проходов по
+всему диффу, включая два, что держат машину и идут цепочкой. Разрезанная по шву,
+она даёт `large` на маленькой переложенной части и `medium` на остатке.
 
 **Считай костяк, а не файлы.** У каждой задачи есть несокращаемые четыре прохода
 (гейт, спеки, код, триаж), и они платятся за каждую. Разрез, после которого обе
-половины остаются в одной ступени, делает ревью **дороже**: тот же объём
+половины остаются в одной метке, делает ревью **дороже**: тот же объём
 проверяется тем же составом, но костяк оплачен дважды. Отсюда правило: **резать,
 когда разрез снимает дорогой проход с большей части диффа**, и не резать, когда
 он просто делает файлы мельче.
 
-**Это планирование, а не предписание процесса.** Ступень ревью выбирается по
+**Это планирование, а не предписание процесса.** Метка ревью выбирается по
 факту изменения — тем, кто его видит, — и в тело задачи не пишется: строка
-«делать профилем standard» это ровно тот второй дом правила выбора, который
-гигиена полей снимает. Шов пользуется ступенью как **признаком**, что в задаче
-две разнородные работы; решение о профиле остаётся за конвейером.
+«делать с меткой medium» это ровно тот второй дом правила выбора, который
+гигиена полей снимает. Шов пользуется меткой как **признаком**, что в задаче
+две разнородные работы; решение о метке остаётся за конвейером.
 
 **Цель наследуется.** Все части несут `goal:` родителя: декомпозиция не меняет
 того, чему работа служит. Если у части цель другая — это признак, что дробили не

av-dev-pm/skills/tasks/references/task-format.md

@@ -278,12 +278,16 @@
 | --- | --- | --- |
 | `ROADMAP.md` | что приложение уже умеет и чего ещё не умеет | канонические и в этом порядке: `Запланировано`, `Направления`, `Сопровождение`, `Готово` (англ. `Planned`, `Directions`, `Operations`, `Done`) |
 | `BACKLOG.md` | что **можно взять** — только задачи | категории проекта (по умолчанию Ядро/Инфра) |
-| `SPRINT.md` | какая цель и какой набор под неё | одна: «Набор» |
+| `SPRINT.md` | какая цель (или что её нет) и какой набор заморожен | одна: «Набор» |
 | `REJECTED.md` | что ушло без реализации и почему | — |
 
 Шапку `SPRINT.md` пишет `sprint start` — **тем же мета-блоком, что у задачи**:
 поле на строку, `- **Цель:** [Заголовок](items/slug.md)`, `- **Начат:**` датой,
-`- **Спринт:**` слагом, которым метится урожай. Прежняя форма (три поля одной
+`- **Спринт:**` слагом, которым метится урожай. У спринта без цели
+(`sprint start --no-goal`) поле «Цель» остаётся на месте и пишется прозой без
+ссылки — «не названа»: **«цели нет» и «цель потерялась» обязаны различаться**.
+Поэтому и признак «спринт идёт» — слаг, а не цель: слаг есть у любого спринта,
+без него нечем метить урожай. Прежняя форма (три поля одной
 строкой через `·`) читается по-прежнему и уходит сама: файл переписывается на
 следующем `sprint start` и очищается на `sprint close`.
 

av-dev-pm/skills/tasks/scripts/tasks.py

@@ -3,8 +3,8 @@
 
 Преемник backlog.py. Разница по существу одна: **порядка нет, есть цель**.
 Приоритеты и секция-как-уровень заменены на цель (`goal:<слаг>` тегом) и на
-спринт — замороженный набор задач под одну цель. Индексов теперь четыре, и
-задача живёт ровно в одном из них за раз.
+спринт — замороженный набор задач, обычно под одну цель. Индексов теперь
+четыре, и задача живёт ровно в одном из них за раз.
 
 Раскладка. Путь каталога — `docs/tasks`, жёстко: это часть канона документов
 av-dev, и подгоняется под него проект. Имена внутри настраиваются через
@@ -17,7 +17,7 @@ av-dev, и подгоняется под него проект. Имена вн
                     Направления | Сопровождение | Готово (или Planned |
                     Directions | Operations | Done — один язык на индекс)
       BACKLOG.md    что можно взять — только задачи, целей здесь нет
-      SPRINT.md     текущий спринт: цель, набор, дата, слаг
+      SPRINT.md     текущий спринт: цель (или её отсутствие), набор, дата, слаг
       REJECTED.md   ушедшее БЕЗ реализации, с причиной и датой
 
 Источник истины — файл задачи в items/. Индексы производны: расходятся —
@@ -68,7 +68,7 @@ goal | feature | fix | chore | research, по-английски, как и пр
   tasks.py move S --section S [--reason R] [--after S | --first] [--dir DIR]
   tasks.py close S (--reason R | --implemented) [--dir DIR]
   tasks.py reopen S [--reason R] [--dir DIR]
-  tasks.py sprint start --goal S [--date ГГГГ-ММ-ДД] [--slug S] [--dir DIR]
+  tasks.py sprint start (--goal S | --no-goal) [--date ГГГГ-ММ-ДД] [--slug S] [--dir DIR]
   tasks.py sprint take S [S …] [--dir DIR]
   tasks.py sprint drop S [S …] --reason R [--dir DIR]
   tasks.py sprint close [--dissolve --reason R] [--dir DIR]
@@ -996,7 +996,11 @@ def questions_open(lay: Layout, task: dict) -> bool:
 # --- Спринт ---
 
 def sprint_goal(lay: Layout) -> tuple[str, str]:
-    """Слаг и заголовок цели текущего спринта; ('', '') — спринта нет."""
+    """Слаг и заголовок цели текущего спринта; ('', '') — цели нет.
+
+    Пустой ответ значит «цель не названа», а НЕ «спринта нет»: спринт бывает
+    без цели законно (`--no-goal`). Идёт ли спринт — отвечает `sprint_started`.
+    """
     for line in read_lines(lay.index("sprint")):
         if (m := GOAL_LINE.match(line.strip())):
             return Path(m.group(2)).stem, m.group(1)
@@ -1011,6 +1015,16 @@ def sprint_slug(lay: Layout) -> str:
     return ""
 
 
+def sprint_started(lay: Layout) -> bool:
+    """Идёт ли спринт. Признак — слаг, а не цель: цели может не быть.
+
+    Слаг пишет `sprint start` и стирает `sprint close`, он есть у любого
+    спринта — без него не проставить `sprint:<слаг>`, то есть не собрать
+    урожай. Поэтому он и есть наблюдаемое «спринт открыт».
+    """
+    return bool(sprint_slug(lay))
+
+
 def sprint_header(lay: Layout, goal_slug: str, goal_title: str,
                   date: str, slug: str) -> list[str]:
     """Шапка спринта — мета-блок той же формы, что у задачи: поле на строку.
@@ -1019,10 +1033,15 @@ def sprint_header(lay: Layout, goal_slug: str, goal_title: str,
     — обе регулярки её берут, — но чинить её нечем и не нужно: `SPRINT.md`
     переписывается целиком на `sprint start` и очищается на `sprint close`,
     так что старая шапка живёт не дольше идущего спринта.
+
+    Спринт без цели пишет ту же строку прозой, без ссылки: поле остаётся на
+    месте, читатель видит решение, а `GOAL_LINE` его не берёт — «цель не
+    названа» и «цель потерялась» этим и различаются.
     """
-    link = f"{lay.cfg['items']}/{goal_slug}.md"
+    goal_line = (f"- **Цель:** [{goal_title}]({lay.cfg['items']}/{goal_slug}.md)"
+                 if goal_slug else "- **Цель:** не названа — набор без цели")
     return ["# Спринт", "",
-            f"- **Цель:** [{goal_title}]({link})",
+            goal_line,
             f"- **Начат:** {date}",
             f"- **Спринт:** `{slug}`", "",
             f"Урожай спринта поднимается `tasks.py list --tag {SPRINT_TAG}{slug}`"
@@ -1032,7 +1051,9 @@ def sprint_header(lay: Layout, goal_slug: str, goal_title: str,
 def empty_sprint(lay: Layout) -> str:
     return ("# Спринт\n\n"
             "Спринта нет. Цель называет человек, набор собирает агент:\n"
-            "`tasks.py sprint start --goal <слаг>`.\n\n"
+            "`tasks.py sprint start --goal <слаг>`. Набор без цели —"
+            " `sprint start --no-goal`\n(багфикс, техдолг, здоровье:"
+            " работа на работоспособность, а не на направление).\n\n"
             f"## {lay.cfg['sprint_section']}\n")
 
 
@@ -1215,6 +1236,8 @@ def check(lay: Layout, fix: bool = False) -> int:
             if task["type"] and task["type"] not in TAKEABLE:
                 errors.append(f"{name}: в спринте тип «{task['type']}»"
                               f" — цель не берут вовсе, её берут её задачи")
+            # Спринт без цели ничьей цели и не противоречит: проверять нечему,
+            # набор там собран по другому признаку (работоспособность).
             if goal_of_sprint and task["goal"] and task["goal"] != goal_of_sprint:
                 errors.append(f"{name}: цель задачи «{task['goal']}» не цель спринта"
                               f" «{goal_of_sprint}» — набор служит одной цели")
@@ -1267,11 +1290,18 @@ def check(lay: Layout, fix: bool = False) -> int:
     if goal_of_sprint and goal_of_sprint + ".md" not in tasks:
         errors.append(f"{label['sprint']}: цель «{goal_of_sprint}» не найдена"
                       f" в {lay.cfg['items']}/")
-    if not goal_of_sprint and entries["sprint"]:
-        errors.append(f"{label['sprint']}: набор есть, а цель не названа")
-    if goal_of_sprint and not sprint_slug(lay):
-        errors.append(f"{label['sprint']}: у спринта нет слага (- **Спринт:** `…`) —"
-                      f" урожай не отобрать; перезапусти `sprint start`")
+    # Спринт без цели законен (`sprint start --no-goal`), и по цели о том, идёт
+    # ли он, судить нельзя. Судим по слагу: он есть у любого спринта, потому
+    # что без него не проставить `sprint:<слаг>` и не собрать урожай.
+    if entries["sprint"] and not sprint_started(lay):
+        errors.append(f"{label['sprint']}: набор есть, а шапки спринта нет"
+                      f" (- **Спринт:** `…`) — урожай не отобрать, а «спринт идёт»"
+                      f" не отличить от «строки остались от прошлого»;"
+                      f" перезапусти `sprint start`")
+    elif goal_of_sprint and not sprint_started(lay):
+        errors.append(f"{label['sprint']}: цель названа, а слага спринта нет"
+                      f" (- **Спринт:** `…`) — урожай не отобрать;"
+                      f" перезапусти `sprint start`")
 
     rejected = lay.index("rejected")
     if rejected.is_file():
@@ -1338,8 +1368,9 @@ def health(lay: Layout, tasks: dict, entries: dict, sections: dict) -> None:
                       " ответа на вопрос"))
 
     goal_slug, _ = sprint_goal(lay)
-    if goal_slug:
-        print(f"  спринт: цель «{goal_slug}», слаг «{sprint_slug(lay) or '—'}»,"
+    if sprint_started(lay):
+        goal_part = f"цель «{goal_slug}»" if goal_slug else "без цели"
+        print(f"  спринт: {goal_part}, слаг «{sprint_slug(lay)}»,"
               f" задач {len(entries['sprint'])}")
     else:
         print("  спринт: не начат")
@@ -2140,7 +2171,11 @@ def cmd_reopen(lay: Layout, a: argparse.Namespace) -> int:
     goal_of_sprint, _ = sprint_goal(lay)
     target = home_index({"type": rtype})
     section = tmp["section"]
-    if target == "backlog" and goal_of_sprint and tmp["goal"] == goal_of_sprint:
+    # Возврат идёт в набор идущего спринта — тем же тестом, что и `sprint take`:
+    # мешает только чужая цель. Спринт без цели не мешает ничем, и задача без
+    # цели не мешает спринту с целью. Спринта нет — возврат в беклог.
+    fits_sprint = not (goal_of_sprint and tmp["goal"] and tmp["goal"] != goal_of_sprint)
+    if target == "backlog" and sprint_started(lay) and fits_sprint:
         target, section = "sprint", lay.cfg["sprint_section"]
     lines = read_lines(lay.index(target))
     # Строка достигнутого снимается ДО вставки и на том же списке: иначе вторая
@@ -2210,12 +2245,21 @@ def meta_updated_text(text: str, reason: str, rtype: str | None = None) -> str |
 # --- Спринт ---
 
 def cmd_sprint_start(lay: Layout, a: argparse.Namespace) -> int:
-    if (err := bad_slug(a.goal)):
+    # Цель либо названа, либо явно не названа. Голое отсутствие `--goal` не
+    # проходит намеренно: забытый флаг и решение «этот спринт без цели» иначе
+    # неразличимы, а второе — продуктовое решение человека.
+    if not a.goal and not a.no_goal:
+        raise Usage("цель спринта: --goal <слаг> или явно --no-goal."
+                    " Спринт без цели законен (багфикс, техдолг, здоровье),"
+                    " но называется решением, а не пропуском флага")
+    if a.goal and (err := bad_slug(a.goal)):
         raise Usage(err)
     entries, _ = parse_entries(read_lines(lay.index("sprint")))
     if entries:
         raise Usage(f"в {lay.name('sprint')} ещё есть набор ({len(entries)}) —"
                     f" закрой спринт: tasks.py sprint close")
+    goal_title = ""
+    if a.goal:
         gpath = lay.items / f"{a.goal}.md"
         if not gpath.exists():
             raise Usage(f"цели {a.goal}.md нет в {lay.cfg['items']}/")
@@ -2223,6 +2267,7 @@ def cmd_sprint_start(lay: Layout, a: argparse.Namespace) -> int:
         if goal["type"] != GOAL:
             raise Usage(f"{a.goal} не цель (тип «{goal['type'] or '—'}») —"
                         f" спринт набирается под одну цель")
+        goal_title = goal["title"]
     date = a.date or datetime.date.today().isoformat()
     if not DATE_RE.fullmatch(date):
         raise Usage("дата в формате ГГГГ-ММ-ДД")
@@ -2236,17 +2281,27 @@ def cmd_sprint_start(lay: Layout, a: argparse.Namespace) -> int:
     if any(f"{SPRINT_TAG}{slug}" in t["tags"] for t in tasks.values()):
         print(f"  внимание: тег {SPRINT_TAG}{slug} уже стоит на задачах прошлого спринта"
               f" — урожаи склеятся; задай другой `--slug`")
-    lines = [*sprint_header(lay, a.goal, goal["title"], date, slug),
+    lines = [*sprint_header(lay, a.goal or "", goal_title, date, slug),
              f"## {lay.cfg['sprint_section']}", ""]
     plan = Plan()
     plan.index(lay, "sprint", lines)
     plan.commit()
     ready = [n[:-3] for n, t in tasks.items()
-             if t["goal"] == a.goal and t["type"] in TAKEABLE
+             if t["type"] in TAKEABLE
+             and (t["goal"] == a.goal if a.goal
+                  else not (t["type"] in NEEDS_GOAL and not t["goal"]))
              and not questions_open(lay, t) and not schema_verdict(lay, t)[0]]
+    if a.goal:
         print(f"спринт начат: цель «{a.goal}», {date}, слаг «{slug}»")
         print(f"  кандидатов под цель без открытых вопросов: {len(ready)}"
               + (f" ({', '.join(sorted(ready))})" if ready else ""))
+    else:
+        print(f"спринт начат: без цели, {date}, слаг «{slug}»")
+        print(f"  набор без цели: цель не проверяется, в него идёт что угодно"
+              f" из готового к взятию ({len(ready)})."
+              f" Перечень — `tasks.py list --index backlog`")
+        print("  докладу это не безразлично: спринт без цели называется таковым"
+              " и объясняется (багфикс, техдолг, здоровье)")
     print(f"  заводимое по ходу метится тегом {SPRINT_TAG}{slug} само — это урожай")
     print("  набери: tasks.py sprint take <слаг> …; набор показывается человеку до старта")
     return EXIT_OK
@@ -2254,8 +2309,10 @@ def cmd_sprint_start(lay: Layout, a: argparse.Namespace) -> int:
 
 def cmd_sprint_take(lay: Layout, a: argparse.Namespace) -> int:
     goal_slug, _ = sprint_goal(lay)
-    if not goal_slug:
-        raise Usage("спринт не начат: tasks.py sprint start --goal <слаг>")
+    # Начат ли спринт, судим по слагу, а не по цели: спринт без цели идёт так же.
+    if not sprint_started(lay):
+        raise Usage("спринт не начат:"
+                    " tasks.py sprint start (--goal <слаг> | --no-goal)")
     sprint_lines = read_lines(lay.index("sprint"))
     backlog_lines = read_lines(lay.index("backlog"))
     hi, section = find_section(sprint_lines, lay.cfg["sprint_section"])
@@ -2277,7 +2334,10 @@ def cmd_sprint_take(lay: Layout, a: argparse.Namespace) -> int:
         if t["type"] not in TAKEABLE:
             raise Usage(f"{slug}: тип «{t['type']}» в спринт не берётся —"
                         f" цель не берут вовсе, берут её задачи")
-        if t["goal"] and t["goal"] != goal_slug:
+        # Цель сверяется, только когда она у спринта есть. Спринт без цели
+        # берёт что угодно готовое: он собран по работоспособности, и чужой
+        # цели там нет — не с чем расходиться.
+        if goal_slug and t["goal"] and t["goal"] != goal_slug:
             raise Usage(f"{slug}: цель «{t['goal']}» не цель спринта «{goal_slug}» —"
                         f" набор служит одной цели, даже если взять удобно")
         if not t["goal"] and t["type"] in NEEDS_GOAL:
@@ -2383,7 +2443,8 @@ def cmd_sprint_close(lay: Layout, a: argparse.Namespace) -> int:
     plan = Plan()
     plan.file(lay.index("sprint"), empty_sprint(lay))
     plan.commit()
-    print(f"спринт закрыт (цель «{goal_slug or '—'}», слаг «{slug or '—'}»)"
+    print(f"спринт закрыт ({f'цель «{goal_slug}»' if goal_slug else 'без цели'},"
+          f" слаг «{slug or '—'}»)"
           + (", набор распущен" if a.dissolve and entries else ""))
     print(f"  история наборов остаётся в git: `git log -p {lay.index('sprint')}`")
     if slug:
@@ -3315,8 +3376,15 @@ def main() -> int:
 
     p = sub.add_parser("sprint", help="операции спринта")
     ssub = p.add_subparsers(dest="sprint_command", required=True)
-    s = ssub.add_parser("start", help="начать спринт под названную цель")
-    s.add_argument("--goal", required=True)
+    s = ssub.add_parser("start", help="начать спринт под названную цель или без цели")
+    # Группа взаимоисключающая, но не required: отказ за отсутствие обоих
+    # флагов даёт cmd_sprint_start — его текст объясняет, а argparse только
+    # называет флаги.
+    g = s.add_mutually_exclusive_group()
+    g.add_argument("--goal", help="слаг цели, под которую набирается спринт")
+    g.add_argument("--no-goal", dest="no_goal", action="store_true",
+                   help="набор без цели: багфикс, техдолг, здоровье —"
+                        " работа на работоспособность, а не на направление")
     s.add_argument("--date")
     s.add_argument("--slug", help="слаг спринта; по умолчанию дата начала")
     s.add_argument("--dir")

lefthook.yml

@@ -0,0 +1,53 @@
+# Гейт коммита: всё, что в этом репозитории проверяется машиной.
+#
+# Документы — то, что читает не человек, а машина, и чья поломка **не видна при
+# чтении**: фронтматтер (его разбирает загрузчик скиллов), помеченная копия
+# правила (расходится молча) и диаграмма mermaid (текст правдоподобен, рендер
+# падает). Скрипты — ruff и pyrefly: они же стерегут ноль внешних зависимостей,
+# без которого tasks.py и docs.py перестают работать в чужом проекте.
+# Всё остальное (проза, устройство, язык) — предмет ревью, а не хука.
+#
+# **Что судится — staged-файлы, а не рабочее дерево**, всюду, где проверка
+# умеет смотреть поимённо: гейт обязан судить то, что уедет в историю, а не то,
+# что случайно лежит на диске рядом. Два исключения названы у своих задач, и оба
+# — про то, что проверке нужен весь репозиторий по существу, а не для удобства.
+#
+# Ставится `lefthook install` (см. README, «Гейт коммита»). Обойти разово —
+# `LEFTHOOK=0 git commit …`; обход законен ровно для того случая, когда чинить
+# найденное нечем прямо сейчас.
+
+pre-commit:
+  parallel: true
+  jobs:
+    # Обе проверки документов идут по всему репозиторию, и это не недосмотр.
+    # copies.py сверяет копию с домом, а дом лежит в другом файле, которого в
+    # индексе может не быть: список staged дал бы «копии дословны» там, где
+    # правка дома их и разошлась. frontmatter.py смотрел бы поимённо, но весь
+    # обход стоит сотые доли секунды — платить за него нечем.
+    - name: фронтматтеры
+      glob: "*.md"
+      run: python3 scripts/frontmatter.py
+
+    - name: копии правил
+      glob: "*.md"
+      run: python3 scripts/copies.py
+
+    # Самая дорогая проверка: каждый блок — свой запуск mermaid-cli со своим
+    # chromium. Отсюда и staged-файлы вместо обхода, и параллель внутри самого
+    # скрипта: репозиторий целиком — 3 секунды, один файл — одна.
+    - name: диаграммы
+      glob: "*.md"
+      run: python3 scripts/diagrams.py {staged_files}
+
+    # Линтеры — через uv: версии прибиты точно, и `uv run` берёт именно их, а не
+    # то, что оказалось в PATH. `--fix` чинит безопасное сам, `stage_fixed`
+    # доносит починку до этого же коммита — иначе она осталась бы в рабочем
+    # дереве, а в историю уехал бы невычищенный файл.
+    - name: ruff
+      glob: "*.py"
+      stage_fixed: true
+      run: uv run ruff check --fix {staged_files}
+
+    - name: pyrefly
+      glob: "*.py"
+      run: uv run pyrefly check {staged_files}

scripts/diagrams.py

@@ -29,6 +29,18 @@ Chromium запускается с `--no-sandbox`: на современных
 «No usable sandbox». Содержимое здесь своё и локальное, так что песочница ничего
 не защищает — она только мешает запуску.
 
+Дорого здесь не чтение markdown, а рендер: каждый блок — отдельный запуск
+mermaid-cli со своим chromium, секунда с лишним. Отсюда два рычага, и оба нужны
+гейту коммита:
+
+- **блоки собираются все сразу, а рендерятся параллельно.** Сбор — обход файлов,
+  он же и определяет порядок вывода; рендер ждёт подпроцесс и потому пускается
+  пулом потоков. Порядок находок от этого не плывёт: он берётся из порядка
+  сбора, а не из порядка ответов;
+- **проверять можно не весь репозиторий, а названные файлы.** `diagrams.py
+  путь.md …` смотрит только их — так гейт платит за диаграммы ровно того файла,
+  который правят. Без аргументов обходится весь репозиторий, как и раньше.
+
 Коды выхода — тот же словарь, что у tasks.py, docs.py и copies.py:
   0  все диаграммы рендерятся
   1  диаграмма не рендерится
@@ -41,15 +53,22 @@ from __future__ import annotations
 
 import argparse
 import json
+import os
 import re
 import shutil
 import subprocess
 import sys
 import tempfile
+from concurrent.futures import ThreadPoolExecutor
 from pathlib import Path
 
 OK, DRIFT, USAGE, ENV, INTERNAL = 0, 1, 2, 3, 4
 
+# Потолок параллели. Каждый рендер — свой chromium, а он стоит сотни мегабайт:
+# на машине с 24 ядрами упереться в память дешевле, чем в процессор. Восемь
+# снимают почти весь выигрыш и не рискуют ничем.
+MAX_WORKERS = 8
+
 FENCE_OPEN = re.compile(r"^\s*```mermaid\s*$")
 FENCE_CLOSE = re.compile(r"^\s*```\s*$")
 
@@ -72,10 +91,28 @@ class Block:
         self.where = f"{path.relative_to(root).as_posix()}:{line}"
 
 
-def collect(root: Path) -> list[Block]:
-    """Все mermaid-блоки репозитория, в порядке обхода."""
+def markdown(root: Path, named: list[Path]) -> list[Path]:
+    """Какие файлы смотреть: названные или весь репозиторий.
+
+    Названные фильтруются теми же правилами, что и обход: только `*.md`, только
+    внутри корня, без пропускаемых каталогов. Гейт передаёт сюда staged-файлы
+    списком, в котором есть и скрипты, и удалённое, — отбор его дело, а не
+    вызывающего.
+    """
+    if not named:
+        return sorted(root.rglob("*.md"))
+    out = []
+    for path in named:
+        full = (path if path.is_absolute() else root / path).resolve()
+        if full.suffix == ".md" and full.is_file() and full.is_relative_to(root):
+            out.append(full)
+    return sorted(set(out))
+
+
+def collect(root: Path, named: list[Path]) -> list[Block]:
+    """Все mermaid-блоки, в порядке обхода. Порядок вывода берётся отсюда."""
     found: list[Block] = []
-    for path in sorted(root.rglob("*.md")):
+    for path in markdown(root, named):
         if any(part in SKIP for part in path.relative_to(root).parts):
             continue
         lines = path.read_text(encoding="utf-8").splitlines()
@@ -106,11 +143,17 @@ def renderer() -> list[str] | None:
     return None
 
 
-def render(cmd: list[str], block: Block, workdir: Path, config: Path) -> str | None:
-    """Отрендерить блок. None — получилось, иначе сообщение об ошибке."""
-    src = workdir / "d.mmd"
+def render(cmd: list[str], block: Block, workdir: Path, config: Path,
+           slot: int) -> str | None:
+    """Отрендерить блок. None — получилось, иначе сообщение об ошибке.
+
+    `slot` разводит временные файлы: рендеры идут параллельно, и одно имя на
+    всех означало бы, что блоки затирают исходники друг друга — с находками,
+    которые не воспроизводятся поодиночке.
+    """
+    src = workdir / f"d{slot}.mmd"
     src.write_text(block.text, encoding="utf-8")
-    out = workdir / "d.svg"
+    out = workdir / f"d{slot}.svg"
     done = subprocess.run(
         [*cmd, "-p", str(config), "-i", str(src), "-o", str(out)],
         capture_output=True,
@@ -132,6 +175,8 @@ def render(cmd: list[str], block: Block, workdir: Path, config: Path) -> str | N
 
 def main() -> int:
     ap = argparse.ArgumentParser(description="Проверка mermaid-диаграмм.")
+    ap.add_argument("paths", nargs="*", type=Path,
+                    help="какие файлы смотреть; без них — весь репозиторий")
     ap.add_argument("--dir", default=".", help="корень репозитория")
     args = ap.parse_args()
 
@@ -141,9 +186,10 @@ def main() -> int:
               f" (нет .claude-plugin)", file=sys.stderr)
         return ENV
 
-    blocks = collect(root)
+    blocks = collect(root, args.paths)
     if not blocks:
-        print("диаграмм нет")
+        print("диаграмм нет" if not args.paths
+              else "диаграмм нет в названных файлах")
         return OK
 
     cmd = renderer()
@@ -153,15 +199,19 @@ def main() -> int:
               " или запусти проверку там, где есть npx.", file=sys.stderr)
         return ENV
 
-    broken: list[tuple[Block, str]] = []
     with tempfile.TemporaryDirectory(prefix="diagrams-") as tmp:
         workdir = Path(tmp)
         config = workdir / "puppeteer.json"
         config.write_text(json.dumps({"args": ["--no-sandbox"]}), encoding="utf-8")
-        for block in blocks:
-            error = render(cmd, block, workdir, config)
-            if error is not None:
-                broken.append((block, error))
+        workers = max(1, min(MAX_WORKERS, len(blocks), os.cpu_count() or 1))
+        with ThreadPoolExecutor(max_workers=workers) as pool:
+            # Потоки, а не процессы: работа целиком в ожидании подпроцесса,
+            # своего интерпретатора ей не надо. `map` сохраняет порядок блоков,
+            # поэтому вывод не зависит от того, кто ответил первым.
+            errors = list(pool.map(
+                lambda pair: render(cmd, pair[1], workdir, config, pair[0]),
+                enumerate(blocks)))
+    broken = [(b, e) for b, e in zip(blocks, errors, strict=True) if e is not None]
 
     files = len({b.path for b in blocks})
     print(f"диаграмм {len(blocks)} в {files} файлах")

scripts/frontmatter.py

@@ -44,7 +44,7 @@ OK, DRIFT, USAGE, ENV, INTERNAL = 0, 1, 2, 3, 4
 
 # Дом раскладки — «Модель по проходу» в review-pipeline/SKILL.md; здесь её
 # механизация. Порядок цветов — порядок стоимости прогона.
-PALETTE = {"sonnet": "green", "opus": "yellow", "fable": "red"}
+PALETTE = {"sonnet": "green", "opus": "yellow"}
 
 SKILL_KEYS = {"name", "description"}
 AGENT_KEYS = {"name", "description", "tools", "model", "color"}