Plan mode — дослідження без редагування
Plan mode потрібен для того, щоб підтвердити картину проблеми до змін у репозиторії. Claude читає код, документацію й тести, простежує flow та формує висновки, але не редагує файли.
Результат — компактна Investigation Note, а не енциклопедія проєкту. Вона має бути достатньою саме для конкретного issue.
| Частина нотатки | Питання |
|---|---|
| Точки входу | Де починається сценарій? |
| Runtime flow | Через які методи й шари проходить виконання? |
| Тести | Які regression і сусідні сценарії вже покриті? |
| Спільні механізми | Де працюють validation та error mapping? |
| Точки впливу | Які мінімальні файли можуть бути релевантними? |
| Unknowns і ризики | Що ще не підтверджено або може зламатися? |
Послідовність read-only discovery
- Знайдіть endpoint або іншу точку входу.
- Пройдіть виклик до бізнес-логіки.
- Перевірте тест проблемного сценарію та сусідні випадки.
- Знайдіть спільні validation і error-mapping механізми.
- Перевірте всі використання підозрілого методу.
- Визначте мінімальні можливі точки зміни.
- Зафіксуйте докази, ризики та питання, що залишилися.
Статус кожного висновку
Наприклад, наявність маршруту в конкретному контролері — evidence. Твердження, що саме він є єдиною причиною помилки, — hypothesis, доки не перевірені validation, exception handler та інші виклики сервісу.
| Статус | Значення |
|---|---|
| Evidence | Безпосередньо підтверджено файлом, тестом, логом або документацією |
| Hypothesis | Правдоподібне пояснення, яке ще потрібно перевірити |
| Assumption | Тимчасове припущення через неповну інформацію |
| Unknown | Питання, на яке поки немає відповіді |
Як працювати з unknowns
- Допустиме unknown можна винести на подальше узгодження, якщо воно не блокує безпечний план.
- Блокувальне unknown потрібно дослідити додатково або передати domain owner.
- Контракт публічного API, shared-метод, схема даних і поведінка фонового процесу часто є блокувальними зонами.
- Не перетворюйте відсутність доказів на дозвіл для широкого redesign.
Межі plan mode
- Не редагуйте файли під час investigation.
- Не запускайте неповʼязані рефакторинги.
- Не змінюйте API без підтвердженої потреби.
- Не вигадуйте новий error mechanism, якщо вже існує спільний.
- Не сприймайте впевнену відповідь Claude як доказ.
- Не розширюйте задачу до redesign або UX-змін без окремого рішення.
Канонічне джерело уроку · JavaRush
Відкрити матеріал JavaRush