code-breaking-changes

code-breaking-changes — узкий навык OpenAI для поиска несовместимых изменений в тех интерфейсах, от которых зависят внешние пользователи и существующие сценарии Codex. Его полезно подключать к ревью до выпуска изменения, когда важно понять не только то, компилируется ли код, но и сохраняется ли договорённость с уже работающими клиентами, командами и сохранёнными состояниями. Навык задаёт четыре обязательные области проверки: app-server API, параметры CLI, загрузку конфигурации и возобновление сессий из существующих rollout. Это не общий аудит стиля и не поиск любой ошибки; фокусом остаются integration surfaces и риск breaking change. Для app-server API проверка должна охватить внешний контракт сервера: изменения в доступных операциях, входных данных и результате могут нарушить клиент, который ещё использует прежнюю форму взаимодействия. Важно рассматривать не только удаление метода. Изменение имени, обязательности или смысла внешнего поля также нужно сопоставить с тем, как API вызывается и как ответ разбирается потребителем. Такой взгляд помогает отделить внутренний рефакторинг от изменения публичной поверхности. Если API используется несколькими процессами или версиями клиента, ревью должно пройти по каждой затронутой точке интеграции и зафиксировать, какая именно часть старого поведения больше не гарантируется. Параметры CLI образуют отдельный контракт. Проверяется, какие аргументы и флаги принимаются командой, как они передаются в запуск и какие существующие команды продолжают работать. Особое внимание нужно уделять переименованию, исчезновению и изменению способа передачи параметра: пользователь может вызывать CLI напрямую, хранить команду в скрипте или передавать её через другой инструмент. Совместимость здесь означает сохранение ожидаемого запуска для существующих вызовов либо явное обнаружение места, где потребуется миграция. Навык не ограничивает ревью конкретным языком или конкретным тестовым фреймворком — он предлагает проследить внешнюю командную поверхность целиком. Загрузка конфигурации проверяется как самостоятельный integration surface. В ревью нужно сравнить, какие настройки читаются, в каком месте жизненного цикла они загружаются и как изменение загрузки влияет на ранее сохранённые или автоматически созданные конфигурации. Если существующий rollout зависит от конкретной настройки, её исчезновение или изменение смысла может проявиться не при обычном старте, а только при восстановлении. Поэтому конфигурационный путь нельзя считать безопасным лишь потому, что новый чистый запуск проходит. Четвёртая область — resume-сценарии для существующих rollout. Навык требует искать изменения, из-за которых сохранённая сессия перестаёт возобновляться, иначе интерпретируется или теряет нужные данные. Проверка должна начинаться с уже существующего состояния и пройти весь путь восстановления, а не только проверить создание нового rollout. Важен сам факт совместимости старого состояния с новым кодом: именно на границе версий чаще всего обнаруживается breaking change, который не виден в свежем smoke-тесте. Работа не заканчивается после первой найденной проблемы. После каждого сигнала нужно продолжить анализ остальных трёх поверхностей, связать наблюдение с конкретным изменением и отделить настоящий внешний контракт от внутренней детали реализации. В результате получается полный список мест, где изменение может сломать app-server API, CLI, конфигурацию или resume, с приоритетом для фактически затронутых интеграций. Навык не обещает автоматически исправить несовместимость и не подменяет проверку конкретного проекта: его задача — не пропустить соседний breaking change после первой находки и направить code review на все четыре внешних пути.