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

Разница видна на обычном требовании: перед завершением задачи прогнать тесты. Записанное правилом, оно работает в большинстве случаев и не работает ровно тогда, когда важнее всего: задача длинная, контекст переполнен, до конца осталось одно действие, и модель считает шаг необязательным. Записанное hook на событие завершения, оно выполняется всегда, а стоит одного скрипта и одной строки конфигурации. Разница между этими двумя вариантами не в качестве формулировки, а в том, участвует ли требование в рассуждении или стоит вне его.

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

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

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

Типичные провалы предсказуемы. Записать одно требование в четыре разных места и получить противоречие. Ждать от правила гарантии, которую даёт только hook или разрешения. Держать командную политику там, откуда её легко снять локально. Списывать расхождение поведения между людьми на модель. И настраивать инструмент по частям, не задав себе вопрос, какой слой должен владеть решением.