Checkpoints і /rewind: відкат сесії

1. Checkpoint — це не коміт

Checkpoint легко сплутати з Git-комітом: «зберегли стан — можна повернутися». Але шари різні: checkpoint живе всередині Claude session, а коміт — в історії проєкту.

У довгій сесії Claude накопичує робочу історію: прочитані файли, гіпотези, правки, тести, що впали. Звернули не туди — потрібна розвилка назад. Checkpoint і є така точка, а /rewind — повернення до неї. Назва команди може змінюватися від версії до версії, тож перевіряйте актуальну поведінку через /help. Ідея стабільна: це відновлення на рівні сесії, а не заміна системи контролю версій.

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

Checkpoint A: refund-flow у початковому scope
Тести: зелені
Claude: занадто широко виносить логіку
Результат: змінено 6 файлів, 3 тести червоні
/rewind
=> повертаємося до Checkpoint A

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

2. Зона дії /rewind всередині сесії

/rewind відкочує тільки стан поточної сесії, не «реальність цілком». У цьому і сила, і межа.

Відкочується гілка розмови: з контексту зникає невдала ланка гіпотез, рішень, дій. Правки у файлах усередині сесії часто відкочуються разом із нею. Іноді rewind — це повернення до конкретної точки міркування, щоб піти іншою гілкою з уточненими межами.

Корисно тримати в голові таку таблицю:

Тут важливий нюанс: «часто так», а не «завжди і гарантовано». Курс не прив’язаний до конкретної версії, тож ми не будуємо лекцію на обіцянках щодо поведінки кожної. Правильна доросла позиція така: /rewind — добрий інструмент для повернення всередині поточної сесії, але важливі межі все одно закріплюються Git і усвідомленими контрольними точками.

Після відкату дуже корисно не просто повторити стару команду, а трохи переналаштувати курс. Наприклад, так:

Відкотімося до checkpoint перед extract.
Збережімо scope: лише refund-flow.
Не винось логіку в спільний utility.
Спочатку запропонуй мінімальний план із 2 кроків.

Зверніть увагу на тон. Тут немає паніки і немає довгого емоційного листування з моделлю в дусі «ти знову все зіпсував». Ви просто повернули робочу точку і знову задали межі. Це набагато професійніше і, якщо чесно, набагато дешевше за часом і нервами.

3. Межі влади /rewind

Найнебезпечніша помилка навколо /rewind — чекати від нього більше, ніж він взагалі може дати. Це не кнопка «відкотити світ». Це кнопка «повернути назад поточну гілку сесії». Щойно наслідки вийшли за межі стану сесії та потрапили в історію проєкту або у зовнішні системи, починає працювати вже не /rewind, а інший механізм повернення.

Ось тут різниця стає особливо важливою:

/rewind

Якщо Claude уже зробив зміни, які ви встигли оформити як коміт, особливо якщо цей коміт уже пішов у спільну історію, розраховувати на /rewind не можна. Навіть якщо якась версія продукту вміє «відмотувати» локальний стан сесії досить глибоко, інженерно правильна межа тут проходить по Git. Там уже живе історія проєкту, а не просто історія розмови.

Те саме з зовнішніми побічними ефектами. Припустімо, під час експерименту Claude запустив міграцію схеми PostgreSQL у нашому Commerce OS або викликав команду, яка надіслала реальний запит до зовнішньої системи. /rewind може прибрати з розмови обговорення цієї команди, але не поверне базу даних у попередній стан і не скасує зовнішній ефект. Світ був би надто прекрасним, якби все працювало саме так, але, на жаль, ні.

Тому корисно запам’ятати майже грубу, але дуже робочу формулу: /rewind не лікує наслідки, які вже встигли стати частиною зовнішнього світу. Якщо ви вже щось зробили насправді, відкотити доведеться там, де це дія реально відбулася. Для Git — у Git. Для бази — міграцією назад, резервною копією або іншою процедурою відновлення. Для розгортання — окремим планом відкату. І саме тому в довгих задачах такі важливі точки зупинки: чим раніше ви помічаєте погану гілку, тим вищий шанс, що вона ще живе тільки всередині сесії, а не в бойовому середовищі.

4. Ознаки того, що час натискати /rewind

У багатьох початківців є спокуса «дотиснути» модель словами. Вона пішла не туди, а ви починаєте поверх цього будувати все нові уточнення: «не так», «ні, тільки цей файл», «поверни попередню логіку», «не чіпай controller», «чому ти змінив config». І через кілька ходів сесія вже нагадує суперечку в сімейному чаті про ремонт кухні: формально всі говорять про одне, але ніхто вже не пам’ятає, з чого все почалося.

Гарний момент для /rewind зазвичай упізнається за кількома симптомами одразу. Claude починає спиратися на гіпотезу, яку ви вже відкинули. Diff раптово розповзається далеко за межі scope. Замість однієї акуратної правки з’являються латки на латках: одну червону перевірку виправлено ціною двох нових проблем. Або, що особливо показово, ви ловите себе на думці: «Я вже не хочу розбиратися, що він тут зробив». Якщо вам не хочеться читати diff, це майже завжди знак, що час не дописувати черговий промпт, а повернутися до чистої точки.

Є ще один дуже чесний індикатор. Якщо ви вже вдруге або втретє відкочуєтеся до однієї й тієї самої точки, а потім Claude знову йде в той самий неправильний бік, проблема, найімовірніше, не в тому, що він «погано запам’ятав». Проблема в task spec, у evidence або в занадто розпливчастому обмеженні. Інакше кажучи, третій /rewind до однієї й тієї самої розвилки — не стратегія, а діагноз. Отже, треба переписати постановку задачі, звузити scope, явно заборонити небезпечний напрям або взагалі відкрити нову сесію з чистішими вхідними даними.

Тут корисний такий робочий ритм. Спочатку ви спокійно дивитеся на поточний стан: що змінилося, які тести впали, чи вийшли ми за scope. Якщо проблема локальна і ще не закріплена в Git або у зовнішній системі, /rewind — добрий вибір. Після відкату ви не продовжуєте з того самого розпливчастого місця, а заново формулюєте наступну спробу точніше. І якщо після цього все одно виникає те саме спотворення, значить, потрібен не ще один rewind, а серйозніша корекція вхідних даних.

Це звучить дуже по-дорослому, але на практиці дає напрочуд буденний ефект: ви просто менше злитеся на інструмент і швидше повертаєте контроль собі.

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

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

Ви просите Claude зробити акуратний extract. Він читає код, а потім пропонує занадто сміливе рішення: окрім сервісу, створює спільний utility для money rules, виносить туди логіку, зачіпає сусідній модуль approvals і заодно перейменовує пару методів «для єдності». Звучить навіть розумно. Але фактично scope уже поїхав, а тести по approval-гілці стали червоними. Ось тут найчастіший промах — почати просити: «виправ тільки approval», «поверни старе ім’я методу», «utility залиш, але не змінюй controller». І через три ходи ви вже живете всередині Frankenstein-diff.

Набагато здоровіше зробити так: відкотитися до checkpoint перед невдалою гілкою і сформулювати нову спробу вже як мінімальну трансформацію.

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

Тепер Claude отримує не просто «зроби ще раз», а чіткий коридор. Після цього дуже корисно перевірити: чи справді він змінив тільки потрібний файл або файли, чи справді тести навколо refund-flow залишилися осмисленими, чи не зачепив він сусідні контракти. Якщо так — чудово, ви продовжуєте. Якщо ні — принаймні знову відкочуєтеся до чистої точки, а не до вже переплутаної суміші двох невдалих підходів.

І тут стає видно, чому checkpoints так тісно пов’язані з дисципліною з минулої лекції. Добрий checkpoint — не випадковість. Він з’являється там, де у вас уже була зрозуміла віха, зелені тести і коротке резюме того, що вважається нормальним станом. Якщо ви дійшли до середини величезної брудної сесії без точок зупинки, навіть вдалий rewind часто повертає вас не до «хорошого місця», а просто до більш раннього хаосу. Тож /rewind особливо добре працює в акуратних розробників. Несправедливо, але закономірно.

6. Вибір: /rewind, нова сесія або інший відкат

Коли ви вже трохи попрацювали з довгими задачами, у вас з’являється нова навичка: швидко визначати, де взагалі зараз живе проблема. Це майже важливіше за саму команду. Тому що технічно зрілий розробник відрізняється не тим, що знає більше прапорців, а тим, що розуміє, який шар зламався.

Корисно подумки проходити короткий фільтр. Якщо проблема знаходиться всередині поточної гілки розмови, reasoning поїхав не туди, а історія проєкту ще не зачеплена всерйоз, вам підходить /rewind. Якщо сама ідея сесії вже забруднена старими гіпотезами, але файловий стан проєкту загалом нормальний, часто краще нова сесія з коротким, чистим підсумком. А якщо зміни вже стали частиною історії Git або, тим більше, зовнішніх систем, відкат робиться не в Claude conversation, а у відповідному шарі.

Це можна тримати як маленьку шпаргалку:

/rewind

І останнє, що варто запам’ятати з цієї лекції. Найкращий /rewind — той, для якого ви заздалегідь підготували місце посадки: точку після зелених перевірок і контрольної точки, до ризикованого експерименту, з ясним scope. Тоді відкат — не аварія, а звичайний рух: гілка невдала, повертаємося до здорової точки й ідемо обережніше.

Так Claude Code перестає здаватися непередбачуваним — це інструмент у руках того, хто розуміє, де закінчується сесія і починається історія проєкту.