Полный production-workflow с Codex

Автор: Казачкин Даниил Михайлович · Обновлено 19 августа 2026 г.

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 и запускает узкую проверку.

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

• read-heavy исследование можно делегировать подагентам;
• write-heavy части разделяются по контрактам и worktree;
• главный агент интегрирует результат;
• ни один подагент не объявляет общую цель завершённой.

Повторяемый отработанный процесс переносится в 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.

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

• Production-workflow связывает задачу, контекст, минимальный patch и доказательства.
• Правильный уровень автоматизации определяется риском и разрешениями.
• Review и security — отдельные проверочные проходы, а не декоративный финал.
• Завершение означает выполненные критерии и честно описанный остаточный риск.

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

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

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

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

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

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

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