1. Цифрові сліди Claude Code
Базовий стан Git, проєктні правила, межа дозволів, спільні інструкції — безпечний старт майже зібрано. Залишився тихий шар: сліди сесії.
Сесія не зникає із закриттям вікна. Комп’ютер складає все: історію діалогу, вивід команд, знімки файлів, точки відкоту, пам’ять про проєкт. У Commerce OS Claude бачить файли, логи, результати команд — і локально осідають артефакти з тим, що ви не збиралися показувати: внутрішні адреси, конфіги, токени, клієнтські дані, секрет із виводу невдалої команди.
Карта того, що лишається:
| Що може лишитися локально | Звідки це береться | Чим це небезпечно |
|---|---|---|
| Історія сесій і transcripts | ваші повідомлення та відповіді Claude | туди можуть потрапити внутрішні деталі проєкту, посилання, назви модулів, чутливі дані |
| Історія запитів | те, що ви надсилали в Claude | іноді там лишаються шматки логів, конфігів і невдало вставлені фрагменти |
| Вивід інструментів і команд | git diff, docker compose logs, cat, результати тестів | саме тут найчастіше «вистрибують» секрети та внутрішні адреси |
| Знімки файлів і контрольні точки | автозбереження та точки відкоту | у них можуть жити старі версії файлів із чутливим вмістом |
| Пам’ять про проєкт | автоматично запам’ятовані правила та факти | там може осісти застаріла або взагалі хибна інформація |
Деталі зберігання напам’ять не потрібні — вони змінюються залежно від версії та середовища. Правило простіше: бачили, як Claude отримав дані через файл, команду або ваш текст, — сліди могли лишитися.
flowchart TD
A["Ви відкрили файл або запустили команду"] --> B["Дані з'явилися у виводі"]
B --> C["Claude отримав цей вивід у сесії"]
C --> D["Сліди лишилися в transcripts або snapshots"]
D --> E["Пізніше ви ділитеся логом, скриншотом або проєктом"]
Витік рідко виглядає як «я виклав секрет в інтернет». Частіше: скриншот термінала колезі, лог у тикет, transcript ментору, gist. Local data hygiene — це інженерна акуратність, а не параноя.
2. Типові місця витоку secrets
Більшість витоків починається з «зараз швидко покажу Claude, що в мене в .env». Після цього секрет уже не у файлі — він мандрує логами, transcripts і виводами інструментів.
Секрети живуть не в одному місці: .env, змінні середовища контейнерів, вивід невдалих команд, експортовані CSV, дампи конфігурації, тестові webhook-ключі, логи платіжних інтеграцій. У Commerce OS особливо небезпечне все, що стосується бази, платежів, інтеграцій підтримки та внутрішніх сервісів. Сирий доступ без потреби — і чутливе розмазується по нових артефактах.
Привичка одна: Claude бачить структуру конфігурації, але не реальні секрети. Для цього і є розділення .env та .env.example.
.env
.env.*
!.env.example
.claude/CLAUDE.local.md
.claude/settings.local.json
Реальні значення не йдуть у репозиторій, а шаблон лишається опорою для розмови з Claude.
Приклад шаблону:
# Локально заповніть своїми значеннями
POSTGRES_URL=postgres://app:ваш_пароль@localhost:5432/commerce
STRIPE_SECRET_KEY=sk_test_заповніть_локально
SUPPORT_API_TOKEN=token_заповніть_локально
PAYMENT_WEBHOOK_SECRET=whsec_заповніть_локально
Claude аналізує, які змінні потрібні проєкту, не бачачи значень. Питання не «прочитай мій секрет», а «скажи, чого застосунку бракує за шаблоном і конфігами».
Добра постановка:
Перевір, які змінні середовища потрібні застосунку.
Використай `.env.example`, `README.md` і конфіги запуску.
Файл `.env` не відкривай.
Реальні значення ключів не запитуй.
Коли змінної бракує, наведи лише її назву.
Задачу не приховуєте, зайве не тягнете. Один рядок економить багато нервів.
Перевіряйте себе: покажу завтра цей transcript колезі або ментору — чи буде там те, що не можна показувати? «Можливо» — означає, що ви вже зайшли надто далеко.
3. Transcripts, логи та публікація
«Я ж просто надіслав лог у підтримку» — типова помилка з обличчям невинності. Лог, transcript або скриншот термінала — не текст, а пакет даних: адреси, токени, пошти, внутрішні хости, ідентифікатори клієнтів. Згадуєте про них за дві хвилини після надсилання.
Ділячись чимось назовні — інтернет, чат команди, тикет, ментор — думайте не «це вивід команди», а «це артефакт, який треба підготувати»: очистити, скоротити, сховати зайве. Це sanitation.
Наочніше на прикладі:
До очищення:
Authorization: Bearer sk_live_xxxxx
Хост БД: pg-prod.internal.company
Електронна пошта клієнта: olga@company.com
Після очищення:
Authorization: Bearer ***REDACTED***
Хост БД: ***INTERNAL_HOST***
Електронна пошта клієнта: ***REDACTED_EMAIL***
Лог не втрачає користі: видно авторизацію, проблему у внутрішній базі, клієнтські дані в потоці. Чутливі дані більше не видно.
Те саме з transcripts. «Зручно для розбору» не означає «надсилати як є». Перед відправленням пройдіться по категоріях:
токени і ключі; внутрішні домени та IP; e-mail і персональні дані; реальні ID замовлень і платежів; вміст .env; службові шляхи компанії.
Окремий момент — передавання проєкту між машинами або людьми. Здається, що це просто git push. Насправді ширше: локальні нотатки, чутливі transcripts, старі знімки, історія сесій — ви передаєте не лише код, а й шлейф навколо нього. Перед зміною машини, публікацією навчального репозиторію та показом матеріалів думайте про локальний стан, а не лише про репозиторій.
4. Довга сесія дорожча й дурніша
Звести usage лише до грошей — вузько. Навіть безкоштовна сесія з довгим брудним контекстом дорога за часом, увагою та якістю. Утомлена сесія думає гірше: AI плутається, коли на стіл висипали одразу всі папери зі шафи.
Команда або екран для usage у Claude Code є. Назви змінюються від версії до версії — сумніваєтеся, дивіться /help і підказки продукту. Дивляться usage не заради статистики, а щоб зрозуміти, де ви почали платити за хаос.
«Дорогими» виявляються типові патерни:
| Патерн | Що зазвичай відбувається | Що краще зробити |
|---|---|---|
| Вставили величезний лог цілком | Claude витрачає увагу на шум і втрачає саму задачу | дати лише фрагмент навколо помилки |
| П’ять спроб підряд лагодити одне й те саме | у сесії накопичуються старі гіпотези та плутанина | зупинитися і перескласти контекст |
| Тримаєте одну сесію «на все» | змішуються непов’язані задачі й рішення | розділяти роботу за задачами |
| Лишили фонову роботу висіти без потреби | ростуть витрати та губиться керованість | закривати зайве і фіксувати стан |
| Підключили зайві інструменти й плагіни | зростає контекстне навантаження | тримати лише те, що справді потрібно |
Помічайте не тільки вартість, а й симптом якості. Claude повторює стару хибну гіпотезу, забуває межі задачі, просить перечитати прочитане, пропонує «про всяк випадок переписати половину проєкту» — це не зла воля. Сесія розрослася і втомилася.
Тоді не вмовляйте модель ще одним уточненням — зробіть крок назад. Іноді вистачає скоротити лог і переформулювати запит; іноді краще почати нову сесію; іноді — розбити задачу на дві. Після «ще один раз» починається цифрова археологія.
Перед довгою вставкою поставте собі два запитання:
це справді потрібно моделі для розв’язання задачі?
Чи залишиться суть, коли прибрати дев’ять десятих тексту?
У дев’яти випадках із десяти відповідь на друге запитання — «так». Це знак, що сесією керуєте ви, а не вона вами.
5. Безпечна модель роботи: п’ять опор
Безпечна робота тримається не на одному прийомі, а на кількох опорах. Заберете будь-яку — система не впаде миттєво, але стане помітно крихкішою.
| Опора | Запитання, яке варто поставити собі |
|---|---|
| Git baseline | Я точно працюю у зрозумілій гілці та з чистого стану? |
| Permissions | Claude не може більше, ніж потрібно для цієї задачі? |
| Project instructions | Він знає команди, правила та межі проєкту? |
| Local data hygiene | Я не тягну в сесію секрети й не розношу їх по логах? |
| Review людиною | Я все одно перевірю diff і результат сам? |
Опори поєднуються з CLAUDE.md, який ви писали в попередній лекції. Туди доречно вписати нагадування про data hygiene, щоб не сподіватися на пам’ять:
## Гігієна даних
- не читати `.env` і файли із секретами без явної причини
- для конфігурації спиратися на `.env.example`
- перед публікацією логів і transcripts робити очищення
- під час довгої сесії спершу скоротити контекст, потім продовжувати
Це не жорсткий захист, а контекст для себе і для Claude. .gitignore, permissions і людський контроль він не замінить, але нагадує про правильну поведінку, коли хочеться зрізати кут.
Звичайна ситуація: відкриваєте Commerce OS або pet-проєкт — чиста гілка, зрозумілий scope, помірний permission mode, короткий CLAUDE.md, нормальний .env.example, secrets лише локально. Показали Claude потрібний шматок логу, а не весь серіал. Подивилися diff і не надіслали transcript без очищення. Це і є спокійна, зріла робота.
Так формула рівня перетворюється на звичку: безпечний Claude Code workflow — це Git baseline, акуратні permissions, корисні project instructions, чиста local data hygiene і обов’язковий людський review. Коли ці пʼять речей на місці, Claude прискорює розробку. І лише тоді має сенс говорити з ним не буденним «зроби ось це», а інженерною задачею — з межами, критеріями та перевіркою.
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ