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

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

@@ -104,7 +104,7 @@ description: Проводит несколько задач разом — пл
   параллельном она гонится в волне **одна** (обоснование — ниже, в шаге 4).
   Помечается здесь, на планировании, а не во время прогона, и **независимо от
   режима**: состав волны определяется сейчас, режим может смениться просьбой уже
-  после плана, а профиль ревью сабагент выберет только внутри задачи — ключевать
+  после плана, а ступень ревью выберет разметчик уже внутри прогона — ключевать
   волну на ещё не сделанный выбор нельзя. Триггеры — по фактам о задаче, каждый
   сам по себе достаточен:
   - трогает схему хранилища, миграцию, формат на диске или объём хранимого;
@@ -115,12 +115,12 @@ description: Проводит несколько задач разом — пл
     где уже мерили или уже ломалось.
 
   Ни один триггер не сработал — задача не замеряющая, даже если её ревью
-  окажется `wide`. Профиль про глубину проверки, замеряющая — про соревнование за
+  окажется `wide`. Ступень про глубину проверки, замеряющая — про соревнование за
   железо; это разные вопросы, и совпадают они не всегда. Обратное тоже бывает и
   тоже законно: помеченная задача, чьё ревью пошло профилем `quick` или
   `standard`, машину не займёт вовсе — меряющие проходы живут только в `wide`.
-  Пометка от этого не снимается: она ставится **до** выбора профиля, и
-  перестраховка здесь стоит одной волны, а ошибка — испорченных чисел;
+  Пометка от этого не снимается: она ставится **до** разметки, и перестраховка
+  здесь стоит одной волны, а ошибка — испорченных чисел;
 - **нумерованные артефакты — номера раздаёт оркестратор заранее.** Если проект
   нумерует миграции (путь — `docs/.pm.json`, ключ `migrations`), посмотри последний
   номер и **раздай номера всем задачам, которые, вероятно, их добавят**, до
@@ -238,9 +238,10 @@ flowchart TD
    - прогони Skill **`av-dev-pipeline:task-pipeline`** ровно на этой задаче,
      полный цикл SDD с обоими чекпоинтами ревью;
    - если задаче назначен **номер артефакта** — используй строго его;
-   - **профиль ревью выбирается по факту изменения.** Батч не повод понижать
-     профиль: «нас много и мы спешим» — это ровно тот стимул, из-за которого
-     проходы пропускают;
+   - **ступень ревью выбирает разметчик конвейера, а не ты и не сабагент.**
+     Профиль в вызов не передаётся вовсе. Батч не повод её понижать: «нас много и
+     мы спешим» — ровно тот стимул, из-за которого проходы пропускают, и он снят
+     тем, что регулятор не в руках у автора;
    - **режим прогона проходов ревью — от режима батча**, и его называет charter,
      а не сабагент: батч идёт по одной задаче → режим умолчательный, **`по
      графу`** (машина свободна); батч идёт волнами → **`линейно`**, твой worktree
@@ -248,17 +249,18 @@ flowchart TD
      Внутренние рёбра графа — цепочку проходов, держащих машину — конвейер
      соблюдает сам, в любом режиме;
    - **если вложенные сабагенты недоступны** (движок не даёт запускать агентов из
-     агента) — не пропускай ревью и не понижай профиль: проведи его **инлайн** по
-     тем же charter'ам `av-dev-pipeline`, сохранив обязательное — гейт до
-     опиниативных проходов, состав по профилю, триаж последним. И **скажи в
-     отчёте прямым текстом, что ревью шло инлайн**: инлайновый проход видит
-     контекст автора и потому разведён с ним слабее — это меняет доверие к
-     результату, а не только способ запуска;
+     агента) — не пропускай ревью и не понижай ступень: проведи его **инлайн** по
+     тем же charter'ам `av-dev-pipeline`, сохранив обязательное — разметку первой
+     (план с темами и ступенью), гейт до опиниативных проходов, состав по плану,
+     триаж последним. И **скажи в отчёте прямым текстом, что ревью шло инлайн**:
+     инлайновый проход видит контекст автора и потому разведён с ним слабее — а
+     инлайновая разметка вдобавок означает, что ступень выбрал автор, и это
+     отдельная строка;
    - **вернуть отчёт**, в котором обязательно: исход задачи одним из трёх слов;
-     **объявленный профиль ревью и режим прогона**; что сделано; какие вопросы
+     **план прогона: ступень с обоснованием, темы и их глубины**, и режим; что сделано; какие вопросы
      записаны и куда; изменённые файлы; добавлялся ли нумерованный артефакт и с
      каким номером; затронутые capability; состояние гейта; **перечень
-     запущенных проходов ревью поимённо с исходом каждого**; **путь к
+     тем с исходом по каждой**; **путь к
      сохранённому отчёту триажа** (`openspec/changes/<id>/review/`, после
      архивации — `openspec/changes/archive/<id>/review/`); шло ли ревью
      инлайн; границы покрытия.
@@ -275,24 +277,25 @@ 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`, и только потом