Интеграция Codex с GitHub умеет запускать обзор pull request и учитывать при этом специфичные для репозитория Code Review Rules из ближайшего AGENTS.md. Это превращает обзор из общего "посмотри код" в проверку против правил, которые команда считает важными именно для своего проекта. Но ценность такого обзора целиком зависит от качества правил: хорошие правила ловят реальный риск, плохие - создают шум, который скоро начинают игнорировать.

Главное правило про правила: они должны описывать значимое поведение, а не дублировать линтер. Линтер уже ловит форматирование, неиспользуемые переменные и стилистику - выносить это в Code Review Rules бессмысленно, только зашумляет обзор. Правила окупаются там, где статический анализатор бессилен: в логике авторизации, границах доверия, совместимости контрактов, обработке данных. То, что нельзя выразить правилом линтера, но что критично для корректности, - вот материал для Code Review Rules.

Полезно один раз увидеть осмысленное правило целиком. Ниже - блок Code Review Rules про авторизацию: помечать любой endpoint, который читает данные арендатора, не выводя tenant_id из аутентифицированного принципала; параметр маршрута не является доверенной границей арендатора; безопасный путь - сначала авторизовать принципала, затем ограничить каждый запрос авторизованным арендатором. Это не стиль, а поведенческий инвариант, нарушение которого - реальная уязвимость.

Хорошее правило устроено как проверяемое утверждение о риске, а не как пожелание. Оно называет конкретный антипаттерн ("читает данные арендатора без вывода tenant_id из принципала"), объясняет, почему это опасно ("параметр маршрута - не доверенная граница"), и задаёт безопасный путь. Такое правило агент может применить однозначно: есть чёткий признак нарушения и понятный правильный вариант. Расплывчатое "пиши безопасный код" правилом не является - по нему нельзя ни поймать нарушение, ни объяснить его.

Enforcement на уровне репозитория - это то, что делает правила силой, а не документом. Когда Code Review Rules живут в AGENTS.md под контролем версий, они применяются ко всем PR одинаково и эволюционируют вместе с проектом через обычный процесс ревью. Правило, добавленное после инцидента, начинает ловить его повторение автоматически. Это дешевле, чем каждый раз надеяться, что человек-ревьюер вспомнит про конкретный класс риска на конкретном участке кода.