Перед первой командой в незнакомом репозитории есть шаг, который легко пропустить, потому что его как будто и нет: агент уже пришёл с настройками. Rules, skills, субагенты, хуки, плагины и MCP-серверы загружаются молча, из нескольких источников сразу, и начинают действовать раньше, чем вы напишете хоть слово. Наивное предположение - что всё это "моё и безобидное", раз оно в моём проекте. Именно оно и делает первый запуск слепым.
Ломается предположение на том, что загруженные настройки приходят из трёх разных областей с разной подотчётностью. Панель Customizations в Devin Local показывает фактически загруженные rules, skills, субагентов, хуки, плагины и MCP-серверы и, главное, откуда каждый из них: из репозитория, из организации или из вашего аккаунта. "Из репозитория" - значит, их мог положить любой, у кого есть доступ к ветке. "Из организации" - значит, они спущены политикой и вы на них не влияете. "Из аккаунта" - ваши личные, переезжающие за вами между проектами. Три источника - три разных ответа на вопрос "кто это сюда поставил".
Почему смотреть на это стоит именно списком, а не по памяти. Always-on правило действует в каждой сессии, не спрашивая; хук встаёт на путь вызовов инструментов и исполняет код; MCP-сервер открывает внешний endpoint с правами и данными; плагин приносит всё перечисленное разом. Ни одно из этих влияний не объявляет о себе в момент первой команды - оно уже включено. Панель Customizations - это способ увидеть включённое до того, как оно проявится в поведении агента, а не после, разбираясь, почему он "сам" что-то сделал.
Отсюда практика: аудит проекта перед первой командой, по нескольким явным пунктам. Always-on правила должны быть короткими и не противоречить друг другу - длинный или конфликтующий always-on тихо искажает каждую сессию. Хуки должны принадлежать репозиторию и иметь понятный исход: что именно они разрешают, меняют или блокируют. MCP-endpoint и их scope должны быть одобрены вами осознанно, а не унаследованы. Плагины - закреплены по версии и просмотрены по составу. И отдельно: не должно быть неизвестных импортов из других AI-инструментов, затесавшихся в конфигурацию.
Последний пункт заслуживает отдельного внимания, потому что это частый и незаметный источник чужого поведения. Конфигурации разных агентных инструментов похожи по форме, и файл, принесённый из другого продукта, может подхватиться как "свой", неся правила и инструкции, которых вы не писали и за которые не отвечаете. Признак прост: в списке загруженного есть строка, происхождение которой вы не можете назвать. Пока не названо - это не ваша настройка, а неизвестность, действующая с правами вашей.
Цена пропущенного аудита конкретна и всегда всплывает позже. Агент "сам" держится странного стиля - потому что в репозитории лежит чужое always-on правило. Команда "почему-то" не выполняется - потому что её перехватывает унаследованный хук. Появляется обращение к внешнему сервису, которого вы не подключали, - потому что MCP-сервер приехал с плагином или из организации. Каждый из этих случаев объясняется одной строкой в панели, которую не открыли вовремя.
Полезно понимать и обратную сторону: аудит - это не разовая процедура установки, а состояние, которое устаревает. Смена ветки может подменить проектные rules и hooks на другие. Обновление плагина - принести новые always-on инструкции и новый код хуков под тем же именем. Изменение enterprise-политики - добавить или убрать организационные настройки без вашего участия. Поэтому аудит повторяют после каждого из этих событий, а не считают закрытым однажды.
Проверять результат аудита стоит способом, отличным от беглого взгляда: пройти список сверху вниз и по каждой строке назвать источник и назначение вслух или в заметке. Строка, для которой не находится ответа "кто и зачем", - это не пройденная проверка, а найденная задача. В stable 3.8.20 по загруженным настройкам работает общий поиск, что делает такой проход быстрым даже в насыщенной конфигурации. Аудит закрыт не тогда, когда панель просмотрена, а когда для каждой активной настройки есть внятное объяснение.
Типичный провал - относиться к панели как к информационной, а не к контрольной. Её открывают из любопытства уже после того, как агент повёл себя странно, и используют для объяснения постфактум вместо проверки заранее. Второй провал - провести аудит один раз и считать его вечным, не повторяя после смены ветки или обновления плагина. Признак обоих один: первую команду отдали агенту, чью загруженную конфигурацию ни разу не назвали поимённо. Назвать её до команды - и большинство "он сам" просто не возникнет.