session-handoff — передача состояния сессии/контура

Долгоживущие контуры (роли: надзорный, Радон, моделирование, ...) переживают /clear, компакции контекста, закрытие линий работы, а иногда — клонирование одной роли на несколько машин (десктоп + ноутбук). Хендофф — документ, который следующая сессия читает ПЕРВЫМ ДЕЛОМ вместо того, чтобы восстанавливать состояние по догадке. Плохой хендофф хуже отсутствующего: он выглядит авторитетно и заставляет действовать по неактуальному или чужому плану.

Конкретный инцидент, из которого вырос этот скилл (09.08.2026, контур надзорный): ноутбучный клон роли прочитал SESSION-STATE.md и handoff_*.md в общей GDrive-папке и принял их за собственный устаревший план — файлы на деле писала ДЕСКТОПНАЯ сессия той же роли («старший брат»). Причина — в файлах не было явно указано, чья это сессия. Разбор — [[censor-laptop-clone]] в памяти контура на ноутбуке.

Когда писать

• Явная команда оператора, любой формулировкой — не только буквальные «хендофф»/«state»: «напиши хендофф», «сделай хендофф», «оформи хендофф», «подготовь передачу сессии», «сохрани state», «сохрани session state», «обнови SESSION-STATE», «готовлюсь к /clear», «закрываю линию», «передай контекст следующей сессии», «snapshot состояния контура», «session handoff», а также непрямые формулировки того же намерения: «на чём мы остановились», «продолжим позже», «сохрани, что нужно знать по проекту», «закругляемся», «запиши для следующего раза», «зафиксируй, что сделано».
• Закрытие значимой линии работы (публикация, мердж, завершение этапа).
• Порог контекста ≥80% в контуре, который предполагает продолжение — срабатывает молча, без команды оператора (порог пересчитан #CTX-1 2026-08-14 под 1M-окно Claude 5; было 60% из 200k-эпохи).
• Периодически в долгоживущих контурах — по решению агента, не реже раза на значимый отрезок работы, если сессия может прерваться без предупреждения.

Границы с соседними скиллами

• md-doc — вёрстка и типографика ЛЮБОГО markdown-документа, включая готовый хендофф. Используются ВМЕСТЕ: сюда — за структурой и обязательными полями, в md-doc — за версткой поверх готовой структуры (как пара rn-article-style↔md-doc). Просьба «сделай справку с открытыми задачами» бьёт по обоим — не давать md-doc подменить структуру хендоффа версткой без обязательных полей.
• workflow — бутстрап AGENTS.md и ролей для НОВОГО проекта/контура. Здесь — продолжение УЖЕ существующей сессии/роли, не создание новой.
• Проверка фактов внутри хендоффа перед отправкой/публикацией — по общеконтурному правилу пред-отправочной верификации (~/.claude/CLAUDE.md), не отдельный шаг этого скилла.

Обязательные поля — без них хендофф не годен

1. Владелец. Чья это сессия/машина/профиль писала файл — явно, именем машины/профиля, не только путём. Если роль клонирована на нескольких машинах — указать, к какой из копий относится ИМЕННО ЭТОТ файл. Смешение владения — подтверждённый источник ошибок (см. инцидент выше).
2. Дата написания + правило устаревания. ISO-дата в заголовке. Явный порог (по умолчанию 7 дней): «если дата выше устарела на N дней — предупреждать оператора, не действовать как по актуальному плану».
3. Только проверенное. Не писать по памяти сессии — только то, что реально сделано и проверяемо (SHA коммита, путь файла, URL, номер строки). То же правило, что в пред-отправочной верификации: вспомненное — гипотеза, прочитанное — факт.
4. Абсолютные пути. Все пути — полные, от диска. Относительные ссылки бесполезны для сессии с другим рабочим каталогом.
5. Открытые задачи с приоритетом и статусом. Не список, а таблица: что можно трогать сразу, что monitor-only, что ждёт явного «да» оператора.
6. Триггеры обновления самого файла. Когда перезаписывать в следующий раз — иначе хендофф молча гниёт и вводит в заблуждение вместо того, чтобы помогать.

Структура (шаблон)

Полный шаблон с плейсхолдерами — references/template.md. Обязательные разделы:

1. Заголовок: роль/контур + дата + владелец (машина/профиль).
2. Правило устаревания (одна строка, дословно, сразу под заголовком).
3. Роль и правила — ссылки на CLAUDE.md/скиллы, определяющие поведение контура.
4. Первые шаги при старте — что должна сделать читающая сессия, до работы.
5. Открытые задачи — таблица (номер, задача, приоритет, статус).
6. Что сделано в предыдущей сессии — конкретика с датами/SHA/путями, не пересказ.
7. Ключевые пути — таблица, абсолютные.
8. Security/приватность инварианты — если применимо к контуру.
9. Триггеры обновления этого файла.
10. Следующий шаг — что делать сессии, которая это читает, прямо сейчас.

Антипаттерны

• Хендофф без явного владельца — прямой путь к путанице между клонами роли на разных машинах (реальный инцидент, не гипотетический).
• Хендофф без даты и порога устаревания — читатель не может решить, доверять ли плану.
• Пересказ по памяти вместо конкретики (коммит/путь/URL/номер строки).
• Один файл на несколько ролей/сессий без разметки, кто за какой раздел отвечает.
• Хендофф, который никто не обновляет — триггеры обновления должны реально срабатывать, не быть декларацией.
• Хендофф как история изменений (changelog) — это состояние ДЛЯ ПРОДОЛЖЕНИЯ работы, не журнал всего, что происходило.

Формат

Markdown. Для читаемости/печати оператором — прогнать через md-doc (абзацы одной строкой, HTML-версия при необходимости); обычный рабочий хендофф для чтения другой сессией HTML-версии не требует.