Enterprise-раскатка Codex начинается не с выдачи полного доступа, а с инвентаризации. Прежде чем что-то включать, составляют карту: какие поверхности используются, какая identity, какие репозитории, какая политика данных, какие модели разрешены, как контролируются plugins и skills, какая сеть и кто отвечает за поддержку. Соблазн "дать всё и посмотреть, что будет" на уровне организации особенно дорог, потому что ошибка тиражируется на всех. Сначала инвентаризация, потом осознанное включение по частям.

Managed requirements - это инструмент, которым организация задаёт обязательные границы. Через requirements можно ограничить разрешённые approval-политики, sandbox-режимы, MCP identity, hooks, reviewer для auto-review, сетевые домены, plugins и skills. Ключевое свойство, отличающее requirements от обычного config: пользовательский config не должен иметь возможности расширить enforced boundary. Обычный слой можно перекрыть слоем выше; managed-требование - нет, в этом весь смысл централизованной политики.

Полезно один раз развести роли конфигурационных механизмов в таблице. System-, user- и project-config.toml задают значения по умолчанию, которые нижний слой может переопределить по приоритету. requirements.toml задаёт admin-enforced ограничения и allowlists, которые перекрыть нельзя. Это разные по природе вещи: одно - удобные дефолты, другое - обязательные рамки. Путать их - значит либо ждать от config гарантий, которых он не даёт, либо от requirements гибкости, которой у него нет намеренно.

Раскатку ведут по порядку, а не включают всё сразу. Сначала создают непроизводственную pilot-identity, проверяют на ней провайдера и модели, доступ и поведение. Затем разворачивают managed-политику на canary-группе, а не на всех сразу: невалидные записи могут вырезаться, а security-чувствительные границы должны падать закрыто. И только на проверенной основе включают остальное. Enterprise прощает меньше, чем локальная настройка, поэтому порядок и постепенность здесь - не бюрократия, а защита.