Дисципліна комітів і упаковка PR

Файл, коміт і PR мають різні ролі

Збереження файлів захищає поточну роботу. Коміт фіксує завершений, зрозумілий і потенційно відкотний крок. PR пояснює повну зміну: мету, реалізацію, перевірки, ризики та межі.

Гілка описує задачу загалом, а коміти — окремі етапи її виконання. Великий змішаний коміт ускладнює review, пошук причин і rollback.

Атомарний коміт відповідає плану

1. Перегляньте diff перед індексацією.
2. Додайте лише файли поточного логічного кроку.
3. Не включайте автоматичне форматування, перейменування або сторонній cleanup.
4. Переконайтеся, що призначення коміту можна пояснити одним реченням.
5. Перевірте команду або тест, повʼязані саме з цим кроком.
6. Збережіть окремо documentation чи інші самостійні зміни.

test(checkout): зафіксувати помилку порожнього кошика
fix(checkout): відхилити замовлення без позицій
docs(api): описати відповідь для порожнього кошика

Структура PR_DESCRIPTION.md

• Що зроблено — компоненти, логіка та додані тести.
• Навіщо — проблема й підтверджена першопричина.
• Як перевірити — точні команди, сценарії та очікувані результати.
• Ризики та крайні випадки — що перевірено і що потребує уваги.
• Поза межами — свідомо невиконані суміжні зміни.

Не приписуйте репозиторію вигадані докази

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

Перед публікацією PR звірте кожне твердження. Не пишіть, що тест, документація або coverage оновлені, якщо цього немає у diff та результатах команд.

Перевірка перед упаковкою PR

1. Зіставте diff з approved plan.
2. Перевірте атомарність комітів.
3. Запишіть реальні команди та результати.
4. Додайте root cause, ризики й non-goals.
5. Перевірте, що ручні сценарії відтворювані.
6. Залиште merge та інші зовнішні дії на людське рішення.