Hook debugging, побічні ефекти та відновлення

Діагностуйте hook по шарах

Помилку hook потрібно локалізувати послідовно: спочатку перевірити реєстрацію і scope, потім event та matcher, далі handler і його exit code, а після цього — побічні наслідки. Це відділяє помилку конфігурації від помилки самого скрипта.

Handler корисно запускати вручну з тими самими параметрами, які отримує hook.

1. Перевірте, чи конфіг завантажений у правильному scope.
2. Перевірте event, tool, path і matcher.
3. Запустіть handler окремо.
4. Перевірте stdout, stderr і exit code.
5. Знайдіть зайві зміни, затримки, цикли або витік даних.
6. Тимчасово вимкніть automation, якщо вона заважає роботі.

Типові причини несправностей

Контролюйте побічні ефекти

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

Recovery path має бути очевидним

Зміни automation супроводжуйте diff і коротким записом у changelog або README. Надійний hook тихий, обмежений за сферою, передбачуваний і легкий для діагностики.

Format-on-edit: сценарій перевірки

1. Відтворіть проблему на конкретному файлі.
2. Переконайтеся, що hook активний і реагує на правильну подію.
3. Запустіть handler окремо.
4. Звузьте matcher до потрібних розширень.
5. Додайте guard для generated-файлів.
6. Перевірте звичайний і виключений випадок.
7. Зафіксуйте оновлення як командний артефакт.