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

Замечено при сверке документов канона с составом ступеней: три документа
остались без читателя ниже 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>

README.md

@@ -28,11 +28,12 @@
 - **av-dev-pipeline** — исполнение. **Требует OpenSpec.**
   - `task-pipeline` — задача через полный цикл SDD, от постановки до коммита;
   - `task-batch` — несколько задач разом, каждая в своём worktree;
-  - `review-pipeline` — конвейер ревью: гейт, сверка со спеками, базовый проход
-    на отказы и лишнее, а в верхней ступени — враждебные постановки,
-    эксплуатационный постмортем и архитектура; триаж обязателен всегда. Девять
-    агентов-проходов, три ступени стоимости: `quick` (4 прохода), `standard` (5,
-    умолчание), `wide` (7, только крупное или незнакомое — 5–10% задач).
+  - `review-pipeline` — конвейер ревью **по темам**: каждый документ проекта это
+    тема проверки, а проход лишь закрывает её на заданной глубине. Прогон
+    начинает разметчик — находит документы, выводит темы, выбирает ступень.
+    Десять агентов-проходов, три ступени: `quick` и `standard` закрывают все темы
+    сверкой и разбором, `wide` добавляет доказательство — запуск, замер,
+    построенный путь (5–10% задач).
 - **av-dev-git** — `commit`: сообщения в личном стиле.
 
 Соглашение об именах: имя **плагина** длинное с префиксом `av-dev-`, имена
@@ -45,7 +46,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/"]
@@ -80,8 +81,10 @@ flowchart TB
 обязательных — в ней не хватало путей, чьё отсутствие `docs.py check` считает
 нарушением.
 
-**Отдельного файла-брифа для ревью нет.** Проходы читают документы канона
-напрямую; карта «что нужно проходу → где лежит» —
+**Документ канона — это тема ревью, и список тем открытый:** завёл документ в
+`docs/` — завёл направление проверки, а форма дома (файл или каталог) на выбор
+проекта. Отдельного файла-брифа при этом нет — проходы читают документы напрямую;
+карта «тема → её дом → что оттуда берётся» —
 [project-facts.md](av-dev-pipeline/skills/review-pipeline/references/project-facts.md).
 
 Прийти в старый проект и перевести его на канон — `/av-dev-pm:canon`. Канон