New Dialog Handoff

Переход в новый диалог

Ты выполняешь протокол безопасного handoff в свежий чат. Цель: не потерять рабочее состояние, не дублировать память и не тащить критичный контекст только в историю разговора.

Принцип

Сначала сохрани состояние в durable source of truth, потом переводи работу в новый чат. Не делай длинный пересказ беседы, если уже есть log.md, tasks.md, context.md, research-note, spec или другой канонический артефакт.

Когда применять

• Чат стал длинным и качество следующих ответов может просесть.
• Агент показывает критический хвост CTX.
• Пользователь явно просит продолжить в новом чате.
• Предстоит длинный следующий шаг: review, большой diff, большой ресёрч, многофайловая правка, длинное объяснение.

Протокол

Шаг 1. Определи, где должен жить state

Спроси себя:

• это проектная работа;
• это standalone research/knowledge;
• или уже есть готовый канонический артефакт, на который можно опереться.

Приоритет источника правды (в порядке медленные слои → быстрые, как в write-protocol.md §5):

1. существующий проектный контур — README.md → plan.md → context.md → tasks.md → log.md;
2. 01_now/ops/<contour>/delegations/<person-slug>.md — если state — это открытое делегирование;
3. 01_now/personal/tasks.md — если state — личное обязательство владельца;
4. уже созданный standalone note в 03_knowledge/;
5. 00_inbox/ — если это curiosity без проекта;
6. новый checkpoint только если без него состояние реально потеряется.

Если handoff касается активного проекта, а plan.md ещё не существует (legacy) — сначала создай plan.md из шаблона, затем фиксируй состояние уже в новом slow-layer контракте. Handoff не должен опираться только на log.md, если проект уже активный.

Шаг 2. Переиспользуй parking, а не заменяй его

Если работа относится к проекту:

• сначала выполни протокол из skills/parking/SKILL.md — он сам разведёт state по правильным файлам (plan / log / tasks / delegations / personal) согласно task-routing decision tree (см. task-routing-methodology-2026-04.md §4);
• не изобретай параллельную систему фиксации;
• в следующем чате рекомендуй вход через resume — он сам перечитает README → plan → context → tasks → log и сделает passive recall по delegations.

Если задача вне проекта, но в текущем цикле уже создан durable artifact:

• используй его как source of truth;
• отдельную handoff-память не создавай.

Если durable artifact ещё нет, а потеря контекста реальна:

• сначала создай минимальный checkpoint в правильном месте;
• только потом предлагай новый чат.

Шаг 3. Сожми handoff до restart-packet

Верни пользователю короткий пакет, максимум 5 пунктов:

Новый диалог:
- Что продолжаем: <1 строка>
- Source of truth: <1-3 файла — в порядке plan → context → tasks → log>
- Открытые делегирования: <если есть, путь к delegations/*.md>
- Следующий шаг: <1 конкретное действие>
- Старт в новом чате: <короткая команда или prompt>

Не пересказывай всю сессию. Не копируй длинный анализ. Не дублируй содержимое файлов в чат.

Шаг 4. Правило запуска нового чата

Если проектный handoff:

• рекомендованный старт: resume <проект или задача>

Если это standalone работа:

• дай paste-ready prompt:

Продолжаем <задача>. Source of truth: <пути к файлам>. Не пересказывай заново, продолжай с шага: <следующий шаг>.

Шаг 5. При критическом остатке не пытайся «дожать»

Если хвост уже критический:

• не начинай новый длинный анализ;
• не уходи в дополнительные поиски;
• сначала checkpoint/handoff;
• затем новый чат.

Ограничения

• Не держи важный state только в истории разговора.
• Не создавай новый handoff-артефакт, если достаточно parking + существующих файлов.
• Не подменяй resume; новый чат должен либо входить через resume, либо опираться на явно названные source-of-truth файлы.
• Не растягивай restart-packet: он должен быть короче обычного recap.