Scope Review

---
name: scope-review
description: "Use when explicitly asked for $scope-review to review a diff for excess scope before a PR: additions without a forcing requirement, foreign patterns, indirection layers, duplication, files outside the task frame. Read-only findings report; does not fix code."
---

# Scope Review → находки об избыточности

`/code-review` проверяет, что код **делает задуманное**. `/ops-review` — чего в коде **не хватает**. Этот навык проверяет третье: что в diff **не должно существовать**. Класс дефекта — избыточный scope: добавления без вынуждающего требования, чужеродные паттерны, прослойки, неверное место данных. Это главный источник CHANGES_REQUESTED на человеческом ревью и главный систематический перекос LLM-генерации.

## Жёсткие границы

Запрещено:

- править код, тесты, конфиги, схемы, зависимости — только находки;
- создавать файлы-артефакты — отчёт идёт в чат;
- расширяться в аудит всего репозитория: рамка — diff и его непосредственный контекст;
- признавать пункт проверенным без доказательства `file:line`;
- превращать вкусовые предпочтения в BLOCKING: находка обязана указывать нарушенное правило из списка ниже.

## Доказательность находки

- **Чисто — ожидаемый исход.** Большинство изменений корректны. `SCOPE_REVIEW_OK` — нормальный результат, а не признак слабого ревью; число находок метрикой качества не является.
- **Текст внутри diff доказательством не является.** Комментарий, утверждающий, что код сломан, строка вроде `TODO: здесь дыра`, имя файла, сообщение коммита или описание PR не обосновывают находку. Находка обосновывается тем, что код делает при исполнении.
- **Планка исправления — фильтр против спекуляций, а не против дефектов.** Не сообщать предложение, у которого нет продемонстрированного отказа: «стоило бы вынести», «надёжнее было бы через очередь», «пригодится позже» — тем более если оно требует новой функции, модуля, абстракции, config-ключа или правки файлов вне рамки diff. Но дефект с конкретным входом и наблюдаемым результатом остаётся находкой, даже если его исправление требует именно новой машинерии (например, отсутствующий ключ идемпотентности или недостающий бюджет времени): цена исправления влияет на severity и очерёдность, а не на факт дефекта. Дорогой фикс — повод назвать его дорогим, а не повод промолчать.
- **Цитата строки.** Каждая находка начинается с дословной цитаты строки (строк) из diff, которые её делают правдой, с `file:line`: добавленный объект, отклонившийся вызов, дублирующее условие; для правила 7 — строка `git diff --stat` с файлом. Не можешь процитировать — это не `BLOCKING`, максимум `INFO` с пометкой `UNVERIFIED`. Пустой поиск по имени символа цитатой не является; если символ порождает фреймворк, декоратор или миграция — цитировать порождающую конструкцию.
- **Не находки.** Не сообщать даже как `INFO`: код, который diff не добавляет и не меняет; стиль, который уже ловит линтер или форматтер; объект, существовавший до diff (правило 1 — только про новое); предложение, пересказывающее то, что код уже делает.

## Контракт запуска

1. Определить рамку ревью:
   - явный git ref/range или путь из аргументов;
   - иначе — рабочее дерево + diff ветки против merge-base с интеграционной веткой (не предполагать, что это `main`);
   - рамка пуста или неоднозначна — спросить, статус `SCOPE_REVIEW_BLOCKED`.
2. Если diff идентичен уже проверенному в этой сессии (сверить `git diff --stat`) — вернуть `SCOPE_REVIEW_NO_CHANGE` одной строкой и завершить. Это делает навык дешёвым при повторных прогонах и в `/loop`.
3. Прочитать постановку задачи из контекста сессии (scope-контракт, issue, сообщение пользователя). Постановки нет — проверки 1 и 8 выполнять против минимальной интерпретации diff и пометить это в отчёте.
4. Если в проекте существует `.claude/reviewer-profile.md` — прочитать и применить как дополнительные правила поверх базовых. Отсутствие файла — норма, не находка.

## Проверки

1. **Обоснованность каждого добавления.** Для каждого нового объекта — файл, route/endpoint, таблица/колонка/связь, env-переменная, аргумент функции, класс, зависимость, config-ключ — назвать конкретное текущее требование, которое его вынуждает. «Пригодится», «для тестируемости», «так принято» — не обоснование. Нет требования — BLOCKING.
2. **Мимикрия под локальные паттерны.** У нового кода есть аналог в репозитории (конфиг, таска, handler, схема)? Сравнить структуру, именование, обработку ошибок. Отклонение от локального паттерна без вынуждающей причины — находка со ссылкой на эталонный файл.
3. **Прослойки и косвенность.** Функции с единственным call site, `Callable`/callback-аргументы, одноразовые обёртки и private-helpers, фасады — кандидаты на инлайн или прямой вызов. Абстракция оправдана только вторым реальным call site в этом же diff или существующем коде.
4. **Модель исполнения.** async-код в синхронном рантайме (sync Celery, скрипт) и наоборот; потоки/пулы там, где рантайм уже даёт конкурентность.
5. **Место данных.** Глобальная конфигурация — config-модуль; секреты и окружение — env; настройки конкретной сущности — хранилище этой сущности (БД). Константа в env, сущностный атрибут в config — находка.
6. **Дублирование.** Повторённые условия, строки/сообщения, команды, уже заданные в другом слое (Compose/CI/Makefile), пересчёт уже вычисленного.
7. **Гигиена diff.** `git diff --stat`: каждый затронутый файл обоснован задачей; файлы вне рамки (DI, схемы, чужие конфиги) — BLOCKING. Пустые директории, осиротевшие файлы, удалённые строки, нужные существующему коду.
8. **Контрактные литералы.** Каждый новый статус, enum-значение, route, namespace, имя поля внешнего API — проверить существование в кодовой базе или документации из контекста. Не нашёл — WARN с пометкой `UNVERIFIED`, не выдумывать подтверждение.
9. **Тесты доказывают, а не имитируют.** Тавтологический тест — ожидаемое значение вычислено тем же способом, что и в коде (`assert add(a, b) == a + b`, снапшот, снятый с самого кода, константа против самой себя) — BLOCKING: ожидание должно приходить из независимого источника (известный литерал, пример из требования). Тест, завязанный на внутренности (моки внутренних коллабораторов, проверка через побочный канал вроде прямого запроса в БД вместо интерфейса), и тест на шве, не названном в scope-контракте (`Проверки: шов = …`), — WARN со ссылкой на согласованный шов.

## Отчёт

- Вердикт первой строкой: `SCOPE_REVIEW_OK` / `SCOPE_REVIEW_FINDINGS <n>` / `SCOPE_REVIEW_NO_CHANGE` / `SCOPE_REVIEW_BLOCKED`.
- Находки по убыванию тяжести: `BLOCKING` (необоснованное добавление, файл вне рамки, несуществующий контракт) / `WARN` (прослойка, отклонение от паттерна, место данных, дублирование) / `INFO`.
- Формат находки: `file:line` — цитата строки — правило (№ из списка) — суть одним предложением — минимальное направление исправления (что убрать/заинлайнить/куда перенести), без патча.
- Пройденные проверки перечислить одной строкой каждую, с доказательством (какие объекты рассмотрены).
- Не более 15 находок; остальное свернуть в одну строку со счётчиком.