Бюджет контексту, /context і compaction

1. Навіть чистий контекст розбухає

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

Звідси context budget. У вікна сесії є межа, за неї конкурують історія діалогу, файли, вивід команд, правила проєкту. Довгий лог легко коштує дорожче за пʼять рядків із goal, scope і обмеженнями. Половину бюджету з’їв шум — міркування попливло.

Що потрапляє у вікно і коли це шкодить:

Приклад із Commerce OS. Баг: після неправильного пароля користувач бачить порожній екран. Старт чистий — LoginController.java, SessionService.java, AuthFlowTest.java, короткий лог, reproduction steps. Через пів години в сесії три нові гіпотези, довгий вивід тестів, обговорення SSO, шматок відкинутого рішення і команда «просто подивитися». Формально все по темі. Практично вікно захаращене.

Проблема не в тому, що Claude «став гірше міркувати», — ви перестали керувати робочим простором. Час дивитися на сесію як інженер.

2. Читання виводу /context

/context перетворює розмите «сесія розбухла» на конкретну картину: чим зайняте вікно. Точний формат виводу залежить від версії Claude Code — орієнтуйтеся на актуальний /help. Це приладова панель: сама шум не прибере, але покаже палаючий індикатор.

Концептуально вивід читається так:

/context
Історія діалогу: велика
Файли в роботі: LoginController.java, SessionService.java, AuthFlowTest.java
Вивід команд: auth-error.log, test output
Проєктні інструкції: CLAUDE.md
Дод. сигнали: memory, rules

Читайте це як відповідь на три запитання. Чи не з’їла історія надто багато місця. Чи не лежать у вікні виводи команд, якими вже ніхто не користується. Чи залишилися у фокусі файли й обмеження, заради яких сесія почалася.

<Auth>файли на місці, але історія величезна, а лог помилки тягне на себе непропорційно багато — сигнал на користь /compact. Поруч із auth-багом бовтаються SSO-підказки, обговорення UX форми і README із сусіднього модуля — потрібне вже не стискання, а радикальне прибирання.

Це перевірка фокуса. Не можете в одному абзаці відповісти «мета, scope, що заважає» — проблема вже не в обсязі: сесія розмиває задачу.

3. /compact: стиснення історії без ілюзій

/compact — не телепорт в ідеальний стан, а компроміс. Ви міняєте докладну історію на стисле зведення: місця більше, частина деталей втрачається. Це не «зберегти все», а «залишити головне».

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

Тому робіть стискання не мовчки, а з указанням, що зберегти. За задачею в Commerce OS:

/compact Збережи:
- мета: виправити порожній екран після неправильного пароля
- область змін: лише src/auth/* і AuthFlowTest
- обмеження: не змінювати public API, не чіпати міграції
- відкинута гіпотеза: проблема не в SessionService
- приймання: показати помилку користувачу і зберегти поточну поведінку успішного входу

Логи, хибні гіпотези й другорядне відпускаєте; мету, scope, обмеження і перевірені висновки переносите у зведення.

Допомагає, якщо task spec уже лежить у файлі:

Мета: виправити порожній екран після неправильного пароля
Область змін: src/auth/*, AuthFlowTest.java
Обмеження:
- не змінювати public API
- не додавати залежності
Приймання:
- користувач бачить помилку
- успішний вхід працює як раніше

Тоді після стискання ви не витягуєте все з памʼяті, а повертаєте готовий артефакт. Саме тому task spec і критерії приймання переживають довгу роботу — вони живуть поза діалогом.

Після /compact відновіть фокус коротким нагадуванням:

Продовжуємо ту саму задачу.
Повторюю мету: прибрати порожній екран після неправильного пароля.
Перечитай заново LoginController.java і AuthFlowTest.java.
Зберігаємо попередній session API і не виходимо за межі src/auth/*.

Дрібниця, але вона підвищує шанс, що Claude продовжить у тих самих межах, а не в режимі «ну там щось із логіном».

І ще: після стискання не можна тиснути «але ти ж 20 хвилин тому говорив». У вікні зведення, а не повна історія — надійніше заново підняти факт із файлу, тесту чи task spec.

4. Коли стискання вже не допомагає

/clear здається визнанням поразки. Насправді це наступний інструмент гігієни сесії, коли стискання вже мало допомагає.

Задача та сама, історія стала важкою — спочатку /compact. Заїхала інша тема — чистіше обнулити бесіду. Не можете за пʼять-шість рядків перескласти goal, scope і evidence — нова сесія дешевша за порятунок старої.

/clear — нова розмова в тому самому проєктному оточенні. Нова сесія — новий контейнер, куди ви заново приносите рамку: goal, scope, обмеження, evidence. Межа проста: доки задача одна — зберігаєте форму сесії; форма втрачена — перескладаєте, а не дотискаєте силою.

І тут спливає запитання: сесія просто важка — чи вже забруднена старим шумом і конфліктними сигналами?

5. Сценарій на Commerce OS: життєвий цикл сесії наживо

Зберемо все в наскрізний сценарій. Commerce OS, той самий баг: після неправильного пароля замість помилки — порожній екран. Ви вже зробили те, чого вчилися раніше: оформили task spec, звузили scope, дали лише потрібні файли. Старт:

Мета: виправити порожній екран після неправильного пароля
Область змін: src/auth/*, AuthFlowTest.java
Обмеження:
- не змінювати public API
- не чіпати міграції
Приймання:
- помилку видно користувачеві
- успішний вхід працює як раніше

Читаєте LoginController.java, SessionService.java, ганяєте тести, дивитеся лог. Через деякий час у бесіді довгий вивід тестів, дві хибні гіпотези, обговорення SSO-потоку. Claude відповідає менш точно. Не «ти знову не туди» — діагностуєте:

/context

Історія велика, auth-файли у фокусі, але вивід команд розрісся, а стара гіпотеза про SessionService досі впливає на міркування. Випадок для /compact, не /clear: задача та сама. Направляєте стискання:

/compact Збережи:
- мету і критерії приймання з task spec
- область змін: тільки src/auth/*
- відкинуту гіпотезу: SessionService не є коренем проблеми
- наступний крок: перевірити рендер помилки в LoginController

Після стискання коротко відновлюєте рамку:

Продовжуємо той самий bugfix.
Повторюю: змінюємо лише src/auth/*, public API не чіпаємо.
Перечитай заново LoginController.java і AuthFlowTest.java.
Перевір, чому помилка не потрапляє в рендер.

Підзадачі заново не переписуємо — повертаємо головні опори. Сесія знову тримається на меті й фактах, а не на шумі.

Баг локалізовано — і прилітає нове прохання: «Раз ви вже в формі логіну, додайте підказку про вхід через SSO і змініть тексти помилок». Класична помилка — продовжити в тій самій сесії. Задача змінилася з bugfix на UX — /clear або нова сесія з новим міні-спеком. Так ви тримаєте керований diff.

Увесь матеріал — один ритуал. Сесія важчає — дивитеся /context. Задача та сама — /compact. Змінилася — перескладаєте розмову в новий контейнер. Після стискання або перезапуску коротко повторюєте goal, scope, обмеження — і лише потім продовжуєте.