Переезд в новый чат: handoff контекста

Текущий чат переполнен (или близко к этому). Не начинай новый «с нуля» — это потеря всего что мы поняли. Сгенерируй один артефакт-handoff, после которого новая сессия будет знать столько же, сколько ты сейчас.

Текущий фокус: {{session_focus}} Цель нового чата: {{next_session_goal}} Куда писать: {{project_path}}/HANDOFF.md

Когда переезжать (сигналы)

Не жди катастрофы. Переезжай при любом из:

• Контекст ≥ 80% (видно по индикатору или по поведению)
• Чувствуется «дежавю»: повторяю то, что обсуждали в начале
• Просьба «напомни что мы решили» — это симптом compaction'а съевшего важное
• Замедление ответов или их укорочение без причины
• Большая задача завершилась — естественный момент для свежего старта, даже если контекст ещё не полный

Что собрать в HANDOFF (контрольный список)

Не «всё что было», а именно эти 9 категорий:

1. Что это

1-2 предложения про проект. Кто юзер, что строим, главная ценность. Это контекст для новичка, не для тебя.

2. Стек и версии

Точные версии (Next.js 16.2.6, React 19, и т.д.). Не «современный фронтенд» — конкретика. Особенно важны breaking changes от обычного знания (например «это не тот Next.js что в твоих данных»).

3. Цифры в моменте

Таблица: сколько чего сейчас (страниц, файлов, юзеров, промтов, и т.п.). Это якорь — новый чат сразу видит масштаб.

4. Структура файлов (что где живёт)

Только важное. Не ls -R. Где промты, где компоненты, где деплой-скрипты. С пояснением зачем каждая папка.

5. Дизайн-токены и конвенции

Если есть. Цвета, шрифты, размеры. Какие правила нарушать НЕЛЬЗЯ.

6. Что сделано (с числами и URL)

• ✓ Список реализованных фич
• Метрики до/после, если меряли
• Ссылки на прод
• Закрытые задачи помечать зачёркиванием + что закрыло

7. Что НЕ сделано / open items

Открытые задачи, известные ограничения, технический долг. Каждое — с почему (зачем оставили, что блокирует).

8. Команды (copy-paste готовые)

Локальные: dev, build, type-check. Деплой: полный rsync/ssh оneliner. Smoke: curl-команды для проверки прода. Откат: что делать если что-то сломалось.

9. Стиль общения с юзером

• На каком языке
• Tone (формальный/неформальный, на «ты»)
• Что любит / не любит (длинные объяснения? эмодзи? уточняющие вопросы?)
• Какие skills использует (TodoWrite, brainstorming, и т.п.)
• Красные линии (что НЕ трогать без согласия)

10. Что делать на старте новой сессии

3-5 шагов: что прочитать первым, что прогнать (smoke, lighthouse), что спросить.

Формат

Markdown-файл HANDOFF.md в корне проекта. Структура:

# <Имя проекта> — Handoff

> Читай это прежде чем что-то трогать. Здесь полный контекст: где мы, куда дальше, что нельзя.

## 1. Что это
## 2. Стек
## 3. Цифры
## 4. Структура файлов
## 5. Токены / конвенции
## 6. Реализованные фичи
## 7. Что НЕ сделано
## 8. Команды
## 9. Стиль общения
## 10. Что делать на старте новой сессии

---
**Последнее обновление:** <дата + краткая суть итерации>

История итераций (если есть несколько):
- **Iter 1:** что сделано, метрики
- **Iter 2:** ...

Размер цель: 300-500 строк. Меньше = недостаточно. Больше = ты перетаскиваешь шум, новый чат всё равно не прочитает.

Шаги выполнения

В старом чате (текущий)

1. Прогенерируй HANDOFF.md по шаблону выше. Используй точные числа, не приблизительные.
2. Сделай smoke прода: curl ключевые URL, убедись что цифры в HANDOFF матчат реальности.
3. Сохрани файл. Если работаем через git — закоммить (но HANDOFF можно держать .gitignored, как контекст-документ).
4. Скажи юзеру: «HANDOFF.md готов, можно открывать новый чат с фразой...» и дай ему точную starter-фразу для нового чата.

Starter-фраза для нового чата (шаблон)

Переключаюсь с переполненного чата на проекте «<имя>».

Локально: <путь>
Прод: <URL>
Контекст: HANDOFF.md в корне (<число> строк)

Шаги:
1. Прочитай HANDOFF.md целиком
2. Smoke прода: curl <health-URL>
3. Краткий аудит (≤ 200 слов): что заметил
4. Предложи план следующей итерации

Стиль из HANDOFF.md секция 9. Готов начинать.

В новом чате

1. Первым делом — Read HANDOFF.md (не выборочно, целиком).
2. Smoke прода как написано в HANDOFF.md секция 8.
3. Краткий отчёт юзеру: «понял, готов делать X / есть ли уточнения».
4. Не предлагать переделывать то, что в HANDOFF помечено как «не трогать без согласия».

Anti-patterns (НЕ делать)

• ❌ Дамп всего чата. HANDOFF — это дистиллят, не транскрипт. 80% разговоров в чате не нужны новому чату.
• ❌ Дублировать то, что в коде. Новый чат читает код. HANDOFF — это то, чего в коде нет: решения, причины, контекст, стиль юзера.
• ❌ «Возможно», «кажется», «думаю». Только факты. Если не уверен — проверь и зафиксируй точное.
• ❌ Забыть стиль общения. Если юзер не любит эмодзи и говорит на «ты» — без этого в HANDOFF новый чат будет инородным телом.
• ❌ Оставить стале данные. Цифры на момент закрытия чата, не «изначальные». Прогнать smoke перед сохранением.
• ❌ Скрыть факапы. Если что-то не сработало (попробовали и забросили) — это самое ценное для нового чата, иначе он повторит ту же ошибку.
• ❌ Откладывать. Когда контекст переполнен — уже поздно качественно собрать HANDOFF, ответы становятся хуже. Делать заранее.

Что НЕ нужно класть в HANDOFF

• Reasoning по каждому маленькому решению (если решение в коде — пусть код говорит)
• Шутки/реплики
• Промежуточные неудачные попытки (только финальное + одна строка «пробовали X, отказались потому что Y»)
• Полные тексты файлов (только ссылки + ключевые куски)

Когда повторить

HANDOFF — живой документ. Обновляй:

• В конце каждой большой итерации
• Перед переездом в новый чат (последний апдейт)
• Если юзер сменил приоритеты (новая «цель нового чата» → проапдейтить старую)

Один и тот же HANDOFF может пережить 5-10 переездов между чатами, если его обновлять.