1. Бесконечный чат проигрывает сессии
Самая частая ошибка — «один разговор на все случаи жизни». Утром чините пустой экран после неверного пароля в Commerce OS, днём — пагинацию заказов, вечером README, под конец тесты. Выглядит продуктивно, а вы убиваете контекст и diff.
Сессия работает, когда у неё есть границы — ответы на пять вопросов: что делаем, где, что решили, что неясно, какой следующий шаг. Есть ответы — Claude спокоен. Нет — половина переписки про один баг, четверть про другой, остальное про «нет, я имел в виду не это».
| Рабочая сессия | Бесконечный чат |
|---|---|
| Привязана к одной задаче или одному рабочему потоку | Смешивает несколько задач |
| Имеет понятный goal и scope | Живёт по принципу «разберёмся по ходу» |
| Её легко продолжить завтра | Завтра вы сами с трудом поймёте, что тут происходит |
| Из неё можно сделать короткую сводку | Из неё получается археологическая раскопка |
| Claude получает устойчивые сигналы | 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. Когда открывать новый контейнер
Команды и кнопки в интерфейсах разные, а решение всегда одно: этот контейнер задачи ещё жив или уже нет.
| Состояние | Признак | Что делать |
|---|---|---|
| Тот же task, форма жива | goal и scope всё ещё легко пересказать | Продолжать текущую сессию |
| Тот же task, но истории слишком много | Полезное ядро есть, но шум уже мешает | Сжать разговор и повторить опорные детали |
| Task сменился или цель уже трудно пересказать | Scope смешался, разговор расползся | Открывать новый контейнер задачи |
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
На том же баге ритуал такой:
- Поднимите рамку задачи. Возьмите из TASK_SPEC.md goal, scope, constraints и критерии приёмки. Не начинайте с расплывчатого «почини логин».
- Соберите минимальный контекстный набор. В окно — только нужное задаче: LoginController.java, SessionService.java, AuthFlowTest, короткий stack trace и reproduction steps. Не тащите весь репозиторий.
- Следите за бюджетом по ходу работы. Диалог разросся — посмотрите /context. Окно занято задачей или его съели старые гипотезы, длинные логи и побочные темы?
- Отделите нехватку данных от загрязнённой сессии. Не хватает файла или сигнала — добавьте точечно. Дело в старом шуме и конфликтующих направлениях — применяйте действие восстановления: сжимайте, чистите или пересобирайте сессию как новый контейнер.
- Примите решение по жизненному циклу. Тот же task — продолжайте или коротко сожмите. Задача сменилась или разговор потерял форму — открывайте новый контейнер со сводкой: цель, границы, подтверждённое evidence, следующий шаг.
Бытовой на вид ритуал собирает день в рабочую привычку. Вы больше не живёте внутри бесконечного чата: у контейнера есть ясный старт, понятное состояние и способ закрыться или начаться заново.
Дальше всплывают новые вопросы: как жить с задачами длиннее одного захода, где ставить контрольные точки, где кончается история сессии и начинается история проекта. Это другой уровень дисциплины — разберём его дальше.
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ