Operational model: як влаштовано контекст Claude

1. Міф «Claude все памʼятає» заважає працювати

Найдорожча помилка — говорити з Claude як із колегою, який учора дивився той самий файл і за ніч перечитав репозиторій. Claude не сидить уночі над вашим Commerce OS і не перечитує src/auth/*. Він працює лише з тим, що потрапило у вікно поточної сесії.

Ви: Ви ж раніше дивилися LoginController.java, чому знову питаєте?
Claude: У цій сесії файл ще не відкрито. Можу прочитати його зараз.

Здається, що він «гальмує». Насправді він чесно повідомляє: файлу в контексті немає.

Claude не «памʼятає проєкт». Claude працює з тим, що реально опинилося в поточному вікні контексту.

Прийнявши це, ви перестаєте чекати людської памʼяті й даєте робочі сигнали: яка помилка, де проявляється, які файли важливі, що вже перевірено. Магія стає інженерією.

2. Контекст — це робоче вікно, а не памʼять

Контекст — робоче вікно з обмеженим набором сигналів: не весь проєкт, не все попереднє спілкування, лише те, що зараз лежить перед моделлю. Не бібліотека, а письмовий стіл: проєкт, логи, нотатки, правила існують, але вміщується лише частина. Решта в задачі не бере участі.

flowchart LR
    A[Ваш поточний prompt] --> E[Поточне вікно контексту]
    B[Прочитані файли] --> E
    C[Вивід команд і логи] --> E
    D[CLAUDE.md, rules, memory] --> E
    E --> F[Наступна відповідь Claude]

Два наслідки. Вікно скінченне — точні ліміти знати не потрібно, важливий принцип. І сигнал потрапляє в нього не телепатією: прочитали файл — він у контексті; команда вивела помилку — її вивід теж сигнал; правило в CLAUDE.md підвантажується як інструкція. Маєте на увазі «це ж зрозуміло» — для моделі це порожнеча.

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

3. Під капотом: вікно — це стрічка повідомлень

Технічно вікно контексту — це стрічка повідомлень. Кожен prompt, кожна відповідь Claude, кожне читання файла, кожен вивід команди, кожен результат інструмента — окреме повідомлення. Відповідаючи, Claude не «оновлює думку про проєкт» — він дивиться на всю стрічку і дописує в кінець рівно одне повідомлення. Прочитав LoginController.java — додалося повідомлення з файлом. Повернувся stack trace — ще одне.

Звідси скінченність вікна: стрічка зростає, кожне повідомлення залишається до кінця сесії. Коли вона впирається в стелю, щось викидається або перескладається — про це окрема розмова про /context і compaction.

Формула: Claude не «памʼятає проєкт» — він дивиться на стрічку й дописує наступне повідомлення. Шари, які розберемо далі, — це різні види її повідомлень.

4. Шари, з яких складається контекст

Коли Claude відповідає погано, запитуйте не «чи він сьогодні розумний», а «з яких джерел зібрався контекст»:

Шари завантажуються по-різному. Діалог виникає сам, файли — лише якщо ви надали доступ, а CLAUDE.md і частина постійних шарів підвантажуються заново самі. Звідси ілюзія: «він і в новій сесії знає, що не можна чіпати migrations, отже, все памʼятає». Ні — він знову отримав стабільні інструкції, наприклад такий фрагмент CLAUDE.md у Commerce OS:

# CLAUDE.md

Команда тестування: ./gradlew test
Не змінювати public API в src/auth/*
Не чіпати migrations
Перед правками — перелічіть файли, яких торкнуться зміни

Картка скаже, як поводитися в проєкті, але не яку гіпотезу ви перевіряли дві години тому і чому вона виявилася хибною.

5. Нова сесія — не повна амнезія

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

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

На практиці: учора ви знайшли підозріле місце в LoginController.java, відкинули ідею про SessionService, побачили stack trace, вирішили писати мінімальний фікс. Відкриєте сьогодні сесію з «реалізуй учорашнє рішення» — Claude знає правила проєкту, але не саме рішення.

Тому task spec — не бюрократія, а спосіб відновити деталі. Записані goal, scope, non-goals, constraints і фіксація ухвалених рішень перетворюють сесію з «все заново» на продовження роботи.

6. Звідки відчуття, що Claude «не знає очевидного»

Розкладіть його на типові причини — майже завжди справа в одній із них.

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

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

Третя: конфлікт сигналів. У CLAUDE.md — «не змінювати public API», а в prompt ви розпливчасто просите «перероби auth flow нормально». Старі сигнали не зняті, нові нечіткі — Claude тягне відповідь у несумісні боки.

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

Питання тепер не «чому він не здогадався», а «якого сигналу немає або який конфліктує».

7. Один збій у Commerce OS, дві постановки задачі

Збій: після хибного пароля користувач бачить порожню сторінку замість повідомлення про помилку. Учора ви покопалися в src/auth/*, сьогодні продовжуєте. Слабка постановка:

Виправ помилку з логіном.
Ти ж учора дивився auth.
Зроби нормально і без зайвого.

Для Claude майже безкорисно: немає спостережуваної поведінки, ефекту, області змін, обмежень. «Ти ж дивився auth учора» спирається на віру в памʼять моделі.

Варіант, що використовує те, що ви вмієте після модулів 3 і 4:

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

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

8. Від спору з памʼяттю — до керування середовищем

Головний зсув — нова мова мислення. Дивний відповідь не пояснюйте містикою, ставте інженерні запитання: чи бачив він у цій сесії потрібний файл; чи є у вікні stack trace; чи не конфліктує prompt з інструкціями проєкту; чи не спираюся я на вчорашню розмову, якої немає; чи подав я гіпотезу як гіпотезу, а не як відчуття?

Переведіть емоції на робочу мову:

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