Режими дозволів і модель підтверджень

1. Режим обирають до першого запиту

Проєктні інструкції ви вже розібрали — тепер до наступного питання: що Claude дозволено робити саме в цій сесії. Permission mode обирають до першого змістовного запиту, а не після першого неочікуваного diff. Це межа допустимої поведінки Claude. Якщо Git baseline відповідає на питання «як відкотити невдалу ітерацію», то permission mode відповідає на питання «наскільки далеко вона взагалі може зайти».

Три шари, які легко переплутати:

Переплутаєте ролі — хаос. Ідеальна гілка та охайний prompt не врятують за надто вільного режиму; суворий режим, навпаки, не дасть назмінювати пів репозиторію навіть за розпливчастого promptʼа.

Звідси звичка: спочатку репозиторій і scope, потім режим доступу, і лише потім — задача. Зайшли досліджувати refund-логіку в режимі швидких правок — уже підняли ризик, не знаючи навіть, у якому файлі причина.

Safe Claude Code workflow = Git baseline + safe permissions + useful project instructions + memory hygiene + diff/tests/human review.

Середину викинути не можна. Про Git пам’ятають, про diff згадують наприкінці, а межа дозволів стоїть рівно між ними.

2. Prompt не замінює режим

Здається, що фразою «виправ усе швидко й не став запитань» можна змінити характер сесії. Не зміните. Prompt описує мету, permission mode — дозволений діапазон дій. У режимі дослідження «внеси зміни просто зараз» не зробить режим робочим; за вільного старту «будь обережним» не додасть обмежень.

Запуск на дослідження в одній із версій:

# Точні назви прапорців і режимів можуть відрізнятися — звіряйте з `claude --help`
git switch -c investigate/refund-order
claude --permission-mode plan   # режим дослідження без правок

Досліджуй, чому в inbox refund-запити йдуть у неправильному порядку.
Файли поки не змінюй.
Поверни:
1. зачеплені файли,
2. гіпотезу причини,
3. план перевірки.

Claude читає й зіставляє, але не перетворює розслідування на імпровізований коміт.

Коли причина ясна і ви переходите до правки:

# Приклад звичайної робочої сесії
git switch -c fix/refund-label
claude --permission-mode default   # звичайна робота з явними approvals

Виправ лише сортування refund-запитів у модулі inbox.
Публічний API не змінюй.
Якщо потрібно вийти за `src/orders/refund/**`, спочатку зупинися і поясни, навіщо.
Після правки покажи diff і які перевірки потрібно запустити.

Обережний prompt усе ще потрібен — але поверх межі, а не замість неї. Умовляти Claude текстом замість налаштування режиму — як повісити на двері серверної табличку «не заходьте» замість замка.

3. Approval model: що можна, а що запитується

Режим зрозуміліший не через назви, а через approval model — модель підтверджень. Частину дій Claude робить спокійно: читає файли, шукає по коду, дивиться логи. Частина проходить через ваш явний контроль: запис у файли, команди з побічним ефектом, масові правки. Деструктивні команди, чутливі шляхи й обхід обмежень не мають ставати рутиною взагалі.

Approval — не надокучливе вікно, а сигнал: ціна помилки зросла, стежте уважно. Зайве підтвердження — секунди. Зайвий git diff іноді коштує сорока хвилин і пари ніякових пояснень на code review.

Approval працює в парі зі scope: обмежили задачу одним модулем — зміна за його межами одразу підозріла. Scope не оголошено — система не помітить, що Claude «поліз допомогти трохи ширше».

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

Тому замість «не питай зайвого» формулюйте так:

Погано:
"Виправ усе швидко й не став запитань"

Краще:
"Спочатку запропонуй план. Змінюй лише `src/orders/refund/**`.
Публічний API не чіпай. Якщо потрібен інший файл — спочатку поясни чому.
Після правки покажи diff."

Prompt задає рамку. Approval стежить, щоб ви непомітно за неї не вийшли. Рішення приймаєте ви.

4. Чотири сімейства режимів, а не таблиця назв

Назви режимів плавають між версіями: default, plan, acceptEdits, щось вільніше. Вчити їх напам’ять крихко — перша нова версія все ламає. Надійніше тримати в голові чотири сімейства поведінки.

Так простіше: важливо не назва кнопки, а хто вам зараз потрібен — дослідник, охайний виконавець чи майже автономний механік.

Вільні режими здаються привабливішими, коли ви втомилися, — і саме тоді вони найнебезпечніші. «Не питай нічого» — коротка дорога до довгого вечора з git restore.

Чим гірше ви розумієте задачу, чим чутливіша зона і чим дорожчий відкат — тим консервативніший режим. Не навпаки.

5. Commerce OS: чотири різні задачі

Ззовні всі чотири схожі на «час попрацювати з кодом», усередині вимагають різної свободи.

Перша — розслідування бага в порядку refund-запитів. Причина невідома: сортування, SQL, DTO або часовий пояс. Вільний режим лише підвищує ризик, що Claude почне правити до доведення причини. Потрібен режим дослідження.

Друга — невелика правка в pet-проєкті або низькоризиковій частині Commerce OS: підпис поля, один метод відображення. Звичайний режим із підтвердженнями — хороший default.

Третя — механічна серія однотипних правок у тестах в окремій гілці, відкат однією дією. Прискорений режим виправданий, але лише за трьох умов одночасно: зона низькоризикова, scope вузький, відкат дешевий і очевидний.

Четверта — чутлива зона: auth, payment, конфігурація, міграції, розрахунок грошей. Гілка здешевлює відкат, але не робить дешевою змістову помилку. Якщо Claude «корисно» змінить контракт, розрахунок комісії або сценарій авторизації, шкода визначається не швидкістю відкату, а тим, наскільки легко ви це помітите. Отже: спочатку дослідження і план, потім дуже акуратні правки під явним контролем.

Практичний поділ:

# Спочатку зрозуміти проблему
git switch -c investigate/refund-order
claude --permission-mode plan   # точна назва може змінитися

# Потім внести невеликий підтверджений фікс
git switch -c fix/refund-order
claude --permission-mode default   # звичайний режим з approvals

Одна задача — дві сесії з різною permission posture. Не параноя, а економія уваги.

6. Зробіть вибір режиму помітним

У будь-який момент ви маєте вміти відповісти собі на «у якому режимі я працюю?» і «чому саме в ньому?». Відповідь «ну, щось звичайне» — привід навести лад у сесії.

Старт короткий: перевірили репозиторій, сформулювали scope, запустили Claude з потрібним режимом і лише потім дали задачу. Для дослідження:

Досліджуй модуль refund.
Знайди, де формується порядок елементів в inbox.
Файли не змінюй.
Поверни лише:
- релевантні файли,
- гіпотезу причини,
- план перевірки.

Такий prompt підтримує режим, а не сперечається з ним: ви не просите «виправити заодно».

Не впевнені в поточному режимі посеред сесії — не вгадуйте за поведінкою моделі. Відкрийте /help, знайдіть команду, яка у вашій версії показує дозволи, і перевірте напряму. Назви змінюються, ідея — ні.

Змінювати режим посеред сесії нормально, але причина має бути інженерною. Довели причину і переходите до вузького низькоризикового фіксу — зрозуміло. Просто втомилися від підтверджень — провісник дивного diff.

7. Консервативний вибір дешевший за вільний

Асиметрія: надмірна строгість дратує, а надмірна свобода спершу приємно пришвидшує, потім дорого обходиться. Тому консервативний вибір — не боягузтво, а зрілість.

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

Звідси робочий режим за замовчуванням. Дослідження — читання і план. Звичайні правки — явні approvals. Вільна автоматизація — лише низький ризик, вузький scope, дешевий відкат. Обхідні режими — лише одноразова пісочниця, яку ви готові викинути. Коротко: вагаєтеся — обирайте суворіше.

Правильно виставлена межа не заважає продуктивності, а тримає її: менше суперечок із Claude, менше розгрібання неочікуваних змін, ясніше розуміння, що ви робите. Тоді scope, project instructions і diff review працюють як інженерна система, а не декоративні слова.