Scope Review

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

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

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

Запрещено:

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

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

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 находок; остальное свернуть в одну строку со счётчиком.