Checkpoints и /rewind: откат сессии

1. Checkpoint — это не коммит

Checkpoint легко спутать с Git-коммитом: «сохранили состояние — можно вернуться». Но слои разные: checkpoint живёт внутри Claude session, а коммит — в истории проекта.

В длинной сессии Claude копит рабочую историю: прочитанные файлы, гипотезы, правки, упавшие тесты. Свернул не туда — нужна развилка назад. Checkpoint и есть такая точка, а /rewind — возврат к ней. Имя команды может меняться от версии к версии, поэтому проверяйте актуальное поведение через /help. Идея стабильна: это session-level recovery, а не замена version control.

Пример из Commerce OS. Вы рефакторите refund-flow: task spec есть, тесты зелёные, scope ограничен refund-логикой. Просите вынести часть в сервис — а Claude заодно «улучшает архитектуру»: тащит логику в utility, трогает шесть файлов, ломает три теста. Писать поверх хаоса промпт дороже, чем вернуться к здоровой точке.

Checkpoint A: refund-flow в исходном scope
Tests: green
Claude: выносит логику слишком широко
Result: изменены 6 файлов, 3 теста красные
/rewind
=> возвращаемся к Checkpoint A

Важна не команда, а привычка: ветка пошла не туда — вернитесь к последней здоровой точке, не стройте этаж ошибок поверх старого.

2. Зона действия /rewind внутри сессии

/rewind откатывает только состояние текущей сессии, не «реальность целиком». В этом и сила, и граница.

Откатывается ветка разговора: из контекста уходит неудачная цепочка гипотез, решений, действий. Правки в файлах внутри сессии часто откатываются вместе с ней. Иногда rewind — это возврат к конкретной точке рассуждения, чтобы пойти другой веткой с уточнёнными границами.

Полезно держать в голове такую таблицу:

Здесь важный нюанс: «часто да», а не «всегда и гарантированно». Курс не завязан на конкретную версию, поэтому мы не строим лекцию на обещаниях о поведении каждой. Правильная взрослая позиция такая: /rewind — хороший инструмент для возврата внутри текущей сессии, но важные границы всё равно закрепляются Git и осознанными milestone points.

После отката очень полезно не просто повторить старую команду, а слегка перенастроить курс. Например, так:

Откатимся к checkpoint перед extract.
Сохраним scope: refund-flow only.
Не выноси логику в общий utility.
Сначала предложи минимальный план на 2 шага.

Обратите внимание на тон. Здесь нет паники и нет длинной эмоциональной переписки с моделью в духе «ты опять всё испортил». Вы просто вернули рабочую точку и заново задали границы. Это намного профессиональнее и, честно говоря, намного дешевле по времени и нервам.

3. Границы власти /rewind

Самая опасная ошибка вокруг /rewind — ждать от него больше, чем он вообще может дать. Это не кнопка «откатить мир». Это кнопка «вернуть назад текущую ветку сессии». Как только последствия вышли за пределы состояния сессии и попали в проектную историю или во внешние системы, начинает работать уже не /rewind, а другой механизм возврата.

Вот здесь разница становится особенно важной:

/rewind

Если Claude уже сделал изменения, которые вы успели оформить как коммит, особенно если этот коммит уже ушёл в общую историю, рассчитывать на /rewind нельзя. Даже если какая-то версия продукта умеет «отматывать» локальное состояние сессии довольно глубоко, инженерно правильная граница здесь проходит по Git. Там уже живёт история проекта, а не просто история разговора.

То же самое с внешними побочными эффектами. Допустим, в ходе эксперимента Claude запустил миграцию схемы PostgreSQL в нашем Commerce OS или вызвал команду, которая отправила реальный запрос во внешнюю систему. /rewind может убрать из разговора обсуждение этой команды, но не вернёт базу данных в предыдущее состояние и не отменит внешний эффект. Был бы мир слишком прекрасным, если бы всё работало именно так, но увы — нет.

Поэтому полезно запомнить почти грубую, но очень рабочую формулу: /rewind не лечит последствия, которые уже успели стать частью внешнего мира. Если вы уже что-то сделали по-настоящему, откатывать придётся там, где это действие реально произошло. Для Git — в Git. Для базы — миграцией назад, бэкапом или другой процедурой восстановления. Для деплоя — отдельным планом отката. И именно поэтому в длинных задачах так важны stop points: чем раньше вы замечаете плохую ветку, тем выше шанс, что она ещё живёт только внутри сессии, а не в боевом окружении.

4. Признаки того, что пора нажимать /rewind

У многих начинающих есть соблазн «додавить» модель словами. Она ушла не туда, а вы начинаете поверх этого строить всё новые уточнения: «не так», «нет, только этот файл», «верни предыдущую логику», «не трогай controller», «почему ты изменил config». И через несколько ходов сессия уже напоминает спор в семейном чате о ремонте кухни: формально все говорят об одном, но никто уже не помнит, с чего всё началось.

Хороший момент для /rewind обычно узнаётся по нескольким симптомам сразу. Claude начинает опираться на гипотезу, которую вы уже отвергли. Diff внезапно расползается далеко за рамки scope. Вместо одной аккуратной правки появляются латки на латках: одна красная проверка исправлена ценой двух новых проблем. Или, что особенно показательно, вы ловите себя на мысли: «Я уже не хочу разбираться, что он тут сделал». Если вам не хочется читать diff, это почти всегда знак, что пора не дописывать очередной промпт, а вернуться к чистой точке.

Есть ещё один очень честный индикатор. Если вы уже второй или третий раз откатываетесь к одной и той же точке, а потом Claude снова уходит в ту же неправильную сторону, проблема, скорее всего, не в том, что он «плохо запомнил». Проблема в task spec, в evidence или в слишком расплывчатом ограничении. Иными словами, третий /rewind к одной и той же развилке — не стратегия, а диагноз. Значит, надо переписать постановку задачи, сузить scope, явно запретить опасное направление или вообще открыть fresh session с более чистым вводом.

Здесь полезен такой рабочий ритм. Сначала вы спокойно смотрите на текущее состояние: что изменилось, какие тесты упали, вышли ли мы за scope. Если проблема локальна и ещё не закреплена в Git или во внешней системе, /rewind — хороший выбор. После отката вы не продолжаете с того же расплывчатого места, а заново формулируете следующую попытку точнее. И если после этого всё равно возникает то же самое искажение, значит, нужен не ещё один rewind, а более серьёзная коррекция входных данных.

Это звучит очень по-взрослому, но на практике даёт удивительно бытовой эффект: вы просто меньше злитесь на инструмент и быстрее возвращаете контроль себе.

5. Сценарий в Commerce OS: refactor refund-flow

Чтобы это не оставалось абстракцией, давайте пройдём короткий, но реалистичный сценарий. У нас есть задача в Commerce OS: вынести decision logic refund-потока из контроллера в сервис. Scope узкий, public API трогать нельзя, интеграцию с payment provider не трогаем. После прошлой лекции у нас уже есть именованная сессия и milestone summary, так что стартовая точка хорошая.

Вы просите Claude сделать аккуратный extract. Он читает код, а потом предлагает слишком смелое решение: кроме сервиса, создаёт общий utility для money rules, выносит туда логику, затрагивает соседний модуль approvals и заодно переименовывает пару методов «для единообразия». Звучит даже умно. Но по факту scope уже уехал, а тесты по approval-ветке стали красными. Вот здесь самый частый промах — начать просить: «поправь только approval», «верни старое имя метода», «utility оставь, но не меняй controller». И через три хода вы уже живёте внутри Frankenstein-diff.

Гораздо здоровее сделать так: откатиться к checkpoint перед неудачной веткой и сформулировать новую попытку уже как минимальную трансформацию.

Вернёмся к точке до широкого extract.
Нужен только RefundService.
Не создавать utility-классы и не менять approvals.
Сначала вынеси одну функцию и покажи diff.

Теперь Claude получает не просто «сделай снова», а чёткий коридор. После этого очень полезно проверить: действительно ли он изменил только нужный файл или файлы, действительно ли тесты вокруг refund-flow остались осмысленными, не затронул ли он соседние контракты. Если да — отлично, вы продолжаете. Если нет — по крайней мере, снова откатываетесь к чистой точке, а не к уже перепутанной смеси двух неудачных подходов.

И вот здесь становится видно, почему checkpoints так тесно связаны с дисциплиной из прошлой лекции. Хороший checkpoint — не случайность. Он появляется там, где у вас уже был понятный milestone, зелёные тесты и короткое резюме того, что считается нормальным состоянием. Если вы дошли до середины огромной грязной сессии без stop points, даже удачный rewind часто возвращает вас не к «хорошему месту», а просто к более раннему хаосу. Так что /rewind особенно хорошо работает у аккуратных разработчиков. Несправедливо, но закономерно.

6. Выбор: /rewind, fresh session или другой откат

Когда вы уже немного поработали с длинными задачами, у вас появляется новое умение: быстро определять, где вообще сейчас живёт проблема. Это почти важнее самой команды. Потому что технически зрелый разработчик отличается не тем, что знает больше флагов, а тем, что понимает, какой слой сломан.

Полезно мысленно проходить короткий фильтр. Если проблема находится внутри текущей ветки разговора, reasoning уехал не туда, а проектная история ещё не затронута всерьёз, вам подходит /rewind. Если сама идея сессии уже засорилась старыми гипотезами, но файловое состояние проекта в целом нормальное, часто лучше fresh session с коротким, чистым summary. А если изменения уже стали частью Git history или, тем более, внешних систем, откат делается не в Claude conversation, а в соответствующем слое.

Это можно держать как маленькую шпаргалку:

/rewind

И последнее, что стоит запомнить из этой лекции. Лучший /rewind — тот, для которого вы заранее подготовили место посадки: точку после зелёных проверок и milestone, до рискованного эксперимента, с ясным scope. Тогда откат — не авария, а обычное движение: ветка неудачная, возвращаемся к здоровой точке и идём аккуратнее.

Так Claude Code перестаёт казаться непредсказуемым — это инструмент в руках того, кто понимает, где кончается сессия и начинается история проекта.

1

Задача

Claude code, 6 уровень, 1 лекция

Недоступна

Git baseline перед risky session

Git baseline перед risky session

Открыть

1

Задача

Claude code, 6 уровень, 1 лекция

Недоступна

Временная правка и session rewind

Временная правка и session rewind

Открыть