Не summary разговора
Свободное резюме отвечает «о чём говорили». Для продолжения работы этого мало: новая сессия должна различить проверенное и предполагаемое, выполненное и только запланированное, локальный diff и уже опубликованный результат.
Минимальный handoff отвечает на восемь вопросов:
- Какова текущая цель и граница задачи?
- Что уже сделано и чем это проверено?
- Что осталось сделать?
- Где лежат доказательства: файлы, команды, issue, commit, артефакты?
- Какие решения уже приняты и где их каноническая запись?
- Какие гипотезы ещё не подтверждены?
- Что блокирует продолжение и чьё решение требуется?
- Каков один следующий безопасный шаг?
Сырые логи и transcript могут оставаться достижимыми, но не входят в brief целиком. Handoff хранит ссылки на них и ровно те фрагменты, без которых следующий шаг неоднозначен (Agent Memory, Bounded Tool Output).
Поля с разным авторитетом
Каталог вроде .ai-memory/ удобен как реализация, но его имя не задаёт семантику. Внутри оказываются артефакты с разным сроком жизни и разным правом на истину:
| Артефакт | Роль | Источник истины | Обновление |
|---|---|---|---|
architecture.md |
карта и объяснение устройства | код, проверяемые контракты и ADR | ревью вместе с изменением архитектуры |
database-schema.md |
навигация по данным | миграции или декларативная схема | лучше генерировать или ссылаться, чем копировать вручную |
decision-log.md |
почему выбран и отвергнут вариант | ADR или другой версионируемый журнал решений | append/supersede с автором и датой |
active-tasks.md |
незавершённая работа текущего захода | фактический Git/runtime state | на границе сессии, с явной датой актуальности |
| индекс прошлых сессий | поиск похожего опыта | исходные transcript/артефакты | отдельно от канонических документов |
Главная защита от «памяти, которая врёт уверенно»: handoff не копирует архитектуру, схему и решения в ещё одну независимую истину. Он указывает на их владельцев и фиксирует только состояние продолжения.
Жизненный цикл
При старте новая сессия читает handoff, затем проверяет изменчивые поля в среде: ветку и git status, существование файлов, состояние задачи, доступы и результат незавершённого побочного эффекта. Фраза «тесты прошли» без команды, времени и revision — подсказка, а не evidence.
Во время работы brief обновляют на устойчивых границах, а не после каждой мысли: завершён проверяемый этап, появилось внешнее обязательство, принято решение или обнаружен блокер.
При завершении записывают фактический остаток работы и следующий шаг. Завершённую задачу закрывают или архивируют; иначе старая active-tasks.md будет выглядеть как актуальная инструкция спустя месяцы.
При возобновлении права, approvals, арендатора, остаток бюджета и статус внешних эффектов берут из канонического управляющего состояния, а не из Markdown (Context Compaction, Agent Identity). Handoff может сослаться на approval ID, но не создаёт и не продлевает его.
Поиск по истории — дополнение, не замена
Инструмент вида search_past_sessions(query) полезен для эпизодического вопроса «сталкивались ли мы с похожим». Он не должен автоматически подмешивать найденную выжимку в системные инструкции или выдавать прошлое решение за действующее.
Рабочий порядок: поиск возвращает короткие совпадения с session ID и датой → агент открывает нужный исходный фрагмент → проверяет решение против текущего кода и ADR → только затем использует его. Индекс можно пересобрать; transcript и канонические артефакты сохраняют provenance.
Когда handoff не нужен
- новая задача не продолжает предыдущую;
- вся работа уже выражена коммитом, issue и проверяемыми критериями приёмки;
- brief почти равен полному transcript — значит граница задачи ещё не найдена;
- handoff пытаются использовать вместо checkpointer для точного runtime state (Durable Execution).
Связано с
- Context Window — reset освобождает окно, handoff возвращает ориентацию
- Context Compaction — summary остаётся в сессии, handoff переносит работу через её границу
- Agent Memory — эпизодический поиск и файловая память как внешние слои
- State Centric Execution — каноническое состояние важнее реконструкции по рассказу
- ADR — долговечные решения не должны жить только в active task