Що варто зберігати в memory? Аудит моїх 5 записів, по черзі

Попередній допис доводив, що CLAUDE.md має містити лише те, чого Claude не бачить, читаючи код. Читач одразу запитав: а що з memory? Memory теж контекст — у чому реальна різниця?

Багато хто з часом починає ставитись до memory як до «резервного розширення» CLAUDE.md — пхає туди все, що спадає на думку. Поступово memory розпухає, Claude читає його на кожній сесії, і рішення ухвалюються на застарілій інформації.

Цей допис пропускає абстрактні визначення. Я відкрив усі 5 файлів memory, які наразі живуть у цьому проєкті, і провів аудит кожного окремо — що лишається, що йде, що взагалі не мало бути записаним. Попутно питання CLAUDE.md vs memory відповідає саме на себе.

Різниця в одному рядку

• CLAUDE.md потрапляє в system prompt кожної сесії. Статичний. Для інваріантів.
• memory Claude читає й оновлює сам. Динамічний. Для фактів, що змінюються, або окремих подій, які варто зберегти.

Корисне питання — не «куди це покласти», а «скільки живе ця інформація і хто її оновлює».

Мої 5 файлів memory

feedback_commits               — чекати, поки я скажу "commit", перш ніж комітити
feedback_article_authenticity  — практичні статті не можна вигадувати
project_i18n_strategy          — рішення «запустити всі мови одночасно»
project_howdev_plan            — незавершений план для how2claude.dev
project_article_workflow       — конвеєр публікації статей

Згрупую за типом.

Тип A: Одне виправлення стає вічним правилом (feedback_commits)

Тіло коротке: "don't auto-commit, wait for user to confirm."

Найвищий ROI серед типів memory. Одне виправлення → назавжди в усіх майбутніх сесіях.

Чому не в CLAUDE.md? Це не правило проєкту — це моя особиста робоча звичка. Якщо до проєкту приєднається інший контриб'ютор, йому не обов'язково дотримуватись того самого правила. CLAUDE.md — рівень команди. Memory — «між мною і Claude».

Чому не повторювати на початку кожної розмови? Бо memory зберігається між сесіями. Коли Claude допоможе мені наступного тижня, він усе ще пам'ятатиме.

Тригер чистий: я виправив одного разу, і хочу, щоб виправлення лишалося назавжди.

Тип B: Справа про інцидент із датою (feedback_article_authenticity)

Тіло цього memory незвично конкретне:

2026-04-16, коли я писав фінал серії multi-agent, я вигадав історію про «трьох Agent-ів, які будують webhook-фічу»... все вигадане. Користувач запитав «це реальне чи придумане?» — це інша планка, ніж у двох попередніх (методологічних) статей...

Суть: поле Why не абстрактний принцип — це конкретна подія + дата + що сталося.

Чому так написано? Через півроку «практичним статтям потрібен реальний матеріал» як абстрактне правило мене спантеличить — коли це встановили, чому? Але «4-16, вигадав історію про agent і попався» миттєво оживляє спогад і дозволяє на місці оцінити, чи правило ще чинне.

Це найважчий запис із моїх 5. Це не просто правило — це справа про інцидент, до якої можуть звертатись і Claude, і я.

Тип C: Контекст стратегічного рішення (project_i18n_strategy)

Зміст: чому цей проєкт агресивно запустив усі мови одразу — вартість перекладу через Claude ~$0, а англомовна офіційна документація — головне вікно можливостей.

Цього не видно з коду. Код показує лише 19 файлів локалі. Чому 19, чому одночасно, чому японська й корейська в пріоритеті — усе це живе у мене в голові.

Memory відстоює це «рішення в голові» в щось стале, щоб коли Claude пізніше пропонуватиме фічу, він міг запитати: чи конфліктує це зі стратегією i18n?

Не операційне правило (не в CLAUDE.md). Стратегічний фон (у memory).

Тип D: Передача між сесіями (project_howdev_plan)

Найтимчасовіший: план імплементації з 9 файлів для сайту розробників how2claude.dev, завершується фразою «продовжимо в наступній сесії».

Найнебезпечніший тип memory — легко стає memory-зомбі. Закінчив роботу, забув видалити; наступного разу Claude вважає його активним і радить на основі застарілого плану («ти ще не зробив step 3»).

Таким memory потрібен явний механізм виходу: у мить, коли how2claude.dev запуститься, доведеться видалити цей запис вручну.

Тип E: Та, яку слід видалити (project_article_workflow)

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

• Існування /write-article і /publish-article → подивитись у .claude/commands/, все
• Структура каталогу draft (meta.json + lang.md) → docs/drafts/ робить це очевидним
• URL API → лежить у .claude/publish-config.json
• Список slug-ів category/series → у seed-файлі

Claude може все це вивести, читаючи код.

Єдине, що memory реально дає, — останній блок: "Accounts (production): zh → @how2claude, en → @howtoclaude" — і це вже застаріло. У минулій сесії стало зрозуміло, що у продакшні насправді zh=@howtoclaude. Memory зафіксував знімок кількаденної давнини; він уже дрейфонув.

Висновок: 90 % цього memory має піти. Те, що варто зберегти («використати kamal, щоб опитати акаунти наживо»), краще пасує CLAUDE.md — або, ще краще, ніде, бо захардкоджені у memory акаунти знову дрейфонуть.

Чотири висновки

1. Справжня робота memory — відчиняти кімнати, в які Claude не може зайти.

• Не може зайти до моєї голови → стратегія, уподобання, причини
• Не може зайти в минулотижневу сесію → на чому я тебе виправляв
• Не може зайти у провал трьохмісячної давнини → конкретна подія + дата

2. Якщо Claude може прочитати це з коду — не клади це в memory.

Той самий принцип, що й у попередній статті про CLAUDE.md. Шляхи до файлів, URL API, структура каталогів — усе це питання, на які відповідає код. Пхати в memory, щоб не запускати grep, — це ставка, що ніщо ніколи не зміниться.

3. Memory псується.

project_article_workflow — доказ: написаний кілька днів тому, інформація про акаунти вже неправильна. Чим старший memory, тим менше йому можна довіряти. Регулярний аудит > нескінченне додавання.

4. Поле Why — те, що вас рятує.

Порівняйте мої два feedback-и:

• Why у feedback_article_authenticity: «4-16, я вигадав історію в статті multi-agent» → через півроку я можу миттєво оцінити, чи правило ще чинне.
• Why у feedback_commits: лише «user wants to review» → через півроку я не впевнений, яке саме виправлення його породило.

Другий суттєво слабший. Абстрактні принципи не виживають — ніхто не пам'ятає, нащо їх нав'язали.

Дерево рішень: CLAUDE.md vs memory vs нічого

Коли з'являється нова інформація, поставте три питання:

1. Чи може Claude вивести це з коду? Так → нічого не писати.
2. Чи мають усі контриб'ютори цього дотримуватися? Так → CLAUDE.md.
3. Чи зміниться це з часом? Так → memory (з конкретним Why + How to apply).

Третє питання — пастка. Більшість «незмінних» речей, які хочеться занотувати, насправді виводяться з коду — ви просто не хочете, щоб Claude знову робив grep.

Що видно після аудиту

Після одного проходу впадає в очі кілька речей:

• 90 % project_article_workflow виводиться з коду. Цьому запису потрібна найсерйозніша хірургія.
• project_howdev_plan — тимчасова передача; теоретично йому потрібен механізм виходу.
• project_i18n_strategy — стратегічне рішення; варто переглянути за кілька місяців.
• Why у feedback_commits слабкий; додати конкретну подію зробить його надійнішим.

Побіжне спостереження: мій розподіл типів — feedback×2 + project×3, нуль типів user або reference. Тобто я ще не розповів Claude «хто я» чи «з яких зовнішніх систем я читаю стан». Імовірно, це наступна партія для написання.

Наостанок

Найбільша пастка memory — не «те, що я мав написати й не написав». А «те, що я написав, і воно вже застаріло». При 5 записах достатньо одного дрейфу — Claude тихо використовує старі дані для рішень і не повідомить вам про дрейф.

У моїх 5 я вже бачу кілька речей, які хочеться зрушити. А у ваших?