Двухролевой процесс Codex: от спецификации до CI

Зачем нужны две роли

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

Разделение работает только тогда, когда у ролей разные контракты. Две сессии, выполняющие одну широкую инструкцию, не создают контроля качества.

Рабочий контракт

Роль реализации получает границы задачи, критерии приёмки и перечень допустимых изменений. Роль проверки получает те же критерии, но не внутренние допущения автора. Она должна ссылаться на доказательства: тест, diff, журнал или воспроизводимый сценарий.

спецификация → реализация → независимая проверка → CI → решение человека

Что должен проверять CI

• форматирование, линтер и типы;
• unit-тесты критического поведения;
• валидацию контрактов данных;
• браузерную проверку пользовательского пути;
• фиксацию версии и ограничений.

CI не оценивает ценность продукта. Он предоставляет воспроизводимое внешнее доказательство того, что конкретная версия соответствует техническому контракту.

Типичные сценарии отказа

Первый — расширение границ задачи во время реализации. Второй возникает, когда review обсуждает стиль, но не выполняет сценарий приёмки. Третий — зелёный CI, основанный на тестах, которые не затрагивают изменённый путь.

Где паттерн полезен

Такой процесс подходит для задач с явным контрактом и проверяемым результатом. Если направление продукта ещё не определено, до добавления новых агентов требуется решение владельца.