Полный production-workflow с Codex

Production-workflow объединяет все навыки трека в управляемый цикл. Его цель — не получить больше сгенерированного кода, а сократить путь от требования до доказанного, обозримого…

Краткий ответ

Production-workflow объединяет все навыки трека в управляемый цикл. Его цель — не получить больше сгенерированного кода, а сократить путь от требования до доказанного, обозримого и безопасного изменения.

Production-workflow объединяет все навыки трека в управляемый цикл. Его цель — не получить больше сгенерированного кода, а сократить путь от требования до доказанного, обозримого и безопасного изменения.

Этап 1. Подготовить задачу

До запуска агента:

1. выберите один coherent outcome; 2. запишите наблюдаемое текущее состояние; 3. назовите точку входа и релевантные материалы; 4. определите сохранённое поведение; 5. задайте автоматические и ручные критерии; 6. выберите минимальные разрешения; 7. проверьте состояние Git.

Если решение неоднозначно, начните с read-only исследования или Plan mode. Если работа долгая, превратите согласованный результат в goal с вехами.

Этап 2. Исследовать до изменения

Codex читает действующие AGENTS.md, строит путь данных, находит существующие паттерны и тесты. Внешние текущие факты проверяет по официальным источникам. Live context из GitHub, Figma или документации получает через разрешённый plugin/MCP, если он действительно нужен.

Результат исследования:

Не начинайте необратимое действие, если ключевое решение ещё является догадкой.

Этап 3. Реализовать минимально

Агент меняет ближайшую правильную границу и сохраняет пользовательский diff. После связного шага просматривает patch и запускает узкую проверку.

При параллельной работе:

Повторяемый отработанный процесс переносится в skill. Устойчивые правила репозитория — в AGENTS.md. Технически обязательная защита — в test, CI, policy или hook.

Этап 4. Доказать результат

Проверка идёт от узкого к широкому:

reproduction / failing test
→ targeted test
→ typecheck и lint
→ package or integration tests
→ production build
→ browser/API/data scenario
→ final diff review

Набор адаптируется к задаче. Для backend race важен конкурентный integration test; для layout — реальный viewport; для миграции — повторный запуск и старые данные; для auth — отрицательные сценарии.

Этап 5. Review и безопасность

Отдельный review проверяет correctness, regressions и пробелы тестов. Security-проход фокусируется на trust boundaries, authorization, input, secrets, filesystem и network.

Каждое замечание должно иметь сценарий и последствие. Принятое замечание превращается в минимальное исправление и регрессионный тест. После правок review повторяется на актуальном diff.

Публикация, commit, push, PR, deployment и изменение внешней системы выполняются только если они входят в запрос и разрешения. Локальная реализация не подразумевает автоматический deploy.

Этап 6. Передать результат

Финальный отчёт начинается с результата, а не с журнала:

Не прячьте ограничение за фразой «всё готово». Если production-контекст недоступен, скажите, что локальный результат проверен, а deployment не выполнялся.

Итоговое упражнение

Возьмите реальный баг средней сложности и проведите полный цикл:

1. составьте prompt «цель / контекст / ограничения / готово»; 2. проверьте AGENTS.md и Git status; 3. запросите read-only диагностику; 4. утвердите план; 5. выполните минимальное исправление; 6. добавьте регрессионный тест; 7. запустите проверки по риску; 8. воспроизведите пользовательский сценарий; 9. проведите correctness и security review; 10. подготовьте честный handoff без публикации.

После завершения проведите retrospective: какое правило повторялось, какой контекст был лишним, чего не хватило и следует ли обновить AGENTS.md или создать skill.

Частые вопросы

Может ли Codex выполнить весь workflow автономно?

Да, внутри ясной цели, доступов и проверяемой среды он может исследовать, менять, тестировать и ревьюить. Продуктовые решения, новые полномочия и необратимые внешние действия остаются точками контроля владельца.

Где заканчивается задача Codex?

В условии «готово, когда». Если оно включает только локальный код и тесты, push или deploy не подразумеваются. Если требуется production rollout, должны быть отдельно заданы полномочия, проверка и откат.

Как понять, что процесс стал лучше?

Измеряйте не объём промптов, а число повторных исправлений, время до воспроизводимого теста, размер нерелевантного diff, долю проверенных критериев и количество дефектов после merge.

Что важно запомнить

https://yadro-code.ru/lessons/without-university/codex-agent-workflows/codex-agent-18