Маршрутизация и одобрение пул-реквестов решают задачу, которая обычно решается людьми вручную: кому это ревьюить и можно ли принять без обсуждения. Система назначает ревьюеров по владению кодом и истории изменений и может сама одобрять изменения низкого риска по заданным критериям. Границу стоит зафиксировать сразу: это не полноценный обзор кода, а маршрутизация с ограниченным правом пропускать очевидное. Спутать эти две вещи легко, потому что внешне результат один и тот же - у пул-реквеста появляется одобрение.

Решение опирается на несколько сигналов: находки автоматического обзора, результаты проверки безопасности, оценку риска и файлы политики в самом репозитории. Именно последнее делает механизм пригодным для больших команд - политика лежит рядом с кодом, версионируется вместе с ним и проходит обычное ревью, а не живёт в настройках, о которых знают двое. Изменение правил становится обычным изменением: его видно в истории, о нём можно спорить в комментариях и его можно откатить.

Поиск политики устроен строго. Для каждого изменённого файла система ищет файл с точным именем в его каталоге и выше по дереву; ближайший имеет приоритет. Имя в другом регистре, резервная копия или похожее написание игнорируются - и это важная деталь: политика, названная почти правильно, не действует и никак об этом не сообщает. Ошибка проявится не сообщением, а тишиной: правила, которые вы считали действующими, просто не участвуют в решении. Верхнеуровневая маршрутизация живёт в отдельном каталоге в виде списка с продуктами, границами и политиками.

Самая интересная часть механизма - защита от самоослабления. Если пул-реквест меняет саму политику одобрения или маршрутизации, система не применяет новую версию к этому же изменению: берётся версия из базовой ветки либо требуется человек. Иначе достаточно было бы одной строки в политике, чтобы разрешить себе всё остальное - и это был бы самый короткий путь мимо любых требований. А при неоднозначной специфичности применяется более строгая инструкция, тот же принцип, что и с запретами в разрешениях: сомнение решается в сторону ограничения.

Отсюда практическая рекомендация про потолок автоматического одобрения. Его держат низким и явно объявляют защищённые области, где человек нужен всегда: авторизация, платежи, инфраструктура, миграции данных и сами файлы политики. Всё остальное можно постепенно отпускать по мере накопления статистики, но не наоборот - начинать с широкого автоматического одобрения и сужать его по инцидентам дороже и дольше, потому что за это время команда успевает привыкнуть к отсутствию ревью.