Життєвий цикл сесії: контейнер задачі

1. Нескінченний чат програє сесії

Найчастіша помилка — «одна розмова на всі випадки життя». Зранку ви лагодите порожній екран після неправильного пароля в Commerce OS, удень — пагінацію замовлень, увечері — README, наприкінці — тести. Виглядає продуктивно, а ви вбиваєте контекст і diff.

Сесія працює, коли в неї є межі — відповіді на пʼять запитань: що робимо, де, що вирішили, що неясно, який наступний крок. Є відповіді — Claude спокійний. Немає — половина переписки про одну ваду, чверть про іншу, решта про «ні, я мав на увазі не це».

Сесія — папка справи. Одна вада: симптоми, докази, підозрювані файли, план. Додайте сюди ще CI, архітектуру та «перепиши текст на кнопці» — і папка стане шухлядою столу, яку ви розбиратимете «на вихідних». Не розбиратимете.

Сесії вистачає чіткого центра тяжіння: «виправляємо порожній екран після неправильного пароля в src/auth/*, public API не змінюємо, міграції не чіпаємо, критерії в TASK_SPEC.md».

2. Шапка сесії за хвилину

Типовий старт: «подивіться, тут щось не так із логіном». Так ви з першого повідомлення втрачаєте половину користі. Claude не телепат: рамку не задали — добудує сам, старанно і не туди.

Дайте сесії коротку «шапку»: імʼя, ціль, межі, заборони, найближчий крок. Це ритуал, а не команда.

Сесія: commerce-os-auth-invalid-password
Мета: виправити порожній екран після неправильного пароля.
Область змін: src/auth/*, AuthFlowTest.
Не-цілі: не змінювати public API, не чіпати міграції та залежності.
Відкриті питання: чи впливає SSO callback на цей сценарій?
Наступний крок: відтворити баг і підтвердити точку збою.

Просто — і в цьому сила. Імʼя, межі, заборони та крок зафіксовано, сесія більше не безіменна.

Для Commerce OS старт можна повʼязати зі task spec:

Працюємо за TASK_SPEC.md для bugfix в авторизації.
Потрібно виправити порожній екран після неправильного пароля.
Спочатку досліджуємо без широкого рефакторингу.
Обмеження: не змінювати public API і не чіпати міграції.
Після аналізу покажи affected files, гіпотези та мінімальний план виправлення.

Жодного роману — тільки каркас, який переживе стискання історії, паузу і повернення через години. Цінність не в кнопці перейменування, а в тому, що рамку проговорено одразу.

3. Коли відкривати новий контейнер

Команди й кнопки в інтерфейсах різні, а рішення завжди одне: цей контейнер задачі ще живий чи вже ні.

Recovery-інструменти другорядні. Спочатку дайте відповідь: та сама задача чи ні. Якщо ні — сесію не рятують за те, що вона довго прожила. Це витратний контейнер, не реліквія.

flowchart TD
    A[Нова сесія] --> B[Зафіксувати goal і scope]
    B --> C[Робота над задачею]
    C --> D{Це все ще один task container?}
    D -- Так --> E[Продовжувати]
    D -- Так, але історії багато --> F[Стиснути розмову й повторити ключові обмеження]
    D -- Ні --> G[Відкрити новий контейнер]
    E --> H[Закрити сесію на зрозумілій проміжній точці]
    F --> H
    G --> H

Сесія живе рівно стільки, скільки допомагає одній задачі. Почала заважати — її цінність закінчилася.

4. Коротка зовнішня примітка рятує повторний старт

Навіть усередині однієї задачі винесіть назовні три-чотири опорні факти: що перевірили, яку гіпотезу відкинули, що змінювати не можна, який наступний крок. Для багфіксу цього вистачає.

- SessionService не корінь проблеми.
- Правимо тільки src/auth/*.
- Public API не чіпаємо.
- Наступний крок: перевірити рендер помилки в LoginController.

Це не звітність, а страховка: після паузи не копати ту саму хибну гілку.

5. Зберігайте підсумок, а не весь роман

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

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

Задача: bugfix порожнього екрана після неправильного пароля.
Підтверджено: проблема в LoginController, не в SessionService.
Межі: public API не змінюємо, міграції та залежності не чіпаємо.
Наступний крок: внести мінімальну правку й прогнати повʼязані тести.

Цього вистачає, щоб повернутися до задачі без археології по чату.

6. Практичний ритуал для Commerce OS

На тому самому багу ритуал такий:

1. Підніміть рамку задачі. Візьміть із TASK_SPEC.md goal, scope, constraints і критерії приймання. Не починайте з розпливчастого «виправ логін».
2. Зберіть мінімальний контекстний набір. У вікно — тільки те, що потрібно задачі: LoginController.java, SessionService.java, AuthFlowTest, короткий stack trace і reproduction steps. Не тягніть увесь репозиторій.
3. Слідкуйте за бюджетом у процесі роботи. Діалог розрісся — подивіться /context. Вікно зайняла задача чи його з’їли старі гіпотези, довгі логи й побічні теми?
4. Відокремте нестачу даних від забрудненої сесії. Не вистачає файлу або сигналу — додайте точково. Справа в старому шумі й конфліктних напрямках — застосовуйте дію відновлення: стискайте, чистіть або перескладіть сесію як новий контейнер.
5. Прийміть рішення щодо життєвого циклу. Та сама task — продовжуйте або коротко стискайте. Задача змінилася або розмова втратила форму — відкривайте новий контейнер із підсумком: ціль, межі, підтверджене evidence, наступний крок.

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

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

1

Опитування

Контекст і сесії у Claude Code, рівень 5, лекція 4

Недоступний

Контекст і сесії у Claude Code

Контекст і сесії у Claude Code

Відкрити