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

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

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

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

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

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

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