Налагодження й аналіз першопричини

Налагодження починається з фіксації проблеми

Якщо targeted check стабільно падає, кілька правок не допомогли або diff швидко росте, потрібно перейти в діагностичний режим. Нова правка без розуміння причини може лише змінити форму симптому.

Один невдалий запуск ще не доводить серйозний дефект. Спочатку зафіксуйте відтворення, фактичний результат, очікування та актуальний стан змін.

Зберіть компактний пакет доказів

У stack trace спочатку шукайте перший кадр із власним кодом, а потім його викликачів. Для передачі між сесіями зручно вести EVIDENCE_LOG.md, де симптом, очікування, факти й останні зміни не змішані з пропозицією фіксу.

• стабільні кроки відтворення;
• фактичний результат і очікувану поведінку;
• релевантну частину stack trace;
• останні зміни в diff;
• підозрілі файли та виклики;
• команду або запит для повторної перевірки.

Запит на діагностику без редагування

Do not edit files.
Reproduce or trace the reported failure.
Rank possible causes by likelihood.
For each cause, cite code, test, log, or stack-trace evidence.
Propose the smallest check for the leading hypothesis.
Separate evidence, hypothesis, and unknowns.

Мінімальна перевірка гіпотези

Мінімальна перевірка підтверджує розуміння першопричини, але не замінює regression test. Після фіксу сценарій потрібно закріпити тестом на рівні, де проявляється дефект.

1. Повторіть один проблемний запит або команду.
2. Простежте його до точки входу та найближчої бізнес-логіки.
3. Перевірте наявність guard для null або порожніх даних.
4. Зіставте поведінку з stack trace і тестами.
5. Запишіть, що саме підтверджено, а що ще залишається гіпотезою.

Як зупинити patch loop

• Зупиніть поточні правки.
• Перегляньте статистику та зміст diff.
• Скасуйте спекулятивні зміни через контрольований Git-процес.
• Поверніться до відтворення, evidence і однієї провідної гіпотези.
• За потреби почніть нову сесію з коротким контекстом.
• Після підтвердження запишіть root-cause note: механізм, місце доказу та спосіб відтворення.