Context pollution і дії відновлення

1. Проблема часто не в моделі, а в стані сесії

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

Context pollution — забруднення контексту: у вікні накопичилися сигнали, що заважають поточному завданню. Не «зламалося всередині Claude».

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

Помітно в довгих сесіях. Ви лагодите в Commerce OS баг авторизації: після неправильного пароля — порожній екран. Гіпотеза про SessionService, потім новий лог, потім LoginController, потім питання про SSO callback, потім «глянь, чому тести повільні». Через сорок хвилин Claude працює не із завданням, а з клубком напіврозібраних думок.

Не «Claude став гіршим», а «сесія втратила дисципліну». Назвали так — зʼявилося лікування.

2. Ознаки забрудненої сесії

Ухопити context pollution на початку дешевше, ніж рятувати сесію за годину.

Найчастіша ознака: Claude повертається до відкинутої гіпотези, ніби вона жива. Ви перевірили, що справа не в SessionService, — а він знову пропонує «про всяк випадок» поправити там обробку помилки. Друга: впевнений тон за поганої привʼязки до фактів — висновки розходяться з файлами, які він уже читав. Третя: ігнорує свіжі обмеження. Ви написали «не чіпай SSO і public API» — а diff змінює обробник авторизації поза scope.

Побутові маркери: діалог в’язкий; багато «вибач, ти маєш рацію, зараз виправлю» без поліпшення; diff зростає, хоча завдання не розширювалося; просочується «раз ми вже тут, давай ще…».

Видно на фрагменті робочого логу:

10:05 — гіпотеза: проблема в SessionService
10:14 — перевірили AuthFlowTest.failed_login → гіпотеза не підтверджена
10:22 — новий фокус: LoginController
10:29 — користувач додав: «до речі, ще перевір SSO callback»
10:36 — у сесію вставлено великий application.log цілком
10:44 — Claude знову пропонує правити SessionService
10:49 — Claude змінює LoginController, SessionService і SsoCallbackHandler одночасно

Формально все «логічно». Але після 10:29 сесія попливла: побічна тема залізла в головний потік, великий лог забив контекст, стара гіпотеза спливла. Pollution — серія дрібних зсувів, а не одна драматична помилка.

3. Забруднення проти нестачі контексту

Дії протилежні. Контексту мало — додати. Забруднений — скорочувати, чистити, перескладати. Переплутати — гасити пожежу бензином.

Коли даних мало, Claude чесний: ставить уточнювальне запитання, просить файл, stack trace або reproduction steps, позначає висновок як гіпотезу. Відповідь — додати файл, шматок логу, test output.

За забруднення навпаки: даних достатньо або навіть забагато, але частина з них погана. Claude не просить фактів — упевнено міркує на старому смітті. Не «я не знаю, покажи файл», а «знову правити те, що двадцять хвилин тому виключили».

Тримайте цю таблицю під рукою:

Робоче запитання: «Claude чогось не знає — чи знає занадто багато зайвого?» Чесна відповідь робить recovery action очевидною.

4. Карта відновлення: команди та fresh session

Чарівної кнопки немає. Є набір дій, кожна під свій тип проблеми. Назви слеш-команд і їхня поведінка змінюються від версії до версії: перевіряйте /help, але мисліть завданням, а не назвою.

Уся карта:

/compact

/clear

/rewind

Таблиця каже, коли що обирати. Далі — нюанси, яких у ній немає.

/compact: не викидати розмову, а прибрати зайву вагу. Корисна інструкція до compaction — заздалегідь кажіть, що зберегти.

/compact Збережи: goal, scope, non-goals, поточну гіпотезу,
stack trace excerpt і список уже відкинутих причин.
Опусти: довгі проміжні міркування та старі чорновики.

/clear: не поразка, а «відрізав непотрібний хвіст». Дешевше відкрити чисту бесіду, ніж тягнути сміття.

/rewind працює на рівні сесії та гілки міркування. Якщо зміни зачепили файли — спочатку читайте diff і спирайтеся на Git. Історія проєкту живе не у слеш-команді.

Fresh session лякає: здається, «втратите все». Насправді ви втрачаєте сміття, якщо перед стартом збираєте короткий жорсткий пакет: мета, scope, non-goals, constraints, evidence.

І головна дія, про яку забувають: нічого не робити, доки не прочитаєте diff. Додавати промпти поверх хаосу погано — спочатку дивіться, що змінилося.

5. Сценарій із Commerce OS: рятуємо багфікс в auth

Давайте пройдемо типовий сценарій. Завдання знайоме: після неправильного пароля — порожній екран замість повідомлення.

Був хороший task spec: виправити порожній екран, працювати лише в src/auth/*, public API не змінювати, SSO не чіпати, перевірити AuthFlowTest. Claude висунув гіпотезу про SessionService. Кілька ходів, звірка з тестом — не підтверджується. Далі класика: побічне питання про SSO callback, занадто великий лог, і Claude знову лізе правити SessionService.

Доросла дія — не «ну гаразд, виправляй далі», а зупинитися, назвати діагноз і записати recovery-рішення.

# SESSION_LOG.md

Завдання: порожній екран після неправильного пароля в Commerce OS
Область змін: src/auth/*, AuthFlowTest
Ознаки pollution:
- 3 невдалі корекції поспіль
- повернення до відкинутої гіпотези про SessionService
- у розмову заїхав SSO callback поза scope
- diff зачепив зайві файли

Рішення: fresh session
Переносимо в новий контекст:
- мета
- поточна поведінка / очікувана поведінка
- фрагмент stack trace
- LoginController.java
- AuthFlowTest
- жорсткі обмеження

Відкриваєте fresh session і переносите не всю розмову, а лише суть.

Мета: виправити порожній екран після неправильного пароля.
Поточна поведінка: за неправильних credentials сторінка рендериться порожньою.
Очікувана поведінка: користувач бачить повідомлення про помилку, redirect не ламається.
Область змін: src/auth/LoginController.java і AuthFlowTest.
Нецілі: не чіпати SSO, не змінювати public API, не додавати залежності.
Докази: фрагмент stack trace + failing UI behavior.
Спочатку знайди root cause і запропонуй мінімальний fix без правок.

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

Менш романтично, ніж «витягти сесію з болота». Зате працює.

6. Task spec як аварійний комплект

Чим краще оформлено task spec, тим простіше переживати pollution. Відновлювати завдання по памʼяті не можна: здається, що памʼятаєте все, але забудете один non-goal або розмиєте scope — і розмова знову поїде не туди. Task spec — аварійний комплект: переносите goal, current behavior, desired behavior, scope, constraints, критерії приймання і стартуєте знову.

Особливо після /compact (зведення згладжує нюанси — повторюєте критичні обмеження) і fresh session (task spec — основа першого повідомлення). Тут видно, чому формулювання з модулів 3 і 4 були важливими. Goal не дає розмові розповзтися. Scope відрізає зайві файли. Non-goals захищають від «раз ми вже тут, давай ще». Критерії приймання — від красивого, але неправильного виправлення.

Polluted session лікується не розумним промптом, а дисципліною. Task spec — зафіксована дисципліна, яку переносите із сесії в сесію.

7. Звичка зрілого процесу

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

Замість «ні, не це, давай ще раз» — спокійний цикл: помітили ознаки pollution, зупинилися, за потреби прочитали diff, обрали /compact, /clear, /rewind або fresh session, пересклали task spec, пішли далі.

З часом це стає автоматизмом — як звичка дивитися git status перед роботою. І тоді Claude Code відчувається не вередливою співбесідою, а передбачуваним інструментом.