Стартовий ритуал і Git baseline

Безпечний старт починається до промпту

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

Git baseline — це зафіксований стан, з яким можна порівняти результат Claude. Репозиторій не обовʼязково має бути абсолютно чистим, але кожен наявний diff потрібно вміти пояснити до початку нової задачі.

Послідовність baseline

1. Перевірте шлях до поточного каталогу.
2. Виконайте git status і розберіться з кожним modified, deleted або untracked файлом.
3. Створіть окрему гілку для нової задачі, якщо це дозволяє процес проєкту.
4. Перевірте правила .gitignore і фактичний вміст робочої області.
5. Занотуйте дозволені та заборонені частини задачі.
6. Лише після цього запускайте Claude Code і передавайте йому контекст.

pwd
git status
git switch -c fix/refund-inbox-order
git check-ignore -v .env

Що робити з незрозумілим diff

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

Окрема гілка не виправляє змістову помилку автоматично. Вона лише робить межу експерименту видимою та дає змогу повернутися до попереднього стану.

git diff src/support/refund/RefundInboxService.java
git diff
git status

Короткий scope до запуску Claude

• Назвіть конкретну мету, а не загальне «покращити модуль».
• Вкажіть дозволені каталоги або файли.
• Перелічіть зони, які не можна змінювати без окремого рішення.
• Заздалегідь визначте, як перевірятимете результат.

Завдання: перевірити порядок refund-запитів у inbox.
Дозволені зміни: src/support/refund/** і пов’язані тести.
Заборонені зміни: API-контракти, міграції БД, .env* та конфігурація середовища.

Контроль після роботи Claude

1. Перегляньте повний git diff і кількість змінених файлів.
2. Порівняйте фактичну область правок із початковим scope.
3. Запустіть релевантні тести, lint або build.
4. Перевірте ключовий сценарій вручну, якщо автоматичних перевірок недостатньо.
5. Якщо ітерація невдала, спочатку визначте, що саме потрібно залишити або відкотити.

git diff
git restore src/support/refund/RefundInboxService.java
git status