Codex Session Lifecycle: безопасный перенос проверенной работы между AI coding dialogs.

Зачем вообще понадобился lifecycle для AI coding sessions

Инженерная задача живёт дольше одного окна чата

Длинная работа с Codex редко укладывается в один диалог. За несколько часов или дней появляются решения, проверенные и непроверенные изменения, активный ExecPlan, локальные ограничения, открытые вопросы и договорённости о том, чего делать нельзя. Сам чат при этом остаётся временным контейнером: он может закончиться из-за нового диалога, смены проекта или необходимости очистить контекст, хотя сама задача ещё далека от завершения.

На практике проблема проявляется не просто как «потеря памяти». Новая сессия может повторить уже выполненное исследование, выбрать старый план, забыть blocker, принять видимый UI за доказательство deployment или назвать частично проверенную работу завершённой. Чем сложнее проект, тем дороже такая ошибка: агент тратит время, размывает историю решений и иногда получает ложное ощущение прогресса.

Transcript dump не исправляет ситуацию. Большой пересказ смешивает постоянные правила, текущий статус, исторические причины и временный шум. Контекста становится больше, но следующей сессии всё равно трудно понять, что истинно сейчас, на каком evidence основан вывод и какое действие действительно должно быть следующим.

Идея решения: две стороны одного перехода

end-session закрывает работу, new-session возобновляет её

Я спроектировал lifecycle вокруг двух orchestrator skills. end-session отвечает за честное завершение текущего диалога: он дожидается активной работы, собирает результаты проверок, разделяет состояния verified, partially verified, failed, blocked и not-run, а затем обновляет только те проектные артефакты, которым действительно принадлежит найденное знание.

new-session решает обратную задачу. Он начинает не с чтения всего проекта, а с проверки корня, состояния lifecycle и компактной restart map. После этого выбирается один релевантный ExecPlan, а architecture, diary и другие слои памяти загружаются только тогда, когда они нужны текущему продолжению. Это уменьшает шум и не позволяет старой истории автоматически управлять новой работой.

Связующим контрактом служит Summarizations.md. Он записывается последним, после gated updates, поэтому отражает уже согласованное состояние: что сделано, чем проверено, что осталось, где продолжать и какие blockers нельзя скрывать. Это не полный transcript, не новый backlog и не разрешение выполнять внешние или разрушительные действия.

Почему одного summary skill было недостаточно

Память должна иметь владельцев и разные уровни долговечности

У проекта нет одной универсальной «памяти». Инструкции репозитория, архитектурные контракты, дневник решений, активный план, переиспользуемые lessons и краткий handoff отвечают на разные вопросы. Если записывать всё в один файл, временная деталь легко превращается в постоянное правило, а локальный workaround начинает выглядеть как архитектурное решение.

Поэтому orchestrators не пытаются заменить остальные инструменты. Они вызывают специализированные skills для project diary, architecture, ExecPlans, repository guidance, verification и promotion действительно переиспользуемых lessons. Каждый слой получает собственный gate: запись происходит только при наличии нового durable knowledge и только в артефакт, который этим знанием владеет.

В публичную систему вошли 16 полных skill folders. Помимо new-session иend-session, в ней есть skills для создания и обновления ExecPlan, чтения и записи project diary, обновления архитектуры, подготовки repository instructions, verification gate, summarization и четырёх режимов context diagnostics: fundamentals, degradation, optimization и compression.

Как выглядит завершение сессии

Сначала evidence, затем durable updates, handoff — последним

Завершение начинается с определения фактического состояния работы. Если выполняется build, deployment или асинхронная проверка, lifecycle не должен преждевременно фиксировать результат. После этого один консервативный verification verdict переиспользуется во всех downstream updates, чтобы plan, diary и handoff не расходились в формулировках.

Затем система решает, что действительно нужно сохранить. Изменение публичного API может требовать architecture update; важное проектное решение — diary entry; незавершённый milestone — обновление ExecPlan. Если долговечного знания нет, соответствующий файл не меняется. Такой default-to-no-change защищает проект от бесконечного накопления пересказов.

Только после этих шагов создаётся restart map. Она содержит текущую цель, подтверждённый результат, незакрытые проверки, точный continuation point и релевантные пути. Благодаря этому следующая сессия получает не историю разговора, а операционную карту продолжения.

Как начинается следующая сессия

Минимально достаточный контекст вместо полного сканирования проекта

На старте new-session проверяет, что работа ведётся в ожидаемом project root, а найденный handoff действительно относится к этому проекту и ещё не закрыт. Затем skill определяет активный план и читает только те документы, без которых нельзя безопасно выполнить ближайший шаг.

Этот порядок важен для context engineering. Architecture полезна, когда меняются контракты или runtime flows; diary — когда нужно восстановить причины решения; repository guidance — когда действуют локальные правила. Загружать все слои на каждый запрос дорого и создаёт конкуренцию между актуальным заданием и историческими деталями.

Lifecycle также сохраняет границу полномочий. Запись о прошлом deployment не разрешает новый deployment, а старое намерение удалить файл не становится действующей командой. Handoff передаёт состояние и evidence, но не расширяет scope пользователя.

Инженерные границы и privacy

Публичная система не должна переносить приватный проект вместе с методологией

При подготовке open-source версии было важно отделить универсальный workflow от содержимого реальных проектов. В репозиторий не включаются credentials, секреты, приватные URLs, локальные абсолютные пути, внутренние артефакты и project-specific данные. Публикуется контракт поведения skill и необходимые емуagents/, references/ и scripts/, а не пользовательская память.

Ещё одна граница касается утверждений. Система может доказать, что репозиторий существует, skills опубликованы, atlas собирается и production route отвечает. Она не доказывает массовое adoption, поисковые позиции или универсальный процент экономии времени. Поэтому кейс фиксирует только проверяемые результаты и отделяет их от ожидаемой практической пользы.

Что получилось в итоге

Исходный код для внедрения и atlas для понимания всей системы

Результат опубликован на двух взаимодополняющих поверхностях. GitHub-репозиторий содержит все 16 skills и позволяет изучить точные инструкции, gates и supporting files. Интерактивный Vite + React atlas показывает систему сверху: фазы lifecycle, dependency graph, владельцев артефактов, privacy boundaries и путь данных от завершения одной сессии до старта следующей.

Для разработчика это reference implementation, которую можно разбирать по частям. Можно начать только с парыnew-session / end-session, а затем подключать planning, diary, architecture или context diagnostics по мере роста проекта. Ценность подхода не в обещании идеальной памяти, а в том, что забывание, проверка и продолжение становятся явными инженерными процессами.

Проверенный результат

Что подтверждено на момент публикации

• Публичный GitHub-репозиторий доступен в ветке main и содержит 16 заявленных skill directories.
• Чистый checkout интерактивного atlas проходит npm run build и npm run test:sites: 4/4 tests.
• Production atlas отвечает по адресу /end-new/ и загружает assets из правильного base path.
• Публичный workflow по контракту исключает credentials, private project artifacts и local absolute paths.

Изучить систему можно в интерактивном atlas ↗, а скачать и проверить исходники — в публичном GitHub-репозитории ↗. Связанный материал о долговечной проектной памяти: Architecture Update: Project Memory for Codex.