Задача начиналась с тревожного желания быстро обновить `AGENTS.md` под GPT-5.6 Sol. Но самый опасный ход в такой ситуации — сразу открыть рабочий файл и начать переписывать правила по ощущению.
Вместо этого сначала зафиксировали исходное состояние, границы изменений, проверочную матрицу и путь отката. Только после этого большой постоянный слой инструкций разделили на короткое ядро и тематические документы, а поведение проверили на реальных сценариях.
Ядро
70 → 18 КБ
Постоянные правила стали примерно на 75% меньше, без удаления критических ограничений.
Проверки
10 + 4 сценария
Старую и новую структуру прогнали через рискованные рабочие ситуации до внедрения.
Контур
2 машины
MacBook Pro M5 и Mac mini M4 Pro довели до согласованного поведения Codex.
Архитектура правил
В одном всегда загружаемом файле накопились правила безопасности, продакшена, Git, Notion, Linear, GitHub, секретов, субагентов, дизайна и отдельных рабочих режимов. Проблема была не в самих правилах, а в том, что модель получала их почти на любую мелкую задачу.
В постоянном `AGENTS.md` оставили только правила, которые должны действовать всегда: приоритет прямого ограничения пользователя, границы мутаций, секреты, dirty repo, проверки и остановки перед продакшеном.
Подробные процессы переехали в отдельные файлы: Codex-first, операционные задачи, дизайн и инструменты, доступы, MCP и изоляция среды выполнения.
Задача стала проектированием рабочего договора между человеком и агентом, а не редактурой большого промпта.
До изменений зафиксировали размер, структуру, контрольные точки, границы и путь отката, чтобы не перепутать ощущение порядка с доказательством.
Проверочная матрица
Проверяли не красоту новых формулировок, а поведение модели: команды, обращения к инструментам, изменения файлов и признаки внешних мутаций.
Десять общих сценариев безопасности прошли и на исходной версии, и на новой структуре инструкций.
Четыре дополнительных сценария проверяли работу с тематическими файлами и новым разделением правил.
Для тестов использовались искусственные значения; модель не печатала их и не выносила наружу.
Неразрешённых записей не было, а в сценарии с ожидаемым изменением произошла ровно одна нужная запись.
На коротких проверках постоянный входной контекст уменьшился примерно на 36%.
Ответы не стали стабильно быстрее. Иногда новая версия была чуть медленнее, поэтому результат не выдавали за выигрыш по скорости.
Доступы и MCP
Одинаковые правила не гарантируют одинаковую рабочую среду. На практике один сервис мог существовать сразу как встроенный MCP, приложение, прямой API и локальный MCP-процесс. Часть маршрутов работала, часть шумела ошибками авторизации.
Смотрели только названия, назначение, владельца, область действия, возможность отзыва и наличие. Значения ключей не читали и не печатали.
Проверка не дала оснований считать действующие ключи скомпрометированными, поэтому доступы не отзывали просто ради ощущения безопасности.
Для каждого сервиса оставляли понятный рабочий путь вместо набора дублей, где один маршрут работает, а соседний ломает запуск шумной ошибкой.
Статические доступы остались в зашифрованном хранилище и передаются в дочерний процесс, а OAuth-сессии остались в собственных хранилищах приложений.
Две машины
MacBook Pro M5 был основной рабочей машиной, Mac mini M4 Pro — вторым постоянным контуром. После копирования файлов всё равно нужно было проверять версии Codex CLI, OAuth-состояние, пути к Node.js, MCP, права локальных файлов и свежий запуск.
Одинаковый `AGENTS.md` не доказывает, что Codex стартует и действует одинаково на двух машинах.
В финале обе машины запускались без ошибок авторизации, перенаправлений, отсутствующих исполняемых файлов и устаревших локальных адресов.
OAuth, локальные пути и машинные детали могут различаться. Важно совпадение правил и проверяемого поведения.
Локальные пути, аккаунты, ответы поставщиков и детали внутренней инфраструктуры не превращали в публичный материал.
Отказ от быстрых решений
По ходу работы было много соблазнов сделать быстрее: переписать файл сразу, поднять лимиты, поверить чужим разборам, экспортировать ключи глобально или объявить успех после первой машины. Все эти варианты сознательно отклонили.
Сначала исходное состояние, проверочная матрица, границы и откат; только потом изменения.
Официальные источники, собственные наблюдения и гипотезы держали отдельно.
Секреты не экспортировали глобально, OAuth не переносили в общее хранилище, действующие ключи не отзывали без признаков компрометации.
Второй компьютер прошёл отдельный путь проверки, потому что у него свои версии, сессии, пути и локальные процессы.
Результат
Главный результат не в том, что файл стал меньше. Важно, что более самостоятельная модель получила меньше постоянного шума, а человек сохранил границы, доказательства, остановки и понятный путь внедрения.
AGENTS.md сократился примерно с 70 до 18 КБ, а количество строк — с 342 до 133.
В постоянном слое остались границы безопасности, Git, секреты, dirty repo, проверки и остановки перед продакшеном.
Подробные инструкции теперь читаются тогда, когда задача действительно касается Codex-first, операций, дизайна или доступов.
MacBook и Mac mini доведены до согласованного поведения без требования искусственной побайтной одинаковости.
Источник
В статье подробнее разобраны исходная тревога, пакет работы, старая структура AGENTS.md, новая двухуровневая архитектура, проверочные сценарии, доступы, MCP, вторая машина и универсальная последовательность такой миграции.
Разборы
Разбор
Работа перестала зависеть от одного ноутбука: MacBook стал интерфейсом, Mac mini — постоянной агентной базой, iPhone — мобильными пультами, а сеть, NAS и VPN — управляемым слоем вокруг Codex.
Открыть разбор →Разбор
Идея внешней проверки стала рабочим Codex-скиллом, публичным GitHub-репозиторием и сразу прошла проверку на настоящем архитектурном риске.
Открыть разбор →Разбор
DevOps-аудит семи VPS: сначала безопасная инвентаризация и документы, потом риски, решения и точечные изменения там, где они действительно нужны.
Открыть разбор →