Context budget, /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

Читайте это как ответ на три вопроса. Не съела ли история слишком много места. Не лежат ли в окне выводы команд, которыми уже никто не пользуется. Остались ли в фокусе файлы и ограничения, ради которых сессия началась.

файлы на месте, но история огромная, а лог ошибки тянет на себя непропорционально много — сигнал в пользу /compact. Рядом с auth-багом болтаются SSO-подсказки, обсуждение UX формы и README из соседнего модуля — нужен уже не compaction, а радикальная уборка.

Это проверка фокуса. Не можете в одном абзаце ответить «цель, scope, что мешает» — проблема уже не в объёме: сессия размывает задачу.

3. /compact: сжатие истории без иллюзий

/compact — не телепорт в идеальное состояние, а компромисс. Вы меняете подробную историю на сжатую сводку: места больше, часть деталей теряется. Это не «сохранить всё», а «оставить главное».

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

Поэтому делайте compaction не молча, а с указанием, что сохранить. По задаче в Commerce OS:

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

Логи, ложные гипотезы и второстепенное отпускаете; цель, scope, ограничения и проверенные выводы уносите в сводку.

Помогает, если task spec уже лежит в файле:

Цель: исправить пустой экран после неверного пароля
Область изменений: src/auth/*, AuthFlowTest.java
Ограничения:
- не менять public API
- не добавлять зависимости
Приёмка:
- пользователь видит ошибку
- успешный логин работает как раньше

Тогда после compaction вы не вытаскиваете всё из памяти, а возвращаете готовый артефакт. Поэтому task spec и критерии приёмки переживают долгую работу — они живут вне диалога.

После /compact восстановите фокус коротким напоминанием:

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

Мелочь, но она повышает шанс, что Claude продолжит в той же рамке, а не в режиме «ну там что-то с логином».

И ещё: после compaction нельзя давить «но ты же 20 минут назад говорил». В окне сводка, а не полная история — надёжнее заново поднять факт из файла, теста или task spec.

4. Когда compaction уже не помогает

/clear кажется признанием поражения. На деле это следующий инструмент гигиены сессии, когда compaction уже мало.

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

/clear — новый разговор в том же проектном окружении. Fresh session — новый контейнер, куда вы заново приносите рамку: 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: задача та же. Направляете compaction:

/compact Сохрани:
- цель и критерии приёмки из task spec
- область изменений: только src/auth/*
- отклонённая гипотеза: SessionService не корень проблемы
- следующий шаг: проверить рендер ошибки в LoginController

После сжатия коротко восстанавливаете рамку:

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

Ползадачи заново не переписываем — возвращаем главные опоры. Сессия снова держится на цели и фактах, а не на шуме.

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

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