ревью по темам: документ проекта стал направлением проверки

Замечено при сверке документов канона с составом ступеней: три документа
остались без читателя ниже wide — security.md, database.md и adr/. Проект
поддерживал их, а на 90% задач не открывал никто. Причина оказалась не в
переезде проходов, а в том, как описан состав прогона.

Список тем нигде не был записан: он существовал побочным продуктом списка
проходов. Проход уезжал в верхнюю ступень — и тема уезжала с ним беззвучно.
Отчёт честно говорил «ops не запускался» и не говорил «эксплуатацию не смотрел
никто», а нужно второе. Теперь тема первична, проход вторичен — это правило 0
конвейера, а прогон описывается таблицей «тема → дом → глубина → кто закрывает»,
и таблица есть в каждом отчёте.

Тема есть документ, список открытый. Всё, что проект кладёт в docs/, становится
темой ревью; запретить нельзя, разрешения не надо. Не темы ровно две: docs/tasks/
и docs/review — настройка самого конвейера, слой над темами. Отсюда главное:
docs/ перестал быть документацией и стал конфигурацией конвейера. Проект
настраивает проверку тем, что пишет о себе, а не отдельным файлом настроек,
который разошёлся бы с документами. Ядро — requirements, autotests, conventions,
architecture, security, operations; всё сверх разбирает basics, потому что
именных проходов конечное число, а тем столько, сколько заведёт проект.

Тема живёт файлом или каталогом, на выбор проекта: docs/security.md и
docs/security/ — одно и то же. Прежде форма была задана поимённо и обосновать её
было нечем; заодно в TODO висел вопрос «а если architecture.md разрастётся».
Теперь ответ механический: разросся — стал каталогом с README.md, и это не смена
версии. Обе формы сразу — ошибка, docs.py её ловит.

Заведён review-scope, sonnet, стадия 0, до гейта: находит документы, выводит
темы, назначает глубины, выбирает ступень с обоснованием. Довод оказался сильнее
синхронизации документов — до сих пор профиль называл тот же оркестратор,
который написал код, то есть в точке выбора глубины проверки разведённости с
автором не было вовсе, а решала она под давлением «я почти закончил». Вызывающий
пайплайн профиль больше не передаёт. Поднять и понизить ступень разметчик вправе
одинаково, но обоснование обязательно всегда.

Sonnet ему хватает потому, что вывод устроен как список: каждый файл в docs/
обязан попасть в план темой или строкой «не тема, потому что», и план сверяется с
ls docs/ за секунду. Выбор ступени — суждение, но у него три независимых
корректора: отрицательный тест quick, правило «спорный случай вниз» и сигнал
basics о заниженной ступени.

Разметчик передаёт адреса, а не пересказ. Проект однажды уже держал
review-brief.md и убрал его: второй дом расходится с первым и выглядит
актуальным. Пересказ в задании — тот же посредник, живущий один прогон.
Исключение одно: отсутствие дома, этого проход сам дёшево не выяснит.

quick и standard совпали составом и разошлись глубиной — иначе требование
«нижние ступени закрывают все темы, просто не так глубоко» не выполняется.
Глубин три, и они про способ доказательства, а не про старательность: сверка
(открыть дом, открыть дифф, сравнить), разбор (построить сценарий рассуждением),
доказательство (прогнать, померить, построить путь). Третья есть только в wide.
Цена принята: это единственное место, где профиль не выводится из списка
проходов, поэтому глубина объявляется в отчёте наравне со ступенью.

review-code переписан, и это оказалось крупнее исходной находки: код как код не
читал никто. specs сверял с требованиями, basics — с отказами окружения,
architecture — с устройством, а code был проходом только по прозаическим
конвенциям и прямо объявлял, что рантайм и логика не его. «Здесь ошибка в логике»
не говорил вообще никто. Теперь у прохода две половины: девять классов
технического дефекта (необработанная ветка отказа, пустое и нулевое, граница
диапазона, перепутанный операнд, неосвобождённый ресурс, изменение под итерацией,
неверно применённый интерфейс библиотеки, недостижимая ветка, «сделано соседнее»)
и прежняя сверка с конвенциями. Модель поднята до opus по признаку темы 35: цена
пропущенной находки — дефект в проде.

Канон повышен до версии 5: форма дома на выбор, открытый список тем, AGENTS.md
законно лежит рядом с CLAUDE.md, «Вопросы к проходам» → «Вопросы по темам» (имя
прохода переезд не переживает, тема переживает), «Недоступно проверке» — тоже по
темам. docs.py переписан под темы: ловит двойной дом, принимает обе формы,
перечисляет свои темы проекта вместо «файл вне канона».

Побочно закрыт давний пункт TODO про каталожную форму architecture.md — решать
больше нечего.

Прогон от всего этого стал дороже, а не дешевле, впервые за сессию: плюс scope в
голове каждого прогона, плюс code на opus, плюс basics теперь и в quick. Куплены
разведённость выбора ступени, видимость непокрытых тем и технический разбор кода,
которого не было вовсе.

Тема 36 в DECISIONS.md, следствия 137-140.

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

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

@@ -10,8 +10,8 @@ description: Автономно проводит одну задачу чере
 
 Это тонкая обёртка над каноническими скиллами `opsx:explore` / `opsx:propose` /
 `opsx:apply` / `opsx:archive` — вызывай их через Skill, не переизобретай их шаги.
-Ревью — скилл `av-dev-pipeline:review-pipeline`, он же держит правило выбора
-профиля.
+Ревью — скилл `av-dev-pipeline:review-pipeline`; он же держит правило выбора
+ступени и **сам её выбирает**: ты профиль не передаёшь.
 
 ## Предпосылки
 
@@ -76,8 +76,8 @@ description: Автономно проводит одну задачу чере
 Задача сделана, когда верно всё:
 
 1. гейт проекта зелёный;
-2. ревью проведено **по профилю**, состав прогона сверен с таблицей профилей
-   поимённо, непущенные проходы названы в границах покрытия;
+2. ревью проведено, **план прогона сверен с исходом по каждой теме**, темы без
+   отчёта и без дома названы в границах покрытия;
 3. change заархивирован, дельты влиты в актуальные спеки;
 4. коммит сделан в текущую ветку;
 5. **критерии приёмки, если проект их дал, выписаны поимённо, и по каждому назван
@@ -160,7 +160,7 @@ flowchart TD
     s4["4. ревью предложения, профиль design"]
     s5["5. отработать замечания + validate --strict"]
     s6["6. opsx:apply — код, гейт, поведенческая верификация"]
-    s7["7. ревью кода, профиль по факту изменения"]
+    s7["7. ревью кода, ступень выбирает разметчик"]
     s8["8. opsx:archive"]
     s9["9. синк документации — av-dev-pm:docs"]
     s10["10. коммит работы — av-dev-git:commit"]
@@ -259,13 +259,18 @@ flowchart TD
 ### 7. Ревью кода — Skill `av-dev-pipeline:review-pipeline`
 
 Второй чекпоинт. Вызови Skill **`av-dev-pipeline:review-pipeline`**, дав ссылку
-на change `<id>`, базу диффа, профиль **и режим запуска**.
+на change `<id>`, базу диффа **и режим запуска**.
 
-**Правило выбора профиля живёт в скилле конвейера** (раздел «Профили»), проектные
-триггеры — в `docs/review.md`, если записаны. Здесь оно не пересказывается: три
-копии одного правила расходятся, и работать будет та, которую прочитали
-последней. Помни ровно одно — **профиль выбирается по факту изменения, а не по
-ощущению важности**, и посмотри таблицу перед вызовом.
+**Профиль ты не передаёшь, и это правило, а не упрощение.** Ступень выбирает
+разметчик конвейера (`review-scope`, стадия 0) — по объёму и незнакомости
+изменения, с обоснованием строкой. Причина в разведённости: ты только что написал
+этот код, и решать, насколько глубоко его проверять, тебе нельзя — под давлением
+«я почти закончил» решение известно заранее. Правило выбора живёт в скилле
+конвейера, проектные триггеры — в `docs/review.*`.
+
+**Считаешь ступень заниженной — скажи это в докладе строкой, а не переспорь.**
+Разметчик вправе и поднять, и понизить; твоё несогласие это факт для человека, а
+не команда конвейеру.
 
 **Режим по умолчанию — `по графу`, и обосновывать его не надо.** Конвейер сам
 знает свои рёбра: гейт открывает опиниативные проходы, проходы с пометкой «держит
@@ -280,11 +285,12 @@ flowchart TD
 потолком 7 пунктов, разметкой `Действие: инлайн | развилка` и секцией границ
 покрытия.
 
-**Сверь состав прогона с таблицей профилей в скилле, прежде чем коммитить.**
-Отчёт обязан называть запущенные проходы **поимённо и с исходом**; непущенный
-идёт строкой «не запускался» в границы покрытия. Реестр короткий (4–8 проходов) —
-сверка стоит одного взгляда. Почему это правило существует, объясняет раздел
-«Профили» скилла конвейера; здесь — само требование.
+**Сверь план прогона с исходом, прежде чем коммитить.** Отчёт начинается планом
+разметчика — таблицей «тема → дом → глубина → кто закрывает», — и против каждой
+темы обязан стоять исход. Тема без отчёта и тема без дома — разные вещи, и обе
+должны быть названы. Реестр короткий (шесть тем ядра плюс свои) — сверка стоит
+одного взгляда. Почему это правило существует, объясняет раздел «Профили» скилла
+конвейера; здесь — само требование.
 
 Отработай так же, как шаг 5: помеченное `инлайн` чини сам и не логируй,
 `развилка` — вопросом в запись (он уже сформулирован триажем, его остаётся
@@ -384,7 +390,7 @@ flowchart TD
   это доклад приёмщику, а не отметка «принято»;
 - **`Урожай`** — отложенные находки списком (формулировка, оракул, провенанс).
   Задачи из него заводит тот, кто ведёт задачи проекта;
-- **одна строка границ покрытия**: какой профиль и режим гонялись, какие проходы
+- **одна строка границ покрытия**: какая ступень и режим гонялись, какие проходы
   не запускались и что проверить было невозможно. Доклад без неё сообщает
   «проверено», не сообщая, что именно.
 
@@ -402,7 +408,7 @@ flowchart TD
   спрашивай, запиши вопросом и доведи остаток.
 - Держи вызывающего в цикле короткими репликами на переходах фаз, но не проси
   подтверждать механику.
-- **Занизить профиль ревью или пропустить проход — самый дешёвый способ
-  «ускориться», и он же самый дорогой по последствиям.** Защита одна: профиль
-  выбирается по факту изменения, состав сверяется поимённо, а непущенное
-  называется в отчёте строкой.
+- **Занизить ступень ревью или пропустить тему — самый дешёвый способ
+  «ускориться», и он же самый дорогой по последствиям.** Защита устроена так,
+  что регулятора у тебя нет: ступень выбирает разметчик, план сверяется по темам,
+  непокрытое называется в отчёте строкой.